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" <[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)... > > 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 >>>> >>>> >>> >>> >>> >>> >> > > > >
