Geospatial data support in OData–Strawman proposal
For those of you interested in Geospatial issues – check out the new strawman proposal for adding Geospatial to the OData protocol.
This is a strawman proposal. Please challenge it in the OData mailing list.
OData supports geospatial data types as a new set of primitives. They can be used just like any other primitives - passed in URLs as literals, as types and values for properties, projected in $select, and so on. Like other primitives, there is a set of canonical functions that can be used with them.
The only restriction, as compared to other primitives, is that geospatial types may not be used as entity keys (see below).
The rest of this spec goes into more detail about the geospatial type system that we support, how geospatial types are represented in $metadata, how their values are represented in Atom and JSON payloads, how they are represented in URLs, and what canonical functions are defined for them.
Our type system is firmly rooted in the OGC Simple Features geometry type system. We diverge from their type system in only four ways.
Figure 1: The OGC Simple Features Type Hierarchy
Cross Posted from Dan Fay's Blog (http://blogs.msdn.com/dan\_fay)