C# SQLGeography: Diagnose ungültiger Geometrien

Question

Wir haben eine große Menge an Geografie in MapInfo-Tabellen gespeichert, die wir jetzt in SQL Server speichern möchten. Wir haben C# -Dienstprogramme geschrieben, um die Geografie aus den MapInfo-Dateien zu lesen und sie in den SQL-Server zu importieren. In den meisten Fällen funktioniert das gut. Nach vielen Cleanup-Pässen mit Werkzeugen, die wir selbst entwickelt haben, bleiben uns jedoch eine beträchtliche Anzahl von Regionen, die von SqlGeography.STIsValid() als ungültig angesehen werden.

Für die meisten oder alle dieser Fälle kann die .NET-Methode SqlGeography.MakeValid() eine gültige Geografieinstanz erstellen. Die Dokumentation dazu ist jedoch ziemlich dürftig, und wir sind nicht damit zufrieden, einfach die Änderungen zu akzeptieren, die MakeValid macht, ohne die Gründe dafür zu verstehen, dass die Geographie als ungültig betrachtet wird und was sie tut, um sie zu korrigieren.

Durch den Aufruf IsValidDetailed erhalten wir eine kryptische Fehlermeldung, die nicht gut dokumentiert ist. Für viele der Fälle sieht die Zeichenfolge zurückgegeben von IsValidDetailed etwas wie folgt aus:

24404: Nicht gültig, da Polygonring (1) schneidet selbst oder einen anderen Ring. Das Problem tritt in Eintrag (19) in einer Geometriesammlung auf

Alle Geografieobjekte, die wir importieren möchten, sind Multipolygone. Durch das Parsen dieser Fehlermeldung haben wir versucht, die problematischen Polygone und Ringe innerhalb dieser Polygone zu identifizieren. Wir stellen jedoch fest, dass die Indizes nicht wirklich mit den tatsächlichen problematischen Polygonen/Ringen übereinstimmen. In vielen Fällen liegen die Indizes außerhalb der Grenzen der Arrays der Eingabegeometrien.

Gibt es eine bessere Möglichkeit, den genauen Grund für ein Geometrie-/Geografieobjekt anzugeben, das als ungültig betrachtet wird, und um festzustellen, welche Polygone, Ringe oder Punkte problematisch sind?

Answer 1

Ich habe diesen Fehler mehrmals selbst durchlaufen. Es ergibt sich normalerweise aus der Tatsache, dass SQL Server erfordert, dass die Punkte im Gegenuhrzeigersinn aufgelistet werden. Wenn Punkte im Uhrzeigersinn angeordnet sind, wird die Ausnahme erzeugt, die Sie sehen.

ist hier eine große visuelle: http://danielwertheim.se/sqlgeography-in-sql-server-2012-polygon-must-start-on-correct-position-no/

... und für eine praktische Lösung, dieses Blog-Post check out: http://blogs.msdn.com/b/edkatibah/archive/2008/08/19/working-with-invalid-data-and-the-sql-server-2008-geography-data-type-part-1b.aspx