Re: [gdal-dev] GDAL python API - Data axis to CRS axis mapping

2022-12-10 Thread Even Rouault 

Hi Chris,

==> 
https://gdal.org/api/python/osgeo.osr.html#osgeo.osr.SpatialReference.GetDataAxisToSRSAxisMapping


Doc: 
https://gdal.org/api/ogrspatialref.html#_CPPv4NK19OGRSpatialReference27GetDataAxisToSRSAxisMappingEv


Example at 
https://github.com/OSGeo/gdal/blob/9452625baa544ea3ab6bb0b3e368023434011ea7/autotest/gcore/vrt_read.py#L1339


Even

Le 10/12/2022 à 20:06, Chris Crook a écrit :

Hi

I am using the GDAL python API and trying to determine the data axis 
to CRS axis mapping.  This is displayed by gdalinfo, eg looking at 
test.tif file I have:


Data axis to CRS axis mapping: 2,1

However I can't see how to access this in the API.  I have looked at 
the tolatlong.py sample, and but this looks like it is about 
converting projections, which I think is a different thing.  What I am 
looking for is the correct mapping from the lat/lon order generated by 
the geotransform to the order defined by the CRS WKT.


Can anyone advise on how to best access this mapping?

Thanks
Chris Crook




This message contains information, which may be in confidence and may 
be subject to legal privilege. If you are not the intended recipient, 
you must not peruse, use, disseminate, distribute or copy this 
message. If you have received this message in error, please notify us 
immediately (Phone 0800 665 463 or i...@linz.govt.nz) and destroy the 
original message. LINZ accepts no responsibility for changes to this 
email, or for any attachments, after its transmission from LINZ. Thank 
You.


___
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] GDAL python API - Data axis to CRS axis mapping

2022-12-10 Thread Chris Crook 
Hi

I am using the GDAL python API and trying to determine the data axis to CRS 
axis mapping.  This is displayed by gdalinfo, eg looking at test.tif file I 
have:

Data axis to CRS axis mapping: 2,1

However I can't see how to access this in the API.  I have looked at the 
tolatlong.py sample, and but this looks like it is about converting 
projections, which I think is a different thing.  What I am looking for is the 
correct mapping from the lat/lon order generated by the geotransform to the 
order defined by the CRS WKT.

Can anyone advise on how to best access this mapping?

Thanks
Chris Crook




This message contains information, which may be in confidence and may be 
subject to legal privilege. If you are not the intended recipient, you must not 
peruse, use, disseminate, distribute or copy this message. If you have received 
this message in error, please notify us immediately (Phone 0800 665 463 or 
i...@linz.govt.nz) and destroy the original message. LINZ accepts no 
responsibility for changes to this email, or for any attachments, after its 
transmission from LINZ. Thank You.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] libtiff v4.5.0 release candidate available

2022-12-10 Thread Even Rouault 

Hi,

annoying that FindTIFF.cmake is so formatting sensitive, but I've 
reverted the reformatting of that file in 
https://gitlab.com/libtiff/libtiff/-/merge_requests/434


I've also added long overdue TIFFLIB_MAJOR_VERSION, 
TIFFLIB_MINOR_VERSION, TIFFLIB_MICRO_VERSION defines


Even

Le 10/12/2022 à 11:40, Kai Pastor, DG0YT a écrit :

Thanks for your work!

There is an issue with tiff_vers.h:
The new linebreak style of the TIFF_VERSION_STR definition breaks 
version detection in CMake's FindTIFF.cmake,
leaving TIFF_VERSION unset (in CMake). Some packages rely on this 
variable. E.g. openimageio in vcpkg:


-- Found TIFF
CMake Error at src/cmake/checked_find_package.cmake:154 (if):
  if given arguments:

    "VERSION_LESS" "4.0"

  Unknown arguments specified
Call Stack (most recent call first):
  src/cmake/externalpackages.cmake:90 (checked_find_package)
  CMakeLists.txt:141 (include)


which probably comes from some

if(${TIFF_VERSION} VERSION_LESS "4.0")

I would suggest to restore a formatting which doesn't break existing 
CMake code.


Regards, Kai

Am 09.12.22 um 16:48 schrieb Even Rouault:

Hi,

I've prepared a release candidate for libtiff v4.5.0:

- https://download.osgeo.org/libtiff/tiff-4.5.0rc1.tar.gz
- https://download.osgeo.org/libtiff/tiff-4.5.0rc1.tar.gz.sig
- https://download.osgeo.org/libtiff/tiff-4.5.0rc1.tar.xz
- https://download.osgeo.org/libtiff/tiff-4.5.0rc1.tar.xz.sig
- https://download.osgeo.org/libtiff/tiff-4.5.0rc1.zip
- https://download.osgeo.org/libtiff/tiff-4.5.0rc1.zip.sig

Release notes at https://libtiff.gitlab.io/libtiff/releases/v4.5.0.html

I'll promote it to final next week if no serious blocking issues are 
reported.


Thanks to all contributors.

Best regards,



___
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] Odd error

2022-12-10 Thread Clive Swan 
I have been using the security details for weeks, now getting an odd error.

 

Getting an odd error??

I have been using the same:

AWS_ACCESS_KEY_ID

AWS_SECRET_ACCESS_KEY

 

ERROR 4: Attempt to create new tiff file `/vsis3/summer-outputs/1/coastal-
-2020.tif' failed: Permission denied

Input file size is 45, 225000

ERROR 13: The specified key does not exist << ??

 

### Script below

#!/bin/bash

 LOG_FILE=/home/ubuntu/run_translate.log

 exec 1>>${LOG_FILE}

exec 2>>${LOG_FILE}

 ## 5_UK_prod_rasters >> 3_data_ready_for_spectra

 

gdal_translate /vsis3/summer-outputs /1/coastal -2020.vrt /vsis3/
summer-outputs /2/coastal -2020.tif -co BIGTIFF=YES  -co
NUM_THREADS=ALL_CPUS --config GDAL_CACHEMAX 10 --config CPL_TMPDIR
/data/tmp --config CPL_VSIL_USE_TEMP_FILE_FOR_RANDOM_WRITE YES  --config
AWS_ACCESS_KEY_ID KEY_ID --config AWS_SECRET_ACCESS_KEY ACCESS_KEY

echo end script

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

Re: [gdal-dev] libtiff v4.5.0 release candidate available

2022-12-10 Thread Kai Pastor, DG0YT 

Thanks for your work!

There is an issue with tiff_vers.h:
The new linebreak style of the TIFF_VERSION_STR definition breaks 
version detection in CMake's FindTIFF.cmake,
leaving TIFF_VERSION unset (in CMake). Some packages rely on this 
variable. E.g. openimageio in vcpkg:


-- Found TIFF
CMake Error at src/cmake/checked_find_package.cmake:154 (if):
  if given arguments:

    "VERSION_LESS" "4.0"

  Unknown arguments specified
Call Stack (most recent call first):
  src/cmake/externalpackages.cmake:90 (checked_find_package)
  CMakeLists.txt:141 (include)


which probably comes from some

if(${TIFF_VERSION} VERSION_LESS "4.0")

I would suggest to restore a formatting which doesn't break existing 
CMake code.


Regards, Kai

Am 09.12.22 um 16:48 schrieb Even Rouault:

Hi,

I've prepared a release candidate for libtiff v4.5.0:

- https://download.osgeo.org/libtiff/tiff-4.5.0rc1.tar.gz
- https://download.osgeo.org/libtiff/tiff-4.5.0rc1.tar.gz.sig
- https://download.osgeo.org/libtiff/tiff-4.5.0rc1.tar.xz
- https://download.osgeo.org/libtiff/tiff-4.5.0rc1.tar.xz.sig
- https://download.osgeo.org/libtiff/tiff-4.5.0rc1.zip
- https://download.osgeo.org/libtiff/tiff-4.5.0rc1.zip.sig

Release notes at https://libtiff.gitlab.io/libtiff/releases/v4.5.0.html

I'll promote it to final next week if no serious blocking issues are 
reported.


Thanks to all contributors.

Best regards,



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