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

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Richard Duivenvoorde
Hi,

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.

Another thingie:

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

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 (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

Is this something because it is supposed to work with values > 1?
In this case it is modeloutput: a cloud so very small values...

Thanks for any info,
And let me know if this is worth creating one or two? issues.


Wanne play/try?
http://duif.net/temp/smoke.zip is an example epsg:4326
raster smoke plume.

Regards,

Richard Duivenvoorde
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: gdal_contour -p options no attributes and interval < 1 strange results?

Even Rouault-2
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
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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
>

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev