-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gdalwarp time increase for vertical datum conversion #5414
Comments
can you try to download https://cdn.proj.org/us_nga_egm96_15.tif instead and use +geoidgrids=us_nga_egm96_15.tif instead in your PROJ string ? There are known inefficiencies in the way the new GTX reader in PROJ proceeds, which should not be present with the TIFF reader |
Thanks a lot for the fast solution @rouault! Using this on Windows decreases the time to approx. 6s. This is wonderful. I now get about the same difference in time between versions as on Ubuntu. Is this difference expected? |
if your question is about the difference of runtime between GDAL 3.3.3 and GDAL 3.4.1, the later uses a more accurate way of applying the vertical offset (which might not be that visible for your use case) which has longer runtime. |
Excellent. I was mostly interested in the difference between GDAL versions. Thanks a lot @rouault. |
Expected behavior and actual behavior.
Hi. I have noticed a steep increase in compute time when converting the vertical datum of a DEM with gdalwarp. In GDAL 3.3.3 this is a matter of seconds while with GDAL 3.4.1 it takes several minutes on Windows. The difference on Ubuntu is not quite as high but it still took more than three time as long. For regular CRS conversion, e.g. to UTM, this cannot be observed.
Steps to reproduce the problem.
Linux bash only:
Operating system
Ubuntu 20.04 (via WSL), Windows 10
GDAL version and provenance
four different conda environments:
The text was updated successfully, but these errors were encountered: