From: "David E Jones" <[EMAIL PROTECTED]>
On Aug 8, 2008, at 3:33 PM, Jacques Le Roux wrote:
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
Based on this and some other messages (lots of stuff getting thrown
around), a proposal:
Pretty neat !
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)
I just want to add
. float precision : 6 decimals (but we are all ok about that anyway)
. Elevation as requested by BJ
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)
I will add
Container (not sure, as I don't know what it's used for exactly, on
trucks, railways, boats ?)
FacilityLocation
By the way what about location in warehouse ? Should we not give
attention to that (areaId, aisleId, sectionId, levelId - yes BJ
with elevation -, positionId )
NOTE: maybe we miss some other entities here, please check
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
I was asking myself why a Party would need a geoPoint ? Why not use
her/his/its PostalAddress to related to a GeoPoint ? Of course,
if you would like to be able to know where a Person is in, for instance,
her/his car you will need that... SFA might need that, yes
defintively ! Same for FixedAsset [boats, trucks, etc. ], containers, etc.
If everybody is ok I will create a patch for review soon.
Jacques
-David
