Re: [Qlandkartegt-users] Aero-nautical units and route elevation support (willing to contribute)

[Cédric <ced...@ce...>]

Hello Oliver

On 20/03/12 21:40, Oliver Eichler wrote:
> Hi Cédric,
>
[...]
>>>> A. Should I add a new "CUnitAeroNautic" class or should I modify the
>>>> "CUnitNautic" one?
>>>> PS: I'm not aware of any use of "Nautical" units out of the sea-faring
>>>> and sky-faring realms. Sea-faring users don't use elevation data (and
>>>> should not care about which unit is being used). Sky-faring users
>>>> always
>>>> use elevation in feet (ICAO standard).
>>> That's a valid point. I think you can change the elevation in
>>> CUnitNautic to feet.
>> Done
>
> Patch applied and committed.
Thanks!
>
>>>
>>>> B. Should I modify the "CRoute::addPosition" method to handle a new
>>>> "altitude" field (and modify all call to this method accordingly) or
>>>> would you rather have me create a new "CRoute::setAltitude" method (to
>>>> be called after "CRoute::addPosition" when relevant, e.g. in
>>>> "CDlgWpt2Rte::accept") ?
>>> Change CRoute::addPosition(). Use WPT_NOFLOAT whenever the elevation
>>> is unknown.
>> I eventually opted for a separate "CRoute::addWaypoint", which is less
>> intrusive and more elegant for waypoints support
>>>> C. When exporting a route to GPX, each route point "<RtePt>" is named
>>>> numerically (sequentially) and the original waypoints' name is
>>>> lost. Can
>>>> we imagine keeping the original (waypoint) name, knowing that the
>>>> order
>>>> of route points is implicit, in the containing vector (in CRoute)
>>>> or in
>>>> the GPX file ?
>>> Hm depends. The current numbering is a tribute to Garmin devices.
>>> They create a waypoint for every route point and the numbering helps
>>> to keep them together. Thus it's better to make this an option.
>> The way I did this, the change is noticeable only during GPX export of
>> routes created using selected waypoints in QLGT. I guess this should
>> spare side-effects on GPS devices (unless the CRouteDB::saveGPX method
>> is used during the upload of routes; I haven't checked that far).
>
> It is used for upload routes. And there is another problem. You have
> to handle the additional information in the serialization operators <<
> and >>. See CRoute.cpp. The tricky part is not to break backward
> compatibility. As the route points are serialized one after the other
> they are not extendible. Bad design :(. Thus I would suggest to open a
> new section type. See CRoute::type_e.
Ha! Ok.

I've been thinking of this "QLGT" fully-fledge routes support.

As I see it, I we want to start the right way and provision for the
widest "horizons", I think we should consider the "extended" CRoute as a
*collection of ordered CWpt*.
Maybe it would even make sense to have a new CRtePt, derived from CWpt.
Doing so would have the advantage of-reusing the implementation of CWpt
(methods, fields, serialization, etc.) and re-use existing code with
minimal changes for all the new features that may come on top of
CRtePt-based CRoutes (most of which coming done to CWpt-like manipulations).

Then, to retain backward compatibility, we keep the current CRoute::pt_t
implemenation exactly as is it, except for an *additional* CRtePt field
(which may potentially remain undefined).
Backward compatibility is maintained in regards with existing pt_t usage.

As soon as a CRtePt field is used (defined) in a CRoute
(CRoute::addWaypoint), we switch type from "eRtePts" to "eRteWpts"
(thanks to a new "CRoute::isRteWpts" flag) and we handle serialization
accordingly.
In other words: a "eRtePts" route can *not* contain any CRtePt; a
"eRtePts" contains *at least* a CRtePt (but not all the CRoute::pt_t may
have it defined; this has to be tested each time one wants to use the
CRtePt of a pt_t).
Existing "eRtePts" can still be (un-)serialized. As soon as a CRtePt is
used, we switch "eRteWpts" (un-)serialization.
Backward compatibility is maintained in regards with serialization.

Now comes the question of when to use the available CRtePt data. I'd say
that as soon as we use waypoints to create a route, we create a new
CRtePt. This can not hurt as CRtePt do no affect the behavior of pt_t.
If I get it right, the potential problems lie when "exporting" the route
to a device.
I'd say that we (somehow) add a flag to CRouteDB::saveGPX which tells it
whether the generated GPX file should include all (available) CRtePt
data (as I did it in my 'waypoints_route' patch) or if it should retain
its "legacy" behavior (known to be compatible with devices).
As I understand it, this flag should be used only when "Exporting geo-data".
CRouteDB::loadGPX, on the other hand, should parse all GPX standard tags
(not the unstandardized extensions) in order to build the most complete
CRtePt as possible.
Backward compatibility is maintained in regards with devices.

PS: some (compatible) devices may actually benefit from the "extended"
CRoute; e.g. proximity distance for each route point, different symbol,
etc. Meaning: let's implement the "extended" saveGPX flag in such a way
that it can be set when exporting to those devices (how could this be
achieved?).

Once we settle on a proper design for an extended "CRoute", we'll have
the doors wide open to add all kind of nice features around QLGT
CRoutes. What I have in mind based on the software I had been using so far:
 - create/extend routes by using (adding) defined waypoints (both from
the map of the waypoints tree on the left); this means we must have the
mean to select a route as the "destination" for such actions
 - create/extend routes by loading GPX routes (or concatenating another
route); an existing route being "extended" thanks to a right-click
contextual menu entries ("load...", "concatenate...")
 - fully-fledged route edition (route name, waypoints order, waypoints
deletetion, waypoints edition)
(or "my own personal roadmap" :-) )

Does all of this make sense?

Cheers,

Cédric
>
>
>>> The route stuff is still pretty mediocre as I do not really use it.
>>> There is no real concept to edit and change routes so far. If you
>>> feel like it you could implement something similar like the edit
>>> dialog for distance overlays. That would enable the user to edit the
>>> name, comment (action) and icon of a route point. You would make
>>> yourself a few friends with that :)
>> I might have a look at this.
>>
>> I was also thinking of allowing to create a route by right-clicking on a
>> waypoint and having a new contextual menu entry dubbed "Add to route".
>> (this would spare the reording of waypoints when using "make route..."
>> with selected waypoints).
>
> Ok.
>
>
> Oliver
>