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