Hi Gabriel, as a goal, it is achievable, but there are a few roadblocks that need to be removed. On the good side of things, we have a service that, last time I checked, managed to pass the CITE tests for OGC API - Core and OGC API Features - Coordinate Reference Systems by Reference.
However, there are also issues that stem either from the nature of the OGC APIs and part from the code being developed mostly as an accumulation of code sprints. The issue with OGC APIs development is that an implementation of a service is an amalgamation of various small specs, all of which are in different stages of development, some stable, other subject to change. The issue becomes evident when this is coupled with Spring MVC controllers, e.g. the items resource <https://github.com/geoserver/geoserver/blob/main/src/community/ogcapi/ogcapi-features/src/main/java/org/geoserver/ogcapi/v1/features/FeatureService.java#L375> : in the same method signature we have bits that are finalized (bbox, limit, datetime), bit that are only formally finalized (filter, filter-lang, filter-crs) and others that are coming straight out of other specifications (sortby). The filter bit needs some clarification. Filter comes from Part 3, which defines a general filtering mechanism, but the preferred filtering language is CQL2. I hear that CQL2 is nearing completion, but our implementation for cql-text and cql-json (found in GeoTools) are several months old. Now, in GeoServer a supported module is stable and reliable, spec wise: we cannot have someone implement a client against a supported module, and then a few months down the line, maybe to grab a security fix, have it stop working in a permanent way because the specification changed. Long story short, an extension module should implement a stable specification. So, we'll have a need to separate OGC API Features so that the unstable bits are left out in the community, as plugins, while the stable bits are found in the extension. To do this, you'll have to go thought the service implementation with a fine tooth comb and separate the various bits, opening extension points for the current functionality that does not belong in extension. Thankfully, filtering languages are pluggable already, although I'm not sure how to indicate that the default is going to be something else (e.g. ECQL) of it going this way is even desirable, as at one point that default will have to change. The other troublesome bit is that the some of the core integration of the dispatcher has overridden some Spring bits in a deep way to get support for the @HTMLOutput annotations and the general output format management (e.g., the support of "f=json", or the variable interpretation of what "f=json" means for example). I don't see it a priority, but you might think otherwise. The last bit is that this is a true community module, in that while I've been doing quite a bit of work on it, a number of people have already contributed to it, so far with little friction. I also know that GeoCat is interested in working on it (and already has, for example, contributed various bits to it) and also has some objectives to achieve, I'll let Jody explain more. Generally speaking, graduating this module will have to be an effort that keeps everyone happy, so collaboration and openness to compromise are going to be key here. Regards, Andrea Aime == GeoServer Professional Services from the experts! Visit http://bit.ly/gs-services-us for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions Group phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 https://www.geosolutionsgroup.com/ http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail On Mon, Jun 24, 2024 at 4:20 PM 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
