Thanks Even, All clear.
For -p the -amin -amax options work \o/ (having the same precision issue with shapes though) Ticket created: https://github.com/OSGeo/gdal/issues/1487 Regards & Thanks, Richard Duivenvoorde On 29/04/2019 22.03, Even Rouault wrote: > 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 > _______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
