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" <[EMAIL PROTECTED]> >> 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 >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> >>> >> > > >
