Openstreetmap Update Frequency

[Alarico Boyett]

OpenStreetMapitself only provides global "planet files" in the .osm.pbf format. Regional extracts in that format are provided as a service by third parties. Update frequency of these files is, therefore, dependent on which provider you plan to get these files from.

I can pull the building data from the Nominatim API but it does not indicate when that footprint was identified. Further, I checked the OSM buildings wiki, but did not see any info on an update schedule or frequency.

Despite its name, OpenStreetMap is a collaborative geodatabase (or geodata collection) first, and a map only second (if at all). Anyone with an OpenStreetMap account can edit the data. Live. That is, changes made that way are reflected in the database right away, without having to go though any review or approval process first. Kinda like edits on Wikipedia, but without protected articles.

I'm unsure whether Nominatim works directly on the OpenStreetMap database or whether it (like many other OpenStreetMap-internal secondary services) consumes the minutely diffs of the OpenStreetMap dataset as they become available and processes them to update its indices. In either case, while there might be a slight delay (i.e. lag), there should be almost no perceivable "update cycle". Changes should become visible shortly after having been made in the main OpenStreetMap database.

I've found older answers below, but is there anything more current on the Mapbox/OSM update frequency? EXAMPLE: a major zoo wants to change and update their exhibit names, POI labels, pathways, and also use more descriptive tags for some elements (e.g. to style non-public buildings differently in Mapbox using OSM's "buiding=service" tag instead of "building=yes"). These changes by the zoo will help everyone have an updated zoo campus data set!

The time it takes for OSM changes to populate in the Mapbox basemap depends on several factors. Typically you can expect to see changes within a couple of weeks, though the process can take a bit longer due to the fact that we have a data team dedicated to quality assurance as outlined in our documentation here.

As discussed in more detail in our map data documentation, our map data does not come exclusively from OpenStreetMap. In general, if it has been more than a several weeks since you made a significant set of changes to OpenStreetMap which have not been propagated to the Mapbox basemap, you can reach out to us with the relevant changeset ID so that we can look into applying these updates. Unless the requested changes relate to urgent matters (such as correcting map vandalism), direct requests to bypass changes any early than this will typically be asked to wait a bit longer to maintain the integrity of our data validation pipeline.

Is this limitation still true?

Would openstreetmap.org really charge for HA frontend clients (browsers and companion apps) to download tiles on demand (only when a person is looking at maps)? Or would they think the HA backend would need persistent and recurring API calls to keep the maps up to date?

OpenStreetMap (OSM) is the most successful crowdsourced geographic information project to date [1]. It was initiated in 2004 in response to the mainstream presence of legal or technical restrictions on available maps, with the ultimate goal of creating and distributing free geographic data for the whole world [2]. As a matter of fact, the OSM geospatial database is distributed under the open access Open Database License (ODbL) [3], allowing freely using, modifying and building upon the database under non-restrictive conditions such as providing attribution to the OSM contributors. The relatively easy way - even for people with no background in geography or computer science - to create OSM data has attracted so far an ever increasing number of contributors to the project. At the time of writing (June 2019), the project counts about 5.5 million registered users [4], while the number of contributors, i.e. the users who have made at least one edit to the database, has exceeded the threshold of 1 million only in March 2018 [5]. In turn, a rich ecosystem of software tools, services and applications allows a wide number of developers, humanitarian operators, industry and governmental actors to exploit OSM data on a daily basis and for a variety of purposes [6].

According to the simplified OSM conceptual data model shown in Fig. 1, there are four main data types. Three of them, namely nodes, ways and relations, include a geometric component. A node, defined by a latitude and a longitude, is used to represent standalone point features such as trees, traffic lights or points of interests, and consists of geographic coordinates (latitude and longitude). A way is an ordered list of between 2 and 2000 node references, which can represent both linear features (polylines) such as roads and rivers, and areal features (polygons) such as buildings and land use areas. The limit of 2000 nodes per way was established in 2009 with the changes from version 0.5 to 0.6 of the OSM API [28], therefore ways created earlier might reference any number of nodes. A relation is a special structure used to represent polylines or polygons of more than 2000 nodes and relationships between zero or more nodes, ways and other relations [29, 30]. An example of relation is a bus route, which links the ways of the roads traveled by the bus and the nodes of the bus stops. Another common example is a polygon with holes, e.g. a building with an inner courtyard, which links the outer way of the building outline and the inner way of the courtyard. Each single OSM node, way and relation has an id number that uniquely identifies it. For example, the node accessible at (where 5207201516 is the node id) currently represents the Notting Hill subway station in London; similarly, the way accessible at , (where 32965412 is the way id) currently represents the Statue of Liberty in New York; and the relation accessible at (where 7515426 is the relation id) currently represents the Louvre Museum in Paris. It is worth clarifying that the ids of nodes, ways and relations cannot be considered as permanent ids of real-world features [31]. In other words, a real-world feature which is currently represented by e.g. a node might in the future be represented by another node or by a way or a relation. As an example, the Louvre Museum was in the past represented by another relation with id 3262297 and might be represented by new relations in the future. This fundamental difference between the permanent ids of real-world features and the OSM ids of nodes, ways and relations should be properly considered when analyzing OSM history data.

Tags are the fourth data type of the OSM data model (see Fig. 1) and specify the attributes of real-world features represented by nodes, ways and relations. Tags consist of key-value pairs, where each key specifies a property and each value defines the value of the node, way or relation for that property [32]. Nodes, ways and relations can have from a minimum of zero tags (e.g. in the case of nodes solely referenced by OSM ways) up to any number of tags. In the following, the term OSM object is used to indicate a node, way or relation having at least one tag; thus, with few exceptions, OSM objects represent real-world features. For example, the main tag associated to the way of the Statue of Liberty in New York is artwork_type=statue, where artwork_type is the key and statue the value. This tag is accompanied by many other tags defining additional properties, such as name=Statue of Liberty, indicating the name of the statue; tourism=attraction, meaning that the Statue of Liberty is a tourism attraction; and wikipedia=en:Statue of Liberty, linking the corresponding page in the English Wikipedia. The OSM Map Features wiki page [33], together with all the wiki pages reachable from it, lists the official tags to be used for labelling real-world objects. This reference list of tags was also termed folksonomy (i.e. a crowdsourced taxonomy), since it represents the evolving product of the negotiation process between OSM contributors [34]. The popular taginfo service [35] provides statistics about the use of OSM tags and their combination with other tags.

Each time a contributor performs an editing session and saves a group of changes to the OSM database, e.g. after creating, deleting and/or modifying one or more OSM nodes, ways and/or relations, in terms of their geometry and/or tags, a so-called changeset is created [36]. As mentioned above, each changeset - which is associated to one single contributor - is also stored in the OSM database through the association of a unique and persistent id. For example, at the time of writing (June 2019), the latest changeset including edits to the way of the Statue of Liberty is accessible at , where 68221957 is the changeset id. Since each changeset carries information about the edits made to the OSM database (i.e. which nodes, ways, relations and/or tags were added, modified and/or deleted, and how), the contributor who made the edits, and the timestamp of the edits, the availability of all the changesets ensures the availability of the whole history of each OSM node, way and relation, and - on a larger scale - of the full OSM database.

OSM history has been investigated by many researchers to achieve a number of objectives. Quality assessment is by far the most frequently occurring. Ciepłuch et al. [46] developed a set of quality indicators for OSM which also considered the history and profiling of contributors. Similarly, the intrinsic methods developed by Keler and de Groot [47] and Muttaqien et al. [48] modelled the quality of OSM objects based on historical information such as the number of contributors and the number of versions. The history of OSM objects and OSM contributors was exploited by Mooney and Corcoran [49] to analyse contributor patterns in seven cities around the world. Grchenig et al. [50] developed an intrinsic approach for the assessment of OSM completeness through the analysis of community contributions over time. A novel approach for improving the positional accuracy and completeness of the OSM road network using the OSM history was proposed by Nasiri et al. [51]. Barron et al. [52] developed a comprehensive framework for OSM intrinsic quality assessment, which includes more than 25 methods and indicators exclusively based on OSM history.

3a8082e126