30.03.2023 | Frederik Ramm
We’ve started making vector tile packages available on our download server at download.geofabrik.de. At the moment you’ll find a .tar.gz
file with vector tiles typically on the same level where you’d also find shape files — i.e. we don’t give you a package for all of Europe, but for individual European countries, and we don’t have a package for all of the US, but for individual states and so on.
These vector tiles use our Shortbread schema, and we create them with the excellent open source Tilemaker software. For suitable MapLibre vector styles, have a look at the VersaTiles repository.
This is supposed to be an experiment and we don’t yet make any promises about the structure and update frequency of this offer. We’re happy to hear your ideas though. At present, the .tar.gz files simply contain all vector tiles for the region as simple files (which are themselves .gz compressed so you might have to instruct your web server to add the appropriate encoding headers).
Like everything else on our download server, these tiles are made from OpenStreetMap data and come under Open Database License 1.0 with an OpenStreetMap attribution requirement.
29.03.2023 | Frederik Ramm
This weekend we’ll implement a change that affects the handling of boundary-straddling multipolygons in our OSM extracts. (See this 2017 blog article for some background.)
We’ll stop completing cross-border multipolygons except landuse polygons and a hand-picked list of natural polygons (e.g. water, grassland, wetland).
This has become necessary because of the propensity of OSM mappers to create huge multipolygons like “the Iberian penisula” or “the Alps”, artifacts that not only unnecessarily increase the data volume of any given PBF but also have unexpected consequences – for example, for a while anyone processing the rivers of the Switzerland extract would find a stretch of the River Danube in Vienna, because it happened to be part of the outline of the “Alps” multipolygon.
We hope that by restricting multipolygon completion to landuse and a small list of natural polygons we’ll be able to curb these unexpected side effects of polygon completion.
As a result of this change, the .osc.gz files generated on Friday night will contain “delete” operations for ways and nodes that were heretofore contained in the extracts due to multipolygon completion, but are not any longer.
Some data extracts, notably those for small islands or archipelagos, will shrink by more than 10%, but for most extracts the size will not be affected dramatically.
20.09.2022 | Michael Reichert
A few days ago we have added a couple of new road-related layers to our OSM Inspector.
highway=*
In the past, highway=*
was sometimes added to route relations (type=route
+ route=road
). This is not in line with current tagging standards any more, and can even lead to duplicated line geometries when importing OSM data into PostgreSQL with Osm2pgsql.
The layer shows these old-style relations in dark red.
Not all relations with highway=*
are a problem – for example, pedestrian areas and rest areas mapped as multipolygons relations (type=multipolygon
) are totally fine and hence not shown as errors. This exception applies to multipolygons with a highway=*
value of pedestrian
, footway
, service
, rest_area
or services
.
Multipolygon relations with other highway=*
values are likely candidates for changing to area:highway=*
. See the OSM Wiki page aboutarea:highway=*
for details about mapping roads as areas.
Even though OSM records “facts on the ground” and not historic or future data, it is generally accepted to map roads and paths which are not in use any more (or are not completed yet).
In recent years, the so-called Lifecycle Tagging Schema was adopted by many mappers and is used to tag feature which are not actively used any more, are (partially) removed or expected to be created in the future. The schema works by adding the lifecycle state as a colon-separated prefix to main key of the feature. If a road tagged as highway=secondary
becomes disused, the tag is changed to disused:highway=secondary
. Other tags of the feature remain unchanged.
(An older, but equally valid, way of describing lifecycle states is to put highway=construction
together with construction=secondary
. The new OSMI layers treat both methods in the same way.)
The following lifecycle sates are in use:
razed
or dismantled
or removed
(note that the use of these prefixes is often subject to discussion and may be discouraged in your region)abandoned
disused
construction
proposed
(note that mapping proposed features may contravene the on-the-ground mapping rule and may be discouraged in your region)OSM Inspector now has four new layers displaying all linear highway=*
features which are abandoned, disused, under construction, or proposed.
Two new layers render frequent mapping mistakes:
highway=construction
without a construction=*
tag), this is considered an error. Sometimes the correct tag value can be discovered from the object history; otherwise a survey is required.Please use quality assurance tools responsibly. They are often wrong. And even when they point you to poor mapping, simply repairing the mistakes is not a good choice. Poor mapping is often a sign of lack of knowledge (e.g. newbies), bad intentions, or mechanical edits, organised editing or imports gone wrong. It is worth having a look at an object’s history and other edits by the mappers involved to avoid simply “cleaning” the map and therefore possibly hiding a systemic issue. When contacting others about mistakes they have made, always remember that we all make mistakes and we can only become better by supporting each other.
1.07.2022 | Frederik Ramm
We have made a few small improvements to the OSM Inspector user interface, providing better responsiveness to different display sizes, using tiled WMS access for better performance, and improving the presentation of feature detail information.
Give it a spin at https://tools.geofabrik.de/osmi and tell us what you think!
5.09.2021 | Frederik Ramm
In the past night, a problem on the download server caused us to publish truncated data extracts for the following countries:
In Africa:
In Asia:
The extracts have been reset to yesterday’s version but if you have downloaded an extract between 2021-09-05 01:00 UTC and 2021-09-05 10:00 UTC then you have got a truncated file. Also, if you have an automatic process that loads daily updates, and you have loaded and processed an update for any of these countries in that timespan, you now have a truncated database and need to re-import data. (This will not automatically fix itself with the next update.)
If you have not loaded updates during this timespan, or if you have loaded updates but not for the countries mentioned, then you are not affected. (You are also not affected if you have used the full Africa or Asia files, these were correct.)