Re: [gdal-dev] GTI: override SRS of source tiles (disable reprojection)

[Craig de Stigter via gdal-dev]

Thanks for the replies. Using a FGB tile index without GTI/VRT
unfortunately doesn't solve the problem since at some point the caller will
still have to (pointlessly) transform the tiles, but thanks for the
suggestion anyway.

The VRT connection string sounds ideal; I hadn't seen that before. I had
been considering adding VRTs for each tile but tons of XML files lying
around wasn't very appealing, so it's great that we can do that without the
extra files!

Thanks
Craig

On Wed, 19 Mar 2025 at 22:24, Even Rouault 
wrote:

> Craig,
> >
> > Is there a way to override the projection of the source tiles when
> > using the GTI driver?
>
> One way would be to put in the GTI index
> "vrt:///path/to/file?a_srs=srs_def" where srs_def is an EPSG code or a
> WKT string (cf
> https://gdal.org/en/stable/drivers/raster/vrt.html#vrt-connection-string)
>
> Even
>
> --
>
> http://www.spatialys.com
> My software is free, but my time generally not.
>
>

-- 
Regards,
Craig

Platform Engineer
Koordinates
koordinates.com / @koordinates 
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GTI: override SRS of source tiles (disable reprojection)

[Even Rouault via gdal-dev]

Craig,


Is there a way to override the projection of the source tiles when 
using the GTI driver?


One way would be to put in the GTI index 
"vrt:///path/to/file?a_srs=srs_def" where srs_def is an EPSG code or a 
WKT string (cf 
https://gdal.org/en/stable/drivers/raster/vrt.html#vrt-connection-string)


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

[gdal-dev] Yet another GML EPSG::4326 offsetvector XY-order problem

[Riivo Kolka via gdal-dev]

Hi.

I see that gdaljp2metadata.cpp has lots of code for extracting
something useful but I got files that still escape the effort.

Some Pleiades jp2 images that gdalinfo fails to find the
Origin and Pixel Size and reports wrong Corner Coordinates.
gdalinfo only reports (seemingly correct) GeoTransform

I verified that just the order ofs matter.
If i switch the values inside jp2  then gdal detects correct
Origin, Pixel Size and correct Corner Coordinates.

GDAL 3.10.2, released 2025/02/11

Full description in a gist
https://gist.github.com/rkolka/70ef4ac1172d6ed98b51d0412ff73d49
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Yet another GML EPSG::4326 offsetvector XY-order problem

[Even Rouault via gdal-dev]

Hi,

This is a recurring source of confusion as the related specs aren't very 
explicit / clear about that. But all example in 
https://docs.ogc.org/is/08-085r8/08-085r8.html use


|0 positive_value 
negative_value 0 for EPSG:4326, so 
at least the behavior of GDAL is consistent with that, and thus I'd tend 
to believe your Pleiades images are faulty Rather than hacking the file, 
you might try setting the environment variable / configuration option 
GDAL_JP2K_ALT_OFFSETVECTOR_ORDER to YES, although I'm not 100% positive 
it does the exact switch of coefficients that is needed here... Even |


Le 19/03/2025 à 18:51, Riivo Kolka via gdal-dev a écrit :

Hi.

I see that gdaljp2metadata.cpp has lots of code for extracting
something useful but I got files that still escape the effort.

Some Pleiades jp2 images that gdalinfo fails to find the
Origin and Pixel Size and reports wrong Corner Coordinates.
gdalinfo only reports (seemingly correct) GeoTransform

I verified that just the order ofs matter.
If i switch the values inside jp2  then gdal detects correct
Origin, Pixel Size and correct Corner Coordinates.

GDAL 3.10.2, released 2025/02/11

Full description in a gist
https://gist.github.com/rkolka/70ef4ac1172d6ed98b51d0412ff73d49
___
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