Check SGU minerals service for INSPIRE compliance about project-support-wp8

[nmtoken]

Another issue is reported as:

A BoundingBox is provided for non existing CRS either in the layer itself nor in a parent layer.

but as far as I can see, that's incorrect, there are 20 reported CRS and 20 BBOX (for the same CRS)

Reported CRS are (sorted for easy comparison):

<CRS>EPSG:2400</CRS>
<CRS>EPSG:3006</CRS>
<CRS>EPSG:3007</CRS>
<CRS>EPSG:3008</CRS>
<CRS>EPSG:3009</CRS>
<CRS>EPSG:3010</CRS>
<CRS>EPSG:3011</CRS>
<CRS>EPSG:3012</CRS>
<CRS>EPSG:3013</CRS>
<CRS>EPSG:3014</CRS>
<CRS>EPSG:3015</CRS>
<CRS>EPSG:3016</CRS>
<CRS>EPSG:3017</CRS>
<CRS>EPSG:3018</CRS>
<CRS>EPSG:3021</CRS>
<CRS>EPSG:3857</CRS>
<CRS>EPSG:4258</CRS>
<CRS>EPSG:4326</CRS>
<CRS>EPSG:900913</CRS>
<CRS>CRS:84</CRS>

Reported BBOXs are:

<BoundingBox CRS="EPSG:2400" minx="6137390.6797204185" miny="1208297.4237487656" maxx="7675562.557708611" maxy="2025251.7699124748"/>
<BoundingBox CRS="EPSG:3006" minx="6135770.452929046" miny="259684.0050077687" maxx="7677837.391538707" maxy="1076143.5974246587"/>
<BoundingBox CRS="EPSG:3007" minx="6138395.009631221" miny="99751.39456478368" maxx="7701645.20487165" maxy="915411.7167689488"/>
<BoundingBox CRS="EPSG:3008" minx="6138118.403613457" miny="4651.968066317902" maxx="7690546.184811202" maxy="820978.3164638255"/>
<BoundingBox CRS="EPSG:3009" minx="6138225.743226336" miny="-90412.15985617373" maxx="7680909.755440882" maxy="726374.147083492"/>
<BoundingBox CRS="EPSG:3010" minx="6138558.7508550035" miny="-185417.6649788171" maxx="7672737.569950899" maxy="631625.1457019188"/>
<BoundingBox CRS="EPSG:3011" minx="6138163.097969501" miny="-280340.88585896493" maxx="7668929.117860458" maxy="536756.4346571134"/>
<BoundingBox CRS="EPSG:3012" minx="6138124.080493759" miny="-42885.9596441286" maxx="7685545.035969097" maxy="773695.9361468436"/>
<BoundingBox CRS="EPSG:3013" minx="6138136.137185056" miny="-137923.70963645558" maxx="7676640.540384196" maxy="679016.1627480525"/>
<BoundingBox CRS="EPSG:3014" minx="6138183.956004276" miny="-232891.05662195355" maxx="7669201.00587983" maxy="584204.2118458112"/>
<BoundingBox CRS="EPSG:3015" minx="6138615.728403173" miny="-327764.1203374828" maxx="7672435.834097797" maxy="489284.849413655"/>
<BoundingBox CRS="EPSG:3016" minx="6138199.286045368" miny="-422518.4821062682" maxx="7680548.3625816945" maxy="394282.23013459955"/>
<BoundingBox CRS="EPSG:3017" minx="6138128.0635218965" miny="-517129.04988239426" maxx="7690125.19601949" maxy="299220.03201897285"/>
<BoundingBox CRS="EPSG:3018" minx="6138440.787800478" miny="-611569.9224352842" maxx="7701164.693364408" maxy="204121.59041181763"/>
<BoundingBox CRS="EPSG:3021" minx="6137390.6797204185" miny="1208297.4237487656" maxx="7675562.557708611" maxy="2025251.7699124748"/>
<BoundingBox CRS="EPSG:3857" minx="1247616.6541505074" miny="7433459.945171671" maxx="2683195.04054296" maxy="1.0740908824518066E7"/>
<BoundingBox CRS="EPSG:4326" minx="55.3671957158819" miny="11.2075310914546" maxx="68.9681779468207" maxy="24.1035511519344"/>
<BoundingBox CRS="EPSG:4258" minx="55.3671957158819" miny="11.2075310914546" maxx="68.9681779468207" maxy="24.1035511519344"/>
<BoundingBox CRS="EPSG:900913" minx="1247616.6541505074" miny="7433459.945171671" maxx="2683195.04054296" maxy="1.0740908824518066E7"/>
<BoundingBox CRS="CRS:84" minx="11.2075310914546" miny="55.3671957158819" maxx="24.1035511519344" maxy="68.9681779468207"/>

-- UPDATE --

This is a genuine error see:

https://github.com/inspire-eu-validation/community/issues/252

EPSG:3034 needs adding to the list of CRS supported.

[nmtoken]

Next reported issue, is interesting (a test of the optional transparent parameter)

https://maps3.sgu.se/geoserver/inspire/ows?BBOX=11.2075310914546%2C55.3671957158819%2C24.1035511519344%2C68.9681779468207&CRS=CRS%3A84&FORMAT=image%2Fpng&HEIGHT=500&LAYERS=MR.SGU.MineralResources&REQUEST=GetMap&SERVICE=WMS&STYLES=&TRANSPARENT=true&VERSION=1.3.0&WIDTH=500

So same layer as above was used to test, and fails because of this, but funnily enough strictly the test should fail, because an invalid parameter value is sent (values are case sensitive and the allowed values for transparent are (TRUE|FALSE) but the test request uses true

-- UPDATE --

This is a validator error see: https://github.com/inspire-eu-validation/community/issues/250

[nmtoken]

[1] WMS GetCapabilities is schema valid

[2] MetadataURL points to invalid resource

https://www.geodata.se/geodataportalen/srv/en/csw-inspire?request=GetRecordById&service=CSW&version=2.0.2&elementSetName=full&id=fdc2a96a-530b-4d51-8158-a81dc520438d&outputSchema=csw:IsoRecord

[3] Minerals Commodity legend(s) looks correct

[4] Mineral Occurrence Type symbols, you have coloured diamonds, but to be aware that ERML working group proposal is to use clear symbols:

and for (Mine) status in the MineView the current proposal is one of three black/white symbols (glyphs)

... WIP

[tomlind]

Thanks for checking!
I suspect our national metadata catalog is having some problems. I did not get a response using the URL above early this morning but it seems to be working now without any action from me. Could you please try again?

[nmtoken]

Working for me now (I get a record) but previously I got a response but no record.

[auretepereira]

Are you using the INSPIRE validator for validate the service? http://inspire.ec.europa.eu/validator/

[nmtoken]

@auretepereira not yet

[nmtoken]

So for the WMS 1.3 test only the INSPIRE validator fails the service, we should note that this might reflect issues in the validator (which is in beta) rather than the WMS.

One issue is a test that was expecting an exception response, when a request is sent without a mandatory parameter (in this case request=GetCapabilities); though possibly this is a little harsh because the response is actually the GetCapabilities response.

I think I understand how this has occurred ~ there's a static file at the GetCapabilities endpoint, so whatever parameters are given you always get a response, and the service itself is perfectly functional.

[nmtoken]

Next reported failure is:

A layer's Identifier has a non unique value for its authority.

Where the authority is:

<Identifier authority="SGU">

Well I agree it's possible that SGU as an authority might be a duplication across INSPIRE authorities, I'm not sure if that's what's being tested here

-- UPDATE --

This is looking like a validator error. I'm guessing that validator hasn't paired the identifier in the group layer(s) with the AuthorityURL in the root layer, which is:

<AuthorityURL name="SGU">
    <OnlineResource xlink:type="simple" xlink:href="https://resource.sgu.se"/>
</AuthorityURL>

-- UPDATE 2 --

This issue has been addressed in the validator see: https://github.com/inspire-eu-validation/community/issues/255

[nmtoken]

There's a failure against layer name (even though I only requested a WMS 1.3 test, not INSPIRE themes).

The following layers do not have a correct name according with the harmonised layer names given in the INSPIRE collection: 'MR.SGU.MineralResources, MR.Commodity, MR.CommodityIndustrialMinerals, MR.CommodityBuildingMaterials, MR.CommodityCeramic, MR.CommodityChemicalUse, MR.CommodityPreciousGemstones, MR.CommodityPreciousMetals, MR.CommodityEnergy, MR.CommodityRareMetals, MR.CommodityIronMetals, MR.CommodityBaseMetals, MR.ProcessingPlant, MR.MiningWaste, MR.MiningActivity, MR.MineralOccurence'.

Let's unpick this...

Layers to be provided by INSPIRE view services (from the TG)

MR.Mine

and

MR.MineralOccurrence

So MR.MineralOccurence in the SGU service is incorrect because of spelling (Occurrence not Occurence).

Also the legislation says the title must be Mineral Occurrences so Mineralförekomster (MineralOccurence) is also incorrect here.

There is a MR.Mine layer.

That fulfils the obligations, though if you don't have mines data or had mines data but not occurrences information, it would be interesting how you could provide an INSPIRE service ...

So MR.SGU.MineralResources is the root layer name and not invalid.

Now the fun bit.

Table 6 in the data specification Listed Layers for MR Commodity (so that's a layer that's not required, or even mentioned)

• MR.CommodityBaseMetals
• MR.CommodityIronMetals
• MR.CommodityRareMetals
• MR.CommodityEnergy
  ...

So those are the same layer names that are rejected by the WMS 1.3 validator

and having a group layer MR.Commodity as a container for these seems perfectly allowable (as discussed in the INSPIRE thematic cluster forum).

In summary there is only one valid layer name issue reported here the incorrect spelling of MR.MineralOccurence

[nmtoken]

A genuine error found by the validator is:

https://maps3.sgu.se/geoserver/inspire/ows?BBOX=11.2075310914546%2C55.3671957158819%2C24.1035511519344%2C68.9681779468207&CRS=CRS%3A84&FORMAT=image%2Fpng&HEIGHT=500&LAYERS=MR.SGU.MineralResources&REQUEST=GetMap&SERVICE=WMS&STYLES=&VERSION=1.3.0&WIDTH=500

gives an error (a request for the root layer should give a map response, even if you wouldn't normally do it).

The layer inspire:MR.SGU.MineralResources or even just MR.SGU.MineralResources doesn't exist in the service (as opposed the static capabilities file).

[tomlind]

Thanks a lot. We will investigate and hopefully solve these issues. I know we have issues on the WFS also, maybe we should add a check issue for that also.

[nmtoken]

Not important for validation, but if you add the <Keyword>Erml_lite_queryable_geoserver</Keyword> keyword to your layers, the service will be able to resymbolized in the OneGeology Portal. Currently, the analysis tool allows reportrayal using queries on commodity and on mineral occurrence type (or both).

[tomlind]

Finally we have started to do some more systematic validation using the ETF Validator. Some of the things you point out are common to all of our services, since we are using Geoserver with static capabilities in front, and your comments have been very helpful, thanks again!

Some issues we can fix rather easy, and on others we have some comments or questions. I will comment them one by by one in comments below

[tomlind]

A genuine error found by the validator is:

https://maps3.sgu.se/geoserver/inspire/ows?BBOX=11.2075310914546%2C55.3671957158819%2C24.1035511519344%2C68.9681779468207&CRS=CRS%3A84&FORMAT=image%2Fpng&HEIGHT=500&LAYERS=MR.SGU.MineralResources&REQUEST=GetMap&SERVICE=WMS&STYLES=&VERSION=1.3.0&WIDTH=500

gives an error (a request for the root layer should give a map response, even if you wouldn't normally do it).

The layer inspire:MR.SGU.MineralResources or even just MR.SGU.MineralResources doesn't exist in the service (as opposed the static capabilities file).

This has always been confusing to me. What is the root layer supposed to give as a map response? Actually I have never really understood the need for the root layer, and in our new version of Geoserver there is an option to don't add a root layer in the publishing tab. We have not tested that option yet.

@nmtoken How are BGS others handling this problem, or are you avoiding it somehow?

I guess we have the same problem with our group layers in the MR and GE services, they are not giving map responses. It can't see that the ETF validator reports this, is that not a problem or has the root layer some specific meaning?

[nmtoken]

Well perhaps I was being a little harsh to say you might never use the root layer, it is after all another group layer, and sometimes group layers are useful. You could have it so all your sub layers are available at different scales, or have point layers to always show on top of polygons, but when you have multiple layers of the same type and at the same scale (as say in a geology and minerals service) it is less useful.

BGS OneGeology services (own and hosted) are mainly MapServer which renders the root layer. BGS also use ArcGIS (which doesn't support it) and GeoServer...

I do occasionally use static GetCapabilities files to test and 'proxy' services (usually to change metadata) etc, but I it might be that services should be properly proxied, for example using MapProxy (I haven't yet tested but others are ~ OneGeology/TechnicalDiscussion#8) or perhaps just cascaded through another WMS to ensure a valid response.

On your other group layers not showing an ETF error, I think it's because it's not tested, rather than anything else. On group layers in GeoServer (and indeed MapServer) there are several different types, and choosing one over another may affect your outcome, for GeoServer I think you need 'Named Tree Mode'

[nmtoken]

Closing as mostly resolved now. New services can be re-checked under a new issue