Skip to content

GSIP 126

Jody Garnett edited this page Jul 12, 2017 · 1 revision

GSIP 126 - Runtime ProcessParameterIO creation

Overview

Proposed By

Andrea Aime

Assigned to Release

This proposal is for GeoServer 2.8-beta, with an eventual backport to 2.7.x (the proposal is long because detailed, not because the changes are invasive)

State

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

Motivation

The current PPIO (Process Parameter Day) design currently allows to plug converters the Java objects representing process inputs and their external representation, decoupling the two and allowing new formats to be added to existing processes.

The main limitations of the current design are:

  • The PPIO are registered in the Spring context and looked up as Spring beans, meaning they need to be all known at compile time
  • While not all PPIO can do both encoding and decoding (output and input respectively) the API provides no way to figure out if the PPIO can actually support both sides (a runtime exception is eventually thrown when trying to use them)

In this proposal we want to remove both limitation and add an example of dynamically generated PPIOs using the new functionality.

Proposal

The proposal consists of three simple changes, ability to indentify the direction of a PPIO, the ability to create new PPIO at runtime, and an OGR based implementation leveraging the two concepts

Identifying input and output abilities

The ProcessParameterIO class will be extended with an enumeration declaring which operations are supported, and a method to retrieve the supported ones.

public abstract ProcesssParameterIO {

public enum PPIODirection { 
  /** Only encoding supported, PPIO suitable only for outputs */
  ENCODING, 
  /** Only decoding supported, PPIO suitable only for inputs */
  DECODING, 
  /** Both encoding and decoding supported */
  BOTH };

      /**
       * Used to advertise if the PPIO can support encoding, decoding, or both. 
       * By default BOTH is returned, subclass can override with their 
       * specific abilities
       */
public PPIODirection getDirection() {
   return PPIODirection.BOTH;
}
}

To avoid breaking backwards compatibility the new method will return PPIODirection.BOTH by default, subclass implementors are kindly requested to override the method as needed.

The DescribeProcess object will be modified to take into account the PPIO direction when declaring the supported inputs and outputs formats.

The PPIOFactory extension point

The factory will be used to locate ProcessParameterIO instances that cannot be known at compile time:

public static PPIOFactory {

    /**
     * Returns a list of process parameter IO. This method will be called every 
     * time a PPIO is looked up , so implementors are required to implement  
     * suitable caching if the creation of these objects is expensive
     */
    List<ProcessParameterIO> getProcessParameterIO();
}

The ProcessParameterIO.findAll() method will be modified to also lookup for factories, and integrate the generated PPIO objects in its results.

The OGR module integration

The OGR module integration The OGR module is today a WFS output format generator, it leverages the ogr2ogr utility to create WFS output formats for new formats. The list of available formats depends on which libraries ogr2ogr was compiled with, and a configuration file picking the desired ones along with command options:

<OgrConfiguration>
  <ogr2ogrLocation>ogr2ogr</ogr2ogrLocation>
  <!-- <gdalData>...</gdalData> -->
  <formats>
    <Format>
      <ogrFormat>MapInfo File</ogrFormat>
      <formatName>OGR-TAB</formatName>
      <fileExtension>.tab</fileExtension>
    </Format>
    <Format>
      <ogrFormat>MapInfo File</ogrFormat>
      <formatName>OGR-MIF</formatName>
      <fileExtension>.mif</fileExtension>
      <option>-dsco</option>
      <option>FORMAT=MIF</option>
    </Format>
    <Format>
      <ogrFormat>CSV</ogrFormat>
      <formatName>OGR-CSV</formatName>
      <fileExtension>.csv</fileExtension>
      <singleFile>true</singleFile>
      <mimeType>text/csv</mimeType>
    </Format>
    <Format>
      <ogrFormat>KML</ogrFormat>
      <formatName>OGR-KML</formatName>
      <fileExtension>.kml</fileExtension>
      <singleFile>true</singleFile>
      <mimeType>application/vnd.google-earth.kml</mimeType>
    </Format>
  </formats>
</OgrConfiguration>

The current “ogr” module will be split into three bits, a ogr-core, supporting interaction with ogr2ogr and configuration, a ogr-wfs that will contain the current ogr2ogr wfs output format generator, and a ogr-wps that will implement a ogr2ogr based PPIOFactory: the user will then decide which jars to install, if only the ogr-core and ogr-wfs, or also the ogr-wps one.

In order to integrate with WPS a new configuration bit, “type”, will be added, with the following values: “text”, “xml”, “binary” (defaults to binary if not specified). This will allow the PPIOFactory to instantiate the right type of PPIO subclass, BinaryPPIO (binary), CDataPPIO (text), XMLPPIO (xml) to serve the format as a process parameter output. The above example would become:

<OgrConfiguration>
  <ogr2ogrLocation>ogr2ogr</ogr2ogrLocation>
  <!-- <gdalData>...</gdalData> -->
  <formats>
    <Format>
      <ogrFormat>MapInfo File</ogrFormat>
      <formatName>OGR-TAB</formatName>
      <fileExtension>.tab</fileExtension>
      <type>binary</type> <!-- not really required, it’s the default -->
    </Format>
    <Format>
      <ogrFormat>MapInfo File</ogrFormat>
      <formatName>OGR-MIF</formatName>
      <fileExtension>.mif</fileExtension>
      <option>-dsco</option>
      <option>FORMAT=MIF</option>
      <type>binary</type> <!-- not really required, it’s the default -->
    </Format>
    <Format>
      <ogrFormat>CSV</ogrFormat>
      <formatName>OGR-CSV</formatName>
      <fileExtension>.csv</fileExtension>
      <singleFile>true</singleFile>
      <mimeType>text/csv</mimeType>
      <type>text</type>
    </Format>
    <Format>
      <ogrFormat>KML</ogrFormat>
      <formatName>OGR-KML</formatName>
      <fileExtension>.kml</fileExtension>
      <singleFile>true</singleFile>
      <mimeType>application/vnd.google-earth.kml</mimeType>
      <type>xml</type>
    </Format>
  </formats>
</OgrConfiguration>

The implementation will be, for the moment, limited to generated outputs, thus the OGR generated PPIOs will be returning PPIODirection.OUTPUT. Future efforts can remove this limitation and allow the OGR PPIOs to also work on the input side.

Feedback

Backwards Compatibility

No backwards compatibility issues found, the new method to identify the PPIO direction is added to an abstract class with default implementation, the factories are going to be a simple addition that one can decide to implement, or not, and the OGR store configuration will work by assuming a binary format type if none is specified (and the WFS usage will not be affected).

Voting

Project Steering Committee:

  • Alessio Fabiani
  • Andrea Aime +1
  • Ben Caradoc-Davies
  • Christian Mueller
  • Gabriel Roldán
  • Jody Garnett +1
  • Jukka Rahkonen
  • Justin Deoliveira
  • Phil Scadden +0
  • Simone Giannecchini

Links

Clone this wiki locally