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
