[gdal-dev] vector NODATA for Z values?

Fri Jan 26 03:06:24 PST 2024

Hi,

I do understand the use case and we use such nodata-Z in some of our datasets. For example, in our densified contour lines where the computed densification points get Z-value -9999. We prefer to use the nodata value because we cannot guarantee that the interpolated Z would match with the ground truth.
However, none of the 3D programs that I know can handle such data correctly, despite the one that we have written ourselves.

I somehow think that I do not like the nodata values in Z at all. It is a misuse of XYZ coordinates which should define the location in 3D space. I think that nobody is planning to support nodata in X and Y. How is it possible to compute the volume of some 3D solid if Z-values are unknown? Z that may be unknown is rather a measure than a Z-coordinate.  Or maybe even an attribute instead of a coordinate. On the other hand, I recognize that nodata-Z can be useful because anything better and standardized exists yet. OGC to the rescue?

-Jukka Rahkonen-

Lähettäjä: Abel Pau <a.pau at creaf.uab.cat>
Lähetetty: perjantai 26. tammikuuta 2024 11.59
Vastaanottaja: Rahkonen Jukka <jukka.rahkonen at maanmittauslaitos.fi>; gdal-dev at lists.osgeo.org
Aihe: RE: vector NODATA for Z values?

Hi again,
I understand...

Perhaps an option could be using something like -lco Z_NODATA_VALUE_DST="X" to translate NODATA  from origin to this value X (NaN, 0, or whatever it may be). The driver can offer this number instead of the own NODATA and the user can know that the X value in destination will mean NODATA.

On the other hand, a user could also specify -lco Z_NODATA_VALUE_SRC="Y" so that a driver can identify a value considered NODATA in the source and translate it to the own NODATA value (or the one specified by the first parameter (if it exists)).

Is this too complicated? Are there any repercussions that I'm not seeing?
Thanks.

De: Rahkonen Jukka <jukka.rahkonen at maanmittauslaitos.fi<mailto:jukka.rahkonen at maanmittauslaitos.fi>>
Enviado el: dijous, 25 de gener de 2024 18:27
Para: Abel Pau <a.pau at creaf.uab.cat<mailto:a.pau at creaf.uab.cat>>; gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>
Asunto: Re: vector NODATA for Z values?

Hi,

I think that it depends on the file format. Rather often it is set to zero but I have seen NaN in many places. However, shapefiles explicitly denies NaN

"...Positive infinity, negative infinity, and Not-a-Number (NaN) values are not allowed in shapefiles. Nevertheless, shapefiles support the concept of "no data" values, but they are currently used only for measures. Any floating point number smaller than -1038 is considered by a shapefile reader to represent a "no data" value.

With the SQLite dialect it is possible to select the value but NaN is not accepted.
Can be tested with
ogrinfo -dialect SQLite -sql "select CastToXYZ(ST_GeomFromText('POINT (1 2)'),3)" point.json

-Jukka Rahkonen-

Lähettäjä: gdal-dev <gdal-dev-bounces at lists.osgeo.org<mailto:gdal-dev-bounces at lists.osgeo.org>> Puolesta Abel Pau via gdal-dev
Lähetetty: torstai 25. tammikuuta 2024 19.07
Vastaanottaja: gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>
Aihe: [gdal-dev] vector NODATA for Z values?

Hi,
there is any value in GDAL for VECTORS that indicates that a concrete value of a Z is not known (z nodata value)?
I couldn't find it anywhere.

In MiraMon format we use one concrete number documented in our format pdf (-1.0E+300) an in the driver it's planned to translate it to the same number. I could translate it to the one I am asking. And the same for detecting nodata Z and translate them to -1.0E+300 when reading another format.

Thanks!

Abel Pau Garcia
GIS developer
[https://www.creaf.cat/sites/default/files/creaf-signature.png]
a.pau at creaf.uab.cat<mailto:a.pau at creaf.uab.cat>
Let's chat on Teams!<https://teams.microsoft.com/l/chat/0/0?users=a.pau@creaf.uab.cat>
Tel. +34 934814277
[https://www.creaf.cat/sites/default/files/so-en-signature.png]
[https://www.creaf.cat/sites/default/files/twitter-icon-signature.png]<https://twitter.com/CREAF_ecologia>[https://www.creaf.cat/sites/default/files/linkedin-icon-signature.png]<https://www.linkedin.com/company/1363052?trk=tyah&trkInfo=clickedVertical:company,clickedEntityId:1363052,idx:2-1-2,tarId:1465807877789,tas:creaf>[https://www.creaf.cat/sites/default/files/youtube-icon-signature.png]<https://www.youtube.com/c/creafecologia>[https://www.creaf.cat/sites/default/files/instagram-icon-signature.png]<https://www.instagram.com/CREAF_ecologia/>
www.creaf.cat<http://www.creaf.cat/> | http://blog.creaf.cat<http://blog.creaf.cat/>
[https://www.creaf.cat/sites/default/files/uab_logo_signatura.png]
CREAF. Campus UAB. Edifici C. 08193 Bellaterra (Barcelona)

Before printing this electronic message, think about the environment.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240126/c442322f/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 3657 bytes
Desc: image001.png
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240126/c442322f/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 2547 bytes
Desc: image002.png
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240126/c442322f/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 505 bytes
Desc: image003.png
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240126/c442322f/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 446 bytes
Desc: image004.png
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240126/c442322f/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 553 bytes
Desc: image005.png
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240126/c442322f/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.png
Type: image/png
Size: 582 bytes
Desc: image006.png
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240126/c442322f/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.jpg
Type: image/jpeg
Size: 2208 bytes
Desc: image007.jpg
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240126/c442322f/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image008.jpg
Type: image/jpeg
Size: 1111 bytes
Desc: image008.jpg
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240126/c442322f/attachment-0003.jpg>