gdal_contour issues with large level values

[vmo]

gdal_contour -b 1 -a level -fl 1 1e+01 1e+02 1e+03 1e+04 1e+05 1e+06 1e+07 1e+08 1e+09 1e+10 input output.shp

rsults in warnings:

Value 100000000 of field level of feature 19 not successfully written. Possibly due to too larger number with respect to field width

Even: better you could likely fix it. I would just drop the SetWidth() and SetPrecision() calls at ​https://github.com/OSGeo/gdal/blob/trunk/gdal/apps/gdal_contour.cpp#L320

vmora: I was more thinking about changing the format of the field, there is no reason my 1e+10 is changed into a 10000000000

EvenR: I'd just drop it. The defaults of each driver should be fine. Regarding 1e+10, this is handled as a IEEE754 double value on parsing, so the original scientific notation is lost and anyway the DBF writer doesn't write numbers with scientific notations currently (unclear that DBF allows it. There's a ticket about that I think)

vmora: then we could resort to a string field, can't we ? Because next thing is 1e30 (not kidding) and the default may very well fail.

EvenR: The real type makes more sense in most cases. That said, you could possibly add an option to create the level field as a string if you wish or add an option to the shape driver to allow scientific notation

vmora: or use an output format that is smarter (no problem with geopackage)

EvenR: yeah was just thinking about that

vmora: actually I had an algo working with shapes, now the algo doesn't work with gpkg, so I juste encountered the problem while trying to diagnose. The problem is not there, so I'm reverting to gpkg

[Even Rouault]

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to ​https://github.com/OSGeo/gdal/issues if it is not already reported there.