v22.0 comes with a new web application called
datafeeder, which aims
to facilitate the integration of datasets into the infrastructure, via a web wizard:
- the dataset is sent to the backend
- the user types in some infos
- the dataset is loaded into a postGIS database
- a layer is created into a geoserver workspace
- a Metadata is created into geonetwork
During the process, emails are sent to the user, depending on the status of the import.
For now, the service only supports ZIPped shapefiles, but could allow other formats to be uploaded in the future.
Technically, the web service is split into 2 web applications:
- a backend, commonly available under
- a web user interface, commonly available under
The second one is actually triggering calls to the first one, both being behind the security-proxy.
- The code for the backend is located into the official geOrchestra repository.
- The web ui code has its own separated repository.
A maven module has been created into the main geOrchestra repository, so that we can generate a webapp out of the UI source code.
Depending on the deployment approach being used, the artifacts for the web user interface do not have the same nature:
- the docker image is a simple nginx one serving static assets of the UI
- the webapp generated from the
datafeeder-uimaven module is basically a spring based web application which mimics what the previous nginx configuration does.
The datafeeder does not need specific components to run, apart from the ones geOrchestra already relies on:
- a postGreSQL/PostGIS database
The configuration can be found into the geOrchestra datadir, in the dedicated directory.
The datafeeder will also require a correctly configured GEMET thesaurus inside GeoNetwork. Make sure that the thesaurus URL set in the configuration can be queried.
The datafeeder will make use of 2 database connections:
- the first one is meant to keep track of the imported datasets via the user interactions ; see here for the relevant configuration. By default this targets the
datafeederschema from the
- the second one is meant to store the geographical data being imported ; relevant config here. Any PostGIS-enabled database is suitable, though we advise to use a fresh one, rather than a shared database (due to potential collision of schemas' names).