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" <[EMAIL PROTECTED]>
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" <[EMAIL PROTECTED]>
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"
<[EMAIL PROTECTED]>
To: <dev@ofbiz.apache.org>
Sent: Friday, August 08, 2008 11:24 PM
Subject: Re: Latitude, Longitude in PostalAdress
From: "BJ Freeman" <[EMAIL PROTECTED]>
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" <[EMAIL PROTECTED]>
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
