Difference between revisions of "INSPIRE"

From OSGeo
Jump to navigation Jump to search
m (Adding GeoServer)
m
Line 53: Line 53:
  
 
=== What is already available? ===
 
=== What is already available? ===
−
* Viewing services ([[MapServer]], [[deegree]], [[MapGuide]], [[Mapbender]], [[OpenLayers]],[[GeoServer]], others)
+
* Viewing services ([[MapServer]], [[deegree]], [[MapGuide]], [[Mapbender]], [[OpenLayers]], [[GeoServer]], others)
 
* Discovery services ([[GeoNetwork]], [[Mapbender]], [[deegree]], [http://pycsw.org pycsw], others)
 
* Discovery services ([[GeoNetwork]], [[Mapbender]], [[deegree]], [http://pycsw.org pycsw], others)
 
* Download services ([[deegree]], [[GeoServer]], [[MapServer]], others)
 
* Download services ([[deegree]], [[GeoServer]], [[MapServer]], others)

Revision as of 13:39, 9 November 2016

INSPIRE is a European based approach at solving interoperability issues for gespatial data. Join the INSPIRE Mailing list.

Introduction (from http://eu-geoportal.jrc.it/)

INSPIRE (Infrastructure for Spatial Information in Europe) is an initiative launched by the European Commission and developed in collaboration with Member States and accession countries. It aims at making available relevant, harmonized and quality geographic information to support formulation, implementation, monitoring and evaluation of Community policies with a territorial dimension or impact. INSPIRE intends to trigger the creation of a European spatial data infrastructure that delivers to the users integrated spatial information services linked by common standards and protocols.

The INSPIRE Geo-Portal is Europe's Internet access point for Spatial Data and Services. From there, you can search for spatial data, services, and organisations.

The INSPIRE Components

There are five major components:

  1. Metadata. Well, we know that Metadata is data and so on. Intriguing topic. The current interpretation of INSPIRE clobbered metadata long enough with ISO profiles to almost kill it.
  2. Network Services. Performance, uptime, bindings, etc. & still under work.
    • Discovery Services. Probably something like Catalog Services but it is as yet unclear why they should: ...making it possible to search for spatial data sets and services on the basis of the content of the corresponding metadata and to display the content of the metadata
    • View Services. Straight forward: Digital maps served through WMS 1.3 / ISO 19128. ...making it possible, as a minimum, to display, navigate, zoom in/out, pan, or overlay viewable spatial data sets and to display legend information and any relevant content of metadata;
    • Download Services. Straight forward: Digital data served through WFS 2.0 / ISO 19142) -> see this discussion ...enabling copies of spatial data sets, or parts of such sets, to be downloaded and, where practicable, accessed directly;
    • Transformation Services. Rubbish. The original idea was that a web service would be able to transform existing data by mamber staed on-the-fly for further processing. This is usually done offline in the basement on number crunchers. ...enabling spatial data sets to be transformed with a view to achieving interoperability
    • Services ... allowing spatial data services to be invoked. (I never really got this one?)
  3. Data and Service Sharing. Licenses, copyright, all the fun stuff that prevents us from using data in our software.
  4. Data Specification. The tricky bit is the harmonization of data that is need prior to setting up the actual service. This currently requires lots of transformations with GML 3.2.1 (and not enough software packages supporting 3.2.1 does not help either)
  5. Reporting and Monitoring. This is more domain specfic to EU public administrations. Not clear yet whether any software will be involved in this. But the monitoring services will be of help to control things.

The Annexes list themes that need to be made available in three stages until well into 2016 and possibly even 2019. The first themes are:

  1. Coordinate reference systems
  2. Geographical grid systems
  3. (GN) Geographical names
  4. (AU) Administrative units
  5. (AD) Addresses
  6. (CP) Cadastral parcels
  7. (TN) Transport networks
  8. (HY) Hydrography
  9. (CP) Protected sites

OSGeo's involvement

There is no coordinated effort at involving OSGeo as an organization in the INSPIRE initiative but many OSGeo projects are already tied into processes and the emerging INSPIRE architecture. A formal meeting of OSGeo representatives with people (from JRC) involved in INSPIRE was planned for the end of 2008 but never happened. In 2010 JRC and OSGeo joined forces to make an Open Source Mash-up at the INSPIRE conference possible.

FIT/GAP analysis

How good does Open Source GIS software fit into the INSPIRE picture? Can it be used as a software stack to build INSPIRE SDI's? It would be interesting to make a fit/gap analysis between what the INSPIRE standards require and what the OSGeo stack provides. Also, a plan could be made up to fill in the gaps (in time). The reasoning behind this is that the regular customers will not be able to make this analysis by themselves, so it would be good to have something written up. Of course this is an ongoing effort as not many of the standards are final as yet, and most are still in draft.

Who is interested in collaborating in such a fit/gap analysis?


What is already available?

What is still missing?

  • Comprehensive tutorial / how to / white paper on security of SDIs.
  • Some stuff emerging now through ESDIN deliverables. Find more information on the requirements in the ESDIN Wiki.
  • GML 3.2.1 support in GeoServer (already available in deegree3)

What is in progress?

Presentations

Use Cases


Conference

See also

Blogosphere
OSGeo INSPIRE Initiatives
Retrieved from "http://wiki.osgeo.org/w/index.php?title=INSPIRE&oldid=104079"