search

agiorguk / gemini

Resources relating to the UK Gemini metadata profile
5 stars 3 forks source link

2021-03 Spatial reference system should not be required for Service records (Peter Parslow, Feb 2021) #21

Open PeterParslow opened 3 years ago

PeterParslow commented 3 years ago

See INSPIRE TG C.3.1 - not required for Network Services (Discovery, View, Download)

See INSPIRE TG C.1.2 and TG Requirement 6.1: metadata/2.0/req/sds-interoperable/crs - there are Interoperable Spatial Data Services that should provide it.

See also 2020-21 (both!)

6footdestiny commented 3 years ago

Im not sure of the reasoning behind not including it?

PeterParslow commented 3 years ago

Im not sure of the reasoning behind not including it?

Example: when creating a record for a CSW (Discovery Service), what Spatial reference system should I say it supports? I suppose the boundingBox (if requested) has to be in WGS84, and the boundingBoxes of any responses would be, but that's not to say that any records returned by the CSW describe things that are only in WGS84.

nmtoken commented 3 years ago

Network services would also include processing services like WPS and WCPS, where no Spatial reference system applies

archaeogeek commented 1 year ago

@nmtoken to check schematron rules

archaeogeek commented 1 year ago

@PeterParslow to check INSPIRE definition of Interoperable Spatial Data Services

nmtoken commented 1 year ago

INSPIRE (Infrastructure for Spatial Information in the European Community) defines "Interoperable Data Services" as services that allow for the exchange, sharing, and processing of spatial data from varied sources across Europe in a seamless and consistent way. These services are expected to comply with the regulations laid out in the INSPIRE Directive, which includes technical standards that ensure data interoperability, quality, and accessibility.

PeterParslow commented 1 year ago

https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32014R1312#d1e118-8-1

“interoperable spatial data service” means an invocable spatial data service which fulfils the requirements of Annex VI

i.e.

“Invocable spatial data service” means all of the following plus conformant metadata.

(a) a spatial data service with metadata which fulfils the requirements of Commission Regulation (EC) No 1205/2008 (5),

(b) a spatial data service with at least one resource locator that is an access point,

(c) a spatial data service in conformity with a documented and publicly available set of technical specifications providing the information necessary for its execution,

PeterParslow commented 4 months ago

As so often, the matched PR seems unrelated.

I think it is actually non-breaking in that we would relax the Obligation from "at least one" to "optional", so no currently-valid records would be made invalid.

Do we now agree that it should be optional?

nmtoken commented 4 months ago

@nmtoken to check schematron rules

Currently required for all services MI-17a (Spatial Reference System): At least one coordinate reference system used in the described dataset, dataset series, or service shall be given using gmd:referenceSystemInfo/gmd:MD_ReferenceSystem/gmd:referenceSystemIdentifier/gmd:RS_Identifier

Agree that it should be optional for services unless it's a SDS; so will need to need to check for an SDS keyword in the schematron.

Related to https://github.com/agiorguk/gemini/issues/78 ~ Will need an isSDS rule

PeterParslow commented 4 months ago

If we can test that, then the obligation should be "Conditional, required when describing an INSPIRE Spatial Data Service"

nmtoken commented 4 months ago

Possibly confusing myself here, but do we need to change the Spatial data service type guidance Metadata Item 37 - Spatial Data Service Type or schematron rule MI-37a (Spatial Data Service Type) ; at the moment we say that if the hierarchyLevel is service then you must supply one spatial data service type (one of 'discovery', 'view', 'download' , 'transformation', 'invoke' , 'other'), which implies that all network services are also SDS (and therefore need a coordinate reference system).

Or are we now saying that not all service records are SDS, and therefore don't need a Spatial Data Service Type (and that this subset of service records don't need a coordinate reference system)

Or are we saying that these service types define network services, and are required, but we have misrepresented them as Spatial Data Service Types.

However

See INSPIRE TG C.3.1 - not required for Network Services (Discovery, View, Download)

Discovery, View, Download are all included in the list of possible spatial data service types, and are also represented in the INSPIRE SpatialDataServiceCategory codelist with for example infoCatalogueService infoRegistryService, infoFeatureAccessService, infoMapAccessService, infoCoverageAccessService

I changed the schematron to only check for a spatial reference system where hierarchyLevel is dataset or series, or where hierarchyLevel is service and there is a keyword from the INSPIRE SpatialDataServiceCategory, but considering that infoMapAccessService is there and is a view service type (which is a type of network service...) I'm not so sure this is a valid test.

original test:

  <sch:pattern fpi="Gemini2-mi17-refSysInfo-1">
    <sch:p>The coordinate reference system(s) used in the described dataset or dataset series shall
      be given using element
      gmd:referenceSystemInfo/gmd:MD_ReferenceSystem/gmd:referenceSystemIdentifier/gmd:RS_Identifier
      INSPIRE Requirements metadata/2.0/req/sds-interoperable/crs and metadata/2.0/req/isdss/crs </sch:p>
    <sch:rule context="//gmd:MD_Metadata[1]">
      <sch:assert id="MI-17a"
        test="count(//gmd:MD_Metadata[1]/child::gmd:referenceSystemInfo/descendant::gmd:RS_Identifier) &gt; 0"
        > MI-17a (Spatial Reference System): At least one coordinate reference system used in the described dataset, dataset
        series, or service shall be given using
        gmd:referenceSystemInfo/gmd:MD_ReferenceSystem/gmd:referenceSystemIdentifier/gmd:RS_Identifier
      </sch:assert>
    </sch:rule>
  </sch:pattern>

revised tests currently:

  <sch:pattern fpi="Gemini2-mi17-refSysInfo-1a">
    <sch:p>The coordinate reference system(s) used in the described dataset or dataset series shall
      be given using element gmd:referenceSystemInfo/gmd:MD_ReferenceSystem/gmd:referenceSystemIdentifier/gmd:RS_Identifier
      INSPIRE Requirements metadata/2.0/req/isdss/crs </sch:p>   
    <sch:rule context="//gmd:MD_Metadata[1]">
      <sch:report id="MI-17a" test="($hierarchyLevelCLValue = 'dataset' or $hierarchyLevelCLValue = 'series') and $refSysInfoNum = 0">
        MI-17a (Spatial Reference System): At least one coordinate reference system used in the described dataset, dataset series shall be given using
        gmd:referenceSystemInfo/gmd:MD_ReferenceSystem/gmd:referenceSystemIdentifier/gmd:RS_Identifier.
        <sch:emph>DEBUG:</sch:emph> We have <sch:value-of select="$hierarchyLevelCLValue"/> and <sch:value-of select="$refSysInfoNum"/>
      </sch:report>
    </sch:rule>
  </sch:pattern>
  <sch:pattern fpi="Gemini2-mi17-refSysInfo-1b">
     <sch:p>The coordinate reference system(s) used in the spatial data service shall
      be given using element gmd:referenceSystemInfo/gmd:MD_ReferenceSystem/gmd:referenceSystemIdentifier/gmd:RS_Identifier
      INSPIRE Requirements metadata/2.0/req/sds-interoperable/crs</sch:p>
    <sch:rule context="//gmd:MD_Metadata[1]/gmd:identificationInfo[1]/srv:SV_ServiceIdentification/gmd:descriptiveKeywords/*[1]/gmd:keyword/child::*/text()">
      <sch:report id="MI-17sds" test="$hierarchyLevelCLValue = 'service' and $refSysInfoNum = 0 and
        $sdsClassCodes//cat/text()[normalize-space(.) = normalize-space(current()/.)]">
        MI-17sds (SDS Spatial Reference System): At least one coordinate reference system used in the described service shall be given using
        gmd:referenceSystemInfo/gmd:MD_ReferenceSystem/gmd:referenceSystemIdentifier/gmd:RS_Identifier.
        <sch:emph>DEBUG:</sch:emph> We have <sch:value-of select="$hierarchyLevelCLValue"/> and <sch:value-of select="$refSysInfoNum"/> and SDS Keyword <sch:value-of select="."/>
      </sch:report>
    </sch:rule>
  </sch:pattern>
PeterParslow commented 4 months ago

The INSPIRE Metadata Technical Guidance certainly implies that the 'network services' are (types of) spatial data service

https://github.com/INSPIRE-MIF/technical-guidelines/blob/2022.2/metadata/metadata-iso19139/metadata-iso19139.adoc#4-conformance-classes-for-spatial-data-services

"Most of the metadata requirements for INSPIRE Network Services are contained in Conformance Class 3: INSPIRE Spatial Data Service baseline metadata. Though brief, this Conformance Class is added here to make clear which metadata requirements apply to Network Services."

They then allow for other Spatial Data Services, like the ones listed at https://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceCategory:1. These "other" ones can then be invocable, interoperable, or harmonised - with each level adding extra metadata requirements. It's only at "interoperable" that they say to an SRS is mandatory.

GEMINI is then tighter than that (I can't remember the original reasons!) requiring SRS on network services. We are now softening that a bit to not require them on all services (specifically, the ones known as network services).

(I find the INSPIRE lists of SDS types far from ideal. For example, I don't know the difference between an SDS of type https://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceCategory/infoCatalogueService and an INSPIRE Discovery Service!)

nmtoken commented 4 months ago

So all network services need an SDS conformity statement, and SDS keyword, and when the conformtity statement says the service is interoprable or hamonized it then needs a SRS

PeterParslow commented 4 months ago

I reckon that is the INSPIRE position. As mentioned above, we (GEMINI) have been more strict.

nmtoken commented 4 months ago

We've been more strict on SRS, but don't yet check for the conformity statement and keywords. So not sure what to do with schematron rules. It will be a breaking change to check that all services have the keyword and conformity statement, the latter of which I will need to test to add a conditional check for when services need a SRS