Closed mmcfarland closed 7 years ago
Comparing vectors drawn over the rendered (3857
) tiles against the same vector over the source raster (reprojected to 3857
) shows why the processed output of the data raster does not match expected output based on visual inspection of the rendered tile. Three types of discrepancies seem to exist between the rendered tiles and the source raster used in analysis:
5070
-> 3857
via qgis)
Tiled (from same source, also in 3857
via GT)
As a result of these various problems, vectors drawn over the rendered tiles don't tend to select the intended cells for modeling. Even where the glitch/offset is less pronounced, the orientation of the cells means that other cell boundaries can be intersected slightly, even if the rendered vs source cells basically line up. We are currently using any intersection for cell inclusion, not just centroid. In other areas, the cells are simply not in the right place.
The effect in total is small, only ever affecting an area by about one cell width (30m), but it's amplified in this application because the areas of interest can be as small as a dozen cells. Also, within that dozen there may be a value represented a single time, which means it's very noticeable when that cell value is not included in analysis output when it looks like it should be.
It doesn't appear that the tiled images in use now are accurate enough to use in the application, although they were created at some expense. We could switch to including only cells that have had their centroid included, which would ameliorate some of the imprecision, but not all. The consequence of that is that when small areas are drawn horizontally or vertically, they may cross no centroids at all, which is also problematic.
This has resulted in an upstream GT fix, we'll need to reingest after a snapshot build is available https://github.com/locationtech/geotrellis/pull/2216
Crops on screen seem to bee offset by about half a cell width. Determine if this is a projection issue, a rendered tile issue or other.