gravitystorm/openstreetmap-carto

A general-purpose OpenStreetMap mapnik style, in CartoCSS

OpenStreetMap Carto

These are the CartoCSS map stylesheets for the Standard map layer on OpenStreetMap.org.

The general purpose, the cartographic design goals and guidelines for this style are outlined in CARTOGRAPHY.md.

These stylesheets can be used in your own cartography projects, and are designed to be easily customised. They work with Kosmtik and also with the command-line CartoCSS processor.

Since August 2013 these stylesheets have been used on the OSMF tileservers (tile.openstreetmap.org), and are updated from each point release. They supersede the previous XML-based stylesheets.

Installation

You need a PostGIS database populated with OpenStreetMap data along with auxillary shapefiles. See INSTALL.md.

Contributing

Contributions to this project are welcome, see CONTRIBUTING.md for full details.

Versioning

This project follows a MAJOR.MINOR.PATCH versioning system. In the context of a cartographic project you can expect the following:

• PATCH: When a patch version is released, there would be no reason not to upgrade. PATCH versions contain only bugfixes e.g. stylesheets won't compile, features are missing by mistake, etc.
• MINOR: These are routine releases and happen every 2-5 weeks. They will contain changes to what's shown on the map, how they appear, new features added and old features removed. They may rarely contain changes to assets i.e. shapefiles and fonts but will not contain changes that require software or database upgrades.
• MAJOR: Any change the requires reloading a database, or upgrading software dependencies will trigger a major version change.

Roadmap

Initial Release (v1.0.0, December 2012)

This was a full re-implementation of the original OSM style, with only a few bugs discovered later. There's been no interest in creating further point releases in the v1.x series.

Mapnik 2 work (v2.x)

The v2.x series initially focused on refactoring the style, both to to fix glitches and to leverage new features in CartoCSS / Mapnik to simplify the stylesheets with only small changes to the output, as well as removing 'old-skool' tagging methods that are now rarely used. It then started adding new features.

Mapnik and CartoCSS update (v3.x)

The v3.x series was triggered by an update to the required Mapnik and CartoCSS versions.

Care has been taken to not get too clever with variables and expressions. While these often make it easier to customise, experience has shown that over-cleverness (e.g. interpolated entities) can discourage contributions.

Database schema change (v4.x)

The v4.x series includes osm2pgsql lua transforms and a hstore column with all other tags, allowing use of more OpenStreetMap data. Users need to reload their databases, v3.x compatibility is not maintained.

Database schema change (v5.x)

The v5.x series updates Lua tag transforms, linestring and polygon decisions have changed.

There are over 500 open requests, some that have been open for years. These need reviewing and dividing into obvious fixes, or additional new features that need some cartographic judgement.

Alternatives

There are many open-source stylesheets written for creating OpenStreetMap-based maps using Mapnik, many based on this project. Some alternatives are:

• OSM Bright
• XML-based stylesheets
• OpenStreetMap "FR" Carto
• OpenStreetMap Carto German

Maintainers

• Andy Allan @gravitystorm
• Paul Norman @pnorman
• Daniel Koć @kocio-pl
• Christoph Hormann @imagico
• Lukas Sommer @sommerluk
• Joseph Eisenberg @jeisenbe

Previous maintainers

• Michael Glanznig @nebulon42
• Matthijs Melissen @matthijsmelissen
• Mateusz Konieczny @matkoniecz

openstreetmap-carto's Issues

undocumented curl dependency

There is an undocumented curl dependency. curl is not included by default on a ubuntu desktop 13.04 install

performance issues in comparison to "standard" style

I configured Mapnik master with ./configure RENDERING_STATS=True, picked a single tile at z13 with a bunch of data (http://tile.osm.org/13/4052/2688.png) and made a first crack at finding performance differences between this style and the osm.xml standard style.

I've found that this style is 1.5 to 2x slower than the osm.xml even though the layers are identical. The culprit is the usage of Carto attachments which generate more <Style> objects in XML and therefore trigger more queries against the database (many of which are less efficient because they pull data that is later thrown away).

The best example of the problem is the landcover layer. In the osm.xml it is a single layer and style, while in this style it is 9 separate styles such that 9 database queries are issued for the same exact data for a single layer. For the sample tile this meant osm.xml rendered landcover in 200 ms while this style rendered landcover in 1.4s. It looks like the cause of the attachment usage in this case was to work around this carto bug: mapbox/carto#20 as discussed in #15.

Other expensive queries like buildings and minor-roads also suffer slightly from the same problem:

• This style renders buildings in 7.5 seconds using 2 styles while osm.xml renders with a single style in 3.5 seconds. The second style in question here is buildings-aeroway and renders no data, while over 100,000 rows are queried. So, in makes complete sense here that rendering of building would be 2x as slow: actual rendering is only happening once, but the data is fetched twice before other layers can be rendered.
• Also for minor-roads this style renders in 2s (vs 1.4s) and uses 2 styles (vs 1). The second style in question is minor-roads-fill-railway and for this tile ends up pulling 31654 features but only renders 871.

For reference, here is the output for the carto style (https://gist.github.com/4323399) and for the standard osm.xml (https://gist.github.com/4323395).

highway=construction renders without dashes

http://bl.ocks.org/d/4271706/#16.00/59.3235/-335.2230
osm vs osm-carto on the image below:

schools are bold @ z15 in osm-carto, but not in osm

low priority & not sure which treatment is better, but fyi...

Refactor other.mss into different files

The contents of other.mss is the same grab-back of styles rules as were left in osm.xml after the (partial) refactoring into inc files.

This doesn't help people figure out their way around the stylesheets.

Much of the file consists of the "layered lines", mainly roads but also railways and aeroways. Is there a good name for this collection of features? The rest can be spat out into other files, as appropriate.

station, sub_station areas don't need different styles

power=sub_station areas could probably be grouped along with power=station and power=generator in the landcover query as just 'power', in turn letting us get away with a bit less CartoCSS

this is somewhat beyond the scope of this ticket, but we could also make sure that all power features (i.e. power lines, etc) use the same hues - along the lines of #60

customize postgres configuration

would be great if you could configure the postgres connection parameters with a simple script - some people may be connection on different hosts, users, passwords, etc and it's a pain to use TileMill's GUI to change these, and scary to do this with sed. especially true if you are unfamiliar with a project.mml.

could be some very simple variable replacement magic.

Remove ogr2ogr dependency

Given that we only need it for one minor task, we should remove the ogr2ogr dependency from the setup. It's not too bad on linux systems (yay package management) but it's an unnecessary hurdle elsewhere.

If we can't get the NE shapefile fixed upstream, then lets host a fixed version of the file somewhere and grab it from there instead.

Use style-level opacity for national park boundaries

At the moment the line-opacity values leads to nasties when they boundaries overlap or double back on themselves.

See http://www.openstreetmap.org/?lat=57.011&lon=-6.428&zoom=10&layers=M (from #59 ) where the boundaries around coastlines are of varying intensity.

highway=construction too wide at Z13

At zoom 13/14/15 highway=construction renders too wide. See fat dashed line below. Note that this object no longer appears on yevaud, the tags have been changed since my local planet import.

my local DB has:

gis=# select osm_id,highway,railway,construction from planet_osm_line where osm_id=157955877;
  osm_id   |   highway    | railway | construction 
-----------+--------------+---------+--------------
 157955877 | construction |         | 

http://www.openstreetmap.org/browse/way/157955877

Use land polygons from OpenStreetData.org

Please switch the style to use the Land Polygons from: http://openstreetmapdata.com/data/land-polygons

Performance enhancements: ST_Intersects

In some cases ST_Intersects may provide performance enhancements over && in some cases.

Likely cases are queries which involve long linestrings. Unlikely cases are small polygons (e.g. buildings)

This is a general performance enhancement and would apply to osm.xml as well.

admin_levl=6 on ZL 9 and 10

From Toby:

county borders (admin_levl=6) aren't being rendered at zoom 9 and 10. But I do recall some confusion on the existing style between ways and relations. I don't remember the details but there was some difference between the zoom level at which ways and relations tagged with admin_level=6 got rendered. Maybe this caused confusion when porting to carto? Easy place to see this difference: http://bl.ocks.org/d/4271706/#9.00/39.4664/-96.9125

Response from AJ:

This seems to be about boundary relation way members being individually (and redundantly?) tagged with boundary=administrative. Some of the admin_level=6 ways in this area 1 are tagged as boundary=administrative, and others are tagless members of boundary relations. If you zoom out, the tagless ways disappear at zoom level 10 and below.

This commented out section of the stylesheet may be why the CartoCSS version is different:

https://github.com/gravitystorm/openstreetmap-carto/blob/master/admin.mss#L75-L85

natural=scrub a bit lighter now in lower zoom levels

The water body in the middle of http://bl.ocks.org/d/4271706/#13.00/51.1123/13.9906 (http://www.openstreetmap.org/browse/way/50772537) is surrounded by natural=scrub which is rendered a bit lighter than in the non-Carto version at zoom levels where the icon is not used (zoom<13).

building=hotel missing names

There are a few hotels near this one and none of them appear with names in the Carto tiles

http://www.openstreetmap.org/browse/way/146220935

http://tile.osm.osuosl.org/tiles/osm_carto/17/38599/49259.png

barrier=hedge polygons not filled

in the original mapnik/osm style, barrier=hedge polygons are filled not in the cartocss version.

in others.mss there is #barriers_area but project.mml does not use it, but uses .barriers for both lines and polygons, so the polygon-fill can simply move there...

See https://github.com/gravitystorm/openstreetmap-carto/blob/master/other.mss#L2891

Halo on secondary

OSM Standard has no halo on secondary, while OSM-carto does have one in orange (see Castro street label).

OSM (existing):

OSM-carto (new):

leisure = playground shows see-saw icon but no area

The see-saw is shown but the area around it isn't. Could be an ordering issue with the landuse=residential area it is inside.

http://tile.osm.osuosl.org/tiles/osm_carto/17/38603/49274.png

http://www.openstreetmap.org/browse/way/147067262

waterway=ditch is rendered with a casing

waterway=ditch in osm-carto renders with a white casing; in the default mapnik style, it does not.

See http://bl.ocks.org/d/4271706/#17.00/41.44225/-81.68726 as an example .

Personally, it looks better with the casing, but that's for 3.0 =)

As I look at this more, it may be an error/design choice with the old stylesheet...

https://github.com/openstreetmap/mapnik-stylesheets/blob/master/inc/layer-water.xml.inc#L68 - instructs stroking zoom >= 15+.
only if there is a tunnel.
https://github.com/openstreetmap/mapnik-stylesheets/blob/master/inc/layer-water.xml.inc#L281

highway = bus_stop often missing

Seems like these bus_stop icons often go missing for no obvious reason, e.g.

http://www.openstreetmap.org/browse/node/2063039041

should appear on this tile

http://tile.osm.osuosl.org/tiles/osm_carto/17/38602/49275.png

there are two more bus stops on junctions to the South along this road which aren't shown either.

Recreation grounds are not being rendered

e.g. http://bl.ocks.org/d/4271706/#17.00/52.05596/1.19319 for Newbury Road recreation ground in Ipswich. Several zoom levels.

London underground lines on top of roads

In London the Carto style often places the underground tube lines over the top of roads

natural=cliff renders with one excess line

natural=cliff renders as two parellel lines+triangles instead of one line+triangles.
Example: http://bl.ocks.org/d/4271706/#17.00/59.40349/24.61058

Should landcover be ordered by z_order?

At the moment the query orders by both z_order and way_area. Ordering by area makes sure small polygons end up on top (where there's no holes in a larger polygon). I guess z_order will help if the features are on separate layers, since there's no fine control over landcover ordering required.

But is this necessary? Are overlapping features with different z_orders - and the larger one on top - either common or wanted?

Road colors changed in e0d614719

In e0d6147, several roads changed color. Notably, low-zoom residential roads are quite darker.

• #tunnels::casing
  • tertiary,tertiary_link at zoom>=13
    • was #999, now @tertiary-casing = #bbb
  • residential,unclassified,road at zoom>=13
    • was #999, now @residential-casing = #bbb
• #minor-roads-fill
  • tertiary,residential,unclassified,road at zooms 10-13
    • was #bbb, now @residential-thin = #999
  • service=INT-normal at zoom>=13
    • was #bbb, now @residential-thin = #999

It looks like bbb and 999 were swapped when extracting the values into variables.

There's also this one, but the new value wasn't used elsewhere before, so perhaps it was intentional:

• #roads
  • secondary, secondary_link at zooms 9-12:
    • was #fecc8b, now @secondary-fill = #fed7a5

shop = clothes is missing name?

There are a few shops near this one and each one has an icon but no name in the carto map. There looks like there should be sufficient space available.

http://www.openstreetmap.org/browse/node/1378899236

natural=coastline renders name along shore/coastline

On z15+, name of a lake (which, because it's very large, is tagged as natural=coastline) is displayed along its edge, as shown in this image instead of being within the body of water.

Here it is on osm

This may be the result of using different coastline files being used in osm-carto and on the main mapnik server.

hospital name has text in wrong color

OSM layer uses similar pink for text and icon

http://www.openstreetmap.org/browse/node/357642745

Carto uses black text

http://tile.osm.osuosl.org/tiles/osm_carto/17/38599/49271.png

Check for programs before downloading in get-coastlines.sh

Currently get-coastlines.sh assumes the presence of all the programs it is going to use.

Checking before downloading would be a good idea.

Remove the catchall from #roads-text-name

There's a catchall at the end of #roads-text-name that draws labels on all kinds of things. This should be reworked into explicit rules.

At the moment it'll label all kinds of linear features, due to the rather bizarre sql query. It should only render roads, and if other things (underground power cables?) need labelling, there should be explicit rules for these to allow people to turn them on and off as they see fit.

Also, the catch-all leads to needing to explicitly override the values (e.g. halo-radius: 0;) on the more explicit rules.

ogr2ogr warnings

ogr2ogr data/ne_10m_populated_places/ne_10m_populated_places_fixed.shp data/ne_10m_populated_places/ne_10m_populated_places.shp in get-shapefiles.sh generates the warning

Warning 1: One or several characters couldn't be converted correctly from UTF-8 to ISO-8859-1.
This warning will not be emitted anymore.

Improve the different tracktypes

4319b29 mentions that tracktypes need output-affecting work.

The refactoring highlights the mess that the tracktype declarations have become, with inconsistent colours, opacities, and smaller tracks (e.g. grade4, grade5) being wider than more important ones.
I've also highlighted two places where grade3 ends up missing a dasharray pattern.

Bring some consistency and predictable progression to widths, opacities and colours, fix the bugs in grade3 on bridges and in tunnels, and generally simplify and tidy things up.

remove natural=hedge

It's explicitly mentioned in sql queries, but barrier=hedge is ~1000 time more popular.

line-color should be related to polygon-fill for most if not all polygon features

This would simplify both the visual style and the code base considerably. Ideally we do this by establishing a convention like

polygon-fill: @some_color;
line-color: darken(@some_color, 10%)

although I imagine there will need to be considerable tweaking

Names of residential, unclassified ways are repeated too often at z17+

Names of residential, unclassified ways are repeated too often at z17+.

As an example: http://imgur.com/mAOcMXx (This same area in OSM)

Another example

While trying to fix this, I found that in the OSM mapnik stylesheet, (Line 3226), residential and unclassified ways at z17+ have a text-spacing of 400px.

Since this is missing in the carto stylesheet other.mss at the moment , I added - text-spacing: 400; at line 2875 to other.mss in my local (and updated) repo but it didn't fix this.

I wondered if the catch-all (noted with comment as 'other roads') (written right below the rule) was the culprit, but I also added the text-spacing:400 there and the names were still close together.

I also made sure, each of those ways in the examples are each one singular way, not multiple ways connected together (that have the same tags).

Labels for highway=construction is rendered at z13,z14

For example, these 3 ways' names display at z13 ,14
in osm-carto, not the case in the standard mapnik layer. The only commonality is the highway=construction tag on them.

Interestingly, this way also has the highway=construction tag on it, but also has the tag access=no - as a result, the way's name does not display at z13 or 14.

Use alternate source for world_boundaries-spherical.tgz

We should use an alternate source for this file. I think it's vmap0 but I'm not sure

larger text halo radius for school, college, university & kindergarten

In the carto style the text radius for school, college, etc is 2, whereas the osm.xml is only 1

osm.xml:
[amenity] = 'school' or [amenity] = 'college'
TextSymbolizer size="9" fill="#33" fontset-name="book-fonts" halo-radius="1" wrap-width="14" placement="interior">[name]

carto:
([amenity] = 'school')
TextSymbolizer size="9" fill="#33" fontset-name="fontset-0" halo-radius="2" wrap-width="14" placement="interior" ><![CDATA[[name]]]>

thematically related landcover types should use the same hue

I'm thinking that features like parks, grasslands, wood, forest, pitch, etc could share a consistent hue and be differentiated only by their lightness and/or saturation. lowest hanging fruit seem to be land cover types, but i wonder where else this could help clean up the map + create a more organized palette.

Definitely a version 3 ticket.

Resolve the landcover ordering problem

As a workaround for mapbox/carto#20 all the entries in landcover.mss have key-based attachments. This breaks the order-by-area clause, and also leaves the output of multiple tagging (e.g. #6 ) susceptible to changes in refactoring[1]

A different approach is needed, to make overlapping areas more likely to be drawn as intended (i.e. smallest on top), while preserving the clarity of the mss. Two choices spring to mind:

• sql-level coalesce into a "feature" type, with the corresponding changes to filters. Can lead to confusion among contributors (e.g. "feature=residential") , but removes need for attachments
• Something clever with group-by on the layer, based on area. Is this even possible?

[1] since attachment draw order is based on the order its first encountered, adding or removing a rule that happens to act as the first declaration of the attachment can change the order of layers entirely.

leisure=garden rendering pink

leisure=garden is rendering pink where it should be green:

Slow queries on US test server

Ian Dees reports these slow queries from running the OSM-carto style on tile.osm.osuosl.org

I've been trying to figure out why the carto style rendering is taking so damn long on tile.osm.osuosl.org. I think it's mostly because it was catching up on osm2pgsql until very recently, but I did notice some particular slow queries that I thought I should send you to think about:

https://gist.github.com/4558b2dab2ecfb35a389#file-slow_query_a-sql

This guy tends to take a very long time and the query planner doesn't seem to be using any indexes:

https://gist.github.com/4558b2dab2ecfb35a389#file-query_plan_a-sql

Again, this could simply be osm2pgsql keeping the disks too busy to do anything else, but I thought I'd pass along more data.

construction being rendered for bus_guideway

It appears that the carto style renders a dashed line for the bus_guideway under construction which isn't shown in the legacy osm.xml.

http://www.openstreetmap.org/browse/way/45320333

carto:

legacy:

gis=# select osm_id,highway,railway,construction from planet_osm_line where osm_id=45320333;
  osm_id  |   highway    | railway | construction 
----------+--------------+---------+--------------
 45320333 | construction |         | bus_guideway

openstreetmap-carto uses a different file layout for the shape files

Not that it matters too much, but the layout of the "world_boundaries" shape files have changed. So you can't use the same shapefile directory for testing both styles.

In the old style the shape files were all in a single flat directory. Now the shape files are each in a sub directory.

It also tries to use a ne_10m_populated_places_fixed.shp rather than ne_10m_populated_places.shp file.

Document expected osm2pgsql command

There are a number of different ways to load data with osm2pgsql. We should document the options that the stylesheet expects

No halo on tertiary

OSM Standard has a white holo on tertiary highways where OSM-carto has none.

OSM (existing):

OSM-carto (new):

Move to group-by for bridge layers

group-by is a layer property released in v2.1 of mapnik.

It'll cut down all the repetition, in both layer definitions and the output xml, for the bridges layers. If it works well, it could be expanded to stack all the non-bridge layers properly too.

See https://github.com/mapnik/mapnik/wiki/Grouped-rendering

It's supported (but not documented) in CartoCSS by using the "properties" of a layer definition.

Recommend -G flag for multipolygons

Relations with multiple members like http://www.openstreetmap.org/?lat=57.011&lon=-6.428&zoom=10&layers=M are rendered multiple times and are a bit of a cartographic disaster.

One possible fix is to import with osm2pgsql in -G mode to create a MULTIPOLYGON instead of multiple POLYGONs. @springmeyer informs me that mapnik should render the label on just the largest POLYGON within the MULTIPOLYGON by default.

Do we know anyone running with -G?

associate label styles with the features they label

For example, park labels should (in some, yet-to-be-determined) way inherit their color from parks. If implemented well, this could considerably reduce noise without removing features.

probably a Version 3 task

Download script errors on first run

When running with no previous files downloaded the errors

Warning: Illegal date format for -z, --timecond (and not a file name).
Warning: Disabling time condition. See curl_getdate(3) for valid date syntax.

are generated.