European Commission logo
INSPIRE Community Forum

Referencing LAEA km grid

According to the data specification for population, a href reference should be made to the spatial unit the statistical value is connected to. I wish to use the ETRS89-LAEA km-grid for this. The data specification on Geographical Grid Systems specifies the URI for this, as http://inspire.ec.europa.eu/grid/etrs89-laea/1kmN2599E4695. My problem is that this URI does not exist, it is a broken link. What to do? I am aware of the discussions about SDMX, which might have solved the problem, if a way forward was found. But this approach seems to be halted right now. The deadline in October is approaching. What to do?

  • Katharina SCHLEIDT

    By Katharina SCHLEIDT

    Hi Andres,

    I fear you've over-weighted a recommendation, the only mention of this URL within the INSPIRE dataspec for grids is the following:

    Recommendation 2 Where applicable, the following URI pattern should be used to refer to the Grid_ETRS89-LAEA:
    http://inspire.ec.europa.eu/grid/etrs89-laea/<resolution&gt;

    In addition, we find this example below the rec:

    EXAMPLE For the grid at a resolution level of 100km the following URI should be used: http://inspire.ec.europa.eu/grid/etrs89-laea/100k

    So, first a correction to your URL, you need a resolution bit before the explicit cell name, should be more like

    http://inspire.ec.europa.eu/grid/etrs89-laea/100k/1kmN2599E4695

    Second, a bit of realism (sometimes referred to as cussed pessimism when coming from me ;) ) - I seriously doubt that these standard URLs will be appearing in the next weeks or months :(

    Ideally, Eurostat would expose what they're providing as shapefiles at https://ec.europa.eu/eurostat/web/gisco/geodata/reference-data/population-distribution-demography/geostat once for all MS to reuse. In reality I've also gotten lost on what the plan for statistics is other than hopes that SDMX will just make geo go away ;)

    In reality, it would probably be simplest if one MS put this base layer up for all users (really not that much work, could probably do this in a week or 2 max). This would be a way around wasting months on discussing who could/should do this work...

    Sorry!

    :)

    Kathi

     

  • Andres OSTMAN

    By Andres OSTMAN

    Hi Kathi and thanks for you reply

    First, there is a lot of inconsistencies in the data specification for GGS about the URI's, so we don't have to spend time on how to write them properly.

    You confirm my suspicion that the standard URI's will not be appearing during the coming months. For me it is good to have this confirmed, although not yet from an authoritative source.

    The data spec for population requires a href to the specific grid cell. Even if the grid is provided as a shape file, I can not make a href to a single grid cell within the shape file, at least not to my knowledge.

    We'll decide on our solution after the summer break. Until then, I am interested to hear all suggestions.

    Kind regards

    Anders

  • Katharina SCHLEIDT

    By Katharina SCHLEIDT

    Hi Anders,

    a few more thoughts (to date I'd only used grids in the coverage context, now looked a bit further):

    • As this is a European dataset, I do not see a requirement for a MS to provide this (reasoning for the EC URLs in the data spec)
    • For provision of data under PD, you only need to provide the reference in the xlink. If the target of this xlink is beyond your governance, I don't think this is your problem
    • Provision of the recommended URIs (http://inspire.ec.europa.eu/grid/etrs89-laea/1kmN2599E4695 ) could actually make sense. While there is no data available, the grid cell is correctly and uniquely referenced, the data user must provide the spatial aspects from alternative sources until the EC provides their data on this

    Finally a question - is there some player in the statistical community one could encourage to provide this? While my suggestions above should lead you to a correct endpoint for PD, I do find it frustrating that European statistical data remains separate from the wider spatial world! This would be such a valuable layer for many activities, sad that it remains locked in silos where only the initiated have access!

    :)

  • Mirosław MIGACZ

    By Mirosław MIGACZ

    Hi Anders, Kathi,

    I'm afraid that instead of answers I can only provide more questions...

    Statistics Poland has only one PD grid dataset from the last census (2011). We published it only as a downloadable dataset in our ATOM feed for PD, which serves as a download service. We also published a SU grid dataset with the ETRS89-LAEA grid in GML in a similar ATOM feed for SU.

    However:

    - for both datasets we didn't use the generic GG grid (as we were probably supposed to), we used the grid cell code as designed in the SU data specification (a bit more info for each cell, incl. resolution and coordinate reference system), e.g. CRS3035RS1000mN2998000E4938000

    - each PD value does have an xlink in pd:spatial to a single cell, but the xlink is not resolvable, as all data have been published in downloadable ZIPs. So basically we put links we would want to be there, had we implemented a fully functional WFS for example :)

    - both the SU and PD grid datasets encoded in GML had to be divided into 75 100kmx60km sectors in order for the GML files to be readable on computers. The whole dataset was simply too large to be processed in any way.

    Feel free to dive in and have a look at the datasets:

    PD: http://geo.stat.gov.pl//atom_web-0.1.0/atom/PD?language=pl&spatial_dataset_identifier_code=PD.GRID.2011&spatial_dataset_identifier_namespace=PL.ZIPGUS.2827

    SU: http://geo.stat.gov.pl//atom_web-0.1.0/atom/SU?language=pl&spatial_dataset_identifier_code=SU.GRID&spatial_dataset_identifier_namespace=PL.ZIPGUS.312

    As for SDMX, I still can't get my digital hands on a working prototype or example of this solution to even start assessing its geo-usability.

    Aside from the not-exactly usable GMLs we provide all our data in SHP.

    The fact of the PD spec not being usable has been reported to JRC multiple times. The SDMX reporting was supposed to be a solution but I've yet to see it actually working.

    :)

  • Katharina SCHLEIDT

    By Katharina SCHLEIDT

    Hi Miro,

    to your statement "we didn't use the generic GG grid" - assuming you're referring to the Geographical Grid Systems defined under Annex I, with only a dataspec, but no model? To my limited grid understanding, this was foreseen as only the underlying logic of the grid (origin&offset+projection), not for provision. The only providable grid cells I've found are StatisticalGridCell under SU, nicely in line with the PD spec, so I'd assume you've done the right thing!

    Question - as you've already done the hard part of transformation and GML encoding, would it be permissable to reprovide this data via a WFS?

    Also - I do see a few glitches in your encoding:

    • What's the reason for 7 digits on N & E instead of the usual 4 digits?
    • I'm assuming that the "1KN" bit in the string refers to the 1km grid? Any reason for the "N"?
    • As I'm a grid idiot - would the identifier link below refer to the cell "N2900E4920" (while further specifying the average altitude as 100m?

    Example URL I pulled out of the data file where the GML encoding is contained:

    http://geo.stat.gov.pl/INSPIRE/dane/PL.ZIPGUS.312.SU.GRID.ETRS89LAEA1KPL/ETRS89LAEA1KN2900000E4920000W60H100/CRS3035RS1000mN2994000E4940000

    :?

    Kathi

  • Mirosław MIGACZ

    By Mirosław MIGACZ

    Hello Kathi!

    The grid situation in INSPIRE is a tad more complicated. While SU is actually a theme with a data spec tailored for grid provision, it is also required to use the GG grid for pan-European usage. The SU grid is a more flexible approach to grids, cause it allows resolutions other than powers of ten, and coordinate reference systems other than ETRS89-LAEA. Therefore it has more information in the grid cell code, while the code itself is constructed differently:

    if the coordinate reference system is projected, the word RES followed by the grid resolution in meters and the letter m. Then, the letter N followed by the northing value in meters, and the letter E followed by the easting value in meters too

    This explains the trailing zeros.

    In our dataset the part: ETRS89LAEA1KN2900000E4920000W60H100 depicts a 100x60 km sector, so it does not follow the cell code construction rules.

    Anyway, we only created the dataset for the area of Poland and will probably recreate it, while rebuilding our geoportal. Maybe we'll manage to publish a WFS while we're at it. Who knows?

    :)

    Miro

  • Andres OSTMAN

    By Andres OSTMAN

    Hi Miro and Kathi,

    Sorry for late reply, but I read your posts with great interest.

    @Miro: I understand your solution as follows

    1. Your SU theme consists of several zipped XML files, each one covering 6000 grid cells (100 x 60 cells). Links to these XML files are provided in the ATOM feed. The PD theme is structured in a similar way.

    2. Each SU XML file specifies a grid. There are however here a couple of things I don't understand. I notice that each grid cell is identified by the gml:id attribute and also the gml:identifier element. The gml:id attribute seems to be an internal identifier and that is fine to me, as long it is unique. However, the gml:identified element is assigned the full URI of the grid cell, "http://geo.stat.gov.pl/...&quot; When trying to access these URI's from the browser, I got the result that the resource is not found. As I understand, to make reference to a cell, one should use the gml:id instead as an xpointer, for instance "http:://geo.stat.gov.pl/....gml#gml:idAttributeValue&quot;.

    3.   I am aware of the way you assign linkages is in accordance with the INSPIRE FAQ #59309. But have you tested that your way of assigning URI's actually work? Have you for instanced checked it with the INSPIRE validator?

    Kind regards

    Anders

     

     

  • Mirosław MIGACZ

    By Mirosław MIGACZ

    Hi Anders!

    1. Yes, this is exactly how it works.

    2/3. Not sure if I mentioned but the GMLs were prepared for us by an external company 5 years ago when we did a project rebuilding our geoportal. Not sure if the gml:id is correct, but quite sure it is unique. The gml:identifier however is a non-resolvable URL (as mentioned in one of the previous replies) simply because it had to be a URL and we nor the contractor didn't have an idea to implement it in a resolvable way. The reference identifier for the grid is the one used in:

    <su-grid:code>CRS3035RS1000mN2995000E4941000</su-grid:code>

    We will be rebuilding the services and datasets soon, either ourselves or with help of another contractor (a new project for rebuilding our geoportal is under way). However we are not sure how to go about publishing the SU and PD themes, to be honest:

    • as Kathi mentioned, there is no point in publishing those specific grids on a national level, since they are used to present data on a European level,
    • there is no word on Eurostat publishing an INSPIRE service / dataset with the EU grid, even though some grid referenced population datasets are published by Eurostat (results of European projects),
    • there will be further confusion as to the SU grid identifier, since the EU regulation on the population and housing census introduced a country code prefix before the grid cell identifier, making the above mentioned ID look like this: PL_CRS3035RS1000mN2995000E4941000,
    • there still is no consensus on how to publish PD data - the current model is unusable, while the SDMX proposal is supposedly endorsed but only as a good practice, since there are no guidelines or a working prototype.

    As for the resolvable links we have some experience with publishing linked open data and providing a working triple store with resolvable URIs. Not sure if it's a correct way to go about it...

    Kind regards

    Miro

  • Andres OSTMAN

    By Andres OSTMAN

    Hi Miro,

    Thanks for your detailed response. FYI, I am working with Swedish Statistics (SCB) on the INSPIRE implementation, but I am not an employee or representative of SCB. My task here is to give recommendations about possible implementations. This means that we are not sure either on how to implement PD and SU themes. As I see it right now, we have two option.

    1. We can follow the recommendations in the SU technical guidelines and use their (non-resolvable) URI's for the the PD datasets. We will then have a number of "broken linkages", but this problem is not new to the Linked Data community.

    2. A second option is to publish the SU as XML, similar to what you have done, but not as zipped xml's. Then we will use xpointers to the gml:id attribute for linking the PD data to the SU's.

    I think triple store is too early right now. We are currently focusing on passing the INSPIRE validators and I think both solutions above do it properly, but I have not tested it yet. Linked Open Data (LOD) seems however to be in the pipeline for the next "version" of INSPIRE. We made a study on LOD a couple of years ago, but we could at that time not find any clear value propositions for such an approach. But things change over time ...

    One way of integrating INSPIRE and SDMX is given in https://www.unece.org/fileadmin/DAM/stats/documents/ece/ces/ge.58/2017/mtg3/2017-UNECE-Standards-Workshop-INSPIRE-SDMX-paper-V2__1_.pdf. I think this approach seems to be feasible and it makes sense to me. 

    I will continue my discussions with SCB within the next weeks and if you wish we may share more ideas and experiences. My email is Anders.Ostman@novogit.se

    Kind regards

    Anders  

     

  • Katharina SCHLEIDT

    By Katharina SCHLEIDT

    Hi Miro, Anders,

    On providing resolvable clean URLs for the grid cells, I've also run into this issue (all over INSPIRE, one of the many elephants in the room!). I did some work on this for one of my clients, they were nice enough to let me write it in English and made it publicly available:

    https://inspire.austrocontrol.at/resources/download/GuidelinesURLrewritting_v2.0.pdf

    Actually quite simple once one figures out the trick :) Still think it should be provided centrally by Eurostat or JRC

    As to the PD model, I'm wondering if it would become semi-sane if one upgraded the StatisticalValue dataType to a featureType and exposed this? Far from perfect, but possible to provide and use

    :)

    Kathi

Statistics & Health

Statistics & Health

Join this group if you would like to share knowledge or ask questions regarding the INSPIRE implementation of Statistical Units [SU], Population Distribution (Demography) [PD] or Human Health and Safety [HH] data themes