Mateusz Konieczny's Diary

Recent diary entries

StreetComplete is an application allowing to contribute to OSM by answering simple question. It makes possible to contribute without learning about tagging schemes and without learning how to handle interface of more general editor like JOSM, iD or Vespucci.

I contributed to StreetComplete in past. Recently I received a grant that will allow me to spend more time on improving it.

Grant is funded by a NLnet as part of NGI Zero grants. StretComplete grant is mentioned by NLnet at and pages. It will allow me to spend far more time on improving StreetComplete.

I will participate in project as usual, sending pull requests that will be reviewed and accepted (or rejected) by StreetComplete author, Tobias Zwick and minor changes commited directly (and still subject as review).

Note that I selected topics of work to be done (based mostly on open issues on the bug tracker) on my own, and it was accepted without any requested changes. I am sole beneficiary of the grant.

Total grant will depend on how much I will manage to do before deadline.

See for earlier, very similar entry.

I created and submitted it OSM weekly as it seems to me that other OSM projects also may be funded.

I made that can be used to generate vector maps in SVG format.

Generated maps can be downloaded. This allows much easier reuse of OSM data in some cases. For example where someone needs OSM geometries of relatively small area, but existing tools are too complex for them[0]

It will likely work well for tiny and small areas, it will definitely fail for very large areas.

It is very experimental, feedback is welcomed! has list of known issues and is best place to report existing issues, but feel free to simply leave comments also here.

I am also working on making easier to make own map styles. It is already relatively easy, but documentation is missing.

[0] For many people Overpass Turbo, databases, filtering OSM data will be far too complex.

PS It was created as part of one of parts of

I was working on making generator of SVG file accepted by laser cutters, and noticed that what I am creating can be a bit more generic and accessible than initially planned tool.

Current tool is an experimental proof-of-concept with some of features that I need.

I know that tools consuming OSM data and producing SVG images exist already, but according to my research none were at once

  • working in browser
  • not requiring install of any extra software
  • allowing easy export of a generated image
  • relatively easy to implement own map styles

or easily modifiable to fit all this requirements at once

I somehow suspect that such tool may be existing already - in such case please let me know!

PPS Thanks for Overpass API! Without Overpass it would be unable to work and would require me to install, setup and maintain database replicating OSM data what is beyond my abilities.

NGI Zero grant for StreetComplete development

Posted by Mateusz Konieczny on 18 June 2019 in English (English). Last updated on 7 August 2021.

StreetComplete is an application allowing to contribute to OSM by answering simple question. It makes possible to contribute without learning about tagging schemes and without learning how to handle interface of more general editor like JOSM, iD or Vespucci.

I contributed to StreetComplete in past. Recently I received a grant that will allow me to spend more time on improving it.

Grant is funded by a NLnet as part of NGI Zero grants. StretComplete grant is mentioned by NLnet at and pages. It will allow me to spend far more time on improving StreetComplete.

I will participate in project as usual, sending pull requests that will be reviewed and accepted (or rejected) by StreetComplete author, Tobias Zwick.

Note that I selected topics of work to be done (based mostly on open issues on the bug tracker) and that Tobias who will review pull requests remains completely independent - I am sole beneficiary of the grant.

Total grant was 5000 euro.

I have written a short text about what people are doing in OSM. I am curious whatever others would use the same taxonomy.

OpenStreetMap is a large decentralised project. There are thousands of people who participate for various reasons.

Mappers, people mapping the world are the most important group. They collect various information and enter it into the OpenStreetMap database - for example location of playgrounds, shapes of forests, routes of hiking trails, street names and many more.

But to make it possible it is necessary to maintain various software and hardware. It includes creating and improving editor programs used by mappers, maintaining OpenStreetMap servers and website.

Collected data is used by many people for various purposes in their projects - displaying maps on websites, using it as one of the sources in flood preparation plans, making private offline maps for various devices - GPS units, smartphones etc. There are also many, many other uses - for example, I am making a 3D map for the blind using OSM data.

And there is the largest group - people that benefit directly or indirectly from projects powered by OpenStreetMap data - they may be using maps more accurate and cheaper than alternatives, they may be rescued by firefighters using OpenStreetMap data to get to the site of an accident or watch a movie with a cool map in a background made using OSM data.

But reality is always more complicated than expected, and decision how to describe some features is not straighforward. There are people inventing, discussing and documenting ways how the world can be described and mapped.

There are also many projects that are helping mappers, developers and data consumers. One of the most prominent ones is taginfo that provides very useful statistics about tags used in OpenStreetMap. There are also QA tools detecting common problems in data like Osmose and tools making access to OSM data easier (Overpass Turbo is a great example).

Groups mentioned so far may be split into subgroups in various ways. Mappers may be split by what, how, why and where they map.

People creating software may be additionally split by their role - they may be programmers, translators, reporters of bugs, graphic designers.

There are also many other roles not mentioned in this brief overview - people who fund hardware for OpenStreetMap servers or development of various helpful software, people promoting OpenStreetMap, vandals attempting to damage data, people countering vandals and reverting their damage.

Mentioned groups are fluid. One person may be a mapper of local hiking routes, participate in discussion how colour assigned to hiking routes should be mapped, encourage friends to use detailed maps made using OpenStreetMap data and from time to time donate to fund for maintaining hardware running core OSM services and other necessary expenses.

(please, comment if there are some typos, anything unclear or something important missing)

It was originally published at my website.

During making documentation of OSM tools and software it is frequently useful to add screenshots. Especially tutorials are often featuring multiple ones. I always disliked that such images are frequently getting outdated. It may caused by interface changes, map style changes and edits to OSM data.

Sometimes it requires more significant update of documentation, sometimes updating images is enough. But it may be very time-consuming.

When I was making my Overpass Turbo Tutorial for newbies* I wanted to find a way to make such images easy to recreate.

I found an interesting solution. Selenium is a software usually used for testing websites. It has plenty of features but interesting here is is that one may write a simple script that will

  • open a website
  • wait for it to load
  • take a screeenshot

This way it may be possible to generate and recreate screenshots without manually taking them.

There is plenty of way how Selenium may be used, I am using Python bindings connected to Firefox using geckodriver.

Time-saving code is relatively simple.


from selenium import webdriver
import time
from import By
from import WebDriverWait
from import expected_conditions as EC

Lets say that I wanted an example of a simple website. This code will take a picture of googling results and save it to a specified file.


Following code sample will modify vieport size and interact with page to hide irritating banners, then take a picture of site (note that such use is also subject of Tile Usage Policy like other automated tile downloading, but for regular tutorial updates use will be not higher than human doing the same):

driver.set_window_size(1024, 768)
#hide banners about SOtM and other spam
for popup in driver.find_elements_by_class_name("close-wrap"):

Isle of Man map

overpass turbo screenshots are a bit trickier when we want to display query results

def smart_overpass_capture(url, image_file, driver):
    element = WebDriverWait(driver, 10).until_not(
        EC.presence_of_element_located((By.CLASS_NAME, "loading"))

smart_overpass_capture('', "Nepal-glaciers.png", driver)

Nepal glaciers map

Overall it turned out to be much easier than expected, and now to update all images I need to run just a python script rather than fiddle with pixel alignment and crop images to an exact size.

One nice part is to add proper image comparison to git - I used method described at It is not ideal, but it is good enough for me.

I still have to figure out how to automate generation of animated images showing usage of interface. This would allow to easily tweak and improve such animations without manually recreating everything.

*if you have time or are interested in how on may extract data from Overpass Turbo - feel free to write to me how it may be improved (by OSM message or by comments of this entry).

Fortunately I am typically editing area that is not a victim of landuse imports.

Unfortunately today I am trying to fix area affected by at least two landuse imports

As bonus, one is using mysterious undocumented CLC:code, CLC:shapeId tags that are not documented anywhere and it is not clear what one should do with them on modifying and merging areas with them.

Is there anywhere at least one large-scale import of landuse data that was done properly?

Using Wikidata data, fixing wrong wikipedia and wikidata tags

Posted by Mateusz Konieczny on 26 September 2017 in English (English). Last updated on 27 September 2017.

I invite everybody interested in

  • using data wikidata to add more data to OSM
  • fixing wikipedia tags
  • fixing wikidata tags

I would be happy to generate reports for your local area. It is possible to generate report about specific region (and I know that many people are interested primarily in fixing area they know well). Example report is at,%20Deutschland.html (full list of locations with currently available reports is at )

Feedback is welcomed, especially from people who looked at the site and decided to not use it - what went wrong? Also feedback from people using reports would be useful.

I already added and improved how reports work based on requests. For example, I added overpass querries usable in JOSM that skip already fixed objects.

This tool is likely to be useful - it was already used to improve thousands of objects in Poland - special thanks go to wmyrda, rmikke who fixed massive amount of objects (thanks also to everybody else who used this reports).

This is the first part of comparing openstreetmap-carto and other map styles. Note that comparison is focused on finding things that may be improved in openstreetmap-carto.

Relief data

All maps in my basic sample turned out to show relief data. It ranges from subtle, almost unnoticeable to extremely heavy and dominating over all other features. Is is open question whatever adding rendering of elevation data to openstreetmap-carto would be desirable. But it is clear that rendering elevation data is common, and in some cases effect is great.


But even assuming that it would improve map there are some complications:

  • more non OSM data - what would run contrary to attempts reducing usage of external sources. It may be even considered as misleading given that OSM has no terrain data.
  • Default map already renders many things. Adding something completely new to render would need really good justification and would be very complicated to do well
  • To render elevation data source of worldwide elevation data on suitable license is necessary. Some data is available but either it requires major work to fix voids/peaks/pits (see for some examples of complication). There are some sources with this problems partially fixed - and seem to be the most popular, but both have a problematic copyright status. First has “Users are prohibited from any commercial, non-free resale, or redistribution without explicit written permission from CIAT”, second claims that “Elevations and contour lines are facts that should be ineligible for copyright”. While I agree that this should be ineligible for copyright I am not sure whatever these data is eligible for copyright (or fall under equivalent laws). AFAIK it is likely to be covered under database rights (collection of data may be protected even if individual entries are not copyrighted and there is no creative work involved).

See comparison of maps in a basic sample.


The previous comparison is revealing also another weakness in openstreetmap-carto - it is not capable of diplaying landmarks earlier. Google maps is fairly good at this - though with results badly affected by fact that “business paid for advertising” is one of criteria for landmark. Sputnik is trying, sometimes with fairly good results, sometimes with rather poor. But this problem is mostly affecting higher zoom levels.

On lower zoom levels mostly two types of landmarks are visible - “the highest mountain in region” visible above gives quite good results.


Sputnik seems to be also quite good at deciding which airports should be rendered. There are some mistakes, but overall their algorithm works fine. See Atlanta or Bogota with cluster of airpots to the west and cluster of airports in the eastern direction.

It is interesting whatever solely OSM data is used here.

See “Too many tiny private airports on the map at small scales”.

There is one common tagging problem - missing service tags on minor railways. It leads to a poor rendering on lower zoom levels, as renderers are rendering minor service tracks like important railways.

It is quite easy to spot places that require fixing by browsing map on lower zoom levels - see for example

This place at times of writing has noticeable bundle of rails near McAlester, indicating place where somebody mapped minor railway tracks without marking them as minor (note for this case is at


See for documentation how service tags should be used for railways. Note that remote mapping generally is not feasible as result of subtle differences between yard and siding.


Image by Basil D Soufi, CC-BY-SA license.

It is typical for maps covering large areas to display city labels. It is quite common to mark exact locations by displaying dots, circles or other symbols.

It also seems that labels for cities and towns may be displayed larger to improve the map.

I tested both ideas, without changing algorithm that selects cities and towns to be displayed. Example of before/after tested on UK are available below.

z11 github github

z10 github github

z9 github github

z8 github github

z7 github github

z6 github github

z5 github github

I ma not entirely sure about dots and I will certainly experiment with tweaking them, but I am happy with new sizes for city labels.

Additional before/after are available at

Location: Kosocice, Swoszowice, Krakow, Lesser Poland Voivodeship, Poland

During GSoC 2015 I focused on improving road presentation in the Default OSM map style. This year I am again participating, but with more diverse goals. I am planning to improve performance, reduce rendering order problems and tune mid-zoom level rendering.

mid-zoom level rendering

I started with work on improvements to mid zoomlevels (z6 to z9). During search for the best and most promising ways to improve rendering, starting from trawling through reported issues. I also prepared and submitted some additional tweaks like rendering names for barriers, fixing viewpoints and forests and shops and other.

I am also like during GSoC 2015 preparing a comparison between the current map style and alternatives.

A bit of history

There are some visualisations showing how data was added to OSM. But I have neither seen nor found something similar for a map style. So, for start of next big series to the map I made a display of what was changed in the past.

Visualisation are available for z18 z18

z14 z14

z8 z8.

I selected Weybridge as location as map of this place was the first OpenStreetMap-based map to go on Wikipedia.


As usually testing and review is welcomed for open pull requests, especially one considering rendering names for barriers and an associated popular tagging mistake.

I am considering to look more for inspiration/comparison in printed maps. I looked for online sources and for now I found surprisingly small number of contemporary maps that would display sort-of-similar set of symbols as Default OSM style, with scale within z5 - z10 range.

From promising findings I caught David Rumsey Map Collection and Wikimedia Commons (enabling CCI allowed to find something).

But I found nothing highly useful. For now

are the best. Is anybody aware about maps or database of maps allowing to find maps similar in content to Default OSM Style, with scale within z5 - z10 range?


Thanks to Paul Norman for simplified osm2pgsql database dump. Without that resource obtaining database for lower zoom levels would be far more complicated.

Location: Kosocice, Swoszowice, Krakow, Lesser Poland Voivodeship, Poland

Proposed mechanical edit: surface=woodchip to surface=woodchips

Posted by Mateusz Konieczny on 1 September 2015 in English (English). Last updated on 14 June 2016.

this entry is copy of

I plan to change surface=woodchip to surface=woodchips.

surface=woodchip is a clear duplicate of surface=woodchips. It is also less popular and undocumented on Key:surface. It would be a good idea to retag it to already documented tag before this tags are used more.

amount of surface=woodchip in OSM as of 2015-09-1 is 135.

amount of surface=woodchips in OSM as of 2015-09-1 is 228.

I’d download all surface=woodchip using Overpass API and change the tagging by search and replace using Level0 editor. The upload of the changed data I’d do in chunks to check the data once more before upload and not to create a worldwide changeset.

This would be a one time edit.

Edits will be made from account “Mateusz Konieczny: bot account”


state before mechanical edit:


state after mechanical edit:


Changeset comment would be “ changing surface=woodchip to surface=woodchips as surface=woodchip is less popular duplicate. This mechanical edit is documented at


Posted by Mateusz Konieczny on 31 August 2015 in English (English). Last updated on 15 September 2015.

It is not OK to use one tag (for example amenity=hotel) and add second tag that negates or massively change its meaning (for example adding involuntary=yes to amenity=hotel instead of using amenity=prison). Additional tags should clarify meaning of main tags rather than negate it.

In general, any tag tag must be processed to avoid producing false or invalid data is a trolltag.

For example somebody wants to produce map of cycleways. Simply processing highway=cycleway and highway=path with bicycle=designated should be enough. Data consumer in that situation should not be expected to check for “proposed=yes”, “demolished=yes”, “construction=yes”, “completely_fictional=yes” or “end_date=1990”.

Obviously, one may want to look for more detail - for example to show proper map of cycleways one would want to check also access, surface, oneway and other tags. But again - segment of cycleway destroyed in landslide should be removed from map rather than tagged as [highway=cycleway, surface=giant_gaping_hole, smoothness=impassable].

Adding tags like proposed=yes is a really poor idea. In case of data consumers not supporting them it will lead to invalid and highly misleading data. And data consumers supporting completely broken tagging schemes (like [highway=tertiary; construction=yes] instead of supporting just [highway=construction, construction=tertiary]) encourages usage of this tagging method. The danger is that with more and more data tagged using trolltags other data consumers will either be forced to add support for trolltags or stop using OSM data.

And possibilities for trolltag are endless. Lets say that somebody wants to display existing shops and support all tagging schemes. Good luck with filtering out proposed=yes, abandoned=yes, vacant=yes, demolished=yes, construction=yes, empty=yes, ruins=yes, parsing start_date and end_date etc etc.

Some real examples: - there was a building. Then it was demolished. But somebody, instead of deleting it from OSM (or maybe temporarily converting it into note=”there was building here now it is demolished”) decided to add demolished=yes. - railway=route tagged on highways and footways. To detect that this is not a railway route but original research about line that was closed over 80 years ago one would need to process “note=abandoned railway” or “railway:end_date=1931”

In many cases (like this two cases above) correct mapping is no mapping whatsoever. What existed in past and is not existing now should not be mapped in OSM (see - “What it doesn’t include is opinionated data like ratings, historical or hypothetical features, and data from copyrighted sources.”).

In other cases objects should not be deleted but retagged. For example in really rare cases mapping proposed roads makes sense. Maybe some proposal for constructing footways are also verifiable. But in that case use [highway=proposed, proposed=footway] rather than [highway=footway; proposed=yes]. At least normal data users will not be mislead into displaying proposals as reality. (and yes, somebody did it - see ).

It is OK to map objects under construction. But [highway=footway; construction=yes] is the best method to irritate data consumers (real - see Use [highway=construction; construction=footway] instead.

And good luck with interpreting [construction=yes; railway=tram_stop; start_date=2012]. Is it construction that was supposed to end in 2012? Is it construction that was supposed to start in 2012? And almost everybody will process it as an existing tram stop. It would be better to avoid mapping until it was really constructed (or use something like [construction=tram_stop, end_date=2012])

Note that some tags may be OK or trolltag depending on how it is used. For example abandoned=yes. It is perfectly OK to add it to building - after all, abandoned building is still building. But using it on shop=supermarket to indicate that shop is no longer operating and it is impossible to buy anything there (in other words - it is no longer a shop) is not OK and should be tagged in proper way (typically - by deleting shop=supermarket).

Disclaimer - trolltags are frequently not processed and ignored. As result it is typical that [highway=motorway, construction=yes] is no longer under construction and may be used. This type of issues as usually requires survey on the ground to be properly fixed.

And you may use this overpass query to detect more in your region - (it includes tags that nearly always are trolltags - but certainly some false positives will appear. For example vacant=yes is fine for building).

Most obrotowy w Giżycku

OpenStreetMap Carto 2.34.0 has been released and rolled out to the servers. It might take up to 48 hours before all tiles show the new rendering.

Changes include

  • better rendering for highway=path/footway/cycleway - this is the next iteration of improving how footways and cycleways are displayed. Unpaved footways are now visible on natural=bare_rock and there are now three classes: paved, unpaved and unknown surface #1788
  • man_made=bridge is now rendered #1633, #1791
  • new rendering for landuse=quarry #1696
  • amenity=veterinary is now rendered #1656
  • amenity=community_centre is now rendered #1744
  • amenity=prison and landuse=military rendering takes in account area size #1739
  • consistent color for boundaries #1773
  • tweaked zoom level for amenity=car_sharing #1762 and amenity=car_rental #1761
  • Mapnik 3 preperations are now finished. The style now supports Mapnik 3. Most of the work was done on the Mapnik side. #1792

A full list of changes can be found on Github.

Style for footways and cycleways is not ideal and there are some known problems (see #1793 and #1748). Pull requests that would solve this issues are welcomed.

It is a good idea to check whatever bridges in your region are tagged for renderer - mistagging bridges as buildings is quite popular (only rare constructions fit definition of building=bridge - building=bridge is brown and man_made=bridge is gray).

For people interested in adding surface tags in their area - here is a helpful overpass query (zoom in before using “Run” button): This query return ways without surface tags and ones tagged with tags not documented as valid surface values. Only ways with highway=footway/path/cycleway are displayed. In nearly fully mapped regions one may modify query to search for missing surface also for other highway types.

As always, we welcome bug reports at where they will be tracked.

Previous release announcement:

Location: Osiedle Wilanów, Giżycko, gmina Giżycko, Giżycko County, Warmian-Masurian Voivodeship, 11-500, Poland


Next pull request for changing road style was opened. This time it is a final stage of proposing a rendering change including new colours for roads, new widths and rework of a railway styling. Feedback is welcomed.

PR link:

All changes before PR were squashed into two commits - as result changes done based on feedback since creating PR are listed on

Casings on z11

One of repeated comments was that casings on z11 are not working well. Therefore I prepared also another casingless variant for z11. Below are test renderings for some places (current rendering, rendering from PR, potential rendering using low zoom styling for z11)



Iceland, Reykjavik




New Jersey

Rural UK


z11 will be now using casingless style, especially as attempt to improve casings on low zoom by reducing it failed to solve problems with pixelated casings and managed to create new.

highway=pedestrian/living_street is this comparison was set to pale gray/gray version. Reported problems were fixed, resulting in new shield colors, tweaked road color and subtler casings. Thanks for the feedback!

This comparison is using latest version of style, newer than one used on the OSM website. The most important change is the new forest style.

For start: place that had problem with too strong casing resulting in problems with bridge that was not sufficiently different from other sections of roads. It is now improved - and now it should be OK.

What is preferable? Large images or smaller ones next to each other (like in the previous entry)? Or maybe big pictures next to each other - but available as links and not inlined (like many in this older entry)?


Default OSM style is displaying huge amount of information. Here is image of displayed road types on some of landcovers. Note that due to size limitation effects of service tags (that would tripple different road styles) are not displayed.

Full image

New road style fixes problems with certain road types invisible on common landcovers, but there are still some situations where road is too close to landcover. Unfortunately, as result of huge amount of landcovers it is not easily fixable - but new problems are a bit less severe than old “trunk is invisible in forests, secondary is invisible on farmland”.

highway=motorway through landuse=military is poor

highway=secondary shield is almost the same as the heath color

highway=secondary is close to natural=beach

highway=trunk infestation in San Paulo

Posted by Mateusz Konieczny on 8 August 2015 in English (English). Last updated on 10 August 2015.

To anybody editing in region of San Paulo - it seems that road classification in this region is thoroughly broken (many highway=trunk that probably should highway=tertiary/secondary given how road ends etc etc). It seems that somebody tagged all dual carriageway roads in this region as highway=trunk.

I opened also some notes - is there any better method of contact with local community?

Location: Vila Aurora, Mandaqui, São Paulo, Região Imediata de São Paulo, Região Metropolitana de São Paulo, Região Geográfica Intermediária de São Paulo, São Paulo, Southeast Region, 02410-010, Brazil

New road style for the Default map style - the full version

Posted by Mateusz Konieczny on 8 August 2015 in English (English). Last updated on 13 February 2019.

Next stages of developing new road style are finished.

First changes all already present on OSM website as result clutter on mid zoom levels is now reduced (#1682, #1690 and #1676).

This version is the first one tested also for low zoom levels.

At the start of this preview of the new style I want to thanks everybody who offered feedback. Obviously, not every suggestion was implemented - but many were highly useful and some are used. Thanks to everybody! Special thanks to Paul Norman for simplified osm2pgsql database dump that allowed to test low zoom levels.

For start - rendering for both in current and the new style (note - missing data that is causing poor rendering of railways in Antwerp is now fixed).

z11 50 8288 4 3684 z11 750px d396f750d41db78c227c62290f5dfeefbb91a730 750px 50 8288 4 3684 z11 750px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 750px

z10 50 8288 4 3684 z10 750px d396f750d41db78c227c62290f5dfeefbb91a730 750px 50 8288 4 3684 z10 750px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 750px

z9 50 8288 4 3684 z09 750px d396f750d41db78c227c62290f5dfeefbb91a730 750px 50 8288 4 3684 z09 750px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 750px

z8 50 8288 4 3684 z08 750px d396f750d41db78c227c62290f5dfeefbb91a730 750px 50 8288 4 3684 z08 750px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 750px

z7 50 8288 4 3684 z07 750px c6942c7a16fbd8f0048a8be8d7bf3703243b02e1 750px

z6 50 8288 4 3684 z06 300px d396f750d41db78c227c62290f5dfeefbb91a730 300px 50 8288 4 3684 z06 300px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 300px

z5 50 8288 4 3684 z06 300px d396f750d41db78c227c62290f5dfeefbb91a730 300px 50 8288 4 3684 z06 300px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 300px


z5 -36 8487 174 76135 z05 300px d396f750d41db78c227c62290f5dfeefbb91a730 300px -36 8487 174 76135 z05 300px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 300px

z6 -36 8487 174 76135 z06 300px d396f750d41db78c227c62290f5dfeefbb91a730 300px -36 8487 174 76135 z06 300px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 300px

z7 -36 8487 174 76135 z07 300px d396f750d41db78c227c62290f5dfeefbb91a730 300px -36 8487 174 76135 z07 750px c6942c7a16fbd8f0048a8be8d7bf3703243b02e1 750px


-36 8487 174 76135 z08 750px d396f750d41db78c227c62290f5dfeefbb91a730 750px -36 8487 174 76135 z08 750px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 750px

z9 -36 8487 174 76135 z09 750px d396f750d41db78c227c62290f5dfeefbb91a730 750px -36 8487 174 76135 z09 750px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 750px

z10 -36 8487 174 76135 z10 750px d396f750d41db78c227c62290f5dfeefbb91a730 750px -36 8487 174 76135 z10 750px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 750px

z11 -36 8487 174 76135 z11 750px d396f750d41db78c227c62290f5dfeefbb91a730 750px -36 8487 174 76135 z11 750px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 750px

And yes, these volcanoes are tagged correctly - see


Place mentioned in bug report #102 - “Secondary and trunk color too similar to landuse colors”

z5 malmo - fields 55 39276 13 2979 z05 300px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 300px

z6 malmo - fields 55 39276 13 2979 z06 300px d396f750d41db78c227c62290f5dfeefbb91a730 300px malmo - fields 55 39276 13 2979 z06 300px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 300px

z7 malmo - fields 55 39276 13 2979 z07 300px d396f750d41db78c227c62290f5dfeefbb91a730 300px malmo - fields 55 39276 13 2979 z07 750px c6942c7a16fbd8f0048a8be8d7bf3703243b02e1 750px

z8 malmo - fields 55 39276 13 2979 z08 750px d396f750d41db78c227c62290f5dfeefbb91a730 750px malmo - fields 55 39276 13 2979 z08 750px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 750px

z9 malmo - fields 55 39276 13 2979 z08 750px d396f750d41db78c227c62290f5dfeefbb91a730 750px malmo - fields 55 39276 13 2979 z09 750px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 750px

z10 malmo - fields 55 39276 13 2979 z10 750px d396f750d41db78c227c62290f5dfeefbb91a730 750px malmo - fields 55 39276 13 2979 z10 750px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 750px

z11 malmo - fields 55 39276 13 2979 z11 750px d396f750d41db78c227c62290f5dfeefbb91a730 750px malmo - fields 55 39276 13 2979 z11 750px 0eb62a8e825d0eeb622e072ac4830231bfa1f6e5 750px

Preview location from readme

preview pri7 -87 6515 41 8693 -87 615 41 8788

Current style:


One of the changes that I especially like are new railways - now less likely to be confused on low zoom levels with minor roads. The service tag is now used more for railways - minor tracks are rendered later (change already deployed on OSM website) and now main railways tracks are also more prominent. Tunnels for railway=rail also were changed to a version that is prettier and consistent with other railway tunnels.

Here are some additional examples with comparison how railway rendering may change.

london - railway tunnel 10 19 master - master 400px london - railway tunnel 10 19 new-road-style - new-road-style 400px

krakow - minor major railways 10 19 master - master 400px krakow - minor major railways 10 19 new-road-style - new-road-style 400px

highway=pedestrian, highway=living_street

I have a problem with colors for these road types. It is desirable to keep these distinguishable, using white colour and differentiating by width is not feasible.

Current colors are quite confusing - OK, highway=pedestrian is a bit darker. Then why living street - something between highway=pedestrian and normal streets is even darker?

The obvious solution - switch colors is problematic, as it makes squares really ugly:

vatican - square new-road-style -_ new-road-style 17 17 new-road-style - new-road-style 350px london - trafalgar square new-road-style -_ new-road-style 17 17 new-road-style - new-road-style 350px

It is possible to make both living street and pedestrian lighter.

vienna - square around church in the cetrum megacollider -_ megacollider 17 17 megacollider - megacollider 350px

but it makes highway=pedestrian and landuse=residential areas too close:

conflict with landuse residential - orchester megacollider megacollider-_megacollider 17 17 350px megacollider - megacollider 350px

Reddish highway=pedestrian was promising

living street pedestrian red -_ red 17 17 red - red 350px

until it turned out that it collides with other landuse

test_pedestrian_on_industrial 1 red red-_red 17 17 350px red - red 350px

Other PRs

During work on road rendering I discovered that map would look better with some landuses becoming lighter and less saturated. Therefore I slightly modified old proposal to modify rendering of forests and submitted it as #1728 (I opened a new PR as code needed to be updated).

There is an open PR that would unify highway=path and highway=footway styling and show surface for highway=path/footway/cycleway - #1713

There is also a PR that would improve rendering of highway=raceway: #1712

Also there are also PRs that would make farmland and power areas less prominent - see #1701 and #1680.

During the development of road style some long-standing bugs were sufficiently annoying to prepare code fixing these issues. Once test images will finish generation I will send also fixes for #1143, #686 and part of #1648


Some other minor changes like tweaking display of steps will be present in the next release


It is quite interesting - some changes are quite simple, like in this case. Entire PR was changing only one number. But preparing even such easy changes without causing problems requires testing many locations and weird situations to avoid unexpected reducing in quality of rendering. In that case, during preparations I tested several other variants - maybe even smaller (it was no longer looking like steps)? Maybe increase distance between red dashes (it no longer looked like a single element)? Maybe make red dashes narrow (it was not noticeable enough in typical cases)? Maybe reduce width but not so much (it was worse in areas of high steps density without benefit for typical situation with single steps in areas).

New road style for the Default map style - the second version

Posted by Mateusz Konieczny on 23 July 2015 in English (English). Last updated on 29 October 2018.

“map styles: Default OSM vs Google Maps” included a comparison of OSM Default map and Google maps. Now I present a similar comparison at the same location. But now with a third version - current version of new potential road style.

From left: (1) with changes developed as part of road redesign (2) currently used rendering on the OSM website (3) Google maps

Maybe it would be a good idea to make landuse=residential darker on low zoom levels to better mark built-up areas, but overall I consider this change as a significant improvement.

Changes based on feedback:

Thanks to daganzdaanda for the idea of displaying highway=tertiary as a white line, wider than highway=residential/unclassified. As tertiary roads are no longer using yellow it made possible to display secondaries using this colour, what in turn allowed to move hue of primary toward yellow.

It was not as simple as it sounds. For example, one of obvious consequences is that yellow roads are now rendered also on lower zoom levels. It is problem because the yellow roads are hard to keep visible both on landuse=farmland and unmapped land. For example using light yellow worked great on farmland but completely failed on unmapped land where it was really hard to notice.

Making highway=primary yellower allowed to render trunk in orange and keep road classes possible to differentiate.

So: highway=trunk and highway=motorway are now rendered differently.

See for example highway=trunk near Košice and D1 motorway.

and now with the new style. Game “spot highway=trunk” is now less challenging and it should be distinguishable from a motorway.

And view at the preview location from the readme

Using a grained fill pattern to indicate unpaved roads is an interesting idea that will be tested. I will also test the idea of using dashed casing for unpaved roads with tunnels marked solely by a colour change of fill and casing. There was also the idea of displaying tunnels as without fill what is also worth testing - but it is likely that displaying unpaved roads as one with dashed casing and fill would be too close. Also, size of ref shields should be reconsidered - it seems possible to make them small without losing readability.


There are also changes to how railway are displayed. Some improvements of rendering railway=tram will be used after next update of map style on OSM servers. But there also problems with rendering railway=rail - both major and minor (marked by service=spur/siding/yard) rails are rendered really close. At lower zoom levels rendering of railway=rail is really close to rendering of minor roads.

I am experimenting with changes to rendering of railways. Some changes are ready for presentation and effects are visible on presented examples.

Accepted changes

I am trying to find as many improvements as possible that may be proposed, discussed, improved and accepted as an isolated change. It makes discussion easier and bugs are less likely.

Turning circles on highway=track are no longer too big, code was improved. In addition highway=proposed is no longer rendered (for discussion and reasoning behind decision see

Currently proposed changes

There are also active pull requests, some of mine are done as part of road redesign. For example there in pull request proposing better display of minor tram tracks It is open question whatever railway=tram with service=spur/siding/yard should be rendered on z14 and z15 - feedback is welcomed (more locations with rendered before/after are listed on GitHub).

Examples of current work

Stopping too early rendering of highway=residential allows to achieve improvements like demonstrated in the first picture demonstrating changed rendering in London. But ceasing to render highway=residential on zoom levels 12 makes noise created by small buildings noticeable. These buildings are too small to be rendered in a useful way but big enough to create noticeable changes.

The simplest solution would be to start rendering buildings from z13, one zoom levels later. But some of the largest buildings may be usefully rendered on z12. Also, as usually there are additional complications (for example - moving only rendering of buildings to higher zoom level is not enough - it is necessary to move also rendering of amenity=place_of_worship).

On the left - current style. On the right - new style, including removal of highway=residential on this zoom level

And three examples of buildings may be handled:

stop rendering of all buildings (even the largest ones)

stop rendering of small buildings (threshold is arbitrary what is quite noticeable. In many places it is clear that some buildings are rendered and some not despite nearly the same size)

render only big buildings on z12 (my favourite - but it still arbitrary threshold and some big ones will not be rendered. But as rendered buildings are quite rare it is not so noticeable)

About problems with [surface=unpaved; access=destination] roads

Posted by Mateusz Konieczny on 18 July 2015 in English (English). Last updated on 29 October 2018.

Render paved/unpaved

Rendering surface value should reduce prevalence of using highway=track for any unpaved road. Unfortunately currently this tagging for renderer is really popular.


There are various styles typically used to depict important low quality roads:

  • (1) lack of fill, only the casing is displayed. But it works well on maps where most roads are OK, and only some are of low quality (typical for maps of Australia with unpaved roads across the outback). In areas where all or nearly all roads are unpaved results would be weird - roads render as thin double lines. Also, there would be problems with OSM data model, as rendering of crossings and places where way is split would be poor

  • (2) lack of casing or dashed casing - this style is currently used for tunnels. It would make necessary to find a new style for tunnels what is not easier. Also, people would be highly confused by using tunnel style with a new meaning.

  • (3) dashed fill (normal road colour & special colour) - it is a style that seems the most promising and examples below show how it may work. Roads under construction are currently using this style - it is also necessary to change it.

  • (4) new separate colours of fill/casing - changing only the casing is not really noticeable and/or is ugly, changing colour of fill doubles number of road classes that should be distinguishable. What worse, unpaved and paved of the same class should be similar what is quite hard to achieve. This differentiation is used really rarely, with Humanitarian style as the most prominent example.

  • (5) display in style similar to current highway=track - this style is not working well for important roads of a low quality (there are situations where [highway=primary; surface=unpaved] is used)

  • (6) dashed casing & fill (normal road style & empty space) - this style works better for roads under construction. highway=construction may start using such style

Styling of unpaved roads should:

  • introduce easily noticeable difference between paved and unpaved roads
  • do not introduce highly busy styling
  • make clear that unpaved road is worse than paved road
  • do not make unpaved road more noticeable than paved one
  • keep unpaved and paved road of the same class similar

on the left - current rendering, on the right possible new rendering

Imgur Imgur Imgur

But the situation is further complicated by fact that some roads are unpaved with set access=no/private/destination. Ideally it would be clear whatever given private road is also paved/unpaved. Unfortunately this part is not really successful.


On the map above it is not immediately clear which road, if any is unpaved.

But in case of private roads it is more important that there is no access than surface value and unpaved roads with access=destination are quite rare so maybe this problem is outweighed by rendering surface value.

One thing that remains to be adjusted is how prominent dashes should be. Below are sets of images with various intensity of dashes. For each location there are four images

left: current rendering right: light dashes

left: light dashes right: moderate dashes

left: moderate dashes right: strong dashes

left: strong dashes right: really strong dashes

Unpaved primary road

City with some unpaved roads

Unpaved service roads. Such roads are very often mapped using highway=track

Paved and unpaved raceways.

City with curvy unpaved roads

Unpaved road with access=private

Unpaved road in the city

Unpaved road in suburbs

Unpaved roads in a village

Unpaved road with access=destination

Unpaved tertiary road

Currently I am planning to use moderate dashes.

Differentiating highway=trunk and highway=motorway

I am working on two version of differentiating of these road types. First keeps all road types in white-yellow-red gradient, with an additional road class. Second is based on the German map style. Unfortunately, after days of tweaking I am still unhappy about results so I decided to avoid publishing preview.

highway=residential on z12?

flohoff proposed to keep highway=residential on z12

I love the z10 z11 residential road change. I’d like to keep them in z12 for the moment. Residentials often make one get an impression on residential areas and population density. That would get lost.

From my test (some comparison images are linked below) - rendering highway=residential on z12, less prominent than highway=unclassified improves map for locations without mapped landuse=residential. But for places where landuse=residential is mapped it is better to not render these roads.