Hallo steffterra, > Mann, geht mal an die frische Luft. Ich will ja hier keinen > beleidigen, aber das ist der Grund, warum sich nichts bewegt.
> Also kein tag -> alte Interpretation > key dran -> Interpretation nach key > Wo ist das Problem? Kann man doch auch im Wiki so festhalten. Dann > weiss es jeder, dass amenity=parking ohne Zusatztag/key ein großer > Parkplatz ist - ist das denn so abwägig? Das Problem ist nicht die Theorie, da bin ich sogar - oh Wunder - mit Dir einer Meinung! Das Problem ist, dass die Idee nicht rückwärts-kompatibel ist. Alle Programme, welche nur die 'grossen' Parkplätze anzeigen wollen, müssen umgeschrieben werden. > Genau deshalb wird nichts in die Welt gebracht. Genau wegen solcher > Argumente. Natürlich hist es einfacher, etwas schnell schlecht > umzusetzen, als groß aufziehen zu müssen und dafür eine geordnete > Tagging-Struktur zu bekommen. > Tausende von Einzeltags sind _nicht_ besser als ein Überbegriff und > darin den passenden key suchen. Letzteres ist wesentlich flexibler, > aber letzeres ist "besser" in der Einzelkämpfer-Marnier hier durchzusetzen. So ist es eben in einer Anarchie. :-> Oberstes Ziel von OSM ist es nicht, ein 'abstrakt-korrektes' bzw. 'informatik-logisch korrektes' Taging-System aufzubauen, sondern es wird auch grossen Wert auf die praktische Nutzbarkeit gelegt. Wenn sich nun ein Tag in der 'falschen' Nutzungs-Art verbreitet hat, dann kann man sich überlegen, ob man für die 'neue' Nutzung nicht ein neues Tag einführen sollte. (siehe z.B. auch die leidige Diskussion um bicycle=designated) > Wir würden uns nicht "streiten", wenn es nicht darum ginge einen > tag zu einem Überbegriff zu machen. Wenn amenity=parking schon ein > überbegriff mit keys wäre, wäre es ein Kinderspiel, einfach einen > neuen key einzuführen. Aber man muss ja nicht an die Zukunft > denken... Lieber immer wieder neu einen Tag durchboxen. Erstens wird hier nicht durchgeboxt, sondern mit (den immer gleichen Argeumenten :-> ) diskutiert. Mit boxen bringe ich nämlich niemanden dazu, 'meinen' Tag zu benutzen. Warum man bei Tags nicht nur in die Zukunft schauen kann sondern auch zurück steht weiter oben. > Eine Parkplatz/Parkstand/Stellplatz-Datenbank ist viel leichter > aufzuziehen, wenn man nicht darauf achten muss, wieviele > unterschiedliche Tags es fürs Parken gibt. Einfach den amenity > nehmen, auslesen, welche keys dazu gemappt wurden und gut ist. Aber > das wäre wohl zu fortschrittlich gedacht. Es ist einfacher, 1 bis 5 > neue Tags für ähnliche Dinge einzuführen. Die Frage ist aber auch, ob man überhaupt eine gesamte Datenbank aller Parkmöglichkeiten benötigt oder ob die Nachfrage von "Parkhäuser und grosse Parkplätze" und "einzelne Parkplätze insb. Spezial-PP" nicht sowieso meistens getrennt sind. >> Wer bespricht diese semantische Änderung auf der englischen talk Liste >> (bislang habe ich dort kein Wort über diese Diskussion gesehen)? >> Wer bespricht diese Änderung auf allen anderssprachigen Mailinglisten? >> Wer kümmert sich darum, das diese Änderung im Wiki *konsistent* (über >> alle Sprachen) geändert wird? >> Wer kümmert sich darum, das alle relevanten Kartenrenderer diese >> Änderung mitbekommen? >> Wer kümmert sich darum, daß Editoren ihre Presets entsprechend anpassen? > >> ... und ich hab mit Sicherheit noch so einiges vergessen. > Angst! Arbeit! .. oder wie? Wenn man hier zusammenhalten würde und > sich nicht jeder als Einzelkämpfer (der für "seine Art zutaggen" > kämpfen würde) sondern vielmehr gemeinsamen nach _guten_ Lösungen > (mit freiem Kopf!) gesucht würde, dann könnte man das auch stark > gemeinsam flächendeckend umsetzen. Wir suchen ja gerade nach einer guten Lösung. Allerdings wird es nie eine Lösung geben, die *alle* als die beste emfpinden. > Irgendwo muss man ja mal anfangen, sich andere Meinungen anzuhören. > Nur so langsam merke auch ich, dass hier viele eben nicht an das > denken, was aus osm werden könnte, sondern, wie man am besten alles > in das derzeitige Schema presst. Man merkt das es bei > richtungsabhängigen Sachen eigentlich immer konfuser wird, weil > tagging-ketten keine bessere Lösung als Relationen sind, weil man > merkt, dass Linienbündel einen haufen Arbeit bedeuten. Blos nicht > über den Tellerrand hinausdenken, es könnte Arbeit machen. Es ist > einfacher im aktuellen Gedankenschema zu bleiben. Was meinst Du, warum ich hier gefragt habe und nicht einfach meine Art als *die Lösung* präsentiert habe? Wie schon mehrfach erwähnt ist parking+capacity zwar logisch aus Informatiker-Sicht, aber in OSM gibt es noch viel mehr zu beachten. > Nein es fängt sogar schon bei einem Einzeltag an, dass hier keiner > mehr am gleichen Ziel arbeitet, nämlich OSM zu verbessern, sondern > versucht sein Einzellkämpfer-Ding innerhalb bestehender Grenzen durchzusetzen. Wenn Du die Diskussion so verstehst, dann hast Du sie nicht ver- standen. Es geht hier nicht um Durchsetzung sondern um Abwägung. > Sich > drum zu kümmern das die Änderungen konsistent überall bekannt, > akzeptiert und entsprechend geändert werden ist eine ganz andere Geschichte. Die aber bei der Aenderung des verbreitetsten amenity-Tags ebenso bedacht werden muss. Ginge es um amenity=wheelchair_lift, wäre die Lage wieder anders.. Für das Sommerloch habe ich übrigens noch ganz andere revolutionäre Ideen, wie z.B. das Aendern von amenity=vending_machine zu amenity= dispenser für Hundekottütenspender, da sie mMn *überhaupt* nichts mit vending oder gar machine zu tun haben... > Dem ist nichts mehr hinzuzufügen. Habe Flasche leer. Aber damit starte ich frühestens, wenn Deine Flasche wieder voll ist. :-> Gruss, Thomas _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
