Jura Mountains mapping

A hands-on mapping exercise that maps and analyses features of historic, archeological and wildlife interest in Switzerland's Jura Mountains serves as an open-access use case to demonstrate modern OpenStreetMap (OSM), Geographic Information System (GIS) and Building Intelligence Modelling (BIM) technologies for use at the local and project scales. The mapping covers the Jura Vaudois Nature Park and is centered on the village of Saint-Cergue at the south-western end of Switzerland's Jura Mountains.

The various mapping tools and applications are being incorporated in projects in Tanzania's Usumbara Mountains that deal with biodiversity, forest monitoring and water cachment nature-based solutions for risk mitigation.

For mapping, various websites offer:

• JuraMap historical map, circa 1898: (raster tiles)
• OpenStreetMap micromapping
• OpenStreetMap editing
• Divide and Map - Now (DAMN) tasking manager
• historical (1933) aerial photos
• Explorer panoramic trail views is being replaced by a Panoramax "trails" layer
• point-cloud site views
• pasture biomass mapping
• forest biomass mapping
• Land Use - Land Cover
• 3d vector terrain maps
• uMap cadastral maps

A range of applications is planned. Available currently are:

• OpenRouteService
• OSM tag identification
• Overpass API
• ohsome-API swagger
• ohsome dashboard
• OpenBuildingMap front-end
• Offline JuraMap files

Some specialised tools are implemented:

• Kosmtik
• OpenGTS-Traccar GPS tracking (only the OpenGTS login screen is made available) - see IMPLEMENTATION NOTES

The implementation of each of these technologies is described briefly. Details are available in some cases as Implementation Notes.

Main map site (map.peterboswell.net)

Static layers:

• a locally rendered OSM map tile layer
• a 50 cm Digital Elevation Model (DEM) relief layer (the swisstopo swissALTI3D product)
• a 10 cm resolution ariel image layer (the swisstopo swissIMAGE 10 product)
• a high-resolution topographic map layer (the swisstopo Swiss Map Raster 10 product)
• historic ariel images (swisstopo, 1933)
• satellite layers (Google, Bing, ArcGIS)
• point clouds (the swisstopo swissSURFACE3D product)

Interactive layers (Leaflet scripted):

• points of interest using a self-hosted Overpass API
• routing using the OpenRouteService
• access points to trail views

Interactive pop-ups (as a Leaflet-scripted modal)

• point-clouds via a self-hosted Potree app
• cadastral maps via a self-hosted uMap app
• map layers (OpenStreetMap, DEM)
• links (information; InstantStreetView and/or KartaView, if available)

Divide & Map - Now (DAMN) tasking manager - IMPLEMENTATION NOTE

The Jura Mountains mapping project's main map is for the village of Saint-Cergue in Switzerland. A Divide and Map - Now (DAMN) tasking manager is used to divide map areas into small squares that are locked while being micromapped. The DAMN manager uses a self-hosted OpenStreetMap website and database.

JuraMap feature mapping (JuraMap.org) - IMPLEMENTATION NOTE

The mapping of features based on an historical map of a region is being carried out to better understand the landscape of the Jura Mountains in the south-west corner of Switzerland above the village of Saint Cergue. This mapping exercise is consolidated under the JuraMap.org activity.

Vector and raster map files are made available for downloading so that the JuraMap can be used offline with a smartphone's built-in GPS (see IMPLEMENTATION NOTE).

The aim is to create as closely as possible a map of the region as it existed in 1898, the year the Siegfried Map was published, following the Dufour Map, the first map of modern-day Switzerland, that was published in 1845. Using this map as the basis, various features are added (geological, cutural, nature and wildlife based, etc) as the basis for vitual tours of the region.

Micromapping - IMPLEMENTATION NOTE

Top-down view symbols for trees and related features such as hedges have been incorporated into the map of the village of St-Cergue to improve micromapping.

OSM vector tiles - IMPLEMENTATION NOTE

A TileKiln Spirit style map tile generation and rendering stack is being set up to serve the historical JuraMap (and eventually the St-Cergue micromap) as vector map tiles.

JuraMap routing - IMPLEMENTATION NOTE

A self-hosted OpenRouteService has been set up so that routing can be provided for JuraMap that maps paths, tracks and roads as they probably existed at the end of the 19th Century before the modern road network was built in the Jura Mountains using heavy machinery. JuraMap and JuraMap routing make use of a historical mapping of roads and tracks.

Trail views sites - IMPLEMENTATION NOTE

A simplified version of the deprecated proof-of-concept TrekView Explorer is used for the panoramic viewing of trails. Panoramic views are taken using a Google Pixel 4a smartphone. This site is being replaced by the backend and web API of a Panoramax instance for storing and viewing field photos which is available a the "Trails" layer of the detailed raster JuraMap.

Point clouds

Three-dimensional point clouds of smallish areas are viewed using the Potree viewer to estimate forest density (see IMPLEMENTATION NOTES).

Pasture biomass site - IMPLEMENTATION NOTE

The month-by-month biomass that is plotted in popups is monitored using the Sentinel2 Leaf Index (Se2LI) biomass index calculated using the Copernicus Sentinel2 A and B 20 m resolution red-edge (Band 5) and near-infrared (Band 8A) bands pan-sharpened to a resolution of 10 m and captured in May to November.

The boundaries of grassy pastures are are drawn using leaflet.draw. The baseline is the most heavily biomassed month (uusally June) and grassy areas was taken to be those grassy areas with a SeLI value above a certain value. These grassy areas corresponded closely to those given by the Version 1.5  cropland and grassland map of Switzerland based on Sentinel-2 data published by Envidat.

Forest diversity and structure site - IMPLEMENTATION NOTE

Forest mapping has so far focusssed exclusively on using GEDI high-reolution laser satellite data. The approach has been to use red-green-blue composite points corresponding to GEDI laser shots to determine forest diversity and structure. The structure determination is more robust and informative. It uses a composite index made up from indeces for the forest cover, layering and understory. Unfortunately, the number of GEDI scans in our region of interest (i.e., where we can access ground-truth reasonably easily) is still very limited, so it is difficult to draw conclusions at this stage.

More recently, GEDI Level 4 data (released in August 2021 - see Earthdata) has been used to plot the Above Ground Biomass Density in parts of the Jura Mountains.

Interactivity for the forest mapping is scripted using OpenLayers instead of Leaflet because the rotation of map layers is needed in order to align the GEDI laser shot transects with plots showing various metrics such as the variation with height of the biomass density.

Land use - land cover site

The aim is to investigate whether or not localised, relatively small-scale land-use land-cover (LULC) maps have a sufficiently high resolution for use in estimating changes in class-derived physical conditions (heat, noise, humidity, wind, light, etc.) that would accompany changes to the LULC arising from the introduction of green infrastruture or high-rise buildings, for example.

Aerial earth observation can yield high-resolution LULC maps that distinguish man-made and natural features in urban environments. The question is whether the same results can be achieved using OSM data with satellite observations. A start has been made with LULC mapping using OSM data. The GLASS osm2lulc package was used to create a LULC shapefile that was split into layers using QGIS GDAL modules. Layers exported from QGIS as geojson files were then combined and converted to .mvt files using lab-geojson2mvt.  The .mvt files are then simply loaded into an apache2 website. 

Developments in the area are monitored in the hope that high-resolution LULC mapping will become more accessible using open-source technologies and resources.

Area-of-Interest site

Schemes that use OSM to identify certain types of urban and peri-urban areas are of interest for reasons that we cannot discuss. Area-of Interest mapping is closely related. A start has been made by implementing aoi-osm. This is not currently working.

OpenBuildingMap - IMPLEMENTATION NOTE

The OpenBuildingMap (OBM) - a window to OpenStreetMap, providing a filtered subset of OSM data with just the building data - is hopefully destined to become as important as the OpenStreetMap. Understanding the technology that lies behind OBM is therefore important. A clone of the original OBM Javascript front-end was implemented, the only change being to include a land-use overlay (the standard overlays are the building occupancy, building levels, ground area, floor space and position that are served by the OBM). Map tiles for the land-use overlay were rendered in the same was as for the OSM site (i.e., using the OSM rendering database with Mapnik and renderd).

Recently, OBM changed to supplying vector tiles and the front-end has been redesigned.

The OBM's update and enrichment process receives updates from the public OSM database, imports these updates in the OBM PostGIS database, and adds information for the updated and imported buildings according to a set of predefined rules.

An open-source Docker Compose setup is in principle available to implement an OBM database and importer and updater service as well as a raster or vector tile render for the OBM database. Installing the OBM's Tirex tile server on Ubuntu 18.04 instead of the Switch2OSM renderd (a background process that renders map tiles when they are requested) has not been successful, but is probably solvable. The question is whether having a self-hosted OBM server available, updated using OSM or local data, would be useful for use at a project or similar level.

There are of course other opportunities for a different window on OSM data - an infrastructure window for example. Manwhile the new, redesigned OBM frontend has been implemented.

OSM site

The OSM website is the Rails port of the OSM website. The JOSM map editor is to used to edit the self-hosted OSM database. Changes to the OSM website database are synchronised with the rendering, Overpass and oshdb databases, see Rion1 and Rion2.

Details of Ubuntu 20.04 Switch2OSM and Ubuntu 22.04 Switch2OSM rendering sites have been released, based on Postgresql 12 and 14 databases respectively and the Postgis 3 extension.

Open Historical Map site

Certain use cases we are developing call for a map site that shows the evolution with time of features. One option is to use a Open Historical Map (OHM) site for open-source, user-editable historical maps. OHM is based on the OSM Rails port and is fairly straightforward to install.

The OHM includes the Mapbox GL timeslider and its Leaflet control for a user's vector tile layer (see example). The vector tiles can be viewed using the OHM Tegola vector tile server (see the same area as the example). OHM is supported by a Tasking Manager to divide a large mapping project into smaller tasks and is based on the HOT Tasking Manager. Other OHM tools include a weekly OHM planet file, Overpass instance, a Nominatim instance, a map warper, and rich tagging on the OHM website for linking information using an enhanced OSM inspector called ohm-inspector.

As an alternative to the HOT Tasking Manager, the Divide and Map - Now (DAMN) tasking manager has been implemented. We are also investigating the use of date information embedded in OpenStreetMap tags to monitor the development of trees (and potentially the history of other map features). See the tree layers at high zoom levels of the St- Cergue map.

Vector maps - IMPLEMENTATION NOTE

We are exploring the need for a raster and vector tile server for high-resolution elevation mapping (together with terrain-RGB raster and vector terrain tilesets). TileServer GL with MapLibre GL has been set up and used for a terrain-RGB map. Our discussion includes exploring the MapLibre GL terrain3d branch for terrain rendering, as discussed at FOSS4G 2021 (see a terrain3d test map). The upshot of this discussion is that we now use Shortbread-styled TileKiln tiles for three-dimensional vector mapping (see juramap.org).

OSM back-end rendering tile server

OSM map tiles are rendered using a Ubuntu 18.04 Switch2OSM tile server.

oshdb / ohsome-API

The need for the historical visualisation of map features of the type described above for the OpenHistoricalMap has prompted us to install a local oshdb database instance so that we can create oshdb databases for the ohsome-api. The oshdb instance is created as an H2 database using the oshdb-etl (extract - transform - load) tool chain. ohsome-api, a generic web API to extract data from an oshdb database is the starting point for more extensive analysis of OSM data.

The main issue in using a local oshdb instance is the manipulation of history files created from the self-hosted OSM database that are required for the oshdb-etl.

While the ohsome API is well documented, open-source code is not available for a reasonably general-purpose front-end. Open-source code is available for oshsome2label and is effectively available in a compressed form for the ohsomeHeX and the ohsome dashboard front-ends. ohsome2X is available for generating OSM metrics.

A feature for the ohsomeHex front-end has recently implemented (see also ohsomeHeX feature history) that uses a time slider to display the evolution with time of map features. It does this by superimposing a data layer generated using the ohsome API that gives the outlines of features such as buildings. This ohsomeHeX feature is built around the ohsome-py Python client for the ohsome-api and a specialised ohsomehex-api. It should be possible to set up a self-hosted backend for the ohsomeHeX time slider.

Historical snapshots of OSM data can be displayed using the ohsome-qgis-plugin for QGIS provided the plugin generates suitable geometries (in which case the QGIS native Temporal Controller is activated).

For visualisation as part of data analaysis as opposed to the spatio-temporal visualisation of map features, the ohsome-quality-analyst illustrates the type of web-interface visualisation that is possible. GeoDB and oshdb/ohsome-api are used as data providers. A self-hosted version of the ohsome dashboard has been implemented to explore use cases at the local and project scales.

Overpass API

The most common way to extract data from an OSM database is to use the Overpass-API which is easily installed as a local instance. Overpass API is designed to enable detailed and complicated searches of the OSM database (there are several front-ends, notably Overpass Turbo).

Manipulation of the .xml file returned by a query to an Overpass API starts with conversion of the .xml file to a Javascript geojson object using osmtogeojson. In a typical use case, osmtogeojson uses tags that denote attributes to create geojson features that can be extracted and displayed on maps using Leaflet and OpenLayers.

Rich tagging of the type used by the OHM website entered into a local OSM database via a local OSM website instance using the JSOM editor can be extracted using a local Overpass-API instance for use with the ohm-inspector. For a website that uses rendered map tile, the rich tagging is probably best displayed using a modal and not a sidebar as in the OSM website (see Leaflet.Modal).

A local Overpass-API instance is useful if one needs to extract large amounts of OSM data (there are data limits for the public full-planet instances). For some use cases at the local and project levels, being able to display overlays comprising features that have special tags is necessary.

An alternative to Overpass in some cases may be Underpass, which uses a proper database instead of disk-based tempfiles and can be accessed directly by geospatial tools such as GDAL. Exploration of possible use cases at the local and project levels is planned.

Kosmtik style editor

We need edited OSM Carto style sheets. The preferred route however for adjusting Mapnik styles is to use the open-source Kosmtik style editor. For the Carto style, Kosmtik uses the Carto .lua and .style files and .mms styles for each of the various OSM Carto tag categories.

OpenGTS -Traccar GPS tracking

The OpenGTS open-source GPS tracking front-end and back-end service is available, mainly to provide tracking while checking ground-truth in forests. An old Nexus 5 mobile phone with Android 6 and the mGts client app is used as the GPS device. mGts does not work with more recent Android versions. Traccar can be integrated with OpenGTS to allow the Traccar client to be used. For this it is best to start by a) using the standard integration configuration for the traccar.xml file; and b) to switch the Traccar app service on and off to trigger sending a data packet that is logged as a HEX message by the Traccar log before it creates a record in the OpenGTS database. The app's ServerURL setting should include port 5055 (i.e., http://host:5055).

Our hands-on use case illustrates the types of technologies that are useful at the local and project scales. These technologies are being applied to forest and biodiversity preservation in Tanzania. An infrastructure-related use case is also being developed with partners, but at this stage little can be said about this.