Il 5/26/2015 12:03 PM, Even Rouault ha scritto:
Le mardi 26 mai 2015 11:40:22, Calogero Mauceri a écrit :
Il 5/26/2015 11:28 AM, Even Rouault ha scritto:
Le mardi 26 mai 2015 11:00:21, Calogero Mauceri a écrit :
Hi all,
we are having problems saving/reading GCPs values in a VRT file when
those values are inf or nan. This problem is happening on Window
platform while it is working as expected in unix systems.
We are setting the GCP values in a VRT dataset using the library
function GDALSetGCPs. The inf values get saved into the VRT XML as
"*1.#INF00000000E+000*" string
<GCPList Projection="PROJCS["unnamed",
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563],
TOWGS84[0,0,0,0,0,0,0]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433]],
PROJECTION["Orthographic"],
PARAMETER["latitude_of_origin",71.331088221],
PARAMETER["central_meridian",-156.63420306],
PARAMETER["false_easting",0],
PARAMETER["false_northing",0]]">
<GCP Id="0" Pixel="0.0000" Line="0.0000" X="*1.#INF00000000E+000*"
Y="*1.#INF00000000E+000*" />
<GCP Id="1" Pixel="363.0000" Line="0.0000"
X="-3.463981152302E+004"
Y="3.246591123662E+004" />
<GCP Id="2" Pixel="725.0000" Line="0.0000"
X="-1.070555064325E+004"
Y="1.097994383230E+004" />
<GCP Id="3" Pixel="1088.0000" Line="0.0000"
X="-5.461709489401E+003" Y="6.277974169290E+003" />
<GCP Id="4" Pixel="1450.0000" Line="0.0000"
X="-3.134437286904E+003" Y="4.191819043427E+003" />
</GCPList>
when those values are read through the GDALGetGCPs library function,
then the inf values are set to 1.0.
Is this a bug in GDAL or are we setting the inf GCP values in the wrong
way?
Note that on unix everything works fine, the inf values are saved as
"INF" strings in the VRT XML and they are properly converted when they
are read back.
Calogero,
Dealing with Inf or NaN serialized number on Windows require special
cases. But I fail to see why you need to set GCPs at infinity or nan,
and I'd bet the behaviour of the TPS or polynomial transforms will be
pretty much undefined with such as value.
Even
I agree with you Even, Inf and NaN values should not be saved as GCPs,
but the way how they are treated in GDAL is very misleading, as invalid
values become valid after saving and then reading them.
If you think that should not be fixed it
Actually with changes done some time ago in trunk to use locale unaware
functions to parse strings as double, it should have worked already, but only
strict 1.#INF or -1.#INF were recognized. I've improved CPLStrodDelim() to
also accept with other characters behind.
should be at least reported in
the documentation.
Calogero
Great Even!
Will the changes be in next GDAL release?
Calogero
--
Calogero Mauceri
Software Engineer
Applied Coherent Technology Corporation (ACT)
www.actgate.com
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
