Recent diary entries
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.
Time-saving code is relatively simple.
from selenium import webdriver import time from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support 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) driver.get('https://www.openstreetmap.org/#map=10/54.2066/-4.5782') #hide banners about SOtM and other spam for popup in driver.find_elements_by_class_name("close-wrap"): popup.click() driver.save_screenshot('Isle-of-Man.png')
overpass turbo screenshots are a bit trickier when we want to display query results
def smart_overpass_capture(url, image_file, driver): driver.get(url) element = WebDriverWait(driver, 10).until_not( EC.presence_of_element_located((By.CLASS_NAME, "loading")) ) driver.save_screenshot(image_file) smart_overpass_capture('http://overpass-turbo.eu/s/zNL', "Nepal-glaciers.png", driver)
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 http://www.akikoskinen.info/image-diffs-with-git/. 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?
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 https://matkoniecz.github.io/OSM-wikipedia-tag-validator-reports/Bremen,%20Deutschland.html (full list of locations with currently available reports is at https://matkoniecz.github.io/OSM-wikipedia-tag-validator-reports/ )
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.
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 http://www.imagico.de/map/aster_gdem.php http://www.imagico.de/pov/earth_srtm.php http://www.imagico.de/map/srtm1_en.php for some examples of complication). There are some sources with this problems partially fixed - http://srtm.csi.cgiar.org/ and http://www.viewfinderpanoramas.org/dem3.html 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).
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.
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 https://www.openstreetmap.org/#map=7/34.840/-95.902
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 https://www.openstreetmap.org/note/630900#map=13/34.8597/-95.8650)
See http://wiki.openstreetmap.org/wiki/Key:service#Railways 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.
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.
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 https://github.com/matkoniecz/before_after_for_placenames
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
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.
But I found nothing highly useful. For now
https://commons.wikimedia.org/wiki/File:Florida_topographic_map-en.svg https://commons.wikimedia.org/wiki/File:Scotland_map-fr.jpg https://commons.wikimedia.org/wiki/File:Scotland_topographic_map-fr.jpg https://commons.wikimedia.org/wiki/File:Deutschland_%C3%9Cbersichtskarte.png
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.
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 http://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny/surface%3Dwoodchip_to_surface%3Dwoodchips "
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:
http://www.openstreetmap.org/way/47749318 - 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.
http://www.openstreetmap.org/relation/1918067 - 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 http://www.openstreetmap.org/welcome - "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 http://www.openstreetmap.org/way/53821342 ).
It is OK to map objects under construction. But [highway=footway; construction=yes] is the best method to irritate data consumers (real - see http://www.openstreetmap.org/way/281018186#map=19/51.50653/-0.01904). 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 http://www.openstreetmap.org/node/1049342953#map=19/53.47988/-2.15500 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 - http://overpass-turbo.eu/s/bcS (it includes tags that nearly always are trolltags - but certainly some false positives will appear. For example vacant=yes is fine for building).
OpenStreetMap Carto 2.34.0 has been released and rolled out to the openstreetmap.org servers. It might take up to 48 hours before all tiles show the new rendering.
- 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.
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): http://overpass-turbo.eu/s/b88 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 https://github.com/gravitystorm/openstreetmap-carto/issues where they will be tracked.
Previous release announcement: http://www.openstreetmap.org/user/pnorman/diary/35589
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.
All changes before PR were squashed into two commits - as result changes done based on feedback since creating PR are listed on https://github.com/gravitystorm/openstreetmap-carto/pull/1736/commits
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)
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.
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
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?
Next stages of developing new road style are finished.
This version is the first one tested also for low zoom levels.
And at 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 http://www.openstreetmap.org/#map=10/50.8302/4.4769 both in current and the new style (note - missing data that is causing poor rendering of railways in Antwerp is now fixed).
And yes, this volcanoes are tagged correctly - see https://en.wikipedia.org/wiki/Auckland_volcanic_field
Place mentioned in bug report #102 - "Secondary and trunk color too similar to landuse colors"
Preview location from readme
One of changes that I especially like are new railways - now less likely to be confused on low zoom levels with minor roads. 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 version that is prettier and consistent with other railway tunnels.
Here are some additional examples with comparison how railway rendering may change.
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:
It is possible to make both living street and pedestrian lighter.
but it makes highway=pedestrian and landuse=residential areas too close:
Reddish highway=pedestrian was promising
until it turned out that it collides with other landuse
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
During development of road style some long-standing bugs were sufficiently annoying to prepare code fixing this 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 https://github.com/gravitystorm/openstreetmap-carto/pull/1714
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 preparing 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).
"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.
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 https://github.com/gravitystorm/openstreetmap-carto/issues/1654).
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)
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
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.
changes based on feedback (comments on diary and GitHub):
Reverted highway=footway, highway=path changes and restored currently used version. highway=motorway, highway=trunk rendering will be distinguishable. For oneway arrows old blue version also will be considered.
In addition feedback confirmed that it would be a good idea to: render motorway junction labels in red and rework widths of roads.
Example of the current rendering of pedestrian area (left - current rendering, right - proposed new rendering). highway=footway styling was rolled back, but highway=pedestrian/living_street is changed.
Request for a testing place
I am looking for a well mapped place where displaying highway=residential on z10/z11/z12 makes sense and is desirable. I am also looking for a place where rendering highway=unclassified at z10 is a good idea. According to my tests rendering these roads later improves situation, except places with badly mapped road types (highway=residential linking towns etc).
highway=residential rendering starting at z13, instead of z10 (on the right - rendering of minor roads starts later)
z10 without both highway=residential and highway=unclassified (on the right - rendering of minor roads starts later)
After such change it would probably be a good idea to make landuse=residential darker on z10/z11/z12 to make area covered by settlements clear.
Testing road width
I am experimenting with resizing roads and I would welcome feedback on these presented versions - what is a better version for highway=residential/living_street/pedestrian? Left or right side? Or maybe both are too narrow/wide?
Note - I would welcome examples of a well mapped rural areas for testing locations.
highway=path, highway=footway problems
highway=path is a generic path, either multi-use or unspecified usage, open to all non-motorized vehicles. The path may have any type of surface.
This includes walking and hiking trails, bike trails and paths, horse and stock trails, mountain bike trails, ski[disputed] and snowmobile trails[disputed] as well as combinations of the above
It is a big problem for designing rendering. Given that definition from wiki highway=path may be anything from paved cycleway, though paved footway or horse trail to mountain bike trail. Some even include snowmobile trails existing only during winter as an acceptable feature to be mapped as highway=path.
For general rendering it would be preferable to have two tags - one for footways/path/sidewalks open for pedestrians and second for weird variations like mountain bike trails and snowmobile trails existing only during winter rather than current situation.
But in reality overwhelming majority of highway=path is used to map paths that are not more open to non-motorized vehicles than highway=footway. It also seems that as result of a difference in Default map style it is very common to consider highway=footway as paved and highway=path as unpaved. Confirmations/refutations are welcomed as my personal experience is mostly limited to Poland - elsewhere it is mostly guessing based on limited research.
So there are following possibilities that may work:
- consider highway=path to be unpaved and highway=footway to be paved (current situation)
- stop differentiating between highway=path and highway=footway (render both using current styling of highway=footway or highway=path)
- stop differentiating between highway=path and highway=footway, render them differently based on surface tag
- invent a new tagging style (highly unlikely that something replacing highway=path/footway would be accepted, but the current one may be improved - see for example http://wiki.openstreetmap.org/wiki/Talk:Tag:highway%3Dpath#skiDisputed_and_snowmobile_trailsDisputed )
special access on highway=path (cycleways, bike trails, snowmobile routes)
- consider popular combinations equivalent to already rendered road types (current situation, for example [highway=path; bicycle=designated] is considered to be equivalent of [bighway=cycleway]), ignore other)
- detect popular combinations, in addition attempt to detect other special cases and do not display highway=path in such cases (foot=no would cause highway=path to not be rendered, except cases where it would be rendered thanks to fitting one of popular combinations)
I would welcome opinions on these possibilities and other ideas that would work. There possibilities that are not listed here because it would lead to poor results. For example differentiate rendering based on both highway=path/footway and surface value with four different stylings is not something that would work. Special rendering for every special case of highway=path is also impossible with a style that is supposed to be usable. Ceasing to detect [highway=path; bicycle=designated] makes no sense.
In addition it may be considered to treat highway=bridleway as a synonym of highway=path given relatively low importance of that way type and high similarity.
Related to current road restyling - see https://github.com/gravitystorm/openstreetmap-carto/issues/1654 that contains a proposal to stop rendering highway=proposed (in that case comments should be posted on GitHub issue).
I am not sure how to display this road type. In some way that it would make clear that it should be changed to proper highway type? But it would make the map ugly. But maybe in a situation like that it is acceptable?
Attempt to guess what is the most common proper type and render it in this style or close to it as it done currently? But it breaks The Mapper Feedback Loop, also it results in a confusing map where something that resembles highway=unclassified/residential may be anything.
Stop rendering of highway=road? Provided feedback is "you should not use this tag". It also would be highly confusing, this time for people contributing to OSM.
Next pull requests related to clutter on clutter around z10 were merged: start displaying minor rail from z13, fixes #1645 #1647. As result railway=rail ways with service=yard/siding/spur are no longer rendered on z11 and z12.
Stop displaying really small zoos and theme parks After that change smaller ones will appear later and bigger on earlier zoom levels (before/after with current road styling).
The first version of the road style is prepared. It is a work in progress and feedback is welcomed. I started work from designing z16 zoom level, currently I am expanding style to cover higher and lower zoom levels.
Current rendering (preview location from openstreetmap-carto readme)
Style under development - with its variants
Display of major roads on lower zoom levels is currently working quite OK and I am trying to make it better. For example, I am considering various variants how junction names and oneway arrows should be rendered. Below are some of possibilities.
Test renderings are for a location from "trunk is invisible in forest and secondary on farmland" bug report. All renderings have for comparison on the left side how map is currently displayed.
gray oneway arrows and red junction names: https://cloud.githubusercontent.com/assets/899988/8582450/22903378-25c7-11e5-8e6c-b88daeb5d81a.png
gray oneway arrows and blue names: https://cloud.githubusercontent.com/assets/899988/8582452/22bd76a8-25c7-11e5-9018-44d6f6d8d0cf.png
version with modified road colors: https://cloud.githubusercontent.com/assets/899988/8582451/22b4d58e-25c7-11e5-8dba-461c8a018bc0.png)
rendering for names and arrows unmodified despite road colour change: https://cloud.githubusercontent.com/assets/899988/8582447/228aa700-25c7-11e5-8b9e-64f79a2e2d9b.png
Current rendering of highway=footway is quite noisy, also highway=pedestrian is closer to highway=tertiary in its style than to highway=footway. Dotted highway footway is not pretty - for example rendering proposed by sb12 is much prettier. But finding styling that would at the same time would be prettier than the current one, do not look like a road and fulfil additional criteria turned out to be an interesting challenge. Finally, after many failed attempts, I tried as joke styling inspired by OSM landscape. It turned out to be better than expected and was the first one that was considered by testers both as prettier and with readability not worse than the current rendering.
Unfortunately, purple is already used for borders, airport infrastructure, railway land use and industrial landuse so I am experimenting with both different colour for pedestrian infrastructure and changing landuse colours.
a rural area where highway=footway are important:
highway=pedestrian and highway=footway:
pedestrian area & footways nearby landuse=railway:
Also - something that is already done.
During reworking road style I decided to try changing closely related tram style as on z13, z15, z16 tram lines were too noticeable.
During more close checking of rendering I discovered that tram tracks were rendered also on z10, z11 and z12 what was quite surprising as I never noticed it.
On reading code I discovered that railway=tram was rendered from z8, what makes no sense. Especially with current style as even during looking for tram lines at known positions I failed to notice it.
Overall this was one of many things leading to really bad rendering of cities around z10.
Even in Toronto, a city with "the largest streetcar system in the Americas" and quite far on the north (relevant due to distortion of scale) it makes sense to render trams up to z12. It is possible to make a weak argument for rendering at z11. See http://overpass-turbo.eu/s/ai3 (I linked overpass turbo, as in current rendering tram lines are not possible to find - despite rendering them).
Another example, Vienna - "With 173.4 km of track, Vienna's network is one of the largest in the world." z11 is the lowest zlevel where rendering tram makes sense ( http://overpass-turbo.eu/s/ai4 - note, the query returns a large amount of data).
In general it seems that even with large networks rendering tram up to z12 makes sense, z11 may be justified but it is not the best idea but later it is rather pointless.
And obviously, there is no point in rendering something in a way that makes it impossible to notice it.
Unfortunately it is impossible to make rendering great for all locations. In some places each tram tracks are mapped separately and in some places two tracks are together mapped as a single railway=tram line. In places where two tracks are mapped as one on low zoom levels trams are not displayed not as strong where each track is mapped. Compare for example Praha (where two tracks are mapped as a single railway=tram line) with Helsinki and Kraków (each track mapped as a railway=tram line).
Tram rendering is causing exactly the same problem with current road style and my proposed version. Working on it separately makes easier to test and review so I prepared it as a separate change.
Proposed change that should improve the situation was merged yesterday - thanks for the feedback!
Changes for different locations:
Humanitarian map style is in some ways between current Default OSM style and Google maps style. It is not using so many colours for roads as openstreetmap-carto but still more than Google maps. The same may be said about how quickly minor roads are disappearing and some other choices unrelated to displaying roads.
As result Humanitarian style is also better at lower zoom levels than openstreetmap-carto - again mostly thanks to a subtler display of minor roads and not using all possible colours to display roads.
Not so wide roads also work better especially in areas with high road density.
It seems that main reason for really wide roads in a Default OSM style is to keep street labels within road area. But both Humanitarian and Google maps have labels sticking outside road areas and narrower roads what seems to work much better. Also in areas that are not so extreme.
In Humanitarian style trunk and motorway are displayed using the same style - it is the next candidate for such merge. Note that at lowest zoom levels there is a difference between trunk and motorway. In Humanitarian map style also highway=footway and highway=pedestrian are displayed using the same style but this union seems to not be really working for general purpose map.
It is also interesting to check how displaying surface tag works in that style. In Humanitarian unpaved minor roads are marked by making road darker, with brown colour. It has a side-effect of making roads more visible. It suggests (at least for me) a higher importance of road rather than a worse surface.
All tracks are displayed in the same style (tracktype and surface tags are ignored), all tracks are assumed to be unpaved what is not really working. As highway=track may be anything from something barely usable to high quality road - highway=track is defined by its function, not quality.
For major roads situation is better - making paved roads intensively coloured and unpaved pale works better, though there may be too significant difference between paved and unpaved primary road.
One quite interesting design choice that may be used during road redesign is less prominent rendering of tram lines.
Currently I am working on a GSoC project - improvement of styling of roads and paths in openstreetmap-carto, the default OSM map style.
I started from researching how other map styles are designed. I would welcome comments and feedback as it would allow to notice my biases. Feedback on general ideas will hopefully reduce amount of time needed to rework and tweak style that I will produce.
The first compared map style is probably the most popular one, used by Google maps.
At high zoom levels any OSM map is typically better than Google Maps as a result of more detailed and rich data. Quality of Google Maps is also decreased because one of its primary roles is to be used as a place to advertise businesses - what results in businesses appearing earlier than reasonable and leaving no place for more useful information.
But as one zooms out the situation is typically changing, with OSM rapidly losing - and the worst situation is in the cities, with roads as a major source of a problem.
For example, lets try with London.
First problems are noticeable at z16 - openstreetmap-carto has more information but is also less readable. The first road-related issue is that some oneway roads are without arrows (names are displayed instead making it one of many tradeoffs - not everything may be displayed).
z15 has much bigger problems for OSM - hierarchy of road importance is clearly more readable in Google maps. It is an effect of lower amount of displayed data and no using as many colours as possible in gmaps. openstreetmap-carto is using for displaying roads blue, green, orange, red, yellow and white. Google restricted palette to white, yellow and orange - what gives much better results.
The situation gets continually worse for OSM on zooming out to z14, z13, z12. Nearly all roads continue to be displayed on both maps, but in Google roads of lower importance are nearly invisible, the Default OSM map is much messier. In addition on z12 green trunk roads are merging with parks making the map even less readable.
On z11 Google drops minor roads completely, in OSM are still displayed but no useful information is presented - it results only in a messier map.
On z10 Google Maps also have a problem with high road density in London - but road network as presented by openstreetmap-carto is even worse and completely unreadable beyond "there are many roads in London". M4 looks like a continuation of Thames. Rural areas are not much better (trunk roads through forests etc).
Further zooming out is not improving the situation for OSM.
First thought is that using blue, green, red etc for roads may work for maps that limits itself to displaying roads, towns and cities - but it is not going to work for a map that is trying to show nearly everything.
Maybe attempting to make highway=primary and secondary, higway=residential and living_street, highway=track and highway=service clearly different is not really necessary? Maybe displaying both using the same style may work better and reduce clutter?
It would be nice to not display roads of lower importance in cities on lower zoom level, but doing it in other areas. Maybe it would be doable by something like making landuse=residential and minor roads the same colour in lower zoom levels? It seems to work in Google maps.
It may seem easy to solve other mentioned problems by starting to render roads of each class later than it is done currently but it is not so simple.
Let's try another location - in a rural area in UK with much lower road density.
Here a combination of facts that somebody mapped this area in OSM, lack of data in Google maps and low feature density makes OSM a clear winner for z14 and higher. Lower zoom levels are problematic for OSM map. Road network continues to be less and less readable in OSM since z13, famous "green trunk through green area" problem is making it even worse.
Note that rendering roads later what would improve rendering in London means harm for map in low density areas like this one. It would be much better to solve situation differently.
One of limitations is that the same feature in one place may be completely unimportant and critically important in another. For example - one of thousands unimportant highway=footway through a park in a massive city or highway=footway in a remote area of high mountains, the most important feature within several kilometers. Both will be rendered using exactly the same style. Therefore most tweaking of style will improve some locations but make it worse in others, it is completely impossible to make it perfect everywhere. The obvious solution - render features differently in low density areas is really hard to do properly and doing this is not planned as part of this GSoC project.
It may be possible to try different things - minor roads at low zoom levels with the same colour as landuse=residential? Displaying narrower roads? But some tradeoffs will be necessary.