[Geoserver-devel] [JIRA] (GEOS-9553) WCS 2.0 should support SUBSET with limitLow=limitHigh
Jukka Rahkonen ( https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A883da887-d047-4a0a-8aab-3c5d883c4f43 ) *created* an issue GeoServer ( https://osgeo-org.atlassian.net/browse/GEOS?atlOrigin=eyJpIjoiZGI2YTY5ZTBhYjBlNDRmOTg5MzM3YmUzMWZkODhkOTQiLCJwIjoiaiJ9 ) / Improvement ( https://osgeo-org.atlassian.net/browse/GEOS-9553?atlOrigin=eyJpIjoiZGI2YTY5ZTBhYjBlNDRmOTg5MzM3YmUzMWZkODhkOTQiLCJwIjoiaiJ9 ) GEOS-9553 ( https://osgeo-org.atlassian.net/browse/GEOS-9553?atlOrigin=eyJpIjoiZGI2YTY5ZTBhYjBlNDRmOTg5MzM3YmUzMWZkODhkOTQiLCJwIjoiaiJ9 ) WCS 2.0 should support SUBSET with limitLow=limitHigh ( https://osgeo-org.atlassian.net/browse/GEOS-9553?atlOrigin=eyJpIjoiZGI2YTY5ZTBhYjBlNDRmOTg5MzM3YmUzMWZkODhkOTQiLCJwIjoiaiJ9 ) Issue Type: Improvement Assignee: Unassigned Components: WCS Created: 26/Mar/20 6:04 PM Priority: Medium Reporter: Jukka Rahkonen ( https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A883da887-d047-4a0a-8aab-3c5d883c4f43 ) Geoserver does not support subsetting (trimming) if the trim value range has same values as both lower and upper limit. That makes GDAL WCS driver to fail in some circumstances. According to WCS standard subset request with trimLow=trimHigh is valid. Geoserver supports WCS 2.0 GetCoverage request that is making subset slicing with one slice value for both spatial axis (lat, long or east,north). The output of such request is a raster with one pixel. This can be tested with URL https://demo.geo-solutions.it/geoserver/wcs?service=WCS&version=2.0.1&request=GetCoverage&coverageid=nurc__Img_Sample&subset=Long(-100)&subset=Lat(22 ) or with local Geoserver http://localhost:8080/geoserver/wcs?service=WCS&version=2.0.1&request=GetCoverage&coverageid=nurc__Img_Sample&subset=Long(-100)&subset=Lat(22 ) However, trimming with ranges that have the lower limit equal to upper limit are failing. https://demo.geo-solutions.it/geoserver/wcs?service=WCS&version=2.0.1&request=GetCoverage&coverageid=nurc__Img_Sample&subset=Long(-100,-100)&subset=Lat(22,22 ) or http://localhost:8080/geoserver/wcs?service=WCS&version=2.0.1&request=GetCoverage&coverageid=nurc__Img_Sample&subset=Long(-100,-100)&subset=Lat(22,22 ) Empty intersection after subsetting According to WCS 2.0.1 standard the trimLow and trimHigh values in SUBSET can be equal: > > > > Requirement 32 /req/core/getCoverage-request-trim-within-extent: > Let the extent of the coverage’s gml:Envelope along the dimension > specified in the trim > request range from L to H. Then, for the trim bounds trimLow and trimHigh > the following > shall hold: L <= trimLow <= trimHigh <= H. > > It would be nice if subset trimming with trimLow=trimHigh would output a single pixel output just like subset slicing with a single subset values already does. Notice: By reading the standard closely it is actually wrong to output a GeoTIFF or any other raster file with the slicing request. A single pixel raster file has still the same number of dimensions as bigger raster coverages while the WCS standard requires that the output must have fewer dimensions. That is only possible when the outputformat is for example GML or something similar. > > > > Requirement 39 /req/core/getCoverage-response-slicing: > The response to a successful GetCoverage request on coverage identifier id > of admissible > type containing no trimming and exactly one slicing operation with > dimension name dname, > and slice point s shall be a coverage identical to c, but containing > exactly those cells from c > which lie within B, with dimension dname removed from both the coverage’s > domain set and > all of the coverage’s cell coordinate positions, with the number of > dimensions of the result > coverage set to the number of dimensions of c minus 1. > > I consider that the way how Geoserver behaves now is a feature and not a bug. ( https://osgeo-org.atlassian.net/browse/GEOS-9553#add-comment?atlOrigin=eyJpIjoiZGI2YTY5ZTBhYjBlNDRmOTg5MzM3YmUzMWZkODhkOTQiLCJwIjoiaiJ9 ) Add Comment ( https://osgeo-org.atlassian.net/browse/GEOS-9553#add-comment?atlOrigin=eyJpIjoiZGI2YTY5ZTBhYjBlNDRmOTg5MzM3YmUzMWZkODhkOTQiLCJwIjoiaiJ9 ) Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core&referrer=utm_source%3DNotificationLink%26utm_medium%3DEmail ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailNotificationLink&mt=8 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100122- sha1:93a3ad8 ) ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] [JIRA] (GEOS-9552) [GeoFence Plugin] "LIMITS" type rules seem failing for ImageMosaics
Alessio Fabiani (
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A0027cfac-890c-48e1-8af0-974f12f7b9dc
) *created* an issue
GeoServer (
https://osgeo-org.atlassian.net/browse/GEOS?atlOrigin=eyJpIjoiMzdlMmQ5NmNmZTE0NDE3NGEwYTc1ZDE1YjdlY2Q2NDUiLCJwIjoiaiJ9
) / Bug (
https://osgeo-org.atlassian.net/browse/GEOS-9552?atlOrigin=eyJpIjoiMzdlMmQ5NmNmZTE0NDE3NGEwYTc1ZDE1YjdlY2Q2NDUiLCJwIjoiaiJ9
) GEOS-9552 (
https://osgeo-org.atlassian.net/browse/GEOS-9552?atlOrigin=eyJpIjoiMzdlMmQ5NmNmZTE0NDE3NGEwYTc1ZDE1YjdlY2Q2NDUiLCJwIjoiaiJ9
) [GeoFence Plugin] "LIMITS" type rules seem failing for ImageMosaics (
https://osgeo-org.atlassian.net/browse/GEOS-9552?atlOrigin=eyJpIjoiMzdlMmQ5NmNmZTE0NDE3NGEwYTc1ZDE1YjdlY2Q2NDUiLCJwIjoiaiJ9
)
Issue Type: Bug Affects Versions: 2.15.5, 2.16.2, 2.17-RC Assignee: Unassigned
Components: GeoFence Created: 26/Mar/20 3:29 PM Priority: High Reporter:
Alessio Fabiani (
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A0027cfac-890c-48e1-8af0-974f12f7b9dc
)
By defining a "LIMIT" type access rule for a specific user against an
ImageMosaic, I would expect the outcome to be cropped accordingly to the
specified allowed area.
E.g.:
1. Having an Image Mosaic with about 80 granules on a single dimension with the
following BBOX
SRS = EPSG:3857
NATIVE BBOX =
{x0: 4324501.311667766, y0: -821850.9280018109, x1: 4412556.768240058, y2:
-714227.5921912305}
LL_BBOX =
{x0: 38.847656244660726, y0: -7.362466864463051, x1: 39.638671869550855, y2:
-6.402648405022478}
2. Having a GeoFence LIMIT Rule defined as
{ user: afabiani, access: LIMIT service: *, layer: , catalogMode:
MIXED, allowedArea: SRID=4326;MULTIPOLYGON (((39.21844481882432
-6.670063574969543, 39.39971923288702 -6.822807115777458, 39.39971923288702
-6.986406834755428, 39.22943114694938 -6.975501952613067, 39.21844481882432
-6.670063574969543))) }
When querying the layer I get the following logs:
{{ 2020-03-26 14:08:03,718 DEBUG [geoserver.geofence] - Getting access limits
for Layer planet_satellite_imagies_2018
2020-03-26 14:08:03,718 DEBUG [geoserver.geofence] - Getting access limits for
Resource planet_satellite_imagies_2018
2020-03-26 14:08:03,718 DEBUG [geoserver.geofence] - Setting user for filter:
afabiani
2020-03-26 14:08:03,719 DEBUG [geoserver.geofence] - ResourceInfo filter:
RuleFilter [user:"afabiani"+ role:ANY inst:name+:default-gs
ip:"0:0:0:0:0:0:0:1"+ serv:"WMS"+ req:"GETLEGENDGRAPHIC"+ ws:"geonode"+
layer:"planet_satellite_imagies_2018"+]
2020-03-26 14:08:03,719 DEBUG [geofence.cache] - Request for RuleFilter
[user:"afabiani"+ role:ANY inst:name+:default-gs ip:"0:0:0:0:0:0:0:1"+
serv:"WMS"+ req:"GETLEGENDGRAPHIC"+ ws:"geonode"+
layer:"planet_satellite_imagies_2018"+]
2020-03-26 14:08:03,720 DEBUG [geofence.cache] - Loading RuleFilter
[user:"afabiani"+ role:ANY inst:name+:default-gs ip:"0:0:0:0:0:0:0:1"+
serv:"WMS"+ req:"GETLEGENDGRAPHIC"+ ws:"geonode"+
layer:"planet_satellite_imagies_2018"+]
2020-03-26 14:08:03,722 INFO [services.RuleReaderServiceImpl] - Requesting
access for RuleFilter [user:"afabiani"+ role:ANY inst:name+:default-gs
ip:"0:0:0:0:0:0:0:1"+ serv:"WMS"+ req:"GETLEGENDGRAPHIC"+ ws:"geonode"+
layer:"planet_satellite_imagies_2018"+]
2020-03-26 14:08:03,724 DEBUG [geoserver.security] - Setting ROLES for User
[afabiani] to [ROLE_REGISTERED-MEMBERS]
2020-03-26 14:08:03,724 DEBUG [geofence.internal] - Checking Role
[ROLE_REGISTERED-MEMBERS] on ActiveRoleService
[org.geoserver.security.GeoServerRestRoleService@13db5a7]
2020-03-26 14:08:03,725 DEBUG [geofence.internal] - Checking UserGroupService
[default]
2020-03-26 14:08:03,725 DEBUG [geofence.internal] - Matching Roles [
[ROLE_REGISTERED-MEMBERS] ] for User [afabiani]
2020-03-26 14:08:03,742 DEBUG [util.FilterUtils] - ADDED Rule [id:9458 pri:341
user:afabiani ws:geonode l:planet_satellite_imagies_2018 acc:LIMIT]
2020-03-26 14:08:03,742 DEBUG [util.FilterUtils] - ADDED Rule [id:9459 pri:342
user:afabiani srv:WMS ws:geonode l:planet_satellite_imagies_2018 acc:ALLOW]
2020-03-26 14:08:03,749 DEBUG [util.FilterUtils] - ADDED Rule [id:9458 pri:341
user:afabiani ws:geonode l:planet_satellite_imagies_2018 acc:LIMIT]
2020-03-26 14:08:03,749 DEBUG [util.FilterUtils] - ADDED Rule [id:9459 pri:342
user:afabiani srv:WMS ws:geonode l:planet_satellite_imagies_2018 acc:ALLOW]
2020-03-26 14:08:03,750 DEBUG [services.RuleReaderServiceImpl] - Filter
RuleFilter [user:"afabiani"+ role:ANY inst:name+:default-gs
ip:"0:0:0:0:0:0:0:1"+ serv:"WMS"+ req:"GETLEGENDGRAPHIC"+ ws:"geonode"+
layer:"planet_satellite_imagies_2018"+] is matching the following Rules:
2020-03-26 14:08:03,751 DEBUG [services.RuleReaderServiceImpl] -
Role:ROLE_REGISTERED-MEMBERS
2020-03-26 14:08:03,751 DEBUG [services.RuleReaderServiceImpl] -
Role:ROLE_REGISTERED-MEMBERS ---> Rule [id:9458 pri:341 user:afabiani
ws:geonode l:planet_satellite_imagies_2018 acc:LIMIT]
2020-03-26 14:08:03,752 DEBUG [services.RuleReaderS
