date:20240125

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.

___
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-25 Thread Javier Jimenez Shaw via gdal-dev

What about NaN?

On Thu, 25 Jan 2024, 18:07 Abel Pau via gdal-dev, 
wrote:

> 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*
>
> [image: https://www.creaf.cat/sites/default/files/creaf-signature.png]
>
> *a@creaf.uab.cat* 
>
> *Let's chat on Teams!*
> 
>
> *Tel. +34 934814277*
>
> [image: https://www.creaf.cat/sites/default/files/so-en-signature.png]
>
> [image:
> https://www.creaf.cat/sites/default/files/twitter-icon-signature.png]
> [image:
> https://www.creaf.cat/sites/default/files/linkedin-icon-signature.png]
> [image:
> https://www.creaf.cat/sites/default/files/youtube-icon-signature.png]
> [image:
> https://www.creaf.cat/sites/default/files/instagram-icon-signature.png]
> 
>
> *www.creaf.cat* * | **http://blog.creaf.cat*
> 
>
> [image: 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.
>
> [image: 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
>
___
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?


Hi,

good question. To the best of my knowledge, in the official WKT / WKB 
spec, it is a "everything or nothing" logic. Either all the vertices 
have a well defined Z value and then you use LINESTRING Z, POLYGON Z, 
etc.. Or none of them have, and you use the 2D versions: LINESTRING, 
POLYGON, etc.


I believe QGIS has standardized using not-a-number NaN number for that 
purpose, but officially, you can't export that to WKT... That said, for 
the sake of interoperability with QGIS or other software using NaN, the 
OGR WKT importer and exporter also supports its:


$ python -c "from osgeo import ogr; g = ogr.CreateGeometryFromWkt('POINT 
Z (1 2 nan)'); print(g.ExportToIsoWkt())"

POINT Z (1 2 nan)

but I'm not sure if I'd recommend using that convention. I can imagine 
exporting NaN to some formats could produce invalid content.


The good old shapefile uses a similar convention to the -1e300 trick you 
propose. 
https://www.esri.com/content/dam/esrisites/sitecore-archive/Files/Pdfs/library/whitepapers/pdfs/shapefile.pdf 
, page 2 : "Any floating point number smaller than –10^38 is considered 
by a shapefile reader to represent a "no data" value"


Even

Le 25/01/2024 à 18:07, Abel Pau via gdal-dev a écrit :


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

[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] false easting and northing units

2024-01-25 Thread Kirk Waters - NOAA Federal via gdal-dev



Le 25/01/2024 à 17:08, Kirk Waters - NOAA Federal a écrit :

Even,
Thanks for the explanation and tips. I'm not clear on how setting to 
26988 (Michigan North meters) would help.

Hopefully forcing 1.0 will fix the issue.

ah, I didn't realize that the "NAD83 / Michigan North" in your WKT was 
*not* official EPSG:26988. I'd strongly suggest you modify your WKT to 
use "NAD83 / Michigan North (ftuS)" instead to avoid any confusion!


Actually your WKT is a bit weird as it lacks the name of the CompoundCRS 
(quite surprise that PROJ manages to parse it) before the PROJCS[]. Try 
the following instead


COMPD_CS["NAD83 / Michigan North (ftUS) + NAVD88 height 
(ftUS)",PROJCS["NAD83 / Michigan North 
(ftUS)",GEOGCS["NAD83",DATUM["North_American_Datum_1983",SPHEROID["GRS 
1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],AUTHORITY["EPSG","6269"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4269"]],PROJECTION["Lambert_Conformal_Conic_2SP"],PARAMETER["standard_parallel_1",47.08333],PARAMETER["standard_parallel_2",45.48333],PARAMETER["latitude_of_origin",44.78333],PARAMETER["central_meridian",-87],PARAMETER["false_easting",2624.667],PARAMETER["false_northing",0],UNIT["US 
survey 
foot",0.304800609601219],AXIS["X",EAST],AXIS["Y",NORTH]],VERT_CS["NAVD88 
height (ftUS)",VERT_DATUM["North American Vertical Datum 
1988",2005],UNIT["US survey 
foot",0.304800609601219],AXIS["Gravity-related 
height",UP],AUTHORITY["EPSG","6360"]]]


By itself, that will not improve the interoperability, but at least 
things will be better labelled, with a GTCitationGeoKey (Ascii,53): 
"NAD83 / Michigan North (ftUS) + NAVD88 height (ftUS)"


Even


If I do a gdal_translate with that, it shows as being in New Zealand, 
just as Arc had done. It would certainly make lots more sense to 
actually put the data in a standard projection that has an EPSG code 
(meters or international feet), but that gets back to the embarrassing 
tale. It may well be that I'll have to force GeoTiff 1.0. I think 
there are other software packages that haven't caught up. Even when 
they do catch up, I've come across people running 15 year old CAD 
software and complaining about the DXF version GDAL produces.


Thanks to the whole team for the work you do to maintain GDAL.

Kirk


On Thu, Jan 25, 2024 at 10:47 AM Even Rouault 
 wrote:


Kirk,

perhaps you could try using -a_srs EPSG:26988+6360 instead of a
full WKT. That way GDAL will *not* write the projected parameter
definitions, but just reference the horizontal and vertical CRS codes:

Geotiff_Information:
   Version: 1
   Key_Revision: 1.1
   Tagged_Information:
  ModelTiepointTag (2,3):
 0 0 0
 440720    3751320 0
  ModelPixelScaleTag (1,3):
 60    60 1
  End_Of_Tags.
   Keyed_Information:
  GTModelTypeGeoKey (Short,1): ModelTypeProjected
  GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
  GTCitationGeoKey (Ascii,46): "NAD83 / Michigan North +
NAVD88 height (ftUS)"
  ProjectedCSTypeGeoKey (Short,1): PCS_NAD83_Michigan_North
  VerticalCSTypeGeoKey (Short,1): Code-6360 (NAVD88 height (ftUS))
  End_Of_Keys.
   End_Of_Geotiff.

Even

Le 25/01/2024 à 16:17, Even Rouault via gdal-dev a écrit :


Kirk,

this is a complicated story indeed... What changed since
https://trac.osgeo.org/gdal/changeset/31405 is that OGC GeoTIFF
1.1 was published, which mostly fixes issues with vertical CRS,
which your CRS uses. So by default GDAL 3.1 or later, when seeing
a CompoundCRS write it as GeoTIFF 1.1, and this new GeoTIFF
version was the opportunity to remove writing the
ProjLinearUnitsInterpCorrectGeoKey=3059 hack, since using GeoTIFF
1.1 is a way to indicate that you're implementing correctly the
standard.

If you force writing GeoTIFF 1.0 by adding -co
GEOTIFF_VERSION=1.0, GDAL will write
the ProjLinearUnitsInterpCorrectGeoKey when needed, and listgeo
will show the "Unknown-3059 (Short,1): Unknown-1" geotiff key.

To know if a Geotiff is 1.0 or 1.1 with listgeo , look at the
Key_Revision in the 3rd line which will be 1.0 or 1.1

So I assume ArcPro doesn't specifically implement 1.1. Either
they implement GeoTIFF themselves, or they use GDAL < 3.1 that
hasn't GeoTIFF 1.1 explicit support

Even

Le 25/01/2024 à 15:24, Kirk Waters - NOAA Federal via gdal-dev a
écrit :

Hi,
I've run across an odd issue with GeoTIFFS using custom
projections written by GDAL and their interpretation in ArcPro.
The specific case is doing a projection for Michigan State Plane
North using U.S. survey feet. [insert embarrassing tale of
another US agency wanting to always use survey feet regardless
of state legislation or that the

Re: [gdal-dev] false easting and northing units

Even,
Thanks for the explanation and tips. I'm not clear on how setting to 26988
(Michigan North meters) would help. If I do a gdal_translate with that, it
shows as being in New Zealand, just as Arc had done. It would certainly
make lots more sense to actually put the data in a standard projection that
has an EPSG code (meters or international feet), but that gets back to the
embarrassing tale. It may well be that I'll have to force GeoTiff 1.0. I
think there are other software packages that haven't caught up. Even when
they do catch up, I've come across people running 15 year old CAD software
and complaining about the DXF version GDAL produces.

Thanks to the whole team for the work you do to maintain GDAL.

Kirk


On Thu, Jan 25, 2024 at 10:47 AM Even Rouault 
wrote:

> Kirk,
>
> perhaps you could try using -a_srs EPSG:26988+6360 instead of a full WKT.
> That way GDAL will *not* write the projected parameter definitions, but
> just reference the horizontal and vertical CRS codes:
>
> Geotiff_Information:
>Version: 1
>Key_Revision: 1.1
>Tagged_Information:
>   ModelTiepointTag (2,3):
>  0 0 0
>  4407203751320   0
>   ModelPixelScaleTag (1,3):
>  60601
>   End_Of_Tags.
>Keyed_Information:
>   GTModelTypeGeoKey (Short,1): ModelTypeProjected
>   GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
>   GTCitationGeoKey (Ascii,46): "NAD83 / Michigan North + NAVD88 height
> (ftUS)"
>   ProjectedCSTypeGeoKey (Short,1): PCS_NAD83_Michigan_North
>   VerticalCSTypeGeoKey (Short,1): Code-6360 (NAVD88 height (ftUS))
>   End_Of_Keys.
>End_Of_Geotiff.
>
> Even
> Le 25/01/2024 à 16:17, Even Rouault via gdal-dev a écrit :
>
> Kirk,
>
> this is a complicated story indeed... What changed since
> https://trac.osgeo.org/gdal/changeset/31405 is that OGC GeoTIFF 1.1 was
> published, which mostly fixes issues with vertical CRS, which your CRS
> uses. So by default GDAL 3.1 or later, when seeing a CompoundCRS write it
> as GeoTIFF 1.1, and this new GeoTIFF version was the opportunity to remove
> writing the ProjLinearUnitsInterpCorrectGeoKey=3059 hack, since using
> GeoTIFF 1.1 is a way to indicate that you're implementing correctly the
> standard.
>
> If you force writing GeoTIFF 1.0 by adding -co GEOTIFF_VERSION=1.0, GDAL
> will write the ProjLinearUnitsInterpCorrectGeoKey when needed, and listgeo
> will show the "Unknown-3059 (Short,1): Unknown-1" geotiff key.
>
> To know if a Geotiff is 1.0 or 1.1 with listgeo , look at the Key_Revision
> in the 3rd line which will be 1.0 or 1.1
>
> So I assume ArcPro doesn't specifically implement 1.1. Either they
> implement GeoTIFF themselves, or they use GDAL < 3.1 that hasn't GeoTIFF
> 1.1 explicit support
>
> Even
> Le 25/01/2024 à 15:24, Kirk Waters - NOAA Federal via gdal-dev a écrit :
>
> Hi,
> I've run across an odd issue with GeoTIFFS using custom projections
> written by GDAL and their interpretation in ArcPro. The specific case is
> doing a projection for Michigan State Plane North using U.S. survey feet.
> [insert embarrassing tale of another US agency wanting to always use
> survey feet regardless of state legislation or that the federal government
> has been officially metric for a long time]. For a file that should land in
> the Michigan upper peninsula, ArcPro puts it in New Zealand. It appears the
> issue is that Arc is interpreting the false easting as meters instead of
> survey feet. If I do a define projection in ArcPro and make a custom
> projection, it lands in the right place.
>
> I used an old listgeo from the geotiff library to look at the tags both in
> the original file and a copy that had define projection applied to see what
> was different. They looked essentially the same, including having the same
> value for the false easting. However, the Arc version had an extra tag
> (3059) that wasn't in the GDAL produced one. An internet search turned up this
> 13-year old GDAL issue . If I
> understand it correctly, a bug in GDAL was found that always used meters
> for the false easting and northing. In addition to fixing that, a tag
> (3059) was added to indicate this was fixed so software could differentiate
> broken GDAL output from new output. It looks like Arc is looking for this
> tag and if it's not there, false easting is assumed to be meters.
>
> A few questions, assuming I interpreted that issue correctly:
> 1) Why is gdal not adding that 3059 tag? (GDAL command used is below)
> 2) If it's only supposed to be relevant to GDAL written files, why is Arc
> writing it?
> 3) How do I get GDAL to add the tag?
>
> Command used in file creation:
> gdal_translate -a_srs 'COMPD_CS[PROJCS["NAD83 / Michigan
> North",GEOGCS["NAD83",DATUM["North_American_Datum_1983",SPHEROID["GRS
>

Re: [gdal-dev] false easting and northing units


Kirk,

perhaps you could try using -a_srs EPSG:26988+6360 instead of a full 
WKT. That way GDAL will *not* write the projected parameter definitions, 
but just reference the horizontal and vertical CRS codes:


Geotiff_Information:
   Version: 1
   Key_Revision: 1.1
   Tagged_Information:
  ModelTiepointTag (2,3):
 0 0 0
 440720    3751320   0
  ModelPixelScaleTag (1,3):
 60    60    1
  End_Of_Tags.
   Keyed_Information:
  GTModelTypeGeoKey (Short,1): ModelTypeProjected
  GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
  GTCitationGeoKey (Ascii,46): "NAD83 / Michigan North + NAVD88 
height (ftUS)"

  ProjectedCSTypeGeoKey (Short,1): PCS_NAD83_Michigan_North
  VerticalCSTypeGeoKey (Short,1): Code-6360 (NAVD88 height (ftUS))
  End_Of_Keys.
   End_Of_Geotiff.

Even

Le 25/01/2024 à 16:17, Even Rouault via gdal-dev a écrit :


Kirk,

this is a complicated story indeed... What changed since 
https://trac.osgeo.org/gdal/changeset/31405 is that OGC GeoTIFF 1.1 
was published, which mostly fixes issues with vertical CRS, which your 
CRS uses. So by default GDAL 3.1 or later, when seeing a CompoundCRS 
write it as GeoTIFF 1.1, and this new GeoTIFF version was the 
opportunity to remove writing the 
ProjLinearUnitsInterpCorrectGeoKey=3059 hack, since using GeoTIFF 1.1 
is a way to indicate that you're implementing correctly the standard.


If you force writing GeoTIFF 1.0 by adding -co GEOTIFF_VERSION=1.0, 
GDAL will write the ProjLinearUnitsInterpCorrectGeoKey when needed, 
and listgeo will show the "Unknown-3059 (Short,1): Unknown-1" geotiff key.


To know if a Geotiff is 1.0 or 1.1 with listgeo , look at the 
Key_Revision in the 3rd line which will be 1.0 or 1.1


So I assume ArcPro doesn't specifically implement 1.1. Either they 
implement GeoTIFF themselves, or they use GDAL < 3.1 that hasn't 
GeoTIFF 1.1 explicit support


Even

Le 25/01/2024 à 15:24, Kirk Waters - NOAA Federal via gdal-dev a écrit :

Hi,
I've run across an odd issue with GeoTIFFS using custom projections 
written by GDAL and their interpretation in ArcPro. The specific case 
is doing a projection for Michigan State Plane North using 
U.S. survey feet. [insert embarrassing tale of another US agency 
wanting to always use survey feet regardless of state legislation or 
that the federal government has been officially metric for a long 
time]. For a file that should land in the Michigan upper peninsula, 
ArcPro puts it in New Zealand. It appears the issue is that Arc is 
interpreting the false easting as meters instead of survey feet. If I 
do a define projection in ArcPro and make a custom projection, it 
lands in the right place.


I used an old listgeo from the geotiff library to look at the tags 
both in the original file and a copy that had define projection 
applied to see what was different. They looked essentially the same, 
including having the same value for the false easting. However, the 
Arc version had an extra tag (3059) that wasn't in the GDAL produced 
one. An internet search turned up this 13-year old GDAL issue 
. If I understand it 
correctly, a bug in GDAL was found that always used meters for the 
false easting and northing. In addition to fixing that, a tag (3059) 
was added to indicate this was fixed so software could differentiate 
broken GDAL output from new output. It looks like Arc is looking for 
this tag and if it's not there, false easting is assumed to be meters.


A few questions, assuming I interpreted that issue correctly:
1) Why is gdal not adding that 3059 tag? (GDAL command used is below)
2) If it's only supposed to be relevant to GDAL written files, why is 
Arc writing it?

3) How do I get GDAL to add the tag?

Command used in file creation:
gdal_translate -a_srs 'COMPD_CS[PROJCS["NAD83 / Michigan 
North",GEOGCS["NAD83",DATUM["North_American_Datum_1983",SPHEROID["GRS 
1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","6269"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4269"]],PROJECTION["Lambert_Conformal_Conic_2SP"],PARAMETER["standard_parallel_1",47.083334],PARAMETER["standard_parallel_2",45.48],PARAMETER["latitude_of_origin",44.78],PARAMETER["central_meridian",-87],PARAMETER["false_easting",2624.667],PARAMETER["false_northing",0],UNIT["US 
survey 
foot",0.304800609601219],AXIS["X",EAST],AXIS["Y",NORTH]],VERTCRS["NAVD88 
height (ftUS)",  VDATUM["North American Vertical Datum 1988"], 
 CS[vertical,1],  AXIS["gravity-related height (H)",up], 
 LENGTHUNIT["US survey foot",0.304800609601], ID["EPSG",6360]]]' -co 
TILED=YES -co COMPRESS=DEFLATE -co PREDICTOR=3 -co BIGTIFF=IF_SAFER 
input.tif output.tif


Kirk Waters, PhD
NOAA Office for Coastal Management
Applied Sciences

Re: [gdal-dev] help

Oh, sorry :(
Some time ago I tried with OSGeo4W but finally 
I used vcpkg and it worked.
If anybody can give you the solution you can try that one.
Sorry again

De: Marián Hadri 
Enviado el: dijous, 25 de gener de 2024 16:19
Para: Abel Pau 
CC: gdal-dev@lists.osgeo.org
Asunto: AW: help

Hi,
no, it did not help. Btw. I downloaded GDAL 3.8.3  project from 
https://gdal.org/download.html to directory
C:\Dev\gdal-3.8.3 and PROJ project with use of 
OSGeo4W software distribution to directory 
C:\OSGeo4W.
My include directory for PROJ is C:\OSGeo4W\include and lib directory is 
C:\OSGeo4W\lib.
I simply try to use CMake for creating project file for VS2019 with command 
"cmake -G "Visual Studio 16 2019"", but
I got these errors ...



Marián Hadri  Developer

E-Mail  marian.ha...@rib-software.com

Telefon  +49(711)7873-339



RIB Software GmbH | Vaihinger Str. 151, 70567 Stuttgart, Germany

Sitz Stuttgart. Amtsgericht Stuttgart HRB 783426. Geschäftsführer: René Wolf, 
Tobias Hamacher.

[Banner Signatur.jpg]

RIB Webseite | LinkedIn 
Profil
Bitte denken Sie an die Umwelt, bevor Sie diese E-Mail ausdrucken.

DISCLAMER: Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der 
angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert 
wurde, verständigen Sie bitte umgehend den Absender. Danach löschen Sie bitte 
diese E-Mail. Das unerlaubte Benutzen, Kopieren sowie die unbefugte 
Übermittlung sind nicht gestattet. RIB nimmt den Datenschutz sehr ernst. Mehr 
zu unseren Datenschutzgrundsätzen finden Sie hier: 
https://www.rib-software.com/group/datenschutzerklaerung/


Von: Abel Pau mailto:a@creaf.uab.cat>>
Gesendet: Thursday, January 25, 2024 16:00
An: Marián Hadri 
mailto:marian.ha...@rib-software.com>>
Cc: gdal-dev@lists.osgeo.org
Betreff: RE: help


[External email: Use caution with links and attachments]




I forgot to tell that I used vcpkg to install dependences
and I build the project with this line
cmake -B D:\GitHub-repository\GDAL\build -S . 
-DCMAKE_TOOLCHAIN_FILE=C:/dev/vcpkg/vcpkg/scripts/buildsystems/vcpkg.cmake

(from cmd in here: D:\GitHub-repository\GDAL)

and I compile the project it with this one:
cmake --build D:\GitHub-repository\GDAL\build

I hope being helpful

De: gdal-dev 
mailto:gdal-dev-boun...@lists.osgeo.org>> En 
nombre de Abel Pau via gdal-dev
Enviado el: dijous, 25 de gener de 2024 15:58
Para: Marián Hadri 
mailto:marian.ha...@rib-software.com>>
CC: gdal-dev@lists.osgeo.org
Asunto: Re: [gdal-dev] help

Hi,.
I have in my windows environment variables (not in any other place) this one:

PROJ_LIB = C:\dev\vcpkg\vcpkg\buildtrees\proj\x64-windows-rel\data
Attached I send what is in this folder.

I think it could be the cause of the problem, but I'm not an expert.
Luck and tell us if I solve anything :)


De: gdal-dev 
mailto:gdal-dev-boun...@lists.osgeo.org>> En 
nombre de Marián Hadri via gdal-dev
Enviado el: dijous, 25 de gener de 2024 14:58
Para: gdal-dev@lists.osgeo.org
Asunto: [gdal-dev] help

Hi,

I'm trying to build the GDAL dll and lib files, so GDAL can be used for linker 
and includes in an other C++ project. We're needing to upgrade from GDAL 3.2.2 
to 3.8.3. I try to create project file for VS 2019. In GDAL 3.2.2 was for that 
purpose used "generate_vcxproj.bat", which was in root directory. Now, this 
file is no there anymore. For that reason I try to do it with CMake program. 
But when I did it from cmd as " cmake -G "Visual Studio 16 2019" " or directly 
from Cmake, I got an error messages like this ...

CMake Error at C:/Program 
Files/CMake/share/cmake-3.28/Modules/FindPackageHandleStandardArgs.cmake:230 
(message):
  Could NOT find PROJ (missing: PROJ_LIBRARY PROJ_INCLUDE_DIR) (Required is at 
least version "6.0")

Call Stack (most recent call first):
  C:/Program 
Files/CMake/share/cmake-3.28/Modules/FindPackageHandleStandardArgs.cmake:600 
(_FPHSA_FAILURE_MESSAGE)
  cmake/modules/packages/FindPROJ.cmake:57 (find_package_handle_standard_args)
  cmake/helpers/CheckDependentLibraries.cmake:378 (find_package)
  gdal.cmake:265 (include)
  CMakeLists.txt:246 (include)

>From my point of view, it seems, that this is most important "Could NOT find 
>PROJ (missing: PROJ_LIBRARY PROJ_INCLUDE_DIR)
(Required is at least version "6.0")". Where and how I have to set that ? If I 
put that as Environment variables in CMake program like
PROJ_INCLUDE_DIR = -IC:\OSGeo4W\include
PROJ_LIBRARY = C:\OSGeo4W\lib
it did not work.

Marian Hadri



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

Re: [gdal-dev] help

2024-01-25 Thread Marián Hadri via gdal-dev

Hi,
no, it did not help. Btw. I downloaded GDAL 3.8.3  project from 
https://gdal.org/download.html to directory
C:\Dev\gdal-3.8.3 and PROJ project with use of 
OSGeo4W software distribution to directory 
C:\OSGeo4W.
My include directory for PROJ is C:\OSGeo4W\include and lib directory is 
C:\OSGeo4W\lib.
I simply try to use CMake for creating project file for VS2019 with command 
"cmake -G "Visual Studio 16 2019"", but
I got these errors ...



Marián Hadri  Developer


E-Mail  marian.ha...@rib-software.com


Telefon  +49(711)7873-339


[cid:blue-line_d40935b2-037b-4887-8d74-19a11bd1363f.png]


RIB Software GmbH | Vaihinger Str. 151, 70567 Stuttgart, Germany

Sitz Stuttgart. Amtsgericht Stuttgart HRB 783426. Geschäftsführer: René Wolf, 
Tobias Hamacher.


[cid:bannersignatur_c8faa565-c355-4095-afdd-b1abeba6cc25.jpg]


RIB Webseite 
|  LinkedIn 
Profil


Bitte denken Sie an die Umwelt, bevor Sie diese E-Mail ausdrucken.

DISCLAMER: Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der 
angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert 
wurde, verständigen Sie bitte umgehend den Absender. Danach löschen Sie bitte 
diese E-Mail. Das unerlaubte Benutzen, Kopieren sowie die unbefugte 
Übermittlung sind nicht gestattet. RIB nimmt den Datenschutz sehr ernst. Mehr 
zu unseren Datenschutzgrundsätzen finden Sie hier: 
https://www.rib-software.com/group/datenschutzerklaerung/



Von: Abel Pau 
Gesendet: Thursday, January 25, 2024 16:00
An: Marián Hadri 
Cc: gdal-dev@lists.osgeo.org
Betreff: RE: help


[External email: Use caution with links and attachments]




I forgot to tell that I used vcpkg to install dependences
and I build the project with this line
cmake -B D:\GitHub-repository\GDAL\build -S . 
-DCMAKE_TOOLCHAIN_FILE=C:/dev/vcpkg/vcpkg/scripts/buildsystems/vcpkg.cmake

(from cmd in here: D:\GitHub-repository\GDAL)

and I compile the project it with this one:
cmake --build D:\GitHub-repository\GDAL\build

I hope being helpful

De: gdal-dev 
mailto:gdal-dev-boun...@lists.osgeo.org>> En 
nombre de Abel Pau via gdal-dev
Enviado el: dijous, 25 de gener de 2024 15:58
Para: Marián Hadri 
mailto:marian.ha...@rib-software.com>>
CC: gdal-dev@lists.osgeo.org
Asunto: Re: [gdal-dev] help

Hi,.
I have in my windows environment variables (not in any other place) this one:

PROJ_LIB = C:\dev\vcpkg\vcpkg\buildtrees\proj\x64-windows-rel\data
Attached I send what is in this folder.

I think it could be the cause of the problem, but I'm not an expert.
Luck and tell us if I solve anything :)


De: gdal-dev 
mailto:gdal-dev-boun...@lists.osgeo.org>> En 
nombre de Marián Hadri via gdal-dev
Enviado el: dijous, 25 de gener de 2024 14:58
Para: gdal-dev@lists.osgeo.org
Asunto: [gdal-dev] help

Hi,

I'm trying to build the GDAL dll and lib files, so GDAL can be used for linker 
and includes in an other C++ project. We're needing to upgrade from GDAL 3.2.2 
to 3.8.3. I try to create project file for VS 2019. In GDAL 3.2.2 was for that 
purpose used "generate_vcxproj.bat", which was in root directory. Now, this 
file is no there anymore. For that reason I try to do it with CMake program. 
But when I did it from cmd as " cmake -G "Visual Studio 16 2019" " or directly 
from Cmake, I got an error messages like this ...

CMake Error at C:/Program 
Files/CMake/share/cmake-3.28/Modules/FindPackageHandleStandardArgs.cmake:230 
(message):
  Could NOT find PROJ (missing: PROJ_LIBRARY PROJ_INCLUDE_DIR) (Required is at 
least version "6.0")

Call Stack (most recent call first):
  C:/Program 
Files/CMake/share/cmake-3.28/Modules/FindPackageHandleStandardArgs.cmake:600 
(_FPHSA_FAILURE_MESSAGE)
  cmake/modules/packages/FindPROJ.cmake:57 (find_package_handle_standard_args)
  cmake/helpers/CheckDependentLibraries.cmake:378 (find_package)
  gdal.cmake:265 (include)
  CMakeLists.txt:246 (include)

>From my point of view, it seems, that this is most important "Could NOT find 
>PROJ (missing: PROJ_LIBRARY PROJ_INCLUDE_DIR)
(Required is at least version "6.0")". Where and how I have to set that ? If I 
put that as Environment variables in CMake program like
PROJ_INCLUDE_DIR = -IC:\OSGeo4W\include
PROJ_LIBRARY = C:\OSGeo4W\lib
it did not work.

Marian Hadri



___
gdal-dev mailing list
gdal-dev@lists.osgeo.org

Re: [gdal-dev] false easting and northing units


Kirk,

this is a complicated story indeed... What changed since 
https://trac.osgeo.org/gdal/changeset/31405 is that OGC GeoTIFF 1.1 was 
published, which mostly fixes issues with vertical CRS, which your CRS 
uses. So by default GDAL 3.1 or later, when seeing a CompoundCRS write 
it as GeoTIFF 1.1, and this new GeoTIFF version was the opportunity to 
remove writing the ProjLinearUnitsInterpCorrectGeoKey=3059 hack, since 
using GeoTIFF 1.1 is a way to indicate that you're implementing 
correctly the standard.


If you force writing GeoTIFF 1.0 by adding -co GEOTIFF_VERSION=1.0, GDAL 
will write the ProjLinearUnitsInterpCorrectGeoKey when needed, and 
listgeo will show the "Unknown-3059 (Short,1): Unknown-1" geotiff key.


To know if a Geotiff is 1.0 or 1.1 with listgeo , look at the 
Key_Revision in the 3rd line which will be 1.0 or 1.1


So I assume ArcPro doesn't specifically implement 1.1. Either they 
implement GeoTIFF themselves, or they use GDAL < 3.1 that hasn't GeoTIFF 
1.1 explicit support


Even

Le 25/01/2024 à 15:24, Kirk Waters - NOAA Federal via gdal-dev a écrit :

Hi,
I've run across an odd issue with GeoTIFFS using custom projections 
written by GDAL and their interpretation in ArcPro. The specific case 
is doing a projection for Michigan State Plane North using U.S. survey 
feet. [insert embarrassing tale of another US agency wanting to always 
use survey feet regardless of state legislation or that the federal 
government has been officially metric for a long time]. For a file 
that should land in the Michigan upper peninsula, ArcPro puts it in 
New Zealand. It appears the issue is that Arc is interpreting the 
false easting as meters instead of survey feet. If I do a define 
projection in ArcPro and make a custom projection, it lands in the 
right place.


I used an old listgeo from the geotiff library to look at the tags 
both in the original file and a copy that had define projection 
applied to see what was different. They looked essentially the same, 
including having the same value for the false easting. However, the 
Arc version had an extra tag (3059) that wasn't in the GDAL produced 
one. An internet search turned up this 13-year old GDAL issue 
. If I understand it 
correctly, a bug in GDAL was found that always used meters for the 
false easting and northing. In addition to fixing that, a tag (3059) 
was added to indicate this was fixed so software could differentiate 
broken GDAL output from new output. It looks like Arc is looking for 
this tag and if it's not there, false easting is assumed to be meters.


A few questions, assuming I interpreted that issue correctly:
1) Why is gdal not adding that 3059 tag? (GDAL command used is below)
2) If it's only supposed to be relevant to GDAL written files, why is 
Arc writing it?

3) How do I get GDAL to add the tag?

Command used in file creation:
gdal_translate -a_srs 'COMPD_CS[PROJCS["NAD83 / Michigan 
North",GEOGCS["NAD83",DATUM["North_American_Datum_1983",SPHEROID["GRS 
1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","6269"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4269"]],PROJECTION["Lambert_Conformal_Conic_2SP"],PARAMETER["standard_parallel_1",47.083334],PARAMETER["standard_parallel_2",45.48],PARAMETER["latitude_of_origin",44.78],PARAMETER["central_meridian",-87],PARAMETER["false_easting",2624.667],PARAMETER["false_northing",0],UNIT["US 
survey 
foot",0.304800609601219],AXIS["X",EAST],AXIS["Y",NORTH]],VERTCRS["NAVD88 
height (ftUS)",  VDATUM["North American Vertical Datum 1988"], 
 CS[vertical,1],  AXIS["gravity-related height (H)",up], 
 LENGTHUNIT["US survey foot",0.304800609601], ID["EPSG",6360]]]' -co 
TILED=YES -co COMPRESS=DEFLATE -co PREDICTOR=3 -co BIGTIFF=IF_SAFER 
input.tif output.tif


Kirk Waters, PhD
NOAA Office for Coastal Management
Applied Sciences Program
coast.noaa.gov/digitalcoast 



___
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] help

I forgot to tell that I used vcpkg to install dependences
and I build the project with this line
cmake -B D:\GitHub-repository\GDAL\build -S . 
-DCMAKE_TOOLCHAIN_FILE=C:/dev/vcpkg/vcpkg/scripts/buildsystems/vcpkg.cmake

(from cmd in here: D:\GitHub-repository\GDAL)

and I compile the project it with this one:
cmake --build D:\GitHub-repository\GDAL\build

I hope being helpful

De: gdal-dev  En nombre de Abel Pau via 
gdal-dev
Enviado el: dijous, 25 de gener de 2024 15:58
Para: Marián Hadri 
CC: gdal-dev@lists.osgeo.org
Asunto: Re: [gdal-dev] help

Hi,.
I have in my windows environment variables (not in any other place) this one:

PROJ_LIB = C:\dev\vcpkg\vcpkg\buildtrees\proj\x64-windows-rel\data
Attached I send what is in this folder.

I think it could be the cause of the problem, but I'm not an expert.
Luck and tell us if I solve anything :)


De: gdal-dev 
mailto:gdal-dev-boun...@lists.osgeo.org>> En 
nombre de Marián Hadri via gdal-dev
Enviado el: dijous, 25 de gener de 2024 14:58
Para: gdal-dev@lists.osgeo.org
Asunto: [gdal-dev] help

Hi,

I'm trying to build the GDAL dll and lib files, so GDAL can be used for linker 
and includes in an other C++ project. We're needing to upgrade from GDAL 3.2.2 
to 3.8.3. I try to create project file for VS 2019. In GDAL 3.2.2 was for that 
purpose used "generate_vcxproj.bat", which was in root directory. Now, this 
file is no there anymore. For that reason I try to do it with CMake program. 
But when I did it from cmd as " cmake -G "Visual Studio 16 2019" " or directly 
from Cmake, I got an error messages like this ...

CMake Error at C:/Program 
Files/CMake/share/cmake-3.28/Modules/FindPackageHandleStandardArgs.cmake:230 
(message):
  Could NOT find PROJ (missing: PROJ_LIBRARY PROJ_INCLUDE_DIR) (Required is at 
least version "6.0")

Call Stack (most recent call first):
  C:/Program 
Files/CMake/share/cmake-3.28/Modules/FindPackageHandleStandardArgs.cmake:600 
(_FPHSA_FAILURE_MESSAGE)
  cmake/modules/packages/FindPROJ.cmake:57 (find_package_handle_standard_args)
  cmake/helpers/CheckDependentLibraries.cmake:378 (find_package)
  gdal.cmake:265 (include)
  CMakeLists.txt:246 (include)

>From my point of view, it seems, that this is most important "Could NOT find 
>PROJ (missing: PROJ_LIBRARY PROJ_INCLUDE_DIR)
(Required is at least version "6.0")". Where and how I have to set that ? If I 
put that as Environment variables in CMake program like
PROJ_INCLUDE_DIR = -IC:\OSGeo4W\include
PROJ_LIBRARY = C:\OSGeo4W\lib
it did not work.

Marian Hadri



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

Re: [gdal-dev] help

2024-01-25 Thread Kirk Waters - NOAA Federal via gdal-dev

Hi,.
I have in my windows environment variables (not in any other place) this one:

PROJ_LIB = C:\dev\vcpkg\vcpkg\buildtrees\proj\x64-windows-rel\data
Attached I send what is in this folder.

I think it could be the cause of the problem, but I'm not an expert.
Luck and tell us if I solve anything :)


De: gdal-dev  En nombre de Marián Hadri via 
gdal-dev
Enviado el: dijous, 25 de gener de 2024 14:58
Para: gdal-dev@lists.osgeo.org
Asunto: [gdal-dev] help

Hi,

I'm trying to build the GDAL dll and lib files, so GDAL can be used for linker 
and includes in an other C++ project. We're needing to upgrade from GDAL 3.2.2 
to 3.8.3. I try to create project file for VS 2019. In GDAL 3.2.2 was for that 
purpose used "generate_vcxproj.bat", which was in root directory. Now, this 
file is no there anymore. For that reason I try to do it with CMake program. 
But when I did it from cmd as " cmake -G "Visual Studio 16 2019" " or directly 
from Cmake, I got an error messages like this ...

CMake Error at C:/Program 
Files/CMake/share/cmake-3.28/Modules/FindPackageHandleStandardArgs.cmake:230 
(message):
  Could NOT find PROJ (missing: PROJ_LIBRARY PROJ_INCLUDE_DIR) (Required is at 
least version "6.0")

Call Stack (most recent call first):
  C:/Program 
Files/CMake/share/cmake-3.28/Modules/FindPackageHandleStandardArgs.cmake:600 
(_FPHSA_FAILURE_MESSAGE)
  cmake/modules/packages/FindPROJ.cmake:57 (find_package_handle_standard_args)
  cmake/helpers/CheckDependentLibraries.cmake:378 (find_package)
  gdal.cmake:265 (include)
  CMakeLists.txt:246 (include)

>From my point of view, it seems, that this is most important "Could NOT find 
>PROJ (missing: PROJ_LIBRARY PROJ_INCLUDE_DIR)
(Required is at least version "6.0")". Where and how I have to set that ? If I 
put that as Environment variables in CMake program like
PROJ_INCLUDE_DIR = -IC:\OSGeo4W\include
PROJ_LIBRARY = C:\OSGeo4W\lib
it did not work.

Marian Hadri



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

[gdal-dev] false easting and northing units

Hi,
I've run across an odd issue with GeoTIFFS using custom projections written
by GDAL and their interpretation in ArcPro. The specific case is doing a
projection for Michigan State Plane North using U.S. survey feet. [insert
embarrassing tale of another US agency wanting to always use survey feet
regardless of state legislation or that the federal government has been
officially metric for a long time]. For a file that should land in the
Michigan upper peninsula, ArcPro puts it in New Zealand. It appears the
issue is that Arc is interpreting the false easting as meters instead of
survey feet. If I do a define projection in ArcPro and make a custom
projection, it lands in the right place.

I used an old listgeo from the geotiff library to look at the tags both in
the original file and a copy that had define projection applied to see what
was different. They looked essentially the same, including having the same
value for the false easting. However, the Arc version had an extra tag
(3059) that wasn't in the GDAL produced one. An internet search turned up this
13-year old GDAL issue . If I
understand it correctly, a bug in GDAL was found that always used meters
for the false easting and northing. In addition to fixing that, a tag
(3059) was added to indicate this was fixed so software could differentiate
broken GDAL output from new output. It looks like Arc is looking for this
tag and if it's not there, false easting is assumed to be meters.

A few questions, assuming I interpreted that issue correctly:
1) Why is gdal not adding that 3059 tag? (GDAL command used is below)
2) If it's only supposed to be relevant to GDAL written files, why is Arc
writing it?
3) How do I get GDAL to add the tag?

Command used in file creation:
gdal_translate -a_srs 'COMPD_CS[PROJCS["NAD83 / Michigan
North",GEOGCS["NAD83",DATUM["North_American_Datum_1983",SPHEROID["GRS
1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","6269"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4269"]],PROJECTION["Lambert_Conformal_Conic_2SP"],PARAMETER["standard_parallel_1",47.083334],PARAMETER["standard_parallel_2",45.48],PARAMETER["latitude_of_origin",44.78],PARAMETER["central_meridian",-87],PARAMETER["false_easting",2624.667],PARAMETER["false_northing",0],UNIT["US
survey
foot",0.304800609601219],AXIS["X",EAST],AXIS["Y",NORTH]],VERTCRS["NAVD88
height (ftUS)",  VDATUM["North American Vertical Datum 1988"],
 CS[vertical,1],  AXIS["gravity-related height (H)",up],  LENGTHUNIT["US
survey foot",0.304800609601], ID["EPSG",6360]]]' -co TILED=YES -co
COMPRESS=DEFLATE -co PREDICTOR=3 -co BIGTIFF=IF_SAFER input.tif output.tif

Kirk Waters, PhD
NOAA Office for Coastal Management
Applied Sciences Program
coast.noaa.gov/digitalcoast
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] help

2024-01-25 Thread Marián Hadri via gdal-dev

Hi,

I'm trying to build the GDAL dll and lib files, so GDAL can be used for linker 
and includes in an other C++ project. We're needing to upgrade from GDAL 3.2.2 
to 3.8.3. I try to create project file for VS 2019. In GDAL 3.2.2 was for that 
purpose used "generate_vcxproj.bat", which was in root directory. Now, this 
file is no there anymore. For that reason I try to do it with CMake program. 
But when I did it from cmd as " cmake -G "Visual Studio 16 2019" " or directly 
from Cmake, I got an error messages like this ...

CMake Error at C:/Program 
Files/CMake/share/cmake-3.28/Modules/FindPackageHandleStandardArgs.cmake:230 
(message):
  Could NOT find PROJ (missing: PROJ_LIBRARY PROJ_INCLUDE_DIR) (Required is at 
least version "6.0")

Call Stack (most recent call first):
  C:/Program 
Files/CMake/share/cmake-3.28/Modules/FindPackageHandleStandardArgs.cmake:600 
(_FPHSA_FAILURE_MESSAGE)
  cmake/modules/packages/FindPROJ.cmake:57 (find_package_handle_standard_args)
  cmake/helpers/CheckDependentLibraries.cmake:378 (find_package)
  gdal.cmake:265 (include)
  CMakeLists.txt:246 (include)

>From my point of view, it seems, that this is most important "Could NOT find 
>PROJ (missing: PROJ_LIBRARY PROJ_INCLUDE_DIR)
(Required is at least version "6.0")". Where and how I have to set that ? If I 
put that as Environment variables in CMake program like
PROJ_INCLUDE_DIR = -IC:\OSGeo4W\include
PROJ_LIBRARY = C:\OSGeo4W\lib
it did not work.

Marian Hadri


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

Re: [gdal-dev] Bad values when reading GCPs from a VRT file with gdalinfo in GDAL 3.8.3

Now perhaps GDAL could inform that “FIN” and “fin” are not valid 
double values, but on the other hand, I think that I have also some 
influence on the wrong behavior.



Validation of values added in https://github.com/OSGeo/gdal/pull/9138

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] Bad values when reading GCPs from a VRT file with gdalinfo in GDAL 3.8.3

Hi,

Certainly, consistent behavior is expected but I did not notice that your VRT 
was created with GDAL.
I edited your vrt a bit:

and with gdalinfo I seem to get still the same
GCP[  0]: Id=0, Info=
  (0,0) -> (0,0,0)

And I tried also this:
gdal_translate -gcp 0 0 fin fin test.tif inftest.tif

gdalinfo inftest.tif
GCP[  0]: Id=1, Info=
  (0,0) -> (0,0,0)

Now perhaps GDAL could inform that “FIN” and “fin” are not valid double values, 
but on the other hand, I think that I have also some influence on the wrong 
behavior. But the issue with INF/inf seems to be fixed now by Even.

-Jukka Rahkonen-

Lähettäjä: Pierluigi Guasqui 
Lähetetty: torstai 25. tammikuuta 2024 15.04
Vastaanottaja: Rahkonen Jukka 
Aihe: Re: [gdal-dev] Bad values when reading GCPs from a VRT file with gdalinfo 
in GDAL 3.8.3

Jukka,

it is not documented but I expect GDAL to be consistent with itself. If I set 
GCP (0, 0, inf, inf, -inf) with GDAL I would expect to read the same values 
with GDAL.

Pierluigi

On Thu, Jan 25, 2024 at 1:24 PM Rahkonen Jukka 
mailto:jukka.rahko...@maanmittauslaitos.fi>>
 wrote:
Hi,

I guessed so. Is that your own invention or is it documented somewhere that 
undefined GCPs should be marked that way by using INF? I ask because if it is 
something that should be reliable then I may have use for that feature in the 
future.

Problem may be limited to vrt. This test seems to pass
gdal_translate -gcp 0 0 inf inf test.tif inftest.tif

gdalinfo inftest.tif
…
GCP[  0]: Id=1, Info=
  (0,0) -> (inf,inf,0)

-Jukka Rahkonen-

Lähettäjä: Pierluigi Guasqui mailto:guas...@actgate.com>>
Lähetetty: torstai 25. tammikuuta 2024 14.16
Vastaanottaja: Rahkonen Jukka 
mailto:jukka.rahko...@maanmittauslaitos.fi>>
Aihe: Re: [gdal-dev] Bad values when reading GCPs from a VRT file with gdalinfo 
in GDAL 3.8.3

Hello Jukka,

in general using infinite values is to mark undefined or invalid GCPs.

Pierluigi

On Thu, Jan 25, 2024 at 12:44 PM Rahkonen Jukka 
mailto:jukka.rahko...@maanmittauslaitos.fi>>
 wrote:
Hi,

Out of curiosity, what is the purpose of using inf or -inf as values? Is it to 
use them as placeholders telling that you do not know yet what the 
georeferenced coordinates of the ground control points are?

-Jukka Rahkonen-

Lähettäjä: gdal-dev 
mailto:gdal-dev-boun...@lists.osgeo.org>> 
Puolesta Pierluigi Guasqui via gdal-dev
Lähetetty: torstai 25. tammikuuta 2024 13.34
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] Bad values when reading GCPs from a VRT file with gdalinfo in 
GDAL 3.8.3

Dear GDAL team,

I am using GDAL version 3.8.3 and I am trying to extract GCPs values with 
gdalinfo tool from a VRT file (attached).

As you can see by looking at the VRT file with a text editor GCP XYZ values are 
infinite values. When I read GCPs from the attached VRT file with gdalinfo 
(latest version GDAL v. 3.8.3) I am getting all zeros:

GCP[  0]: Id=0, Info=
  (0,0) -> (0,0,0)

Instead, if I use gdalinfo (GDAL v. 3.6.3) I am getting the correct values:

GCP[  0]: Id=0, Info=
  (0,0) -> (inf,inf,-inf)

Is this a bug with GDAL 3.8.3?

Thank you for your help!

--
Pierluigi Guasqui
Software Engineer

Applied Coherent Technology Corporation (ACT)
www.actgate.com


--
Pierluigi Guasqui
Software Engineer

Applied Coherent Technology Corporation (ACT)
www.actgate.com


--
Pierluigi Guasqui
Software Engineer

Applied Coherent Technology Corporation (ACT)
www.actgate.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Bad values when reading GCPs from a VRT file with gdalinfo in GDAL 3.8.3

Hi,

I guessed so. Is that your own invention or is it documented somewhere that 
undefined GCPs should be marked that way by using INF? I ask because if it is 
something that should be reliable then I may have use for that feature in the 
future.

Problem may be limited to vrt. This test seems to pass

gdal_translate -gcp 0 0 inf inf test.tif inftest.tif

gdalinfo inftest.tif
…
GCP[  0]: Id=1, Info=
  (0,0) -> (inf,inf,0)

-Jukka Rahkonen-

Lähettäjä: Pierluigi Guasqui 
Lähetetty: torstai 25. tammikuuta 2024 14.16
Vastaanottaja: Rahkonen Jukka 
Aihe: Re: [gdal-dev] Bad values when reading GCPs from a VRT file with gdalinfo 
in GDAL 3.8.3

Hello Jukka,

in general using infinite values is to mark undefined or invalid GCPs.

Pierluigi

On Thu, Jan 25, 2024 at 12:44 PM Rahkonen Jukka 
mailto:jukka.rahko...@maanmittauslaitos.fi>>
 wrote:
Hi,

Out of curiosity, what is the purpose of using inf or -inf as values? Is it to 
use them as placeholders telling that you do not know yet what the 
georeferenced coordinates of the ground control points are?

-Jukka Rahkonen-

Lähettäjä: gdal-dev 
mailto:gdal-dev-boun...@lists.osgeo.org>> 
Puolesta Pierluigi Guasqui via gdal-dev
Lähetetty: torstai 25. tammikuuta 2024 13.34
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] Bad values when reading GCPs from a VRT file with gdalinfo in 
GDAL 3.8.3

Dear GDAL team,

I am using GDAL version 3.8.3 and I am trying to extract GCPs values with 
gdalinfo tool from a VRT file (attached).

As you can see by looking at the VRT file with a text editor GCP XYZ values are 
infinite values. When I read GCPs from the attached VRT file with gdalinfo 
(latest version GDAL v. 3.8.3) I am getting all zeros:

GCP[  0]: Id=0, Info=
  (0,0) -> (0,0,0)

Instead, if I use gdalinfo (GDAL v. 3.6.3) I am getting the correct values:

GCP[  0]: Id=0, Info=
  (0,0) -> (inf,inf,-inf)

Is this a bug with GDAL 3.8.3?

Thank you for your help!

--
Pierluigi Guasqui
Software Engineer

Applied Coherent Technology Corporation (ACT)
www.actgate.com


--
Pierluigi Guasqui
Software Engineer

Applied Coherent Technology Corporation (ACT)
www.actgate.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Bad values when reading GCPs from a VRT file with gdalinfo in GDAL 3.8.3


Hi,

will be fixed per https://github.com/OSGeo/gdal/pull/9136 . As a 
workaround, you can spell them "inf" or "-inf" lowercase


Even

Le 25/01/2024 à 12:34, Pierluigi Guasqui via gdal-dev a écrit :

Dear GDAL team,

I am using GDAL version 3.8.3 and I am trying to extract GCPs values 
with gdalinfo tool from a VRT file (attached).


As you can see by looking at the VRT file with a text editor GCP XYZ 
values are infinite values. When I read GCPs from the attached VRT 
file with gdalinfo (latest version GDAL v. 3.8.3) I am getting all zeros:


GCP[  0]: Id=0, Info=
          (0,0) -> (0,0,0)

Instead, if I use gdalinfo (GDAL v. 3.6.3) I am getting the correct 
values:


GCP[  0]: Id=0, Info=
          (0,0) -> (inf,inf,-inf)

Is this a bug with GDAL 3.8.3?

Thank you for your help!

--
Pierluigi Guasqui
Software Engineer

Applied Coherent Technology Corporation (ACT)
www.actgate.com 

___
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] How to use geokey CoordinateEpochGeoKey in Geotiff from Python



Le 25/01/2024 à 04:41, David Shean a écrit :

Hi Even,
Thanks for the pointer to this resource, and for working to support 
this important functionality.
Would it make sense to add the -a_coord_epoch option to gdal_edit.py, 
so users can directly update the GeoTiff header for a dataset with 
known epoch?

That could indeed be an appropriate addition. Contribution welcome

-David



--
David Shean
Civil and Environmental Engineering
University of Washington
https://www.ce.washington.edu/facultyfinder/david-shean 



201 More Hall, Box 352700
3760 E. Stevens Way NE
Seattle, WA 98195-2700
Office: (206) 543-3105, Wilcox Hall 265
Pronouns: he, him, his

On Jan 17, 2024, at 11:40 AM, Even Rouault via gdal-dev 
 wrote:


Hi,

cf test_tiff_write_coordinate_epoch() in 
https://github.com/OSGeo/gdal/blob/3a9541d19f2df52f1e66dacfa33878531a5f2c58/autotest/gcore/tiff_write.py#L9575


On the command line you might use: gdal_translate in.tif out.tif 
-a_coord_epoch .YYY


Even

Le 17/01/2024 à 20:20, Glen Rice - NOAA Federal via gdal-dev a écrit :

Hello,

We are trying to create geotiffs from Python and specify an epoch 
for a dynamic CRS.  Is there a way to do this from python or a 
command line utility?


We see the pull request adding CoordinateEpochGeoKey (5120) and 
expect I could print the information from gdalinfo if I had an 
example file.  If we were in C/C++ then we could use libgeotiff and 
GTIFKeyGet( ).  However we are in Python and we don't see how to 
write either the CoordinateEpochGeoKey, or even a generic geokey, 
into a geotiff.


For reference we looked at the following links:
https://gdal.org/user/coordinate_epoch.html
https://github.com/opengeospatial/geotiff/issues/78
https://github.com/opengeospatial/geotiff/pull/99
https://github.com/OSGeo/libgeotiff/blob/master/libgeotiff/geokeys.inc

Thanks for any help,
Glen and Barry

--
Glen Rice
National Bathymetric Source
Hydrographic Systems and Technology Branch
Office of Coast Survey / Coast Survey Development Laboratory

___
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



--
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] Bad values when reading GCPs from a VRT file with gdalinfo in GDAL 3.8.3