SPAM

+1

But using the Wiki page can also go wrong ;D

For example the German Wiki told you to use fireplace=yes for a outdoor bbq place on the ground.

So presumably you would agree with me doing the sort of correcting mentioned in my question on the help forum?

Yes, if it is done carefully (be sure there is no other similar tag, check a few POIs, check the tag combinations etc.)

The main advantage I see it that it clears up the value lists on taginfo and it becomes easier to see which undocumented values are used and you can creat Wiki pages from them or maybe start a proposal which allows you to combine some. For example I did that with vending= and it really reduced the amount of different values and allows me to find more common tags that were worth to be documented, which hopefully encourages others to map it.

My other concern is that OSM has traditionally been against automated edits of tags.

While I share that sentiment (also don’t like imports at all), I think sometimes that stance is completely pointles: amenity=emergency_phone is still 7000 in the database, even though emergency=phone was accepted and is used 4x as often. I can’t think of a single argument against just converting those tags.

I agree that there are tags, where it is not clear and then I rather set a note in the Wiki and encourage people to fix it in their area. But for me this is not a black&white issue.

As such, I feel that I should not change tags even when they only occur a few times in our data.

For me the main thing is where do we draw the line then, because if we stick to how you and many other people see it then we are stuck with vending=news_papers forever and in 10 years will still “correct” all the people who spell it right. And if we change it, what is different from changing any other tag for a different reason?

Finally it is often easier to accept these tags without challenging them at the risk of making OSM appear to be a “British only project”.

Well, we learn BE English here in Germany and when I was in school writing “color” was just flat out wrong.

Sollte aber eigentlich sport=beach_volleyball sein…

https://en.wiktionary.org/wiki/beach_volleyball

I wish this was a default setting.

Depending on the Wiki and page that might result in a lot of “spam” and users complaining.

Imports really make me rage every time I look at this page:

http://taginfo.openstreetmap.org/reports/frequently_used_keys_without_wiki_page

Just document it. You just put more than 10k objects into the database, now you can at least take a few minutes to create a Wiki page about it. And if you just create some redirects to the import or key page and write a short description in English.

Frequently used keys without wiki page is such a great resource to find important undocumented tags, but all the imports make it really hard to find the tags, which are actually being used by the community.

I can’t click on the icons like “Website”, “Phone” etc. but I’m pretty sure it’s Firefox 29 or 30 fault, because that was when the problems started and that wasn’t the only issue (Addons, History etc. also causing trouble).

Make a tag note= with some explanation if necessary.

This can’t be emphasized enough!

Especially if you are not a native English speaker make a note in your language. There are so many tags that are used and even defined incorrectly due to translation errors. Sometimes it is easy to figure out what was meant or at least what wasn’t - like a fireplace on a picnic site, but if vending=photo is a photo booth or some kind of printer is not always that obvious. Also adding any kind of additional tags helps. For example I was able to identity a lot of vending=photo as amenity=photo_booth by the operator tag.

Nowadays if I don’t find a matching tag I pick the best matching english word for a value since the key mostly obvious - malenki

And that has resulted in a lot of wrong tags coming mostly from the Germany community… Maybe you are more carefull when finding the best matching word by checking mutiple dictionaries, wikipedia, making a image search etc. but unfortunately a lot of people aren’t.

What Germans think a fireplace is:

What a fireplace actually is:

also add it to a private collection of more or less undocumented tags.

And even if the tag isn’t approved “officially” other people can find and use or comment it. - malenki

PLEASE create a tag page. And if you just take the template and fill out key/value. Then just copy the reasoning from your table. Then people will actually be able to find how you used it, because 99% won’t find that page you linked. Also to some extent we can then assume others used it in a similar way. In addition if someone finds the page that person is more likely to expand it, compared to a non existing one.

I know documenting tags in the Wiki is boring, but the time you all take now might save someone in the future a lot of work when he has to figure out how a tag was used. Also create actual tag pages and don’t just define it on a page related to the tag, unless it is very specific (fireplace= for example is correctly defined on wilderness hut page, but not on the picnic site page - if a page existed, maybe with an image, that misunderstanding would have been obvious much sooner)

Also ich setze immer alle addr: tags in die Entrance Nodes wenn ich nach dem System arbeite, dann hat man alles zusammen. Auf dem Haus lasse ich dann nur den building tag. Scheint mir auch das gängige Prinzip zu sein; die Mapper die nur Nodes auf Häuser setzen packen da auch immer alles rein.

Und ja einfach die Node in die Häuserfront rein. Sieht man im ID Editor recht gut:

I think http://keepright.at/ also displays those, if you want to fix them outside the US.

No blaming you ;D

For the specific case of the associatedstreet relation, it also fixes the problem of finding the right street to park in front of a house when the nearest-matching-way algorythm fails.

But nearest-matching-way isn’t the equivalent to the realtion. It’s putting the add:street tag on the object.

Also the main problem as pointed out is not just consumers, but users. addr: tags on a object are easy to understand for a new mapper, relations are not.

Awesome! I think what would be even more useful would be to map all the charging stations of Tesla.

• Charging Station Locations
• Charging Guide

amenity=charging_station

Not sure how to tag the socket, but you could start with operator=Tesla Motors I guess.

https://www.mapbox.com/blog/updating-world-cup-stadiums/

This is worth submitting to Featured images.

One image alone does not show anything and you can’t really have 3 images as “featured image”. You would need to create some kind of over overlay.

The building tool drops extra nodes, i.e. it doesn’t join them on adjacent areas.

Yes, it does unless I misunderstood you.

For the given example I’d have used extrude instead anyway, but I can see other cases where it’ll be usefull.

Or just the (B)uilding tool.

delete this too please http://www.openstreetmap.org/user/willaec4/diary/21958

Looks like crap