Re: [gdal-dev] How to stop gdal_translate using overviews when resampling

2021-05-28 Thread Jon Morris 

Hi Even,

Thanks for getting back to me. I should have mentioned we're using the Python 
bindings, but presumably we can still do something like this?
ds = gdal.OpenEx(path, open_options=['OVERVIEW_LEVEL=NONE'])

Jon

e: jon.mor...@jbarisk.com
t: +44 (0)1756 799919
www.jbarisk.com
All JBA Risk Management's email messages contain confidential information and 
are intended only for the individual(s) named. If you are not the named 
addressee you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately by email if you have received this email 
by mistake and delete this email from your system.
JBA Risk Management Limited is registered in England, company number 07732946, 
1 Broughton Park, Old Lane North, Broughton, Skipton, North Yorkshire, BD23 
3FD, England.
From: Even Rouault 
Sent: 28 May 2021 15:03
To: Jon Morris ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] How to stop gdal_translate using overviews when 
resampling


With GDAL 3.3, you could add -oo OVERVIEW_LEVEL=NONE. See 
https://gdal.org/api/raster_c_api.html?highlight=overview_level#_CPPv410GDALOpenExPKcjPPCKcPPCKcPPCKc
Le 28/05/2021 à 15:56, Jon Morris a écrit :
Hello all,

One of our users reported a difference in outputs after we upgraded from GDAL 
2.2 to 3.2. Our tool is using gdal_translate to resample a raster from 5m to 
10m and the outputs are very different.

I'm ok with things changing between major versions, but when investigating, I 
found that the outputs also change depending on whether the input file has 
overviews. I was aware of the issue with gdalwarp where overviews are used as a 
shortcut 
(http://erouault.blogspot.com/2014/10/warping-overviews-and-warped-overviews.html),
 but haven't been able to find anything similar in the docs or the code when it 
comes to gdal_translate.

Should overviews make a difference? Is there any way to disable this behaviour, 
so the resampling is always done using the input raster and not the overviews?

Thanks,

Jon

Jon Morris
Software Developer


e: ​
jon.mor...@jbarisk.com
t:
+44 (0)1756 799919
www.jbarisk.com
[cid:image001.png@01D753D5.37F15020]
[Facebook]
[LinkedIn]
[Twitter]
[YouTube]



All JBA Risk Management's email messages contain confidential information and 
are intended only for the individual(s) named. If you are not the named 
addressee you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately by email if you have received this email 
by mistake and delete this email from your system.
JBA Risk Management Limited is registered in England, company number 07732946, 
1 Broughton Park, Old Lane North, Broughton, Skipton, North Yorkshire, BD23 
3FD, England.



___

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 stop gdal_translate using overviews when resampling

2021-05-28 Thread Even Rouault 
With GDAL 3.3, you could add -oo OVERVIEW_LEVEL=NONE. See 
https://gdal.org/api/raster_c_api.html?highlight=overview_level#_CPPv410GDALOpenExPKcjPPCKcPPCKcPPCKc


Le 28/05/2021 à 15:56, Jon Morris a écrit :


Hello all,

One of our users reported a difference in outputs after we upgraded 
from GDAL 2.2 to 3.2. Our tool is using gdal_translate to resample a 
raster from 5m to 10m and the outputs are very different.


I'm ok with things changing between major versions, but when 
investigating, I found that the outputs also change depending on 
whether the input file has overviews. I was aware of the issue with 
gdalwarp where overviews are used as a shortcut 
(http://erouault.blogspot.com/2014/10/warping-overviews-and-warped-overviews.html 
), 
but haven't been able to find anything similar in the docs or the code 
when it comes to gdal_translate.


Should overviews make a difference? Is there any way to disable this 
behaviour, so the resampling is always done using the input raster and 
not the overviews?


Thanks,

Jon

*Jon Morris*

*Software Developer*

e: ​*jon.mor...@jbarisk.com* 
t:  *+44 (0)1756 799919* 



*www.jbarisk.com* 

Facebook 


LinkedIn 


Twitter 


YouTube 



All JBA Risk Management's email messages contain confidential 
information and are intended only for the individual(s) named. If you 
are not the named addressee you should not disseminate, distribute or 
copy this e-mail.
Please notify the sender immediately by email if you have received 
this email by mistake and delete this email from your system.
JBA Risk Management Limited is registered in England, company number 
07732946, 1 Broughton Park, Old Lane North, Broughton, Skipton, North 
Yorkshire, BD23 3FD, England.



___
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] How to stop gdal_translate using overviews when resampling

2021-05-28 Thread Jon Morris 
Hello all,

One of our users reported a difference in outputs after we upgraded from GDAL 
2.2 to 3.2. Our tool is using gdal_translate to resample a raster from 5m to 
10m and the outputs are very different.

I'm ok with things changing between major versions, but when investigating, I 
found that the outputs also change depending on whether the input file has 
overviews. I was aware of the issue with gdalwarp where overviews are used as a 
shortcut 
(http://erouault.blogspot.com/2014/10/warping-overviews-and-warped-overviews.html),
 but haven't been able to find anything similar in the docs or the code when it 
comes to gdal_translate.

Should overviews make a difference? Is there any way to disable this behaviour, 
so the resampling is always done using the input raster and not the overviews?

Thanks,

Jon

Jon Morris
Software Developer



e: jon.mor...@jbarisk.com
t: +44 (0)1756 799919
www.jbarisk.com
All JBA Risk Management's email messages contain confidential information and 
are intended only for the individual(s) named. If you are not the named 
addressee you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately by email if you have received this email 
by mistake and delete this email from your system.
JBA Risk Management Limited is registered in England, company number 07732946, 
1 Broughton Park, Old Lane North, Broughton, Skipton, North Yorkshire, BD23 
3FD, England.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: adopt RFC 81: support for coordinate epochs in geospatial formats

2021-05-28 Thread jratike80 
Hi,

I guess that by "data" you mean datasets like GeoJSON file or GeoTIFF image. 
For individual coordinates folks in the Finnish Geospatial Institute (FGI)
do conversions like in this cs2cs example 

echo 2258573.56109 1010806.43899 5859099.49087 2021.26 | cs2cs -d 4 --area
finland EPSG:7789 EPSG:4936

where "2021.26" after the x, y, and z coordinates is the epoch and it gets
used with this operation:

projinfo -s EPSG:7789 -t EPSG:4936 -o PROJ --area Finland
-
Operation No. 1:
NKG:ITRF2014_TO_FI, ITRF2014 to ETRS89 (EUREF-FIN), 0.01 m, Finland -
onshore and offshore.
PROJ string:
+proj=pipeline
+step +proj=helmert +x=0 +y=0 +z=0 +rx=0 +ry=0 +rz=0 +s=0 +dx=0 +dy=0 +dz=0
+drx=8.5e-05 +dry=0.000531 +drz=-0.00077 +ds=0 +t_epoch=1989
+convention=position_vector
+step +inv +proj=deformation +t_epoch=2000.0 +grids=eur_nkg_nkgrf17vel.tif
+step +proj=helmert +x=0.15651 +y=-0.10993 +z=-0.10935 +rx=-0.00312861
+ry=-0.00378935 +rz=0.00403512 +s=0.00529 +convention=position_vector +step
+proj=deformation +dt=-3 +grids=eur_nkg_nkgrf17vel.tif

The same thing with Python:

transformer = pyproj.Transformer.from_pipeline("""
+proj=pipeline
+step +proj=helmert +x=0 +y=0 +z=0 +rx=0 +ry=0 +rz=0 +s=0 +dx=0
+dy=0 +dz=0 +drx=8.5e-05 +dry=0.000531 +drz=-0.00077 +ds=0
+t_epoch=1989 +convention=position_vector
+step +inv +proj=deformation +t_epoch=2000.0
+grids=eur_nkg_nkgrf17vel.tif
+step +proj=helmert +x=0.15651 +y=-0.10993 +z=-0.10935
+rx=-0.00312861 +ry=-0.00378935 +rz=0.00403512 +s=0.00529
+convention=position_vector
+step +proj=deformation +dt=-3 +grids=eur_nkg_nkgrf17vel.tif""")
coord = transformer.transform(x_wgs84, y_wgs84, z_wgs84, year)

-Jukka Rahkonen-


Nyall Dawson wrote
> On Thu, 27 May 2021 at 23:40, Even Rouault <

> even.rouault@

> > wrote:
>>
>> Hi,
>>
>> - merging the underlying API without any format support is I believe of
>> little interest.
> 
> Well.. it would give users the command line tools to do static <->
> dynamic transformation of data with the epoch specified in the command
> line arguments. That's a quite compelling feature on its own, as it
> could be used to transform data if the user has knowledge of the epoch
> from other sources (e.g. in some pdf doc provided with the data, or if
> they collected it themselves and know the correct epoch). I'm unaware
> of any other tool (commercial or open source) which currently allows
> this type of transformation.
> 
> Nyall
> ___
> gdal-dev mailing list

> gdal-dev@.osgeo

> https://lists.osgeo.org/mailman/listinfo/gdal-dev





--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev