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" <[EMAIL PROTECTED]>
>> From: "BJ Freeman" <[EMAIL PROTECTED]>
>>> 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" <[EMAIL PROTECTED]>
>>>>>
>>>>> On Aug 8, 2008, at 3:33 PM, Jacques Le Roux wrote:
>>>>>
>>>>>>> From: "BJ Freeman" <[EMAIL PROTECTED]>
>>>>>>>> contact mech may not always be the same address and geopoint
>>>>>>>> for an address it will always have the same geopoint
>>>>>>>> 1) how do you connect an address that already exists with a New
>>>>>>>> ConactMech.
>>>>>>>> 2) how do you connect the assoicated Geopoint that goes with that
>>>>>>>> address.
>>>>>>> My last proposition should cover your previous demand. If you
>>>>>>> expire an address then the geo-point this address used (point to)
>>>>>>> would still exist but as the address is obsolete we don't have to
>>>>>>> care (this address and its associations should not be used
>>>>>>> anymore)
>>>>>>> Let see your new questions now:
>>>>>>> 1) Not sure to understand this one since an address is a type of
>>>>>>> ContachMech. Did you not used a word for another ?
>>>>>>> 2) PostalAddress.ContactMechId -> ContacMech ->
>>>>>>> ContacMech.TerrestialPositionId -> TerrestialPosition
>>>>>>
>>>>>> Sorry should have been PostalAddress.contactMechId -> ContacMech ->
>>>>>> ContacMech.terrestialPositionId -> TerrestialPosition
>>>>>
>>>>> Based on this and some other messages (lots of stuff getting thrown
>>>>> around), a proposal:
>>>>
>>>> Pretty neat !
>>>>
>>>>> 1. new entity called "GeoPoint" (to go along with Geo which is a
>>>>> geographic boundary) with geoPointId as a sequenced primary key,
>>>>> latitude and longitude floats, dataSourceId (just use the existing
>>>>> DataSource entity)
>>>>
>>>> I just want to add
>>>> . float precision : 6 decimals (but we are all ok about that anyway)
>>>> . Elevation as requested by BJ
>>>>
>>>>>
>>>>> 2. there is no need for Well-Known-Text on GeoPoint as it is more
>>>>> useful for describing a boundary, so let's put a wellKnownText
>>>>> field  on Geo instead of GeoPoint
>>>>>
>>>>> 3. for other entities that are at a single position add a geoPointId
>>>>> to them; this would include Facility, PostalAddress (but NOT
>>>>> ContactMech because most ContactMechs don't imply any position, and
>>>>> even for PostalAddress it is only the case sometimes)
>>>>
>>>> I will add
>>>> Container (not sure, as I don't know what it's used for exactly, on
>>>> trucks, railways, boats ?)
>>>> FacilityLocation
>>>> By the way what about location in warehouse ? Should we not give
>>>> attention to that (areaId, aisleId, sectionId, levelId - yes BJ
>>>> with elevation -, positionId )
>>>>
>>>> NOTE: maybe we miss some other entities here, please check
>>>>
>>>>> 4. for entities that need a series or history of positions add a join
>>>>> entity with the other entity's ID, a geoPointId, fromDate,
>>>>> thruDate,  etc; this would include FixedAsset, Party (applies to
>>>>> Person and  sometimes to PartyGroup, though some PartyGroups have
>>>>> no corporeal  form and so no location); for example add a
>>>>> FixedAssetGeoPoint entity  with fixedAssetId, geoPointId, and fromDate
>>>>> as the primary key and  thruDate as an additional field; note that it
>>>>> would go with in the  FixedAsset entity's package and is
>>>>> FixedAssetGeoPoint and NOT  GeoPointFixedAsset because the GeoPoint is
>>>>> the lower level entity and  just used to further describe
>>>>> the FixedAsset
>>>>
>>>> I was asking myself why a Party would need a geoPoint ? Why not use
>>>> her/his/its PostalAddress to related to a GeoPoint ? Of course,
>>>> if you would like to be able to know where a Person is in, for
>>>> instance,
>>>> her/his car you will need that... SFA might need that, yes
>>>> defintively ! Same for FixedAsset [boats, trucks, etc. ],
>>>> containers, etc.
>>>>
>>>> If everybody is ok I will create a patch for review soon.
>>>>
>>>> Jacques
>>>>
>>>>> -David
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
> 
> 
> 
> 

Reply via email to