I am happy to announce that we, the OpenStreetMap Carto maintainers, have prepared a new release of the OpenStreetMap Carto stylesheet (the default stylesheet on the OSM website). Once changes are deployed on openstreetmap.org it will take a couple of days before all tiles show the new rendering.

This is a minor release, but it still contains quite a lot of high impact changes to the map. We are also introducing a number of new design techniques in the style like scale dependent de-duplication of features and abbreviation of long labeling strings.

Under the hood we have added quite a few performance improvements, that we hope will ease resource requirement for style users and free resources for both mappers to add more data and for us to further improve the design of the map.

Here are some details on the visible changes this release brings to the style.

Motorway junction improvements

Density of highway=motorway_junction labels has been too high in some areas, leading to junction labels often blocking other labels (in particaular highway shields) while not being too useful themselves. We have made two changes in that regard:

• moving the starting zoom level for the labels up by one (ref starting z12 instead of z11, name starting z14 instead of z13).
• de-duplicating junctions with the same ref/name at the lower zoom levels.

The latter is important for motorway junctions because they are often mapped in pairs for both directions of the motorway. This previously often led to two identical labels and avoiding that helps a lot in reducing label density without removing substantial information. We also de-duplicate suffixes on ref (like 42a, 42b)

https://github.com/openstreetmap-carto/openstreetmap-carto/pull/5204

https://github.com/openstreetmap-carto/openstreetmap-carto/pull/5227

Thanks to contributor leijurv for implementing these changes.

Unification of the fill colour for power plants etc. with the fill colour for industrial landuses for zoom levels 10-12

This fixes the error of the fill color for power=generator and similar tags not being unified with all the other builtup landuses at lower zoom levels.

https://github.com/openstreetmap-carto/openstreetmap-carto/pull/5193

Thanks to contributor olafkryus for implementing this change.

Remove golf=pin rendering on polygons

We had previously displayed symbols for golf=pin on both nodes and polygons while mapper consensus is clearly that it is only used on nodes. This is changed now.

https://github.com/openstreetmap-carto/openstreetmap-carto/pull/5214

Thanks to contributor dch0ph for implementing this change.

Remove highway=bus_guideway oneway arrow offset

We had rendered oneway arrows on highway=bus_guideway with an offset next to the line for a long time, but it was noticed that this leads to confusion in case of several closeby roads. We therefore changed this to centered oneway arrows.

https://github.com/openstreetmap-carto/openstreetmap-carto/pull/5226

Thanks to contributor dch0ph for implementing this change.

Rework waterway lines

One of the biggest changes of this release is reworking of the waterway line rendering.

This includes, in particular:

• substantially narrowing the line signature of waterway=canal, which we had shown much stronger - like waterway=river - before, which does not reflect mapper consensus on the use of the tag though. This had led to mappers feeling discouraged to use waterway=canal on smaller artificial waterways. We have now adjusted this to a much more moderate line width.
• fixing errors and inconsistencies in bridge/tunnel rendering in some cases.
• reducing the halo of small waterways at high zoom levels, which had previously led to an inbalance between darker and brighter backgrounds.
• starting minor waterways earlier (at z12) in a subtle way to better communicate the drainage structure and provide better feedback on waterway mapping on a coarse scale.

https://github.com/openstreetmap-carto/openstreetmap-carto/pull/5201

Thanks to contributor dch0ph for implementing this change.

Render waterway=fish_pass and tidy waterway bridge/tunnel code

waterway=fish_pass has been established as tagging for structures at weirs or dams that are meant to facilitate fish passing by the barrier during migration. We have now added support for rendering those and at the same time re-organized rendering of waterway tunnels and bridges a bit. That leads to us no more rendering waterways that are tagged both bridge=yes and tunnel=yes - which is not really meaningful tagging anyway and which had broken rendering before.

https://github.com/openstreetmap-carto/openstreetmap-carto/pull/5240

Thanks to contributor leijurv for implementing this change.

Merge bridge and waterway-bridge layers

OSM-Carto has the most sophisticated and most accurate framework of layered roads rendering of all OSM based map styles in production use - yet there are various aspects in which our rendering is not properly reflecting the mapping in OSM. One of them is waterway bridges (like aqueducts) - which we have so far not correctly layered with the roads. The waterway bridges were always rendered above all road bridges, even if the layer tagging indicated othewise.

We have now integrated the waterway bridges into the road bridges layer and render them in correct order.

https://github.com/openstreetmap-carto/openstreetmap-carto/pull/5251

Thanks to contributor dch0ph for implementing this change.

Improvements of waterway=dam and other water barriers

A number of improvements were made to the rendering of waterway barriers, in particular dams.

waterway=dam is used to map dams in the sense of contructed barriers to contain a standing body of water (usually called a reservoir). This is not to be confused with man_made=dyke, which is a barrier to prevent flooding during seasonal or weather related higher water levels.

These can be and are mapped with either nodes, linear ways or polygons.

OSM-Carto has rendered waterway=dam for a long time, but we have had various issues with the rendering that needed work. Some of them have been addressed now.

First the appearance of dams at the first zoom levels (z13-z15) was often considered heavy, especially for smaller dams. We tuned the rendering parameters to address that - and also the high zoom level design to better show that linear way and polygon design are representations of the same feature class.

Then we removed rendering of name labels on the outline of waterway=weir mapped with polygons. We had stopped rendering polygons tagged waterway=weir because that is not consensus mapping, but the label rendering was remaining as a stray label. This is now fixed. Also we changed the drawing order to provide better feedback on overlapping waterway barriers by rendering linear ways above polygons.

As you can see there are still some issues not yet addressed - like the stray labels for dams mapped with nodes at the lower zoom levels and the offset of dam polygon labels.

https://github.com/openstreetmap-carto/openstreetmap-carto/pull/5241

https://github.com/openstreetmap-carto/openstreetmap-carto/pull/5264

Thanks to contributor dch0ph and leijurv for implementing these changes.

Remove rendering of name of amenity=charging_station

Like for many other points of interest we had - so far - rendered amenity=charging_station with a name label. But charging stations rarely have a proper name so the name tag on these is mostly abused as a label tag - not in line with the consensus among mappers about name tagging. Hence we decided to remove those labels. This also opens space for better differentiating charging stations in the future in a meaningful way - like indicating the vehicle types supported, plug standards, payment methods etc.

https://github.com/openstreetmap-carto/openstreetmap-carto/pull/5238

Thanks to contributor GA-Kevin-Codes for implementing this change.

Add rendering of man_made=ceremonial_gate

Some time ago mappers have discussed the idea to unify tagging of different types of ceremonial gates (common in east and southeast Asia) to a single primary tag and thereby making it easier for mappers to tag these (without requiring up-front knowledge of the specific type) and for data users to interpret them.

We have now added basic support for rendering these.

https://github.com/openstreetmap-carto/openstreetmap-carto/pull/5236

Thanks to contributor daishu0000 for implementing this change.

Delay minor accommodation text label

So far we have started showing symbols and labels of tourism accommodations (like hotels) all at the same zoom level (z17). With this change we now delay the name labels of the minor accommodations (tourism=guest_house and tourism=chalet) until z18.

https://github.com/openstreetmap-carto/openstreetmap-carto/pull/5262

Thanks to contributors dch0ph for implementing this change.

Shorten multi-component flat and housenumber lists

There are addresses mapped containing long lists in addr:housenumber or addr:flats, which led to very long labels in OSM-Carto. We now addressed this problem by abbreviating long lists in such tags with an ellipsis.

We deliberately did not try to fully parse the content of these tags and label them in an abbreviated and normalized form since there are no firmly established conventions for the form of these tags when containing more than a single number.

https://github.com/openstreetmap-carto/openstreetmap-carto/pull/5272

Thanks to contributors dch0ph for implementing this change.

Hide fake admin boundary segments on the 180 degree meridian

In OpenStreetMap we ought to map things in geographic coordinates, but unfortunately mappers often tend to map in equirectangular projection (which essentially means treating geographic coordinates as cartesian coordinates). And many data users also rely on them doing so.

This leads - among other things - to mappers creating fake geometries at the 180 degree meridian to formally close geometries in equirectangular projection (while, ironically, breaking them in geographic coordinates).

We in OSM-Carto have been in an unfortunate position since we - like many others - rely on software that expects data in equirectangular projection and is unable to process data in geographic coordinates. So we essentially are unable to support mappers in mapping things in geographic coordinates. So far we have displayed data as is - including the fake closures at the 180 degree meridian. We have now changed that for the administrative boundaries by explicitly removing those parts of the boundary directly on the 180 degree meridian. This works only because there are no actual administrative boundaries direcly on the 180 degree meridian of course.

There are still other issues related to the problem of the software we use only dealing with equirectangular projection and not being able to properly implement the periodic boundary conditions of the Mercator projection in longitude direction. We would like to do better in that regard, but have only limited options to do so.

https://github.com/openstreetmap-carto/openstreetmap-carto/pull/5294

Thanks to contributor leijurv for implementing this change.

Rework railway=crossing rendering (starting zoom level, prioritization)

So far we have rendered railway=level_crossing/railway=crossing in a very simple fashion, starting with a small symbol at z14/z15 and switching to a larger symbol at z16. The symbol also had very low priority, meaning it was often hidden by road labels despite there being space for the road label to not block the crossing.

We now changed that by making the starting zoom level depend on the type of crossing railway. Also we indicate if a crossing is mapped not on a railway track by using a different symbol.

https://github.com/openstreetmap-carto/openstreetmap-carto/pull/5285

Thanks to contributors dch0ph for implementing this change.

Lighten design and increase starting zoom level for minor service=* variants of some railways

We have also reviewed and re-designed the zoom level progression of minor service=* variants (service=spur/siding/yard) of some railways. railway=light_rail yards, in particular, were very heavy in appearance at the medium zoom levels and there were various inconsistencies in the zoom level progressions in general.

https://github.com/openstreetmap-carto/openstreetmap-carto/pull/5290

Thanks to contributor leijurv for implementing this change.

Other changes

This release also includes various other, non-visible changes. For a full list of commits, see

https://github.com/openstreetmap-carto/openstreetmap-carto/compare/v6.0.0…v6.1.0

Note for deployments: This release updates all of the SQL scripts that you need to run on the rendering database before using the style (indexes.sql, functions.sql and common-values.sql). See INSTALL.md for details.

Thanks

The OSM-Carto maintainers thank all contributors - including those who contributed changes not visible in the map that are not listed above. Particular thanks go to the new contributors:

olafkryus, daishu0000, Harvester57, wangi

I want, in particular, to thank Nakaner (geofabrik) and leijurv for work on efficiency improvements of the style.

Thanks also go to Mapnik developers for addressing various issues and implementing improvements of particular interest for OSM-Carto.

As always, we welcome any bug reports at

https://github.com/openstreetmap-carto/openstreetmap-carto/issues