Repository navigation
v.what.strds: make the test data position-dependent - #7930
Merged
Merged
Conversation
The rasters held a single value each, so a point sampled the same number wherever it was and a pixel shift or a reordered point could not change the result. Each raster is now map_number * 1000 + row() * 10 + col(), and the points sit at known cell centres created with v.in.ascii instead of seeded v.random, so every cell holds a distinct value. The row assertion now compares whole rows including the category, rather than dropping the first column, and the fixture docstring no longer claims the points share a location. Follow-up to OSGeo#7898, as discussed there.
github-actions
Bot
added
vector
Valyrian-Code
marked this pull request as ready for review
September 27, 2026 20:58
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
Fix the non-unique raster encoding and sort query results by category before comparison.
Review effort: Lite
Findings: 1
Open (1)
What changed in this PR
Updates v.what.strds tests with deterministic points and position-dependent raster values.
Changes:
- Uses known cell-centre coordinates.
- Encodes raster row and column positions.
- Compares complete output rows, including categories.
| File | Summary |
|---|---|
scripts/v.what.strds/tests/v_what_strds_test.py |
Strengthens test data and assertions. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
row() * 10 + col() collides once the region has more than nine columns: with twelve, (row 1, col 11) and (row 2, col 1) both give 21. The three sampled cells happened not to collide, so the test passed, but the comment claimed more than the encoding delivered. Use row() * 100 + col().
ninsbl
approved these changes
Oct 9, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #7898, where @ninsbl pointed out each raster held a single value, so a point sampled the same number wherever it sat.
Rasters are now
map_number * 1000 + row() * 10 + col(), with the points at known cell centres viav.in.asciiinstead of seededv.random. Checked both failure modes fail now and passed before: moving a point one cell east, and swapping two points' categories.Also the two Copilot notes from #7898: whole rows are compared instead of dropping the category column, and the docstring no longer claims the points share a location.