The document discusses the EU INSPIRE Directive and its implications for UK academia. The INSPIRE Directive aims to create a European Spatial Data Infrastructure (SDI) to improve sharing of spatial information between public authorities and accessibility for the public. This will allow better environmental policies and outcomes. While initially for environmental policy, INSPIRE intends to extend to other domains. The directive may apply to UK universities as they are considered public authorities. This could mean universities would need to make certain spatial datasets available according to INSPIRE specifications. The directive presents both obligations and opportunities for UK academia as data providers and data users.

1. The EU INSPIRE Directive.
And what it might mean for UK academia...

2. INSPIRE - Aims
The AIM of the INSPIRE Directive is to:
create a European Spatial Data Infrastructure (SDI) to
improve the sharing of spatial information between public authorities and improve accessibility to the public.
This will allow the EC and Member States to design and deliver better environmental policies that will result in
improved environmental outcomes.*
INSPIRE will improve the quantity and quality of spatial information and enable information from different
sources to be more easily combined.
* While it is intended for use in environmental policy making in the first instance, the intention is that it will be extended wider.

3. "Whether or not a data set falls under the INSPIRE obligations does not
depend on the scale, the specificity of the data sets, or the level of
government involved in their management.
When the data sets, at any level of government, are relevant for
developing, implementing or monitoring laws or regulations which may
have an impact on the environment, INSPIRE obligations should apply.
Such conditions could equally apply to data sets collected by a
research project activity as the INSPIRE Directive makes no distinction
between ‘operational’ and ‘research’ data sets.
INSPIRE could be considered a positive incentive to safeguard valuable
research data sets after the ending of a project."

4. What are the issues and opportunities for opening up content?
INSPIRE activities in the UK have to be set alongside wider initiatives at UK
government and EU level which provide simultaneously both obligations and
opportunities, specifically:
The UK Location Programme- a cross domain, public sector effort to
Establish the UK SDI and to partially realize UK obligations under:
INSPIRE - A pan- European Directive for the establishment
of an Infrastructure for Spatial Information (SDI) in the EU
The aim of INSPIRE is to:
improve the sharing of spatial information
between public authorities and
improve accessibility to the public.
INSPIRE will improve the quality of spatial
information and enable information from
different sources to be more easily
combined

5. What are the issues and opportunities for opening up content?
The definition of ‘public authority’ (as per FoI) includes
universities and Research Councils - the upshot of this is
that Universities are required to comply with the Directive*.
Implications of this depend on which perspective we take:
Academia as Data Provider/Creator
Academia as Data User
In reality, it is likely that BOTH perspectives will pertain!!
* Public Task has been defined for most public sector bodies in relation to the Re-use of Public Sector Information. But the
PSI does not apply to Universities so there has been no need to create a statement of public task for that legislation.
Guidance on public task places the onus on the Body to create the statement and it is reliant on both declared activities and
“custom and practice” and it is open to challenge if outside parties disagree with the statement.
The Scottish Information Commissioner has noted:
“I would question, however, whether it is possible to say that a university will never have public tasks for the purposes of
[INSPIRE]....it is not unknown for EU Law to deal with universities on the basis that they do discharge public functions. ”

6. UK HFE as INSPIRE Data Provider
For university institutions it is unlikely that much of the geospatial data they hold
would come under INSPIRE – certainly for the Annex I & II Themes .
However, there are two caveats to this:
1. As the focus shifts to the third annex, it is possible that data held within universities
might come within scope e.g. species distribution, habitats, atmospheric conditions.
2. Studies of environmental change require an understanding of how phenomena
change over time. This requires access to historic data and earlier editions of data
which may be held only by universities (or rather researchers and research teams
within universities).
In both cases, Universities would be required* to make these data available.
The Commission has stated that it is “a fundamental right of third parties to enrich the
European Spatial Data Infrastructure with data sets currently hidden or difficult to find”.
This philosophy also underpins the UK LP (aka UK SDI)
* see earlier comment on 'public task'

7. So what does that mean in practice?

Data harmonization (information will adhere to specified common specifications)

Provision of online services such as:
discovery (find out what data exists),
view (to display viewable spatial data sets)
download (to obtain the data)
transform (to enable data interoperability)

Licensing arrangements that allow information to be shared, accessed
and used in accordance with FOI legislation, EIR and the PSI Regulations
It won’t necessarily be free…

Monitoring mechanisms to demonstrate that the information is being
made available

Co-ordination mechanisms to ensure effective operation

8. Whats in scope?
The grouping of themes in Annex II and Annex III represents a grouping for addressing
different actions concerning harmonisation, dissemination and other actions formulated
in the Directive.
Different time schedules are linked to the data in the three annexes I, II and III.
There is no thematic hierarchy in the INSPIRE Directive, however each theme
represents a cluster/collection of different data sets.
Data specifications
already published

9. Annex III Themes of possible interest to social science?
Population distribution – demography
Geographical distribution of people, including population characteristics and activity
levels, aggregated by grid, region, administrative unit or other analytical unit.
Important feature types and attributes:
The definition in the Directive specifies kinds of features relevant to demography: The definition includes
the term "aggregated". Non-aggregated data about population is excluded. The mentioned examples of aggregation
are by grid, region, administrative unit or other analytical unit.
Underneath are examples. Important attributes however, can be very diverse and are
generally referred to as 'socio-economic attributes'. Different variables can be relevant for different
aggregation levels.
administrative unit, e.g. from the LAU2 level. settlement – small settlement, village, block, township, town, city
• id • id
• socio-economic attributes • socio-economic attributes as mentioned above
grid, e.g. 1x1 km, 100x100m physical region/area within settlement
• id • category
• socio-economic attributes
functional region/area within settlement
census districts • category
• id
• socio-economic attributes as mentioned above
Can also give population figures at other regional aggregations,
small area statistics "free" regionalisation
• id
• socio-economic attributes

10. Annex III Themes of possible interest to social science?
Human health and safety
Geographical distribution of dominance of pathologies (allergies, cancers, respiratory diseases, etc.),
information indicating the effect on health ( biomarkers, decline of fertility, epidemics) or well-being of
humans (fatigue, stress, etc.) linked directly (air pollution, chemicals, depletion of the ozone layer, noise, etc.)
or indirectly (food, genetically modified organisms, etc.) to the quality of the environment.
Important feature types and attributes:
To illustrate kinds of geographical information which can be included in this INSPIRE theme, some
examples on medical statistics and medical geography can be given:

General statistics on health - change over time

Incidence data on specific diseases or other health issues

Causes of poor or good health – risk factors - exposures

Geographical distribution over exposure elements

Human well-being

Security

Health services
Scope, use examples:
• Health planning and management
• Monitoring of marine foods or marine algal blooms that could cause harm to human health
• Research on causes of illness and death: Through medical geography and geographical epidemiology different health
issues can be analysed in a geographical context.
• Emergency management
• Security management: Over the last decade the criminal justice community has begun to reap the valuable analytic
benefits of geographic information systems (GIS) technology. The powerful technology enhances the ability of
researchers and practitioners to identify hot spots, analyse spatial patterns of crime and criminal behaviour,
and to share disparate data sets across jurisdictional boundaries.

11. Data Specifications – Relevant Document Relationships
“Data Specifications will provide a detailed definition of data
content by means of application schema and feature catalogue.
Furthermore the Data Specifications will specify requirements to
data quality, data consistency, reference systems and metadata.
The theme description, scopes and examples in this deliverable
D2.3 may serve as a starting point for the development of the
Data Specifications.”

12. Data Specifications (DS) - Detail
What is a DS?
The guideline contains detailed technical documentation of the
data specification highlighting the mandatory and the
recommended elements related to the implementation of INSPIRE.
Data Specifications document structure
Each DS starts with two executive summaries:
1. Interoperability of Spatial Data Sets and Services – General Executive Summary
a quick overview of the INSPIRE data specification process in general
2. {specific theme} – Executive Summary
the general content of the data specification on {the specific theme}.
These are designed for managers, decision makers, and all those
new to the INSPIRE process and/or information modelling as a
starting point.

13. Data Specifications (DS) – Document Structure Detail
1 Scope 6 Reference systems
2 Overview 6.1 Coordinate reference systems
2.1 Name and acronyms 6.1.1 Datum
2.2 Informal description 6.1.2 Coordinate reference systems
2.3 Normative References 6.1.3 Display
2.4 Information about the creation of the specification 6.1.4 Identifiers for coordinate reference systems
2.5 Terms and definitions 6.2 Temporal reference system
2.6 Symbols and abbreviations
2.7 Notation of requirements and recommendations
2.8 Conformance Reminding us of the generic reference systems that are
appropriate for the specific theme or expanding on this
the reference statements of the document where the theme needs to
3 Specification scopes
7 Data quality
Normally just a brief statement but...
This chapter includes a description of data quality elements and
the specification of a data product may not be sub-elements as well as the associated data quality measures. The
homogeneous across the whole data product, but may selected data quality measures are used to evaluate quality of
vary for different parts of the data. Each part shall datasets for a specific data quality element / sub-element. The
correspond to a specification scope. evaluation can be performed at the level of spatial object, spatial
object type, dataset or dataset series.
4 Identification information
8 Dataset-level Metadata
Orientation information – the top level what 8.1 Mandatory and conditional metadata elements
is this theme all about 8.2 Optional metadata elements
8.3 Guidelines on using metadata elements defined in Regulation 1205/2008/EC
However, this may be removed from Annex II Metadata can be reported for each individual spatial object (spatial
& III specifications (and a blank section object-level metadata) or once for a complete dataset or dataset
inserted). series (dataset-level metadata). Spatial object-level metadata is
any info then would be: fully described in the application schema (section 5).
If data quality elements are used at spatial object level, the
• for “managers” in the executive summary, documentation refers to the appropriate definition in section 7. This
• for “domain/data experts” in Chapter 2, section only specifies dataset-level metadata elements.
• for “technical experts” in Chapter 5
9 Delivery
5 Data content and structure 9.1 Delivery medium
9.2 Encodings
THE NITTY GRITTY OF THE DS!! (see next)
How the specification is exposed through network services and
encoding Includes a GML schema for each theme.

14. Data Specifications (DS) – Document Structure Detail
10 Data Capture
Data capturing rules are the main element to
define the targeted level of detail. For instance,
there may be a need for transport networks on two
levels of detail (at the European level, scale about
1:1000000 and at the local level, scale about
1:10000) with very similar feature catalogues.
However, the data will be very different. Bibliography
This difference is a result of different capturing
rules / selection criteria for both levels of detail. Annex A (normative) Abstract Test Suite
11 Portrayal Place holder for future conformance test suite
11.1 Layer types
11.2 Default Styles Annex B - E (informative)
11.3 Other Well-defined Styles
11.4 Layers organization
These include a description of the use cases on
There is no requirement in the Directive which the data specification is based
about portrayal, but to guarantee that spatial data
is portrayed consistently from the different MS
some rules are thought necessary.
The section defines the rules for layers and
styles to be used for portrayal of the spatial object
types defined for the theme.
The majority of these (currently) are black
and white and so there will be work required as
part of the developing maintenance process.

15. Data Specifications (DS) – Ch 5 – Application Schema
5.2 Application Schema
5.2.1 Description
Narrative Description & UML Overview
Consistency Between Datasets
Identifier Management
Modelling of Object References
Geometry Representation
Temporality Representation
This section provides you with a more detailed
overview of each individual application class Area Management, Restriction and Regulation Zon...
schema comprising the data specification
«featureT ype»
ManagementRestrictionOrRegulationZoneCollection
+ inspireID: Identifier [0..1]
+ legalBasi s: LegislationReference [0..1]
constraints
{legalBasi s mandatory if not provided on ManagementRestrictionOrRegulationZone}
«dataType»
AlternateIdentifier
Provides a set of UML diagrams which
+ identifier: CharacterString
+ identifierScheme: CharacterString
Encoding recommendation 1: legalBasis
the legalBasis shall be defi ned as a minimum at the highest level
+relatedZone
+member 1..* of Legislation (e.g. EC).
0..*
«codeList»
summarise the application schema
«featureType» T hi s is required to enable European scale data discovery.
ZoneTypeCode
ManagementRestrictionOrRegulationZone
+ airQualityManagementZone Encoding recommendation 2: LegalBasis
+ inspireID: Identifier It i s recommended that if the legi sl ation has been transposed i nto
+ noiseManagementZone
+ thematicID: AlternateIdentifier [0..*] Member State or regional l egisl ation these legislations shoul d be
+ avi anInfluenzaRestricti onZone
+ geometry: GM_Object provi ded.
+ bluetongueRestrictionZone
+ prospectingAndMiningPermitArea «voidable»
+ regulatedFairwayAtSeaOrLargeInlandWater + name: GeographicalName [0..*]
+ restrictedZonesAroundContaminatedSites + zoneType: ZoneT ypeCode
+ areaForDumpingOfWaste + speci alisedZoneType: SpecialisedZoneT ypeCode [0..1] /* One of ei ther managementInformation or
+ coastalZoneManagementArea + validTime: T M_Period restrictionOrRegulationInformation is mandatory */
+ restrictedAreaAroundDri nkingWater + competentAuthority: CI_ResponsibleParty inv: self.managementInformation->notEmpty() or
+ nitrateVulnerableZone + legal Basis: Legisl ationReference [0..1] self.restrictionOrRegulationInformation->notEmpty()
What is UML?
+ riverBasinDistrict «voidable, lifecycl eInfo»
+ marineRegion + beginLifespanVersion: DateT ime
+ bathingWater A
+ endLifespanVersi on: DateT ime [0..1]
/* T ype of geometry shall be GM_Surface or
constraints
GM_Multi Surface */
{legal Basis mandatory if not provided on SpatialDataSet level}
+managementInformation 0..1 inv: geometry.oclIsKindOf(GM_Surface) or
{Geometry shall be surface or multi-surface}
«voidable» geometry.ocl IsKindOf(GM_MultiSurface)
{Either managementInformation or controlledActi vity is mandatory}
«dataT ype»
ManagementInformation
Formal, graphical modelling language for
«voidabl e» «codeList» «codeList»
+ managementPlan: CI_Citation [1..*] «union» ControlledActiv ityType DayTypeCode
RestrictedPeriod + agri cul tureAquacultureAndForestry + monday
+controlledActivity + environmental Pollution + tuesday
«voidable» 0..* + validTi me: TM_Period
«codeList» + scheduledPeriod: Schedule + resourceExtraction + wednesday
SpecialisedZoneTypeCode «dataT ype» + fishingHuntingOrCollecting + thursday
defining conceptual data models and
ControlledActiv ityInformation + transportation + friday
+ landUseAndPlanning + saturday
+ controlMeasure: ControlTypeCode «enumeration» + riskManagement + sunday
+ activity: ControlledActi vityT ype [1..*] «dataT ype» ControlTypeCode + conservation + weekdays
«voidable» Schedule + weekends
«codeList» permitted + publicHoliday
+ specialisedActi vity: Speciali sedActivityT ypeCode [0..*] + day: DayT ypeCode restricted
SpecialisedActivityTypeCode + descri ption: CharacterString [0..1]
additional business rules. All documentation
+ startT ime: T M_Position prohibited
+ restrictionPeriod: RestrictedPeriod [0..*] + endTi me: TM_Positi on promoted
+ activityLegalBasis: LegislationReference [0..1]
and implementation schemas (e.g. XSDs) are
automatically generated from UML
Slide content courtesy Debbie Wilson, Snowflake Software

16. Consistency & Identifiers
5.2 Application Schema This section shall define any requirements or recommendations to ensure consistency and
5.2.1 Description interoperability.
Narrative Description & UML Overview
Consistency Between Datasets Examples sub-sections include:
Identifier Management Consistency along boundaries
Modelling of Object References
Geometry Representation Consistency at the same level of detail
Temporality Representation
Consistency between different spatial objects in the same area
Consistency between spatial objects from different themes
No requirement under INSPIRE legislation to mandate that Annex III themes are
assigned a unique, persistent identifier
5.2 Application Schema Each theme has identified requirements for identifiers and their management if they
5.2.1 Description use the Identifier type from GCM
Narrative Description & UML Overview
Consistency Between Datasets Requirement for making identifiers mandatory in Annex III include:
Identifier Management
Modelling of Object References Linking other information to the object e.g. Management Plans
Geometry Representation
Defining relationships to other spatial objects e.g. inclusion of references to monitoring facilities in
Temporality Representation observations
Some themes may also define additional identifiers (backwards compatibility) and should describe any
management issues for these too

17. Object References
5.2 Application Schema
5.2.1 Description
Narrative Description & UML Overview
Consistency Between Datasets
Identifier Management
Modelling of Object References
Geometry Representation
Temporality Representation
Provides guidance to understand how associations to other spatial objects should be
implemented within the scope of the theme
Content of this section varies across the data specifications
Examples from Annex I:

Objects shall carry a thematic identifier to enable linkage with information in national
registers

If the same real-world object is exchanged in more than one Hydro application schema then
they shall carry the same name or hydroID

Each lower level admin unit shall be linked to an upper level unit

18. Geometry Representation
5.2 Application Schema
5.2.1 Description
Narrative Description & UML Overview
Consistency Between Datasets
Identifier Management
Modelling of Object References
Geometry Representation
Temporality Representation
This section shall define any requirements, recommendations and additional
guidance describing how the geometry shall be encoded:

Restrict geometry encodings to Simple Features profile

Define which geometries shall be provided where the geometry type is the
high level GM_Object type

Geometric/Topological constraints

Geometry must be explicitly defined even if derived from another spatial
object vs using referencing for encoding shared geometries

19. Temporal Representation
5.2 Application Schema
5.2.1 Description
Narrative Description & UML Overview
Consistency Between Datasets
Identifier Management
Modelling of Object References
Geometry Representation
Temporality Representation
This section shall define any requirements/recommendation or
guidelines for understanding how to implement any temporal
properties:

Implementing INSPIRE lifecycleInfo properties:

beginLifespanVersion

endLifespanVersion
NOTE: Guidance for lifecycleInfo properties same for all data
specifications

Real-world temporal validity properties

validFrom/validTo

startTime/endTime

20. Feature Catalogue
5.2.2 Feature Catalogue – consists of tables
Feature Catalogue Metadata
Types defined in the Feature Catalogue
Spatial Object Types
Data Types
Code lists
Informative section – description of
types imported from external schemas
The Feature Catalogue is
the key section to read as it
provides definitions and
descriptions of:

Class types (Feature types, data
types, code lists/enumerations)

Property/Attribute values

Associations

Constraints

21. Timeline

22. UK HFE as INSPIRE Data Consumer
Academics and researchers in a wide range of fields are
likely to benefit directly by easier access to data
facilitated by the Directive.
The vast majority of collection development
expenditure by JISC and the research councils
has focused on the UK and on core reference
data sets.
Much UK research is about places outside the UK.
Researchers can face real difficulty in getting access
to geospatial data in other countries.
The ability to make seamless connections across
the wide range of data types and thematic areas will,
as well as reducing the barriers to accessing data,
also open up new opportunities for understanding
all kinds of change processes and enable national
and international comparisons.

23. More Info
Draft IR: 03-21 September 2012
Done by JRC data specification team with support from
TWGs
Until then:
Still time and need to participate!!

24. More Info
More Info on INSPIRE at:
http://inspire.jrc.ec.europa.eu/
More info on UK LP at:
http://location.defra.gov.uk/
More info on INSPIRE&UKLP for HE/FE at:
http://geco.blogs.edina.ac.uk/category/inspire/
James S Reid
Geoservices, EDINA
University of Edinburgh
e:James.reid@ed.ac.uk
t: +44 (0)131 651 1383
m: 0759 5116988
sk: indolentJ
tw: @sixfootdestiny

26. What is a Directive?
An EU Directive is a European Union legal instruction or
secondary European legislation which is binding on all Member
States but which must be implemented through national
legislation within a prescribed time-scale.
INSPIRE was translated into the UK legal framework via the
INSPIRE Regulations in December 2009.
The clock for delivering key milestones is ticking...

27. INSPIRE – an European SDI
A little more on the policy drivers...
Implementation of INSPIRE in the UK will deliver a step change in data
management, data interoperability and data sharing across the public sector,
supported by better integration with mainstream information services.
“citizens will have ready access to the information they need to go about their daily lives,
whether at home, in business, in research or in government. Doing this will exploit the full value
of the UK’s spatial information.”
Specifically, this will allow us to:
Know what data we have, and avoid duplicating it;
Use common reference data so we know we are talking about the same places;
Share spatial information easily through a common infrastructure of standards,
technology and business relationships.