[Qgis-user] Layer Ordering for KMZ

Jeff Sonnentag jsonnentag at llenviroinc.com
Sun Aug 15 08:12:05 PDT 2021


I have read other people’s solutions to the problem in the past and they recommended setting the clamp elevation to various levels above the surface in order to try forcing apparent render order.  It seemed to mostly work.  But I will definitely have to try the <gx:drawOrder> mentioned in another response too.  You just probably can’t do that from within Google Earth and have to hunt through a lot of KML the locations to insert things.


From: Qgis-user <qgis-user-bounces at lists.osgeo.org> On Behalf Of Charles Dixon-Paver
Sent: Sunday, August 15, 2021 6:54 AM
To: krishna Ayyala <ayyalakrishna at gmail.com>
Cc: qgis-user <qgis-user at lists.osgeo.org>; Andrea Giudiceandrea <andreaerdna at libero.it>
Subject: Re: [Qgis-user] Layer Ordering for KMZ

I just had a chance to look at the samples and it seems my hypothesis was in fact correct.

I had expected that because Google Earth functions in 3D that it may perhaps render placemarkl symbols based on the orientation of the "camera" to the point, but from my assessment it definitely seems that altitude is the deciding factor when it comes to determining the rendering order of symbols.

By exporting the big points with "clamptoground" active, but using the relative to ground and altitude addend functionality in the KML tools export (see screenshot.png), the small points are "higher" in altitude and render on top of the big points regardless of orientation. In the example I provided (desired_output.kmz) I "lifted" the small points 25m off the ground.

By using the $x and $y attributes on the supplied shp data in QGIS, it became apparent that there were some offsets between the point positions:

Small Points
Big Points
wkt_geom
id
Name
x
y
wkt_geom
id
Name
x
y
Point (-98.94705168629492675 29.6341226203915511)
1
A
-98.94705168629493
29.63412262039155
Point (-98.94705168490899894 29.63412262285223875)
1
E
-98.947051684909
29.63412262285224
Point (-98.93203732506144377 29.63666293420626374)
2
B
-98.93203732506144
29.636662934206264
Point (-98.9320373399207682 29.63666292869620733)
2
F
-98.93203733992077
29.636662928696207
Point (-98.94352477360057208 29.62202767741294451)
3
C
-98.94352477360057
29.622027677412945
Point (-98.94352558873751491 29.62202773383394927)
3
G
-98.94352558873751
29.62202773383395
Point (-98.92999000422139488 29.62559164108440513)
4
D
-98.9299900042214
29.625591641084405
Point (-98.92998992924056267 29.62559174501802062)
4
H
-98.92998992924056
29.62559174501802


I expect the reason "some" points rendered on top and not others, is that the slight positional offset would have likely ended up giving the points different altitudes based on the "clamp to ground" positions.

There are a number of approaches you can utilise to resolve this issue, depending on your needs. One is to export the KMZ with a multilayer symbol from QGIS (the style will become a single png), if you intend on using the same geometries. This would yield a more consistent result, however it of course would not work on different layers.

I have attached a zip file (kmz_data.zip) with the following elements for your review:

  *   screenshot.png - KML Tools export settings for increasing point position from ground
  *   desired_output.kmz - The desired output as expressed by OP
  *   points_big_clamped_to_ground.kmz - Big points layer exported with clamp to ground and used in desired output
  *   points_single_symbol_one.kmz - A multilayer QGIS symbol used in a KMZ
  *   points_single_symbol_one.qml - A QML style for anyone unfamiliar with multisymbol styles
  *   points_single_symbol_two.kmz - A multilayer QGIS symbol with offset applied to get a style closer to original kmz
  *   points_small_with_altitude.kmz  - Small points layer exported with relative to ground and addended altitude, used in desired output
  *   points_with_shift.kmz - Point positions shifted west to display how altitude seems to impact rendering in google earth more than orientation
The export tools also provide various data driven options which may be used instead of the addend altitude feature.

Hope that clears this up for everyone. I'd be interested to know if this resolves the issues that were being experienced.

Regards


On Sun, 15 Aug 2021 at 05:04, David Strip <qgis-user at stripfamily.net<mailto:qgis-user at stripfamily.net>> wrote:
I tried your file on   Google Earth Pro 7.3.4.8248 (64-bit) on Win10. I get an even stranger result - two of the small circles appear on top of the big circles, the other two behind.
Both layers are listed as clamp to ground.

_______________________________________________
Qgis-user mailing list
Qgis-user at lists.osgeo.org<mailto:Qgis-user at lists.osgeo.org>
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-user/attachments/20210815/e371e0c5/attachment.html>


More information about the Qgis-user mailing list