Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Andrea Aime
    @aaime
    @justb4 please remove the geosolutions wfs3 endpiont, that's a testbed 14 implemnetation and won't be updated
    eventually I hope we'll have a features 1.0 compliant implementation, but it will be at a different endpoint
    Just van den Broecke
    @justb4
    @aaime done!
    Andrea Aime
    @aaime
    thanks!
    Clemens Portele
    @cportele
    Just to explain, we switched from service to service-desc/service-doc, which were just registered with IANA earlier this year, once we were aware of them and noticed they are a closer match to the semantics of our links.
    Andrea Aime
    @aaime
    No worries @cportele I understand there have been a lot of small changes between DRAFT1 and final, it's just that our "business model" allows us to work on stuff only when there is dedicated funding, we're not selling licences that could be used to fund product evolution, the direct contract for a specific purpose are the ones pushing things forwards
    Clemens Portele
    @cportele
    Fully understood @aaime - ldproxy is open source, too, so in general it is not so different from our situation
    Just van den Broecke
    @justb4
    Sorry if I caused some sentiments at the end of a working week. Think we're all aiming to have a standard and its implementations+verifications developed side-by-side in The Open. Something unique (in OGC) I am proud to be part of!
    Matthias Mohr
    @m-mohr
    /collections/{collectionId}/items has a limit parameter for pagination, but /collections has not. What's the reason for that? Simply because it is (falsely?) expected that there are not so many collections?
    Clemens Portele
    @cportele
    @m-mohr - For the core we decided to not specify such a mechanism as most APIs won't have that many collections. But we have normative statements in there to support pagination in an implementation or in a standard extension. See http://docs.opengeospatial.org/is/17-069r3/17-069r3.html#per_core_fc-md-items and opengeospatial/ogcapi-features#76
    Tim Schaub
    @tschaub
    @cportele (regarding https://gitter.im/opengeospatial/WFS_FES?at=5da59c5489acff6ff5fc4499 way back), I was thinking that OGC would be the central place where extensions were encouraged to play well together (or perhaps not blessed unless they didn't conflict with the future or other extensions)
    and that the specs themselves would try to reserve space for future growth, or avoid future conflicts as much as possible
    I know it is already in, but suggesting that implementations use any query params they want doesn't reserve much space for future growth
    but yeah, I agree with your point - nothing guaranteeing that extensions don't clobber one another
    ghobona
    @ghobona
    @tschaub The Standards Working Group (SWG) would be expected to detect the conflicting query parameter names and to suggest alternatives. The OGC Architecture Board (OAB) and the OGC Naming Authority (OGC-NA) would also likely spot such conflicts. Have a look at the Standards Roadmap to see the review stages https://www.opengeospatial.org/roadmap
    Even Rouault
    @rouault
    the main conflict is with the simple query capability. If you have a property/field/attribute called "filter", you cannot query it with the core
    Tim Schaub
    @tschaub
    Thanks @ghobona - sounds good. The future compatibility thing I was pointing out was within the Features spec itself
    yes, what @rouault said
    Even Rouault
    @rouault
    (actually you can, since filter is an extension / not in the core. But let's say "limit" )
    Tim Schaub
    @tschaub
    /collections/foo/items?my-property=foo means the spec has given away this space, my-property shouldn't have collisions in the future, but it wouldn't be surprising if someone had a property name that did collide with a future param that the spec or an extension wanted to use
    Alessandro Pasotti
    @elpaso
    same with properties btw (in the other extension)
    Even Rouault
    @rouault
    it seems to me that either a server implements just the core and then it works, and if it implements the query extension, then it can (should) drop the simple query capability
    probably that if the fflter extension is adopted, some guidance should be added in the core to mention that issue
    ghobona
    @ghobona
    The Filter extension might need to include a requirement such as: If a server receives both a Simple Query and a Filter Query, then it shall return an Exception...or something along those lines.
    Alessandro Pasotti
    @elpaso
    You've probably considered it yet, but to avoid query argument clashes with field names, wouldn't be sufficient to namespace them? Something like oapif.limit, oapif.offset, oapif.properties etc.? Of course it wouldn't be 100% robust but probably enough.
    Even Rouault
    @rouault
    @elpaso Too late for the existing ones, but might be something to consider for the new extensions
    Alessandro Pasotti
    @elpaso
    In core we do have just limit correct?
    Even Rouault
    @rouault
    limit, datetime, bbox
    Alessandro Pasotti
    @elpaso
    oh, yes and bbox-crs
    ghobona
    @ghobona
    @elpaso In principle, the namespace approach would work. We'll raise it at the next Architecture DWG meeting (Nov 18th, 2019 in Toulouse).
    Rob Atkinson
    @rob-metalinkage
    If you use JSON-LD (backwards compatible) then its possible to publish contexts that map to resolvable URIs so having short namespaces (CURIES) works - there might be a few wrinkles about some data structures in JSON-LD - but the ELFIE IE has explored some of these issues - making SELFIE use OGCAPI with JSON-LD would be a starting point to test this out.
    Chuck Heazel
    @cmheazel
    @rouault Which extensions have gone though the OGC approval process? As long as the extension is still in development, we can make adjustments (even if they are inconvenient).
    Even Rouault
    @rouault
    @cmheazel I don't know... None I think, but I can be wrong
    Chuck Heazel
    @cmheazel
    There are two patterns we can use; qualified names (scope:name) and class paths (a.b.c.d). We should choose one. If we choose qualified names, then we need to replace the ":" since it is a URI reserved character. I recommend not using dot (.) since that implies class path.
    Chuck Heazel
    @cmheazel
    One advantage to the qualified name approach is that the "scope" can map to a URI (see JSON-LD). That URI + the name = a resolvable path which can return the definition of that parameter (can you say ontology?).
    Tim Schaub
    @tschaub
    Cross post from https://gitter.im/opengeospatial/features-stac-sprint, but opengeospatial/ogcapi-features#283 is up for review. I hope there is enough context for people who weren't at the sprint. I'm happy to make adjustments or field questions about it. I think I heard that there was going to be a call on Monday (Nov 11). Not sure if that would be an opportunity to discuss, but I'm going to be unavailable as it is a work holiday for me.
    Andrea Aime
    @aaime
    @justb4 you might want to give http://ows.geo-solutions.it/geoserver/ogc/features a try, should be (hopefully?) up to date with 1.0 final
    wish there was a CITE test to confirm :-/
    Just van den Broecke
    @justb4
    @aaime thanks, tried (btw you can also try yourself by registering on https://demo.geohealthcheck.org). Bit puzzling but the OpenAPI JSON doc fails. The GHC WFS3Drilldown Probe tries to find a link to the OAPI doc in your JSON landing page that has the attr rel: service-desc. Appears there are three links (with service-desc). GHC assumes only one, not sure what the 1.0 final says. But even the "service-desc"-link with type: application/json returns an error: http://ows.geo-solutions.it/geoserver/ogc/features/api?f=application%2Fjson (also with f=json). From the Swagger page I see that the OAPI JSON doc should be http://ows.geo-solutions.it/geoserver/ogc/features/api?f=application%2Fopenapi%2Bjson%3Bversion%3D3.0 . So all in all 2 questions for std: 1) are multiple service-desc links allowed? 2) what should be the typefor the service-desc JSON doc? pygeoapi landing page has application/vnd.oai.openapi+json;version=3.0...(sorry for so much text but wanted to be complete).
    Just van den Broecke
    @justb4
    Update: from http://docs.opengeospatial.org/is/17-069r3/17-069r3.html#req_oas30_oas-definition-1 and Abstract Test 40 I deduct that at least one service-desc link with type application/vnd.oai.openapi+json;version=3.0 should be available. Then the GHC Probe should also look for that combination in the landing page...
    Andrea Aime
    @aaime
    About the multiple ones, yes, I would be surprised otherwise, there can be one per supported format. If the OpenAPI mime changed, that I don't know, might be the case
    @justb4 I updated the Features API during a flight, not sure when an occasion to do that will happen again, but will let you know
    Rob Atkinson
    @rob-metalinkage
    @cmheazel definition returned by the URI can be in any form - and the OGC defs server supports multiple forms - you can ask for mime-type or profile which gives us great felxibility - what we (OGC) need is feedback about what forms would be most useful - we will then go into bat in the international community to seek to standardise these behaviours. (any volunteer in the solution provider space to publish definitions and test interoperability of this aspect?)
    Even Rouault
    @rouault
    @aaime Regarding "If the OpenAPI mime changed", yes there was a releated change between a previous draft of OAPIF and final 1.0 (not sure if the official MIME type changed, or OAPIF adopted the official one)
    Just van den Broecke
    @justb4
    For Python OWSLib OAPIF client (which GeoHealthCheck uses) think this describes the issue (how to fetch OpenAPI doc from landing page) and suggested solution: geopython/OWSLib#630. Will be similar for other OAPIF clients.
    Janne Heikkilä
    @jampukka
    Did we end up anywhere with POSTing queries? I think we at least acknowledged that probably we'll have to do it in order to support large filters that won't fit in the query part of a GET request. Has there been any discussions on this matter after the code sprint in DC or any implementation? I'm fairly certain that STAC came up with their own query extension but I haven't checked it out
    Matthias Mohr
    @m-mohr
    Yes, STAC does GET + POST queries at /search.
    dstenger
    @dstenger
    Currently, we are discussing how to represent FeatureCollections in the OpenAPI document.
    If placeholders are used (e.g. paths./collections/{collectionId}), we do not see a possiblity to connect parameters to a single FeatureCollection (e.g. query on simple property). Instead, the parameters can just be defined for complete API (path: components.parameters).
    From our understanding, this can just be solved by listing every single FeatureCollection in path element (e.g. paths./collections/collectionA, paths./collections/collectionB).
    Do you have an idea if there is a way to use placeholders and connect parameters to single FeatureCollections? Do you think this connection is important/mandatory?
    Panagiotis (Peter) A. Vretanos
    @pvretano
    @dstenger There is an extension in the pipe line called CQL (Common Query Langauge) that would allow you to use a parameterized OpenAPI document and still be able to say "property=value" without having to explicitly list every collection and define every query property. So, you would be able to say .../collections/{collectionId}/items?...filter-lang=CQL&filter=property%3Dvalue... Keep in mind that CQL is more flexible than what is defined in the core; you can use operators other than "=" and it also has logical, spatial and temporal operators too. Think of it like a SQL where clause with spatial and temporal capabilities. The extension is being worked on here: https://github.com/opengeospatial/ogcapi-features/tree/master/extensions/cql