On Jan 4, 2010, at 4:19 PM, Yonik Seeley wrote: > On Mon, Jan 4, 2010 at 2:29 PM, <gsing...@apache.org> wrote: >> + public static final double KM_TO_MILES = 0.621371192; >> + public static final double MILES_TO_KM = 1.609344; > > I don't care if these exist, but what are your plans for actually using them?
Probably premature to commit on my part, I was working on SOLR-1568 and was allowing the user to pass in the units for the distance value. > > For spatial search, it seems like we should simply standardize on > something, probably either meters or kilometers and be done with it. > It's trivial for clients to convert (and clients aren't end-users), > and will reduce confusion about how to specify units, etc. > > Likewise for points/locations - they should simply be lat,lon in > degrees. No need to specify if it's in radians or degrees when > degrees is more of an external standard and it's as simple for a > client to convert as it is to specify. Possibly, except you can save a few operations per document if you just store radians when using haversine. I'm just not sure I see this as a big deal. Technically, we could hide all the complexity of numerics from the user too, but yet we offer ints, floats and doubles (we could parse them on our side and figure out which is what). I'm more of the mindset that I think the app designer should be able to make the choice, but possibly with some guidance from us as to what is appropriate for each situation, just as we do with other field types.
