Latitude, Longitude in PostalAdress

[David E Jones]

And what about running on databases that don't have any GIS support?

-David


On Jul 1, 2008, at 2:11 PM, Chris Howe wrote:

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

[cjhowe]

proj.4 should handle this.  proj.4 is MIT license.  I haven't gone looking for the license of the java port

David E Jones <[hidden email]> wrote:
And what about running on databases that don't have any GIS support?

-David


On Jul 1, 2008, at 2:11 PM, Chris Howe wrote:

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

[cjhowe]

Or, if you're wanting to go directly to a LGPL source...there is a plugin for GeoTools for geometryless databases.

http://geotools.codehaus.org/Geometryless+JDBC+Data+Store

Chris Howe <[hidden email]> wrote: proj.4 should handle this.  proj.4 is MIT license.  I haven't gone looking for the license of the java port

David E Jones  wrote:
And what about running on databases that don't have any GIS support?

-David


On Jul 1, 2008, at 2:11 PM, Chris Howe wrote:

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

[BJ Freeman]

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

[BJ Freeman]

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

[BJ Freeman]

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" <[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,

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

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

 640K ought to be enough for anybody.   This reminds me of another benefit to WTK/WTB.  WTK and WTB are not dependent on the coordinate system you are using.  Whether your coordinate system is the latitudinal and longitudinal circles of the earth or whether they are the coordinate system of your RFID enabled warehosue, WTK and WTB handles them the same.  Same data format, same use of projections, same reliability in application you build.  Why record the same type of information in 15 different formats based on their use?

[cjhowe]

In addition, TIGER road data is to 15 significant digits as is US data for county political boundaries.

Chris Howe <[hidden email]> wrote: Roland  wrote: 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

 640K ought to be enough for anybody.   This reminds me of another benefit to WTK/WTB.  WTK and WTB are not dependent on the coordinate system you are using.  Whether your coordinate system is the latitudinal and longitudinal circles of the earth or whether they are the coordinate system of your RFID enabled warehosue, WTK and WTB handles them the same.  Same data format, same use of projections, same reliability in application you build.  Why record the same type of information in 15 different formats based on their use?

[cjhowe]

I've added some notes to the Cookbook on how to get setup with PostGIS under the subheading "Geographic Information Systems (GIS)"
http://docs.ofbiz.org/x/YwU

I was able to grab geospatial data through the SQL processor.  When trying to get it through webtool's entity maintenance, I ran out of memory.

Jacques Le Roux <[hidden email]> wrote: 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"

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

[David E Jones]

Here is what I found in a quick search:

"Coordinates in the TIGER/Line® files are in decimal degrees and have  
six
implied decimal places. The positional accuracy of these coordinates  
is not
as great as the six decimal places suggest."

That is from near the bottom of page 6 of this document:

http://www.census.gov/geo/www/tiger/tigerua/ua2ktgr.pdf

Or are you referring to a different TIGER?

BTW Chris, I'm having a lot of trouble understanding your posts. I  
don't know if others are running into the same thing, but much of the  
time I'm not sure quite what you're getting at or what you propose as  
many of these seem to be little snippets of thought instead of entire  
thoughts... could explain a little more of what you have in mind?

Also: I looked at the postgis stuff you added, and... what's the  
point? If it only works with postgres how is that useful for OFBiz?

-David


On Jul 2, 2008, at 4:31 AM, Chris Howe wrote:

> In addition, TIGER road data is to 15 significant digits as is US  
> data for county political boundaries.
>
> Chris Howe <[hidden email]> wrote: Roland  wrote: 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
>
> 640K ought to be enough for anybody.   This reminds me of another  
> benefit to WTK/WTB.  WTK and WTB are not dependent on the coordinate  
> system you are using.  Whether your coordinate system is the  
> latitudinal and longitudinal circles of the earth or whether they  
> are the coordinate system of your RFID enabled warehosue, WTK and  
> WTB handles them the same.  Same data format, same use of  
> projections, same reliability in application you build.  Why record  
> the same type of information in 15 different formats based on their  
> use?
>

[cjhowe]

David,

I stand corrected on the significant digits used in TIGER. It seems there is a slight difference in unit specificity in the projection that I assumed versus what TIGER provides

4269 degree Unit = 0.01745329251994328
Tiger degree Unit = 0.017453292519943295

This threw off the retrieval calculation of the coordinates and didn't result in round numbers at the 6th decimal place and thus was calculated to the maximum significant digits of the library (15 digits).

In regards to what I'm suggesting: I am simply suggesting that we use the standards that have existed for over a decade for the storage of geometrical data, namely Well-Known-Text or Well-Known-Binary.  The reason I am suggesting this is because you've already submitted a desire to perform calculations that have been optimized under libraries that use WTK/WTB.  The other reason that I am suggesting this is that latitude and longitude is not the only coordinate system that would benefit from using the standard.  For instance, if someone has an RFID grid in their warehouse, they could benefit from the same conventions being used.

In regards to "What about the other databases?":  I can't imagine the other databases with spatial extensions would require approaches that were much different to benefit from GIS.  PostGIS happens to be an implementation of the OGC standards, so databases that have an implementation of that standard would benefit from code written to that standard.  

The GeoTools Module Matrix plugins should give you an idea if you're concerned about connecting to other databases.

http://geotools.codehaus.org/Module+Matrix

David E Jones <[hidden email]> wrote:
Here is what I found in a quick search:

"Coordinates in the TIGER/Line® files are in decimal degrees and have  
six
implied decimal places. The positional accuracy of these coordinates  
is not
as great as the six decimal places suggest."

That is from near the bottom of page 6 of this document:

http://www.census.gov/geo/www/tiger/tigerua/ua2ktgr.pdf

Or are you referring to a different TIGER?

BTW Chris, I'm having a lot of trouble understanding your posts. I  
don't know if others are running into the same thing, but much of the  
time I'm not sure quite what you're getting at or what you propose as  
many of these seem to be little snippets of thought instead of entire  
thoughts... could explain a little more of what you have in mind?

Also: I looked at the postgis stuff you added, and... what's the  
point? If it only works with postgres how is that useful for OFBiz?

-David


On Jul 2, 2008, at 4:31 AM, Chris Howe wrote:

> In addition, TIGER road data is to 15 significant digits as is US  
> data for county political boundaries.
>
> Chris Howe  wrote: Roland  wrote: 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
>
> 640K ought to be enough for anybody.   This reminds me of another  
> benefit to WTK/WTB.  WTK and WTB are not dependent on the coordinate  
> system you are using.  Whether your coordinate system is the  
> latitudinal and longitudinal circles of the earth or whether they  
> are the coordinate system of your RFID enabled warehosue, WTK and  
> WTB handles them the same.  Same data format, same use of  
> projections, same reliability in application you build.  Why record  
> the same type of information in 15 different formats based on their  
> use?
>

[David E Jones]

I think I see where you're coming from Chris, and I'm for standards  
and existing toolsets. I think what we're talking about here is much  
more simple.

Eventually we'll (hopefully!) get to the point where we want to define  
polygon boundaries for Geo records and that sort of thing, and doing  
so with Well Known Text (or even GML) might be a great way to go and  
would simplify the data model a lot.

For now all we're looking for is a point location for an address, and  
possibly other things too. Actually, I kind of like the idea of having  
another ContactMechType for a terrestrial position, and maybe add some  
sort of positionContactMechId to the PostalAddress entity to point to  
it for an address.

In any case, we want to keep this simple because chances are we will  
not use it with a GIS package, unless perhaps to pass the coordinates  
to something to determine if it is within a boundary or something.  
More likely we'll use really simple square or circle boundaries and  
such which are a lot easier to search within using any database using  
numerical coordinates, and those are easy since we're just talking  
about point coordinates.

Of course, if someone wants to get into real GIS stuff and enhance the  
Geo and other entities in OFBiz for that... by all means please go for  
it!

-David


On Jul 2, 2008, at 4:42 PM, Chris Howe wrote:

> David,
>
> I stand corrected on the significant digits used in TIGER. It seems  
> there is a slight difference in unit specificity in the projection  
> that I assumed versus what TIGER provides
>
> 4269 degree Unit = 0.01745329251994328
> Tiger degree Unit = 0.017453292519943295
>
> This threw off the retrieval calculation of the coordinates and  
> didn't result in round numbers at the 6th decimal place and thus was  
> calculated to the maximum significant digits of the library (15  
> digits).
>
> In regards to what I'm suggesting: I am simply suggesting that we  
> use the standards that have existed for over a decade for the  
> storage of geometrical data, namely Well-Known-Text or Well-Known-
> Binary.  The reason I am suggesting this is because you've already  
> submitted a desire to perform calculations that have been optimized  
> under libraries that use WTK/WTB.  The other reason that I am  
> suggesting this is that latitude and longitude is not the only  
> coordinate system that would benefit from using the standard.  For  
> instance, if someone has an RFID grid in their warehouse, they could  
> benefit from the same conventions being used.
>
> In regards to "What about the other databases?":  I can't imagine  
> the other databases with spatial extensions would require approaches  
> that were much different to benefit from GIS.  PostGIS happens to be  
> an implementation of the OGC standards, so databases that have an  
> implementation of that standard would benefit from code written to  
> that standard.
>
> The GeoTools Module Matrix plugins should give you an idea if you're  
> concerned about connecting to other databases.
>
> http://geotools.codehaus.org/Module+Matrix
>
> David E Jones <[hidden email]> wrote:
> Here is what I found in a quick search:
>
> "Coordinates in the TIGER/Line® files are in decimal degrees and have
> six
> implied decimal places. The positional accuracy of these coordinates
> is not
> as great as the six decimal places suggest."
>
> That is from near the bottom of page 6 of this document:
>
> http://www.census.gov/geo/www/tiger/tigerua/ua2ktgr.pdf
>
> Or are you referring to a different TIGER?
>
> BTW Chris, I'm having a lot of trouble understanding your posts. I
> don't know if others are running into the same thing, but much of the
> time I'm not sure quite what you're getting at or what you propose as
> many of these seem to be little snippets of thought instead of entire
> thoughts... could explain a little more of what you have in mind?
>
> Also: I looked at the postgis stuff you added, and... what's the
> point? If it only works with postgres how is that useful for OFBiz?
>
> -David
>
>
> On Jul 2, 2008, at 4:31 AM, Chris Howe wrote:
>
>> In addition, TIGER road data is to 15 significant digits as is US
>> data for county political boundaries.
>>
>> Chris Howe  wrote: Roland  wrote: 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
>>
>> 640K ought to be enough for anybody.   This reminds me of another
>> benefit to WTK/WTB.  WTK and WTB are not dependent on the coordinate
>> system you are using.  Whether your coordinate system is the
>> latitudinal and longitudinal circles of the earth or whether they
>> are the coordinate system of your RFID enabled warehosue, WTK and
>> WTB handles them the same.  Same data format, same use of
>> projections, same reliability in application you build.  Why record
>> the same type of information in 15 different formats based on their
>> use?
>>
>
>

[cjhowe]

The part that is overlooked when wanting to go "simple" is that the coordinates that will be recorded become garbage data when they are stored without the correct coordinate system reference.  Without the correct coordinate system reference, the possibility of "eventually" will be removed from your development path.

Building out the infrastructure to accomodate a coordinate system recreates about 90% of a GIS infrastructure.  Someone with extensive knowledge of the nuts and bolts of the entity engine could look at the geotools module matrix plugins and get an idea on how to build that out appropriately in 1/10th of the effort.  Taking that approach gives you standards compliance, all of the calculations you could be concerned with, and a internal map server to boot.

David E Jones <[hidden email]> wrote:
I think I see where you're coming from Chris, and I'm for standards  
and existing toolsets. I think what we're talking about here is much  
more simple.

Eventually we'll (hopefully!) get to the point where we want to define  
polygon boundaries for Geo records and that sort of thing, and doing  
so with Well Known Text (or even GML) might be a great way to go and  
would simplify the data model a lot.

For now all we're looking for is a point location for an address, and  
possibly other things too. Actually, I kind of like the idea of having  
another ContactMechType for a terrestrial position, and maybe add some  
sort of positionContactMechId to the PostalAddress entity to point to  
it for an address.

In any case, we want to keep this simple because chances are we will  
not use it with a GIS package, unless perhaps to pass the coordinates  
to something to determine if it is within a boundary or something.  
More likely we'll use really simple square or circle boundaries and  
such which are a lot easier to search within using any database using  
numerical coordinates, and those are easy since we're just talking  
about point coordinates.

Of course, if someone wants to get into real GIS stuff and enhance the  
Geo and other entities in OFBiz for that... by all means please go for  
it!

-David


On Jul 2, 2008, at 4:42 PM, Chris Howe wrote:

> David,
>
> I stand corrected on the significant digits used in TIGER. It seems  
> there is a slight difference in unit specificity in the projection  
> that I assumed versus what TIGER provides
>
> 4269 degree Unit = 0.01745329251994328
> Tiger degree Unit = 0.017453292519943295
>
> This threw off the retrieval calculation of the coordinates and  
> didn't result in round numbers at the 6th decimal place and thus was  
> calculated to the maximum significant digits of the library (15  
> digits).
>
> In regards to what I'm suggesting: I am simply suggesting that we  
> use the standards that have existed for over a decade for the  
> storage of geometrical data, namely Well-Known-Text or Well-Known-
> Binary.  The reason I am suggesting this is because you've already  
> submitted a desire to perform calculations that have been optimized  
> under libraries that use WTK/WTB.  The other reason that I am  
> suggesting this is that latitude and longitude is not the only  
> coordinate system that would benefit from using the standard.  For  
> instance, if someone has an RFID grid in their warehouse, they could  
> benefit from the same conventions being used.
>
> In regards to "What about the other databases?":  I can't imagine  
> the other databases with spatial extensions would require approaches  
> that were much different to benefit from GIS.  PostGIS happens to be  
> an implementation of the OGC standards, so databases that have an  
> implementation of that standard would benefit from code written to  
> that standard.
>
> The GeoTools Module Matrix plugins should give you an idea if you're  
> concerned about connecting to other databases.
>
> http://geotools.codehaus.org/Module+Matrix
>
> David E Jones  wrote:
> Here is what I found in a quick search:
>
> "Coordinates in the TIGER/Line® files are in decimal degrees and have
> six
> implied decimal places. The positional accuracy of these coordinates
> is not
> as great as the six decimal places suggest."
>
> That is from near the bottom of page 6 of this document:
>
> http://www.census.gov/geo/www/tiger/tigerua/ua2ktgr.pdf
>
> Or are you referring to a different TIGER?
>
> BTW Chris, I'm having a lot of trouble understanding your posts. I
> don't know if others are running into the same thing, but much of the
> time I'm not sure quite what you're getting at or what you propose as
> many of these seem to be little snippets of thought instead of entire
> thoughts... could explain a little more of what you have in mind?
>
> Also: I looked at the postgis stuff you added, and... what's the
> point? If it only works with postgres how is that useful for OFBiz?
>
> -David
>
>
> On Jul 2, 2008, at 4:31 AM, Chris Howe wrote:
>
>> In addition, TIGER road data is to 15 significant digits as is US
>> data for county political boundaries.
>>
>> Chris Howe  wrote: Roland  wrote: 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
>>
>> 640K ought to be enough for anybody.   This reminds me of another
>> benefit to WTK/WTB.  WTK and WTB are not dependent on the coordinate
>> system you are using.  Whether your coordinate system is the
>> latitudinal and longitudinal circles of the earth or whether they
>> are the coordinate system of your RFID enabled warehosue, WTK and
>> WTB handles them the same.  Same data format, same use of
>> projections, same reliability in application you build.  Why record
>> the same type of information in 15 different formats based on their
>> use?
>>
>
>

[Jacques Le Roux]

From: "David E Jones" <[hidden email]>
>
> I think I see where you're coming from Chris, and I'm for standards  and existing toolsets. I think what we're talking about here
> is much  more simple.
>
> Eventually we'll (hopefully!) get to the point where we want to define  polygon boundaries for Geo records and that sort of thing,
> and doing  so with Well Known Text (or even GML) might be a great way to go and  would simplify the data model a lot.

From http://en.wikipedia.org/wiki/Well-known_text this sounds like a good idea to me.

> For now all we're looking for is a point location for an address, and  possibly other things too. Actually, I kind of like the
> idea of having  another ContactMechType for a terrestrial position, and maybe add some  sort of positionContactMechId to the
> PostalAddress entity to point to  it for an address.

I undestand and agree with Chris's argument, but it's true that I don't need such sophistication for the moment.
Using the extensibility pattern sounds a 1st raisonnable approach to me. Obviously better than introducing lat+long in PostalAddress
and let future open ...

Jacques

> In any case, we want to keep this simple because chances are we will  not use it with a GIS package, unless perhaps to pass the
> coordinates  to something to determine if it is within a boundary or something.  More likely we'll use really simple square or
> circle boundaries and  such which are a lot easier to search within using any database using  numerical coordinates, and those are
> easy since we're just talking  about point coordinates.
>
> Of course, if someone wants to get into real GIS stuff and enhance the  Geo and other entities in OFBiz for that... by all means
> please go for  it!
>
> -David
>
>
> On Jul 2, 2008, at 4:42 PM, Chris Howe wrote:
>
>> David,
>>
>> I stand corrected on the significant digits used in TIGER. It seems  there is a slight difference in unit specificity in the
>> projection  that I assumed versus what TIGER provides
>>
>> 4269 degree Unit = 0.01745329251994328
>> Tiger degree Unit = 0.017453292519943295
>>
>> This threw off the retrieval calculation of the coordinates and  didn't result in round numbers at the 6th decimal place and thus
>> was  calculated to the maximum significant digits of the library (15  digits).
>>
>> In regards to what I'm suggesting: I am simply suggesting that we  use the standards that have existed for over a decade for the
>> storage of geometrical data, namely Well-Known-Text or Well-Known- Binary.  The reason I am suggesting this is because you've
>> already  submitted a desire to perform calculations that have been optimized  under libraries that use WTK/WTB.  The other reason
>> that I am  suggesting this is that latitude and longitude is not the only  coordinate system that would benefit from using the
>> standard.  For  instance, if someone has an RFID grid in their warehouse, they could  benefit from the same conventions being
>> used.
>>
>> In regards to "What about the other databases?":  I can't imagine  the other databases with spatial extensions would require
>> approaches  that were much different to benefit from GIS.  PostGIS happens to be  an implementation of the OGC standards, so
>> databases that have an  implementation of that standard would benefit from code written to  that standard.
>>
>> The GeoTools Module Matrix plugins should give you an idea if you're  concerned about connecting to other databases.
>>
>> http://geotools.codehaus.org/Module+Matrix
>>
>> David E Jones <[hidden email]> wrote:
>> Here is what I found in a quick search:
>>
>> "Coordinates in the TIGER/Line® files are in decimal degrees and have
>> six
>> implied decimal places. The positional accuracy of these coordinates
>> is not
>> as great as the six decimal places suggest."
>>
>> That is from near the bottom of page 6 of this document:
>>
>> http://www.census.gov/geo/www/tiger/tigerua/ua2ktgr.pdf
>>
>> Or are you referring to a different TIGER?
>>
>> BTW Chris, I'm having a lot of trouble understanding your posts. I
>> don't know if others are running into the same thing, but much of the
>> time I'm not sure quite what you're getting at or what you propose as
>> many of these seem to be little snippets of thought instead of entire
>> thoughts... could explain a little more of what you have in mind?
>>
>> Also: I looked at the postgis stuff you added, and... what's the
>> point? If it only works with postgres how is that useful for OFBiz?
>>
>> -David
>>
>>
>> On Jul 2, 2008, at 4:31 AM, Chris Howe wrote:
>>
>>> In addition, TIGER road data is to 15 significant digits as is US
>>> data for county political boundaries.
>>>
>>> Chris Howe  wrote: Roland  wrote: 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
>>>
>>> 640K ought to be enough for anybody.   This reminds me of another
>>> benefit to WTK/WTB.  WTK and WTB are not dependent on the coordinate
>>> system you are using.  Whether your coordinate system is the
>>> latitudinal and longitudinal circles of the earth or whether they
>>> are the coordinate system of your RFID enabled warehosue, WTK and
>>> WTB handles them the same.  Same data format, same use of
>>> projections, same reliability in application you build.  Why record
>>> the same type of information in 15 different formats based on their
>>> use?
>>>
>>
>>
>
>

[Jacques Le Roux]

I resurrect this thread to let you know that I'm ready to work on this
I'd like to create, as we agreed but please confirm,
. a new entity TerrestrialPosition with at least these fields for now
      . contactMechId
    . latitude (using new type degree being NUMERIC(18,6))
    . longitude (using new type degree being NUMERIC(18,6))
    . comment using type comment
. add of a new ContactMechType : TerrestrialPosition

The same mechanism used to relate PostalAddress to a Party, a Facilty, an Invoice, an Order or an OrderItem (so far) will be used to
relate a TerrestrialPosition (through PartyContactMech, FaciltyContactMech, etc. )

If needed we can put more decimals in degree, but RolandH pointed out that 6 decimals is enough for 4.37184 inch or 11.1044736
centimeters !!!

If nobody disagree I will go for that (as soon as Adam will have fixed OFBiz ;o)

Jacques


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

> From: "David E Jones" <[hidden email]>
>>
>> I think I see where you're coming from Chris, and I'm for standards  and existing toolsets. I think what we're talking about here
>> is much  more simple.
>>
>> Eventually we'll (hopefully!) get to the point where we want to define  polygon boundaries for Geo records and that sort of
>> thing,
>> and doing  so with Well Known Text (or even GML) might be a great way to go and  would simplify the data model a lot.
>
>>From http://en.wikipedia.org/wiki/Well-known_text this sounds like a good idea to me.
>
>> For now all we're looking for is a point location for an address, and  possibly other things too. Actually, I kind of like the
>> idea of having  another ContactMechType for a terrestrial position, and maybe add some  sort of positionContactMechId to the
>> PostalAddress entity to point to  it for an address.
>
> I undestand and agree with Chris's argument, but it's true that I don't need such sophistication for the moment.
> Using the extensibility pattern sounds a 1st raisonnable approach to me. Obviously better than introducing lat+long in
> PostalAddress and let future open ...
>
> Jacques
>
>> In any case, we want to keep this simple because chances are we will  not use it with a GIS package, unless perhaps to pass the
>> coordinates  to something to determine if it is within a boundary or something.  More likely we'll use really simple square or
>> circle boundaries and  such which are a lot easier to search within using any database using  numerical coordinates, and those
>> are
>> easy since we're just talking  about point coordinates.
>>
>> Of course, if someone wants to get into real GIS stuff and enhance the  Geo and other entities in OFBiz for that... by all means
>> please go for  it!
>>
>> -David
>>
>>
>> On Jul 2, 2008, at 4:42 PM, Chris Howe wrote:
>>
>>> David,
>>>
>>> I stand corrected on the significant digits used in TIGER. It seems  there is a slight difference in unit specificity in the
>>> projection  that I assumed versus what TIGER provides
>>>
>>> 4269 degree Unit = 0.01745329251994328
>>> Tiger degree Unit = 0.017453292519943295
>>>
>>> This threw off the retrieval calculation of the coordinates and  didn't result in round numbers at the 6th decimal place and
>>> thus
>>> was  calculated to the maximum significant digits of the library (15  digits).
>>>
>>> In regards to what I'm suggesting: I am simply suggesting that we  use the standards that have existed for over a decade for the
>>> storage of geometrical data, namely Well-Known-Text or Well-Known- Binary.  The reason I am suggesting this is because you've
>>> already  submitted a desire to perform calculations that have been optimized  under libraries that use WTK/WTB.  The other
>>> reason
>>> that I am  suggesting this is that latitude and longitude is not the only  coordinate system that would benefit from using the
>>> standard.  For  instance, if someone has an RFID grid in their warehouse, they could  benefit from the same conventions being
>>> used.
>>>
>>> In regards to "What about the other databases?":  I can't imagine  the other databases with spatial extensions would require
>>> approaches  that were much different to benefit from GIS.  PostGIS happens to be  an implementation of the OGC standards, so
>>> databases that have an  implementation of that standard would benefit from code written to  that standard.
>>>
>>> The GeoTools Module Matrix plugins should give you an idea if you're  concerned about connecting to other databases.
>>>
>>> http://geotools.codehaus.org/Module+Matrix
>>>
>>> David E Jones <[hidden email]> wrote:
>>> Here is what I found in a quick search:
>>>
>>> "Coordinates in the TIGER/Line® files are in decimal degrees and have
>>> six
>>> implied decimal places. The positional accuracy of these coordinates
>>> is not
>>> as great as the six decimal places suggest."
>>>
>>> That is from near the bottom of page 6 of this document:
>>>
>>> http://www.census.gov/geo/www/tiger/tigerua/ua2ktgr.pdf
>>>
>>> Or are you referring to a different TIGER?
>>>
>>> BTW Chris, I'm having a lot of trouble understanding your posts. I
>>> don't know if others are running into the same thing, but much of the
>>> time I'm not sure quite what you're getting at or what you propose as
>>> many of these seem to be little snippets of thought instead of entire
>>> thoughts... could explain a little more of what you have in mind?
>>>
>>> Also: I looked at the postgis stuff you added, and... what's the
>>> point? If it only works with postgres how is that useful for OFBiz?
>>>
>>> -David
>>>
>>>
>>> On Jul 2, 2008, at 4:31 AM, Chris Howe wrote:
>>>
>>>> In addition, TIGER road data is to 15 significant digits as is US
>>>> data for county political boundaries.
>>>>
>>>> Chris Howe  wrote: Roland  wrote: 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
>>>>
>>>> 640K ought to be enough for anybody.   This reminds me of another
>>>> benefit to WTK/WTB.  WTK and WTB are not dependent on the coordinate
>>>> system you are using.  Whether your coordinate system is the
>>>> latitudinal and longitudinal circles of the earth or whether they
>>>> are the coordinate system of your RFID enabled warehosue, WTK and
>>>> WTB handles them the same.  Same data format, same use of
>>>> projections, same reliability in application you build.  Why record
>>>> the same type of information in 15 different formats based on their
>>>> use?
>>>>
>>>
>>>
>>
>>
>

[David E Jones]

It might be better to have an independent ID for the  
TerrestrialPosition (like terrestrialPositionId) and have things point  
to it rather than having it point to other things. In other words we  
would add a terrestrialPositionId to the ContactMech instead of  
putting a contactMechId on TerrestrialPosition. In that way anything  
could point to it.

Also, considering the discussions from before maybe we should add a  
text field for Well Known Text that can be used as an alternative to  
(or perhaps supplement to) the simple lat/lon.

-David


On Aug 4, 2008, at 3:51 PM, Jacques Le Roux wrote:

> I resurrect this thread to let you know that I'm ready to work on this
> I'd like to create, as we agreed but please confirm,
> . a new entity TerrestrialPosition with at least these fields for now
>    . contactMechId
>  . latitude (using new type degree being NUMERIC(18,6))
>  . longitude (using new type degree being NUMERIC(18,6))
>  . comment using type comment
> . add of a new ContactMechType : TerrestrialPosition
>
> The same mechanism used to relate PostalAddress to a Party, a  
> Facilty, an Invoice, an Order or an OrderItem (so far) will be used  
> to relate a TerrestrialPosition (through PartyContactMech,  
> FaciltyContactMech, etc. )
>
> If needed we can put more decimals in degree, but RolandH pointed  
> out that 6 decimals is enough for 4.37184 inch or 11.1044736  
> centimeters !!!
>
> If nobody disagree I will go for that (as soon as Adam will have  
> fixed OFBiz ;o)
>
> Jacques
>
>
> From: "Jacques Le Roux" <[hidden email]>
>> From: "David E Jones" <[hidden email]>
>>>
>>> I think I see where you're coming from Chris, and I'm for  
>>> standards  and existing toolsets. I think what we're talking about  
>>> here
>>> is much  more simple.
>>>
>>> Eventually we'll (hopefully!) get to the point where we want to  
>>> define  polygon boundaries for Geo records and that sort of thing,
>>> and doing  so with Well Known Text (or even GML) might be a great  
>>> way to go and  would simplify the data model a lot.
>>
>>> From http://en.wikipedia.org/wiki/Well-known_text this sounds like  
>>> a good idea to me.
>>
>>> For now all we're looking for is a point location for an address,  
>>> and  possibly other things too. Actually, I kind of like the
>>> idea of having  another ContactMechType for a terrestrial  
>>> position, and maybe add some  sort of positionContactMechId to the
>>> PostalAddress entity to point to  it for an address.
>>
>> I undestand and agree with Chris's argument, but it's true that I  
>> don't need such sophistication for the moment.
>> Using the extensibility pattern sounds a 1st raisonnable approach  
>> to me. Obviously better than introducing lat+long in PostalAddress  
>> and let future open ...
>>
>> Jacques
>>
>>> In any case, we want to keep this simple because chances are we  
>>> will  not use it with a GIS package, unless perhaps to pass the
>>> coordinates  to something to determine if it is within a boundary  
>>> or something.  More likely we'll use really simple square or
>>> circle boundaries and  such which are a lot easier to search  
>>> within using any database using  numerical coordinates, and those  
>>> are
>>> easy since we're just talking  about point coordinates.
>>>
>>> Of course, if someone wants to get into real GIS stuff and enhance  
>>> the  Geo and other entities in OFBiz for that... by all means
>>> please go for  it!
>>>
>>> -David
>>>
>>>
>>> On Jul 2, 2008, at 4:42 PM, Chris Howe wrote:
>>>
>>>> David,
>>>>
>>>> I stand corrected on the significant digits used in TIGER. It  
>>>> seems  there is a slight difference in unit specificity in the
>>>> projection  that I assumed versus what TIGER provides
>>>>
>>>> 4269 degree Unit = 0.01745329251994328
>>>> Tiger degree Unit = 0.017453292519943295
>>>>
>>>> This threw off the retrieval calculation of the coordinates and  
>>>> didn't result in round numbers at the 6th decimal place and thus
>>>> was  calculated to the maximum significant digits of the library  
>>>> (15  digits).
>>>>
>>>> In regards to what I'm suggesting: I am simply suggesting that  
>>>> we  use the standards that have existed for over a decade for the
>>>> storage of geometrical data, namely Well-Known-Text or Well-
>>>> Known- Binary.  The reason I am suggesting this is because you've
>>>> already  submitted a desire to perform calculations that have  
>>>> been optimized  under libraries that use WTK/WTB.  The other reason
>>>> that I am  suggesting this is that latitude and longitude is not  
>>>> the only  coordinate system that would benefit from using the
>>>> standard.  For  instance, if someone has an RFID grid in their  
>>>> warehouse, they could  benefit from the same conventions being
>>>> used.
>>>>
>>>> In regards to "What about the other databases?":  I can't  
>>>> imagine  the other databases with spatial extensions would require
>>>> approaches  that were much different to benefit from GIS.  
>>>> PostGIS happens to be  an implementation of the OGC standards, so
>>>> databases that have an  implementation of that standard would  
>>>> benefit from code written to  that standard.
>>>>
>>>> The GeoTools Module Matrix plugins should give you an idea if  
>>>> you're  concerned about connecting to other databases.
>>>>
>>>> http://geotools.codehaus.org/Module+Matrix
>>>>
>>>> David E Jones <[hidden email]> wrote:
>>>> Here is what I found in a quick search:
>>>>
>>>> "Coordinates in the TIGER/Line® files are in decimal degrees and  
>>>> have
>>>> six
>>>> implied decimal places. The positional accuracy of these  
>>>> coordinates
>>>> is not
>>>> as great as the six decimal places suggest."
>>>>
>>>> That is from near the bottom of page 6 of this document:
>>>>
>>>> http://www.census.gov/geo/www/tiger/tigerua/ua2ktgr.pdf
>>>>
>>>> Or are you referring to a different TIGER?
>>>>
>>>> BTW Chris, I'm having a lot of trouble understanding your posts. I
>>>> don't know if others are running into the same thing, but much of  
>>>> the
>>>> time I'm not sure quite what you're getting at or what you  
>>>> propose as
>>>> many of these seem to be little snippets of thought instead of  
>>>> entire
>>>> thoughts... could explain a little more of what you have in mind?
>>>>
>>>> Also: I looked at the postgis stuff you added, and... what's the
>>>> point? If it only works with postgres how is that useful for OFBiz?
>>>>
>>>> -David
>>>>
>>>>
>>>> On Jul 2, 2008, at 4:31 AM, Chris Howe wrote:
>>>>
>>>>> In addition, TIGER road data is to 15 significant digits as is US
>>>>> data for county political boundaries.
>>>>>
>>>>> Chris Howe  wrote: Roland  wrote: 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
>>>>>
>>>>> 640K ought to be enough for anybody.   This reminds me of another
>>>>> benefit to WTK/WTB.  WTK and WTB are not dependent on the  
>>>>> coordinate
>>>>> system you are using.  Whether your coordinate system is the
>>>>> latitudinal and longitudinal circles of the earth or whether they
>>>>> are the coordinate system of your RFID enabled warehosue, WTK and
>>>>> WTB handles them the same.  Same data format, same use of
>>>>> projections, same reliability in application you build.  Why  
>>>>> record
>>>>> the same type of information in 15 different formats based on  
>>>>> their
>>>>> use?
>>>>>
>>>>
>>>>
>>>
>>>
>

[BJ Freeman]

I like the idea of the TerrestrialPosition entity.
Maybe have field for the source of the lon/lat.
like google, yahoo, USPS as enumerated types.
I say this because i find a difference in the lon/lat for each source.
and there may be a need to have a different TerrestrialPosition  for
each one to make that particular system work correctly. Maybe a parent
child relationship, to save pointing other entities.
As a side note: just for future would like a elevation field.
this is for GPS.


David E Jones sent the following on 8/5/2008 8:41 AM:

>
> It might be better to have an independent ID for the TerrestrialPosition
> (like terrestrialPositionId) and have things point to it rather than
> having it point to other things. In other words we would add a
> terrestrialPositionId to the ContactMech instead of putting a
> contactMechId on TerrestrialPosition. In that way anything could point
> to it.
>
> Also, considering the discussions from before maybe we should add a text
> field for Well Known Text that can be used as an alternative to (or
> perhaps supplement to) the simple lat/lon.
>
> -David
>
>
> On Aug 4, 2008, at 3:51 PM, Jacques Le Roux wrote:
>
>> I resurrect this thread to let you know that I'm ready to work on this
>> I'd like to create, as we agreed but please confirm,
>> . a new entity TerrestrialPosition with at least these fields for now
>>    . contactMechId
>>  . latitude (using new type degree being NUMERIC(18,6))
>>  . longitude (using new type degree being NUMERIC(18,6))
>>  . comment using type comment
>> . add of a new ContactMechType : TerrestrialPosition
>>
>> The same mechanism used to relate PostalAddress to a Party, a Facilty,
>> an Invoice, an Order or an OrderItem (so far) will be used to relate a
>> TerrestrialPosition (through PartyContactMech, FaciltyContactMech, etc. )
>>
>> If needed we can put more decimals in degree, but RolandH pointed out
>> that 6 decimals is enough for 4.37184 inch or 11.1044736 centimeters !!!
>>
>> If nobody disagree I will go for that (as soon as Adam will have fixed
>> OFBiz ;o)
>>
>> Jacques
>>
>>
>> From: "Jacques Le Roux" <[hidden email]>
>>> From: "David E Jones" <[hidden email]>
>>>>
>>>> I think I see where you're coming from Chris, and I'm for standards
>>>> and existing toolsets. I think what we're talking about here
>>>> is much  more simple.
>>>>
>>>> Eventually we'll (hopefully!) get to the point where we want to
>>>> define  polygon boundaries for Geo records and that sort of thing,
>>>> and doing  so with Well Known Text (or even GML) might be a great
>>>> way to go and  would simplify the data model a lot.
>>>
>>>> From http://en.wikipedia.org/wiki/Well-known_text this sounds like a
>>>> good idea to me.
>>>
>>>> For now all we're looking for is a point location for an address,
>>>> and  possibly other things too. Actually, I kind of like the
>>>> idea of having  another ContactMechType for a terrestrial position,
>>>> and maybe add some  sort of positionContactMechId to the
>>>> PostalAddress entity to point to  it for an address.
>>>
>>> I undestand and agree with Chris's argument, but it's true that I
>>> don't need such sophistication for the moment.
>>> Using the extensibility pattern sounds a 1st raisonnable approach to
>>> me. Obviously better than introducing lat+long in PostalAddress and
>>> let future open ...
>>>
>>> Jacques
>>>
>>>> In any case, we want to keep this simple because chances are we
>>>> will  not use it with a GIS package, unless perhaps to pass the
>>>> coordinates  to something to determine if it is within a boundary or
>>>> something.  More likely we'll use really simple square or
>>>> circle boundaries and  such which are a lot easier to search within
>>>> using any database using  numerical coordinates, and those are
>>>> easy since we're just talking  about point coordinates.
>>>>
>>>> Of course, if someone wants to get into real GIS stuff and enhance
>>>> the  Geo and other entities in OFBiz for that... by all means
>>>> please go for  it!
>>>>
>>>> -David
>>>>
>>>>
>>>> On Jul 2, 2008, at 4:42 PM, Chris Howe wrote:
>>>>
>>>>> David,
>>>>>
>>>>> I stand corrected on the significant digits used in TIGER. It
>>>>> seems  there is a slight difference in unit specificity in the
>>>>> projection  that I assumed versus what TIGER provides
>>>>>
>>>>> 4269 degree Unit = 0.01745329251994328
>>>>> Tiger degree Unit = 0.017453292519943295
>>>>>
>>>>> This threw off the retrieval calculation of the coordinates and
>>>>> didn't result in round numbers at the 6th decimal place and thus
>>>>> was  calculated to the maximum significant digits of the library
>>>>> (15  digits).
>>>>>
>>>>> In regards to what I'm suggesting: I am simply suggesting that we
>>>>> use the standards that have existed for over a decade for the
>>>>> storage of geometrical data, namely Well-Known-Text or Well-Known-
>>>>> Binary.  The reason I am suggesting this is because you've
>>>>> already  submitted a desire to perform calculations that have been
>>>>> optimized  under libraries that use WTK/WTB.  The other reason
>>>>> that I am  suggesting this is that latitude and longitude is not
>>>>> the only  coordinate system that would benefit from using the
>>>>> standard.  For  instance, if someone has an RFID grid in their
>>>>> warehouse, they could  benefit from the same conventions being
>>>>> used.
>>>>>
>>>>> In regards to "What about the other databases?":  I can't imagine
>>>>> the other databases with spatial extensions would require
>>>>> approaches  that were much different to benefit from GIS.  PostGIS
>>>>> happens to be  an implementation of the OGC standards, so
>>>>> databases that have an  implementation of that standard would
>>>>> benefit from code written to  that standard.
>>>>>
>>>>> The GeoTools Module Matrix plugins should give you an idea if
>>>>> you're  concerned about connecting to other databases.
>>>>>
>>>>> http://geotools.codehaus.org/Module+Matrix
>>>>>
>>>>> David E Jones <[hidden email]> wrote:
>>>>> Here is what I found in a quick search:
>>>>>
>>>>> "Coordinates in the TIGER/Line® files are in decimal degrees and have
>>>>> six
>>>>> implied decimal places. The positional accuracy of these coordinates
>>>>> is not
>>>>> as great as the six decimal places suggest."
>>>>>
>>>>> That is from near the bottom of page 6 of this document:
>>>>>
>>>>> http://www.census.gov/geo/www/tiger/tigerua/ua2ktgr.pdf
>>>>>
>>>>> Or are you referring to a different TIGER?
>>>>>
>>>>> BTW Chris, I'm having a lot of trouble understanding your posts. I
>>>>> don't know if others are running into the same thing, but much of the
>>>>> time I'm not sure quite what you're getting at or what you propose as
>>>>> many of these seem to be little snippets of thought instead of entire
>>>>> thoughts... could explain a little more of what you have in mind?
>>>>>
>>>>> Also: I looked at the postgis stuff you added, and... what's the
>>>>> point? If it only works with postgres how is that useful for OFBiz?
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>> On Jul 2, 2008, at 4:31 AM, Chris Howe wrote:
>>>>>
>>>>>> In addition, TIGER road data is to 15 significant digits as is US
>>>>>> data for county political boundaries.
>>>>>>
>>>>>> Chris Howe  wrote: Roland  wrote: 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
>>>>>>
>>>>>> 640K ought to be enough for anybody.   This reminds me of another
>>>>>> benefit to WTK/WTB.  WTK and WTB are not dependent on the coordinate
>>>>>> system you are using.  Whether your coordinate system is the
>>>>>> latitudinal and longitudinal circles of the earth or whether they
>>>>>> are the coordinate system of your RFID enabled warehosue, WTK and
>>>>>> WTB handles them the same.  Same data format, same use of
>>>>>> projections, same reliability in application you build.  Why record
>>>>>> the same type of information in 15 different formats based on their
>>>>>> use?
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>
>
>
>
>

[Jacques Le Roux]

From: "David E Jones" <[hidden email]>
> It might be better to have an independent ID for the  TerrestrialPosition (like terrestrialPositionId) and have things point  to
> it rather than having it point to other things. In other words we  would add a terrestrialPositionId to the ContactMech instead of
> putting a contactMechId on TerrestrialPosition. In that way anything  could point to it.

Yes and this is even simpler. I followed the PartyContactMech pattern because I thought it was a best practise. But obviously like
that the scope will be wider.

> Also, considering the discussions from before maybe we should add a  text field for Well Known Text that can be used as an
> alternative to  (or perhaps supplement to) the simple lat/lon.

Yes, I remember this discussion. I will add it

Thanks

Jacques

> -David
>
>
> On Aug 4, 2008, at 3:51 PM, Jacques Le Roux wrote:
>
>> I resurrect this thread to let you know that I'm ready to work on this
>> I'd like to create, as we agreed but please confirm,
>> . a new entity TerrestrialPosition with at least these fields for now
>>    . contactMechId
>>  . latitude (using new type degree being NUMERIC(18,6))
>>  . longitude (using new type degree being NUMERIC(18,6))
>>  . comment using type comment
>> . add of a new ContactMechType : TerrestrialPosition
>>
>> The same mechanism used to relate PostalAddress to a Party, a  Facilty, an Invoice, an Order or an OrderItem (so far) will be
>> used  to relate a TerrestrialPosition (through PartyContactMech,  FaciltyContactMech, etc. )
>>
>> If needed we can put more decimals in degree, but RolandH pointed  out that 6 decimals is enough for 4.37184 inch or 11.1044736
>> centimeters !!!
>>
>> If nobody disagree I will go for that (as soon as Adam will have  fixed OFBiz ;o)
>>
>> Jacques
>>
>>
>> From: "Jacques Le Roux" <[hidden email]>
>>> From: "David E Jones" <[hidden email]>
>>>>
>>>> I think I see where you're coming from Chris, and I'm for  standards  and existing toolsets. I think what we're talking about
>>>> here
>>>> is much  more simple.
>>>>
>>>> Eventually we'll (hopefully!) get to the point where we want to  define  polygon boundaries for Geo records and that sort of
>>>> thing,
>>>> and doing  so with Well Known Text (or even GML) might be a great  way to go and  would simplify the data model a lot.
>>>
>>>> From http://en.wikipedia.org/wiki/Well-known_text this sounds like  a good idea to me.
>>>
>>>> For now all we're looking for is a point location for an address,  and  possibly other things too. Actually, I kind of like the
>>>> idea of having  another ContactMechType for a terrestrial  position, and maybe add some  sort of positionContactMechId to the
>>>> PostalAddress entity to point to  it for an address.
>>>
>>> I undestand and agree with Chris's argument, but it's true that I  don't need such sophistication for the moment.
>>> Using the extensibility pattern sounds a 1st raisonnable approach  to me. Obviously better than introducing lat+long in
>>> PostalAddress  and let future open ...
>>>
>>> Jacques
>>>
>>>> In any case, we want to keep this simple because chances are we  will  not use it with a GIS package, unless perhaps to pass
>>>> the
>>>> coordinates  to something to determine if it is within a boundary  or something.  More likely we'll use really simple square or
>>>> circle boundaries and  such which are a lot easier to search  within using any database using  numerical coordinates, and those
>>>> are
>>>> easy since we're just talking  about point coordinates.
>>>>
>>>> Of course, if someone wants to get into real GIS stuff and enhance  the  Geo and other entities in OFBiz for that... by all
>>>> means
>>>> please go for  it!
>>>>
>>>> -David
>>>>
>>>>
>>>> On Jul 2, 2008, at 4:42 PM, Chris Howe wrote:
>>>>
>>>>> David,
>>>>>
>>>>> I stand corrected on the significant digits used in TIGER. It  seems  there is a slight difference in unit specificity in the
>>>>> projection  that I assumed versus what TIGER provides
>>>>>
>>>>> 4269 degree Unit = 0.01745329251994328
>>>>> Tiger degree Unit = 0.017453292519943295
>>>>>
>>>>> This threw off the retrieval calculation of the coordinates and   didn't result in round numbers at the 6th decimal place and
>>>>> thus
>>>>> was  calculated to the maximum significant digits of the library  (15  digits).
>>>>>
>>>>> In regards to what I'm suggesting: I am simply suggesting that  we  use the standards that have existed for over a decade for
>>>>> the
>>>>> storage of geometrical data, namely Well-Known-Text or Well- Known- Binary.  The reason I am suggesting this is because you've
>>>>> already  submitted a desire to perform calculations that have  been optimized  under libraries that use WTK/WTB.  The other
>>>>> reason
>>>>> that I am  suggesting this is that latitude and longitude is not  the only  coordinate system that would benefit from using
>>>>> the
>>>>> standard.  For  instance, if someone has an RFID grid in their  warehouse, they could  benefit from the same conventions being
>>>>> used.
>>>>>
>>>>> In regards to "What about the other databases?":  I can't  imagine  the other databases with spatial extensions would require
>>>>> approaches  that were much different to benefit from GIS.   PostGIS happens to be  an implementation of the OGC standards, so
>>>>> databases that have an  implementation of that standard would  benefit from code written to  that standard.
>>>>>
>>>>> The GeoTools Module Matrix plugins should give you an idea if  you're  concerned about connecting to other databases.
>>>>>
>>>>> http://geotools.codehaus.org/Module+Matrix
>>>>>
>>>>> David E Jones <[hidden email]> wrote:
>>>>> Here is what I found in a quick search:
>>>>>
>>>>> "Coordinates in the TIGER/Line® files are in decimal degrees and  have
>>>>> six
>>>>> implied decimal places. The positional accuracy of these  coordinates
>>>>> is not
>>>>> as great as the six decimal places suggest."
>>>>>
>>>>> That is from near the bottom of page 6 of this document:
>>>>>
>>>>> http://www.census.gov/geo/www/tiger/tigerua/ua2ktgr.pdf
>>>>>
>>>>> Or are you referring to a different TIGER?
>>>>>
>>>>> BTW Chris, I'm having a lot of trouble understanding your posts. I
>>>>> don't know if others are running into the same thing, but much of  the
>>>>> time I'm not sure quite what you're getting at or what you  propose as
>>>>> many of these seem to be little snippets of thought instead of  entire
>>>>> thoughts... could explain a little more of what you have in mind?
>>>>>
>>>>> Also: I looked at the postgis stuff you added, and... what's the
>>>>> point? If it only works with postgres how is that useful for OFBiz?
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>> On Jul 2, 2008, at 4:31 AM, Chris Howe wrote:
>>>>>
>>>>>> In addition, TIGER road data is to 15 significant digits as is US
>>>>>> data for county political boundaries.
>>>>>>
>>>>>> Chris Howe  wrote: Roland  wrote: 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
>>>>>>
>>>>>> 640K ought to be enough for anybody.   This reminds me of another
>>>>>> benefit to WTK/WTB.  WTK and WTB are not dependent on the  coordinate
>>>>>> system you are using.  Whether your coordinate system is the
>>>>>> latitudinal and longitudinal circles of the earth or whether they
>>>>>> are the coordinate system of your RFID enabled warehosue, WTK and
>>>>>> WTB handles them the same.  Same data format, same use of
>>>>>> projections, same reliability in application you build.  Why  record
>>>>>> the same type of information in 15 different formats based on  their
>>>>>> use?
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>
>
>

[Jacques Le Roux]

From: "BJ Freeman" <[hidden email]>
>I like the idea of the TerrestrialPosition entity.
> Maybe have field for the source of the lon/lat.
> like google, yahoo, USPS as enumerated types.
> I say this because i find a difference in the lon/lat for each source.
> and there may be a need to have a different TerrestrialPosition  for
> each one to make that particular system work correctly. Maybe a parent
> child relationship, to save pointing other entities.

This is a bit frightening but unfortunately not really surprising. I did not check, so I rely upon you on this.
I don't think we need more than a field geoPositionSourceEnumId using a relation to Enumeration with a table for this information
except if someone has a better idea/information.
So each source variations will be available, geoPositionSourceEnumId being part of the primary key (with TerrestrialPositionId).

> As a side note: just for future would like a elevation field.
> this is for GPS.

OK, I will add which unit would you prefer ? Maybe better using an elevationUomId referring to a LENGTH_MEASURE ?

Thanks

Jacques

>
> David E Jones sent the following on 8/5/2008 8:41 AM:
>>
>> It might be better to have an independent ID for the TerrestrialPosition
>> (like terrestrialPositionId) and have things point to it rather than
>> having it point to other things. In other words we would add a
>> terrestrialPositionId to the ContactMech instead of putting a
>> contactMechId on TerrestrialPosition. In that way anything could point
>> to it.
>>
>> Also, considering the discussions from before maybe we should add a text
>> field for Well Known Text that can be used as an alternative to (or
>> perhaps supplement to) the simple lat/lon.
>>
>> -David
>>
>>
>> On Aug 4, 2008, at 3:51 PM, Jacques Le Roux wrote:
>>
>>> I resurrect this thread to let you know that I'm ready to work on this
>>> I'd like to create, as we agreed but please confirm,
>>> . a new entity TerrestrialPosition with at least these fields for now
>>>    . contactMechId
>>>  . latitude (using new type degree being NUMERIC(18,6))
>>>  . longitude (using new type degree being NUMERIC(18,6))
>>>  . comment using type comment
>>> . add of a new ContactMechType : TerrestrialPosition
>>>
>>> The same mechanism used to relate PostalAddress to a Party, a Facilty,
>>> an Invoice, an Order or an OrderItem (so far) will be used to relate a
>>> TerrestrialPosition (through PartyContactMech, FaciltyContactMech, etc. )
>>>
>>> If needed we can put more decimals in degree, but RolandH pointed out
>>> that 6 decimals is enough for 4.37184 inch or 11.1044736 centimeters !!!
>>>
>>> If nobody disagree I will go for that (as soon as Adam will have fixed
>>> OFBiz ;o)
>>>
>>> Jacques
>>>
>>>
>>> From: "Jacques Le Roux" <[hidden email]>
>>>> From: "David E Jones" <[hidden email]>
>>>>>
>>>>> I think I see where you're coming from Chris, and I'm for standards
>>>>> and existing toolsets. I think what we're talking about here
>>>>> is much  more simple.
>>>>>
>>>>> Eventually we'll (hopefully!) get to the point where we want to
>>>>> define  polygon boundaries for Geo records and that sort of thing,
>>>>> and doing  so with Well Known Text (or even GML) might be a great
>>>>> way to go and  would simplify the data model a lot.
>>>>
>>>>> From http://en.wikipedia.org/wiki/Well-known_text this sounds like a
>>>>> good idea to me.
>>>>
>>>>> For now all we're looking for is a point location for an address,
>>>>> and  possibly other things too. Actually, I kind of like the
>>>>> idea of having  another ContactMechType for a terrestrial position,
>>>>> and maybe add some  sort of positionContactMechId to the
>>>>> PostalAddress entity to point to  it for an address.
>>>>
>>>> I undestand and agree with Chris's argument, but it's true that I
>>>> don't need such sophistication for the moment.
>>>> Using the extensibility pattern sounds a 1st raisonnable approach to
>>>> me. Obviously better than introducing lat+long in PostalAddress and
>>>> let future open ...
>>>>
>>>> Jacques
>>>>
>>>>> In any case, we want to keep this simple because chances are we
>>>>> will  not use it with a GIS package, unless perhaps to pass the
>>>>> coordinates  to something to determine if it is within a boundary or
>>>>> something.  More likely we'll use really simple square or
>>>>> circle boundaries and  such which are a lot easier to search within
>>>>> using any database using  numerical coordinates, and those are
>>>>> easy since we're just talking  about point coordinates.
>>>>>
>>>>> Of course, if someone wants to get into real GIS stuff and enhance
>>>>> the  Geo and other entities in OFBiz for that... by all means
>>>>> please go for  it!
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>> On Jul 2, 2008, at 4:42 PM, Chris Howe wrote:
>>>>>
>>>>>> David,
>>>>>>
>>>>>> I stand corrected on the significant digits used in TIGER. It
>>>>>> seems  there is a slight difference in unit specificity in the
>>>>>> projection  that I assumed versus what TIGER provides
>>>>>>
>>>>>> 4269 degree Unit = 0.01745329251994328
>>>>>> Tiger degree Unit = 0.017453292519943295
>>>>>>
>>>>>> This threw off the retrieval calculation of the coordinates and
>>>>>> didn't result in round numbers at the 6th decimal place and thus
>>>>>> was  calculated to the maximum significant digits of the library
>>>>>> (15  digits).
>>>>>>
>>>>>> In regards to what I'm suggesting: I am simply suggesting that we
>>>>>> use the standards that have existed for over a decade for the
>>>>>> storage of geometrical data, namely Well-Known-Text or Well-Known-
>>>>>> Binary.  The reason I am suggesting this is because you've
>>>>>> already  submitted a desire to perform calculations that have been
>>>>>> optimized  under libraries that use WTK/WTB.  The other reason
>>>>>> that I am  suggesting this is that latitude and longitude is not
>>>>>> the only  coordinate system that would benefit from using the
>>>>>> standard.  For  instance, if someone has an RFID grid in their
>>>>>> warehouse, they could  benefit from the same conventions being
>>>>>> used.
>>>>>>
>>>>>> In regards to "What about the other databases?":  I can't imagine
>>>>>> the other databases with spatial extensions would require
>>>>>> approaches  that were much different to benefit from GIS.  PostGIS
>>>>>> happens to be  an implementation of the OGC standards, so
>>>>>> databases that have an  implementation of that standard would
>>>>>> benefit from code written to  that standard.
>>>>>>
>>>>>> The GeoTools Module Matrix plugins should give you an idea if
>>>>>> you're  concerned about connecting to other databases.
>>>>>>
>>>>>> http://geotools.codehaus.org/Module+Matrix
>>>>>>
>>>>>> David E Jones <[hidden email]> wrote:
>>>>>> Here is what I found in a quick search:
>>>>>>
>>>>>> "Coordinates in the TIGER/Line® files are in decimal degrees and have
>>>>>> six
>>>>>> implied decimal places. The positional accuracy of these coordinates
>>>>>> is not
>>>>>> as great as the six decimal places suggest."
>>>>>>
>>>>>> That is from near the bottom of page 6 of this document:
>>>>>>
>>>>>> http://www.census.gov/geo/www/tiger/tigerua/ua2ktgr.pdf
>>>>>>
>>>>>> Or are you referring to a different TIGER?
>>>>>>
>>>>>> BTW Chris, I'm having a lot of trouble understanding your posts. I
>>>>>> don't know if others are running into the same thing, but much of the
>>>>>> time I'm not sure quite what you're getting at or what you propose as
>>>>>> many of these seem to be little snippets of thought instead of entire
>>>>>> thoughts... could explain a little more of what you have in mind?
>>>>>>
>>>>>> Also: I looked at the postgis stuff you added, and... what's the
>>>>>> point? If it only works with postgres how is that useful for OFBiz?
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>> On Jul 2, 2008, at 4:31 AM, Chris Howe wrote:
>>>>>>
>>>>>>> In addition, TIGER road data is to 15 significant digits as is US
>>>>>>> data for county political boundaries.
>>>>>>>
>>>>>>> Chris Howe  wrote: Roland  wrote: 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
>>>>>>>
>>>>>>> 640K ought to be enough for anybody.   This reminds me of another
>>>>>>> benefit to WTK/WTB.  WTK and WTB are not dependent on the coordinate
>>>>>>> system you are using.  Whether your coordinate system is the
>>>>>>> latitudinal and longitudinal circles of the earth or whether they
>>>>>>> are the coordinate system of your RFID enabled warehosue, WTK and
>>>>>>> WTB handles them the same.  Same data format, same use of
>>>>>>> projections, same reliability in application you build.  Why record
>>>>>>> the same type of information in 15 different formats based on their
>>>>>>> use?
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>
>>
>>
>>
>
>
>