Das Layout finde ich sehr ansprechend, habe aber eine Weile gebraucht, um zu verstehen, was der Fußweg und was die Fahrbahn ist. Das lag an dem hellen Grau des Fußwegs und daran, dass es anders als beim Radweg keine grafischen Merkmale gibt, die auf einen Fußweg hinweisen (Piktos, z.B.). Die Fahrbahn ist mir zu schmal in Relation zu Rad- und Fußweg.
Ich verstehe auch nicht, was die gestrichelten Linien mit Pfeilen auf der Fahrbahn bei C1, C2, D1 und D2 bedeuten.
Ich komme gut mit den Grafiken auf der französischen Wiki-Seite zurecht, auch wenn diese etwas altbacken daher kommen.
Nun, jetzt wo wir die Attribute durch insgesamt 3 Iterationen aufgeräumt haben und eure Vorschläge jetzt Richtung alternative Visualisierungen gehen, würde ich gerne mit dieser “PDF”-Version abschließen.
So wie es jetzt ist, als alleinstehendes PDF, war es mein Ziel, wie ich es mir zu Beginn gesetzt hatte. (Falls jemand Interesse an der PDF hat, gebt bescheid.)
Ich bin leider kein Fan von den weißen Trennbalken - zumindest wie ich sie jetzt mal ausprobiert habe beim Design - deswegen würde ich die ungern in das Dokument, wie es jetzt ist, aufnehmen. Da habe ich mir zu viel Freiraum gelassen bei den Übergängen in der Illustration und den Trennlinien bei den Beschreibungen links.
Fürs Wiki werde ich das ganze natürlich weiter entwickeln.
Dafür möchte ich aber gerne eine kleine Umfrage einschieben. Wie stellt ihr euch denn die Illustration für die Tabelle vor?
Fluent Wiki (links) und Block Wiki (rechts, Entwurf)
Fluent Wiki - Illustration mit Übergängen behalten und aufteilen
ästhetisch und abwechslungsreich
Reihenfolge ist fest, (falls nötig) komplizierte Erweiterung
durch die festgelegten Bestandteile ist der Themenumfang für Anfänger gesichert
Block Wiki - Neue Illustrationen im selben Stil mit festen Proportionen und ohne Übergänge
kann beliebig von den Wiki-Bearbeitern angeordnet werden
sieht etwas repetitiv aus, kann/muss vielleicht mit einzelnen Straßenmöbeln aufgehübscht werden
kommt dann dem Bicycle Wiki auf Englisch nahe, allerdings fürchte ich, dass dann mit der Zeit durch Erweiterungen der “Anfänger”-Aspekt vom abgekapselten Guide wieder verloren geht
Mich persönlich hatte das Bicycle Wiki nämlich vom Umfang her abgeschreckt.
Fluent Wiki
Block Wiki
0voters
Natürlich würde ich auch die iD-Darstellung darauf anpassen und separat erstellen, die hab ich jetzt für dieses Beispiel weggelassen.
Auf jeden Fall habe ich keinerlei Erfahrung mit dem Wiki selbst, deswegen würde ich mich da gerne mit einem erfahreneren Editor zusammentun, der das umsetzen wöllte.
Was denkt ihr so?
Mammi71
(One feature, Six mappers and still More ways to map it)
45
Optisch finde ich diese Version viel ansprechender.
Zwei Anmerkungen:
Ich überlege, ob es eventuell Sinn macht, C1 und C2 zu vertauschen und dabei die Gesamt-Wegbreite (jetzt noch) C2 (segregated=no) etwas schmaler zu lassen. Das entspricht meiner Erfahrung nach meist eher der Realität otg. Dafür dann erst beim Übergang von C2 auf C1 (dem vertauschten) insgesamt breiter werden.
D1 würde ich den Radweg und die Baumreihe nach links versetzen (in der Flucht zum vorherigen rot markierten Radweg und erst beim Übergang zu D2 nach rechts verschwenken
PS: die Anmerkungen beziehen sich auch auf die Zusammenhängende Version, nicht nur auf die aufgeteilte.
Wenn du unten den Bordstein-Einrichtungs-Radweg unten als Attribut an der Haupt-Fahrbahn mappst (was ich richtig finde) wäre es konsequent, das auch bei Bordstein-Zweirichtungs-Radweg so zu machen, den hast du mit einer separaten Linie gemappt.
Hallo.
Ich bin aktiver Fahrrad-Mapper in Italien, und habe mich ausgiebig mit dem Thema befasst.
Das mapping der Fahrrad-relevanten Objekte ist kompliziert und das kommt,zumindest im italienischen Kontext, zum großenteils daher, dass die entsprechenden offiziellen Regeln nicht sehr klar formuliert sind, zum Teil auch widersprüchlich, und außerdem noch durch amtliche “Erklärungen” ergänzt werden, von denen man einfach wissen muss, dass sie existieren.
Aus diesem Grund halte ich eine vereinfachte Version fuer Anfaenger fuer unangebracht.
Was wir brauchen ist eine komplette Neubearbeitung der Bicycle:it OSM Wiki Seiten.
Auf diesem Hintergrund einige on-the-fly Kommentare ohne besondere Reihenfolge
Was immer auch hier entsteht, muss einfach in das wiki einbindbar sein - ich halte nichts von einem separaten guide fuer Mapping-Anfaenger.
Das Format muss auch graphisch Wiki-kompatibel sein, insbesondere ist eine elongierte Grafik von vorne herein ungeeignet.
Die grafische Darstellng der OSM Objekte sollte nicht auf einen bestimmten Editor abzielen.
Ich halte die traditionelle Graphik der englischen WIki-Seite fuer besser, aus mehreren Gruenden:
a) Sie ist in kleinere Module unterteilbar (der Seitenumbruch ist einfacher)
b) Sei zeigt die gesamte Strasse mit Buregersteigen und Radstreifen
c) Die Strassenzeichen sind einfach hinzuzufuegen
d) ein Foto ist besser verstaendlich als ein symblische Luftfoto.
f) es ist einfacher alternative Taggings darzustellen.
g) ich kann mich auf den Inhalt konzentrieren, und brauche nicht auf der “Schoenheit” der Gesamtgraphik Ruecksicht zu nehmen.
D1: halte das mixen von extra way fuer Fahradweg mit Fussweg mit dem Fahrbahn-way mappen ungluecklich
C1 - D2: Ich mache keinen Unterschied ob die Abtrennung von der Strasse durch eine Buergersteigkante oder einen Streifen Land mit Bauemen erfolgt. Ich habe das (englische) wiki immer so interpretiert, dass D2 und C1 aequivalent sind, und dass D2 die bevorzugte - weil detailliertere - Methode ist.
B1: ist zulaessig, aber die bevorzugte Methode ist ein getrennter way fuer den Radweg.
A1: ist zulaessig, aber die bevorzugte Methode ist ein getrennter highway=footway mit bicycle=yes
Z1: Gibt es Einbahnstrassen mit Fahrradverkehr in Gegenrichtung, ohne dass dies mit vertikaler Beschilderung angezeigt werde muss?
Das mappen von Radinfrastruktur ist länderspezifisch. Der Guide trifft die deutschen Regeln aus meiner Sicht schon ganz gut.
Ich habe nichts gegen alternative Darstellungen und Darstellungen für Anfänger. Die beste Darstellung für das Wiki wäre es aus auch meiner Sicht nicht.
Die Unterscheidung zwischen nur Bordstein und echter Trennung z.B. durch Baumreihe ist in OSM gängig. Es ist eine Empfehlung, wann man getrennt erfasst - aber es gibt auch gute Gründe davon in einigen Fällen abzuweichen…
Hallo ihr, ich war ein bisschen stumm, weil ich ein wenig in einer Zwickmühle stecke.
Zuallererst die Ergebnisse aus der Umfrage. 50:50 ist eine schwierige Grundlage, um zu entscheiden, was Besucher der Wiki-Seiten tatsächlich bevorzugen. Insbesondere weil ich nicht einfach in ner Hals über Kopf-Aktion etwaige geliebte Tabellen durcheinander bringen will.
Ich denke, falls wir die Fluent Wiki Variante machen, sollte dafür eine neue Wiki-Seite her.
Und ich denke, falls wir auf bestehende Tabellen aufbauen wollen, sollten wir dafür die Block Wiki Variante nehmen.
Aber vielleicht ist der Guide auch an sich gar nicht fürs Wiki geeignet.
Danke für die Anregung, aber das ganze hatte ich vorher schon einmal probiert. Wenn ich die Abschnitte vertausche müssen zwei neue Schilder her, der rote Streifen geht und kommt, das sieht alles ein bisschen ungewollt aus.
Ich denke das beides probier ich nochmal in einer Kombination aus.
Danke @voschix für deinen Beitrag. Ich denke - ohne viel auf deine einzelnen Vorschläge einzugehen - stellt sich halt im Gesamtbild die Frage: Hat der grafisch intensivere Stil überhaupt eine Daseinsberechtigung im Wiki abseits vom Anfänger-Milieu?
Letztendlich hab ich den Guide überhaupt erst begonnen, um selbst etwas dazuzulernen. Mein Gedanke dabei lag nun mal bei “ja wenn diese Darstellung außerordentlichen Zuspruch erhält, könnte man ja was ins Wiki übernehmen” und nicht bei “ich halte diese Darstellung prinzipiell fürs Wiki besser geeignet und ich werde alles dafür tun um so viele Mitglieder wie möglich davon zu überzeugen”.
Wenn sich sowas in die Richtung mal anbietet, wisst ihr ja wo ihr mich findet und was dabei grafisch rauskommen könnte.
Ich will gar nicht zu viel versprechen, aber ich überlege zur Zeit eine Website zu entwickeln, die an Streetmix angelehnt ist, den hier entstandenen Stil verwendet, aber dann für den zusammengestellten Straßenabschnitt die OSM Attribute anzeigt.
Vielleicht wird es so sandbox-artig oder ein Tutorial oder ein Lernspiel, wer weiß.
Dann solltest du das in Italia (Italy) - OpenStreetMap Community Forum diskutieren. Das Tagging kann sich von Land zu Land deutlich unterscheiden, was auch an den jeweiligen rechtlichen Gegebenheiten liegt. Hier im Thema geht es ausschließlich um die Situation in Deutschland.
Mir ist natürlich klar, dass das bicycle tagging länderspezifische Komponenten enthält. Ich habe nur darauf hinweisen wollen, dass es Aspekte gibt, die in beiden Laendern gelten.
Die Darstellungsweise ist einer, der Ansatz, ein vereinfachtes Tagging fuer Anfaenger zu schaffen, oder nicht, ist ein anderer.
Außerdem sind mir auf Anhieb Tagging-Unterschiede aufgefallen, die eigentlich nicht existieren sollten.
Länderspezifische Tagging-Unterschiede sollten nur bestehen fuer Objekte, die in verschiedenen Ländern tatsächlich verschieden sind; Objekte, die gleich sind, sollten möglichst auch gleich getaggt werden.
Dafür gibt es mindestens zwei Gründe:
(1) um den Leuten die Router herstellen das Leben nicht unnötig schwierig zu machen
(2) um die Anzahl der Fehler niedrig zu halten, die entstehen, wenn durchreisende Fahrrad-Touristen mappen (Davon haben wir hier erstaunlich viele. Und wir sind dankbar fuer ihre Beitraege )
Leider wird in meiner Region Dein gelungenes Projekt mißbraucht, um die, jeder baulichen und gesetzlichen Vorschrift und Nutzbarkeit widersprechenden Eigenschaften der gepflasterten 40-60 cm breiten Holperpisten mit Sturzkante, aus der Mottenkiste der 1970er Jahre, zum Status “Radweg” zu verhelfen. Könntest Du in Deinem Wiki noch einmal klarstellen, was gemäß den geltenden Gesetzen als Radweg zu kennzeichnen ist und was nicht.
Vielen Dank für Deine Mühe!
? Aber das sind doch auch weiterhin Radwege - meint: Du DARFST dort fahren.
Das bleiben sie auch solange, solange da nicht explizit ein Schild a la “Fußweg” steht.
Sie sind i.d.R. eben nicht mehr benutzungspflichtig. Du MUßT dort nicht fahren. (wenn sie das sind - d.h. wenn da ein blauer Loli steht - dann solltest Du dich bei der Gemeinde beschweren.)
Aber wie gesagt: es bleiben Radwege, auf denen z.b. Fußgänger nichts verloren haben!
Oh - mir ist eben erst aufgefallen, daß das Dein erster Post hier ist. Herzlich willkommen im Forum! und: schön, daß Du dich an der Karte und an der Diskussion beteiligst.
Da Problem mit den Radwegen ist, daß es eben nicht so einfach ist…
Die Karte bildet ab, wie es ist - nicht wie es sein sollte.
Und oft widersprechen die Dinge vor Ort (Beschilderung, Zustand der Wege) den gesetzlichen Bestimmungen. Für die Einhaltung dieser Bestimmungen ist aber leider nicht OSM zuständig.
Das Problem ist, wenn width und surface Eigenschaften weggelassen werden (was sehr häufig passiert). Dann haben Router keine Möglichkeit diese Wege von 2 Meter breiten richtigen Radwegen zu unterscheiden. Und selbst wenn sie Eigenschaften gesetzt werden wird das von den üblichen Renderern auch nicht ausgewertet so das die Unterscheidung in der Kartendarstellung fehlt. Ein highway=foortway mit bicycle=yes bildet da die Realität deutlich besser ab als ein highway=cycleway.
Tut es nicht, weil auf dem Fußweg mit Radverkehr frei darf man eben nur Schrittgeschwindigkeit fahren - auf alten Radwegen ohne Schild darfst du wie auf allen Radwegen auch schneller fahren, solange du keine Fußgänger gefährdest.
Und fehlende Tags gibt es auch überall nicht nur bei den nicht-benutzungspflichtigen Radwegen. Gerade neben Landesstraßen finden sich gerne auch benutzungspflichtige Radweg die eigentlich nicht mehr befahrbar sind. Die saubere Lösung ist, die width und smoothness Tags nachtragen.
Genau das ist bei den Wegen die hier das Thema sind ja gerade nicht gegeben. Da kann man selten schneller als 10 km/h fahren ohne sich selbst oder andere zu gefährden.
highway=footway mit bicycle=yes immer als Schrittgeschwindigkeit zu interpretieren ist ja auch nicht korrekt, da es bei für Fahrräder freigegeben Wege in Parks oder ähnlichem nicht gilt.
Wobei sie dann ja nicht mehr benutzungspflichtig sind. Das Schild mag noch stehen hat aber keine Rechtswirkung mehr. Wir taggen halt nach dem Schild und packen im Zweifel wrong_sign oder etwas ähnliches dazu.
Das lässt sich dann halbwegs gut aus width, surface und meinetwegen auch smoothness ableiten, führt aber nicht dazu, dass ein Radweg in OSM zum Fußweg degradiert werden sollte.
Und deswegen bin ich ein Verfechter von explizitem maxspeed:bicycle=walk an diesen Wegen Expizit ist immer gut.
Aber trotzdem ist die Situation in einem Park nicht immer vergleichbar, denn dort sind ganz oft gar keine Schilder, keine StVo-konformen Schilder, oder eine Grünflächenregelung, oder, oder, oder. Im Grunde läuft es darauf hinaus, dass wir in der Regel jeden echten, also ausgeschilderten, Gehweg (Zeichen 239) mit highway=footway erfassen. Daraus ergeben sich in Deutschland einige verkehrsrechtliche Besonderheiten wie: EKFs dürfen dort nicht fahren und falls Fahrradverkehr erlaubt ist, hat dieser Schritt zu fahren. Dass ist eine Besonderheit in Deutschland (beim Taggen) und eigentlich hält sich die Mehrheit daran, auch wenn ein highway=footway eigentlich identisch ist mit highway=path + access=no + foot=designated. Aber die Diskussion wollen wir bitte nicht noch mal führen, da gibt’s genug Threas…
O.k ich hab mich falsch ausgedrückt. Nur noch langsam befahrbar. Und dann darfst du Benutzungspflicht nicht ignorieren
Wenn ich deine Idee richtig interpretiere, soll der Mapper nach eigenen Empfinden entscheiden ob ein Radweg gut genug befahrbar ist und ihn entsprechend danach als Rad- oder Fußweg eintragen damit er dann blau oder rot in der Karte erscheint?
Ich würde doch dazu raten die objektiven Kriterien zu erfassen
Verkehrsschild,
Surface
und zumindest wenn besonders gut oder schlecht smoothness und width
wenn der Radweg undeutlich ist dann kann auch ein source:bicycle die Erklärung liefern, woran man erkannt hat, das da überhaupt Radfahrer fahren dürfen.
