Straßen (auch) als Flächen mappen...

Communities Deutschland (Germany)
21

Dieser Kritikpunkt geht ins Leere. Die Linien sind ja niemals nicht zum exakten Nachfahren gedacht, sondern sind Abstraktionen möglicher Fahrtrouten. Jede Linie – nehmen wir mal die von Osten kommende – steht dabei für die gesamte Straße mit sämtlichen Spuren. Der Punkt, an dem die Rechtsabbiegerampe im Datenmodell vom durchgehenden Way abzweigt, ist mitnichten der Punkt, an dem sich der Fahrer von der Straßenmitte wegbewegt, sondern ist der Punkt, an dem die Rechtsabbiegespur (die ja im lanes:=* und turn:lanes=* des von Osten kommenden Ways enthalten ist!) in eine eigene Fahrbahn übergeht. Da muss niemand eine durchgezogene Linie überfahren, denn auf der Rechtsabbiegespur ist er ja schon. Nur muss dieser Punkt zwangsläufig (da auf der Linie liegend, die die gesamte Straße repräsentiert) in der Straßenmitte liegen und nicht am rechten Rand, wo er einklich hingehört. Das in eine tatsächlich abzufahrende Linie „umzurechnen“ wäre Sache eines Routers, was er sogar lagegenau leisten kann, wenn er lanes:=* und width:lanes=* hat.

–ks

22

Hm. Hier kommt man mit dem Anworten ja gar nicht hinterher …

Ich wollte gerade mitteilen, dass ich den Ansatz von slhh in #11, den firstAid in #20 ablehnt, ziemlich richtig finde, weil er genau meiner Denke entspricht. Auf der anderen Seite kann ich die Gedanken von Dir, firstAid, zu großen Teilen nachvollziehen und unterstützen. Das Problem “wie oft messe ich dann” bezüglich der Straßenbreiten sehe ich übrigens genauso wenig wie bei der Frage, wann ich einen neuen Punkt setze, um eine Kurve gut abzubilden: Man macht es einfach so oft, wie es notwendig ist. Bei bestimmten Straßenverläufen ist es häufiger, bei anderen weniger häufig. Das sehe ich als kein Problem an, zumal, wenn man im Editor das gerenderte Ergebnis direkt sehen kann (wie bei Fahrspuren), sich also sukzessive an die ideale Knotenanzahl herantasten kann.

Die Geschichte mit dem Fluss … ja, da könnte man sicher Parallelen ziehen. Allerdings gibt es auch ein paar mehr Straßen als Flüsse … Naja, und ich pendele auch immer im Spannungsfeld zwischen “vielen geometrisch richtigen Daten” und “wenigen komprimierten Daten”, die aber die gleiche Information beinhalten, hin und her. Beides hat Vor- und Nachteile, die leider oft auch geschmacks- oder anwendungsabhängig sind.

Ein gutes Beispiel sind die Fahrspuren. Leider gibt es ja dieses o.g. Dogma mit der baulichen Trennung. Hier würde ich mich so weit aus dem Fenster lehnen und behaupten, dass es eigentlich überholt ist. Es entstand halt zu einem Zeitpunkt, als man es noch zur sauberen Datendarstellung brauchte und gar keine Möglichkeit hatte, so detailier zu mappen wie heute. Ich habe jedenfalls bei Kreuzungen und dergleichen immer wieder Schwierigkeiten damit und würde mir wünschen, dass man – wenn nötig (und nur dann) – von dieser Regel abweichen könnte. Das würde im Zweifel darauf hinauslaufen, dass man jeden Fahrstreifen einer Kreuzun mit einem eigenen Way mappt. Ich sehe vor meinem geistigen Auge, wie manchen die Haare zu Berge stehen :wink: Aber was soll´s – falls es gewichtige Argumente gibt, das Dogma aufrecht zu erhalten, dann bleibt es. Ansonsten muss man gucken, wie man neue Lösungen schafft.

Achso, nur noch ein Punkt zum Beispiel oben (OT): Ampeln machen auch immer Spaß. Wenn man welche setzt wie z.B. die in den Abbiegespuren, dann muss man sie auch so taggen, dass sie nur für den Weg gilt, für den sie eben gilt. Denn sonst bekommt man beim Abbiegen plötzlich eine Ampel vorgesetzt, die gar nicht für einen selbst relevant ist. Zum Beispiel. Habe mir die Daten nicht angeguckt, weiß also nicht, ob es da so oder so ist.

Übrigens … nicht falsch verstehen, aber wir schreiben hier manchmal so locker, flockig von Dingen, die abgestimmt werden müssten und dass man das dann mal in eine Wiki schreibt undso … nur sollten wir im Hinterkopf behalten, dass wir hier nicht der Nabel der OSM-Welt sind und es auch noch andere User gibt auf dieser Welt :wink: DIe Proposal- und Abstimmungsprozesse hatte ich ja schon mal angesprochen letztens.

23

Mit der üblichen Frage: Woher weiß der Router, dass die Fahrspur beliebig gewechselt werden kann? Momentan gehen ja die Router bei parallel unverbunden verlaufenden Ways davon aus, dass das nicht möglich ist – wo heute Fahrspuren einzeln gemappt sind, geht der Router, der seinen Nutzer auf einer Geradeausspur ortet, obwohl rechts abgebogen werden muss, davon aus, dass die Abzweigung verpasst wurde, und wird bereits eine Umleitung suchen. Was wieder den Nutzer verwirrt: Nanu, eben sollte ich noch rechts abbiegen, jetzt auf einmal geradeaus?

Das ließe sich beispielsweise über Fahrbahnrelationen lösen, in denen man die „wechselfähigen“, zu einer Fahrbahn gehörenden Spuren zusammenpackt. Prinzipiell habe ich nichts dagegen, weil Geometrien sich dann viel schöner abbilden lassen und vor allem die furchtbaren turn-Relationen dann nicht mehr gebraucht werden, um Fahrspuren von einem Way zum anderen fortzusetzen.

–ks

24

Ja, Du hast Recht, eine Abkehr von dieser Regel würde eine Menge Arbeit bedeuten, ggf. auch Änderungsaufwand an bestehendem Mapping. Daher glaube ich nicht, dass es von heute auf morgen passiert. Aber man sollte sich Gedanken darüber machen, und das am besten im globalen Rahmen – ist ein bisschen nervig, aber so ist es nun mal.

25

Kleiner Einwurf meinerseits: Aktuell werden Straßen ihrem Typ nach mit einer zoomabhängigen normierten Breite gezeichnet. Ich denke, dass das zunächst sinnvoll ist als Abstraktion, um ein einfaches Ablesen der Karte zu ermöglichen. Im Prinzip machen das alle gedruckten Karten so. Das Problem ist dann wohl hier, dass Abstraktion (Lesbarkeit / Nützlichkeit) und Realität (Sattelitbild / Micromapping) aufeinander treffen, wobei ich die gut ablesbare Abstraktion als höherwertig ansehe als die Reale Straßenbreite. Hierbei spielen für mich die “Lücken” eine Vermittlerrolle zwischen Abstraktion und Realität, was an sich gut ist. Man kann die Lücken/Flächen vielleicht als landuse=highway taggen und das Seitengrün als landuse=meadow/rock/… und die abstrakte Straße dann on-top.

Ich denke die reale Straßenbreite zu rendern ist kein guter Weg, denke ich (zumindest nicht in DE). Das könnte zu Verwechslungen zwischen den Klassen (primary, secondary, …) führen, nur weil eine Gemeinde mehr oder weniger Geld für Asphalt hatte.

Als Zwischenlösung, die sowohl der Abstraktion als auch der Realität dient, könnte man die Anzahl der lanes auswerten und programmatisch die gerenderte Breite normiert anpassen. Das dürfte die Übersicht nicht gefährden.

26

Ja das ist genau die Sichtweise die absolut nicht mit meiner Übereinstimmt.

  1. Eine Linie repräsentiert eine Straße! (sonst würde sie nicht mit dem Atribut “highway” getaggt werden)
  2. Diese Spezielle Linie (Highway) ist in diesem Fall mit dem Tag “Verbindungsweg” getaggt, was bedeutet - eine Straße die einen Verbindungsweg repräsentiert.
  3. Eine Linie (zwischen zwei Punkten) hat immer einen Anfang und eine Ende
  4. Die Punkte repräsentieren somit zwangsläufig den Beginn und das Ende des “Verbindungswegs”

Angenommen deine Sichtweise ist richtig - kann hier aber kein Verbindungsweg beginnen, da die Verbindung von einer durchgezogenen Linie unterbrochen wird und somit nie und nimmer ein Weg repräsentieren kann.

Was wir also in der Datenbank haben, ist etwas anderes als den Weg - du sagst es ja selbst, es ist mitnichten der Punkt an dem man auf die Verbindungsweg wechseln kann. Insofern ist der Kritikpunkt schon berechtigt, da dann nämlich genau die Linie - die mir sagt - wo ich wechseln kann in der Datenbank ja fehlt und stattdessen eine andere Linie die vorgibt - der Verbindungsweg (so heißt die Linie schließlich) zu sein, der aber defacto auf der Hälfte unterbrochen wird (also das Gegenteil einer Verbindung ist).

Und hier die Arbeit auf die Renderer abzustellen ist ehrlich gesagt mehr als fragwürdig - woher soll ein Renderer wissen wo genau eine durchfahrt möglich ist und wo nicht. Die Aufgabe eines Renderers ist ja nicht die OSM-Datenbank zu ergänzen sondern die Daten innerhalb der Datenbank möglichst brauchbar abzubilden!

Zudem: Wenn es so wäre, wie du es sagst, dürften wir die Linie gar nicht mit “Verbindungsweg” taggen, denn der Zweck dieses Wegtyps ist es ja die “Verbindung” zwischen zwei anderen Dingen herzustellen…

Das musst du mir also nochmal genauer erklären, wieso meine Kritik hier ins Leere geht…

27

Noch eine generelle Anmerkung…

Meiner Meinung nach braucht es eigentlich nicht mal zwingend ein Proposal zum Mapping von den von mir gewünschten Flächen. Imho. müssen diese Flächen auch keinen “Highway”-Bezug (was aber vielleicht ganz gut wäre) Aber wir haben ja - rein für die Fläche schon den Tag “Surface” der bisher überwiegend als sekundärer Tag genutzt wird, aber bei dem eine Flächennutzung ja ebenfalls vorgesehen ist.

http://wiki.openstreetmap.org/wiki/Key:surface

Das wäre z.B. auch eine Lösung für den “Übergang”… Und wenn das Flächenddeckend zum Einsatz käme (gewisse Eigendynamik vorausgesetzt) würden die Renderer vieleicht auch irgendwann Surface-Tags rendern

28

Aus der eigentlichen Diskussion halte ich mich hier mal raus - das macht meiner Meinung erst dann wieder Sinn, wenn Alle bereit sind, die vermeintlichen Notwendigkeiten des Renderings nicht in die Diskussion einfließen zu lassen, sondern das Ganze aus der Perspektive des Mappers zu betrachten und wie dieser am effizientesten und robustesten die Realität dokumentieren kann.

Ich möchte aber mit der immer wieder gebrachten urbanen Legende von der Fluss-Analogie aufräumen:

Das ist falsch. Flüsse werden in OSM als ways mit waterway=river erfasst. Alle Attribute des Flusses, Namen und was auch immer noch, gehen an diese ways. Sie sind die Erfassung des Flusses in OSM, ohne diese fehlt der Fluss. Die riverbank-Polygone hingegen erfassen die wasserbedeckte Fläche. Es gibt in OSM keine festen Regeln, ob und wann diese erfasst werden muss. Sie ist folglich optional. Jeder Mapper kann frei entscheiden, wo er diese erfassen möchte und wo nicht. De facto ist es so, dass für Flüsse, die nicht wenigstens etwa 10m breit sind (und das sind mehr als 3/4 aller Fluss-Kilometer der Welt), so dass ihr riverbank-Polygon spätestens ab etwa z16 im Standardstil breiter als die Linienbreite von waterway=river dargestellt wird, nur sehr selten riverbank-Polygone erfasst werden.

Das entscheidendere ist jedoch, dass dies ein Mapper-zentriertes Erfassungs-Konzept ist. Für jeden Karten-Gestalter, der nicht die trivial-Darstellung verwenden möchte (alle Wasser-bezogenen Linien-und Flächen-Elemente in einheitlicher Farbe) ist das Ganze im Grunde ein Albtraum. Es gibt da auch eine Menge Verbesserungs-Potential, insbesondere würde eine verbreitete Erfassung der durchschnittlichen Flussbreite (width=*) den Nutzwert der Daten mit recht wenig Aufwand massiv steigern. Wegen fehlender Verwendung solcher Informationen durch die Datennutzer sind die Mapper hier jedoch nicht sonderlich aktiv.

Also etwas vorsichtig sein mit der Idee ich möchte Straßen wie Flüsse erfassen - wegen die Geister die ich rief und so. Oder möchte irgendwer ernsthaft, dass in allen OSM-Karten Straßen so dargestellt werden wie Flüsse?

29

Hallo, ich hatte ursprünglich eine sehr lange Antwort erfasst… aber vielleicht hast du mich einfach auch nur falsch verstanden, oder ich habe es nicht gut genug ausgedrückt…

Mir ging es bei dem Beispiel um die Coexistenz zwischen der realitätsbezogenen Flächenabbildung und der abstrakteren Ways-Abbildung… Erst beides zusammen ergibt die bestmögliche Abbildung des realen Flusses… Und bei Flüssen ist das halt jedem klar!.. DAS war meine Aussage - nicht, dass ich alle Straßen zu Flüssen machen will. :wink: Flüsse sind nun mal hier das Paradebeispiel, da sie sowohl als Way als auch als Area erfasst sind… Und das friedlich und ergänzend nebeneinander. Aber das Thema will ich jetzt gar nicht ausweiten…

Nur einen kleinen Hinweis:

genau das machst du beim Fluss-Thema aber auch nicht

Und ich finde es nicht mal sonderlich schlimm, wenn man “auch” daran denkt was man später aus den Daten machen kann… Denn ich sehe mich insbesondere auch als Servicedienstleister gegenüber dem Enduser… Wir sind Teil einer Informationskette und wir müssen alle zusammenarbeiten

Mapper->OSM->Renderer/Datendarsteller->Enduser

Bei uns fängt aber alles an…

Ein Überschwemmungsforscher will vielleicht die OSM-Daten mal nutzen um potentielle Überschwemmungsszenarien zu berechnen… dafür braucht er zwingend die Riverbank-Informationen. Eine abstrakte Flusslinie bringt ihm nix, wenn er nicht weiß wie “Scharfkantig” die Begrenzungen sind oder ob das Wasser vielleicht in einer weichen Kurve fließt… Das ist alles Sachen die wir als Datenerfasser gar nicht im Auge haben können - Wenn wir aber Informationen möglichst umfassend erfassen, kann der Überschwemmungsforscher was damit anfangen.

Und bei Straßen ist es nicht anders… Vielleicht interessiert es irgendwann mal ein OpenAICar, wie weit es auf einer Straße nach Rechts ausweichen kann und noch auf Asphaltierter Fläche bleibt - und würde gerne die Erstabschätzung anhand von OSM-Daten vornehmen. Wer von uns weiß schon, was die Zukunft bringt…

edith wollte noch was los werden :slight_smile: :
Ich finde, das viele sich hier immer sehr stark anmaßen zu bestimmen wie die OSM-Daten zu Erfassung zu verwenden zu sind…
Um mal am Flussbeispiel zu bleiben - was genau ist dein Problem damit, wenn irgendwo auf der Welt jemand einen Fluss “nur” als Riverbank erfassen würde? Es tut doch niemandem weh - und es ist besser als wenn der Fluss nicht erfasst wäre… “Du” kannst ja dann gezielt nach solchen Areas suchen und diese um die Ways komplettieren… Ich sehe nicht was in der Vorgehensweise “Falsch” sein sollte. Im Gegenteil - genau das ist meiner Meinung nach der Kern der OSM.

30

An dem Beispiel sollte man beachten, dass es ein “Overlay” zu OSM ist. Gedacht war ja die area:highway-Flächen unter den Way zu rendern:

http://wiki.openstreetmap.org/wiki/File:OSM-area-highway.jpg

Wenn ein Renderer nur waterway=* darstellen will kann er waterway=riverbank für eine Liniendarstellung ausblenden.

Wenn ein Renderer nur highway=* darstellen will kann er area:highway ausblenden.

31

Stimmt. Aber habt ihr schon bemerkt, das OsmAnd die Straßenflächen auch darstellt und tatsächlich unter dem Way? Als reine weiße Strasse.
Aber dann auch die Segmentlinien, was mich etwas stört. Habe jetzt kein Bildbeispiel.

32

Einige Anmerkungen zur Kartendarstellung:
In niedrigen Zoomstufen werden Straßen absichtlich (deutlich) breiter dargestellt als sie in Wirklichkeit sind. An diesem Sachverhalt soll sich auch gar nichts ändern. Somit sind die Straßenflächen erst für die hohen Zoomstufen, so ab Level 17, interessant. Denn hier transportiert die Flächendarstellung mehr Informationen. Wichtig wäre es aber, dass sich beide Darstellungsformen hinsichtlich Straßenfarbe und Straßenbegrenzung ähnlich sehen.

33

Ja, wobei dieses schöne Prinzip ja leider durch die Taggingvariante natural=water + water=river verwässert wurde.

34

Meine Sichtweise ist die: Der Way repräsentiert die Straße in ihrer gesamten Breite. Der Node, an dem die Abbiegerampe abzweigt, repräsentiert die “Höhe”, auf der sich die Fahrbahnen trennen - aber nicht zwischen rechts und links, sondern nur zwischen vorn und hinten. Seine Position gibt den Input für “jetzt rechts abbiegen”. Aber nicht für “von hier aus schräg rüberfahren”. Ich stelle mir das so vor, dass der Rechtsabbiegeway auf der ganzen Breite vom Hauptway abzweigt. Dann müssen keine durchgezogenen Linien überfahren werden.

35

Nein, ich argumentiere hier, dass die Tatsache, dass die Erfassung von Flüssen für die differenzierte Datennutzung ein Albtraum ist, belegt, dass das bei den Flüssen ein Mapper-zentriertes Erfassungs-Konzept ist. Ich beschreibe hier den Ist-Zustand der Gewässer-Erfassung, während Du dich in einem Analogie-Argument zur Begründung deiner Ideen für den Soll-Zustand bei den Straßen versuchst (was wie erläutert nicht funktioniert).

Ich hab auch garnicht argumentiert, dass das schlimm ist - es wird nur kaum gemacht und darüber ist hoffentlich auch niemand unglücklich.

Ich betone noch mal meine zwei Ratschläge:

  • die vermeintlichen Notwendigkeiten des Renderings bei der Diskussion, wie etwas erfasst werden soll, ignorieren. Die Betonung liegt hier auf vermeintlichen - denn es sind im Allgemeinen nur Bequemlichkeiten.
  • auf das Analogie-Argument Straßen sind wie Flüsse zu verzichten - das stimmt einfach in keinerlei Hinsicht.

Hast Du das schon mal versucht?

36

erst seit 2014 mit 16:3 Stimmen

37

wobei ich diese Taggingvariante wesentlich besser finde, da so eine Unterscheidung der Gewässerfläche nach Fluß, Kanal, Gewässeraltlauf, ect. möglich ist, eine Sache, die ich hier im Spreewald zu schätzen gelernt habe.
…das wird aber hier OT.

Man kommt aber irgendwann nicht mehr darum herum, Straßen als Flächen zu erfassen… Das habe ich 2013 bereits geschrieben:
https://forum.openstreetmap.org/viewtopic.php?pid=329131#p329131

Ich Zitiere mich mal selbst:

Ich gehe sogar soweit zu sagen, daß die Taggingweise, mit der man Rad- und Fußwegeeigenschaften an der Straße erfasst wird, dann aufgegeben werden muß, wenn man area:highway erfasst. Dann funktioniert auch die tactile_paving - Erfassung und kerb=*

Sven

PS: welchen Abbildungsmaßstab haben wir den eigentlich bei der höchsten Zoomstufe Z19?

38

https://wiki.openstreetmap.org/wiki/DE:Zoom_levels

39

Danke… bei Z19 also ca. 1:1000…

Sven

40

Für den 52-ten Breitengrad gilt dies:

Zoom	Denominator
 0	1 : 344205412
 1	1 : 172102706
 2	1 : 86051353
 3	1 : 43025676
 4	1 : 21512838
 5	1 : 10756419
 6	1 : 5378210
 7	1 : 2689105
 8	1 : 1344552
 9	1 : 672276
10	1 : 336138
11	1 : 168069
12	1 : 84035
13	1 : 42017
14	1 : 21009
15	1 : 10504
16	1 : 5252
17	1 : 2626
18	1 : 1313
19	1 : 657