Description
GeoCouch's casual treatment coordinate systems in its bounding box query bothers me:
./src/vtree/vtree.erl:84:
lookup(Fd, Pos, Bbox, {FoldFun, InitAcc}, {-180, -90, 180, 90});
This hardcodes a plane bounding rectangle corresponding to spherical(/ellipsoidal) coordinates, which gets used to split an invalid bounding box into two pieces "wrapped" around the sphere.
While I understand your good intentions behind this, I'm worried you are trying to merge spherical and plane coordinate systems. This is something I repeatedly tried to do in my first years of cartographic programming, and I've never seen it end well. [This is one of the architectural problems with OpenLayers, it tried to conflate plane and sphere coordinates by simply calling the latter LonLat instead of LatLon.]
Here's the problem:
GeoCouch adds a 2-dimensional /cartesian/ spatial index to CouchDB. This bounding box (may I say) "hack" on the other hand, implies that GeoCouch indexes /spherical/ coordinates. This may further confuse users regarding this important distinction. For example, the spatial_updater simply uses min/max to calculate bounding boxes for the contained shape. If I try to index a "spherical" linestring whose geodesics cross the antimeridian, the calculated (cartesian) bounding box will be essentially incorrect.
I suggest that GeoCouch make it clear that it supports cartesian (i.e. projected) coordinate systems only, reminding the user to take special note that when they emit e.g. WGS-84 [lon,lat] pairs, they are working on a plate carrée projection, not on a sphere.