Micromapping trees

Trees are an important feature of the Jura Mountains in general and of the village of Saint-Cergue in particular.

The map for Saint-Cergue now uses top-down view symbols for trees based on an alternative OpenStreetMap (OSM) Carto map style. Called osm-carto-alternative colors, the map style is a fork of the standard CartoCSS gravitystorm/openstreetmap-carto map style used by the OpenStreetMap for its Standard map layer.

The thinking behind the design concept and its implementaion has been described by Christoph Hormann, the developer, in a series of blog posts in four parts (1, 2, 3, 4).

While the osm-carto-alternative-colors style implements several very valuable alternatives to the standard OSM Carto style, we summarise here the rendering of trees, tree rows, shrubs and hedges (corresponding to the OSM tags: natural=tree, natural=tree_row, natural=shrub and natural=hedge) that are differentiated by size (crown_diameter) , leaf_type and leaf_cycle tags.

As the starting point we have an Ubuntu Linux 18.04 LTS server with a standard switch2osm set-up for serving OSM tiles as well as an OpenStreetMap "Rails Port" website for editing a self-hosted OSM databse. For the map-tile server, the aim is to replace the section in the gravitystorm amentity-points.mss style that deals with trees with the relevant part of the osm-carto-alternative-colors style. The approach is simply to create an osm-carto-alternative-colors renderer for trees and to remove the the section of the gravitystorm mapnik.xml that is used to render all features except trees, tree rows, shrubs and hedges .

This approach entails cloning the osm-carto-alternative-colors repository to a "/home/usr/src/osm-carto-alternative-colors" directory and:

  • adding a table called "carto_symbols" to the postgres/postgis database called "gis" that is used to render OSM tiles;
  • using the osm-carto-alternative-colors' "assemble-project.py" script and a "layers.yml" file to generate a "project-trees.mml" file;
  • using osm-carto-alternative-colors' carto in the normal way (carto project-trees.mml > mapnik-trees.mml) to generate a "mapnik-trees.xml" file
  • adding a section in the renderd configuration file ("renderd.conf") for trees that refers to the "mapnik-trees.xml" in the osm-carto-alternative-colors directory.

The "layers.yml" need only be a cut-down version of the "layers.yml" file given in the osm-carto-alternative-colors repository:

layers:

.. header:

.... source: layers/header.mml

.... stylesheets:

...... - style/style.mss

...... - style/fonts.mss

.. trees:

.... source:layers/trees.mml

.... stylesheets:

...... - style/amenity-points.mss

.... tags:

...... - ac

It appeared to be important to use a limited number of versions of the relevant software. In our case, in a virtual environment (in a comand terminal: "python3 - m venv ."):

  • python --version (3.6.9)
  • carto --version (1.2.0)
  • mapnik-config --version (3.0.24)
  • sudo -u postgres -i ¦ psql ¦ \c gis ¦ SELECT version(); gives PostgresSQL = 10.22
  • sudo -u postgres -i ¦ psql ¦ \c gis ¦ SELECT PostGIS full version(); gives POSTGIS = 2.4.3 and GDAL 2.4.2

The osm-carto-alternative-colors contributing.md indicates that yaml is needed. Installing PyYAML was adequate (a terminal command "pip install pyyaml" from memory).

Setting up the "carto_symbols" table in the "gis" database was the most troublesome aspect. The sql scripts given in the osm-carto-alternative-colors "sql" directory each needed to be executed using a termnal command of the form:

  • psql -d gis /home/user/src/osm-carto-alternative-colors/sql/z.sql

It is unclear if all six sql statements are needed for trees. To be safe, all were executed. The "symbols.sql" gave errors. First, executing "symbols.sql" did not create the "carto_symbols" table ("relation carto_symbols does nor exist"). lxml needed to be installed ("sudo pip3 -m install lxml").

Executing the "generate_symbols.py" script in the osm-carto-alternative-colors "scripts" directory gave the error "No such file or directory: 'inkscape'" and "inkscape error when converting symbol". From memory the terminal command "sudo apt install inkscape" may have installed inkscape successfully. Whatever was done, the command "inkscape --version" gave "Inkscape 0.92.3" once inkscape was installed.

However, the most important error on exceuting "generate_symbols.py" was :

  • postgresql "st_scale" geometry srid (0) does not match column srid

Two sets of psql commands were required, the first for the "carto_symbols" table and the second for the table's "way" column:

ALTER TABLE carto_symbols ADD CONSTRAINT enforce_srid_way CHECK (ST_Srid(way) = 3857);

ALTER TABLE carto_symbols ALTER COLUMN way type geometry(MultiPolygon,3857) using ST_Multi(way);

UPDATE way SET geom.STSrid=3857;

UPDATE way SET geom=ST_SetSRID(geom,3857) WHERE to_update;

ALTER COLUMN way TYPE geometry(MULTIPOLYGON,3857) USING ST_SetSRID(way,3857)

The kosmtik mapping framework can be used to test the osm-carto-alternative-colors project-trees.mml by runnning:

  • kosmtik serve /home/user/src/osm-carto-alternative-colors/project-trees.mml

Here, kosmtik is intalled in /home/user/src/kosmtik ("npm install -g kosmtik*) with node set to version 9.3.0 ("node --version" gives v9.3.0) by having nvm installed and running "nvm use 9.3.0".

Finally, when the OpenStreetMap rendering database call "gis" is updated using "osm.xm" generated from the OpenStreetmap database:

  • osmosis --read-apidb host="localhost" database="openstreetmap" user="user" password="user" validateSchemaVersion="no" --write-xml file="/home/user/osm.xml"

we in fact use the the gravitystorm style:

  • osm2pgsql -W -d gis -H localhost --slim --hstore --multi-geometry --style /home/user/src/openstreetmap-carto-gravity/openstreetmap-carto.style --tag-transform-script /home/user/src/openstreetmap-carto-gravity/openstreetmap-carto.lua --input-reader xml /home/user/osm.xml --expire-tiles 17 --expire-output /home/user/osm-site/expired-tiles.list

where the OpenStreetMap "Rails Port" website is installed in the "osm-site" directory.

Top-down veiew symbols are obviously attractive for micromapping features such as trees in urban settings. Other features dealt with in the OSM Carto amenity-points.mss style file do not seem to warrent a similar treatment. Elsewhere, water-related features such as basins (landuse:basin) and wetlands (natural:wetland) may benefit from size- and property-dependant top-down view symbols.

Updated 29 June 2023

PeterBoswell.com