Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 15:19
    heidivanparys opened #465
  • 15:12
    heidivanparys opened #464
  • 12:19
    pvretano synchronize #463
  • Dec 02 18:50
    prushforth commented #341
  • Dec 02 18:32
    jerstlouis commented #341
  • Dec 02 13:59
    pvretano commented #458
  • Dec 02 13:41
    pvretano opened #463
  • Dec 02 12:55
    pvretano synchronize #461
  • Dec 02 12:53
    pvretano synchronize #462
  • Dec 02 12:41
    pvretano synchronize #461
  • Dec 02 11:27
    cportele commented #424
  • Dec 02 11:27
    cportele commented #424
  • Dec 02 03:35
    pvretano synchronize #462
  • Dec 02 02:58
    pvretano synchronize #461
  • Dec 01 17:01
    m-mohr commented #400
  • Dec 01 17:00
    pvretano commented #400
  • Dec 01 16:56
    m-mohr commented #400
  • Dec 01 16:56
    m-mohr commented #400
  • Dec 01 16:56
    cportele commented #400
  • Dec 01 16:49
    pvretano commented #400
Joe
@turingtestfail
@cportele Thanks for the response. I will definitely try and monitor this gitter to stay on top of when part 3 comes out. Count me as a single vote in favor of the object flavor, if for no other reason, it seems to be a bit more human readable.
Tim Schaub
@tschaub
@cportele - Regarding public comments on JSON filter encoding, I'm not familiar with the SWG or OGC process. How does that public review process take place (will there be an announced start/end, where are comments received, etc.)?
Clemens Portele
@cportele
@tschaub - Yes, there will be a press release, tweets, etc. to make everyone aware. We will inform about the start/end here, too. OGC API Features has done the public comment periods at little different than all other OGC standards. Usually the comment period is one month, but for OGC API Features we have always used a longer period and I think we will do that for CQL, too. Usually comments have to be sent to an OGC email address, we have asked to create issues in the GitHub repo, because that's where we want to have all discussions. So the main point of the public review for OGC API Features is to highlight that we think we are getting close to a release candidate and the review period is like a last call for comments and concerns.
It will take some more until the public review will start. Once the SWG thinks we are ready there are other groups in OGC that have to approve the public review.
Tom Kralidis
@tomkralidis
what is the current status of supporting a properties= type query parameter on /collections/{collectionId}/items ? The idea is for the server to be able to provide responses with only properties specified by the client (ala WFS)
Clemens Portele
@cportele
@tomkralidis It is on the list of extensions after filtering and simple transactions - and I would expect with a high priority as it is straightforward to specify (and implement in most cases) and it has been requested multiple times. But to work on this we will need to add this to the group charter first which takes some time and energy to go through the OGC process.
In ldproxy we support properties with the approach that you have described and also skipGeometry=true to drop the geometry. sample request
Tom Kralidis
@tomkralidis
thanks @cportele . I will implement as properties= then in pygeoapi, guessing that the extension would follow this design pattern. Should I open a ticket?
Clemens Portele
@cportele
There should already be an (old) issue for this. Let me check...
I did not find an exact match, but the subject is discussed in #16, even though the title is only about the geometry property.
Just van den Broecke
@justb4

Q: in short: how to best enforce (Geo)JSON-only responses from OAFeat endpoint services compliant with standard? ?f=json (I hope for) or HTTP Accept: ... (Content Negotiation)?

Expanded: Working on GeoHealthCheck OAFeat Probe (using OWSLib oafeat client). Interesting results from multiple OAFeat implementations on demo.geohealthcheck.org: naively thought Content Negotiation using Accept: application/json would do, but as in metadata some service requests require other content-types like items application/geo+json. pygeoapi happily accepts application/json, but other implementations return 406, as e.g. for items or OpenAPI Doc.

Clemens Portele
@cportele
@justb4 - You have to use the Accept header, this is the only requirement in the standard, consistent with the HTTP standard. http://docs.opengeospatial.org/is/17-069r3/17-069r3.html#encodings
Just van den Broecke
@justb4
@cportele clear, thanks for the quick reply!
Chris Holmes
@cholmes
What's the status of CQL? Has it gone to official 'request for comments'? When will it be fully released?
We're looking to align STAC, to make it the default filter language, but ideally point at a stable (or at least 'tagged') version.
Clemens Portele
@cportele
@cholmes - It is the number one priority of the SWG to move this to the public review stage. We are working on resolving the open issues where we can and ask for feedback on the remaining issues where we need more feedback (like on the JSON encoding options). We should have a stable draft (= considered stable by the SWG and with 2 or 3 implementations for testing) within a month or so. Then it will be up to the normal process including the OAB review when the public review will start.
Chris Holmes
@cholmes
Ok, great. Thanks @cportele I'm hoping to get the STAC API 1.0.0-beta.1 on a similar time frame, but I'm cool to point at the draft and make any tweaks needed for 1.0.0-beta.2. I'm mostly just providing an overview and links in, and then we will need to figure out how we incorporate it in our OpenAPI.
One thing that I didn't yet see, which would be very helpful, is more examples. It's hard to read the BNF and figure out what exactly to write. I'm aiming to put examples in the STAC one (review will be appreciated), but it'd be great if there were a number of examples of the core - both text and json.
Chris Holmes
@cholmes
Is there a version of OGC API - Features that is POST instead of GET? Like is the CQL-JSON meant to be POST-ed? Or are we just imagining that people include the JSON in their GET requests?
For STAC we want a POST endpoint, to handle large geometries...
Clemens Portele
@cportele
@cholmes - Fully agree on the examples, and we have enough live examples that we can use. I have added an issue for this #448.
Clemens Portele
@cportele
Currently there is no POST endpoint, but we need to discuss/clarify this. I have added #449.
Chris Holmes
@cholmes
Thanks @cportele. I just commented on the latter issue - POST is taken by Transaction, which makes sense, and with STAC we liked using /items with post to insert. We have the /search endpoint, which is where we use POST of JSON for querying - https://stacspec.org/STAC-ext-api.html#operation/postSearchSTAC
Chris Holmes
@cholmes
Are there any example openapi documents for Transactions extension? I'm working to align STAC transaction extension with OGC
Chris Holmes
@cholmes
Digging in with just the spec, things look mostly the same. One question though, we use a 204 for a successful delete request, and it looks like OGC API uses a 200. Was that deliberate? Seems like 204 might be better? https://medium.com/@sameira/rest-response-code-for-delete-operation-200-or-204-ee9c72a2dcb2
Clemens Portele
@cportele
The spec should allow 200, 202 or 204, depending on how the server handles the request and if it will include some content in the response (that is for me the distinction between 200 and 204). Clients should accept all of these.
@pvretano, I think you have a server available with an OpenAPI document that supports transactions?
Chris Holmes
@cholmes
@cportele ok, cool. I'll just leave ours as 204 then. In the spec it seems to only give the 200 option, in the diagram, and then in the response it says it shall be a 200:
Screen Shot 2020-11-02 at 11.23.50 AM.png
Chris Holmes
@cholmes
Also have you all considered etags for optimistic locking? It came about a bit later for us, as people were actually implementing. Perhaps an optional conformance class?
Janne Heikkilä
@jampukka
In Core section 7.1. (http://docs.opengeospatial.org/is/17-069r3/17-069r3.html#core-overview) one bullet says that for eachCollection "A list of coordinate reference systems (CRS) in which geometries may be returned by the server: the first CRS is the default coordinate reference system (in the Core, the default is always WGS 84 with axis order longitude/latitude);"
It seems like this would require CRS84(h) to always be the first value in the crs array but I'm not sure if that's the actual intent. Also I don't think the default CRS should even be changeable by any extension.
Janne Heikkilä
@jampukka
One other question regarding CRS extension and GeoJSON outputformat. Now that OGC-CRS and the ability to explicitly state the axis-order was removed and we moved to using Content-Crs as in conneg-by-crshave we reached a consensus on using a fixed axis-order (e.g. longitude-latitude) or is CRS defined order expected?
Or was it left out on purpose? CRS extension basically moves the responsibility from the server to the client
Angelos Tzotsos
@kalxas
hi all, the virtual OSGeo Code Sprint is happening next week, feel free to join us https://wiki.osgeo.org/wiki/OSGeo_Virtual_Community_Sprint_2020
Chris Holmes
@cholmes
Are there any sample OpenAPI documents for CQL extension?
Clemens Portele
@cportele
@cholmes - It is on my todo list: opengeospatial/ogcapi-features#400
Chris Holmes
@cholmes
Great. I'll probably just leave it off for our beta.1 release.
What's the plan for upgrading to OpenAPI 3.1? I saw you mentioned it there.
Clemens Portele
@cportele
We will add support for OpenAPI 3.1 when it has been released. rc1 is out since a few weeks and there was a deadline for implementer feedback a few days ago. It should be close to final. I think a key question for OAI is whether to use JSON Schema 2019-09 or wait for the next version (2020-11-rc-0 was released yesterday).
Matthias Mohr
@m-mohr
Hm, honestly several tooling is still on draft 7 and has not even implemented 2019-09. So for better tooling support at the moment, it seems best to go with draft-7 actually. 2020-11 seems to recent.
Clemens Portele
@cportele
I was talking about whether OpenAPI 3.1 will go for 2019-09 or the next version. This is not our decision :wink:. But to avoid supporing two different JSON Schema versions in various parts of the APIs, we really should support the version that OpenAPI 3.1 will select and that will be implemented in the OpenAPI tooling.
Matthias Mohr
@m-mohr
Oh, I see. Thanks for the clarification...
Chris Holmes
@cholmes
Hey @cportele and @pvretano - what is the timing looking like for CQL and Transaction releases? I'm trying to align STAC to them, but it looks like there's changes coming for CQL.
Chris Holmes
@cholmes
Would there be any chance of 'interim' releases, like use the 'tags' on github and call it a 'beta' or something? That would definitely make life a bit easier for us. Then we could release STAC API 1.0.0-beta.1 and have it depend on tagged versions, and be able to give better feedback.
Clemens Portele
@cportele
@cholmes - Yes, we have also done this before. For CQL, this 1.0.0-draft.1 release would be when we decide that it is ready for the "public review" and submit this to the OAB for their review. This should be before Christmas. All the current changes are from the process of resolving comments to prepare for the next phase.
For CRUD transactions I think we want to clean up the main issues that we have before we create a 1.0.0-draft.1, sometime in Q1 2021.
Panagiotis (Peter) A. Vretanos
@pvretano
@cholmes what @cportele said ... I was typing a similar response as @cportele 's response popped in! ;)
Matthias Mohr
@m-mohr
How has OAFeat planned to use the OACommon conformance classes?
At the moment I think OAFeat only lists their own conformance classes, but in the future there's for example http://www.opengis.net/spec/ogcapi_common-2/1.0/req/collections for Collections. Is that going to be added to the spec as a required conformance class or is that conformance class implicitly included in the OAFeat conformance class? I'm wondering how this will work because we are trying to also use conformance classes in STAC and I am not sure how such dependencies are expected to work... @cportele
Chris Holmes
@cholmes
@cportele + @pvretano - great draft.1 of CQL before christmas would help us a lot. We'll aim to do a beta.2 release after it's out.
Clemens Portele
@cportele
@m-mohr - The idea is to change this in a future version 1.x to reference the Common conformance classes (assuming that Common will be specified in a way that does not break anything in Features). My idea would be that we will still explain everything in an informative way in Features so that implementers do not have to read Common to implement a server or client for Features. Normative statements (requirements and recommendations) that go beyond Common would still be kept in Features.