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

Kirk Waters - NOAA Federal via gdal-dev writes: > 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 sens

Re: [gdal-dev] 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 th

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

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

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, et

[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 numbe

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

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 *n

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

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:   Mo

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.

Re: [gdal-dev] 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\inclu

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.

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 wit

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 :

[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

[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

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, bu

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 infte

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

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 gdali

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 know

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

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 Puolesta Pierluigi Guasqui via gdal-dev Lähet

[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 ve

Re: [gdal-dev] Convert alpha to nodata?

On Wed, 24 Jan 2024 at 02:27, Even Rouault wrote: > > https://github.com/OSGeo/gdal/pull/9128 should do what you wish. As > usual, the hardest part is the naming of options... Wow! I'll try and review it in the next few days. Rob :) ___ gdal-dev mailin