[gdal-dev] Problem saving/reading inf GCPs values in VRT
Even Rouault
even.rouault at spatialys.com
Tue May 26 03:03:23 PDT 2015
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
--
Spatialys - Geospatial professional services
http://www.spatialys.com
More information about the gdal-dev
mailing list