Erledigt, waren ja nur zwei Ziffern.

Bei den Wegweisern habe ich bisher die ref nur an den Aufklebern der Bergwacht gesehen. Ich habe sie also den emergency_acess_point zugeordnet.
Ob man die zu den guidepost mit dazu packt, gibt es unterschiedliche Ansichten, stellenweise werden sie künstlich als extra node ein paar Zentimeter daneben gemappt, aber man sollte sie mMn nicht ersatzlos vom guidepost löschen.

Die Linien sind Mitglied in unterschiedlichen Relationen, müssten deswegen nicht doppelt vorhanden sein, sie tragen aber unterschiedliche Tags.
Dabei ist der Tag source an der Linie des Gebietes überflüssig, denn er steht auch in der Relation, und der Tag type=boundary an der Linie ist eh falsch.
Die Tags an der Grenzlinie der Kernzone stehen deshalb, weil das ein Teilgebiet einer Kernzone mit vier getrennten Flächen und Namen ist.

Hallo Peter,

die Umrisslinie zum Biosphärengebiet wurde vor einem Monat von jemand bei der Geschäftsstelle eingetragen. Die Tags waren nicht ganz korrekt, wurden zwischenzeitlich aber von user DD1GJ korrigiert. Die Grenzen des Gebietes sind eigentlich weitgehend die der teilnehmenden Gemeinden. Sie wurden aber von der Geschäftsstelle einfach über alles drübergelegt. Die Grenzen der Kernzonen wurden vor über einem Jahr ebenfalls von jemand an der Geschäftsstelle eingetragen ohne Rücksicht auf bestehende Grenzen. Das führte dann natürlich zu Doppelungen, ist aber inzwischen korrigiert.
Die Gemeindegrenzen habe ich vor fast 10 Jahren auf Basis der damaligen Daten von LGL eingetragen. Inzwischen sind Grenzen um ein paar Meter unterschiedlich in Maps4BW eingetragen. Sie sind wahrscheinlich durch eine geänderte Generalisierung der Katasterdaten bei LGL entstanden. Sie sehen eine Idee genauer aus und wurden auch von der Geschäftsstelle verwendet.
Fazit: Dort wo die Kernzonen am Rand des Biosphärengebietes liegen, sollten die deckungsgleichen Linien (Knoten) verschmolzen werden.
Da wo die Abweichung der Gemeindegrenzen ebenfalls nur wenige Meter beträgt, sollten die auch auf diese Linien verschoben werden.
Bei dieser Gelegenheit habe ich festgestellt, dass die aktuellen admin-Grenzen in Maps4BW in etlichen Abschnitten leicht von denen in OSM abweichen, das ist aber ein anderes Thema.

There is no special meaning of this tag.

The whole route has been imported as ways in several chunks from a source containing probably GPS tracks. There were two and very often three ways on top of each other containing identical nodes but different endpoints. The only difference were the ids.
All tags come from the imported data and do not conform to OSM tagging. I copied part of the tags - especially the descriptio(n) - to the hiking route relation.
In general I am very restrained in deleting information. Later on with more experience with that import I deleted obsolete tags on the ways but kept the ids with just retagging to loc_id because id is a too short tag in OSM. I kept them provisionally because they showed which segments fit together.

I think these tags can all be deleted after some waiting time but this is at the moment not highest priority for me.

Position of most benches is very suspicious. They are far off any access, in river beds, in woods, above 4000 m.
No source given, personal survey is unlikely since they are distributed over a large area.
Partial revert seems mandatory.

My orientation for tagging in this disputed area was the AL2-boundary with tagging administrative. This is the recommendation for "line of control" by the "on the ground rule".
I have no local knowledge about the real control and so I removed the controlled_by tag.
I'm e.g. not sure about the control of Charit since there is a road connection from China to Doslinma and further a path of just 1 km down to Charit as well as a path from Dürzen up the Sharitang Chu valley.
The connection to undisputed Bhutan territory at Haa Chu is over two mountain passes.

As there is no answer: I have cleaned ways and put them to route relations

As there is no answer: I have cleaned ways and put them to route relations

There is a more serious problem in the Trans Bhutan Trail imports by user Sonam Yangdon than just the truncation of description.
The ways are unprocessed imports of GPS-Tracks, up to three on top of each other. The imported tags make no sense in OSM.
I am trying to convert things to route relations in OSM scheme, but that's tedious and often several thousand points are affected.
So if you intend to work on that TBT problem, too, please contact me to avoid mass upload collisions.

Stream can be better seen in actual Bing image. Maybe it was even more obvious in earlier imagery.

But it is of course to some extent a "matter of taste" whether to map such small intermittent waterways - although they may be a great obstacle during monsoon.

If it makes no difference you may ignore it.
But thanks for the hint to the difference between country and language codes.
Anyway - I will keep off Thimphu in the future.

As a general rule I don't delete objects from presumably local mappers even if they are a bit suspicious.
I do delete obvious errors like duplicate buildings, areas or roads.
I try to "disarm" conflicting or misleading tags by adding :bt (or :np) to show that they were added by local mappers disregarding OSM syntax.
I agree that these "id"-tags were most likely introduced by an improper GIS import, but I will interfere with that taggings as little as possible since I don't know details.

In OSM wird abgebildet, was vorhanden ist.
Dass die Treppe gesperrt ist, muss auch vor Ort sichtbar sein (Schild, Tor o.ä). Eine vorhandene Treppe wird sonst genutzt, egal ob sie in OSM ist oder nicht.

Ich würde bei DE:Key:protection_class nachsehen, da ist es genauer aufgeführt.
Danach haben die Kernzonen class=1 (das a kann entfallen) innerhalb der Nationalparks (NLP) mit class=2.
Das class=14 ist für solche Gebiete wie Wildruhezonen.

Hallo Peter,
das ist die Straße direkt hinter der Uni-Mensa, da war ich schon ewig nicht mehr. Die Einbahnstraßenrichtung dürfte nach Stadtplan aber immer noch stimmen. In Tübingen ist es nicht unüblich, dass Einbahnstraßen T-förmig nach beiden Richtungen abgehen, siehe Keplerstraße direkt dahinter.
Völliger Unsinn ist aber das highway-Tagging. Der hw-Typ ist kein Freitext, da gehört residential rein und sonst nichts.
Deshalb wird der Abschnitt nicht gerendert und Routen geht auch nicht.
Das psv=yes macht wenig Sinn, denn die Straße ist ja nicht gesperrt. Gemeint ist vermutlich oneway:psv=no.
Es kann sein, dass der Bus wie auch die Fahrräder gegen die Einbahnrichtung durch darf. Tübingen ist bezüglich Verkehrsregeln sehr speziell.
Gruß Helmut

These keys have been introduced by some project/import cf keys
project:url=https://github.com/MeghaStha/ILO-training
source=ILO transportation mapping, 2cpokhara
When i came in touch with that highways in 2016, i just corrected syntax errors like lanes=Two and changed class and condition keys to class:np and condition:np since they were interfering with other uses of these keys in OSM.
class=DCRN is just a newer district road classification scheme in Nepal than a former ABC scheme, condition=* is a discouraged subjective classification appearing in that data sets.

Zunächst mal vorneweg: Ich stehe dem Eintragen von Landschaftsregionen in OSM sehr skeptisch gegenüber. Mit Linien kann man die Abgrenzung nur ziemlich willkürlich eintragen. Ich habe hier vor etlicher Zeit nur mitgewirkt, weil die Grenzen teils um zig Kilometer daneben eingetragen waren.
Die Abgrenzung Alb zu Randen ist relativ willkürlich, da der Randen geologisch die Fortsetzung des Jura nach Südwesten ist. Das Donautal bei Geisingen kann man dafür hernehmen, da es der deutlichste Einschnit ist, mehr als das Aitrachtal bis Blumberg. Für abweichende Abgrenzungen kann es aber andere Begründungen geben.

Ja, denn ich mittle über die gleichzeitig aufgenommenen Trackpunkte. Musste ich selber schreiben, denn so was habe ich noch nirgends gesehen.

Kommando zurück: Da ich am Tagging des Weges nichts geändert habe, tauche ich dort nicht auf, wohl aber an den Nodes.
Die habe ich bis zu 6 m in Richtung meines Tracks verschoben. Die Wege in Maps4BW sind (anders als die Gebäude) nicht aus den Katasterdaten und erfahrungsgemäß etwas ungenauer.
Wegen der geringen Abweichung würde ich aber nicht auf meiner Version bestehen. Da bin ich leidenschaftslos.

Ich habe einen GPS-Track gemittelt aus 6 Geräten hochgeladen. Ich habe den Wegweiser eingetragen, am Weg (blauer Balken) habe ich nichts geändert, zumindest sehe ich in der History nichts.
In den Bildern sehe ich nur inMapbox (und etwas schärfer in ESRI) ein Stück des Weges. Den Bildern ist aber insbesondere an Abhängen nicht zu trauen, da kommt es wegen der Ungenauigkeiten im Höhenmodell gerne zu Verzerrungen.