How about address correction software that is certified by the USPS Their lon/lat is actually taken from walk routes. others use mapping data that is sometimes a guesstimate or extrapolated.
Chris Howe sent the following on 7/1/2008 1:11 PM: > I would greatly urge you to look into storing this information in the Well > Known Text or Well Known Binary formats instead. Most of what will be useful > in an ERP system will contain polygons with hundreds (if not thousands) of > verticies. Imagine the processing and communication between the database and > application that will occur if you choose a system that separates the > coordinate pairs. Many databases have specialized functions added to their > package to deal with GIS data. Let us stand on the shoulders of giants on > this one. > > David E Jones <[EMAIL PROTECTED]> 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" >>>>> Thanks Rob, >>>>> >>>>> This is an interesting information, I'm just discovering Google >>>>> Map API and related... >>>>> >>>>> Jacques >>>>> >>>>> From: "Rob Schapper" >>>>>> 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" >>>>>>>> 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 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 >>>>>>>> >>>>>>>> >>>>>> > > >
