GeoSpatial API endpoint doesn’t follow bound request

[emarzini]

We are using the bound of the visible map to filter the geo_shape returned by the relevant endpoint, in order to have spatial data owned by the filtered bound of coordinates.

As example we can consider the following bound:

The request is the following one: https://api.oih.trust-it.it/spatial.geojson?search_text=&facetType=the_geom&facetName=[41.67692194182064,9.540337847974456 TO 43.28937353859965,11.62956931682217]

But seeing the geospatial results returned there are tons of result that not belong to the filter boundaries. As an example we can show one of the results returned (in red) compared with the map bound passed (yellow)

Below the example feature in red

{
    "0": {
        "type": "Feature",
        "properties": {
            "id": "https://raw.githubusercontent.com/iodepo/odis-arch/master/collection/tempHosting/data-wod/wod_mrb_2015.json",
            "geom_length": 102.96567833370581
        },
        "geometry": {
            "type": "Polygon",
            "coordinates": [
                [
                    [
                        -18.920000076293945,
                        25.462005615234375
                    ],
                    [
                        79.747802734375,
                        25.462005615234375
                    ],
                    [
                        79.747802734375,
                        54.900001525878906
                    ],
                    [
                        -18.920000076293945,
                        54.900001525878906
                    ],
                    [
                        -18.920000076293945,
                        25.462005615234375
                    ]
                ]
            ]
        }
    }
}

[jmckenna]

@emarzini there are many problems in the WOD endpoint regarding the bounds of each record (I had reported this to the WOD team before, as those incorrect bounds come from the metadata inside their data product) - can you try with a different partner instead, that has known good coordinates (such as CIOOS, or Pacific Data Hub) ? thanks.

[pieterprovoost]

@jmckenna This query also returns plenty of OBIS features outside the bounding box. Not sure what the problem is, but there doesn't seem to be much difference in the result set with versus without the spatial filter.

[jmckenna]

@pieterprovoost @emarzini I haven't (yet) examined the geometry/bounds of the JSON-LD provided by OBIS - but for the record here is the list of partners that I have been examining & working closely with regarding geometry in JSON-LD: CIOOS, Pacific Data Hub, Research Data Australia, MEDIN. They have made many changes and corrections in the shared geometry inside their JSON-LD. (the same effort, I believe, must be put towards each partner, for geometry validation - or, automated through a validation check & magically emailed to the partner)

@pieterprovoost can we start by examining one problem OBIS result/record here together? (I find it easier to start with one record, than examining why multiple records from a partner have geometry errors)

[pieterprovoost]

@jmckenna This is one of the records, I'm assuming there's an issue is the with coordinates order, are you expecting lat/lon instead of lon/lat? The way the polygon is encoded now corresponds to the WKT notation and the record displays fine on the OIH spatial search map.

[pbuttigieg]

@jmckenna pinging this again - seems there's a communication snafu between the UI and SOLR

[pbuttigieg]

Some of this is from the upstream sources. @fils we'll disable harvested for cases where the source is delivering poor metadata. @jmckenna - SOLR content should track the graph content upstream. If something disappears from the graph, the SOLR cores should delete any corresponding content they have.

The case here is is WOD - we will delist them until the metadata is fixed, thus they should disappear from SOLR and thus the frontend.