Hi, klinke mich hier nun doch nochmal ein …
Am 04.02.2012 um 00:46 schrieb Tirkon: >>> 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. > > Ü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. +1 >>> 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. Zum Pflegen des Straßennetzes in der Fläche sind die User auch von Nöten … Ob die nun ein Linienbündel oder eine "normale Straße" pflegen, ist meiner Meinung nach egal, solange das Pflegen des Bündels ähnlich einfach ist. Von daher geh ich damit konform, dass vor dem Einführen einer entsprechenden Entwicklung auf jeden Fall ein entsprechendes Tool für den Normal-Mapper nötig ist. >> 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. Also sollten nach Möglichkeit beide Dinge kombiniert werden, eine vereinfachte Bedienung der Editoren, trotz höherer Komplexität, so dass die Otto-Normal- Verbraucher, die gerne einen Fahrspurassistenten hätten, diesen auch selber durch entsprechendes Mapping ermöglichen können. > Wie schon gesagt: Briefkästen sind ein Additiv und ignorierbar. > Linienbündel ERSETZEN vorhandene Straßenteile. Vielleicht sollte man daran ansetzen? Ich kenne das Konzept der Linienbündel nicht, hab da noch keine Zeit gefunden, mich einzulesen, aber kann man nicht beides parallel nutzbar machen? >>> 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. +1 Das mit dem ÖPNV finde ich als "nicht-Informtatiker" schon arg grenzwertig … Gruß Dennis _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
