Check for consistent handling of pixel locations

[ansoncfit]

Geotiff exports suggest top left corners are used. For display, the web UI adjusts by half a pixel. We should check for coherence, especially with regards to intersection with opportunity data.

[ansoncfit]

This may be limited to geotiff exports of time grids, which uses a GridCoverage2D with this hard-wired: private static final PixelInCell PIXEL_IN_CELL = PixelInCell.CELL_CORNER;

[abyrd]

Based on our initial review earlier today, we believe R5 is properly distinguishing between pixel corners and centers, as indicated by differentiated use of pixelToCenterLon vs. pixeltoLon methods.

As @ansoncfit stated above, the problem may be entirely within the GeoTools export to GeoTIFF. R5's TimeGrid#writeGeotiff uses a GridCoverageFactory to create a GridCoverage2D from a WritableRaster. The GridCoverageFactory calls the GridCoverage2D constructor, which is hard-wired to create a GridGeometry2D and a MathTransform using PixelInCell.CELL_CORNER.

The documentation on that hardwired constant says "Whatever default grid range computation should be performed on transform relative to pixel center or relative to pixel corner. The former is OGC convention while the later is Java convention." The WritableRaster we are using to hold the output data is from java.awt.image, not from GeoTools, which might explain this conversion. But it's not entirely clear to me what is meant by "grid range" here - this needs to be verified as it might not be exactly what we're concerned about.

Note that that comment says "default grid range computation". This default seems to refer to a GridGeometry2D which is created several frames down into nested GridCoverageFactory.create() calls. It seems possible to manually override this behavior by calling one of these create() methods with more parameters, including our own grid geometry that does not trigger the default CELL_CORNER behavior. But this seems very roundabout and involves duplicating code from within GeoTools itself.

Another possibility would be to just change the ReferencedEnvelope we supply to match the GridCoverageFactory's expectations. This implies a rather confusing self-canceling double half-pixel shift just to strictly follow Java's definition of image coordinates, but it should do the job. Grid#getMercatorEnvelopeMeters calls Grid#mercatorPixelToMeters, which accepts parameters of type double. We could just subtract 0.5 from the pixel values passed in (though we'd need to double-check that we shouldn't add 0.5 to bottomRight, it looks to me like we'd subtract in both cases upperLeft and bottomRight).

Once the GeoTIFF export problem is addressed, we should nonetheless do an audit of other places the pixel corner / center distinction might cause problems:

• Linking grids to the street network (pixel center should be used as sample point)
• Aggregating opportunities into pixels in the backend (corner to corner pixel area should be used)
• Aggregating opportunities into pixels in the frontend (should only reuse precomputed info from the backend, taking reported travel time to be representative of travel time to all opportunities within that pixel's corner to corner area)
• Displaying regional results in the frontend (gridualizer should interpolate patches between pixel centers, except for nearest-neighbor where pixels are filled corner-to-corner with the value)

[abyrd]

Also: When messing with Geotools GeoTiff calls, we may want to update it to version 21 or 22. This will however also update the JTS dependency (new package name), which could interfere with software that uses R5 as a dependency, so we need to check for incompatibilities.