Latitude, Longitude in PostalAdress

[Jacques Le Roux]

OK, thanks for the link, I will study...

Jacques

From: "BJ Freeman" <[hidden email]>

>I have not written much on the wiki yet because is very complicated.
> however part of the proposal is the stages and sequence to get this done
> so people that have data already in use will not suffer.
> in the light
> yes there will be a series of patches probably under different task in
> the same jira.
> http://docs.ofbiz.org/display/OFBIZ/Address+Schema+Change+Proposal
>
>
> Jacques Le Roux sent the following on 8/9/2008 10:26 AM:
>> From: "BJ Freeman" <[hidden email]>
>>> Yes it save a lot of programming. mostly in matching the stored address
>>> with the with the user input.
>>> that is part of the change plan to to implement that.
>>> the stored postal address, would be already postoffice formatted for the
>>> country. so the matching algorithm for the user input and the screen to
>>> do this is more complicated, but will worth the effort making sure there
>>> is a usable address in the system.
>>
>> This is interesting. I think we will look forward for a Jira with
>> patch(es). I write patch(es) because if it's a large piece of code it is
>> worth to split it in patches.
>> For instance at least data model and code separated. Maybe more
>> separation between code from functionnalities, etc.
>>
>> Jacques
>>
>>>
>>> Jacques Le Roux sent the following on 8/9/2008 3:22 AM:
>>>> I agree that addresses should not be specific to a party and could be
>>>> shared. Let see what other think. There may be a good reason it's build
>>>> like that... It introduces some redundancy but maybe save programming
>>>> efforts...
>>>>
>>>> Jacques
>>>>
>>>> From: "BJ Freeman" <[hidden email]>
>>>>> ah, well I am working a plan to remove toname and attnname.
>>>>> if you read the data books it was not laid out that way.
>>>>> my concept was
>>>>>                              contactMechtoPostalAddressAssoce
>>>>> postal addresss -------------->postaladdressid
>>>>>                               ContactMechID  <------------contact Mech
>>>>> the toname and attentent name would become part of the contact mech
>>>>> types with those types using the same relationship.
>>>>> so one postal address is in the database.
>>>>> Just like in the real world that is just one address, or location.
>>>>>
>>>>>
>>>>>
>>>>> Jacques Le Roux sent the following on 8/9/2008 12:56 AM:
>>>>>> To answer you question you have only to have a look at the
>>>>>> PostalAddress
>>>>>> definition
>>>>>> There are specific fields there like toName and attnName which can't
>>>>>> shared. A PostalAddress is only an administrative mean to contact, not
>>>>>> to locate
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>> From: "BJ Freeman" <[hidden email]>
>>>>>>> so when someone else puts in the same address will they point to the
>>>>>>> same address or will a new record be added?
>>>>>>>
>>>>>>> Jacques Le Roux sent the following on 8/8/2008 2:33 PM:
>>>>>>>>
>>>>>>>> ----- Original Message ----- From: "Jacques Le Roux"
>>>>>>>> <[hidden email]>
>>>>>>>> To: <[hidden email]>
>>>>>>>> Sent: Friday, August 08, 2008 11:24 PM
>>>>>>>> Subject: Re: Latitude, Longitude in PostalAdress
>>>>>>>>
>>>>>>>>
>>>>>>>>> From: "BJ Freeman" <[hidden email]>
>>>>>>>>>> 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
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Jacques Le Roux sent the following on 8/8/2008 1:00 PM:
>>>>>>>>>>> Yes , this is a good point to note. Actually the geo point
>>>>>>>>>>> continues to
>>>>>>>>>>> exist (it may be used by another thing) but the relation between
>>>>>>>>>>> it and
>>>>>>>>>>> the address does not.
>>>>>>>>>>>
>>>>>>>>>>> Jacques
>>>>>>>>>>>
>>>>>>>>>>> From: "BJ Freeman" <[hidden email]>
>>>>>>>>>>>> but some means would need to link the terrestrial position to
>>>>>>>>>>>> the
>>>>>>>>>>>> address so if the address part is disabled, through the
>>>>>>>>>>>> enddate, in
>>>>>>>>>>>> the
>>>>>>>>>>>> contact mech, so is the position associated with it.
>>>>>>>>>>>>
>>>>>>>>>>>> I agree on the rest.
>>>>>>>>>>>>
>>>>>>>>>>>> Adrian Crum sent the following on 8/7/2008 2:57 PM:
>>>>>>>>>>>>> Jacques Le Roux wrote:
>>>>>>>>>>>>>> Yes actually, I was just thinking about the
>>>>>>>>>>>>>> EntityNameContactMech
>>>>>>>>>>>>>> pattern, not a rule indeed.
>>>>>>>>>>>>>> And because I wondered why we'd use this pattern in most other
>>>>>>>>>>>>>> cases
>>>>>>>>>>>>>> and not for GPS Geolocation, I just reviewed how Len
>>>>>>>>>>>>>> Silverston
>>>>>>>>>>>>>> suggests to deal with contact informations.
>>>>>>>>>>>>>> At this stage I must admit that things were not much more
>>>>>>>>>>>>>> clear. As
>>>>>>>>>>>>>> far as I read Len speaks only about PartyContactMech and
>>>>>>>>>>>>>> FacilityContactMech, but it's easy to extrapolate more
>>>>>>>>>>>>>> usages as
>>>>>>>>>>>>>> it's
>>>>>>>>>>>>>> done in OFBiz.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Now, please let me think loud. What is the difference
>>>>>>>>>>>>>> between a
>>>>>>>>>>>>>> postal
>>>>>>>>>>>>>> address and a GPS point ? Is there more differences between
>>>>>>>>>>>>>> them than between, say a telecom number and a postal address ?
>>>>>>>>>>>>>> Obviously telecom numbers and a postal addresses have
>>>>>>>>>>>>>> something in
>>>>>>>>>>>>>> common that a GPS point does not share: they are
>>>>>>>>>>>>>> mechanismes to
>>>>>>>>>>>>>> contact somebody (or something at large). A GPS point is
>>>>>>>>>>>>>> only a
>>>>>>>>>>>>>> mean
>>>>>>>>>>>>>> to locate somebody (or something at large), you can't
>>>>>>>>>>>>>> contact a
>>>>>>>>>>>>>> GPS point. So yes, it makes sense to differntiate a GPS point
>>>>>>>>>>>>>> from
>>>>>>>>>>>>>> other contact mech. A GPS point is not a contact mech as Len
>>>>>>>>>>>>>> Silverstion defines one. It's a mean to locate not to
>>>>>>>>>>>>>> contact. So
>>>>>>>>>>>>>> now
>>>>>>>>>>>>>> I better understant why you wanted things to point to it
>>>>>>>>>>>>>> rather than having it point to other things. I still wonder
>>>>>>>>>>>>>> though if
>>>>>>>>>>>>>> we should not think a bit more about it. Putting a
>>>>>>>>>>>>>> terrestrialPositionId  in ContactMech does not make sense, as
>>>>>>>>>>>>>> it's not
>>>>>>>>>>>>>> a mean to contact but locate. Should we not introduce
>>>>>>>>>>>>>> something else. Like a LocateMech, which could be maybe
>>>>>>>>>>>>>> used for
>>>>>>>>>>>>>> other
>>>>>>>>>>>>>> stuff in future ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I like the idea of making terrestrial position another contact
>>>>>>>>>>>>> mech
>>>>>>>>>>>>> type.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I disagree that you can't contact a GPS point. You can if you
>>>>>>>>>>>>> have
>>>>>>>>>>>>> a GPS
>>>>>>>>>>>>> device and a means of transportation - the same as a postal
>>>>>>>>>>>>> address. How
>>>>>>>>>>>>> is locating someone via car plus GPS device any different than
>>>>>>>>>>>>> locating
>>>>>>>>>>>>> someone via car plus a map?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I can think of other uses for a terrestrial position contact
>>>>>>>>>>>>> mech
>>>>>>>>>>>>> type -
>>>>>>>>>>>>> locating facilities or fixed assets like electrical
>>>>>>>>>>>>> transmission
>>>>>>>>>>>>> towers,
>>>>>>>>>>>>> cell towers, etc. They aren't going to have a postal address or
>>>>>>>>>>>>> phone
>>>>>>>>>>>>> number. If terrestrial position was another contact mech type,
>>>>>>>>>>>>> then we
>>>>>>>>>>>>> could use existing services, etc to associate that location to
>>>>>>>>>>>>> the
>>>>>>>>>>>>> facility.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Adrian
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>
>

[BJ Freeman]

think facilities should also have a geopoint along with a postal address
then the moving asset can be tracked relative to is origin or destination.

David E Jones sent the following on 8/9/2008 12:44 PM:

>
> On Aug 9, 2008, at 1:13 PM, Adrian Crum wrote:
>
>> --- On Sat, 8/9/08, David E Jones <[hidden email]> wrote:
>>> 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?
>
> What about FixedAssets that are not located in a Facility, like trucks
> or equipment being transported?
>
> The main point is that Facilities are typically not mobile (though I
> suppose they could be... or maybe not) but FixedAssets usually are
> mobile and so need a history of locations (tracked using GeoPoints).
>
> -David
>
>
>
>
>

[Jacques Le Roux]

+1

Jacques

From: "BJ Freeman" <[hidden email]>

> think facilities should also have a geopoint along with a postal address
> then the moving asset can be tracked relative to is origin or destination.
>
> David E Jones sent the following on 8/9/2008 12:44 PM:
>>
>> On Aug 9, 2008, at 1:13 PM, Adrian Crum wrote:
>>
>>> --- On Sat, 8/9/08, David E Jones <[hidden email]> wrote:
>>>> 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?
>>
>> What about FixedAssets that are not located in a Facility, like trucks
>> or equipment being transported?
>>
>> The main point is that Facilities are typically not mobile (though I
>> suppose they could be... or maybe not) but FixedAssets usually are
>> mobile and so need a history of locations (tracked using GeoPoints).
>>
>> -David
>>
>>
>>
>>
>>
>

[Adrian Crum-2]

--- On Sat, 8/9/08, David E Jones <[hidden email]> wrote:

> From: David E Jones <[hidden email]>
> Subject: Re: Latitude, Longitude in PostalAdress
> To: [hidden email]
> Date: Saturday, August 9, 2008, 12:44 PM
> On Aug 9, 2008, at 1:13 PM, Adrian Crum wrote:
>
> > --- On Sat, 8/9/08, David E Jones
> <[hidden email]> wrote:
> >> 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?
>
> What about FixedAssets that are not located in a Facility,
> like trucks  
> or equipment being transported?
>
> The main point is that Facilities are typically not mobile
> (though I  
> suppose they could be... or maybe not) but FixedAssets
> usually are  
> mobile and so need a history of locations (tracked using
> GeoPoints).

Good point. Thanks!

-Adrian



     

[Jacques Le Roux]

I had a look and put some (limited fro now) comments in repective wiki pages

Jacques

From: "Jacques Le Roux" <[hidden email]>

> OK, thanks for the link, I will study...
>
> Jacques
>
> From: "BJ Freeman" <[hidden email]>
>>I have not written much on the wiki yet because is very complicated.
>> however part of the proposal is the stages and sequence to get this done
>> so people that have data already in use will not suffer.
>> in the light
>> yes there will be a series of patches probably under different task in
>> the same jira.
>> http://docs.ofbiz.org/display/OFBIZ/Address+Schema+Change+Proposal
>>
>>
>> Jacques Le Roux sent the following on 8/9/2008 10:26 AM:
>>> From: "BJ Freeman" <[hidden email]>
>>>> Yes it save a lot of programming. mostly in matching the stored address
>>>> with the with the user input.
>>>> that is part of the change plan to to implement that.
>>>> the stored postal address, would be already postoffice formatted for the
>>>> country. so the matching algorithm for the user input and the screen to
>>>> do this is more complicated, but will worth the effort making sure there
>>>> is a usable address in the system.
>>>
>>> This is interesting. I think we will look forward for a Jira with
>>> patch(es). I write patch(es) because if it's a large piece of code it is
>>> worth to split it in patches.
>>> For instance at least data model and code separated. Maybe more
>>> separation between code from functionnalities, etc.
>>>
>>> Jacques
>>>
>>>>
>>>> Jacques Le Roux sent the following on 8/9/2008 3:22 AM:
>>>>> I agree that addresses should not be specific to a party and could be
>>>>> shared. Let see what other think. There may be a good reason it's build
>>>>> like that... It introduces some redundancy but maybe save programming
>>>>> efforts...
>>>>>
>>>>> Jacques
>>>>>
>>>>> From: "BJ Freeman" <[hidden email]>
>>>>>> ah, well I am working a plan to remove toname and attnname.
>>>>>> if you read the data books it was not laid out that way.
>>>>>> my concept was
>>>>>>                              contactMechtoPostalAddressAssoce
>>>>>> postal addresss -------------->postaladdressid
>>>>>>                               ContactMechID  <------------contact Mech
>>>>>> the toname and attentent name would become part of the contact mech
>>>>>> types with those types using the same relationship.
>>>>>> so one postal address is in the database.
>>>>>> Just like in the real world that is just one address, or location.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Jacques Le Roux sent the following on 8/9/2008 12:56 AM:
>>>>>>> To answer you question you have only to have a look at the
>>>>>>> PostalAddress
>>>>>>> definition
>>>>>>> There are specific fields there like toName and attnName which can't
>>>>>>> shared. A PostalAddress is only an administrative mean to contact, not
>>>>>>> to locate
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>> From: "BJ Freeman" <[hidden email]>
>>>>>>>> so when someone else puts in the same address will they point to the
>>>>>>>> same address or will a new record be added?
>>>>>>>>
>>>>>>>> Jacques Le Roux sent the following on 8/8/2008 2:33 PM:
>>>>>>>>>
>>>>>>>>> ----- Original Message ----- From: "Jacques Le Roux"
>>>>>>>>> <[hidden email]>
>>>>>>>>> To: <[hidden email]>
>>>>>>>>> Sent: Friday, August 08, 2008 11:24 PM
>>>>>>>>> Subject: Re: Latitude, Longitude in PostalAdress
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> From: "BJ Freeman" <[hidden email]>
>>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>>> Jacques
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Jacques Le Roux sent the following on 8/8/2008 1:00 PM:
>>>>>>>>>>>> Yes , this is a good point to note. Actually the geo point
>>>>>>>>>>>> continues to
>>>>>>>>>>>> exist (it may be used by another thing) but the relation between
>>>>>>>>>>>> it and
>>>>>>>>>>>> the address does not.
>>>>>>>>>>>>
>>>>>>>>>>>> Jacques
>>>>>>>>>>>>
>>>>>>>>>>>> From: "BJ Freeman" <[hidden email]>
>>>>>>>>>>>>> but some means would need to link the terrestrial position to
>>>>>>>>>>>>> the
>>>>>>>>>>>>> address so if the address part is disabled, through the
>>>>>>>>>>>>> enddate, in
>>>>>>>>>>>>> the
>>>>>>>>>>>>> contact mech, so is the position associated with it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I agree on the rest.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Adrian Crum sent the following on 8/7/2008 2:57 PM:
>>>>>>>>>>>>>> Jacques Le Roux wrote:
>>>>>>>>>>>>>>> Yes actually, I was just thinking about the
>>>>>>>>>>>>>>> EntityNameContactMech
>>>>>>>>>>>>>>> pattern, not a rule indeed.
>>>>>>>>>>>>>>> And because I wondered why we'd use this pattern in most other
>>>>>>>>>>>>>>> cases
>>>>>>>>>>>>>>> and not for GPS Geolocation, I just reviewed how Len
>>>>>>>>>>>>>>> Silverston
>>>>>>>>>>>>>>> suggests to deal with contact informations.
>>>>>>>>>>>>>>> At this stage I must admit that things were not much more
>>>>>>>>>>>>>>> clear. As
>>>>>>>>>>>>>>> far as I read Len speaks only about PartyContactMech and
>>>>>>>>>>>>>>> FacilityContactMech, but it's easy to extrapolate more
>>>>>>>>>>>>>>> usages as
>>>>>>>>>>>>>>> it's
>>>>>>>>>>>>>>> done in OFBiz.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Now, please let me think loud. What is the difference
>>>>>>>>>>>>>>> between a
>>>>>>>>>>>>>>> postal
>>>>>>>>>>>>>>> address and a GPS point ? Is there more differences between
>>>>>>>>>>>>>>> them than between, say a telecom number and a postal address ?
>>>>>>>>>>>>>>> Obviously telecom numbers and a postal addresses have
>>>>>>>>>>>>>>> something in
>>>>>>>>>>>>>>> common that a GPS point does not share: they are
>>>>>>>>>>>>>>> mechanismes to
>>>>>>>>>>>>>>> contact somebody (or something at large). A GPS point is
>>>>>>>>>>>>>>> only a
>>>>>>>>>>>>>>> mean
>>>>>>>>>>>>>>> to locate somebody (or something at large), you can't
>>>>>>>>>>>>>>> contact a
>>>>>>>>>>>>>>> GPS point. So yes, it makes sense to differntiate a GPS point
>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>> other contact mech. A GPS point is not a contact mech as Len
>>>>>>>>>>>>>>> Silverstion defines one. It's a mean to locate not to
>>>>>>>>>>>>>>> contact. So
>>>>>>>>>>>>>>> now
>>>>>>>>>>>>>>> I better understant why you wanted things to point to it
>>>>>>>>>>>>>>> rather than having it point to other things. I still wonder
>>>>>>>>>>>>>>> though if
>>>>>>>>>>>>>>> we should not think a bit more about it. Putting a
>>>>>>>>>>>>>>> terrestrialPositionId  in ContactMech does not make sense, as
>>>>>>>>>>>>>>> it's not
>>>>>>>>>>>>>>> a mean to contact but locate. Should we not introduce
>>>>>>>>>>>>>>> something else. Like a LocateMech, which could be maybe
>>>>>>>>>>>>>>> used for
>>>>>>>>>>>>>>> other
>>>>>>>>>>>>>>> stuff in future ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I like the idea of making terrestrial position another contact
>>>>>>>>>>>>>> mech
>>>>>>>>>>>>>> type.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I disagree that you can't contact a GPS point. You can if you
>>>>>>>>>>>>>> have
>>>>>>>>>>>>>> a GPS
>>>>>>>>>>>>>> device and a means of transportation - the same as a postal
>>>>>>>>>>>>>> address. How
>>>>>>>>>>>>>> is locating someone via car plus GPS device any different than
>>>>>>>>>>>>>> locating
>>>>>>>>>>>>>> someone via car plus a map?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I can think of other uses for a terrestrial position contact
>>>>>>>>>>>>>> mech
>>>>>>>>>>>>>> type -
>>>>>>>>>>>>>> locating facilities or fixed assets like electrical
>>>>>>>>>>>>>> transmission
>>>>>>>>>>>>>> towers,
>>>>>>>>>>>>>> cell towers, etc. They aren't going to have a postal address or
>>>>>>>>>>>>>> phone
>>>>>>>>>>>>>> number. If terrestrial position was another contact mech type,
>>>>>>>>>>>>>> then we
>>>>>>>>>>>>>> could use existing services, etc to associate that location to
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> facility.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -Adrian
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>

[BJ Freeman]

they come from the xAL:2.0 standardard

Jacques Le Roux sent the following on 8/10/2008 2:16 AM:

> I had a look and put some (limited fro now) comments in repective wiki
> pages
>
> Jacques
>
> From: "Jacques Le Roux" <[hidden email]>
>> OK, thanks for the link, I will study...
>>
>> Jacques
>>
>> From: "BJ Freeman" <[hidden email]>
>>> I have not written much on the wiki yet because is very complicated.
>>> however part of the proposal is the stages and sequence to get this done
>>> so people that have data already in use will not suffer.
>>> in the light
>>> yes there will be a series of patches probably under different task in
>>> the same jira.
>>> http://docs.ofbiz.org/display/OFBIZ/Address+Schema+Change+Proposal
>>>
>>>
>>> Jacques Le Roux sent the following on 8/9/2008 10:26 AM:
>>>> From: "BJ Freeman" <[hidden email]>
>>>>> Yes it save a lot of programming. mostly in matching the stored
>>>>> address
>>>>> with the with the user input.
>>>>> that is part of the change plan to to implement that.
>>>>> the stored postal address, would be already postoffice formatted
>>>>> for the
>>>>> country. so the matching algorithm for the user input and the
>>>>> screen to
>>>>> do this is more complicated, but will worth the effort making sure
>>>>> there
>>>>> is a usable address in the system.
>>>>
>>>> This is interesting. I think we will look forward for a Jira with
>>>> patch(es). I write patch(es) because if it's a large piece of code
>>>> it is
>>>> worth to split it in patches.
>>>> For instance at least data model and code separated. Maybe more
>>>> separation between code from functionnalities, etc.
>>>>
>>>> Jacques
>>>>
>>>>>
>>>>> Jacques Le Roux sent the following on 8/9/2008 3:22 AM:
>>>>>> I agree that addresses should not be specific to a party and could be
>>>>>> shared. Let see what other think. There may be a good reason it's
>>>>>> build
>>>>>> like that... It introduces some redundancy but maybe save programming
>>>>>> efforts...
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>> From: "BJ Freeman" <[hidden email]>
>>>>>>> ah, well I am working a plan to remove toname and attnname.
>>>>>>> if you read the data books it was not laid out that way.
>>>>>>> my concept was
>>>>>>>                              contactMechtoPostalAddressAssoce
>>>>>>> postal addresss -------------->postaladdressid
>>>>>>>                               ContactMechID  <------------contact
>>>>>>> Mech
>>>>>>> the toname and attentent name would become part of the contact mech
>>>>>>> types with those types using the same relationship.
>>>>>>> so one postal address is in the database.
>>>>>>> Just like in the real world that is just one address, or location.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Jacques Le Roux sent the following on 8/9/2008 12:56 AM:
>>>>>>>> To answer you question you have only to have a look at the
>>>>>>>> PostalAddress
>>>>>>>> definition
>>>>>>>> There are specific fields there like toName and attnName which
>>>>>>>> can't
>>>>>>>> shared. A PostalAddress is only an administrative mean to
>>>>>>>> contact, not
>>>>>>>> to locate
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>> From: "BJ Freeman" <[hidden email]>
>>>>>>>>> so when someone else puts in the same address will they point
>>>>>>>>> to the
>>>>>>>>> same address or will a new record be added?
>>>>>>>>>
>>>>>>>>> Jacques Le Roux sent the following on 8/8/2008 2:33 PM:
>>>>>>>>>>
>>>>>>>>>> ----- Original Message ----- From: "Jacques Le Roux"
>>>>>>>>>> <[hidden email]>
>>>>>>>>>> To: <[hidden email]>
>>>>>>>>>> Sent: Friday, August 08, 2008 11:24 PM
>>>>>>>>>> Subject: Re: Latitude, Longitude in PostalAdress
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> From: "BJ Freeman" <[hidden email]>
>>>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>> Jacques
>>>>>>>>>>
>>>>>>>>>>> Jacques
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Jacques Le Roux sent the following on 8/8/2008 1:00 PM:
>>>>>>>>>>>>> Yes , this is a good point to note. Actually the geo point
>>>>>>>>>>>>> continues to
>>>>>>>>>>>>> exist (it may be used by another thing) but the relation
>>>>>>>>>>>>> between
>>>>>>>>>>>>> it and
>>>>>>>>>>>>> the address does not.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>
>>>>>>>>>>>>> From: "BJ Freeman" <[hidden email]>
>>>>>>>>>>>>>> but some means would need to link the terrestrial position to
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> address so if the address part is disabled, through the
>>>>>>>>>>>>>> enddate, in
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> contact mech, so is the position associated with it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I agree on the rest.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Adrian Crum sent the following on 8/7/2008 2:57 PM:
>>>>>>>>>>>>>>> Jacques Le Roux wrote:
>>>>>>>>>>>>>>>> Yes actually, I was just thinking about the
>>>>>>>>>>>>>>>> EntityNameContactMech
>>>>>>>>>>>>>>>> pattern, not a rule indeed.
>>>>>>>>>>>>>>>> And because I wondered why we'd use this pattern in most
>>>>>>>>>>>>>>>> other
>>>>>>>>>>>>>>>> cases
>>>>>>>>>>>>>>>> and not for GPS Geolocation, I just reviewed how Len
>>>>>>>>>>>>>>>> Silverston
>>>>>>>>>>>>>>>> suggests to deal with contact informations.
>>>>>>>>>>>>>>>> At this stage I must admit that things were not much more
>>>>>>>>>>>>>>>> clear. As
>>>>>>>>>>>>>>>> far as I read Len speaks only about PartyContactMech and
>>>>>>>>>>>>>>>> FacilityContactMech, but it's easy to extrapolate more
>>>>>>>>>>>>>>>> usages as
>>>>>>>>>>>>>>>> it's
>>>>>>>>>>>>>>>> done in OFBiz.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Now, please let me think loud. What is the difference
>>>>>>>>>>>>>>>> between a
>>>>>>>>>>>>>>>> postal
>>>>>>>>>>>>>>>> address and a GPS point ? Is there more differences between
>>>>>>>>>>>>>>>> them than between, say a telecom number and a postal
>>>>>>>>>>>>>>>> address ?
>>>>>>>>>>>>>>>> Obviously telecom numbers and a postal addresses have
>>>>>>>>>>>>>>>> something in
>>>>>>>>>>>>>>>> common that a GPS point does not share: they are
>>>>>>>>>>>>>>>> mechanismes to
>>>>>>>>>>>>>>>> contact somebody (or something at large). A GPS point is
>>>>>>>>>>>>>>>> only a
>>>>>>>>>>>>>>>> mean
>>>>>>>>>>>>>>>> to locate somebody (or something at large), you can't
>>>>>>>>>>>>>>>> contact a
>>>>>>>>>>>>>>>> GPS point. So yes, it makes sense to differntiate a GPS
>>>>>>>>>>>>>>>> point
>>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>> other contact mech. A GPS point is not a contact mech as
>>>>>>>>>>>>>>>> Len
>>>>>>>>>>>>>>>> Silverstion defines one. It's a mean to locate not to
>>>>>>>>>>>>>>>> contact. So
>>>>>>>>>>>>>>>> now
>>>>>>>>>>>>>>>> I better understant why you wanted things to point to it
>>>>>>>>>>>>>>>> rather than having it point to other things. I still wonder
>>>>>>>>>>>>>>>> though if
>>>>>>>>>>>>>>>> we should not think a bit more about it. Putting a
>>>>>>>>>>>>>>>> terrestrialPositionId  in ContactMech does not make
>>>>>>>>>>>>>>>> sense, as
>>>>>>>>>>>>>>>> it's not
>>>>>>>>>>>>>>>> a mean to contact but locate. Should we not introduce
>>>>>>>>>>>>>>>> something else. Like a LocateMech, which could be maybe
>>>>>>>>>>>>>>>> used for
>>>>>>>>>>>>>>>> other
>>>>>>>>>>>>>>>> stuff in future ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I like the idea of making terrestrial position another
>>>>>>>>>>>>>>> contact
>>>>>>>>>>>>>>> mech
>>>>>>>>>>>>>>> type.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I disagree that you can't contact a GPS point. You can if
>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>> a GPS
>>>>>>>>>>>>>>> device and a means of transportation - the same as a postal
>>>>>>>>>>>>>>> address. How
>>>>>>>>>>>>>>> is locating someone via car plus GPS device any different
>>>>>>>>>>>>>>> than
>>>>>>>>>>>>>>> locating
>>>>>>>>>>>>>>> someone via car plus a map?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I can think of other uses for a terrestrial position contact
>>>>>>>>>>>>>>> mech
>>>>>>>>>>>>>>> type -
>>>>>>>>>>>>>>> locating facilities or fixed assets like electrical
>>>>>>>>>>>>>>> transmission
>>>>>>>>>>>>>>> towers,
>>>>>>>>>>>>>>> cell towers, etc. They aren't going to have a postal
>>>>>>>>>>>>>>> address or
>>>>>>>>>>>>>>> phone
>>>>>>>>>>>>>>> number. If terrestrial position was another contact mech
>>>>>>>>>>>>>>> type,
>>>>>>>>>>>>>>> then we
>>>>>>>>>>>>>>> could use existing services, etc to associate that
>>>>>>>>>>>>>>> location to
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> facility.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -Adrian
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
>
>

[BJ Freeman]

oops see you main comment.
:)

BJ Freeman sent the following on 8/10/2008 2:35 AM:

> they come from the xAL:2.0 standardard
>
> Jacques Le Roux sent the following on 8/10/2008 2:16 AM:
>> I had a look and put some (limited fro now) comments in repective wiki
>> pages
>>
>> Jacques
>>
>> From: "Jacques Le Roux" <[hidden email]>
>>> OK, thanks for the link, I will study...
>>>
>>> Jacques
>>>
>>> From: "BJ Freeman" <[hidden email]>
>>>> I have not written much on the wiki yet because is very complicated.
>>>> however part of the proposal is the stages and sequence to get this done
>>>> so people that have data already in use will not suffer.
>>>> in the light
>>>> yes there will be a series of patches probably under different task in
>>>> the same jira.
>>>> http://docs.ofbiz.org/display/OFBIZ/Address+Schema+Change+Proposal
>>>>
>>>>
>>>> Jacques Le Roux sent the following on 8/9/2008 10:26 AM:
>>>>> From: "BJ Freeman" <[hidden email]>
>>>>>> Yes it save a lot of programming. mostly in matching the stored
>>>>>> address
>>>>>> with the with the user input.
>>>>>> that is part of the change plan to to implement that.
>>>>>> the stored postal address, would be already postoffice formatted
>>>>>> for the
>>>>>> country. so the matching algorithm for the user input and the
>>>>>> screen to
>>>>>> do this is more complicated, but will worth the effort making sure
>>>>>> there
>>>>>> is a usable address in the system.
>>>>> This is interesting. I think we will look forward for a Jira with
>>>>> patch(es). I write patch(es) because if it's a large piece of code
>>>>> it is
>>>>> worth to split it in patches.
>>>>> For instance at least data model and code separated. Maybe more
>>>>> separation between code from functionnalities, etc.
>>>>>
>>>>> Jacques
>>>>>
>>>>>> Jacques Le Roux sent the following on 8/9/2008 3:22 AM:
>>>>>>> I agree that addresses should not be specific to a party and could be
>>>>>>> shared. Let see what other think. There may be a good reason it's
>>>>>>> build
>>>>>>> like that... It introduces some redundancy but maybe save programming
>>>>>>> efforts...
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>> From: "BJ Freeman" <[hidden email]>
>>>>>>>> ah, well I am working a plan to remove toname and attnname.
>>>>>>>> if you read the data books it was not laid out that way.
>>>>>>>> my concept was
>>>>>>>>                              contactMechtoPostalAddressAssoce
>>>>>>>> postal addresss -------------->postaladdressid
>>>>>>>>                               ContactMechID  <------------contact
>>>>>>>> Mech
>>>>>>>> the toname and attentent name would become part of the contact mech
>>>>>>>> types with those types using the same relationship.
>>>>>>>> so one postal address is in the database.
>>>>>>>> Just like in the real world that is just one address, or location.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Jacques Le Roux sent the following on 8/9/2008 12:56 AM:
>>>>>>>>> To answer you question you have only to have a look at the
>>>>>>>>> PostalAddress
>>>>>>>>> definition
>>>>>>>>> There are specific fields there like toName and attnName which
>>>>>>>>> can't
>>>>>>>>> shared. A PostalAddress is only an administrative mean to
>>>>>>>>> contact, not
>>>>>>>>> to locate
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>> From: "BJ Freeman" <[hidden email]>
>>>>>>>>>> so when someone else puts in the same address will they point
>>>>>>>>>> to the
>>>>>>>>>> same address or will a new record be added?
>>>>>>>>>>
>>>>>>>>>> Jacques Le Roux sent the following on 8/8/2008 2:33 PM:
>>>>>>>>>>> ----- Original Message ----- From: "Jacques Le Roux"
>>>>>>>>>>> <[hidden email]>
>>>>>>>>>>> To: <[hidden email]>
>>>>>>>>>>> Sent: Friday, August 08, 2008 11:24 PM
>>>>>>>>>>> Subject: Re: Latitude, Longitude in PostalAdress
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> From: "BJ Freeman" <[hidden email]>
>>>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>> Jacques
>>>>>>>>>>>
>>>>>>>>>>>> Jacques
>>>>>>>>>>>>
>>>>>>>>>>>>> Jacques Le Roux sent the following on 8/8/2008 1:00 PM:
>>>>>>>>>>>>>> Yes , this is a good point to note. Actually the geo point
>>>>>>>>>>>>>> continues to
>>>>>>>>>>>>>> exist (it may be used by another thing) but the relation
>>>>>>>>>>>>>> between
>>>>>>>>>>>>>> it and
>>>>>>>>>>>>>> the address does not.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> From: "BJ Freeman" <[hidden email]>
>>>>>>>>>>>>>>> but some means would need to link the terrestrial position to
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> address so if the address part is disabled, through the
>>>>>>>>>>>>>>> enddate, in
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> contact mech, so is the position associated with it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I agree on the rest.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Adrian Crum sent the following on 8/7/2008 2:57 PM:
>>>>>>>>>>>>>>>> Jacques Le Roux wrote:
>>>>>>>>>>>>>>>>> Yes actually, I was just thinking about the
>>>>>>>>>>>>>>>>> EntityNameContactMech
>>>>>>>>>>>>>>>>> pattern, not a rule indeed.
>>>>>>>>>>>>>>>>> And because I wondered why we'd use this pattern in most
>>>>>>>>>>>>>>>>> other
>>>>>>>>>>>>>>>>> cases
>>>>>>>>>>>>>>>>> and not for GPS Geolocation, I just reviewed how Len
>>>>>>>>>>>>>>>>> Silverston
>>>>>>>>>>>>>>>>> suggests to deal with contact informations.
>>>>>>>>>>>>>>>>> At this stage I must admit that things were not much more
>>>>>>>>>>>>>>>>> clear. As
>>>>>>>>>>>>>>>>> far as I read Len speaks only about PartyContactMech and
>>>>>>>>>>>>>>>>> FacilityContactMech, but it's easy to extrapolate more
>>>>>>>>>>>>>>>>> usages as
>>>>>>>>>>>>>>>>> it's
>>>>>>>>>>>>>>>>> done in OFBiz.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Now, please let me think loud. What is the difference
>>>>>>>>>>>>>>>>> between a
>>>>>>>>>>>>>>>>> postal
>>>>>>>>>>>>>>>>> address and a GPS point ? Is there more differences between
>>>>>>>>>>>>>>>>> them than between, say a telecom number and a postal
>>>>>>>>>>>>>>>>> address ?
>>>>>>>>>>>>>>>>> Obviously telecom numbers and a postal addresses have
>>>>>>>>>>>>>>>>> something in
>>>>>>>>>>>>>>>>> common that a GPS point does not share: they are
>>>>>>>>>>>>>>>>> mechanismes to
>>>>>>>>>>>>>>>>> contact somebody (or something at large). A GPS point is
>>>>>>>>>>>>>>>>> only a
>>>>>>>>>>>>>>>>> mean
>>>>>>>>>>>>>>>>> to locate somebody (or something at large), you can't
>>>>>>>>>>>>>>>>> contact a
>>>>>>>>>>>>>>>>> GPS point. So yes, it makes sense to differntiate a GPS
>>>>>>>>>>>>>>>>> point
>>>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>>> other contact mech. A GPS point is not a contact mech as
>>>>>>>>>>>>>>>>> Len
>>>>>>>>>>>>>>>>> Silverstion defines one. It's a mean to locate not to
>>>>>>>>>>>>>>>>> contact. So
>>>>>>>>>>>>>>>>> now
>>>>>>>>>>>>>>>>> I better understant why you wanted things to point to it
>>>>>>>>>>>>>>>>> rather than having it point to other things. I still wonder
>>>>>>>>>>>>>>>>> though if
>>>>>>>>>>>>>>>>> we should not think a bit more about it. Putting a
>>>>>>>>>>>>>>>>> terrestrialPositionId  in ContactMech does not make
>>>>>>>>>>>>>>>>> sense, as
>>>>>>>>>>>>>>>>> it's not
>>>>>>>>>>>>>>>>> a mean to contact but locate. Should we not introduce
>>>>>>>>>>>>>>>>> something else. Like a LocateMech, which could be maybe
>>>>>>>>>>>>>>>>> used for
>>>>>>>>>>>>>>>>> other
>>>>>>>>>>>>>>>>> stuff in future ?
>>>>>>>>>>>>>>>> I like the idea of making terrestrial position another
>>>>>>>>>>>>>>>> contact
>>>>>>>>>>>>>>>> mech
>>>>>>>>>>>>>>>> type.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I disagree that you can't contact a GPS point. You can if
>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>> a GPS
>>>>>>>>>>>>>>>> device and a means of transportation - the same as a postal
>>>>>>>>>>>>>>>> address. How
>>>>>>>>>>>>>>>> is locating someone via car plus GPS device any different
>>>>>>>>>>>>>>>> than
>>>>>>>>>>>>>>>> locating
>>>>>>>>>>>>>>>> someone via car plus a map?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I can think of other uses for a terrestrial position contact
>>>>>>>>>>>>>>>> mech
>>>>>>>>>>>>>>>> type -
>>>>>>>>>>>>>>>> locating facilities or fixed assets like electrical
>>>>>>>>>>>>>>>> transmission
>>>>>>>>>>>>>>>> towers,
>>>>>>>>>>>>>>>> cell towers, etc. They aren't going to have a postal
>>>>>>>>>>>>>>>> address or
>>>>>>>>>>>>>>>> phone
>>>>>>>>>>>>>>>> number. If terrestrial position was another contact mech
>>>>>>>>>>>>>>>> type,
>>>>>>>>>>>>>>>> then we
>>>>>>>>>>>>>>>> could use existing services, etc to associate that
>>>>>>>>>>>>>>>> location to
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> facility.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -Adrian
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>
>>
>
>
>
>

[Jacques Le Roux]

From: "David E Jones" <[hidden email]>

>
> On Aug 8, 2008, at 3:33 PM, Jacques Le Roux wrote:
>
>>> From: "BJ Freeman" <[hidden email]>
>>>> 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
>
>

[BJ Freeman]

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" <[hidden email]>
>>
>> On Aug 8, 2008, at 3:33 PM, Jacques Le Roux wrote:
>>
>>>> From: "BJ Freeman" <[hidden email]>
>>>>> 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
>>
>>
>
>
>
>

[Jacques Le Roux]

From: "BJ Freeman" <[hidden email]>
> on a light side
> anything that a robot would need to know to get to and from something.
> :)

Yes, for the moment areaId, aisleId, sectionId, levelId - needs elevation -, positionId  are only references in OFBiz.
If we want to be able tro track their locations, we will need to create new entities. Like Area, Aisle, Section, Level and Position
(no sure for the last), and so on (if needed)...

Note :
GPS precision is nowaday +-3 meters
Galilleo's Commercial Service will be less than 1 meter
and intiatives like Teria (from French land surveyors association) allow already centimetric precision
http://www.geometre-expert.fr/www/cmsMng.do;jsessionid=D843CB3022F8CF13D26277C7D48CA1DF?ID_PAGE=11377&ID_RUBRIC=13.

Before I translate all this in entitymodel files. I'd like this possibility discussed.

Thanks

Jacques

> Jacques Le Roux sent the following on 8/10/2008 2:56 PM:
>> From: "David E Jones" <[hidden email]>
>>>
>>> On Aug 8, 2008, at 3:33 PM, Jacques Le Roux wrote:
>>>
>>>>> From: "BJ Freeman" <[hidden email]>
>>>>>> 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
>>>
>>>
>>
>>
>>
>>
>

[BJ Freeman]

http://en.wikipedia.org/wiki/Global_Positioning_System

Jacques Le Roux sent the following on 8/13/2008 11:25 AM:

> From: "BJ Freeman" <[hidden email]>
>> on a light side
>> anything that a robot would need to know to get to and from something.
>> :)
>
> Yes, for the moment areaId, aisleId, sectionId, levelId - needs
> elevation -, positionId  are only references in OFBiz.
> If we want to be able tro track their locations, we will need to create
> new entities. Like Area, Aisle, Section, Level and Position (no sure for
> the last), and so on (if needed)...
>
> Note :
> GPS precision is nowaday +-3 meters
> Galilleo's Commercial Service will be less than 1 meter
> and intiatives like Teria (from French land surveyors association) allow
> already centimetric precision
> http://www.geometre-expert.fr/www/cmsMng.do;jsessionid=D843CB3022F8CF13D26277C7D48CA1DF?ID_PAGE=11377&ID_RUBRIC=13.
>
>
> Before I translate all this in entitymodel files. I'd like this
> possibility discussed.
>
> Thanks
>
> Jacques
>
>
>> Jacques Le Roux sent the following on 8/10/2008 2:56 PM:
>>> From: "David E Jones" <[hidden email]>
>>>>
>>>> On Aug 8, 2008, at 3:33 PM, Jacques Le Roux wrote:
>>>>
>>>>>> From: "BJ Freeman" <[hidden email]>
>>>>>>> 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
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>
>
>
>

[BJ Freeman]

also note: that the number of satellites the receiver can pick up will
effect the accuracy. Even to the point of not getting elevation.
This happens when I drive in the shadow of something that blocks the
reception of a couple of satellites.
8 is the best number. 3 is the least number.

Jacques Le Roux sent the following on 8/13/2008 11:25 AM:

> From: "BJ Freeman" <[hidden email]>
>> on a light side
>> anything that a robot would need to know to get to and from something.
>> :)
>
> Yes, for the moment areaId, aisleId, sectionId, levelId - needs
> elevation -, positionId  are only references in OFBiz.
> If we want to be able tro track their locations, we will need to create
> new entities. Like Area, Aisle, Section, Level and Position (no sure for
> the last), and so on (if needed)...
>
> Note :
> GPS precision is nowaday +-3 meters
> Galilleo's Commercial Service will be less than 1 meter
> and intiatives like Teria (from French land surveyors association) allow
> already centimetric precision
> http://www.geometre-expert.fr/www/cmsMng.do;jsessionid=D843CB3022F8CF13D26277C7D48CA1DF?ID_PAGE=11377&ID_RUBRIC=13.
>
>
> Before I translate all this in entitymodel files. I'd like this
> possibility discussed.
>
> Thanks
>
> Jacques
>
>
>> Jacques Le Roux sent the following on 8/10/2008 2:56 PM:
>>> From: "David E Jones" <[hidden email]>
>>>>
>>>> On Aug 8, 2008, at 3:33 PM, Jacques Le Roux wrote:
>>>>
>>>>>> From: "BJ Freeman" <[hidden email]>
>>>>>>> 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
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>
>
>
>

[Jacques Le Roux]

Yes, anyway this will be enhanced year after years and should not block us. Remember Apple II, 1st PC, Mac, Atari ;o)

Jacques

From: "BJ Freeman" <[hidden email]>

> also note: that the number of satellites the receiver can pick up will
> effect the accuracy. Even to the point of not getting elevation.
> This happens when I drive in the shadow of something that blocks the
> reception of a couple of satellites.
> 8 is the best number. 3 is the least number.
>
> Jacques Le Roux sent the following on 8/13/2008 11:25 AM:
>> From: "BJ Freeman" <[hidden email]>
>>> on a light side
>>> anything that a robot would need to know to get to and from something.
>>> :)
>>
>> Yes, for the moment areaId, aisleId, sectionId, levelId - needs
>> elevation -, positionId  are only references in OFBiz.
>> If we want to be able tro track their locations, we will need to create
>> new entities. Like Area, Aisle, Section, Level and Position (no sure for
>> the last), and so on (if needed)...
>>
>> Note :
>> GPS precision is nowaday +-3 meters
>> Galilleo's Commercial Service will be less than 1 meter
>> and intiatives like Teria (from French land surveyors association) allow
>> already centimetric precision
>> http://www.geometre-expert.fr/www/cmsMng.do;jsessionid=D843CB3022F8CF13D26277C7D48CA1DF?ID_PAGE=11377&ID_RUBRIC=13.
>>
>>
>> Before I translate all this in entitymodel files. I'd like this
>> possibility discussed.
>>
>> Thanks
>>
>> Jacques
>>
>>
>>> Jacques Le Roux sent the following on 8/10/2008 2:56 PM:
>>>> From: "David E Jones" <[hidden email]>
>>>>>
>>>>> On Aug 8, 2008, at 3:33 PM, Jacques Le Roux wrote:
>>>>>
>>>>>>> From: "BJ Freeman" <[hidden email]>
>>>>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>
>

[BJ Freeman]

Our family manufactured autopilots for fishing boats.
My dad authored the NMEA 0183 standard, in the 80's, to connect ranger
receivers to the pilot. GPS was a big step from those days. :)
Realtime DGPS is even better.
so yes we are progressing.
:D


Jacques Le Roux sent the following on 8/13/2008 12:58 PM:

> Yes, anyway this will be enhanced year after years and should not block
> us. Remember Apple II, 1st PC, Mac, Atari ;o)
>
> Jacques
>
> From: "BJ Freeman" <[hidden email]>
>> also note: that the number of satellites the receiver can pick up will
>> effect the accuracy. Even to the point of not getting elevation.
>> This happens when I drive in the shadow of something that blocks the
>> reception of a couple of satellites.
>> 8 is the best number. 3 is the least number.
>>
>> Jacques Le Roux sent the following on 8/13/2008 11:25 AM:
>>> From: "BJ Freeman" <[hidden email]>
>>>> on a light side
>>>> anything that a robot would need to know to get to and from something.
>>>> :)
>>>
>>> Yes, for the moment areaId, aisleId, sectionId, levelId - needs
>>> elevation -, positionId  are only references in OFBiz.
>>> If we want to be able tro track their locations, we will need to create
>>> new entities. Like Area, Aisle, Section, Level and Position (no sure for
>>> the last), and so on (if needed)...
>>>
>>> Note :
>>> GPS precision is nowaday +-3 meters
>>> Galilleo's Commercial Service will be less than 1 meter
>>> and intiatives like Teria (from French land surveyors association) allow
>>> already centimetric precision
>>> http://www.geometre-expert.fr/www/cmsMng.do;jsessionid=D843CB3022F8CF13D26277C7D48CA1DF?ID_PAGE=11377&ID_RUBRIC=13.
>>>
>>>
>>>
>>> Before I translate all this in entitymodel files. I'd like this
>>> possibility discussed.
>>>
>>> Thanks
>>>
>>> Jacques
>>>
>>>
>>>> Jacques Le Roux sent the following on 8/10/2008 2:56 PM:
>>>>> From: "David E Jones" <[hidden email]>
>>>>>>
>>>>>> On Aug 8, 2008, at 3:33 PM, Jacques Le Roux wrote:
>>>>>>
>>>>>>>> From: "BJ Freeman" <[hidden email]>
>>>>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>
>
>

[Jacques Le Roux]

Yes, that's it : terrestial stations. Thanks for the link BTW, now I know that Teria is only an instance of DGPS :o)

Jacques

From: "BJ Freeman" <[hidden email]>

> Our family manufactured autopilots for fishing boats.
> My dad authored the NMEA 0183 standard, in the 80's, to connect ranger
> receivers to the pilot. GPS was a big step from those days. :)
> Realtime DGPS is even better.
> so yes we are progressing.
> :D
>
>
> Jacques Le Roux sent the following on 8/13/2008 12:58 PM:
>> Yes, anyway this will be enhanced year after years and should not block
>> us. Remember Apple II, 1st PC, Mac, Atari ;o)
>>
>> Jacques
>>
>> From: "BJ Freeman" <[hidden email]>
>>> also note: that the number of satellites the receiver can pick up will
>>> effect the accuracy. Even to the point of not getting elevation.
>>> This happens when I drive in the shadow of something that blocks the
>>> reception of a couple of satellites.
>>> 8 is the best number. 3 is the least number.
>>>
>>> Jacques Le Roux sent the following on 8/13/2008 11:25 AM:
>>>> From: "BJ Freeman" <[hidden email]>
>>>>> on a light side
>>>>> anything that a robot would need to know to get to and from something.
>>>>> :)
>>>>
>>>> Yes, for the moment areaId, aisleId, sectionId, levelId - needs
>>>> elevation -, positionId  are only references in OFBiz.
>>>> If we want to be able tro track their locations, we will need to create
>>>> new entities. Like Area, Aisle, Section, Level and Position (no sure for
>>>> the last), and so on (if needed)...
>>>>
>>>> Note :
>>>> GPS precision is nowaday +-3 meters
>>>> Galilleo's Commercial Service will be less than 1 meter
>>>> and intiatives like Teria (from French land surveyors association) allow
>>>> already centimetric precision
>>>> http://www.geometre-expert.fr/www/cmsMng.do;jsessionid=D843CB3022F8CF13D26277C7D48CA1DF?ID_PAGE=11377&ID_RUBRIC=13.
>>>>
>>>>
>>>>
>>>> Before I translate all this in entitymodel files. I'd like this
>>>> possibility discussed.
>>>>
>>>> Thanks
>>>>
>>>> Jacques
>>>>
>>>>
>>>>> Jacques Le Roux sent the following on 8/10/2008 2:56 PM:
>>>>>> From: "David E Jones" <[hidden email]>
>>>>>>>
>>>>>>> On Aug 8, 2008, at 3:33 PM, Jacques Le Roux wrote:
>>>>>>>
>>>>>>>>> From: "BJ Freeman" <[hidden email]>
>>>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>

[Jacques Le Roux]

From: "Jacques Le Roux" <[hidden email]>
> From: "BJ Freeman" <[hidden email]>
>> on a light side
>> anything that a robot would need to know to get to and from something.
>> :)
>
> Yes, for the moment areaId, aisleId, sectionId, levelId - needs elevation -, positionId  are only references in OFBiz.
> If we want to be able tro track their locations, we will need to create new entities. Like Area, Aisle, Section, Level and
> Position (no sure for the last), and so on (if needed)...

I was suspecting something was wrong in my proposition but as I did not know what, I continued to search.
I just realize reading http://docs.ofbiz.org/display/OFBENDUSER/Products that <<areaId, aisleId, sectionId, levelId - needs
elevation -, positionId  are only references in OFBiz.>> because they are all *FacilityLocations* ! So please forget this comment :/

Tomorrow, I will open a Jira issue an create a patch for the options discussed so far. I hope to apply it this week...

A question though : this is an interesting concept as it is unlimited (i f needed in your warehouse you can add something under
position, or between section and aisle, etc.).
But I know that in Neogia they have used another approach to have a knowledge of what is in what (a section is a part of an aisle
which is itself a part of an area, etc.).
I wonder now why they did not use the OFBiz model, any memories, ideas ?

Thanks

Jacques
PS : http://docs.ofbiz.org/display/OFBENDUSER/Products is certainly one of the most interesting part of the user documentation I
read (I must acknowledge I did not read it all). There is only maybe some informations missing in .2.3.9.12 Features. On how to
apply features to create variants I mean. And wich type (selectable) to use for them to allow the final user (or CS employee) choice
in dropdowns.

> Note :
> GPS precision is nowaday +-3 meters
> Galilleo's Commercial Service will be less than 1 meter
> and intiatives like Teria (from French land surveyors association) allow already centimetric precision
> http://www.geometre-expert.fr/www/cmsMng.do;jsessionid=D843CB3022F8CF13D26277C7D48CA1DF?ID_PAGE=11377&ID_RUBRIC=13.
>
> Before I translate all this in entitymodel files. I'd like this possibility discussed.
>
> Thanks
>
> Jacques
>
>
>> Jacques Le Roux sent the following on 8/10/2008 2:56 PM:
>>> From: "David E Jones" <[hidden email]>
>>>>
>>>> On Aug 8, 2008, at 3:33 PM, Jacques Le Roux wrote:
>>>>
>>>>>> From: "BJ Freeman" <[hidden email]>
>>>>>>> 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
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>

[BJ Freeman]

you can still connect the GeoPoint to faclities and use an scea
to keep it in sync for those that want a standard.
then all you need is the GeoPointID in the location.

Jacques Le Roux sent the following on 8/17/2008 1:52 PM:

> From: "Jacques Le Roux" <[hidden email]>
>> From: "BJ Freeman" <[hidden email]>
>>> on a light side
>>> anything that a robot would need to know to get to and from something.
>>> :)
>>
>> Yes, for the moment areaId, aisleId, sectionId, levelId - needs
>> elevation -, positionId  are only references in OFBiz.
>> If we want to be able tro track their locations, we will need to
>> create new entities. Like Area, Aisle, Section, Level and
>> Position (no sure for the last), and so on (if needed)...
>
> I was suspecting something was wrong in my proposition but as I did not
> know what, I continued to search.
> I just realize reading http://docs.ofbiz.org/display/OFBENDUSER/Products
> that <<areaId, aisleId, sectionId, levelId - needs
> elevation -, positionId  are only references in OFBiz.>> because they
> are all *FacilityLocations* ! So please forget this comment :/
>
> Tomorrow, I will open a Jira issue an create a patch for the options
> discussed so far. I hope to apply it this week...
>
> A question though : this is an interesting concept as it is unlimited (i
> f needed in your warehouse you can add something under position, or
> between section and aisle, etc.).
> But I know that in Neogia they have used another approach to have a
> knowledge of what is in what (a section is a part of an aisle which is
> itself a part of an area, etc.).
> I wonder now why they did not use the OFBiz model, any memories, ideas ?
>
> Thanks
>
> Jacques
> PS : http://docs.ofbiz.org/display/OFBENDUSER/Products is certainly one
> of the most interesting part of the user documentation I read (I must
> acknowledge I did not read it all). There is only maybe some
> informations missing in .2.3.9.12 Features. On how to apply features to
> create variants I mean. And wich type (selectable) to use for them to
> allow the final user (or CS employee) choice in dropdowns.
>
>
>
>> Note :
>> GPS precision is nowaday +-3 meters
>> Galilleo's Commercial Service will be less than 1 meter
>> and intiatives like Teria (from French land surveyors association)
>> allow already centimetric precision
>> http://www.geometre-expert.fr/www/cmsMng.do;jsessionid=D843CB3022F8CF13D26277C7D48CA1DF?ID_PAGE=11377&ID_RUBRIC=13.
>>
>>
>> Before I translate all this in entitymodel files. I'd like this
>> possibility discussed.
>>
>> Thanks
>>
>> Jacques
>>
>>
>>> Jacques Le Roux sent the following on 8/10/2008 2:56 PM:
>>>> From: "David E Jones" <[hidden email]>
>>>>>
>>>>> On Aug 8, 2008, at 3:33 PM, Jacques Le Roux wrote:
>>>>>
>>>>>>> From: "BJ Freeman" <[hidden email]>
>>>>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
>
>
>

[BJ Freeman]

using the new feature that Adrian has introduced.
you can use something like
http://www.zipinfo.com/search/zipcode.htm
to get pertinent information.
this is only good for US.
it was the implementation of Adrians feature I as more thinking about.

Jacques Le Roux sent the following on 8/17/2008 1:52 PM:

> From: "Jacques Le Roux" <[hidden email]>
>> From: "BJ Freeman" <[hidden email]>
>>> on a light side
>>> anything that a robot would need to know to get to and from something.
>>> :)
>>
>> Yes, for the moment areaId, aisleId, sectionId, levelId - needs
>> elevation -, positionId  are only references in OFBiz.
>> If we want to be able tro track their locations, we will need to
>> create new entities. Like Area, Aisle, Section, Level and
>> Position (no sure for the last), and so on (if needed)...
>
> I was suspecting something was wrong in my proposition but as I did not
> know what, I continued to search.
> I just realize reading http://docs.ofbiz.org/display/OFBENDUSER/Products
> that <<areaId, aisleId, sectionId, levelId - needs
> elevation -, positionId  are only references in OFBiz.>> because they
> are all *FacilityLocations* ! So please forget this comment :/
>
> Tomorrow, I will open a Jira issue an create a patch for the options
> discussed so far. I hope to apply it this week...
>
> A question though : this is an interesting concept as it is unlimited (i
> f needed in your warehouse you can add something under position, or
> between section and aisle, etc.).
> But I know that in Neogia they have used another approach to have a
> knowledge of what is in what (a section is a part of an aisle which is
> itself a part of an area, etc.).
> I wonder now why they did not use the OFBiz model, any memories, ideas ?
>
> Thanks
>
> Jacques
> PS : http://docs.ofbiz.org/display/OFBENDUSER/Products is certainly one
> of the most interesting part of the user documentation I read (I must
> acknowledge I did not read it all). There is only maybe some
> informations missing in .2.3.9.12 Features. On how to apply features to
> create variants I mean. And wich type (selectable) to use for them to
> allow the final user (or CS employee) choice in dropdowns.
>
>
>
>> Note :
>> GPS precision is nowaday +-3 meters
>> Galilleo's Commercial Service will be less than 1 meter
>> and intiatives like Teria (from French land surveyors association)
>> allow already centimetric precision
>> http://www.geometre-expert.fr/www/cmsMng.do;jsessionid=D843CB3022F8CF13D26277C7D48CA1DF?ID_PAGE=11377&ID_RUBRIC=13.
>>
>>
>> Before I translate all this in entitymodel files. I'd like this
>> possibility discussed.
>>
>> Thanks
>>
>> Jacques
>>
>>
>>> Jacques Le Roux sent the following on 8/10/2008 2:56 PM:
>>>> From: "David E Jones" <[hidden email]>
>>>>>
>>>>> On Aug 8, 2008, at 3:33 PM, Jacques Le Roux wrote:
>>>>>
>>>>>>> From: "BJ Freeman" <[hidden email]>
>>>>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
>
>
>

[Jacques Le Roux-2]

This is related to https://issues.apache.org/jira/browse/OFBIZ-1923

I don't know for Yahoo and other, but I guess it's the same than for Google. You need a key to use their Map API. For Google this
key is related to the domain used and allow to use the API only on this domain. So we need to store this information somewhere. I
think about general.properties

Jacques

[Jacques Le Roux]

Hi,

I'm trying to finally commit our GoePoint entities related modelling. For that, I need to introduce the Google Map API key concept
(a key corresponding to an URL). I previsously suggested general.properties. But maybe an entity like the one below would be more
convenient in case the user would have to deal with more than an handle of URLs

  <entity entity-name="GoogleMapApiKey" package-name="org.ofbiz.common.geo" default-resource-name="CommonEntityLabels"
    title="Google Map API key">
    <field name="UrlId" type="id"></field>
    <field name="ApiKey" type="long-varchar"></field><!-- As generated from UrlId at
http://code.google.com/intl/fr/apis/maps/signup.html, note that it works for http://localhost !-->
    <prim-key field="UrlId"/>
  </entity>

What do you think ?

Thanks

Jacques

From: "Jacques Le Roux" <[hidden email]>
> This is related to https://issues.apache.org/jira/browse/OFBIZ-1923
>
> I don't know for Yahoo and other, but I guess it's the same than for Google. You need a key to use their Map API. For Google this
> key is related to the domain used and allow to use the API only on this domain. So we need to store this information somewhere. I
> think about general.properties
>
> Jacques