Volles Einverständnis. Market Consolidation heißt das in der BWL. Embrace and Extend hab ich auch schon gelesen. In der gelobten Konsequenz sicher zielführend, wenn man OSM first-mover-routing untauglich machen will. Das ist eine Sache für die Platzhirschen und solls werden, ah bleiben.
Was soll das schließlich heißen - weniger wäre mehr? Nur Mehr ist Mehr! Also: OSM braucht dringend Flächen, die kennzeichnen, wo man die kartierten Wege verlassen, will heißen, ignorieren darf, und was dort alles erreichbar ist. Es ginge billiger, aber wo bleibt dann das (Wirtschafts-) Wachtsum?
Das wäre schön, aber wie machst du das? Einerseits, wie formuliert man eine solche Datenbankabfrage generisch? Andererseits, wie ordnet man die Radweg-Infos den Straßenlinien zu wenn Radwege und Straßenlinien nicht an den gleichen Stellen geteilt sind? Auch die Zuordnung, welcher Radweg-Teil an welche Straßen-Teil gehört ist nicht immer eindeutig.
Man müsste mit der Datenbankabfrage die Straßenkanten teilen können, sowohl an bestehenden Knoten, als auch zwischen den Knoten.
Bei unterschiedlichen Längen von Radweg und Fahrbahn müsste interpoliert werden.
Zudem braucht es einen Algotithmus, der entscheidet, ob ein Weg als paralleler Radweg durchgeht oder ob es z.B. nur eine Verbindung zwischen Straße und Radweg ist.
Ich habe mal 3 Beispiele gezeichnet. Grün und Blau sind die Linien der separaten Radwege / Gehsteige. Rot bis Lila sind die Straßenlinien. Wo die Farbschattierung wechselt sind die Linien geteilt weil sich Attribute ändern. Die Attribute der blauen und grünen Radweg- / Gesteig-Linien sollen vor dem Routen den Straßen-Linien zugeordnet werden.
Im Beispiel A) sollen die Infos aus den drei Radweglinien 1-2, 2-3 und 3-4 an die Straßenlinien 7-8-9 und 9-10. Dazu müsste die Straßenlinie am Knoten 8 geteilt werden. Ob der Knoten 3 und der Knoten 9 wirklich zusammengehören wäre in der Datenbankabrage zu entscheiden, ggf. muss nahe dem Knoten 9 nochmal geteilt werden.
Im Beispiel B) müssten die Straßenlinie 9-8-9 und die Linie 9-10 geteilt werden.
Im Beispiel C) müssten ebenso Straßenlinen mehrfach geteilt werden. Zudem ist für die Straßenlinie 9-5 zu entscheiden, ob die Linie 4-5 ein paralleler Radweg ist (so wie 3-4) oder nicht. Aus der Datenbankabfrage müsste dabei herauskommen, dass bereits die Linie 4-11 der parallele Radweg ist und 4-5 nur eine Verbindung zwischen Radweg und Fahrbahn.
Ich bin mir nicht sicher, ob das alle Schwierigkeiten sind.
Ich bin kein Datenbankprofi, kann mir aber nicht richtig vorstellen, dass man das in einer Abfrage hinbekommt.
Eher kann ich mir vorstellen, dass man Übertragen der Radweg-Eigenschaften an die Straßenlinien in einem Vor-Prozess unter Nutzung von Routingalgorithmen macht. Man schaut vorab bei jeder Kreuzung, welche alternativen Fahrwege über Radwege es zur nächsten Kreuzung gibt. Die Attribute dieser Wege werden dann zur Wichtung der Straßenlinien genutzt.
Ich vermute das alles ist entweder nicht eindeutig machbar. Vermutlich ist auch der Code dazu so kompliziert oder rechenaufwändig, dass es nicht realistisch umsetzbar ist. Es verbleibt also als einer der großen Nachteile des Getrennt-Mappings, dass das Routing an “mikroskopisch” abgebildeten Kreuzungen teilweise unbrauchbar wird.
Die Info, ob der seperate gemappte Weg nun wirklich seperat ist oder ob ein Wechsel zur / Querung der Fahrbahn möglich ist nicht duch Datenbankabfragen oder Algorithmen generierbar, die muss irgendwie gemappt werden.
Ja, das ist einer der großen Nachteile des Zusammen-Mappings. Es stehen nur ‘width’ oder ‘lanes’ und ‘placement’ zur Verfügung, um die Lage einigermaßen zu verorten. Bei fahrbahnnahen, weitgehend parallelen Radwegen sollte das aber ausreichen.
Da gab es ein DDR-Lied “Sag mir wo du stehst?” Als Radfahrer sind Radwege der Nabel der Welt, Autos sind eh’ Schrott der Geschichte. Als Grundstücksbesitzer sind es aber eher die Grundstücke. Also wenn, dann eher die äußerste Grenze der Straße mappen, also von außen nach innen, oder ?
Die bisherige Abstraktion durch Linien hätte ich so verstanden, dass die Linie standardmäßig die Mitte der Straße / der Fahrbahn abbildet und die Fahrspuren/Seitenräume von dort aus gezeichnet werden. Das wäre eine Umkehr des Ganzen, hat auch so seine Reize.
Das Problem würde es aber auch nicht lösen. Wenn auf der anderen Seite ein Radweg verläuft haben wir wieder 2 Linien wo sich die Frage stellt, “Wo kommt man von der einen auf die andere Linie?”.
Vielleicht eine andere Möglichkeit: Alle Radwegdetails an die Straße mappen, den geometrischen Verlauf dann separat aber ohne weitere Attribute außer einen Tag das sagt “Attribute stehen an der Straße”. Dann fehlen die Infos allerdings beim mikroskopischen Routing.
zum Thema Bigplayer und Hardwareanforderungen, das kommt auf die Größe an, small players können das dann vielleicht nicht weltweit machen sondern nur in kleineren Gebieten. Oder nur für ein Spezialgebiet und nicht für alle möglichen Features, oder nicht live sondern nur mit monatlichen Updates, etc. Es ist auch mit „Heimhardware“ möglich, die Daten aufwendig vorzubereiten, eher wird es an Entwicklerzeit als an der Hardware scheitern.
ja klar, wenn man die Radwegeigenschaften für das Rendering an der Straße haben will muss man die Straße in diesem Schritt auch weiter aufteilen. Soweit es halt für die Renderregeln notwendig ist, und umgekehrt kann man zusätzlich auch alle Segmente verbinden, die man gleich rendern will.
Der Algorithmus könnte einen Buffer um die Radwege legen und darin alle Straßen suchen, und davon die nächste nehmen. Das für alle nodes des Radwegs machen, ggf. noch prüfen ob die Straßensegmente alle verbunden sind und ggf. fehlende Zwischenstücke suchen (per Routing). Welchen Abstand man dabei setzen will ab dem man es nicht mehr macht, das macht man abhängig von der Ziel-Zoomstufe und der Straßenbreite die man dort rendert.
Nur mal als Fragmente, ich gebe zu dass es da viele schwierige Probleme gibt, vielleicht geht es auch gar nicht zuverlässig, jedenfalls gibt es sicher Stellen wo es nicht gehen würde bzw. Fehler machen würde.
Viel einfacher wäre es dadurch, dass man als Mapper mit einer Relation die Zuordnung Straße - Radweg definiert, dann würde es ausreichen, für die Wege für die es Relationen gibt, die Eigenschaften zu übertragen, das könnte durchaus ein dauerhafter Verarbeitungsschritt sein und müsste nicht jeweils on the fly in einer Datenbankabfrage generiert werden.
Hallo Dieter, du hast *"wenn der Mapper fürs Mappen wenig Zeit hat" ins Wiki als Kriterium fürs Getrennt-Mapping geschrieben.
Das Anlegen eines einfachen separaten Radwegs im ID mit zwei Knoten braucht 6 Klicks.
Das Anlegen eines Radwegs als Attribut an eine bestehende Straßenkante braucht 4 Klicks. Wenn man erst die Vorlage “Fahrradstreifen” sucht braucht es 6 Klicks und ein “F” in der Vorlagensuche. Die Klicks für das Eingeben der Geometrie fallen komplett weg.
Weitere Attribute muss man immer eingeben, egal ob separat oder zusammen. Vorlagen können bei Beiden gleichermaßen helfen.
Fazit: Die Unterschiede sind nicht relevant, wenn, dann müsste das als Pro auf der anderen Seite stehen.
Oh, ich hab es in der Änderungsansicht gelesen und falsch einsortiert und mich echt gewundert, sorry! Als sonderlich relevant emfinde ich es trodtzem nicht. Wenn ich keine Zeit habe kann ich auch schnell Linien zeichnen, dann bin ich halt ungenauer. Besser grob als gar nicht kartiert. Aber ja, wenn man es sorgfältig macht ist das Linienmappen aufwendiger.
Wenn ich hier so mitlese scheint mir, den SOTM Vortrag von cylcestreets hat keiner angeschaut. Zur Erinnerung https://www.cyclestreets.org/news/2019/09/22/sotm2019/ - ganz besonders für die Radschienenleger, aber nicht nur, und ausgenommen freilich, wenn wir die Farbe der Pflasterung mappen, aber selbst dann?
vor allem weil ja eine Linie nicht reicht, man muss die dann auch an den Einfahrten und sonstigen Querungen verbinden, und diese ways muss man dann auch alle taggen. Und diese Details hat man sonst in der Regel auch einfach nicht, wenn man es über Attribute des highways macht, weil wenn man das alles mappen würde, dann würde man einen separaten Radweg auch mit einem eigenen way mappen
Genau. Im Prinzip kann ich dann “meine” (eingegebenen Daten) nur noch nutzen, weil andere sie mir vor-verarbeiten oder das Produkt zur Verfügung stellen. Und wenn ich darauf angewiesen bin, dass sie mir jemand vorbereitet, wo ist dann der Sinn, sie erst komplex einzugeben.
Nur wenn Du überall auf der Welt Daten eingibst und Karten von überall und allem produzieren willst, dann schon, ansonsten kannst Du das für “Dein Gebiet” vermutlich auch allein leisten. Ist beim Routing und Rendering ja auch nicht anders, das könntest Du alles auch alleine machen, aber ist sehr viel Arbeit, und daher wird man normalerweise den Dienst von irgendjemandem nutzen, der diese Arbeit schon gemacht hat und dir das Ergebnis zur Verfügung stellt.
Es geht ja nicht ums “komplexe” Eingeben, sondern um das einfache Eingeben ohne Sonderregeln (eigener Weg mit eigener Fahrbahn als eigener way), das halte ich für weniger komplex als abstrakte cyclway:right:width=2 Angaben auf einer in der Nähe liegenden Straße verbunden mit der Erwartung, dass deswegen der Fahrradweg nicht mehr als way gemappt wird. Was komplexer wird ist die Zuordnung der Straße zum Fahrradweg, es ist aber nicht so, dass die überhaupt für alle Datennutzer relevant wäre.
jetzt hast du nahezu den gesamten Abschnitt ohne Ankündigung gelöscht. Nach dieser Disskussion hier empfinde ich das als unangebracht. Wir hatten hier darüber diskutiert, ob die Auflistung der Vor-/Nachteile dort reingehört da die sehr groß ist. Da bin ich auch dafür, es bei einem Verweis zu lassen. Aber von Alles-Löschen hat bislang Keiner gesprochen.
Hier haben sich schon Viele einen Kopf über diesen Text gemacht, das wäre nun alles weg. In einem solchen Fall sprech deine Ansichten bitte hier erst an, es kann ja duchaus sinnvoll sein. Statt Alles zu Löschen dann auch eher das Relevante (die Handlungsempfehlung?) an eine bessere Stelle schieben.
Ich habe ihn mir angeschaut nur noch keine Zeit dazu, hier zu antworten.
Einige Probleme des Getrennmappings hat er echt gut dargestellt. Es ist Wasser auf meine Mühlen, dass weder die eine noch die andere Mappingart in allen Fällen die bessere ist. Das sollten sich z. B. die hoffentlich Mitlesenden der Berliner Verkehrswende-Mapper anschauen, deren Wiki-Formulierungen schon nach “Verfechten” des einen Schemas klingen.
Allerdings bin ich aus dem Vortrag nicht schlauer geworden. Er sagt zwar, dass er im Flächenmapping den Ausweg sieht. Er erklärt aber nicht, wie das funktionieren soll. Wie bekommt er z. B. die Zuodnung der Flächen zu den Linien hin, wenn die Attribute an den Linien stehen, die Linien aber innerhalb einer Fläche geteilt sind und dort die Attribute wechseln?
Ich hatte ja gedacht, wenn der Router etwas abstrakter routen will, nimmt er die Linien der Fahrbahn statt die der mikro-gemappten Seitenbereiche. Ihn verstehe ich aber so, dass er fürs gehweg-Routen über Gehweg-Flächen routen will (bzw. Radweg). Da frage ich mich, wie er auf einer wabernden Fläche mit ständig ändernden Breiten erkennen will, ob die Fläche einen abbiegenden Gehsteig darstellt oder nur einen etwas unförmigen Gehsteig. Ist doch auch wieder nur “Raten nach Formen”.
Bin diesbezüglich in keiner besseren Situation. Das erste das auffällt ist der reißerische Titel Is the OSM data model creaking? Der Anfang ist aber gleich gut: Wir modellieren flows. Das ist schon einmal eine Ansage: Wie soll ein flow OTG wahr sein? Aber eh, aus der Sicht von jemandem, der seit über einem Jahrzehnt an einem Router arbeitet, da kann es schon so aussehen. Und recht überlegt, so falsch ist es womöglich gar nicht. Denn es macht die Daten für Zwecke der Navigation brauchbar, einfach und gut. Ich kann mir vorstellen, dass Grundlagen für Navigation schaffen das Hauptmotiv von sehr vielen Edits an den Daten ist.
Weil, Neulinge bekommen das ja auf der Willkommensseite nach dem Anmelden so vorgesetzt, openstreetmap ist dazu da, Dinge in der Welt, an denen man ein Interesse hat, mit ihren Geokoordinaten in die Datenbank zu stellen. Bekannte von mir haben schon vor fünf Jahren das Interesse verloren, weil eh schon alles drin ist. Und es ist wirklich viel drin. Auch viel Unnützes, aber wer soll das entscheiden, und Platz ist Ende nie.
Der Vortrag kommt dann über ein paar Umwege zu dem Schluss, dass das Mappen von immer mehr flows, die sich ja ausgezeichnet als Linien darstellen lassen: Hier gehen die Leute, da fahren die Räder, dort fahren die Autos, die Mädchen nach links, die Knaben nach rechts; einen Haufen neue Informationen bringt, die sich für Navigationszwecke verwenden lassen, aber das Ende der Fahnenstange auch nicht ist. Nicht zuletzt, weil die Abbildung sich nicht in sinnvolle, verständliche turn-by-turn Anleitungen übersetzen lässt.
Richtig paradox wird es dann, wenn ich so Zeug lese, wie hier im Thread, "man könnte ja auch den “highway” als Attribut vom “cycleway” mappen, ganz so, als würde “highway” für Fahrbahn stehen. Highway steht für Straße, und da gehört mehr dazu als die Fahrbahn. So weit ist das Separieren scheints schon, dass Leute vor lauter flows separieren die Lebenswelt nicht mehr kennen. Das betont und damit endet ja auch der Vortrag, dass es ein Manko ist, dass es kein Konzept für so etwas alltägliches wie eine Straße gibt, das aber ein gravierendes ist, in einer openstreetmap nicht zuletzt, und dem abgeholfen werden muss. Von daher wohl der Titel des Vortrags.
Das mit den Flächen, als eine Art Relation, für die keine Linien gesplittet werden müssen, die diverse Inhalte erfassen kann, ohne dass dafür eine neue Rolle erfunden werden müsste usw. Das wäre ein Hit. Als ein Platzhirsch hat cyclestreets.net ja Ressourcen. Flächenrouter sind nicht trivial zu machen. Fußrouting das das nicht kann, das hat den Namen nicht verdient. Radrouting gehts wohl ebenso. Sogar Autorouter kämpfen ein Einzelfällen. Nur Bahnrouter nicht
damit Flächenrouting für Fußgänger überhaupt funktionieren könnte bräuchte man vollständige Daten was relevante Hindernisse angeht, jeder Zaun und jede Mauer und Böschung, jedes Cliff und jeder Graben, etc. lückenlos und detailliert, vielleicht gibt es das in Deutschland in manchen Gegenden, aber die Idee die existierenden Wege als Linien vorzugeben macht das ganze auch schon sinnvoll nutzbar lange bevor es „komplett“ ist.
Ich bin ja garnicht dagegen. Nur finde ich es merkwürdig, dass wir hier über den Rext reden und du ohne zu reden ihn einfach raus nimmst.
Schwamm drüber!
Ja, dort passt es gut.
Meines Erachtens gehört die Ausführlichkeit der Vor- und Nachteile auch dort nicht hin, da bin ich deiner Meinung. Dazu habe ich ja die Vor und Nachteile in einer eigenen Gegenüberstellung zusammengesammelt.
Eine Entscheidungshilfe passt da aber sehrwohl. Unter “Hinweise” gibt es bereits eine Überschrift “Entscheidungshilfe zwischen footway, cycleway und path”. Davor oder danach könnte es als “Entscheidungshilfe zum Erfassen des Radwegs als eigenständige Linie oder an der Straßen-Linie” .
Die übergeordnete Überschrift sollte m. E. aber nicht “Kontroversen und Mehrdeutigkeiten” heißen, wenn dort Entscheidungshilfen enthalten sind. Im Text wird ja bereits darauf hingewiesen, dass die Alternativen häufig diskutiert werden. Was mit “Mehrdeutigkeit” gemeint ist, erschließt sich mir auch nicht.
Allerdings frage ich mich, ob einige der Kontroversen nicht bereits von der Praxis beantwortet wurden:
Ist das noch kontrovers? Beschwert sich z. B. heute noch jemand, wenn man bei einem gemeinsamen Geh-/Radweg mit Zeichen 240 das ‘hw=cycleway’ durch ‘hw=path’ ersetzt?
Das ist hier im Forum doch recht oft ein Thema. Das zeigt schon, dass es wichtig ist. Auch bedarf es Aufklärung, weil gerade beim Getrennt-Mappen viel falsch gemacht wird.
Grundsätzlich finde ich die Anleitungen der Berliner-Verkehrswendegruppe dafür sehr gut. Wenn man das Zusammenführen könnte, das wäre schön. Allerdings beschreiben die Berliner nur das Getrennt-Mappen, alles andere wird eher beiläufig erwähnt. Die anderen Taggingschemen sollten in der gleichen Qualität beschrieben werden. Auch deren Empfehlung widerstrebt mir zutiefst, für Gehsteige und Radwege getrennte Linien zu zeichnen.
Noch eine mögliche Baustelle im Wiki … ich muss erstmal meine offenen Baustellen beenden.
Ich hatte auch schonmal überlegt, ob man beim Seperat-Mappen die kontinuierliche Querungsmöglichkeit über eine Fläche abbildet. Nur im Bereich der Querungsmöglichkeit ist die Fläche mit Radweg und Fahrbahn verklebt. Ein entsprechendes neues Attribut sagt aus, dass die Fläche nur eine abstrakte Übergangsmöglichkeit darstellt. Ggf. erhält die Fläche Attribute für Widerstände wie z.B. Bordsteinhöhen.
Es werden also nur die Flächen getaggt, die fürs Routing notwendig sind mit dem Ziel, bestimmte Linien in bestimmten Abschnitten miteinander zu verbinden. Das würde auch für das im Vortrag genannte Beispiel mit fußgängerrouting “nach rechts” helfen.
Das ist etwas Anderes, Abstrakteres, als das Abzeichnen der Fahrbahn und Radwegflächen von den Luftbildern, wie es im Flächentagging mitunter gemacht wird.
Allerdings ist es in OSM untypisch, logische Verknüpfungen zwischen den Linien über Flächen abzubilden. Das machen sonst immer Relationen. Mit Relationen ist das aber nicht handhabbar. Es wäre eine Flut von Drei-Kanten-Relationen. Dass Radweg und Straße bei Beginn und Ende der kontinuierlichen Querungsmöglichkeit gesplittet werden müssten ist auch blöd.
Neukölln, deren “Karte” heut in der review gefeatured wurde, dort gehts in die Richtung. Ich bin immer wieder erstaunt, wofür Leute Interesse aufbringen. In meinen Augen ist die vorgestellte Ausarbeitung keine Karte, sondern ein Plan. Sie geht weit über das hinaus, was man als Stadtplan kennt. Von der Anmutung her ist das so etwas der Art, was Architekten aus den Plänen machen, die sie von den Bauherrn bekommen oder vom Tiefbauamt. Es muss im ArcGIS da einen Knopf dafür geben. Die Neuköllner erzeugen die Flächen aber aus Linien. Das ist trotzdem etwas ganz etwas anderes als eine Karte, wie OSM-Carto.
Hierbei zu tun, als sollte die ganze Welt dem nacheifern, das führt zu hypergemappten Mini-Inseln die an ihren Enden ausfransen, auf sehr sehr lange Zeit. Als lokales Projekt ist es aber recht gut gediehen. Immerhin werden sogar Radwege die als lane Attribut an der Straße erfasst sind als Flächen gerendert, was angeblich viel “post-processing” erfordert. Ich würde meinen, dass nun nicht mehr viel fehlt, mit sidewalks ebenso zu verfahren?
Ob sich die generierten Flächen für Routing weiterverwenden lassen? Selbst wenn eine Programmierstunde so viel kostet wie 100 Mapperstunden könnte sich das auszahlen.
Auch A/B-Street wurde erwähnt, das hat einen guten Fußrouter, aber die Herangehensweise ist eine ganz andere. Bei den einen geht es um ein statisches Abbild, der andere will Verkehr simulieren. Interessanterweise ist A/B Street mit Attributen viel besser bedient als mit separaten Ways. Hat auch ganz einen ganz anderen Begriff der “Straße”. In Neukölln könnte ich meinen, die Straße ist der Raum, der zwischen den Landuse=Residential ausgespart ist. In A/B-Street ist die Straße ein multimodaler Verkehrsweg.
Ich hab die Sammlung der Für und Wider im Detail durchgelesen. Das ist ein Arbeitspapier. Sehr fundiert. Aber mir fällt beim besten Willen nicht ein, wie das in den Radwege-Kartieren Artikel einfügen, obwohl die Angelegenheit dort sogar mehrfach angesprochen wird.
In diesem Zusammenhang sollte man aber auch bedenken, wie die Neuköllner dort vorgehen: Dieses Rendering basiert nicht nur auf Linien, sondern auch auf Flächen. Hier werden massiv landuse=residential für den Renderer effektiv missbraucht. https://www.openstreetmap.org/#map=19/52.47845/13.43894
Diese werden genutzt um die Grenzen des Gehweges nachzuzeichnen…
?