Re: [gdal-dev] vector NODATA for Z values?

2024-01-26 Thread Abel Pau via gdal-dev
Perfect then!
I leave at it is and we’ll see.

De: Even Rouault 
Enviado el: divendres, 26 de gener de 2024 12:17
Para: Abel Pau ; Rahkonen Jukka 
; gdal-dev@lists.osgeo.org
Asunto: Re: [gdal-dev] vector NODATA for Z values?


Hi,

IMHO, I would not complicate the driver for that. Such options would actually 
be quite generic, and if we wanted to implement them, they would probably 
better be implemented as options of ogr2ogr (but should be done separately from 
your driver submission)

Even
Le 26/01/2024 à 10:59, Abel Pau via gdal-dev a écrit :
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 

Enviado el: dijous, 25 de gener de 2024 18:27
Para: Abel Pau ; 
gdal-dev@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 
mailto:gdal-dev-boun...@lists.osgeo.org>> 
Puolesta Abel Pau via gdal-dev
Lähetetty: torstai 25. tammikuuta 2024 19.07
Vastaanottaja: gdal-dev@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@creaf.uab.cat
Let's chat on 
Teams!
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://www.creaf.cat/sites/default/files/linkedin-icon-signature.png][https://www.creaf.cat/sites/default/files/youtube-icon-signature.png][https://www.creaf.cat/sites/default/files/instagram-icon-signature.png]
www.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.






___

gdal-dev mailing list

gdal-dev@lists.osgeo.org

https://lists.osgeo.org/mailman/listinfo/gdal-dev

--

http://www.spatialys.com

My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


Re: [gdal-dev] Virtual Raster Tile Index (VRTTI) driver, and associated gdaltindex improvements

2024-01-26 Thread Even Rouault via gdal-dev

Hi,

the driver has recently landed into GDAL master, renamed as GTI: 
https://gdal.org/drivers/raster/gti.html


Can be tested using 
https://gdal.org/download.html#gdal-master-conda-builds , the refreshed 
ghcr.io/osgeo/gdal Docker image, or other nightly builds of GDAL master


Even

Le 20/12/2023 à 19:33, Even Rouault via gdal-dev a écrit :

Hi,

For those not actively following github tickets & PR, I just want to 
point to a new pending major functionality to improve management of 
virtual mosaics with a very large number of tiles/sources (> tens of 
thousands of tiles), by referencing them as features of a vector layer 
(typically created by gdaltindex), instead of a XML file as in 
traditional VRT, augmented with additional metadata.


More details in https://github.com/OSGeo/gdal/pull/8983 (and in 
initial ticket in https://github.com/OSGeo/gdal/issues/8861)


Even


--
http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


Re: [gdal-dev] vector NODATA for Z values?

2024-01-26 Thread Even Rouault via gdal-dev

Hi,

IMHO, I would not complicate the driver for that. Such options would 
actually be quite generic, and if we wanted to implement them, they 
would probably better be implemented as options of ogr2ogr (but should 
be done separately from your driver submission)


Even

Le 26/01/2024 à 10:59, Abel Pau via gdal-dev a écrit :


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 
*Enviado el:* dijous, 25 de gener de 2024 18:27
*Para:* Abel Pau ; gdal-dev@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  *Puolesta 
*Abel Pau via gdal-dev

*Lähetetty:* torstai 25. tammikuuta 2024 19.07
*Vastaanottaja:* gdal-dev@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@creaf.uab.cat* 

*Let's chat on Teams!* 



*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://www.creaf.cat/sites/default/files/linkedin-icon-signature.png 
https://www.creaf.cat/sites/default/files/youtube-icon-signature.png 
https://www.creaf.cat/sites/default/files/instagram-icon-signature.png 



*www.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.

http://www.creaf.uab.cat/_signatura/line.gif


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


--
http://www.spatialys.com
My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


Re: [gdal-dev] vector NODATA for Z values?

2024-01-26 Thread Rahkonen Jukka via gdal-dev
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 -. 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 
Lähetetty: perjantai 26. tammikuuta 2024 11.59
Vastaanottaja: Rahkonen Jukka ; 
gdal-dev@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 
mailto:jukka.rahko...@maanmittauslaitos.fi>>
Enviado el: dijous, 25 de gener de 2024 18:27
Para: Abel Pau mailto:a@creaf.uab.cat>>; 
gdal-dev@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 
mailto:gdal-dev-boun...@lists.osgeo.org>> 
Puolesta Abel Pau via gdal-dev
Lähetetty: torstai 25. tammikuuta 2024 19.07
Vastaanottaja: gdal-dev@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@creaf.uab.cat
Let's chat on 
Teams!
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://www.creaf.cat/sites/default/files/linkedin-icon-signature.png][https://www.creaf.cat/sites/default/files/youtube-icon-signature.png][https://www.creaf.cat/sites/default/files/instagram-icon-signature.png]
www.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.



___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


Re: [gdal-dev] vector NODATA for Z values?

2024-01-26 Thread Abel Pau via gdal-dev
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 
Enviado el: dijous, 25 de gener de 2024 18:27
Para: Abel Pau ; gdal-dev@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 
mailto:gdal-dev-boun...@lists.osgeo.org>> 
Puolesta Abel Pau via gdal-dev
Lähetetty: torstai 25. tammikuuta 2024 19.07
Vastaanottaja: gdal-dev@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@creaf.uab.cat
Let's chat on 
Teams!
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://www.creaf.cat/sites/default/files/linkedin-icon-signature.png][https://www.creaf.cat/sites/default/files/youtube-icon-signature.png][https://www.creaf.cat/sites/default/files/instagram-icon-signature.png]
www.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.



___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev