> 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).
Users have a different point of view :) As long as you accept the auto-routed path or as in your case you go straight lines, it's ok. But if it comes to hiking or bike tours, things are less deterministic. What is a nice route to walk or go by bike? No one can tell. Thus users want to plan their routes in detail and want to use it on their device. Right now this can't be done by any device. And the GPX specification does not provide guidance either. Users have to rely on tracks. But anyway, we can do better as long as we stay in the QLGT universe. And if we leave that we drop back to what GPX offers. > > 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.). I wouldn't trust it either :) >> 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. I agree. >> 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! Yes, keep it simple. I would save each point in it's own section. By that it can be extended easily. 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
