Conversions between GeoTools GridCoverage2D and GeoTrellis Raster types #1502
Conversation
According to the documentation[1], DataBuffer.TYPE_BYTE corresponds to "unsigned byte" not "byte". 1. https://docs.oracle.com/javase/7/docs/api/java/awt/image/DataBuffer.html
Since all bands of Geotrellis MultibandTiles must all have the same cellType and NODATA value, that particular type is not a good candidate for representing the data in a GeoTools GridCoverage2D. The best analog of a GeoTools GridCoverage2D is an Array of Geotrellis Rasters. Also, the converter now emits *ConstantNoDataCellType when it can.
The Raster[Tile] to GridCoverage2D transformation provides best-guess ColorModels to the created GridCoverage2D objects. The Raster[MultibandTile] to GridCoverage2D transformation does not attempt to provide ColorModel information. NODATA metadata is now correct in both the Tile case and MultibandTile case.
Since all bands of Geotrellis MultibandTiles must all have the same cellType and NODATA value, that particular type is not a good candidate for representing the data in a GeoTools GridCoverage2D. The best analog of a GeoTools GridCoverage2D is an Array of Geotrellis Rasters. Also, the converter now emits *ConstantNoDataCellType when it can.
The Raster[Tile] to GridCoverage2D transformation provides best-guess ColorModels to the created GridCoverage2D objects. The Raster[MultibandTile] to GridCoverage2D transformation does not attempt to provide ColorModel information. NODATA metadata is now correct in both the Tile case and MultibandTile case.
|
+1 This looks good to me. There is quite a bit of test coverage and I was able to confirm that this produces I think that a valuable contribution would have been a concrete suggestion for compactifying some of the larger chunks of code, but unfortunately -- to the best of my knowledge -- the visual/textual similarity between different blocks of code is not necessarily easily addressed in a statically-typed language without using higher-order functions (or lisp-like macros). |
| ProjectedRaster(toRaster(bandIndex), crs) | ||
| case None => | ||
| // Default LatLng | ||
| ProjectedRaster(toRaster(bandIndex), LatLng) |
There was a problem hiding this comment.
I wonder if it is worth emitting a warning here and/or giving a big warning in the source code that a CRS is being assumed.
|
I think that |
|
@jamesmcclain good call. Can you do that in you do that in your SimpleFeature PR? |
Indeed. |
Supersedes #1444