Sorry gabe, here is the correct PR: https://github.com/geoserver/geoserver/pull/7716 showing some of the user interface integration challenges -- Jody Garnett
On Jun 24, 2024 at 11:40:34 AM, Jody Garnett <jody.garn...@gmail.com> wrote: > 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
