Where communities thrive

Join over 1.5M+ people
Join over 100K+ communities
Free without limits
Create your own community

Explore more communities

opengeospatial/OGC-API-Sprint-August-2020

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

the main argument against it was that it would hard to expect clients to handle both ways, especially if they run into one way more often than the other

jratike80

@jratike80

Ok, bbox with bbox-crs might be useful (playing only with data in national CRS). But somehow I feel sad because SUBSET with axis names was finally something that is hard to understand wrong.

BTW, which one overrides if both are used?

Jerome St-Louis

@jerstlouis

@jratike80 I think they should not be allowed to be used both

Tom Kralidis

@tomkralidis

couldn’t both be allowed?

Either /collections with links to say /collections/{collectionId}/domainset or /collections/{collectionId} with an inline representation. The idea being if a user is interested enough in hitting /collections/{collectionId} specifically, an implementation could return domainset and rangeset inline.

This is analogous to alternate approaches to listing our resources in OpenAPI documents (resource as a fixed path vs. {} parameter.

Keith Pomakis

@pomakis

There's a difference between stating the coordinate system of the requested bounding box (bbox-crs) and the coordinate system of the response (crs). For raster maps these two must be the same, and there's no point in having two separate parameters, so they've chosen to stick with "bbox" dor consistency with WMS.

Jerome St-Louis

@jerstlouis

@tomkralidis that was my proposal... @pomakis is saying it makes it hard for the clients :) we can bring it back for discussion if you want :)

Tom Kralidis

@tomkralidis

/collections/{collectionId} could inline the info or link relation it just the same (as well as from/in /collections).

jratike80

@jratike80

I do not know the backgrounds so it is easy for me to say that I do not understand why to have both subsets and bbox. I can't see the benefit but I can imagine troubles.

Jerome St-Louis

@jerstlouis

@jratike80 a simple way to query geospatial data across Features, Maps & Coverages. If bbox is defined in a confusing manner, that's an OGC API-wide problem.

Keith Pomakis

@pomakis

The subset parameter is more general in that it can handle arbitrary (and an arbitrary number of) dimensions. BBOX is being added for its simplicity for the common 2D or 3D case.

Jerome St-Louis

@jerstlouis

@pomakis would you agree with the NODATA and width & height support? :)

(for BBOX)

jratike80

@jratike80

Ok, I like OGC API Features and bbox is used there in the same way. Now it makes sense.

Jerome St-Louis

@jerstlouis

also regarding rastermap and bbox-crs, I still disagree they have to be the same. if I have some regional CRS that I want to return the data in, I might not really know the coordiantes well so want to use the familiar WGS84 BBOX. My returned image is a GeoTIFF still properly georeferenced.

@jratike80 a distinction in Features thouhg is that Features intersects rather than clip. so I suggest a ClipBBOX for Features.

and with this you have an easy way to cut out map, features or coverages tiles with a simple bbox (clipbox for Features), width & height.

(For tiles)

connecting all the main OGC APIs.

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

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.

Chat via Matrix