How to make saved changes live?

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

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.

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.

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.

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.