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.
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.
On Saturday next week (Nov 30 2019) I’ll upgrade this servers operating system. So the print map services will not be available for parts of that day, and maybe also for parts of Sunday Dec 1st
Continue reading “Maintenance Notice Nov 30 / Dec 1”
Local installations can now be bound to the actually imported data area.
Continue reading “Data area bounds”
As the topic says: the OSM Carto standard style has been upgraded to the latest v4.23.0 release.
You can find the original release announcement here:
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
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.
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
I added a new experimental “OSM Notes” overlay yesterday.
The Overlay will retrieve all active OSM notes for the displayed area, and will add numbered markers and index entries for each note.
This way it is possible to check a neighborhood for open notes without having to stare on a screen to get from one to the next, or at least that’s my personal intended purpose.
Continue reading “OSM Notes Overlay (experimental)”