inspire-mif / technical-guidelines Goto Github PK
View Code? Open in Web Editor NEWCommunity for the discussion of change proposals to the INSPIRE Technical Guidance documents.
Home Page: https://inspire-mif.github.io/technical-guidelines
Community for the discussion of change proposals to the INSPIRE Technical Guidance documents.
Home Page: https://inspire-mif.github.io/technical-guidelines
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.
D2.8.III.2 Data Specification on Buildings – Technical Guidelines
Section 10.2.1 and 10.2.2
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.
Replace "BU.Building.default" with "BU.Building.Default"
editorial
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.
INSPIRE-MIF/helpdesk-validator#626 (comment)
Johanna Ott
wetransform GmbH
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"
Data Specification on Agricultural and Aquaculture Facilities – Technical Guidelines
chapter 11
Should be aligned with values expected by validator
Change AF.Sites to AF.Site, change AF.AgriculturalHolding to AF.AgriculturalHolding.Default, change AF.Site to AF.Site.Default.
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.
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
The CRS-s should become valid values.
The CRS-s should become valid values.
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
Fix typos in the numbering of TG recommendations
http://inspire.ec.europa.eu/id/document/tg/metadata-iso19139/2.1.0
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).
Update numbering of all TG Recommendations to ensure consistency
To be provided
For all data specifications: replace the code list descriptions with a link to the code list in the INSPIRE registry.
All data specifications.
This will impact sections 5.3.2 "Feature catalogue" and Annex C "Code list values".
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.
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.
TBD when all the data specifications are on GitHub.
Technical issue
"Common code lists" in the IR on the interoperability of spatial data sets and services
No impact.
No impact.
N/A
No impact.
N/A
No impact
N/A
Heidi Vanparys, helpdesk facilitator.
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.
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.
Technical Guidance for the implementation of INSPIRE View Services
Section 4.2.3.3.1. View service metadata
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.
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.
Get View Service Metadata operation
No impact.
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
INSPIRE-MIF/helpdesk-validator#1098
No impact.
No impact.
Subgroup 2.3.2 (Data and Service Linking simplification)
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.
Technical Guidance for the implementation of INSPIRE dataset and service metadata based on ISO/TS 19139:2007
Document information section
see change proposal description
date of publication = 2023-01-31
status = 2.1.2
no impact
no impact
no impact
no impact
Daniela Hogrebe (member of MIG-T and governance-sub-group)
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.
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
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.
Update TG as proposed by the Subgroup 2.3.2 (Data and Service Linking simplification).
No impact.
The abstract and executable test suite have to be updated.
inspire-eu-validation/INSPIRE-Validator-UI#53
No impact.
No impact.
Subgroup 2.3.2 (Data and Service Linking simplification)
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 PS data model was completely revised, with the following major changes:
No impact.
Yes
PS_ProtectedSite_rename inspireID to inspireId #13
PS_ProtectedSite_thematicId +LegalFoundationDate to 'Date' + LegalFoundationDate and LegalFoundationDocument moved to DesignationType data type #14
Yes
Yes, the definition of the DesignationValue codelist was changed.
This issue collects some Pull Requests related to fixing typos and improving the general formatting.
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.
Technical Guidance for the implementation of INSPIRE Download Services
Section 6.6 Publishing INSPIRE metadata using ows:ExtendedCapabilities.
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.
See pull request.
Get Download Service Metadata operation
No impact.
The validator has to take into account scenario 3.
N/A
No impact.
No impact.
Subgroup 2.3.2 (Data and Service Linking simplification)
The namespace component of the dataset identifier is optional, the requirements in the TG Download should reflect this.
Technical Guidance for the implementation of INSPIRE Download Services
Make spatial_dataset_identifier_namespace optional in requirements 13, 42, 43, 44, 50 and 51.
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.
Update of the TG requirements 13, 42, 43, 44, 50 and 51 and the surrounding text, see pull request.
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008R1205-20081224
N/A
Impact on:
INSPIRE-MIF/helpdesk-validator#124
inspire-eu-validation/download-service#89
N/A
N/A
Heidi Vanparys, Danish Agency for Data Supply and Infrastructure
N/A
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,
While the guidelines correctly mention the "gco:Distance" class, it is mentionned as "gco:distance" in the examples.
I suggest to fix the issue which occurs multiple times in the examples, and capitalize the "gco:Distance" class wherever it should be.
Technical Guidance for the implementation of INSPIRE dataset and service
metadata based on ISO/TS 19139:2007
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)
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.
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, ...)
EF
Some concepts in INSPIRE:EF were specific to the INSPIRE activity.
They are now included in the International Standard (IS)
Updating to the revision of the IS will enhance interoperability
No PR yet, a group activity is required
Will need to be checked by the upcoming group
Will need to be checked by the upcoming group
INSPIRE O&M guidelines will also need to be updated accordingly -> another issue needs to be created here
Will need to be checked by the upcoming group
Will need to be checked by the upcoming group
Sylvain Grellet - BRGM
Links to the revised ISO spec will be available soon
Technical Guidance for the implementation of INSPIRE dataset and service metadata based on ISO/TS 19139:2007 (Version 2.0.1)
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:
update all footnote to e.g. Attribute codeList can e.g. containt ...
or Attribute codeList may e.g. point to ...
Currently not possible.
editorial
no impact on the Implementing Regulation
quote in the footnotes of the TG MD "Attribute codeList shall be …"
no impact on INSPIRE XML schemas
not relevant
no impact on INSPIRE code lists content
not relevant
Coordination Office SDI Germany | Federal Agency for Cartography and Geodesy
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.
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.
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
Not available as the TG is not yet available in the repository.
editorial
no impact
no impact
endlifespanVersion shall be updated to 0..1 in ElevationGridCoverage , ElevationTIN and ElevationVectorElements application schemas
INSPIRE-MIF/application-schemas#42
no impact
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.
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
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.
D2.8.II.4 INSPIRE Data Specification on Geology – Technical Guidelines
Section "5.3.2.1.4. GeologicCollection"
There is an inconsistency between documentation (TG and UML) and the XSD application schema.
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.
Not available
editorial
No
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).
INSPIRE-MIF/helpdesk-validator#625
No, the multiplicity in the schema is already 0..*.
No
JRC
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.
All data specifications.
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.
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.
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.
TBD for each data specification available on GitHub.
Technical issue
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.
INSPIRE-MIF/helpdesk-validator#1066
No impact.
N/A
A coordinate systems register shall be created in the INSPIRE Registry, replacing the temporary table created in the helpdesk repository.
INSPIRE-MIF/helpdesk-registry#75
INSPIRE Support team.
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.
INSPIRE Metadata Implementing Rules: Technical Guidelines, maybe also Reporting guidance documents if they are stating content concerning the validator
Technical Guidance C.2.27 Metadata language, to also include “Norwegian“ and “Icelandic” as a part of the domain.
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.
See above
We dould kind ask for information through the process
TECHNICAL
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
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.
See above. Impact on acccepted NOR and ICE + localised languages
There is alerady an issue raised,
see above
INSPIRE-MIF/helpdesk-validator#327
Arvid Lillethun, Norwegian Mapping Authority
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.
Data Specification on Statistical Units - Technical Guidelines
Data Specification on Statistical Units - Technical Guidelines
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.
Update UML diagram mentioned above and/or add a constraint on AreaStatisticalUnit.
Not available as the TG is not yet available in the repository.
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.
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).
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'.
TN
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).
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'.
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
4.4.3.1. Minimum estimated Quality of Service/Table 4.2
See Change proposal description.
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.
AFAIK the INSPIRE validator already uses the correct codelist URL's.
See INSPIRE-MIF/helpdesk-validator#880.
@arbakker - Kadaster (NL)
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.
Metadata
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
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.
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
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
Would also need amendment
None
None
Peter Parslow, Ordnance Survey Great Britain
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.
TG Metadata 2.0.1
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.
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".
Changes as described above & in the pull request.
I can only find the two TG Requirement ones in metadata-iso19139.adoc, not the footnotes or table that I see in the PDF.
None
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.
None
None
Peter Parslow
This is a placeholder for the issue that was mentioned in #2 (comment).
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.
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:
Not available as the TG is not yet available in the repository.
editorial
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).
No impact.
No impact
No impact.
No impact.
Heidi Vanparys
N/A
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 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.).
A test for the new geometry constraint shall be added.
INSPIRE-MIF/helpdesk-validator#1052
The data type of the geometry attribute of the DrainageBasin feature type shall be changed from "GM_Surface" to "GM_Object".
INSPIRE-MIF/application-schemas#84
Yes
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"."
Technical Guidance for the implementation of INSPIRE dataset and service metadata based on ISO/TS 19139:2007 Version 2.0.1
TG Requirement C.15 in section 2.3.5 Using keywords on page 41 of the TG document.
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"
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"
Editorial
May require a loosening of validation checks for MD_Keywords to ensure DateTypeCode of revision and creation are also allowed.
None known
None known
No known linked issues
None
No known linked issues
Sean Gaffney, UK Marine Environmental Data and Information Network and member of AGI GEMINI Working Group
None
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,
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.
D2.8.III.3 Data Specification on Soil – Technical Guidelines
Currently paragraph 53238 lists 3 categories (chemical, physical, biological) of profile element parameters with an option to extend these categories narrower
only.
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).
The population of this section of the registry is currently quite limited, no impact is expected.
In an atom, there should be an attribute to encode the resolution of a raster.
Technical Guidance for the implementation of INSPIRE Download
Services
Chapter 5 : Atom Implementation of Pre-defined Dataset Download Service
We have rasters available in different resolutions and wish to encode that information in a single atom.
Either an attribute in or an attribute in to allow for the resolution to be encoded.
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.
Thomas Ruhl, for the Brussels Region, Belgium.
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.
Figure 11 - on Page 47
In Figure 11 the multiplicity of the soilDerivedObjectObservation association is 1, while in the new version of the soil schema this multiplicity is [1 .. *]
Update Figure 11.
Not available as the TG is not yet available in the repository.
editorial
no impact
no impact
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.
INSPIRE-MIF/application-schemas#8
no impact
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.
https://inspire.ec.europa.eu/id/document/tg/so
Page 1
The number of recommendation metadata/2.0/rec/common/use-anchors-for-thesauri is not correct.
TG metadata
3.2. Originating controlled vocabulary
Change the number to C.9
N/A
This is a recommendation, so no impact.
N/A
N/A
N/A
N/A
N/A
Heidi Vanparys, Danish Agency for Data Supply and Infrastructure
N/A
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.
Technical Guidance for the implementation of INSPIRE Download Services
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.
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.
1 – Update TG Requirement 6 from
to
The INSPIRE Metadata for the Download Service shall be linked to in one of the following ways:
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
;and add table 17b to show the mapping of the INSPIRE Metadata elements.
Get Download Service Metadata operation
No impact.
This impacts test Download service feed: Provide link to metadata record for the download service.
N/A
No impact.
No impact.
Subgroup 2.3.2 (Data and Service Linking simplification)
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.
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.
The same proposed solution as for #9.
The same information as for #9.
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.
Technical Guidance for the implementation of INSPIRE Download Services
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.
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:
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.
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.
None, awaiting feedback proposal.
None.
None.
No impact, considering it proposes a relaxation of a requirement.
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
.
INSPIRE-MIF/helpdesk-validator#661
None.
None.
anton.bakker[at]kadaster.nl
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.
This change has an impact on several parts of the TGs:
Change of the Article 4:
Removal of the enumeration concept from the “Stereotypes” section:
Change of the Article 6:
Removal of the “Enumerations” section from the feature catalogue and conversion of the enumerations into codelists (ONLY TGs which define enumerations):
Removal of any reference to enumeration (if applicable):
Change of the stereotype from “enumeration” to “codeList” in the UML
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.
N/A
Yes, the enumerations shall be removed from the xsd and the datatype of the related attributes need to be changed.
Convert enumerations into codelists_Change from 1089 amendment #89
Yes
Yes, the enumerations shall be converted into codelists.
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
Technical Guidance for the implementation of INSPIRE dataset and service metadata based on ISO/TS 19139:2007
inspire-tg-metadata-iso19139-2.0.1
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.
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?
Undecided
None?
I believe this only impacts that TG.
I don't believe this would impact the validator.
I don't believe this impacts the XML schemas
I don't believe this impacts the INSPIRE code lists
Peter Parslow
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
TG metadata
Annex G Examples of complete INSPIRE metadata records.
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.
Add the examples to GitHub as well.
Update the link.
N/A
editorial
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
Heidi Vanparys, helpdesk facilitator
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.
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
https://inspire.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_HY_v3.1.pdf
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
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.
Update the table to change "Dick" to "Dyke"
Not available as the TG is not yet available in the repository.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.