Hi Norman,
I think I hit that same kind of issue when implementing raster support
in GeoMesa with Accumulo years ago. If it is the same issue, we got
around by guessing when GeoServer was making a registration request and
GeoMesa returned a blank image with the requested envelope[1].
At least I think that's what the code was doing. We've since deprecated
and removed raster support. IMO, it is preferable to store
raster/imagery data directly in HDFS/S3/whatever unless one is going to
do something really, really compelling with remote programming in the
distributed database.
Cheers,
Jim
1.
https://github.com/locationtech/geomesa/blob/geomesa_2.11-2.4.1/geomesa-accumulo/geomesa-accumulo-raster/src/main/scala/org/locationtech/geomesa/raster/wcs/GeoMesaCoverageReader.scala#L63-L67
On 5/3/21 12:29 PM, Norman Bobroff wrote:
Hi,
I have developed an extension to Geoserver to expose IBM's searchable
store of raster satellite data ( geospatially indexed in HBase) as a
Geoserver raster layer.
To the Geoserver client, the data appears as a new type of Geoserver
DataStore which is published as a global geoserver layer. Multiple
clients can request images through this new layer exposed by our
extension/plugin using WMS protocol. This plugin function is
implemented using the Geoserver/Geotools SPI Interfaces
DataStoreFactorySpi and GridFormatFactorySpi. Then I extend
AbstractGridCoverage2DReader to return a multiband GridCoverage2D to
Geoserver when invoked through the GridCoverage2DReader.read(...) method.
This extension has worked well for a couple years rendering dynamic
images to the Geoserver client leveraging Geoserver to do SLD, WPS
processing for us.
Recently however, I need to add support for WCS getCoverage() format
to return a GeoTiff and am encountering an issue. A WCS getCoverage
operation invokes the GridCoverage2DReader.read(...) in my extension
extension in the same way as with WMS getMap. I'm called with an
AbstractGridFormat.READ_GRIDGEOMETRY2Dparameter with a request
envelope that matches the 'subset' region on the WCS request. ( A
sample GET request is below.) On the first WCS request after a
Geoserver start I get a request envelope that is the WCS subset of the
request. Lets say, as the sample request below, a 4 x 4 degree region
in India. (Note, the extent property of the published layer in
Geoserver layer is global (-180, -90) -> (180, 90)). I go get the data
and hand back a GridCoverage2D with a raster for this region
specifying the envelope of the data, ( i.e. the 4 x 4 degree box) . So
far, all is good and the returned Geotiff looks fine in gdalinfo and
when used as a QGIS data source.
The problem is on the all subsequent WCS queries which are for a
different subsets of the layer. For every subsequent request, the
requestEnvelope that comes in AbstractGridFormat.READ_GRIDGEOMETRY2is
identical to what I returned in the first request, the 4x4 degree
patch in India. The result is if there is no overlap between the
subsequent request envelope in and that of the original query no data
is returned. If there is some overlap between the original spatial
subset and that of subsequent queries, the overlap is returned. From
this behavior I see at a naive level that the intent of a WCS query
is to get back the extant of the layer Coverage and then crop it down
to the requested subset. Unlike a WMS request where I just hand
geoserver a gridCoverage with the dat of the BBOX argument.
It seems Geoserver is deciding after the first request that the extant
of the coverage of the layer is limited to what I returned and keeping
that info until I restart the Geoserver.
There must be some information I am failing to provide in the return
gridCoverage that lets Geoserver know I am only giving a small area
back of the global coverage of the layer. And not to cache the extant
as that of the entire layer. These are very high resolution images and
at different timestamps. It is not possible to return the entire
global raster coverage for Geoserver to crop down to the requested
sub-region.
I have tried turning off all the caches that I know of. I also suspect
the solution may have something to do with the affine transform that
is passed in on the request. But I don't have any ideas how to
continue here.
(Sample request, the parameters with 'ibmpairs' are custom extension
indicating what raster data to fetch out of HBase).
http://localhost:8080/geoserver/pairs/wcs?service=WCS&version=2.0.1&request=getcoverage&format=tiff&coverageid=pairs__pairspluginlayer&width=1920&height=960&ibmpairs_layerid=49523&ibmpairs_timestamp=1262304000&bbox=15,78,19,82&subset=Long(78,82)&subset=Lat(15,19)&SUBSETTINGCRS=EPSG:4326
Thanks for your help,
Norm
Norman Bobroff 914 945 2094
bobr...@us.ibm.com
_______________________________________________
Geoserver-users mailing list
Please make sure you read the following two resources before posting to this
list:
- Earning your support instead of buying it, but Ian Turton:
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines:
http://geoserver.org/comm/userlist-guidelines.html
If you want to request a feature or an improvement, also see this:
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
_______________________________________________
Geoserver-users mailing list
Please make sure you read the following two resources before posting to this
list:
- Earning your support instead of buying it, but Ian Turton:
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines:
http://geoserver.org/comm/userlist-guidelines.html
If you want to request a feature or an improvement, also see this:
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
