Nein. Wir mappen nicht für den Renderer. Wenn das in anderen Gebieten auch falsch gemappt ist, dann gehören die auch gefixt. Wenn ein Ding keinen Namen hat, dann mappen wir auch keinen. Dass leider sehr viele sich nicht an unsere Grundwerte halten (osm.wiki/How_We_Map), ist leider richtig, aber deshalb muss man das nicht nachmachen.

Außerdem wird der Name der Lifte sehr wohl auch auf dem Standard-Layer gerendert, wenn man ein bisschen hineinzoomt. Dass das nicht so prominent wie vorher ist, sehe ich auf einer allgemeinen (und nicht Wintersport-) Karte eher als positiv (aber irrelevant für die grundsätzliche Entscheidung).

Hier ändert sich ja häufig etwas, aber bicycle=no stimmt für den Teil nordwestliche der Kreuzung südlich der Stadtwildnis 100%ig nicht (das habe ich soeben korrigiert) und auch für den Weg von der Vorgartenstraße weg ist das mMn falsch. Letzte Woche war der allgemein gesperrt, wird aber vmtl. für Fußgänger und Radfahrende in absehbarer Zeit wieder geöffnet oder?

Da wäre es am besten gewesen, du hättest das disused ganz gelöscht, da ja klar ist, dass Objekte "in use" sind, wenn nicht explizit was anderes angegeben ist.

Das Problem ist nicht, dass die Stationen (in der Realität) keine Namen haben, sondern, dass sie in OSM falsche eingetragen haben (und zwar die Namen der Lifte). In dem Link von dir stehen aber nur die Namen der Lifte nicht die der Stationen. Weißt du, ob die sicher alle keine Namen haben?

Zu den Gärten muss man vl. dazu sagen, dass das eigentlich nie für Privat-Gärten gedacht war - deshalb auch der leisure-Schüssel. Da ging es ursprünglich um öffentliche Gärten wie sie in manchen Parks vorkommen. In der Gegend würde wohl (Teile des) Mirabellgarten am ehesten diesem Schema entsprechen.

Auf Basis dessen haben Einige angefangen auch nicht öffentliche Gärten damit zu mappen, was viele Mapper aber als Overkill sehen. Es macht jedenfalls keinen Sinn kleine 10m²-Inselchen als solches zu taggen. Wenn du Privatgärten unbedingt mappen willst, dann setze bitte auf jeden Fall zusätzlich garden:type=residential und access=private, damit das klar und maschinenlesbar von anderen unterschieden werden kann.

Ganz allgemein ist es nicht im Interesse von OSM jeden cm² mit einer detaillierten Landuse zu versehen, nur weil man am Luftbild unterschiedliche Flächen wahrnehmen kann. Es ist z.B. vollkommen OK Gärten, Grasflächen etc. innerhalb von Siedlungsgebieten nicht explizit zu taggen - sie sind genau so wie Häuser und Straßen Teil des landuse=residential. Das sieht auf Mapnik vl. ganz nett aus (auch das ist sehr subjektiv), aber es hat im Grunde nur sehr wenig Informationsgehalt bei gleichzeitig hohem Arbeitsaufwand für Mensch und Maschine. ;)

Da ich in Hintersee ein bisschen herum geschaut habe, noch ein bisschen anderes Feedback für dich:

osm.org/way/966617210, osm.org/way/966875624 da gehört der 2. Name jeweils in alt_name (o.ä.)

osm.org/node/8942885578 wäre eher was für natural=gorge - als way nicht node.

Bei osm.org/node/8241288681 habe ich Zweifel am Namen; beim Pfarramt (osm.org/way/144264482) und Gemeindezentrum (osm.org/way/289394999), Feuerwehr (osm.org/way/144264467) hab ich keine - dass sie nicht stimmen. Wenn diese Objekte Namen haben, dann ist sicherlich der Ort(steil) ein Teil davon. Im Zweifelsfall (d.h. ohne eindeutige Quelle) lieber keinen Namen setzen. Wenn das Objekt durch andere Tags eh schon beschrieben ist, findet man es auch. Und wenn nicht, ist description oft der bessere Tag für so etwas.

LG

Wie kommt man auf die Idee disused=no zu taggen, wenn man das disused=yes selbst gesetzt hat? :)

Was mir aber hier störender aufgefallen ist, sind die Namen der Stationen. Das ist zwar nicht auf deinem Mist gewachsen, aber da du ja wohl aus der Gegend bist, wäre es toll, wenn du da mal drüber gehen könntest. Ich nehme an, die meisten der Stationen haben gar keinen echten Namen oder?

PS: Änderungskommentare wie "x" sind nicht besonders kollegial. Der Sinn von diesen Texten ist, dass andere bei Changesets leicht sehen können, was jemand geändert hat - so wie bei diesem hier.

Absolutely, thus our goal should be to make it usable without misusing the name tag with invented values. BTW using the same name on the subrelations is not what I proposed - that would be equally wrong - arguably even more so. However, your argument applies to relations without a name (or unique ref) as well - because osm.org does not handle this properly yet, e.g., the Austrian legs after my change yesterday (that fixed lots of actual errors but also moved all names to descriptions) osm.org/relation/2764556
These breakages are exactly why having a test balloon like this is helpful (even though it temporarily breaks things - especially consistency).

How does osm.org/relation/8130282 not violate osm.wiki/Relations/Relations_are_not_Categories ?
It also seems to not be maintained at all. I'd rather remove it. What do you think?

These are not proper names as they are not on the ground or anywhere else. This directly violates two or our four core principles: truthfulness and verifiability (cf. osm.wiki/How_We_Map). We invented them to ease their handling and they are arguably useful to the user (at least from the country level up) - but they are not names. So they either belong into the note tag (if they are deemed useful only to mappers) or description (if deemed useful to end users). At the end, all partitioning of these EV relations in OSM does not reflect how the ECF has split them up into legs. So this whole construction is really just to make it easier for mappers.

For public transport routes there was a similar problem where people put operators, origins, destinations, references etc. into their names but this has been resolved by moving them to proper tags. I am thinking about proposing something similar for international routes.

You are absolutely right about inconsistency. However, that is unfortunately the way OSM progresses as their is no well-established process to coordinate changes that correct wide-spread problematic tagging. We have to start somewhere. On the positive side this reveals problems in applications on a smaller scope first and let's us improve editors and renderers. This is also true here and the first change for improvements is already on the way into JOSM to auto-generate identifiers for relations within the GUI based on the description if there is no name available. Something similar needs to be done in other software, e.g., the relation handling at osm.org. Misusing the name tag is not the way to go.

ok, *war*. da hätte aber auch damals schon das conditional access gelöscht gehört... mach ich jetzt.

Das liegt aber am conditional access... bicycle yes ist/war falsch.

Hi, das ist bis jetzt nicht passiert... ich bin gerade dabei die EV6-Relation mal wieder zu reparieren und hab die Verknüpfung gelöscht (WIP) - die Relation selbst aber noch bestehen gelassen. Wenn ich nicht auch vergesse, werde ich die Relation selbst demnächst löschen ;)

You renamed a small leg within Austria to look like it is THE ev6 with this changeset... not exactly "ideal". :/

No, these are not proper names - using description was the right thing to do. I am not sure this relation is the right one but that's another topic (and the reason why I was looking at the history in the first place).

Hallo,
ich bin nicht sicher, was du hier und in den anderen Changesets zum Meridianradweg genau machen wolltest, aber es ist definitiv nicht gut ausgegangen :) Jetzt gibt's 49(!!!) Relationen zum Meridianradweg, die offensichtlich nur eine sein sollte. Kannst du das bitte aufräumen?

Thanks for your answer.

That is a very bad practice that was spread from Germany elsewhere. We are currently trying to clean that up (in Europe) actually and that's why I was looking around to find other places where this problem exists.

You should never add any invented values to OSM (cf. osm.wiki/How_We_Map). The ref tag is meant to refer to existing external references.

Similarly to SDP, I think the ref here has been invented. That's not what ref is meant for.

Hi, what's the source for the value "SDP" of the ref key? To me this looks like an invented value.

OK, thanks. I am not sure if there is any consensus regarding emojis in this context. The two bicycle-centric maps on osm.org (cyclOSM and cycle map) are not able to render it correctly, so at least their devs did not expect it. I'd be surprised if many applications could deal with it correctly. On the other hand it is way too cute to just remove it IMHO :)

What should be done in any case is to add what you explained to the description key. The value of that key is meant to be presented to end users, e.g., on mobile apps, when the user shows details of an object.

That was already tagged on the way (osm.org/way/414454788) thus I have deleted your node.

Hi, regarding the ref tag of osm.org/relation/12886069/
Using symbols is not the best idea there, but more importantly, is the symbol actually used on signposts etc.? ref should only contain official IDs that one can find along the route on maps, signposts etc.