Latitude, Longitude in PostalAdress

[David E Jones]

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

> From: "David E Jones" <[hidden email]>
>> It might be better to have an independent ID for the  
>> TerrestrialPosition (like terrestrialPositionId) and have things  
>> point  to it rather than having it point to other things. In other  
>> words we  would add a terrestrialPositionId to the ContactMech  
>> instead of putting a contactMechId on TerrestrialPosition. In that  
>> way anything  could point to it.
>
> Yes and this is even simpler. I followed the PartyContactMech  
> pattern because I thought it was a best practise. But obviously like  
> that the scope will be wider.

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

[BJ Freeman]

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

[Jacques Le Roux]

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

>
> On Aug 5, 2008, at 2:37 PM, Jacques Le Roux wrote:
>
>> From: "David E Jones" <[hidden email]>
>>> It might be better to have an independent ID for the   TerrestrialPosition (like terrestrialPositionId) and have things  point
>>> to it rather than having it point to other things. In other  words we  would add a terrestrialPositionId to the ContactMech
>>> instead of putting a contactMechId on TerrestrialPosition. In that  way anything  could point to it.
>>
>> Yes and this is even simpler. I followed the PartyContactMech  pattern because I thought it was a best practise. But obviously
>> like  that the scope will be wider.
>
> 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

[BJ Freeman]

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" <[hidden email]>
>>> It might be better to have an independent ID for the
>>> TerrestrialPosition (like terrestrialPositionId) and have things
>>> point  to it rather than having it point to other things. In other
>>> words we  would add a terrestrialPositionId to the ContactMech
>>> instead of putting a contactMechId on TerrestrialPosition. In that
>>> way anything  could point to it.
>>
>> Yes and this is even simpler. I followed the PartyContactMech pattern
>> because I thought it was a best practise. But obviously like that the
>> scope will be wider.
>
> 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
>
>
>
>

[David E Jones]

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

> From: "David E Jones" <[hidden email]>
>>
>> On Aug 5, 2008, at 2:37 PM, Jacques Le Roux wrote:
>>
>>> From: "David E Jones" <[hidden email]>
>>>> It might be better to have an independent ID for the    
>>>> TerrestrialPosition (like terrestrialPositionId) and have things  
>>>> point
>>>> to it rather than having it point to other things. In other  
>>>> words we  would add a terrestrialPositionId to the ContactMech
>>>> instead of putting a contactMechId on TerrestrialPosition. In  
>>>> that  way anything  could point to it.
>>>
>>> Yes and this is even simpler. I followed the PartyContactMech  
>>> pattern because I thought it was a best practise. But obviously
>>> like  that the scope will be wider.
>>
>> 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

[Jacques Le Roux]

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

>
> On Aug 5, 2008, at 4:08 PM, Jacques Le Roux wrote:
>
>> From: "David E Jones" <[hidden email]>
>>>
>>> On Aug 5, 2008, at 2:37 PM, Jacques Le Roux wrote:
>>>
>>>> From: "David E Jones" <[hidden email]>
>>>>> It might be better to have an independent ID for the    TerrestrialPosition (like terrestrialPositionId) and have things
>>>>> point
>>>>> to it rather than having it point to other things. In other   words we  would add a terrestrialPositionId to the ContactMech
>>>>> instead of putting a contactMechId on TerrestrialPosition. In  that  way anything  could point to it.
>>>>
>>>> Yes and this is even simpler. I followed the PartyContactMech   pattern because I thought it was a best practise. But obviously
>>>> like  that the scope will be wider.
>>>
>>> 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
>
>

[BJ Freeman]

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" <[hidden email]>
>>
>> On Aug 5, 2008, at 4:08 PM, Jacques Le Roux wrote:
>>
>>> From: "David E Jones" <[hidden email]>
>>>>
>>>> On Aug 5, 2008, at 2:37 PM, Jacques Le Roux wrote:
>>>>
>>>>> From: "David E Jones" <[hidden email]>
>>>>>> It might be better to have an independent ID for the  
>>>>>> TerrestrialPosition (like terrestrialPositionId) and have things
>>>>>> point
>>>>>> to it rather than having it point to other things. In other  
>>>>>> words we  would add a terrestrialPositionId to the ContactMech
>>>>>> instead of putting a contactMechId on TerrestrialPosition. In
>>>>>> that  way anything  could point to it.
>>>>>
>>>>> Yes and this is even simpler. I followed the PartyContactMech  
>>>>> pattern because I thought it was a best practise. But obviously
>>>>> like  that the scope will be wider.
>>>>
>>>> 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
>>
>>
>
>
>
>

[Adrian Crum]

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

[BJ Freeman]

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

[David E Jones]

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

[David E Jones]

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

> From: "David E Jones" <[hidden email]>
>> 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

[Jacques Le Roux]

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

> 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" <[hidden email]>
>>>
>>> On Aug 5, 2008, at 4:08 PM, Jacques Le Roux wrote:
>>>
>>>> From: "David E Jones" <[hidden email]>
>>>>>
>>>>> On Aug 5, 2008, at 2:37 PM, Jacques Le Roux wrote:
>>>>>
>>>>>> From: "David E Jones" <[hidden email]>
>>>>>>> It might be better to have an independent ID for the
>>>>>>> TerrestrialPosition (like terrestrialPositionId) and have things
>>>>>>> point
>>>>>>> to it rather than having it point to other things. In other
>>>>>>> words we  would add a terrestrialPositionId to the ContactMech
>>>>>>> instead of putting a contactMechId on TerrestrialPosition. In
>>>>>>> that  way anything  could point to it.
>>>>>>
>>>>>> Yes and this is even simpler. I followed the PartyContactMech
>>>>>> pattern because I thought it was a best practise. But obviously
>>>>>> like  that the scope will be wider.
>>>>>
>>>>> 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
>>>
>>>
>>
>>
>>
>>
>

[BJ Freeman]

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" <[hidden email]>
>> 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" <[hidden email]>
>>>>
>>>> On Aug 5, 2008, at 4:08 PM, Jacques Le Roux wrote:
>>>>
>>>>> From: "David E Jones" <[hidden email]>
>>>>>>
>>>>>> On Aug 5, 2008, at 2:37 PM, Jacques Le Roux wrote:
>>>>>>
>>>>>>> From: "David E Jones" <[hidden email]>
>>>>>>>> It might be better to have an independent ID for the
>>>>>>>> TerrestrialPosition (like terrestrialPositionId) and have things
>>>>>>>> point
>>>>>>>> to it rather than having it point to other things. In other
>>>>>>>> words we  would add a terrestrialPositionId to the ContactMech
>>>>>>>> instead of putting a contactMechId on TerrestrialPosition. In
>>>>>>>> that  way anything  could point to it.
>>>>>>>
>>>>>>> Yes and this is even simpler. I followed the PartyContactMech
>>>>>>> pattern because I thought it was a best practise. But obviously
>>>>>>> like  that the scope will be wider.
>>>>>>
>>>>>> 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
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>
>
>
>

[Adrian Crum]

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

[David E Jones]

On Fri, 08 Aug 2008 07:44:08 -0700, Adrian Crum <[hidden email]> 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

[Adrian Crum]

David Jones wrote:

>
> On Fri, 08 Aug 2008 07:44:08 -0700, Adrian Crum <[hidden email]> 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

[Jacques Le Roux]

From: "Adrian Crum" <[hidden email]>

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

[Jacques Le Roux]

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

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

[BJ Freeman]

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

[Jacques Le Roux]

From: "Adrian Crum" <[hidden email]>

> David Jones wrote:
>>
>> On Fri, 08 Aug 2008 07:44:08 -0700, Adrian Crum <[hidden email]> 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
>