Moin Auch von mir zum Thema paar Denkanstöße, da ich mich mit dem Thema auch schon öfters befasst habe...
Frederik Ramm schrub: > das Thema taucht immer wieder auf - wie tagge ich einen > Fussweg/Radweg/Buergersteig/Wirtschaftsweg, der parallel > zur Strasse verlaeuft. In der Tat... *seufz* Diese Unklarheit mit ihren negativen Folgen bzgl. Rendern etc. hat mich bisher davon abgehalten, mich ums Karlsruher Radverkehrsnetz zu kümmern (neben paar Unklarheiten bzgl. detaillierter Erfassung der vielen Besonderheiten an Radwegarten, Benutzungspflichten etc.) > Grundsaetzlich, das ist mittlerweile jedem klar, gibt es die > Moeglichkeit, zusaetzliche Tags an den "Haupt-Way" dranzubasteln, > oder aber man zeichnet den neuen Weg einzeln ein. > Beide Verfahren haben Vor- und Nachteile. Eventuell muessen > je nach Situation beide eingesetzt werden. Habe die Tage auf http://wiki.openstreetmap.org/index.php?title=De:Bicycle/quellen paar Gedankenfetzen hinterlassen: * Gedankenfetzen "Wie mappen"? entweder: ** Radinfrastruktur, sofern (halbwegs) straßenbegleitend, stets in highway-tag unterbringen? *** pro: Renderer hätten sofort den Zusammenhang aller "Spuren" (Fahrbahn, Rad- und Gehwege) 1) *** contra: Renderer stellen das derzeit nicht da. 2) *** contra: sehr umständliches tagging, insbes. wenn je nach Fahrtrichtung unterschiedlich 3) *** contra: dann empfindlich gegen Ändern der Richtung 3) *** pro: In Zukunft könnte noch mehr am highway dran hängen müssen (Fahrspuren je Richtung, spurenabhängiges Navigieren = rechtzeitiges Einordnen, wie es schon etliche Navis anbieten), dann macht's nichts, wenn auch noch Radanlagen dranhängen 3) ** Radinfrastruktur stets auf eigenen ways, egal wie nahe an Fahrbahn *** pro: einfacheres und sichereres taggen 4) *** contra: komplizierteres Rendern, ggfs. gegenseitige Verdeckung von Fahrbahn oder Radweg **** Problem muss aber sowieso gelöst werden, weil es auch Straßen mit mehreren Fahrbahnen betrifft (Autobahn, Anliegerfahrbahn) oder mit Gleiskörper in der Mitte oder andere Parallelitäten (Fluss neben Straße, Feldweg neben Straße, landuse-way neben Straße etc.) ** beide Lösungen nebeneinander nutzbar 5) 1) sie nutzen es derzeit nicht, denn es gilt: 2) Was ein deutlicher Nachteil ist, wenn man a) das Ergebnis seiner Arbeit nicht sieht in den Hauptkarten und viele Radfahrer hier hätten wohl zumind. die wichtigsten Infos drin, weil gerade DAS ein Unterschied zu kommerziellen Karten wäre Für ganz genaue Detaillierung (Anzeige Radwegbreite etc.) wäre vermutlich eine eigene Karte besser, aber für eine Übersicht, wie man am besten von A nach B kommt, sollten grunddaten in der Hauptkarte drin sein. 3) wurde ja auch hier schon angerissen 4) Vor allem, wenn's an großen Kreuzungen kompliziert wird, wenn Radler von A nach B ganz anders geführt werden wie Autofahrer Anbiegeanweisungen eines Navis führen dann eher in die Irre, wenn sie nicht über die anders strukturierte Radwegführung routen. Abbiege-Restrictions können zudem für Radler anders sein als für Autofahrer etc. 5) nach der bisherigen Diskussion würde ich fast erweitern auf: alle drei Lösungen nebeneinander nutzbar, nämlich einfaches Mappen/taggen: highway=primary (cycleway=track) einfaches Mappen/detailliertes taggen: highway=primary mit way1...n left/r detailliertes Mappen/einfaches (o. detailliertes) taggen: eigene ways > Es ist ein kompliziertes Thema, das nicht auf Deutschland beschraenkt > ist, aber hier wird es als besonders wichtig angesehen. Ja, wir Deutschen mochten es schon immer etwas genauer :-) > Das Thema wird ganz bestimmt nicht durch Diskussionen auf der > Mailingliste geloest werden. Oops... Jetzt haben wir hier aber schon angefangen :-) Aber Ideen sammeln kann man ja schon mal. Man weiß ja nie, ob man für nachfolgendes Zeit hat oder es zu weit weg ist... > Was wir brauchen, ist eine Handvoll Leute, denen das Thema > am Herzen liegt, Diese Voraussetzung ist gegeben... :-) > und von denen je mindestens einer sich mit einem der > wichtigen Editoren, einem der wichtigen Renderer und einer > Routingsoftware auskennt, Nun ja, nur als Nutzer... > dazu noch ein paar erfahrene Mapper, und dann sollen die > sich uebers Wochenende irgendwo einsperren und sich eine > Loesung ausdenken und die umsetzen (d.h. Editor, Renderer > usw. anpassen und ausprobieren). So a la Karlsruher Hausnumerierungsschema? Ich wage aber zu bezweifeln angesichts der Komplexität, dass ein WE reicht... Wer sponsort einen 2-wöchigen Urlaub ... > Dann sollen sie sich eine kleine Stadt schnappen und ... in einer kleinen Stadt am Mittelmeer oder so :-) > alles nach ihren Loesungsvorschlaegen umbauen und auf > diese Weise einer praktischen Ueberpruefung unterziehen. > Und dann ist die Sache reif, um von allen anderen auch > benutzt zu werden. > In meinen Augen ist das eines der grossen Themen, die > geloest werden muessen, In der Tat. Sascha Silbe schrub: > 1. Separat vs. shared way: Sobald Nicht-Straßenteile wie > z.B. ein Grünstreifen dazwischen sind, sollte ein > separater Weg benutzt werden > PS: Wenn ich so recht drüber nachdenke, ist für mich der > Grünstreifen einer Autobahn Teil der Straße - ich würde > deshalb eher folgende Kriterien ansetzen: > - unterschiedlicher Verlauf der Teilwege (z.B. Radweg, > der zusätzliche Schwünge macht) Eben... Welcher Grünstreifen ist wirklich relevant... Welcher Schlenker hat wirklich eine Auswirkung auf Karte und Router Schwer abzugrenzen. > - unterschiedliche Verbindungen; wobei man sich das auch > noch genauer überlegen muß - es ist ja völlig normal, > daß verschiedene Spuren woanders hinführen (s.a. unten). Auf der Fahrbahn kann man aber Spuren wechseln. Zwischen Radweg und Fahrbahn kann man nicht überall wechseln. Vor paar Tagen erst wieder mal erlebt. Linksseitiger Radweg ignoriert rechtsseite Einmündung völlig... *grummel* > An anderen Stellen dagegen muß man über den Bürgersteig fahren > (hier in Tübingen haben wir so einen Fall), um von Straße zu > Straße zu kommen. Letzteres ist übrigens momentan nicht abbildbar. Hast Du einen Link zu einem Google-Luftbild für diese Stelle oder Ortsangabe? Sowas kann schon mal vorkommen, muss aber nicht unbedingt so relevant für Karte oder Router sein, um es in OSM reinzwängen zu müssen... > Gibt es eigentlich irgendwo Straßen, die z.B. einen Bürgersteig > in der Mitte haben? Karlsruhe vom Mühlburger Tor weg zum Kaiserplatz könnte man so bezeichnen... Und vergiss nicht Straßenbahnhaltestellen in der Straßenmitte! :-) Auch so 'ne Art Gehweg :-) Rene Falk schrub: > > Ich bin sowieso total gegen "links" und "rechts". Das kommt mir > > einfach unprofessionell vor. Ist das echt ueblich in der > > Strassenbau-Szene, dass man von linken und rechten Seiten einer > > Strasse spricht? > > Ist meiner Meinung ein schlechtes Beispiel. Bundesstraßen haben im > allgemeinen schon eine Richtung durch die Stationierung. Aber > natürlich hast Du recht, das sollte mal "professionell" geklärt > werden. Vermutlich kann man über die amtlichen Straßenverzeichnisse > die Richtung klären, solange diese keine reinen Bestandslisten sind, > was ja auch vorkommen kann. Aber dann hat man immer noch keine Regel > dafür. Solche Straßenlisten, wenn überhaupt existent, wären nicht allgemein verfügbar. Allgemein verfügbar sind nur die Richtungen der gemappten ways in OSM und da bietet sich an, mit links und rechts in Bezug auf den way zu arbeiten und zwei Sorten "way umdrehen" zu haben, eine mit und eine ohne Umdrehen der tags. Hängt nur ein oneway=yes dran, kann man mit letzterem die Einbahnstraßenrichtung korrigieren. Ersteres könnte umdrehen, sofern es in den Tags auftaucht: left <--> right forward <--> backward 1 <--> -1 bzw. s.u. 1 <--> n, falls Spuren von ways wie vorgeschlagen durchnumeriert werden ähnliches für incline oneway=yes könnte man mit oneway=forward gleichsetzen, damit man beim umdrehen oneway=backward bekäme. Wäre auch nützlich, wenn die Richtung eines Tags der eines anderen tags entgegengesetzt wäre, wofür mir aber gerade kein Bsp. einfällt. Ach, sehe gerade, dass es nun oneway=-1 gibt. Auch gut... forward/backward gibt's aber für bushaltestellen, wenn ich das hier richtig las? Sebastian Hohmann schrub: > highway=tertiary > ways=4 > way:1=footway > way:2=cycleway > way:3=tertiary > way:4=path Wäre eine Alternative zu left/right oder Ergänzung. Wobei man streiten kann, ob man die beiden Fahrstreifen der tertiary gleich direkt mit way:3 und way:4 definiert, weil man das ja eh bald streifenweise definieren wird wegen fahrstreifenabhängiger Navigation, Einschränkungen fahrtrichtungsabhängig oder ein way:3.lanes=3 anhängt... > Wie willst du das dann machen? -1 für links neben der Mitte und > +1 für rechts? Was ist mit 0? Und wo ist überhaupt die Mitte? > Die physische Mitte lässt sich ja nicht immer genau ausmessen. Über 1...n oder -n ... +m kann man noch streiten. Letzteres hat den Vorteil, dass man 0 als Mitte der Geometrie des ways definieren kann. 0 ist entweder "nix" wenn es nur ein schmaler Grünstreifen ist oder der Trennstrich zwischen den Fahrbahnen. Wobei genau das kann man natürlich angeben: way:0=green way:0=Fahrstreifenbegrenzung durchgezogen einfach/doppelt o. gestrichelt Oder 0 ist eben Geometriemitte = rechter Radweg... Wahre way-Gesamt-Lage könnte später aus Spurenbreiten grob korrigiert werden... Oder es ist was reales. way:0=tram (wenn man nicht gleich beide Gleise einzeln...) way:0=cycleway bei der erwähnten Bundesstraße :-) way:0=canal soll auch mal vorkommen... Damit hätten wir schon mal zwei "highway-fremde" Elemente aus Versehen mit in das System eingebaut hat... Diskussionsbedarf... Nicht zu vergessen amenity=parking als Parkstreifen aus dem anderen thread enbauen in das System... Interessante Erweiterung des Systems, damit man den way nicht jedes Mal auftrennen muss, wenn der Parkstreifen mal paar meter unterbrochen ist...: Nodes könnten tags tragen wie: way:2=stopping:parking way:2=starting:bus_stop am einen Knoten way:2=starting:parking way:2=stopping:bus_stop an einem folgenden Knoten, wenn Parkstreifen kurz durch Bushalt unterbrochen. stopping <---> starting muss natürlich auch umgedreht werden, s.o. "ing" wegen Verwechslungsgefahr zu "stop" in bus_stop o.ä. Dann könnte man sich auch überlegen, ob man nicht way:all=starting:bridge;starting:layer.1 way:all=stopping:bridg;stopping:layer.1 ... oder so ähnlich konstruiert oder way:-2.3=starting:bridge wenn Brücke nur für die Spuren -2 bis 3 gilt. Oder man könnte way:all=starting:render_name way:all=middle:render_name ... definieren Es gibt nun mehrere mögliche mapping-Varianten: 1) einfach nur highway=tertiary Begleitender Gehweg und lanes=2 werden per Default angenommen oder so (Gehweg ggfs. nur innerorts...) 2) highway=tertiary mit Zusätzen wie cycleway=yes/track/lane für symmetrische Radwege oder railway=tram für Bahn auf Fahrbahn 3) highway=tertiary und cycleway=left o.ä. für einfache Fälle unsymmetrischer Radwege 4) highway=tertiary? bundle? ...? für kompliziertere Fälle mit Numerierung way:2=... etc. 5) separate ways für Fahrbahnen, Radwege, Straßenbahnen, Flüsse und was sonst noch so parallel laufen kann (Anliegerfahrbahn, Feldweg, ... Landnutzungsgrenzen?) aus historischen Gründen oder weil besondere abseitige Wegführung oder komplexe Verknüpfungsvarianten dies angeraten erscheinen lassen. 6) Kombinationen aus 5) und 1)-4), denn bei einem Bündel aus Hauptfahrbahnen, Anliegerfahrbahnen und anderen Dingen kann jede Teil ja auch seine Eigenarten haben (Hat Hauptfahrbahn oder Nebenfahrbahn oder beide Parkstreifen, Radwege, ...?) 5) und 6) haben derzeit den Nachteil, dass Renderer und Router nicht wissen, dass diese zusammengehören. Alles, was parallel zueinander sein soll, ganz oder abschnittsweise, sollte also in eine Relation, wobei man den einzelnen Teilen dann eine role=0 role=1 role=-1 nach obigem Numerierungsschema zuordnen könnte... "parallel ... abschnittsweise" deswegen, weil z.B. der Renderer die Parallelität eventuell nur dann berücksichtigen soll, wenn bspw. der Radweg in der gerade aktuell gerenderten Zoomstufe so nahe an der Fahrbahn liegt, dass er verdeckt würde. Man könnte sagen, dass ab einer gewissen Distanz davon ausgegangen wird, dass er zu weit abseits läuft und er separat gerendert wird. Ist ja gerade der Vorteil von 5), dass kurvige Führungen erfasst werden und dargestellt werden können, wenn man will. Evtl. sollte man in die role packen können, ob man das will oder stets parallel zeichnen will... Ein Router braucht ab dieser Stelle nur noch auswerten... ;-) Interessant wird an hier die Frage des Renderns... Bisher wird bei 5)/6) alles separat gezeichnet, in der Regel kommt es zu wechselnden Abständen und bei vielen Zoomstufen auch zu ganzen oder teilweisen Verdeckungen... Unschön, sehr unschön... Aber es wird gezeichnet. Deswegen wohl so mancher separate Radweg, wo er eigentlich dicht an der Fahrbahn liegt... Bei 1)-4) fällt alles außer dem highway=... unter den Tisch. Weder von cycleway=... noch von railway=... sieht man was... Gezeichnet wird bei 1)-6) nur mit einer Geometrie, der des ways, mit nur wenig Gestaltungsmöglichkeiten: Eine dicke Linie in der Farbe des highways und drunter gelegt eine etwas dickere Linie für die Bordüre/Perkussion/Randlinie des highways, meist grau. Oder bei einigen Renderern für bestimmte Wege eine einfache durchgezogene oder gestrichelte Linie (Tram, Feldweg, Radweg) Offen ist die Frage, wie man Zusatzinfos zeichnet und besonders wie man die seitenabhängigen Dinge zeichnet. Meine Idee dazu: Verschiedenfarbige "Perkussion" des Hauptweges, evtl. auch mehrlinige Perkussion: tertiary-Fahrbahn mit beidseitiger Radverkehrsanlage: dicker teritary-Strich blaue Perkussion beidseitig mit Radweg einseitig: blaue Perkussion auf einer Seite, graue Perkussion auf anderer Seite Dann hätten wir noch nicht Radweg von Radspur unterschieden. Wenn man das unterscheiden will: secondary-orange - blaue Perkussion - graue Perkussion = Radspur secondary-orange - graue Perkussion - blaue Perkussion = Radweg nach dem Muster grau = Bordstein Zweirichtungsradweg = breitere blaue Perkussion benutzungspflichtig / nicht benutzungspflichtig = dunkelblau / hellblau Man könnte überlegen: schmale graue Perkussion = kein Gehweg breite graue Perkussion = Gehweg vorhanden Radspur/Gehweg wäre dann neben secondary: ... - sec.orange - dkl.blau - grau breit Angebotsstreifen/Gehweg wäre dann neben secondary: ... - sec.orange - hellblau - grau breit getrennter Geh-/Radweg benutzungspflichtig wäre dann: ... - sec.orange - grau schmal (Bordstein) - dkl.blau - grau breit getrennter Gehweg/"anderer Radweg" (nicht benutzungspflichtig): ... - sec.orange - grau schmal (Bordstein) - hellblau - grau breit gemeinsamer Geh-/Radweg benutzungspflichtig: ... - sec.orange - dkl.blau-grau breit gestrichelt Gehweg, Radfahrer frei: ... - sec.orange - hellblau-breit gestrichelt Fahrradstraße mit Gehwegen beiderseits, nur Radler: grau breit - dkl.blau - grau breit Fahrradstraße mit Gehwegen beiderseits, Kfz. frei: grau breit - hellblau - grau breit und so weiter ... oder Gehweg = rote Perkussion Auf jeden Fall bekämen wir bei Seitenabhängigkeit Probleme mit dem SVG und der bisher einfachen Geometrie, da bisher die Perkussion dieselbe Geometrie hat wie der eigentliche way, nur dass sie breiter ist und eine Ebene tiefer liegt und nur mit diesem Trick als Perkussion erscheint... Die Perkussionen bräuchten dann eigene Geometrien, die entweder bei 1)-4) noch relativ einfach aus der Geometrie des ways parallel zum Rand hin weiter entwickelt werden. Oder die bei 5) erst aus den Geometrien der beteiligten ways ermittelt werden müssen: Entweder ist per role die Mitte festgelegt oder sie wird selbst ermittelt nach dem Muster - höchstrangiger highway - wenn zwei gleichwertige highway parallel die Mittellage ermitteln - wenn railway dazwischen: diese nehmen - ... evtl. weitere Fälle Aus dieser vorgegebenen oder ermittelten Geometrie wird dann die Geometrie jeder Perkussion ermittelt. Die müssen aus 5) oder 6) erst noch in die richtige Reihenfolge gebracht werden. Dann muss noch die von der Mitte her ermittelte Geometrie der Perkussion mit der Geometrie des ways verglichen werden (in Fällen von 6) komplexer...) und entschieden werden (wenn nicht vorgegeben), ob noch nahe genug für gemeinsames Zeichnen oder zu weit entfernt und separates Zeichnen notwendig... Wenn Mitte definiert (way:0=green oder way:0=line) evtl. entscheiden, ob Trennung durch graue Linie oder ein wenig Hintergrund dazwischen... Sortieren und Geometrievergleich dürften nicht ganz trivial sein. Man braucht Funktionen wie "way n liegt parallel zu way m im durchschnittlichen Abstand von x" und wie vor mit "... nur im Bereich bis node k", dan schwenkt er weg oder endet. Die Knoten werden zudem selten direkt nebeneinander liegen, Zwischenknoten müssen evtl. gerechnet werden. Mapnik in python und orp in Perl dürften das hinkriegen, osmarender-xslt hat aber vermutlich verloren... Ggfs. muss man noch austüfteln, ob man diese Rechnerei jedes Mal macht oder die neuen Geometrien zwischenlagert bis sich an den Geometrien oder tags der ways was ändert (wie zuverlässig feststellen?), bei [EMAIL PROTECTED] eher nicht möglich...? Und was macht man mit Querstraßen, die nicht 90° dazustoßen, aber mit Neben-ways Knoten haben... Die Ränder von Flächennutzungen könnte man so auch sauber prallel zeichnen. Irgendwann wurde auch mal angesprochen, dass Sackgassen, die nahe an einer Straße enden, oftmals so überdeckt werden, dass das Sackgassige ger nicht mehr erkannt wird. Packt man bei 5) den Endknoten in die relation mit rein, wäre das Problem lösbar. Evtl. muss noch berücksichtigt werden, dass am Ende der Sackgasse noch ein Geh-/Radweg bis zur Straße nicht untergehen darf. Oder Verdrängungsfragen von separat gemappten Häusern an der Straße. Hatte mir schon mal überlegt, ob ich da selbst akitv werde, weil mich die unschönen Parallelitäten in dne bisherigen Karten stören, aber in Perl habe ich bisher wenig gemacht, in python nix... also erstmal nix getan, weil mir das letztlich doch zu komplex wurde... Ich hege daher Zweifel, ob das mit dem Renderer an einem WE klappen würde... :-) So, das war's erst mal, das Bett ruft :-) Gruß Heiko "Mueck" Jacobs _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
