Hi Gabriel, thanks for following up, some feedback inline below.
On Tue, Jul 30, 2024 at 5:45 PM Gabriel Roldan < gabriel.rol...@camptocamp.com> wrote: > * Defining and Implementing Service Metadata Independent of WFS > Configuration: > > Currently, the service metadata and configuration for the OGC Features > module use the WFS service configuration. We need to decouple it from the > WFS configuration, and the exact approach is open for discussion. > Agree with Jody, I don't see it as a strict necessity to separate the two. Even when separate, there is a number of output format configurations in the WFS admin page, which are stored in the WFSInfo, that would still be shared between the two services. Unless one wants to configure the output formats in different ways depending on the service? Seems unlikely but not impossible. Generally speaking, in my mind, I see parts that are specific to WFS/Features (e.g., titles, descriptions, keywords), parts that are shared (output formats)... but going there would mean breaking the existing configuration and REST API quite a bit. I'd wait and see how the requirements from actual usage emerge. > * Designing and Implementing a Mechanism to Enable/Disable Non-Finalized > Parts of the Specification: > > The OGC Features API is divided into separate specifications, some of > which are not finalized. It is crucial that these unfinished aspects of the > API can be enabled or disabled via configuration. This configuration will > likely be part of the ogcapi-specific service configuration mentioned above. > This is going to be "fun". It could be something similar to KVPReader, pluggable objects that take the raw request and can, if enabled, enrich/alter the request object which is being sent to the underlying feature engine. > * Setting Up CI/CD Pipelines: > > We need to establish and integrate continuous integration and deployment > pipelines for automated testing. These pipelines should run CITE > conformance tests and additional integration tests (e.g., against PostGIS). > I would recommend against setting up a CI/CD in Jenkins, if that breaks, we are too late as the commit already got in, and grabbing the original committer might take time. Instead, make it a Github action that fails in the PR, blocking its merger. Testing can be "fun", the CITE tests are not data specific, meaning that you can have different results depending on which data you use for the tests. I'd start with the WMS 1.0 CITE test data directory, as it has simple data, while the WFS ones can be more challenging. And you could have the GeoServer under CITE use PostGIS, to catch two birds with one stone (again, some failures will be format specific, a test might work under PostGIS and fail under GeoPackage for example). > * Providing a Technical Preview Distribution of GeoServer: > > A technical preview distribution of GeoServer with the OGC APIs enabled > will allow us to reach a wider audience for testing and early feedback. > Isn't testing with the docker image enough? Even if they reach extension status, they would still be optional, but easy to install. > * Organizing a Code Sprint: > > To complement community discussions on design and implementation, it would > be ideal to organize an online code sprint. Although we may not have > sufficient funding for an on-site event, an online code sprint would still > enable all interested parties to contribute focused time and effort. > Even an online sprint will require some funding, a large part of the participation cost is normally lost revenue. Cheers Andrea
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
