Consider removing references to OGC WFS in the best practice

[jvanulde]

As discussed in the update meeting on June 30, 2022 the best practice should promote OGC API - Features rather than OGC WFS. Furthermore, the new generation of OCG APIs are substantially aligned with the best practices and so it may be prudent to mention OGC API - Records, OGC API - EDR, etc. even though many of them are in draft. Perhaps as an aside or prominently in the emerging best practices section.

[lvdbrink]

I've taken a look at the current document and there are still several significant references to WFS. It is not so simple to remove them all.

Quite a few of these references occur in a section in BP12, where the possible approach describes how you could transition from the 'old' SDI standards (WFS/WMS/CSW etc) by hiding them, as a first step, behind a proxy or enriching the data provided through these services with linked data.

It might be best to retain these examples still, because these seem to be viable ways to start offering web-friendly spatial data without having to revamp your entire SDI.

On the other hand, is anyone really doing this? Or is it really better to set up new OGC APIs and start phasing out the old WFS services?

In any case, I'm not comfortable (yet) removing all WFS references without a discussion... Possibly I missed all the discussion (sorry if that's the case).

In other part of the document references to WFS do occur that we can remove or replace. I'll start doing that.

[situx]

We have discussed previously that we would want to remove as many references to WFS as reasonable, i.e., that there are places in the document where it makes sense to do that, e.g., to update an example in which, as WFS is used with an example in which OGC API Features is used. I think it is important to acknowledge that WFS still exist and are, for the time being, at least still used. I know that people are building parallel infrastructures with linked open data or have plans to do that, not to hide WFS services but rather to make them accessible in RDF. However, with OGC API Features being here now, there is a web-friendly alternative to representing data that used to be represented by a WFS, so if parallel infrastructures are set up, then it is mainly to promote RDF only.

[lvdbrink]

Okay, then I think I will keep example 51, 52 and 53 in BP12, but add text to BP 12 explaining that it is possible to publish spatial data on the web as a convenience API, using OGC APIs (and how to do that + an example). And recommend this as the best option. And then go on to say that

If the data is already published in a Spatial Data Infrastructure based on the old generation OGC services (WFS/CSW etc), there are basically two options to publish the data via an additional convenience API.

(new part highlighted)

And then basically keep the text that follows as is.

Any thoughts?

[situx]

I think that should be fine, even though ldproxy to my knowledge, is nowadays used as an OGC API Features frontend and less as a frontend for WFS services unless I missed something.

[cportele]

even though ldproxy to my knowledge, is nowadays used as an OGC API Features frontend and less as a frontend for WFS services unless I missed something

Just to clarify, since ldproxy was mentioned: ldproxy can be used to deploy OGC Web APIs (that is, spatially-enabled Web/HTTP/REST APIs that implement API building blocks from OGC API standards). The spatial source data can be accessed from various backends, including WFS.

In general, I see OGC API facades on top of WxS as a transitional approach. For an OGC Web API in production, I would recommend to directly access the data source, typically some database.

If it helps, I could also review and propose updates to the text next week.

[situx]

Thanks for the clarification, and yes, I agree, I have mainly seen ldproxy interact with databases. That was my point. If you think you can improve the text here, I think the best would be to push to Lindas Draft Pull Request #1385 Thanks for reviewing and updating.