Strassen als Fläche

Ich befinde mich gedanklich beim Fahren immer am “Momentan”-Punkt und fahre eine Linie (die im Grunde der Breite meines Autos entspricht). An ungewöhnlichen Kreuzungen mit mehreren Möglichkeiten kann man Linien, die sich zudem an einem zentralen Punkt treffen, schnell abzählen. Wenn die Kreuzung samt Straßen als Fläche dargestellt werden, überblickt man das nicht mehr, insbesondere wenn der automatische Zoom greift.

Zur “weiteren Dimension”…
Schnelle Punkt-Linien-Auffassung: “Man befindet sich hier und muss da lang.”
Weitere Dimension: “Wo auf der Fläche befindet man sich und wie muss man die Fläche durchqueren um dahin zu kommen.”

Ich glaube, wenn die Anzeige zu exakt an der Realität ist, ist man zuviel mit (unbewussten) Vergleichen beschäftigt - ein Abkoppeln der reinen Navigations-Informationen wird schwerer.

Möglich. Spontan würde ich sagen Ansicht A ist besser - aber du hast schon auch recht, denn wenn ich mir jetzt noch die Radwege, die Fußwege und und und als Flächen vorstelle, wird es wieder schwieriger.

Nun, ich muss euch Recht geben. Wenn das Umfeld einer Karte 2-D ist, hat das Gehirn Schwierigkeiten, annähernd “gewohnte” Ansichten mit der 2D Umgebung zu vermischen und muss eindeutig mehr Aufwand (Denkarbeit) leisten, um das sinnvoll umzusetzen. Im allgemeinen lehnt der Mensch jede übermäßige Anstrengung des Gehirns ab ( “Ist mir viel zu anstrengend, auf das Navi zu schauen…; Da bekommt man ja Kopfschmerzen…; etc…”).
Wichtig wäre, eine Verbindung des a:h tagging mit einer 3D OSM Welt hinzubekommen, was ja noch etwas ‘Zukunftmusik’ ist, aber keineswegs unrealistisch. Stellt euch mal die F4 Map mit den a:h gerenderten Straßen vor. Hier ein kleines Video, wo das Gehirn gar nicht viel tun braucht, weil alles so leicht umsetzbar ist.

Hi all,

Sorry to write this in English, but it will take me to much effort to do this in German. As there is much discussion in this thread about the usefulness and possibility of area:highway=x rendering, I thought I would share some of the latest development work on my ArcGIS Renderer for OpenStreetMap (not yet publicly available).

It shows two example areas of the city of Szczecin, Poland, located near the Poland/Germany border, and for the second image with the large flyovers an extra Google Maps comparison.

The rendering shows area:highway features tagged and rendered with surface=x, which means the rendering will show differentiation based on surface, e.g. “asphalt” or “sett”. Unfortunately, since most of the area:highway features tagged and digitized in this area are main roads consisting of asphalt, you won’t see much differentiation, except the small areas forming the “Mazurska” residential road in the lower right part of the first image. Besides rendering of area:highway features, you can also see the renderer fully resolving man_made=bridge as areas based on the layer=x tag in the second image of the large road junction near the Oder / Odra river. Based on test-renderings of the area, I discovered issues with the layer=x tagging of the road lines and road areas and bridges at this large junction, and actually went in to correct this using JOSM, allowing you to see the this correctly resolved.

The rendering of area:highway only kicks in at high zoom and large scale, before that, you just see the normal road classification. I have chosen to display surface over road classification, as I think it adds something new at large scales (>1:2500), and at these large scales and highly zoomed in, road classification starts to become less important. Thus, showing surface is really nice I think.

There is one exception to the surface=x based rendering: area:highway features tagged as area:highway=cycleway are rendered as an overlay layer together with “emergency” road markings in a flat muted red color. This is because I think clearly showing them as cycleways is far more important than knowing the actual surface. Most of the area:highway=cycleway features added as areas, will be in cities anyway, and paved by default in some way, so “surface” is less important than the fact that you can actually easily spot them on the map by their reddish color.

Anyway, I noticed a lot of area:highway features currently lack a surface=x. I know there has been written about the possibility of automatically deriving this information from the corresponding line element, but frankly, knowing this would entail global scale geoprocessing operations on millions upon millions of features, I think this is unrealistic, and then I am not even considering the problems with way and area features not exactly matching at end points / nodes.

I therefore would like to encourage everybody to at least, as a minimum, to additionally add surface=x to area:highway features.

Marco Boeringa
The Netherlands
ArcGIS OpenStreetMap Area:Highway rendering example 1

ArcGIS OpenStreetMap Area:Highway rendering example 2

Szczecin

Wow, good job Marco.
I will try to add the surface indormation in Szczecin together with mapper d3mol3k.

It is true that copying some tags to the areas would help with some less complex use cases. However, this is not a panacea, as some information cannot be simply copied (in particular, anything way direction dependent). So we have to take care to make sure that ways and areas can be matched.

The proposal does currently enable this, so this is not meant as a criticism. I simply wanted to point out that these operations are not “unrealistic”, but actually necessary – at least for some use cases, including accurate lane rendering.

Hi Tordanik,

Yes, I actually fully concur with your observations. In fact, to enable the proper rendering of the traffic junction with flyovers in Szczecin example, I did just that: I made sure ways and areas matched by fixing “over-” or “undershoots” (not exactly the right term here), and connecting up through common nodes, and fixing layer tagging as well. One extra thing I encountered, and that extents upon what is already documented: it would be desirable to also closely match up man_made=bridge features with area:highway=x and highway=x features, as otherwise the layered rendering of bridges may interfere with the display of area:highway or highway features (or the other way around depending on how you look at it…).

That said, my main concern was and is that it is probably difficult or impractical, even in a perfect situation, to fully automatically derive area attributes from ways based on common nodes or overlapping geometry topology.

Adding surface=x, as you also point out as being a “less complex use case”, solves the main dilemma’s. Actually, I think with surface, we have the main tag useful for area rendering anyway. There is not much sense in adding attributes like speed, access restrictions directly to an area, since the most common and accepted visualizations for these type of attributes is line. This is different for surface=x, as traditionally large scale maps, e.g. in the form of GIS or CAD files, typically list and show surface as the main attribute of areas of roads.

As argued above, I agree it would be desirable to properly follow the tagging guide lines as described at the area:highway pages, especially the “Mapping guidelines”:

http://wiki.openstreetmap.org/wiki/Proposed_features/area_highway/mapping_guidelines
http://wiki.openstreetmap.org/wiki/Proposed_features/Street_area
http://wiki.openstreetmap.org/wiki/Proposed_features/area:highway

Weder surface noch den Straßentyp sollte man an der Fläche angeben. Dies sind redundante Informationen, die nur zu Unstimmigkeiten führen. Der Renderer kann diese Information dem Weg entnehmen, wenn korrekt gemappt wurde. Wenn unvollständig gerendert wird, falls falsch gemappt wurde, hilft dies, die Qualität zu erhöhen.
Wenn man area:highway=residential bis area:highway=motorway durch area:highway=carriageway ersetzt,
Die bisher verwendeten Werte mögen für anfänglichge Renderingexperimente sehr hilfreich gewesen sein, jedoch halte ich sie als dauerhafte Lösung für strukturell unpassend.
Es wäre im Editor viel einfacher zu handhaben, wenn man nur einen Fahrbahnfläche hätte. Es ist nur ein Preset erforderlich und es erscheint kaum möglich, verschiedene Fahrbahnflächentypen je nach Straßentyp im Editor sinnvoll zu rendern, was die Eingabe fehleranfälliger machen würde.

Eine Ausnahme sehe ich allerdings. Es wäre durchaus sinnvoll, surface für Teilflächen definieren zu können. Beispiele:

  • eine Asphaltstraße, die in Straßenmitte wegen einer Straßenbahn Plastersteine hat

  • ein betonierter Bushaltestellenbereich

  • eine alte Straße mit Sommerweg

  • Gepflasterte Kreuzungsbereiche

In der Regel werden dies aber zusätzliche überlagerte Flächen sein müssen. Ich denke, diese fehlen noch im Proposal. In manchen Fällen mag auch mal die Junction-Fläche dazu geeignet sein.

Zwischendurch haben wir 63000 area:highway Elemente in OSM.

Es wäre vielleicht an der Zeit über Rendering dieser Elemente in Mapnik nachzudenken.

Oder?

Meine Meinung: bitte nicht!
Die Lesbarkeit der Kartendarstellung ist in meinen Augen schlechter. Ich halte es für eine Spezialdarstellung im Lageplandesign.

Dies soll sich auf die höchste Zoomstufe beschränken und ist in meinen Augen besser.

Vergleiche:
http://wiki.openstreetmap.org/w/images/c/c7/F3DBbridgeOldApproach.JPG

mit
http://wiki.openstreetmap.org/w/images/2/29/F3DBbridgeTopViev.JPG
(allerdings ohne Namen rendern an den Kanten).

Dieser Vorschlag wurde bereits realisiert. Wir rendern schon man_made=bridge in der Karte.

Der Rest wäre nur eine logische Fortsetzung.

Schon, sieht aber nicht schön aus. Objekte auf der Brücke (in diesem Fall die Gleise), sollten auch AUF der Fläche zu sehen sein und nicht von ihr fast überdeckt.

Hier sieht es besser aus: http://www.openstreetmap.org/#map=19/51.38318/7.40484&layers=N. Gefällt mir aber auch noch nicht so richtig, weil die Brückpfeiler die Brücke ja nicht unterbrechen, sondern diese auf den Pfeilern aufliegt.

In Mapnik ist aber auch man_made=brigde (schöner): http://www.openstreetmap.org/#map=18/50.94151/6.96614

Du siehst in der obigen Skizze ein Mockup von dem Proposal.
Umgesetzt wurde dies so, wie Du schreibst.
Sehe z.B.: http://www.openstreetmap.org/#map=19/52.51878/13.40224

In ZL 19 und meinetwegen auch 18 fände ich es praktisch. Wer so weit reinzoomt, will keine Übersicht haben, sondern Details, und dann sollte das Rendering auch die exakten Straßenränder hergeben, wenn die Datenbank sie hat.

Unterhalb stört es niemanden, wenn die Straßen Linien fixer Breite bleiben. Ich finde sie in Mapnik generell zu breit seit dem letzten Update. Dicht benachbarte, unverbundene Straßen wie die hier (die B 14 / B 19 bleibt unten, die K 2573 steigt nach Süden stark an) verschmelzen mir in kleineren Darstellungen schon zu leicht.

–ks

+1.

Ich habe eine Skizze gemacht, wie die a:h in jetzigem level 19 aussehen könnte:

http://wiki.openstreetmap.org/wiki/File:MockupAreaHighwayWithStreetMidlines.jpg

Waren nicht schon einmal die lanes:* im Zoom 19?

Ja, schon. Nur denke ich, sollen wir erst Mal überhaupt eine Fläche zeichnen.
Es ist kein Hexenwerk.

Ich hab da ein Farbvorschlag gemacht: https://github.com/gravitystorm/openstreetmap-carto/issues/180#issuecomment-246173053

Wenn es so in Z19 angezeigt wird, ist es erträglich.
Persönlich würde ich eine helleres Grau bevorzugen und die linienförmigen Straßen/Informationen auf der Fläche, zwecks besserer Lesbarkeit, darstellen.
Dann hat die Straßenfläche was von Landuse/Landcover.

Etwa so: http://wiki.openstreetmap.org/wiki/File:MockupAreaHighwayWithStreetMidlinesBright.jpg ?