search

INSPIRE-MIF / helpdesk-geoportal

Community discussion for INSPIRE geoportal topics
11 stars 3 forks source link

Misinterpretation of Spatial Scope information etc in the GUI #213

Open hallinpihlatie opened 2 months ago

hallinpihlatie commented 2 months ago

Unfortunately it seems that the INSPIRE Geoportal isn't showing nor recognizing SpatialScope information correctly.

The filtering according to Spatial Scope coverage isn't showing correct results.

For Finnish datasets in the AU theme all metadata that are shown in category Other should actually be shown in either the National or the Regional category. The correct Spatial Scope key words are included in the metadata.

For example the metadata called "Jämsän kaupungin kiinteistörajat" has the Spatial Scope value Regional, in Finnish Alueellinen, is shown in category Other, and not in category Regional as it should be shown in. See original metadata. The reference to the correct value is made by an Anchor. File identifier: d527c231-0c7f-4ef0-89df-e5a34888caa4

The metadata called "Aluevesien rajat" again includes the keyword "Kansallinen" as a CharacterString, which is the name for "National" in Finnish. File identifier: 2b47e493-bed9-4e91-8636-22f8ac9d94b4

Is this a "bug" already on the list of things to be fixed?

Previously Spatial Scope information was shown as a property (eg. flag for the whole country). It was a useful feature for visually checking if Spatial Scope information was missing. I'm also wondering if you are planning to include this in the GUI the near future?

Kind regards

jescriu commented 2 months ago

Dear @hallinpihlatie, Thanks for spotting. We will analyse this issue and provide a fix if confirmed.

jescriu commented 2 months ago

Dear @hallinpihlatie, Our ICT team confirmed a bug which prevented to classify your 'Jämsän kaupungin kiinteistörajat' (Spatial Scope = Regional) metadata record correctly, which was shown in both, the 'Regional' and 'Other' filters - We will apply the correction to the frontend as soon as we can.

In the case of the 'Aluevesien rajat' metadata record, the problem seems that the corresponding Elastic Search query is unable to get one of the necessary parameters (the 'link' parameter) - See below: image

Probably the reason is that the Spatial Scope keyword is not referenced here with an Anchor enconding, as it was done in the case of the first metadara record.

E.g. also the 'Hallinnolliset aluejaot (vektori)' metadata record (Spatial Scope = National) is using an Anchor encoding and seems correctly classified - See below: image

We will analyse if this is exactly the issue and, if so, our ICT team will provide a fix to accept both types of encodings (using Anchor or CharacterString) in the filter - as it should be as per this page.

jescriu commented 1 month ago

Dear @hallinpihlatie,

We analysed the situation with GeoCat, and the necessary modifications in the system for being able to also capture the CharacterString encoding for the Spatial Scope keyword will require us processing the corresponding values (National / Regional / Other) in all languages of the EU when performing indexation.

I suggest to take advantage of the Spatial Scope code list and provide all metadata records using the Anchor encoding, which will allow to keep a simplified indexation.

hallinpihlatie commented 1 month ago

Dear @jescriu I'm very sorry to hear this as technically also the other kind of xml encoding is correct. It passes metadata validation etc. It requires resources, with the only effect that it will improve the correctness on the INSPIRE Geoportal side. Its not affecting the monitoring results etc. I'm not sure we will be able to prioritise it.

I also see possilble issues with the Achnor encoding. DCAT seems to extract only the link and not the key word itself, which may cause issues when interpreting RDF on the web, without additional efforts. See: https://github.com/SEMICeu/GeoDCAT-AP/issues/134. Is this an unnecessary concern?

jescriu commented 1 month ago

Dear @hallinpihlatie, I see your point. We will evaluate the effort for the mechanism to accept the CharacterString encoding, but I am sure it will not be quick. GeoCat is working in enhancing the Link Checker, which is now the priority. The alternative solution I explained above is available in case you would need a quicker solution for this issue. To automate and speed up this transformation, you may consider leveraging on automated AI tools.