OSM-Wiki: neue Seiten im Zusammenhang mit Projekt "namo"

Das Problem ist nicht in erster Linie das Wiki.

Wenn das gemacht wird, was ich da zu sehen glaube, wird das bis dato übliche Tagging von Straßen komplett über den Haufen geworfen. Bis jetzt wurden z.B. Gehsteige, die baulich nicht von der Straße getrennt waren, per Attribut sidewalk=* zur Straße hinzugefügt. In dem Bild http://wiki.openstreetmap.org/wiki/File … n_namo.JPG aber sind jetzt alle Randsteine als eigene Ways parallel zur Straße angelegt.

Ich hätte nichts dagegen, für Behinderte die Randsteinhöhe analog zum key sidewalk mit zur Straße hinzuzufügen, aber bitte nicht als getrennte Linien links und rechts der Straße. Das verdreifacht, wenn konsequent angewendet, schlagartig das Linienwirrwarr in Innenstädten um den Faktor 3.

Hat jemand Kontakt zu diesem Projektgruppe, die es sicher gut meint, aber mit diesem Vorschlag (so wie ich es sehe) völlig unkoordiniert an der bisherigen Tagging-Praxis vorbei arbeitet.

seichter wrote:

Das Problem ist nicht in erster Linie das Wiki.

Wenn das gemacht wird ...

www.openstreetmap.org/user/namo1/edits

seichter wrote:

Das Problem ist nicht in erster Linie das Wiki.

Wenn das gemacht wird, was ich da zu sehen glaube, wird das bis dato übliche Tagging von Straßen komplett über den Haufen geworfen. Bis jetzt wurden z.B. Gehsteige, die baulich nicht von der Straße getrennt waren, per Attribut sidewalk=* zur Straße hinzugefügt. In dem Bild http://wiki.openstreetmap.org/wiki/File … n_namo.JPG aber sind jetzt alle Randsteine als eigene Ways parallel zur Straße angelegt.

Ich hätte nichts dagegen, für Behinderte die Randsteinhöhe analog zum key sidewalk mit zur Straße hinzuzufügen, aber bitte nicht als getrennte Linien links und rechts der Straße. Das verdreifacht, wenn konsequent angewendet, schlagartig das Linienwirrwarr in Innenstädten um den Faktor 3.

Hat jemand Kontakt zu diesem Projektgruppe, die es sicher gut meint, aber mit diesem Vorschlag (so wie ich es sehe) völlig unkoordiniert an der bisherigen Tagging-Praxis vorbei arbeitet.

ja, sie waren beim Stammtisch in Frankfurt. Wir haben die Erfahrungen von MentzDV geschildert, das beschriebene Mappen haben wir kommentiert, aber nicht abgelehnt. Es soll auf diese beiden Bereiche beschränkt sein, ist halt ein Forschungsprojekt. Sie wollten noch eine mail an talk-de und hier über ihr Projekt schreiben, vermutlich in den nächsten Tagen.

Somit sehe ich die Diskussion als eröffnet... duck weg...

Mich erinnert das ganze an eine Begegnung auf dem OSM-Stand auf der Intergeo Anfang Oktober. Da waren zwei Leute von irgendeiner Uni (?) da, die genau das für ein Projekt erfassen wollten. Sie wollten Bürgersteige hinsichtlich ihrer Barrierefreiheit erfassen. Ich habe sie dann nach bestem Wissen und Gewissen beraten (d.h. nur bei baulicher Trennung eigenständige Linien, sonst sidewalk-Tag). Deren allererste Änderungen waren aber in Nürnberg und nicht im Raum Frankfurt.

Auch wenn es vielleicht hart klingen mag, aber für mich sieht dies ein wenig nach feindlicher Übernahme aus. Auch wenn ich es gutheiße, dass angeblich auch IT-Firmen beteiligt sind.

Nur ohne jedweger Diskussion (in Forum und ML) Tagging-Schemas einführen zu wollen, (und das kann nicht bestritten werden "und wird neu definiert, da es im OSM-Standard nichts Vergleichbares gibt." [1]) und auch noch dazu die Wiki zu missbrauchen finde ich nicht die höfliche Art in einem Projekt vorstellig zu werden. Macht zumindest auf mich einen präpotenten Eindruck.

[1] http://wiki.openstreetmap.org/wiki/Querneigung

PS: Ich wäre für die Reduktion auf einen Wiki-Eintrag und wenn später mehr gebraucht werden, sollten sie im Namen eindeutig das "namo" tragen (solange es nicht durch die üblichen Methoden diskutiert wurde)

Ich habe dem Projekt eine Mail geschrieben mit der Bitte, doch offline zu arbeiten - möglicherweise haben da Studenten im Eifer des Gefechtes nicht bedacht, was sie da anrichten.
Mal sehen.

mgehling wrote:

Sie wollten noch eine mail an talk-de und hier über ihr Projekt schreiben, vermutlich in den nächsten Tagen.

Bloß nichts überstürzen, sie editieren ja erst seit vier Monaten.

Oli-Wan wrote:

mgehling wrote:

Sie wollten noch eine mail an talk-de und hier über ihr Projekt schreiben, vermutlich in den nächsten Tagen.

Bloß nichts überstürzen, sie editieren ja erst seit vier Monaten.

...am 4.11 war Stammtisch, dort haben wir eine Wiki Seite vorgeschlagen, und wie man sieht, ist es für eine Mail noch zu früh...

stephan75 wrote:

Und die Hauptseite

http://wiki.openstreetmap.org/wiki/%27% … n%27%27%27

könnte in Hinblick auf den bisherigen allgemein gültigen Arbeitsstil im Wiki auch eine Umbenennung "vertragen".

ist umbenannt. http://wiki.openstreetmap.org/wiki/Namo

surface = paving_stone:double_t
auch deren Erfindung ?

Oli-Wan wrote:

mgehling wrote:

Sie wollten noch eine mail an talk-de und hier über ihr Projekt schreiben, vermutlich in den nächsten Tagen.

Bloß nichts überstürzen, sie editieren ja erst seit vier Monaten.

Das Projekt läuft über 3 Jahre und soll bis Ende 2014 (?) gehen. Spätestens dann entschläft es sanft und wir behalten den Schrott drin.

Wehret den Anfängen.

Gruss
walter

Nur mal so:

• Die Doppellinie in Straßen als bauliche Trennung wurde verworfen (im Wiki geändert)
  
• Warum nicht Rad-/Fußwege neben Straßen - mittlerweile sollten wir Detailmapping (auch für 3D) akzeptieren.
  
• Es ist N3 für LKW über 12,5 t eingeführt.
  
• eine Trennung von Flächen und Wegen sollte auch möglich sein. Fläche an Fläche (leisure, amenity, building in die Fläche - ways über die Fläche)
  
• Im Wiki ist manches auf dem Stand von ... obwohl sich fast alles weiterentwickelt.
  
• Stolpersteine sind auf "Fußwegen (meist)
  

Wenn Details ein DB-Problem (Speicherplatz? oder?) bereiten, sollte man eventuell eine DB einfach mit einer DB-Detail (3D?) verknüpfen?

PS:

surface = paving_stone:double_t
auch deren Erfindung ?

Hier sollte man eventuell orientieren auf
surface = paving_stone
paving_stone=double_t

(Finde ich besser als manche tracks mit surface=ground;gras;paved)

mgehling wrote:

stephan75 wrote:

Und die Hauptseite

http://wiki.openstreetmap.org/wiki/%27% … n%27%27%27

könnte in Hinblick auf den bisherigen allgemein gültigen Arbeitsstil im Wiki auch eine Umbenennung "vertragen".

ist umbenannt. http://wiki.openstreetmap.org/wiki/Namo

Hallo Marc,

danke fürs Umbenennen!

Jetzt sind aber noch diese Seiten verblieben: http://wiki.openstreetmap.org/wiki/Spec … sHere/Namo

Wie kann man diese jetzt zu Wiki-Unterseiten von Namo machen?
Einfach umbenennen in Namo/xxxxx ?

Stephan

stephan75 wrote:

Wie kann man diese jetzt zu Wiki-Unterseiten von Namo machen?
Einfach umbenennen in Namo/xxxxx?

Ja. Dadurch werden teilweise auch Seiten Unterseiten von anderen, obwohl das nicht gewünscht ist (z.B. "GNU/Linux" von "GNU"), weshalb in Wikipedia Unterseiten im ANR deaktiviert sind.

Ich hole den Thread mal wieder hervor, da das Projekt am Donnerstag nun auch angefangen hat in Bad Nauheim zu mappen. Momentan ist ein recht großer Teil der eingetragenen Wege noch ganz ohne Tags, wobei diese wohl automatisch mit einem festen Offset parallel zu den bestehenden Straßen erzeugt wurden. Diese Art der Voraberstellung ohne Berücksichtigung der bestehenden Daten hat dann vermutlich dazu geführt, dass dieser, bereits vorhandene, Gehweg ignoriert und direkt daneben eigene Wege (Beispiel) erstellt wurden. Ansonsten ist mir auch noch aufgefallen, dass sich beim Taggen von Übergängen mit Ampeln durchgängig ein kleiner Tippfehler eingeschlichen hat (crossing=Traffic_signals).

Stellt sich die Frage, wie es hier weiter gehen soll. Gab es im November von Seiten des Projekts eine Reaktion? Zumindest im Wiki als auch auf talk-de konnte ich nichts finden.

TOGA wrote:

Diese Art der Voraberstellung ohne Berücksichtigung der bestehenden Daten

Es sieht sogar so aus, als würden sie ihre eigenen Daten nicht berücksichtigen und auch mal selbst zwei gleich getaggte parallele Wege (260279038 und 260279701) einzeichnen. Das Routen dürfte auch schwierig werden, wenn man seine Wege nicht mit kreuzenden Wegen verbindet...

Hallo,

danke TOGA fürs Hervorholen dieses Threads.

Ich habe mir mal die Edits dieses Users/des Projekts genauer angeschaut.

Zuerst habe ich mir einen Überblick verschafft, wo namo1 aktiv war. Dazu habe ich bei WhoDidIt nach den Gegenden gesucht, wo namo1 aktiv war.

Da man da nur grobe Rechtecke sieht, habe anschließend den Overpass-Turbo befragt (für die Region Bad Nauheim):

<user␣name="namo1"/>
<print␣mode="meta"/>

Wenn ich mir die Edits in Bad Nauheim (Bereich Burgallee) anschaue, kann ich TOGAs Beobachtungen bestätigen.

Es gibt zwei Arten von Wegen:

• Die einen Wege haben keine Tags und weisen einen konstanten Offset zur Straße auf. Wenn sie, was ich vermute, Bürgersteige repräsentieren sollen, dann sind sie falsch. In der Burgallee und vielen anderen Straßen sind die Straßen meist breiter und somit die Bürgersteige weiter von der Straßenachse entfernt. Diese Wege sind nicht mit dem Wegennetz verbunden. Ich vermute, dass diese Wege automatisch erstellt worden sind. Es gibt z.B. Wege, die auf Bing gar nicht existieren. (Ich bin nicht ortskundig.)
• Die anderen Wege haben Tags, liegen auf dem Bürgersteig, sind aber auch nicht mit dem übrigen Wegenetz verbunden. Letzteres ist nicht richtig. OSM ist keine Datenbank für private Geodaten.

Außerdem ist mir aufgefallen, dass der Changeset-Kommentar immer gleich ist. Das ist zusammen mit dem konstanten Offset und nicht existenten Bürgersteigen ein Zeichen für automatische Edits, auch wenn der User-Agent JOSM ist. Automatische Edits sind anmeldepflichtig. Ich kann mich nicht an eine Ankündigung hier Forum, auf talk-de oder auf talk (nicht ganz passend, da die Edits auf Deutschland beschränkt sind) erinnern.

Wege ohne Tags (und ohne note=* o.ä.), sind nicht nützlich und nicht sinnvoll. Solche Wege kann man eigentlich löschen. Was haltet ihr davon? Soll ich die Edits, die Ways ohne Tags löschen? Die Data Working Group würde ich erst einschalten, wenn sie nach der Löschung dieselben Wege ohne Tags erneut "automatisch" hochladen.

Ich habe eine PN an namo1 geschrieben mit Verweis auf diesen Thread und der Bitte, sich hier zu melden (siehe unten). Damit sie auch auf jeden Fall Bescheid wissen (vielleicht wurde der Account mit einer Wegwerfadresse registriert), habe ich auch noch eine Mail an die Mailadresse, die ich auf deren Website gefunden habe, gesendet.

Nakaner wrote:

Liebe Leute vom namo-Projekt,

könntet ihr euch bitte mal im OpenStreetMap-Forum folgeden Thread durchlesen und euch dort melden? Mehrere Mapper, nicht nur ich, stören sich daran, wie ihr Daten in OSM eintragt. http://forum.openstreetmap.org/viewtopic.php?id=23208

Bei euren Bearbeitungen in der Nähe der Burgallee in Bad Nauheim ist mir folgendes aufgefallen:

1. Ihr ladet Wege hoch, die einen konstanten Offset zur Straßenachse haben. Das ist in meinen Augen eine automatische Änderung. Automatische Änderungen müssen vorher über die Mailingliste oder das Forum angekündigt werden. Siehe dazu auch unsere "Mechanical Edit Policy". http://wiki.openstreetmap.org/wiki/Mech … dit_Policy
2. Die Wege haben keine Tags. Wege ohne Tags haben keinen Nutzen. Ihr braucht euch nicht wundern, wenn die mal jemand löscht. Bitte ladet die Wege erst hoch, wenn sie getaggt sind!
3. Könntet ihr euch bitte an die etablierten Tagging- und Mapping-Schemata halten?

Wenn ein Fußweg keine bauliche Trennung (Mauern, Grünstreifen, Zäune und Geländer sind z.B. bauliche Trennungen, Bordsteine hingegen nicht) aufweist, wird er nicht als eigenständige Linie eingetragen. Stattdessen ergänzt man an der Straße sidewalk=both (bei beiderseitigem Bürgersteig) bzw. sidewalk=right/left (wenn es in OSM-Linienrichtung nur auf einer Seite einen nicht abgetrennten Bürgersteig gibt). Für die Bürgersteig-Eigenschaften stellt man den Tags einfach ein "sidewalk:" voran, also sidewalk:surface=paving_stones statt surface=paving_stones, da das reine surface=paving_stones für die Fahrbahn gilt. Fußgängerüberwege werden bei OSM durch Nodes repräsentiert, die mit crossing=* getaggt sind.

Wenn ein Fußweg eine Straße kreuzt und es keine Brücke/Unterführung ist, müssen die beiden Linien miteinander verbunden sein (einen gemeinsamen Punkt haben).

Bitte führt eure neuen Tags durch Tagging Proposals ein und haltet Kontakt zur Community. http://wiki.openstreetmap.org/wiki/Proposal

Mir ist klar, dass diese Änderungen bei der Software, die eure Daten nutzt, erhebliche Anpassungen erfordern. OSM ist keine Datenbank, in die man einfach seine privaten Geodaten reinschreiben kann. OSM funktioniert nur, wenn sich alle Beteiligten an gemeinsame Standards halten und offen miteinander kommunizieren.

Die gesamte Software, die OSM zugrunde liegt (egal ob Editoren, Datenbank oder Website) ist freie Software. Ihr könnt auch eure eigenen private Datenbank nach dem OSM-Schema aufsetzen. Ihr wärt nicht die ersten, die OSM-Technologie für eine Geodatenbank nutzen.

Es ist nicht so schlimm, wie die oben genannten Patzer, aber bitte gebt euren Changesets künftig aussagekräftigere Kommentare beim Hochladen. Also nich einfach "namo - Mobil im Alter (http://wiki.openstreetmap.org/wiki/Namo)", sondern z.B. "Bürgersteig-Eigenschaften in der Burgallee in Bad Nauheim". http://wiki.openstreetmap.org/wiki/DE:G … t_comments

Abschließend möchte ich euch darum bitten, euch unbedingt im Forum zu melden und euch den Fragen und Bitten der Community zu stellen. OSM ist ein Community-Projekt. Da gehört es dazu, dass man sich als Projekt eurer Art, die Fragen der Community beantwortet und sich nicht stumm stellt!

Bitte entschuldigt den etwas ruppigen Tonfall in dieser Mail.

Viele Grüße

Michael

Nakaner wrote:

...

Wege ohne Tags (und ohne note=* o.ä.), sind nicht nützlich und nicht sinnvoll. Solche Wege kann man eigentlich löschen. Was haltet ihr davon? Soll ich die Edits, die Ways ohne Tags löschen? Die Data Working Group würde ich erst einschalten, wenn sie nach der Löschung dieselben Wege ohne Tags erneut "automatisch" hochladen.

....

Hmm...da sich die Änderungen nur auf sehr kleine Gebiete beschränken, würde ich da vielleicht nochmal abwarten. Es wäre halt schön, wenn nun recht kurzfristig eine Kommunikation zwischen dem Projekt und der Community stattfinden würde.

Nach meiner Erfahrung in Bockenheim: Diese Wege sind nur Zwischenprodukte - keine Ahnung, warum die hochgeladen werden. Ein paar Wochen später wurden sie dann mit Tags versehen. Kontakt mit der Frankfurter Community gab es aber schon, u.A. auf dem Frankfurter Stammtisch. Die Lage relativ zu den Straßen wurde dann nachträglich auch noch deutlich verbessert, auch wenn einige Wege immer noch durch Häuser führen.
Sie zu überzeugen, die Wege auch wirklich mit den Straßen zu verknüpfen, haben wir aber nicht geschafft. Dafür gibt es in Bockenheim jetzt vierspurige Fußgängerüberwege (lanes=4)...

mueschel wrote:

Nach meiner Erfahrung in Bockenheim: Diese Wege sind nur Zwischenprodukte - keine Ahnung, warum die hochgeladen werden. Ein paar Wochen später wurden sie dann mit Tags versehen. Kontakt mit der Frankfurter Community gab es aber schon, u.A. auf dem Frankfurter Stammtisch. Die Lage relativ zu den Straßen wurde dann nachträglich auch noch deutlich verbessert, auch wenn einige Wege immer noch durch Häuser führen.
Sie zu überzeugen, die Wege auch wirklich mit den Straßen zu verknüpfen, haben wir aber nicht geschafft. Dafür gibt es in Bockenheim jetzt vierspurige Fußgängerüberwege (lanes=4)...

Also das Verknüpfen von Fußwegen mit den Straßen sollte das mindeste sein. *aufreg* Wie soll da ein 08/15-Router (wie OSRM, OsmAnd, Graphhopper) eine FußgängerRoute von irgendeiner Adresse aus berechnen, wenn das Ziel nicht über das namo-Bürgersteignetz erreichbar ist?

Meine Meinung ist vielleicht ein bisschen "radikal", aber wer sich nicht an die Community (die Community ist der Hausherr von OSM) anpassen möchte und seine Modellierungsideen nicht der Community-Öffentlichkeit richtig vorstellt, braucht sich nicht wundern, wenn sich jemand mal um das Zeug kümmert. Kümmern heißt für mich, dass man die Tags der Bürgersteig-Ways an die Straßen heftt (d.h. wenn der Bürgersteig surface=asphalt hat, wird der Bürgersteig gelöscht und die Straße hat dann surface:sidewalk[:right/left]=asphalt). Bevor man jedoch die Tags an die Straßen heftet, würde ich die DWG informieren, damit die denen von namo mal ins Gewissen redet.

Viele Grüße

Michael

EDIT: Link auf Modellierungsideen ergänzt

Also das mit den Modellierungsideen ist ja schon ein wenig frech. Oder verstehe ich das falsch? Allein wenn man sich die beiden Bilder nach OSM- und deren Schema anschaut. Ich mein, ist ja schön wenn man sich um Probleme kümmert und sich Gedanken macht, aber 1. hat deren Schema eben auch Schwächen und 2. sollte so etwas doch wenigstens von der Gemeinschaft zur Diskussion gegeben werden.

Schina02 wrote:

Also das mit den Modellierungsideen ist ja schon ein wenig frech. Oder verstehe ich das falsch? Allein wenn man sich die beiden Bilder nach OSM- und deren Schema anschaut. Ich mein, ist ja schön wenn man sich um Probleme kümmert und sich Gedanken macht, aber 1. hat deren Schema eben auch Schwächen und 2. sollte so etwas doch wenigstens von der Gemeinschaft zur Diskussion gegeben werden.

Ich habe bei namo den Eindruck (siehe auch meine PN an namo1), dass die OSM nur als Ablageort benutzen und ein paar Mapper als Datenerfasser gewinnen wollen.

Irgendwie erinnert mich das ganze an das erste Hallo von Mentz DV auf talk-de, nur dass die Grundeinstellung von Mentz ganz anders war (Offenheit) und das ganze gut ausgegangen ist.

Zur Info:
Auf meine Mail vom 12.11. kam keine Reaktion.

Meine Einschätzung, dass da jemand OSM als günstige Entwicklungsplattform benutzt (missbraucht?), hat sich nicht geändert.

Wer zu einem crowd-sourcing-Projekt Daten beisteuert, sollte sich an ein Mindestmaß an Regeln halten.

seichter wrote:

Zur Info:
Auf meine Mail vom 12.11. kam keine Reaktion.

Danke, gut zu wissen. Das bestätigt mich.

Ich glaube, dass die aktiver/redseliger werden, wenn sich die DWG um die kümmert (muss nicht unbedingt eine Sperre sein).

Hallo Michael,

ich kenne von einem anderen ÖPNV-Projekt jemand bei der rms GmbH und könnte da über den "kleinen Dienstweg" gehen. Ich nehme an, dass du die Mail aus #18 erst heute weggeschickt hast. Wenn am Montag keine Reaktion erfolgt, werde ich mal nachfragen.

Grüße
Joachim

Hallo Joachim,

DD1GJ wrote:

ich kenne von einem anderen ÖPNV-Projekt jemand bei der rms GmbH und könnte da über den "kleinen Dienstweg" gehen. Ich nehme an, dass du die Mail aus #18 erst heute weggeschickt hast. Wenn am Montag keine Reaktion erfolgt, werde ich mal nachfragen.

Die PN und die Mail habe ich nahezu gleichzeitig mit dem Post abgeschickt. Aus den Edits heraus habe ich schon erkannt, dass die nur während der Arbeitszeiten. aktiv sind.

Ja, das wäre toll, wenn du da vermitteln würdest. Sonst wird das mit einem vergifteten Klima enden. Das will ich nicht ...

Viele Grüße

Michael

Hallo,

ich habe bis jetzt keine Antwort auf meine PN bekommen. Auch meinen Mail, die kurz und knapp auf die PN hinwies, wurde nicht beantwortet. Ich rechne nicht nach 21:00 Uhr (eigentlich nach 16:30 Uhr) mit einer Antwort.

EDIT: namo1 scheint heute entweder die PN gelesen zu haben oder Urlaub zu haben oder krank zu sein, da der User namo1 heute nicht aktiv war. 🙂

Viele Grüße

Michael

Ich rufe dann morgen freundlich an ...

Das Telefonat hat stattgefunden und das Projektteam wird firmenintern nochmals auf die Diskussion hier hingewiesen. Die Firma ist nächste Woche auf der IT-TRANS in Karlsruhe vertreten und wird daher am nächsten Mittwoch (19. Februar) beim Karlsruher Stammtisch anwesend sein.

DD1GJ wrote:

Die Firma ist nächste Woche auf der IT-TRANS in Karlsruhe vertreten und wird daher am nächsten Mittwoch (19. Februar) beim Karlsruher Stammtisch anwesend sein.

"Auf sie mit Gebrüll" 😉

Ne, danke, daß du das mal angetriggert hast und hoffe, daß die Kommunikation sich verbessert.

Gruss
walter

DD1GJ wrote:

Das Telefonat hat stattgefunden und das Projektteam wird firmenintern nochmals auf die Diskussion hier hingewiesen. Die Firma ist nächste Woche auf der IT-TRANS in Karlsruhe vertreten und wird daher am nächsten Mittwoch (19. Februar) beim Karlsruher Stammtisch anwesend sein.

Das passt mit dem zusammen, was mir heute auf meine PN geantwortet wurde.

Wenn nichts dazwischenkommt, werde ich auch wieder da sein (wie auch beim Hackweekend kommendes Wochenende).

Auszüge aus der Antwort vom namo-Projekt:

namo1 wrote:

Ersteinmal möchte ich mich dafür entschuldigen, dass wir die OSM-Community mit unserer Datenerhebung derartig "überrumpelt" haben - das sehen wir auch ein.

In Zukunft wollen wir die Community stärker einbinden, da wir im Sinne der Nachhaltigkeit hoffen, dass das Konzept der beidseitigen Pflege von Fußwegekanten auf die Akzeptanz der Mapper stößt, damit jene ggf. in Zukunft ihre Daten in dieser Form pflegt.

namo1 wrote:

[...]
Da dies ein Forschungsprojekt ist, bitten wir, dass Ihr nicht direkt von Anfang an euch unserer Datenerhebung verschließt, sondern dass wir gemeinsam darüber diskutieren, da durch das anschließend entwickelte Fußwegerouting alle profitieren sollen.

Die ungetaggten Ways in Bad Nauheim wollen sie jetzt erstmal wieder löschen. Noch ist nichts geschehen, letzter Edit von namo1 war am Freitag.

Viel mehr Nennenswertes stand nicht in der PN.

Ich würde jetzt erstmal den Stammtisch in Karlsruhe nächste Woche abwarten, an dem (da Karlsruhe) auch ein DWG-Mitglied sitzt.

Hallo zusammen,

auch wenn das jetzt nicht ganz zum Thema passt: In der heutigen hessenschau war ein Bericht über die Rollstuhlfahrer-App (wheelmap) - ab morgen dürfte die Aufzeichnung auch in der Mediathek des hr (www.hr-online.de) zu sehen sein.

Auf http://www.heise.de/newsticker/meldung/ … 05098.html kann man auch schon einen ersten Einblick gewinnen...

Vielleicht könnte man hier zwischen den beiden Projekten einen Kontakt herstellen, da die Zielsetzung ziemlich identisch sein dürfte (Barrierefreies Routing).

VG,
Thorsten

DoDoMR wrote:

Hallo zusammen,

auch wenn das jetzt nicht ganz zum Thema passt: In der heutigen hessenschau war ein Bericht über die Rollstuhlfahrer-App (wheelmap) - ab morgen dürfte die Aufzeichnung auch in der Mediathek des hr (www.hr-online.de) zu sehen sein.

Auf http://www.heise.de/newsticker/meldung/ … 05098.html kann man auch schon einen ersten Einblick gewinnen...

Vielleicht könnte man hier zwischen den beiden Projekten einen Kontakt herstellen, da die Zielsetzung ziemlich identisch sein dürfte (Barrierefreies Routing).

VG,
Thorsten

Hallo DoDoMR,

vielen Dank für den Hinweis - allerdings kann ich Ihnen mitteilen, dass zwischen diesem und unserem Projekt bereits erste Gespräche stattgefunden haben.

Nakaner wrote:

Die ungetaggten Ways in Bad Nauheim wollen sie jetzt erstmal wieder löschen. Noch ist nichts geschehen

Ich werde mich morgen darum kümmern.

Mit freundlichen Grüßen,
namo1

Nakaner wrote:

Also das Verknüpfen von Fußwegen mit den Straßen sollte das mindeste sein. *aufreg* Wie soll da ein 08/15-Router (wie OSRM, OsmAnd, Graphhopper) eine FußgängerRoute von irgendeiner Adresse aus berechnen, wenn das Ziel nicht über das namo-Bürgersteignetz erreichbar ist?

Nach dem OSM-Stammtisch in Frankfurt am Main haben wir Ihr Anliegen umgesetzt und an den Eintrittspunkten am Randbereich in unserem Untersuchungsgebiet die Verknüpfung mit den bereits bestehenden Kanten vorgenommen, damit ein Einsprung von anderen Routern - sowohl unserem eigenen Router - in und aus dem Testgebiet stattfinden kann (siehe Bild).

Haben wir noch etwas nicht bedacht?

Viele Grüße,
namo1

namo1 wrote:

Haben wir noch etwas nicht bedacht?

naja, ein link wäre nett, da es schwierig ist herauszufinden, wer von euch das wann und wo gemacht hat.
eure changeset-Kommentare "namo - Mobil im Alter" könnt ihr gleich weglassen, die sagen uns garnichts 🙁

Gruss
walter

Ich habe mal geschaut und die Stelle auf dem Bild in Frankfurt-Bornheim gefunden: http://www.openstreetmap.org/node/1649025644 ist die Apotheke oben rechts.

Die gezeigte Stelle ist eher unproblematisch, und die erforderlichen Straßenübergänge sind eingezeichnet. Das ist aber eher die Ausnahme, siehe z.B. an dieser Kreuzung: http://www.openstreetmap.org/node/31506328. Da kann man die Straße eigentlich überall überqueren, und jede Einzeichnung eines Fußwegs zur Querung wäre willkürlich. Konsequenterweise hat man es auch (noch?) nicht gemacht.

Ich denke, solange die Definition sagt, dass Bürgersteige, die unmittelbar am Straßenrand verlaufen, nicht als eigener Way eingezeichnet werden, so lange sollte man es auch nicht machen. Denn die jetzige Semantik sagt, dass man als Fußgänger die Straße nicht überqueren kann, wo kein Fußweg eingezeichnet ist. Das entspricht aber meist nicht der Realität.

Aber selbst wenn eine legale Möglichkeit gefunden würde, Bürgersteige einzuzeichnen, damit ein Rollstuhlfahrer außerhalb seines gewohnten Bereiches aufgrund von OSM-Daten sich einen geeigneten Weg routen lassen kann: Woher will man die Mapper nehmen, die diese unzähligen Bürgersteige malen und taggen? Und dabei darauf achten, dass das ganze sowohl Fußgänger-, als auch Fahrradfahrer und Rollstuhlfahrer-kompatibel ist? Da sehe ich dann doch sehr schwarz. Nicht, dass es nicht prinzipiell ginge. Aber es müssten Mapper sein, die auch genau das machen wollen und daran Spaß haben.

Fazit: ich denke, das Ganze sollte wieder verschwinden.

Karl

Einige der ungetaggten Ways in Bad Naheim wurden bereits gestern von namo1 entfernt. Die dabei ofenbar versehentlich gelöschte Straße "An der Sodenschmiede" habe ich wiederhergestellt.

mink wrote:

Die gezeigte Stelle ist eher unproblematisch, und die erforderlichen Straßenübergänge sind eingezeichnet. Das ist aber eher die Ausnahme, siehe z.B. an dieser Kreuzung: http://www.openstreetmap.org/node/31506328. Da kann man die Straße eigentlich überall überqueren, und jede Einzeichnung eines Fußwegs zur Querung wäre willkürlich. Konsequenterweise hat man es auch (noch?) nicht gemacht.

Damit eine Straßenquerung erfasst wird, muss diese bestimmte Kriterien erfüllen, damit diese im Anschluss beauskunftet werden kann. Erfasst werden aus diesem Grund Straßenquerungen an Zebrastreifen und Lichtsignalanlagen. Zusätzlich werden unmarkierte Straßenquerungen erfasst, wenn am Bordsteinrand und am gegenüberliegendem Bordsteinrand eine Absenkung vorliegt, sodass Rollstuhlfahrer bzw. Rollatornutzer diese Querung „sicher“ passieren können. Wer einen Rollator verwendet kann jenen nicht unbedingt einen Bordstein hinaufheben.

mink wrote:

Woher will man die Mapper nehmen, die diese unzähligen Bürgersteige malen und taggen? Und dabei darauf achten, dass das ganze sowohl Fußgänger-, als auch Fahrradfahrer und Rollstuhlfahrer-kompatibel ist? Karl

Eine Beurteilung soll nicht durch den Mapper erfolgen. Die Grundidee ist, das Mapper die Gegebenheiten vor Ort erfassen und im Anschluss der Router die Gehwege unter Berücksichtigung von individuellen Einstellungen des Nutzers berechnet und ausgibt.

Ja gut, damit hast Du gutes Routing für Rollstuhlfahrer, aber schlechtes Routing für alle anderen (die in Realität
an jeder Stelle z.B. vom Bürgersteig links auf Bürgersteig rechts wechseln können).

chris66 wrote:

Ja gut, damit hast Du gutes Routing für Rollstuhlfahrer, aber schlechtes Routing für alle anderen (die in Realität
an jeder Stelle z.B. vom Bürgersteig links auf Bürgersteig rechts wechseln können).

An welcher Stelle sollte das routing schlecht sein? Es ist davon auszugehen das an jeder Kreuzung eine Querungsmöglichkeit besteht. Daraus folgt das es nachteile nur dann gibt wenn ich innheralb eines Straßenabschnittes die Straßenseite Wechseln müsste. Das passiert aber eigentlich auch nur wenn ich von einer linken Hausnummer zu einer rechten der selben Straße wechseln möchte. Das aber ist eigentlich kein gebräuchlicher Routing Auftrag.
Außerdem sollte es auch möglich für Stellen wo dies relevant wäre Straßenquerungen zu ermöglichen, ohne das diese für beeinträchtigte Menschen benutzt werden, weil eben die Bordsteinhöhe anders angegeben wird.

Vielleicht ist das Routing mit dem Straßenseiten Wechsel aber doch häufiger als gedacht. Nämlich dann wenn es um Wege von der Haltestelle zu einer bestimmten Hausnummer geht. Und wie ich an den Projektpartnern gesehen habe dürften einige dieses Ziel verfolgen. Also sollte dafür auch eine sinnvolle Lösung gefunden werden.

viw wrote:

An welcher Stelle sollte das routing schlecht sein? Es ist davon auszugehen das an jeder Kreuzung eine Querungsmöglichkeit besteht. Daraus folgt das es nachteile nur dann gibt wenn ich innheralb eines Straßenabschnittes die Straßenseite Wechseln müsste.

Spontan fallen mir Einmündungen ein, bei denen an der gegenüberliegenden Seite der Gehsteig nicht abgeflacht ist. Da kann man ohne separat gemappte Gehwege einfach abbiegen, der Router spaziert ja auf dem Mittelstreifen und kennt keine Randsteine. Bei separaten Gehwegen muss man bis zur nächsten Kreuzung gehen. Alternativ bis zur nächsten Stelle, wo auf beiden Seiten der Randstein abgeflacht ist (das heisst vermutlich auch, dass auf beiden Seiten ein Gehweg sein muss...).

Falls der Text zu unklar war, so ungefähr:

(links ohne Gehsteig, rechts mit. rot Straße, schwarz Fussweg, blaue Punkte das Routingergebnis)

Grüße, Max

Gegenbeispiel Wenn auch nicht besonders groß:
http://www.openstreetmap.org/#map=19/52.54895/13.50199
https://maps.google.de/?ll=52.548874,13 … 25,,0,9.47

viw wrote:

Gegenbeispiel Wenn auch nicht besonders groß

Schon klar. Das oben gemalte unglückliche Fussgängerrouting passiert auch ständig mit unseren jetzigen Daten (Beispiel, die Rümannstr ist überall ziemlich gefahrlos zu überqueren trotz der eingezeichneten Parkflächen), einfach weil man vergisst, die gegenüberliegenden Wege anzuschliessen. Nur war das eben bisher eine bedauerliche Fehlfunktion.

Ich meinte nicht unbedingt das man vergaß die Straße anzuschließen. Sondern ich meinte das Geländer welches das Überqueren der Straße verhindert.
Dort ist nämlich genau das vorgesehen was du vermeiden möchtest. Ohne getrennte Wege wäre das aber nicht abbildbar.

viw wrote:

Dort ist nämlich genau das vorgesehen was du vermeiden möchtest. Ohne getrennte Wege wäre das aber nicht abbildbar.

Ich wollte eher mein eigenes Argument abschwächen 😉 Das Problem ist, dass namo jetzt überall virtuelle Geländer aufstellen will, indem sie überall getrennte Wege eintragen. Das zwingt jeden Fussgängerrouter dazu, entweder "namo-Wege" zu erkennen und zu vermeiden, oder zu routen als hätte er einen Rollator.

Grüße, Max

Was mir schon beim ersten Versuch des Projekts nicht gefallen hat:
Durch die getrennten Gehwege aka "virtuelles Geländer" wird der Linienwirrwarr in den Innenstädten entlang Straßen verdreifacht.

Ein besserer Ansatz wäre mE ein geeignetes (von mir aus auch neues) Tag an der Straße (highway=*) zusätzlich zu sidewalk, also etwas wie
sidewalk:right:sloped_curb=*
Siehe auch http://wiki.openstreetmap.org/wiki/DE:W … ir_routing

Das hat zur Folge, dass Strassen häufiger abgeteilt werden müssen (an jeder Rollstuhlüberquerung), aber das scheint mir das bei weitem kleinere Übel.

Zur Vermeidung des Splittens von ways und des Einzeichnens separater Bürgersteige hätte ich folgende Idee:
An die Stelle der abgesenkten Bordsteinkante setzt man ein node mit
sidewalk=drop_kerb (beidseitige Absenkung)
Einseitige bekämen sidewalk:right=* bzw. *:left=*
Bei Fahrradwegen könnte man analog vorgehen.

seichter wrote:

Was mir schon beim ersten Versuch des Projekts nicht gefallen hat:
Durch die getrennten Gehwege aka "virtuelles Geländer" wird der Linienwirrwarr in den Innenstädten entlang Straßen verdreifacht.

Ein besserer Ansatz wäre mE ein geeignetes (von mir aus auch neues) Tag an der Straße (highway=*) zusätzlich zu sidewalk, also etwas wie
sidewalk:right:sloped_curb=*
Siehe auch http://wiki.openstreetmap.org/wiki/DE:W … ir_routing

Das hat zur Folge, dass Strassen häufiger abgeteilt werden müssen (an jeder Rollstuhlüberquerung), aber das scheint mir das bei weitem kleinere Übel.

Das scheint dir das kleinere Übel? Also mir scheint das eher ein sehr viel größeres Übel zu sein! Das Problem sind wahrscheinlich auch nicht die Wege zwischen zwei Kreuzungen. Hier könnte man das Queren ja mittels highway=crossing an einem Punkt jederzeit zulassen.
An einer Kreuzung kann ich aber mit der Punktmethode am Schnittpunkt nicht mehr eindeutig anzeigen über welche Straße man gegebenfalls kommen kann und über welche nicht.
Die Lösung dafür wäre vielleicht vier Punkte an den jeweiligen Schenkeln zu setzen. Was denkt ihr darüber?

viw wrote:

...
Die Lösung dafür wäre vielleicht vier Punkte an den jeweilige Schenkeln zu setzen. Was denkt ihr darüber?

So habe ich mir das unter #48 vorgestellt.
sidewalk=drop_kerb an highway=crossing wäre dort auch eine hilfreiche Zusatzinfo.

viw wrote:

Die Lösung dafür wäre vielleicht vier Punkte an den jeweiligen Schenkeln zu setzen. Was denkt ihr darüber?

Das (#48-50) erscheint mir besser als die Eigenschaft an ways (aus http://wiki.openstreetmap.org/wiki/DE:W … ir_routing).
Entspräche ja auch dem bisherigen Vorgehen bei normalen Fußgängerüberwegen.

maxbe wrote:

...
Ich wollte eher mein eigenes Argument abschwächen 😉 Das Problem ist, dass namo jetzt überall virtuelle Geländer aufstellen will, indem sie überall getrennte Wege eintragen. Das zwingt jeden Fussgängerrouter dazu, entweder "namo-Wege" zu erkennen und zu vermeiden, oder zu routen als hätte er einen Rollator.

Grüße, Max

Ich füge dein Bild noch einmal ein:

Kann nicht auch der "Fussgängerrouter " so eingestellt werden, dass er auch über den highway=Straße auf den folgenden Punkt wechselt? (Entsprechend deinem Bild "Routing" ohne Fußwege). Und wenn der Router den anderen (längeren Weg) vorschlägt, kann der "Fußgänger" ja immer noch entscheiden "über die Straße" zu gehen.

Für Routing mit Rollator oder Schulwege (Seniorenwege) ist ein entsprechendes Routing sicherer.

geri-oc wrote:

Kann nicht auch der "Fussgängerrouter " so eingestellt werden, dass er auch über den highway=Straße auf den folgenden Punkt wechselt?

Schwer zu machen.... Man könnte natürlich bei den Routern irgendwas in der Art "Du darfst auch mal 2m von Weg zu Weg springen" einführen. Allerdings geben unsere Daten wenig her, was die weissen Flecken zwischen den Wegen betrifft. Da kann alles mögliche liegen: Graben, Begrünung, ein noch nicht gemappter Zaun, ein Randstein...

Das einzuführen und zu taggen dürfte mühsamer sein als alle Vorschläge in diesem Faden. Möglich wäre das mit kleinen schmale Flächen mit passenden (access/smothness/highway/kerb/...) zwischen allen Wegen, oder Relationen zwischen Straßen und ihren Gehweg, die die Überquerbarkeit des Zwischenraumes beschreibt...

Das kann man sicher besser durch ein Tag an der Straße oder grosszügig gemalte Querverbindungen hinkriegen. Wobei letztere den Nachteil haben, dass der Mapper schon wissen müsste, wo der Benutzer des Routers über die Straße will. An Kreuzungen und Einmündungen will er sicher, zwischen den Kreuzungen aber sicher auch manchmal.

geri-oc wrote:

Und wenn der Router den anderen (längeren Weg) vorschlägt, kann der "Fußgänger" ja immer noch entscheiden "über die Straße" zu gehen.

Der Router wird den Fußgänger vielleicht an diese Stelle gar nicht führen, weil er auf 5km Strecke 30 solcher Situationen hat, wo er die Strecke um 50 Meter falsch einschätzt und er sich deshalb für eine ganz andere Route entscheidet.

geri-oc wrote:

Für Routing mit Rollator oder Schulwege (Seniorenwege) ist ein entsprechendes Routing sicherer.

Jo. wir brauchen eine Möglichkeit, auszuwählen, ob wir nur an besonderen Stellen oder überall über die Straße laufen wollen. Bei getrennt gemappten Wegen, die nur bei Bordsteinabsenkungen verbunden sind, haben wir die Auswahl nicht.

Nachtrag: Damit das ganze nicht so theoretisch klingt, noch ein Bildchen. Situation wie oben, eine Einmündung und gegenüber der Weg ohne Verbindung zur Straße. Der Router wird den für ihn kürzesten Weg (links) anbieten, weil ihm der Seniorenweg (mitte) länger vorkommt. Dass man auch einfach abkürzen kann (rechts), weiss der Router nicht und der Fußgänger wird es nie erfahren, weil er seinem Router folgt.

(Bitte nicht nachmessen, die Zahlen sollten stimmen, die Pixel nur so ungefähr)

Auf unserer wiki.osm-Seite http://wiki.openstreetmap.org/wiki/Namo haben wir unter Kapitel 3.3 Vorgefertigte Eingabemasken für JOSM unsere Eingabemasken veröffentlicht, die wir für die Einarbeitung der erhobenen Daten verwenden. Über ein Feedback würden wir uns freuen.

Viele Grüße,
namo1

Relation von Gehweg bzw. Straßenquerung zur Straße erzeugen

Für ein aussagekräftiges Fußwegerouting werden Informationen, die sich an den Straßen-Kanten (wie z.B. Straßenname, Straßentyp, Geschwindigkeitsbegrenzungen und weitere relevante Informationen) befinden, ebenfalls an den zugehörigen Gehweg-Kanten benötigt. Diese Verknüpfung von Straße mit Gehweg bzw. Straßenquerungen wollen wir über Relationen realisieren. Dabei orientieren wir uns an das Relationsschema associatedStreet (http://wiki.openstreetmap.org/wiki/Rela … atedStreet) und verwenden für die Umsetzung das Programm JOSM. Dementsprechend sieht unser tagging aus.

Folgende Rollen wollen wir verwenden:

„street“ – für Straße
„sidewalk“ – für Gehweg
„crossing“ – für Straßenquerungen

Die angefügten Bilder sollen dies exemplarisch verdeutlichen.

Wir wollen Euch um ein Feedback bezüglich der Vorgehensweise bitten. Besten Dank im Voraus.

Mit freundlichen Grüßen,
namo1

Etwas allgemeiner betrachtet geht es hier wohl um die Erfassung von "komplexen Straßen" und "komplexen Kreuzungen". Da gab es ja schon mal Anläufe, s. http://wiki.openstreetmap.org/wiki/Prop … s/Junction und http://wiki.openstreetmap.org/wiki/Rela … rriageways .

MMn sollte man es gleich allgemeiner angehen.

namo1 wrote:

Dabei orientieren wir uns an das Relationsschema associatedStreet (http://wiki.openstreetmap.org/wiki/Rela … atedStreet) und verwenden für die Umsetzung das Programm JOSM.

Würden das die bisherigen Auswerter von associatedStreet-Relationen verstehen?

Bisher war associatedStreet ausschliesslich dafür da, Hausnummern an Straßen zu binden. Falls ich den Quellcode von Nominatim richtig verstehe (in functions.sql einfach nach associated suchen) , wertet das z.B. auch nur die Rollen "street" und "alles andere" aus. Nach wiki gibt es auch nur zwei mögliche Rollen.

Vielleicht wäre da ein anderer Relationentyp besser, der noch nicht völlig anders definierte wurde...

Grüße, Max

Es gibt noch die street-Relation, welche auch andere Werte zulässt und demnach m.M.n der richtige
Relationstyp für den Zweck ist.

http://wiki.openstreetmap.org/wiki/Rela … sed/Street

Ansonsten der Hinweis, dass diese Klimmzüge nicht notwendig wären, wenn man Bürgersteige nicht separat, sondern
als Attribut der Straße mappt.

chris66 wrote:

Ansonsten der Hinweis, dass diese Klimmzüge nicht notwendig wären, wenn man Bürgersteige nicht separat, sondern
als Attribut der Straße mappt.

Ich halte das Erfassen von getrennten Gehwegen sogar als Bruch der bisher geübten Konvention, Wege (Linienzüge) nur dann getrennt zu erfassen, wenn sie baulich getrennt sind, ein Wechsel also nicht möglich ist.
Ein Beispiel dafür ist das Mappen von Fahrspuren. Da werden diese solange als Attribut einer einzigen Linie eingetragen, solange sie nicht baulich getrennt sind. Erst wenn z.B. die Autobahnausfahrt abbiegt, wird sie als getrennte Linie erfasst.

Mir fällt im Moment nichts ein, was dagegen sprechen würde, nicht getrennt verlaufende Gehwege mit allen Attributen (abgesenkt, rechts, links etc.) als Eigenschaft der Straße zu erfassen, so wie man es auch bei den Fahrspuren macht (machen sollte).
Der einzige Nachteil, den man sich dadurch einhandelt, ist, dass die Straßen dann häufiger aufgesplittet werden müssen, wenn sich die Eigenschaft des Gehwegs ändert. Damit hat man sich beim Spurtagging aber auch arrangiert.

seichter wrote:

Ich halte das Erfassen von getrennten Gehwegen sogar als Bruch der bisher geübten Konvention, Wege (Linienzüge) nur dann getrennt zu erfassen, wenn sie baulich getrennt sind, ein Wechsel also nicht möglich ist.
Ein Beispiel dafür ist das Mappen von Fahrspuren. Da werden diese solange als Attribut einer einzigen Linie eingetragen, solange sie nicht baulich getrennt sind. Erst wenn z.B. die Autobahnausfahrt abbiegt, wird sie als getrennte Linie erfasst.

Das sehe ich genauso, das Spurtagging ist ein gutes Vorbild. Und im Vergleich zu der Vorstellung, bei allen Straßen mit Gehwegen (also bei vollständiger Erfassung fast jeder Straße) mit Relationen arbeiten zu müssen, sind die häufigeren Wegteilungen ein eher kleines Ärgernis.

Naja, aus Sicht eines Autos besteht ja auch eine bauliche Trennung wenn der Bürgersteig nicht abgesenkt ist.
Aus meiner Sicht spricht einiges für, aber auch einiges gegen das getrennte Erfassen von straßenbegleitenden Wegen. Und mit der Tatsache, dass es sowieso praktiziert wird, muss sich dann sowieso jeder Router rumschlagen. Das kommt nunmal davon, dass wir in OSM so tolerant sind, für jedes Problem 10 Lösungen als akzeptabel anzusehen :-\

Nadjita wrote:

Und mit der Tatsache, dass es sowieso praktiziert wird, muss sich dann sowieso jeder Router rumschlagen.

Ich finde, wer so etwas grossflächig einführen will, sollte einen Vorschlag machen, wie sich ein Router für nicht-Rollatornutzer damit rumschlagen sollte. Leider hat Namo nicht auf die Beiträge #35 bis #53 reagiert, sondern lediglich um weiteres Feedback zu einem anderen Thema gebeten.

Für den eigenen Router hat Namo ja eine Lösung: Sie modellieren die Daten so dass es für sie passt, weil sie sich mit Routingproblemen bei Bürgersteigen nicht rumschlagen wollen, trotz sicher vorhandener Kompetenz, wenn ich mir die Beteiligten und das Budget so ansehe.

maxbe wrote:

Ich finde, wer so etwas grossflächig einführen will, sollte einen Vorschlag machen, wie sich ein Router für nicht-Rollatornutzer damit rumschlagen sollte

Auf die Gefahr hin, dass wir aneinander vorbei reden: das separate Mapping von Fuß- und Radwegen ist schon länger standardisiert. Die vorgeschlagenen Erweiterungen von Namo zu den Relationen haben ja nichts damit zu tun, dass bereits heute schon Bürgersteige separat gemapped werden und sich Router damit arrangieren müssen. Ob das wirklich nötig ist, bezweifle ich, aber ich habe auch bisher keinen Router für OSM programmiert. Ich halte es allerdings für falsch sich das Programmieren eines Routers durch Einführen von Relationen zu erleichtern.

Besten Dank für die Anregungen und Hinweise. Nachdem wir uns mit unseren Projektpartnern abgestimmt haben (das dauert natürlich immer ein paar Tage … deshalb sind wir leider etwas langsam für das Forum), möchten wir gerne auf einige Punkte antworten.

maxbe #46
Das zwingt jeden Fussgängerrouter dazu, entweder "namo-Wege" zu erkennen und zu vermeiden, oder zu routen als hätte er einen Rollator.

Es gibt unseres Wissens nach keine richtigen „Fußgänger-Router“ basierend auf OSM, welche nur Fußwege verwenden. Grundsätzlich werden Fußgänger über Straßen ohne jegliche Restriktion (bis auf Autobahn) geroutet, ohne zu wissen, ob es einen Fußweg gibt.

viw #49
Hier könnte man das Queren ja mittels highway=crossing an einem Punkt jederzeit zulassen.
An einer Kreuzung kann ich aber mit der Punktmethode am Schnittpunkt nicht mehr eindeutig anzeigen über welche Straße man gegebenfalls kommen kann und über welche nicht.

Informationen an Punkten sind schlecht nutzbar, da Informationen in der Datenaufbereitung an die Kante müssen. Allerdings ist dann unklar, welche Kante die Eigenschaft bekommen soll. Es können auch virtuelle Kanten mit der Länge 0m hinzugefügt werden. Dann kann man aber keinen Faktor mehr drauf rechnen, wenn die Kreuzung laut Anforderung des Nutzers möglichst vermieden werden soll.

geri-oc #59
Kann nicht auch der "Fussgängerrouter " so eingestellt werden, dass er auch über den highway=Straße auf den folgenden Punkt wechselt? (Entsprechend deinem Bild "Routing" ohne Fußwege). Und wenn der Router den anderen (längeren Weg) vorschlägt, kann der "Fußgänger" ja immer noch entscheiden "über die Straße" zu gehen.

Nein, kann unser "Fußgängerrouter" leider nicht.

Aber grundsätzlich ist in solchen Situationen immer eine Art Überquerung durch das Straßenbauamt vorgesehen. Daher können dann auch Überquerungen in den Daten modelliert werden. Das einzige Problem ist wirklich nur, wenn man auf einer Seite der Straße startet (egal ob von einer Haustür oder einer Haltestelle) und einfach nur auf die andere Seite muss.

seichter #59
Mir fällt im Moment nichts ein, was dagegen sprechen würde, nicht getrennt verlaufende Gehwege mit allen Attributen (abgesenkt, rechts, links etc.) als Eigenschaft der Straße zu erfassen, so wie man es auch bei den Fahrspuren macht (machen sollte).

Wir haben diese Variante geprüft und uns dagegen entschieden, da wir dabei keine Straßenquerungen modellieren können.

maxbe #62
Ich finde, wer so etwas grossflächig einführen will, sollte einen Vorschlag machen, wie sich ein Router für nicht-Rollatornutzer damit rumschlagen sollte.

Die Lösung, Fußwege so zu modellieren wie wir, ist generisch und kann von jedem Router (bei entsprechender Datenaufbereitung) interpretiert werden. Derzeit bestehende Router arbeiten auf Straßen und sind somit nicht betroffen. Fußwege gibt es in OSM bisher kaum, daher ist dieses Routing-Problem zurzeit nicht lösbar. Allerdings wäre es aus unserer Sicht doch wirklich hilfreich eine Beschreibung zu erstellen, wie auf diesen Daten gut geroutet werden kann. Das kann man am Projektende machen, wenn gezeigt wurde, dass der Prototyp auch funktioniert.

Mit freundlichen Grüßen,
namo1

Hallo,

namo1 wrote:

Besten Dank für die Anregungen und Hinweise. Nachdem wir uns mit unseren Projektpartnern abgestimmt haben (das dauert natürlich immer ein paar Tage … deshalb sind wir leider etwas langsam für das Forum), möchten wir gerne auf einige Punkte antworten.

Ich muss mich schon ein bisschen zusammenreißen, damit ich Verständnis aufbringen kann. OSM ist ein Community-Projekt, wir antworten nunmal etwas schneller …

namo1 wrote:

maxbe #46
Das zwingt jeden Fussgängerrouter dazu, entweder "namo-Wege" zu erkennen und zu vermeiden, oder zu routen als hätte er einen Rollator.

Es gibt unseres Wissens nach keine richtigen „Fußgänger-Router“ basierend auf OSM, welche nur Fußwege verwenden. Grundsätzlich werden Fußgänger über Straßen ohne jegliche Restriktion (bis auf Autobahn) geroutet, ohne zu wissen, ob es einen Fußweg gibt.

Ja, weil Fußwege noch nicht so stark im Fokus der Mapper angekommen sind. sidewalk=* gibt es, aber momentan sind die meisten auf Adressen, POIs und Radwege fixiert. Das sidewalk-Tag hat halt noch ein Henne-Ei-Problem.

namo1 wrote:

viw #49
Hier könnte man das Queren ja mittels highway=crossing an einem Punkt jederzeit zulassen.
An einer Kreuzung kann ich aber mit der Punktmethode am Schnittpunkt nicht mehr eindeutig anzeigen über welche Straße man gegebenfalls kommen kann und über welche nicht.

Informationen an Punkten sind schlecht nutzbar, da Informationen in der Datenaufbereitung an die Kante müssen. Allerdings ist dann unklar, welche Kante die Eigenschaft bekommen soll. Es können auch virtuelle Kanten mit der Länge 0m hinzugefügt werden. Dann kann man aber keinen Faktor mehr drauf rechnen, wenn die Kreuzung laut Anforderung des Nutzers möglichst vermieden werden soll.

geri-oc #59
Kann nicht auch der "Fussgängerrouter " so eingestellt werden, dass er auch über den highway=Straße auf den folgenden Punkt wechselt? (Entsprechend deinem Bild "Routing" ohne Fußwege). Und wenn der Router den anderen (längeren Weg) vorschlägt, kann der "Fußgänger" ja immer noch entscheiden "über die Straße" zu gehen.

Nein, kann unser "Fußgängerrouter" leider nicht.

Aber grundsätzlich ist in solchen Situationen immer eine Art Überquerung durch das Straßenbauamt vorgesehen. Daher können dann auch Überquerungen in den Daten modelliert werden. Das einzige Problem ist wirklich nur, wenn man auf einer Seite der Straße startet (egal ob von einer Haustür oder einer Haltestelle) und einfach nur auf die andere Seite muss.

seichter #59
Mir fällt im Moment nichts ein, was dagegen sprechen würde, nicht getrennt verlaufende Gehwege mit allen Attributen (abgesenkt, rechts, links etc.) als Eigenschaft der Straße zu erfassen, so wie man es auch bei den Fahrspuren macht (machen sollte).

Wir haben diese Variante geprüft und uns dagegen entschieden, da wir dabei keine Straßenquerungen modellieren können.

maxbe #62
Ich finde, wer so etwas grossflächig einführen will, sollte einen Vorschlag machen, wie sich ein Router für nicht-Rollatornutzer damit rumschlagen sollte.

Die Lösung, Fußwege so zu modellieren wie wir, ist generisch und kann von jedem Router (bei entsprechender Datenaufbereitung) interpretiert werden. Derzeit bestehende Router arbeiten auf Straßen und sind somit nicht betroffen.

Doch, bestehende Router sind von eurem Mapping betroffen. Wenn ich von meinem Haus zum Haus meines Nachbar gegenüber route und ihr auf beiden Straßenseiten die Bürgersteige als eigene Ways eingetragen habt, dann schickt mich mein Router bis zur nächsten Kreuzung! Dabei kann ich (als nicht mobilitätseingeschränkter Fußgänger) problemlos den Bordstein überqueren. Bitte berücksichtigt, dass es auch Leute gibt, die keinen Rollator brauchen.

Euer Datenmodell ist nicht kompatibel mit dem bestehenden und den Datennutzern. Mapping-/Tagginschemata, die bestehende Konventionen über den Haufen werfen, setzen sich in der OSM-Community erfahrungsgemäß nur sehr langsam (public_transport-Schema) oder gar nicht (bread_bakery) durch.

Bitte passt euch den Gepflogenheiten in OSM an und versucht nicht, uns euer Mappingschema aufzudrücken. Wenn ihr meint, dass es besser ginge, dann geht bitte den Weg eines Proposals, diskutiert das mit der Community und stellt nicht einfach eure Schemata auf eine Wiki-Seite.

Wenn ihr euer Schema nicht ändern und auf die Community zugehen wollt, dann wäre für euch das beste, die OSM-DB auf einem privaten Server zu installieren und OSM zu forken. Die OSM-DB samt Zubehör ist freie Software. Das Projekt Moabi hat das schon gemacht und dazu auf der SotM-US einen Vortrag gehalten. In eurem Privat-OSM könnt ihr dann mappen, wie ihr wollt.

namo1 wrote:

Fußwege gibt es in OSM bisher kaum, daher ist dieses Routing-Problem zurzeit nicht lösbar.

Wer sagt denn das? Die Propaganda von TomTom, die ihre teuren, aber in Deutschland nicht mehr konkurrenzfähigen Daten verkaufen will? Nennt mir mal bitte einen Anbieter, der mehr Fußwege in Deutschland hat und kein Amt ist! OSM hat in Deutschland ca. 80.000 km Fußwege.

Ich und vermutlich auch manch anderer hier haben immer noch den Eindruck, dass ihr nicht verstanden habt, wie OSM bzw. die Community funktioniert. Ihr könnt uns nicht einfach euer Mappingschema aufdrücken, welches vorschreibt, dass baulich nicht getrennte Fußwege als separate Ways gemappt werden. Bitte respektiert das. Passt eure Software daran an. Ihr müsst dann halt in der Vorverarbeitung bei jedem Straßen-Way, der ein sidewalk=yes hat, diesen um ein paar Meter zur Seite versetzen und anschließend an Kreuzungen die Ways, die "übestehen" kappen (falls ihr AutoCAD kennt, dort nennt man diese Funktion "versetzen"). Wenn ihr nicht die Kenntnisse/Fähigkeiten/Zeit habt, euch selbst OSM aufzusetzen, dann gibt es bestimmt Anbieter, die das gegen Bezahlung für euch tun.

Wisst ihr eigentlich, dass eure Aktivitäten und euer Umgang mit Community sowie das Auftreten von drei weiteren Firmen/Projekten dazu geführt hat, dass es wohl über kurz oder lang eine Organizational Mapping Policy, also ein Verhaltenskodex für weisungsgebundene und bezahlte Mapper gibt? Auf der OSMF-talk-Mailingliste wurdet ihr schon letzten Herbst erwähnt, das Thema (die Policy) wird nun auf der internationalen talk-Mailingliste diskutiert.

Viele Grüße

Michael

Hallo namo,

namo1 wrote:

maxbe #46
Das zwingt jeden Fussgängerrouter dazu, entweder "namo-Wege" zu erkennen und zu vermeiden, oder zu routen als hätte er einen Rollator.

Es gibt unseres Wissens nach keine richtigen „Fußgänger-Router“ basierend auf OSM, welche nur Fußwege verwenden.

Ja, vermutlich routet keiner nur auf Fußwegen. Das Problem ist, dass es einige Fußgänger-Router gibt, die auf Fußwegen und Straßen routen. Was generell auch gut ist, sonst kämen meine rollatorschiebende Nachbarin und ich nicht aus unserem Haus an der gehsteiglosen Straße.
Solche Router freuen sich auch über Eure Fußwege und werden die vermutlich sogar bevorzugt zur Routen verwenden. Nur kommen die dann nicht mehr an jeder Stelle vom Fußweg runter, sondern nur an Kreuzungen oder anderen von Euch bevorzugten Punkten.

namo1 wrote:

Grundsätzlich werden Fußgänger über Straßen ohne jegliche Restriktion (bis auf Autobahn) geroutet, ohne zu wissen, ob es einen Fußweg gibt

Naja, ich denke, die meisten davon kennen schon noch Abstufungen zwischen "Du darfst da nicht laufen" und "Super Weg, den nehme ich"... Sie können auch in Erfahrung bringen, ob da ein Fußweg ist, indem sie "sidewalk=*" auswerten. Ich kenne einen Router, der diese Wege bevorzugt, aber andere Leute kamen sicher auch schon auf diese nicht ganz abseitige Idee.

Was sie dann natürlich nicht können, ist die Antwort auf "Kann ich hier über die Straße" zu geben. Bei Straßen mit "sidewalk=*" ist die Antwort immer "ja" (1), bei Euch wird sie "Nein" sein.

namo1 wrote:

Die Lösung, Fußwege so zu modellieren wie wir, ist generisch und kann von jedem Router (bei entsprechender Datenaufbereitung) interpretiert werden. Derzeit bestehende Router arbeiten auf Straßen und sind somit nicht betroffen. Fußwege gibt es in OSM bisher kaum, daher ist dieses Routing-Problem zurzeit nicht lösbar. Allerdings wäre es aus unserer Sicht doch wirklich hilfreich eine Beschreibung zu erstellen, wie auf diesen Daten gut geroutet werden kann. Das kann man am Projektende machen, wenn gezeigt wurde, dass der Prototyp auch funktioniert.

Derzeitige Router für Fußgänger arbeiten auf Straßen und Fußwegen, sind also schon betroffen. Sie können Fußwege natürlich auch verarbeiten, nur finden sie halt nicht an jeder Stelle über die Straße, wo ihr Benutzer das könnte. Stattdessen routen sie bis zur nächsten Kreuzung, wo Fußweg und Straße verbunden sind. In manchen Fällen mag das richtig sein (in #43 ist ein Beispiel), in den meisten Fällen eben nicht. Ich glaube es nicht, aber ich würde mich freuen, wenn Ihr eine Lösung dafür findet 😉

Grüße, Max

Edit: (1) Eigentlich müsste die Antwort bei sidewalk=left|right|both nicht immer "ja" sein. Aus dem könnte man ja ableiten, wo der Gehweg ist und dann das überqueren nur an bestimmten Punkten erlauben (Ne Idee dazu in #48). Allerdings wüsste ich keinen Router, der das auswertet. Das hielte ich für einen viel schöneren Ansatz für Eure Forschung...

namo1 wrote:

viw #49
Hier könnte man das Queren ja mittels highway=crossing an einem Punkt jederzeit zulassen.
An einer Kreuzung kann ich aber mit der Punktmethode am Schnittpunkt nicht mehr eindeutig anzeigen über welche Straße man gegebenfalls kommen kann und über welche nicht.

Informationen an Punkten sind schlecht nutzbar, da Informationen in der Datenaufbereitung an die Kante müssen. Allerdings ist dann unklar, welche Kante die Eigenschaft bekommen soll. Es können auch virtuelle Kanten mit der Länge 0m hinzugefügt werden. Dann kann man aber keinen Faktor mehr drauf rechnen, wenn die Kreuzung laut Anforderung des Nutzers möglichst vermieden werden soll.

Mit verlaub, aber diese Antwort ist nicht stichhaltig!
Wenn man Dinge an Kanten braucht, dann erzeugt euch doch Kanten aus highway mit sidewalk=yes die können sogar links und rechts neben der Straße liegen.
Ein vermeiden der Kreuzung geht dann nicht mit einem Faktor. Aber sehrwohl mit einem absolutwert. Nehmen wir an die Straße ist in der Regel 6m mit Parkstreifen 10m breit und schon hat man Ansätze welche Standardwerte für die Vermeidung erforderlich sind. Möchte man das genauer machen, kann man sicher auch die selten gefüllten Straßenbreiten auslesen. Zusätzlich könnte man das auch an den Crossings angeben, wenn das gebraucht wird.

Nakaner wrote:

Wenn ich von meinem Haus zum Haus meines Nachbar gegenüber route und ihr auf beiden Straßenseiten die Bürgersteige als eigene Ways eingetragen habt, dann schickt mich mein Router bis zur nächsten Kreuzung!

Wir sind uns dieser Problematik bewusst, dass unser Router nur an vordefinierten Übergängen die Straßenseite wechseln kann. Jedoch ist das beschriebene Beispiel nicht unser wahrscheinlichster Anwendungsfall. Wer lässt sich von seinem Haus zum gegenüberliegenden Haus routen? Und falls wir dennoch von diesem Beispiel ausgehen und dann annehmen, dass diese Straße eine Hauptverkehrsstraße in einer Großstadt ist, bevorzugt sicher auch die nichtmobilitätseingeschränkte Person die Ampelquerung.

Wir möchten Querungen berücksichtigen. Auch nicht mobilitätseingeschränkte Fußgänger sollten laut StVO Ampelquerungen und Zebrastreifen verwenden, wenn diese vorhanden sind. Außerdem werden im Straßenraum dort abgesenkte Bordsteine, Ampeln und Zebrastreifen angelegt, wo eine Querung für alle sinnvoll erscheint.

Das Problem ist, dass die Erzeugung von zusätzlichen Kanten wie im Forum vorgeschlagen in der Realität Probleme birgt. Hier ist vor allem die Informationsweitergabe zu den Kreuzungen, die an den Punkten vorliegt schwierig. Außerdem hängt an diesem Punkt EINE Information. Welche der vielleicht 4 Querung einer Kreuzung dies betrifft lässt sich nicht ablesen. Richtungsangaben lassen sich auch nicht sinnvoll an den Punkt schreiben, da dies darauf ankommt von wo nach wo man laufen möchte. Außerdem lassen sich die Kreuzungen nicht in allen Fällen allein rechnerbasiert erzeugen. Und wir können nicht wirklich bei jedem Datenimport aus OSM jede Kreuzung in Deutschland in einem Zeichenprogramm nachziehen. Wir freuen uns über Lösungsansätze und prüfen jene auch.

Mit freundlichen Grüßen,
namo1

Tordanik wrote:

Das sehe ich genauso, das Spurtagging ist ein gutes Vorbild. Und im Vergleich zu der Vorstellung, bei allen Straßen mit Gehwegen (also bei vollständiger Erfassung fast jeder Straße) mit Relationen arbeiten zu müssen, sind die häufigeren Wegteilungen ein eher kleines Ärgernis.

Die Relationen sind keine Pflicht, aber für den Prototyp wichtig. Wenn es diese Relation nicht gibt, gibt es keine Informationen über die angrenzende Straße.

Relationen stören keine bestehenden Systeme, solange sie korrekt verwendet werden.

chris66 #58
Es gibt noch die street-Relation, welche auch andere Werte zulässt und demnach m.M.n der richtige Relationstyp für den Zweck ist
.
http://wiki.openstreetmap.org/wiki/Rela … sed/Street”

Besten Dank für den Hinweis! Diese Möglichkeit der Relationsbildung (http://wiki.openstreetmap.org/wiki/Relation:street) haben wir intern geprüft und sind zu der Entscheidung gekommen, dass wir dieses Relationsschema nun anwenden werden, wenn es hierzu keine Einwände gibt. Anbei ein Bild zur Verdeutlichung.

Als Rolle werden wir weiterhin sidewalk für die Gehwege verwenden, da dies auch bereits auf folgender OSM-Wiki Seite vorgeschlagen wurde (http://wiki.openstreetmap.org/wiki/Prop … parate_way).

Zitat daraus unter Relation : "There are proposals suitable for linking the sidewalks and the main road with a relation. associatedStreet, or the proposed street relations are possible candidates. The sidewalks could be added with role sidewalk."

Bei Fragen stehen wir zur Verfügung.

Mit freundlichen Grüßen,
namo1

Hi namo,

Ihr habt im Sommer euren mehrmonatigen Feldtest. Könnt Ihr, wenn ihr so weit seid, mal eine Gegend nennen, wo ihr glaubt, das Mapping sei halbwegs perfekt für eure Bedürfnisse?

Ich fürchte, das Problem beschränkt sich nicht auf Nakaners Besuch bei seinem Nachbar gegenüber. Er könnte z.B. auch nur schwer die Kirche besuchen. Das könnten natürlich alles noch Dinge auf Eurer todo-Liste für den Sommer sein, deshlb wäre es gut, wenn man ein Demo-Gebiet hätte, um einen anderen Router mal drauf los zu lassen...

namo1 wrote:

Das Problem ist, dass die Erzeugung von zusätzlichen Kanten wie im Forum vorgeschlagen in der Realität Probleme birgt. Hier ist vor allem die Informationsweitergabe zu den Kreuzungen, die an den Punkten vorliegt schwierig. Außerdem hängt an diesem Punkt EINE Information. Welche der vielleicht 4 Querung einer Kreuzung dies betrifft lässt sich nicht ablesen. Richtungsangaben lassen sich auch nicht sinnvoll an den Punkt schreiben, da dies darauf ankommt von wo nach wo man laufen möchte. Außerdem lassen sich die Kreuzungen nicht in allen Fällen allein rechnerbasiert erzeugen. Und wir können nicht wirklich bei jedem Datenimport aus OSM jede Kreuzung in Deutschland in einem Zeichenprogramm nachziehen. Wir freuen uns über Lösungsansätze und prüfen jene auch.

Na dann auf gehts:

Schwarz ist eine normale Straßenkreuzung in OSM wie sie heute bereits existieren.
Ergänzt um Punkte an denen eine Querung der Straße möglich ist. (man läuft ja nicht diagonal über die Kreuzung)

Daraus könnt ihr über die Sidewalkeigenschaften die Kanten entlang der Straße berechnen und die Verbindungen über die Straße ergeben sich aus den Informationen an den Punkten welche auch heute schon für Zebrastreifen und Verkehrsinseln gebräuchlich sind.

Wenn ich das richtig verstanden habe, müsste man, wenn Bürgersteig und Straße in eine Relation sollen, eine gerade Straße an jeder Kreuzung zerstückeln, weil ja dann ein anderer Bürgersteig "zuständig" ist. Vermeiden lassen würde sich das nur, wenn man versucht, die Straßen immer um die Ecken gehen zu lassen. Habe ich das richtig verstanden?

Nadjita wrote:

Wenn ich das richtig verstanden habe, müsste man, wenn Bürgersteig und Straße in eine Relation sollen, eine gerade Straße an jeder Kreuzung zerstückeln, weil ja dann ein anderer Bürgersteig "zuständig" ist.

So sehe ich das auch.
Die Vorgehensweise von "namo" ist halt noch viel aufwendiger: Da gehen von dieser Kreuzung acht Bürgersteige als getrennte ways ab.

Nadjita wrote:

Wenn ich das richtig verstanden habe, müsste man, wenn Bürgersteig und Straße in eine Relation sollen, eine gerade Straße an jeder Kreuzung zerstückeln, weil ja dann ein anderer Bürgersteig "zuständig" ist.

Ich stelle mir die Zuständigkeit anders vor: 1 lange Straße hat N Stücke Gehweg.

maxbe wrote:

Ich stelle mir die Zuständigkeit anders vor: 1 lange Straße hat N Stücke Gehweg.

Na dann musst Du eben die Gehwege an jeder Kreuzung teilen. Letztendlich hast du einen Haufen Segmente. Und woher weiss der Router nun welcher Buergersteig zu welchem Teil der Strasse gehoert?

Nadjita wrote:

Na dann musst Du eben die Gehwege an jeder Kreuzung teilen. Letztendlich hast du einen Haufen Segmente.

Ja, das ist das doofe an diesem Projekt

Nadjita wrote:

Und woher weiss der Router nun welcher Buergersteig zu welchem Teil der Strasse gehoert?

Sie wollen den Gehweg den "Straßenname, Straßentyp, Geschwindigkeitsbegrenzungen und weitere relevante Informationen" zuordnen. Das geht auch, wenn man die räumliche Beziehung zur Straße völlig ausser acht lässt und nur eine Verknüpfung Weg zu Straße erzeugt.

So wie ich das sehe, ist das ganze Projekt sogar darauf angelegt, die räumliche Beziehung zur Straße vernachlässigen zu können: Namo will nur auf Fußwegen routen, also bauen sie sich eine Welt aus Fußwegen. Wenn man doch mal was aus dem Rest der Daten benötigt, ein Straßenname z.B. oder deren Straßentyp, muss man sich das irgendwie über eine Relation besorgen können. Der Router muss gar nichts über die Straße wissen, er kennt sie nicht mal. Bestenfalls hat er ein Stück "ungünstigen Weg" in seinem Wegenetz, was in der echten Welt ein Zebrastreifen oder eine Ampel ist.

Danke für die Erklärung. Mein Versuch, das Ganze zu verstehen, war vielleicht doch zu wenig fußgängerzentrisch. Nun leuchtet es ein.

Nadjita #72
Wenn ich das richtig verstanden habe, müsste man, wenn Bürgersteig und Straße in eine Relation sollen, eine gerade Straße an jeder Kreuzung zerstückeln, weil ja dann ein anderer Bürgersteig "zuständig" ist.

Nein. Eine Straße muss nur geteilt werden, wenn sich die Attributeigenschaften nach der Kreuzung ändern. Dies wird allerdings von der Community bereits heute schon so gehandhabt. Nehmen wir z.B. an, dass eine Straße über die gesamte Länge dieselben Attribute verfügt (z.B. Tempolimit 30), so ist ein Aufsplitten nicht notwendig. Ändert sich hingegen das Geschwindigkeitslimit nach einer Kreuzung, dann wäre diese Straße sowieso bereits in zwei Kanten aufgeteilt.

Wenn wir die Daten, die wir erhoben haben, den bereits bestehenden Kanten hinzufügen, dann müssten wir diese Kanten bei jeder Änderung (z.B. Oberflächenstruktur oder Neigung/ Steigung) teilen. Erschwerend kommt noch hinzu, dass die Gegebenheiten des linken und rechten Bürgersteigs unterschiedlich sein können.

maxbe #70
Er könnte z.B. auch nur schwer die Kirche besuchen.

Das ist richtig. Vielen Dank für diesen Hinweis. Da müssen wir noch Querungen einarbeiten.

Bezüglich der Straßenquerungsmöglichkeiten werden wir unsere Untersuchungsgebiete nochmals überarbeiten.

maxbe #76
Sie wollen den Gehweg den "Straßenname, Straßentyp, Geschwindigkeitsbegrenzungen und weitere relevante Informationen" zuordnen.

Richtig. Mit Hilfe der Relationsbildung vermeiden wir u.a. auch eine „unschöne“ Darstellung in gerenderten Karten. So würden z.B. die Straßennamen dargestellt, wenn wir diese an die Gehwegkante anfügen. In diesem Fall käme es zu einer Doppelung, da Straßennamen bereits über gerenderte Straßen abgebildet werden.
Ein weiterer Vorteil der Relationsbildung ist die Datenpflege. Ändern sich Attribute an der Straße, dann müssen diese für die Gehwege nicht gesondert nachgezogen werden.

Sollte es zu einer Teilung einer Straße kommen, dann betrifft dies keine bestehende Relationen, da diese dadurch nicht „zerstört“ werden.

Mit freundlichen Grüßen,
namo1

maxbe wrote:

deshlb wäre es gut, wenn man ein Demo-Gebiet hätte, um einen anderen Router mal drauf los zu lassen...

Wir testen unser Untersuchungsgebiet Bornheim in Frankfurt am Main mit mapquest (http://open.mapquest.co.uk/).

Beste Grüße,
namo1

Hallo,

namo1 wrote:

Nakaner wrote:

Wenn ich von meinem Haus zum Haus meines Nachbar gegenüber route und ihr auf beiden Straßenseiten die Bürgersteige als eigene Ways eingetragen habt, dann schickt mich mein Router bis zur nächsten Kreuzung!

Wir sind uns dieser Problematik bewusst, dass unser Router nur an vordefinierten Übergängen die Straßenseite wechseln kann. Jedoch ist das beschriebene Beispiel nicht unser wahrscheinlichster Anwendungsfall. Wer lässt sich von seinem Haus zum gegenüberliegenden Haus routen?

Wenn man eine Travelling Salesman-Aufgabe für Fußgänger hat, dann lässt man sich von Haus zu Haus routen. Dann kann es das Ergebnis erheblich beeinflussen.

namo1 wrote:

Das Problem ist, dass die Erzeugung von zusätzlichen Kanten wie im Forum vorgeschlagen in der Realität Probleme birgt. Hier ist vor allem die Informationsweitergabe zu den Kreuzungen, die an den Punkten vorliegt schwierig. Außerdem hängt an diesem Punkt EINE Information. Welche der vielleicht 4 Querung einer Kreuzung dies betrifft lässt sich nicht ablesen. Richtungsangaben lassen sich auch nicht sinnvoll an den Punkt schreiben, da dies darauf ankommt von wo nach wo man laufen möchte.

Da haben sich die anderen Forumsmitglieder vielleicht nicht gut genug ausgedrückt. Aber man kann den Node auf der Straße, der Informationen zur Bordsteinhöhe, Existenz eines Zebrastreifens usw. enthält nicht nur auf die Straßenkreuzung setzen, sondern auch fünf bis zehn Meter zurückgesetzt in die Zubringerstraßen (dort wo vielleicht eine Vekehrsinsel stehen könnte).

namo1 wrote:

Nadjita #72
Wenn ich das richtig verstanden habe, müsste man, wenn Bürgersteig und Straße in eine Relation sollen, eine gerade Straße an jeder Kreuzung zerstückeln, weil ja dann ein anderer Bürgersteig "zuständig" ist.

Nein. Eine Straße muss nur geteilt werden, wenn sich die Attributeigenschaften nach der Kreuzung ändern. Dies wird allerdings von der Community bereits heute schon so gehandhabt. Nehmen wir z.B. an, dass eine Straße über die gesamte Länge dieselben Attribute verfügt (z.B. Tempolimit 30), so ist ein Aufsplitten nicht notwendig. Ändert sich hingegen das Geschwindigkeitslimit nach einer Kreuzung, dann wäre diese Straße sowieso bereits in zwei Kanten aufgeteilt.

Wenn wir die Daten, die wir erhoben haben, den bereits bestehenden Kanten hinzufügen, dann müssten wir diese Kanten bei jeder Änderung (z.B. Oberflächenstruktur oder Neigung/ Steigung) teilen. Erschwerend kommt noch hinzu, dass die Gegebenheiten des linken und rechten Bürgersteigs unterschiedlich sein können.

Dafür gibt es dann surface:sidwalk:right=paving_stones und surface:sidewalk:left=asphalt, genauso mit allen anderen Straßeneigenschaftstags (lit:sidewalk:right=yes, lit:sidewalk:left=no usw.). Left und right beziehen sich auf die Richtung des OSM-Ways.

Viele Grüße

Michael

Nakaner wrote:

Dafür gibt es dann surface:sidwalk:right=paving_stones und surface:sidewalk:left=asphalt, genauso mit allen anderen Straßeneigenschaftstags (lit:sidewalk:right=yes, lit:sidewalk:left=no usw.). Left und right beziehen sich auf die Richtung des OSM-Ways.

Richtig. Allerdings wollte ich damit nur zum Ausdruck bringen, dass wir mit dieser Methode jede Menge Segmente erzeugen würden. Dies würde noch häufiger vorkommen, wenn auf den gegenüberliegenden Gehwegseiten unterschiedliche Gegebenheiten vorliegen. Mal abgesehen davon, ist das Problem mit der automatischen Kantenerzeugung noch nicht gelöst.

Ein weiteres Problem welches wir bei der Verwendung von left/right bedacht haben ist folgendes. Ändert ein Nutzer die Richtung der Kante und pflegt die left/right-Beziehung nicht nach, obwohl bei JOSM eine Warnmeldung erscheint, ist die ausgegebene Information falsch.

Viele Grüße,
namo1

namo1 wrote:

Nakaner wrote:

Dafür gibt es dann surface:sidwalk:right=paving_stones und surface:sidewalk:left=asphalt, genauso mit allen anderen Straßeneigenschaftstags (lit:sidewalk:right=yes, lit:sidewalk:left=no usw.). Left und right beziehen sich auf die Richtung des OSM-Ways.

Richtig. Allerdings wollte ich damit nur zum Ausdruck bringen, dass wir mit dieser Methode jede Menge Segmente erzeugen würden. Dies würde noch häufiger vorkommen, wenn auf den gegenüberliegenden Gehwegseiten unterschiedliche Gegebenheiten vorliegen. Mal abgesehen davon, ist das Problem mit der automatischen Kantenerzeugung noch nicht gelöst.

Ein weiteres Problem welches wir bei der Verwendung von left/right bedacht haben ist folgendes. Ändert ein Nutzer die Richtung der Kante und pflegt die left/right-Beziehung nicht nach, obwohl bei JOSM eine Warnmeldung erscheint, ist die ausgegebene Information falsch.

+1
Das ist auch das hauptproblem früherer Wheelchairroutingansätze gewesen. Hier sollten sogar noch die ansteigende und abfallende Bordsteinkannte erfasst werden, was für eine einfach Auffahrt 3 Segmente bedeutet hätte.

Ich hatte an anderer Stelle einmal vorgeschlagen Eigenschaften nicht an Wegen sondern an Relationen aus Nodes zu erfassen. Denn etwas anderes sind Wege auch nicht. Und dann ist es nur eine Frage dessen was der Editor abbilden will.

Viw #41
Es ist davon auszugehen das an jeder Kreuzung eine Querungsmöglichkeit besteht. Daraus folgt das es nachteile nur dann gibt wenn ich innheralb eines Straßenabschnittes die Straßenseite Wechseln müsste. Das passiert aber eigentlich auch nur wenn ich von einer linken Hausnummer zu einer rechten der selben Straße wechseln möchte. Das aber ist eigentlich kein gebräuchlicher Routing Auftrag.

Maxbe #70
Ich fürchte, das Problem beschränkt sich nicht auf Nakaners Besuch bei seinem Nachbar gegenüber. Er könnte z.B. auch nur schwer die Kirche besuchen.

Wie bereits im Post #78 angekündigt haben wir unsere Straßenquerungsmöglichkeiten im Untersuchungsgebiet Bornheim in Frankfurt am Main überarbeitet.

Es sind jetzt an fast jeder Kreuzung Querungsmöglichkeiten vorhanden, sodass bessere Routingergebnisse für nicht mobilitätseingeschränkte Personen ausgegeben werden können, um dadurch für diese vermeidbare Umwege zu verhindern.

Wir werden diesen Datensatz im Laufe des Tages hochladen.

Mit freundlichen Grüßen,
namo1

UPDATE: Der aktuelle Datensatz ist nun hochgeladen.

http://alba-publikation.de/alba/nahverk … r=nv201405

Nadine George, M. A. / Dipl.-Geogr. Michael Neuhauser / Dipl.-Geogr. Marco Gennaro / Dipl.-Inform. Joachim Kast

Open Street Map für Auskunftssysteme im ÖPNV ►

Erfahrungen mit Technik und Community aus dem FuE-Projekt namo

Zusammenfassung

Unter Federführung der Rhein-Main-Verkehrsverbund Servicegesellschaft (rms) wird im Forschungsprojekt namo basierend auf Open Street Map (OSM) ein personalisiertes Fußwegerouting entwickelt. Der Einsatz von OSM bietet Chancen, wie die hohe Genauigkeit und Aktualität der Daten, birgt aber auch Risiken, wie beispielsweise die sich ständig verändernde Datenstruktur. Im Beitrag werden erste Erfahrungen im Umgang mit der OSM-Technik und der OSM-Community beschrieben.

namo1 wrote:

chris66 #58
Es gibt noch die street-Relation, welche auch andere Werte zulässt und demnach m.M.n der richtige Relationstyp für den Zweck ist
.
http://wiki.openstreetmap.org/wiki/Rela … sed/Street”

Besten Dank für den Hinweis! Diese Möglichkeit der Relationsbildung (http://wiki.openstreetmap.org/wiki/Relation:street) haben wir intern geprüft und sind zu der Entscheidung gekommen, dass wir dieses Relationsschema nun anwenden werden, wenn es hierzu keine Einwände gibt.

Wir haben nun das Relationsschema "street" angewendet, um die Gehwege mit den Straßen zu verknüpfen und hochgeladen.

Viele Grüße,
namo1

Die Erhebung unseres zweiten Untersuchungsgebietes Bad Nauheim ist abgeschlossen. Dabei haben wir unsere Erfahrungen aus dem ersten Untersuchungsgebiet Bornheim in Frankfurt am Main einfließen lassen. Diesen Datensatz werden wir im Lauf dieser Woche hochladen.

Bei Rückfragen stehen wir zur Verfügung.

Mit freundlichen Grüßen,
namo1

UPDATE: Der Datensatz für Bad Nauheim ist nun hochgeladen.

namo1 wrote:

namo1 wrote:

Besten Dank für den Hinweis! Diese Möglichkeit der Relationsbildung (http://wiki.openstreetmap.org/wiki/Relation:street) haben wir intern geprüft und sind zu der Entscheidung gekommen, dass wir dieses Relationsschema nun anwenden werden, wenn es hierzu keine Einwände gibt.

Wir haben nun das Relationsschema "street" angewendet, um die Gehwege mit den Straßen zu verknüpfen und hochgeladen.

Nur mal so fürs Protokoll: Es gab Einwände.

Tordanik wrote:

namo1 wrote:

namo1 wrote:

Besten Dank für den Hinweis! Diese Möglichkeit der Relationsbildung (http://wiki.openstreetmap.org/wiki/Relation:street) haben wir intern geprüft und sind zu der Entscheidung gekommen, dass wir dieses Relationsschema nun anwenden werden, wenn es hierzu keine Einwände gibt.

Wir haben nun das Relationsschema "street" angewendet, um die Gehwege mit den Straßen zu verknüpfen und hochgeladen.

Nur mal so fürs Protokoll: Es gab Einwände.

Bezüglich der Verwendung des Relationsschemas "street" wurden hier keine Einwände verfasst. Kannst Du diese bitte zitieren, damit wir diese prüfen können. Besten Dank im Voraus.

namo1 wrote:

Bezüglich der Verwendung des Relationsschemas "street" wurden hier keine Einwände verfasst. Kannst Du diese bitte zitieren, damit wir diese prüfen können. Besten Dank im Voraus.

Da habe ich mich wohl ungenau ausgedrückt: Nicht gegen "street" als type-Wert der Relation, sondern über die Modellierung mit Relationen und separaten Ways generell, was natürlich street-Relationen einschließt.

Ich verstehe schon, dass es für euch nicht einfach ist, wenn alle Forenteilnehmer widersprüchliche Aussagen durcheinander rufen und es keine eindeutig akzeptierten Standards gibt. Aber ich finde es als Befürworter von sidewalk-Tags an Straßen frustrierend, dass ihr anscheinend nicht bereit seid, euch in dieser Frage zu bewegen – auch, nachdem die zentralen Argumente für euer Modell entkräftet wurden, und auch angesichts der gewichtigen Gegenargumente.

Ich würde mir zumindest wünschen, dass ihr anerkennt, dass euer Projekt mit tag-basierten Gehwegen und Überwegen genauso gut möglich gewesen wäre, und dass ihr die Vorteile der Vermeidung separater Ways (z.B. fürs 2D- und 3D-Rendering und die Möglichkeit der Straßenquerung an beliebigen Punkten) durchdenkt und versteht.

In Beitrag Nummer 7 wurde darum gebeten, das Projekt offline durchzuführen, da nicht zu erwarten ist, dass dieses Schema sich durchsetzen wird und es wenig sinnvoll ist, veraltete Daten zu haben. Könnte namo1 mal darauf eingehen, warum dies nicht offline durchgeführt wird und wir mit diesem sehr komplizierten System belastet werden, welches nachher keiner pflegen wird?

namo1 wrote:

Die Erhebung unseres zweiten Untersuchungsgebietes Bad Nauheim ist abgeschlossen. Dabei haben wir unsere Erfahrungen aus dem ersten Untersuchungsgebiet Bornheim in Frankfurt am Main einfließen lassen. Diesen Datensatz werden wir im Lauf dieser Woche hochladen.

Bei Rückfragen stehen wir zur Verfügung.

Mit freundlichen Grüßen,
namo1

Könntet ihr einmal auf euer Projekt verlinken - welche Auswirkungen es auf das foot/wheelchair Routing hat- Gegenüberstellung mit einem nicht-namo Gebiete - vorher nachher - ...

Meines Erachtens ist auch die Dokumentattion auf der Website nichtsagend. Es wird nur dokumentiert, was passieren soll - aber die Dokumentation bisherigen Fortschritte (Beispiele) fehlen.

KartoGrapHiti #90

In Beitrag Nummer 7 wurde darum gebeten, das Projekt offline durchzuführen, da nicht zu erwarten ist, dass dieses Schema sich durchsetzen wird und es wenig sinnvoll ist, veraltete Daten zu haben. Könnte namo1 mal darauf eingehen, warum dies nicht offline durchgeführt wird und wir mit diesem sehr komplizierten System belastet werden, welches nachher keiner pflegen wird?

Ein Projektziel ist die Nachhaltigkeit. Deshalb haben wir uns bewusst gegen das Offline-Arbeiten entschieden, damit die Community unseren Ansatz der Erhebung mitdiskutieren kann und wir abschätzen können, was ggf. auch außerhalb der Testgebiete konsensfähig ist.

Tordanik #89

Ich verstehe schon, dass es für euch nicht einfach ist, wenn alle Forenteilnehmer widersprüchliche Aussagen durcheinander rufen und es keine eindeutig akzeptierten Standards gibt. Aber ich finde es als Befürworter von sidewalk-Tags an Straßen frustrierend, dass ihr anscheinend nicht bereit seid, euch in dieser Frage zu bewegen – auch, nachdem die zentralen Argumente für euer Modell entkräftet wurden, und auch angesichts der gewichtigen Gegenargumente.

Ich würde mir zumindest wünschen, dass ihr anerkennt, dass euer Projekt mit tag-basierten Gehwegen und Überwegen genauso gut möglich gewesen wäre, und dass ihr die Vorteile der Vermeidung separater Ways (z.B. fürs 2D- und 3D-Rendering und die Möglichkeit der Straßenquerung an beliebigen Punkten) durchdenkt und versteht.

Wir hatten uns vor der Datenaufnahme mit Ansprechpartnern in der Community abgestimmt und ihnen unsere Vorstellungen erläutert. Jene wurden gut geheißen, wenn auch mit dem Hinweis, dass sie in der Community Themen kontrovers diskutiert werden.

Eine automatische Generierung der Kanten wurde uns auch auf der InterGeo vorgeschlagen. Dies haben wir durch unser Systemhaus prüfen lassen. Eine Datenaufbereitung wie von uns benötigt ist jedoch automatisch so nicht leistbar.
Wir haben die unterbreiteten Vorschläge schon geprüft und auch im Kreis der Projektpartner kontrovers darüber diskutiert. Mit Blick auf die Nachhaltigkeit hätten wir sicherlich gerne einen Weg gewählt, der sich stärker am Bestand orientiert. Aber das entscheidende Argument konnte aus unserer Sicht nicht wirklich entkräftet werden. Sorry, dass wir dadurch bei den Befürwortern von sidewalk-Tags für Frust sorgen!

Zusätzliche Querungen haben wir dank Eurem Hinweis eingefügt, so dass ein Nutzer zwar Probleme bekommt, wenn er sich von Hausnummer 15 zu Hausnummer 21 routen lässt, aber ansonsten sollte ein Routing sinnvoll möglich sein sollte. Die Verknüpfung mit der Straße wurde vorgenommen, so dass wir keine Inseln produzieren, von denen der Router nicht mehr herunter kommt.

Wir mussten uns entscheiden ob wir ein echtes Fußwegerouting entwickeln wollen oder wie bisher auch ein Fußwegerouting auf Straßendaten durchführen. Da wir als weiteren Schwerpunkt die Barrierefreiheit haben, blieb uns nur Variante 1. Natürlich gehen wir nicht davon aus, dass Mapper alle von uns erhobenen Attribute auch erheben und wir müssen somit sowieso ein Stufenkonzept entwickeln, mit welcher Datenqualität welches Routing möglich ist. Vorschläge hierzu werden wir dann auch zur Diskussion stellen.

geri-oc #91

Könntet ihr einmal auf euer Projekt verlinken - welche Auswirkungen es auf das foot/wheelchair Routing hat- Gegenüberstellung mit einem nicht-namo Gebiete - vorher nachher - ...

Meines Erachtens ist auch die Dokumentattion auf der Website nichtsagend. Es wird nur dokumentiert, was passieren soll - aber die Dokumentation bisherigen Fortschritte (Beispiele) fehlen.

Welche Auswirkungen es auf das foot/wheelchair Routing im Vergleich zu nicht-namo-Gebieten hat, werden wir bei unseren Funktions- und Feldtests untersuchen. Derzeit ist das System aber noch in Aufbau und die Tests stehen noch aus.
Über die Ergebnisse werden wir sicherlich auch berichten. Ob das allerdings auf unserer Website, die einen allgemeinen Überblick über namo bieten soll, geschehen wird oder auf anderem Wege müssen wir noch intern klären.

Mit freundlichen Grüßen,
namo1

namo1 wrote:

Eine automatische Generierung der Kanten wurde uns auch auf der InterGeo vorgeschlagen. Dies haben wir durch unser Systemhaus prüfen lassen. Eine Datenaufbereitung wie von uns benötigt ist jedoch automatisch so nicht leistbar.

Nur weil Euer Systemhaus das nicht leisten kann, heißt das doch lange nicht, dass das nicht geht...

namo1 wrote:

Über die Ergebnisse werden wir sicherlich auch berichten. Ob das allerdings auf unserer Website, die einen allgemeinen Überblick über namo bieten soll, geschehen wird oder auf anderem Wege müssen wir noch intern klären.

Achtet bitte darauf, dass wir das auch lesen können. Projekte enden ja oft mit einem Bericht an die Geldgeber, den (abgesehn vielleicht vom Abstract) niemand liest und drei Papers in Fachzeitschriften, an die man schwer rankommt und die man nicht weiterverbreiten darf. Da wäre ein frei verfügbares viertes Paper und eine freie Version des Berichts wirklich nett.

Und OpenStreetMap sollte vielleicht auch irgendwo in einen Nebensatz erwähnt werden, wengstens im Abstract für den Geldgeber 😉

Grüße, Max

Zusätzliche Querungen haben wir dank Eurem Hinweis eingefügt, so dass ein Nutzer zwar Probleme bekommt, wenn er sich von Hausnummer 15 zu Hausnummer 21 routen lässt, aber ansonsten sollte ein Routing sinnvoll möglich sein sollte. Die Verknüpfung mit der Straße wurde vorgenommen, so dass wir keine Inseln produzieren, von denen der Router nicht mehr herunter kommt.

Un genau das meinte ich - verdeutlicht an einem Link zu dieser Kartenstelle. Dann kann "jeder" sich diese Eintragungen im "Testgebiet" ansehen, testen und diskutieren.

Ich mappe auch getrennte Fußwege (Detailmapping). Z.B. könnte man von sidewalk auf den benachbarten way (Straße) für foot weiterrouten. Für wheelchair (sicherer Weg) aber nur an Kreuzungspunkte (die meist auch Grundstückszufahrten sind - kerb).

maxbe wrote:

Und OpenStreetMap sollte vielleicht auch irgendwo in einen Nebensatz erwähnt werden, wengstens im Abstract für den Geldgeber 😉

Wir werden Euch die gewonnenen Erkenntnisse auf jeden Fall zugänglich machen.
Und da die Wahl von OpenStreetMap als Basis gerade auch vor dem Hintergrund der Nachhaltigkeit unseres Vorhabens eine große Rolle spielt, gibt es im Schlussbericht hierzu sicherlich auch etwas mehr als einen Nebensatz

Hallo liebe OSM-Community-Mitglieder,

wir vom namo-Team sind auf der Suche nach OSM-Mitgliedern die daran interessiert sind, an unserem namo-Expertentest teilzunehmen.

Im Projekt namo wurde ein mobiler Reiseassistenzdienst entwickelt, der die Bedürfnisse von älteren Mitmenschen im ÖPNV berücksichtigt.
Der Dienst soll älteren Menschen auf der ersten bzw. letzten Meile helfen und ihnen den Zugang zum ÖPNV erleichtern, indem beim Routing die körperliche Verfassung berücksichtigt wird.

Beim Testen soll euer Fokus auf dem Routing für Fußwege liegen, das im Rahmen des Projekts entwickelt wurde und für das OSM die Basis bildet.

Der Fußwegerouting-Dienst soll in den beiden Untersuchungsgebieten Frankfurt Bornheim und Bad Nauheim (Kerngebiet) getestet werden, da nur dort Fußwege separat zum Straßenverlauf im Detail erhoben und anschließend in das System gepflegt wurden. Optimal wäre es daher, wenn ihr aus der Umgebung der Testgebiete kommt, euch dort auskennt und den Dienst vielleicht sogar vor Ort testen könntet.

Nach der Testphase (ca. 2-3 Wochen), während der ihr frei testet oder auch einige von uns vorgeschlagene Aufgaben erfüllen könnt, würden wir gerne mit euch ein abschließendes Interview führen - entweder in unseren Räumlichkeiten in Frankfurt oder auch gerne telefonisch - um eure Eindrücke vom Dienst in Erfahrung zu bringen und diese in die Auswertung mit einfließen lassen zu können.

Meldet euch bitte bei Interesse, um weitere Informationen zur Teilnahme zu erfahren.

Wir würden uns über positive Nachrichten freuen!

Mit freundlichen Grüßen,
das namo-Team

Hallo OSM-Community-Mitglieder,

wir möchten euch anhand von Screenshots aus der namo-App heraus ein paar Ergebnisse des Fußwegeroutings vorstellen, da dieses auf OSM basiert. Die gezeigten Fußwege auf den unteren Bildern befinden sich in unseren Untersuchungsgebieten Frankfurt am Main - Bornheim und Bad Nauheim (Kerngebiet). Die Fußwege wurden sehr detailliert aufgenommen mit dem Ziel ein barrierefreies, straßenseitenscharfes Routing im Straßenraum zu ermöglichen. Die erhobenen Attribute könnt ihr auf unserer OSM-Wiki-Seite nachlesen.

Anhand der Daten kann ein individuelles Fußwegerouting je nach Wunsch des Nutzers berechnet werden. Hierfür kann er in unserer App zwischen vorgefertigten Profilen wie z.B. „Rollatornutzer“, „Ohne Einschränkungen“, „Geheingeschränkt“, „Treppe meiden“ wählen oder er stellt sich ein Profil ganz individuell nach seinen Wünschen zusammen. Die Auswahl der Attribute basiert u.a. auf den Projekten BAIM/BAIMplus, deren Ziel ein barrierefreies Routing innerhalb von Stationen ist, DIN-Normen der Barrierefreiheit und in Zusammenarbeit mit eines eigens einberufenen Seniorengremium, mit dem diverse Szenarien unter realen Einflüssen durchgespielt wurden.

Bitte bedenkt beim Betrachten der Bilder, dass die namo-App noch einen Arbeitsstand und nicht die finale Version darstellt.

Routingergebnisse:

Die ersten beiden Bilder stellen einen Vergleich einer Verbindungsanfrage mit denselben Start- und Zielparametern dar. Im linken Bild wurde für die Verbindungsanfrage das Profil „Rollatornutzer“ verwendet. Dieses Profil sorgt dafür dass u.a. Kanten, die eine Steigung größer 6% aufweisen, schlechter bewertet werden als Kanten ohne oder mit einer geringeren Steigung. Da der Pfad zwischen der Gronauer Str. und Heidestr. eine Steigung von über 6% aufweist, wird der Nutzer mit dem Profil „Rollatornutzer“ an dieser Stelle nicht über diese Kante geroutet. Der Weg über die Neebstr. ist für sein gewünschtes Profil günstiger. Mit dem Profil „Ohne Einschränkungen“ erhält der Nutzer die kürzeste Route (rechtes Bild), unabhängig von den vorliegenden Attributen an den Kanten.

Profil: Profil:
Rollatornutzer Ohne Einschränkungen

Im dritten und vierten Bild werden wieder zwei unterschiedliche Routingergebnisse für eine Verbindungsanfrage vorgestellt. Im linken Bild wird der Nutzer über die Treppe geroutet, da er das Profil „Ohne Einschränkung“ ausgewählt hat, während im rechten Bild kein Routing über die Treppen erfolgt, da hier das Profil „Rollatornutzer“ ausgewählt wurde und hier Treppen ausgeschlossen sind.

Profil: Profil:
Ohne Einschränkungen Rollatornutzer

In den letzten beiden Bildern werden für ein und dieselbe Verbindungsanfrage wieder zwei unterschiedliche Routingergebnisse aufgezeigt. Im linken Bild wurde das Profil „Ohne Einschränkung“ ausgewählt. Im rechten Bild wurde zusätzlich zum Profil „Ohne Einschränkung“ noch der Parameter „Dunkle Passagen meiden“ hinzugefügt. Aus diesem Grund wird der Nutzer im rechten Bild nicht durch den schlecht ausgeleuchteten Park geroutet, sondern über beleuchtete Gehwege. Dies soll zum subjektiven Sicherheitsgefühl beitragen.

Profil: Profil:
Ohne Einschränkungen Ohne Einschränkung + Dunkle Passagen meiden

Wir würden uns freuen, wenn ihr die verschiedenen Routingergebnisse kommentieren würdet.

Bei eurem Feedback solltet ihr insbesondere darauf eingehen, dass das Fußwegerouting straßenseitenscharf auf der Karte angezeigt wird und auch Straßenquerungen erkennen lässt.

Außerdem wäre die Bereitschaft zur Pflege von Fußwegeattributen eurerseits interessant, insbesondere da anhand der Beispiele erkennbar ist, dass dadurch ein individuelles Fußwegerouting möglich ist. Besten Dank im Voraus.

Mit freundlichen Grüßen,
das namo-Team

namo1 wrote:

die eine Steigung größer 6% aufweisen, schlechter bewertet werden als Kanten ohne oder mit einer geringeren Steigung.

Wie sehen denn Eure Gewichtungen aus? In der Praxis dürften Ja/Nein-Entscheidungen eher selten sein, Abwägungen ("3 Stufen sind schlecht, aber 800 Meter Umweg noch schlechter") die Regel.

Die Ergebnisse sehen gut aus, aber ohne Ortskenntnis kann man halt nur sehen, dass ein Profil "keine Treppen" eben keine Treppen auswählt. Habt Ihr die Testsenioren schon befragt? Vielleicht haben die ja lieber einen Weg genommen, der in OSM fehlt. Oder falsch eingetragen ist. Oder richtig eingetragen ist, aber von den Routingprofilen falsch bewertet wird.

namo1 wrote:

Bei eurem Feedback solltet ihr insbesondere darauf eingehen, dass das Fußwegerouting straßenseitenscharf auf der Karte angezeigt wird und auch Straßenquerungen erkennen lässt.

Dass das Routing auf parallelen Fußwegen neben den Straßen entlangführt, überrascht nicht so sehr bei einem Router, der Fußwege mag und Straßen meidet. Vermeidet Ihr Straßen gänzlich, oder werden die nur sehr schlecht bewertet? Auf dem letzten Bild sieht es so aus, als ob die Route der Kurstr. folgt, nicht ihrem Gehweg...

namo1 wrote:

die Bereitschaft zur Pflege von Fußwegeattributen eurerseits interessant

Ich habe den Eindruck, die Leute tragen ganz gerne Fußwege ein. Allerdings nicht in der benötigten Detaillierung. Neigungswinkel und Gehsteigkantenhöhen sind mühsam zu erfassen und erfordern persönliche Anwesenheit des Mappers vor Ort. Aber da fehlt einfach nur die Motivation durch sinnvolle Anwendungen. Bei Informationen, die fürs Autorouting interessant sind, klappt das ja auch.

Grüße, Max

maxbe wrote:

Wie sehen denn Eure Gewichtungen aus? In der Praxis dürften Ja/Nein-Entscheidungen eher selten sein.

Wir verwenden folgende Gewichtungswerte -1 und 0.5 bis 10, wobei -1 einen Ausschluss eines Attributes bedeutet, z.B. Treppen vermeiden. Beim Routing wird die Länge der Kante mit dem hinterlegten Wert multipliziert, so dass der Nutzer (abhängig von seinen Einstellungen) für ihn den kürzesten und günstigsten Weg erhält.

Den Wert -1 setzen wir sehr sorgfältig ein, da oftmals der Nutzer sonst nicht an sein Ziel ankommen würde.

Ein Beispiel:
Liegt das Ziel auf einer Anhöhe, die z.B. eine Steigung von 12% oder mehr besitzt, würde es nicht anroutbar sein, wenn der Nutzer zuvor das Attribut „Steigung größer als 12%“ ausgeschlossen hätte. In diesem Fall wird dieses Attribut sehr hoch gewichtet, so dass der Nutzer diese Kante/Fußweg möglichst nur erhält, wenn sein Ziel sich dort befindet.

maxbe wrote:

Habt Ihr die Testsenioren schon befragt?

Ja, wir hatten Ende letzten Jahres den Nutzertest, bei dem die Senioren mit Hilfe der namo-App diverse Szenarien erledigen sollten. Dabei spielte auch insbesondere das Fußwegerouting eine große Rolle. Anschließend konnten die Senioren in einem freien Nutzertest die namo-App noch privat ausprobieren. Die Auswertung der Ergebnisse befindet sich noch in Arbeit.

maxbe wrote:

Vermeidet Ihr Straßen gänzlich, oder werden die nur sehr schlecht bewertet?

Nein, Straßen werden nicht gänzlich vermieden. Sie erhalten lediglich eine höhere Gewichtung als Fußwege. Ausschluss von Straßen würde nämlich bedeuten, dass wir aus unseren Untersuchungsgebieten nicht „rauskommen“ würden und das wollen wir natürlich nicht! In unsere Untersuchungsgebiete soll rein- und rausgeroutet werden können. Aus diesem Grund haben wir die Fußwege am Ende der Untersuchungsgebiete mit dem vorherrschenden Straßennetz verbunden.

maxbe wrote:

Auf dem letzten Bild sieht es so aus, als ob die Route der Kurstr. folgt, nicht ihrem Gehweg.

Ja, aber tatsächlich folgt die Route dem gepflegten Fußweg. Diese „Unschönheit“ kommt zustande, da wir uns bei der Pflege der Fußwege an Bing Sat orientiert haben. In der Realität ist dieser Abschnitt eine einspurige Einbahnstraße, so dass die Straßen- und Fußwegkante sehr dicht beieinanderliegen. Oftmals haben wir dieses Problem der "Unschönheit“, da das Straßennetz nicht immer mit der Bing Sat-Karte deckungsgleich ist und da wir uns auch in diesen Situationen an die Bing Sat-Karte orientiert haben, kommt es öfters mal zu solchen „Unschönheiten“.

Hallo,
ich möchte dieses Thema hier nochmal aufgreifen...
Ich arbeite gerade im Ortskern von Bad Nauheim.
Wie soll ich mit dieser Projektarbeit umgehen?
Was ist mit den Relationen 'street' an den Gehwegen?
Gibt es da irgendeinen Konsens?
Alles löschen? und umtaggen?

Ich kann einiges davon übernehmen, aber wie schon angemerkt wurde, macht es extrem viel Arbeit, es anzupassen.
Gruss scg1176

Warum willst du löschenoder ändern? Ist etwas falsch?
Zeige am besten Beispiele mit Link - was falsch ist oder was du ändern/löschen würdest.

Es geht mir nicht um etwas bestimmtes einzelnes, sondern um das Projekt an sich...
Es ist ja nicht OSM-konform erstellt worden.
http://www.openstreetmap.org/#map=19/50.36478/8.73430

Hier gibt es footway=crossing und Relationen mit type=street usw., die aus diesem Projekt kommen.
Deshalb meine Eingangsfrage: Wie soll damit umgegangen werden?
Wird das weiter verfolgt, oder soll ich es OSM-konform machen?
Soll ich es einfacher machen?
LG

Wir mappen was wir sehen und vereinfachen kann "Software".

Und wo ist es nicht konform? Vielleicht wie das Projekt angefangen hat ... - aber falsches kann ich nicht sehen (und nicht nur deutsche Seiten im Wiki beachten - verbindlich ist immer noch englisch):

http://wiki.openstreetmap.org/wiki/Tag: … %3Dfootway

http://wiki.openstreetmap.org/wiki/Tag: … 3Dcrossing

http://wiki.openstreetmap.org/wiki/Relation:street

Was soll hier verkehrt sein?
http://www.openstreetmap.org/directions … 657/8.7389

Hallo scg1176,

wenn es vor Ort keine bauliche Trennung (Bordsteine sind hier keine bauliche Trennung) gibt, dann haben die Bürgersteige IMHO keine Existenzberechtigung in OSM als separate Ways. Ich selbst habe schon mal vor über einem Jahr in Bad Nauheim Bürgersteige in der Frankfurter Straße aus diesem Grund gelöscht. (Ich war vor Ort)

Das Namo-Projekt ist, solange es nicht wieder irgendeinen Fördertopf gibt, tot und wird sich nicht darum kümmern. OSM ist, was man daraus macht. Manchmal gehört zur Pflege auch das Löschen. Dass das Namo-Projekt kräftig angeeckt ist, kannst du in diesem Thread ja schön nachlesen.

Ich selbst hätte kein Problem damit, wenn man sogar das ganze Namo-Zeug pauschal löschen würde, wenn das die Arbeit erleichtert.

Viele Grüße

Michael

Nakaner wrote:

Das Namo-Projekt ist, solange es nicht wieder irgendeinen Fördertopf gibt, tot und wird sich nicht darum kümmern.

Hmmm, gibt's denn wenigstens Anwender, also hunderte von Rentnern, die sich ein OSM Navi an den Rollator schnallen und sich damit durch die Straßen von Bad Nauheim leiten lassen?

Nakaner wrote:

wenn es vor Ort keine bauliche Trennung (Bordsteine sind hier keine bauliche Trennung) gibt, dann haben die Bürgersteige IMHO keine Existenzberechtigung in OSM als separate Ways.

Ich würde mir wünschen, dass wir in diesem Punkt allmählich etwas toleranter werden. Ich verstehe das Wiki, aber auch das real vorhandene Mapping in OSM so, dass es ganz einfach zwei verschiedene Ansätze gibt, wie Bürgersteige (sidewalks) gemappt/getaggt werden können. Beide Ansätze sind an sich OK und in sich schlüssig, sie müssen nur jeweils korrekt umgesetzt und dürfen nicht vermischt werden.

1. Die Bürgersteige werden nicht als separate Ways erfasst, sondern per Tags an der Straße, welche sie begleiten. Diese Straße erhält daher das Tag sidewalk=no/left/right/both. Weitere Attribute der Bürgersteige werden analog dazu an der Straße mit sidewalk:left:width=*, sidewalk:left:surface=* etc. getaggt. Achtung: Wenn die Art/die Eigenschaften der Bürgersteige wechseln, muss man die Straße am entsprechenden Punkt teilen.

2. Die Bürgersteige werden als eigene Wege gemappt und mit highway=footway, footway=sidewalk getaggt. Letzteres ist wichtig: footway=sidewalk erlaubt die Unterscheidung von 'echten' Fußwegen und kann von Renderern und Co. dazu verwendet werden, die Bürgersteige auszublenden, wenn das gewünscht ist (v.a. auf groben Zoomstufen sinnvoll). Weitere Attribute der Bürgersteige werden direkt an diesen Ways getaggt.

Beide (!) Ansätze haben ihre Vor- und Nachteile. Sie dürfen natürlich nicht vermischt werden, sprich, die Bürgersteige dürfen nicht an einer Straße mit beiden Methoden auf einmal erfasst werden (kommt hin und wieder vor), denn das ist natürlich nicht eindeutig auswertbar und kann zu Widersprüchen führen.

Wenn wir einfach mal anerkennen, dass es beide Ansätz gibt, könnte wir uns den Kleinkrieg für/gegen Ansatz 1/2 sparen und stattdessen konstruktiver daran arbeiten, das an einer Straße/in einem Gebiet jeweils vorhandene Tagging konsequent durchzuziehen und zu verbessern. 😉

Edit: klarer.

Chrysopras wrote:

Beide Ansätze sind an sich OK und in sich schlüssig, sie müssen nur jeweils korrekt umgesetzt und dürfen nicht vermischt werden.

Das ist m.E. gerade nicht der Fall, denn beide Ansätze haben klaffende Lücken. Beim Tag-Mapping ist die Lücke die fehlende Geometrie-Information, was gerade bei von der Straße abgesetzten Gehsteigen schmerzlich vermisst wird. Beim Getrenntmapping kann man sehr schön Details eintragen, dafür gibt es die Lücken eben bei den Basics ("welches Stück Gehsteig gehört zu welchem Stück Straße" usw).

Wenn wir einfach mal anerkennen, dass es beide Ansätz gibt, könnte wir uns den Kleinkrieg für/gegen Ansatz 1/2 sparen und stattdessen konstruktiver daran arbeiten, das an einer Straße/in einem Gebiet jeweils vorhandene Tagging konsequent durchzuziehen und zu verbessern. 😉

Das ist ein schöner Wunsch, aber da es eben nicht nur um Geschmacksfragen geht, sondern die Ansätze inhaltlich sehr verschieden und für sich genommen jeweils unvollständig sind, wird es ohne ein übergreifendes Konzept kaum einen Frieden geben. Und als Lösung jetzt zu sagen, dass man in A-Stadt eben die Information X nicht mappen kann und in B-Stadt die Information Y nicht mappen kann, ist aus meiner Sicht nicht realistisch. Das widerspricht dem sonst üblichen OSM-Ansatz, dass jeder die Informationen eintragen kann, die ihn interessieren.

Es führt aus meiner Sicht kein Weg daran vorbei, sich noch mal ans Reißbrett zu setzen und eine Komplettlösung zu finden. Es muss möglich sein, mal eben schnell die Existenz von Gehsteigen einzutragen, und dann Schritt für Schritt Zusatzinformation über die Geometrie des Gehsteigs, Barrieren auf dem Gehsteig etc. hinzuzufügen, ohne(!) dass dadurch an anderer Stelle Information verloren geht.

Nakaner wrote:

...
wenn es vor Ort keine bauliche Trennung (Bordsteine sind hier keine bauliche Trennung) gibt, dann haben die Bürgersteige IMHO keine Existenzberechtigung in OSM als separate Ways. Ich selbst habe schon mal vor über einem Jahr in Bad Nauheim Bürgersteige in der Frankfurter Straße aus diesem Grund gelöscht. (Ich war vor Ort)

Das Namo-Projekt ist, solange es nicht wieder irgendeinen Fördertopf gibt, tot und wird sich nicht darum kümmern. OSM ist, was man daraus macht. Manchmal gehört zur Pflege auch das Löschen. Dass das Namo-Projekt kräftig angeeckt ist, kannst du in diesem Thread ja schön nachlesen.

Ich selbst hätte kein Problem damit, wenn man sogar das ganze Namo-Zeug pauschal löschen würde, wenn das die Arbeit erleichtert.

Viele Grüße

Michael

Ich finde löschen sollte die letzte Möglichkeit sein, Daten zu verändern.

Dann brauchten wir ja die Koordinaten nur so auslegen, das man nur aller 10 m einen node packen kann. Das war vielleicht am Anfang sinnvoll, mittlerweile ist aber ein viel detaillierteres Mappen möglich. Es geht um das Erfassen der Daten und da ist ein Fußweg bei zwei Spuren schon 10 m neben der Straßenmitte. Das Nutzen der Daten für Routing zeigt, das es auch sinnvoll für Fußgänger ist. Und wenn der Fußweg ein sidewalk trägt, kann ein "sportlicher Router" jederzeit die kürzeste Verbindung direkt über die Straße wählen.

Auch in Dresden gibt es solche "Löscher" von separaten Fußwegen, weil sie nicht in ihre Vorstellungen passen. Obwohl das Wiki separate Bürgersteige zulässt.

Hmmm, gibt's denn wenigstens Anwender, also hunderte von Rentnern, die sich ein OSM Navi an den Rollator schnallen und sich damit durch die Straßen von Bad Nauheim leiten lassen?

Gab es vor 10 Jahren schon Smartphone mit Routingfunktion für Fußganger? Nein, da wurde nur alles auf Autorouting eingetragen, weil man das für sinnvoll erachtete gegenüber kostenpflichtigen Daten. Es wurden aber immer mehr Details eingetragen - Geschäfte , Gaststätten, Spielplätze, Schulen, Hundekottütenspender, ...
Es wird sicher nicht heute 100 Rentner in Bad Nauheim geben, die OSM zum routen nutzen, aber vielleicht in 2-3 Jahren. Es gibt aber jetzt schon Vorschläge für sicheren Schulweg, Arztweg der sich durch Fußgängerrouting darstellen lässt.

Und wichtig: Das deutsche Wiki sollte nicht willkürlich übersetzt werden. Siehe die Unterschiede zum Beispiel im footway - dort ist im englischen sogar bebildert und beschrieben was footway und sidewalk ist. Ein Bürgersteig ist nun einmal ein Fußweg mit Bordstein in Städten.

Was macht man mit einen Fußweg der 50 m mit einem Geländer abgeteilt ist und an einer Kreuzung Geländerschutz hat?

PS: Danke an Chrysopras.

Um in Bad Nauheim zu bleiben:
Was ist dort so falsch, dass es stört, wenn Fußwege getrennt eingetragen sind?

Tordanik wrote:

Chrysopras wrote:

Beide Ansätze sind an sich OK und in sich schlüssig, sie müssen nur jeweils korrekt umgesetzt und dürfen nicht vermischt werden.

Das ist m.E. gerade nicht der Fall, denn beide Ansätze haben klaffende Lücken. (...)

Danke, Tordanik, für Deine Darstellung! Du hast recht, beide Ansätze sind alles andere als perfekt, und es wäre am besten, eine umfassende Lösung zu finden, welche die Vorteile beider Ansätze möglichst ohne ihre Nachteile verbindet.

Mir ging es allerdings v.a. darum, der immer noch verbreiteten einseitigen Vorstellung zu widersprechen, Bürgersteige müssten zwingend als Tags an der Straße eingetragen werden (bei mir Ansatz Nr. 1), alles andere sei Unsinn, und separat gemappte Bürgersteige (Ansatz Nr. 2) seien falsch und könnten, ja sollten deshalb beliebig gelöscht werden. Auch Ansatz 1 hat Nachteile, wie Tordanik gezeigt hat.

Daher würde ich mein Fazit gerne wie folgt modifizieren: Solange wir nicht die von Tordanik mit Recht eingeforderte "Komplettlösung" haben, sollten Anhänger beider Ansätze auch den jeweils anderen Ansatz wenigstens dulden, "eingedenk des Umstandes", dass auch ihr eigener Ansatz nicht vollkommen ist. Mit dem willkürlichen Löschen von separat gemappten Bürgersteigen sollte Schluss sein (außer natürlich, falls sie sehr sehr schlecht gemappt sind bzw. es an der entsprechenden Stelle gar keinen Bürgersteigt gibt 😉).

geri-oc wrote:

Was macht man mit einen Fußweg der 50 m mit einem Geländer abgeteilt ist und an einer Kreuzung Geländerschutz hat?

Ich verstehe leider Dein Beispiel nicht: Also, zuerst wird ein Ueberqueren der Strasse 50m lange durch eine Gelaender verhindert, aber was ist ein Geländerschutz an einer Kreuzung?

Hier noch einmal meine Fragen:

o Wie kann irgend eine interpretierende Software sicher erkennen, zu welcher Strasse genau der Gehsteig gehoert?
o Wie zeichne ich jetzt noch Radwege ein? Nochmals ein eigener Way fuer den Radweg?
o Radwege sind in jedem Fall als Einbahnen zu mappen, oder wie kann ich systematisch und sicher erkennen, dass der Gehsteig links oder rechts zu einer Strasse gehoert?
o Nachdem der Detailgrad dadurch ja (eigentlich vorteilhafterweise) deutlich erhoeht wird: Wie stelle ich sicher, dass Radwege richtig gekennzeichnet werden. (Radweg laeuft auf Gehsteig, Radweg nur durch Bodenmarkierung von der Strasse getrennt); Also wie stelle ich sicher, dass (a) die Radfahrer durch diesen Mappingstil nicht systematisch benachteiligt werden und (b) durch "antaggen" der Radwegeigenschaften an Strasse oder Fussweg nicht erst wieder ein Taggingdschungel entsteht?
o Wie schauts mit Routen aus, viele kriegen dadurch, obwohl es nur eine Strasse gibt zwei Wege (fuer zwei Richtungen) fuer Radfahrer/Fussgaenger?

Die Thematik gehoert dringendst ordentlich durchueberlegt...

geri-oc wrote:

Nakaner wrote:

...
Ich selbst hätte kein Problem damit, wenn man sogar das ganze Namo-Zeug pauschal löschen würde, wenn das die Arbeit erleichtert.

Ich finde löschen sollte die letzte Möglichkeit sein, Daten zu verändern.

+1. Ergänzend: Änderungen sollten/dürfen m.M.n. nicht zu einem Verlust an Informationen führen.

Gppes wrote:

Hier noch einmal meine Fragen:

o Wie kann irgend eine interpretierende Software sicher erkennen, zu welcher Strasse genau der Gehsteig gehoert?
o Wie zeichne ich jetzt noch Radwege ein? Nochmals ein eigener Way fuer den Radweg?
o Radwege sind in jedem Fall als Einbahnen zu mappen, oder wie kann ich systematisch und sicher erkennen, dass der Gehsteig links oder rechts zu einer Strasse gehoert?
o Nachdem der Detailgrad dadurch ja (eigentlich vorteilhafterweise) deutlich erhoeht wird: Wie stelle ich sicher, dass Radwege richtig gekennzeichnet werden. (Radweg laeuft auf Gehsteig, Radweg nur durch Bodenmarkierung von der Strasse getrennt); Also wie stelle ich sicher, dass (a) die Radfahrer durch diesen Mappingstil nicht systematisch benachteiligt werden und (b) durch "antaggen" der Radwegeigenschaften an Strasse oder Fussweg nicht erst wieder ein Taggingdschungel entsteht?
o Wie schauts mit Routen aus, viele kriegen dadurch, obwohl es nur eine Strasse gibt zwei Wege (fuer zwei Richtungen) fuer Radfahrer/Fussgaenger?

1. Durch eine direktes tagging als Attribut der Straße*, oder mittels street-Relationen, oder durch einen name-tag und footway=sidewalk, oder durch footway=sidewalk und einer "around" abfrage, oder durch sonstige schlaue Algorithmen. Alles eine Frage des Schwierigkeitsgrades.
Aber schon beim Mappen fragt man sich manchmal, ob der Fußweg/Radweg nun zu einer Straße gehört oder nicht.
2.+3. Zu Radwegen siehe bitte Radverkehrsanlagen kartieren im Wiki. Bis auf die Beispiele für "*=lane" ist das Mapping austauschbar.
4. Ob Tagging-Jungel oder nicht ist eigentlich in beiden Fällen eine Frage der Gewöhnung und Abstraktion.
5. Dann ist das so, der parallele verlaufende Bereich kann dann mit "forward/backward" genauer beschrieben werden. Es ist aber m.M.n. auch OK, wenn der Zentrale-Weg (das Fahrbahn-Element) in der Route erhalten bleibt.

Hallo
ich habe nicht gemeint, dass das alles falsch ist.
Ich habe nur festgestellt, dass diese Art von Tagging richtig viel Arbeit macht. Ich habe mir einfach einen Ansatz gewünscht, der auch in Zukunft machbar ist. Dieses Thema (street, sidewalk,..) ist sehr kleinteilig. Unzählige Linien, Relationen.
Eine Änderung bedarf hier schon akribischer Vorbereitung. Sehr mühselig...
Vor allem, wenn größere Änderungen anstehen. Wie diese aussehen könnten, überlasse ich jedem seiner eigenen Fantasie!
Und es geht mir um die Änderungsnotwenigkeiten, an die man heute noch nicht denkt.

Das offensichtlich Klärungsbedarf besteht, habe ich ja mit der dezent los getretenen Diskussion ja schon bewiesen... 🙂

Mein Anliegen ist, wie es weitergehen soll.
Ich bin nämlich der Meinung, dass bestimmte Themen (und nicht nur dieses) durch die Community einigermaßen verbindlich geklärt werden sollten, an die sich, vor allem, der nullachtfünfzehn-Mapper halten kann.
public_transport hat das gleiche Problem.

Und ja, ich halte die Koexistenz verschiedener Mappingansätze für bestimmte Themen problematisch.
Was ist, wenn demnächst wieder ne neue Lösung angeboten und gemappt wird? Und in 2-3 Jahren wieder ein neuer Ansatz.
Das gibt Unkraut vom allerfeinsten, keiner blickt mehr durch, und vor allem neue Mapper werden abgeschreckt, wenn ich für jedes Teilthema Unmengen Wiki-Seiten durcharbeiten muss, um es zu verstehen. Man muss das mal in die Zukunft denken.
Auch hier ist public_transport ein gutes Beispiel. Es wird die Koexistenz geduldet, weil die Konzepte relativ gut zusammenpassen.
Aber keiner geht hin (Gruppe, Arbeitskreis, whatever...) und sagt, lasst es uns mit Ansatz x machen - fertig.
(Zumindest habe ich keine solche Entscheidung gefunden)

Es erfordert bereits heute mehrwöchiges Durchackern, um auch nur ansatzweise einen Überblick zu bekommen.
Dies sollte durch die Community stärker geregelt werden. OSM.de reicht da nicht.

Will ich neue Themen anpacken, muss ich in unzähligen Wiki/Proposals/Usersites/Foren/Diskussionen suchen, um etwas zu finden, was
ein Thema abschließend beschreibt. Natürlich mit der Möglichkeit zur Erweiterung. Ich will ja keine Fehler machen, die wiederum ein Nacharbeiten erfordern. Das hatte ich nämlich schon öfter...
Und meistens gibt es keine abschließende Meinung... nur mehrere Meinungen...

Aber so wird das in Zukunft nicht funktionieren, dafür ist OSM einfach zu groß geworden.
So große Projekte sollten im Sinne der Community gesteuert werden. Ich bin mir sicher, dass ist möglich.

So - jetzt habe ich mir mal was von der Seele geredet. (und bin auch etwas vom Thema abgekommen)
Bitte nicht gleich erschlagen, weil ich irgendein Detail vergessen habe. Mir geht es um das Große und Ganze.
Ich finde, große Teile sind sehr unübersichtlich geworden und erfordern oft immer und immer wieder Einarbeitungszeit.
Ich bin halt ein alles-mögliche-Mapper, selten mappe ich nur bestimmte Themen. Und das ist sehr schwer geworden.

Gruss
scg1176

Hubert87 wrote:

1. Durch eine direktes tagging als Attribut der Straße*, oder mittels street-Relationen, oder durch einen name-tag und footway=sidewalk, oder durch footway=sidewalk und einer "around" abfrage, oder durch sonstige schlaue Algorithmen. Alles eine Frage des Schwierigkeitsgrades.
Aber schon beim Mappen fragt man sich manchmal, ob der Fußweg/Radweg nun zu einer Straße gehört oder nicht.
2.+3. Zu Radwegen siehe bitte Radverkehrsanlagen kartieren im Wiki. Bis auf die Beispiele für "*=lane" ist das Mapping austauschbar.
4. Ob Tagging-Jungel oder nicht ist eigentlich in beiden Fällen eine Frage der Gewöhnung und Abstraktion.
5. Dann ist das so, der parallele verlaufende Bereich kann dann mit "forward/backward" genauer beschrieben werden. Es ist aber m.M.n. auch OK, wenn der Zentrale-Weg (das Fahrbahn-Element) in der Route erhalten bleibt.

Von Deinen Vorschlaegen ist viel Konstruktives dabei, aber wenn ich mich als begeisterter Radfahrer so ernst nehme wie das Gehsteigzeichner tun, dann male ich gleich mal an viele Strassen zusaetzlich zwei Ways fuer meine Radwege ran, das macht dann fuenf Ways pro Strasse...

Gute Nacht, wenn neben der Strasse ein Park ist, wo sich - leicht abgesetzt - noch ein Fuss-/Rad-Weg befindet.

PS.: Trotzdem ist loeschen auch aus meiner Sicht nicht der richtige Weg, nachdenken, einen Konsens finden, die Komplexitaet im Auge behalten... Schwierig...

Gppes wrote:

Hubert87 wrote:

1. Durch eine direktes tagging als Attribut der Straße*, oder mittels street-Relationen, oder durch einen name-tag und footway=sidewalk, oder durch footway=sidewalk und einer "around" abfrage, oder durch sonstige schlaue Algorithmen. Alles eine Frage des Schwierigkeitsgrades.
Aber schon beim Mappen fragt man sich manchmal, ob der Fußweg/Radweg nun zu einer Straße gehört oder nicht.
2.+3. Zu Radwegen siehe bitte Radverkehrsanlagen kartieren im Wiki. Bis auf die Beispiele für "*=lane" ist das Mapping austauschbar.
4. Ob Tagging-Jungel oder nicht ist eigentlich in beiden Fällen eine Frage der Gewöhnung und Abstraktion.
5. Dann ist das so, der parallele verlaufende Bereich kann dann mit "forward/backward" genauer beschrieben werden. Es ist aber m.M.n. auch OK, wenn der Zentrale-Weg (das Fahrbahn-Element) in der Route erhalten bleibt.

Von Deinen Vorschlaegen ist viel Konstruktives dabei, aber wenn ich mich als begeisterter Radfahrer so ernst nehme wie das Gehsteigzeichner tun, dann male ich gleich mal an viele Strassen zusaetzlich zwei Ways fuer meine Radwege ran, das macht dann fuenf Ways pro Strasse...

Gute Nacht, wenn neben der Strasse ein Park ist, wo sich - leicht abgesetzt - noch ein Fuss-/Rad-Weg befindet.

PS.: Trotzdem ist loeschen auch aus meiner Sicht nicht der richtige Weg, nachdenken, einen Konsens finden, die Komplexitaet im Auge behalten... Schwierig...

Ungefähr so sehe ich das auch...
Es ist irgendwann nur noch durch Profis händelbar. Ob das Sinn macht?

Beispiel Geländerschutz an einer Kreuzung (zur Ebene Bing Aerial View wechseln):
http://www.sammyshp.de/fsmap/#20/51.00692/13.65764

scg1176 wrote:

... Ich habe nur festgestellt, dass diese Art von Tagging richtig viel Arbeit macht. Ich habe mir einfach einen Ansatz gewünscht, der auch in Zukunft machbar ist. Dieses Thema (street, sidewalk,..) ist sehr kleinteilig. Unzählige Linien, Relationen. ...

Das "kleinteilige" ist aber "lagerichtig" im Verhältnis zur Straße und teilweise ändert sich sogar die Lage mehrfach. Ich bin für einfaches Mappen, genau wie man es sieht.
- Und ja es ist aufwendiger, da genauer / detailierter.

Das ist für mich "unübersichtlicher"
- auch fehlen Informationen: Wo verläuft bei diesen Tagging der Fußweg und der Radweg? Wie breit ist der jeweilige Weg? Noch mehr taggs an diesen way, wenn der surface einer Seite sich ändert? Wo mappe ich einen Poller auf dem Fußweg?
cycleway:left=track; cycleway:left:bicycle=designated; cycleway:left:oneway=no; cycleway:left:segregated=no; cycleway:left:surface=paving_stones; highway=secondary; lanes=2; lit=yes; maxspeed=50; name=Tharandter Straße; ref=S 194; sidewalk=both; sidewalk:both:smoothness=good; sidewalk:both:surface=paving_stones; smoothness=excellent; surface=asphalt; zone:traffic=DE:urban

Gppes wrote:

Von Deinen Vorschlaegen ist viel Konstruktives dabei, aber wenn ich mich als begeisterter Radfahrer so ernst nehme wie das Gehsteigzeichner tun, dann male ich gleich mal an viele Strassen zusaetzlich zwei Ways fuer meine Radwege ran, das macht dann fuenf Ways pro Strasse...

Wieso 5 ways?
Meist ist doch ein Bürgersteig entweder mit geteiltem oder kombinierten Radweg. Und meist ist der Radweg im Gegenverkehr nur auf einer Straßenseite. Zu mindest bei uns.

geri-oc wrote:

Das ist für mich "unübersichtlicher"
- auch fehlen Informationen: Wo verläuft bei diesen Tagging der Fußweg und der Radweg? Wie breit ist der jeweilige Weg? Noch mehr taggs an diesen way, wenn der surface einer Seite sich ändert? Wo mappe ich einen Poller auf dem Fußweg?
cycleway:left=track; cycleway:left:bicycle=designated; cycleway:left:oneway=no; cycleway:left:segregated=no; cycleway:left:surface=paving_stones; highway=secondary; lanes=2; lit=yes; maxspeed=50; name=Tharandter Straße; ref=S 194; sidewalk=both; sidewalk:both:smoothness=good; sidewalk:both:surface=paving_stones; smoothness=excellent; surface=asphalt; zone:traffic=DE:urban

Das ist nicht unuebersichtlich, wenn sich der Editor daran anpasst. Zusammengehoerige Tags kann man gruppieren und mit einem Pfeilchen aufklappen, um die Tags zu pruefen oder anzupassen. Und alles waere logisch an dem Objekt dran, wo es ran gehoert: An der Strasse. (Und ich fahre mit meinem Garmin nicht mehr - wie der derzeit - auf einem unbekannten Weg (wenn als extra way gemappt), sondern so wie es sich gehoert auf der So-und-so-Strasse. Ich kenne derzeit keine einzige Software, die diese Gehsteig-Ways den entsprechenden Strassen zuordnen kann. Obendrein halte ich es nach der derzeitigen Mappingkonvention fuer fast unmoeglich, so eine Software (die auch zuverlaessig arbeitet) zu programmieren.

geri-oc wrote:

Gppes wrote:

Von Deinen Vorschlaegen ist viel Konstruktives dabei, aber wenn ich mich als begeisterter Radfahrer so ernst nehme wie das Gehsteigzeichner tun, dann male ich gleich mal an viele Strassen zusaetzlich zwei Ways fuer meine Radwege ran, das macht dann fuenf Ways pro Strasse...

Wieso 5 ways?
Meist ist doch ein Bürgersteig entweder mit geteiltem oder kombinierten Radweg. Und meist ist der Radweg im Gegenverkehr nur auf einer Straßenseite. Zu mindest bei uns.

Fuenf ways extrem gesprochen deshalb, weil wenn neben der Strasse ein Buergersteig und ein getrennter Radweg auf beiden Seiten laeuft, es nach der Methode getrennte Ways zu Mappen es auch nur konsequent ist, alle Wege getrennt zu mappen. Einen Tagging-Dschungel kann ich immer erfinden: Z.B. ist bei uns an vielen Radwegen ein "Radweg-Ende"* gebraeuchlich. Radweg und Fussweg koennen unterschiedliche Oberflaechen haben, auch durchaus gebraeuchlich.

• Edit: Bei vielen Kreuzungen, um den Nachrang fuer Radfahrer zu erzwingen.
  

Gppes wrote:

Radweg und Fussweg koennen unterschiedliche Oberflaechen haben, auch durchaus gebraeuchlich.

Ist das nicht sogar die Regel?

x:x eine Koordinate für einen Punkt auf der Mitte von einem Radweg.
y:y eine Koordinate für einen Punkt auf der Mitte von einer Straße.

Sie liegen auseinander. Wir mappen nicht für Router, wir erfassen Daten. Und wir brauchen nichts erfinden, wenn wir die Wirklichkeit erfassen. OSM hat den Vorteil, viele Einzelheiten zu erfassen und nicht an Vorgaben von kommerziellen Nutzern gebunden zu sein. Den Vorteil - und den Vorsprung -sollten wir nutzen.

Und wenn es keine Software kann, dann muss sie es lernen.
Oder sollten wir die Datenbankgenauigkeit auf 15 m reduzieren?

Einmal ein paar Zitate von früher - älter als 5 Jahre:
Fabi2: "Man kann ja sehr wohl einen Radweg über den highway-Tag von einer Straße unterscheiden und wenn der Router, in der Einstellung "Auto", einen auf den Radweg schicken will, sollte man den Entwicklern mal einen Bugreport schicken oder einen kaufen, der funkrioniert."

errt: "... Letztendlich werden wir es getrennt mappen müssen, alles andere ist langfristig zu ungenau."
"... damit die Autorouter nicht noch mehr jammern."

flaimo: "... dass OSM in absehbarer zeit die kommerzielle konkurrenz im regen stehen lässt und durch festklammern an mapping-konventionen anno 2009 wird sich das nicht erreichen lassen."

Mueck: "Nicht nur Blinde. Für gutes Rollstuhlrouting wird eines Tages auch die Info relevant sein, wo genau Bordsteine abgesenkt sind."

okilimu: " Ich erfasse in meiner Stadt Bürgersteige als eigenständige Wege, ich verstehe nicht, warum diese nur als straßenbegleitend angesehen werden, sie sind eigenständig für den "Verkehrsträger" Mensch.

EDIT: Wir sollten auch nicht nur über Deutschland reden, andere mappen auch so: http://www.openstreetmap.org/#map=19/52.21528/-0.06674

geri-oc wrote:

x:x eine Koordinate für einen Punkt auf der Mitte von einem Radweg.
y:y eine Koordinate für einen Punkt auf der Mitte von einer Straße.

Sie liegen auseinander. Wir mappen nicht für Router, wir erfassen Daten. Und wir brauchen nichts erfinden, wenn wir die Wirklichkeit erfassen. OSM hat den Vorteil, viele Einzelheiten zu erfassen und nicht an Vorgaben von kommerziellen Nutzern gebunden zu sein. Den Vorteil - und den Vorsprung -sollten wir nutzen.

Und wenn es keine Software kann, dann muss sie es lernen.
Oder sollten wir die Datenbankgenauigkeit auf 15 m reduzieren?

Die Mapper, die Gehsteige separat Mappen, argumentieren eigentlich sehr gerne ueber das Argument Fussgaengerrouting... Und ich argumentiere aus meiner Sicht durchaus konstruktiv dahingehend, dass die derzeitige Loesung wirklich teuflisch fuer Software ist. Ich sage also nicht "Mappe fuer den Renderer" sondern eher "Mappe nicht gegen den Renderer (und jegliche andere interpretierende Software)".

Aus meiner Sicht wird das ganze zum von vielen gewuenschten Flachenmapping von Strassen fuehren, fuer mich auch ein grosses Aua, aber es wird - glaube ich - kommen. Dann wird um die ganzen Ways ohnehin eine Area gewickelt, das Problem mit der Zugehoerigkeit ist erledigt, und die Detailstufe ist in vernuenftigem Mass aufgedreht. Die Ways selber werden dann auf den Karten vermutlich unsichtbar gerendert, weil es ja nur noch Routing-Informationen sind (und schon wieder hat man die Ways nur fuer den Router gemacht).

Ich glaube, wenn das Flaechenmapping auf Wegen ohne starkes Konzept kommt, dann wird es aber wirklich schlimm. Denke man an die ganzen Flaechen-Multipolygon und Flaechenrendergeschichten auf Wiesen, Aeckern und Waeldern.

Vielleicht sollte man die Diskussion hier konstruktiv dazu nutzen auf irgend einer Wiki-Diskussionsseite objektiv Vorteile und Nachteile zu listen, Vermutungen fuer potenzielle Probleme anzufuehren und sich Regeln fuer ein 2D-Strassenmapping zu ueberlegen, weil da fuehrt die Sache aus meiner Sicht unweigerlich hin. (Ich will das nicht wegen der Komplexheit, aber kann gut damit leben, einfach weil mir Openstreetmap taugt und weil es Potenzial fuer viele Details hat.)

geri-oc wrote:

EDIT: Wir sollten auch nicht nur über Deutschland reden, andere mappen auch so: http://www.openstreetmap.org/#map=19/52.21528/-0.06674

Dieses Wegebueschel im Zentrum, startend vom "Chapmans Drive". Aua! ;-)

Gppes wrote:

Aus meiner Sicht wird das ganze zum von vielen gewuenschten Flachenmapping von Strassen fuehren, fuer mich auch ein grosses Aua, aber es wird - glaube ich - kommen. Dann wird um die ganzen Ways ohnehin eine Area gewickelt, das Problem mit der Zugehoerigkeit ist erledigt, und die Detailstufe ist in vernuenftigem Mass aufgedreht. Die Ways selber werden dann auf den Karten vermutlich unsichtbar gerendert, weil es ja nur noch Routing-Informationen sind (und schon wieder hat man die Ways nur fuer den Router gemacht).

Ich glaube, wenn das Flaechenmapping auf Wegen ohne starkes Konzept kommt, dann wird es aber wirklich schlimm. Denke man an die ganzen Flaechen-Multipolygon und Flaechenrendergeschichten auf Wiesen, Aeckern und Waeldern.

Ich Zitiere mich mal aus dem Jahre 2012:

streckenkundler wrote:

Streng genommen würde es darauf hinauslaufen daß es eine Routingebene geben müsste oder muß oder gibt, die die Wege- und Straßeninformationen zur Zielfindung endhält und das es zum anderen eine Ebene der Kartendarstellung gibt, die man z.B. im Web-Browser sieht. Beides ist gleichermaßen wichtig.

In mir keimt auch so die Vermutung daß auch Renderer diese Dinge unterscheiden werden müssen.

Bei dieser Sicht bleibe ich auch, und nach den Jahren verfestigt sich meine Meinung weiter. Bei der Anwendung von area:highway ergeben sich automatisch seperate straßenbegleitende Rad- und Fußwege, da das Konzept ohne dieses nicht funktioniert. Der Detaillierungsgrad ist ja viel höher.

Sven

Leute, die sich für die Problematik des Bürgersteigroutings interessieren finden übrigens bei dieser Bachelorarbeit von Nathanael Lang Code zum Spielen und eine interessante Lektüre. Dort wird auch die Frage behandelt, was man bei Wegen macht, die auf beide Arten eingetragen sind. Kam neulich mal als Wochennotiz, ist aber vielleicht untergegangen.

Chrysopras wrote:

footway=sidewalk erlaubt die Unterscheidung von 'echten' Fußwegen und kann von Renderern und Co. dazu verwendet werden, die Bürgersteige auszublenden, wenn das gewünscht ist (v.a. auf groben Zoomstufen sinnvoll). Weitere Attribute der Bürgersteige werden direkt an diesen Ways getaggt.

Kennt jemand einen Renderer, der das jetzt schon macht? Ich schaffe es nicht. In kleinen Maßstäben überdecken die Strassen sowieso die Gehwege oder die Pfade werden sowieso noch nicht gezeichnet. In grossen Maßstäben bleiben immer so merkwürdige Stummel dort, wo nicht-sidewalks auf sidewalks treffen (z.B. links im Bild, Kreuzung Augusten/Brienner und nördlich Brienner/Königsplatz zur Grünanlage, ist diese Gegend). Einzig sinnvolle Verwendung des Tags fürs Rendern scheint mir derzeit, dass man damit die lästigen Mehrfachbeschriftungen von Autofahrbahn, Radfahrbahn und Fussweg unterdrücken kann.

scg1176 wrote:

Wie soll ich mit dieser Projektarbeit umgehen?
Was ist mit den Relationen 'street' an den Gehwegen?
Gibt es da irgendeinen Konsens?
Alles löschen? und umtaggen?

Ich würde nichts absichtlich löschen, aber auch keine grosse Rücksicht nehmen. Bei Namo scheint der letzte Konferenzkeks geknabbert zu sein und wenn das BMBF nicht nochmal eine Million nachschiesst, werden wir wohl auch den in #96 hier versprochenen Abschlussbericht nicht zu sehen bekommen 😉

Grüße
Max

Moin,

maxbe wrote:

Chrysopras wrote:

footway=sidewalk erlaubt die Unterscheidung von 'echten' Fußwegen und kann von Renderern und Co. dazu verwendet werden, die Bürgersteige auszublenden, wenn das gewünscht is [...]

Kennt jemand einen Renderer, der das jetzt schon macht? Ich schaffe es nicht.
[...]
In grossen Maßstäben bleiben immer so merkwürdige Stummel dort, wo nicht-sidewalks auf sidewalks treffen

na ja, das sehe ich als Tagging-Missverständnis:
Ein (foot)way-Stummel, der nur einen sidewalk mit dem Straßen-way verbindet ist für mich auch immer ein sidewalk - es ist ja letztendlich auch nur der Bordstein.
Edit: Links unten an der Kreuzung Augustenstr. ist der Stummel ja auch nicht zu sehen.
Im Gegensatz zu einem 'echten' footway, der über den (querenden) sidewalk hinaus bis zum Straßen-way durchgebunden wird.

Man muss den Kompromiss zwischen den beiden Mapping-Arten halt auch beim Tagging schon entsprechend berücksichtigen.
(So a la: Wie ist es zu taggen, wenn ich die andere Art verwenden würde.)

Grüße, Georg

maxbe wrote:

Chrysopras wrote:

footway=sidewalk erlaubt die Unterscheidung von 'echten' Fußwegen und kann von Renderern und Co. dazu verwendet werden, die Bürgersteige auszublenden, wenn das gewünscht is [...]

Kennt jemand einen Renderer, der das jetzt schon macht?

Nein, aber das ist doch das Problem des Renderers, nicht des Mappers. Durch footway=sidewalk gibt der Mapper dem Renderer die Möglichkeit, die Gehsteige von anderen Fußwegen zu unterscheiden. Eine einfache Fallunterscheidung sollte da reichen. (Falls das bei real existierender OSM-Render-Software nicht so einfach ist, tut mir das leid, aber an sich sollte das nicht mehr als ein einfaches if sein.)

GeorgFausB wrote:

maxbe wrote:

In grossen Maßstäben bleiben immer so merkwürdige Stummel dort, wo nicht-sidewalks auf sidewalks treffen

na ja, das sehe ich als Tagging-Missverständnis:
Ein (foot)way-Stummel, der nur einen sidewalk mit dem Straßen-way verbindet ist für mich auch immer ein sidewalk - es ist ja letztendlich auch nur der Bordstein. (...) Man muss den Kompromiss zwischen den beiden Mapping-Arten halt auch beim Tagging schon entsprechend berücksichtigen.

So sehe ich das auch. Kurze Wege, welche ein highway=footway, footway=sidewalk mit einer Straße verbinden, sollten ihrerseits entweder wieder highway=footway, footway=sidewalk sein, oder ggf. (wenn sie an einer markierten Stelle über die Straße führen) highway=footway, footway=crossing.

Chrysopras wrote:

...

So sehe ich das auch. Kurze Wege, welche ein highway=footway, footway=sidewalk mit einer Straße verbinden, sollten ihrerseits entweder wieder highway=footway, footway=sidewalk sein, oder ggf. (wenn sie an einer markierten Stelle über die Straße führen) highway=footway, footway=crossing.

Die Verbindungen mit der Straße ist aber nur richtig, wenn sich an dieser Stelle im Bordstein eine Absenkung befindet. Vielmals fehlt nur die Grundstückszufahrt über den Fußweg, und auch das sie erst als "Privat" ab Grundstückseingen eingetragen sind.

Noch zum rendern: Fußwege könnten ab Z18 / Z19 gerendert werden - da bin ich aber "Laie", ob so etwas möglich ist.

maxbe wrote:

Bei Namo scheint der letzte Konferenzkeks geknabbert zu sein und wenn das BMBF nicht nochmal eine Million nachschiesst, werden wir wohl auch den in #96 hier versprochenen Abschlussbericht nicht zu sehen bekommen 😉

Hier ist er:
http://www.ffg.tu-dortmund.de/cms/de/Pr … vfinal.pdf
Ab Seite 109 steht auch etwas über die Diskussion im Forum.

Viele Grüße,
whb

whb wrote:

Hier ist er:
http://www.ffg.tu-dortmund.de/cms/de/Pr … vfinal.pdf
Ab Seite 109 steht auch etwas über die Diskussion im Forum.

Danke!

Nachtrag, habs gelesen: Für die technischen Teile bin ich nicht in der richtigen Zielgruppe, fürchte ich. Den Rest fand ich sehr lesenswert.