GeoTools / GeoServer PMC meeting - 2025-08-12Attending -
Torben Barsballe - Gabriel Roldan - Jukka Rahkonnen - Andrea Aime - Kevin Smith - Peter Smythe - Jody Garnett Actions from prior meetings: - [image: checked] Gabriel: Review geoserver#8665 <https://github.com/geoserver/geoserver/pull/8665> before 2.27.2 release - [image: checked] Peter: 2.27.2 release later this week. Mention CITE cert in the release announcement Agenda 1. Splitting GeoServer into smaller modules (chit chat) 2. One month to 2.28.0 3. MKDocs how is it going 4. Progress on OGC API Process CITE tests 5. OSGeo Code Sprint 2025 in Riga Actions - [image: unchecked] Splitting GeoServer into smaller modules (chit chat) Several core GeoServer modules are large, and cause the build to be fairly slow. In particular, OGC services such as WFS. This is in part due to interdependencies between these modules, and in part due to each module including every version of the service Idea: Split off OGC services into smaller modules, that don’t need to be included - Core engine - Individual protocols - Integration modules that depend on other protocols This would both speed up the build (through more parallelization), and allow more configurability in GeoServer deployments, not requiring every service version to be in every GeoServer deployment. Chat: - Gabe would like to turn: GeoServer cloud from 40k to 1k, and have it just be a distribution over time… - Sharing requests between modules, wrapped in an interface. - Jody likes the idea of enable/disable specific profiles / conformances - This is more a UI / Setting challenge - Conformance has some way to store additional enable/disable functionality, use the same approach to manage WFS 2.0, WFS 1.1, WFS 1.0. - This is an idea on the side of Andrea's desk, so a good idea if folks wish to help out or proceed - Chance to improve modularization - ideally alongside GS3 - How to make different GeoServer downloads - make a “lite” that just has WFS 2.0, WCS 2.0, WMS 1.3, ogcapi-features - or just has an ogcapi services etc… - alternative: manage in docker image, include extensions, and include/exclude on startup One month to 2.28.0 Focus GS3 Milestone 1.0: - ImageN: 50% - critical path - The core ImageN is “working” (compiling and passing tests) - moving a number of “legacy” operations out of the way - restore “comparison” tests between affine original, and adding jai-ext - However updating downstream code, and getting it to compile is what we are working on now - OAuth2 OIDC: 50% not a blocker, can work on during 2.28.x - OIDC is present and can be tested - Feature parity needs to be worked on, but is not a blocker - Build + Environment: 90% - Java 17 and build improvements - Open Rewrite migrations not required, but is a solid improvement - this is not a blocker Weather report: chance of rain, GeoServer 2.28.0 may be delayed due to the above, stay tuned! Stay dry. Enjoy summer. MKDocs how is it going This is an area where we can use help. There is some enthusiasm, but we need to get it to the stage where it can be worked. Can run the script following instructions - however there is a regression, so output is not working, need to troubleshoot - https://github.com/jodygarnett/translate - idea: automate the translation script publish its “example” docs Peter to check back in September, set up a small online code sprint. Progress on OGC API Process CITE tests <testng-results total="54" passed="40" failed="9" skipped="5"> 74% success! Test requires echo process, for string, double, bbox, remote reference etc… - tests you can read, and then also write, each type OSGeo Code Sprint 2025 in Riga September 29 to October 3, 2025 Jukka will probably be there and can have a look at some old JIRA tickets, at least. Ideas: - alongside European Commission and ESA organized conference, big data from space - GS3 code sprint? maybe.. we avoid logistics of venue… - Close reports that cannot be reproduced Chit Chat GEOT-1179 <https://osgeo-org.atlassian.net/browse/GEOT-1179> Bursa-Wolf parameters selection in the EPSG database - So annoying, slightly different results from proj - override <https://docs.geoserver.org/latest/en/user/configuration/crshandling/customcrs.html#override-an-official-epsg-code> “works” but is annoying - when options are “even” there is a selection process, decides blindly - does not always guess the same as PROJ - PROJ defaults on widest entry - GeoTools takes most accurate even if very small - could we do some hints, “do not prefer deprecated”, or “prefer newer”, .. sigh. - Jody was looking at EPSG:31287 MGI / Austria Lambert - MGI Datum is not chosen the same as PROJ - Use system variable to change to PROJ approach - If you did it dynamic, as you do tiles it would change to more accurate - Perhaps area of layer, and then pass that down to CRS subsystem - That way it could chose all of Austria, or a city specific one … - Hint to supply “area of interest” … that is the real solution - -Dorg.geotools.referencing.operation.order=AreaFirst Documented here: https://docs.geotools.org/latest/userguide/library/referencing/config_transformations.html PROJ has lots of options: https://proj.org/en/stable/apps/projinfo.html - Can provide area used for selection - Default is to select first one from list of alternatives - default order sorted by area, directly from the database (but the database does not provide a preference) Discussion change defaults for GS3: - Andrea: Could we change this default in GS3? Yeah perhaps - Andrea: Enable prepared statements, multithreading - Gabe: Java virtual threads. java 21 only feature, maybe multi-release jars? - Java 25 is coming out soon - Jody: “Secure by default” vs “backwards compatibility” - not comfortable with either option, honestly - Andrea: Grid set name EPSG:900913 -> WebMercatorQuad (not EPSG:3857)
_______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
