inspire dq&md krakow 2010-06-22 minutes

8/12/2019 Inspire Dq&Md Krakow 2010-06-22 Minutes

http://slidepdf.com/reader/full/inspire-dqmd-krakow-2010-06-22-minutes 1/47

EUROPEAN COMMISSION Directorate General JRC

Joint Research CentreInstitute for Environment and Sustainability

Spatial Data Infrastructures Unit

INSPIRE Data Quality and Metadata Workshop: “ FromRequirements to Metadata”

Krakow, 22 June 2010 14h00-17h30

Participants:1) Representatives of EU/EFTA countries nominated by the INSPIRE Contact points:

Country Name Organisation

Austria Georg Topf BEV

Belgium Geraldine Nolf AGIV - Agentschap voor Geografische

Informatie VlaanderenBulgaria Lilyana Turnalieva

Czech Republic Tomas Cajtham Czech Office for Surveying, Mapping and

Cadastre

Denmark Dorthe Drauschke

Finland Aaro Mikkola National Land Survey

France Gilles Troispoux CERTU / Pôle Géomatique du Ministère

Germany Sebastian Schmitz

Greece Eleni Grigoriou

Hungary Tamás Palya Institute of Geodesy, Cartography and

Remote Sensing

Latvia Saulius Urbanas

Norway Kåre Kyrkjeeide Statkart Norway

Poland Marcin Grudzień Main Geodetic and Cartographic

Documentaion Centre

Romania Daniela DOCAN Directorate of Geodesy and Cartography,Slovakia Martin Koška Slovak Environmental Agency

Slovenia Irena Ažman

Spain Celia Sevilla-

SánchezDolors Barrot-Feixat

Instituto Geográfico Nacional de España

(IGN-E)



3) Staff of the European Commission (INSPIRE Data Specification Support Team)

– Katalin Tóth and Robert Tomas (workshop organisers) – Vanda Nunes de Lima (INSPIRE Data Specification contact point)

AgendaWelcome, objectives of the workshop R. Tomas

Tour de table(introduction of the participants) AllData Quality in INSPIRE: from Requirements to Metadata K. Tóth

Analysis of the Member states responses (DQ questionnaire) R. TomasStatus of ISO 19157 project Johan Esko

Discussion All

Conclusions, way forward All

Data quality in INSPIRE: from requirements to Metadata(K. Tóth)

The objectives of presentation were – to present the Discussion paper prepared by EC-JRC INSPIRE Team that

was distributed prior to the meeting – to clarify the role of data quality in Spatial Data Infrastructures

– to highlight the differences and similarities between a priori data quality

requirements and metadata

Analysis of the Member states responses (R. Tomas)

The discussion paper has been accompanied a questionnaire aiming to clarify the positionof the Member States how data quality has to be made part of INSPIRE. R. Tomas

presented the context and the outcome of the survey: – the legal requirements coming from ISNPIRE Directive, the Implementing

Rules and the technical guidelines

– quantitative and qualitative analysis of the responses for each question

The Status of ISO 19157 (Johan Esko – project leader)The emerging ISO 19157 – Geographic Information: Data Quality standard will present

an integrated view on data quality of geographical information that – will replace ISO 19113, 19114, 19138 incorporating all DQ models in a

consolidated way

– will provide handy conformance descriptions for product specifications



Points for discussionHaving presented the Discussion paper and the results of the questionnaire the following

points were highlighted for further discussion:

1) Discussion process in your country

– (has it taken place, what are the further plans)

– Input for the discussion paper2) The discussion paper

–

Does any part of the discussion paper need clarifications? – Do the questions need modifications?

– Do we need additional questions?

3) A priori DQ requirements – Do you agree that a priori DQ requirements/recommendation can be

inserted in the interoperability target specifications when it is justified by

the high level use-cases of the infrastructure?4) Data transformation

– Shall metadata be transformed when data is transformed?5) Metadata

– The more metadata the better is? – Shall all a priori DQ requirements reported as metadata (with actual

values) or can they replaced by conformance statement?

– Do additional metadata for evaluation and use help users to betterunderstand the fitness for use?

– How to publish metadata that is available for a specific data set, but is not

specified in the interoperability target specifications for the infrastructure6) Lineage

– Does lineage help the users to better understand the fitness for use?

– What is lineage good for (what is within the scope and what is out)?

– Can lineage replace (a part of) DQ elements? – Does the lineage need a fixed structure within the data theme?

7) Conformance

– Is it appropriate to specify conformance levels based on different sets of

user requirements? – Do more conformance levels mean more confusion?

– How/where to describe how a data set does not conform?8) Positional accuracy

– Is the only (or most important) way to say something about the

“comparability” of data sets?



Reflections from the country representatives

United Kingdom

1) Country discussion has started; nine responses were received at the national level

2) The discussion paper is quite good, only Q4 needs clarification3) The use-case approach is definitely useful; otherwise users cannot predict what data is

good for

5) Metadata – the more is the better – use rather a document than formal metadata

elements6) Lineage: is important from legal point of view; fixed structure would be nice, but not

convinced about the practicability and feasibility for every data theme

7) Conformance levels – introduce a fairly low conformance level as mandatory one andhigher levels as recommended ones. Non conformity has to be reported as free text.

8) Positional accuracy is important, but there are many other factors that define and are

equally important (e.g scale)

Sweden1) The answers sent to the Commission are composed from 3-4 replies. A face to face

meeting is planned for September.

2) Discussion paper: The metadata part was a bit more difficult to understand

3) DQ requirements: start the specification process and justify DQ requirements with use-cases

5) MD – the importance is obvious – however focus on the most important metadata.

Each data theme has to select and discuss which metadata elements are important

6) Lineage: better if structured8) Positional accuracy is not the most important element – sometimes data with good

positional accuracy do not meet the expectations of users.

Spain

1) No, only input from Catalonia has been received so far, but more agencies will be

involved in the face to face discussions in September

3) Use cases are important – the description of high level use cases should come from theinteroperability target specifications – the data providers don’t know the users5) Metadata – the Spanish profile include more DQ elements. These elements are mainly

targeted at expert users. Other users can be better informed from informal “fitness for

use” descriptions.6) Lineage is also a language issue – who is going to provide translations from Spanish to



Slovenia

1) No, only few stakeholders have been consulted. The situation is very different in each

data provider. Face to face discussion – is foreseen till the end of the year.2) The discussion paper is a good start, however some questions were difficult to

understand.3) The use cases approach is important in international level. Within a country data

providers usually know who their users are and what their requirements are.

5) In ISO standards there are about: 400 metadata elements, which is too much. The bestmethod to learn what the data is good for is best way is to give a call to the data provider.

6) Lineage is important: should be structured for each data set. Each INSPIRE data

specification should provide a template for that.7) Conformance – more levels and structure for describing the reason of non

conformance are needed.

8) Positional accuracy is not so much important; depend mainly on the scale and the

nature of the data set.

Poland

1) No, concerning the content of the discussion, Poland is in a learning stage. Discussionwill be organized later in the year.

2) The discussion paper is a good start. Question 4 is not clear – add examples to betterunderstand the context.

3) Use cases are good idea and they may be important for potential data users working on

international level. DQ recommendation can be inserted in the interoperability targetspecifications when it is justified by the high level use-cases of the infrastructure. With

time (with more experience gained by NMCAs) recommendation could be changed to

requirements.4) We have to follow realistic objectives in data transformation. At the beginning weshould focus on the quality of the process and the data received after the transformation.

Extension of metadata requirements should come later. Probably, only further iterations

can be based on formal quality inspections.5) MD – the more the better. Consequently, users would like to have both conformance

statement and reported DQ values in metadata. However, please keep in mind that

producing good metadata is resource consuming. One of the most resource consumingmetadata elements are those which describe data quality. Poland will probably not be able

to provide all optional DQ elements specified in INSPIRE during the first iteration of

INSPIRE data sets production.6) Lineage: more standardization might be helpful, but the lineage will never fully

replace other DQ elements.

7) More conformance levels are generally good idea However each conformance level



Netherlands

1) Lack of time – further discussions will be organised.

2) The Dutch SDI approach: criteria for selecting data to be included in the INSPIRE are published – this is the basis for the content (availability of features and attributes), quality

discussion, frequency of update, scale, selecting regional or local data set. Not all the datasets are available for INSPIRE, but what is provided is the best available ones.

Germany

1) Due to lack of time the discussion process has not been started. It can be predicted that

it will be very hard to define a common position for Germany: there are many lands andmany data providers

2) DQ requirements should be examined also from domain point of view.

Finland

1) No the discussion has not taken place.

2) The paper was clear. If possible add examples for conformance. Even though the

question was clear, it is very difficult to answer what target values are appropriate.

3) Use-cases are important, we support this approach.4) Data transformation: quality control of the metadata production is also necessary.

5) The current demand in INSPIRE is not very accurate – perhaps new MD elements areneeded. Use the experience of data providers and EuroGeographics

7) Conformance – more conformance levels make more confusion; never the less the two

effective values are insufficient

8) Positional accuracy – depends on the scale but give some limits of acceptable quality.

France1) The discussion process is ongoing between users and producers

2) The discussion paper is clear and no additional questions are needed.

3). Yes, a priori data quality requirements have to be introduced. Use cases are veryimportant to determine criteria on data. Go further with fitness for use, which is

especially important for thematic data.

4) Transformation applies to metadata, too. It is more difficult for data transformation.

Lineage is certainly a solution.5) Actual values of a priori data quality requirements shall be reported when affordable.

This is the best, but often too expensive for actual datasets. Conformance statements

seem not to be very useful and easy to obtain. A solution could be to declare its datasetsfollowing defined quality classes.

Additional metadata is needed; we must work together to find new metadata around the



6) Lineage is valuable to users. It gives a lot of information about the life of the data set

but can give just an idea on DQ. It does not replace any DQ element. Certainly, when we

look different catalogues, the contents of this metadata are very various and sometimesirrelevant and without interest. This subject is complex; common reflection is needed

how to guide the writer of this metadata and how to describe the history of the data?Generally, it is necessary avoid free texts. From experience, open metadata is too poorly

drafted and difficult to operate.

7) Conformance may be a partial but cheap solution for fitness for use. However moreconformance level can create confusion, it seems to be practical to limit conformance

levels to five. If the data set is correctly described with the good metadata the user must

be able to understand if the data set is conform and no need for describing separately thenon conformance.8) Positional accuracy is important – propose quality classes, following NATO’s

STANAG.

Denmark

1) The National INSPIRE advisory board will take up the discussion in the autumn.

Czech Republic

1) The first discussion forum was organised with involvement of 2 organizations. The

plan is to continue in September with other bodies.

2) Make clearer terms e.g. target and scope and give definition of the non standardquality terms.

3) User requirements have to be revised to determine DQ requirements.

5) Be aware that for consuming metadata another tools might be required. For example

metadata acquired during production processes could be generated through automationtools. The outputs should be standardised: it is not necessary to use only metadata; is

possible to use also viewing services, reports or other outputs.

6) It seems that lineage is misused in INSPIRE guidelines – it is not a black hole. Oneway is to change current usage of lineage to another way of reporting in MD/DQ

elements.

7) Conformance should be demonstrated by certification and accreditation.8) Positional accuracy is of prime interest only for a couple of use-cases. In the Czech

Republic positional accuracy is calculated only for points and they may or may not beaggregated for lines and polygons.

Belgium

1) No face to face discussion has taken part, especially not at the federated level2) Th l b t j t t h t i ti t i l



low-end users don’t read metadata, especially not the quality metadata elements. They

want to know if the data will fulfil their needs. In this respect minimum metadata

elements are abstract, scale, usage & constraints and lineage. Producing MD qualityelements should not be the goal, but the aim has to be making the quality better in the

data itself.6) Lineage: Each update brings a new lineage process step (free text description), but is

only for history – don’t misuse it!

7) Conformance is enough as it is now.General comment: Find the best balance in necessity, inevitability, nice to have and

overkill.

Austr ia

1) The discussion has taken place in form of commenting the discussion paper, but noface to face meeting has been organised. No further discussion is planned for this year.

2) The discussion paper was a very good summary of the state of the art.

3) Before introducing a priori data quality requirements in the interoperabilityspecifications, the scope of INSPIRE need to be defined first.

5) Evaluate the need for new metadata first – “the more the better” is not adequate at this

stage and will not help the user. But MD-Elements like “CRS”, “Encoding” and “fitnessfor use” (scope) should be included in the thinking process.

6) Lineage: it should be added, how quality is deteriorated in course of transformations

7) What should be the benefit of detailed conformance levels? At the moment (MD-

Regulation) a dataset can be conform, not conform or not evaluated. Additionalconformance steps do not seem to be appropriate. What conformance level should it be, if

a data set meets 80% of the requirements and how useful is this information?8) Positional accuracy can bear witness about the “comparability” of data sets but it doese.g. not provide information about acquisition density and parameter. If positional

accuracy will be fixed as a priori DQ requirement at a very high level it can course that

many data sets will not fulfil this requirement. Inaccurate data are still better than no data.General comment: Please do not force the member states to implement additional data

quality requirements and MD-quality requirements at the moment. Data quality

requirements are important, for sure. But the implementation of INSPIRE (data and

services) should have priority.

Reflections from the audience

Stefania de Zorzi (CORILLA)Since no DQ representative has been nominated from Italy Stefania de Zorzi informed



Peter Semrad (JRC, Institute of Energy, Petten)

INSPIRE is not a general benchmark for data quality. Distinction between reference and

thematic data is very important as the first can carry attributes for many other themes –consequently the DQ requirements for Annex I should be higher.

Positional accuracy is not so important for many themes – e.g. in gas pipelines modellingthe connectivity is much more important. When talking of quality look at other aspects

too.

Antti Jakobsson (EuroGeographics)

INSPIRE is getting closer and closer to this topic, which is great! The current tools in the

specifications are in the right directions – the ESDIN project has tested them, but foundsome errors. The ESDIN project offers their results to be shared in a specific guideline.Create a platform to channel the user requirements in the process (ESTAT, EEA, GMES)

INSPIRE has to introduce some minimal rules – like the minimal logical consistency.

EuroRegionalMap provides a good example how to deal with data quality and metadatawhen data come from disparate sources. It would be worth doing a small study on it.

Marc Leobet (INSPIRE National Contact Point, France)

It is not appropriate to be guided by use-cases. The absence of quality might be costly inthe near future; put in realistic, but ambitious targets especially for positional accuracy of

reference data. Users use data whatever they want to, but we have to sufficiently informwhat data is good for.

Conclusions:

All participants agreed that the data quality in INSPIRE is an important issue and thusJRC should continue facilitating the process of finding the common position among

Member States.

Due to the lack of time proper discussions in Member states have not been realised, but

based on the outcome of the Workshop – explanations of the terminology etc. participantsexpressed that the national discussions will take place till the end of November 2010.

It was agreed that based on the national discussions the MS who has not sent the answers

yet would provide them by November 2010. (updated versions of already sent MS

responses)JRC ISNPIRE team agreed to provide the Minutes of the workshop and updated version

of the Discussion paper (adding the examples)The need for a new Data Quality workshop has been raised that could take place at the

beginning of the next year (February 2011) to discuss the results of the Data Quality

discussions in the Member States



1

Data Quality in INSPIREData Quality in INSPIRE

From Requirements to MetadataFrom Requirements to Metadata

Katalin Tóth

EC-JRC INSPIRE data specification support

team



2

OutlineOutline

1. Introduction

2. The roots of the problem3. Data quality and metadata in data productio

4. Data quality and metadata in spatial datainfrastructures

5. What has been done in INSPIRE so far?6. Why we have to go on?

7. What we plan to do?



3

Data quality inData quality in SDIsSDIs

• Is difficult …because – We don’t understand each

other (terminology confusion,unclear context)

– Everybody is committed forquality (common platform of

data users and providers)> When it does not cost too

much

> Till the requirements do not

need to be collected andformalised

– When establishing an SDImoney and work have to beinvested



4

Roots of the problemRoots of the problem

• Concept of data sharing (re-using) – the terms fit for describing data quality in data production are being put

in new context (SDI)→ false synonyms

– Data is being used (even produced) by a wide audience sometimeslacking “GI literacy”→ is there an easy way to communicate

– SDI has introduced new terms like interoperability and usability that aredifficult to describe and quantify

• The wide variety of data quality elements and measuressometimes rather confuse than help (even to specificationdevelopment experts)

• Conformity statements based on self declaration – too many

question marks – How reliable they are?

– Can they replace metadata?

– Are they useful for the users when they don’t know the content against

which the conformity statement is issued? – Different viewpoints (against specifications or against usability?)

Q



5

DQ in data productionDQ in data production

• Careful analysis of theuse-case of a specificuser

• The requirementsderived from the use-case contain DQrequirements too

• The data productspecification prescribestarget values for

selected DQ elements

Specification development Data utilisationData & metadata production

Quality assurance

Ex ante Ex post

• Targets at achieving/fulfilling the dataspecification elementscomprising those on DQ

• Contains DQ inspectionsbased on appropriatesampling against thecriteria of the dataspecification

• Results:

– Pass/fail decisions

– Conformancedeclarations

• The results of DQinspection are publishedas metadata forevaluation and use

• May contain additionalmetadata to help the usersbetter understand the data – Selected data

specification elements(topic categories, scope,

purpose, representationtype, identificationinformation, geographicaldescription, encoding)

– Other specific metadataelements (lineage)

ISO 19131 (Data Product Specifications) contains both DQ requirements and Metadata

Q S fDQ i S ti l D t I f t t



6

DQ in Spatial Data InfrastructuresDQ in Spatial Data Infrastructures

• Definition of the scope

based on the high leveluse-cases that theinfrastructure is supporting

• Three levels ofinteroperability – Publish and share every

existing data – Establish interoperability

– Achieve fullharmonisation

• The interoperability targetis defined in formalspecifications – may include DQ

requirements if justifiedby the selected usedcases (scope of theinfrastructure)

Defini tion of the scope/purpose

Publication (Geoportals)Data and metadatatransformation

Quality assurance

Ex ante Ex post

• Targets at achieving/

fulfilling the specificationelements (comprising thoseon DQ) in theinteroperability targetspecification

• Contains DQ inspectionsbased on appropriatesampling against thecriteria of theinteroperability specification

to determine – (how well thetransformation work

– How the DQ changes inthe process

• Results: – Pass/fail decisions

– Conformance declarations

• The results of DQinspection are publishedas metadata forevaluation and use

• May contain additionalmetadata to help the users

better understand the data – Selected data

specification elements(topic categories, scope,purpose, representationtype, identification

information, geographicaldescription, encoding)

– Other specific metadataelements (lineage)

Interoperabil ity target specif ications may follow the structure of ISO 19131. Usually they contain both

D re uirements and Metadata



7

Quality of data in production and SDIQuality of data in production and SDI

• While DQ requirementsare strong drivers in dataproduction, it has to beapproached in SDIimplementation with

caution

• DQ requirements are inboth a priori targets,metadata is a posterioridocumentation of qualityachieved



8

Balance dilemma in SDISBalance dilemma in SDIS

• Wide selection of

data available• Interoperability

problems in manyapplications

• User aregenerallyunsatisfied with

data quality

• No interoperability

obstacles• Only few datasets

included

• Low level of datasharing – A smaller group of

users completely

satisfied, while therest my remainempty handed

No a priori DQ

requirements for

inclusion

Stringent a priori

DQ requirements

Golden middle?

Put in DQ

requirements whenit is justified by thescope/ typical use-

cases of theinfrastructure



9

Guess aboutGuess about ““golden middlegolden middle””

• Put in DQ requirements generated by the typical use-cases ofthe infrastructure

• DQ targets should be inserted in the interoperability targetspecifications

• DQ target has to be achieved in course of necessary

transformations• Document all the notion about the eventual data quality (after

having transformed the data) with a sufficient and explanatoryset of metadata

• Metadata should report all the DQ requirements set in thetarget specification plus any other notion that help users to

judge about fitness for use



10

DQ requirements in INSPIREDQ requirements in INSPIRE

• The Directive follows the interoperability approach: users should be able tocombine spatial data from different sources in consistent way withoutspecific efforts of humans or machines

• Data shall be “comparable” in terms of logical and geometrical consistency

that implicitly sets requirements against data quality• Requirements can be fulfilled by rigorous data modeling based on the

Generic Conceptual Model and direct DQ requirements

• While the data models included in the specifications provide solid basis to

provide data of appropriate quality in terms of logical consistency, otherrequirements against data quality are addressed on case by case basis

• Generic approach: – Use recommendations rather than mandatory data quality requirements

– Fully document data quality as metadata

– When DQ requirements are introduced they are also reported as metadatausing the same DQ element

• Natural diversity of the data themes: no common approach, slightlydifferent data quality requirements and metadata elements in the

specifications in spite of trying harmonised them



11

Metadata in INSPIRE Annex IMetadata in INSPIRE Annex I

Data quality

elementData quality sub-element Metadata element AD AU CP GN HY PS TN

commission DQ_CompletenessCommission X X X X 2X

omission DQ_CompletenessOmission X X X X X X X

conceptual consistency DQ_ConceptualConsistency X X X X

domain consistency DQ_DomainConsistency X X X

format consistency DQ_FormatConsistency X

topological consistency DQ_TopologicalConsistency 2X 3X** 9X 6X

absolute or external accuracy DQ_AbsoluteExternalPositionalAccuracy 2X X X X X 2X X

relative or internal accuracy DQ_RelativeInternalPositionalAccuracy

X

Temporal

accuracy

temporal consistency DQ_TemporalConsistency

X

classification correctness DQ_ThematicClassificationCorrectness X

non-quantitative attribute

correctness

DQ_NonQuantitativeAttributeAccuracy

X X X

quantitative attribute accuracy DQ_QuantitativeAttributeAccuracy X

Maintenance*MD_MaintenanceInformation

3X 3X 3X 3X 3X 3X 3X

Thematic

accuracy

Positional

accuracy

Logical

consistency

completeness



13

What are our objectives?What are our objectives?

• Put in place a bottom up process clarifying the

stakeholders’ views and reaching agreementin each Member State

• Confront the national positions and buildconsensus about

– applicability of mandatory DQ requirements in

INSPIRE

– appropriate means of communicating DQ to the

users (valid and meaningful metadata and

conformance statements)



14

What we plan to do?What we plan to do?

• Because of shortage of time it has not been possibleto coordinate consensus building process in the MS

• The DQ&MD workshop in Krakow allows – clarifying the position of the participants

– spotting the “hot” topics and possibly reaching agreementin some parts

– specialist input for further refinement of the discussionpaper

– Setting a roadmap for further actions

• Reiterate the discussions and consensus building inMS and at European level



1

Data quality in INSPIRE: fromData quality in INSPIRE: from

requirements to metadatarequirements to metadata

Analysis of the Member states responses Analysis of the Member states responses

Robert Tomas, Katalin Toth

EC-JRC INSPIRE data specification team



2

Data quality in the INSPIRE directiveData quality in the INSPIRE directive

• INSPIRE Directive

– Article 5(2): MD shall include information on

data quality and validity of spatial data sets – Article 11(2): Network services (Discovery)

shall include searching functionality on quality

and validity of spatial data sets.

– Article 21(2): Report on the organization of

quality assurance – Article 8(3-4): Consistency and ability to

compare data



3

Implementing rulesImplementing rules

• Commission Regulation (1205/2008) as regards Metadata

• Commission Decision (2009/4199) as regards monitoring

and reporting• Draft Commission Regulation as regards Interoperability of

spatial data sets and services (Annex I Spatial data themes)

• Commission Regulation (268/2010/EC) as regards theaccess to spatial data sets and services

– Article 6 ... Member States shall also make available, upon request,

information for evaluation and use, on the mechanisms for

collecting, processing, producing, quality control and obtaining

access to the spatial data sets and services, where that additional

information is available and it is reasonable to extract and deliver it.



4

Data quality in the INSPIRE directiveData quality in the INSPIRE directive

• INSPIRE Directive

– INSPIRE does not require collection of new

spatial data – Development of the Data specifications should

be based on the user requirements

– Cost-benefit considerations should be appliedall the time

Difficult to balance..



5

Summary of the MS responsesSummary of the MS responses

• 15 Responses from 12 Member States

• Austria, Belgium (2x), the Czech Republic,

Denmark, Finland, France, Latvia (3x),Poland, Romania, Slovenia, Sweden, the UK

• Not enough time to prepare a consolidatedcountry position

• Apart from the answers to the questions wehave received several general commentsrelated to the data quality in INSPIRE



The statistics of the responses to theThe statistics of the responses to the



7


11stst QuestionQuestion

Statistics: 15 responses

Yes, for each dataset – 3xYes, but only for some.. – 7x

No – 5x

Is there a need to include a priori data quality targets (elements,

measures, and values) in INSPIRE data specifications?

Answers:Yes, for each dataset addressing the same set of requirements.

Yes, but only for those datasets where achieving interoperability

requires so.

No.




8


11stst QuestionQuestionIs there a need to include a priori data quality targets (elements,

measures, and values) in INSPIRE data specifications?

General Comments:

• Extra cost for data providers to implement• Directive doesn’t requires collection of new data

• Better to use DQ Targets then Requirements

• „Nice to have“, but difficult to implement (Annex Iexperience)

• Quality is unlikely to be consistent across nationaldatasets (different sources)

• Spatial data is (has to be) produced by the public

authorities only in the appropriate quality which isnecessary for the specific use.




9

The statistics of the responses to thep

22ndnd QuestionQuestion

Mandatory:

Annex I Themes

Administrative Units – 6xGeographical Names – 4x

Addresses – 4x

Cadastral Parcels – 6xHydrography – 5x

Transport Networks – 5x

Protected Sites – 2xCRSystems – 1x

Please indicate the theme and whether these targets should be addresses by

mandatory requirements (M) or recommendations (R)?

Annex II & III Themes

Elevation – 5xOrthoimagery – 5x

Buildings – 4x

Statistical Units – 6xLand Cover – 5x

Utility and Governmnetal

Services – 2x




11

pp

33rdrd QuestionQuestion


• Not enough time to elaborate

• Should be proposed by domain experts• Different DQ measures and values compare to

Annex I Data specifications

Please indicate the data quality elements, measures, and the target

values to be used. Please fill a separate table for each data theme to

which a priori DQ requirements / recommendation apply.



13

pp

44thth QuestionQuestion


Yes – 8xNo – 7x

Do you recommend to specify mandatory metadata elements in INSPIRE

when no a priori data quality requirements have been specified, or to

complement those specified in the DQ section to inform users about the

fitness for purpose?




14

p


General comments:• Optional MD elements to report on the fitness for

purpose should be introduced• MD for interoperability should be applied also for AnnexII&III

• “lowest common denominator” within Europe will causeunbearable expenses.

• It is more important to have technical characterisationand lineage then DQs

• The MD lineage should be structured (x bad use of theEn ISO 19115 MD element instead of DQs)

Do you recommend to specify mandatory metadata elements in INSPIRE

when no a priori data quality requirements have been specified, or to

complement those specified in the DQ section to inform users about the

fitness for purpose?




15


What is the best way to generate DQ metadata about the data that has

been made conformant to the INSPIRE data specifications (i.e. after

the necessary data transformations)?

Answers:1. Keep the original metadata

2. Generate new metadata based on calculations or quality inspection

by appropriate sampling

3. Keep the original metadata and described as process step inMD_lineage (transformations performed with their possible effect

on data quality)

Statistics: 15 responsesKeep the original MD and use the MD_lineage – 10xGenerate new MD – 5x




16


What is the best way to generate DQ metadata about the data that has

been made conformant to the INSPIRE data specifications (i.e. after

the necessary data transformations)?

General comments:• Not ideal, but practical approach – (Use of LI_ProcessStep)

• New MD based on quality inspection – a long term target• For Annex I – Reference data – new MD; for Annex II&IIIMD_Lineage

• Additional MD has to be searchable via Discovery Services




17


Do you recommend to introduce theme-specific conformity levels (in

addition to conformant, non conformant, not evaluated) in the

INSPIRE Annex II-III data specifications development?

Statistics: 15 responsesYes – 4x

No – 11x




18


Do you recommend to introduce theme-specific conformity levels (in

addition to conformant, non conformant, not evaluated) in the

INSPIRE Annex II-III data specifications development?

General comments:

• Cannot be dealt with now – based on user

requirements for Annex II&III• Consistent approach should be taken – nodataset will be 100% conformant – how to record

levels of not conformity or where is not conformant



Analysis of the Member states Analysis of the Member states



21

responsesresponses

Summarizing comments:

• Min. data requirements only based on the clear user

requirements – important to develop appropriate Usecases – re-evaluate cost/benefit considerations

• Yes to distinguish between Reference data and Thematic

data• Change of terminology - Data quality requirements to

“ data estimation of adequacy” / DQ targets or

recommendations

• Many organizations do not have the data product

specifications – costly to implement now.

• Definition of the INSPIRE conformance testing - AbstractTest Suites

Analysis of the Member states Analysis of the Member states



22

responsesresponses

Summarizing comments:

• It is too early (INSPIRE implementation) to introduce any

additional “ burden” on the MSs. – danger of the failure ofthe whole implementation of INSPIRE

• Evaluate other DQ initiatives (GEOSS Quality Assurance

strategy and ISO 19157 DQ revision project)• The need for common quality requirements is well

understood (real benefits of a joint SDI) x diff icult to

consolidate the needs of the internal processes and‘public’ needs.

• The effort to find the broader agreement (consensus) on

the data quality targets in INSPIRE (E SDI) shouldcontinue.

Thank you for your attention !



23http://inspire.jrc.ec.europa.eu

inspire dq&md krakow 2010-06-22 minutes

Documents