For some unknown reasons Mapnik has a problem with the color name DarkSlateGray, if this name occurs in a GeoJson color or fillColor attribute rendering will just fail with an exception.

Searching over the error logs I found that it is always just this one color name that makes rendering fail, but as I’m not sure about this being the only color name with a problem, I’ve now changed the Umap Json preprocessing code to do color name lookups on the python side already and replace them with their respective hex color code, so that Mapnik will never have to resolve color names by itself when processing GeoJson data files.

Umap improvements

Depending on how an UMAP map was created some default attribute settings like colors and shapes were ignored, and the default global fallbacks were used, leading to all-blue results.

This should be solved now, my umap format parser should now be able to handle all variants of the umap json export format, so that correct colors, line widths and icon shapes should be shown in the rendered maps.

Vagrant setup: refactoring

If you are using the Maposmatic Vagrant test setup, you may notice that its directory layout has changed a bit over the last days.

Aside from the elevation model related changes mentioned in the previous post, most change really just reorganized paths and changed directory and file names.

Some of the more notable changes beside the renames:

  • Style and overlay install scripts now no loner write out ocitysmap.cnf snippets, instead for each style setup .sh file there is now also an .ini file containing the ocitysmap.cnf style declaration block only. The ocitysmap-conf.sh script then creates a new ocitysmap.cnf file when run, by collecting all the .ini files from the styles and overlays sub directories, creating the available_styles: and available_overlays: lists from this, and concatenating all the .ini snippets to the end of the config file. As the config file is now re-created from scratch each time now this should be more robust than the previous approach.
  • The README.md file is more detailed now, including information on e.g. file system layout, adding new styles, or provisioning real servers …
  • The number of “red” lines shown during provisioning has been reduced as much as possible, and the remaining ones that can’t be avoided are listed in the README. Anything mentioned there can be considered OK, any other red lines should be considered a failure that someone should look into

Vagrant setup: hill shading and contour line setup

Originally the provisioning of the Vagrant test setup just installed hill shading and contour lines for a fixed area (parts of Germany).

From now on during provisioning the actual area covered by the imported OSM data file gets determined, then all the SRTM 90m zone files overlapping with the data bounding box are downloaded and processed to produce hill shading, relief, and contour lines data for the data area.

Depending on the size of your import datas bounding box this may slow down provisioning a bit, but on the pro side you get your actual data area covered instead of just a part of Germany you may not even be interested in.

Some recent bug fixes

Web frontend

  • Empty paper format choice for multi page layout
  • When going back the paper format tab did no longer show the [Next] button
  • When going all the way back and choosing a different map section or layout, the choice of possible paper formats would not be updated accordingly
  • When uploading a GPX or UMAP file with a non-ascii character, like e.g. “ö”, in its name the frontend ran into a conversion error causing a 503 error page

Rendering backend

  • The OSM Notes overlay fails to add its own index category if no indexeable items were found on the base map layer. Instead of failing hard the overlay is just disabled in such cases for now
  • Also in general a failure inside an overlay plugin will only terminate the processing of that overlay, and not of the complete map request
  • When requesting re-render of an old request that included uploaded GPX or UMAP files no longer available in the servers upload directory, the request will now still succeed, but will be missing the GPX or UMAP overlay data, instead of failing completely

Open rendering bugs

  • With large map areas, or when using the “Pencil” style, the render process will sometimes run out of memory. To prevent this from happening I would have to reduce the maximum map area substantially. Instead I consider adding a “soft” size limit that will show a warning in the web frontend when being exceeded. E.g. on more than 10x10km² a warning would be shown, and anything above 20x20km² would still be refused up front …
  • Sometimes the Mapnik renderer runs into a segmentation fault and crashes. There’s not much about that I’d be able to do about that. It seems to be related to large map sizes, too, but I need to track this down further yet …

Maxspeed overlay update

The MaxSpeed overlay now also shows streets with a speed limit of less than 30km/h, including “highway=living_street”, which usually don’t have an explicit “maxspeed” value set.

Such roads are now rendered in a lighter shade of green, and thinner lines.

Also road segments with no speed limit information at all are now marked with thin, gray lines.

PS: as the original ITO speed limit map has been discontinued, which I originally based the color scheme on, I may refactor the color scheme / color-to-speed mapping at some point