--- On Sat, 8/9/08, David E Jones <[EMAIL PROTECTED]> wrote:
> From: David E Jones <[EMAIL PROTECTED]>
> Subject: Re: Latitude, Longitude in PostalAdress
> To: [email protected]
> Date: Saturday, August 9, 2008, 11:27 AM
> 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:
>
> 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)
>
> 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)
>
> 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
Are you sure about linking GeoPoint to FixedAsset? Wouldn't it be better to
link GeoPoint to the facility where the fixed asset is located?
-Adrian
