Configuring GeoServer

The alignment has now been defined and can be exported to a GeoServer App-Schema configuration, thanks to the App-Schema plugin for HALE developed by GeoSolutions.

To start the Export Alignment wizard, select File → Export → Alignment... from the menu bar on top.

The export procedure is mostly the same regardless of the alignment in question, so we will go through it only for the alignment with separate mappings for each type.

Choosing an export format

The first step consists in choosing the export format. The wizard screen should look like this:

Export format dialog

The highlighted options in the figure above represent two complementary export approaches:

• App-Schema Configuration: the configuration is saved to one or more files, which must be manually copied / extracted to the right place in the GeoServer data directory. This approach may be preferred during testing, or when a live GeoServer instance is not available or not accessible.
• App-Schema Configuration [Direct Upload]: the configuration is generated and immediately uploaded to GeoServer via its REST API. This approach is more convenient and should generally be preferred.

In the context of this tutorial, we will always do direct uploads, so select the second option (App-Schema Configuration [Direct Upload]) in the list and click on the Next button. Another dialog will appear, asking for the URL of the GeoServer instance we want to publish to:

Enter http://localhost:8083/geoserver in the Target URL field and hit Next.

Including target schema

The next wizard screen is very simple, as it poses a simple question:

If the Include target schema in the archive option is checked, the target schema that was imported in the project at the beginning of the example, including all its dependencies, will be added to the exported archive and uploaded to GeoServer along with the mapping configuration.

This option may be useful when GeoServer is running on a server with no internet connectivity and is thus unable to download the required schemas from the web. However, in general it should be left unchecked, to maximize schema reuse among App-Schema datastores via GeoServer’s centralized App-Schema cache.

Leave the option unchecked, and click Next.

Configuring feature chaining

See this introductory part for detailed information about how feature chaining works.

If the alignment defines at least one Join relation, the wizard will now ask us to configure feature chaining. Basically, we will provide here the missing configuration bits, that could not be specified in the Join definition and that are actually needed by GeoServer to properly nest the joined types. Even if the Join involved more than two types, feature chaining is always configured pair-wise.

We will be presented with one configuration dialog for each join condition that we defined. The first dialog is shown in the figure below:

Feature chaining configuration for meteo_stations and meteo_observations

The upper part of the dialog contains a read-only table displaying the current configuration, while the bottom part contains a schema explorer view, showing all the properties of the target type of the whole Join relation, and, further down, a checkbox.

We will forget about the checkbox for now, as it is not relevant for this example, and focus on the table and the schema explorer view.

The table is composed of four columns:

• Source Type: the name of the source type we are chaining / joining.
• Role: specifies whether the source type should be nested into the other, or viceversa. The role is determined from the join order and cannot be modified: the join type in the condition has always the NESTED role, while the base type has always the CONTAINER role.
• Join Property: the property that is checked for equality.
• Target Type: the source type will be mapped to this type, i.e. a feature type mapping for it will be created in the App-Schema configuration.

As the dialog is opened the first time, all cells in the table are filled automatically, except the nested type’s target: that is what we will select in the schema explorer view. Navigate to the Station/observation/Observation property and click on it: the Target Type column in the second table row will be populated with the value Observation, as shown in the figure above. In this way, we are telling GeoServer two things:

1. the meteo_observations source type should be mapped to the Observation type; this is crucial in the single-join approach, but actually redundant here, as the Retype relation meteo_observations → Observation conveys the same information already;
2. Observation instances should be nested under the observation attribute of the Station type.

Leave the Generate unique mapping for nested target type checkbox unchecked, and hit Next.

The second feature chaining configuration dialog will appear. Select the Observation/parameter/Parameter property in the schema explorer view and the dialog should now look like the figure below:

Feature chaining configuration for meteo_observations and meteo_parameters

In this way, we are telling GeoServer both that the meteo_parameters source type should be mapped to the Parameter type (again, redundant in this particular case), and that Parameter instances should be nested under the parameter attribute of the Observation type.

Leave the Generate unique mapping for nested target type checkbox unchecked, and hit Next.

The third feature chaining configuration dialog will appear. Select the Station/contactMail property in the schema explorer view and the dialog should now look like the figure below:

Feature chaining configuration for meteo_contact_mail and meteo_stations using cardinality 1..n

A Configure Workspaces wizard windows will appear, it is useful for making a workspace isolated on Geoserver. On this case let the default configuration and click on *Next button.

Hit Next to proceed to the DataStore configuration screen.

Configuring the DataStore

On this wizard page, you must enter the DataStore configuration parameters.

Note

Although the GeoServer App-Schema extension supports a variety of data store types and multiple data store configurations, the HALE App-Schema plugin only allows to configure a single PostGIS data store. This limitation will likely be removed (or at least alleviated) in future releases of the plugin.

Select the database type, on this case Relational Database:

Fill the database connection fields:

The database password is hale_tutorial. Be sure to check Expose primary keys, or you will get errors where primary key columns are used in attribute mappings.

Clicking on the Next button will take you to the last page in the wizard.

Providing REST credentials

The last wizard page asks you to enter the credentials to access GeoServer’s REST services (see figure below).

Username and password for the local GeoServer instance are respectively admin and Geos.

Click on the Finish button to generate the configuration and upload it to the local GeoServer instance.

Note

Before starting the upload, make sure GeoServer is actually running by visiting the URL http://localhost:8083/geoserver. If it’s not running start it by double clicking on the start_geoserver.bat batch script.

If all goes well, when the upload is finished you should see in the Report List view an App Schema REST export message with a green tick mark icon on its left side.

Visit GeoServer’s Layer Preview page and you should see two new layers in the list, st:Station and st:Observation.

Congratulations, you successfully created a new App-Schema DataStore in GeoServer! In the next section, we will issue a few WFS requests to demonstrate how your data can be queried.