Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 10:04
    cportele commented #502
  • Jun 15 08:01
    cportele commented #546
  • Jun 15 07:28
    cportele commented #588
  • Jun 15 05:46
    jampukka commented #570
  • Jun 14 17:42
    cportele commented #493
  • Jun 14 17:13
    cportele commented #587
  • Jun 14 17:09
    plutoscarab commented #541
  • Jun 14 16:44
    cportele commented #592
  • Jun 14 16:43
    cportele commented #541
  • Jun 14 16:34

    cportele on master

    Remove bitStringLiteral and hex… Merge pull request #591 from pv… (compare)

  • Jun 14 16:34
    cportele closed #591
  • Jun 14 16:32

    cportele on master

    Remove boolean literal T|t,F|f,… According to RFC 5243, ABNF str… Merge pull request #590 from pv… (compare)

  • Jun 14 16:32
    cportele closed #590
  • Jun 14 16:27

    cportele on master

    escape URI template closes #588 Merge pull request #589 from op… (compare)

  • Jun 14 16:27

    cportele on uri-template

    (compare)

  • Jun 14 16:27
    cportele closed #589
  • Jun 14 16:27
    cportele closed #588
  • Jun 14 16:13

    pvretano on master

    Fix typo. (compare)

  • Jun 14 15:37
    cportele commented #587
  • Jun 14 15:25
    heidivanparys commented #587
Andrea Aime
@aaime
I would agree with @jampukka on LIKE
Seems like an advanced capability at least
Janne Heikkilä
@jampukka
Yeah and I'm having hard time coming up with what would be the actual benefit of it
Janne Heikkilä
@jampukka
Having case-insensitive version of LIKE is nice because it allows for the server to decide what's the best way to do it (e.g. for postgres backed services maybe you indexed upper(column) instead of lower(column)). I wonder if having a separate predicate (ILIKE?) would be easier for implementations to handle?
Clemens Portele
@cportele

@jampukka @aaime - Please open an issue about LIKE.

I just checked CSW and the qualifiers like SINGLECHAR are new, so they are not part of the CQL legacy and I would have not problems to remove them again. Maybe NOCASE still makes sense, but another keyword like ILIKE would be an option, too.

Janne Heikkilä
@jampukka
Temporal operators seem to make sense when a property is of type interval. For timestamps/instants these seem a bit overkill and most of the time just get translated into a set of <, <=, >=, >, OR, AND, NOT operations
Or am I missing something?
I'll open an issue about LIKE
Andrea Aime
@aaime
@cportele GeoServer uses ILIKE indeed
Andrea Aime
@aaime
@jampukka that's my experience as well, temporal operators against instants are normally translated down to generic comparisons (e..g, in SQL)
Janne Heikkilä
@jampukka
@cportele we are interested in and will implement Property Selection #525, Schemas #527 and parts of Queries/Search #528 (executing POSTed ad-hoc queries, listing and executing stored queries and listing their parameters) but I'm not in a position to say that NLS Finland will commit to an implementation
Clemens Portele
@cportele
Thanks @jampukka. We have enough commitments for most capabilities to start the work and what is important in the end is to have multiple consistent implementations. The commitments are mainly there to get an early indication, if there is sufficient interest to start work on a new task. I am looking forward to eventually see the updates to your NLS Finland APIs!
Janne Heikkilä
@jampukka
Has there been any discussions about comparing fields to another fields being an advanced filtering capability not simple?
For example Elasticsearch EQL doesn't allow this "You also cannot compare a field to another field, even if the fields are changed using a function." (https://www.elastic.co/guide/en/elasticsearch/reference/current/eql-syntax.html#limitations-for-comparisons)
CQL does too?
Panagiotis (Peter) A. Vretanos
@pvretano
@jerstlouis @jampukka, CQL allows general expression comparisons so field1=field2 is allowed.
@jampukka no, there has been no discussion about making field1=field2 an "advanced" capability. Seems like a pretty standard filter expression capability ... no?
Jerome St-Louis
@jerstlouis
@pvretano I would agree :)
Clemens Portele
@cportele
Yes, but since there are backends that do not support such predicates as @jampukka points out and since most filter expressions will consist of predicates with a property reference and a literal, maybe we should consider to make predicates like field1=field2 a separate conformance class?
Janne Heikkilä
@jampukka
Yes that's exactly what I meant @cportele
Panagiotis (Peter) A. Vretanos
@pvretano
@jampukka @cportele I have no problem considering it... Is there are issue in the feature's github?
Janne Heikkilä
@jampukka
nope not yet, just something I came across while taking a look at Elasticsearch.
Just hoping that we can keep Part 3 as simple as possible to implement while still solving large portion of use-cases
Janne Heikkilä
@jampukka
STAC query extension also seems to follow the simple property operator literal pattern (https://github.com/radiantearth/stac-api-spec/tree/master/fragments/query). However it looks like the query extension is only at Pilot stage and "Likely to get deprecated in the future in favor of CQL." (CQL being OGC API Features Part 3)
Panagiotis (Peter) A. Vretanos
@pvretano
@jampukka understood...
Clemens Portele
@cportele

@cholmes / all - Based on the discussion earlier in the thread, the working group has decided to "inofficially" extend the review period for Part 3 (CQL/filtering) to the end of May - and if more time time is needed, please let us know.

We have started to discuss the comments that we have received during the official review period, but will take additional comments into account as we receive them. We have updated the readme page of Part 3 with the latest information and also with information about servers available for testing (currently two).

We will try to keep this updated. Pull requests are welcome, if there are other servers. If anyone finds issues with the implementations, please let us know, too.

Tom Kralidis
@tomkralidis

@cportele in EDR we are taking your lead on updating our implementations.

Question: are there any thoughts on where/how to highlight deployments of implementations?

Clemens Portele
@cportele

@tomkralidis - Currently these are / can be included in the sub-page of each tool. See e.g. pygeoapi or ldproxy.

The OGC Product Database also has links to deployments for testing (mandatory for reference implementations, I think).

Tom Kralidis
@tomkralidis
thanks Clemens. Aside: PR in opengeospatial/ogcapi-features#573 while I was there :)
Clemens Portele
@cportele
Merged :)
Tom Kralidis
@tomkralidis

@tomkralidis - Currently these are / can be included in the sub-page of each tool. See e.g. pygeoapi or ldproxy.

The OGC Product Database also has links to deployments for testing (mandatory for reference implementations, I think).

@cportele what about deployments which are not backed by products per se?

Phil Varner
@philvarner

Related to Part 3 -- my understanding is that I could mix and match the GET (query parameters) and POST (JSON body) and cql-lang of CQL Text or CQL JSON, e.g., I could support all 4 combinations? Is this correct?

GET /items?filter-lang=cql-text&filter=prop1=2
GET /items?filter-lang=cql-json&filter={ "eq": [ { "property": "prop1" }, 2 ] }
POST /items { "filter-lang": "cql-text", "filter": "prop1=2" }
POST /items { "filter-lang": "cql-json", "filter": { "eq": [ { "property": "prop1" }, 2 ] } }

And, how would I advertise that I did support these, or that I only supported cql-text for GET and cql-json for POST? (I didn't see that in the spec, through it might be in there and I just missed it)
Clemens Portele
@cportele
@tomkralidis - My general feeling is that managing a catalog of deployments via GitHub and PRs is not the right approach, it doesn't scale. A separate catalog app/website would be a better approach. Something like STAC Index.
Clemens Portele
@cportele
@philvarner - The current Part 3 only specifies support for GET (and POST to /items would be restricted to Create new features) and POST would be supported at /search (https://github.com/opengeospatial/ogcapi-features/tree/master/proposals/search). See #449. If "cql-text" and/or "cql-json" is supported can be determined from the Conformance Declaration at /conformance. If this includes http://www.opengis.net/spec/ogcapi-features-3/1.0/req/cql-text then CQL Text is supported (http://www.opengis.net/spec/ogcapi-features-3/1.0/req/cql-json for CQL JSON).
Tom Kralidis
@tomkralidis
@cportele thanks, and totally agree
Phil Varner
@philvarner
@cportele thanks, I keep forgetting that the OGC endpoints don't use POST. For STAC API Item Search (and I hope for Part 5), I think I'm going to state that GET must support cql-text and cql-json, and POST JSON must support cql-json, but implementers may support cql-text in POST JSON if they wish.
Clemens Portele
@cportele
Sounds good @philvarner
Chris Holmes
@cholmes
Question - I see a opengeospatial/ogcapi-features#501 for renaming from Simple transactions, and an associated PR that looks to cover everything, that was merged to master. But when I go to https://github.com/opengeospatial/ogcapi-features/tree/master/extensions/transactions I see 'simple' everywhere. Am I looking the wrong place?
Also what's the status on transactions extension? Is it going up for comments (or did it already)?
Martin Davis
@dr-jts
Are there any CQL-text grammars available for popular parser-generators? (E.g. ANTLR)?
4 replies
Panagiotis (Peter) A. Vretanos
@pvretano
@cholmes right place. Read the draft https://docs.ogc.org/DRAFTS/20-002.html. We have not updated the README in the transaction directory. Most of the relevant README text is in the top level README https://github.com/opengeospatial/ogcapi-features. I'll try to update the "local" README soon.
1 reply
@cholmes we are working on CQL RFC comments at the moment. Once we finish with those we will shift gears to get Part 4 in shape for RFC.
1 reply
Chris Holmes
@cholmes
For CQL, I'm happy to have Planet fund Even soon to get GDAL up to snuff and give feedback from a client perspective. I see the updated links for your server Peter, and I'm assuming Clemens's is also up to date. Are there any other CQL server implementations for him to test against? I think we'll also have a couple STAC implementations soon, and are aiming for a beta.2 release of STAC API spec that incorporates it.
1 reply
Brad Hards
@bradh
Panagiotis (Peter) A. Vretanos
@pvretano
@bradh pvretano.com is my development machine so my servers are kinda testbeds and not 100% stable ... what issue did you run into?
Brad Hards
@bradh
It looked like a problem with the oracle? backend.
That specific url just spins and doesn't return anything.
I was just letting you know, not demanding a fix.