Project Activity #7578
Discovery, Access & geovisualization of CLS Spatialite WMS/WFS in AAPS VRE
|Status:||Rejected||Start date:||Mar 17, 2017|
|Assignee:||Manuel Goacolou||% Done:|
This ticket should handle tasks to move forward and provide geo-visualization capacities for the AAPS VRE & CLS Spatialite data. I let you assign this activity to the right people. For your convenience, i give some possible scenarios to move forward. Suggestions/Objections from other partners are more than welcome
Scenario 1 - Maps discovery, access & geoVisualization through WMS GetCapabilities
This scenario doesn't require creation/publication of GIS metadata to reference the layer products at all in a metadata catalogue (CSW). You can stick with publish data as WMS/WFS (with possible customization of map styles if you need it). Geovisualization is relying on GetCapabilities files to discover, access and visualize the maps. A basic static web-app map viewer can do this job, and be plugged in the VRE.
The python script is appropriate for publishing this.
** Scenario 2 - Maps discovery, access through CSW (GIS metadata) & geovisualization**
This scenario requires that you create & publish metadata in a metadata catalogue together with your WMS layers (generally this is the best practice). ANd use a CSW client for browsing and visualizing the maps (e.g. Geonetwork embedded map viewer, gCube GeoExplorer, custom web-GIS app). Passing through metadata to do implement a geo-visualization is not absolutely required, but it should be an "horizon".
Here the Python script I provided doesn't allow that, and i'm not aware of any ISO19139 metadata generator in Python, nor Python publisher to Geonetwork.
They are several cases that you can consider:
- Scenario 2A Do your Spatialite publication in other language that has good support for Geoserver publication, ISO19139 metadata creation & GeoNetwork publication:
- Scenario 2A1 Python has poor support for these 3 operation needs
- Scenario 2A2 Java has good support for this, respectively: geoserver-manager, ApacheSIS/Geotoolkit for metadata generation, and geonetwork manager (or better here: the gCube Geoserver interface that builds on these 3 components)
Scenario 2A3 R has partial (but growing) support: geosapi (operational, released), geometa (under development), geonapi (development not yet started)
Scenario 2B Rely on gCube planned service to deliver Metadata templating tool, and gCube Geoserver Interface as REST API.
Accordingly, you are free to keep using Python, invoke gCube service to build template and publish metadata. AFAIK and IMHO, the constraint here is the timeframe.
My 2 cents: if this activity has to be carried out ASAP (which seems to be the case), i would suggest to go for scenario 1, and keep vision to go towards scenario 2 as iterative approach (2B, 2A2 or 2A3) depending on your needs, preferences, allocable effort and availability/status of the above mentioned technologies.
Hope this helps.
#3 Updated by Pasquale Pagano over 2 years ago
- Priority changed from Normal to High
Thanks for this ticket that is very clear and propositive.
I need to add the context, i.e. the project that is paying for this effort. I have to remember any of you that scenario 1 cannot be accepted. All the data that are managed by the infrastructure have to indexed by a catalogue. For geospatial data this catalogue is GeoNetwork. So metadata in standard ISO19139 format has to be produced and stored in GN.
Then they will be harvested and made available in the infrastructure common catalogue.
So, Scenario 2 is the only one feasible. I cannot impose any possible implementation based on Java, R, Python. However, I have to remember you that this use case is in delay and you need to move forward to be in line with expectations and project contract. Please clarify the approach you will follow and according to your choice we will support you as best as we can.
#4 Updated by Emmanuel Blondel over 2 years ago
On my side, on technical support, i take note that you say ISO 19139 is mandatory and use of CSW catalogue (through Geonetwork) is also mandatory according to project contract. This is #7579 work, and pre-requisite for this activity. I suppose then that this activity is not isolated, and many other VRE similar needs are then also in delay (e.g. TunaAtlas meta(data) publication?). If i'm requested to provide support on #7579, BTW it will have to be done with the technology available and according to requirements. If Python use is a requirement, i will take it as it is, anyway programming interface is a detail. I don't pretend changing the requirements i receive as pre-requisite. Publication will have to be done either through Geonetwork API, or through templating tool & wrapper gcube REST interface to the latter, as born and presented by CNR at last Tcom. AFAIK, the latter is not yet available, isn't it? Thanks in advance to give us a clear timeframe indication if/when we can start using it, otherwise the only way will be to stick with third-party technology and the "native" APIs.
#5 Updated by Pasquale Pagano over 2 years ago
The ticket is assigned to @email@example.com and clearly I was referring to him.
As far as the REST interface presented by Fabio (he is in copy and can report additional information) is an activity just started and we plan to deliver it in June. However, Java libraries are available since ever and we have started the implementation of the REST service to simplify the interaction with the infra of the non-native Java sources. So, stick with third-party technology and the "native" APIs is not the only solution. We recommend to use the gCube Java libraries until the new REST service will become available. Clearly, the provider can choose a different solution but we can provide support only for Java client until the new REST service will become available.