to clarify I am only talking if the lon/lat is tied to a street address.
BJ Freeman sent the following on 7/1/2008 2:56 PM:
> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>
>>
>>
>
>
>
>
