OGR_WKT_PRECISION=[0,1,2,3] cause exponential notation side effect

[jidanni]

Here using OGR_WKT_PRECISION of 0, 1, 2, 3 causes an undocumented exponential notation (E Scientific Exponential Notation etc.) formatting side effect that the user has no control over:

set -- -1000 -1000 1000  1000 -1000  1000 1000 -1000;\
until test $# -eq 0;\
do \
	eval echo $1 $2 \$$((0+1));\
	shift 2;\
done |\
sort -k 1n,1 -k 2n,2 > 0.xyz
for i in `seq -1 5|tac`; do \
	gdal_contour -q -a name 0.xyz 0.csv -i 100 -lco GEOMETRY=AS_WKT --config OGR_WKT_PRECISION=$i;\
	printf %02d: $i; sed -n '/,0$/{p;q;}' 0.csv; \
done
05:"LINESTRING (-0.50025 -2000,-0.50025 -1000,-0.50025 1000.0,-0.50025 2000.0)",9,0
04:"LINESTRING (-0.5003 -2000,-0.5003 -1000,-0.5003 1000.0,-0.5003 2000.0)",9,0
03:"LINESTRING (-0.5 -2E+03,-0.5 -1E+03,-0.5 1E+03,-0.5 2E+03)",9,0
02:"LINESTRING (-0.5 -2E+03,-0.5 -1E+03,-0.5 1E+03,-0.5 2E+03)",9,0
01:"LINESTRING (-0.5 -2E+03,-0.5 -1E+03,-0.5 1E+03,-0.5 2E+03)",9,0
00:"LINESTRING (-1 -2E+03,-1 -1E+03,-1 1E+03,-1 2E+03)",9,0
-1:"LINESTRING (-0.50025 -2000,-0.50025 -1000,-0.50025 1000.0,-0.50025 2000.0)",9,0

Also using OGR_WKT_PRECISION=-1, -2... should trigger an error, or in fact might be useful to just continue the logical sequence, rounding to 10s and 100s... But instead all negative values of OGR_WKT_PRECISION oddly map to OGR_WKT_PRECISION=5. P.S., OGR_APPLY_GEOM_SET_PRECISION=YES (rightly) doesn't affect all this.

[jratike80]

Feels like safeguarding GDAL against an error that a user makes intentionally. The one who reads the documentation would not do that, except for testing.

OGR_WKT_PRECISION=: Defaults to 15. Number of decimals for coordinate values.

Nothing wrong with hardening per se. Does GDAL handle well the other inputs from the QA engireer joke https://news.ycombinator.com/item?id=25851770?