Incorrect Street Name

I am brand new to OpenStreetMap, having just read about it this morning in a Los Angeles Times article.

I see that the street on which I live is not accurately named. (3 streets come together in a Y shape - two legs of the “Y” have one name, while the third leg has a different name. The current map inaccurately shows that the base of the Y has the same name as the right hand top leg, while it actually shares the name of the left hand top leg.)

I am sure there is an easy way to correct this, but I cannot find it. Could someone please point me in the right direction.

Welcome to OSM!

  1. Always post a permalink (lower right corner on That will make it easier for everybody to see what you’re talking about. :wink:

  2. You need to split the way and rename the wrong leg. How to do that depends on your editor. If you can’t figure out how to do that (always search in the online help and the wiki-pages first!) feel free to post more questions here.

Simplest way would be to go to zoom the map all the way in to the point where the ways diverge. Click on the Edit tab (you might need to login). Choose ‘edit with save’. Give the ways the correct name (you might need to use the scissors to cut the way with the same name into two sections). If you’re satisfied, hit save and wait a few minutes to an hour for the renderers to catch up and voila, hopefully :wink:

To use the scissors, click on the way you want to split, then click the intersection node, then click the scissors or hit X.

(By the way, if you only change the properties of ways, not nodes, it won’t automatically rerender unless you append /dirty to the URL of the tile image.)

As pointed by Lambertus, the easiest editor is the online editor available at (tab “edit”). If you don’t want to fix it yourself, you could send the permalink (the URL available on the “permalink” button on the down right side of the online map) here with the street name to fix and someone else will do it for you.

If you want to try yourself, check the Y intersection. You will have two possibilities :
1- either it’s two lines with two different names and the base of the Y is not attached to the correct “leg”
2- or it’s three lines joined at the junction but the base of the Y has the wrong name.

The case 2 is the easiest to fix : with the editor, select the base of the Y and change the name property, then save. It will take some time until the change is reflected on the online map.
The case 1 is a bit more complicated as the base of the Y is attached to the wrong “leg”. You will have to split the base of the Y and then change the name (a second option is to attach the base to the correct leg but that’s only optionnal. What is important is that the name is correct). The online editor is documented on the wiki, it’s called “Potlatch”:
(you can find it also through the online help)

The keyboard shortcuts doc is a must:

Here you see that ‘x’ will split a way. Then selecting the node at the junction with the mouse and pressing ‘x’ will split the line in two smaller lines with the same name. Then just select the base of the Y and modify its name. If you don’t split the line, you will set the same name to all legs and Y base which is not what you want.

Thank you, everyone, for the help. It worked just as you said it would, and I am now eagerly waiting for the updated map - both to see that my street is correctly named, and as confirmation that I actually did everything correctly.

You’ll be waiting a while unless you mark the tile as dirty. Right click the map tile and view image, append “/dirty” after png and hit enter, then hard-refresh the tile.

I’m not sure you should give this tip as a first level help. The tiles are normally updated if when you access them. So after 1 min or 2, use the browser to see the map, then refresh the browser cache. That’s enough most of the time. The “/dirty” is a workaround when the normal refresh process failed somewhere.

Mapnik will rerender a tile if a node has been moved. If you just change tags and values the tile won’t be renderd until the next import (once a month IIRC). The “/dirty” flag will force mapnik to rerender this image regardless if there were changes in this area or not.


Okay, that wasn’t so retrictive in the past, was it ?

I think the tiles should be refreshed for any attributes changes. Otherwise how can we convince new contributors that the difference between OSM and others is that what they fix in the map has a “real effect” and not after an hypothetical import every month or semester. The hack with /dirty is a dirty answer. If the “refresh on demand” is the only solution because of some hardware capacities, then we should provide a button or anything other than the current answer.

Pieren: patches welcome :wink:

osm2pgsql -e 16-16 -o expired_tiles.txt & render_expired --touch-from=11 < expired_tiles.txt

Or something of that form.

Yes, the osm2pgsql based expiry compared to the ruby tile expiry has other tradeoffs too, so it isn’t as clear as to witch to use, but that specific problem of only way-tag changes should be solved by the osm2pgsql solution. Perhaps it is worth revisiting and reevaluating the trades between the two.

@pierren: As far as I know, it has always been the case with the minutely diffs or at least nothing has changed with respect to this behaviour.

@NE2, PHersion, pieren: Correcting my self a bit: The current expiry code (which I believe is at does take ways into account, just not relations. So changing tags on a way does correctly expire the appropriate tiles and there shouldn’t be a necessity to use the “/dirty” hack (It is a hack that was afaik introduced to test stylesheet changes by the stylesheet developers and thus shouldn’t really be needed by anyone else. Which is why it isn’t publicised widely). So as long as you don’t use relations, your fine.

No, changing tags on a way does not expire the tiles. I know this from experience.

Indeed, you are right, it did not expire the tiles on way-tag changes. But that was a bug introduced a while ago and should now be fixed (and soon deployed). So thanks for reporting.

If I’m not mistaken, this was deployed during the recent unscheduled maintenance. Thanks.

Thanks. I was not sure it this behaviour was a bug or a feature since tile expiration policy has to balance rendering load and data updates. I can see how this can be a hard task to find the best compromise.