Aber Du hast vorhandene Informationen 1:1 nach Deinem bevorzugten Schema geändert. Das ist nicht in Ordnung. Findest Du bestimmt auch nicht i.O. wenn es Deine Eintragungen betrifft, oder?
Für Software, die sich also durch den maxspeed-Dschungel schlagen muss, sollte es also herzlich egal sein, welcher Key denn nun genutzt wird.
Und Streetcomplete ist es auch egal: wenn die Geschwindigkeit irgendwie erfasst ist, wird nie mehr danach gefragt. Also auch nichts umgetaggt.
Und hier liegt der Kernpunkt der berechtigten Kritik die man an Ruben stellen könnte:
Einfach nur einen anderen Key verwenden bringt je nachdem wen man fragt keinen oder wenig Mehrwert und hat den Nebeneffekt, dass es so aussieht als sei die Geschwindigkeitsbegrenzung gerade überprüft worden (durch Datum letzter Bearbeitung).
Die Frage die glaube ich bisher niemand gestellt hat ist also, ob die Situation vor Ort denn überhaupt jeweils überprüft wurde?
Im übrigen finde ich es auch nicht OK dass das deutsche Forum von einigen so gern als Pranger genutzt wird.
Auch bei solchen Themen könnte man z.B. titeln “Ist es OK, source:maxspeed in maxspeed umzutaggen?” statt gleich einen Angriff auf die Person zu machen.
Zum auswerten via Software sei gesagt, das es keinen Sinn ergibt mehrere Tags mit ähnlichen Inhalten zu pflegen.
source:maxspeed=DE:zone30, zone:maxspeed=DE:zone30 sowie maxspeed:type=DE:zone30 und maxspeed=30 sollen von irgendeiner Software noch sinnvoll gelesen werden und von Mappern gepflegt werden?
Ich mein, das einzige Argument was ich bisher gehört habe was gegen die Verwendung von maxspeed=DE:zone:30 spricht ist, dass es nicht rückwärts kompatibel ist.
Klar, neue Werte sind nicht nicht rückwärts-kompatibel. Aber ich denke nicht, dass eine Software im Moment alle 4 Tags auswertet und dann ein 30-Zonen-Schild anzeigt. Im Gegenteil es wird nur maxspeed=30 ausgewertet und entsprechend eine 30 im roten Kreis gezeigt.
Entsprechend wird keine Kompabilität beeinträchtigt… es wird lediglich die Liste der gültigen Werte um zwei erweitert.
Das ist deutlich einfacher umzusetzen als die drei anderen Süppchen die gekocht werden.
Doch natürlich. Wenn man Daten korrigiert, verifiziert oder aktualisiert ist es doch egal wie man das tut, solange klar ersichtlich ist was damit gemeint ist und es dokumentiert wird.
Beides ist bei mir der Fall und ebenso bei source:maxspeed, maxspeed:type, sowie zone:maxspeed.
Wenn jemand nun die Daten vor Ort prüft und ein anderes Schema bevorzugt trägt er die Daten anders ein.
Klar sind es “meine” Änderungen, aber im Endeffekt arbeiten wir doch auf ein gemeinsames Ziel hin: Eine vollständige und aktuelle Weltkarte mit möglichst vielen Details.
Ein - in meinen Augen - kaputtes Tagging Scheme blind anzuwenden ist hier falsch. Würden wir das alle tun gäbe es eben nur einen etablierten Weg das zu taggen, nicht drei.
Das Ziel hier ist klar: Man versucht sich daran gemeinsam den besten Weg zu finden und die Nutzung entscheidet am Ende was von Parsern unterstützt wird.
Die Tags werden genutzt und werden auch nicht von heute auf morgen verschwinden. Vermutlich wird es die für immer geben, es sei denn es gibt irgendwann ein Proposal, dass mit dem maxspeed-Tagging aufräumt.
Jedenfalls wenn hier einer ganz viele maxspeed:type in source:maxspeed umtaggt oder dort einer zone:maxspeed in maxspeed umtaggt, ändert das an der Situation für Softwarehersteller nichts.
Naja, aber OSM hat explizit kein Enforcen von Regeln zum Tagging. Ich zitiere mal “OpenStreetMap has very few rules on tagging. There are tagging standards but they evolve instead of being pushed through.”
Die Redundanzen der drei “etablierten” Standards bringen uns eben auf Software-Seite m.E. überhäupt nicht weiter. Es ist eine Information und nicht zwei unterschiedliche. Das wird dann auch klar, wenn es unterschiedliche Geschwindigkeits-Beschränkungen gibt - beispielsweise bei DE:rural. Klar ist das 100 km/h für Autos, aber nur 60 km/h für große LKW. Würden wir das explizit taggen wollen, müsste man ein maxspeed:hgv=60 an jedes maxspeed:type=DE:rural, maxspeed=100 dran hängen. Alternativ leitet man das implizit ab, aber an der Stelle darf man sich dann fragen, warum man das maxspeed=100 dann überhaupt benötigt.
Keine der zusätzlichen Tags wurde durchdacht eingeführt mit einem Proposal (korrigiert mich, wenn das falsch ist - konnte keines dazu finden). Also ist es genauso eine Änderung der Gewohnheit die zur Änderung des Schemas geführt hat wie das was ich jetzt gemacht hab. Ich hab es dokumentiert und da wo ich es überprüft/geändert habe nach dem Schema eingetragen was mir sinnvoller erschien.
Der Kandidat hier gehört deutlich verwarnt. DWG. Er setzt sein Verhalten fort als ob nichts gewesen wäre. Das ist Vandalismus pur!
PS: Den Namen aus dem Thread-Titel entfernen? Bis gerade eben hätte ich “ja” gesagt. Aber vielleicht will hier jemand im Form an ganz prominenter Stelle seinen Namen lesen.
Wie bitte?
Das ist also deine Argumentation um deine Wunschvorstellung hier durchzudrücken. … und dann zu dokumentieren und gut ist.
Es geht ab und zu chaotisch zu und her beim OSM-Tagging. Das Eröffnet natürlich die Möglichkeit seinen persönlichen Stil durchzudrücken. Das ist kein Stil! Und auf sowas stehe ich gar nicht.
Hat mal jemand einen Link was genau in der Wiki geändert wurde?
Die Wiki soll u.a. dokumentieren, welche Tags wie genutzt werden. Dass maxspeed=<Ländercode>: in Deutschland (quasi) nicht genutzt wird, ist denke ich durchaus eine Erwähnung wert. Aber es sollte auch nicht unter den Tisch fallen, dass es in anderen Ländern durchaus üblich ist.
Okay, ich hab mich an ein Proposal gesetzt um hoffentlich, eine einhaltliche Lösung die einfach zu parsen ist zu definieren und die Tags “zone:maxspeed”, “source:maxspeed” und “maxspeed:type” nicht länger dafür zu nutzen implizite Werte einzutragen.
Das bedeutet natürlich nicht, dass man nun anfängt alles wild “umzutaggen”, sondern, dass Apps wie StreetComplete in Zukunft die Nutzer fragen können welche maxspeed-Situation vor Ort vorliegt und den Tag “umschreiben” kann wenn sich etwas geändert hat ohne damit jemandem auf die Füße zu treten.
Hoffe hier lässt sich ein vernünftiger Konsens finden.
“These tags can be used in the tag source:maxspeed=* as well, in addition to an explicit maxspeed=* value - which is currently preferred by some local communities.”
Zum einen ist es kein größeres Problem für Software, mehrere alternative keys anzusehen, und zum anderen kommt der Wildwuchs hier von Leuten wie Dir, denen der bisherige Standard nicht passt und die daher einen neuen konkurrierenden einführen. Wenn man das (im Gegensatz zu maxspeed:type, das wenigstens noch parallel verwendet werden kann) wie hier “auf Konfrontation” macht, also ein bestehendes Schema (hier was in “maxspeed” als Wert eingetragen wird) so ändert, dass bisherige Werte geändert werden müssten, dann kommt es logischerweise zu Aufregung und im Endeffekt hat man eine noch kompliziertere Lage, muss nämlich noch ein weiteres Schema berücksichtigen.
Ich stimme mit dieterdreist überein, im Namen des Community-Friedens wäre es besser, Änderungen dieser Art in entsprechenden Proposals zu besprechen. Eine echte Änderung kann man sowieso nur so herbeiführen.
Ich würde zunächst aber mal dringend empfehlen, noch kein Voting zu starten und stattdessen die Beweggründe und Inhalte auch auf den entsprechenden Mailingliste National und International darzulegen und das Proposal zu präsentieren.