Bug 288662

Summary: Elevation Profile breaks OSM Vector Rendering
Product: [Applications] marble Reporter: Florian Eßer <f.esser>
Component: generalAssignee: marble-bugs
Status: RESOLVED FIXED    
Severity: normal    
Priority: NOR    
Version: unspecified   
Target Milestone: 1.3 (KDE 4.8)   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In: 1.3.0
Attachments: Screenshot showing the problem. (For better visibility, I chose a map theme with only white tiles at this zoom level)

Description Florian Eßer 2011-12-10 15:31:26 UTC
Created attachment 66597 [details]
Screenshot showing the problem. (For better visibility, I chose a map theme with only white tiles at this zoom level)

Version:           unspecified (using KDE 4.7.3) 
OS:                Linux

If the Elevation Profile plugin is activate, the placemark labels of OSM Vector Rendering (Great feature, btw!) are rendered between the "normal" map tiles and the vector layer and thus are not visible.
Hiding the Elevation Profile restores the placemark labels back to the top layer.

Reproducible: Always

Steps to Reproduce:
Download a small area in JOSM, save as *.osm, open in Marble.

Enable the Elevation Profile --> the placemarks disappear.

At the borders of your downloaded *.osm file, they are still visible, but behind the vector layer.

Disable Elevation Profile --> placemarks are displayed correctly.

Actual Results:  
Invisible Placemarks if Elevation Profile Plugin is active.

Expected Results:  
Visible Placemarks even with Elevation Profile Plugin active.

compiled from Git revision 423d6c01
Comment 1 Florian Eßer 2011-12-10 18:36:53 UTC
Git commit 2a4b0bd028a89509a6b0dd6798be2b886d4535cd by Florian Eßer.
Committed on 10/12/2011 at 19:29.
Pushed by esser into branch 'bugfix'.

Put occupants of HOVERS_ABOVE_SURFACE layer into a defined z-order

Both the GeometryLayer and the PlacemarkLayout are rendered in the layer
HOVERS_ABOVE_SURFACE, but neither had a zValue set, so defaulting to 0.0

According to LayerInterface.h:62: "If both have the same z value, their
paint order is undefined." By chance, the PlacemarkLayout was always
drawn above the GeometryLayer and everything worked out just fine.

When the Elevation Profile's "red flag thingy" came along as a third
player on the HOVERS_ABOVE_SURFACE layer, the dice fell the other way
around and suddenly the placemarks were rendered beneath the geometry.

Thanks for the help, Thibaut!
BUG: 288662
FIXED-IN: 1.3.0

M  +5    -0    src/lib/layers/PlacemarkLayout.cpp
M  +5    -0    src/lib/layers/PlacemarkLayout.h
M  +5    -0    src/lib/routing/RoutingLayer.cpp
M  +3    -0    src/lib/routing/RoutingLayer.h
M  +1    -1    src/plugins/render/elevationprofile/ElevationProfileFloatItem.cpp

http://commits.kde.org/marble/2a4b0bd028a89509a6b0dd6798be2b886d4535cd
Comment 2 Florian Eßer 2011-12-10 18:47:06 UTC
Git commit 1c1fd92a5166cd20d5e2096cf11d56072728fe8c by Florian Eßer.
Committed on 10/12/2011 at 19:29.
Pushed by esser into branch 'master'.

Put occupants of HOVERS_ABOVE_SURFACE layer into a defined z-order

Both the GeometryLayer and the PlacemarkLayout are rendered in the layer
HOVERS_ABOVE_SURFACE, but neither had a zValue set, so defaulting to 0.0

According to LayerInterface.h:62: "If both have the same z value, their
paint order is undefined." By chance, the PlacemarkLayout was always
drawn above the GeometryLayer and everything worked out just fine.

When the Elevation Profile's "red flag thingy" came along as a third
player on the HOVERS_ABOVE_SURFACE layer, the dice fell the other way
around and suddenly the placemarks were rendered beneath the geometry.

Thanks for the help, Thibaut!
BUG: 288662
FIXED-IN: 1.3.0

M  +5    -0    src/lib/layers/PlacemarkLayout.cpp
M  +5    -0    src/lib/layers/PlacemarkLayout.h
M  +5    -0    src/lib/routing/RoutingLayer.cpp
M  +3    -0    src/lib/routing/RoutingLayer.h
M  +1    -1    src/plugins/render/elevationprofile/ElevationProfileFloatItem.cpp

http://commits.kde.org/marble/1c1fd92a5166cd20d5e2096cf11d56072728fe8c