Hi Cédric,
thanks for the patches. >>> 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 :-) If the map is LCC projection and you do not notice any error, you are probably saved by the small area the map covers. Pay attention to the bottom right corner. The error should be worst in this corner. When I started to write this software I had no knowledge about projections at all. I simply assumed that referencing a point on the map is done by applying an offset and a scale factor to the pixel based on the top left corner of the map. For Mercator like maps this is true. However with LCC you have to apply a rotation, too. And that means quite some work on all map classes. >>> 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. >> >>> 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. >> 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 ------------------------------------------------------------------------------ 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
