GeoServer Complex-Feature WFS Configuration: Directory Structure

At present, there is no user-interface component that helps you configure a complex-feature WFS in GeoServer. I'm sure that it is being worked on, but in the meantime, the configuration is done manually, by building the appropriate directory structure and putting XML configuration files in the right places.

This is an example of the directory structure that has to be in place.

The directory geoserver\data\workspaces contains a folder for each workspace that you use in your GeoServer installation. For a GeoSciML complex-feature WFS, you'll want to set up a new workspace. You can actually do this through the admin interface, but you can also create it by making a gsml folder and including two simple XML documents there. I've uploaded examples of these two documents and described them: namespace.xml (GeoServer Namespace Configuration) and workspace.xml (GeoServer Workspace Configuration).

Also within the gsml workspace directory is a folder for each datastore that exists under that workspace, in this case, a gsml_GeologicUnit and a gsml_MappedFeature datastore. In the GeoSciML case, think of each datastore as a featuretype that you want to serve, or to be available for queires. The names of these folders are arbitrary, but represent GeoServer's internal identifier for that datastore/featuretype.

In order for the gsml_GeologicUnit folder to be recognized by GeoServer as a datastore, it must contain a file called datastore.xml. For datastores created by the admin interface, this XML document contains information about the datasource itself - is it shapefiles? What directory are they in? Is the datasource a PosgreSQL + PostGIS database? What are the connection parameters?

However for our complex-feature service, this is where we implement the app-schema extension. Instead of putting all the data connection information here, we instead point to the other file in this directory: gsml_GeologicUnit.xml, and let GeoServer know that we are using the app-schema extension. An example of the datastore.xml document is at the page: GeoServer DataStore Configuration for Complex Features.

All the magic happens in the file gsml_GeologicUnit.xml, which is called a "Mapping File". This XML document contains the data connection information that we omitted from the datastore.xml, and then defines the mapping from the source data itself into the complex schema that you want to serve, in this case GeoSciML. I'll put up an example of this document very soon.

Finally, within geoserver\data\gsml\gsml_GeologicUnit\gsml_GeologicUnit is a file called "featuretype.xml". This file must be there in order for GeoServer to understand that the featuretype we're creating should be available for WFS requests. This document is relatively simple, and contains mostly information that will later appear in the GetCapabilities response on your WFS. Here is an example: GeoServer FeatureType Configuration