ludicrously small data set of two numbers. Afterwords,
let’s try to pick the best visualization.” —45 Ways to Communicate Two Quantities | Visual.ly Blog (via notational)
Currently, and for the approximately zero people that are interested, mongoimport fails when importing large hex-encoded WKB geometry representations (approximately 4MB or larger). Which is a reasonably big and/or reasonably complex multipolygon for those playing along. MongoDB has a document size limit of 16MB. So there is some disconnect between what is importable and what is storable. And, yes, I do have a 16MB WKB polygon, i.e. many many nodes. That is a honking big geometry in any format.
Anyway, all of this is to say that despite some noise about how MongoDB (or pick your flavor of NoSQL) should have true geospatial support, instead of just points, I suspect that those implementations will be some time in coming based on these limitations. If it can’t handle complex polygons, it can’t really handle polygons. We could debate WKB vs WKT vs some geometry object that isn’t stringified; that isn’t really the point. The point is large, complex geometries exist in the world and spatial is a whole heck of a lot more than some dinky little point for a check-in. And when you see folks talking about their big geospatial data in mongo, they are generally talking about the equivalent of an ascii grid in the document - a 2D matrix tagged with the x, y of the cell centroid, cell value, and some metadata defining the origin and cell size, etc. So they’ve implemented an ascii grid in the fancypants nosql. I’ll just remember the look of horror on a colleague’s face as he told me about how raster data used to be stored in text files! as a matrix! that may not have a spatial reference! Kids with CS degrees, let me tell ya.