Hi all, On Fri, 2010-10-08 at 16:14 -0400, Eric Perko wrote: > What additions to a GPS message would make it easier to interface to > googlemaps? I think we should treat Google Maps and the like as what they are, part of the user interface/presentation layer that clearly shouldn't influence how core layers represent GPS/GNSS data. Any sound internal representation will enable conversion to whatever format the UI expects. > I think it is very important to split the message into basic chunks > and build composite messages of that with indicators of whether or not > to use the data. Agreed. I guess we could flag each data point as, say, "original" (calculated by the receiver), "derived" (in software) or "unavailable". > This is especially important for non-GPSd devices - I have a GPS unit > that currently only outputs lat/long/altitude, standard deviations on > each of those in meters, a fix type and number of satellites used. > This would leave some of the fields empty in the current GPSd message > with no way to say whether or not they should be used. Do we really > need both dilution of precision information and the err* fields or can > one be derived from the other? Dilution of precision is a fairly theoretical value: It is computed solely from the geometrical configuration (as seen by the receiver) of the satellites used in the positioning solution. So, it's merely a lower bound on the expected error but doesn't necessarily reflect the magnitude of the actual error. The err* fields should ideally be derived from the covariance matrix of the receiver-internal Kalman filter, thus representing what the receiver thinks the actual error currently is. > I think it would be best to actually have a GPS position message that > includes both the fix itself and status information. Anytime I've used > GPS, we've always needed the status information to tell us whether or > not to even believe the fix information at all, so I'm not sure how > useful an optional status is. Agreed. In my experience an optional status isn't useful in practice. > Is there a datum and/or ellipsoid that many others can be converted > to? Offhand I can't think of any reason why you couldn't convert arbitrarily between different representations as far as individual points are concerned. Preserving distance information would be a different story. Which relevant representations are there in practice though? On the user visible and interface layers GPS is pretty "hard wired" to WGS84 (due in part to the ubiquitous use of NMEA). ECEF (Earth-centered, Euclidean) is popular as the state representation used by the receiver-internal Kalman filter. > I think it would be best to specify one for this message so that any > tools such as the gpsd_viewer only have to worry about one datum and > ellipsoid. I agree in general. I would add the following requirement though: The ROS driver should retrieve data in the format used by the receiver internally (if possible by any means) and use a well documented/understood software routine to do the conversion. I have seen receivers where the conversion from the internal ECEF datum to WGS84 apparently lost precision. Cheers, Rene -- ------------------------------------------------------------ Dipl.-Inf. René Wagner Junior Researcher DFKI Bremen Enrique-Schmidt-Str. 5 Safe and Secure Cognitive Systems D-28359 Bremen Phone: (+49) 421-218-64224 Fax: (+49) 421-218-98-64224 Email: Rene.Wagner@dfki.de Web: http://www.dfki.de/sks --- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Deutsches Forschungszentrum für Künstliche Intelligenz GmbH Firmensitz: Trippstadter Strasse 122, D-67663 Kaiserslautern Geschäftsführung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern HRB 2313 ------------------------------------------------------------