Developer’s Corner: Advanced Raster Projection in GeoServer
in this post we would like to talk about some developments we are performing lately to implement a projection handling subsystem for raster, similar to the one we have for vectors which allows us to handles vector data that crosses the international dataline change as well as to replicated vector data over and over to have a seamless continuous map.
In this post we are going to describe the work that needs to be done to achieve this goal in GeoServer. It is going to be a very technical post, sharing information at developer level in case you are wondering how this could be implemented.
Reading the data
This functionality will require the following basic building blocks:
- Read only the portion of the raster data that has been requested, and that’s inside the valid area for the target projection (bbox cut of requested area)
- Read data corrently when the request crosses the dateline, that is, read all the data required (a portion might be on the other end of the world) and at the correct resolution (if we are reading a small area we should not consider it like reading the whole world)
- Make sure the output is contiguous even when working across the dateline
- (optional) Repeat the raster N times for projections that nicely wrap across the datelines (mercator, plate carree)
Composing the final raster
In order to find the areas that we need to load from the original raster we can leverage the vector ProjectionHandler getQueryEnvelopes method, which will return a list of ReferencedEnvelope in the source CRS that represents potential area were we have to read data (e.g., in the dateline cross case, it will return two envelopes at the two dateline ends).
The two raster portions being read cannot be mosaicked right away, because if we do, we’d generate a image that spans the world and all the other operations will not know they don’t need to process the bit in the middle. And trying to move one part to the other side of the dateline before reprojection might cause issues with the code that estimates the warp simplification (as it creates discontinuities in the segments being reprojected to compute the right number of elements in the warp grid).
Long story short, reading rasters might now result in getting back a list of Coverage to be further processed.
Reprojecting and post-processing
Each of the Coverages returned obtained must now be reprojected in a separate way and then we need to apply the special handling for coverage wrapping, to replicate the reprojected areas in the right places, e.g:
In order to find where and how the images need to be replicated with minimal code duplication we can:
- extract the bounds of each read image
- turn it into a Polygon
- feed it to the ProjectionHandler postProcess method, that will return a list of polygons
- use the results to compute the right offsets, and generate N images
- mosaic them to generate the final output
The GeoSolutions team,