bei meinen Korrekturen mittels OSMI bin ich in der Gegend um Dessau auf Straßen und Wege gestoßen, die im JOSM farblich anders als gewohnt dargestellt wurden - hier war es das Tag tunnel=no an vielen Straßen, das zum Wechsel der Farbe der Wege in JOSM führte. In der Historie konnte ich dann erkennen dass jemand mit dem Editor OSMapTuner folgende (meist unnötige) Tags hinzugefügt hat:
access = official
bridge = no
construction = no
cycleway = shared
oneway = no
Diese Tags wurden auch ergänzt, wenn nur etwas an der Straße geändert wurde (in höheren Versionen als 1).
In der Bedienungsanleitung (Link auch unten auf der Wiki-Seite) im Abschnitt Detail View im ersten Screenshot unter Optional Tags sind die Tags access, bridge und construction zu sehen - soweit zu erkennen, stehen die noch auf Not set. Vermutlich hat der Nutzer, der diese überflüssigen Tags ergänzt hat, auch versucht, viele optionale Tags auszufüllen und nicht auf Not set stehen zu lassen.
Folgende Zahlen zeigt Taginfo im Moment:
bridge = no: 7619
construction = no: 544
tunnel = no: 7167
Wie lässt es sich bewerkstelligen, dass dieser und weitere Nutzer dieser Android-App nicht auch die überflüssigen default-Werte für optionale Tags eingeben und hochladen?
Ist ja die App dran Schuld die dem Nutzer zu solch unsinnigen Eingaben geradezu herausfordert. Im Prinzip dürfte es nur “ja” und “nein” geben. Wenn ja, dann bridge=yes, wenn nein, dann den Wert bridge ganz aus dem Weg rauslöschen.
Passierte mir früher selber und das in meinem heißgeliebten Josm!
Way angelegt, Vorlage-Popup ausgefüllt, aus Versehen Einbahnstraße anstelle von Brücke aktiviert, gleich gemerkt und Häkchen wieder weggemacht → oneway=no in den tags
Hatte mich irgendwann mal gewundert, welcher Idiot diese blöden Tags reinschreibt - dumm gelaufen
Ist übrigens immer noch, ich sollte wohl mal ein Ticket aufmachen.
Die Klickfelder im josm haben 3 Zustände: Haken, kein Haken und leicht bläulich.
Haken: =yes
kein Haken: =no
bläulich: kein Wert gesetzt
Das ist auch ganz sinnvoll. Schließlich soll man auch explizit sagen können, dass da die Eigenschaft eben nicht zutrifft.
Ein Beispiel: tourism=caravan_site sagt per default nichts darüber aus, ob man dort zelten kann oder nicht. Wenn man also nicht zelten darf, dann muss ein tents=no gesetzt werden, wenn es erlaubt ist, kann ein tents=yes derzeit auch nicht schaden, da diese Eigenschaft leider kaum genutzt wird und man sich nicht wirklich drauf verlassen kann, dass ein tourism=caravan_park & tents!=no Zelte erlaubt.
In diese Richtung hatte ich auch schon gedacht - nur yes und Not set zuzulassen. Nur bei oneway geht das nicht - für Autobahnen brauchen wir manchmal das oneway=no, da der default for motorway auf yes steht.
Ein anderer Gedanke geht in die Richtung wie der Expertenmodus bei den anderen Editoren - dass man die default-Werte erst in diesem (versteckten) Modus setzen kann. Die muss das Programm dann aber alle kennen (z.B. dass oneway bei motorways auf yes steht, bei allen anderen auf no.
Eine App die dem Nutzer die “unterste Ebene” unser OSM-Welt verschleiern möchte, müsste solche Feinheiten schon selbst erkennen. Wobei natürlich auch klar wird, warum solche Ausnahmeregelungen wie dass motorway immer oneway impliziert, generell problematisch sind und die Nutzung der Daten nur unnötig verkomplizieren.
Da das Programm offensichtlich nicht mehr weiterentwicklelt wird - Version bei Google Play datiert vom 14. März 2012 (Jahreszahl in Worten: zweitausendzwölf), würde ich keine Hoffnung in eine Verbesserung des Editors setzen. Dummerweise erreicht OSMapTuner ein beträchtliches Publikum (allein 2013 haben bereits 64 User 1062 Bearbeitungen vorgenommen - Stand vor zwei Wochen). Einzige Chance ist wohl, einzelne Mapper direkt anzuschreiben, die damit regelmäßig Unsinn verbocken.
