Latitude, Longitude in PostalAdress

[Jacques Le Roux]

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 <extend-entity>

Thanks

Jacques

[cjhowe]

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 <[hidden email]> 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

[BJ Freeman]

been giving this some thought
1) how about using geo or new entity connected to Geo, since we have a
one relationship in PostalAddress.
2)Each degree is 111.111 km when going north-south, so 0.001 degrees
would be 111 m and 0.0001 is 11 m, so the entity should have enough
accuracy to make sure it does not slop over to the next address.
Offsets east-west must be multiplied by cos(latitude), which is 0.5 in
Oslo, and a little larger  in France?
the entity should have degrees, min, sec hudredes, thousand, 10 thousand
fields.
3) need to have a field as to where the the longitude was gotten so
comparison against other sources or validation can be done.



Jacques Le Roux sent the following on 6/26/2008 3:44 PM:

> 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 <extend-entity>
>
> Thanks
>
> Jacques
>
>
>

[Jacques Le Roux]

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" <[hidden email]>

>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 <[hidden email]> 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
>
>

[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" <[hidden email]>
>> 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 <[hidden email]> 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
>>
>>
>

[Jacques Le Roux]

Though, maybe a better example would be http://people.apache.org/map.html?project=Apache%20OFBiz ;o)

Note that to have these icons on the map we give our lat. long.

Jacques

From: "Jacques Le Roux" <[hidden email]>

> 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" <[hidden email]>
>>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 <[hidden email]> 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
>>
>>
>

[Jacques Le Roux]

Thanks Rob,

This is an interesting information, I'm just discovering Google Map API and related...

Jacques

From: "Rob Schapper" <[hidden email]>

> 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" <[hidden email]>
>>> 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 <[hidden email]> 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
>>>
>>>
>>
>
>

[cjhowe]

Depending on your usage, that may or may not be a good example.  Google Maps begins to choke at about 500 data points.  The file that Apache is using contains 260 points and then only a fraction of those are marked on the map (based on project parameter).

If you start getting into lines (roads) or polygons, you begin needing to tile your bounding box and ensuring that you're only sending data points within that box.  postgis is able to index this data so that the calculations don't become a performance issue.  

Two additional considerations..

What information are you sending to Google in order for them to make a pretty map for you?
The file you're sending to Google (AFAIK) has to be publicly available.  What information are you allowing to be available for the world?

Jacques Le Roux <[hidden email]> wrote: Though, maybe a better example would be http://people.apache.org/map.html?project=Apache%20OFBiz ;o)

Note that to have these icons on the map we give our lat. long.

Jacques

From: "Jacques Le Roux"

> 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
>>
>>
>

[RolandH-2]

Hi,

just 2 things to think about:

- not only PostalAddress may have Latitude and Longitude, e.g. IP
Address may have them: http://www.maxmind.com/app/locate_my_ip
- whatever you geocode today, may change over time: the IP Address may
get a new owner, street maps get more detail,...

just my 2 cents
Roland

Jacques Le Roux wrote:
> 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 <extend-entity>
>
> Thanks
>
> Jacques

[Jacques Le Roux]

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" <[hidden email]>

> Thanks Rob,
>
> This is an interesting information, I'm just discovering Google Map API and related...
>
> Jacques
>
> From: "Rob Schapper" <[hidden email]>
>> 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" <[hidden email]>
>>>> 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 <[hidden email]> 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
>>>>
>>>>
>>>
>>
>>
>

[RolandH-2]

Hi Jacques,

why not a new entity, which can be connected to PostalAddress and maybe
in the future others?
Another questions comes to mind here: more than one Entity may be at the
same LatLong point.
And you're able to save additional data inside the new entity:
datasource (may be intersting when using more than one geocoder: google,
yahoo)
valid from/until

just another 2 cents,
Roland

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" <[hidden email]>
>> Thanks Rob,
>>
>> This is an interesting information, I'm just discovering Google Map
>> API and related...
>>
>> Jacques
>>
>> From: "Rob Schapper" <[hidden email]>
>>> 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" <[hidden email]>
>>>>> 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 <[hidden email]> 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
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>

[David E Jones]

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" <[hidden email]>
>> Thanks Rob,
>>
>> This is an interesting information, I'm just discovering Google Map  
>> API and related...
>>
>> Jacques
>>
>> From: "Rob Schapper" <[hidden email]>
>>> 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" <[hidden email]>
>>>>> 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 <[hidden email]> 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
>>>>>
>>>>>
>>>>
>>>
>>>
>

[Jacques Le Roux]

This makes sense indeed Roland. I vote for since I will certainly need to add some other data. This is why I thought about
extend-entity in 1st place.
I can't see any related entities yet, but this could maybe happen in future. Waiting for other opinions...

Another point I'm interested in : is there a mean/field to relate a duplicated order with the original one ?

Jacques

From: "RolandH" <[hidden email]>

> Hi Jacques,
>
> why not a new entity, which can be connected to PostalAddress and maybe in the future others?
> Another questions comes to mind here: more than one Entity may be at the same LatLong point.
> And you're able to save additional data inside the new entity:
> datasource (may be intersting when using more than one geocoder: google, yahoo)
> valid from/until
>
> just another 2 cents,
> Roland
>
> 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" <[hidden email]>
>>> Thanks Rob,
>>>
>>> This is an interesting information, I'm just discovering Google Map API and related...
>>>
>>> Jacques
>>>
>>> From: "Rob Schapper" <[hidden email]>
>>>> 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" <[hidden email]>
>>>>>> 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 <[hidden email]> 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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>

[RolandH-2]

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" <[hidden email]>
>>> Thanks Rob,
>>>
>>> This is an interesting information, I'm just discovering Google Map
>>> API and related...
>>>
>>> Jacques
>>>
>>> From: "Rob Schapper" <[hidden email]>
>>>> 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" <[hidden email]>
>>>>>> 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 <[hidden email]> 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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>
>

[Jacques Le Roux]

Thanks for comments David,

I'm not in a hurry yet, and I prefere to have the power of the community with me

Jacques

From: "David E Jones" <[hidden email]>

>
> 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" <[hidden email]>
>>> Thanks Rob,
>>>
>>> This is an interesting information, I'm just discovering Google Map  API and related...
>>>
>>> Jacques
>>>
>>> From: "Rob Schapper" <[hidden email]>
>>>> 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" <[hidden email]>
>>>>>> 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 <[hidden email]> 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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>
>

[Jacopo Cappellato-3]

Hi Jacques,

On Jun 28, 2008, at 10:31 PM, Jacques Le Roux wrote:

> This makes sense indeed Roland. I vote for since I will certainly  
> need to add some other data. This is why I thought about extend-
> entity in 1st place.
> I can't see any related entities yet, but this could maybe happen in  
> future. Waiting for other opinions...
>
> Another point I'm interested in : is there a mean/field to relate a  
> duplicated order with the original one ?
>

You may consider the OrderItemAssoc entity (adding a new type in the  
OrderItemAssocType entity).

Jacopo

> Jacques
>
> From: "RolandH" <[hidden email]>
>> Hi Jacques,
>>
>> why not a new entity, which can be connected to PostalAddress and  
>> maybe in the future others?
>> Another questions comes to mind here: more than one Entity may be  
>> at the same LatLong point.
>> And you're able to save additional data inside the new entity:
>> datasource (may be intersting when using more than one geocoder:  
>> google, yahoo)
>> valid from/until
>>
>> just another 2 cents,
>> Roland
>>
>> 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" <[hidden email]>
>>>> Thanks Rob,
>>>>
>>>> This is an interesting information, I'm just discovering Google  
>>>> Map API and related...
>>>>
>>>> Jacques
>>>>
>>>> From: "Rob Schapper" <[hidden email]>
>>>>> 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" <[hidden email]>
>>>>>>> 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 <[hidden email]> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>

[Jacques Le Roux]

Thanks Jacopo,

You made my day !

Jacques

From: "Jacopo Cappellato" <[hidden email]>

> Hi Jacques,
>
> On Jun 28, 2008, at 10:31 PM, Jacques Le Roux wrote:
>
>> This makes sense indeed Roland. I vote for since I will certainly  need to add some other data. This is why I thought about
>> extend- entity in 1st place.
>> I can't see any related entities yet, but this could maybe happen in  future. Waiting for other opinions...
>>
>> Another point I'm interested in : is there a mean/field to relate a  duplicated order with the original one ?
>>
>
> You may consider the OrderItemAssoc entity (adding a new type in the  OrderItemAssocType entity).
>
> Jacopo
>
>
>> Jacques
>>
>> From: "RolandH" <[hidden email]>
>>> Hi Jacques,
>>>
>>> why not a new entity, which can be connected to PostalAddress and  maybe in the future others?
>>> Another questions comes to mind here: more than one Entity may be  at the same LatLong point.
>>> And you're able to save additional data inside the new entity:
>>> datasource (may be intersting when using more than one geocoder:  google, yahoo)
>>> valid from/until
>>>
>>> just another 2 cents,
>>> Roland
>>>
>>> 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" <[hidden email]>
>>>>> Thanks Rob,
>>>>>
>>>>> This is an interesting information, I'm just discovering Google  Map API and related...
>>>>>
>>>>> Jacques
>>>>>
>>>>> From: "Rob Schapper" <[hidden email]>
>>>>>> 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" <[hidden email]>
>>>>>>>> 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 <[hidden email]> 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>
>

[David E Jones]

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" <[hidden email]>
>>>> Thanks Rob,
>>>>
>>>> This is an interesting information, I'm just discovering Google  
>>>> Map API and related...
>>>>
>>>> Jacques
>>>>
>>>> From: "Rob Schapper" <[hidden email]>
>>>>> 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" <[hidden email]>
>>>>>>> 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 <[hidden email]> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>
>

[cjhowe]

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 <[hidden email]> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>
>

[Jacques Le Roux]

Cool,

The debate is launched...

I'm fine with either solutions as long as we create a new specialised entity. Pease gents furbish your arguments :o)

Jacques

From: "Chris Howe" <[hidden email]>

>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 <[hidden email]> 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>
>
>