Ich habe heute die Fußgängerzone in Riedlingen (Württ.) mit area:highway=pedestrian neu eingezeichnet. Leider werden die Seitenstraßen noch bis zur “Centerline” angezeigt. Diese sollten beim Beginn der area:highway ausgeblendet werden.
Gruß
Peter
Hallo Peter,
Centerline und area:highway im obigen Kontext gibt es nur bei Straßen, bei denen zusätzlich die Fahrbahnfläche gemappt ist.
Für Fußgängerzonen gilt: Entweder als Weg (Häuserschlucht) oder als Fläche (Platz). Die zuführenden Straßen werden dann an den Rand der Fläche angebunden. Für unterschiedliche Eigenschaften (z.B. bicycle=yes) müssten verschiedene Flächen verwendet werden. Der Renderer möchte auch nicht unterscheiden, ob ein Weg über eine Fläche verläuft, meist ist das ja so gewollt. Ausblenden macht demnach nur bei Weg und Fläche gleichen Typs Sinn, deswegen die etwas eigenartige Anzeige. Die Mittellinie ist also nicht nötig und die Zugangsstraßen müssten gekürzt und mit dem Rand verbunden werden, man darf ja auf den Zufahrten nicht bis auf die Mitte der Fußgängerzone fahren. Die (Nicht-)Befahrbarkeit regeln auch access-Rechte an der Fläche (Fahrrad, Lieferverkehr etc.).
Gruß
Mario
Wenn ich die Fußgängerzone als Fläche darstellen will, muß ich also area:highway=pedestrian durch highway=pedestrian + area=yes + name=* ersetzen, die “Centerline” löschen und die Seitenstraßen an die “Fläche” anschließen ?
Gruß
Peter
Ganz genau.
Ach so, zwei Flächen braucht man nicht, Fahrrad ist wohl für den gesamten Bereich zugelassen. Also bicycle=yes sollte noch an die Fläche.
Ach doch: Die “Straßen”-namen unterscheiden sich, sind sogar 4 Segmente…
Edit: Buchstabendreher
Also das Problem hatten wir schon einmal hier: Hauptstraße Dresden Neustadt
Ein Routing ohne verbindende highway=pedestrian funktioniert nicht - nur durch eine “Centerlinie” kann es funktionieren.
Die Problematik über eine Fläche zu routen, hatten wir schon - funktioniert mit Aufwand sicher schon, ist aber für jetziges routen nicht angebracht. Ich befürworte deshalb auch das “Flächen mit Centerlinie” - egal ob pedestrian oder residential mit entsprechenden access.
Dann brauchen die Renderer aber eine weitere Eigenschaft für die Durchgangslinien (Mittellinie und Anschlüsse an Seitenwege), die diese bei Bedarf unsichtbar machen lässt. Zudem muss auch über den Flächenrand erkennbar sein, dass eine Mittellinie existiert, so dass man auf das Routing am Rand entlang verzichten kann. Ohne diese weiteren Infos ist die Mittellinie sichtbar und Routing-Programme zaubern weiterhin einen routingfähigen Rand hinzu. Beides ist doof für die jeweilige Anwendung.
Es braucht klare Richtlinien, zuverlässige Zusammenhänge, keinen Alleingang und lückenlose Information. OSM wird sonst immer mehr zu einem Pool an vermischten Daten, von denen einfache kaum noch allgemeingültig ausgewertet (area für Plätze und Straßenflächen) und komplexe nicht mehr logisch verknüpfbar (cycleway=lane & bicycle=use_sidepath) werden können.
Die darunterliegenden ways sind überschrieben - und warum nicht am Rand routen, wenn es passt? (Also ich gehe zur Zeit nur von pedestrian aus)
Das funktioniert gut, weil Mapnik für rein visuelle Auswertung bestimmt ist, macht das aber nicht ohne Grund nur bei gleichem highway. Routingprogramme sind aber auf Linien angewiesen und tasten Linien nicht an ohne Wissen, dass sie ein Behelf sind (und: bei der Verarbeitung hat ein Element keine Kenntnis vom Vorhandensein eines anderen, welches ersetzbar wäre - also die Linie in der Fläche oder die Fläche, durch welche die Linie verläuft). Zudem werden (zumindest bei Garmin) Linien grundsätzlich über Flächen dargestellt und nicht verdeckt. Unterbrechungen in Wegen sind ja auch bei der Planung von Touren nicht sinnvoll.
Zusätzlich am Rand zu routen ist nicht weiter wild. Die sichtbare Mittellinie ist da eher ein kosmetisches Problem. Aber unsichtbar machen kann man diese aber so nicht - das gilt dann ja auch für alle Fußgängerzonen, die nur als Weg ohne Fläche eingetragen sind, z.B. ehemalige Straßen.
agricultural ist kein “Fahrzeugtyp” wie motorcar/bicycle/hgv/foot. Stattdessen gehört access=agricultural dran, was alle ausschließt außer landwirtschaftlichen Verkehr. Den Fehler würde man aber nicht bemerken, da kein Navi den Modus “Landwirtschaft” kennt.
Dran gehört:
access=agricultural
foot=yes
Weg kann dann:
vehicle=no
Entgegen der Meinung von http://osmtools.de/traffic_signs/?signs=250,1024-17
Ich würde mich da ans Wiki halten, das kennt agricultural=* nicht, ist aber bindend und breiter bekannt. Zusatztools können auch Fehler haben.
Alles ist wohl richtig. Mein Wiki (deutsch und englisch) kennt agricultural=yes:
Was das Navi kann, ist dabei uninteressant.
Ich würde es mir einfach machen:
vehicle=agricultural
Grüße Klaus
Bitte den Unterschied zwischen Z.1024-17 und Z.1026-36 beachten. Im Zweifel einfach das oben genannten Vehrkehrszeichentool befragen, das kennt die Regeln besser als 99% aller Mapper.
@PrinceKassad: Ist das “deine” Gegend?
Heißen die Wege hier wirklich “NN” und “Fußgänger und Fahrradweg” ?
https://www.openstreetmap.org/#map=18/50.16699/8.96884
Da bin ich einmal zufällig vorbeigegangen. Das ist offensichtlich ein Zufahrtsweg für die Bauarbeiten am Fliegerhorst. Die Namen sind natürlich Quatsch, ein Fußgänger- und Fahrradweg ist das auch nicht, der Weg ist mit Absperrbake und Z. 250 gesperrt.
Und? Bleibt das jetzt so?
Offensichtlich, macht ja keiner.
Ich war/bin dabei das Chaos in Flörsheim aufzuräumen. Schulen, die als amenity=college getaggt sind, doppelte Hausnummern neben POIs, nur damit die auch schön auf der Karte erscheinen, Müll im Namen (highway=bus stop, name=Bushaltestelle - das ist mir auch noch nicht untergekommen…) und noch viel mehr…
Übrigens scheint Frankfurt auch einen neuen Stadtteil bekommen zu haben: Frankfurt-Weilbach…
Hallo,
wie kann man denn die “Remote-Control-Option” aktivieren, da wenn ich von der OSM-Startseite direkt auf JOSM zugreifen möchte diese Nachricht kommt:
PS: JOSM ist bereits gestartet.
http://wiki.openstreetmap.org/wiki/DE:JOSM/Plugins/RemoteControl
“im Menü “Bearbeiten”, Punkt “Einstellungen”, das Icon mit der “Fernsteuerung” (9. Icon von oben), bei “Fernsteuerung aktivieren” den Haken setzen.”
Hallo,
ich suche einen neuen material-tag. Und zwar für dieses Edelstahl-Drahtgeflecht:
Wichtig ist die Durchsichtbarkeit. Subjektiv gesehen gehen 30% Bildinformation verloren ( natürlich abhängig von der Nähe ).
Da das Material auf einer Aussichtsplattform mit mehreren Ebenen montiert ist und dieses schon in 3D getaggt, lohnt sich hier vielleicht diese Mühe.
Mein Vorschlag: material=mesh_wire oder wire_mesh ?
z.Z. als building:material=metal getaggt ( absolut undurchsichtig ).
http://www.openstreetmap.org/#map=19/50.85013/6.36711
Nochmal Detailansicht:
Als der jenige der die 3D infos da verbrochen hat melde ich mich mal. Was spricht gegen:
building:opacity=30%
roof:opacity=30%
Muss man halt definieren, dass dieses Tag nur eine Wand und nicht zwei Wände (durchgucken) beschreibt.
Eindeutiger ist vielleicht
building:material:opacity=30%
roof:material:opacity=30%