3D line length not shown in identify tool results

[coefficient1900]

Describe the bug

A line layer that received the Z-values from the built-in "Drape" algorithm does not show the 3D length in the identify tool results. Using the "v.drape" from the GRASS toolbox to assign Z-values will result in a visible 3D length in the identifying section.

How to Reproduce

1. Create a new 2D line shape layer (I used CRS: 25832 ETRS89/UTM32N) where you have a DEM available.

2. The line won't show a 3D length which is the expected behaviour, because it does not have Z-values.
   

3. Use the "Drape" algorithm the assign Z-values to that specific line.

4. Z-Values are there, but a 3D length is not displayed yet.
   

5. If you use the "v.drape" from GRASS instead to assign the Z-Values to the line, the 3D length is shown in the identifying section, although the vertex section does not show the Z-values.
   

(Even when you edit the Z values of a line manually, you will not get the 3D length)

QGIS and OS versions

<style type="text/css"> p, li { white-space: pre-wrap; } </style>

QGIS version	3.16.8-Hannover	QGIS code revision	8c50902
Compiled against Qt	5.15.2	Running against Qt	5.15.2
Compiled against GDAL/OGR	3.3.0	Running against GDAL/OGR	3.3.0
Compiled against GEOS	3.9.1-CAPI-1.14.2	Running against GEOS	3.9.1-CAPI-1.14.2
Compiled against SQLite	3.35.2	Running against SQLite	3.35.2
PostgreSQL Client Version	13.0	SpatiaLite Version	5.0.1
QWT Version	6.1.3	QScintilla2 Version	2.11.5
Compiled against PROJ	8.0.1	Running against PROJ	Rel. 8.0.1, March 5th, 2021
OS Version	Windows 10 Version 2009
Active python plugins	db_manager; MetaSearch; processing

Additional context
I am using two independent windows machines (same behaviour) and a new profile.

This behaviour occurred in the version 3.10.14, 3.16.8, 3.18.3 and 3.20.0.

The archive contains a dem and the origin line which was used to go through the steps described above.
demand2dline.zip

[nyalldawson]

I can't reproduce. What output format are you saving the draped layer to?

[coefficient1900]

Its does not matter. The screenshots show it for temporary layers, but it is the same result for permanent shapes and for geopackage layers.

[gioman]

The archive contains a dem and the origin line which was used to go through the steps described above.

@coefficient1900 there is only the line, not de DEM.

[nyalldawson]

Again, I can't reproduce. You'll need to post additional details about how to trigger this bug.

[coefficient1900]

@gioman I downloaded the archive and it contains utmdem.tif (of course the dem) and four necessary files of a shapefile.

[coefficient1900]

I tested the procedure with the data from the archive on Ubuntu which never has seen QGIS before (with the version from the Ubuntu software center (3.10.4)). The result is similar to the described above.

[coefficient1900]

3dlengthscreen.mp4

Here is screencast (sorry for the missing mouse) that shows the steps with the data form the .zip from above to provoke the behaviour. Let me know when you need something more.

[agiudiceandrea]

Hi @nyalldawson I can also reproduce the described issue with the layers in the provided zip file.

The testline.shp layer is an ESRI Shapefile of type "Line (MultiLineString)" (from Layer Properties) with 1 feature.

I see two kind of issue:

1. with the "Identify Features" tool:

   • using the "Drape (set Z value from raster)" QGIS native tool, the created temporary layer "Draped" is a Memory layer of type "Line (MultiLineStringZ)"
   • for the "Draped" created layer: iface.activeLayer().getFeature(1).geometry().wkbType() returns 1005 (MultiLineStringZ) and QgsWkbTypes.flatType(iface.activeLayer().getFeature(1).geometry().wkbType()) returns 5 (MultiLineString) so the Length 3D is not displayed because it is only displayed for LineString and not for MultiLineString

     QGIS/src/gui/qgsmaptoolidentify.cpp

     Lines 823 to 827 in 521ef28

     	if ( QgsWkbTypes::hasZ( feature.geometry().wkbType() ) && QgsWkbTypes::flatType( feature.geometry().wkbType() ) == QgsWkbTypes::LineString )
     	{
     	str = formatDistance( qgsgeometry_cast< const QgsLineString * >( feature.geometry().constGet() )->length3D()
     	* QgsUnitTypes::fromUnitToUnitFactor( layer->crs().mapUnits(), cartesianDistanceUnits ), cartesianDistanceUnits );
     	derivedAttributes.insert( tr( "Length (Cartesian — 3D)" ), str );

   • the "Vertex Tool" for the "Draped" layer displays X, Y and Z values because the layer type has Z value.

2. with the "v.drape" GRASS tool:

   • executing the tool, the created "3D vector" layer is a "temporary" GPKG layer of type "Line (LineString)" and the following warning is displayed in the log:
     F:\QGIS\SourceDir>v.out.ogr type="auto" input="outputc188af3926ef4425bfe1ba96109264c1" output="C:\Users\Andrea\AppData\Local\Temp\processing_KZfwxN\32d51028644a43f3b8cdb9b01301f4ea\output.gpkg" format="GPKG" --overwrite
WARNING: Vector map <outputc188af3926ef4425bfe1ba96109264c1> is 3D. Use format specific layer creation options (parameter 'lco') to export <in 3D rather than 2D (default).
   • for the "3D vector" created layer: iface.activeLayer().getFeature(1).geometry().wkbType() returns -2147483646 ("LineString25D") and QgsWkbTypes.flatType(iface.activeLayer().getFeature(1).geometry().wkbType()) returns 2 ("LineString") so the Length 3D is displayed (in fact iface.activeLayer().getFeature(1).geometry().asWkt() returns 'LineStringZ (...)'.
   • the "Vertex Tool" for the "3D vector" layer only displays X and Y values, without Z value, because the layer type is "Line (LineString)" so it is supposed to not have the Z value.

[agiudiceandrea]

@coefficient1900 the issue about the "Drape" processing algorithm, the "Identify feature" tool and the Z and Length 3D values has been fixed by #43940

Instead, the issue about the output layer of the GRASS v.drape algorithm, the Vertex tool and the Z values has not yet been fixed, so you need to file another issue report for this unfixed issue in order to let a developer fix it if possible.

[coefficient1900]

@agiudiceandrea is the GRASS "v.drape" issue one for the QGIS repo or is it a GRASS problem to solve in OSGeo/grass?

[gioman]

is the GRASS "v.drape" issue one for the QGIS repo

@coefficient1900 "fun" fact: if saving as SHP when using v.drape the result is a proper 3d vector (MultiLineStringZ) and the vertex editor show the z values, but the identify tool do not show the 3D length. If saving as temporary layer or GPKG the resulting vector do not seems to be 3d (linestring), the vertex editor do not show the Z values but the identify tool shows the 3D length.

[agiudiceandrea]

@gioman the current situation in QGIS is that the GPKG format is always* used for the "Save to temporary file" GRASS algorithms output layer.
All the GRASS algorithms use v.out.ogr to export the GRASS internal layer created by the actual GRASS command (say v.drape) to the output format.
It seems that v.out.ogr correctly outputs a 3d line layer only (?) if the output format is ESRI Shapefile (see this OSGeo/grass@606b979 commit description).
So when the change between SHP and GPKG as default output format in QGIS was made, the v.out.ogr limitation regarding 3d layers output was not taken into account.

* It seems that changing the "Default output vector layer extension" option, in the Processing options, doesn't affects the GRASS algorithms, while it affects the GDAL algorithms. Bug report submitted #43988

[gioman]

the current situation in QGIS is that the GPKG format is always* used for the "Save to temporary file" GRASS algorithms output layer

@agiudiceandrea yes, I always forget about it

All the GRASS algorithms use v.out.ogr to export the GRASS internal layer created by the actual GRASS command (say v.drape) to the output format

yes I know

It seems that v.out.ogr correctly outputs a 3d line layer only (?) if the output format is ESRI Shapefile (see this OSGeo/grass@606b979 commit description).
So when the change between SHP and GPKG as default output format in QGIS was made, the v.out.ogr limitation regarding 3d layers output was not taken into account.

still is interesting that QGIS identify do not show the 3d length for what it is a real 3d vector and show it for what it seems to not be a 3d vector.

[agiudiceandrea]

QGIS identify do not show the 3d length for what it is a real 3d vector and show it for what it seems to not be a 3d vector.

The Identify Feature tool relies to each feature geometry type (and not to the layer type) in order to show or not the length 3D and Z values.

In the first issue (in which the layer is "Line (MultiLineStringZ)"), the feature geometry type is "MultiLineStringZ" so QgsWkbTypes::hasZ() is True and QgsWkbTypes::flatType() is MultiLineString which was not supported by the Identify Feature tool (this is now fixed by #43940 and the Identify Feature tool will support MultiLineString too).

In the second issue (in which the layer type is wrongly "Line (LineString)"), the feature geometry type is "LineString25D" so QgsWkbTypes::hasZ() is True and QgsWkbTypes::flatType() is LineString which is supported by the Identify Feature tool.

[agiudiceandrea]

is the GRASS "v.drape" issue one for the QGIS repo or is it a GRASS problem to solve in OSGeo/grass?

I've filed a issue report OSGeo/grass#1693 in the OSGeo/grass repository.

[gioman]

In the first issue (in which the layer is "Line (MultiLineStringZ)"), the feature geometry type is "MultiLineStringZ" so QgsWkbTypes::hasZ() is True and QgsWkbTypes::flatType() is MultiLineString which was not supported by the Identify Feature tool (this is now fixed by #43940 and the Identify Feature tool will support MultiLineString too).

In the second issue (in which the layer type is wrongly "Line (LineString)"), the feature geometry type is "LineString25D" so QgsWkbTypes::hasZ() is True and QgsWkbTypes::flatType() is LineString which is supported by the Identify Feature tool.

@agiudiceandrea thanks

[agiudiceandrea]

It seems that changing the "Default output vector layer extension" option, in the Processing options, doesn't affects the GRASS algorithms, while it affects the GDAL algorithms. Bug report submitted #43988

Such issue will be fixed by #58102.