Ich mache hier mal einen Split auf aus diesem Thread…
Eine gar nicht abwegige Idee, die mir auch schon seit langem im Kopf in ähnlicher Form rumspukt:
Einen approved: Namensraum und einen experimental: Namensraum. In experimental darf jeder seine Tags erfinden wie er lustig ist (also so wie bisher im allgemeinen Raum). In approved kommen nur solche Tags, die ein (deutlich konsequenteres als bisher) Verfahren zur Validierung durchlaufen haben. Z.B. darf es nicht reichen, wenn innerhalb einer Woche 30 User dafür gestimmt haben. Oder daß es in einem Wiki-Eintrag dokumentiert ist, den Hinz und Kunz jederzeit ändern kann.
Der approved Namensraum erfährt eine Qualitätssicherung, beispielsweise durch eine von der OSMF unterstützte Arbeitsgruppe. Diese legt Taggingregeln fest, die für den approved Namensraum gelten und die auch niemand einfach so umändern kann. Massgeblich sollte z.B. immer die englische Fassung sein. Man beginnt mal mit solchen Tags, die unstrittig sind und arbeitet sich dann langsam hoch.
Wer eine Karte erstellen möchte, kann selbst entscheiden, ob er die approved tags verwendet oder auch experimentelle Tags akzeptiert. Es ist also alle Freiheit da, die heute auch da ist, verbunden mit einem Ansatz, Ordnung in das Chaos zu bringen.
Ähm… Branches in OSM? Dann könnte man sich auch den ganzen Datenbankkram sparen und alles in Git packen.
Nein, davon halte ich nichts. Schon nach kurzer Zeit wird man die beiden Branches nie mehr zusammenführen können. Aber man könnte eine komplett eigenständige Datenbank anlegen und schauen, ob und wie sehr sich das chaotisch entwickeln wird. Als Layer könnte man es natürlich dann trotzdem über OSM legen.
Dürfte aus meiner Sicht ein wenig an der Realität vorbei gehen. Für einen Großteil der Nutzer ist approved genau das, was der Editor ihm anbietet, bzw verlangt. Alles andere ist unbekannt. Ein weiterer Punkt ist, dass man Taggs ein Stück komplexer macht. Das bedeutet wenn ich mich abseits der Vorlagen bewege muss ich nicht nur wissen, wie etwas eingetragen werden soll, sondern muss auch noch wissen, ob es approved oder experimental ist. Es könnte sinnvoll sein, wenn es eine Validierung geben würde. So erweitert man in meinen Augen nur das Chaos.
Deine Vorderung nach einer OSMF-Workgroup ist ja schön und gut, wenn sich in letzter Zeit nicht viel geändert haben sollte, so kranken schon die aktuellen Workinggroups am Mitgliedermangel.
Das haben wir aber jetzt schon. Bei den ÖPV-Routen haben wir PTv1 und PTv2, bei denen dasselbe Tagging etwas ganz anderes bedeuten kann. Da kann man sehen, dass die Katastrophe in der fehlenden Markierung der Branches liegt und nicht in der Existenz der Branches. Wir wären schon längst mit der Umstellung auf PTv2 fertig, wenn es von Anfang klar markiert worden wäre.
Aber man kommt meines Erachtens nicht weit genug damit (und es macht die Tags häßlich). Oft besteht eine Taggingart ja gerade darin, z.B. statt eines Tags eine Relationsmitgliedschaft zu verwenden oder umgekehrt oder für bestimmte Objekte bestimmte Tags zu verlangen.
Ich finde, dass wir die RFC des Internet zum Vorbild nehmen sollten. Da werden Vorschläge für eine Problemlösung gemacht und abgestimmt. Bei Erfolg bekommen sie zentral eine RFC-Nummer zugewiesen und darauf kann sich dann jeder berufen. Man kann aber auch etwas anderes machen, wenn man sich nicht auf diese Nummer beruft (Also etwa: “OSM:4711=yes” an das Objekt dranschreiben oder nicht dranschreiben). Man könnte auch irgendwann darüber abstimmen, irgendwelche alten oder fast unbenutzten Nummern für “veraltet” zu erklären. Es darf jedoch nie der Originaltext verändert werden.
Das sind die angenehmen Nutzer. Die kann man genau dort abholen. Indem z.B. ein JOSM nur solche Presets von Hause aus mitbringt, die approved taggen (oder zumindest die anderen gesondert kennzeichnet).
Wenn man approved beim Upload oder per daily bot überwacht und invalide Tags gleiche wieder revertet, kann das funktionieren. Und wenn default=experimental, muss niemand auch nur einen Character mehr tippen. Der Editor könnte solche tags, die er als approved erkennt, automatisch prefixen.
OSMF war nur eine Idee, muss nicht sein. Wäre aber am besten, wenn tatsächlich mal jemand aufsteht und sagt, jawoll wir sind zuständig dafür, daß dem Wildwuchs ein Ende gesetzt wird und das auch noch auf einigermaßen schmerzfreie Weise. Wer wenn nicht die OSMF? Sie muss ja nicht die Arbeit tun - nur diese koordinieren. Wenn ich die üblichen 10-20 Verdächtigen auf der Tagging Mailingliste sehe, die 90% der Posts verantworten, dann fallen mir spontan bereits Kandidaten ein.
Die Idee kann meiner Meinung nach nicht funktionieren – höchstens unter
enormem Mitarbeiter-Einsatz
und/oder
enormem Verlust der Attraktivität von OSM
Bisher ist es so, dass ich alles, was ich in OSM eintragen will, in einem Rutsch mappe. Ob das nun Häuser sind, Straßen oder Litfaßsäulen oder den großen Außenbereich eines Restaurants.
In Zukunft würden dann beispielsweise die beiden letztgenannten Sachen entweder revertiert oder gar nicht erst zugelassen oder der ganze Upload würde zurückgewiesen. Wie das genau gehen soll, ist für mich offenbar so schleierhaft wie für die Personen, die die Paralleluniversen-Idee hatten.
Für mich ist es sinnvoll, Sachen in OSM zu mappen, für die noch keiner einen Tag gefunden hat. Wie ich das mache, habe ich kürzlich erst hier geschrieben.
Wenn ich beim Mappen einer Ortsbegehung nur “approved” Sachen eintragen soll und später in einem zweiten Durchgang “not-approved”-Zeugs in eine zweite DB kippen (oder warten bis irgendwas irgendwann approved sein wird), verzichte ich auf den zweiten Durchgang. Auf den ersten vielleicht auch.
So gut ich eine Idee heiße, in der sich Leute um konsistentes Tagging bemühen – die in diesem Thread vorgestellte Idee taugt nix. Oder sie wurde schlecht präsentiert.
Die vorgeschlagene Änderung betrifft doch vorallem das Backend und die Datenbank oder? Die API kann ja weiter wie gewohnt laufen und das “Trennen” von approved und experimental serverseitig passieren.
Kleine Zwischenbemerkung: Meine ursprüngliche “Idee” des Paralleluniversums bezog sich eigentlich eher auf eine zweite Datenbank, nicht auf ein Gemisch in der existierenden Datenbank. Dass da einiges an Problemen dran hängt (wie auch immer man mehrere Datensätze voneinander trennen würde), zeigt sich hier ja sehr schnell. Allein schon die Frage, wer das “Recht” hat, in der einen oder in der anderen Datenbank zu schreiben. Am besten würde es vermutlich klappen, wenn es Tile-Paten gäbe, die für ganz bestimmte Tiles eine gewisse Verantwortung übernehmen. Wie ein kleiner Tile-Hausmeister. Das wälst natürlich u.U. eine Menge Arbeit auf diese User ab, und in bestimmten Gegenden wird es viele User geben, in anderen gar keine. Und man kann auch nicht sicherstellen, dass jeder Pate bzw. jede Patin auch einen guten Job macht. Es bleibt halt eine Art Ehrenamt.
Was mir dann noch fehlt ist eine Erklärung, wo der Sinn darin liegt ein Tag massenhaft in den Daten als approved zu markieren? Dann kann doch auch jeder in seiner Auswertung das erledigen. Ala WENN Editor=JOSM und amenity=fuel DANN amenity → approved:amenity. Ob an der Stelle dann wirklich eine Tankstelle ist ist immer noch unbekannt.
Was sind denn die “Use Cases” für so eine Trennung? Muss nicht sowieso für fast jede größere Anwendung eine Vorverarbeitung der Daten durchgeführt werden? Also sinnvoll finde ich einen Katalog von “approved Tags” auf jeden Fall, ob die Speicherung deswegen auch so physikalisch vorgenommen werden muss weiß ich nicht. Ich würde erwarten ein Filter/eine Sicht durch so einen Katalog würde auch ausreichen, um die Daten auszuliefern. Die Definition dieses Kataloges wäre ja auch der erste Schritt. Vielleicht gibt es neben der Aufspaltung in valide Daten auch weitere Auftrennungen, die Sinn machen könnten. z.B. dürfte für einen Geocoder relativ uninteressant sein welche Geometrien ein Objekt besitzt oder ein Renderer nicht für “POI-Informationen” wie Telefonnummern, Öffnungszeiten usw…
Ich danke allen, die ihre Meinung geäußert haben. Es besteht offensichtlich kein tieferes Interesse an der Idee. Sie wabert seit längerem etwas unscharf durch meinen Kopf. Mal sehen, vielleicht ist die Zeit auch noch nicht reif oder der zündende Punkt steht noch aus. Ich lasse das jetzt erst mal wieder gären.
Ja. Meine Äußerung bezog sich aber auf Sinn und Unsinn von “Branches” bzw. deren Markierung.
Das ist eine interessante Frage.
Es war eine Umstrukturierung der Datenstrukturen. Das alte System zu erweitern hatte sich als grauenhaft erwiesen. Wir bewegten uns auf einen Zustand zu, in dem die Roles der Routenrelation einen komplizierteren Aufbau gehabt hätten als die Werte bei den Öffnungszeiten-Tags. Das war unerträglich und widerspricht auch völlig dem Konzept der “Rolle”.
Das damals neue System (PTv2) war gut durchdacht, nur hätte man die Routen des alten und des neuen Systems klar unterscheiden müssen. Z.B. mit dem jetzt erst vom JOSM eingebrachten “public_transport:version=1/2”. Das hat viele Mapper auf falsche Ideen gebracht, den Support durch die Editoren behindert, die Darstellung auf Karten komplizierter gemacht und den heutigen schlechten Zustand vieler Routen bewirkt.
