Re: [Talk-de] Routerhärtetest - Topologie oder STVO?
Martin Koppenhoefer schrieb: Am 26. Juni 2009 17:15 schrieb Heiko Jacobs heiko.jac...@gmx.de: Schaun mer mal. Im Moment lerne ich gerade viel bzgl. Routing dazu anhand der Brücke, diese Fortbildungsmaßnahme will ich mir durch spontanes zurücktaggen nicht verbauen ;-) m.E. sollte man solche autodidaktischen Versuche offline machen, und nicht in den Daten aller löschen, mal sehen was passiert, und wenn sich einige Gegenstimmen mit berechtigten Argumenten melden, weilterhin Beharrungsvermögen zeigen. Du vergisst bei dem Thema ständig, dass die cycleway=*-Variante eine derzeit zulässige Variante ist, auch wenn Dir diese Variante nicht gefällt. Solange sie zulässig ist, sollte alles getan werden, die Unterstützung durch Router zu verbessern. Entweder brauchen wir völlig neue Renderer, ansonsten können wir vernünftiges Radwegerendering vergessen (in beiden Modellen, einseitige im einen Modell, nichtüberlappend im anderen Modell) solange der Radweg oben liegt, finde ich die Überlappung nicht schlimm ... was eine ziemlich radfahrzentrierte Sichtweise ist. Ein Autofahrer dürfte sich durch eine solche Darstellung ziemlich gestört fühlen... Für die opencyclemap ist das Problem so meinetwegen gelöst, aber für die halbwegs an alle gerichtete slippy map geht das so nicht. So wie bisher ist es aber auch nicht optimal... und bin mir nicht sicher, ob eine verschobene Geometrie in allen Fällen vernünftiger wäre. Schon eher sicher bin ich mir, dass ich in einem Radwege-rendering eher die Straße verschieben würde als den Radweg. Auch das ist ein eziemlich radfahrzentrierte Sicht, die schon dann nicht mehr funktioniert, wenn beiderseits Radwege existieren... Deswegen verdrängt man normalerweise von der Mitte her. Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routerhärtetest - Topologie oder STVO?
Am 29. Juni 2009 14:54 schrieb Heiko Jacobs heiko.jac...@gmx.de: Du vergisst bei dem Thema ständig, dass die cycleway=*-Variante eine derzeit zulässige Variante ist, auch wenn Dir diese Variante nicht gefällt. Solange sie zulässig ist, sollte alles getan werden, die Unterstützung durch Router zu verbessern. Zulässig ist alles, was nicht schadet, diese Grenze hast Du hier überschritten. Das übersiehst Du. Ich habe natürlich überhaupt nichts dagegen, das Routing zu verbessern, aber bitte nicht dadurch, dass der Leidensdruck durch Zerstören funktionierender Lösungen erhöht wird. Entweder brauchen wir völlig neue Renderer, ansonsten können wir vernünftiges Radwegerendering vergessen (in beiden Modellen, einseitige im einen Modell, nichtüberlappend im anderen Modell) solange der Radweg oben liegt, finde ich die Überlappung nicht schlimm ... was eine ziemlich radfahrzentrierte Sichtweise ist. wenn Du Dir den Post ansiehst, ging es mir um Radfahrerkarten. Bei den anderen Karten liegt der cycleway AFAIR immer unten. und bin mir nicht sicher, ob eine verschobene Geometrie in allen Fällen vernünftiger wäre. Schon eher sicher bin ich mir, dass ich in einem Radwege-rendering eher die Straße verschieben würde als den Radweg. Auch das ist ein eziemlich radfahrzentrierte Sicht, ja, ist doch berechtigt, wenn wir von Fahrradkarten sprechen, oder? die schon dann nicht mehr funktioniert, wenn beiderseits Radwege existieren... kommt auf die Straßenbreite und die Zoomstufe an. In niedrigen Zoomstufen könnte auch die Mittellinie beider Radwege interpoliert werden und von dieser aus jeweils ein Offset nach aussen (geht ja aber sowieso derzeit nicht). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routerhärtetest - Topologie oder STVO?
Am 26. Juni 2009 17:15 schrieb Heiko Jacobs heiko.jac...@gmx.de: Schaun mer mal. Im Moment lerne ich gerade viel bzgl. Routing dazu anhand der Brücke, diese Fortbildungsmaßnahme will ich mir durch spontanes zurücktaggen nicht verbauen ;-) m.E. sollte man solche autodidaktischen Versuche offline machen, und nicht in den Daten aller löschen, mal sehen was passiert, und wenn sich einige Gegenstimmen mit berechtigten Argumenten melden, weilterhin Beharrungsvermögen zeigen. dann näher spezifiziert z.B. für die halbe Rheinbrücke (andere Hälfte negativ, 0 als Mite): 0.segregrator=crash_barrier 1.landuse=green 1.width=0.5 2.lane=trunk 2.width=3 3.segregrator=dashed_line 4.lane=trunk 4.width=3 5.segregrator=dashed_line 6.lane=trunk 6.width=3 2-6.surface=asphalt 7.segregrator=curb 7.segregrator=crash_barrier 8.lane=cycleway 8.foot=no 8.width=1.5 9.segregator=solid_line 10.lane=footway 10.bicycle=no 10.width=1.5 11.segregrator=handrail 12.water=deep ;-) ich finde man sieht an diesem Beispiel schon, dass das nur schwer funktionieren kann: viel zu unübersichtlich, schreckt die meisten schon beim Anblick ab und spielt die Stärken unserer _Geo_-datenbank (grafische Eingabe und Darstellung im Editor) nicht aus. Oder man macht alles als separaten way: - Das Grün in der Mitte als area, die Leitplanke darauf als line - jede Fahrspur einzeln, wie die gestrichelte Linie dazwischen - Leitplanke zwischen Radweg und Fahrbahn - Radweg - Gehweg - ... ... und packt alles in eine Relation Straßenraum zusammen, in der wiederum womöglich durchnumeriert werden muss, damit man weiß, was neben was liegt etc. ja, m.E. in diese Richtung könnte man das weiter verfeinern, auch wenn die Daten viele Zwecke gar nicht so genau gebraucht werden. könnte man per Relation gleich die ganze Brücke erfassen anstatt dass wie heute 4 separate Brücken gezeichnet werden (den Nachteil des Separat-Modells habe ich ja ganz vergessen ;-) ) ja, die Information, dass es sich um eine Brücke handelt, und nicht um 4 parallele ist sicher wichtig und sollte auch in Zukunft mal irgendwann abgebildet sein (z.B. durch eine zusammenfassende Relation). Entweder brauchen wir völlig neue Renderer, ansonsten können wir vernünftiges Radwegerendering vergessen (in beiden Modellen, einseitige im einen Modell, nichtüberlappend im anderen Modell) solange der Radweg oben liegt, finde ich die Überlappung nicht schlimm und bin mir nicht sicher, ob eine verschobene Geometrie in allen Fällen vernünftiger wäre. Schon eher sicher bin ich mir, dass ich in einem Radwege-rendering eher die Straße verschieben würde als den Radweg. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routerhärtetest - Topologie oder STVO?
Moin, Schaun mer mal. Im Moment lerne ich gerade viel bzgl. Routing dazu anhand der Brücke, diese Fortbildungsmaßnahme will ich mir durch spontanes zurücktaggen nicht verbauen ;-) m.E. sollte man solche autodidaktischen Versuche offline machen, und nicht in den Daten aller löschen, mal sehen was passiert, und wenn sich einige Gegenstimmen mit berechtigten Argumenten melden, weilterhin Beharrungsvermögen zeigen. sein Posting hat mich sehr verärgert. Da wurde eine Menge Text in die Mailingliste eingestellt, ohne dass es zu einer Verbesserung des Zustandes gekommen wäre. @Heiko: Könntest Du die Änderungen rückgängig machen? Ich möchte ungern selbst tätig werden müssen. Deine Routerhärtetests kannst Du auch mit einer privaten OSM-Datei ganz hervorragend durchführen, bzw. Dir andere Ecken suchen, in denen cycleway=track vergeben ist. Auf jeden Fall braucht es dazu keine Brücke, und schon gar nicht muss es die Karlsruher Rheinbrücke sein. [...] könnte man per Relation gleich die ganze Brücke erfassen anstatt dass wie heute 4 separate Brücken gezeichnet werden (den Nachteil des Separat-Modells habe ich ja ganz vergessen ;-) ) ja, die Information, dass es sich um eine Brücke handelt, und nicht um 4 parallele ist sicher wichtig und sollte auch in Zukunft mal irgendwann abgebildet sein (z.B. durch eine zusammenfassende Relation). Das Abbilden von Brücken ist generell schwierig (von einfachen Bauwerken mal abgesehen). Das ist aber kein Argument dafür, den Radweg an die Straße 'drankleben zu wollen. Denn es ist auch dort schwierig, wo es um Straße und Gleise u.ä. geht. highway=tertiary, railway=track? Wohl kaum. Gruß, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routerhärtetest - Topologie oder STVO?
Moin Kam die Tage nicht zu ausschweifenden Antworten, daher erst heute ;-) Die Rheinbrücke ist ein Spezialfall, da ist Streit vorprogrammiert. In der Tat ;-) Aber ich sehe es so wie Sven, Martin und Du: Speziell an der Rheinbrücke bin ich der Meinung, dass es bei getrennten Wegen bleiben sollte. Und das sollte Heiko respektieren. Wenn die Diskussion hier nicht dazu führt, dass in Potlatch fleissig die Taste »u« gedrückt wird, war sie, äh, vergebens :) . Schaun mer mal. Im Moment lerne ich gerade viel bzgl. Routing dazu anhand der Brücke, diese Fortbildungsmaßnahme will ich mir durch spontanes zurücktaggen nicht verbauen ;-) Heiko möchte, soweit ich ihn verstehe, gerne die Radwegesituation in unseren Daten verbessern. Das ist mehr als wünschenswert. Das ist irgendwo ein mittel- bis langfristiges Ziel, ja. Kurzfristig habe ich mir schon abgeschminkt ;-) Vor diesem Hintergrund stellt sich die Frage, was wir primär abbilden wollen: Die Topologie (Hier ist ein extra Radweg) oder die STVO (Hier ist ein straßenbegleitender Radweg). Da ich das Projekt viel mehr als Geodatenbank und weniger als nur ein (Staßen)kartenprojekt auffasse, komme ich zu dem Schluß, dass primär die Topologie und sekundär die STVO abgebildet werden sollte. Beides gehört irgendwo zusammen. Die StVO (und Waldgesetze etc.) hat einen Einfluss darauf, wer wo fahren darf. Nur mit dieser kommt man in speziellen Fällen zu einer korrekten Topologie bspw. für Radfahrer. Und es hängt auch von der Definition der Topologie ab, wann sie korrekt abgebildet ist oder nicht. Bspw. bei highway=path foot=designated bicycle=designated segregated=yes highway=trunk lanes=3 haben wir ja in klein die selbe Topologie für diesen Weg, wie in groß für highway=trunk cycleway=yes d.h. man fasst was zusammen und betrachtet diese dann topologisch als Einheit Bordsteinweg oder Fahrbahn im kleinen oder Straße im großen. Unsere Daten verfeinern sich immer mehr. Manche beschreiben das mit Zumüllen der Datenbank. Ich sehe dem relativ gelassen entgegen. Im Falle eines straßenbegleitenden Radweges heißt das, dass jemand auch den Grünstreifen zwischen Fahrbahn und Radweg einzeichnen können soll. Eine gute Sache, trotz der Fragen (speziell bezüglich des Renderings) die das aufwirft. Rendern würde nur in höchsten Vergrößerungen Sinn machen... Ich persönlich komme daher zu dem Schluss, dass in einer Geodatenbank die Topologie wichtiger ist als die STVO, die wie eine Glasglocke über die Topologie gestülpt ist. Relationen sind eine umständlich zu handhabende Sache. Dennoch tendiere ich aus obigen Gründen dazu, dass die STVO durch eine Relation zwischen dem Radweg und der Straße abgebildet werden sollte, so ähnlich wie das ja auch bei Abbiegeverboten gehandhabt wird. Man könnte eigentlich jedes Modell erweitern. Im Straßenraum-Modell generalisiert: highway=trunk cycleway=track dann näher spezifiziert z.B. für die halbe Rheinbrücke (andere Hälfte negativ, 0 als Mite): 0.segregrator=crash_barrier 1.landuse=green 1.width=0.5 2.lane=trunk 2.width=3 3.segregrator=dashed_line 4.lane=trunk 4.width=3 5.segregrator=dashed_line 6.lane=trunk 6.width=3 2-6.surface=asphalt 7.segregrator=curb 7.segregrator=crash_barrier 8.lane=cycleway 8.foot=no 8.width=1.5 9.segregator=solid_line 10.lane=footway 10.bicycle=no 10.width=1.5 11.segregrator=handrail 12.water=deep ;-) Oder man macht alles als separaten way: - Das Grün in der Mitte als area, die Leitplanke darauf als line - jede Fahrspur einzeln, wie die gestrichelte Linie dazwischen - Leitplanke zwischen Radweg und Fahrbahn - Radweg - Gehweg - ... ... und packt alles in eine Relation Straßenraum zusammen, in der wiederum womöglich durchnumeriert werden muss, damit man weiß, was neben was liegt etc. ... oder macht Mischlösungen: - die 2 Fahrbahnen als je ein way, aber mit spurabhängigen tags, evtl. wie oben, und den Geh- und Radweg als 2 ways, auch ggfs. wieder mit spurabhängigen tags für Geh- und Radweg. Ich bin daher auch kein Freund davon, einen Weg zu zerhaken, nur um eine Geschwingigkeitsbeschränkung (oder auch eine einfache Brücke) zu modellieren. Da man Relationen nun sortieren kann (in potlatch anscheinend noch nicht?) wäre der Vorschlag, der kürzlich zu lesen war von irgendwem (vergessen, wer's war), mit Relationen von Knoten zu Knoten für bspw. Brücken statt unterteiltem way eine nette Idee. Router brauchen diese Infos nicht, Renderer könnten damit evtl. eines Tages besser zeichnen. Mit node 1 role=Fahrbahn1 node 2 role=Fahrbahn1 node 3 role=Fahrbahn2 node 4 role=Fahrbahn2 node 5 role=Geh-Radweg ... könnte man per Relation gleich die ganze Brücke erfassen anstatt dass wie heute 4 separate Brücken gezeichnet werden (den Nachteil des Separat-Modells habe ich ja ganz vergessen ;-) ) Die Frage ist: was passiert, wenn der way auf der Brücke durch weitere Knoten verfeinert wird, dann fehlt der ja in einer Nur-Node-Relation... Wäre die Unterstützung für Relationen in unseren
Re: [Talk-de] Routerhärtetest - Topologie oder STVO?
Am Dienstag 23 Juni 2009 22:59:57 schrieb Christoph Eckert: ich möchte anmerken, dass mir die Brücke nicht gehört. Ich wende mich nicht dagegen, dass Heiko dort editiert und Änderungen vorgenommen hat. Ich Natürlich nicht. Ich verändere auch ab und zu Dinge, die Andere angelegt haben. Vor gravierenden Lösch- bzw. Umtagaktionen schreibe ich dem Anderen aber üblicherweise vorher oder parallel eine erklärende Mail, ggf. kann man dann darüber diskutieren. möchte vorsichtshalber auch darauf hinweisen, dass Heiko in Karlsruhe schon eine Menge Verbesserungen zusammengetragen hat. Die Rheinbrücke ist ein Spezialfall, da ist Streit vorprogrammiert. Auch das ist unbestritten. Der Streitfall am konkreten Beispiel entsteht IMHO auch, weil jeder macht was er will. Es keine zentrale Instanz gibt, die Regeln festlegt. Das ist für den lokalen Mapper, der seine Gegend bearbeitet, äußerst angenehm. Er kann mit tags zur Verfügbarkeit von Kuchen am lokalen Bäcker um sich werfen und keinen stört es. Langsam hat OSM aber Maße erreicht wo uns dieses Prinzip beginnt im Weg zu stehen. Heiko möchte, soweit ich ihn verstehe, gerne die Radwegesituation in unseren Daten verbessern. Das ist mehr als wünschenswert. ACK. nicht davor zurückschreckt, auch an kniffeligen Stellen die Finger in die Daten zu stecken, ebenfalls. Denn eine Huch, nein, ich könnte ja was kaputt machen-Mentalität führte sicher nicht dazu, dass das Projekt weiterkommt. NACK. Wie ich oben schon schrieb, ich hätte Dich bzw. den relevanten Mapper den ich in der History sehe angemailt. Warum hast Du das und das so und so erfasst, ich finde das wäre hier und hier besser, was sasgt Du dazu? Vor diesem Hintergrund stellt sich die Frage, was wir primär abbilden wollen: Die Topologie (Hier ist ein extra Radweg) oder die STVO (Hier ist ein straßenbegleitender Radweg). Da ich das Projekt viel mehr als Natürlich die Topologie. Schon mal vor dem Hintergrund das OSM weltweit funktionieren soll und die STVO nur lokal gilt. Das ein Renderer oder Router dann lokale Gegebenheiten, die er an den Ländergrenzen erkennt, berücksichtigen wird ergibt sich später von alleine. eine Relation zwischen dem Radweg und der Straße abgebildet werden sollte, Das sehe ich anders. Topologisch hat der Radweg mit der Straße nichts gemeinsam, die Gemeinsamkeit ist ein Konstrukt der STVO. Besser wäre die Editoren würden Linienbündel an Kreuzungen oder beim Verschieben usw. besser unterstützen, damit man die vielen Kreuzungspunkte nicht händisch pflegen muß. Ich bin daher auch kein Freund davon, einen Weg zu zerhaken, nur um eine Geschwingigkeitsbeschränkung (oder auch eine einfache Brücke) zu modellieren. Warum nicht? Man kann die zerhackstückten Teile, wenn man logische Informationen die zu mehreren Teilen des Weges gehören (name, ref), in eine Relation stecken. Mapnik Osmarender, openrouteservice.org, gosmore oder Navit heute mit unseren Daten zurechtkommen oder nicht, ist zweitrangig. Das lernen die schon noch. Und zwar umso schneller, je einheitlicher das Radwegemapping umgesetzt wird. ACK. Tschaui, Jörg signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routerhärtetest - Topologie oder STVO?
Moin, NACK. Wie ich oben schon schrieb, ich hätte Dich bzw. den relevanten Mapper den ich in der History sehe angemailt. Warum hast Du das und das so und so erfasst, ich finde das wäre hier und hier besser, was sasgt Du dazu? es spricht ja nichts dagegen, dass Du das so machst. Es soll aber auch ohne möglich sein. Denn sonst führt das dazu, dass jemand eine Verbesserung vornehmen könnte, es dann aber dann doch bleiben lässt, weil es ihm zu aufwändig ist, die Sache, die er _jetzt_ in wenigen Minuten erledigen könnte, erst tagelang abstimmen zu müssen. Cheers, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
