Latitude, Longitude in PostalAdress

[Jacques Le Roux]

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

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

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

[Jacques Le Roux]

From: "BJ Freeman" <[hidden email]>
> 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" <[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
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>
>

[Adrian Crum]

Jacques Le Roux wrote:

> 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

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

[Jacques Le Roux]

----- Original Message -----
From: "Jacques Le Roux" <[hidden email]>
To: <[hidden email]>
Sent: Friday, August 08, 2008 11:24 PM
Subject: Re: Latitude, Longitude in PostalAdress

> From: "BJ Freeman" <[hidden email]>
>> 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

Sorry should have been
PostalAddress.contactMechId -> ContacMech -> ContacMech.terrestialPositionId -> TerrestialPosition

Jacques

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

so when someone else puts in the same address will they point to the
same address or will a new record be added?

Jacques Le Roux sent the following on 8/8/2008 2:33 PM:

>
> ----- Original Message ----- From: "Jacques Le Roux"
> <[hidden email]>
> To: <[hidden email]>
> Sent: Friday, August 08, 2008 11:24 PM
> Subject: Re: Latitude, Longitude in PostalAdress
>
>
>> From: "BJ Freeman" <[hidden email]>
>>> 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
>
> Sorry should have been PostalAddress.contactMechId -> ContacMech ->
> ContacMech.terrestialPositionId -> TerrestialPosition
>
> Jacques
>
>> 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" <[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]>

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

[Jacques Le Roux]

To answer you question you have only to have a look at the PostalAddress definition
There are specific fields there like toName and attnName which can't shared. A PostalAddress is only an administrative mean to
contact, not to locate

Jacques

From: "BJ Freeman" <[hidden email]>

> so when someone else puts in the same address will they point to the
> same address or will a new record be added?
>
> Jacques Le Roux sent the following on 8/8/2008 2:33 PM:
>>
>> ----- Original Message ----- From: "Jacques Le Roux"
>> <[hidden email]>
>> To: <[hidden email]>
>> Sent: Friday, August 08, 2008 11:24 PM
>> Subject: Re: Latitude, Longitude in PostalAdress
>>
>>
>>> From: "BJ Freeman" <[hidden email]>
>>>> 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
>>
>> Sorry should have been PostalAddress.contactMechId -> ContacMech ->
>> ContacMech.terrestialPositionId -> TerrestialPosition
>>
>> Jacques
>>
>>> 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" <[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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>

[Jacopo Cappellato-3]

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

[BJ Freeman]

ah, well I am working a plan to remove toname and attnname.
if you read the data books it was not laid out that way.
my concept was
                              contactMechtoPostalAddressAssoce
postal addresss -------------->postaladdressid
                               ContactMechID  <------------contact Mech
the toname and attentent name would become part of the contact mech
types with those types using the same relationship.
so one postal address is in the database.
Just like in the real world that is just one address, or location.



Jacques Le Roux sent the following on 8/9/2008 12:56 AM:

> To answer you question you have only to have a look at the PostalAddress
> definition
> There are specific fields there like toName and attnName which can't
> shared. A PostalAddress is only an administrative mean to contact, not
> to locate
>
> Jacques
>
> From: "BJ Freeman" <[hidden email]>
>> so when someone else puts in the same address will they point to the
>> same address or will a new record be added?
>>
>> Jacques Le Roux sent the following on 8/8/2008 2:33 PM:
>>>
>>> ----- Original Message ----- From: "Jacques Le Roux"
>>> <[hidden email]>
>>> To: <[hidden email]>
>>> Sent: Friday, August 08, 2008 11:24 PM
>>> Subject: Re: Latitude, Longitude in PostalAdress
>>>
>>>
>>>> From: "BJ Freeman" <[hidden email]>
>>>>> 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
>>>
>>> Sorry should have been PostalAddress.contactMechId -> ContacMech ->
>>> ContacMech.terrestialPositionId -> TerrestialPosition
>>>
>>> Jacques
>>>
>>>> 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" <[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]

I agree that addresses should not be specific to a party and could be shared. Let see what other think. There may be a good reason
it's build like that... It introduces some redundancy but maybe save programming efforts...

Jacques

From: "BJ Freeman" <[hidden email]>

> ah, well I am working a plan to remove toname and attnname.
> if you read the data books it was not laid out that way.
> my concept was
>                              contactMechtoPostalAddressAssoce
> postal addresss -------------->postaladdressid
>                               ContactMechID  <------------contact Mech
> the toname and attentent name would become part of the contact mech
> types with those types using the same relationship.
> so one postal address is in the database.
> Just like in the real world that is just one address, or location.
>
>
>
> Jacques Le Roux sent the following on 8/9/2008 12:56 AM:
>> To answer you question you have only to have a look at the PostalAddress
>> definition
>> There are specific fields there like toName and attnName which can't
>> shared. A PostalAddress is only an administrative mean to contact, not
>> to locate
>>
>> Jacques
>>
>> From: "BJ Freeman" <[hidden email]>
>>> so when someone else puts in the same address will they point to the
>>> same address or will a new record be added?
>>>
>>> Jacques Le Roux sent the following on 8/8/2008 2:33 PM:
>>>>
>>>> ----- Original Message ----- From: "Jacques Le Roux"
>>>> <[hidden email]>
>>>> To: <[hidden email]>
>>>> Sent: Friday, August 08, 2008 11:24 PM
>>>> Subject: Re: Latitude, Longitude in PostalAdress
>>>>
>>>>
>>>>> From: "BJ Freeman" <[hidden email]>
>>>>>> 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
>>>>
>>>> Sorry should have been PostalAddress.contactMechId -> ContacMech ->
>>>> ContacMech.terrestialPositionId -> TerrestialPosition
>>>>
>>>> Jacques
>>>>
>>>>> 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" <[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]

to complete my thoughts
                                 TerrestialPositiontoPostalAddress
TerrestialPosition ------------> TerrestialPositionID
                                 PostalAddressID      <--PostalAddress

and
                                 TerrestialPositiontoContactMech
TerrestialPosition ------------> TerrestialPositionID
                                 ContactMechID      <--ContactMech
so if you have a contactMech with type Postal address you know to look
for the TerrestialPositiontoPostalAddress to get the TerrestialPosition

however if the type was anyother, you can just use
TerrestialPositiontoContactMech



BJ Freeman sent the following on 8/9/2008 2:59 AM:

> ah, well I am working a plan to remove toname and attnname.
> if you read the data books it was not laid out that way.
> my concept was
>                               contactMechtoPostalAddressAssoce
> postal addresss -------------->postaladdressid
>                                ContactMechID  <------------contact Mech
> the toname and attentent name would become part of the contact mech
> types with those types using the same relationship.
> so one postal address is in the database.
> Just like in the real world that is just one address, or location.
>
>
>
> Jacques Le Roux sent the following on 8/9/2008 12:56 AM:
>> To answer you question you have only to have a look at the PostalAddress
>> definition
>> There are specific fields there like toName and attnName which can't
>> shared. A PostalAddress is only an administrative mean to contact, not
>> to locate
>>
>> Jacques
>>
>> From: "BJ Freeman" <[hidden email]>
>>> so when someone else puts in the same address will they point to the
>>> same address or will a new record be added?
>>>
>>> Jacques Le Roux sent the following on 8/8/2008 2:33 PM:
>>>> ----- Original Message ----- From: "Jacques Le Roux"
>>>> <[hidden email]>
>>>> To: <[hidden email]>
>>>> Sent: Friday, August 08, 2008 11:24 PM
>>>> Subject: Re: Latitude, Longitude in PostalAdress
>>>>
>>>>
>>>>> From: "BJ Freeman" <[hidden email]>
>>>>>> 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
>>>> Sorry should have been PostalAddress.contactMechId -> ContacMech ->
>>>> ContacMech.terrestialPositionId -> TerrestialPosition
>>>>
>>>> Jacques
>>>>
>>>>> 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" <[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]

Yes it save a lot of programming. mostly in matching the stored address
with the with the user input.
that is part of the change plan to to implement that.
the stored postal address, would be already postoffice formatted for the
country. so the matching algorithm for the user input and the screen to
do this is more complicated, but will worth the effort making sure there
is a usable address in the system.


Jacques Le Roux sent the following on 8/9/2008 3:22 AM:

> I agree that addresses should not be specific to a party and could be
> shared. Let see what other think. There may be a good reason it's build
> like that... It introduces some redundancy but maybe save programming
> efforts...
>
> Jacques
>
> From: "BJ Freeman" <[hidden email]>
>> ah, well I am working a plan to remove toname and attnname.
>> if you read the data books it was not laid out that way.
>> my concept was
>>                              contactMechtoPostalAddressAssoce
>> postal addresss -------------->postaladdressid
>>                               ContactMechID  <------------contact Mech
>> the toname and attentent name would become part of the contact mech
>> types with those types using the same relationship.
>> so one postal address is in the database.
>> Just like in the real world that is just one address, or location.
>>
>>
>>
>> Jacques Le Roux sent the following on 8/9/2008 12:56 AM:
>>> To answer you question you have only to have a look at the PostalAddress
>>> definition
>>> There are specific fields there like toName and attnName which can't
>>> shared. A PostalAddress is only an administrative mean to contact, not
>>> to locate
>>>
>>> Jacques
>>>
>>> From: "BJ Freeman" <[hidden email]>
>>>> so when someone else puts in the same address will they point to the
>>>> same address or will a new record be added?
>>>>
>>>> Jacques Le Roux sent the following on 8/8/2008 2:33 PM:
>>>>>
>>>>> ----- Original Message ----- From: "Jacques Le Roux"
>>>>> <[hidden email]>
>>>>> To: <[hidden email]>
>>>>> Sent: Friday, August 08, 2008 11:24 PM
>>>>> Subject: Re: Latitude, Longitude in PostalAdress
>>>>>
>>>>>
>>>>>> From: "BJ Freeman" <[hidden email]>
>>>>>>> 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
>>>>>
>>>>> Sorry should have been PostalAddress.contactMechId -> ContacMech ->
>>>>> ContacMech.terrestialPositionId -> TerrestialPosition
>>>>>
>>>>> Jacques
>>>>>
>>>>>> 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" <[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: "BJ Freeman" <[hidden email]>
> Yes it save a lot of programming. mostly in matching the stored address
> with the with the user input.
> that is part of the change plan to to implement that.
> the stored postal address, would be already postoffice formatted for the
> country. so the matching algorithm for the user input and the screen to
> do this is more complicated, but will worth the effort making sure there
> is a usable address in the system.

This is interesting. I think we will look forward for a Jira with patch(es). I write patch(es) because if it's a large piece of code
it is worth to split it in patches.
For instance at least data model and code separated. Maybe more separation between code from functionnalities, etc.

Jacques

>
> Jacques Le Roux sent the following on 8/9/2008 3:22 AM:
>> I agree that addresses should not be specific to a party and could be
>> shared. Let see what other think. There may be a good reason it's build
>> like that... It introduces some redundancy but maybe save programming
>> efforts...
>>
>> Jacques
>>
>> From: "BJ Freeman" <[hidden email]>
>>> ah, well I am working a plan to remove toname and attnname.
>>> if you read the data books it was not laid out that way.
>>> my concept was
>>>                              contactMechtoPostalAddressAssoce
>>> postal addresss -------------->postaladdressid
>>>                               ContactMechID  <------------contact Mech
>>> the toname and attentent name would become part of the contact mech
>>> types with those types using the same relationship.
>>> so one postal address is in the database.
>>> Just like in the real world that is just one address, or location.
>>>
>>>
>>>
>>> Jacques Le Roux sent the following on 8/9/2008 12:56 AM:
>>>> To answer you question you have only to have a look at the PostalAddress
>>>> definition
>>>> There are specific fields there like toName and attnName which can't
>>>> shared. A PostalAddress is only an administrative mean to contact, not
>>>> to locate
>>>>
>>>> Jacques
>>>>
>>>> From: "BJ Freeman" <[hidden email]>
>>>>> so when someone else puts in the same address will they point to the
>>>>> same address or will a new record be added?
>>>>>
>>>>> Jacques Le Roux sent the following on 8/8/2008 2:33 PM:
>>>>>>
>>>>>> ----- Original Message ----- From: "Jacques Le Roux"
>>>>>> <[hidden email]>
>>>>>> To: <[hidden email]>
>>>>>> Sent: Friday, August 08, 2008 11:24 PM
>>>>>> Subject: Re: Latitude, Longitude in PostalAdress
>>>>>>
>>>>>>
>>>>>>> From: "BJ Freeman" <[hidden email]>
>>>>>>>> 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
>>>>>>
>>>>>> Sorry should have been PostalAddress.contactMechId -> ContacMech ->
>>>>>> ContacMech.terrestialPositionId -> TerrestialPosition
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>> 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" <[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]

BJ,

Could you please use the convention for Entity and field like Entity.field to describe your plan (like I corrected myself below) ?
It's hard to be sure of what you mean from your "diagram".
I guess you want to add 2 new entities TerrestialPositiontoPostalAddress and  TerrestialPositiontoContactMech. But I think we don't
need them. We have enough information in my proposition and should deal your concern in code.

Jacques

From: "BJ Freeman" <[hidden email]>

> to complete my thoughts
>                                 TerrestialPositiontoPostalAddress
> TerrestialPosition ------------> TerrestialPositionID
>                                 PostalAddressID      <--PostalAddress
>
> and
>                                 TerrestialPositiontoContactMech
> TerrestialPosition ------------> TerrestialPositionID
>                                 ContactMechID      <--ContactMech
> so if you have a contactMech with type Postal address you know to look
> for the TerrestialPositiontoPostalAddress to get the TerrestialPosition
>
> however if the type was anyother, you can just use
> TerrestialPositiontoContactMech
>
>
>
> BJ Freeman sent the following on 8/9/2008 2:59 AM:
>> ah, well I am working a plan to remove toname and attnname.
>> if you read the data books it was not laid out that way.
>> my concept was
>>                               contactMechtoPostalAddressAssoce
>> postal addresss -------------->postaladdressid
>>                                ContactMechID  <------------contact Mech
>> the toname and attentent name would become part of the contact mech
>> types with those types using the same relationship.
>> so one postal address is in the database.
>> Just like in the real world that is just one address, or location.
>>
>>
>>
>> Jacques Le Roux sent the following on 8/9/2008 12:56 AM:
>>> To answer you question you have only to have a look at the PostalAddress
>>> definition
>>> There are specific fields there like toName and attnName which can't
>>> shared. A PostalAddress is only an administrative mean to contact, not
>>> to locate
>>>
>>> Jacques
>>>
>>> From: "BJ Freeman" <[hidden email]>
>>>> so when someone else puts in the same address will they point to the
>>>> same address or will a new record be added?
>>>>
>>>> Jacques Le Roux sent the following on 8/8/2008 2:33 PM:
>>>>> ----- Original Message ----- From: "Jacques Le Roux"
>>>>> <[hidden email]>
>>>>> To: <[hidden email]>
>>>>> Sent: Friday, August 08, 2008 11:24 PM
>>>>> Subject: Re: Latitude, Longitude in PostalAdress
>>>>>
>>>>>
>>>>>> From: "BJ Freeman" <[hidden email]>
>>>>>>> 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
>>>>> Sorry should have been PostalAddress.contactMechId -> ContacMech ->
>>>>> ContacMech.terrestialPositionId -> TerrestialPosition
>>>>>
>>>>> Jacques
>>>>>
>>>>>> 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" <[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]

I have not written much on the wiki yet because is very complicated.
however part of the proposal is the stages and sequence to get this done
so people that have data already in use will not suffer.
in the light
yes there will be a series of patches probably under different task in
the same jira.
http://docs.ofbiz.org/display/OFBIZ/Address+Schema+Change+Proposal


Jacques Le Roux sent the following on 8/9/2008 10:26 AM:

> From: "BJ Freeman" <[hidden email]>
>> Yes it save a lot of programming. mostly in matching the stored address
>> with the with the user input.
>> that is part of the change plan to to implement that.
>> the stored postal address, would be already postoffice formatted for the
>> country. so the matching algorithm for the user input and the screen to
>> do this is more complicated, but will worth the effort making sure there
>> is a usable address in the system.
>
> This is interesting. I think we will look forward for a Jira with
> patch(es). I write patch(es) because if it's a large piece of code it is
> worth to split it in patches.
> For instance at least data model and code separated. Maybe more
> separation between code from functionnalities, etc.
>
> Jacques
>
>>
>> Jacques Le Roux sent the following on 8/9/2008 3:22 AM:
>>> I agree that addresses should not be specific to a party and could be
>>> shared. Let see what other think. There may be a good reason it's build
>>> like that... It introduces some redundancy but maybe save programming
>>> efforts...
>>>
>>> Jacques
>>>
>>> From: "BJ Freeman" <[hidden email]>
>>>> ah, well I am working a plan to remove toname and attnname.
>>>> if you read the data books it was not laid out that way.
>>>> my concept was
>>>>                              contactMechtoPostalAddressAssoce
>>>> postal addresss -------------->postaladdressid
>>>>                               ContactMechID  <------------contact Mech
>>>> the toname and attentent name would become part of the contact mech
>>>> types with those types using the same relationship.
>>>> so one postal address is in the database.
>>>> Just like in the real world that is just one address, or location.
>>>>
>>>>
>>>>
>>>> Jacques Le Roux sent the following on 8/9/2008 12:56 AM:
>>>>> To answer you question you have only to have a look at the
>>>>> PostalAddress
>>>>> definition
>>>>> There are specific fields there like toName and attnName which can't
>>>>> shared. A PostalAddress is only an administrative mean to contact, not
>>>>> to locate
>>>>>
>>>>> Jacques
>>>>>
>>>>> From: "BJ Freeman" <[hidden email]>
>>>>>> so when someone else puts in the same address will they point to the
>>>>>> same address or will a new record be added?
>>>>>>
>>>>>> Jacques Le Roux sent the following on 8/8/2008 2:33 PM:
>>>>>>>
>>>>>>> ----- Original Message ----- From: "Jacques Le Roux"
>>>>>>> <[hidden email]>
>>>>>>> To: <[hidden email]>
>>>>>>> Sent: Friday, August 08, 2008 11:24 PM
>>>>>>> Subject: Re: Latitude, Longitude in PostalAdress
>>>>>>>
>>>>>>>
>>>>>>>> From: "BJ Freeman" <[hidden email]>
>>>>>>>>> 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
>>>>>>>
>>>>>>> Sorry should have been PostalAddress.contactMechId -> ContacMech ->
>>>>>>> ContacMech.terrestialPositionId -> TerrestialPosition
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>> 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" <[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]

sorry thought the diagram would infer the entities were associations.
probably should have named them TerrestialPositiontoPostalAddressAssoc
and TerrestialPositiontoContactMechAssoc. Yes they are new entities.
they are a way to connect TerrestialPosition and ContactMech
there would be no added ID's in TerrestialPosition or ContactMech
TerrestialPositiontoPostalAddress.TerrestialPositionID
TerrestialPositiontoPostalAddress.ContactMechID
would link TerrestialPosition and ContactMech together.
this removes the requirement to keep adding ID to TerrestialPosition
and other entities to connect them.
it gives a many to many, a one to many, or a many to one relationship.




Jacques Le Roux sent the following on 8/9/2008 10:31 AM:

> BJ,
>
> Could you please use the convention for Entity and field like
> Entity.field to describe your plan (like I corrected myself below) ?
> It's hard to be sure of what you mean from your "diagram".
> I guess you want to add 2 new entities TerrestialPositiontoPostalAddress
> and  TerrestialPositiontoContactMech. But I think we don't need them. We
> have enough information in my proposition and should deal your concern
> in code.
>
> Jacques
>
> From: "BJ Freeman" <[hidden email]>
>> to complete my thoughts
>>                                 TerrestialPositiontoPostalAddress
>> TerrestialPosition ------------> TerrestialPositionID
>>                                 PostalAddressID      <--PostalAddress
>>
>> and
>>                                 TerrestialPositiontoContactMech
>> TerrestialPosition ------------> TerrestialPositionID
>>                                 ContactMechID      <--ContactMech
>> so if you have a contactMech with type Postal address you know to look
>> for the TerrestialPositiontoPostalAddress to get the TerrestialPosition
>>
>> however if the type was anyother, you can just use
>> TerrestialPositiontoContactMech
>>
>>
>>
>> BJ Freeman sent the following on 8/9/2008 2:59 AM:
>>> ah, well I am working a plan to remove toname and attnname.
>>> if you read the data books it was not laid out that way.
>>> my concept was
>>>                               contactMechtoPostalAddressAssoce
>>> postal addresss -------------->postaladdressid
>>>                                ContactMechID  <------------contact Mech
>>> the toname and attentent name would become part of the contact mech
>>> types with those types using the same relationship.
>>> so one postal address is in the database.
>>> Just like in the real world that is just one address, or location.
>>>
>>>
>>>
>>> Jacques Le Roux sent the following on 8/9/2008 12:56 AM:
>>>> To answer you question you have only to have a look at the
>>>> PostalAddress
>>>> definition
>>>> There are specific fields there like toName and attnName which can't
>>>> shared. A PostalAddress is only an administrative mean to contact, not
>>>> to locate
>>>>
>>>> Jacques
>>>>
>>>> From: "BJ Freeman" <[hidden email]>
>>>>> so when someone else puts in the same address will they point to the
>>>>> same address or will a new record be added?
>>>>>
>>>>> Jacques Le Roux sent the following on 8/8/2008 2:33 PM:
>>>>>> ----- Original Message ----- From: "Jacques Le Roux"
>>>>>> <[hidden email]>
>>>>>> To: <[hidden email]>
>>>>>> Sent: Friday, August 08, 2008 11:24 PM
>>>>>> Subject: Re: Latitude, Longitude in PostalAdress
>>>>>>
>>>>>>
>>>>>>> From: "BJ Freeman" <[hidden email]>
>>>>>>>> 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
>>>>>> Sorry should have been PostalAddress.contactMechId -> ContacMech ->
>>>>>> ContacMech.terrestialPositionId -> TerrestialPosition
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>> 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" <[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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>
>
>
>

[David E Jones]

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

[David E Jones]

On Aug 8, 2008, at 3:33 PM, Jacques Le Roux wrote:

>> From: "BJ Freeman" <[hidden email]>
>>> 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
>
> Sorry should have been PostalAddress.contactMechId -> ContacMech ->  
> ContacMech.terrestialPositionId -> TerrestialPosition

Based on this and some other messages (lots of stuff getting thrown  
around), a proposal:

1. new entity called "GeoPoint" (to go along with Geo which is a  
geographic boundary) with geoPointId as a sequenced primary key,  
latitude and longitude floats, dataSourceId (just use the existing  
DataSource entity)

2. there is no need for Well-Known-Text on GeoPoint as it is more  
useful for describing a boundary, so let's put a wellKnownText field  
on Geo instead of GeoPoint

3. for other entities that are at a single position add a geoPointId  
to them; this would include Facility, PostalAddress (but NOT  
ContactMech because most ContactMechs don't imply any position, and  
even for PostalAddress it is only the case sometimes)

4. for entities that need a series or history of positions add a join  
entity with the other entity's ID, a geoPointId, fromDate, thruDate,  
etc; this would include FixedAsset, Party (applies to Person and  
sometimes to PartyGroup, though some PartyGroups have no corporeal  
form and so no location); for example add a FixedAssetGeoPoint entity  
with fixedAssetId, geoPointId, and fromDate as the primary key and  
thruDate as an additional field; note that it would go with in the  
FixedAsset entity's package and is FixedAssetGeoPoint and NOT  
GeoPointFixedAsset because the GeoPoint is the lower level entity and  
just used to further describe the FixedAsset

-David

[Adrian Crum-2]

--- On Sat, 8/9/08, David E Jones <[hidden email]> wrote:

> From: David E Jones <[hidden email]>
> Subject: Re: Latitude, Longitude in PostalAdress
> To: [hidden email]
> Date: Saturday, August 9, 2008, 11:27 AM
> On Aug 8, 2008, at 3:33 PM, Jacques Le Roux wrote:
>
> >> From: "BJ Freeman"
> <[hidden email]>
> >>> 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
> >
> > Sorry should have been PostalAddress.contactMechId
> -> ContacMech ->  
> > ContacMech.terrestialPositionId ->
> TerrestialPosition
>
> Based on this and some other messages (lots of stuff
> getting thrown  
> around), a proposal:
>
> 1. new entity called "GeoPoint" (to go along with
> Geo which is a  
> geographic boundary) with geoPointId as a sequenced primary
> key,  
> latitude and longitude floats, dataSourceId (just use the
> existing  
> DataSource entity)
>
> 2. there is no need for Well-Known-Text on GeoPoint as it
> is more  
> useful for describing a boundary, so let's put a
> wellKnownText field  
> on Geo instead of GeoPoint
>
> 3. for other entities that are at a single position add a
> geoPointId  
> to them; this would include Facility, PostalAddress (but
> NOT  
> ContactMech because most ContactMechs don't imply any
> position, and  
> even for PostalAddress it is only the case sometimes)
>
> 4. for entities that need a series or history of positions
> add a join  
> entity with the other entity's ID, a geoPointId,
> fromDate, thruDate,  
> etc; this would include FixedAsset, Party (applies to
> Person and  
> sometimes to PartyGroup, though some PartyGroups have no
> corporeal  
> form and so no location); for example add a
> FixedAssetGeoPoint entity  
> with fixedAssetId, geoPointId, and fromDate as the primary
> key and  
> thruDate as an additional field; note that it would go with
> in the  
> FixedAsset entity's package and is FixedAssetGeoPoint
> and NOT  
> GeoPointFixedAsset because the GeoPoint is the lower level
> entity and  
> just used to further describe the FixedAsset

Are you sure about linking GeoPoint to FixedAsset? Wouldn't it be better to link GeoPoint to the facility where the fixed asset is located?

-Adrian



     

[David E Jones]

On Aug 9, 2008, at 1:13 PM, Adrian Crum wrote:

> --- On Sat, 8/9/08, David E Jones <[hidden email]> wrote:
>> Based on this and some other messages (lots of stuff
>> getting thrown
>> around), a proposal:
>>
>> 1. new entity called "GeoPoint" (to go along with Geo which is a
>> geographic boundary) with geoPointId as a sequenced primary key,
>> latitude and longitude floats, dataSourceId (just use the existing
>> DataSource entity)
>>
>> 2. there is no need for Well-Known-Text on GeoPoint as it is more
>> useful for describing a boundary, so let's put a wellKnownText field
>> on Geo instead of GeoPoint
>>
>> 3. for other entities that are at a single position add a geoPointId
>> to them; this would include Facility, PostalAddress (but NOT
>> ContactMech because most ContactMechs don't imply any
>> position, and even for PostalAddress it is only the case sometimes)
>>
>> 4. for entities that need a series or history of positions add a join
>> entity with the other entity's ID, a geoPointId, fromDate, thruDate,
>> etc; this would include FixedAsset, Party (applies to Person and
>> sometimes to PartyGroup, though some PartyGroups have no corporeal
>> form and so no location); for example add a FixedAssetGeoPoint entity
>> with fixedAssetId, geoPointId, and fromDate as the primary key and
>> thruDate as an additional field; note that it would go with in the
>> FixedAsset entity's package and is FixedAssetGeoPoint and NOT
>> GeoPointFixedAsset because the GeoPoint is the lower level entity and
>> just used to further describe the FixedAsset
>
> Are you sure about linking GeoPoint to FixedAsset? Wouldn't it be  
> better to link GeoPoint to the facility where the fixed asset is  
> located?

What about FixedAssets that are not located in a Facility, like trucks  
or equipment being transported?

The main point is that Facilities are typically not mobile (though I  
suppose they could be... or maybe not) but FixedAssets usually are  
mobile and so need a history of locations (tracked using GeoPoints).

-David