Strassen als Fläche

Vermutlich nie. Das ist kein Proposal, sondern eher eine Sammlung teils sinnvoller und teils unausgereifter Vorschläge.
Der RTC ist durch die vielen inhaltlichen Ergänzungen ohnehin überholt.
Der ältere Vorschlag area:highway wäre dagegen recht einfach zur Abstimmung zu bringen.
Zur Zeit scheint das Interesse an dem Thema aber gering zu sein.

Ekhm,
gerade gestern hatten wir die Zahl 50.000 area:highway überschritten.
1227 Mapper haben zuletzt area:highway gemappt.

http://taginfo.openstreetmap.org/search?q=area%3Ahighway

@marek: Ja, das ist ein tolles Ergebnis. Eigentlich ein Selbstläufertagging. Aber gibt es schon Server für die visuelle Bereitstellung zumindest in Eu?
Ich denke, daran haperts. Leider auch, weil zu wenig Verbesserungen eingereicht werden.
Ich denke, wir sollten Marek unterstützen und uns als DE-Community hier stärker einbringen (Wiki / Server / Verbesserungsvorschläge ).
Im Moment ist es für die Abstimmung noch zu früh.
@marek: Kann der polnische Server nicht noch mehr DE-Bundes-Länder unterstützen? Durch den recht geringen Zugriff sollte das doch eher nicht das Problem sein. Umso eher kommt man dem Ziel näher.

Erg.:

Das ist nicht ok. Das Tagging ist wohl durchdacht. Vielleicht sollte man eine gewisse “Formulierungsstraffung” für das eigentliche Proposal hinbekommen. Aber das hatte ich oben schon erwähnt.

Ich gehöre zu diesen Mappern. “area:highway” ist auch kaum umstritten.
Würde jemand das Proposal von flaimo wieder aktivieren, könnte die Abstimmung in vier Wochen (vermutlich erfolgreich) beendet sein.
Die sonstigen Ideen in deinem Proposal verhindern, dass man darüber abstimmen kann.

Lieber Seawolff,
ist Deine Meinung.
Die Hauptdifferenz zwischen meinem und Flaimo´s Proposal sind nach wie vor Kreuzungsbereiche aufgeteilt in junction = <yes /y_junction/roundabout>.
Dies ist der “Kern der Erfindung”.

Du hast im letzten Jahr vorgeschlagen, wenn ich mich recht entsinne, dass man aus meinem Proposal den Abschnitt: Lane dividers along the street entfernt um die Abstimmung zu vereinfachen.
Das kann man machen, ansonsten gibt es gute Gründe für diese Komplexität.

Lieber Rogehm,
leider hat sich die Situation nicht verändert. Der Marimil, der den Renderer geschrieben hat, ist jederzeit bereit die Software zur Verfügung zu stellen, wenn jemand ein Rendering Server zur Verfügung stellt. Der Server von Marimil ist zu klein dafür.

Viele Grüße an Euch beide!
Marek

Hallo,
jemand hat mich wegen a:h angesprochen. Vielleicht geht es in einigen Wochen mit dem Rendering von area:highway für ganz Deutschland. Mal sehen…

Ich stehe dieser Art des Mappings noch sehr skeptisch gegenüber…

Solche Darstellungsfehler sind hoffentlich noch “Kinderkrankheiten”, oder?

Natürlich. Momentan macht der Renderer von Marimil “nur” das Rendern von area:highway als Fläche. Die gerenderten Flächen werden auf die darunter liegenden Kachel gelegt. Dadurch verschwinden Teile der Beschriftung.

Das Ziel ist aber die a:h in den Hauptrenderer in den Zoomlevel 19 bzw auch 18 einzubauen. Dann verschwinden solche Artefakte.

Zu dem Nutzen von area:highway - Welcher Navi Display wäre für den Fahrer mehr ansprechbar, A oder B ?
Sehe: http://wiki.openstreetmap.org/wiki/File:MarekMockupNaviDisplayWithAreaHighway.jpg

Grüße,
Marek

Marek, da bin ich Oldschool - B!
Vermutlich weil ich immer noch mit einem GPSMAP60 zu Fuß, mit dem Fahrrad, dem Motorrad und dem Auto proma klarkomme :slight_smile:

Diese vorgesetzten pseudo 3D Ansichten kann mein Geodätenkopf schneller aus 2D Informationen herleiten. So denke ich immer noch, was will der Künstler mir alles sagen?
Geneigte ebene Ansichten enthalten nun mal nicht mehr Informationen als orthogonale Ansichten, außer perspektivische Verzerrungen.

Ich bevorzuge auch B

B.

Auf einem Navi-Display würde ich mich für A entscheiden.

Allerdings fehlt in dem Beispiel ja noch das Drum-Herum… also Rad-,Fußwege und Hintergrundflächen. Aber rein vom Prinzip bevorzuge ich eine Ansicht die die Gegebenheiten der Straße so anzeigt wie sie real vorhanden sind. Am Computer, wenn ich Zeit habe - bevorzuge ich die andere Darstellung (als Kartenansicht).

B ist ansprechender.
Beim Navigieren soll die Straßenführung so einfach wie möglich und dadurch mit kurzem Blick schnell erfassbar sein. Flächen sind da unpraktisch, weil das Gehirn mit Verarbeitung einer weiteren Dimension beschäftigt wird.

Wo ist denn da eine weitere Dimension? Die gelbe Straße ist auf dem Display doch auch eine gelbe “Fläche”… Es ist halt einfach nur eine stilisierte Fläche.

Im übrigen sehe ich es genau anders herum - Während ich auf auf einen Blick sehe wie die Straße in Version A verläuft, muss ich bei Version B das stilisierte Bild im Kopf erst wieder aufwendig auf die Realität abbilden. Bei Version A guck ich auf’s Display und sehe das, was ich (aus anderem Blickwinkel) auch in der Realität sehe.

Aber es gibt ja grundsätzlich verschieden arbeitende Gehirne :wink:

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.