Attending- Jody Garnett
-
Jukka Rahkonnen
-
Torben Barsballe
-
Andrea Aime
-
Kevin Smith
Actions from prior meetings:- N/A
Agenda1. Build server migration
-
GeoServer Docs Migration
-
STAC store and mosaic
-
Jetty integration in the bin
Actions- None
Build Server Migration
New Build Server still pending… waiting on DevOps availability?
Contacting Alessandro
Last we heard was that tests were successful, migration test was successful.
Update: https://github.com/geoserver/geoserver/wiki/Move-build.geoserver.org-to-larger-server
GeoServer Docs Migration
This is the last step needed to complete domain migration; we have osgeo space; we have a build server, we need someone with time to copy geotools docs script and change for geoserver.
Regina has set up Jody and Torben with access to the website staging area.
It would be great to be free of boundless S3.
Torben is going to try and take a stab at this sometime this month.
STAC store and mosaic
New community module in geotools “datastore” that speaks to stac api search.
Can do more that ogcapi-features which is nice.
-
Configure store with “hard filter” to avoid millions of results (example “today”)
-
looking at live image mosaic-on-the-fly
Example last day of landsat images from microsoft planetary computer:
Jetty integration in the bin
Really easy to upgrade jetty but skip updating start.jar (one of the few jars included in codebase).
Jody looked and we could use the shaded jar (as used by distribution).
Discussion on continued use of Jetty:
-
bin download uses jetty (and windows installer)
-
pushed to upgrade jetty more and more often; does not keep support for a long time
-
tomcat keeps updated versions of tomcat for a very very long time
Spring boot does simple embedded tomcat, cloud first geoserver uses tomcat as well. Does not work well with xml configuration.
Part of discussion with:
-
Java 8 → Java 11 → Java 17
-
JavaEE → Jakarta
-
Jetty → ???
Chat
OWS standards are proposed to be deprecated by end of 2027.
-
That is really cool!
-
Time to move to ogcapi everyone …
-
Excerpt from TC-Announce mail:
• OWS standards are proposed to be deprecated by end of 2027. There is a transition plan working towards that date including publication of guidance documents, migration cookbook, procurement guide and public polling. -
• Deprecation of the OWS Standards will be accompanied by resources to help users transition and support legacy systems.
-
• Discussion: some want a longer transition, some shorter. The old Standards will be in products for many years, the issue here is to indicate that the OWS is deprecated and that new acquisitions need to use the new Standards.
-
• After discussion in the PC this transition plan will be amended and circulated to the PC.
GeoServer Strategy chat for OWS deprecation:
-
Long-term - move OWS implementations to extension, switch OGCApi to core
-
This is quite a lot of work, required funding
-
Participating in ogc sprint is not really being effective here (and we need to step back until standards are more stable)
-
This needs OGCAPI to actually release stable api specifications that are useful
-
OGC Features core is stable, but doesn’t have many capabilities
-
Other OGC specs are still bad, mostly incomplete
-
Right now, most useful capabilities are changing too frequently for it to be practical to implement
-
Q: So what can be ready for OGC API Features
-
core and features and be graduated to extension with clean up
-
collections - list of feature types
-
items - page through data
-
filter by space (bbox) and time
-
also non-standard:
-
filter via ECQL (not CQL2)
-
forget about the others
Data directory:
-
jody wants a geopackage example for foss4g workshop
-
What is too big (1 MB or less)
-
GeoServer Web Map Services → Maps
-
GeoServer Wem Map Tile Services → Tiles
-
Discussion of top-level categories - OGC API is structured differently enough from OWS that each may need their own header.
-
E.g. “Styles” is for vector tiles and is associated with “Tiles”, not “Maps”