Ooops... Hello Oliver,
Thank you for your quick response and sorry for my last message crossing yours (I had not seen your reply). On 20/03/12 14:59, Oliver Eichler wrote: > Hi Cédric, > >> I (will) actually use QLandKarte for aero-nautical route planning. >> Unfortunately, I'm missing two "features" to do so: > I hope you are aware that QLGT can only handle maps that have a rectangular > coordinate system. In other words: It's not able to display maps with a > Lambert Conformal Conic projection. Ok. Thanks for the clue! Actually, I have geo-referenced the latest swiss OACI map (using "+proj=lcc +ellps=bessel +lat_0=46.9524055556 +lat_1=46.9524055556 +lat_0=46.9524055556 +lon_0=7.4395833333") along with quadratic (6-points) referecing and the result is more than good enough for route planning (I have less than 2 pixel - ~0°0.01 - errors on any of the map grid intersections). If QLGT can't handle the LCC projection, then I guess the quadratic interpolation saved my day :-) > >> I'm thus more than willing to contribute to your project and send you >> the corresponding patches once I'm done (well, if you deem those >> modifications are interesting, of course ;-) ). > Always :) After all that's what open source is about. > >> 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 > >> 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). > 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). > Just be aware of the two faces of a route. There is a primary route with the > user supplied points connect with straight lines. And a secondary one that > has many intermediate points, derived from an auto-routing algorithm. It's > not trivial to handle both representations in a clean way. Then users may have a good time seeing what the auto-routing algorithm may come up with for flight routes! :-) > >> D. When exporting to GPX, it might be safer to use '<![CDATA[...]]>' >> constructs (to encapsulate name, comment and description data). Do you >> thing this could/should be changed as well ? > As the GPX files are UTF8 there shouldn't be a problem. And probably many GPS > devices will puke if they see a CDATA section. Additionally special > characters like < > & are already escaped. OK > Oliver > > Cheers Cédric ------------------------------------------------------------------------------ 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
