Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Panagiotis (Peter) A. Vretanos
    @pvretano
    @kalxas no worries. Hope everything is OK. I'll post the recording once I get it.
    Angelos Tzotsos
    @kalxas
    all good, thanks
    Tom Kralidis
    @tomkralidis
    q: where are meeting recordings posted? Am I looking in the right place at https://portal.ogc.org/index.php?m=projects&a=view&project_id=579&tab=2&artifact_id=94560 ?
    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
    paul van genuchten
    @pvgenuchten
    hi, small question, does oapi common/records facilitate to add extra methods (and/or optional parameters) to the api which are not mandated by the standard?
    paul van genuchten
    @pvgenuchten
    other question, the bbox query param seems a intersect, is there an option to change it to within query, intersect usually gives many results for global/national records, within is usefull if looking for local records
    paul van genuchten
    @pvgenuchten
    Like asc/desc for sorting, alternative is to add a param: bbox-within
    Tom Kralidis
    @tomkralidis
    hi all: keyword set proposal for core record model for review/comment:
    opengeospatial/ogcapi-records#70
    Brad Hards
    @bradh
    Should references to catalogue be collection?
    Tom Kralidis
    @tomkralidis
    @bradh what do you mean?
    Brad Hards
    @bradh
    I was wondering if those are just left over from the CAT 4.0 to OGC API for Records change. If so, I was planning to fix them, although I subsequently got the "stop annoying us" message from the editor, so its OBE.
    Tom Kralidis
    @tomkralidis
    thanks @bradh , perhaps it should just be “record”. Not sure what OBE is, but feel free to open an issue. The SWG meets this Monday at 15h UTC, so we can also discuss there
    Brad Hards
    @bradh
    Overtaken By Events. So the question no longer really matters because the response would not be actionable in any case.
    paul van genuchten
    @pvgenuchten
    related to opengeospatial/ogcapi-records#90, is this a sensible issue? Does it make sense to create a pr to improve these aspects, or this type of details is beyond the scope of the example yaml files?
    Panagiotis (Peter) A. Vretanos
    @pvretano
    @pvgenuchten no, it is not beyond the scope. A PR would be great! Just keep in mind that I just checking in new yaml files so some of the links in issue 90 are no longer valid (e.g. openapi.yaml is now gone). Many of the existing yaml/json files were imported from coverages/features/etc. so they need to be removed or migrated to records.
    paul van genuchten
    @pvgenuchten
    ok, let me check which aspects are still valid, thanx!
    Tom Kralidis
    @tomkralidis
    @pvretano do you have an endpoint handy?
    Panagiotis (Peter) A. Vretanos
    @pvretano
    @tomkralidis handy endpoint for which api?
    @tomkralidis we have a bunch of endpoints at https://test.cubewerx.com/cubewerx/cubeserv/demo. Look at the landing page section to jump into the OpenAPIs.
    Tom Kralidis
    @tomkralidis
    sorry OARec. Thanks will look
    Tom Kralidis
    @tomkralidis
    @pvretano for https://test.cubewerx.com/cubewerx/cubeserv/demo/ogcapi/catalogues/collections/sentinel1cat/items?f=json, should ”type”: “FeatureCollection” be at the root?
    I’m also seeing properties.@type within each record? I think this is now properties.type ?
    Panagiotis (Peter) A. Vretanos
    @pvretano
    @tomkralidis my catalogue implementation is VERY old. One of the things I hope to get done during this sprint is to bring it up to date relative to the specification. Also, use https://www.pvretano.com/cubewerx/cubeserv/default/ogcapi/catalogues/collections/sentinel1cat instead. I will be updating that instance in real time.
    Tom Kralidis
    @tomkralidis
    ok great thanks Peter
    Tom Kralidis
    @tomkralidis
    Panagiotis (Peter) A. Vretanos
    @pvretano
    @tomkralidis I think so. This is the GeoJSON feature collection schema that I copied from features.
    @tomkralidis that is what I am updating my server to generate now ...
    Tom Kralidis
    @tomkralidis
    great. Almost done in pygeoapi, then. Docs, then done !
    Angelos Tzotsos
    @kalxas
    :+1:
    Tom Kralidis
    @tomkralidis
    has anyone done work on searching across ontologies and synonyms? For example, take a weather specific variable called TMP. From an OGC API - Records perspective, is this agnostic to the actual backend search machinery, and we simply return respective themes/concepts accordingly in the records?
    paul van genuchten
    @pvgenuchten
    did some initial work on a faceted search extension opengeospatial/ogcapi-records#110, welcoming comments on any level (usefullness, add certain documentation/examples, consider alternative use cases, references, etc)
    paul van genuchten
    @pvgenuchten
    @pvretano i heard your comment related to atom/opensearch support just now, i wonder what type of integration you have in mind, shouldn't we see atom/opensearch as an alternative approach to query a catalogue, similar as any implementation could support both ogc-api-records as well as a csw endpoint?
    In geonetwork we have atom as an output format of ogc-api-records / collections endpoint, but this may not be the type of integration you have in mind? https://apps.titellus.net/ogcapi/collections/main?f=opensearch
    paul van genuchten
    @pvgenuchten
    Related to the iso19115 discussion, options to facilitate a selection of output-schema is relevant here, the discussion about this topic spreads out over quite a number of issues (for example opengeospatial/ogcapi-records#40). I wonder if some progress has been made recently.

    In opengeospatial/ogcapi-records#16 I made this comment, which still is relevant I think:

    In opengeospatial/ogcapi-common#116 and opengeospatial/ogcapi-common#8 @cportele suggests to use content negotiation by iana types, this can work when using types such as application/iso19115-3+xml, application/vnd.dcat.rdf+xml, application/vnd.dcat.ld.json, but it is less flexible then prof-conneg

    paul van genuchten
    @pvgenuchten
    @pvretano as an alternative to conneg-by-profile i like your suggestion in #40 to add a (vendor) parameter /items/xxx?schema=iso19115:2012&f=xml and the suggestion to use the OPTIONS response to advertise which schema's and formats are available for an endpoint
    Angelos Tzotsos
    @kalxas
    perhaps the schema parameter should point to the gmd namespace as we did in CSW?
    paul van genuchten
    @pvgenuchten
    having a full uri as a query-param value is not optimal
    Panagiotis (Peter) A. Vretanos
    @pvretano
    @pvgenuchten yes OpenSearch is an alternate approach but the OAPIR spec still need to specify some requirements/recommendations to support it. Let me explain ... in order to play in the OpenSearch world a server has to generate a Description document. That description document contains templated links that use standard substitution variables defined by OpenSearch & OpenSearch Geo. So, the integration point is that the server needs to implement query parameters that can be mapped to the OS substitution variables. For example, OpenSearch defines the substitution variable "count" and OAPIR defines "limit" (inherited from Features) so we can map limit to count (i.e. ...&limit={count}&...). In other cases OS defines substitution variables for which no mapping exists (e.g. OS sv startIndex) so in the OpenSearch conformance class for OAPIR we recommend that servers implement a query parameter that can be mapped to startIndex.
    Panagiotis (Peter) A. Vretanos
    @pvretano
    @pvgenuchten re ISO19115 ... yeah, I have implements the schema parameter in my server. When I get my machine back on its feet, I can demonstrate (I hope!;) ).
    Clemens Portele
    @cportele
    I would recommend to use profile instead of schema. This use is consistent with RFC 6906 and if the conneg-by-profile approach will ever become used / standardized by IETF (don't hold your breath...), this approach would still be consistent.
    Panagiotis (Peter) A. Vretanos
    @pvretano
    @cportele sure ... profile works for me ... I'll update my server accordingly.
    paul van genuchten
    @pvgenuchten
    profile works for me also :-)
    let me evaluate if our opensearch/atom implementation matches with parts of that workflow you mention above Peter, would be interesting to share experiences
    i think our opensearch implementation is heavily influenced by the INSPIRE Opensearch Download service
    Panagiotis (Peter) A. Vretanos
    @pvretano
    Sorry! Getting onto github now for the STAC disucssion!
    @tomkralidis you joining GTM for a STAC disucssion?
    Tom Kralidis
    @tomkralidis
    on the way….
    Panagiotis (Peter) A. Vretanos
    @pvretano
    Anyone interested in discussing STAC, we will be discussing on the GTM now.