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
(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.
Panagiotis (Peter) A. Vretanos
@pvretano
FYI. Will be here but in a teleconference tentatively till noon. I will be monitoring feed but if you don't get a response email me at pvretano@cubewerx.com to get my attention.
Panagiotis (Peter) A. Vretanos
@pvretano
Demo Preview: data tile from a coverage ... http://test.cubewerx.com/cubewerx/cubeserv/demo/ogcapi/Daraa/collections/Daraa_DTED/tiles/smerc/12/1651/2451?f=tiff can also return mvt, geojson and wkb.
Jerome St-Louis
@jerstlouis
@pvretano it can return those vector tile formats for the DTED?
I guess you mean the Tiles API for features resources...
Panagiotis (Peter) A. Vretanos
@pvretano
Oops, cut-n-pasted the wrong output formats! tiff and wkb.
Tom Kralidis
@tomkralidis
@ghobona where are the OpenAPI schema in development again? Embarking on doing OpenAPI document support here
23 replies
Panagiotis (Peter) A. Vretanos
@pvretano
@jerstlouis nope. These are data tiles from a coverage, not features.
Jerome St-Louis
@jerstlouis
@pvretano can WKB encode coverage data?
Jerome St-Louis
@jerstlouis
I guess it's a multipoint feature with elevation...
Jeff Yutzler
@jyutzler
More threading more often, please. It is really difficult to track these conversations if you aren't actively participating in real-time.
1 reply
Panagiotis (Peter) A. Vretanos
@pvretano
@jerstlouis we have extended OGC's WKB to be able to encode coverage data ... in a backward compatible way I think.
1 reply
ghobona
@ghobona
We reconvene in 25 minutes for the final demos, discussion and wrap up.
Stephan Meißl
@Schpidi
@cmheazel I'm trying to figure out what is the right syntax for requirements and conformance classes. in common I see usage of: "http://www.opengis.net/spec/ogcapi-common/1.0/req/core", "http://www.opengis.net/spec/ogcapi-common-1/1.0/req/core", "http://www.opengis.net/spec/OAPI-Common-1/1.0/req/core", "http://www.opengis.net/spec/ogcapi-common/1.0/conf/core", ... and in coverages also as "http://www.opengis.net/spec/ogcapi_common-1/1.0/req/collections". What is the correct syntax (all lower case?, dash instead of underscore?, appended with -1?)? thanks
8 replies
ghobona
@ghobona
I think the spec needs to be clearer about what the difference between the expected responses of /collections/{coverageId}/coverage/metadata and /collections/{coverageId} is.
At the moment they both can return CIS-encoded metadata, although /collections/{coverageId}/coverage/metadata can also return domain specific metadata.
5 replies
ghobona
@ghobona
The Gotomeeting room is open.
Scott Simmons
@ogcscotts
Another superb Sprint - thanks for the dedication, all!
ghobona
@ghobona
Everyone, thanks for participating in the sprint. It's been a very productive event.
Tom Kralidis
@tomkralidis
@ghobona minor updates in PR: opengeospatial/OGC-API-Sprint-August-2020#16
ghobona
@ghobona
@tomkralidis Thanks!
Jerome St-Louis
@jerstlouis
We now have coverages and coverage tiles available as GeoTIFF on our server (e.g. https://maps.ecere.com/ogcapi/collections/Daraa:Daraa_DTED/coverage , https://maps.ecere.com/ogcapi/collections/Daraa:Daraa_DTED/tiles/CDBGlobalGrid/0/57/215 ). Did not yet implement DomainSet / RangeType links, and subset parameters, but planning to add these in the following weeks . Note that the /coverage end-points scales by default right now (it understands BBOX, WIDTH & HEIGHT).
ghobona
@ghobona
@jerstlouis Thanks for the update!
Stephan Meißl
@Schpidi
fyi I'm woring on having a complete and adjusted openapi yaml definition at https://github.com/Schpidi/ogcapi-coverages-1/. I found the swagger editor to work nicely with this split setup https://editor.swagger.io/?url=https://raw.githubusercontent.com/Schpidi/ogcapi-coverages-1/master/yaml-unresolved/ogcapi-coverages-1.yaml it is not yet finished but the paths up to /coverage should be aligned with the draft, rest to follow
Jerome St-Louis
@jerstlouis
CoverageClient.jpg
@pomakis wondering if a request using bbox extending beyond the dataset, alongside a scaleSize setting, is currently expected to be working from your service?
32 replies
Jerome St-Louis
@jerstlouis
@ghobona @pomakis I have added screenshots of our client accessing and rendering the CubeWerx elevation coverage (as well as our GNOSIS Map Server) at https://github.com/opengeospatial/OGC-API-Sprint-August-2020/tree/master/Screenshots
Jerome St-Louis
@jerstlouis
@pomakis @joanma747 One thing I noticed is that if a coverage is PointIsCorner, we might want coverage tiles to have the extra corner cell (e.g. 257x257 intead of 256x256). There is otherwise a gap when displaying in QGIS. We implemented this for e.g. https://maps.ecere.com/ogcapi/collections/SRTM_ViewFinderPanorama/tiles/GNOSISGlobalGrid/0/0/0 and https://maps.ecere.com/ogcapi/collections/SRTM_ViewFinderPanorama/tiles/GNOSISGlobalGrid/0/0/1 (GeoTIFF by default). In our GNOSIS Map Tiles format we also do this, plus include an extra cell around so that normals can be computed for hillshading without depending on adjacent tiles, so it's 259 x 259 (http://docs.opengeospatial.org/per/18-025.html#_binary_layout_for_gridded_coverage_tiles).
44 replies
ghobona
@ghobona
@jerstlouis Thanks for the screenshots!
@Schpidi Thanks for advancing the yaml files. Great work!
ghobona
@ghobona
All, registration for the next OGC Code Sprint has been opened. The OGC invites software developers to the May 2021 OGC API Virtual Code Sprint, to be held from May 26th to May 28th, 2021. The Code Sprint will focus on the following draft OGC API specifications: