[gdal-dev] gdal_contour -p options no attributes and interval < 1 strange results?

Even Rouault even.rouault at spatialys.com
Mon Apr 29 13:03:51 PDT 2019


Hi Richard,

> 
> If I use gdal_contour (in QGIS/processing) to generate contours of a
> rasterset you get a call like:
> 
> gdal_contour -b 1 -a ELEV -i 0.0001 -f "ESRI Shapefile" /tmp/smoke.asc
> /tmp/OUTPUT.shp
> 
> The column ELEV will contain the contour 'height'
> 
> But when using the -p option (to create polygons instead of lines) this
> column ELEV is just empty.
> Is this a bug? Or suppoosed to be... if you want to create labels it
> would be handier if this column is filled.

Expected behaviour, which was clarified a few weeks ago,as someone also 
stumbled on this:

https://gdal.org/gdal_contour.html:
"""
-a name:

    provides a name for the attribute in which to put the elevation. If not 
provided no elevation attribute is attached. Ignored in polygonal contouring 
(-p) mode.

-amin name:

    (Since GDAL 2.4) provides a name for the attribute in which to put the 
minimum elevation of contour polygon. If not provided no minimum elevation 
attribute is attached. Ignored in default line contouring mode.

-amax name:

    (Since GDAL 2.4) provides a name for the attribute in which to put the 
maximum elevation of contour polygon. If not provided no maximim elevation 
attribute is attached. Ignored in default line contouring mode.
"""

So the QGIS algorithm should handle the line vs polygon cases a bit 
differently to use -a or -amin + -amax


> When using interal values like above (0.0001) the contours *look* ok,
> but the values in the dbf/shp file all show 0.001  ??

Ah, that's because gdal_contour creates the elevation field with width=12 and 
precision=3, which is obviouly not appropriate for the interval you specify. 
Could be worth a GDAL ticket.

> 
> But when you do output a geopackage
> gdal_contour -b 1 -a ELEV -i 0.0001 -f "GPKG" /tmp/smoke.asc
> /tmp/OUTPUT.gpkg
> 
> The values are OK 

Yes, GeoPackage doesn't support width.precision for numeric fields, and values 
are ultimately stored as IEEE754 double precision.

> (well, showing 0.0011 and 0.00090000000 so 'precision'
> is handled a little strange...), also when you use 1.0E-4 or 1.00000E-4

Showing where ? In QGIS ? Well, that's probably just a formatting issue. With 
ogrinfo/sqlite3, you get the values look OK:

$ echo "select distinct elev from contour order by elev;" | sqlite3 out.gpkg
0.0001
0.0002
0.0003
0.0004
0.0005
0.0006
0.0007
0.0008
0.0009
0.001
0.0011
0.0012
0.0013

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com


More information about the gdal-dev mailing list