[gdal-dev] numeric values in VFK driver

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

[gdal-dev] numeric values in VFK driver

Martin Landa
Hi,

there is an issue with VFK driver when interpreting numeric values.
Attribute type in VFK data is defined by string like

&BVLA;PODIL_CITATEL N30;PODIL_JMENOVATEL N30;

where VLA is layer name, N -> numeric; 30 -> width

Currently such data types are interpreted as bigint by the driver. But
the value can be apparently (tested almost on full Czech cadastre
dataset) larger that bigint in reality, eg.

&DVLA;...109690709117941111470877379;221486618060854273218000000;...

Such values are nonsense, but VFK driver has to read them. Currently
overflowed values are returned.

I can see only one option: switch to strings. So N30 will be treated
as string(30) by GDAL. Unfortunately it will influences (due to few
non-sense values mentioned above) important attributes like ID which
will be converted from bigint to text attributes.

By chance, anyone with better approach? Thanks a lot for pointers in advance! Ma

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: numeric values in VFK driver

Even Rouault-2
On mardi 5 juin 2018 08:12:59 CEST Martin Landa wrote:

> Hi,
>
> there is an issue with VFK driver when interpreting numeric values.
> Attribute type in VFK data is defined by string like
>
> &BVLA;PODIL_CITATEL N30;PODIL_JMENOVATEL N30;
>
> where VLA is layer name, N -> numeric; 30 -> width
>
> Currently such data types are interpreted as bigint by the driver. But
> the value can be apparently (tested almost on full Czech cadastre
> dataset) larger that bigint in reality, eg.
>
> &DVLA;...109690709117941111470877379;221486618060854273218000000;...
>
> Such values are nonsense, but VFK driver has to read them. Currently
> overflowed values are returned.
>
> I can see only one option: switch to strings. So N30 will be treated
> as string(30) by GDAL. Unfortunately it will influences (due to few
> non-sense values mentioned above) important attributes like ID which
> will be converted from bigint to text attributes.

For >= 19 characters, bigint cannot be used indeed. There isn't much other
choice than storing as a string.

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: numeric values in VFK driver

Martin Landa
Hi,

2018-06-05 11:16 GMT+02:00 Even Rouault <[hidden email]>:
> For >= 19 characters, bigint cannot be used indeed. There isn't much other
> choice than storing as a string.

right. In [1] I switched at least to CPLAtoGIntBigEx(). BTW I would
expect that a warning will be printed also on invalid character. But

* 7423849274x is silently parsed as 7423849274
* x7423849274 is silently parsed as 0

Is it expected behaviour of CPLAtoGIntBigEx()?

Martin

[1] https://github.com/OSGeo/gdal/issues/672#issuecomment-395148503

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: numeric values in VFK driver

Even Rouault-2
On mercredi 6 juin 2018 19:27:50 CEST Martin Landa wrote:

> Hi,
>
> 2018-06-05 11:16 GMT+02:00 Even Rouault <[hidden email]>:
> > For >= 19 characters, bigint cannot be used indeed. There isn't much other
> > choice than storing as a string.
>
> right. In [1] I switched at least to CPLAtoGIntBigEx(). BTW I would
> expect that a warning will be printed also on invalid character. But
>
> * 7423849274x is silently parsed as 7423849274
> * x7423849274 is silently parsed as 0
>
> Is it expected behaviour of CPLAtoGIntBigEx()?

Good question. The doc of the function only mentions under/overflows, so the
cases you mention above do not technically match that.

You can use CPLGetValueType(str) == CPL_VALUE_INTEGER as an additional test to
check if it is an integer (of arbitrary length)

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: numeric values in VFK driver

Martin Landa
Hi,

2018-06-06 20:58 GMT+02:00 Even Rouault <[hidden email]>:
> You can use CPLGetValueType(str) == CPL_VALUE_INTEGER as an additional test to
> check if it is an integer (of arbitrary length)

great, I have improved error handling in VFK accordingly [1]. Ma

[1] https://github.com/OSGeo/gdal/issues/672#issuecomment-395340050

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev