Re: [Talk-de] Neue Idee für's lanes-mapping
> Könnte man es nicht "Spur-Angaben" oder so ähnlich nennen? Der Ausdruck passt meiner Meinung nach sehr gut. Es ist auch nur ein kleiner Schritt, er bringt uns aber - glaube und hoffe ich - sehr viel. Vg, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Idee für's lanes-mapping
Hallo. Am 04.02.2012 14:46, schrieb Martin Koppenhoefer: >> > 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. > ich dachte, der hier diskutierte Vorschlag wäre eine Ergänzung zum > bisherigen, baulich getrennte Wege würden ja nach wie vor mit eigenem > Way gemappt, so dass sich da nicht so viel ändern wird, oder sehe ich > das falsch? Das ist ja in meinen Augen grade der elegante Punkt an diesem Vorschlag: Es ist wirklich harmonisch mit bestehenden Daten zu kombinieren. Beispiel: Wenn auf mindestens einer Spur LKW erlaubt sind, kann man zusätzlich die Straße pauschal als "hgv=yes" markieren weil der LKW da durch darf. Details dann für denjenigen der es auswerten kann. Zudem finde ich den Begriff "Linienbündel" hier eine seltsame Wortwahl. Diesen Begriff habe ich zum ersten Mal gehört als jemand eine leicht weltfremde Idee skizzierte wie man eine Straße mit allen dazugehörigen Elementen mit zig Linien darstellen kann die man dann mit Relationen wieder bündelt. Der Begriff lässt mich immer glauben, dass du (Tirkon) diese verschiedenen Herangehensweisen zu sehr in einen Topf wirfst. Ich hatte den Vorschlag so verstanden dass es wirklich nur darum geht, demjenigen der es nutzen kann und will eine Möglichkeit zu geben, die unterschiedlichen Spuren einer Straße darzustellen bzw. zu differenzieren. Es geht also nicht darum, mit diesem Schema jedes halbwegs lineare Element von den Liniendicken bis zum Bordstein-Material oder der Allee-Baumsorte abzubilden wie es bei anderen, komplexeren Vorschlägen möglich wäre. Alleine die Bezeichnung "Linienbündel" lässt etwas einfaches gleich kompliziert erscheinen. Könnte man es nicht "Spur-Angaben" oder so ähnlich nennen? Gruß, Bernd -- Pessimismus wird nur von den Optimisten verbreitet. Die Pessimisten sparen ihn für schlechtere Zeiten auf. - Gabriel Laub signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Idee für's lanes-mapping
Am 04.02.2012 um 14:46 schrieb Martin Koppenhoefer : > ich dachte, der hier diskutierte Vorschlag wäre eine Ergänzung zum > bisherigen, baulich getrennte Wege würden ja nach wie vor mit eigenem > Way gemappt, so dass sich da nicht so viel ändern wird, oder sehe ich > das falsch? Du siehst das richtig. Es soll nur die Möglichkeit ergänzt werden Eigenschaften für Spuren (sozusagen Teile der Wege) zu definieren. Daraus ergeben sich dann automatisch einige neue Möglichkeiten, ohne groß etwas ändern zu müssen. Vg, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Idee für's lanes-mapping
Am 4. Februar 2012 00:46 schrieb Tirkon : > Bernd Wurst wrote: >>> 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. >>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. +1 > Die API kann dem Weg eine Richtung geben. es ist das Datenmodell, das eine Richtung kennt, die ergibt sich automatisch, weil ein way eine geordnete Reihe von nodes ist. Die API muss die Reihenfolge nur beibehalten, sie muss sie nicht prüfen und z.B. fragen: "Du hast eine Straße umgedreht, die einen oneway-tag hatte, willst Du das wirklich?". > Wenn > dasselbe für Tags (und eventuell für Relationselemente) möglich ist, > ist das keine Beschränkung, sondern die Aufhebung einer Beschränkung. ist doch bereits umgesetzt: die Reihenfolge von Relationselementen wird beibehalten, das war am Anfang nicht garantiert (soweit ich mich erinnere). Tags haben dann eine Richtung, wenn die Mapper sie so verstehen. Dazu braucht man auch keine gesonderten API-Funktionen. > Auch für Punkte wäre eine Richtungsangabe sinnvoll, z.B. bei > Ortseingangsschildern mit beidseitig verschiedenen Beschriftungen. ich mache da einfach 2 Schilder, je eins je die Richtung, für die es gilt (neben die Straße, sonst wäre m.E. nicht klar, welche Richtung gemeint ist, habe das aber auch oft schon anders gesehen), analog zu den anderen Verkehrschildern wie maxspeed, maxweight, etc. Man könnte aber auch Punkten zusätzlich eine Richtung mittaggen, z.B. vector=NNE (nord-nordost). Oder vector=3h (3 Uhr). Oder vector=45° (wenn man z.B. festlegt, dass Norden 0 Grad ist und man in oder gegen den Uhrzeiger zählt). Persönlich wäre mir die Uhrangabe am liebsten, finde ich schön einfach und eindeutig. > Derzeit braucht man dazu Relationen. braucht man nicht. > 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. wenn sich das durchsetzen wird, dann werden vermutlich die gängigen Editoren wie JOSM, PL2 und Merkaartor das irgendwann auch grafisch umsetzen, aber als Voraussetzung für die Einführung würde ich das nicht sehen. Als die Relationen eingeführt wurden gab es praktisch keine Unterstützung dafür und die Multipolygone werden immer noch nicht wirklich userfreundlich (=transparent, indem ein Area-Datentyp "simuliert" wird) präsentiert, trotzdem werden sie von vielen Mappern verwendet. > Die Linienbündel (mit Abstrichen auch den ÖPNV) sehe ich als einen > bisher einmaligen Sonderfall in OSM. ich sehe das als einen weiteren Baustein im Puzzle, der zudem m.E. nicht besonders interessant ist, weil Spurassistenten eigentlich nur für Autofahrer relevant sind. Andere Dinge, die wir mappen (z.B. Routen, die Straßen- und Adressrelationen, ÖPNV, die Küstenlinie, Multipolygone, zeitlich oder anders begrenzte Beschränkungen, etc.) sind ebenfalls jeweils Sonderfälle, die jeweils eigene Mechanismen und Regeln haben. > Schon bei dem ÖPNV-Schema war das in ähnlicher Hinsicht problematisch, > wenngleich man den ÖPNV noch ignorieren kann. kann man eigentlich nicht. > 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. ich dachte, der hier diskutierte Vorschlag wäre eine Ergänzung zum bisherigen, baulich getrennte Wege würden ja nach wie vor mit eigenem Way gemappt, so dass sich da nicht so viel ändern wird, oder sehe ich das falsch? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Idee für's lanes-mapping
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
Re: [Talk-de] Neue Idee für's lanes-mapping
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 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 be
Re: [Talk-de] Neue Idee für's lanes-mapping
Bis auf die Mindestlänge-der-Mail ein klares +1 ! Ganz meine Meinung! Am 03.02.2012 um 06:21 schrieb Bernd Wurst : > Hallo Tirkon. > > 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. > > >> 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. > > >> 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. > > >> 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. > > Was nützt es wenn sogar ich als Mapper lieber ein propietäres Navi > benutze weil das Fahrspuren anzeigen kann? > > >> 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? > Kümmere sich doch einfach jeder um die Vollständigkeit in seinem > Aktionsradius. 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. > > >> 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. > > >> 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? > > >> 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? > > Gruß, Bernd > > -- > Wenn man das Licht schnell genug ausmacht, kann man sehen wie die > Dunkelheit aussieht. > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Idee für's lanes-mapping
Hallo Tirkon. 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. > 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. > 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. > 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. Was nützt es wenn sogar ich als Mapper lieber ein propietäres Navi benutze weil das Fahrspuren anzeigen kann? > 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? Kümmere sich doch einfach jeder um die Vollständigkeit in seinem Aktionsradius. 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. > 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. > 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? > 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? Gruß, Bernd -- Wenn man das Licht schnell genug ausmacht, kann man sehen wie die Dunkelheit aussieht. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Idee für's lanes-mapping
Martin Vonwald wrote: >http://lists.openstreetmap.org/pipermail/talk-at/2012-February/003769.html 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. 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. 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 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? Um das sicherzustellen, müssen möglichst viele Mapper das Modell verstehen. Und das ist Problem Nummer 1. Problem Nr. 2: Auf dem Lande haben wir nicht genug Mapper, um alle Straßen zu erfassen, geschweige Spurassistenten aktuell zu halten. Darüber kann man vielleicht nachdenken, wenn Straßen und Adressen so ziemlich komplett sind und der Mapper ansonsten weniger zu tun hat. Außerdem wird die Lizenzbereinigung neue Löcher reißen, die Mapperressourcen bindet und binden wird. IMHO sollte man noch einige Zeit ins Land gehen lassen, bevor man Linienbündel mappt. Problem Nummer 3 sind hierfür nicht taugliche Luftbilder. Möglicherweise bringt die in einigen Monaten erwartete Auflösungs-Verbesserung bei Bing Abhilfe. Es bleibt aber dann die Frage, wie oft diese aktualisiert werden. Schon heute existiert das Problem, dass aktuelle OSM Karten auf den Zustand eines Jahrzehnt-veralteten Luftbildes zurückgemappt werden. 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. Auch deshalb ist die Forderung sinnvoll, einen grafischen Editor vor einer Abstimmung mitzuliefern. Denn bei dessen Programmierung tun sich viele Mängel und Konkretisierungen eines theoretischen Modells auf und es kann nachgebessert werden. Die Existenz einer allgemeinverständlichen Gebrauchsanleitung bietet die Gewähr, dass das Modell von vielen Mappern nachvollzogen und angewendet werden kann. Erst nach einem erfolgreichen Betatest des Plugins und seiner Anleitung sollte man das Modell abstimmen lassen. Problem Nummer 5 ist die Orientierung an der Straßenrichtung mit forward und backward. Da braucht nur ein Anfänger versehentlich oder versuchshalber die Richtung der Straße zu ändern und schon stimmt nichts mehr. Und nichts deutet für ihn auf die Wichtigkeit der Straßenrichtung hin. Diese falsche Richtung ist nur sehr schwer und nur mit sehr eingehender Ortskenntnis zu erkennen. Beispielsweise muss man wissen, dass ein Maxspeed nur in einer Richtung existiert und in welcher. Bezogen auf den Spurassistenten muss man die vorhandenen Spuren beider Richtungen kennen. Und selbst dann springt der Fehler selten ins Auge. Man muss sich schon eingehend auf eine Einzelheit einlassen. Ich hoffe daher darauf, dass in der nächsten zukünftigen API die Richtung für jedes Tag unabhängig von der Straßenrichtung angegeben werden kann, damit wenigstens dieses Problem vom Tisch ist. Dies könnte beispielsweise so geschehen, dass man ID oder Koordinaten des ersten und letzten Nodes eines Weges in der Reihenfolge der gewünschten (optionalen) Richtung des Tags speichert. Editoren müssen bei Splittings oder Vereinigungen entsprechende Folge-Änderungen automatisch mit erledigen und verifizieren. Möglicherweise bietet eine zukünftige API weitere Features, die das Mappen, Speichern und den Umgang mit Linienbündeln vereinfachen. Wer sie also in OSM sehen möchte, möge sich Gedanken machen, wie das geschehen könnte. 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. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Idee für's lanes-mapping
Am 02.02.2012 um 19:52 schrieb aighes: > Hi, > ich gehe mal davon aus, dass es für das finale Schema dann auch ein PlugIn > geben wird. Nur halte ich es für überflüssige Arbeit, zu jedem Vorschlag ein > fertiges PlugIn zu erstellen. +1 Ganz klar, das macht erst Sinn, wenn es fertig ist … Wollte das nur mal so generell als Idee in den Raum geworfen haben ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Idee für's lanes-mapping
> ich gehe mal davon aus, dass es für das finale Schema dann auch ein PlugIn > geben wird. Nur halte ich es für überflüssige Arbeit, zu jedem Vorschlag ein > fertiges PlugIn zu erstellen. Sicher nicht - das ist ja noch nicht mal ein Vorschlag, das ist ja gerade erstmal eine Idee ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Idee für's lanes-mapping
> Klar, nur mit Plugins wäre es für den "otto-normal-mapper" auf jeden Fall > angenehmer, so wie ich zum Beispiel auch lieber den Verkehrsschild-Assistent > nutze als mir das alles selber zusammen zu suchen ;) Nicht nur du verwendest den gerne ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Idee für's lanes-mapping
Hi, ich gehe mal davon aus, dass es für das finale Schema dann auch ein PlugIn geben wird. Nur halte ich es für überflüssige Arbeit, zu jedem Vorschlag ein fertiges PlugIn zu erstellen. Henning Am 02.02.2012 19:43, schrieb Dennis: Klar, nur mit Plugins wäre es für den "otto-normal-mapper" auf jeden Fall angenehmer, so wie ich zum Beispiel auch lieber den Verkehrsschild-Assistent nutze als mir das alles selber zusammen zu suchen ;) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Idee für's lanes-mapping
Hi Am 02.02.2012 um 19:35 schrieb Martin Vonwald: > > Plugins für die gebräuchlichsten Editoren wären sicher nett - egal wie > man dieses Problem löst. Wichtig ist aber, dass es trotz allem auch > ohne Plugin lesbar und verständlich ist. Klar, nur mit Plugins wäre es für den "otto-normal-mapper" auf jeden Fall angenehmer, so wie ich zum Beispiel auch lieber den Verkehrsschild-Assistent nutze als mir das alles selber zusammen zu suchen ;) Gruß Dennis ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Idee für's lanes-mapping
> Könnte mir dann jedoch für das Userinterface vorstellen, dass es cool wäre > einen "Fahrspurassistenten" > zum Taggen zu haben, sozusagen ein Verkehrsschild, in dem man per Drag&Drop > für die vorher angegebene > Anzahl an Spuren Pfeile auf die jeweilige Spur zieht, die dann links, > links/gerade, gerade, gerade/rechts, > rechts bedeuten :-) > Ideal kann man da dann auch noch Verbote/Gebote und > Geschwindigkeitsbegrenzungen genau so per Drag&Drop drauf ziehen :-) Plugins für die gebräuchlichsten Editoren wären sicher nett - egal wie man dieses Problem löst. Wichtig ist aber, dass es trotz allem auch ohne Plugin lesbar und verständlich ist. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Idee für's lanes-mapping
Hi, Am 02.02.2012 um 17:17 schrieb Martin Vonwald: >> Schwierig (wenngleich aber logisch und notwendig) ist die Unterscheidung >> von Komma und Semikolon, das enthält Potenzial für fiese Tippfehler und >> destruktive Verschlimmbesserungen durch Bots. ;-) > > Absolut korrekt, aber die Alternativen sind rar. Es muss ein einfaches, > halbwegs intuitives Zeichen sein und der Strichpunkt ist nun schon mal > Standard für die Trennung mehrerer Werte pro Schlüssel und daher nicht > wegzudiskutieren. Ich dachte zuerst an einen Doppelpunkt zur Trennung der > Werte pro Spur, aber das ist auch nicht besser. Also ich finde es gut, wenn es irgendwie getaggt werden kann, selber hab ich da aber nicht die Ahnung, wie man das am Besten kann. Könnte mir dann jedoch für das Userinterface vorstellen, dass es cool wäre einen "Fahrspurassistenten" zum Taggen zu haben, sozusagen ein Verkehrsschild, in dem man per Drag&Drop für die vorher angegebene Anzahl an Spuren Pfeile auf die jeweilige Spur zieht, die dann links, links/gerade, gerade, gerade/rechts, rechts bedeuten :-) Ideal kann man da dann auch noch Verbote/Gebote und Geschwindigkeitsbegrenzungen genau so per Drag&Drop drauf ziehen :-) Gruß Dennis. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Idee für's lanes-mapping
> Boah, nee! > Du hast höchstens ein paar Tags mehr für Features die bisher nicht eingetragen werden können (z.B. Abbiegespuren). Alle anderen Feature haben genausoviele Tags wie bisher. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Idee für's lanes-mapping
On Thu, Feb 2, 2012 at 4:37 PM, Martin Vonwald wrote: > Vielleicht hier auch interessant: > http://lists.openstreetmap.org/pipermail/talk-at/2012-February/003769.html Boah, nee! Und am Ende hat man dann 50 Tags an einem Way, oder was? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Idee für's lanes-mapping
> Schwierig (wenngleich aber logisch und notwendig) ist die Unterscheidung > von Komma und Semikolon, das enthält Potenzial für fiese Tippfehler und > destruktive Verschlimmbesserungen durch Bots. ;-) Absolut korrekt, aber die Alternativen sind rar. Es muss ein einfaches, halbwegs intuitives Zeichen sein und der Strichpunkt ist nun schon mal Standard für die Trennung mehrerer Werte pro Schlüssel und daher nicht wegzudiskutieren. Ich dachte zuerst an einen Doppelpunkt zur Trennung der Werte pro Spur, aber das ist auch nicht besser. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Idee für's lanes-mapping
Hallo. Am 02.02.2012 16:37, schrieb Martin Vonwald: > Vielleicht hier auch interessant: > http://lists.openstreetmap.org/pipermail/talk-at/2012-February/003769.html Ich finde das ist der erste Ansatz zu diesem Thema der einfach genug ist um das Zeug zum "so machen wir's" zu haben. Danke für den Vorschlag! Schwierig (wenngleich aber logisch und notwendig) ist die Unterscheidung von Komma und Semikolon, das enthält Potenzial für fiese Tippfehler und destruktive Verschlimmbesserungen durch Bots. ;-) Gruß, Bernd -- Das Ärgerlichste in dieser Welt ist, daß die Dummen todsicher und die Intelligenten voller Zweifel sind. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Neue Idee für's lanes-mapping
Vielleicht hier auch interessant: http://lists.openstreetmap.org/pipermail/talk-at/2012-February/003769.html ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
