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
