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
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!
Jerome St-Louis
@jerstlouis
@jratike80 yes I need to get some sleep ;)
will try to get some implementation going in the morning
jratike80
@jratike80
You are damn right, it is 02.02 local time. Bye!
Jerome St-Louis
@jerstlouis
@jratike80 I was referring to e.g. the time dimension in particular, where some geographic areas might have pictures on a certain dates, but not all dates
good night!
(it does map to the extended extent now... so I wonder what it did before)
Keith Pomakis
@pomakis

@jerstlouis wrote:

@pomakis i'm curious , does the 640x480 map to the extended, or cropped extent? And did this behavior change with the new implementation?

You get the requested bbox at the requested size, so pretty much exactly like a WMS request (except for the point-versus-area interpretation of the bounding box - still an item to be resolved).

Back when the requested bbox was trimmed to the extent of the coverage, you got back the requested size, but not necessarily the requested bbox.

Jerome St-Louis
@jerstlouis
@pomakis so that would mean you would receive a different 'scaling factor' tahn you asked for!
(before)
I like that this is potentially addressed, but I think we should consider for a very coverage-native format like netCDF whether introducing NODATA values make any sense... I think this resolved a scaling behavior confusion when specifying a desired target size with scalesize...
(potentially this could be addressed by something like "if the requested representation is a format which may be used by applications not aware of geo-referencing, such as TIFF (incl. GeoTIFF) or PNG , or when doing subsetting on the range set (consisting of raw data values without any referencing), the data shall be extended to match the requested bbox...") Regardless of the representation, the scaling behavior for specifying a target size shall always be based on the requested bbox (whether scalesize or width&height).
Keith Pomakis
@pomakis

@jerstlouis wrote:

@pomakis so that would mean you would receive a different 'scaling factor' tahn you asked for!

Not really. You'd receive an image of the requested size, covering the portion of the coverage that intersects the specified bounding box. (Not as nice as what we have now, I admit, but still reasonably well defined.) There's a separate scalingFactor parameter (e.g., scalingFactor=0.1), but as an alternative to specifying an exact width and height.

Jerome St-Louis
@jerstlouis
@pomakis but presumably you specified that subset and scalesize based on an expected target resolution (especially if you are coming from the more popular WMS standard) and were surprised and confused by the results :)
the odds are if you specify a target size for an area, that's the number of cells you wanted for that whole area.
I would argue it was not well defined, as the server was not required to trim to the cropped extent
Keith Pomakis
@pomakis
@jerstlouis Since we're making these requirements up as we go along, the server was as required to trim to the coverage's extent as it is now required not to. :-)
Jerome St-Louis
@jerstlouis
This was a reference to WCS 2.0 "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."
and since that was not strictly specified, the behavior of scalingSize was potentially equally undefined.
ghobona
@ghobona

Yesterday I was able to isolate the problems that were preventing the openapi definition files (yaml) from compiling. The main recurring issue was that the CIS JSON schema allows for flexibly typed arrays.

"coordinate": {
                                                    "type": "array",
                                                    "items": { "type": ["number", "string", "boolean"] }
                                                }`

This wasn't a problem with the CIS JSON schema, but that the OpenAPITools Generator appears to have difficulty handling such arrays.

ghobona
@ghobona
So the solution was to profile the arrays by selecting only one type.
ghobona
@ghobona
The other thing I had to do was to separate out the schemas of domainSet, rangeType and metadata into standalone yaml files. The separate files were then imported into the main coverages.yaml file. I am now able to compile the coverages.yaml file to automatically generate code stubs.
3 replies
Tom Kralidis
@tomkralidis
1 reply
Tom Kralidis
@tomkralidis
hi all: in addition, I’ve added initial support for OACov client in Python OWSLib: https://github.com/geopython/OWSLib/tree/oacov. Added to implementations via PR
Stephan Meißl
@Schpidi
Jerome St-Louis
@jerstlouis
BBOX vs. SUBSET discussions at opengeospatial/OGC-API-Sprint-August-2020#7 :)
ghobona
@ghobona
Thanks for the preliminary demos this morning, everyone. We'll reconvene in the Gotomeeting room at 15:30 EDT.