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

[Richard Duivenvoorde]

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
>