Project Activity #5794
Project WP #665: WP7 - Supporting Blue Environment: VREs Development [Months: 7-30]
|Status:||Closed||Start date:||Nov 17, 2016|
|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:
- 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:
i-Marine/BlueBridge Aquaculture Atlas Generation VRE maintainers
- Online Reosurce:
Geoserver WMS of the Aquaculture Atlas Production System (AAPS)
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.
#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. @firstname.lastname@example.org could you setup the new workspace.
For the production VRE, @email@example.com 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:
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
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 : http://geoserver-dev2.d4science-ii.research-infrastructures.eu/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 https://next.d4science.org/infrastructure-monitor
#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 geonetwork.d4science.org 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.
#9 Updated by Emmanuel Blondel almost 3 years ago
- Status changed from Paused to In Progress
Hi @firstname.lastname@example.org 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 (@email@example.com, @firstname.lastname@example.org ), you have now:
* a separate Geoserver application - latest release 2.10 - https://geoserver1-spatial-dev.d4science.org/geoserver (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.
#11 Updated by Emmanuel Blondel almost 3 years ago
@email@example.com 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 @firstname.lastname@example.org, 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 @email@example.com.
#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.