Skip to content

GSIP 184

Jody Garnett edited this page Jan 7, 2020 · 12 revisions

GSIP 184 - Promote MBStyle Styling to Extension

Overview

Proposed By

Jody Garnett (GeoCat) is proposing this activity to better support our GeoCat Bridge customers and the combination of GeoServer and Vector Tiles.

Note this proposal uses "MBStyle" to avoid making use of MapBox trademark.

Assigned to Release

This proposal is for GeoServer 2.17-beta.

State

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

Motivation

The Vector Tile extension for GeoServer is a popular way to generate tiles for use in MapBox.GL or OpenLayers.

The MBStyle extension is a great addition to this workflow, enabling the same styling for both client side and server side.

Proposal

Preflight check:

  1. Proposal to GeoTools PMC to take mbstyle unsupported module to plugin status.

    • Double check the duplication between GeoTools and GeoServer "specification" documentation.

Proposal covers:

  1. Moving the module from community to extension in the build system.

  2. Updating the website template to make the extension available.

  3. Updating the pom.xml contract information.

  4. Updating documentation for this extension:

    • Remove removing duplication of specification, provide a link to GeoTools docs
    • Maintain Reference Manual in GeoServer

Backwards Compatibility

Feedback / Discussion

Discussion of Map Box "Open" Standard Expectations

The Mapbox Style Specification is quite active ("unstable" by design). During life as a community module we have seen expression support added (deprecating filter in the process). Staying "current" is likely to require ongoing effort, interest and investment.

On the positive side the standard is documented with these concerns in mind, each feature being marked as available in Mapbox GL JS, Android SDK, iOS SDK, or macOS SDK. Our own copy of the documentation reflects this approach indicating what capabilities are supported.

The standard is "open specification" in that it is freely available to read. Stepping back it is of concern that the standard is now formally part of Mapbox GL JS documentation (and no longer maintained neutral to a specific SDK). MapBox spec is no longer standalone and subject to weekly updates. This tends to imply the standard will change more over time, and become more of a "boutique" document over time as it aligns with the needs of a specific library.

Extension Requirements

The developers guide lists several requirements for community modules graduating to an extension:

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

    • It was include in Boundless Suite, not sure how many users?
    • GeoCat is committed to supporting our customers use of this module, but wishes to see the functionaly incorporated into core or set up as an extension first.
  2. The module has a designated and active maintainer

    Jody Garnett (GeoCat) is willing to act in this capacity, would prefer to see two maintainers of course.

  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

    Not sure about test coverage

  5. The module has no IP violations

    This community module was developed by Boundless from the start and is covered under their CLA.

    The documentation contains a duplication of the mapbox style specification to document the capabilities of our implementation. This was within the license terms at the time, that story is more complicated with the specification being moved into the MapBox GL client.

  6. The module has a page in the user manual

    Requirement noted in proposal plan. Intend to have reference material and a couple of examples.

  7. The maintainer has signed the GeoServer Contributor Agreement

    Jody Garnett and GeoCat have signed OSGeo CLA, GeoServer Contributor Agreement no longer used.

Additional graduation considerations:

  1. User interface review

    The style editor is already shown to be compatible with this additional style format.

    Indeed the style editor "group mode" was setup with this format in mind.

  2. REST API review

    The REST API endpoint is already shown to be compatible with this additional style format.

  3. Security considerations

    The MBStyle is eventually processed into normal GeoTools Style data structures. No additional security vulnerabilities are expected as we are avoiding a lot of XML parsing.

Voting

Project Steering Committee:

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

Links

Clone this wiki locally