Hallo Stefan, leider beschränkt sich das ja nicht nur auf Kreuzungen: Mittelinseln an Fußgängerüberwegen, Bushaltestellen mit deutlichen Buchten, Taxistände, Parkhausein-/ausfahrten oder auch nur die Frage, wonach Straßen in Fahrbahn-Ways aufgetrennt werden (bauliche Trennung, juristisch bauliche Trennung und damit auch durchgezogene Doppellinie, Bürgersteig, Fußweg durch Grünstreifen getrennt, ...).
Insofern brauchen wir keine dedizierte Möglichkeit, Kreuzungen zu mappen, sondern eine Möglichkeit, neben Straßen eben auch Spuren einzutragen. Wenn die von dir zurecht kritisierten, durch Inseln entstandenen oneway-Highways eben nicht mehr highway sondern lane sind, dann ergibt sich ein ganz anderes Bild denn eine einbahn-Spur ist eben keine Einbahn-Straße. Nur hilft eine solch simple Umbenennung des Tags leider nicht weiter, denn welche Spuren gehören dann zu einer Straße? Wie findet man die Straße zusammen? Wie routet man über eine Straße, wenn nur noch Spuren da sind? Wie passt das zusammen mit Gebieten, in denen Spurmapping nicht vorhanden ist? Gruß Peter Am 03.01.2014 09:57, schrieb Stefan: > Hallo, > > ich frage mich, ob nicht ein Problem ist, dass Kreuzungen immer > detaillierter im vorhanden Namensräumen gemappt werden. Eine > Verkehrsinsel zu mappen in dem man zwei Highway als oneway mappet ist > zwar üblich, aber es handelt sich ja nicht wirklich um Einbahnstraßen. > Also streng genommen ein mapping für Router und Renderer. Das gleich > gilt für die beiden baulich getrennten Spuren. Eigentlich ist das ja > eine logische Straße. > Sollten wir veilleicht überlegen, ob die ganzen Dinge an Kreuzungen wie > z.B. Verkehrsinseln, Abbiegespuren, Abbiegeregeln, Ampeln, Fahrad- und > Füßgängerübergänge in einen eigenen "Kreuzungen" Namensraum sollten und > wir im highway Namensraum nur zwei sich kreuzende Highways hätten. > > Dies würde Routen aller Art leichter machen, da diese nicht durch die > verschiedenen Ways einer Kreuzung geführt werden müssten. > Ich habe in den detailliert gemappten Kreuzungen auch immer das Problem, > wo genau ändert sich der Straßenname, wo genau ändert sich der Typ von > secondary zu residential, wo ändert sich die Beleuchtung (lit=yes), .... > Außerdem wäre die Abfrage: "Wie viele Einbahnstraßen hat Hamburg?" ohne > Aufwendige Berechnung möglich. Aber auch z.B. Abfragen, nach der > Gesamtlänge einer Bundesstraße wären leichter zu beantworten. > > Viele Grüße > Stefan > > Am 21.12.2013 14:50, schrieb Tirkon: >> Leider hat sich auch nach einigen Jahren immer noch kein >> durchgreifendes und praktikables Konzept ergeben, wie der ÖPNV in OSM >> integriert werden könnte. Das Oxomoa Schema bzw seine >> Fortentwicklungen sind zwar ein erster Ansatz, die meisten Eigenheiten >> zu erfassen. Allerdings hat die breite Mapperschaft Probleme, dieses >> Modell nachzuvollziehen. Selbst Spezialisten mappen hier nicht >> einheitlich. Insbesondere aufwendig gemappte Kreuzungen mit ÖPNV >> Routen mag der gemeine Mapper zwecks Maintaining nicht mehr anfassen. >> Die Editoren Potlatch und ID ignorieren ÖPNV Relationen weitgehend. >> Sie warnen nicht, wenn jemand ein Straßenelement aus solch einer Route >> löscht, und sie somit unterbricht. >> >> Das Problem könnte entschärft werden, wenn es einen brauchbaren ÖPNV >> Editor gäbe. Ich möchte hier die Idee diskutieren, einen Routenplaner >> (Navi) Algorithmus für die Erstellung (nicht nur) von ÖPNV Routen zu >> nutzen. Wie man dort einen Start- und Zielpunkt eingibt, gibt man für >> den ÖPNV einfach den Ort der Anfangs- und Endhaltestelle an und lässt >> routen. Durch das Ziehen der Route bringt man diese dann auf den >> tatsächlichen Fahrweg. >> >> Ein Routenplaner, der dieses Vorgehen auf OSM Basis bereitstellt, ist >> http://map.project-osrm.org/ >> >> Die Vorteile liegen auf der Hand. Eine Route lässt sich in Sekunden >> bis Minuten zusammenstellen. Das Aufsuchen von Mikrowegen (ein Meter >> Länge) oder z.B. an Brücken stellt damit kein Problem mehr dar. Fehler >> in OSM, die ein Routen über diese Strecke unmöglich machen, könnten >> mit dem Routenplaner Algorithmus gefunden und eingekreist werden. Denn >> der Routenplaner würde sich weigern, über eine solche Fehlstelle zu >> routen. Indem man die Zwischenpunkte immer weiter bis zu wenigen >> Metern an die verweigerte Stelle heranschiebt, könnte man diese >> dingfest machen. >> >> Der Routenplaner Algorithmus könnte für Zugverbindungen auch auf >> Schienenwege erweitert werden. >> >> Auch das Reparieren von Routen (auch nach dem Editieren aufwendig >> gemappter Kreuzungen) würde damit wesentlich erleichtert. Hierzu >> könnte der Routenplaner Algortihmus Vorschläge zur Schließung der >> entstandenen Lücken machen, die man durch Ziehen dann auf die richtige >> Route bringt. >> >> Das Konzept würde sich nicht nur für den ÖPNV, sondern auch für >> jegliche andere Routen wie (Rad-)Wanderwege nutzen lassen. >> >> Das größte Problem an dem Konzept ist allerdings das seltene Update >> der Routenplaner, das allerdings bei dem genannten OSRM Projekt >> vergleichsweise aktuell ist. >> >> Zum Testen würde für's Erste eine Export Funktion für OSRM hilfreich >> sein, die eine berechnete Route als JOSM-taugliche Relation type=route >> ausgibt. Damit könnte man neue Routen erstellen. >> >> Als erstes Demo habe ich die Route "Bus VEJ 411 Georgheil->Norden >> (Verkehrsverbund Ems Jade)" nachgestellt. Die Erstellung hat gerade >> mal wenige Sekunden gedauert. Allerdings nutzt OSRM keine >> highway=service, so dass die hierüber angefahrenen Haltestellen außen >> vor bleiben mussten. Dennoch würde eine solche Erstellungsmethode viel >> Zeit und Mühen einsparen sowie Fehler vermeiden. >> >> Die OSM-Relation der Route: >> http://www.openstreetmap.org/relation/1921181 >> Die Route bei OSRM: >> http://www.osrm.at/5Ue >> >> ------- >> Als weitere Erleichterung könnte IMHO die Unterteilung einer >> Haltestelle in Plattform und Haltepunkt aufgeben werden. Die Angabe >> der Plattform (z.B. Ort des Haltestellenschildes) wäre ausreichend. Um >> den Haltepunkt zu errechnen, bräuchte lediglich das Lot auf die Route >> gefällt werden. Dass dies möglich ist, beweist der OSM Inspector in >> seinem Adress Layer. Beispiel: >> http://tools.geofabrik.de/osmi/?view=addresses&lon=6.85091&lat=51.21682&zoom=18&opacity=1.00&overlays=buildings,buildings_with_addresses,postal_code,nodes_with_addresses_defined,nodes_with_addresses_interpolated,no_addr_street,street_not_found,interpolation,interpolation_errors,connection_lines,nearest_points,nearest_roads >> Falls als Plattform eine Fläche oder Linie angegeben ist, wird das Lot >> aus deren Mitte gefällt. >> >> Fällen eines Lotes bei Wikipedia: >> https://de.wikipedia.org/wiki/Lot_%28Mathematik%29#F.C3.A4llen_des_Lots >> >> Was meint ihr? >> >> >> _______________________________________________ >> Talk-de mailing list >> Talk-de@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-de >> > > > _______________________________________________ > Talk-de mailing list > Talk-de@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-de > _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
