Hi Gabe, GeoCat is interested in doing so also - so I really wish to be sure to communicate and not trip on each other.
While Andrea has gone into some technical gotcha's I have some user experience challenges to go over also. Disclaimer that I respect the work done thus far; and many of the surprises for me come from starting to learn these new standards. *conformances* My customers really want fine grain control over the conformances; the ability to enable/disable on a case-by-case basis. This is going to be required as different regions have different mandatory requirements as we saw during the work done last year. It is also advantageous to limit the attack surface and only enable what is needed. This also provide an approach for all the optional not quite completed yet standards; they can be disabled by default? *user experience* I like the story of configure your layers in geoserver once and they will show up in additional services / protocols as they become available. Kind of the point of GSIP-202. In https://github.com/geoserver/geoserver/pulls you can see I had some surprises integrating service descriptors in line with GSIP-202. I had fully expected to rename the WFS -> Features and have the different protocols (OWS-WFS, OGCAPI-Features) be listed under this common heading. I could see changing the menu heading to "Features" with tabs for each service for example ... However each OGCAPI service has its own ServiceInfo with title/description - even if it does not provide any additional configuration over and above the open web service base (OGCAPI-Featuers uses WFSInfo for example). This was not what I expected so I am not sure I have a good idea how to proceed yet. David added some more "hints" to slot things under the correct heading; and there is not any way to configure the title / heading for OGCAPI-Features separately yet... I am also not sure what to do with things like DIGGS? So while Andrea identifies some challenges integrating with Dispatcher; I want to highlight that we have a challenge integrating with the application experience also. *Per service collections vs everything collections* This is another fundamental how should it work question. If you look at our services each has been done independently with its own collects list. The other implementations (for example pygeopai) have a single collections list; which has more functionality dumped into it to reflect each ogcapi-service conformance enabled ... The "everything" collections is a much better user experience. List stuff and how to interact with it in one place. However it has its limits; even pygeoapi has ended up with "collection" and "record-collection" now... Keeping them independent results in a service that is small enough we could test openapi client generation (but perhaps only the two of us share that dream eh?). Aside: It looks like some things like ogcapi-records search are designed to be additions to all collections end-points (adding text search for example). If we could answer this a bit better we could determine if a refactor / merge is needed? *Tech preview* Last year I relaxed Docker restriction to allow for nightly builds and public testing of OGCAPI services. Even putting that example in the user guide for cut and paste ease. I am not sure if it has resulted in any additional feedback/development/funding? My other idea is to put up a "tech preview" of GeoServer only with OGCAPI services with a warning that "contains community components that have not been reviewed". Similar to how Eclipse Foundation includes a warning on downloads that include incubating components... - Goal: Get more eyes on the OGCAPI protocols and thus more interest both development and funding ... - Caution: This may not be worth it give our poor community response to participation. I have been disappointed with the response thus the 2024 roadmap challenges. It may be easier to interest people in new functionality; but we do need to look to sustainability also. I am going to stop now .... -- Jody Garnett On Jun 24, 2024 at 7:19:26 AM, Gabriel Roldan <gabriel.rol...@camptocamp.com> wrote: > Hi all, > > Camptocamp is interested in contributing to graduate the > gs-ogcapi-features module (and by extension gs-ogcapi-core) to supported > status. > > I'll be getting used to it, but wonder if that's an achievable goal and if > you have any clue of what it would entail. > > Cheers, > Gabe > *camptocamp* > INNOVATIVE SOLUTIONS > BY OPEN SOURCE EXPERTS > > *Gabriel Roldán* > Geospatial Developer > > _______________________________________________ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel >
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
