Change proposal description

In both INSPIRE "Conditions for Access and Use" and "Limitations on Public Access" we require the RestrictionCode to be otherRestrictions.

In many cases, other values of ISO 19115:2003 RestrictionCode are more appropriate, such as "license" or "intellectualPropertyRights". Allowing these (and the other) values would make the resulting record "more standard".

We can still use the otherConstraints element to provide more information, including the Anchor link to the more detailed INSPIRE controlled lists.

Addressed TG

TG Metadata 2.0.1

Location

TG Requirement C.17, third paragraph (and associated footnote 25)
TG Requirement C.18, second paragraph (and associated footnote 27)
C.2.21, 2nd table, "INSPIRE obligation/condition" row

I can only find the two TG Requirement ones in metadata-iso19139.adoc, not the footnotes or table that I see in the PDF.

Issue faced

When the restriction is due to e.g. intellectualPropertyRights, it is harder for the reader of the metadata to find that out - INSPIRE's use of ISO 19115 is "not standard".

Proposed solution

Changes as described above & in the pull request.

Pull request

Additional information

I can only find the two TG Requirement ones in metadata-iso19139.adoc, not the footnotes or table that I see in the PDF.

Relevant legislation

Impact on IR

None

• IR metadata

Impact on INSPIRE validator

Would require changes at https://github.com/inspire-eu-validation/metadata/blob/2.0/common/limitations-on-public-access.md, https://github.com/inspire-eu-validation/metadata/blob/2.0/common/conditions-for-access-and-use.md, and the related tests.

Linked issue

Impact on INSPIRE XML schemas

None

Linked issue

Impact on INSPIRE code lists

None

Linked issue

Change proposer

Peter Parslow

References

Dear

I hope you are all right.

As discussed in another ticket, I think we should change the value type of sourceOfName attribute (from GeographicalName featuretype). As you may know that attribute aims to describe in a human readable way the source of a GeographicalName object.

Regulation 1089/2010 states that field has to be filled with a CharacterString object. That kind of objects aims to express some human readable in one language. As you may know in Belgium we do have three national languages. Even for a Dutch name (for instance "Antwerpen") I do have to express the sourceOfName attribute in both Dutch and French to comply with belgian legislation: the language of the GeographicalName itself does not matter.

That's why I think that LocalisedCharacterString is by far more relevant than CharacterString. With such a value type, one can express in many languages the origin of a specific GeographicalName in a give language. Therefore, the cardinality of sourceOfName should become 1-...

Regards

Change proposal description

According to Commission Regulation (EU) No 1253/2013 the geometry type of AreaStatisticalUnit must be GM_MultiSurface (constraint on AreaStatisticalUnit in section 1.3.1.2.).

The document Data Specification on Statistical Units - Technical Guidelines is currently missing this information. The UML class diagram for "Vector package" (figure 7 in section 5.3.1.2.3) suggests that GM_Object is allowed to describe the geometry.

Addressed TG

Data Specification on Statistical Units - Technical Guidelines

Location

Data Specification on Statistical Units - Technical Guidelines

• UML class diagram for "Vector package" (figure 7 in section 5.3.1.2.3)
• a constraint on AreaStatisticalUnit is missing

Issue faced

The INSPIRE validator enforces at the moment geometries as GM_MultiSurface and does not allow GM_Surface. According to the Commission Regulation (EU) No 1253/2013 this is correct. According to the Data Specification on Statistical Units - Technical Guidelines GM_Surface should be allowed to describe the geometry.

Proposed solution

Update UML diagram mentioned above and/or add a constraint on AreaStatisticalUnit.

Pull request

Not available as the TG is not yet available in the repository.

Additional information

Impact on INSPIRE validator

Linked issue

INSPIRE-MIF/helpdesk-validator#714

It seems that the value "ProtectedLandscapeOrSeascape" of the codelist "IUCNDesignationValue" is not consistent with other values and with the general rules that require values to start with lowercase letters.

The value should be "protectedLandscapeOrSeascape".

The value has been already corrected in the INSPIRE Registry, see the related issue.

For the provision of elevation data, INSPIRE foresees the use of EVRF2000, EPSG:5730.

Since then, this concept has been updated twice, adding the following elevation codes with adjusted vertical Datum:
• EVRF2007 height EPSG:5621
• EVRF2019 height EPSG:9389
• EVRF2019 mean-tide height EPSG:9390

We would kindly request the addition of these EPSG Codes to the list of CRS applicable within INSPIRE.

Addressed TG

https://inspire.ec.europa.eu/id/document/tg/rs
https://inspire.ec.europa.eu/id/document/tg/gg
https://inspire.ec.europa.eu/id/document/tg/el

Impact on INSPIRE validator

The CRS-s should become valid values.

Linked issue

Impact on INSPIRE code lists

The CRS-s should become valid values.

Change proposer

Herzo van der Wal
Data-Manager at Ministry of Infrastructure and Water Management
Rijkswaterstaat (directed to this site by Geonovum)
Responsible for INSPIRE-services on the thema Elevation and more

References

https://github.com/codefornl/INSPIRE-Coverages

Change proposal description

Summary of change: remove mention of word 'publication' in TG Requirement C.15 when describing reference dates for vocabularies as this is not always useful to end-users and replace with 'reference date'. This allows for usage of 'revision' and 'creation' which have valid use cases when indicating what stage a vocabulary has evolved to when a particular term is selected for use in metadata. This change would bring the TG Requirement c.15 in line with the current text that is present in the excerpt of [Regulation 1205/2008], Part B, 3.2 within 2.3.5 Keywords in the INSPIRE TG Metadata v2.0.1.

TG Requirement c.15 states that "The publication date of the vocabulary shall be given using the
gmd:date/gmd:CI_Date/gmd:date/gco:Date and gmd:dateType/gmd:CI_DateTypeCode elements." and there is an accompanying footnote (#24) that states
"Attribute codeList shall have value
"http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#CI_DateTypeCode" and the attribute
codeListValue value "publication"

Proposal of change is that text of TG Requirement C.15: changes to
"The reference date of the vocabulary shall be given using the
gmd:date/gmd:CI_Date/gmd:date/gco:Date and gmd:dateType/gmd:CI_DateTypeCode elements."
and the text in the footnote changes to
"Attribute codeList shall have value
"http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#CI_DateTypeCode" and the attribute
codeListValue value shall be one of "publication", "creation", "revision"."

Addressed TG

Technical Guidance for the implementation of INSPIRE dataset and service metadata based on ISO/TS 19139:2007 Version 2.0.1

Location

TG Requirement C.15 in section 2.3.5 Using keywords on page 41 of the TG document.

Issue faced

TG Requirement c.15 states that "The publication date of the vocabulary shall be given using the
gmd:date/gmd:CI_Date/gmd:date/gco:Date and gmd:dateType/gmd:CI_DateTypeCode elements." and there is an accompanying footnote (#24) that states
"Attribute codeList shall have value
"http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#CI_DateTypeCode" and the attribute
codeListValue value "publication"

NOTE on top of p42 states " Specifying the correct publication date of the thesaurus is important for knowing which version of the thesaurus has been used"

Proposed solution

Proposal of change is that text of TG Requirement C.15: changes to
"The reference date of the vocabulary shall be given using the gmd:date/gmd:CI_Date/gmd:date/gco:Date and gmd:dateType/gmd:CI_DateTypeCode elements."
and the text in the footnote changes to
"Attribute codeList shall have value
"http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#CI_DateTypeCode" and the attribute
codeListValue value shall be one of "publication", "creation", "revision"."

NOTE on p42 shall change to "Specifying the correct reference date of the thesaurus is important for knowing which version of the thesaurus has been used"

Additional information

Kind of issue

Editorial

Relevant legislation

• INSPIRE Directive
• IR network services
• IR metadata
• IR interoperability spatial data sets and services

Impact on IR

• INSPIRE Directive
• IR network services
• IR metadata
• IR interoperability spatial data sets and services

Impact on INSPIRE validator

May require a loosening of validation checks for MD_Keywords to ensure DateTypeCode of revision and creation are also allowed.

Linked issue

None known

Impact on INSPIRE XML schemas

None known

Linked issue

No known linked issues

Impact on INSPIRE code lists

None

Linked issue

No known linked issues

Change proposer

Sean Gaffney, UK Marine Environmental Data and Information Network and member of AGI GEMINI Working Group

References

None

Change proposal description

In ElevationGridCoverage , ElevationTIN and ElevationVectorElements application schemas the 'endLifespanVersion' property has multiplicity equal to one. Proposal in application schema issue #42 is to set endLifespanVersion multiplicity to [0..1], coherently to multiplicity of this property in the other INSPIRE application schemas.
Elevation TG needs be updated accordingly.

Addressed TG

Elevation

Location

Page 56 , Page 65 , page 77, update the Feature catalogue, for the Attribute: endLifespanVersion, setting Multiplicity to 0..1
Update
Figure 17 – UML class diagram: Overview of the ElevationGridCoverage application schema
Figure 20 – UML class diagram: Overview of the ElevationVectorElements application schema
Figure 21 – UML class diagram: Overview of the ElevationTIN application schema

Pull request

Not available as the TG is not yet available in the repository.

Additional information

Kind of issue

editorial

Impact on IR

no impact

Impact on INSPIRE validator

no impact

Linked issue

Impact on INSPIRE XML schemas

endlifespanVersion shall be updated to 0..1 in ElevationGridCoverage , ElevationTIN and ElevationVectorElements application schemas

Linked issue

INSPIRE-MIF/application-schemas#42

Impact on INSPIRE code lists

no impact

Change proposal description

Current Title "D2.8.III.3 INSPIRE Data Specification on Soil – Draft Guidelines" should be changed into "D2.8.III.3 INSPIRE Data Specification on Soil – Technical Guidelines".
The "Draft" adjective is clearly a typo.

Addressed TG

https://inspire.ec.europa.eu/id/document/tg/so

Location

Page 1

Change proposal description

The Norwegian Mapping Authority, as coordinator of Inspire implementation i Norway, observes that Inspire validator for metadata do not accept “NOR” as a value for metadata language. Norway finds this unacceptable. The issue has been raised towards JRC, without results, we now therefore send the request to DG Environment. Nowe we post it as TG revision request on advise from DGEnv.
Norway would kindly ask for a change in practice of the setup of the Inspire validator, accepting also the NOR value and in addition acceptance to deliver English/other official EU languages as localised language. This is a technical issue, but should be decided by the EC and DG Environment.

Addressed TG

INSPIRE Metadata Implementing Rules: Technical Guidelines, maybe also Reporting guidance documents if they are stating content concerning the validator

Location

Technical Guidance C.2.27 Metadata language, to also include “Norwegian“ and “Icelandic” as a part of the domain.

Issue faced

Norwegian Mapping Authority is requesting two minor adjustments to TG Metadata and the Inspire validator;

VALIDATOR TO ACCEPT NOR AND ICE AS VALID CODES FOR METADATA
• The European Economic Area committee agreed through the process 55/2010 and agreement of 30. April 20210 to include Inspire directive (2007/2/EC) into the European Economic Area Agreement. This implies that Norway is to implement Inspire. This also means that EU is accepting Norway as a delivery country.

• Norway is experiencing that Norwegian is not accepted as a language for metadata in Inspire. The Inspire metadata validation accepted NOR as code for Norwegian language some years ago, but technical adjustments were made, with the affect that Norwegian language now not is accepted.

• This results in low score on the Metadata indicator and makes trouble for the Norwegian implementation of Inspire.
• The Inspire legal act states; "Metadata language - This is the language in which the metadata elements are expressed. The value domain of this metadata element is limited to the official languages of the Community expressed in conformity with ISO 639-2”. Norwegian is among the codes in the ISO-list.

• The European Economic Area (EEA) agreement with the EU with regards to Inspire, was done several years later than the Metadata regulation was developed and agreed. Unfortunately, therefore, there is no direct reference to EEA countries Norway, Iceland and Lichtenstein. When the EFTA countries (including Norway) became a part of Inspire, they also become a part of the “Community”, as referenced in in the act. We think that Norway is a member of the Inspire-community and therefore the official language of Norway should be a valid language in the metadata, and thus in the Inspire metadata validator. In addition, this should also account for Icelandic language (ICE), as the country also is part of the European Economic Area Agreement with EU concerning Inspire implementation.

• The Inspire Technical guidance document is stating: “TG Requirement C.5: Metadata/2.0/req/common/metadata-language-code. The language of the provided metadata content shall be given. It shall be encoded using gmd:MD_Metadata/gml/language/gmd:LanguageCode element pointing to one of the tree-letter language codes of the ISO 639-2/b code list. Only the code values for the official languages of the European Union shall be used." This is a guidance document and the document adds a new premise in this requirement, “languages of the Community” are translated to “official languages of the European Union”. It is unfortdocument gets updated in sectionunate that discrepancies between the act and technical documents occur. In this respect we also wish that Technical Guidance C.2.27 Metadata language, to also include “Norwegian“ and “Icelandic” as a part of the domain.

VALIDATOR TO ACCEPT ENGLISH OR OTHER EU LANGUAGE AS LOCALISED LANGUAGE IN INSPIRE METADATA
• Norwegian is at present unfortunately not among the languages accepted, but we provide metadata both in Norwegian and English in our metadata. Metadata elements with textual content are provided in English as a localized language. We can’t see that the act states that the metadata elements should be provided in “official languages of the Community” as main language. We therefore think that metadata delivered as localized language (second language) in one of the EU languages fulfils the regulation and should be accepted in the Inspire validator. We kindly ask for changes in the validator in this respect.
• Norway would then experience better results on the monitoring and reporting exercises. With respect to users, the CSW metadata service from Norway, as already said, is given also in English, therefore the good service to users will remain irrespective of the proposed change in validation practice.

Proposed solution

See above

Pull request

We dould kind ask for information through the process

Additional information

Kind of issue

TECHNICAL

Relevant legislation

SEE ABOVE

Language described in COMMISSION REGULATION (EC) No 1205/2008 of 3 December 2008 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards metadata (Text with EEA relevance). I part B Metadata kap 1.7

• INSPIRE Directive
  YES
• IR network services
  MAY BE ISSUES CONCERNING CSW?
• IR metadata
  YES

Impact on IR

Probably no change on implementing rules. Neither on metadata nor network services (CSW). We still leave the links here for JRC to check if there are consequences on IR.

• IR network services
• IR metadata

Impact on INSPIRE validator

See above. Impact on acccepted NOR and ICE + localised languages

Linked issue

There is alerady an issue raised,

Impact on INSPIRE XML schemas

Linked issue

Impact on INSPIRE code lists

see above

Linked issue

INSPIRE-MIF/helpdesk-validator#327

Change proposer

Arvid Lillethun, Norwegian Mapping Authority

References

Change proposal description

This proposal derives from the need to align the TN TG to the endorsed change INSPIRE-MIF/application-schemas#61.
This change requires that a clarification note is added in the 'Geometry representation' section specifying that an AirNode is not required to be present 'where Transport Links connect or end' when its significantPoint attribute is set to 'false'.

Addressed TG

TN

Location

Issue faced

An AirNode is not necessarily placed at the end or start of a Transport Link when it is not used for navigation/ATS purposes.
Example: an AerodromeNode could either simply represent the aerodrome location (significantPoint = false) or act as transport node for connectivity (significantPoint = true).

Proposed solution

A clarification note is added in Section 5.3.1.6. Geometry representation specifying that an AirNode is not required to be present where Transport Links connect or end when it is not intended for navigation/ATS purposes i.e., when its significantPoint attribute is set to 'false'.

Pull request

Additional information

Impact on INSPIRE validator

INSPIRE-MIF/helpdesk-validator#113

Change description

The "enumeration" concept and the enumeration's values were removed from Regulation (EU) No 1089/2010.
All the enumerations shall be converted into codelists and managed in the INSPIRE Registry.

Implementation of changes

This change has an impact on several parts of the TGs:

• Change of the Article 4:

  • old formulation
    
  • new formulation
    

• Removal of the enumeration concept from the “Stereotypes” section:
  

• Removal of the “Enumerations” section:
  

• Change of the Article 6:

  • old formulation
    
  • new formulation
    

• Removal of the “Enumerations” section from the feature catalogue and conversion of the enumerations into codelists (ONLY TGs which define enumerations):
  

  • The following values are used for the missing tags:
    • Extensibility = none
    • Identifier = http://inspire.ec.europa.eu/codelist/<name_of_enumeration>
    • Values = The allowed values for this code list comprise only the values specified in the INSPIRE Registry.

• Removal of any reference to enumeration (if applicable):

  • E.g. AF TG
    

• Change of the stereotype from “enumeration” to “codeList” in the UML
  

Relevant legislation

Commission Regulation (EU) 2023/2431 of 24 October 2023 amending Regulation (EU) No 1089/2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services

Consolidated text: Commission Regulation (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services

Additional information

Impact on INSPIRE validator

Yes, a specific check needs to be added for enumerations that are converted into codelists, since the related values are no longer checked during the schema validation step.

Linked issue

N/A

Impact on INSPIRE XML schemas

Yes, the enumerations shall be removed from the xsd and the datatype of the related attributes need to be changed.

Linked issue

Convert enumerations into codelists_Change from 1089 amendment #89

Impact on INSPIRE UML

Yes

Impact on INSPIRE Registry

Yes, the enumerations shall be converted into codelists.

Linked issue

INSPIRE-MIF/helpdesk-registry#91

The revised version of OGC/ ISO 19156 Observations & Measurements (now names Observations, measurements and samples) has just been pushed to ISO end of October 2022.

The finalized International Standard will be published by ISO secretariat.

Change proposal description

Several concepts stemming from INSPIRE EF have been included in the new standard.
And the standard also takes into account activity from the observation community over the last decade
Thus there is a need to update INSPIRE EF accordingly (ex : Observer, ObservingCapability, ...)

Addressed TG

EF

Issue faced

Some concepts in INSPIRE:EF were specific to the INSPIRE activity.
They are now included in the International Standard (IS)

Proposed solution

Updating to the revision of the IS will enhance interoperability

Pull request

No PR yet, a group activity is required

Additional information

Impact on IR

Will need to be checked by the upcoming group

Impact on INSPIRE validator

Will need to be checked by the upcoming group

Linked issue

INSPIRE O&M guidelines will also need to be updated accordingly -> another issue needs to be created here

Impact on INSPIRE XML schemas

Will need to be checked by the upcoming group

Impact on INSPIRE code lists

Will need to be checked by the upcoming group

Change proposer

Sylvain Grellet - BRGM

References

Links to the revised ISO spec will be available soon

Some values of the SurveyTypeValue codelist of the Geology data theme have an incorrect description.

It seems that some descriptions are duplicated between the different codelist values and others seem to be swapped.

A revision of all values is required.

The related issue requiring the update of the INSPIRE Registry is available in the Registry helpdesk.

The identifiers of the codelists, i.e. the URL pointing to the INSPIRE registry, are wrong because they contain the value "codeList" with an uppercase "L".
The right values are with the lowercase.

See the related issues in the Registry helpdesk and in the Validator helpdesk.

Any reporting of the same error in other TGs is more than welcome.

Change proposal description

Add/update the URLs where reports [EUR 19575 EN], [EUR 20120 EN] and [EUR 21494 EN] can be found. Update the text to refer to these reports using their labels in the bibliography.

Addressed TG

Coordinate reference systems

Location

Issue faced

The links are outdated. Website http://www.ec-gis.org/ is dedicated to a different topic today.

The reports don't seem to be available in any official publication's repository.

Overview:

• "Spatial Reference Systems in Europe" (EUR 19575 EN)
  • I haven't been able to find an online copy
  • An entry is present in the JRC Publications Repository , but no actual document is available there
• "Map Projections for Europe" (EUR 20120 EN)
  • A copy can be found on http://www.mapref.org/LinkedDocuments/MapProjectionsForEurope-EUR-20120.pdf, http://mapref.org/ seems to be the website of the author of one of the chapters in the report.
  • The repository of the Publications Office of the European Union gives a result, but clicking on the permalink gives the message "The document doesn't have a viewable format at this time"
• "European Reference Grids" (EUR 21494 EN)
  • A copy can be found on https://esdac.jrc.ec.europa.eu/ESDB_Archive/ESDB_data_1k_raster_intro/annoni2005eurgrids.pdf
  • I haven't been able to find an official metadata record in any repository

Proposed solution

1. Place the three documents online in an official EU repository. If none of the aforementioned repositories can be used, perhaps they could be put in the INSPIRE Knowledge Base?
2. Update the references in the bibliography, so they include the correct URLs where the documents can be found.
3. Update the main text, so it actually refers to the bibliography, using labels [EUR 20120 EN] and [EUR 21494 EN].

Pull request

Not available as the TG is not yet available in the repository.

Additional information

Kind of issue

editorial

Relevant legislation

It seems that the INSPIRE requirements regarding the coordinate reference systems are based on the report "Map Projections for Europe", see also INSPIRE-MIF/helpdesk-registry#79 (note: if anybody has more/other background info, I would be happy to know more about that).

Impact on IR

No impact.

Impact on INSPIRE validator

No impact

Impact on INSPIRE XML schemas

No impact.

Impact on INSPIRE code lists

No impact.

Change proposer

Heidi Vanparys

References

N/A

Change proposal description

For all data specifications: remove the table "http URIs for the default coordinate reference systems" and add the link to the coordinate reference systems register in the INSPIRE registry.

Addressed TG

All data specifications.

Location

This will impact Section 6.1.1.4 "Identifiers for coordinate reference systems" of all data TGs and Section 5.5 "Identifiers" of the RS TG.

Issue faced

The IR on the interoperability of spatial data sets and services amendment (see COMMISSION REGULATION (EU) 2023/2431), foresees the creation of a "register of CRS".

To further reduce the implementation and maintenance burden, a register of CRS, including their definition and transformation parameters, should be established and operated by the Commission services (Joint Research Centre) with assistance from the existing expert group.

Proposed solution

All data specifications shall be updated with the following change: the table "http URIs for the default coordinate reference systems" shall be removed and a reference to the relevant register in the INSPIRE registry shall be added instead.

Pull request

TBD for each data specification available on GitHub.

Additional information

Kind of issue

Technical issue

Relevant legislation

Commission Regulation (EU) 2023/2431 of 24 October 2023 amending Regulation (EU) No 1089/2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services

Impact on INSPIRE validator

The related tests in the Validator should be updated to validate the coordinate reference systems against the CRS register instead of against the current static list.

Linked issue

INSPIRE-MIF/helpdesk-validator#1066

Impact on INSPIRE XML schemas

No impact.

Linked issue

N/A

Impact on INSPIRE registry

A coordinate systems register shall be created in the INSPIRE Registry, replacing the temporary table created in the helpdesk repository.

Linked issue

INSPIRE-MIF/helpdesk-registry#75

Change proposer

INSPIRE Support team.

Change proposal description

Change the style name of the layer BU.Building from "BU.Building.default" to "BU.Building.Default" in section10.2.1 and 10.2.2
This is the pattern for other styles in INSPIRE and is also already in use in the validator (see this issue and this list of styles checked in the validator.

Addressed TG

D2.8.III.2 Data Specification on Buildings – Technical Guidelines

Location

Section 10.2.1 and 10.2.2

Issue faced

The style name contains "default" with a lowercase "d" which is different from other default styles using an uppercase "D" and different from what the validator expects.

Proposed solution

Replace "BU.Building.default" with "BU.Building.Default"

Pull request

Additional information

Kind of issue

editorial

Impact on INSPIRE validator

The validator will be changed to support both versions - once the change is realised in the DS, the support of the lowercase variant can be removed from the validator.

Linked issue

INSPIRE-MIF/helpdesk-validator#626 (comment)

Change proposer

Johanna Ott
wetransform GmbH

Change proposal description

1. remove or update all footnotes
2. if removal, add a recommendation at the beginning of the TG listing the recommended URIs of the ISO code lists

Addressed TG

Technical Guidance for the implementation of INSPIRE dataset and service metadata based on ISO/TS 19139:2007 (Version 2.0.1)

Location

• section 2.1.1 Encoding of code list values
• footnote 19, 21, 22, 35, 79

Issue faced

• It is indisputable that the content to be used for an element based on a codeList has to be taken from a quite specific codeList. The "source" for the permissible values of the codeListValue for the language code is unique, regulated in C.5. In other cases (role code, date type etc.) the ISO regulates this itself, as it contains these codeLists directly. Only the footnotes name a particular code list URL to be used.
• The two paragraphs following requirement C.3 are in conflict with the statement, that individually extended codeLists are allowed. These, of course, contains the official values as well (even if you are not allowed to use these individual values for INSPIRE in this case).
• Nevertheless, under codeList you would have a URL that differs from the requirement.
• MIWP 2017.4 agreed that the Validator should only check the value of the codeListValue attribute, and not the value of the codeList attribute. (https://webgate.ec.europa.eu/fpfis/wikis/display/InspireMIG/2017.4+meeting+%2311+2019-07-17)

Proposed solution

1st option

Both the value of the codeList attribute (a URL that references a code list definition within a register or a code list catalogue) and the textual content of the ISO 19139 element are purely informative. Regarding of the metadata element, the codeList attribute may point to one of the following recommended code list dictionaries:

• ISO 639-2 at http://www.loc.gov/standards/iso639-2/, and the attribute codeListValue shall contain one of the three-letter bibliographic language code values
• ISO 19139 at http://standards.iso.org/iso/19139/resources/gmxCodelists.xml, and if a text is provided, it may contain the translation of the code list value in the language of the metadata.
• INSPIRE metadata code list register at https://inspire.ec.europa.eu/metadata-codelist
• ...

2nd option

update all footnote to e.g. Attribute codeList can e.g. containt ... or Attribute codeList may e.g. point to ...

Pull request

Currently not possible.

Additional information

Kind of issue

editorial

Relevant legislation

• https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:02008R1205-20081224&from=FR#tocId19
• https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:02008R1205-20081224&from=FR#tocId48

Impact on IR

no impact on the Implementing Regulation

Impact on INSPIRE validator

quote in the footnotes of the TG MD "Attribute codeList shall be …"

Linked issue

• INSPIRE-MIF/helpdesk-validator#52
• INSPIRE-MIF/helpdesk-validator#432
• INSPIRE-MIF/helpdesk-validator#567

Impact on INSPIRE XML schemas

no impact on INSPIRE XML schemas

Linked issue

not relevant

Impact on INSPIRE code lists

no impact on INSPIRE code lists content

Linked issue

not relevant

Change proposer

Coordination Office SDI Germany | Federal Agency for Cartography and Geodesy

References

Note by Ilkka Rinne from 2016:

• [...] Based on that discussion [...], it became clear that the URIs given as the codeList attributes of the ISO code list elements is not authoritative, but informative: the authoritative source of the possibly values of the particular code list are given in the ISO standards document, regardless of the resource pointed by the codeList attribute. This is probably the reason why the codeList attribute is ignored by the validators. For the ISO code lists the validators shall only check that the codeListValue is one of the permitted values provided by the standard document for the particular code list, and can thus ignore the codeList attribute.
• [...] However it should be pointed out, that as far as I know there are no authoritative and permanent copies of the ISO code lists expressed in XML. Neither the ISO copies under http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources nor under http://www.isotc211.org/2005/resources are guaranteed to be permanently available.
• Neither the INSPIRE Metadata guidance version 1.3 nor 2.0 shall mandate the use of particular URLs for the ISO code lists for this reason.

Change description

Change the data type of the geometry attribute of the DrainageBasin feature type from "GM_Surface" to "GM_Object" and add a geometry constraint (The geometry attribute has to be of type GM_Surface or GM_MultiSurface.).

Implementation of changes

• Update of the relevant section 5.5.2.1.3. DrainageBasin

• Update of the UML diagram
  

Relevant legislation

Commission Regulation (EU) 2023/2431 of 24 October 2023 amending Regulation (EU) No 1089/2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services

Consolidated text: Commission Regulation (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services

Additional information

Impact on INSPIRE validator

A test for the new geometry constraint shall be added.

Linked issue

INSPIRE-MIF/helpdesk-validator#1052

Impact on INSPIRE XML schemas

The data type of the geometry attribute of the DrainageBasin feature type shall be changed from "GM_Surface" to "GM_Object".

Linked issue

INSPIRE-MIF/application-schemas#84

Impact on INSPIRE UML

Yes

Change proposal description

Update Figure 11 by changing the multiplicity of the soilDerivedObjectObservation association from 1 to 1..*.
This change is needed to reflect the related modification in the Soil schema, endorsed following the governance and release process of the INSPIRE artefacts.

Addressed TG

Soil

Location

Figure 11 - on Page 47

Issue faced

In Figure 11 the multiplicity of the soilDerivedObjectObservation association is 1, while in the new version of the soil schema this multiplicity is [1 .. *]

Proposed solution

Update Figure 11.

Pull request

Not available as the TG is not yet available in the repository.

Additional information

Kind of issue

editorial

Impact on IR

no impact

Impact on INSPIRE validator

no impact

Impact on INSPIRE XML schemas

The change in the soil schema has been endorsed in accordance to Governance process of the INSPIRE artefacts and is described in a relevant issue published in the issue tracker of the application schema repository.

Linked issue

INSPIRE-MIF/application-schemas#8

Impact on INSPIRE code lists

no impact

Change proposal description

Fix typos in the numbering of TG recommendations

Addressed TG

http://inspire.ec.europa.eu/id/document/tg/metadata-iso19139/2.1.0

Location

Section 3.1.2:
TG Recommendation 1.1: metadata/2.0/rec/datasets-and-series/md-element-id
TG Recommendation 1.1: metadata/2.0/rec/datasets-and-series/use_md_identifier
Section 3.2.1
TG Recommendation 2.1: metadata/2.0/rec/isdss/source-crs
TG Recommendation 2.1: metadata/2.0/rec/isdss/
TG Recommendation 2.2: metadata/2.0/rec/isdss/srs-using-geographic-identifiers
Section 3.2.4
TG Recommendation 2.2: metadata/2.0/rec/isdss/topological-consistency-measure-name

Section 4.3
Missing TG Recommendations number 5.1, 5.2, 5.3 (directly starting from TG Recommendation 5.4).

Proposed solution

Update numbering of all TG Recommendations to ensure consistency

Pull request

To be provided

Change proposal description

The multiplicity of geophObjectSet and geophObjectMember associations of the GeologicCollection feature type is not defined in the UML and in the TG. In the related XSD the multiplicity is 0..* for both associations.

Addressed TG

D2.8.II.4 INSPIRE Data Specification on Geology – Technical Guidelines

Location

Section "5.3.2.1.4. GeologicCollection"

Issue faced

There is an inconsistency between documentation (TG and UML) and the XSD application schema.

Proposed solution

It seems the multiplicity 0..* is the more suitable one since the two associations of the GeologicCollection feature type are related to the feature types defined in another GE application schema. The proposed solution is to specify the multiplicity 0..* in both TG and UML.

Pull request

Not available

Additional information

Kind of issue

editorial

Impact on IR

No

Impact on INSPIRE validator

Yes, at the moment the multiplicity in the ETS is 1 for both associations (https://github.com/inspire-eu-validation/data-ge/blob/master/ge-ia/features.md#geophObjectSet).

Linked issue

INSPIRE-MIF/helpdesk-validator#625

Impact on INSPIRE XML schemas

No, the multiplicity in the schema is already 0..*.

Impact on INSPIRE code lists

No

Change proposer

JRC

Change proposal description

For all data specifications: replace the code list descriptions with a link to the code list in the INSPIRE registry.

Addressed TG

All data specifications.

Location

This will impact sections 5.3.2 "Feature catalogue" and Annex C "Code list values".

Issue faced

The IR on the interoperability of spatial data sets and services will be amended soon, see also this presentation from the 13th MIG meeting: the code list and enumeration values in the regulation will be replaced with a reference to the INSPIRE registry.

Proposed solution

As a consequence, all data specifications should be updated when the amendment is in force: the code list values should be removed and a reference to the relevant code list in the INSPIRE registry should be added instead.

Pull request

TBD when all the data specifications are on GitHub.

Additional information

Kind of issue

Technical issue

Relevant legislation

"Common code lists" in the IR on the interoperability of spatial data sets and services

Impact on IR

No impact.

Impact on INSPIRE validator

No impact.

Linked issue

N/A

Impact on INSPIRE XML schemas

No impact.

Linked issue

N/A

Impact on INSPIRE code lists

No impact

Linked issue

N/A

Change proposer

Heidi Vanparys, helpdesk facilitator.

References

This issue was created after investigating issues #3 and #1 and discussing those during the subgroup meeting of 01-07-2021. Resolution of this issue would solve those two issues.

The issue collects some pull requests related to fixing typos in the Metadata TG.

List of pull requests:

• #85
• #71 (The change proposed in this PR was incorporated in the previous one)

This is a placeholder for the issue that was mentioned in #2 (comment).

Change proposal description

The validator expects the layer "AF.Site", the TG defines "AF.Sites"
The validator expects the styles "AF.AgriculturalHolding.Default" and "AF.Site.Default", the TG defines "AF.AgriculturalHolding" and "AF.Site"

Addressed TG

Data Specification on Agricultural and Aquaculture Facilities – Technical Guidelines

Location

chapter 11

Issue faced

Should be aligned with values expected by validator

Proposed solution

Change AF.Sites to AF.Site, change AF.AgriculturalHolding to AF.AgriculturalHolding.Default, change AF.Site to AF.Site.Default.

Change proposal description

As various players in the soil domain we endorse to allow to extend the codelists of soil properties wider than the current constraint from the TG, to be narrower then chemical, physical and biological. So we can describe also descriptive properties such as color, stoniness, etc.

Addressed TG

D2.8.III.3 Data Specification on Soil – Technical Guidelines

Location

paragraph 5.3.2.3.8.

Issue faced

Currently paragraph 53238 lists 3 categories (chemical, physical, biological) of profile element parameters with an option to extend these categories narrower only.

Proposed solution

On a recent masterclass on INSPIRE practices in the Soil domain for soil institutes it was suggested to add a 4th category; 'descriptive parameters', which would be able to capture observations from the field, not from a lab. Such as mottle %, mottle size, color, stoniness etc. Another option here would be to allow the codelist to be extended at the rootlevel (relieve the requirement to be narrower then the 3 categories).

Pull request

Additional information

Relevant legislation

Impact on IR

Impact on INSPIRE validator

Linked issue

Impact on INSPIRE code lists

The population of this section of the registry is currently quite limited, no impact is expected.

Linked issue

INSPIRE-MIF/helpdesk#143

Change proposer

• Paul van Genuchten, ISRIC - World Soil Information, EJP Soil
• Fenny van Egmond, Wageningen Environmental Research, EJP Soil

References

Change proposal description

This change proposal is the outcome of the work done in https://github.com/INSPIRE-MIF/gp-data-service-linking-simplification/ that relates to the WMS implementation in the TG View.

Addressed TG

Technical Guidance for the implementation of INSPIRE View Services

Location

Section 4.2.3.3.1. View service metadata

Issue faced

Section 4.2.3.3.1. View service metadata has to be updated to contain a third scenario, in which the View Service metadata elements are published in the WMS capabilities without using the ExtendedCapabilities part.

Proposed solution

Update Implementation Requirement 6 to give the choice between the three scenarios, and make it refer to table 3(a) and a new table 3b, meaning that Implementation Requirement 6 will tell how the INSPIRE metadata elements shall be mapped. This also means that the subsequent requirements requiring a certain mapping are redundant. Therefore, only the subsequent requirements that set requirements for the value of the metadata element are kept.

• Update: req 6, 8, 11, 14, 15, 16, 20, 24, 26, 27, 29
• Remove: req 7, 9, 10, 12, 13, 17, 18, 19, 21, 22, 23, 25, 28, rec 3.
• Add table 3b, rename table 3 to table 3a.

Pull request

#109

Additional information

Relevant legislation

Get View Service Metadata operation

Impact on IR

No impact.

Impact on INSPIRE validator

This affects Conformance class: INSPIRE Profile of WMS 1.3.0 / ISO 19128. The validator will have to take the 3rd scenario into account. The division in different tests can be kept, many of them have to be changed

• to reference req 6 instead of one of the proposed removed requirements
• to take the 3rd scenario into account

Linked issue

INSPIRE-MIF/helpdesk-validator#1098

Impact on INSPIRE XML schemas

No impact.

Impact on INSPIRE code lists

No impact.

Change proposer

Subgroup 2.3.2 (Data and Service Linking simplification)

References

• https://github.com/INSPIRE-MIF/gp-data-service-linking-simplification/
• https://inspire.ec.europa.eu/good-practice/data-service-linking-simplification

Change proposal description

This change proposal is the outcome of the work done in https://github.com/INSPIRE-MIF/gp-data-service-linking-simplification/ that relates to the TG Metadata.

Addressed TG

Technical Guidance for the implementation of INSPIRE dataset and service metadata based on ISO/TS 19139:2007

Location

Section 1.4. Position and structure of this document

Section 3. Conformance Classes for data sets

Section 4.1. Baseline metadata for Spatial Data Services

Issue faced

Section 3. Conformance Classes for data sets has to be updated to contain an additional conformance class, “INSPIRE data sets and data set series linked service metadata”.

In section 1.4. Position and structure of this document, it should be clarified that service metadata can be made in accordance with other TGs.

In section 4.1. Baseline metadata for Spatial Data Services, TG Requirement 3.6 has to be updated, and two recommendations have to be added.

Proposed solution

Update TG as proposed by the Subgroup 2.3.2 (Data and Service Linking simplification).

Pull request

#107

Additional information

Relevant legislation

IR metadata

Impact on IR

No impact.

Impact on INSPIRE validator

The abstract and executable test suite have to be updated.

Linked issue

inspire-eu-validation/INSPIRE-Validator-UI#53

Impact on INSPIRE XML schemas

No impact.

Impact on INSPIRE code lists

No impact.

Change proposer

Subgroup 2.3.2 (Data and Service Linking simplification)

References

• https://github.com/INSPIRE-MIF/gp-data-service-linking-simplification/
• https://inspire.ec.europa.eu/good-practice/data-service-linking-simplification

Change proposal description

The number of recommendation metadata/2.0/rec/common/use-anchors-for-thesauri is not correct.

Addressed TG

TG metadata

Location

3.2. Originating controlled vocabulary

Issue faced

Proposed solution

Change the number to C.9

Pull request

#113

Additional information

Relevant legislation

IR metadata

Impact on IR

N/A

Impact on INSPIRE validator

This is a recommendation, so no impact.

Linked issue

N/A

Impact on INSPIRE XML schemas

N/A

Linked issue

N/A

Impact on INSPIRE code lists

N/A

Linked issue

N/A

Change proposer

Heidi Vanparys, Danish Agency for Data Supply and Infrastructure

References

N/A

While the guidelines correctly mention the "gco:Distance" class, it is mentionned as "gco:distance" in the examples.

Change proposal description

I suggest to fix the issue which occurs multiple times in the examples, and capitalize the "gco:Distance" class wherever it should be.

Addressed TG

Technical Guidance for the implementation of INSPIRE dataset and service
metadata based on ISO/TS 19139:2007

Location

Section 3.1.2.3: Spatial resolution
Examples 3.4 and 3.5 (page 70-71)

##Screenshot of: TG Requirement 1.5: metadata/2.0/req/datasets-and-series/spatial-resolution (page 70)

##Screenshot of example 3.5 (page 71)

Change proposal description

This issue collects some Pull Requests related to fixing typos and improving the general formatting.

Addressed TG

https://github.com/INSPIRE-MIF/technical-guidelines/blob/main/metadata/metadata-iso19139/metadata-iso19139.adoc

Changes Implemented

• Improved general formatting
• Changed names of xml elements in the xml snippets
• Introduced correct Annex numeration
• Added page break for pdf conversion

Pull requests

• #64
• #39
• #40

Change proposal description

According to the Hydrography Technical Guidelines, section 11.1 Layers to be provided by INSPIRE view services, one of the keywords for the layer "HY.PhysicalWaters.ManMadeObject" is supposed to be "Dick".

We believe this should be "Dyke" as per the Inspire Gemet Keywords list: https://www.eionet.europa.eu/gemet/en/concept/2393

Addressed TG

https://inspire.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_HY_v3.1.pdf

Location

https://inspire.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_HY_v3.1.pdf
The table in: section 11.1 Layers to be provided by INSPIRE view services
Specifically the Keywords for the layer HY.PhysicalWaters.ManMadeObject

Issue faced

Dick has a very different meaning than Dyke and this looks wrong on our view services.
As such we have already changed our services to use Dyke instead of Dick and we have seen that other countries have done the same.
At the moment the validator doesn't check keywords for view services, but in the future if the validator is going to validate these keywords and the validator follows the technical guidance rules our services would fail.

Proposed solution

Update the table to change "Dick" to "Dyke"

Pull request

Not available as the TG is not yet available in the repository.

Change proposal description

This change proposal is the outcome of the work done in https://github.com/INSPIRE-MIF/gp-data-service-linking-simplification/ that relates to the WFS implementation in the TG Download.

Addressed TG

Technical Guidance for the implementation of INSPIRE Download Services

Location

Section 6.6 Publishing INSPIRE metadata using ows:ExtendedCapabilities.

Issue faced

Section 6.6 Publishing INSPIRE metadata using ows:ExtendedCapabilities has to be updated to contain a third option (also called scenario), in which the Download Service metadata elements are published in the WFS capabilities without using the ows:ExtendedCapabilities part.

Proposed solution

See pull request.

Pull request

#111

Additional information

Relevant legislation

Get Download Service Metadata operation

Impact on IR

No impact.

Impact on INSPIRE validator

The validator has to take into account scenario 3.

Linked issue

N/A

Impact on INSPIRE XML schemas

No impact.

Impact on INSPIRE code lists

No impact.

Change proposer

Subgroup 2.3.2 (Data and Service Linking simplification)

References

• https://github.com/INSPIRE-MIF/gp-data-service-linking-simplification
• https://inspire.ec.europa.eu/good-practice/data-service-linking-simplification

The NS IRs simply require a Name parameter as part of the layer metadata response parameters in a Get View Service Metadata response.
The View Services TG adds a requirement coming from another IR:

So, the second part of this requirement does not originate in the NS IRs, but in the IR-ISDSS, even if the only way to check this requirement, is through the view service.

Since there is a long discussion about this requirement and the related test in the INSPIRE Reference Validator, we propose to amend the TG requirement to separate the requirements coming from different IRs.

The proposed change is:

4.2.3.3.4.6 NAME
The name of the layer.

NOTE The layer name can be “as is”, in case the data served are not harmonised according to [INS DS], or the harmonised layer names defined in Article 14 of [INS DS] for all INSPIRE spatial data themes and spatial object types.

Implementation Requirement 39 Name shall be mapped with the <wms:Name> element.

The test related to the IR-ISDSS requirement could be added as a separated conformance class to the ETS for view services (similar to the way that this is being done for the metadata requirements for interoperability based on requirements in the IR-ISDSS).

Change proposal description

This change proposal is the outcome of the work done in https://github.com/INSPIRE-MIF/gp-data-service-linking-simplification/ that relates to the Atom implementation in the TG Download.

Addressed TG

Technical Guidance for the implementation of INSPIRE Download Services

Location

Section 5.1, Atom “Download Service Feed” containing an entry for a Pre-defined dataset. The main changes will occur in section 5.1.3 Download Service Feed: feed “link” element – service metadata, but other sections have to be updated consequentially.

Issue faced

Section 5.1.3 Download Service Feed: feed “link” element – service metadata should be updated to contain a second option (also called scenario), in which the Download Service metadata elements are published only in the download service feed, not in a metadata record in a discovery service.

Proposed solution

1 – Update TG Requirement 6 from

(see also https://github.com/inspire-eu-validation/download-atom/blob/3.1/atom-pre-defined/download-service-feed-link-to-metadata-record.md).

to

The INSPIRE Metadata for the Download Service shall be linked to in one of the following ways:

1. The Download Service Feed shall contain an Atom link element that links to the metadata record for this Download Service. The value of the rel attribute of this element shall be describedby and the value of the type attribute shall be either application/xml or application/vnd.ogc.csw.GetRecordByIdResponse_xml;
2. The Download Service Feed shall contain the INSPIRE Metadata for the Download Service in accordance with Table 17b.

and add table 17b to show the mapping of the INSPIRE Metadata elements.

Pull request

#104

Additional information

Relevant legislation

Get Download Service Metadata operation

Impact on IR

No impact.

Impact on INSPIRE validator

This impacts test Download service feed: Provide link to metadata record for the download service.

Linked issue

N/A

Impact on INSPIRE XML schemas

No impact.

Impact on INSPIRE code lists

No impact.

Change proposer

Subgroup 2.3.2 (Data and Service Linking simplification)

References

• https://github.com/INSPIRE-MIF/gp-data-service-linking-simplification
• INSPIRE-MIF/gp-data-service-linking-simplification#63
• https://inspire.ec.europa.eu/good-practice/data-service-linking-simplification

Change proposal description

I noticed that the TG metadata refers to two metadata record examples which can be found via https://inspire.ec.europa.eu/id/document/tg/metadata-iso19139/2.0/examples. Those should be added to the GitHub repo as well to allow for updates, when needed.
The link to the place with examples of compliant metadata records should be changed from https://inspire.ec.europa.eu/id/document/tg/metadata-iso19139/2.0/examples to https://github.com/INSPIRE-MIF/helpdesk-validator/tree/master/examples

Addressed TG

TG metadata

Location

Annex G Examples of complete INSPIRE metadata records.

Issue faced

When looking at INSPIRE-MIF/helpdesk#69, I noticed that the TG metadata refers to two metadata record examples which can be found via https://inspire.ec.europa.eu/id/document/tg/metadata-iso19139/2.0/examples. If we want to update those metadata records to illustrate the possible use of gmd:metadataStandardName and gmd:metadataStandardVersion, it would be best if those examples are on GitHub as well.

The link to the place with examples of compliant metadata records should be changed from https://inspire.ec.europa.eu/id/document/tg/metadata-iso19139/2.0/examples to https://github.com/INSPIRE-MIF/helpdesk-validator/tree/master/examples, as the latter is where the examples are maintained.

Proposed solution

Add the examples to GitHub as well.
Update the link.

Pull request

#22

N/A

Additional information

Kind of issue

editorial

Relevant legislation

N/A

Impact on IR

N/A

Impact on INSPIRE validator

N/A

Linked issue

N/A

Impact on INSPIRE XML schemas

N/A

Linked issue

N/A

Impact on INSPIRE code lists

N/A

Linked issue

N/A

Change proposer

Heidi Vanparys, helpdesk facilitator

References

INSPIRE-MIF/helpdesk#69

Change proposal description

Improve consistency between TG Requirement 2.2: metadata/2.0/req/isdss/crs-id and Example 3.13 in inspire-tg-metadata-iso19139-2.0.1

Addressed TG

Technical Guidance for the implementation of INSPIRE dataset and service metadata based on ISO/TS 19139:2007

Location

inspire-tg-metadata-iso19139-2.0.1

• TG Requirement 2.2: metadata/2.0/req/isdss/crs-id
• Example 3.13
• TG Requirement 6.2: metadata/2.0/req/sds-interoperable/crs-http-uris
• Table C.3.1

Issue faced

In the Metadata Technical Guidance (inspire-tg-metadata-iso19139-2.0.1), the requirements for specifying coordinate reference systems that are INSPIRE defaults CRSs do not line up well with the examples given.

The requirements both state that the "value of the HTTP URI Identifier column shall be used as the value of the ... gmd:code element", but Example 3.13 sensibly places this as the href of a gmx:Anchor, and provides other text (the well known "EPSG::4258") as the actual value of the element.

Proposed solution

Using wording similar to TG Recommendation C.8: metadata/2.0/rec/common/use-anchors-for-cv-keywords, the requirements (TG Requirement 2.2: metadata/2.0/req/isdss/crs-id and TG Requirement 6.2: metadata/2.0/req/sds-interoperable/crs-http-uris) could be restated as something like:

If the coordinate reference system is listed in the table Default Coordinate Reference System Identifiers in Annex D.4, the gmd:referenceSystemInfo/gmd:MD_ReferenceSystem/gmd:referenceSystemIdentifier/gmd:RS_Identifier/gmd:code element shall be encoded using a gmd:keyword/gmx:Anchor element. The xlink:href attribute of the gmx:Anchor element shall be the value of the HTTP URI Identifier column.

Note: should the Short name from the table in D.4 be encouraged, so as to separate between the various ETRS89s? Or (as per the example), the EPSG code in its simpler form?

Pull request

Additional information

Kind of issue

Undecided

Relevant legislation

None?

Impact on IR

I believe this only impacts that TG.

Impact on INSPIRE validator

I don't believe this would impact the validator.

Linked issue

Impact on INSPIRE XML schemas

I don't believe this impacts the XML schemas

Linked issue

Impact on INSPIRE code lists

I don't believe this impacts the INSPIRE code lists

Linked issue

Change proposer

Peter Parslow

References

Dear all,
The INSPIRE Metadata Implementing Rules requires electronicMailAddress as mandatory (within the contactInfo element), but some organisations provide contact forms (https...) instead of e-mail addresses, probably to avoid spam and/or to improve message management.
The ISO 19115 allows onlineResource as another way to contact the organisation (besides e-mail, postal address, etc.).
We propose to expand the INSPIRE Metadata Implementing Rules to this option, as a possible alternative to the electronicMailAddress for that cases where organisations do not have e-mail but contact forms. This means using electronicMailAddress OR onlineResource in contactInfo.
Thanks,

Change description

The PS data model was completely revised, with the following major changes:

• the name of the inspire identifier attribute was harmonised with the other TGs
• a thematic identifier element to the ProtectedSite feature type was added
• legalFoundationDate element value type was changed to 'Date'
• the multiplicity of the elements legalFoundationDate and legalFoundationDocument was changed, to support providing the dates and founding documents corresponding to several designations of the same spatial object.

Implementation of changes

Old structure:

New structure:

Old data type:

New data type:

Relevant legislation

Commission Regulation (EU) 2023/2431 of 24 October 2023 amending Regulation (EU) No 1089/2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services

Consolidated text: Commission Regulation (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services

Additional information

Impact on INSPIRE validator

No impact.

Impact on INSPIRE XML schemas

Yes

Linked issues

PS_ProtectedSite_rename inspireID to inspireId #13
PS_ProtectedSite_thematicId +LegalFoundationDate to 'Date' + LegalFoundationDate and LegalFoundationDocument moved to DesignationType data type #14

Impact on INSPIRE UML

Yes

Impact on INSPIRE Registry

Yes, the definition of the DesignationValue codelist was changed.

Linked issue

INSPIRE-MIF/helpdesk-registry#90

Dear,

I noticed a content mistake in the metadata TG 2.0. At page 44, in the data quality section info (concerning dataquality of the INSPIRE datasets) the footnote 40 clearly states thaht one should use codeListValue "service" which is a mistake. One should use "dataset" instead.

I don't know if you have an internal mistake registry concerning TG 2.0 but I report that problem for an eventual 2.01 version.

Regards,

The link to the changelog for the "Technical Guidance for the implementation of INSPIRE dataset and service metadata based on ISO/TS 19139:2007" points to https://github.com/INSPIRE-MIF/technical-guidelines/releases/tag/2023.1 instead of https://github.com/INSPIRE-MIF/technical-guidelines/releases/tag/v2023.1 causing an error when trying to access it.
This refers to all the three versions of the document (AsciiDoc, HTML, PDF) available from https://github.com/INSPIRE-MIF/technical-guidelines/tree/main/metadata/metadata-iso19139

Change proposal description

The TG Metadata has been updated with the recent release 2023.1 of the technical guidance documents. But date of publication and status in the document information section were not updated accordingly.

Addressed TG

Technical Guidance for the implementation of INSPIRE dataset and service metadata based on ISO/TS 19139:2007

Location

Document information section

Issue faced

see change proposal description

Proposed solution

date of publication = 2023-01-31
status = 2.1.2

Pull request

Additional information

Relevant legislation

Impact on IR

no impact

Impact on INSPIRE validator

no impact

Linked issue

Impact on INSPIRE XML schemas

no impact

Linked issue

Impact on INSPIRE code lists

no impact

Linked issue

Change proposer

Daniela Hogrebe (member of MIG-T and governance-sub-group)

References

Change proposal description

Given the rise of web forms as a primary mechanism for contacting organisations, can we move away from insisting on an email address? We would have to replace this with a more complex/subtle requirement that either an email address or the URL of a web contact form has to be given.

Addressed TG

Metadata

Location

TG Requirement C.6: metadata/2.0/req/common/md-point-of-contact and TG Requirement C.10: metadata/2.0/req/common/responsible-organisation

Issue faced

Organisations are tending away from encouraging email contact towards the use of web forms, so that enquiries are entered straight into an incident management system. By insisting on providing email addresses, INSPIRE is behind the curve on this.

Proposed solution

Pull request

Additional information

Relevant legislation

Unfortunately, this is also a requirement in the Regulation: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32008R1205&rid=1 clause 9.1 and 10.1

Impact on IR

Unfortunately, this is also a requirement in the Regulation: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32008R1205&rid=1 clause 9.1 and 10.1

Impact on INSPIRE validator

Would also need amendment

Linked issue

Impact on INSPIRE XML schemas

None

Linked issue

Impact on INSPIRE code lists

None

Linked issue

Change proposer

Peter Parslow, Ordnance Survey Great Britain

References

Change proposal description

In the Technical Guidance for the implementation of INSPIRE dataset and service metadata based on ISO/TS 19139:2007 in section 4.4.3.1. Minimum estimated Quality of Service/Table 4.2 multiple references are made to incorrect codelist URL's: http://inspire.ec.europa.eu/metadata-codelist/QualityOfServiceCriteriaCode. The correct codelist URL should be:

http://inspire.ec.europa.eu/metadata-codelist/QualityOfServiceCriteria

Addressed TG

Technical Guidance for the implementation of INSPIRE dataset and service metadata based on ISO/TS 19139:2007

Location

4.4.3.1. Minimum estimated Quality of Service/Table 4.2

Issue faced

See Change proposal description.

Proposed solution

Replace http://inspire.ec.europa.eu/metadata-codelist/QualityOfServiceCriteriaCode with http://inspire.ec.europa.eu/metadata-codelist/QualityOfServiceCriteria in 4.4.3.1. Minimum estimated Quality of Service/Table 4.2.

Pull request

#78

Additional information

Relevant legislation

Impact on IR

Impact on INSPIRE validator

AFAIK the INSPIRE validator already uses the correct codelist URL's.

Linked issue

See INSPIRE-MIF/helpdesk-validator#880.

Impact on INSPIRE XML schemas

Linked issue

Impact on INSPIRE code lists

Linked issue

Change proposer

@arbakker - Kadaster (NL)

References

Change proposal description

I propose to relax the mime-type requirement TG Requirement 2 - TG for Download Services for ATOM feed resources to allow application/xml as well as application/atom+xml (currently the only allowed mime-type).

I previously opened an issue at the helpdesk-validator, but it was suggested to open an issue here.

Addressed TG

Technical Guidance for the implementation of INSPIRE Download Services

Location

TG Requirement 2 - Technical Guidance for the implementation of INSPIRE Download Services :

The relevant part of the ATOM RFC 4287:

There are no other parts in the ATOM RFC 4287 about the mime-type for feed resources.

The ATOM RFC 4287 is interpreted by the ETF validator as a requirement for using only application/atom+xml as mime-type for ATOM feed resources. However I would argue that the ATOM RFC 4287 does not set an explicit requirement for the used mime-type and would allow for using application/xml as mime-type for ATOM feed resources.

Issue faced

Mostly copy-paste from INSPIRE-MIF/helpdesk-validator#661 with some edits:

The problem I am facing with this requirement is that the mime-type application/atom+xml is not recognized as an XML format by most browsers. This is the case for at least Chromium based browsers (Google Chrome, MS Edge and more) and Firefox, which represents a significant usage share of web browsers in use currently. Bug reports on this issue have been open for years, so probably will not be fixed any time soon:

• Firefox - Opened 20 years ago
• Chromium - Opened 10 years ago

A consequence of browsers failing to recognize the mime-type application/atom+xml as an XML based format is that browsers do not render the ATOM feed with XML syntax highlighting. Which reduces the user experience of consuming the ATOM feeds directly in a web browser:

An additional consequence is that the browser XSLTProcessor API does not work as well. We use this feature to let the browser render the ATOM XML feeds into a user-friendly HTML output, see for instance Download Service van BRO Wandonderzoek. This works through including an XSL stylesheet in the ATOM feed:

<?xml-stylesheet href="https://service.pdok.nl/atom/style/style.xsl" type="text/xsl" media="screen"?>

This way we can direct users directly to our ATOM services, but this only works if the browser thinks it is dealing with a XML based resource. I am aware the ATOM protocol is mostly intended for machine-to-machine consumption, however I want to argue that facilitating human-to-machine consumption for ATOM services will lower the barrier to entry to these services. Therefore I am proposing to allow usage of application/xml mime-type for ATOM feed resources.

Also I wonder whether the ATOM RFC 4287 is normative on the usage of the application/atom+xml mime-type since it states:

An Atom Document, when serialized as XML 1.0, can be identified with
the following media type:

MIME media type name: application
MIME subtype name: atom+xml

If this is the case , namely application/atom+xml is not required per RFC, then the TG for Download Services does not need a change, then the issue lies with the helpdesk-validator team.

If this is not the case, namely application/atom+xml is required per RFC, then the TG for Download Services would need to explicitly allow for the usage of application/xml, considering it reflects current practices in publishing ATOM feeds and stimulates the usage of ATOM services.

Proposed solution

Explicitly allow for the usage of the following mime-types for ATOM feed resources:

• application/xml
• application/atom+xml

Provided the ATOM RFC does not already allow for this.

Pull request

None, awaiting feedback proposal.

Additional information

None.

Relevant legislation

None.

Impact on IR

No impact, considering it proposes a relaxation of a requirement.

Impact on INSPIRE validator

INSPIRE validator would need to be changed to also allow the mime-type application/xml for ATOM feed resources (besides the already allowed mime-type application/atom+xml.

Linked issue

INSPIRE-MIF/helpdesk-validator#661

Impact on INSPIRE XML schemas

None.

Impact on INSPIRE code lists

None.

Change proposer

anton.bakker[at]kadaster.nl

References

• Bug report Firefox - Opened 20 years ago
• Bug report Chromium - Opened 10 years ago
• ATOM RFC 4287
• Technical Guidance for the implementation of INSPIRE Download Services

Change proposal description

Add/update the URLs where reports [EUR 19575 EN], [EUR 20120 EN] and [EUR 21494 EN] can be found. Update the text to refer to these reports using their labels in the bibliography.

Addressed TG

Geographical Grid Systems

Location

Issue faced

The same issue as for #9.

In addition, the link mentioned on page 6 of the GG data specification, http://www.eionet.eu.int/gis, doesn't work either.

Proposed solution

The same proposed solution as for #9.

Additional information

The same information as for #9.

Dear

I hope you are all right.

As I wrote here I noticed that administrativeUnit relation is missing from UML graphes of both CadastralParcel featurey type and BasicPropertyUnit thuough they are specified by Regulation 1089/2010 and by textual descriptions of CP - Technical Guidelines.

In the same kind of idea I noticed that the GeographicalName class that should be instancied in CadastralZoning is not shown on the UML grpah.

Could I suggest to add both of them in all the concerned classes?

Moreover I noticed the same problem here but I don't know if these data models are meant to be updated or not.

Regards,

Change proposal description

The namespace component of the dataset identifier is optional, the requirements in the TG Download should reflect this.

Addressed TG

Technical Guidance for the implementation of INSPIRE Download Services

Location

Make spatial_dataset_identifier_namespace optional in requirements 13, 42, 43, 44, 50 and 51.

Issue faced

The namespace component of the dataset identifier is optional, in fact it is actually recommended to have a dataset identifier that is encoded in one string, containing both namespace and code, see https://inspire-mif.github.io/technical-guidelines/metadata/metadata-iso19139/metadata-iso19139.html#_unique_resource_identifier. The requirements in the TG Download do not reflect this.

Proposed solution

Update of the TG requirements 13, 42, 43, 44, 50 and 51 and the surrounding text, see pull request.

Pull request

#83

Additional information

Relevant legislation

https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008R1205-20081224

Impact on IR

N/A

Impact on INSPIRE validator

Impact on:

• http://inspire.ec.europa.eu/id/ats/download-atom/3.1/atom-pre-defined/download-service-feed-dataset-identifiers (req 13)
• https://github.com/inspire-eu-validation/download-atom/blob/3.1/atom-pre-defined/opensearch-description-url-describe-spatial-dataset-operation.md (req 42)
• https://github.com/inspire-eu-validation/download-atom/blob/3.1/atom-pre-defined/opensearch-description-one-url-get-spatial-dataset-operation.md (req 43)
• https://github.com/inspire-eu-validation/download-atom/blob/3.1/atom-pre-defined/opensearch-description-query-examples-for-each-dataset.md (req 44)
• http://inspire.ec.europa.eu/id/ats/download-wfs/3.1/wfs-pre-defined/predefined-stored-query (req 50, 51)

Linked issue

INSPIRE-MIF/helpdesk-validator#124
inspire-eu-validation/download-service#89

Impact on INSPIRE XML schemas

N/A

Impact on INSPIRE code lists

N/A

Change proposer

Heidi Vanparys, Danish Agency for Data Supply and Infrastructure

References

N/A

Change proposal description

In an atom, there should be an attribute to encode the resolution of a raster.

Addressed TG

Technical Guidance for the implementation of INSPIRE Download
Services

Location

Chapter 5 : Atom Implementation of Pre-defined Dataset Download Service

Issue faced

We have rasters available in different resolutions and wish to encode that information in a single atom.

Proposed solution

Either an attribute in or an attribute in to allow for the resolution to be encoded.

Pull request

Additional information

Relevant legislation

In the annex of the COMMISSION REGULATION (EC) No 1205/2008, table 1, the multiplicity for "spatial resolution" (6.2) is 0..*, so it should be possible to encode several resolution in which a dataset is available in an atom.

Impact on IR

Impact on INSPIRE validator

Linked issue

Impact on INSPIRE XML schemas

Linked issue

Impact on INSPIRE code lists

Linked issue

Change proposer

Thomas Ruhl, for the Brussels Region, Belgium.

References