Skip to content

Fix various bugs with raster data and tiling - #215

Draft
pyrollo wants to merge 3 commits into
mainfrom
pyr/fix-raster
Draft

pyrollo wants to merge 3 commits into
mainfrom
pyr/fix-raster

Conversation

@pyrollo

@pyrollo pyrollo commented Oct 9, 2026

Copy link
Copy Markdown
Contributor

Issue

May solve #191 (to be tested).

Changes

Three different ones:

  • Fix a probable future bug due to FloatArrayGeographicDataMatrix2d.getFloat returning unwanted value if x out of bounds;
  • Adapt WMS resolution to real needs instead of always asking one pixel per map unit;
  • Start fixing tiled rendering of GeoTiff data (main part of this PR).

Feature description

TODO

Technical changes

TODO

Only half way is done (maybe more).

  • We no more add or remove 0.5 to voxel and map data coordinates to try to adjust centers, now all voxel and pixel coordinates are supposed to be those of voxel/pixel center.
  • GeoTIFF is correctly placed (previously, placement was wrong and changed on each tile, causing artifacts on tiles edges).
Deal with raster data

When we use raster data we have to do an extra computation that was forgotten.

We used to :

  • Convert world bbox into source data CRS;
  • Deduce image properties (size and map position) from resulting envelope;
  • Compute raster data offset and cellsize from image properties and envelope;

That last step was wrong. If cell size is large, that would be very inaccurate.
The real cellsize and offset should be computed from actual raster data sample position (this does not depend on envelope).

So the new process should be:

  • Convert world bbox into source data CRS;
  • Deduce image properties (size and map position) from resulting envelope;
  • Compute image (0,0) sample position and size in source data CRS, these are the correct offset and cellsize;

TODOs

  • Complete PR text
  • Test how GeoTIFF data behaves on image borders
  • Recheck WMS raster data management to see if it is correct according to the new process

Self-checks

  • The code has unit tests associated
  • The code has Javadoc Comments associated
  • Complex / Unexpected code is explained / justified with a small comment
  • Relevant documentation inside the /docs folder has been updated
  • All examples in examples/ work the same (or have been adapted if subject to changes in this PR)
  • Git history is clean (each commit accomplish a single task and describe it accordingly)
  • The texts have been proofread (documentation, error messages, logs, comments...)

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant