Equator and Meridian are problematic. In the end, this is an approximation: In order to determine features which actually intersect, you have to do a post-query limit. (This is also true in PostGIS: You do a “the_geom && bbox AND ST_Intersect(the_geom, bbox)” to get features which actually intersect.) Features which cross a top-level boundary like the equator or dateline will cover the entire range of the world in that dimension. For this demo, this works out okay because such features are usually excluded in the other direction: you end up with (for example):

10101210

where the ‘1111′ is the dimension in which the feature has crossed the top-level boundary of the meridian or equator. Then, because you query is looking only for features > ‘01′ and less than ‘22′ (for example), you won’t hit that feature.

This isn’t a perfect solution: it doesn’t push all the things into the datasource that you actually need. But it provides a first-order limit, which you can use to pull out a mostly-correct list that you can filter on.

This indexing scheme of “truncated geohashes” then is isomorphic to the long-established concept of using Quadtrees as a index structure.

Quadtrees is a viable spatial indexing technique for a planar space. There are issues with using it for indexing data on the sphere - it doesn’t handle objects which cross a pole, or which cross the data line.