Diese Straße ist zwar Fußgängerzone, aber keine Fläche. Also korrekt mit highway=pedestrian, aber ohne area=yes getaggt. Hier dürfte area:highway benutzt werden, um die “Straßen”-Fläche darzustellen.
Das weiter oben zitierte “Note: don´t use area:highway = pedestrian because of already existing rendering of highway = pedestrian as area.” trifft dort nicht zu, denn das ist kein highway=pedestrian als Fläche.
Unlogisch ist jetzt einerseits der Vergleich von area:highway=pedestrian + area=yes mit motorway und andererseits das Vorzeigen einer Fußgängerzone ohne area. Das zeigt doch, dass die Problematik noch nicht ganz klar ist.
Das Problem ist die Trennung von Straßenflächen und begeh-/befahrbaren Plätzen. Was die Router mit highway=* und area=yes nicht hinbekommen haben, bekommen sie auch mit area:highway=* nicht hin. Routing wird weiterhin nur auf Linien geschehen. Bei Plätzen könnte ein Renderer für’s Routing virtuelle Linien errechnen, eben weil Linien notwendig sind. Wie aber soll der Renderer bei Flächen z.B. die Richtung einer Einbahnstraße bestimmen, wenn deren Rand einen geschlossenen (langgezogenen) “Kreis” darstellt? Oder was ist mit Barrieren, die dann einfach umfahren werden können, obwohl man in echt nicht vorbei käme?
Ich denke, wenn OSM gut und weiterhin interessant sein will, sollte es sich an die üblichen Elemente und deren Vervollständigung/Pflege halten. Besseres Aussehen z.B. durch Straßenflächen kann ein Goody sein, was OSM von kommerziellen Kartenherstellern abhebt. Das sollte aber nicht andere Anwendungsmöglichkeiten (Routing) stören.
Garmin-Users Argumente passen schon: Abgesehen vom Aufwand, alle Flächen zu prüfen, ob sie eher ein “Platz” oder ein “Streifen” sind, wäre es schon hilfreich, Flächen mit Verkehr in beliebiger Richtung von Flächen mit gerichtetem Verkehr zu unterscheiden. Da es die beliebigen Richtungen eigentlich nur bei Fussgängerzonen gibt, spielt highway=pedestrian tatsächlich eine besondere Rolle.
Im Prinzip ist doch nur die Begründung falsch, warum a:h=pedestrian nicht genutzt werden sollte. Sollte doch eher sein “Note: Don’t use area:highway=* for plazas and similiar features. These are desribed by highway=* combined with area=yes. Use area:highway only to add an area representation for linear highways where a way tagged highway=* without area=yes exists. This applies mostly but not exclusively to highway=pedestrian.” Oder so.
Und, was denkt Ihr über Ersetzung “This applies mostly but not exclusively to highway=pedestrian” durch “This applies mostly but not exclusively to highway=pedestrian and highway=footway”?
Ich weiß nicht, footway hab ich jetzt noch nicht so oft als Fläche gesehen. Aber wenn du das für sinnvoll hältst, pass es an - dafür ist es ja ein Wiki
Der Autor des Proposals ist damit voll einverstanden, weil er momentan krank ist und außerdem keiner, der es besser weiß als die Anderen Mapper. Es ist unser gemeinsames Werk.
Ist schon richtig. Eine Fläche, die keine Line hat ( imho quasi nur pedestrian + area ) sollte für sich stehen bleiben. Wichtig wäre dann, das diese Fläche trotzdem vom Renderer der area:highway Flächen mit berücksichtigt wird ( als Fußgängerbereich ). Im Moment werden auch Flächen mit highway=footway und highway=path von der Mapnik gerendert. Hier ist i.d.R. eine Line des footways durch die Fläche getaggt. Jetzt ist die Frage, wie geht man damit um? Es geht z.B. um befestigte Flächen (Plätze) innerhalb eines Parks. Die Fläche highway=footway(path) wäre dann kongruent der Fläche area:highway=footway(path). Natürlich genauso wie die Fußgängerzonen. Hier sehe ich noch Klärungsbedarf.
Eigentlich wäre das kein Problem (für’s Renderering und für’s Routing), wenn hier die Fläche doppelt getaggt ist. Aber natürlich absolut nicht gerne gesehen und unschön.
Wie gesagt, vielleicht berücksichtigt der area:highway Renderer alle solche Flächen, auch wenn diese nicht mit a:h getaggt sind. Über Oberflächenrendering reden wir noch nicht.
@Marek: Gute Besserung. Obwohl wenig Zeit, vielleicht schaffe ich es in den nächsten Tagen, die deutsche Seite wenigstens etwas aufzuarbeiten ( obwohl für das Proposal nicht gar so wichtig, aber für das Verständnis der deutschen Mapper sehr wohl ). Edit: Sorry, wegen Unpässlichkeiten und Terminen werde ich es leider doch nicht schaffen, obwohl ich es gerne übernommen hätte.
Das ist so ein typisches Beispiel, bei dem highway=(path) + area=yes überhaupt nicht hinpasst. Es handelt sich zwar um “Plätze”, jedoch sind für’s Routing die Fußwege eingezeichnet. Man braucht dann den Rand dieser Flächen nicht für Routing.
Aber man kann diese bei der Kartenerstellung nicht ausschließen - anderenorts führen Wege aus mehreren Richtungen zum Platz ohne zusätzlich eingezeichnete Wege durch den Platz, die Route würde nicht (am Rand) hindurchführen können. Die Regelsätze gelten schließlich allgemein.
Vielleicht sollte wirklich klar geregelt werden:
Variante 1: Alle Ways sind am Effektivsten als Linie zu mappen (effektiv bedeutet: einfach einzutragen, Daten nutzbar, street-areas lassen sich per Luftbild nachtragen)
Abweichungen:
Variante 2: Plätze (Centerline nicht definierbar) ohne zusätzlich eingetragene Wege bekommen highway=* + area=yes
Variante 3: Straßen-/Wegflächen bekommen die Centerline mit highway=* und die Fläche mit area:highway=*
-Plätze mit Beschränkungen (barrier=*) an Ein-/Ausgängen/-fahrten benötigen als Fläche zwingend Variante 3
-bei motorway, trunk, *ary, *_link, junction=roundabout und Einbahnstraßen nur Variante 1 oder Variante 3 anwendbar
-bei highway=turning_circle Variante 2 oder Variante 3 möglich (etwaigen weiterführenden path/footway korrekt anschließen), Variante 1 immer “unschön”
Das ließe sich auf alle übrigen Straßen-/Wegtypen anwenden - dann braucht man auch keine Ausnahmen zu definieren.
