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
