INSPIRE Thematic Clusters

  • Liked content

Most liked content

  • Good news - WPS service that accepts WFS2.0 GML3.2 data

    Started by Sorin RUSU in the group Protected Sites
    Hi everyone, I have just successfully used GML3.2 data in a geospatial analysis using a WPS1.0 server. The input data is obtained from INSPIRE Download Services, for two data themes: ps:ProtectedSite and br:Bio-geographicalRegion, and it was...
  • By Iurie MAXIM

    Hello everybody,

    I. Regarding the topic "Serving data in multiple CRS using ATOM services" ....

    The TG for INSPIRE Download Services available here is providing several Requirements regarding ATOM and CRS.

    See chapter 5 Atom Implementation of Pre-defined Dataset Download Service​ (starting from page 34):

    A. At page 48 Section 5.1.20 Download Service Feed: entry „category‟ element – CRSs there are some details and a requirement

    TG Requirement 20 Each feed entry shall contain an Atom ‗category‘ element for each CRS in which the pre-defined dataset is available. This category element shall refer to a well-known definition of a coordinate reference system

    This Technical Guidance places no requirements on the coordinate reference systems in which data should be made available. Guidance and requirements for coordinate reference systems is given in the thematic Data Specifications and the regulation on the interoperability of spatial datasets and services [INS SDS].

    B. Shortly, how to implement ATOM feeds (with one or more CRSs) is described at page 35:

    <<This Technical Guidance recommends using Atom feeds to make available pre-defined datasets in a consistent manner. The guidance in this chapter can be summarised at a high-level as follows:

    - A single Atom feed is published as a top-level ―Download Service Feed

    - This feed contains a link to an OpenSearch description document which provides operations metadata for the Download Service. The OpenSearch description document provides information about the operations implemented by the download service.

    - This feed contains one or more Atom entries: one per pre-defined data set. Each of these Atom entries shall contain a link to another Atom Feed (a ―Dataset Feed‖) that describes the particular pre-defined data set.

    - Each of these ―Dataset Feeds‖ shall contain Atom Entries with links to download the predefined dataset in different formats (e.g. in GML, ShapeFile, etc.) and in different Coordinate Reference Systems. One link shall be provided for each format/CRS combination.

    - Feeds may be provided in multiple languages (as described in Section 5.3)

    This pattern is illustrated further in Figure 5.>>

    Reading entire chapter is necessary in order to understand how to implement ATOM

    II. As regards the conclusion <<It should not be a problem to have other non-compliant datasets published "aside">> this is not true. All non compliant datasets will be treated as such by EC Vakidator. All non compliant datasets will create problems to both human users and machines. If it will become a common practice to provide non-compliant datasets, than finding compliant datasets will nbe a difficult process for users looking for compliant data. If the majority of datasets will be non-compliant as it is the case now with most of the datasets, then Idata provided within NSPIRE is not usable.

    It is not too difficult to put non-compliant datasets outside INSPIRE. It is enough just not to include their metadata in the CSW services that are indexed at the national level and then in the EC Geoportal or to create separate download services (INSPIRE compliant and INSPIRE non-compliant)

    Best regards,

    Iurie Maxim

  • By Peter PARSLOW

    Yes, the OGC validator only validates against OGC schemas & specs, so it's only a partial validation against INSPIRE requirements.

    However, you can extend the validation by providing your own schematron rules (an extra '&sch=URL' parameter). Or set up your own instance of the underlying TEAM Engine - I believe Germany have quite some experience with that. There was also some discussion between INSPIRE 'MIG' and OGC about them hosting validation, once we've designed the rules.

    OS Terrain is available in vector & grid flavours. We offered TIN to our market in the UK, but there was very little interest - we'd need to do more to sell the benefits of a TIN to people who are used to working with grids.

  • EarthServer-2 Project

    Information about the project Earthserver-2 which includes interesting material about Big Data, WCS and WCPS.  http://www.earthserver.eu/ http://www.earthserver.eu/webinars
  • INSPIRE Conference 2016

    By Stefania MORRONE Comments (1)
    Among the several scheduled sessions and presentations, I would like to point out a few that are strictly related to Biodiversity or that are dealing with cross cutting topics such as network services, validation tools and...
  • By Stefania MORRONE

    Hi Keiran,

    both in the HB and the SD case, you can use the "spatialObject" association to reference another spatial object defining the spatial extent of your distribution unit. You can choose even how to provide, I mean as external link - i.e."href"- or embedded description i.e. replicate the SR/AM/AU spatial object in the SD/HB dataset.

    Using the 'external link' encoding option, you can provide the PID of the referenced object e.g. the GetFeature request to the WFS service exposing the feature you need.

    For example, you can encode the request for an Administrative Unit as

    <sd:spatialObject  xlink:href=" http://geoportal.ancpi.ro/arcgis/rest/services/AU/AU_Download/GeoDataServer/exts/InspireFeatureDownload/service?SERVICE=WFS&VERSION=2.0.0&REQUEST=GetFeature&STOREDQUERY_ID=urn:ogc:def:query:OGC-WFS::GetFeatureById&id=auAdmUnitS.4/>

    Hope this helps

    Stefania

  • Human health and safety [HH]

    Join this group if you would like to share knowledge or ask questions regarding the INSPIRE implementation of Human Health and Safety [HH] data theme.
    Sub-Group of Statistical Cluster

  • By Guillermo VILLA

    In orthoimagery, we should differentiate two different cases:

    Case 1: Aerial orthophotos. The main problems here are: data production, storage, compression, efficient multiscale serving through Internet (WMS and WMTS services) and quick and flexible visualization and layer overlay with simple web viewers or GIS clients. WMTS servers introduce the need for pyramidal tiling and to work in a single projection. Consequences: It is not practical to have data in different UTM zones, WMTS client and server must work in the same projection, etc…

    Case 2: Satellite images. Remote sensing tendencies in the last years are: multitemporal  and multiscale analysis, integration of data from different sensors and massive parallel and cloud processing of great amounts of data (Big Data technologies).

    In both cases, 1 and 2,  the non-alignment of the pixel borders of georreferenced imagery causes very big interoperability problems:

    - For orthophotos: the need to apply multiple reprojection and resampling operations (causing great costs in processing time, storage space and also degradation of image quality).

    - For satellite imagery: impossibility to directly compare radiometric values for different dates (with very negative consequences in multitemporal analisys, change detection, etc.)

    These interoperability problems happen not only with datasets produced by different producers, but also with single producers. For example, Landsat 8 images are being geometrically corrected in different UTM zones (and ESA plans to do the same for Sentinel 2 images).

    These problems are seriously hampering the development of new technologies, operational applications and business models.

    For orhophotos and satellite images, the solution could be the same: we should reach an agreement on a single grid to produce, store, process, analyze, compare and serve orthoimagery. This grid should be fixed, multiscale (pyramidal), “nested” (2 by 2 pixels of one level of the pyramid should be exactly contained in one pixel of the upper level), assure the alignment of pixel borders at all pyramid levels, and cover the whole earth (or at least the biggest part of the inhabited areas) in a coherent and efficient way. The grid should use a conformal projection in order to avoid “strange” looking of common features like buildings, roundabouts, etc. and a disagreeable kind of “perspective effect” in areas other the equator.

    Inspire recommends the use of a common grid to address some of these problems, but the recommended Zoned Geographic grid does not comply with some of the requirements mentioned above, and does not contain a tiling schema.

    In the last times a “de facto” standard grid has emerged in WMTS services: the one of the tiling schema based on the “Spherical Mercator” conformal projection (EPSG:3857) used by Google Maps, Bing Maps, Yahoo Maps, Open Street Maps and other tiled data and API providers. This grid and tiling schema is fully documented and supported by a great number of software open libraries.

    WMTS is in the process of becoming an official OGC standard (“WMTS simple implementation”), and fixes the projection and TileMatrixSet definition.

    The general acceptance of this tiling schema opens the way for a solution of all the problems cited before. Nevertheless, two remaining problems should be addressed:

    1) WMTS 256x256 pixels tiles are way too small to be practical as production, storage, and processing units. One easy solution is to use tile footprints of one level and pixel sizes of a different level. E.g: use Level 10 tile footprint, but Level 14 9.5546m GSD, so this “supertiles” are 4096x4096 pixels.

    2) “Supertiles” should have overlaps between them, to avoid (or at least minimize) border effects when we perform operations like filtering, classifications, segmentations, etc. These overlaps should have a width of 2n pixels (256, 512, 1024,…) in order to maintain nested pyramidal overlaps. Overlap pixels should be added at the right and below the supertile, in order to maintain the upper left corner position and avoid georreferencing burden.

    A solution in this direction could be proposed to Inspire and should be proposed also to Copernicus and ESA.

  • Preliminary proposals for modifications of the Technical Guidelines on Land Cover and Land Use

    Last updated by Lena Hallin-Pihlatie
    The aim of this page is to gather preliminary proposals for modifications of the Technical Guidelines on Land Cover and Land Use that may be forwarded to the INSPIRE MIG-T MIWP-14 for endorsement and potential implementation....