(As an side, when using Oracle Spatial, the standard “trick” to fix polygon problems, including ring orientation, was to do a self-intersect using SDO_GEOM.SDO_UNION the use of SDO_MIGRATE.TO_CURRENT was also another method. Since this is an OGC-based method, working on the entire geometry for a given feature, it forces polygons into the orientation required for the method – which just happens to be the one used for the Geography type (quite a coincidence, eh? 😉 The key to this behavior is the the STUnion() method.
Then, Ed lets the power of STUnion() be known: ORA-13367: wrong orientation for interior/exterior ringsĬause: In an Oracle Spatial geometry, the exterior and/or interior rings are not oriented correctly.Īction: Be sure that the exterior rings are oriented counterclockwise and the interior rings are oriented clockwise.) (Note: Oracle’s SDO_Geometry polygons, to be valid, must have anti-clockwise outer ring rotation and clockwise inner ring rotation otherwise SDO_GEOM.VALIDATE_GEOMETRY will return: The same goes for inner rings (holes), which SQL Server will orient to clockwise. If SQL Server finds outer rings oriented in a clockwise direction, it will re-orient such rings to counter-clockwise – the direction required for outer rings in the Geography data type. When executing an OGC-based method (which works on the entire geometry) on valid polygon features in the Geometry data type, SQL Server will check ring orientation. However, it appears that the geometry type in SQL Server 2008 not only doesn’t suffer from this but that it also attempts some correction:
SQL Server does not allow polygons with the “wrong” ring orientation into the Geography data type Now, my colleague’s problem stems from the fact that, as Ed tells us: One of the most common data errors when attempting to import spatial data into the Geography data type involves the ring orientation of polygons With a bit of directed questioning I found out that my colleague’s problem is predominantly with polygon ring orientation.Įd Katibah’s blog article Working with Invalid Data and the SQL Server 2008 Geography Data Type, Part 1b is instructive as it informs us that: All files import ok into geometry data type, but I shouldn’t store them like that. I suspect something about the coordinates not being valid Geography data types in SQL, but not sure how to check for this or fix.
I’m using the free Shape2SQL or EasyLoader. I’m migrating mapinfo and/or shapefiles GDA94 files into sql 2008 geography data type (SRID 4283). A colleague is trying to load shapefiles into SQL Server 2008 and asked me the following question:
0 kommentar(er)
