OpenStreetMap

Mateusz Konieczny's Diary

Recent diary entries

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

Posted by Mateusz Konieczny on 8 August 2015 in 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 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).

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

Auckland

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

z8

-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 https://en.wikipedia.org/wiki/Auckland_volcanic_field

Malmo

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:

Railways

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

Merged

Some other minor changes like tweaking display of steps will be present in the next release https://github.com/gravitystorm/openstreetmap-carto/pull/1714

selection_001

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. 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.

railways

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 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)

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

Posted by Mateusz Konieczny on 18 July 2015 in 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.

ops

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.

unf

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

http://imgur.com/c3rZJSS http://imgur.com/UY9bFuH http://imgur.com/DNh5lSX http://imgur.com/bb1DNyt

City with some unpaved roads

http://imgur.com/FSATH8B.png http://imgur.com/s13BOyW.png http://imgur.com/k36hH6n.png http://imgur.com/OBIkJg5.png

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

http://imgur.com/MgrEwYm.png http://imgur.com/4HkPcEM.png http://imgur.com/Mqt7jiY.png http://imgur.com/jzFA62m.png

Paved and unpaved raceways.

http://imgur.com/zRhLBvc.png http://imgur.com/U85KLvw.png http://imgur.com/VqG9ogg.png http://imgur.com/1dK1HIw.png

City with curvy unpaved roads

http://imgur.com/vNRwchY.png http://imgur.com/MqCoHth.png http://imgur.com/6Qi2utb.png http://imgur.com/ghtFH80.png

Unpaved road with access=private

http://imgur.com/9dwnPep.png http://imgur.com/Rjawke2.png http://imgur.com/wLeY2Ym.png http://imgur.com/8bu9o5P.png

Unpaved road in the city

http://imgur.com/x5rV7CB.png http://imgur.com/jHs9rpa.png http://imgur.com/qoCHwLw.png http://imgur.com/AVech6Y.png

Unpaved road in suburbs

http://imgur.com/12lwI9b.png http://imgur.com/rksOG0e.png http://imgur.com/2VCLBcL.png http://imgur.com/OYtkxSx.png

Unpaved roads in a village

http://imgur.com/VNrAeN0.png http://imgur.com/tlC1I4J.png http://imgur.com/hzXjIkc.png http://imgur.com/RVMZq64.png

Unpaved road with access=destination

http://imgur.com/5iTG8cS.png http://imgur.com/AzO5A4G.png http://imgur.com/AYNXKnx.png http://imgur.com/QPuRM5V.png

Unpaved tertiary road

http://imgur.com/W7ftqMZ.png http://imgur.com/knm5PPW.png http://imgur.com/EukXVHK.png http://imgur.com/HMViVg8.png

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.

http://i.imgur.com/rUEOLI8.png

http://i.imgur.com/Tp736hw.png

http://i.imgur.com/raJ3FVw.png

http://i.imgur.com/J1UuqDT.png

http://i.imgur.com/eLuL1T7.png

http://i.imgur.com/qV3He6l.png

http://i.imgur.com/IW4oz01.png

http://i.imgur.com/vSpx5aL.png

http://i.imgur.com/rKzCTgX.png

http://i.imgur.com/GhL7GX8.png

http://i.imgur.com/O7Nft6h.png

http://i.imgur.com/Z19ZrDD.png

http://i.imgur.com/M3Gqeuj.png

http://i.imgur.com/vsvgZFj.png

http://i.imgur.com/uTDf5zz.png

http://i.imgur.com/EG9eTcv.png

http://i.imgur.com/dZNJDPS.png

http://i.imgur.com/LbZJLtM.png

http://i.imgur.com/LDgFrRp.png

http://i.imgur.com/Mhh4BIi.png

http://i.imgur.com/orusQI1.png

http://i.imgur.com/N9rjIaL.png

http://i.imgur.com/8FNAYWI.png

http://i.imgur.com/nQu7KXZ.png

http://i.imgur.com/mScRDnw.png

http://i.imgur.com/zDZLQy0.png

http://i.imgur.com/SAWln34.png

http://i.imgur.com/RBoKwjj.png

http://i.imgur.com/6JBgdFI.png

http://i.imgur.com/ZJrlCaB.png

http://i.imgur.com/vFUHPRm.png

http://i.imgur.com/t7ifFxv.png

http://i.imgur.com/ZLSyyNi.png

http://i.imgur.com/xyYPkVm.png

http://i.imgur.com/wrg90tY.png

http://i.imgur.com/m6VXGjA.png

http://i.imgur.com/70XQdHt.png

http://i.imgur.com/eBcQEOj.png

http://i.imgur.com/NH0UN2F.png

http://i.imgur.com/BMOWFBJ.png

http://i.imgur.com/PcBCfkm.png

http://i.imgur.com/Z4Tncd8.png

http://i.imgur.com/CsXpXnj.png

http://i.imgur.com/lEPJRio.png

New road style for the Default map style - highway=path is evil

Posted by Mateusz Konieczny on 14 July 2015 in English. Last updated on 29 October 2018.

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.

pedestrian_living street in bratislava master-_new-road-style 18 18 350px master - new-road-style

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) sao paulo new-road-style-_hide-residential -23 591 -46 5642 350px new-road-style - hide-residential tunis tunisia new-road-style-_hide-residential 36 8481 10 2289 350px new-road-style - hide-residential

z10 without both highway=residential and highway=unclassified (on the right - rendering of minor roads starts later) sao paulo new-road-style-_also-un -23 591 -46 5642 350px new-road-style - also-un chennai india new-road-style-_also-un 13 07886 80 27261 350px new-road-style - also-un

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?

rural area where highway footway are important narrow-subtle-_narrow 14 14 350px narrow-subtle - narrow prague czech republic narrow-subtle-_narrow 50 0853 14 432 350px narrow-subtle - narrow helsinki finland narrow-subtle-_narrow 60 16827 24 93188 350px narrow-subtle - narrow chennai india narrow-subtle-_narrow 13 07886 80 27261 350px narrow-subtle - narrow bangkok thailand narrow-subtle-_narrow 13 7529438 100 4941219 350px narrow-subtle - narrow sao paulo narrow-subtle-_narrow -23 591 -46 5642 350px narrow-subtle - narrow fully mapped residential area narrow-subtle-_narrow 14 14 350px narrow-subtle - narrow ciudad de mexico narrow-subtle-_narrow 19 4216 -99 0817 350px narrow-subtle - narrow roads with tram lines narrow-subtle-_narrow 14 14 350px narrow-subtle - narrow large area with high road density of many types narrow-subtle-_narrow 14 14 350px narrow-subtle - narrow city with high road density narrow-subtle-_narrow 14 14 350px narrow-subtle - narrow krakow - stare miasto narrow-subtle-_narrow 14 14 350px narrow-subtle - narrow european style town narrow-subtle-_narrow 14 14 350px narrow-subtle - narrow european style city narrow-subtle-_narrow 14 14 350px narrow-subtle - narrow extreme road density narrow-subtle-_narrow 14 14 350px narrow-subtle - narrow

Note - I would welcome examples of a well mapped rural areas for testing locations.

highway=path, highway=footway problems

according to http://wiki.openstreetmap.org/wiki/Tag:highway%3Dpath

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.

yes, wiki mentions that it may be tagged 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:

path/footway difference

  • 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.

rendering highway=proposed

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).

selection_001

rendering highway=road

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.

accepted changes

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.

rail - moscow before after

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).

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

Posted by Mateusz Konieczny on 8 July 2015 in English. Last updated on 17 July 2018.

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) preview master -87 6515 41 8693 -87 615 41 8788

Style under development - with its variants preview new-road-style-z16 -87 6515 41 8693 -87 615 41 8788 preview new-road-style-z16-with-purple-pedestrians -87 6515 41 8693 -87 615 41 8788 preview trunk -87 6515 41 8693 -87 615 41 8788

Major roads

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

both gray: https://cloud.githubusercontent.com/assets/899988/8582448/228d7c64-25c7-11e5-8c68-ed8d3c341628.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

highway=footway, highway=pedestrian

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.

52 4590957 13 362961 16zlevel 450px 1436392632 0 04 50 0559 19 8486 16zlevel 450px 1436253562 0 06

steps: https://cloud.githubusercontent.com/assets/899988/8583429/e841a86c-25cd-11e5-884e-1f3303ad3107.png

a rural area where highway=footway are important:

https://cloud.githubusercontent.com/assets/899988/8583432/e84b45b6-25cd-11e5-8007-d6ef04e5494e.png (purple style)

https://cloud.githubusercontent.com/assets/899988/8583430/e842da8e-25cd-11e5-90e5-2ebdd4687975.png (pink style)

https://cloud.githubusercontent.com/assets/899988/8583434/e8527642-25cd-11e5-95ff-9a56b811af5f.png (based on sb12 style)

https://cloud.githubusercontent.com/assets/899988/8583431/e8487ec6-25cd-11e5-9fa1-900ae0f5e350.png (orange style)

highway=pedestrian and highway=footway:

https://cloud.githubusercontent.com/assets/899988/8583436/e85f921e-25cd-11e5-8f93-f18a43c2ba42.png (purple)

https://cloud.githubusercontent.com/assets/899988/8583433/e85162b6-25cd-11e5-88c0-c7560caf3fdd.png (pink)

https://cloud.githubusercontent.com/assets/899988/8583437/e86606d0-25cd-11e5-870b-a07c48f474df.png (based on sb12)

https://cloud.githubusercontent.com/assets/899988/8583435/e85b4aa6-25cd-11e5-923a-19361827f8ec.png (orange)

in city:

https://cloud.githubusercontent.com/assets/899988/8583444/e8845e78-25cd-11e5-9448-f8bba23f4d43.png (purple)

https://cloud.githubusercontent.com/assets/899988/8583442/e878fd80-25cd-11e5-9841-69d67e2ff5a5.png (pink)

https://cloud.githubusercontent.com/assets/899988/8583445/e887b4f6-25cd-11e5-9f70-ac121d8612f7.png (based on sb12)

https://cloud.githubusercontent.com/assets/899988/8583443/e881c582-25cd-11e5-8093-ff64332828f0.png (orange)

pedestrian area & footways nearby landuse=railway:

https://cloud.githubusercontent.com/assets/899988/8583440/e86c37a8-25cd-11e5-9c75-96fec8a921b7.png (purple)

https://cloud.githubusercontent.com/assets/899988/8583438/e869fe52-25cd-11e5-89f8-5375f1b452aa.png (pink)

https://cloud.githubusercontent.com/assets/899988/8583441/e874e4b6-25cd-11e5-9a2e-9486bd9f7ace.png (based on sb12)

https://cloud.githubusercontent.com/assets/899988/8583439/e86a5b54-25cd-11e5-939e-a62df6967ae7.png (orange)

railway=tram

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”[1] 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.”[2] 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:

Vienna: https://cloud.githubusercontent.com/assets/899988/8582481/607c505e-25c7-11e5-806d-ecc64185809f.png

Praha: https://cloud.githubusercontent.com/assets/899988/8582483/607ee0f8-25c7-11e5-937b-a91fab9f1d48.png

Kraków: https://cloud.githubusercontent.com/assets/899988/8582570/ee7df6aa-25c7-11e5-94cc-e84032a519ce.png)

Helsinki: https://cloud.githubusercontent.com/assets/899988/8582569/ee7c6e3e-25c7-11e5-845e-80c3c96e7d42.png

map styles: Default OSM vs Humanitarian

Posted by Mateusz Konieczny on 10 May 2015 in English. Last updated on 17 July 2018.

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.

Kraków, Poland

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.

See for example Zliten, Libya - http://tools.geofabrik.de/mc/#17/32.4763/14.5690&num=2&mt0=mapnik&mt1=mapnik-humanitarian and http://overpass-turbo.eu/s/9gR

Imgur

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.

http://tools.geofabrik.de/mc/#15/13.0802/12.5267&num=2&mt0=mapnik&mt1=mapnik-humanitarian http://overpass-turbo.eu/s/9gT

Imgur

One quite interesting design choice that may be used during road redesign is less prominent rendering of tram lines.

map styles: Default OSM vs Google Maps

Posted by Mateusz Konieczny on 9 May 2015 in English. Last updated on 17 July 2018.

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).

z10

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.