Skip to content

Comments

r.slope.aspect: replace GSAG test data with AAGRID#5792

Merged
echoix merged 1 commit intoOSGeo:mainfrom
marisn:convert_gsag_bug5787
May 30, 2025
Merged

r.slope.aspect: replace GSAG test data with AAGRID#5792
echoix merged 1 commit intoOSGeo:mainfrom
marisn:convert_gsag_bug5787

Conversation

@marisn
Copy link
Contributor

@marisn marisn commented May 29, 2025

GDAL >=3.11.0 does not support GSAG any more. This PR just replaces GSAG files with ones converted to AAGRID.

Fixes bug #5787

@marisn marisn added the tests Related to Test Suite label May 29, 2025
@echoix
Copy link
Member

echoix commented May 29, 2025

How did you convert them? The previous files have some values that are represented exactly as "1.70141E+38", but the NODATA value here is "NODATA_value 1.701410000000000071e+38", and that number is found multiple times.

Would this be affecting the stats/snapshots we might have taken?

@marisn
Copy link
Contributor Author

marisn commented May 29, 2025

Pure gdal_translate without any extra options. I thought about DECIMAL_PRECISION, but that could change obtained results.

@github-actions github-actions bot added raster Related to raster data processing Python Related code is in Python module labels May 29, 2025
@neteler neteler added this to the 8.5.0 milestone May 29, 2025
@neteler neteler added the backport to 8.4 PR needs to be backported to release branch 8.4 label May 29, 2025
Copy link
Member

@echoix echoix left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried out locally, what would be the difference if keeping the original amount of digits (without adding some approximate ones near the end). There was no difference.

Except that I realized that the precision requested was quite low, for two numbers that have an error in the 6e-5 range. Other than that, two reference values only had 5 digits or so, and then the rest can use 1e-14 precision (except one that fails at 1e11). Note that it isn't using relative error, so 1e-11 can mean the same when the number compared is already small.

I could file that work in another PR if needed. Important for now is to unblock PRs to the repo.

@echoix echoix merged commit 56c55e8 into OSGeo:main May 30, 2025
24 checks passed
@echoix
Copy link
Member

echoix commented May 30, 2025

I updated the PRs that were blocked by this

@marisn marisn deleted the convert_gsag_bug5787 branch May 30, 2025 05:35
echoix added a commit that referenced this pull request May 30, 2025
Follow-up from #5792.

This PR uses a smaller delta for the differences accepted between actual and reference values. The current tests were quite loose, and would probably not help us catch regressions unless the differences were huge. Since it is mostly a golden test, we want to know when anything changes.

* Increase r.slope.aspect precision

* Add more digits to the reference mean values of test_slope

* Increase r.slope.aspect precision to 1e-14, except where results fail

* Add note to use a smaller precision threshold or self.precision

* Apply suggestions from code review
nilason pushed a commit that referenced this pull request Nov 18, 2025
GDAL >=3.11.0 does not support GSAG any more. This PR just replaces GSAG files with ones converted to AAGRID.

Fixes bug #5787
@nilason nilason modified the milestones: 8.5.0, 8.4.2 Nov 18, 2025
@nilason nilason removed the backport to 8.4 PR needs to be backported to release branch 8.4 label Nov 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

module Python Related code is in Python raster Related to raster data processing tests Related to Test Suite

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants