[Marble-devel] Review Request 109379: ElevationProfile: support for gpx-tracks
Bernhard Beschow
bbeschow at cs.tu-berlin.de
Sat Apr 27 12:56:31 UTC 2013
> On April 15, 2013, 5:17 p.m., Bernhard Beschow wrote:
> > Thanks for the patch, looks really nice! Two nitpicks, though: I get every track listed twice in the menu, I wonder why this happens. Morevoer, the elevation profile doesn't display the relevant interval of V-shaped tracks when the bottom edge of the V isn't visible. When these issues are fixed, I'd give you a "Ship it". :)
>
> Roman Karlstetter wrote:
> Could you please send me a file for which this happens? Because I can't reproduce this with the files I have.
> The same holds for the second point (even if I'm not completely sure that I understood it correctly).
>
> Bernhard Beschow wrote:
> I'll check this later. Could you please add "marble" to the group of reviewers, please? It seems as if our conversation is private, i.e. isn't distributed to Marble's developer mailing list. Thx!
>
> Bernhard Beschow wrote:
> How to reproduce that a .gpx file is shown more than once:
> 1) Start Marble (KDE version, latest master)
> 2) Enable the elevation profile float item
> 3) Open examples/gpx/mjolby.gpx from the Marble source code
> Observe that mjolby.gpx is present more than once in the float item's context menu (6 times in my case)
>
> Continue with reproducing an empty float item although the track is clearly visible:
> 4) Enable "Zoom to viewport" in the context menu
> 5) Center on Vikingstad on tile level 14
> 6) Keeping that zoom level, follow the track along the highway in western direction until road "206" is crossed
> 7) Follow the track along this road to Skänninge
> Observe that the float item eventually says: "Not enough points in the viewport" although the track is clearly visible.
>
> Roman Karlstetter wrote:
> Just by only looking at the .gpx-file, it was clear to me why this happens:
> It has more than one trk. So, both issues are actually only one: For every track in the file, there is one entry in the menu, not just one single for every file.
> Some alternatives:
> - show one entry per file by just joining the tracks to one GeoDataLineString. However, between the tracks, there are, of course, jumps in the position, which cannot really be displayed correctly by the elevation profile plugin. This might produce strange results for big jumps (imagine: two tracks that are 1km long each, but one is in munich and the second one in paris. In the elevation profile, you would basically only see the large jump, but as a straight line going down from the height of munich (~500m) to the one of paris(~100m)).
> - leave as is, displaying one entry per track. This is not so easy to understand for the user.
> - add the functionality to the elevationprofile to display many GeoDataLineStrings. This would make things much more complicated and off the top of my head I don't know how to visualize the jump in the elevationprofile, apart from the obvious "display nothing in the jump area"-solution.
>
> Opinions?
>
>
>
> Bernhard Beschow wrote:
> I prefer solution #3 because it relates one elevation profile with one .gpx file. Personally, I wouldn't mind a gapless elevation profile, even if the individual entries have gaps.
>
> Dennis Nienhüser wrote:
> I'd prefer #2 (leave as is) for the short term.
>
> In the long run I'd rather have more interaction with geodata objects themselves so that they can be selected in the shared tree model (already possible) and the selection would be indicated by the styling of the geodata object in the map. Tree model and geoscene should share their selection models so that selecting a geodata object in the map selects it in the tree model and vice versa. The elevation profile float item then would not need to provide a context menu based selection, but just display the currently selected geodata object in case it is some sort of linestring. Consequences for the user:
> - Interact with the route and its height profile is shown in the float item
> - select a track in the Files dock and its height profile is shown directly
> - select a track in the map and its height profile is shown directly
> - select a file / multitrack in the Files dock and the gapless elevation profile of all child linestrings merged as suggested by Bernhard above are shown. Other behavior would be possible as well here of course (e.g. ignore it, or show first track and use context menu for switching)
>
I prefer solution #3, also for the short term. When I record a (bicylcle) trip, I usually switch off GPS when having a bigger break to save the battery. This will split the track, but I'd still like to be able to view the whole elevation profile that I conquered. :)
- Bernhard
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/109379/#review31110
-----------------------------------------------------------
On April 16, 2013, 5:19 p.m., Roman Karlstetter wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/109379/
> -----------------------------------------------------------
>
> (Updated April 16, 2013, 5:19 p.m.)
>
>
> Review request for Marble and Bernhard Beschow.
>
>
> Description
> -------
>
> Changes to the elevation profile plugin, it's now possible to display the height profile for a GPX-track opened from file.
>
> I made a new classes for
> a) providing the data, one for routes and one for tracks. They are in the same file, should this be split into multiple files?
> b) the contextmenu, because it has some members which would only clutter ElevationProfileFloatItem. It is a friend class, is this ok?
>
> Comments please :)
>
>
> Diffs
> -----
>
> src/plugins/render/elevationprofilefloatitem/ElevationProfileContextMenu.h PRE-CREATION
> src/plugins/render/elevationprofilefloatitem/CMakeLists.txt 872e5e1
> src/plugins/render/elevationprofilefloatitem/ElevationProfileContextMenu.cpp PRE-CREATION
> src/plugins/render/elevationprofilefloatitem/ElevationProfileDataSource.h PRE-CREATION
> src/plugins/render/elevationprofilefloatitem/ElevationProfileDataSource.cpp PRE-CREATION
> src/plugins/render/elevationprofilefloatitem/ElevationProfileFloatItem.h cb3bff1
> src/plugins/render/elevationprofilefloatitem/ElevationProfileFloatItem.cpp 7cb3428
>
> Diff: http://git.reviewboard.kde.org/r/109379/diff/
>
>
> Testing
> -------
>
>
> Thanks,
>
> Roman Karlstetter
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/marble-devel/attachments/20130427/39df4680/attachment.html>
More information about the Marble-devel
mailing list