Repository navigation
Conversation
783b6f0 to
00b96e9
Compare
[Maven Build Status]📑 Commit: 📦 Download artifact: voxatile.jar |
indyteo
added
type: bug
| // Compute in grid envelope (pixel envelope) | ||
| GridEnvelope2D gridEnvelope; | ||
| try { | ||
| gridEnvelope = grid.getGridGeometry().worldToGrid(envelope); | ||
| } catch (FactoryException | TransformException | org.geotools.api.referencing.operation.TransformException e) { | ||
| } catch (InvalidGridGeometryException | org.geotools.api.referencing.operation.TransformException e) { | ||
| throw new GenerationFailedException(e); | ||
| } | ||
|
|
||
| // This will ensure we have enough pixels for interpolation | ||
| // - First, we need to be sure we always have four samples around each voxel center. | ||
| // I.E: we need to be sure we always include outer samples | ||
| // gridEnvelope only includes a sample if original envelope overlaps its pixel. | ||
| // this means outer sample is only included if envelope limit is closer to them than to inner sample. | ||
| // - Then, we have to fix envelope computation which excludes last line/column. | ||
| // We could do that more accurately. Growing by 2 pixel in every direction will work but may include one or two useless pixel columns or lines. | ||
| // TODO: grown envelope may overflow out of raster data. Is this correct? | ||
| gridEnvelope.grow(2, 2); |
There was a problem hiding this comment.
Have you looked at worldToGrid method? Inside, you can see it is computed using the lower and upper bounds. Maybe we should replace its call with a function of our own, with lower-1 and upper+1 bounds? Or maybe not 1, but something depending on voxel size?
It would probably be the cleanest option to avoid the grow
There was a problem hiding this comment.
I saw there may be a field or something in GeoTIFF format that should tell where is the anchor and worldToGrid does not take it in account anyway..
Having our own function is probably the cleanest solution but... does it worth it? I'm wondering. Grow will not increase amount of fetched data much. Maybe we could do that now and improve that with margin management development.
There was a problem hiding this comment.
Of course I still have to check the overflow issue. If it works as is, that would also mean that we don't need to intersect envelopes above (would be strange, but why not).
There was a problem hiding this comment.
Intersection was needed to avoid out of bounds exception iirc, so I guess the grow will need to be checked
This branch has not been deployed
2 participants
Issue
Closes #191
Closes #210
Changes
Three different ones:
FloatArrayGeographicDataMatrix2d.getFloatreturning unwanted value ifxout of bounds;Wrong cellsize / offset computation
We were doing something wrong with GeoTiff (and maybe with other raster data). Here is a try to explain what was wrong and what to do.
Raster data is made of sample, placed on a regular grid in a given CRS.
To deal with this data, we need to know:
Raster samples are represented by blue dots. Purple dot is (0,0) and arrows shows the spacing of the raster grid.
Now, we want to use some of these samples to draw some voxels. Voxels and samples may not be on the same grid (depending on the CRS, the grids may even look distorted from each other). Lets place voxel grid on raster samples grid:
Voxel grid is represented with grey squares. We want to draw the voxel tile represented by the red square.
First, we have to select raster sample. That's another issue. Let's say we are able to select the correct samples:
Selected samples are in purple (we need samples around voxels so we can interpolate). The samples envelope is draw as purple square (here we consider only samples, some implementation consider a square around sample but that is also another issue).
Here what we did wrong when calculating offset/cellsize before this PR:
Offset and cellsize where calculated according to voxel envelope (red box) but it should have been calculated from raster samples envelope. This lead distort sample positions.
In most cases that was almost invisible. But with large cells and tiling, we could see a gap in resulting values between tiles (as samples are not distorted the same way by adjacent tiles).
Raster sample selection issue
Selecting samples we need may be a issue.
For GeoTiff, we rely on Geotools GridCoverage2D to compute the set of samples needed. This causes an issue as samples are not considered as dot but as squares (or cells). Sample is at cell center (this could be different in some geotiff files, to be dug).
If selection contains only intersecting cells, we will have something like that:
We need data for voxels in the red box.
Selected samples will be the purple ones because their cell intersect with our red box.
The voxel marked with the red dot is missing some sample to be able to interpolate a value. Missing samples are drawn in light blue. They are missing because the edge of the red box is closer to the sample on the left. On top of the red box, we have all samples we need because the top of the red box is closer to outer samples.
Red box is drawn as if we were considering voxels as cells but actually, we consider them as dots. So the actual box is half a voxel smaller in every direction.
This issue is not really solved in that PR. We simply grow the sample envelope by two in all direction so we are sure to have enough samples.
Dot-Samples or Square-samples issues
TODO
TODOs
Self-checks
Relevant documentation inside the/docsfolder has been updatedexamples/work the same (or have been adapted if subject to changes in this PR)The texts have been proofread (documentation, error messages, logs, comments...)