<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="http://git.reviewboard.kde.org/r/109379/">http://git.reviewboard.kde.org/r/109379/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On April 15th, 2013, 5:17 p.m. UTC, <b>Bernhard Beschow</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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". :)</pre>
</blockquote>
<p>On April 16th, 2013, 4:53 p.m. UTC, <b>Roman Karlstetter</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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).</pre>
</blockquote>
<p>On April 16th, 2013, 5 p.m. UTC, <b>Bernhard Beschow</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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!</pre>
</blockquote>
<p>On April 25th, 2013, 7:04 p.m. UTC, <b>Bernhard Beschow</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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.</pre>
</blockquote>
<p>On April 25th, 2013, 9:21 p.m. UTC, <b>Roman Karlstetter</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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?
</pre>
</blockquote>
<p>On April 26th, 2013, 3:40 p.m. UTC, <b>Bernhard Beschow</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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.</pre>
</blockquote>
<p>On April 27th, 2013, 11:50 a.m. UTC, <b>Dennis Nienhüser</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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)
</pre>
</blockquote>
<p>On April 27th, 2013, 12:56 p.m. UTC, <b>Bernhard Beschow</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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. :)</pre>
</blockquote>
<p>On April 27th, 2013, 1:25 p.m. UTC, <b>Roman Karlstetter</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I've one question regarding the hierarchy of GeoDataObjects. This is just to make sure that I understand things right, are the following things right more or less?
GeoDataDocument corresponds to GPX-Document.
GeoDataPlaceMark and GeoDataMultiGeometry correspond to GPX-Track, so, the trk-tag.
GeoDataTrack corresponds to GPX-Segment, so, the seg-tag.
If it's like that, then, at the moment, there is one entry not only for every track, but even for every segment, which might not make too much sense.</pre>
</blockquote>
<p>On April 27th, 2013, 2:49 p.m. UTC, <b>Roman Karlstetter</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Ok, I implemented joining tracks on the datamodel side, this is cleaner (you would have to join it anyway in the floatitem). I set the altitude to 0 between tracks (this should ne a good indication that there is no data available for this part), but just joined segments for one track. I also added the tracks separately to the menu.
Now it's your choice for the Menu :) Should there be one entry:
#1 per file
#2 per track, I use the track names now (GPX trk-tag)
#3 per segment (GPX seg-tag)
#4 or even one per track + one for complete file?</pre>
</blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">> I set the altitude to 0 between tracks
Where is this needed assuming that the tracks are joined w/o gaps?
My Menu (note the capital "M";) of choice would be #1 for ease of recognition. Because if I open a file called "Foo.gpx" I'd expect to find an entry "Foo.gpx" in the (context) menu.</pre>
<br />
<p>- Bernhard</p>
<br />
<p>On April 16th, 2013, 5:19 p.m. UTC, Roman Karlstetter wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('http://git.reviewboard.kde.org/static/rb/images/review_request_box_top_bg.ab6f3b1072c9.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for Marble and Bernhard Beschow.</div>
<div>By Roman Karlstetter.</div>
<p style="color: grey;"><i>Updated April 16, 2013, 5:19 p.m.</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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 :) </pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>src/plugins/render/elevationprofilefloatitem/ElevationProfileContextMenu.h <span style="color: grey">(PRE-CREATION)</span></li>
<li>src/plugins/render/elevationprofilefloatitem/CMakeLists.txt <span style="color: grey">(872e5e1)</span></li>
<li>src/plugins/render/elevationprofilefloatitem/ElevationProfileContextMenu.cpp <span style="color: grey">(PRE-CREATION)</span></li>
<li>src/plugins/render/elevationprofilefloatitem/ElevationProfileDataSource.h <span style="color: grey">(PRE-CREATION)</span></li>
<li>src/plugins/render/elevationprofilefloatitem/ElevationProfileDataSource.cpp <span style="color: grey">(PRE-CREATION)</span></li>
<li>src/plugins/render/elevationprofilefloatitem/ElevationProfileFloatItem.h <span style="color: grey">(cb3bff1)</span></li>
<li>src/plugins/render/elevationprofilefloatitem/ElevationProfileFloatItem.cpp <span style="color: grey">(7cb3428)</span></li>
</ul>
<p><a href="http://git.reviewboard.kde.org/r/109379/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>