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
BBOX, WIDTH, HEIGHT requires support for resampling. Users should be learned that if the aim is to transfer data as unaltered that's not the way to go. Or user needs to be ultimately careful when calculating the parameters.
Jerome St-Louis
@jerstlouis
@jratike80 yes just like WCS 2.0 SCALESIZE.
agreed the specification should make recommendation on how to transfer the data unaltered
jratike80
@jratike80

if using BBOX with native CRS (e.g. with bbox-crs option), then SUBSET vs. BBOX is just a syntax thing

I have met cases when software is doing things which mean the same through different code paths. I bet I could find some unresolved bug reports as examples. But we are building new programs and we know to be careful. I am an optimistic person and I trust that things will go well.

Jerome St-Louis
@jerstlouis
@jratike80 the spec could go to some extent to note the equivalence between the two with both syntax flavors.
jratike80
@jratike80
Because of BBOX, WIDTH and HEIGHT I never changed from WCS 1.0 into WCS 1.1.
Jerome St-Louis
@jerstlouis
I didn't realize I was begging to bring back WCS 1 functionality back from the dead :)
Tom Kralidis
@tomkralidis
ha
Jerome St-Louis
@jerstlouis
@tomkralidis btw ease of server implementation (including simple static use cases) was why I made that embedded or linked suggestion, but in the end perhaps client-side interoperability concerns trumps that... I will let you and Keith and others chime in on what's best for that :)
Tom Kralidis
@tomkralidis
in OWSLib (Python client) hitting /collections/{collectionId} and then looking for domainset or rangetype would be pretty straightforward. One could also inspect by qualifying itemType == 'Coverage’
if those are not there then one can look for link relations. Or vice-versa.
Jerome St-Louis
@jerstlouis
link relations for that.
itemType is specific to the use of /items
and a collection may be offeres a both coverages & features.
Tom Kralidis
@tomkralidis
in case I missed it, wherever rangetype and domainset are, CIS JSON is required for them?
Jerome St-Louis
@jerstlouis
@tomkralidis yes
if provided as a link, alternate representation (e.g. CovJSON) may also be defined, but the CIS JSON is required.
Tom Kralidis
@tomkralidis
thx
Keith Pomakis
@pomakis

@tomkralidis wrote (re: embedded or links) :

@pomakis any vehement objection to allowing both?

As a server developer, no, since I don't have to worry about the extra complexity of having to handle either.

Tom Kralidis
@tomkralidis
Jerome St-Louis
@jerstlouis
@tomkralidis does your server have a pretty JSON mode?
Tom Kralidis
@tomkralidis
@jerstlouis sec
ghobona
@ghobona
A reminder that we will reconvene at 15:30 EDT to discuss any issues or concerns, if there are any. If there are none, we will continue with the practical work.
Tom Kralidis
@tomkralidis
jratike80
@jratike80
Stupid question, but how am I supposed to know from here https://test.cubewerx.com/cubewerx/cubeserv/demo/ogcapi/Daraa/collections?f=json which collections are coverages?
Keith Pomakis
@pomakis
@jratike80 , the ones that have a link with a relation type of "http://www.opengis.net/def/rel/ogc/1.0/coverage" are coverages.
Stephan Meißl
@Schpidi
I guess from the presence of a link with rel: "http://www.opengis.net/def/rel/ogc/1.0/coverage"
ghobona
@ghobona
jratike80
@jratike80
And that (or some later accepted relation type) will be common for all servers?
Stephan Meißl
@Schpidi
that types are part of the standard, yes
jratike80
@jratike80
Ok, so that's how client like GDAL can filter the OACov layers.
Tom Kralidis
@tomkralidis
@jerstlouis ok JSON pretty print is enabled.
Jerome St-Louis
@jerstlouis
thanks @tomkralidis !
Tom Kralidis
@tomkralidis
Jerome St-Louis
@jerstlouis
@tomkralidis I forget, what did we decide on embedded vs. linked?
Tom Kralidis
@tomkralidis
didn’t we want to ask clarification? opengeospatial/OGC-API-Sprint-August-2020#9
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."