Geoanalytics to publish layers in geonetwork update
|Status:||Closed||Start date:||Apr 02, 2019|
|Assignee:||Panagiota Koltsida||% Done:|
|Sprint:||Not necessary, thanks.|
We are testing the feature of geoanalytics platform where when selected by user it publishes the layer and its metadata to the geonetwork.
For this we are using the
We are trying to test in /gcube/devsec/devVRE but it fails with an HTTP 500 response.
In general could you please provide a working with appropriate privileges instance in dev or propose a different scope to test in pre-production? (We also have problems there)
This is important task for geoanalytics as it can trigger users of Aginfra+ project to publish the layers into the catalogue.
#2 Updated by Leonardo Candela 4 months ago
- Sprint changed from UnSprintable to Not necessary, thanks.
- Assignee changed from Leonardo Candela to Roberto Cirillo
- Project changed from gCube to D4Science Support
Just added some colleagues to the discussion and assigning the reply to the ticket to @firstname.lastname@example.org that is currently reshuffling the various infrastructures beyond production. He knows better than me where we are with respect o the deployment of services.
If you are still in development stage than you should look at the dev infrastructure.
To test the entire workflow we need an environment where the geoanalytics is coexisting with the gCube SDI (at least GN should be there).
#3 Updated by Pasquale Pagano 4 months ago
I think that the SDI service should be used to identify the GN instance to use and the way to use it. Fabio can provide additional details. Clearly, the exploitation of this service follows Roberto communication about the availability of the assets either in dev or in pre.
#5 Updated by Fabio Sinibaldi 2 months ago
@email@example.com the library uses the same logic as the sdi-service, so credentials are correctly retrieved from the IS.
@firstname.lastname@example.org I've run some tests in devVRE and I've been able to reproduce HTTP 500 issue while publishing. I'll be investigating on that.
I've also run the same tests in preVRE with no errors, so I'd suggest to use that environment. PreVre should be used in general, since it's a more stable environment (apart from complicated update routines, which are not regular tasks).