Um es vorwegzuschicken: Ich bin nicht gegen die Einführung von Linienbündeln. Ich bin nur dagegen, dies ohne grafischen Editor zu tun.
Bernd Wurst <be...@bwurst.org> wrote: >Am 02.02.2012 21:32, schrieb Tirkon: >> Wenn man Linienbündel einführt oder über ein entsprechendes Proposal >> abzustimmen gedenkt, dann nicht ohne das JOSM Plugin mitzuliefern, mit >> dem all dies ausreichend visualisiert und grafisch editierbar wird. >> Außerdem gehört eine nicht nur für Computerfreaks verstehbare >> Gebrauchsanleitung des Plugins dazu. > >Das gehört sicherlich nicht zur Diskussion um den Vorschlag an sich. Wir >hatten noch nie zuerst ein fertiges Plugin und danach die Sinnfrage. Natürlich muss es neue Denkmodelle und Ideen geben. Man muss den einfachsten Weg finden, um ein gewisses Problem zu beschreiben. Und dieses einfachste und beste Modell entsteht natürlich nur iterativ durch die Schwarmintelligenz. Und dazu braucht es Diskussionen - Keine Frage. Mir geht es darum, dass hier womöglich ein Modell auf die Schnelle durchgewunken wird. Ich hatte daher in meinem Posting das Plugin vor eine Einführung und Abstimmung eines Modells gestellt, nicht vor das Diskutieren einer Sinnfrage. Mehr zum Plugin weiter unten. >> Möglicherweise bietet eine zukünftige API Features, die das Mappen von >> Linienbündeln vereinfachen. Wer sie also in OSM möchte, möge sich >> Gedanken machen, wie das geschehen könnte. Einen Vorschlag mache ich >> weiter unten. > >Nein, bitte nicht. >Die API muss so minimal wie möglich sein. Wir haben unsere primitiven >Datentypen und mit den Tags können wir daraus lustige Dinge machen. Aber >die API muss das alles nicht verstehen, nicht bewerten und auch nicht >beschränken. Die API kann dem Weg eine Richtung geben. Das empfindest Du offensichtlich nicht als Bewertung oder Beschränkung, sondern akzeptierst sie. Offensichtlich siehst Du einen Nutzen darin. Wenn dasselbe für Tags (und eventuell für Relationselemente) möglich ist, ist das keine Beschränkung, sondern die Aufhebung einer Beschränkung. Auch für Punkte wäre eine Richtungsangabe sinnvoll, z.B. bei Ortseingangsschildern mit beidseitig verschiedenen Beschriftungen. Derzeit braucht man dazu Relationen. Wenn das mit der API wesentlich einfacher ginge, könnte man auch hier darüber nachdenken. Überhaupt: Wenn es mit der API vergleichweise einfach ist, ansonsten nur kompliziert darstellbare und sehr oft gebrauchte Features zu implementieren, sollte man darüber nachdenken. Dabei sind - natürlich - penibelst Einschränkungen der Freiheit auszuschließen. >> Im OSM Wiki sind eine ganze Reihe ausformulierte Vorschläge zum Thema >> Linienbündel zu finden. Einige davon sind recht ähnlich zu diesem. >> Auch einen Workshop hat es schon gegeben: >> http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Workshops/Linienb%C3%BCndel > >Nein, da ist keiner dabei, der es erlaubt ein Tag für mehrere Spuren zu >definieren. >Die im Wiki genannten sind alle wesentlich komplexer und weniger >menschenlesbar. Ohne Frage auf den ersten Blick eine gute Idee! :-) Beim algorithmischen Zerlegen einer solchen Idee zeigt sich häufig, wie gut und flexibel sie wirklich ist. Insofern ist das Schreiben eines grafischen Editors sicherlich keine schlechte Gewährleistung dafür. >> Im Prinzip sind die Modelle daran gescheitert, dass so Getagtes auch >> maintained sein will. Unter Anderem müssen Linienbündel zunächst >> eingetragen aber vor Allem auch aktuell gehalten werden. Was nützen >> fehlleitende Spurassistenten? > >Mit dem Totschlagargument kann man jede neue Idee die ins Detail geht >kaputtreden. Die Linienbündel (mit Abstrichen auch den ÖPNV) sehe ich als einen bisher einmaligen Sonderfall in OSM. Von daher kann man nicht davon sprechen, dass so jede neue Idee totgeschlagen werden könnte oder sollte. Ich will das eingehender darlegen: Es stört kaum jemand Anderen, wenn man Bäume, Kanaldeckel, Vogelhäuschen oder Grashalme mappt. Es stört wenig, wenn da ein Tag nicht stimmt. Hier im Thread aber ist der zentrale Bereich des Straßennetzes betroffen, auf dem die meisten OSM Applikationen aufsetzen. Ohne Straßennetz hätte es OSM - zumindest mit der jetzigen gewaltigen Community Größe - nie gegeben. Hier ist man auf ein durchgehend stimmiges Netz angewiesen, wenn man Routenplaner und Navis auf dessen Grundlage beschicken will. Um das auch in der Fläche sicherzustellen, sind wir auf User vor Ort angewiesen, die ihre "Home"-Area auf dem Laufenden halten. Im Gegensatz zum falsch bezeichneten Baum, den man explizit ansteuern muss, stößt man Durchgehen eines Straßennetzes unweigerlich auf Linienbündel und muss diese maintainen. Und wenn man dann die User vor Ort, die allein einige zig Quadratkilometer zu betreuen haben, durch eine Verkomplizierung vom Maintaining ausschließt, wird es problematisch. Die Freiheit einer kleinen Gruppe von Abstimmenden steht hier gegen diejenige einer großen und hier nicht vertretenen Userschar, die ausgeschlossen und möglicherweise vergrault wird. Schon bei dem ÖPNV-Schema war das in ähnlicher Hinsicht problematisch, wenngleich man den ÖPNV noch ignorieren kann. Bei Linienbündeln geht das nicht mehr, weil sie kein Additiv mehr sind. Sie ERSETZEN vorhandene Wege und Kreuzungen und sie kommen nahezu in jedes Dorf. Wenn dann in diesem Ersatz im Gegensatz zu vorher Objekte schwieriger zu editieren sind, schließt man User aus. Hier wird - vergleichbar mit Wikipedia - dem User ein immer komplexer werdendes Regelwerk aufdoktruiert, dem er sich bei sinnvoller Mitarbeit an einem routinggerechten OSM nicht mehr entziehen kann. Wir haben Regionen, in denen weniger als die Hälfte der offiziellen Straßen gemappt sind. Wir dürfen nicht komplizierter werden. Wir haben nur sehr wenige Mapper, die OSM über Jahre treu bleiben. Ein verlorener Mapper kann hier den Verlust des Maintaining von zig Quadratkilometern bedeuten. Und wenn es nicht nur einer sondern viele sind, dann wiegt das schwerer als ein fehlender und häufig irreführender Linienassistent. >Was nützt es wenn sogar ich als Mapper lieber ein propietäres Navi >benutze weil das Fahrspuren anzeigen kann? Wenn uns die Mapper wegen steigender Komplexität davonlaufen, werden Deinem OSM-Navi nicht nur die Fahrspuren fehlen, sondern auch die Straßen. >> Um das sicherzustellen, müssen möglichst viele Mapper das Modell >> verstehen. Und das ist Problem Nummer 1. > >Ja, und da ist das hier diskutierte um Welten einfacher als die im Wiki >aufgeführten. IMO. >> Problem Nr. 2: [Die Mapper auf dem Land sind zu wenige] >> >> Problem Nummer 3 [die Mapper auf dem Land brauchen Luftbilder] > >Warum mappen wir eigentlich Briefkästen so lange auf dem Land noch >Straßen fehlen? Wie schon gesagt: Briefkästen sind ein Additiv und ignorierbar. Linienbündel ERSETZEN vorhandene Straßenteile. >Kümmere sich doch einfach jeder um die Vollständigkeit in seinem >Aktionsradius. Genau bei der Betreuung des Aktionsradius liegt das Problem, wie oben ausführlich beschrieben. >Jede komplexe Kreuzung die detailliert erfasst ist hilft >irgend einem Navi-Nutzer. Egal ob in der Stadt oder auf dem Land. Wenn >etwas falsch ist ist es falsch, das kann immer und überall passieren und >ist kein Grund neue Errungenschaften abzulehnen. Wenn der Linienassistent dem Projekt auf der anderen Seite mehr schadet, ist die Attributierung "Errungenschaft" in Frage gestellt. >> Problem Nummer 4 ist das Verwenden eines Modells, das man nicht bis zu >> Ende gedacht hat und zu Inkonsistenzen oder Nichtabbildbarkeit >> unbedachter Fälle führt. > >Wir haben in OSM recht viele Dinge die sehr einfach und konsequent sind >und damit nicht alle Eventualitäten direkt abbilden können. Das stört nicht. Man betrachte den ÖPNV in OSM. Hier existieren zig Modelle nebeneinander. Kein anderes Gebiet auf OSM ist derart chaotisch. Und warum? Weil ständig neue Modelle entwickelt wurden, die ein kleines bisschen mehr konnten als das vorige und anschließend von einer kleinen Userschaft, die das so verabredet hatte, genutzt wurde. Einige von diesen Modellen werden nur von wenigen Usern beherrscht und damit auch nicht maintained. Jeder befand sein Modell für das Beste und sah keinen Anlaas, nach Besserem und Umfassenderen zu suchen, bevor man es in den Einsatz schickt. Duchgewinkt wurde das von einer Handvoll Leute, die mit komplexeren Modellen kein Problem haben. Man darf nach nun einiger ins Land gegangenen Zeit wohl mit Fug und Recht behaupten, dass eine gewaltige Mehrheit von Mappern mit den Füßen gegen die ÖPNV Modelle abgestimmt hat und diese nicht annehmen. Die meisten zeichnen Bushaltestellenmaste nach wie vor als busstop (865 463 mal) ein und scheren sich nicht um die Modelle. Anders aber als beim ÖPNV sind Linienbündel nicht mehr ignorierbar. Wenn das nicht stört, dann können, dürfen und wollen in Zukunft immer weniger Mapper maintainen. Mapper denkt: "Wenn die Oberschlauberger da oben meinen, Alles verkomplizieren zu müssen und mich zwingen, es so zu machen, wie die es wollen, sollen die das in Zukunft selbst tun." Ich prognostiziere, dass bei einem "Weiter so" und "Immer komplizierter" OSM die Mapper genau so weglaufen werden, wie Wikipedia derzeit die Autoren. Dort hat eine Handvoll computeraffiner Insider gemerkt, die bisher die Regeln gemacht haben, dass ihnen die Leute weglaufen - und zwar unter Anderem deswegen, weil der für sie ach so einfache Editor von vielen eben nicht als so einfach angesehen wird. Die Informatiker hatten aufgrund Ihres Komplexitätsverständnisses über Software und Regeln die Macht und das Sagen - auch über die Inhalte, von denen sie keine Ahnung hatten. Inzwischen stimmen die Autoren eben mit den Füßen ab und bröckeln nach und nach weg. Jetzt widmet sich eine Schar von Ihnen ausschließlich den Editor, um das zu verhindern. Man bedenke: Mapper sind keine Informatiker! Was für Euch leicht und durchsichtig ist, ist es für viele Mapper nicht. Ich kann daher nur appellieren: Beschließt kein komplexes Modell zum Straßennetz ohne ein grafisches Editor-Plugin. >> Problem Nummer 5 ist die Orientierung an der Straßenrichtung mit >> forward und backward. > >Du hast schon wieder vergessen, dass die momentan gängigen Editoren >dieses Problem erkennen und selbsttätig korrigieren? ... nur bei Ihnen bekannten Richtungsangaben. Wenn für Tags eine vom Weg unabhängige Richtung möglich wäre, kann man sie in jede Dimension beziehen und neue einführen, ohne dass die Editoren jeden einzelnen kennen müssen. Beispiele neben vorwärts und rückwärts: oben, unten, rechts, links, vorn, hinten, bergan, bergab etc. Wegerichtungsänderungen bleiben dann ohne Folgen. Der Editor muss nur noch bei Splittings und Vereinigungen mitdenken und braucht hierzu kein Sammelsurium von Tags zu kennen. >> Wenn man Linienbündel einführt oder über ein entsprechendes Proposal >> abzustimmen gedenkt, dann nicht ohne das JOSM Plugin mitzuliefern, mit >> dem all dies ausreichend visualisiert und grafisch editierbar wird. >> Außerdem gehört eine nicht nur für Computerfreaks verstehbare >> Gebrauchsanleitung des Plugins dazu. > >Musste deine Mail eine gewisse Mindestlänge haben oder warum musst du >dich hier selbst zitieren? Ich habe bei einer Umstellung schlicht vergessen, den Schluss zu löschen. Ich denke, solche Versehen passieren jedem mal. Leider ist hier kein Wiki, in dem ich das hätte korrigieren können. _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
