OpenStreetMap

kocio's diary

Recent diary entries

Planned rendering changes of protected areas

Posted by kocio on 3 December 2017 in English (English)

I'd like to change the rendering of protected areas on osm-carto (the style which is used as a default map layer on the main OSM.org website). That proved to be a complex problem, however thanks to the comments from the community on the issue tracker and Talk list I see the general plan what to do. This entry is just a slightly edited message I sent to the list.

screenshot-2017-12-3 openstreetmap Exhibit A: Adirondack Park disaster...

TL;DR summary: I think that for now we should render all the existing tags, but make some of them appear earlier to encourage smooth migration to a more precise scheme.

General findings

  1. As I currently understand it, nature reserve is always a type of protected area, to begin with.

    We were talking on osm-carto ticket with some people about private reserves and even when someone told me "it's not about protection!" this term was used immediately in the same sentence (or in the next one). =} I guess they meant "it's voluntary and not formal", but still it's intended as a protection of nature, so it's just a special, weak type of protection.

  2. The problem seems to be for a mapper to be more precise, since a typical survey can reveal a sign with a name "XYZ nature reserve". However this is not about just a name.

    Boundaries are not visible on the ground easily, so a mapper who draw them has to use some other sources and I believe there are more informations available. Otherwise the area shape is probably not verifiable, which would be bad anyway. And I think all of them are areas, not the points (node would mean probably "here is the protection area, but exact shape is not shown at the moment"), so boundary is also a sure thing.

  3. The name tag leisure=nature_reserve states that it's about leisure (which of course might be for a given object), but it's always about protection. So even if the value has merits, this key assumption is wrong in general and misses more important property (boundary=nature_reserve has only 35 uses).

  4. Another problem is lack of coherent definition of protection (other than numbers) and lack of high-level classes.

    The numbers seem to be derived from IUCN scheme, but wider: only categories 1-6 are IUCN-based and I don't know about the rest.

    Especially class 7 is interesting for us: "nature-feature area: similar to 4. but without IUCN-level.", so i guess it's for all the non-IUCN classified nature reserves. Probably most of the time this should be clear from the boundary shape source.

    It would be good to have more standardized subtags for common features:

    • "nature" - protection_object=* is the same mess as numbers, when talking about hierarchy levels, so maybe some subtag like "nature_reserve=yes" would be useful
    • "private" owner type (not the access type) - governance_type=private_landowner would be great (if really used...)
    • "voluntary" - but that might be clear from the lack of government or international authorities influence

Tagging solutions

In summary, we have 3 popular but overlapping types now:

  1. leisure=nature_reserve (77 264)
  2. boundary=national_park (16 583)
  3. boundary=protected_area (62 016)

Their general properties and relations:

  1. has a wrong key, but nice value name, and is a subtype of 3.
  2. has a nice value name and a proper key, it's also subtype of 3.
  3. is very broad with precise, but not so common name, it also has subtypes, which are useful for official classification, but are not clear for all the other types of conservation

Therefore I would advice to:

  1. Discourage leisure=nature_reserve and make it a subtag of boundary=protected_area (if needed, otherwise just use a protect_class=7 or other class if known), like:

    • nature_reserve=yes - 2 uses
    • protected_area=nature_reserve - 22 uses
    • protected_area=nature - 61 uses
  2. Drop boundary=national_park, since it's easy to identify them all and they are equivalent for boundary=protected_area + protect_class=2 anyway.

Rendering proposition

For rendering I would show all of them as currently, just using different zoom levels, starting from z8 currently (this might change in the future, of course):

  • z8+: national parks and wilderness areas (both are big by definition)
  • z9+: important natural protected areas (class 1-6, with hatched 1a probably)
  • z10+: other natural protected areas (class 7, maybe also 12, 14 and 97-99)
  • z11+: protected areas without class (if we know they're nature related) and leisure=nature_reserve

This is just a rough sketch, however it has some nice properties:

  • all the existing schemes are visible (boundary=national_park can be dropped later)
  • more important objects are rendered first
  • less precise tagging is rendered later

Another important factor might be their size (so for example small national parks wouldn't be shown on z8) and a name (when the name is not tagged, push them later), but it needs a lot of worldwide testing.

Usage stats

taghistory 6 taghistory 7 (class 4 is the most popular) taghistory 8

OpenStreetMap Carto release v4.5.0

Posted by kocio on 17 November 2017 in English (English)

Dear all,

Today, v4.5.0 of the openstreetmap-carto stylesheet (the default stylesheet on openstreetmap.org) has been released.

Changes include:

Major changes

  • Cleaning up low zoom levels (z5-z7):
    • Rendering roads from z6 instead of z5
    • Rendering national parks from z8 instead of z7
    • Rendering railways from z8 instead of z7
  • Changing parking color from yellow to gray

Changes

  • Unified rendering of leisure=fitness_station and leisure=fitness_centre
  • Rendering of military=bunker
  • Rendering all station buildings as major buildings
  • Text wrapping for station labels
  • Changing windmill color from amenity brown to man_made gray
  • Some other documentation and code changes

Thanks to all the contributors for this release.

For a full list of commits, see https://github.com/gravitystorm/openstreetmap-carto/compare/v4.4.0...v4.5.0

As always, we welcome any bug reports at https://github.com/gravitystorm/openstreetmap-carto/issues

OpenStreetMap Carto release v4.4.0

Posted by kocio on 20 October 2017 in English (English)

Dear all,

Today, v4.4.0 of the openstreetmap-carto stylesheet (the default stylesheet on openstreetmap.org) has been released.

Changes include:

Major changes

  • Rendering inland water areas and labels from z0
  • Rendering island and islet labels earlier

Changes

  • Rendering of amenity=marketplace
  • Rendering of landuse=religious
  • Rendering shop=pastry like shop=confectionery
  • Rendering of addr:unit
  • Rendering natural=bare_rock earlier
  • Rendering elevation also on polygon alpine_hut and shelter
  • Introducing Noto Sans Arabic
  • Rendering icon for slipway ways
  • Better minimal distance between housenumbers
  • Moving aeroways to their own layer
  • Creating amenity POI categories
  • Some other documentation and code cleaning

Thanks to all the contributors for this release, including tpikonen, a new contributor.

For a full list of commits, see https://github.com/gravitystorm/openstreetmap-carto/compare/v4.3.0...v4.4.0

As always, we welcome any bug reports at https://github.com/gravitystorm/openstreetmap-carto/issues

OpenStreetMap Carto release v4.2.0

Posted by kocio on 25 August 2017 in English (English)

Dear all,

Today, v4.2.0 of the openstreetmap-carto stylesheet (the default stylesheet on openstreetmap.org) has been released.

Changes include:

Major changes

  • Water color and default water text color are changed to be more visible
  • Medium zoom level (z8-z12) rework:
    • Landuses colors are faded and some of them are visible earlier
    • Most of the man related landuses are combined into one color and more visible
    • More important roads are better legible

Changes

  • Leaf type rendering in woods and forests
  • Cemetery symbols are not so dense now and Muslim cemetery has its own symbol
  • Rendering of amenity=ferry_terminal
  • Plaque rendering is now different and moved to z19
  • Rendering railway labels
  • Smaller line spaces in labels
  • Junction names on areas
  • Area color for railway=station is the same as for railways
  • Database performance tuning available for Docker
  • Different patterns and all remaining icons moved to SVG
  • Some documentation and code cleaning

Thanks to all the contributors for this release, including littlebtc and giggls, new contributors. Special thanks for rrzefox for testing major changes on his server.

For a full list of commits, see https://github.com/gravitystorm/openstreetmap-carto/compare/v4.1.0...v4.2.0

As always, we welcome any bug reports at https://github.com/gravitystorm/openstreetmap-carto/issues.

OpenStreetMap Carto release v4.1.0

Posted by kocio on 30 July 2017 in English (English)

Dear all,

Today, v4.1.0 of the openstreetmap-carto stylesheet (the default stylesheet on openstreetmap.org) has been released and rolled out to the openstreetmap.org servers. It might take a couple of days before all tiles show the new rendering.

Changes include

  • Malls are no longer rendered as dots (bug fix)
  • Special icon for shop=tyres
  • Airports rendering changes: removing clutter on z10 and moving name labels under the icon
  • Switching forest, scrub and quarry patterns to SVG

In this release we're also introducing Docker-based development environment, which makes it much easier to preview rendering changes before they are deployed on the servers.

Be warned that there's a change in our release plans: compatibility with v3.x series is no longer maintained from now on, so database reload is needed to keep up with current style changes. Some of them can be however backported, especially if you're using hstore-enabled database already.

Thanks to all the contributors for this release. Special thanks go to MaestroGlanz and daganzdaanda for a new icon.

For a full list of commits, see https://github.com/gravitystorm/openstreetmap-carto/compare/v4.0.0...v4.1.0

As always, we welcome any bug reports at https://github.com/gravitystorm/openstreetmap-carto/issues.

OpenStreetMap Carto release v2.45.1

Posted by kocio on 3 December 2016 in English (English)

Dear all,

Today, v2.45.1 of the openstreetmap-carto stylesheet (the default stylesheet on openstreetmap.org) has been released and rolled out to the openstreetmap.org servers. It might take a couple of days before all tiles show the new rendering.

This is a bugfix release restoring two icons:

  • memorial
  • tobacco shop

Thanks to all the contributors for this release.

For a full list of commits, see https://github.com/gravitystorm/openstreetmap-carto/compare/v2.45.0...v2.45.1

As always, we welcome any bug reports at https://github.com/gravitystorm/openstreetmap-carto/issues.

OpenStreetMap Carto release v2.45.0

Posted by kocio on 28 November 2016 in English (English)

Dear all,

Today, v2.45.0 of the openstreetmap-carto stylesheet (the default stylesheet on openstreetmap.org) has been released.

Changes include:

  • Rendering all shops without a specific icon as a dot, not just a whitelist
  • Scrub pattern change to random
  • Changing pitch and track color
  • Railway stations rendering as major buildings
  • Rendering the name of man_made=bridge inside the polygon
  • Documentation updates (including cartography design goals and icon design guidelines)
  • Icons general code cleaning
  • Various bug fixes

Thanks to all the contributors for this release, including micahcochran, a new contributor.

For a full list of commits, see https://github.com/gravitystorm/openstreetmap-carto/compare/v2.44.1...v2.45.0

As always, we welcome any bug reports at https://github.com/gravitystorm/openstreetmap-carto/issues.

You may also like to know that this release is the first with 3 new project maintainers on board. Please be aware that we're going to drop some legacy dependencies soon (like Mapnik 2), so we're approaching a big version change.

One Does Not Simply Walk into Mordor...

Posted by kocio on 4 October 2016 in English (English)