Proposal #8: improve shp2pg action

The Shp2pg action permits to copy a shapefile to postgis spatial table, but is currently quite limited in its functionality. It surely needs some refactoring to clean up the code, add some testing and generalize it a bit.

Proposal

We propose to generalize the action so that both the source and the destination of the copy can be any GeoTools datastore (shapefiles, jdbc databases, etc.). For clarity we think it's better to rename the action to ds2ds (or create a new one with this name and deprecate the old one). The generalization shoulde be very simple to obtain, building both datastores from a set of Geotools connection parameters.

Notice that the GeoServer publishing functionality should be removed, as a specific action already exists for that.

The generalization permits to easily introduce tests for the action, using shapefiles and embedded (H2) databases to avoid the necessity of an online postgis database.

The action should be used for appending or replacing existing data, so a flag will be added in configuration to specify the desired mode.

The input event should be a file (in XML format) specifying the DataStore connection parameters, as in the following example:

<feature>
	<dataStore>			
		<parameters>
			<entry>
				<string>host</string>
				<string>localhost</string>
			</entry>
			<entry>
				<string>port</string>
				<string>5432</string>
			</entry>
			<entry>
				<string>database</string>
				<string>test</string>
			</entry>
			<entry>
				<string>schema</string>
				<string>public</string>
			</entry>
			<entry>
				<string>user</string>
				<string>postgres</string>
			</entry>
			<entry>
				<string>password</string>
				<string>mypassword</string>
			</entry>
		</parameters>
	</dataStore>
	<typeName>poi</typeName>
</feature>

To simplify things we will also support database files (directly or as a zip) as input for some datastore types (such as shapefiles), recognizing if the file is in a known format (e.g. zip, shp) or an xml and proceed accordingly.

Some simple parameters should be configurable (in input XML or directly in flow configuration), such as:

• sourceCRS
• destinationCRS Some simple processing should be configurable too:
• output feature renaming
• attributes projection / renaming

Finally the action should be chainable (now it's not), so we need to produce an output event. This event will be a file (an XML file), similar to the one used as an input event, with data of the output feature produced.

Additional Development

As a plus, advanced processing of some sort could be specified on input, such as:

• attributes mapping
• filtering
• geometry transformations (e.g. clipping)
• using a geotools process
• reprojecting

These too could be specified in the flow configuration, or in the input XML.

Roadmap

• First revision: will contain all the basic features, as described in the Proposal section, and will be released shortly (see issue #122).
• Second revision: will contain advanced features, as described in the Additional Development section and will be released in a second time (see issue #123)

Related Issues

Created from issue #122 Additional development in issue #123