date:20240322

Re: [gdal-dev] USGS 3DEP (3D Elevation Program) - feet should be metres, how can I fix this?

2024-03-22 Thread Conrad Bielski via gdal-dev

 Thanks Even,
looks like a good workaround for the moment. Hopefully, the USGS will update 
their files accordingly.
Thanks Kirk for kicking this up. I'm sure it is not trivial to fix such an 
issue for a national dataset.
Have a great day,Conrad

On Friday, March 22, 2024 at 04:57:03 AM EDT, Even Rouault 
 wrote:  
 
  
Hi,
 
having looked at the file, I believe GDAL behaves correctly given the metadata 
in the file. This is clearly a unit type attached to the Band, and it should be 
corrected by the data producer to reflect what is really used in it
 
One way to correct it on your side is for example this little Python snippet
 
 
from osgeo import gdal
 ds = gdal.Open('test.tif')
 ds.GetRasterBand(1).SetUnitType('metre')
 
As the file is used in read-only mode, this will generate an auxiliary .aux.xml 
side car file overriding the unit.
 
You can also directly override the wrong metadata inside the TIFF with
 
 
ds = gdal.OpenEx('test.tif', open_options=['IGNORE_COG_LAYOUT_BREAK=YES'])
 ds.GetRasterBand(1).SetUnitType('metre')
 
The IGNORE_COG_LAYOUT_BREAK=YES open option is because modifying TIFF metadata 
causes it to be rewritten at the end of the file, which "breaks" the COG 
convention. But that's still a perfectly valid GeoTIFF file, and will not 
change anything for local use of such file. You could reprocess that to a fully 
compliant COG with gdal_translate -of COG
 
 
Regarding how that is used by gdalwarp, the doc enhancement at 
https://github.com/OSGeo/gdal/pull/9527 captures my initial attempt at 
answering your questions.
 

 
Even
 

 
 Le 22/03/2024 à 01:16, Conrad Bielski a écrit :
  
 
 Just realised I should have put you also in CC 
  Here is my response message again. 
Thanks Even, 
  you are correct about the tag number (I sent the incorrrect one). 
  I have provided a sample tif and some other descriptions of the issue here: 
bad_geotiff - Google Drive 
   
|  
|  
|  |  
bad_geotiff - Google Drive
  |

  |

  |


  The three files there are the following:   1.  A bad tiff (this is slightly 
smaller; they are all pretty big). 2.  A GDAL info dump (survey feet is almost 
at the bottom) 3. A PDF with an explanation of the issue   
  thanks for your help. Conrad  
  
  On Thursday, March 21, 2024 at 04:49:57 PM EDT, Even Rouault 
 wrote:  
  
 

 
 Le 21/03/2024 à 21:45, Conrad Bielski via gdal-dev a écrit :
  
 
 Hello GDALers,
 
 I have a question about reading USGS 3DEP (3D Elevation Program) data. Inside 
of this data, a GEOTIFF tag 42114 is provided which is causing problems with 
datum shifts.

There's no such thing as a GEOTIFF tag 42114.
 
The closest tags are:
 
 
#define TIFFTAG_GDAL_METADATA 42112
 #define TIFFTAG_GDAL_NODATA 42113
 
 
It would be helpuful if you could provide the file, or the result of a 
"tiffdump -m 1000 the.tif" and "listgeo the.tif" on it.
 
And was the .tif.aux.xml provided with the TIFF, or computed by GDAL. Because 
the information might come from it too.
 

  
 So when I use GDAL to compute the datum shifts, the tag is read and interprets 
that the DEM is showing elevation in 'feet' while the DEM is actually in 
metres. The DEMs are in fact in meter elevations and meter UTM horizontal 
coordinates. This is obviously erroneously integrated into the tag.
 
 So my question is whether anyone has come across this issue and found a 
solution? Is there a way to edit the offending tag so that it is correctly 
interpreted as metres instead of feet? Other potential solutions so that GDAL 
interprets the elevation correctly?
 
 Thanks in advance for your help. I provide below the output of gdalinfo which 
I hope could help with the offending info in bold.
 
 Have a great day,
 Conrad
 
  
  
  
 Driver: GTiff/GeoTIFF
 
Files:I:\v3_us_3dep\asheville\ashevilleUSGS_1M_17_x34y392_NC_Phase5_2018_A18.tif
       
I:\v3_us_3dep\asheville\ashevilleUSGS_1M_17_x34y392_NC_Phase5_2018_A18.tif.aux.xml
 Size is 10012, 10012
 Coordinate System is:
 PROJCRS["NAD83 / UTM zone 17N",
     BASEGEOGCRS["NAD83",
         DATUM["North American Datum 1983",
             ELLIPSOID["GRS 1980",6378137,298.257222101,
                 LENGTHUNIT["metre",1]]],
         PRIMEM["Greenwich",0,
             ANGLEUNIT["degree",0.0174532925199433]],
         ID["EPSG",4269]],
     CONVERSION["UTM zone 17N",
         METHOD["Transverse Mercator",
             ID["EPSG",9807]],
         PARAMETER["Latitude of natural origin",0,
             ANGLEUNIT["degree",0.0174532925199433],
             ID["EPSG",8801]],
         PARAMETER["Longitude of natural origin",-81,
             ANGLEUNIT["degree",0.0174532925199433],
             ID["EPSG",8802]],
         PARAMETER["Scale factor at natural origin",0.9996,
             SCALEUNIT["unity",1],
             ID["EPSG",8805]],
         PARAMETER["False easting",50,
             LENGTHUNIT["metre",1],
             ID["EPSG",8806]],
         PARAMETER["False northing",0,
             LENGTHUNIT["metre",1],

Re: [gdal-dev] Estonian WMS failure

2024-03-22 Thread Rahkonen Jukka via gdal-dev

Hi,

Works for me from the opposite side of the Gulf of Finland. I get a list of 215 
subdatasets with
gdalinfo "WMS:https://kaart.maaamet.ee/wms/alus-geo?; --debug on

No problem with VERSION=1.3.0 either. I tested with GDAL 3.8.4, released 
2024/02/08 (OSGeo4W).

-Jukka Rahkonen-


Lähettäjä: gdal-dev  Puolesta Elena Ruiz via 
gdal-dev
Lähetetty: perjantai 22. maaliskuuta 2024 13.37
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] Estonian WMS failure


Hi, I am using GDAL v3.06 to read map web services.
A customer from Estonia tells us that the official and public servers in their 
country are not working,
and as you can see below, they return the following error:

>gdalinfo "WMS:https://kaart.maaamet.ee/wms/alus-geo?;
ERROR 1: Error returned by server : unknown (56)
gdalinfo failed - unable to open 'WMS:https://kaart.maaamet.ee/wms/alus-geo?'.

>gdalinfo "WMS:https://kaart.maaamet.ee/wms/alus-geo?version=1.3.0;
ERROR 1: Error returned by server : unknown (56)
gdalinfo failed - unable to open 
'WMS:https://kaart.maaamet.ee/wms/alus-geo?version=1.3.0'.

However, there are some of those Estonian servers that do work like the 
following:
teenus.maaamet.ee/ows/maardlad?service=WMS=1.3.0=GetCapabilities

But I don't see the difference, both are version 1.3.0. Could you tell me what 
is causing this error?
Thank you and regards.

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

[gdal-dev] Estonian WMS failure

2024-03-22 Thread Elena Ruiz via gdal-dev


Hi, I am using GDAL v3.06 to read map web services.
A customer from Estonia tells us that the official and public servers in their 
country are not working,
and as you can see below, they return the following error:

>gdalinfo "WMS:https://kaart.maaamet.ee/wms/alus-geo?;
ERROR 1: Error returned by server : unknown (56)
gdalinfo failed - unable to open 'WMS:https://kaart.maaamet.ee/wms/alus-geo?'.

>gdalinfo "WMS:https://kaart.maaamet.ee/wms/alus-geo?version=1.3.0;
ERROR 1: Error returned by server : unknown (56)
gdalinfo failed - unable to open 
'WMS:https://kaart.maaamet.ee/wms/alus-geo?version=1.3.0'.

However, there are some of those Estonian servers that do work like the 
following:
teenus.maaamet.ee/ows/maardlad?service=WMS=1.3.0=GetCapabilities

But I don't see the difference, both are version 1.3.0. Could you tell me what 
is causing this error?
Thank you and regards.

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

Re: [gdal-dev] USGS 3DEP (3D Elevation Program) - feet should be metres, how can I fix this?

2024-03-22 Thread Kirk Waters - NOAA Federal via gdal-dev

I put in a ticket to the USGS National Map help desk so they'll know it
needs to be fixed. I'm sure some USGS folks watch this forum too.

Kirk Waters, PhD
NOAA Office for Coastal Management
Applied Sciences Program
‪Phone: 843-284-6962‬ (email preferred)
coast.noaa.gov/digitalcoast
[he/him]




On Fri, Mar 22, 2024 at 4:57 AM Even Rouault via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> Hi,
>
> having looked at the file, I believe GDAL behaves correctly given the
> metadata in the file. This is clearly a unit type attached to the Band, and
> it should be corrected by the data producer to reflect what is really used
> in it
>
> One way to correct it on your side is for example this little Python
> snippet
>
> from osgeo import gdal
> ds = gdal.Open('test.tif')
> ds.GetRasterBand(1).SetUnitType('metre')
>
> As the file is used in read-only mode, this will generate an auxiliary
> .aux.xml side car file overriding the unit.
>
> You can also directly override the wrong metadata inside the TIFF with
>
> ds = gdal.OpenEx('test.tif', open_options=['IGNORE_COG_LAYOUT_BREAK=YES'])
> ds.GetRasterBand(1).SetUnitType('metre')
>
> The IGNORE_COG_LAYOUT_BREAK=YES open option is because modifying TIFF
> metadata causes it to be rewritten at the end of the file, which "breaks"
> the COG convention. But that's still a perfectly valid GeoTIFF file, and
> will not change anything for local use of such file. You could reprocess
> that to a fully compliant COG with gdal_translate -of COG
>
> Regarding how that is used by gdalwarp, the doc enhancement at
> https://github.com/OSGeo/gdal/pull/9527 captures my initial attempt at
> answering your questions.
>
> Even
>
>
> Le 22/03/2024 à 01:16, Conrad Bielski a écrit :
>
> Just realised I should have put you also in CC
>
> Here is my response message again.
>
> Thanks Even,
>
> you are correct about the tag number (I sent the incorrrect one).
>
> I have provided a sample tif and some other descriptions of the issue here:
> bad_geotiff - Google Drive
> 
>
> bad_geotiff - Google Drive
> 
>
> The three files there are the following:
> 1.  A bad tiff (this is slightly smaller; they are all pretty big).
> 2.  A GDAL info dump (survey feet is almost at the bottom)
> 3. A PDF with an explanation of the issue
>
> thanks for your help.
> Conrad
>
>
> On Thursday, March 21, 2024 at 04:49:57 PM EDT, Even Rouault
>   wrote:
>
>
>
> Le 21/03/2024 à 21:45, Conrad Bielski via gdal-dev a écrit :
>
> Hello GDALers,
>
> I have a question about reading USGS 3DEP (3D Elevation Program) data.
> Inside of this data, a GEOTIFF tag 42114 is provided which is causing
> problems with datum shifts.
>
> There's no such thing as a GEOTIFF tag 42114.
>
> The closest tags are:
>
> #define TIFFTAG_GDAL_METADATA 42112
> #define TIFFTAG_GDAL_NODATA 42113
>
> It would be helpuful if you could provide the file, or the result of a
> "tiffdump -m 1000 the.tif" and "listgeo the.tif" on it.
>
> And was the .tif.aux.xml provided with the TIFF, or computed by GDAL.
> Because the information might come from it too.
>
>
> So when I use GDAL to compute the datum shifts, the tag is read and
> interprets that the DEM is showing elevation in 'feet' while the DEM is
> actually in metres. The DEMs are in fact in meter elevations and meter UTM
> horizontal coordinates. This is obviously erroneously integrated into the
> tag.
>
> So my question is whether anyone has come across this issue and found a
> solution? Is there a way to edit the offending tag so that it is correctly
> interpreted as metres instead of feet? Other potential solutions so that
> GDAL interprets the elevation correctly?
>
> Thanks in advance for your help. I provide below the output of gdalinfo
> which I hope could help with the offending info in bold.
>
> Have a great day,
> Conrad
>
>
>
>
> Driver: GTiff/GeoTIFF
> Files:
> I:\v3_us_3dep\asheville\ashevilleUSGS_1M_17_x34y392_NC_Phase5_2018_A18.tif
>
>  
> I:\v3_us_3dep\asheville\ashevilleUSGS_1M_17_x34y392_NC_Phase5_2018_A18.tif.aux.xml
> Size is 10012, 10012
> Coordinate System is:
> PROJCRS["NAD83 / UTM zone 17N",
> BASEGEOGCRS["NAD83",
> DATUM["North American Datum 1983",
> ELLIPSOID["GRS 1980",6378137,298.257222101,
> LENGTHUNIT["metre",1]]],
> PRIMEM["Greenwich",0,
> ANGLEUNIT["degree",0.0174532925199433]],
> ID["EPSG",4269]],
> CONVERSION["UTM zone 17N",
> METHOD["Transverse Mercator",
> ID["EPSG",9807]],
> PARAMETER["Latitude of natural origin",0,
> ANGLEUNIT["degree",0.0174532925199433],
> ID["EPSG",8801]],
> PARAMETER["Longitude of natural origin",-81,
> ANGLEUNIT["degree",0.0174532925199433],
> ID["EPSG",8802]],
> PARAMETER["Scale factor at natural origin",0.9996,
>

Re: [gdal-dev] USGS 3DEP (3D Elevation Program) - feet should be metres, how can I fix this?

2024-03-22 Thread Even Rouault via gdal-dev


Hi,

having looked at the file, I believe GDAL behaves correctly given the 
metadata in the file. This is clearly a unit type attached to the Band, 
and it should be corrected by the data producer to reflect what is 
really used in it


One way to correct it on your side is for example this little Python snippet

from osgeo import gdal
ds = gdal.Open('test.tif')
ds.GetRasterBand(1).SetUnitType('metre')

As the file is used in read-only mode, this will generate an auxiliary 
.aux.xml side car file overriding the unit.


You can also directly override the wrong metadata inside the TIFF with

ds = gdal.OpenEx('test.tif', open_options=['IGNORE_COG_LAYOUT_BREAK=YES'])
ds.GetRasterBand(1).SetUnitType('metre')

The IGNORE_COG_LAYOUT_BREAK=YES open option is because modifying TIFF 
metadata causes it to be rewritten at the end of the file, which 
"breaks" the COG convention. But that's still a perfectly valid GeoTIFF 
file, and will not change anything for local use of such file. You could 
reprocess that to a fully compliant COG with gdal_translate -of COG


Regarding how that is used by gdalwarp, the doc enhancement at 
https://github.com/OSGeo/gdal/pull/9527 captures my initial attempt at 
answering your questions.


Even


Le 22/03/2024 à 01:16, Conrad Bielski a écrit :

Just realised I should have put you also in CC

Here is my response message again.

Thanks Even,

you are correct about the tag number (I sent the incorrrect one).

I have provided a sample tif and some other descriptions of the issue 
here:
bad_geotiff - Google Drive 






bad_geotiff - Google Drive

 



The three files there are the following:
1.  A bad tiff (this is slightly smaller; they are all pretty big).
2.  A GDAL info dump (survey feet is almost at the bottom)
3. A PDF with an explanation of the issue

thanks for your help.
Conrad


On Thursday, March 21, 2024 at 04:49:57 PM EDT, Even Rouault 
 wrote:




Le 21/03/2024 à 21:45, Conrad Bielski via gdal-dev a écrit :
Hello GDALers,

I have a question about reading USGS 3DEP (3D Elevation Program) data. 
Inside of this data, a GEOTIFF tag 42114 is provided which is causing 
problems with datum shifts.


There's no such thing as a GEOTIFF tag 42114.

The closest tags are:

#define TIFFTAG_GDAL_METADATA 42112
#define TIFFTAG_GDAL_NODATA 42113

It would be helpuful if you could provide the file, or the result of a 
"tiffdump -m 1000 the.tif" and "listgeo the.tif" on it.


And was the .tif.aux.xml provided with the TIFF, or computed by GDAL. 
Because the information might come from it too.





So when I use GDAL to compute the datum shifts, the tag is read and 
interprets that the DEM is showing elevation in 'feet' while the DEM 
is actually in metres. The DEMs are in fact in meter elevations and 
meter UTM horizontal coordinates. This is obviously erroneously 
integrated into the tag.


So my question is whether anyone has come across this issue and found 
a solution? Is there a way to edit the offending tag so that it is 
correctly interpreted as metres instead of feet? Other potential 
solutions so that GDAL interprets the elevation correctly?


Thanks in advance for your help. I provide below the output of 
gdalinfo which I hope could help with the offending info in bold.


Have a great day,
Conrad




Driver: GTiff/GeoTIFF
Files: 
I:\v3_us_3dep\asheville\ashevilleUSGS_1M_17_x34y392_NC_Phase5_2018_A18.tif

 
I:\v3_us_3dep\asheville\ashevilleUSGS_1M_17_x34y392_NC_Phase5_2018_A18.tif.aux.xml
Size is 10012, 10012
Coordinate System is:
PROJCRS["NAD83 / UTM zone 17N",
    BASEGEOGCRS["NAD83",
        DATUM["North American Datum 1983",
            ELLIPSOID["GRS 1980",6378137,298.257222101,
                LENGTHUNIT["metre",1]]],
        PRIMEM["Greenwich",0,
ANGLEUNIT["degree",0.0174532925199433]],
        ID["EPSG",4269]],
    CONVERSION["UTM zone 17N",
        METHOD["Transverse Mercator",
            ID["EPSG",9807]],
        PARAMETER["Latitude of natural origin",0,
ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8801]],
        PARAMETER["Longitude of natural origin",-81,
ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8802]],
        PARAMETER["Scale factor at natural origin",0.9996,
            SCALEUNIT["unity",1],
            ID["EPSG",8805]],
        PARAMETER["False easting",50,
            LENGTHUNIT["metre",1],
            ID["EPSG",8806]],
        PARAMETER["False northing",0,
            LENGTHUNIT["metre",1],
            ID["EPSG",8807]]],
    CS[Cartesian,2],
        AXIS["(E)",east,
            ORDER[1],
            LENGTHUNIT["metre",1]],
        AXIS["(N)",north,
            ORDER[2],
            LENGTHUNIT["metre",1]],
    USAGE[
        SCOPE["Engineering survey, topographic mapping."],
        AREA["North America - between 84°W and 78°W - onshore and

Re: [gdal-dev] USGS 3DEP (3D Elevation Program) - feet should be metres, how can I fix this?

Re: [gdal-dev] Estonian WMS failure

[gdal-dev] Estonian WMS failure

Re: [gdal-dev] USGS 3DEP (3D Elevation Program) - feet should be metres, how can I fix this?

Re: [gdal-dev] USGS 3DEP (3D Elevation Program) - feet should be metres, how can I fix this?

5 matches

Site Navigation

Mail list logo

Footer information