Hi David, as I wasn't really sure about what to answer to your question, i looked a bit around: http://geocoder.us/blog/2006/03/23/how-many-digits-are-enough/ if their data is correct: 0.000001 degrees are 4.37184 inch or 11.1044736 centimeters that ought to be enough for everyone ;-)
seriously: I think for applications like mapping out addresses that should be enough for years, but there may be other use cases i can't imagine right now. --Roland On Tuesday 01 July 2008 21:21, David E Jones wrote: > Thanks for your comments Roland. I agree now that using a floating > point number is the best way to store them. > > Right now we kind of "hack" floating point numbers for most databases, > ie we actually use a fixed-point number with only 6 decimal places. > > I'm guessing for something like lat/long coordinates we'll want more > than 6 decimal places, so we might need to introduce a new field type > for this (which isn't difficult). > > From your experience how many digits of precision within a degree is > needed for good lat/long coordinates? > > -David > > On Jun 28, 2008, at 2:53 PM, RolandH wrote: > > Hi David, > > > > just to comment on formating: > > please save lat/long in degrees and use float or numeric types for > > that, because with that you may do perimeter searches with db support: > > Having point P with lat/long and a radius, you can select all other > > points from db which are within a square (center is P) supported by > > indices of you're db. Afterwards you have only a limited set to > > check against the radius again. > > If you're database supports sin() / cos() you may take a look here > > http://earthcode.com/blog/2006/11/hey_want_to_sort_your_query_by.html and > > do everything with sql :) > > > > Greetings, > > Roland > > > > David E Jones wrote: > >> The idea of having more generic lat/long coordinates is > >> interesting. For example, we could: > >> > >> 1. add lat/long fields to ContactMech > >> 2. create a new ContactMechType for geo-spatial coordinates like > >> this, like "TerrestrialPosition" or something > >> 3. add a new entity for TerrestrialPosition that is independent of > >> the ContactMech and Geo entities, and then related to with other > >> entities > >> > >> We also need to discuss how to format these. They will probably > >> need to be string/text values so we can store these in any > >> database, so do we want the degrees/minutes/seconds/sub-seconds > >> format, or the degress/minutes/sub-minutes format, or the degrees/ > >> sub-degrees format, or something else? > >> > >> Also, I'm wondering if there is a good open source java library for > >> handling these, or even a standard object in the Java API (I'm not > >> aware of one, but haven't looked either). It would be nice to have > >> something to parse and normalize the strings and such, and of > >> course do calculations for distance or to see if a coordinate is > >> within a certain area, etc. > >> > >> Jacques: for your needs now you might want to consider using extend- > >> entity if your timeline is tight. I'm guessing this needs more > >> discussion and research, etc before we get something good in place. > >> > >> -David > >> > >> On Jun 28, 2008, at 12:34 PM, Jacques Le Roux wrote: > >>> Hi Rob, > >>> > >>> I tested with some commercial addresses I will need to locate > >>> (here in France) : results are not good enough... Morevover the > >>> company I will do that for is already using (lat., long.). So I > >>> will really need them. So my question to the community remains : > >>> PostalAddress or extend-entity ? > >>> > >>> Thanks > >>> > >>> Jacques > >>> > >>> Jacques > >>> > >>> From: "Jacques Le Roux" <[EMAIL PROTECTED]> > >>> > >>>> Thanks Rob, > >>>> > >>>> This is an interesting information, I'm just discovering Google > >>>> Map API and related... > >>>> > >>>> Jacques > >>>> > >>>> From: "Rob Schapper" <[EMAIL PROTECTED]> > >>>> > >>>>> Jacques, > >>>>> > >>>>> Wouldn't it make more sense to use the google geocode methods to > >>>>> get the lat/long from an address rather then store that info in > >>>>> ofbiz? > >>>>> > >>>>> Rob > >>>>> > >>>>> On Jun 27, 2008, at 3:59 PM, Jacques Le Roux wrote: > >>>>>> Hi Chris, > >>>>>> > >>>>>> It was a long time :o), thanks for comments > >>>>>> > >>>>>> I need them to use with Google Map. To do something like > >>>>>> http://code.google.com/apis/maps/documentation/examples/marker-simpl > >>>>>>e.html you can see there map.setCenter(new GLatLng(37.4419, > >>>>>> -122.1419), 13); > >>>>>> > >>>>>> Hopefully I will be able to do something general enough to be > >>>>>> reusable (should not be too hard, the tough part is already > >>>>>> done by > >>>>>> Google) > >>>>>> > >>>>>> Jacques > >>>>>> > >>>>>> From: "Chris Howe" <[EMAIL PROTECTED]> > >>>>>> > >>>>>>> I wasn't going to comment on this because I don't think I have > >>>>>>> the time available to see the discussion through to the end, > >>>>>>> but > >>>>>>> after reading David's "Data Model Changes Post", I'll toss my > >>>>>>> two cents about this. > >>>>>>> > >>>>>>> What are you wanting to ultimately do with Lat/Long? From my > >>>>>>> experience with GeoServer earlier this year, storing Lat/Long > >>>>>>> values > >>>>>>> is rather inconvenient when doing computations and placing > >>>>>>> points (and polygons) on Maps. It was much more convenient > >>>>>>> to store > >>>>>>> these points in the manner prescribed by postgis and using > >>>>>>> the methods that are provided in those kinds of packages. > >>>>>>> Also, as far > >>>>>>> as data modeling, it's somewhat innacurate (although depending > >>>>>>> on your application, possibly within acceptable bounds) to > >>>>>>> refer to > >>>>>>> an address as a point that has the specificity you'd be > >>>>>>> assigning. > >>>>>>> > >>>>>>> Jacques Le Roux <[EMAIL PROTECTED]> wrote: Hi, > >>>>>>> > >>>>>>> I will need to add Latitude and Longitude fields in > >>>>>>> PostalAdress. Could this be a change commited ? > >>>>>>> I will also need to add a type PHONE_HOTLINE in > >>>>>>> ContactMechPurposeType. > >>>>>>> > >>>>>>> Else, of course I will use > >>>>>>> > >>>>>>> Thanks > >>>>>>> > >>>>>>> Jacques
