Incident #9721
closed
MPA intersect algorithm issues with ecoregions query
100%
Description
I've tried to performs several queries in "ecoregions" but it seems doesn't work properly:
The query is the following:
GET Request 'https://dataminer-cluster1.d4science.org/wps/WebProcessingService?request=Execute&service=WPS&Version=1.0.0&lang=en-US&Identifier=org.gcube.dataanalysis.wps.statisticalmanager.synchserver.mappedclasses.transducerers.MPA_INTERSECT_V3_2&gcube-token=2a313504-f199-4f92-a563-384d68ce6d5f-843339462&DataInputs=MPA_Shapefile_Url=https%3A%2F%2Fabsences.zip;Marine_Boundary=ECOREGION;Region_Id=Aegean Sea;Selected_Data_Feature=NA' failed!
I've also checked the logs. It seems an XPath problem:
XPath error : Undefined namespace prefix XPath error : Invalid expression Error in xpathApply.XMLInternalDocument(doc, path, fun, ..., namespaces = namespaces, : error evaluating xpath expression //gml:featureMember//gml:coordinates Calls: source ... xpathApply -> xpathApply.XMLInternalDocument -> .Call Execution halted
Please, could you check?
Updated by Roberto Cirillo over 7 years ago
I've used the following portlet:
https://bluebridge.d4science.org/group/protectedareaimpactmaps/mpa-reporting
Updated by Emmanuel Blondel over 7 years ago
- Assignee changed from Emmanuel Blondel to Anonymous
Wrong target component. Is CNR willing to work on Marine Protected Areas? I'm not going to close the ticket, while in this case that should be the most reasonable choice. @debhasish.bhakta@grida.no error highlighted is not about the app but the algorithm for particular values (things that we are already aware of), let me know if you can have a look.
We have yet @levi.westerveld@gmail.com involved on deeping testing on this portlet, so please avoid duplicate efforts, especially on comunity applications, and even more where there are pending work by the community (GRID-ARENDAL), the case here. BTW, if you really want to enter into beta testing and software assessments, please let us know, we can start creating hundreds of tickets related to the "blue commons" and dig more into QA software assessments. However, there are problably activities that deserve that CNR give a particular emphasis, ie where community raised issues or requested support.
Thank for your understanding
Updated by Emmanuel Blondel over 7 years ago
- Subject changed from mpa-reporting portlet doesn't work with ecoregions query to MPA intersect algorithm issues with ecoregions query
Updated by Pasquale Pagano over 7 years ago
Hi @emmanuel.blondel@fao.org, this is not the correct approach to manage issues related to production VREs and I would not have expected this reaction from you.
Any time we deploy a new release we have to verify that all the environments works as expected. In this particular case, you are right saying that the issue was observed in the past but we don't know if it was expected to be resolved with this release. The fact that the user interface allows to submit a request by selecting specific parameters through the interface suggests that the fix was implemented. An advice on the interface would have avoided this issue.
As far as Blue Commons, if you have identified issues please open as many tickets as needed.
As far as the management of the effort of the technical team, this is something that is managed by myself and by Blue Commons and criticisms are clearly appreciated but should be raised in a different context, as the Tcom for example.
Updated by Massimiliano Assante over 7 years ago
Emmanuel, sarcasm is hard to detect and tough to convey in written messages, a misplaced sentence could easily change a neutral–sounding email into a thinly-veiled attack, which I am sure is not your intention. May I suggest you to re-read your posted message?
The purpose of this incident was to (help) let you know that your algorithm for particular values wouldn't work. We had no idea you were already aware of it and we are in no doubt that you all are hard working to make MPA better and better.
Is there a ticket (task) stating that this algorithm for particular values doesn't work? If so, please link the ticket to this incident and close it. If not, please create one, link it to this ticket and close the incident.
Updated by Emmanuel Blondel over 7 years ago
Dear Lino, If the scope is a gcube release, then the testing should bind to scope of gcube components. Here the component highlighted is the portlet, the container, which is a generic one, and their tests should be bound to what the component is aimed to.
Tests for this generic portlet are as follow:
- allow to configure a website application through the Liferay configuration panel
- allow to configure a URL token application parameter through the Lieferay configuration panel
- the application should be displayed once the portlet is reloaded (functional iframe)
- an application invoking a gcube token based service within the portlet (e.g. MPA application) is working.
If QA tests have to be performed on the "PublicWebappPortlet" component (mpa-reporting is an instance of it), IMHO they should be be bound to that container and its features, not the content. In the case of MPA webapp, without doing execution tests (backed by Dataminer), your team may be able to check quickly since the MPA web-app will start by inheriting user profile through social-network service based on token and this is reported as javascript log and available if you open chrome dev console.
Your team is also welcome to create improvement requests for this portlet (i'm still talking of the gcube portlet container), or even to contribute directly it (I know that @massimiliano.assante@isti.cnr.it had already pointed out some wicknesses to tackle in the past).
MPA application (not the portlet container, but the content) is out of gcube release and built by community, and data are in a continuous process to be improved. Levi (and also Anton) already reported issues dealing with data, and these are being tackled by GRID-ARENDAL. I suppose that these tests are targeting the gcube components, not the thematic web-apps, nor every single data stream. Of course in this context it would not make sense to create a ticket for each execution param attempted, while the issue would be a common one.
Hope this clarifies,
Kind regards
Updated by Emmanuel Blondel over 7 years ago
Hi @massimiliano.assante@isti.cnr.it creating incidents on rush is not appropriate, hence my rush answer, although we all tempt to try to use this ticketing system. For future testing dealing with an thematic application and their data streams, it's better to liaise with people involved, and ask them "is it normal?", and your help you will be much appreciated. I think we were advised in several occasions by Lino to use social-networking instead or even messaging, we are trying to, and it would be a better place to ask about unexpected data & thematic app issues when it is known that they are ongoing activities on it.
The log reported deals with a WFS data fetching issue, which unfortunately in geoserver occurs unexpectedly sometimes, and in this case Data is being improved and updated, so WFS data fetching may be naturally impacted.
@debhasish.bhakta@grida.no can you please inspect the R process and logs, and see which feature fetching is failing.
Thanks
