Hello Oliver, On 21/03/12 16:34, Oliver Eichler wrote: > Hi Cédric, > > routes are the widows of the GPS world :) What you picture is usually done > with tracks and waypoints. You follow a track and if you get close to a > waypoint you get some information. Routes usually are created by simply > selecting waypoints as start, intermediate and end point. And then the device > does some magic and guides you. > > In the dominant Garmin world you can calculate whatever route you want and > transfer it to the device. The device will ignore it and calculate it's own. > That is the reason for the primary route (only the few points to define a > route) and the secondary route (the calculation on the PC). If you transfer a > secondary route on a Garmin the thing goes berserk.
Thanks for your those explanations. Actually, I think one shall not mix the definition of "routes" and "tracks". Unless I'm utterly mistaken, "routes" are by definition a /collection of (a few) waypoints/ to go from A to B, while "tracks" detail (as accurately as possible) the /path/ from A to B (either based on the data saved during a former journey or generated by some nifty Internet service). In the sea- and sky-faring worlds (based on my experience of both), users still rely on "routes" - collections of (a few) waypoints - maybe for the simple reason that sea/sky navigation comes down to following straight lines between landmarks. PS: As crazy as it may sound, GPS are still not officially accepted as a navigation device in airplanes. They are still considered as not reliable enough for "critical" usage (in regards with their variable accuracy or the potential loss of signal in bad weather). Differential GPS is being looked into by the ICAO, and only as an _additional_ mean of nagivation (in addition to NDB, VOR/DME, ILS, etc.). All of this meaning that pilots are still _required_ (in the sense that if they don't and they have an accident or violate an airspace, this will be held against them) to plan their route the "old way" (that is: using landmarks and radio facilities as waypoints). That planning must also take into account altitudes, both to make sure that one does not violate some airspace and to provision for climb/descent times/performances. Thus, many pilots use software like QLGT to plan their route and then report all its waypoints on a sheet of paper (including heading, distance and estimated ellapsed time between each waypoint), which will be then used as the "navigation sheet" during the flight. Actually, I personally use a OpenOffice and a custom macro which allows me to import a GPX route directly in my "Flight Plan" OOWriter template (I'd rather spend days and nights configuring/developing the required tools for my Linux tablet rather than buying the latest Jeppesen software and database for an iPad... crazy me :-D ). But all this is slighty off-topic :-) > As Garmin is dominant, their point of view influenced the definition of the > GPX format. GPX lacks structure to store a calculated route. In fact the > track structure would make a much better container for high sophisticated > routes. It might be that the GPX format was inspired by the ideas of "routes" and "tracks" as described above. Then everything "falls into place" quite well. > In QLGT you can place waypoints close to trackpoints and QLGT will attach > these points with the track and create what is commonly called a roadbook. > This is a loose coupling just by distance. If a device, like the Sportiva, > supports close coupling of waypoints and tracks the export handler should > convert the data in what ever format is needed. > > Now for routes. I do not think that a routpoint should be derived from CWpt. > CWpt is huge. A waypoint can store geocaches, pictures, epic poems. Whatever! > I wouldn't want to deal with that on routes. And I want to change CWpt > without caring about routes. Imho the simple GPX representation of a waypoint > should be enough for a routepoint. OK. In order to have a clean/extendable design, I think I shall still create a new CRtePt class, inspired (but not derived) from the existing CWpt. I'll go through the GPX specs again and make sure we have everything we need. > Concerning backward compatibility: It's enough to read older versions. I do > not want to carry the burden to save data readable for old and new versions > of QLGT. This is free software. Users must update frequently. Thus you can > restructure the writing part of serialization completely and append the > reading part. Ok. Nice! makes it simpler! > Export mode ore not: there is already CGpx::exportMode that flags that > controls the amount of data stored in a GPX file. Device export is > eCleanExport. Great! Then I have all I need! Thanks for your time and explanations. I'll come back to you as soon as I have some new patches ready. Have a good evening, Cédric > Oliver > ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Qlandkartegt-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qlandkartegt-users
