WFS3 Search extension.

[JivanAmara]

Update spec with a /search/ endpoint which accepts a POST request with a query in the body.

Issues:

• Result
  • Return feature collection directly or new virtual collection which is then accessed at another endpoint (such as /searchresults/) where paging will be available.
• Query Format
  • Do we need arbitrary query format?
  • Should we use an existing query tool/language such as openquery or cql? (benefit, familiarity/tooling)...
  • ...or should we simply define a json query object?
• Queryable Parameters
  • The core will require the query parameters "BBOX" & "time"
  • The openapi doc for the service should define the queryable parameters beyond those defined in core.

[rcoup]

See also discussion on #67. ElasticSearch also has a query syntax worth reviewing

[KathiSchleidt]

A further related bit I've always been missing on OGC services, an option to request possible values for a specific element before filtering. DB equivalent would be doing a SELECT DISTINCT on a field. This is essential for creating GUIs on top of OGC services, in order to provide the user with a sane list of existing values (instead of providing all possible values, most without data, in a pulldown). The closest I've found in WFS 2.0 is GetFeature in conjunction with the propertyName key, but this would require first accessing the mini-representation of ALL available features, seems like a waste of resources both server and client sides!

[nmtoken]

In this vein as part of the EarthServer project we had xWCPS, which was a combination of WCPS and XQUERY.

-----Original Message----- From: KathiSchleidt notifications@github.com Sent: 02 July 2018 16:17 To: opengeospatial/WFS_FES WFS_FES@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [opengeospatial/WFS_FES] WFS3 Search extension. (#79)

A further related bit I've always been missing on OGC services, an option to request possible values for a specific element before filtering. DB equivalent would be doing a SELECT DISTINCT on a field. This is essential for creating GUIs on top of OGC services, in order to provide the user with a sane list of existing values (instead of providing all possible values, most without data, in a pulldown). The closest I've found in WFS 2.0 is GetFeature in conjunction with the propertyName key, but this would require first accessing the mini-representation of ALL available features, seems like a waste of resources both server and client sides!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/opengeospatial/WFS_FES/issues/79#issuecomment-401839605 , or mute the thread https://github.com/notifications/unsubscribe-auth/ABnU2y7ZM3W4zhj-4Mx31QVEGun-W2VQks5uCjlWgaJpZM4SjcSv . https://github.com/notifications/beacon/ABnU29sdVW3M7VsWA0H5xpjX1cb1Mozzks5uCjlWgaJpZM4SjcSv.gif

---

This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.

---

[pvretano]

@KathiSchleidt The "propertyName" in GetFeature is not what you are looking for. This is simply a projection clause that specifies which optional properties appear in a response document. It tells you nothing about what property values you might use to build a selection clause (i.e. filter).

What you are looking for is the GetDomain operation that was defined in WFS 2.5. You give GetDomain the name of a feature property or a parameter in the API and the GetDomain operation would return a document describing the value domain in question. This could be an enumerated list, a reference to an authoritative dictionary/vocabulary, a range of values, etc. The idea was that the server would give you some idea about the actual property values available. You could then use that information to construct filters that have a good chance of actually returning something! GetDomain had other "suggestion api" capabilities too. If you are an OGC member, you can review the GetDomain operation here: https://portal.opengeospatial.org/files/?artifact_id=64825

As you may (or may not be aware) WFS 2.5 was abandoned in favour of WFS 3.0. This does not mean that the functionality of WFS 2.5 will be lost but rather it will be refactored into extensions of WFS 3.0. Right not, we have only defined the WFS 3.0 Core. Eventually there will be some extensions such as the CRS extension and ... eventually ... the GetDomain or "Suggestion" extension.

[cportele]

Of course, the server can also provide information about the value domain of properties in the OpenAPI definition.

[KathiSchleidt]

Hi Peter, Clemens cool, thanks! @Clemens: while I admit I'm still a newbie to OpenAPI, I worry that if all possible values of all fields get lifted to the OpenAPI definition, this could be overload. Could you provide a pointer as to how this can be sanely done? @Peter: Quick question - what OGC SWG do I have to be a member of to see the doc? Just tried, but get access issues, still a bit lost on the OGC portal! :)

[pvretano]

https://github.com/KathiSchleidt It's the WFS-FES SWG.

[cportele]

@KathiSchleidt - You can use most of the capabilities from JSON Schema to describe the list of values (min/max for numerical values, enums for enumerants, etc): https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md#schema-object

[KathiSchleidt]

@cportele - thanks for the pointer! I'm still trying to understand, but, I'd expect the schema to be data-set neutral, so providing all possible values that can be provided via the schema, not the explicit list of values made available by a specific service. That in turn would leave us about where we are with WFS 2.0: We can interogate the service to determine from which code-list values are to be taken, but we cannot determine which of these values are actually included by the dataset being served by the service. Think what I'm looking for is more aligned with the offering concept from SOS and WCS (though that admittedly also has its downsides!) GetDomain seems like a simple light-weight extension that would open up the use of data from OGC services to a far wider audience, thus think this is still what I'd want!

[cportele]

@KathiSchleidt - It is different from the WFS 2.x situation. The XML Schemas are fixed and you should not change them without changing the target XML namespace. I.e., every deployment uses the fixed community schema where those exist. This is different here, the typical expectation is that the schema in the OpenAPI definition reflects the data, not a standardised schema. It is the description of the particular server and API, not of some external specification. If the standardised schema supports 20 enums, but your data will only use 4, I see no reason to include the other 16 enums. Or, if you will never have data for an attribute in the community schema, then I would recommend to not include it in the OpenAPI definition.

I am not saying that there is no reason to have something like GetDomain, but in many cases it is not really needed, I think.