[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