Post on 15-Jul-2015
Well that seems dumb?
• GeoJSON spec doesn’t specify a winding order
• S2Loop (the C++ polygon implementation)
– Picks the “inside” of the polygon to be the smaller of the two regions enclosed
• When you are asking small mobile app type queries it doesn’t really matter
I am an airplane at [0, 0]What airports are within my flight range?
1 2
34
Start with a plane with a medium sized flight range polygon
I am an airplane at [0, 0]What airports are within my flight range?
1 2
34
If it’s a longer range plane, that polygon gets bigger
I am an airplane at [0, 0]What airports are within my flight range?
Eventually polygon get so big it covers more than 50% of the planet
4
1 2
3
I am an airplane at [0, 0]What airports are within my flight range?
Well, that’s a problem …Mongo 2.6 doesn’t let you query by a “Big” Polygon
1 2
34
Mongo 3.0 BigPolygon
• GeoJSON shapes are defined inside a “Coordinate Reference System” (CRS)
• 3.0 has a new CRS that respects winding order
• Nothing changes unless you explicitly use the new CRS
• As of writing this, the CRS is:
"urn:x-mongodb:crs:strictwinding:EPSG:4326"
What you can do in 3.0
• Everything you used to be able to do with no code changes
• You can now specify big query polygons without ambiguity or hard to predict behavior when the polygon gets “big”
• You can query by a polygon specified in the new CRS– $geoWithin, $geoIntersects– That polygon is allowed to be BIG
• That’s it … nothing else is new
How do I do that?
// build some geo JSON
var crs = "urn:x-mongodb:crs:strictwinding:EPSG:4326”;
var bigCRS = { type : "name", properties : { name : crs } };
var bigPoly = { type : "Polygon",
coordinates : [
[[-10.0, -10.0],
[10.0, -10.0],
[10.0, 10.0],
[-10.0, 10.0],
[-10.0, -10.0]]],
crs : bigCRS
};
var cursor = db.<collection>.find({
loc : { $geoWithin : { $geometry : bigPoly } }
});
var cursor = db.<collection>.find({
loc : { $geoIntersects : { $geometry : bigPoly } }
});