on a light side anything that a robot would need to know to get to and from something. :)
Jacques Le Roux sent the following on 8/10/2008 2:56 PM: > 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 >> >> > > > >
