Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Nov 24 2020 15:18
    ghobona closed #1
  • Nov 24 2020 15:17
    ghobona transferred #15
  • Nov 24 2020 15:16
    ghobona transferred #14
  • Nov 24 2020 15:16
    ghobona transferred #12
  • Nov 24 2020 15:15
    ghobona transferred #11
  • Nov 24 2020 15:14
    ghobona transferred #10
  • Nov 24 2020 15:13
    ghobona transferred #9
  • Nov 24 2020 15:12
    ghobona labeled #9
  • Nov 03 2020 19:53
    jratike80 commented #2
  • Nov 03 2020 19:53
    pomakis commented #2
  • Nov 03 2020 19:51
    jratike80 commented #2
  • Oct 07 2020 13:59
    Schpidi transferred #6
  • Oct 07 2020 13:55
    Schpidi transferred #5
  • Oct 07 2020 13:54
    Schpidi commented #5
  • Oct 07 2020 13:47
    Schpidi transferred #3
  • Oct 07 2020 13:47
    Schpidi commented #3
  • Oct 07 2020 13:39
    Schpidi closed #2
  • Oct 07 2020 13:39
    Schpidi commented #2
  • Oct 07 2020 13:36
    Schpidi transferred #18
  • Aug 27 2020 08:45
    jratike80 commented #18
jratike80
@jratike80
The widened bbox query will probably throw some error if it is totally outside the valid area of the CRS, like outside World between 85.06°S and 85.06°N for EPSG:3857.
At least if the mathematics of the conversion just do not work.
Jerome St-Louis
@jerstlouis
@jratike80 the widened bbox query can throw an error if it's outside the CRS.
the CRS being requested
if you ask for WGS84 for the whole world, and the data is native in WorldMercator, you 'd have NODATA outside the native CRS's extent.
jratike80
@jratike80
However, it can be too strict to use the limits of the CRS as a reason for throwing an error. For example at the boundary of http://epsg.io/2392 and http://epsg.io/2393 it may be necessary to cross the boundary.
Jerome St-Louis
@jerstlouis
true
if the transformation is well defined, there should not be an error
jratike80
@jratike80
It is hard to compress all this into few crystal clear sentences for the standard ;)
If the transformation is impossible the server may give an error...
Jerome St-Louis
@jerstlouis
I haven't updated our server implementation yet, but some of it is now already working according to the specifications e.g.
jratike80
@jratike80
Perhaps the no-data padding is allowed in WCS 2.0 subsetting even not recommended.
From the standard: "Requirement 38 /req/core/getCoverage-response-trimming:
The response to a successful GetCoverage request on coverage identifier id of admissible
type containing no slicing and exactly one trimming operation with dimension name dname,
lower bound parameter evaluating to low, and upper bound parameter evaluating to high
shall be a coverage identical to c, but containing all points of c with location inside B, and
no other points.
NOTE This requirement does not specify the actual extent of the coverage returned. Possible options include: the minimal bounding box of the coverage returned, or the request bounding box. Servers are strongly encouraged to deliver the minimal bounding box."
Jerome St-Louis
@jerstlouis
right, so it owuld be possible to implement it easily as a facade on top of a conformant WCS2, albeit not one following that recommendation
jratike80
@jratike80
If the actual extent of the coverage returned = request bounding box, how it can be possible without having missing samples filled with nodata?
@jratike80 yes it seems to imply padding with no data. anyways coverages always have no data right if their data extent does not match the CRS axis
jratike80
@jratike80
But from the developers point of view such wording is probably a nightmare. Some servers may apply padding, others don't, and the only way to know is to try. Or to play a detective "by this sort of capabilities response the server is probably MapServer, and those tend to behave this way"
Jerome St-Louis
@jerstlouis
particularyl problematic if you're asking for a PNG with no geospatial referencing!
jratike80
@jratike80
Seems to be exactly like that. See for example https://github.com/OSGeo/gdal/blob/master/gdal/frmts/wcs/wcsdataset201.cpp with comments like // if axis_order_swap
    // the offset order should be swapped

    // Rasdaman does it

    // MapServer and GeoServer not
Jerome St-Louis
@jerstlouis
@jratike80 !! :)
though that is order axis :)
Keith Pomakis
@pomakis
I have updated CubeWerx's handling of the bbox parameter at the coverage endpoint such that if it extends beyond the extent of the coverage, the full requested area will be returned (i.e., not trimmed to the coverage's extent). I have not yet adjusted the behaviour likewise for the subset behaviour, nor have I added width or height parameters. These things will come in time, but not likely within the timeframe of the sprint.
ghobona
@ghobona
I think I have isolated the problem with the API definition (yaml file) of OGC API - Coverages. The issue that prevents compilation appears to be the JSON Schema files that are imported from http://schemas.opengis.net/cis/1.1/json/coverage-schema.json
Jerome St-Louis
@jerstlouis
@pomakis cool thank you! do you know offhand what width and height would map to for scalesize ?
Jerome St-Louis
@jerstlouis
So I am wondering if this 'extend' behavior couldn't actually be dependent on the representation...
if the media type is properly geo-referenced those nodata don't really add much value.
it's great for e.g. 16-bit PNG which cannot carry that georeferencing, or for using BBOX with rangeset for example.
(and also for use together with width / height, where width height are relative to the requested bbox... if the server is trimming the bbox to the data extent then the client will receive less cells than the specified width / height)
jratike80
@jratike80
I was remembering that I have faced the problem with no-data fill sometimes. I found the issue but it was a bit different https://osgeo-org.atlassian.net/browse/GEOS-8893. We had some missing mapsheets in between the Finnish false-color aerial photo coverage and Geoserver was trimming the output raster to smaller extent. That might be a good test case for server developers. Just delete one image from the middle of your image mosaic or what ever you call it, make a request that partially hits the hole and see what happens.
Jerome St-Louis
@jerstlouis
@jratike80 it would seem that the issue description is not accurate based on what you pasted earlier?
the reocmmendation being the "current result"
Image-focused clients really might be expecting the BBOX to be filled up, and that may include GeoTIFF as an extension to a fundamentally image-based TIFF format.
however I think for very coverage-oriented foramt, the minimum data might actually be preferable.
jratike80
@jratike80
You mean the description of the old Geoserver issue, or?
Jerome St-Louis
@jerstlouis
in those there really isn't anye expectation of a canvas of a certain size on which data was returned
@jratike80 right
ahh maybe not
jratike80
@jratike80
it was a long time ago but obviously Andrea Aime considered that it was a bug according to WCS 2.0 because he filed the bug and resolved it
Jerome St-Louis
@jerstlouis
"all point of c"
if there is no data, is that a point of c?
If we consider data stored as a point cloud for example, there really is no concept of 'no data'.
jratike80
@jratike80
Oh, but in theory coverages probably don't have holes. This was real world dataset and we did not have a tiff in the hole telling that the area is nodata. There were just missing data.
Keith Pomakis
@pomakis

@jerstlouis wrote:

@pomakis cool thank you! do you know offhand what width and height would map to for scalesize ?

Are you asking how a client would request a specific with and height via
the scalesize parameter? If so, the answer (four our two coverages) is scalesize=Long(640),Lat(480)

E.g.:

https://test.cubewerx.com/cubewerx/cubeserv/demo/ogcapi/Daraa/collections/Daraa_mosaic_2019/coverage?scalesize=Long(640),Lat(480)

This should work fine in conjunction with the new behaviour of the bbox parameter.

Jerome St-Louis
@jerstlouis
but thats the irregular coverage thing right when it can have holes
thank you @pomakis !
@pomakis i'm curious , does the 640x480 map to the extended, or cropped extent? And did this behavior change with the new implementation?
jratike80
@jratike80
We are getting to the topics for the late night discussions really. What's the difference of having no-data and having no data at all!