Project Activity #5794

Project WP #665: WP7 - Supporting Blue Environment: VREs Development [Months: 7-30]

Project Task #666: T7.1 Aquaculture Atlas Generation VRE [Months: 7-30]

Project Activity #3189: 7.1.6 Vizualisation of data (EO + aquaculture features) with EODA portal

Publish new Geoserver workspace "aaps" in support of 'AquacultureAtlasGeneration' VRE

Added by Emmanuel Blondel about 3 years ago. Updated almost 3 years ago.

Status:ClosedStart date:Nov 17, 2016
Priority:HighDue date:
Assignee:Fabio Sinibaldi% Done:




As discussed with CLS, a geoserver workspace is needed (to be created manually in Geoserver), in support of the 'AquacultureAtlasGeneration' VRE:

  • to be done in both development and production
  • name of the workspace: aaps
  • All WMS operations should be supported and accessible to outside (GetCapabilities, GetMap, GetFeatureInfo, GetLegendGraphic). Other service/operations (e.g. WFS) may be enabled later on request.

As options (if the D4Science Geoserver version supports GetCapabilities description by workspace - to check -), to add the following descriptions in the WMS admin page:

  • Maintainer: i-Marine/BlueBridge Aquaculture Atlas Generation VRE maintainers
  • Online Reosurce:
  • Title: Geoserver WMS of the Aquaculture Atlas Production System (AAPS)
  • Description: This Geoserver WMS provides all layers of the Aquaculture Atlas Production System (AAPS) for the i-Marine/BlueBridge Aquaculture Atlas Generation VRE

Description could be refined later on request.

I let you assign the right people.

Related issues

Related to BlueBRIDGE - Project Activity #5828: Evaluate feasibly to publish Spatialite layer in GeoServe... Closed Dec 02, 2016


#1 Updated by Pasquale Pagano about 3 years ago

  • Sprint changed from Unsprintable to WP07
  • Priority changed from Normal to High
  • Assignee set to Fabio Sinibaldi
  • Tracker changed from Support to Project Activity

For the development infrastructure, it should not be an issue since GeoServer is already in the context. could you setup the new workspace.

For the production VRE, please add the production Geoservers to the VRE first and then Fabio will create the new workspace. In this case, I think that the same workspace can be shared through different GeoServer instances. If possible we should do it since we usually assign to a VRE a cluster of Geoserver instances and not just a single instance.

#2 Updated by Fabio Sinibaldi about 3 years ago

I've set up the workspace in dev environment. It seems that it's possible to define per-workspace information. Please check them and let me know if they're correct now.

About the production VRE:
- if we want to enable SDI features in this VRE we're gonna need also geonetwork and all required IS resources
- AFAIK Geoservers don't share workspaces : if we want it to be available on all gs instances, we need to recreate it on each one.

#3 Updated by Emmanuel Blondel almost 3 years ago

  • % Done changed from 0 to 50

Thanks for the follow-up.

  • About WMS Admin and workspace-specific description
    Indeed, it's possible to define it, but as i was suspecting, your Geoserver version does not persist this textual information it in the GetCapabilities (an issue we had in the past in FAO, probably in bug in Geoserver). Not blocking for this task, but indeed it could be useful to have proper GetCapabilities description given for specific workspace (unfortunately only an Geoserver upgrade could solve this).

  • About WMS GetCapabilities, for CLS:

  • see this WMS GetCapabilities:

  • For now, of course there are no layers, but all layers that will be published will be part of this workspace-specific GetCapabilities document.

  • by default you inherit all Coordinate Reference Systems (CRS) supported in Geoserver. List is very long, if you know which CRS you need to use, we can restraint the GetCapabilities to this list. If yes, please give us the list (EPSG codes if you know them), and we will ask CNR to apply it.

  • About the geoserver cluster, for CNR:
    I don't know the architectural details of the GeoServer clusters you have set-up, but if the latter is made of a single Geoserver data directory shared between multiple Geoserver application instances, then the same workspace can be shared since it is defined as XML configuration file & part of the Geoserver data dir (Consider the workspace is one geoserver "resource" among others). Hope this helps

  • About Geonetwork:
    I take note. Can you remind us the link of D4science de geonetwork that could be used? Thanks

#4 Updated by Fabio Sinibaldi almost 3 years ago

Thanks Emmanuel for the Geoserver hint.
This is the current development instance of Geonetwork : .
Please, keep in mind that it might change (not in a short term).
To check this information you can access the development portal's monitor at

#5 Updated by Fabio Sinibaldi almost 3 years ago

About production environment, we can proceed in different ways depending on your needs.

If you don't plan to use our spatial data libraries to publish your data, we can consider providing an updated and dedicated version of Geoserver.
About metadata and the use of Geonetwork, we're gonna add the official to the scope.
In order to interact with Geonetwork, we strongly encourage you to use our libraries at least for gathering authentication information from IS, otherwise your metadata won't be managed by our other SDI features such as geoexplorer & CKAN.

#6 Updated by Emmanuel Blondel almost 3 years ago

  • Status changed from New to In Progress

#7 Updated by Emmanuel Blondel almost 3 years ago

  • Related to Project Activity #5828: Evaluate feasibly to publish Spatialite layer in GeoServer with existing tools added

#8 Updated by Emmanuel Blondel almost 3 years ago

  • Status changed from In Progress to Paused

Hold on for this, see #5828

#9 Updated by Emmanuel Blondel almost 3 years ago

  • Status changed from Paused to In Progress

Hi i've already reproduced the above task with the new GeoServer instance you prepared for CLS in #5828 / #5880. That is the workspace is in place, and i've also filled the WMS/WFS Service information, So once you will prepare the production instance, you can replicate the same information.

To CLS (, ), you have now:
* a separate Geoserver application - latest release 2.10 - (as indicated in #5828, required to support the spatialite extension)
* an explicit workspace with its instance of WMS/WFS Service (with appropriate information for the AAPS)

I'm now waiting CNR feedback to have access to the geoserver data dir (see #5828) to test the spatialite extension, starting with a manual datastore/layer publication, after what similar test could be done with you for programatic publication.

#10 Updated by Nicolas Longépé almost 3 years ago

Great, looking forward to test the programatic publication

#11 Updated by Emmanuel Blondel almost 3 years ago i would suggest to close this ticket bound to TEST & dev activities. New tickets related to Geoserver exploitation may come so so it's maybe better to have a master ticket later to takle all tasks required for moving in production. Let me know what you think

#12 Updated by Fabio Sinibaldi almost 3 years ago

Hi, does this mean we can consider this activity completed for development/testing purposes?
It's still not clear to me how you're gonna publish metadata on GeoNetwork. Keep in mind that without such metadata, SDI features such as GeoExplorer portlet won't manage your layers.
It would be possible, however, to manually publish records on CKAN via our portal, but I'm not properly aware of the features in place.
If you need further details on this possibility we can ask

#13 Updated by Emmanuel Blondel almost 3 years ago

For test yes, for this specific ticket. Cataloguing & metadata requirements will come later. It will depend on the data flow requirements and how products are supposed to be discovered & accessed by users. I know that client apps such as Geoexplorer rely on CSW and so data will not be shown there, but for the time being it's not a priority.

When it's time to move to production, a ticket will be raised listing all tasks required. It's also better to close this for KPIs.

#14 Updated by Fabio Sinibaldi almost 3 years ago

  • % Done changed from 50 to 100
  • Status changed from In Progress to Closed

Ok for me.

Also available in: Atom PDF