to have accuracy for matching a street address it has to have a 10 meter or better accuracy. this requires .00000xx. at the equator. I don't think 6 places is sufficient. also not that in the us Yahoo, USPS, and Google have different Lon/lat for a given address.
David E Jones sent the following on 7/1/2008 12:21 PM: > > 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-simple.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 >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>> >>> >> > > > >
