Orientation and Geodetic Data – Part 1
I recently read an interesting article by Simon Greener on some of the challenges of accessing Oracle Spatial data created by ESRI’s ArcSDE. He highlights two classes of polygons that are valid in ArcSDE and not in Oracle Spatial, and how you might work with them. This inspired me to discuss another situation where there are two very similar representations of spatial data that are subtly different: Microsoft SQL Server’s planar and geodetic spatial types.
It is very common for spatial data to be stored in geodetic coordinates: latitude, longitude, and perhaps some kind of height. Some software can interpret this data geodetically, taking advantage of a model of the earth’s shape to correctly answer questions like, “what is the distance between two points as the crow (or airplane) flies?” Short of this ability to directly manipulate geometry on the globe, the next best option is to project the data onto a plane that minimizes distortion for a limited region, and analyze or manipulate the data in that context.
When reasoning about areas geodetically, a natural ambiguity arises: if you draw a circle on the globe, does that circle represent the small area inside or the large area outside? Similarly, if you draw a circle around the globe at some latitude, does that represent the area above or below that circle? Some, but not all, geodetic-savvy spatial databases use orientation to make this distinction.
Figure 1: Example of the left-hand rule for geodetic data. A person walks around the outside perimeter with their left hand touching the boundary. If there are holes, the person walks around them from the inside, giving them opposite orientation.
Figure 2: Contrast the right-hand rule often used with 3D data where you curl your fingers in the direction of the polygon vertices and your thumb shows which side is “up”.
This brings us to an interesting problem: what if the data you want to load doesn’t already follow these orientation conventions? Because this situation is inherently ambiguous, you have to choose the polygon orientation that encloses the smaller area, i.e. the geometry in question and not the rest of the world. Jason Follas discussed this challenge in the context of loading geodetic data into SQL Server last November.
In Part 2 to follow next week, I’ll discuss three pitfalls that can arise when you try to solve this orientation problem without considering the earth’s shape.
No related posts.
