Sorry for my ignorance but I am a newbie on here...

Essentially I was wondering how to make my map changes live. Have clicked saved changes and can see the amendments in my edit view everytime I log back in but they are still not changed on the public view? Is this because they are awaiting confirmation from an administrator or something?

Note I made some of the changes in Potlatch a few days ago so have given it time :-) An example of one is here http://www.openstreetmap.org/browse/changeset/8386635


asked 12 Jun '11, 20:01

stokesd3's gravatar image

accept rate: 0%

edited 12 Jun '11, 20:09

Changes go live immediately after you hit the save button. There is no approval or moderation process.

However, due to resource constraints, not all views and applications update immediately. Seeing your changes outside of the Editors, (or if you download the data directly from the API) can take anything from a couple of minutes, to days (or even weeks to months in some offline products using OpenStreetMap such as some navigation devices). It depends on the Application or Map using the OpenStreetMap data. (Many of them are operated and maintained by independent entities, so OpenStreetMap has no influence on how often they update the data)

The main (mapnik) map view on OpenStreetMap.org should typically update in a couple of minutes to hours. A more detailed description of the process can be found at http://help.openstreetmap.org/questions/178/how-often-does-the-main-mapnik-map-get-updated

permanent link

answered 12 Jun '11, 20:17

apmon's gravatar image

accept rate: 20%

Thanks for the quick response will just hold tight then ;-)

(12 Jun '11, 20:43) stokesd3

I suspect that your browser is cacheing the map tiles. Not only had the change been made, but I did not see the old name. It's always a good idea to force a refresh of tiles in the browser if the map has apparently not updated after a few hours.

permanent link

answered 12 Jun '11, 20:45

SK53's gravatar image

SK53 ♦
accept rate: 20%

Actually, not all changes will make tiles updated immediately. The tile may be marked for updating which will occur in a short time after, but if there are multiple changes in the short time, only the first update will be updated immediately, other updates in the OSM data will just mark the tile to be upated MUCH later (for now I've seen that this is about 24 hours, to limit the workload, individual tiles are not updated too frequently on tile servers)

(01 Jun '12, 00:20) Verdy_p

So if you save your work to the OSM database in several successive steps, only the first save will be rendered if you try to load that tile to see the result. Within the next minutes if you add more data, and attempt to refresh the image (even if your browser cache is empty) you'll get the same time for several hours and new data updates will not be immediately visible

(01 Jun '12, 00:20) Verdy_p

Note that the limitation of frequency of refreshes performed on tile servers are dependant of the configuration of each tile server and of its usage: stats will very over time, and between the default Mapnik server and other servers like Mapquest or specialized tile servers for analysis tools.

(01 Jun '12, 00:22) Verdy_p

I wonder why you vote negatively when speaking about true unsolved problems. May be that's because it's not a direct answer to the initial question but it is about the same symptom: the persistance of cached tiles in client applications (web browser, or editors like JOSM) is certainly a problem and we should NEVER need to constantly empty the client cache, because this has a negative impact on servers due to excessive reloads.

Please consider that the correct handling of the client cache (both in clients, but also servers in their responses about the cachability of what they send, and then the correct handling of these caching parameters in clients like JOSM and web browsers), is essential for the whole project, (1) to preserve resources on servers, to avoid these questions like above about completely outdated info rendered in clients.

This was already a problem when openstreetmap.org used OpenLayers to display tiles, but this is still a problem now that it uses Leaflet: theses two Javascript frameworks are still not implementing correctly their client cache strategy, and this is also true in JOSM whose image cache is NEVER emptied (no caching policies implemented at all in JOSM, whose cache grows demesurately without limit, up to the point that it becomes even slower to access the local cache of the client, than to perform a new remote request for reloading all tiles needed for the current display).

This is not just a negative comment, but really a suggestion for improvement about what is really a problem.

permanent link

answered 26 Nov '12, 21:39

Verdy_p's gravatar image

accept rate: 0%


Yes but given the existing Tile usage policy, the default OSM tile server will set cachability of tiles to 7 days (and users should honor this policy, otherwise you risk being blocked for excessive bandwidth usage when downloading rendered tile bitmaps).

Probably 7 days is a bit excessive, notably for areas in small tiles (high resolution : zoom >= 15) that we have been working on ourself, and that we should be able to view rendered more rapidly.

But when working on large areas (such as adding rivers or refining the limits of their bank, lakes, new long distance roads, we easily exceed the details. One possibility would be to render tiles according to the size of the modification group, so that it is covered by eanough tiles, even if subtiles for higher resolutions are delayed.

This is a problem for mapping large zones that are very broadly defined, and adding mots of details, in a progressive way : we start by large zones, adding core elements, then the whole zone gets locked (cannot load map data from server, for several hours or days, before we get allowed to draw smaler details).

We can avoid it by not defining too many details at low resolution, but still splitting routes into fragments that can be loaded separately when working for smaller details : we won't lock too many tiles for too long; but if this happens, we can still suspend the work and work on a nearby zone that is still not locked.

Your journal may help track those areas that you have still not finished but that get temporarily blocked.

But another problem (which causes too much work for tile renderers) is caused by bots that are constantly "spreading" updates throughout the world, instead of working in smaller subzones (finding modified nodes or ways that have an intersection with a small rectangle, and finding all fixes to apply there at the same time): the modification groups made by bots are currently much too large, and I think they should group their updates better, to avoid constantly and repeatedly adding work on so many tiles that will bet updated multiple times or delayed.

permanent link

answered 13 Jun '11, 01:18

Verdy_p's gravatar image

accept rate: 0%


Note: JOSM is effectively caching tiles, but still does not purge automatically the tiles that whose lifetime has expired since long. I frequently see its cache directory growing to hundreds of thousands files (two files per tile, a .png for the image itself, and a .tag file for its HTTP metadata). It takes a considerable time for the filesystem to delete them and rebuild the directory index JOSM cache is definitely broken and should work like browser caches. As it grows in size, accessing to the local directory index to find if a tile is already present there takes longer time that just reloading the tile from the Internet ! And anyway, when the tile is there, most of the time it is outdated since long and will need to be reloaded again. All files in the JOSM tile cache should expire after about one week by default. And this directory should be splitted in several subdirectories (like in Internet browsers) to limit the constant reorganisation of its index by the filesystem. As well we should be able to set its maximum total size (1 or 2 Gigabytes should be largely enough ! (A cache growing about 50 Giga is full of junk data and wastes previous space on the filesystem, notably if it is on the same volume as the default OS volume) The JOSM tile cache has the very bad effect that it rapidly and heavily fragments the MFT of the NTFS filesystem: this slows dows the WHOLE system in all applications. We should not need to have to clean this folder manually as it has reached a relly too large volume.

permanent link

answered 28 May '12, 08:24

Verdy_p's gravatar image

accept rate: 0%

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 12 Jun '11, 20:01

question was seen: 7,270 times

last updated: 26 Nov '12, 21:39

powered by OSQA