StocksAndFisheriesKB

Not sure which geoservice you used for that, but if you used the simple one (with geometry strings as inputs), it doesn't expect a geojson string but a simple string "minx,miny,maxx,maxy" eg -180,-90,180,90

If you can send me the inputs you used for the algorithm i'll start from there.

Thanks

We are using the following service:

• SERVICE_ENDPOINT="http://dataminer-prototypes.d4science.org/wps/WebProcessingService";
• SERVICE_WPS="WPS";
• SERVICE_UNION_IDENTIFIER="org.gcube.dataanalysis.wps.statisticalmanager.synchserver.mappedclasses.transducerers.GEOGRSF_BBOXUNION";

The particular call that fails is the following:
http://dataminer-prototypes.d4science.org/wps/WebProcessingService?request=Execute&service=WPS&Version=1.0.0&gcube-token=****&lang=en-US&Identifier=org.gcube.dataanalysis.wps.statisticalmanager.synchserver.mappedclasses.transducerers.GEOGRSF_BBOXUNION&DataInputs=geom1%3D%7B%27type%27%3A%27Polygon%27%2C%27coordinates%27%3A%5B%5B%5B-11%2C61.9959%5D%2C%5B-11%2C89.99%5D%2C%5B68.5%2C89.99%5D%2C%5B68.5%2C61.9959%5D%2C%5B-11%2C61.9959%5D%5D%5D%7D%3Bgeom2%3D%7B%27type%27%3A%27Polygon%27%2C%27coordinates%27%3A%5B%5B%5B-12.1%2C60.5%5D%2C%5B-12.1%2C85.1%5D%2C%5B69.1%2C85.1%5D%2C%5B69.1%2C60.5%5D%2C%5B-12.1%2C60.5%5D%5D%5D%7D

This is the first time the above is failing (we've used it for more than 100 merges so far)

Ok i was looking at intersect service, sorry. Indeed this service has nothing special and should work. I look at it right now.

Dear colleagues, let me step in as I feel I miss some knowledge here.
Let's take the case a FIRMS (sourced) stock record is asked to be merged with a FishSource stock record.
FIRMS record is "dominant" therefore the species and area codes are retained in the new merged records.

If the above is clear, why do we need to compute union of bounding boxes?

(I am surely missing something for which I say thank you in advance for your clarifications.)

Your comment is correct, However I see that is is part of the agreed merging workflow (documented in https://support.d4science.org/projects/stocksandfisherieskb/wiki/18-11-16-GRSF_validation#Union-of-Polygons-bboxes-in-case-of-merge-records).

Let me know if you wish to change that and stick to the polygon of the dominant record.

Thanks @marketak@ics.forth.gr , and thanks for having found the relevant discussion on this matter.

I suspect that both replies (combine/not combine bboxes) will raise issues in any case.
But I think you are already applying the logic of the dominant record for building the semantic identifiers and other identity metadata in the GRSF record.
So it would make sense to apply the same logic to the geospatial coordinates, i.e. inherit only those from the dominant record and ignore the others.

As we do not know today if for any case it is better to join, do you think is viable to keep both and for the time being return to the record only the dominant one and not the combination?
Do you see any issue or overwhelming complexity?

Thank you both for your answers.

@aureliano.gentile@fao.org the rationale behind the union of polygons was decided before proposing the dominant record, and that's the reason for having it in place in the merging workflow. I am OK with your suggestion (about using the polygon of the dominant record (if it exists). I'll just have to do some small modifications in the workflow.

With many thanks, we keep going learning in this process...

So, @emmanuel.blondel1@gmail.com feel free to close this issue and postpone the updates. We'll move on using the polygon of the dominant record instead of calculating the union.