It escapes me why degrees and distance in meters is a "natural" measurement. To me, that's an arbitrary decision that somebody made (here).
Its not arbitrary. Look up your home town on wikipedia, the location is given in latitude and longitude, not radians. This is just the way it is, its not any decision that was made here, and its not arbitrary at all. It is just the way the world works, that is what people have.
The distance in meters as being the way you specify radii of circles is the most problematic.
Well, this is how people measure distance in this world! How else should i find a pizza restaurant near my house? What units should i use if not meters? What does Geo3D want instead?
But I fully understand that Lucene has already decided what units it intends to use and Geo3d in its current form is incompatible with that. And yet, "meters" implies a surface distance and geo3d doesn't even have a concept of surface distance. You could describe radii in degrees and that could match, but that's not compatible with the 2D implementation.
So should I withdraw this contribution entirely? What is your suggestion?
My suggestion is to do some "hiding" of the internal details. I think all mike wanted to do was benchmark the distance query, to see how 3D compares against 2D.
So it would be better to provide a Geo3DPoint class that has less parameters (no PlanetModel), takes degrees (not radians), etc. It can internally do any conversion that is needed to work with Geo3D.
Nobody is arguing about what geo3d geometry apis should take. But can we fix the API to be easy to use for a lucene user? If Mike cannot figure out how to do these things, I think nobody else stands a chance.