Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 15:42
    cportele labeled #458
  • 15:42
    cportele assigned #458
  • 15:42
    cportele opened #458
  • 15:30
    cportele commented #332
  • 15:28
    cportele commented #453
  • 15:19

    cportele on master

    Change order of ENVELOPE coordi… Merge pull request #443 from pv… (compare)

  • 15:19
    cportele closed #443
  • 15:19
    cportele closed #334
  • 15:16
    cportele commented #455
  • 14:41

    pvretano on master

    Merge pull request #1 from open… Merge pull request #457 from pv… (compare)

  • 14:41
    pvretano closed #457
  • 14:39
    pvretano opened #457
  • 08:02

    cportele on master

    fix BNF include (compare)

  • Nov 22 15:17
    cportele synchronize #455
  • Nov 22 15:17

    cportele on issue-424

    push change that wasn't saved y… (compare)

  • Nov 22 15:12
    cportele assigned #456
  • Nov 22 15:11
    cportele opened #456
  • Nov 22 15:11

    cportele on cp-edits

    initial updates (compare)

  • Nov 22 15:09
    cportele opened #455
  • Nov 22 15:08

    cportele on cp-edits

    (compare)

Clemens Portele
@cportele
STAC (or anyone else) is of course free to require spatial geometries.
Chris Holmes
@cholmes
cool, thanks. I had thought we were requiring spatial geometries, but the spec is a bit ambiguous, so now trying to figure out if we should. We are getting use cases where it's desired, but questions is 'is that stac?' or is it an OGC Feature / generic Item that follows the same structure.
Francesco Bartoli
@francbartoli
Hi folks, which is the official openapi schema fragment for queryables? I only found this https://github.com/opengeospatial/ogcapi-features/blob/master/extensions/cql/standard/requirements/filter/REQ_get-queryables-response.adoc
Clemens Portele
@cportele
@francbartoli - Strictly there is nothing official yet. What you referenced is the current proposal for part 3, but there is also http://docs.opengeospatial.org/DRAFTS/20-009.html#rc_queryables from Styles. We will have to discuss and consolidate this in the coming weeks.
Francesco Bartoli
@francbartoli
thanks @cportele, this one from Styles seems to be more generic and flexible even though it’s obviously more articulated
Jorge Samuel Mendes de Jesus
@jorgejesus
I have made an issue concerning data transaction: opengeospatial/ogcapi-features#422 but dont seem to be able to set tags or any extra info. Lack of permissions ?
Clemens Portele
@cportele
@jorgejesus - Yes. I will later take care of the tags etc.
Jorge Samuel Mendes de Jesus
@jorgejesus
@cportele thank you for the tags and fast reply on the topic now, it make sense
Hisham Massih
@hmassih
Hi all, I ran into some feature collections where the identifier named “id” exists both under a Feature and its Properties. To avoid a “Field_exists_exception” when creating a table, one can rename the second “id” something like “properties_id”. However, before resorting to this solution, I wanted to understand the purpose behind a second “id” under “properties”, and what's best practice (should these services have named it differently). Here are a couple of examples:
Panagiotis (Peter) A. Vretanos
@pvretano
@hmassih aerofacp_1m is from the VMAP Level 0 product and all feature collections in that product have a property named "id". My server simply maps that property from the source data to a same-named property in the "properties" section. If you access data from another non-VMAP collection, the "id" property does not exist in the source data and would thus not appear in the properties section either (e.g. https://eratosthenes.pvretano.com/cubewerx/cubeserv/default/ogcapi/framework/collections/RESERVE/items?f=json&limit=1)
Brad Hards
@bradh
So the presence or absence of id in properties is reasonable and spec compliant. Its a distinct namespace to anything at the Feature level.
Panagiotis (Peter) A. Vretanos
@pvretano
@bradh I think so. I believe the one at the Feature level is specified by the GeoJSON RFC. I don't think there is any restriction (other than JSON validation) for the key names in the properties section.
Hisham Massih
@hmassih
Thank you @pvretano and @bradh for your replies, I'm more confident now that I'm on the right track.
Joe
@turingtestfail
I am working on a CQL-JSON to GeoTools Filter conversion module ( geotools/geotools#3161 ) and received a question about the state of debate on the hierarchical JSON flavor vs the array based one for CQL. Is this the correct forum to ask this question or who should I talk to?
Clemens Portele
@cportele
@turingtestfail - The current draft specifies the object flavor (and has a few implementations), but also points to the array flavor. The SWG is open to which option will eventually been specified, but needs more input why one of the options is preferable to make a good decision. The current plan is to wait at least for the comments from the public review. Preparing part 3 for the public review is the top priority for the group for now.
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?