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
Keith Pomakis
@pomakis
But in general a client can't expect a returned map image to be georeferenced, so it kinda has to know exactly what it's getting back based on the request.
jratike80
@jratike80
And I suggest to deprecate bboxes which require that user knows the correct order of numbers and use more explicit and flexible SUBSETs :)
Jerome St-Louis
@jerstlouis
@pomakis if it's getting back a non-georeferenced map and cares about knowing exactly then it can set bbox-crs and crs to the same thing.
@jratike80 having both options as conformance classes allow people to implement their preferences :) hopefully servers implement both, so clients have their favorite choice available.
Tom Kralidis
@tomkralidis
@jerstlouis / @pomakis I would advocate for the same choice capability then for the ability to inline (or not) for rangeset/domainset IMHO.
Jerome St-Louis
@jerstlouis
@tomkralidis rangeTYPE ?
Tom Kralidis
@tomkralidis
for some implementations, this would reduce the routing machinery.
Jerome St-Louis
@jerstlouis
I'm fine with either only links, or embedded or links...
Tom Kralidis
@tomkralidis
oops rangetype (thanks @jerstlouis)
rangeset would surely be its own endpoint, yes
Keith Pomakis
@pomakis
@jerstlouis Arbitrary-dimension width and height support are already provided through the WCS 2.0 SCALESIZE parameter, but I suppose specific WIDTH and HEIGHT parameters could also be added as companion parameters to the BBOX parameter. I'm hesitant, though, to provide so many alternate ways of making the same request. As for a BBOX request extending beyond the coverage's extent and returning NODATA values, we could easily implement it that way, perhaps based on a boolean request parameter, if it really is a desired option.
Jerome St-Louis
@jerstlouis
@pomakis I really, really, really like a simple BBOX, WIDTH, HEIGHT that works with Coverage, Features and Maps. There's a simple mapping to scalesize / width & height.
and I do feel that for consistency with Maps the NODATA should be default bbox behavior.
jratike80
@jratike80
I have a feeling that different servers will re-project the bbox given in the default CRS:84 coordinates into the native BBOX with slightly different algorithms and therefore return slightly different results sometimes. That's OK if documentation encourages to use native subsetting if result needs to be accurate to last points and pixels.
Tom Kralidis
@tomkralidis

I'm fine with either only links, or embedded or links...

thanks @jerstlouis . @pomakis any vehement objection to allowing both?

Jerome St-Louis
@jerstlouis
@jratike80 no objecton to that recommendation, but I think it's more that the native CRS should be used if results need to be accurate.
if using BBOX with native CRS (e.g. with bbox-crs option), then SUBSET vs. BBOX is just a syntax thing
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 !