Announcing Geospatial support in Azure DocumentDB!

We are excited to announce support for geospatial indexing and querying in Azure DocumentDB! The latest DocumentDB service update includes support for automatic indexing of geospatial data, as well as SQL support for performing proximity queries stored in DocumentDB. If you download version 1.4.0 of the .NET SDK, you'll also find new types for representing points and polygons, support for creating and enabling spatial indexing on DocumentDB collections, and new LINQ query operators for performing spatial queries. As we described in the "Schema Agnostic Indexing with Azure DocumentDB" paper, we designed DocumentDB’s database engine to be truly schema agnostic and provide first class support for JSON. The write optimized database engine of DocumentDB now also natively understands spatial data represented in the GeoJSON standard.

Query Geospatial data with SQL

What kinds of queries can you perform with DocumentDB? Try it for yourself at the DocumentDB playground! We've pre-created a DocumentDB collection in the playground with a scientific dataset containing JSON data about volcanoes. For example, here's a query that returns all volcanoes within 100 km of Redmond, WA using the built-in function, ST_DISTANCE. Find locations within a certain radius: You can also use ST_WITHIN to check if a point lies within a polygon. Commonly polygons are used to represent boundaries like zip codes, state boundaries or natural formations. Again if you include spatial indexing in your indexing policy, then "within" queries will be served efficiently through the index. Find locations within a polygon boundary: Here's what one of our customers had to say about the feature: "Having the backend do the heavy lifting of “location and distance” math married with the power of querying geospatial data via LINQ makes DocumentDB a perfect backend for modern location based applications.” - Ryan Groom, Founder, Trekkit.com

How does spatial indexing work in Azure DocumentDB?

In a nutshell, the geometry is projected from geodetic coordinates onto a 2D plane then divided progressively into cells using a quadtree. These cells are mapped to 1D based on the location of the cell within a Hilbert space filling curve, which preserves locality of points. Additionally when location data is indexed, it goes through a process known as tessellation, i.e. all the cells that intersect a location are identified and stored as keys in the DocumentDB index. At query time, arguments like points and polygons are also tessellated to extract the relevant cell ID ranges, then used to retrieve data from the index. Learn more about this feature here.