Remove split_flipped_bbox and hardcoded {-180, -90, 180, 90} boundary

[natevw]

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.

[vmx]

Those values are just defaults if you don't add a bounding box to the query.

The current GeoCouch has nothing to do with projections, coordinates etc. It is a simple store for numbers in two dimensions. So the name (for the current implementation) is a bit misleading. I'd like to build a projection (and what belongs to it) on top of GeoCouch, perhaps even in another language. The core of GeoCouch will stay a simple store for making range queries.

[natevw]

My complaint is the feature touted in the project readme as "solving" the anti-meridian/pole problem: "A common problem when performing bounding box searches is the date line/poles...GeoCouch automatically detects [flipped] bounding boxes and returns the expected result."

The reason the poles and the anti-meridian are "problems" is that developers want to have the earth both ways: a flat surface for cartesian concepts like rectangular bounding boxes, but still expect the "magic" topology of a sphere. It doesn't work.

I'm asking that you remove the magic bbox wrapping (ie split_flipped_bbox) across the hard-coded {-180, -90, 180, 90} boundary. This builds in confusion between lat/lon coordinates and the actual flat 2-d space GeoCouch works in. Once that is removed, then GeoCouch will have nothing to do with coordinates, as I agree it should, until (as you say) a CRS/projection layer is added.

[vmx]

You are right about the confusion. I should add a remark about it to the readme. The reason why this feature exists (the automatic flipping) is, that this way GeoCouch can be easily be used with web mapping clients (like OpenLayers or Google Maps).

[natevw]

Can we just encourage client code to split their query if it wraps? Otherwise, I think the {-180, -90, 180, 90} range needs to be a property of the design document instead of being hardcoded. If it's really truly needed for this special projection, then it's needed for other projections whose boundaries are a different size.

[vmx]

The Erlang code is there, if you need it I can expose it as query parameter.

[vmx]

natevw,

after some thoughts, you are completely right, I'm sorry for not having had this understanding earlier. The next version of GeoCouch will only support wrapping when explicitly set.

Cheers,
Volker