comments on the DS ATS proposal

[tomasrt]

Hi all, from the reading of the initial assumptions my understanding is that you want to create only one Conformance Class that would cover all current IR CCs also the TG CCs. Plus you will create a generic GML CC to be used by all. If my understanding is correct than I'd like to say that there were at least two reasons for having the DS ATS structured 1-7 IR CCs and TG CC as Nr. 8 (unless there are some theme specific CCs): 1) Giving data providers a possibility to declare confor4mity only to several of the aspects (e.g. OK to Application schema, but maybe not yet OK with the provision of CRS or Values defined by IR codelists etc..) BTW - that finer grinned Conformity was very well received by the MSs 2) the DS ATS structure also follows the structure of the TG documents (Chapters) - Portrayal, CRS, MD for interoperability etc... so it is consistent within the DS TG documents.

My question is therefore what is the benefit of having only one TG CC instead of more? Especialy if (e.g. from eENVPLus project ATS/ETS work-results) we now that it is feasible to create executable schematron scripts to facilitate automation in the most of the CCs currently in DS defined.

[gmartirano]

Hi all, my comment is just related to share my feeling when reading this document.

In order to deal with INSPIRE datasets validation issues, I spent so far some effort attempting to use the content of Annex A of Data Specifications as “the” reference. And after some pain, I succeeded somehow, at least understanding (and agreeing with) the reasoning behind, e.g. the ATS “tree” structure in CCs and abstract tests, and the distinction between IR and TG requirements.

In particular, I believe that this reference is (at least right now) a good starting point to design and implement an ETS which can effectively support data providers aiming at claiming conformance of their datasets, according to the INSPIRE roadmap.

Reading the read.me document, I detect the message that I should change approach, based on several justifications provided. Therefore I feel stimulated to (re)start learning (which is always a good exercise :)), but then I start feeling a bit lost, when I see, for example, that one CC should contain both IR and TG requirements, and when I can’t find anymore any correspondence with the Annex A CCs.

I would definitely need more time to better understand the reasoning of the “new” approach (due to my fault and not to the fact the read.me document is unclear :)). However, I would at least recommend creating a “mapping table” showing correspondences between the “new” tests and the CCs/tests as described in the Annex A of the DS, unless Annex A will be modified accordingly.

[cportele]

@tomasrt

I see the value in being able to distinguish the different aspects in which a spatial data set can conform to the TG. So let me try again to explain why this was not done (I tried that with the text in the readme, but obviously failed 😦):

The current approach has been proposed because

• the "segemented" IR-related conformance classes are not testable (as tests require knowledge about the encoding, which is outside of the IR)
• there is only one TG-related conformance class (per application schema) that is testable
• there are URIs for the existing conformance classes that we need to honour as they are in the TG and may have been used in conformance section of the metadata

Therefore, we have only a single conformance class that we can test for each application schema.

If we say the last of the bullets is not important and we can split the TG conformance class into multiple conformance classes following the split in the IR conformance classes, then we could keep the following conformance classes per application schema:

• schema (standarization target: spatial data set)
• reference systems (standarization target: spatial data set)
• reference systems (standarization target: view service - WMS 1.3)
• data consistency (standarization target: spatial data set)
• data quality (standarization target: metadata record)
• metadata (standarization target: metadata record)
• information accessibility (standarization target: spatial data set)
• portrayal (standarization target: view service - WMS 1.3)

"Encoding" is not in the list as this is implicitly done, partly by the common GML conformance class to which each of the "spatial data set" conformance classes has a dependency.

If we follow this approach, we would need to allocate each of the current test cases to the appropriate conformance class. In some cases we may need to split a test, e.g. https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml-hy-n/gml-hy-n.code-list-values.md partly falls under "schema" and partly under "information accessibility".

So, the question is: Is it important that we keep the single TG conformance class URIs "http://inspire.ec.europa.eu/conformance-class/tg/xx/x.y(.z)" or can we introduce new ones like "http://inspire.ec.europa.eu/conformance-class/tg/xx/x.y(.z)/as", etc.?

[cportele]

@gmartirano Fully understood. See also my response to Robert's comment. Maybe that helps to explain the background for the approach.

As I tried to explain there, I am not opposed to splitting up the conformance classes as done in the IR conformance classes, but as also discussed in the current ATS review an ATS in a TG has to test on the level of the TG, not the IR. Tests against the IR would always have to be manual anyhow as automated tests require selecting an implementation option. And for the TG the current TG specifies only a single conformance class and I was not sure, if we can change that.

Therefore, I have included tests for IR requirements, but on TG level using the default encoding rule, in the TG conformance class. As discussed in the response to Robert's comment, if we can change that and create new TG conformance classes, then we can mostly keep the structure (some changes are necessary as sometimes there is a mix of standardization targets in a single conformance class).

In any case, I agree that we need to document the mapping between the conformance classes and test cases in the current ATS in the TG and whatever approach we end up with in this activity.

PS: For a more detailed reading about requirements, recommendations, conformance classes, standardization targets, etc. see the OGC specification model: https://portal.opengeospatial.org/files/?artifact_id=34762

[tomasrt]

@cportele to the bullet 1and 2) One of the aspect taken into account when developing the ATS structure was the encoding neutrality. I would question that you cannot automate testing of e.g. the required values (e.g. in case of code lists) or geometry test etc... in the ESRI Geodatabase environment using any scripting language Python etc..

to the bullet 3) Well, we can probably check some MD records on the Geoportal, but the point is that we might confuse even more some data providers with a radical change + they would loose the option of providing more grained info on the "Validation status".

• Your proposal for splitting of the one TG CC into more CCs = what is the difference from the current structure apart ? The structure of current ATS - CCs follows the structure of the TG it can also be seen as an handy overview of requirements for data providers.

What about to keep, improved if needed, the ATS and its CC structures (and individual Test cases) as neutral as possible and than have ETS with executable tests for each test case prepared for selected encodings (GML would be the first obviously)?

[cportele]

@tomasrt Unless we change the definition of ATS, CC and ETS, the ETS must test exactly the requirements of the CC.

But let me think about this, maybe we can use the concept of parameterizable conformance classes for this. I.e. the conformance classes can be parameterized with the encoding. For example, the conformance class AS would become AS, AS, etc. If I think this could work I will document the approach in more detail.

[gmartirano]

I start seeing a workable solution, consisting of 1 ATS as much as possible implementation-independent and n ETS implementation-dependent, with ETS-1 related to implementation 1, with implementation 1 consisting of gml encoding, according to TGs.

If this works, then I don’t see any reason to change the actual ATS as defined in the TGs.

Independently from how ETS-1 will be implemented, a clear correspondence between its executable tests and the ATS CCs and related abstract tests should be provided.

I tried to follow this logic reading the tests from A1.1 to A1.7 of CC-1 of HY, and it seems working to me.

Of course I’m curious to see how an ETS-2 would look like, because right now I can’t figure it out :)

[cportele]

@gmartirano @tomasrt

I have now looked at this from two angles:

• I have added in the tables of the test cases in the readme documents a column with a reference to the test cases in the current Hydro ATS (note that the numbering in the annex is quite broken, which may cause confusion).
• I have also extended the proposal for the ATS/CC structure I have started for the rest of the ATSs (see https://github.com/inspire-eu-validation/ats-cross-cutting/issues/16) with an attempt to preserve the current conformance classes as good as possible. This also makes use of the concept of parameterizable conformance classes used for the metadata case. The result is shown below.

For each CC I list the test case (TC) in the structure on GitHub and also identify the section(s) in the current Hydrography TG document that this relates to:

• ATS: TG INSPIRE Data Specification on Hydrography v3.1
  • Notes:
  • This is only supporting the 4.0 schemas for now. If also 3.x needs to be included in the tests, additional CCs for the 3.x schemas are required.
  • The metadata CC is always the same, cannot be changed on a theme-by-theme basis and has a different standardization target. It has therefore been associated with the data specification template document, see https://github.com/inspire-eu-validation/ats-cross-cutting/issues/16. The CC is "Metadata for interoperability - ISO/TS 19139 profile v3.0rc3".
  • The tests related to the "TG CCs" and the Data Delivery CC are basically part of the indirect dependencies, so they can be dropped. If other technical implementation options would be identified, these would become other "Encoding" parameters.
  • As we need to test only features that can occur in a data set, we only need CCs for application schemas with instantiable feature types / spatial object types. I.e., the Hydro Core schema is implicitly covered by the schemas that extend it.
  • Not only the "Application Schema" CC depends in this structure on the specific application schema, but also the other CCs. This seems necessary to minimize the indirect dependencies. But maybe I am getting this wrong - I need to think about this a bit more.
  • CC: Application Schema, Hydrography - Network v3.1
  • Standardization target: Spatial data set
  • Parameter values "Encoding": { "hy-n GML AS 4.0" }
  • Indirect dependency: "hy-n GML AS 4.0"
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml/gml.schema-extensions-not-overlapping.md [A.1.1]
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml/gml.code-list-extensions.md [A.1.3, A.5.1]
    • Note: This TC needs to be split into two, one for this CC and one for the Information Accessibility CC.
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml-hy-n/gml-hy-n.code-list-values.md [A.1.3, A.5.1]
    • Note: This TC needs to be split into two, one for this CC and one for the Information Accessibility CC.
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml-hy-n/gml-hy-n.constraints.md [A.1.6]
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml-hy-n/gml-hy-n.simple-features.md [A.1.7]
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml-hy-n/gml-hy-n.geometry-consistency.md [A.1.7]
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml-hy-n/gml-hy-n.representation-consistency.md [A.1.7]
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml-hy-n/gml-hy-n.link-intersections.md [A.1.7]
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml-hy-n/gml-hy-n.multiple-resolutions.md [A.1.7]
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml-hy-n/gml-hy-n.no-free-nodes.md [A.1.7]
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml-hy-n/gml-hy-n.object-references.md [A.1.8]
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml-hy-n/gml-hy-n.linear-referencing.md [A.1.8]
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml-hy-n/gml-hy-n.delineationKnown.md [A.1.9]
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml-hy-n/gml-hy-n.link-centrelines.md [A.1.10]
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml-hy-n/gml-hy-n.network-connectivity-1.md [A.1.11]
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml-hy-n/gml-hy-n.network-connectivity-2.md [A.1.11]
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml-hy-n/gml-hy-n.network-connectivity-3.md [A.1.11]
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml-hy-n/gml-hy-n.network-connectivity-4.md [A.1.11]
  • Note: A.1.2, A.1.4 and A.1.5 are already covered by the "INSPIRE GML encoding rule 3.3" test
  • CC: hy-n GML AS 4.0
  • Standardization target: XML document with a feature collection (feature schemas: http://inspire.ec.europa.eu/schemas/hy-n/4.0/HydroNetwork.xsd)
  • Dependency: "INSPIRE GML encoding rule 3.3"
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml-hy-n/gml-hy-n.basic-test.md [n/a]
  • CC: Reference Systems, Hydrography - Network v3.1
  • Standardization target: Spatial data set
  • Parameter values "Encoding": { "hy-n GML AS 4.0" }
  • Indirect dependency: "hy-n GML AS 4.0"
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml-hy-n/gml-hy-n.crs.md [A.2.1, A.2.2, A.5.2, A.5.3, A.8.1]
    • Note: This TC needs to be split into two, one for this CC and one for the Information Accessibility CC.
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml-hy-n/gml-hy-n.trs.md [A.2.5]
  • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml-hy-n/gml-hy-n.uom.md [A.2.6]
  • Note: A.2.3 is not relevant as there are no grids.
  • Note: It is unclear which requirement in the document A.2.4 references. In addition I also question the test. It is quite common for WMS products to convert coordinate systems on the fly, so it is not necessary that the data set is in a specific CRS.
  • CC: Data Consistency, Hydrography - Network v3.1
  • Standardization target: Spatial data set
  • Parameter values "Encoding": { "hy-n GML AS 4.0" }
  • Indirect dependency: "hy-n GML AS 4.0"
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml/gml.identifier-persistent.md [A.3.1, A.3.2]
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml/gml.endLifespanVersion.md [A.3.3]
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml/gml.validTo.md [A.3.4]
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml-hy-n/gml-hy-n.consistency-at-borders.md [A.3.6]
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml-hy-n/gml-hy-n.attribute-consistency.md [A.3.6]
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml-hy-n/gml-hy-n.identifier-source.md [A.3.7]
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml-hy-n/gml-hy-n.identifier-consistency.md [A.3.7]
    • Note: Need to add a manual test for A.3.5.
  • CC: Information Accessibility, Hydrography - Network v3.1
  • Standardization target: Spatial data set
  • Parameter values "Encoding": { "hy-n GML AS 4.0" }
  • Indirect dependency: "hy-n GML AS 4.0"
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml/gml.code-list-extensions.md [A.1.3, A.5.1]
    • Note: This TC needs to be split into two, one for this CC and one for the Application Schema CC.
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml-hy-n/gml-hy-n.code-list-values.md [A.1.3, A.5.1]
    • Note: This TC needs to be split into two, one for this CC and one for the Application Schema CC.
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml-hy-n/gml-hy-n.crs.md [A.2.1, A.2.2, A.5.2, A.5.3, A.8.1]
    • Note: This TC needs to be split into two, one for this CC and one for the Reference Systems CC.
    • Note: The numbering in the TG is incorrect.
    • Note: A.5.4 is not applicable as grids are not relevant
  • CC: Portrayal ISO 19128 profile, Hydrography - Network v3.1
  • Standardization target: OGC web service (WMS 1.3.0)
  • Dependency: "INSPIRE Profile of ISO 19128 v3.11"
    • Note: So far, no test is available due to the different standardization target. A.7.1 and A.8.8.
  • CC: Portrayal WMTS 1.0.0 profile, Hydrography - Network v3.1
  • Standardization target: OGC web service (WMTS 1.0.0)
  • Dependency: "INSPIRE Profile of WMTS 1.0.0 v3.11"
    • Note: So far, no test is available due to the different standardization target. A.7.1 and A.8.8.
  • CC: Application Schema Hydrography - Physical Waters v3.1
  • Standardization target: Spatial data set
  • Parameter values "Encoding": { "hy-p GML AS 4.0" }
  • Indirect dependency: "hy-p GML AS 4.0"
  • CC: hy-p GML AS 4.0
  • Standardization target: XML document with a feature collection (feature schemas: http://inspire.ec.europa.eu/schemas/hy-p/4.0/HydroPhysicalWaters.xsd)
  • Dependency: "INSPIRE GML encoding rule 3.3"
  • (etc.)
• ATS: INSPIRE Guidelines for the encoding of spatial data 3.3
  • CC: INSPIRE GML encoding rule 3.3
  • Standardization target: XML document with a feature collection (schemas: http://schemas.opengis.net/wfs/2.0/wfs.xsd, http://schemas.opengis.net/gml/3.2.1/gml.xsd)
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml/gml.utf8.md [A.6.1, A.8.5]
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml/gml.schemaLocation.md [A.6.1, A.8.5]
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml/gml.schema-valid-2.md [A.6.1, A.8.5]
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml/gml.schema-valid-1.md [A.1.1, A.1.2, A.1.3, A.1.4, A.1.5, A.3.2, A.6.1, A.8.1, A.8.5]
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml/gml.root-element.md [A.6.1, A.8.5]
    • TC: https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml/gml.nilReason.md [A.1.2, A.1.3, A.6.1, A.8.5]
    • Note: The numbering in the TG is incorrect.
    • Note: A.8.2-A.8.4 are part of the interoperability metadata CC.
    • Note: A.8.6-A.8.7 are not relevant as coverages are not part of this application schema.
• see https://github.com/inspire-eu-validation/ats-cross-cutting/issues/16 for the other ATSs. This only covers the Hydrography TG.

[cportele]

I am creating an ETS for parts of this to illustrate the two options which may help in the discussion.

If anyone knows some Hydro Network data encoded as INSPIRE GML that could be used for testing, this would be nice 😄.

[lorenahq]

Hi Clemens,

Maybe that can help you:

http://www.ign.es/wfs-inspire/hidrografia-btn100?service=WFS http://www.ign.es/wfs-inspire/hidrografia-btn100?service=WFS&request=GetFeature&version=2.0.0&srsName=urn:ogc:def:crs:EPSG::4258&typeNames=hy-n:WatercourseLink&namespaces=xmlns(hy-n,urn%3Ax-inspire%3Aspecification%3Agmlas%3AHydroNetwork%3A3.0)&count=50 &request=GetFeature&version=2.0.0&srsName=urn:ogc:def:crs:EPSG::4258&typeNames=hy-n:WatercourseLink&namespaces=xmlns(hy-n,urn%3Ax-inspire%3Aspecification%3Agmlas%3AHydroNetwork%3A3.0)&count=50

I have also found this one

http://kortforsyningen.kms.dk/hyn_elf_gml321?service=WFS http://kortforsyningen.kms.dk/hyn_elf_gml321?service=WFS&request=GetCapabilities &request=GetCapabilities

Cheers,

Lorena

From: Clemens Portele [mailto:notifications@github.com] Sent: 26 April 2016 13:09 To: interactive-instruments/ats-spatial-data-hy ats-spatial-data-hy@noreply.github.com Subject: Re: [interactive-instruments/ats-spatial-data-hy] comments on the DS ATS proposal (#1)

I am creating an ETS for parts of this to illustrate the two options which may help in the discussion.

I anyone knows some Hydro Network data encoded as INSPIRE GML that could be used for testing, this would be nice 😄.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/interactive-instruments/ats-spatial-data-hy/issues/1#issuecomment-214704858 https://github.com/notifications/beacon/ARdSeSiJG0k3eo4P3HCnfDMr1XiugRwVks5p7fJhgaJpZM4IGiHN.gif

[cportele]

Thanks, @lorenahq !