Dimension type: geographical

[jstcki]

Cross-posting from https://github.com/zazuko/query-rdf-data-cube/issues/40

There will be two kinds of geographical dimensions.

1. Discrete (nominal) values that reference known geographical entities (e.g. Zürich -> Municipality of Zürich, Zürich -> Canton of Zürich)
   • Important here is that it's not necessary to fetch shape data (GeoJSON) with this library. The relevant part is that a known entity is referenced, e.g. https://ld.geo.admin.ch/boundaries/canton/2:2017
   • The main question for me and for this library to solve is how to traverse these links or how to specify which "fields" to include from the linked resource (e.g. the bfsNumber)
2. Continous values that represent coordinates (ie. points on a map)
   • To be usable on the web these must be WGS84 lon/lat value pairs (not sure how this is represented in RDF)
   • Likely, source data will also contain Swiss grid coordinates (either LV03/LV95 or both) -> I expect these to be converted to WGS84 in the data integration step

[ktk]

• 1. Probably solved via #6
     • additional information that might be useful could be attached to the shape from #6
• 2.
  • Do I have spatial data for this resource?
  • What is the path/model to fetch them?
  • Need to be modeled with examples

[ktk]

Defined in #6, example will follow in Elcom Electricity Price dataset

[Rdataflow]

@ktk are there example datasets containing references to existing geometries? (i.e. those provided by ld.geo.admin.ch)

• if yes: how can paths to geometry be traversed and GeoJSON be fetched in order to reuse for maps like quick example and beyond?
• if no: we could establish an example based on NFI data

[ktk]

@Rdataflow you could use swisstopo URIs at the observation, instead of the example here: https://s.zazuko.com/28wbzJ

Drawback is that this is a SPARQL endpoint outside so you would have to do a federated query (our query builder can do that but it's extra work).

Another way is to model your own municipality and then point to the swisstopo one via owl:sameAs or rdfs:seeAlso for example. You could then still attach standard labels to the resource so the visualization tool will work. For the use-case where you want to get the geometries, you follow the path to Swisstopo & get the shape via federation. Let me know when you want to play it through in a real world example.

[jstcki]

Is a federated query generally better than querying observations without shapes and then querying for the geometries in a separate query (which is how I probably would do it anyway since geometries only need to be loaded when a map is actually displayed)?

Either way the information of the geometries endpoint (e.g. ld.geo.admin.ch) would need to be represented somewhere (at the dimension level?), … The endpoint can't reliably inferred just from rdfs:seeAlso <https://ld.geo.admin.ch/boundaries/canton/1:2019> right?

Also, for standard administrative units like cantons etc. wouldn't you link to https://register.ld.admin.ch/canton/1 from the observation instead of to the geometry (like you did in the Elcom data)?

[ktk]

@herrstucki no fetching that separately is totally valid as well, good point.

And yes, to be able to know where to fetch it we would need additional metadata. I could imagine describing that in a shape as well and attaching the SPARQL endpoint to it there for example.

Last: Also correct, I noticed that I do not point to swisstopo from the simplified view (this is still WIP and it looks like BFS will make that "official" in the next months) so it would make sense to point to Swisstopo from there as well.

[Rdataflow]

Last: Also correct, I noticed that I do not point to swisstopo from the simplified view (this is still WIP and it looks like BFS will make that "official" in the next months) so it would make sense to point to Swisstopo from there as well.

@ktk great to know the missing link will be added in the future. To get a real world example the WSL team will contact you.

[jstcki]

Two more points to consider:

• Just linking from observation -> geometry is not sufficient, since observations may be missing for certain queries. To show a map however, you almost always want to show all geometries (see screenshot) to a) show missing data and b) show the map while observations are loading. So specifying a link to the set of geometries would be needed.
• Just because a geometry is linked, it may not necessarily be the best to use (quality, resolution)* etc. Not solvable generally but probably for standard ones (administrative boundaries), where we could "override" the choice of geometry.

*: There are at least 3 competing sets of boundaries: swissBOUNDARIES3D, swissTLMRegio (both from swisstopo) and Generalisierte Gemeindegrenzen from BFS. Not all of them available as Linked Data, and not all of them up-to-date there.

[l00mi]

In general I think the way to go is that geometry is never directly attached, but only a concept (like Municipality or Region) is possible. If it is of geographical nature, the metadata of the dimension does provide a path (e.g. https://www.w3.org/TR/shacl/#property-paths) where to find a geometry. The metadata of the dimension itself should be always complete in regard of the extend of scope (e.g. all Cantons of Switzerland ).

Another point to consider are the different versions of the maps. Especially in regard of showing the complete map. We might need a way for the user to be able to define which municipality structure (aka year of boundaries) is valid per:

• Full Dataset
• Per Intervall inside the Time Dimension (e.g. for every year another structure)
• or combinations there of (where e.g. the values of fusioned municpalities are combined)

[l00mi]

1. We will use the same links as in the elcom project for cantons and municipalities.
   • https://register.ld.admin.ch/municipality/*
   • https://register.ld.admin.ch/canton/*
2. For coordinates we expect WGS84 in the delivery and provide a structure to encode this.
   • The wgs84 coordinates will be added like a https://schema.org/GeoCoordinates with https://schema.org/latitude and https://schema.org/longitude to a external object.

<obs> <some_cube_link> <station1> .
<station1> schema:longitude "7.153656" .
<station1> schema:latitude "46.806403" .

[ktk]

@l00mi I still don't think using https URIs for schema.org is a good idea

[l00mi]

@ktk That was not intentional, and will happen again in the future. (Habit of copying from the browser bar.)

[Rdataflow]

1. We will use the same links as in the elcom project for cantons and municipalities.

• https://register.ld.admin.ch/municipality/*
• https://register.ld.admin.ch/canton/*

• How are geometries refered in those concepts? (the current response unfortunately is 404)
• What about versioning concept used in https://ld.geo.admin.ch/boundaries/canton/ i.e. https://ld.geo.admin.ch/boundaries/canton/2 hasVersion 2:2020
• What role play existing concepts https://ld.geo.admin.ch/biota/productionregion/ i.e. https://ld.geo.admin.ch/biota/productionregion/1 hasGeometry 1 or https://ld.geo.admin.ch/boundaries/canton/ https://ld.geo.admin.ch/boundaries/canton/2:2018 hasGeometry 1 NB: hasGeometry may refer to a reduced resolution (whenever made available) - in those cases defaultGeometry contains the detailed geometry

1. For coordinates we expect WGS84 in the delivery and provide a structure to encode this.

• The wgs84 coordinates will be added like a https://schema.org/GeoCoordinates with https://schema.org/latitude and https://schema.org/longitude to a external object.

<obs> <some_cube_link> <station1> .
<station1> schema:longitude "7.153656" .
<station1> schema:latitude "46.806403" .

IMHO this proposal contradicts the paradigm that geometry shall never be directly attached. https://github.com/zazuko/rdf-cube-schema-viz/issues/7#issuecomment-749637820 or shall lines 2&3 live in a separated concept space? what about stations changing location from time to time?

[l00mi]

This is now the first steps we implement with the BAFU. We will use the geometries in the next step.

So the proposed "simple" options will stay valid. But can be extended in the future.

[Rdataflow]

This is now the first steps we implement with the BAFU. We will use the geometries in the next step.

So the proposed "simple" options will stay valid. But can be extended in the future.

What do you refer to as simple? Is it this one?

<obs> <some_cube_link> <station1> .
<station1> schema:longitude "7.153656" .
<station1> schema:latitude "46.806403" .

Following my discussion with Sabine BAFU shall not publish geodata in LINDAS but publish the geo part in LD.geo.admin.ch and reuse those concepts together with LINDAS, also valid for station/*

[jstcki]

Shall we close this issue in favor of the concept described in the README? https://github.com/zazuko/rdf-cube-schema-viz#datakind-temporal--spatial

[l00mi]

We can keep it open for now. We will need to consolidate all the infos inhere in the meeting about the spatial topics.

[l00mi]

@davidhanimann this is the issue for

Geometrien: Modellierung mithilfe von meta:dataKind, schema:GeoShape, geo:hasGeometry (Verlinkung zu Swisstopo-Geometrien) an Visualisierungstool anbinden zur Darstellung der Resultate auf Choroplethenkarten.

[l00mi]

Closing now as documented and examples available in lindas.