5

We have a large amount of geography stored in MapInfo tables that we would now like to store in SQL Server. We have written C# utilities to read the geography from the MapInfo files and import them into SQL server. For the most part, this is working well. However, after many cleanup passes using tools we have developed in house, we are still left with a significant number of geographies that are considered invalid by SqlGeography.STIsValid().

For most or all of these cases, the .NET method SqlGeography.MakeValid() is able to create a valid geography instance. However, the documentation on this is pretty poor, and we aren't content with simply accepting the modifications that MakeValid makes without understanding the reasons for the geography being considered invalid and what MakeValid does to correct them.

By calling IsValidDetailed, we get a cryptic error message that is not well documented. For many of the cases, the string returned by IsValidDetailed looks something like this:

24404: Not valid because polygon ring (1) intersects itself or some other ring. The problem occurs in entry (19) in a geometry collection

All of the geography objects we are trying to import are multipolygons. By parsing this error message, we have tried to identify the problem polygons and rings within those polygons. However, we are finding that the indexes do not seem to actually match the actual problematic polygons/rings. In many cases, the indexes are beyond the bounds of the arrays of the input geometries.

Is there a better way to pinpoint the specific reason for a geometry/geography object being considered invalid and to pinpoint which polygons, rings, or points are problematic?

APH
  • 4,109
  • 1
  • 25
  • 36
jmcstwm
  • 51
  • 3

1 Answers1

0

I've ran into this error several times myself. It usually stems from the fact that SQL server requires the points be listed in counter-clockwise order. When points are in clockwise order, it generates the exception you are seeing.

Here is a great visual: http://danielwertheim.se/sqlgeography-in-sql-server-2012-polygon-must-start-on-correct-position-no/

...and for a practical solution, check out this blog post: 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

Daniel
  • 8,133
  • 5
  • 36
  • 51
Nick
  • 13
  • 3
  • Thanks for your reply. While point orientation can be a cause of the error, in our case it is not. We have code that automatically detects the orientation and fixes it if not correct. The remaining geometries that are invalid are invalid for some other reason. – jmcstwm Jul 15 '15 at 17:32