Skip to content

GSIP 210

Jody Garnett edited this page May 7, 2022 · 11 revisions

GSIP 210 - Promote kml-ppio to wps-extension

Overview

The KML PPIO community module adds the ability to transform between GeoTools FeatureCollection objects and KML files. In particular, it can read generic KML and generates the same flavor of KML as its sibling WFS output format, with attributes but without styling.

Proposed By

Andrea Aime

Assigned to Release

This proposal is for GeoServer 2.21.0, with a possible backport to 2.20.x

State

  • Under Discussion
  • In Progress
  • Completed
  • Rejected
  • Deferred

Motivation

The module has been deployed along with GeoNode for a while, allowing generating KML outputs from WPS processes, for subsequent overlay in Google Earth. The module presented no particular issue and is very simple, containing just a single class and a Spring application context file.

Adding the module in GeoServer WPS will improve the parallelism between WFS and WPS, allowing both protocols to generate the KML format in a consistent way.

Proposal

Given the simple nature of the module, it's tempting to simply add the PPIO to the existing gs-wps-core module. However, while natural from an end-user point of view, it presents challenges for those that want a micro-service based deploy. In particular, kml-ppio depends on the core kml module, which in turn depends on the wms module in quite the significant way. That would pose a roadblock for those trying to deploy GeoServer in a micro-service way, as WPS would suddenly depend on the WMS module as well (an exclusion would not help, due to the PPIO declaration in the Spring context).

For this reason, we propose to graduate it with a more gradual approach:

  • The module, as code, would graduate to extension/wps/wps-kml-ppio.
  • Packaging wise, it would be included in the wps release zip, making it transparently available to end-users without extra hassle.

Those that removed the wms or kml modules in their deploy can either avoid depending on it (if using Maven) or removing it from the WPS zip file before copying the results to WEB-INF/lib.

Actions needed for graduation:

  • Moving the module from community to extension in the build system.
  • Cleaning up eventual QA failures
  • Update wps extension artifact to include these jars
  • Updating the pom.xml contact information.
  • Updating documentation location, remove eventual warnings related to community status.

Extension status requirements

The developer's guide lists several requirements for community modules graduating to an extension:

  1. The module has at least a “handful” of users

    • The module has been included in GeoNode's customized GeoServer five years ago.
  2. The module has a designated and active maintainer

    • Andrea Aime (GeoSolutions) is willing to act in this capacity.
  3. The module is considered “stable” by the majority of the PSC

    • The module has been unchanged and working for several releases.
  4. The module maintains 40% test coverage

  5. The module has no IP violations

    • Module was fully written and maintained by GeoSolutions personnel.
  6. The module has a page in the user manual

    • The module has no documentation page. Given the plan to have packaging integrated with WPS, no dedicated page will be written. The WPS user documentation has no mention of PPIOs either. A new section inside the operations page will list the available formats to encode feature collections, that will include a mention of KML.
  7. The maintainer has signed the GeoServer Contributor Agreement

    • OSGeo CLA signed

Voting

Project Steering Committee:

  • Alessio Fabiani: +1
  • Andrea Aime: +1
  • Ian Turton: +1
  • Jody Garnett: +1
  • Jukka Rahkonen:
  • Kevin Smith: +1
  • Simone Giannecchini: +1
  • Torben Barsballe: +1
  • Nuno Oliveira: +1

Links

Clone this wiki locally