From: "David E Jones" <[EMAIL PROTECTED]>
On Aug 7, 2008, at 3:12 PM, Jacques Le Roux wrote:
From: "David E Jones" <[EMAIL PROTECTED]>
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
