Re: Latitude, Longitude in PostalAdress

[David E Jones <jo...@hotwaxmedia.com>]

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" <ja...@les7arts.com>
>>>> Thanks Rob,
>>>>
>>>> This is an interesting information, I'm just discovering Google  
>>>> Map API and related...
>>>>
>>>> Jacques
>>>>
>>>> From: "Rob Schapper" <ro...@hotwaxmedia.com>
>>>>> 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" <cj...@yahoo.com>
>>>>>>> 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 <ja...@les7arts.com> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>
>

Re: Latitude, Longitude in PostalAdress

[Jacques Le Roux <ja...@les7arts.com>]

From: "BJ Freeman" <bj...@free-man.net>
> contact mech may not always be the same address and geopoint
> for an address it will always have the same geopoint
> 1) how do you connect an address that already exists with a New ConactMech.
> 2) how do you connect the assoicated Geopoint that goes with that address.

My last proposition should cover your previous demand. If you expire an address then the geo-point this address used (point to) 
would still exist but as the address is obsolete we don't have to care (this address and its associations should not be used 
anymore)
Let see your new questions now:
1) Not sure to understand this one since an address is a type of ContachMech. Did you not used a word for another ?
2) PostalAddress.ContactMechId -> ContacMech -> ContacMech.TerrestialPositionId -> TerrestialPosition

Jacques

>
> Jacques Le Roux sent the following on 8/8/2008 1:00 PM:
>> Yes , this is a good point to note. Actually the geo point continues to
>> exist (it may be used by another thing) but the relation between it and
>> the address does not.
>>
>> Jacques
>>
>> From: "BJ Freeman" <bj...@free-man.net>
>>> but some means would need to link the terrestrial position to the
>>> address so if the address part is disabled, through the enddate, in the
>>> contact mech, so is the position associated with it.
>>>
>>> I agree on the rest.
>>>
>>> Adrian Crum sent the following on 8/7/2008 2:57 PM:
>>>> Jacques Le Roux wrote:
>>>>> Yes actually, I was just thinking about the EntityNameContactMech
>>>>> pattern, not a rule indeed.
>>>>> And because I wondered why we'd use this pattern in most other cases
>>>>> and not for GPS Geolocation, I just reviewed how Len Silverston
>>>>> suggests to deal with contact informations.
>>>>> At this stage I must admit that things were not much more clear. As
>>>>> far as I read Len speaks only about PartyContactMech and
>>>>> FacilityContactMech, but it's easy to extrapolate more usages as it's
>>>>> done in OFBiz.
>>>>>
>>>>> Now, please let me think loud. What is the difference between a postal
>>>>> address and a GPS point ? Is there more differences between
>>>>> them than between, say a telecom number and a postal address ?
>>>>> Obviously telecom numbers and a postal addresses have something in
>>>>> common that a GPS point does not share: they are mechanismes to
>>>>> contact somebody (or something at large). A GPS point is only a mean
>>>>> to locate somebody (or something at large), you can't contact a
>>>>> GPS point. So yes, it makes sense to differntiate a GPS point from
>>>>> other contact mech. A GPS point is not a contact mech as Len
>>>>> Silverstion defines one. It's a mean to locate not to contact. So now
>>>>> I better understant why you wanted things to point to it
>>>>> rather than having it point to other things. I still wonder though if
>>>>> we should not think a bit more about it. Putting a
>>>>> terrestrialPositionId  in ContactMech does not make sense, as it's not
>>>>> a mean to contact but locate. Should we not introduce
>>>>> something else. Like a LocateMech, which could be maybe used for other
>>>>> stuff in future ?
>>>>
>>>> I like the idea of making terrestrial position another contact mech
>>>> type.
>>>>
>>>> I disagree that you can't contact a GPS point. You can if you have a GPS
>>>> device and a means of transportation - the same as a postal address. How
>>>> is locating someone via car plus GPS device any different than locating
>>>> someone via car plus a map?
>>>>
>>>> I can think of other uses for a terrestrial position contact mech type -
>>>> locating facilities or fixed assets like electrical transmission towers,
>>>> cell towers, etc. They aren't going to have a postal address or phone
>>>> number. If terrestrial position was another contact mech type, then we
>>>> could use existing services, etc to associate that location to the
>>>> facility.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>
> 

Re: Latitude, Longitude in PostalAdress

[BJ Freeman <bj...@free-man.net>]

contact mech may not always be the same address and geopoint
for an address it will always have the same geopoint
1) how do you connect an address that already exists with a New ConactMech.
2) how do you connect the assoicated Geopoint that goes with that address.


Jacques Le Roux sent the following on 8/8/2008 1:00 PM:
> Yes , this is a good point to note. Actually the geo point continues to
> exist (it may be used by another thing) but the relation between it and
> the address does not.
> 
> Jacques
> 
> From: "BJ Freeman" <bj...@free-man.net>
>> but some means would need to link the terrestrial position to the
>> address so if the address part is disabled, through the enddate, in the
>> contact mech, so is the position associated with it.
>>
>> I agree on the rest.
>>
>> Adrian Crum sent the following on 8/7/2008 2:57 PM:
>>> Jacques Le Roux wrote:
>>>> Yes actually, I was just thinking about the EntityNameContactMech
>>>> pattern, not a rule indeed.
>>>> And because I wondered why we'd use this pattern in most other cases
>>>> and not for GPS Geolocation, I just reviewed how Len Silverston
>>>> suggests to deal with contact informations.
>>>> At this stage I must admit that things were not much more clear. As
>>>> far as I read Len speaks only about PartyContactMech and
>>>> FacilityContactMech, but it's easy to extrapolate more usages as it's
>>>> done in OFBiz.
>>>>
>>>> Now, please let me think loud. What is the difference between a postal
>>>> address and a GPS point ? Is there more differences between
>>>> them than between, say a telecom number and a postal address ?
>>>> Obviously telecom numbers and a postal addresses have something in
>>>> common that a GPS point does not share: they are mechanismes to
>>>> contact somebody (or something at large). A GPS point is only a mean
>>>> to locate somebody (or something at large), you can't contact a
>>>> GPS point. So yes, it makes sense to differntiate a GPS point from
>>>> other contact mech. A GPS point is not a contact mech as Len
>>>> Silverstion defines one. It's a mean to locate not to contact. So now
>>>> I better understant why you wanted things to point to it
>>>> rather than having it point to other things. I still wonder though if
>>>> we should not think a bit more about it. Putting a
>>>> terrestrialPositionId  in ContactMech does not make sense, as it's not
>>>> a mean to contact but locate. Should we not introduce
>>>> something else. Like a LocateMech, which could be maybe used for other
>>>> stuff in future ?
>>>
>>> I like the idea of making terrestrial position another contact mech
>>> type.
>>>
>>> I disagree that you can't contact a GPS point. You can if you have a GPS
>>> device and a means of transportation - the same as a postal address. How
>>> is locating someone via car plus GPS device any different than locating
>>> someone via car plus a map?
>>>
>>> I can think of other uses for a terrestrial position contact mech type -
>>> locating facilities or fixed assets like electrical transmission towers,
>>> cell towers, etc. They aren't going to have a postal address or phone
>>> number. If terrestrial position was another contact mech type, then we
>>> could use existing services, etc to associate that location to the
>>> facility.
>>>
>>> -Adrian
>>>
>>>
>>>
>>
> 
> 
> 
> 

Re: Latitude, Longitude in PostalAdress

[Jacques Le Roux <ja...@les7arts.com>]

Yes , this is a good point to note. Actually the geo point continues to exist (it may be used by another thing) but the relation 
between it and the address does not.

Jacques

From: "BJ Freeman" <bj...@free-man.net>
> but some means would need to link the terrestrial position to the
> address so if the address part is disabled, through the enddate, in the
> contact mech, so is the position associated with it.
>
> I agree on the rest.
>
> Adrian Crum sent the following on 8/7/2008 2:57 PM:
>> Jacques Le Roux wrote:
>>> Yes actually, I was just thinking about the EntityNameContactMech
>>> pattern, not a rule indeed.
>>> And because I wondered why we'd use this pattern in most other cases
>>> and not for GPS Geolocation, I just reviewed how Len Silverston
>>> suggests to deal with contact informations.
>>> At this stage I must admit that things were not much more clear. As
>>> far as I read Len speaks only about PartyContactMech and
>>> FacilityContactMech, but it's easy to extrapolate more usages as it's
>>> done in OFBiz.
>>>
>>> Now, please let me think loud. What is the difference between a postal
>>> address and a GPS point ? Is there more differences between
>>> them than between, say a telecom number and a postal address ?
>>> Obviously telecom numbers and a postal addresses have something in
>>> common that a GPS point does not share: they are mechanismes to
>>> contact somebody (or something at large). A GPS point is only a mean
>>> to locate somebody (or something at large), you can't contact a
>>> GPS point. So yes, it makes sense to differntiate a GPS point from
>>> other contact mech. A GPS point is not a contact mech as Len
>>> Silverstion defines one. It's a mean to locate not to contact. So now
>>> I better understant why you wanted things to point to it
>>> rather than having it point to other things. I still wonder though if
>>> we should not think a bit more about it. Putting a
>>> terrestrialPositionId  in ContactMech does not make sense, as it's not
>>> a mean to contact but locate. Should we not introduce
>>> something else. Like a LocateMech, which could be maybe used for other
>>> stuff in future ?
>>
>> I like the idea of making terrestrial position another contact mech type.
>>
>> I disagree that you can't contact a GPS point. You can if you have a GPS
>> device and a means of transportation - the same as a postal address. How
>> is locating someone via car plus GPS device any different than locating
>> someone via car plus a map?
>>
>> I can think of other uses for a terrestrial position contact mech type -
>> locating facilities or fixed assets like electrical transmission towers,
>> cell towers, etc. They aren't going to have a postal address or phone
>> number. If terrestrial position was another contact mech type, then we
>> could use existing services, etc to associate that location to the
>> facility.
>>
>> -Adrian
>>
>>
>>
> 

Re: Latitude, Longitude in PostalAdress

[BJ Freeman <bj...@free-man.net>]

but some means would need to link the terrestrial position to the
address so if the address part is disabled, through the enddate, in the
contact mech, so is the position associated with it.

I agree on the rest.

Adrian Crum sent the following on 8/7/2008 2:57 PM:
> Jacques Le Roux wrote:
>> Yes actually, I was just thinking about the EntityNameContactMech
>> pattern, not a rule indeed.
>> And because I wondered why we'd use this pattern in most other cases
>> and not for GPS Geolocation, I just reviewed how Len Silverston
>> suggests to deal with contact informations.
>> At this stage I must admit that things were not much more clear. As
>> far as I read Len speaks only about PartyContactMech and
>> FacilityContactMech, but it's easy to extrapolate more usages as it's
>> done in OFBiz.
>>
>> Now, please let me think loud. What is the difference between a postal
>> address and a GPS point ? Is there more differences between
>> them than between, say a telecom number and a postal address ?
>> Obviously telecom numbers and a postal addresses have something in
>> common that a GPS point does not share: they are mechanismes to
>> contact somebody (or something at large). A GPS point is only a mean
>> to locate somebody (or something at large), you can't contact a
>> GPS point. So yes, it makes sense to differntiate a GPS point from
>> other contact mech. A GPS point is not a contact mech as Len
>> Silverstion defines one. It's a mean to locate not to contact. So now
>> I better understant why you wanted things to point to it
>> rather than having it point to other things. I still wonder though if
>> we should not think a bit more about it. Putting a
>> terrestrialPositionId  in ContactMech does not make sense, as it's not
>> a mean to contact but locate. Should we not introduce
>> something else. Like a LocateMech, which could be maybe used for other
>> stuff in future ?
> 
> I like the idea of making terrestrial position another contact mech type.
> 
> I disagree that you can't contact a GPS point. You can if you have a GPS
> device and a means of transportation - the same as a postal address. How
> is locating someone via car plus GPS device any different than locating
> someone via car plus a map?
> 
> I can think of other uses for a terrestrial position contact mech type -
> locating facilities or fixed assets like electrical transmission towers,
> cell towers, etc. They aren't going to have a postal address or phone
> number. If terrestrial position was another contact mech type, then we
> could use existing services, etc to associate that location to the
> facility.
> 
> -Adrian
> 
> 
> 

Re: Latitude, Longitude in PostalAdress

[David E Jones <jo...@hotwaxmedia.com>]

On Aug 9, 2008, at 2:40 AM, Jacopo Cappellato wrote:

> On Aug 9, 2008, at 9:55 AM, Jacques Le Roux wrote:
>
>> OK it's your opininon. Note however that you will need another mean  
>> to make a contact wih them (like speaking or something :o). The  
>> terrestial position has only allowed you to locate them, not to  
>> send them any kind of signal.
>
> Terrestrial position would be enough if you just have to nuke them :-)

That is a clear form of communication, though you can only really send  
certain types of messages...

-David

Re: Latitude, Longitude in PostalAdress

[Jacopo Cappellato <ja...@gmail.com>]

On Aug 9, 2008, at 9:55 AM, Jacques Le Roux wrote:

> OK it's your opininon. Note however that you will need another mean  
> to make a contact wih them (like speaking or something :o). The  
> terrestial position has only allowed you to locate them, not to send  
> them any kind of signal.

Terrestrial position would be enough if you just have to nuke them :-)

Jacopo

Re: Latitude, Longitude in PostalAdress

[Jacques Le Roux <ja...@les7arts.com>]

From: "Adrian Crum" <ad...@hlmksw.com>
> Jacques Le Roux wrote:
>> From: "Adrian Crum" <ad...@hlmksw.com>
>>> David Jones wrote:
>>>>
>>>> On Fri, 08 Aug 2008 07:44:08 -0700, Adrian Crum <ad...@hlmksw.com> wrote:
>>>>> David E Jones wrote:
>>>>>> On Aug 7, 2008, at 3:57 PM, Adrian Crum wrote:
>>>>>>
>>>>>>> Jacques Le Roux wrote:
>>>>>>>> Yes actually, I was just thinking about the EntityNameContactMech
>>>>>>>> pattern, not a rule indeed.
>>>>>>>> And because I wondered why we'd use this pattern in most other cases
>>>>>>>> and not for GPS Geolocation, I just reviewed how Len Silverston
>>>>>>>> suggests to deal with contact informations.
>>>>>>>> At this stage I must admit that things were not much more clear. As
>>>>>>>> far as I read Len speaks only about PartyContactMech and
>>>>>>>> FacilityContactMech, but it's easy to extrapolate more usages as it's
>>>>>>>> done in OFBiz.
>>>>>>>> Now, please let me think loud. What is the difference between a
>>>>>>>> postal address and a GPS point ? Is there more differences between
>>>>>>>> them than between, say a telecom number and a postal address ?
>>>>>>>> Obviously telecom numbers and a postal addresses have something in
>>>>>>>> common that a GPS point does not share: they are mechanismes to
>>>>>>>> contact somebody (or something at large). A GPS point is only a mean
>>>>>>>> to locate somebody (or something at large), you can't contact a
>>>>>>>> GPS point. So yes, it makes sense to differntiate a GPS point from
>>>>>>>> other contact mech. A GPS point is not a contact mech as Len
>>>>>>>> Silverstion defines one. It's a mean to locate not to contact. So now
>>>>>>>> I better understant why you wanted things to point to it
>>>>>>>> rather than having it point to other things. I still wonder though if
>>>>>>>> we should not think a bit more about it. Putting a
>>>>>>>> terrestrialPositionId  in ContactMech does not make sense, as it's
>>>>>>>> not a mean to contact but locate. Should we not introduce
>>>>>>>> something else. Like a LocateMech, which could be maybe used for
>>>>>>>> other stuff in future ?
>>>>>>> I like the idea of making terrestrial position another contact mech
>>>>> type.
>>>>>>> I disagree that you can't contact a GPS point. You can if you have a
>>>>>>> GPS device and a means of transportation - the same as a postal
>>>>>>> address. How is locating someone via car plus GPS device any different
>>>>>>> than locating someone via car plus a map?
>>>>>>>
>>>>>>> I can think of other uses for a terrestrial position contact mech type
>>>>>>> - locating facilities or fixed assets like electrical transmission
>>>>>>> towers, cell towers, etc. They aren't going to have a postal address
>>>>>>> or phone number. If terrestrial position was another contact mech
>>>>>>> type, then we could use existing services, etc to associate that
>>>>>>> location to the facility.
>>>>>> A PostalAddress is not a contact mechanism because it represents a
>>>>>> location that you can go to, and in fact many postal addresses are not
>>>>>> places you can go to or if you go there you'll find a box or a bunch of
>>>>>> boxes and no people.
>>>>>>
>>>>>> The term "Postal" is a clue: it is meant for contact via letter or
>>>>>> package or whatever.
>>>>> Huh? Maybe I'm missing something. In The Data Model Resource Book
>>>>> chapter 2, it shows a diagram (mine is figure 2.10) that shows Postal
>>>>> Address, Telecommunications Number, and Electronic Address all contained
>>>>> within a contact mechanism "box." The "box" is described by Contact
>>>>> Mechanism Type. How is Postal Address not a contact mechanism?
>>>>
>>>> Where did I say that it is not a contact mech? It certainly it. I just said it is a contact mech because you can send something
>>>> there, NOT because it represents a location.
>>>>
>>>> Would it make sense for me to say that it is not a ContactMech? Come on, gimme a chance and at least re-read what I wrote if it
>>>> doesn't make sense. If I was that much of an idiot OFBiz wouldn't exist.
>>>>
>>>>> What I was trying to express was that a Terrestrial Position entity
>>>>> could be added to the other entities in that box and it could be
>>>>> described as another contact mechanism type.
>>>>
>>>> And that is what I was commenting on as not making sense, because that is not what being a ContactMech means.
>>>
>>> I wasn't implying that you're an idiot. I'm sorry you took it that way. I tried to phrase my reply to indicate I was confused by
>>> your reply and I was trying to make sense of it.
>>>
>>> Thank you for the explanation, I understand what you were trying to say now.
>>>
>>> It's an interesting conundrum. A person or facility could be contacted via a terrestrial position, but at the same time it is
>>> not necessarily a contact mechanism.
>>
>> Sorry to insist Adrian, a person or facility could be *located* via a terrestrial position, but not *contacted*. How will you
>> contact (try to establish a relation) them with the help of only a geo point  (ie lat/long or such) ?
>>
>> Jacques
>
> The same way I would with a street address - transport myself there.

OK it's your opininon. Note however that you will need another mean to make a contact wih them (like speaking or something :o). The 
terrestial position has only allowed you to locate them, not to send them any kind of signal.

> From my perspective, Postal Address and Terrestrial Position are similar, but reversed:
>
> 1. A Postal Address is always a contact mechanism, but it is not always a physical location.
>
> 2. A Terrestrial Position is always a physical location, but it is not always a contact mechanism.

Yes sounds right. BTW I thought a bit more about my distinction between contact an communicate. I think I was on the way but the
definition was not tottaly correct.
I said the difference between contacting and locating is when you contact someone (or something at large) you try to engage a
communication.
It's kind of true but actually when you contact someone/something this only implies that you are able to send a signal/message (like
with a pager/beeper for instance).
It does not need that your contact is able to answer you ! Note that pagers are almost obsolote nowadays
http://en.wikipedia.org/wiki/Pager. Communicate is more than contact, and contact is more than locate.

Anyway it seems that we agree so far on the data model which will be used. Else please comment.

Jacques

> -Adrian
>

Re: Latitude, Longitude in PostalAdress

[Adrian Crum <ad...@hlmksw.com>]

Jacques Le Roux wrote:
> From: "Adrian Crum" <ad...@hlmksw.com>
>> David Jones wrote:
>>>
>>> On Fri, 08 Aug 2008 07:44:08 -0700, Adrian Crum <ad...@hlmksw.com> 
>>> wrote:
>>>> David E Jones wrote:
>>>>> On Aug 7, 2008, at 3:57 PM, Adrian Crum wrote:
>>>>>
>>>>>> Jacques Le Roux wrote:
>>>>>>> Yes actually, I was just thinking about the EntityNameContactMech
>>>>>>> pattern, not a rule indeed.
>>>>>>> And because I wondered why we'd use this pattern in most other cases
>>>>>>> and not for GPS Geolocation, I just reviewed how Len Silverston
>>>>>>> suggests to deal with contact informations.
>>>>>>> At this stage I must admit that things were not much more clear. As
>>>>>>> far as I read Len speaks only about PartyContactMech and
>>>>>>> FacilityContactMech, but it's easy to extrapolate more usages as 
>>>>>>> it's
>>>>>>> done in OFBiz.
>>>>>>> Now, please let me think loud. What is the difference between a
>>>>>>> postal address and a GPS point ? Is there more differences between
>>>>>>> them than between, say a telecom number and a postal address ?
>>>>>>> Obviously telecom numbers and a postal addresses have something in
>>>>>>> common that a GPS point does not share: they are mechanismes to
>>>>>>> contact somebody (or something at large). A GPS point is only a mean
>>>>>>> to locate somebody (or something at large), you can't contact a
>>>>>>> GPS point. So yes, it makes sense to differntiate a GPS point from
>>>>>>> other contact mech. A GPS point is not a contact mech as Len
>>>>>>> Silverstion defines one. It's a mean to locate not to contact. So 
>>>>>>> now
>>>>>>> I better understant why you wanted things to point to it
>>>>>>> rather than having it point to other things. I still wonder 
>>>>>>> though if
>>>>>>> we should not think a bit more about it. Putting a
>>>>>>> terrestrialPositionId  in ContactMech does not make sense, as it's
>>>>>>> not a mean to contact but locate. Should we not introduce
>>>>>>> something else. Like a LocateMech, which could be maybe used for
>>>>>>> other stuff in future ?
>>>>>> I like the idea of making terrestrial position another contact mech
>>>> type.
>>>>>> I disagree that you can't contact a GPS point. You can if you have a
>>>>>> GPS device and a means of transportation - the same as a postal
>>>>>> address. How is locating someone via car plus GPS device any 
>>>>>> different
>>>>>> than locating someone via car plus a map?
>>>>>>
>>>>>> I can think of other uses for a terrestrial position contact mech 
>>>>>> type
>>>>>> - locating facilities or fixed assets like electrical transmission
>>>>>> towers, cell towers, etc. They aren't going to have a postal address
>>>>>> or phone number. If terrestrial position was another contact mech
>>>>>> type, then we could use existing services, etc to associate that
>>>>>> location to the facility.
>>>>> A PostalAddress is not a contact mechanism because it represents a
>>>>> location that you can go to, and in fact many postal addresses are not
>>>>> places you can go to or if you go there you'll find a box or a 
>>>>> bunch of
>>>>> boxes and no people.
>>>>>
>>>>> The term "Postal" is a clue: it is meant for contact via letter or
>>>>> package or whatever.
>>>> Huh? Maybe I'm missing something. In The Data Model Resource Book
>>>> chapter 2, it shows a diagram (mine is figure 2.10) that shows Postal
>>>> Address, Telecommunications Number, and Electronic Address all 
>>>> contained
>>>> within a contact mechanism "box." The "box" is described by Contact
>>>> Mechanism Type. How is Postal Address not a contact mechanism?
>>>
>>> Where did I say that it is not a contact mech? It certainly it. I 
>>> just said it is a contact mech because you can send something there, 
>>> NOT because it represents a location.
>>>
>>> Would it make sense for me to say that it is not a ContactMech? Come 
>>> on, gimme a chance and at least re-read what I wrote if it doesn't 
>>> make sense. If I was that much of an idiot OFBiz wouldn't exist.
>>>
>>>> What I was trying to express was that a Terrestrial Position entity
>>>> could be added to the other entities in that box and it could be
>>>> described as another contact mechanism type.
>>>
>>> And that is what I was commenting on as not making sense, because 
>>> that is not what being a ContactMech means.
>>
>> I wasn't implying that you're an idiot. I'm sorry you took it that 
>> way. I tried to phrase my reply to indicate I was confused by your 
>> reply and I was trying to make sense of it.
>>
>> Thank you for the explanation, I understand what you were trying to 
>> say now.
>>
>> It's an interesting conundrum. A person or facility could be contacted 
>> via a terrestrial position, but at the same time it is not necessarily 
>> a contact mechanism.
> 
> Sorry to insist Adrian, a person or facility could be *located* via a 
> terrestrial position, but not *contacted*. How will you contact (try to 
> establish a relation) them with the help of only a geo point  (ie 
> lat/long or such) ?
> 
> Jacques

The same way I would with a street address - transport myself there.

 From my perspective, Postal Address and Terrestrial Position are 
similar, but reversed:

1. A Postal Address is always a contact mechanism, but it is not always 
a physical location.

2. A Terrestrial Position is always a physical location, but it is not 
always a contact mechanism.

-Adrian

Re: Latitude, Longitude in PostalAdress

[Jacques Le Roux <ja...@les7arts.com>]

From: "Adrian Crum" <ad...@hlmksw.com>
> David Jones wrote:
>>
>> On Fri, 08 Aug 2008 07:44:08 -0700, Adrian Crum <ad...@hlmksw.com> wrote:
>>> David E Jones wrote:
>>>> On Aug 7, 2008, at 3:57 PM, Adrian Crum wrote:
>>>>
>>>>> Jacques Le Roux wrote:
>>>>>> Yes actually, I was just thinking about the EntityNameContactMech
>>>>>> pattern, not a rule indeed.
>>>>>> And because I wondered why we'd use this pattern in most other cases
>>>>>> and not for GPS Geolocation, I just reviewed how Len Silverston
>>>>>> suggests to deal with contact informations.
>>>>>> At this stage I must admit that things were not much more clear. As
>>>>>> far as I read Len speaks only about PartyContactMech and
>>>>>> FacilityContactMech, but it's easy to extrapolate more usages as it's
>>>>>> done in OFBiz.
>>>>>> Now, please let me think loud. What is the difference between a
>>>>>> postal address and a GPS point ? Is there more differences between
>>>>>> them than between, say a telecom number and a postal address ?
>>>>>> Obviously telecom numbers and a postal addresses have something in
>>>>>> common that a GPS point does not share: they are mechanismes to
>>>>>> contact somebody (or something at large). A GPS point is only a mean
>>>>>> to locate somebody (or something at large), you can't contact a
>>>>>> GPS point. So yes, it makes sense to differntiate a GPS point from
>>>>>> other contact mech. A GPS point is not a contact mech as Len
>>>>>> Silverstion defines one. It's a mean to locate not to contact. So now
>>>>>> I better understant why you wanted things to point to it
>>>>>> rather than having it point to other things. I still wonder though if
>>>>>> we should not think a bit more about it. Putting a
>>>>>> terrestrialPositionId  in ContactMech does not make sense, as it's
>>>>>> not a mean to contact but locate. Should we not introduce
>>>>>> something else. Like a LocateMech, which could be maybe used for
>>>>>> other stuff in future ?
>>>>> I like the idea of making terrestrial position another contact mech
>>> type.
>>>>> I disagree that you can't contact a GPS point. You can if you have a
>>>>> GPS device and a means of transportation - the same as a postal
>>>>> address. How is locating someone via car plus GPS device any different
>>>>> than locating someone via car plus a map?
>>>>>
>>>>> I can think of other uses for a terrestrial position contact mech type
>>>>> - locating facilities or fixed assets like electrical transmission
>>>>> towers, cell towers, etc. They aren't going to have a postal address
>>>>> or phone number. If terrestrial position was another contact mech
>>>>> type, then we could use existing services, etc to associate that
>>>>> location to the facility.
>>>> A PostalAddress is not a contact mechanism because it represents a
>>>> location that you can go to, and in fact many postal addresses are not
>>>> places you can go to or if you go there you'll find a box or a bunch of
>>>> boxes and no people.
>>>>
>>>> The term "Postal" is a clue: it is meant for contact via letter or
>>>> package or whatever.
>>> Huh? Maybe I'm missing something. In The Data Model Resource Book
>>> chapter 2, it shows a diagram (mine is figure 2.10) that shows Postal
>>> Address, Telecommunications Number, and Electronic Address all contained
>>> within a contact mechanism "box." The "box" is described by Contact
>>> Mechanism Type. How is Postal Address not a contact mechanism?
>>
>> Where did I say that it is not a contact mech? It certainly it. I just said it is a contact mech because you can send something 
>> there, NOT because it represents a location.
>>
>> Would it make sense for me to say that it is not a ContactMech? Come on, gimme a chance and at least re-read what I wrote if it 
>> doesn't make sense. If I was that much of an idiot OFBiz wouldn't exist.
>>
>>> What I was trying to express was that a Terrestrial Position entity
>>> could be added to the other entities in that box and it could be
>>> described as another contact mechanism type.
>>
>> And that is what I was commenting on as not making sense, because that is not what being a ContactMech means.
>
> I wasn't implying that you're an idiot. I'm sorry you took it that way. I tried to phrase my reply to indicate I was confused by 
> your reply and I was trying to make sense of it.
>
> Thank you for the explanation, I understand what you were trying to say now.
>
> It's an interesting conundrum. A person or facility could be contacted via a terrestrial position, but at the same time it is not 
> necessarily a contact mechanism.

Sorry to insist Adrian, a person or facility could be *located* via a terrestrial position, but not *contacted*. How will you 
contact (try to establish a relation) them with the help of only a geo point  (ie lat/long or such) ?

Jacques

> -Adrian
> 

Re: Latitude, Longitude in PostalAdress

[Adrian Crum <ad...@hlmksw.com>]

David Jones wrote:
> 
> On Fri, 08 Aug 2008 07:44:08 -0700, Adrian Crum <ad...@hlmksw.com> wrote:
>> David E Jones wrote:
>>> On Aug 7, 2008, at 3:57 PM, Adrian Crum wrote:
>>>
>>>> Jacques Le Roux wrote:
>>>>> Yes actually, I was just thinking about the EntityNameContactMech
>>>>> pattern, not a rule indeed.
>>>>> And because I wondered why we'd use this pattern in most other cases
>>>>> and not for GPS Geolocation, I just reviewed how Len Silverston
>>>>> suggests to deal with contact informations.
>>>>> At this stage I must admit that things were not much more clear. As
>>>>> far as I read Len speaks only about PartyContactMech and
>>>>> FacilityContactMech, but it's easy to extrapolate more usages as it's
>>>>> done in OFBiz.
>>>>> Now, please let me think loud. What is the difference between a
>>>>> postal address and a GPS point ? Is there more differences between
>>>>> them than between, say a telecom number and a postal address ?
>>>>> Obviously telecom numbers and a postal addresses have something in
>>>>> common that a GPS point does not share: they are mechanismes to
>>>>> contact somebody (or something at large). A GPS point is only a mean
>>>>> to locate somebody (or something at large), you can't contact a
>>>>> GPS point. So yes, it makes sense to differntiate a GPS point from
>>>>> other contact mech. A GPS point is not a contact mech as Len
>>>>> Silverstion defines one. It's a mean to locate not to contact. So now
>>>>> I better understant why you wanted things to point to it
>>>>> rather than having it point to other things. I still wonder though if
>>>>> we should not think a bit more about it. Putting a
>>>>> terrestrialPositionId  in ContactMech does not make sense, as it's
>>>>> not a mean to contact but locate. Should we not introduce
>>>>> something else. Like a LocateMech, which could be maybe used for
>>>>> other stuff in future ?
>>>> I like the idea of making terrestrial position another contact mech
>> type.
>>>> I disagree that you can't contact a GPS point. You can if you have a
>>>> GPS device and a means of transportation - the same as a postal
>>>> address. How is locating someone via car plus GPS device any different
>>>> than locating someone via car plus a map?
>>>>
>>>> I can think of other uses for a terrestrial position contact mech type
>>>> - locating facilities or fixed assets like electrical transmission
>>>> towers, cell towers, etc. They aren't going to have a postal address
>>>> or phone number. If terrestrial position was another contact mech
>>>> type, then we could use existing services, etc to associate that
>>>> location to the facility.
>>> A PostalAddress is not a contact mechanism because it represents a
>>> location that you can go to, and in fact many postal addresses are not
>>> places you can go to or if you go there you'll find a box or a bunch of
>>> boxes and no people.
>>>
>>> The term "Postal" is a clue: it is meant for contact via letter or
>>> package or whatever.
>> Huh? Maybe I'm missing something. In The Data Model Resource Book
>> chapter 2, it shows a diagram (mine is figure 2.10) that shows Postal
>> Address, Telecommunications Number, and Electronic Address all contained
>> within a contact mechanism "box." The "box" is described by Contact
>> Mechanism Type. How is Postal Address not a contact mechanism?
> 
> Where did I say that it is not a contact mech? It certainly it. I just said it is a contact mech because you can send something there, NOT because it represents a location.
> 
> Would it make sense for me to say that it is not a ContactMech? Come on, gimme a chance and at least re-read what I wrote if it doesn't make sense. If I was that much of an idiot OFBiz wouldn't exist.
> 
>> What I was trying to express was that a Terrestrial Position entity
>> could be added to the other entities in that box and it could be
>> described as another contact mechanism type.
> 
> And that is what I was commenting on as not making sense, because that is not what being a ContactMech means.

I wasn't implying that you're an idiot. I'm sorry you took it that way. 
I tried to phrase my reply to indicate I was confused by your reply and 
I was trying to make sense of it.

Thank you for the explanation, I understand what you were trying to say now.

It's an interesting conundrum. A person or facility could be contacted 
via a terrestrial position, but at the same time it is not necessarily a 
contact mechanism.

-Adrian

Re: Latitude, Longitude in PostalAdress

[David Jones <jo...@hotwaxmedia.com>]

On Fri, 08 Aug 2008 07:44:08 -0700, Adrian Crum <ad...@hlmksw.com> wrote:
> David E Jones wrote:
>>
>> On Aug 7, 2008, at 3:57 PM, Adrian Crum wrote:
>>
>>> Jacques Le Roux wrote:
>>>> Yes actually, I was just thinking about the EntityNameContactMech
>>>> pattern, not a rule indeed.
>>>> And because I wondered why we'd use this pattern in most other cases
>>>> and not for GPS Geolocation, I just reviewed how Len Silverston
>>>> suggests to deal with contact informations.
>>>> At this stage I must admit that things were not much more clear. As
>>>> far as I read Len speaks only about PartyContactMech and
>>>> FacilityContactMech, but it's easy to extrapolate more usages as it's
>>>> done in OFBiz.
>>>> Now, please let me think loud. What is the difference between a
>>>> postal address and a GPS point ? Is there more differences between
>>>> them than between, say a telecom number and a postal address ?
>>>> Obviously telecom numbers and a postal addresses have something in
>>>> common that a GPS point does not share: they are mechanismes to
>>>> contact somebody (or something at large). A GPS point is only a mean
>>>> to locate somebody (or something at large), you can't contact a
>>>> GPS point. So yes, it makes sense to differntiate a GPS point from
>>>> other contact mech. A GPS point is not a contact mech as Len
>>>> Silverstion defines one. It's a mean to locate not to contact. So now
>>>> I better understant why you wanted things to point to it
>>>> rather than having it point to other things. I still wonder though if
>>>> we should not think a bit more about it. Putting a
>>>> terrestrialPositionId  in ContactMech does not make sense, as it's
>>>> not a mean to contact but locate. Should we not introduce
>>>> something else. Like a LocateMech, which could be maybe used for
>>>> other stuff in future ?
>>>
>>> I like the idea of making terrestrial position another contact mech
> type.
>>>
>>> I disagree that you can't contact a GPS point. You can if you have a
>>> GPS device and a means of transportation - the same as a postal
>>> address. How is locating someone via car plus GPS device any different
>>> than locating someone via car plus a map?
>>>
>>> I can think of other uses for a terrestrial position contact mech type
>>> - locating facilities or fixed assets like electrical transmission
>>> towers, cell towers, etc. They aren't going to have a postal address
>>> or phone number. If terrestrial position was another contact mech
>>> type, then we could use existing services, etc to associate that
>>> location to the facility.
>>
>> A PostalAddress is not a contact mechanism because it represents a
>> location that you can go to, and in fact many postal addresses are not
>> places you can go to or if you go there you'll find a box or a bunch of
>> boxes and no people.
>>
>> The term "Postal" is a clue: it is meant for contact via letter or
>> package or whatever.
> 
> Huh? Maybe I'm missing something. In The Data Model Resource Book
> chapter 2, it shows a diagram (mine is figure 2.10) that shows Postal
> Address, Telecommunications Number, and Electronic Address all contained
> within a contact mechanism "box." The "box" is described by Contact
> Mechanism Type. How is Postal Address not a contact mechanism?

Where did I say that it is not a contact mech? It certainly it. I just said it is a contact mech because you can send something there, NOT because it represents a location.

Would it make sense for me to say that it is not a ContactMech? Come on, gimme a chance and at least re-read what I wrote if it doesn't make sense. If I was that much of an idiot OFBiz wouldn't exist.

> What I was trying to express was that a Terrestrial Position entity
> could be added to the other entities in that box and it could be
> described as another contact mechanism type.

And that is what I was commenting on as not making sense, because that is not what being a ContactMech means.

-David

Re: Latitude, Longitude in PostalAdress

[Adrian Crum <ad...@hlmksw.com>]

David E Jones wrote:
> 
> On Aug 7, 2008, at 3:57 PM, Adrian Crum wrote:
> 
>> Jacques Le Roux wrote:
>>> Yes actually, I was just thinking about the EntityNameContactMech 
>>> pattern, not a rule indeed.
>>> And because I wondered why we'd use this pattern in most other cases 
>>> and not for GPS Geolocation, I just reviewed how Len Silverston
>>> suggests to deal with contact informations.
>>> At this stage I must admit that things were not much more clear. As 
>>> far as I read Len speaks only about PartyContactMech and
>>> FacilityContactMech, but it's easy to extrapolate more usages as it's 
>>> done in OFBiz.
>>> Now, please let me think loud. What is the difference between a 
>>> postal address and a GPS point ? Is there more differences between
>>> them than between, say a telecom number and a postal address ?
>>> Obviously telecom numbers and a postal addresses have something in 
>>> common that a GPS point does not share: they are mechanismes to
>>> contact somebody (or something at large). A GPS point is only a mean 
>>> to locate somebody (or something at large), you can't contact a
>>> GPS point. So yes, it makes sense to differntiate a GPS point from 
>>> other contact mech. A GPS point is not a contact mech as Len
>>> Silverstion defines one. It's a mean to locate not to contact. So now 
>>> I better understant why you wanted things to point to it
>>> rather than having it point to other things. I still wonder though if 
>>> we should not think a bit more about it. Putting a
>>> terrestrialPositionId  in ContactMech does not make sense, as it's 
>>> not a mean to contact but locate. Should we not introduce
>>> something else. Like a LocateMech, which could be maybe used for 
>>> other stuff in future ?
>>
>> I like the idea of making terrestrial position another contact mech type.
>>
>> I disagree that you can't contact a GPS point. You can if you have a 
>> GPS device and a means of transportation - the same as a postal 
>> address. How is locating someone via car plus GPS device any different 
>> than locating someone via car plus a map?
>>
>> I can think of other uses for a terrestrial position contact mech type 
>> - locating facilities or fixed assets like electrical transmission 
>> towers, cell towers, etc. They aren't going to have a postal address 
>> or phone number. If terrestrial position was another contact mech 
>> type, then we could use existing services, etc to associate that 
>> location to the facility.
> 
> A PostalAddress is not a contact mechanism because it represents a 
> location that you can go to, and in fact many postal addresses are not 
> places you can go to or if you go there you'll find a box or a bunch of 
> boxes and no people.
> 
> The term "Postal" is a clue: it is meant for contact via letter or 
> package or whatever.

Huh? Maybe I'm missing something. In The Data Model Resource Book 
chapter 2, it shows a diagram (mine is figure 2.10) that shows Postal 
Address, Telecommunications Number, and Electronic Address all contained 
within a contact mechanism "box." The "box" is described by Contact 
Mechanism Type. How is Postal Address not a contact mechanism?

What I was trying to express was that a Terrestrial Position entity 
could be added to the other entities in that box and it could be 
described as another contact mechanism type.

-Adrian

Re: Latitude, Longitude in PostalAdress

[David E Jones <jo...@hotwaxmedia.com>]

On Aug 7, 2008, at 3:57 PM, Adrian Crum wrote:

> Jacques Le Roux wrote:
>> Yes actually, I was just thinking about the EntityNameContactMech  
>> pattern, not a rule indeed.
>> And because I wondered why we'd use this pattern in most other  
>> cases and not for GPS Geolocation, I just reviewed how Len Silverston
>> suggests to deal with contact informations.
>> At this stage I must admit that things were not much more clear. As  
>> far as I read Len speaks only about PartyContactMech and
>> FacilityContactMech, but it's easy to extrapolate more usages as  
>> it's done in OFBiz.
>> Now, please let me think loud. What is the difference between a  
>> postal address and a GPS point ? Is there more differences between
>> them than between, say a telecom number and a postal address ?
>> Obviously telecom numbers and a postal addresses have something in  
>> common that a GPS point does not share: they are mechanismes to
>> contact somebody (or something at large). A GPS point is only a  
>> mean to locate somebody (or something at large), you can't contact a
>> GPS point. So yes, it makes sense to differntiate a GPS point from  
>> other contact mech. A GPS point is not a contact mech as Len
>> Silverstion defines one. It's a mean to locate not to contact. So  
>> now I better understant why you wanted things to point to it
>> rather than having it point to other things. I still wonder though  
>> if we should not think a bit more about it. Putting a
>> terrestrialPositionId  in ContactMech does not make sense, as it's  
>> not a mean to contact but locate. Should we not introduce
>> something else. Like a LocateMech, which could be maybe used for  
>> other stuff in future ?
>
> I like the idea of making terrestrial position another contact mech  
> type.
>
> I disagree that you can't contact a GPS point. You can if you have a  
> GPS device and a means of transportation - the same as a postal  
> address. How is locating someone via car plus GPS device any  
> different than locating someone via car plus a map?
>
> I can think of other uses for a terrestrial position contact mech  
> type - locating facilities or fixed assets like electrical  
> transmission towers, cell towers, etc. They aren't going to have a  
> postal address or phone number. If terrestrial position was another  
> contact mech type, then we could use existing services, etc to  
> associate that location to the facility.

A PostalAddress is not a contact mechanism because it represents a  
location that you can go to, and in fact many postal addresses are not  
places you can go to or if you go there you'll find a box or a bunch  
of boxes and no people.

The term "Postal" is a clue: it is meant for contact via letter or  
package or whatever.

-David

Re: Latitude, Longitude in PostalAdress

[Jacques Le Roux <ja...@les7arts.com>]

From: "Adrian Crum" <ad...@hlmksw.com>
> Jacques Le Roux wrote:
>> Yes actually, I was just thinking about the EntityNameContactMech pattern, not a rule indeed.
>> And because I wondered why we'd use this pattern in most other cases and not for GPS Geolocation, I just reviewed how Len 
>> Silverston
>> suggests to deal with contact informations.
>> At this stage I must admit that things were not much more clear. As far as I read Len speaks only about PartyContactMech and
>> FacilityContactMech, but it's easy to extrapolate more usages as it's done in OFBiz.
>>
>> Now, please let me think loud. What is the difference between a postal address and a GPS point ? Is there more differences 
>> between
>> them than between, say a telecom number and a postal address ?
>> Obviously telecom numbers and a postal addresses have something in common that a GPS point does not share: they are mechanismes 
>> to
>> contact somebody (or something at large). A GPS point is only a mean to locate somebody (or something at large), you can't 
>> contact a
>> GPS point. So yes, it makes sense to differntiate a GPS point from other contact mech. A GPS point is not a contact mech as Len
>> Silverstion defines one. It's a mean to locate not to contact. So now I better understant why you wanted things to point to it
>> rather than having it point to other things. I still wonder though if we should not think a bit more about it. Putting a
>> terrestrialPositionId  in ContactMech does not make sense, as it's not a mean to contact but locate. Should we not introduce
>> something else. Like a LocateMech, which could be maybe used for other stuff in future ?
>
> I like the idea of making terrestrial position another contact mech type.
>
> I disagree that you can't contact a GPS point. You can if you have a GPS device and a means of transportation - the same as a 
> postal address. How is locating someone via car plus GPS device any different than locating someone via car plus a map?

<notroll>
Maybe this comes from an ambiguity in language (and maybe from French where the same words are used).
For me contacting implies the possibility of a response, it opens a communication (with possibly no answers). This is the main 
reason of existences for postal addresses, telephone numbers, emails, fax, IP addresses, etc. : to communicate.
Locate is unidirectional, you don't expect a car (or a machine at large) to answer you.
This is why I tried to introduce this difference betwen contact and locate. I was also thinking about RFID and such rising 
technologies.

But as I said you can use a postal address without expecting an answer, only to locate someone or something (delivery man, postman, 
etc.).
You may use an IP address to locate a machine : whois. I also use the example of cell phones used by police when investigating, but 
this one is disconcerting because it's a mix.
So I don't want to troll, and as I said before maybe this distinction is not needed in OFBiz which is already enough complex...
</notroll>

> I can think of other uses for a terrestrial position contact mech type - locating facilities or fixed assets like electrical 
> transmission towers, cell towers, etc. They aren't going to have a postal address or phone number. If terrestrial position was 
> another contact mech type, then we could use existing services, etc to associate that location to the facility.

Yes, to locate them :o)

Jacques

> -Adrian
> 

Re: Latitude, Longitude in PostalAdress

[Adrian Crum <ad...@hlmksw.com>]

Jacques Le Roux wrote:
> Yes actually, I was just thinking about the EntityNameContactMech 
> pattern, not a rule indeed.
> And because I wondered why we'd use this pattern in most other cases and 
> not for GPS Geolocation, I just reviewed how Len Silverston
> suggests to deal with contact informations.
> At this stage I must admit that things were not much more clear. As far 
> as I read Len speaks only about PartyContactMech and
> FacilityContactMech, but it's easy to extrapolate more usages as it's 
> done in OFBiz.
> 
> Now, please let me think loud. What is the difference between a postal 
> address and a GPS point ? Is there more differences between
> them than between, say a telecom number and a postal address ?
> Obviously telecom numbers and a postal addresses have something in 
> common that a GPS point does not share: they are mechanismes to
> contact somebody (or something at large). A GPS point is only a mean to 
> locate somebody (or something at large), you can't contact a
> GPS point. So yes, it makes sense to differntiate a GPS point from other 
> contact mech. A GPS point is not a contact mech as Len
> Silverstion defines one. It's a mean to locate not to contact. So now I 
> better understant why you wanted things to point to it
> rather than having it point to other things. I still wonder though if we 
> should not think a bit more about it. Putting a
> terrestrialPositionId  in ContactMech does not make sense, as it's not a 
> mean to contact but locate. Should we not introduce
> something else. Like a LocateMech, which could be maybe used for other 
> stuff in future ?

I like the idea of making terrestrial position another contact mech type.

I disagree that you can't contact a GPS point. You can if you have a GPS 
device and a means of transportation - the same as a postal address. How 
is locating someone via car plus GPS device any different than locating 
someone via car plus a map?

I can think of other uses for a terrestrial position contact mech type - 
locating facilities or fixed assets like electrical transmission towers, 
cell towers, etc. They aren't going to have a postal address or phone 
number. If terrestrial position was another contact mech type, then we 
could use existing services, etc to associate that location to the facility.

-Adrian

Re: Latitude, Longitude in PostalAdress

[Jacques Le Roux <ja...@les7arts.com>]

From: "David E Jones" <jo...@hotwaxmedia.com>
>
> On Aug 7, 2008, at 3:12 PM, Jacques Le Roux wrote:
>
>> From: "David E Jones" <jo...@hotwaxmedia.com>
>>> One thing to note after this : an address may be used to contact  but also only to locate (like for delivery). Same with a cell
>> phone, when the police investigates... So maybe a ContacMech is  enough, in OFBiz at least...
>>
>> Sorry for the long post, but you asked for thinking, I tried and  finally find your 1st solution simple and clear :
>> 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$
>
> It could be a type of ContactMech, but DEFINITELY not on the  ContactMech itself... most contact mechs have no location 
> implication,  except perhaps in a wide area (like a country or area code of a phone  number).
>
> But still, a TerrestrialPosition is not a ContactMech and creating a  type for it would be a serious hack.

Yes it was late (like it's now) and I stupidly copied all your 1st proposition forgetting the one I wrote in the meantime. I rewrote 
it there adding the new ideas/corrections we (re)expressed. Please comment.if needed
. I agree we don't need to have a new ContactMechType : TerrestrialPosition (personnaly from my distincton between 
contact/communicate and locate usage)
. So we will not use an intersection entity like EntityNameContactMech but will directly relate a thing to a TerrestrialPosition 
through ContactMech using a TerrestrialPositionId field
. So we will add a new field TerrestrialPositionId to ContactMech
. We will create a new entity TerrestrialPosition with at least these fields for now
    . terrestrialPositionId
    . latitude (using new type degree being NUMERIC(18,6))
    . longitude (using new type degree being NUMERIC(18,6))
    . wellKnownText    (text field)
    . comment using type comment

>> BTW, what do yout think about my answer to BJ about different  geolocation sources (yahoo, google, etc.) : a primary key field 
>> geoPositionSourceEnumId using a relation to Enumeration in  TerrestrialPosition entity?
>> And his proposition of 2 fields for GPS elevation (one that has the  value and one the enumerates elevationUomId)
>
> Why a primary key field? That makes no sense to me whatsoever...

BJ wrote << 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."

The idea was to prevent to have to deal with any relationships. So the couple terrestrialPositionId+geoPositionSourceEnumId would 
have defined an unique TerrestrialPosition instance.
But I admit that this is annoying if we want to point to a TerrestrialPosition through a ContactMech. I will see that later... 
tired...

Jacques

> -David
>
> 

Re: Latitude, Longitude in PostalAdress

[David E Jones <jo...@hotwaxmedia.com>]

On Aug 7, 2008, at 3:12 PM, Jacques Le Roux wrote:

> From: "David E Jones" <jo...@hotwaxmedia.com>
>> One thing to note after this : an address may be used to contact  
>> but also only to locate (like for delivery). Same with a cell
> phone, when the police investigates... So maybe a ContacMech is  
> enough, in OFBiz at least...
>
> Sorry for the long post, but you asked for thinking, I tried and  
> finally find your 1st solution simple and clear :
> 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$

It could be a type of ContactMech, but DEFINITELY not on the  
ContactMech itself... most contact mechs have no location implication,  
except perhaps in a wide area (like a country or area code of a phone  
number).

But still, a TerrestrialPosition is not a ContactMech and creating a  
type for it would be a serious hack.

> BTW, what do yout think about my answer to BJ about different  
> geolocation sources (yahoo, google, etc.) : a primary key field  
> geoPositionSourceEnumId using a relation to Enumeration in  
> TerrestrialPosition entity?
> And his proposition of 2 fields for GPS elevation (one that has the  
> value and one the enumerates elevationUomId)

Why a primary key field? That makes no sense to me whatsoever...

-David

Re: Latitude, Longitude in PostalAdress

[BJ Freeman <bj...@free-man.net>]

As I responded to adrian, My only real concern is that a geopoint,
linked to an address, needs to be admistered so that the geopoint
enddate is set at the same time the address enddate is set.
having Geopoints that do not relate to and address is ok with me.
like if there is a topicgraphical map made from geopoints, that is why
the elevation.

Jacques Le Roux sent the following on 8/8/2008 1:16 AM:
> Or vice versa. For me a geo point has more sense than an adress, it's
> physical (ok humans define what physical is and the rules ;o), an
> address is only a convenient  administrative thing (between parties). I
> mean that a goe point subsume an address (think about sea, 70% of the
> globe surface ;o)
> 
> Jacques
> 
> From: "BJ Freeman" <bj...@free-man.net>
>> if I may.
>> think of it this way
>> an address is fixed, never moves
>> and geopoint is the same
>> now if the contact mech point to the address the the address will give
>> the geopoint
>> so you have a mechanism to find the geopoint, if just the address point
>> to the geo point, in a view.
>>
>> so contact mech points to the address from the address you find the
>> geopoint
>>
>>
>>
>> Jacques Le Roux sent the following on 8/7/2008 2:12 PM:
>>> From: "David E Jones" <jo...@hotwaxmedia.com>
>>>>
>>>> On Aug 5, 2008, at 4:08 PM, Jacques Le Roux wrote:
>>>>
>>>>> From: "David E Jones" <jo...@hotwaxmedia.com>
>>>>>>
>>>>>> On Aug 5, 2008, at 2:37 PM, Jacques Le Roux wrote:
>>>>>>
>>>>>>> From: "David E Jones" <jo...@hotwaxmedia.com>
>>>>>>>> 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.
>>>>>>
>>>>>> This is something we should maybe discuss more, ie whether the
>>>>>> TerrestrialPosition should be a type of ContactMech or it's own
>>>>>> independent thing. I was thinking the independence might be
>>>>>> better,  and we would have more control over what it is attached
>>>>>> to.
>>>>>> In other  words, the use patterns and relationships to other
>>>>>> entities are a  little different than what is done with
>>>>>> ContactMechs.
>>>>>>
>>>>>> Still, if anyone thinks otherwise... please share.
>>>>>
>>>>> Actually what I said above is not true. The scope will not be wider.
>>>>> You can get the same using the ContactMech pattern. It's
>>>>> only a bit  harder since you have to create a specific entity (like
>>>>> FacilityLocationContactMech) and make the association
>>>>> between the 2  other entities each time you want to relate a new
>>>>> entity (like say  FacilityLocation). In the second case only one
>>>>> association to  TerrestrialPosition would be needed. So it's up to
>>>>> you guys,  sometimes breaking the rules is good, sometimes
>>>>> it's not, we have to  really think about it ... before...
>>>>
>>>> What do you mean by "break the rules"? I don't see any rules being
>>>> broken here...
>>>
>>> Yes actually, I was just thinking about the EntityNameContactMech
>>> pattern, not a rule indeed.
>>> And because I wondered why we'd use this pattern in most other cases and
>>> not for GPS Geolocation, I just reviewed how Len Silverston
>>> suggests to deal with contact informations.
>>> At this stage I must admit that things were not much more clear. As far
>>> as I read Len speaks only about PartyContactMech and
>>> FacilityContactMech, but it's easy to extrapolate more usages as it's
>>> done in OFBiz.
>>>
>>> Now, please let me think loud. What is the difference between a postal
>>> address and a GPS point ? Is there more differences between
>>> them than between, say a telecom number and a postal address ?
>>> Obviously telecom numbers and a postal addresses have something in
>>> common that a GPS point does not share: they are mechanismes to
>>> contact somebody (or something at large). A GPS point is only a mean to
>>> locate somebody (or something at large), you can't contact a
>>> GPS point. So yes, it makes sense to differntiate a GPS point from other
>>> contact mech. A GPS point is not a contact mech as Len
>>> Silverstion defines one. It's a mean to locate not to contact. So now I
>>> better understant why you wanted things to point to it
>>> rather than having it point to other things. I still wonder though if we
>>> should not think a bit more about it. Putting a
>>> terrestrialPositionId  in ContactMech does not make sense, as it's not a
>>> mean to contact but locate. Should we not introduce
>>> something else. Like a LocateMech, which could be maybe used for other
>>> stuff in future ?
>>>
>>> Let me dream now (you are allowed to no read that :o) : I live in the
>>> country (not so far from town, but country). And where I live
>>> there is no numbers to the road. So it's hard to find me (I did not make
>>> it purposely ;o). Sometimes it's cool, sometimes it's very
>>> annoying. Like when you receive a CD from Amazon the 1st time (and even
>>> after : deliverymen change). Sometimes it's even worse : the
>>> French postal service, "La Poste", will change its status soon and will
>>> become a private company (yes things are changing, even in
>>> France). The bad side (there is always one in all things) is that they
>>> speak to not delilver anymore addresses without numbers. You
>>> see ? If we were using geolocation (with a comment for more) in place of
>>> addresses I will not have this problems. We are still using
>>> old tools whereas we have already what is needed to do more.
>>>
>>>> As with anything you design to requirements, and try to make things
>>>> flexible but many-to-many relationships are not inherently
>>>> better in  any way than many-to-one relationships, they are just
>>>> different and  better for use in different situations.
>>>
>>> Yes I agree, I did not have thought enough about that. What do you think
>>> about the LocateMech idea ? Apart its name, would it be
>>> really useful in future or shall we stay with ContactMech only?
>>>
>>> One thing to note after this : an address may be used to contact but
>>> also only to locate (like for delivery). Same with a cell
>>> phone, when the police investigates... So maybe a ContacMech is enough,
>>> in OFBiz at least...
>>>
>>> Sorry for the long post, but you asked for thinking, I tried and finally
>>> find your 1st solution simple and clear :
>>> 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$
>>>
>>> BTW, what do yout think about my answer to BJ about different
>>> geolocation sources (yahoo, google, etc.) : a primary key field
>>> geoPositionSourceEnumId using a relation to Enumeration in
>>> TerrestrialPosition entity?
>>> And his proposition of 2 fields for GPS elevation (one that has the
>>> value and one the enumerates elevationUomId)
>>>
>>> Other ideas ?
>>>
>>> Jacques
>>> PS : a simpler solution in my case (delivery issue) is to choice myself
>>> a number, maybe 7777777 : can't be confused, easy to
>>> remember.... but not to write, mmmm... 777 could do it ! Deregulation...
>>> is that freedom ? GPS/Galileo is that future ? Will future
>>> be freedom ?
>>>
>>>> -David
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
> 
> 
> 
> 

Re: Latitude, Longitude in PostalAdress

[Jacques Le Roux <ja...@les7arts.com>]

Or vice versa. For me a geo point has more sense than an adress, it's physical (ok humans define what physical is and the rules ;o), 
an address is only a convenient  administrative thing (between parties). I mean that a goe point subsume an address (think about 
sea, 70% of the globe surface ;o)

Jacques

From: "BJ Freeman" <bj...@free-man.net>
> if I may.
> think of it this way
> an address is fixed, never moves
> and geopoint is the same
> now if the contact mech point to the address the the address will give
> the geopoint
> so you have a mechanism to find the geopoint, if just the address point
> to the geo point, in a view.
>
> so contact mech points to the address from the address you find the geopoint
>
>
>
> Jacques Le Roux sent the following on 8/7/2008 2:12 PM:
>> From: "David E Jones" <jo...@hotwaxmedia.com>
>>>
>>> On Aug 5, 2008, at 4:08 PM, Jacques Le Roux wrote:
>>>
>>>> From: "David E Jones" <jo...@hotwaxmedia.com>
>>>>>
>>>>> On Aug 5, 2008, at 2:37 PM, Jacques Le Roux wrote:
>>>>>
>>>>>> From: "David E Jones" <jo...@hotwaxmedia.com>
>>>>>>> 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.
>>>>>
>>>>> This is something we should maybe discuss more, ie whether the
>>>>> TerrestrialPosition should be a type of ContactMech or it's own
>>>>> independent thing. I was thinking the independence might be
>>>>> better,  and we would have more control over what it is attached
>>>>> to.
>>>>> In other  words, the use patterns and relationships to other
>>>>> entities are a  little different than what is done with
>>>>> ContactMechs.
>>>>>
>>>>> Still, if anyone thinks otherwise... please share.
>>>>
>>>> Actually what I said above is not true. The scope will not be wider.
>>>> You can get the same using the ContactMech pattern. It's
>>>> only a bit  harder since you have to create a specific entity (like
>>>> FacilityLocationContactMech) and make the association
>>>> between the 2  other entities each time you want to relate a new
>>>> entity (like say  FacilityLocation). In the second case only one
>>>> association to  TerrestrialPosition would be needed. So it's up to
>>>> you guys,  sometimes breaking the rules is good, sometimes
>>>> it's not, we have to  really think about it ... before...
>>>
>>> What do you mean by "break the rules"? I don't see any rules being
>>> broken here...
>>
>> Yes actually, I was just thinking about the EntityNameContactMech
>> pattern, not a rule indeed.
>> And because I wondered why we'd use this pattern in most other cases and
>> not for GPS Geolocation, I just reviewed how Len Silverston
>> suggests to deal with contact informations.
>> At this stage I must admit that things were not much more clear. As far
>> as I read Len speaks only about PartyContactMech and
>> FacilityContactMech, but it's easy to extrapolate more usages as it's
>> done in OFBiz.
>>
>> Now, please let me think loud. What is the difference between a postal
>> address and a GPS point ? Is there more differences between
>> them than between, say a telecom number and a postal address ?
>> Obviously telecom numbers and a postal addresses have something in
>> common that a GPS point does not share: they are mechanismes to
>> contact somebody (or something at large). A GPS point is only a mean to
>> locate somebody (or something at large), you can't contact a
>> GPS point. So yes, it makes sense to differntiate a GPS point from other
>> contact mech. A GPS point is not a contact mech as Len
>> Silverstion defines one. It's a mean to locate not to contact. So now I
>> better understant why you wanted things to point to it
>> rather than having it point to other things. I still wonder though if we
>> should not think a bit more about it. Putting a
>> terrestrialPositionId  in ContactMech does not make sense, as it's not a
>> mean to contact but locate. Should we not introduce
>> something else. Like a LocateMech, which could be maybe used for other
>> stuff in future ?
>>
>> Let me dream now (you are allowed to no read that :o) : I live in the
>> country (not so far from town, but country). And where I live
>> there is no numbers to the road. So it's hard to find me (I did not make
>> it purposely ;o). Sometimes it's cool, sometimes it's very
>> annoying. Like when you receive a CD from Amazon the 1st time (and even
>> after : deliverymen change). Sometimes it's even worse : the
>> French postal service, "La Poste", will change its status soon and will
>> become a private company (yes things are changing, even in
>> France). The bad side (there is always one in all things) is that they
>> speak to not delilver anymore addresses without numbers. You
>> see ? If we were using geolocation (with a comment for more) in place of
>> addresses I will not have this problems. We are still using
>> old tools whereas we have already what is needed to do more.
>>
>>> As with anything you design to requirements, and try to make things
>>> flexible but many-to-many relationships are not inherently
>>> better in  any way than many-to-one relationships, they are just
>>> different and  better for use in different situations.
>>
>> Yes I agree, I did not have thought enough about that. What do you think
>> about the LocateMech idea ? Apart its name, would it be
>> really useful in future or shall we stay with ContactMech only?
>>
>> One thing to note after this : an address may be used to contact but
>> also only to locate (like for delivery). Same with a cell
>> phone, when the police investigates... So maybe a ContacMech is enough,
>> in OFBiz at least...
>>
>> Sorry for the long post, but you asked for thinking, I tried and finally
>> find your 1st solution simple and clear :
>> 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$
>>
>> BTW, what do yout think about my answer to BJ about different
>> geolocation sources (yahoo, google, etc.) : a primary key field
>> geoPositionSourceEnumId using a relation to Enumeration in
>> TerrestrialPosition entity?
>> And his proposition of 2 fields for GPS elevation (one that has the
>> value and one the enumerates elevationUomId)
>>
>> Other ideas ?
>>
>> Jacques
>> PS : a simpler solution in my case (delivery issue) is to choice myself
>> a number, maybe 7777777 : can't be confused, easy to
>> remember.... but not to write, mmmm... 777 could do it ! Deregulation...
>> is that freedom ? GPS/Galileo is that future ? Will future
>> be freedom ?
>>
>>> -David
>>>
>>>
>>
>>
>>
>>
> 

Re: Latitude, Longitude in PostalAdress

[BJ Freeman <bj...@free-man.net>]

if I may.
think of it this way
an address is fixed, never moves
and geopoint is the same
now if the contact mech point to the address the the address will give
the geopoint
so you have a mechanism to find the geopoint, if just the address point
to the geo point, in a view.

so contact mech points to the address from the address you find the geopoint



Jacques Le Roux sent the following on 8/7/2008 2:12 PM:
> From: "David E Jones" <jo...@hotwaxmedia.com>
>>
>> On Aug 5, 2008, at 4:08 PM, Jacques Le Roux wrote:
>>
>>> From: "David E Jones" <jo...@hotwaxmedia.com>
>>>>
>>>> On Aug 5, 2008, at 2:37 PM, Jacques Le Roux wrote:
>>>>
>>>>> From: "David E Jones" <jo...@hotwaxmedia.com>
>>>>>> 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.
>>>>
>>>> This is something we should maybe discuss more, ie whether the  
>>>> TerrestrialPosition should be a type of ContactMech or it's own
>>>> independent thing. I was thinking the independence might be 
>>>> better,  and we would have more control over what it is attached
>>>> to.
>>>> In other  words, the use patterns and relationships to other 
>>>> entities are a  little different than what is done with
>>>> ContactMechs.
>>>>
>>>> Still, if anyone thinks otherwise... please share.
>>>
>>> Actually what I said above is not true. The scope will not be wider. 
>>> You can get the same using the ContactMech pattern. It's
>>> only a bit  harder since you have to create a specific entity (like 
>>> FacilityLocationContactMech) and make the association
>>> between the 2  other entities each time you want to relate a new
>>> entity (like say  FacilityLocation). In the second case only one
>>> association to  TerrestrialPosition would be needed. So it's up to
>>> you guys,  sometimes breaking the rules is good, sometimes
>>> it's not, we have to  really think about it ... before...
>>
>> What do you mean by "break the rules"? I don't see any rules being 
>> broken here...
> 
> Yes actually, I was just thinking about the EntityNameContactMech
> pattern, not a rule indeed.
> And because I wondered why we'd use this pattern in most other cases and
> not for GPS Geolocation, I just reviewed how Len Silverston
> suggests to deal with contact informations.
> At this stage I must admit that things were not much more clear. As far
> as I read Len speaks only about PartyContactMech and
> FacilityContactMech, but it's easy to extrapolate more usages as it's
> done in OFBiz.
> 
> Now, please let me think loud. What is the difference between a postal
> address and a GPS point ? Is there more differences between
> them than between, say a telecom number and a postal address ?
> Obviously telecom numbers and a postal addresses have something in
> common that a GPS point does not share: they are mechanismes to
> contact somebody (or something at large). A GPS point is only a mean to
> locate somebody (or something at large), you can't contact a
> GPS point. So yes, it makes sense to differntiate a GPS point from other
> contact mech. A GPS point is not a contact mech as Len
> Silverstion defines one. It's a mean to locate not to contact. So now I
> better understant why you wanted things to point to it
> rather than having it point to other things. I still wonder though if we
> should not think a bit more about it. Putting a
> terrestrialPositionId  in ContactMech does not make sense, as it's not a
> mean to contact but locate. Should we not introduce
> something else. Like a LocateMech, which could be maybe used for other
> stuff in future ?
> 
> Let me dream now (you are allowed to no read that :o) : I live in the
> country (not so far from town, but country). And where I live
> there is no numbers to the road. So it's hard to find me (I did not make
> it purposely ;o). Sometimes it's cool, sometimes it's very
> annoying. Like when you receive a CD from Amazon the 1st time (and even
> after : deliverymen change). Sometimes it's even worse : the
> French postal service, "La Poste", will change its status soon and will
> become a private company (yes things are changing, even in
> France). The bad side (there is always one in all things) is that they
> speak to not delilver anymore addresses without numbers. You
> see ? If we were using geolocation (with a comment for more) in place of
> addresses I will not have this problems. We are still using
> old tools whereas we have already what is needed to do more.
> 
>> As with anything you design to requirements, and try to make things 
>> flexible but many-to-many relationships are not inherently
>> better in  any way than many-to-one relationships, they are just
>> different and  better for use in different situations.
> 
> Yes I agree, I did not have thought enough about that. What do you think
> about the LocateMech idea ? Apart its name, would it be
> really useful in future or shall we stay with ContactMech only?
> 
> One thing to note after this : an address may be used to contact but
> also only to locate (like for delivery). Same with a cell
> phone, when the police investigates... So maybe a ContacMech is enough,
> in OFBiz at least...
> 
> Sorry for the long post, but you asked for thinking, I tried and finally
> find your 1st solution simple and clear :
> 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$
> 
> BTW, what do yout think about my answer to BJ about different
> geolocation sources (yahoo, google, etc.) : a primary key field
> geoPositionSourceEnumId using a relation to Enumeration in
> TerrestrialPosition entity?
> And his proposition of 2 fields for GPS elevation (one that has the
> value and one the enumerates elevationUomId)
> 
> Other ideas ?
> 
> Jacques
> PS : a simpler solution in my case (delivery issue) is to choice myself
> a number, maybe 7777777 : can't be confused, easy to
> remember.... but not to write, mmmm... 777 could do it ! Deregulation...
> is that freedom ? GPS/Galileo is that future ? Will future
> be freedom ?
> 
>> -David
>>
>>
> 
> 
> 
> 

Re: Latitude, Longitude in PostalAdress

[Jacques Le Roux <ja...@les7arts.com>]

From: "David E Jones" <jo...@hotwaxmedia.com>
>
> On Aug 5, 2008, at 4:08 PM, Jacques Le Roux wrote:
>
>> From: "David E Jones" <jo...@hotwaxmedia.com>
>>>
>>> On Aug 5, 2008, at 2:37 PM, Jacques Le Roux wrote:
>>>
>>>> From: "David E Jones" <jo...@hotwaxmedia.com>
>>>>> 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.
>>>
>>> This is something we should maybe discuss more, ie whether the   TerrestrialPosition should be a type of ContactMech or it's own
>>> independent thing. I was thinking the independence might be  better,  and we would have more control over what it is attached
>>> to.
>>> In other  words, the use patterns and relationships to other  entities are a  little different than what is done with
>>> ContactMechs.
>>>
>>> Still, if anyone thinks otherwise... please share.
>>
>> Actually what I said above is not true. The scope will not be wider.  You can get the same using the ContactMech pattern. It's
>> only a bit  harder since you have to create a specific entity (like  FacilityLocationContactMech) and make the association
>> between the 2  other entities each time you want to relate a new entity (like say  FacilityLocation). In the second case only one
>> association to  TerrestrialPosition would be needed. So it's up to you guys,  sometimes breaking the rules is good, sometimes
>> it's not, we have to  really think about it ... before...
>
> What do you mean by "break the rules"? I don't see any rules being  broken here...

Yes actually, I was just thinking about the EntityNameContactMech pattern, not a rule indeed.
And because I wondered why we'd use this pattern in most other cases and not for GPS Geolocation, I just reviewed how Len Silverston
suggests to deal with contact informations.
At this stage I must admit that things were not much more clear. As far as I read Len speaks only about PartyContactMech and
FacilityContactMech, but it's easy to extrapolate more usages as it's done in OFBiz.

Now, please let me think loud. What is the difference between a postal address and a GPS point ? Is there more differences between
them than between, say a telecom number and a postal address ?
Obviously telecom numbers and a postal addresses have something in common that a GPS point does not share: they are mechanismes to
contact somebody (or something at large). A GPS point is only a mean to locate somebody (or something at large), you can't contact a
GPS point. So yes, it makes sense to differntiate a GPS point from other contact mech. A GPS point is not a contact mech as Len
Silverstion defines one. It's a mean to locate not to contact. So now I better understant why you wanted things to point to it
rather than having it point to other things. I still wonder though if we should not think a bit more about it. Putting a
terrestrialPositionId  in ContactMech does not make sense, as it's not a mean to contact but locate. Should we not introduce
something else. Like a LocateMech, which could be maybe used for other stuff in future ?

Let me dream now (you are allowed to no read that :o) : I live in the country (not so far from town, but country). And where I live
there is no numbers to the road. So it's hard to find me (I did not make it purposely ;o). Sometimes it's cool, sometimes it's very
annoying. Like when you receive a CD from Amazon the 1st time (and even after : deliverymen change). Sometimes it's even worse : the
French postal service, "La Poste", will change its status soon and will become a private company (yes things are changing, even in
France). The bad side (there is always one in all things) is that they speak to not delilver anymore addresses without numbers. You
see ? If we were using geolocation (with a comment for more) in place of addresses I will not have this problems. We are still using
old tools whereas we have already what is needed to do more.

> As with anything you design to requirements, and try to make things  flexible but many-to-many relationships are not inherently
> better in  any way than many-to-one relationships, they are just different and  better for use in different situations.

Yes I agree, I did not have thought enough about that. What do you think about the LocateMech idea ? Apart its name, would it be
really useful in future or shall we stay with ContactMech only?

One thing to note after this : an address may be used to contact but also only to locate (like for delivery). Same with a cell
phone, when the police investigates... So maybe a ContacMech is enough, in OFBiz at least...

Sorry for the long post, but you asked for thinking, I tried and finally find your 1st solution simple and clear :
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$

BTW, what do yout think about my answer to BJ about different geolocation sources (yahoo, google, etc.) : a primary key field 
geoPositionSourceEnumId using a relation to Enumeration in TerrestrialPosition entity?
And his proposition of 2 fields for GPS elevation (one that has the value and one the enumerates elevationUomId)

Other ideas ?

Jacques
PS : a simpler solution in my case (delivery issue) is to choice myself a number, maybe 7777777 : can't be confused, easy to
remember.... but not to write, mmmm... 777 could do it ! Deregulation... is that freedom ? GPS/Galileo is that future ? Will future
be freedom ?

> -David
>
>

Re: Latitude, Longitude in PostalAdress

[David E Jones <jo...@hotwaxmedia.com>]

On Aug 5, 2008, at 4:08 PM, Jacques Le Roux wrote:

> From: "David E Jones" <jo...@hotwaxmedia.com>
>>
>> On Aug 5, 2008, at 2:37 PM, Jacques Le Roux wrote:
>>
>>> From: "David E Jones" <jo...@hotwaxmedia.com>
>>>> 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.
>>
>> This is something we should maybe discuss more, ie whether the   
>> TerrestrialPosition should be a type of ContactMech or it's own
>> independent thing. I was thinking the independence might be  
>> better,  and we would have more control over what it is attached to.
>> In other  words, the use patterns and relationships to other  
>> entities are a  little different than what is done with ContactMechs.
>>
>> Still, if anyone thinks otherwise... please share.
>
> Actually what I said above is not true. The scope will not be wider.  
> You can get the same using the ContactMech pattern. It's only a bit  
> harder since you have to create a specific entity (like  
> FacilityLocationContactMech) and make the association between the 2  
> other entities each time you want to relate a new entity (like say  
> FacilityLocation). In the second case only one association to  
> TerrestrialPosition would be needed. So it's up to you guys,  
> sometimes breaking the rules is good, sometimes it's not, we have to  
> really think about it ... before...

What do you mean by "break the rules"? I don't see any rules being  
broken here...

As with anything you design to requirements, and try to make things  
flexible but many-to-many relationships are not inherently better in  
any way than many-to-one relationships, they are just different and  
better for use in different situations.

-David

Re: Latitude, Longitude in PostalAdress

[Jacques Le Roux <ja...@les7arts.com>]

From: "David E Jones" <jo...@hotwaxmedia.com>
>
> On Aug 5, 2008, at 2:37 PM, Jacques Le Roux wrote:
>
>> From: "David E Jones" <jo...@hotwaxmedia.com>
>>> 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.
>
> This is something we should maybe discuss more, ie whether the  TerrestrialPosition should be a type of ContactMech or it's own
> independent thing. I was thinking the independence might be better,  and we would have more control over what it is attached to.
> In other  words, the use patterns and relationships to other entities are a  little different than what is done with ContactMechs.
>
> Still, if anyone thinks otherwise... please share.

Actually what I said above is not true. The scope will not be wider. You can get the same using the ContactMech pattern. It's only a 
bit harder since you have to create a specific entity (like FacilityLocationContactMech) and make the association between the 2 
other entities each time you want to relate a new entity (like say FacilityLocation). In the second case only one association to 
TerrestrialPosition would be needed. So it's up to you guys, sometimes breaking the rules is good, sometimes it's not, we have to 
really think about it ... before...

Jacques

Re: Latitude, Longitude in PostalAdress

[BJ Freeman <bj...@free-man.net>]

I like the idea of having association to the TerrestrialPosition
I believe it gives more flexibility.
that way the association carries both the entities IDs and save adding
pointers to other entities. having an enumerated type, in the
association would allow indexing.

David E Jones sent the following on 8/5/2008 2:46 PM:
> 
> On Aug 5, 2008, at 2:37 PM, Jacques Le Roux wrote:
> 
>> From: "David E Jones" <jo...@hotwaxmedia.com>
>>> 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.
> 
> This is something we should maybe discuss more, ie whether the
> TerrestrialPosition should be a type of ContactMech or it's own
> independent thing. I was thinking the independence might be better, and
> we would have more control over what it is attached to. In other words,
> the use patterns and relationships to other entities are a little
> different than what is done with ContactMechs.
> 
> Still, if anyone thinks otherwise... please share.
> 
> -David
> 
> 
> 
> 

Re: Latitude, Longitude in PostalAdress

[David E Jones <jo...@hotwaxmedia.com>]

On Aug 5, 2008, at 2:37 PM, Jacques Le Roux wrote:

> From: "David E Jones" <jo...@hotwaxmedia.com>
>> 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.

This is something we should maybe discuss more, ie whether the  
TerrestrialPosition should be a type of ContactMech or it's own  
independent thing. I was thinking the independence might be better,  
and we would have more control over what it is attached to. In other  
words, the use patterns and relationships to other entities are a  
little different than what is done with ContactMechs.

Still, if anyone thinks otherwise... please share.

-David

Re: Latitude, Longitude in PostalAdress

[Jacques Le Roux <ja...@les7arts.com>]

From: "David E Jones" <jo...@hotwaxmedia.com>
> 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" <ja...@les7arts.com>
>>> From: "David E Jones" <jo...@hotwaxmedia.com>
>>>>
>>>> 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 <jo...@hotwaxmedia.com> 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?
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>
>
> 

Re: Latitude, Longitude in PostalAdress

[BJ Freeman <bj...@free-man.net>]

geoPositionSourceEnumId sounds good.
making it a part of the PK is interesting, had not thought of that.
I guess to fields for GPS elevation, then
one that has the value and one the enumerates elevationUomId , like you
say. you looking at 0.0 meters to 7K meters

Jacques Le Roux sent the following on 8/5/2008 2:36 PM:
> From: "BJ Freeman" <bj...@free-man.net>
>> 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" <ja...@les7arts.com>
>>>>> From: "David E Jones" <jo...@hotwaxmedia.com>
>>>>>>
>>>>>> 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 <jo...@hotwaxmedia.com> 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?
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>>
> 
> 
> 
> 

Re: Latitude, Longitude in PostalAdress

[Jacques Le Roux <ja...@les7arts.com>]

From: "BJ Freeman" <bj...@free-man.net>
>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" <ja...@les7arts.com>
>>>> From: "David E Jones" <jo...@hotwaxmedia.com>
>>>>>
>>>>> 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 <jo...@hotwaxmedia.com> 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?
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>
>>
>>
>>
>
>
> 

Re: Latitude, Longitude in PostalAdress

[BJ Freeman <bj...@free-man.net>]

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" <ja...@les7arts.com>
>>> From: "David E Jones" <jo...@hotwaxmedia.com>
>>>>
>>>> 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 <jo...@hotwaxmedia.com> 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?
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>
> 
> 
> 
> 

Re: Latitude, Longitude in PostalAdress

[David E Jones <jo...@hotwaxmedia.com>]

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" <ja...@les7arts.com>
>> From: "David E Jones" <jo...@hotwaxmedia.com>
>>>
>>> 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 <jo...@hotwaxmedia.com> 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?
>>>>>
>>>>
>>>>
>>>
>>>
>

Re: Latitude, Longitude in PostalAdress

[Jacques Le Roux <ja...@les7arts.com>]

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" <ja...@les7arts.com>
> From: "David E Jones" <jo...@hotwaxmedia.com>
>>
>> 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 <jo...@hotwaxmedia.com> 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?
>>>>
>>>
>>>
>>
>>
> 

Re: Latitude, Longitude in PostalAdress

[Jacques Le Roux <ja...@les7arts.com>]

From: "David E Jones" <jo...@hotwaxmedia.com>
>
> 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 <jo...@hotwaxmedia.com> 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?
>>>
>>
>>
>
>

Re: Latitude, Longitude in PostalAdress

[Chris Howe <cj...@yahoo.com>]

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 <jo...@hotwaxmedia.com> 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?
>>
>
>

Re: Latitude, Longitude in PostalAdress

[David E Jones <jo...@hotwaxmedia.com>]

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 <jo...@hotwaxmedia.com> 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?
>>
>
>

Re: Latitude, Longitude in PostalAdress

[Chris Howe <cj...@yahoo.com>]

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 <jo...@hotwaxmedia.com> 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?
>

Re: Latitude, Longitude in PostalAdress

[David E Jones <jo...@hotwaxmedia.com>]

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 <cj...@yahoo.com> 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?
>

Re: Latitude, Longitude in PostalAdress

[Chris Howe <cj...@yahoo.com>]

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

Chris Howe <cj...@yahoo.com> 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?

Re: Latitude, Longitude in PostalAdress

[Chris Howe <cj...@yahoo.com>]

Roland <ro...@redvision.de> 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?

Re: Latitude, Longitude in PostalAdress

[Roland <ro...@redvision.de>]

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" <ja...@les7arts.com>
> >>>
> >>>> Thanks Rob,
> >>>>
> >>>> This is an interesting information, I'm just discovering Google
> >>>> Map API and related...
> >>>>
> >>>> Jacques
> >>>>
> >>>> From: "Rob Schapper" <ro...@hotwaxmedia.com>
> >>>>
> >>>>> 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" <cj...@yahoo.com>
> >>>>>>
> >>>>>>> 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 <ja...@les7arts.com> 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

Re: Latitude, Longitude in PostalAdress

[BJ Freeman <bj...@free-man.net>]

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" <ja...@les7arts.com>
>>>>>> Thanks Rob,
>>>>>>
>>>>>> This is an interesting information, I'm just discovering Google Map
>>>>>> API and related...
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>> From: "Rob Schapper" <ro...@hotwaxmedia.com>
>>>>>>> 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" <cj...@yahoo.com>
>>>>>>>>> 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 <ja...@les7arts.com> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>
>>
>>
> 
> 
> 
> 

Re: Latitude, Longitude in PostalAdress

[BJ Freeman <bj...@free-man.net>]

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" <ja...@les7arts.com>
>>>>> Thanks Rob,
>>>>>
>>>>> This is an interesting information, I'm just discovering Google Map
>>>>> API and related...
>>>>>
>>>>> Jacques
>>>>>
>>>>> From: "Rob Schapper" <ro...@hotwaxmedia.com>
>>>>>> 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" <cj...@yahoo.com>
>>>>>>>> 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 <ja...@les7arts.com> 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
> 
> 
> 
> 

Re: Latitude, Longitude in PostalAdress

[Chris Howe <cj...@yahoo.com>]

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 <ja...@les7arts.com> 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>
>
> 

Re: Latitude, Longitude in PostalAdress

[Jacques Le Roux <ja...@les7arts.com>]

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" <cj...@yahoo.com>
>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 <jo...@hotwaxmedia.com> 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>
>
> 

Re: Latitude, Longitude in PostalAdress

[BJ Freeman <bj...@free-man.net>]

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 <jo...@hotwaxmedia.com> 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
>>>>>>>>
>>>>>>>>
>>>>>>
> 
> 
> 

Re: Latitude, Longitude in PostalAdress

[Chris Howe <cj...@yahoo.com>]

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 <cj...@yahoo.com> 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>
>

Re: Latitude, Longitude in PostalAdress

[Chris Howe <cj...@yahoo.com>]

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 <jo...@hotwaxmedia.com> 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>
>

Re: Latitude, Longitude in PostalAdress

[David E Jones <jo...@hotwaxmedia.com>]

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 <jo...@hotwaxmedia.com> 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>
>

Re: Latitude, Longitude in PostalAdress

[Chris Howe <cj...@yahoo.com>]

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 <jo...@hotwaxmedia.com> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>
>