Komplizierte Kreuzungen zum Testen des Area=highway

Hallo,

hmm, da fällt mir spontan der Bereich um das "Mörsenbroicher Ei" [1] in Düsseldorf ein - ein komplexe Mehrfach-Kreuzung der B1, B7 und B8 sowie diverser weiterer Straßen.

In OSM stimmt bei der Erfassung bestimmt noch nicht jedes Detail, aber dort gibt es alles, was das Mapper-Herz begehrt: Fahrspuren ohne Ende, eine Rampe/Brücke, Straßenbahn- und Bus-Haltestellen (auch zwischen den Spuren), Grünflächen und sogar einen Bach innerhalb der Kreuzung. Auf der Grashofstr. von nordwest kommend gibt es auch eine Bus-/Taxi-Spur.

Gerüchten zufolge mussten bei der Planung der Ampelphasen mehrere Personen in die Psychiatrie eingewiesen werden ... ;-)

[1] http://www.openstreetmap.org/?lat=51.25 … 8&layers=M

Seoman

Schluchz... Vielen Dank Seoman!
Ich habe gehört dass die Mexiko City und Paris ebenfalls üble Kreuzungen haben. Kann das jemand mit einem Beispiel bestätigen?

Stuttgart hat etliche komplizierte Kreuzungen. Ich wollte an die sowieso mal dran, da dort sinnfreie und illegale Routen möglich sind und dazu das ganze noch höchst unübersichtlich gemappt ist. Sämtliche kreuzende Fahrspuren sind verbunden, aber enorme Mengen an only_straight_on-Relations verhindern (wie in der Wirklichkeit auch), dass man von der Fahrspur wegkommt - hätte man sich den Node gespart, hätte man die Relations gar nicht gebraucht. Dafür meckert keepright halt einen falschen Fehler an... imho ist es aber deutlich besser, diese pseudo-Fehler beizubehalten statt das ganze mit zig mini-Schnipsel und only_straight_on-Relations in die Unwartbarkeit zu jagen - und die Verarbeitung wird auch etwas einfacher.

Ein paar Beispiele (nicht auf alle muss das obige zutreffen, ich hab noch nicht alle genauer angeschaut): http://osm.org/go/0DmUgHLqC-- http://osm.org/go/0DmUKfqWv-- http://osm.org/go/0DmUxLLYj-- http://osm.org/go/0DmUb5ShC-- http://osm.org/go/0DmRfs9bV--

Die hier hab ich vor einiger Zeit mal aufgeräumt, wie ich es für sinnvoll halte (idealerweise legt man sich hier das Aerowest-Luftbild drunter): http://osm.org/go/0DgRZUEJu--

Hallo Cobra, ich kenne diese Gegend (Stuttgart) aber ich habe mir die OSM Darstellung hier im Detail nicht angesehen:
die Beispiele sind wirklich komplex - insbesondere die Darstellung übereinander liegenden Flächen kann dort untersucht werden.
Danke.

dieser Kreisverkehr in Swindon (aka "Magic Roundabout") ist vielleicht auch noch von Interesse.

Cobra wrote:

Sämtliche kreuzende Fahrspuren sind verbunden

Ist ja auch korrekt. Der Router erkennt sonst Abbiegevorgänge nicht korrekt.

Schwierig sind natürlich auch Kreuzungen, die Fast vollständig unter der Erde verschwiden:
http://osm.org/go/0BPCwDQ8~--
Wer diese Gegend nicht besuchte, hat mit dem OSM Rendering schlechte Karten.

Eine verrückte Idee: Für Bereiche in denen Inhalte mit der Bezeichnung layer=-1 usw. sind, extra Kachel rendern. In dem view müßte man dann die Möglichkeit haben zwischen den Geschoßen zu wechseln. Auf diese Art könnte man solche Areas zeichnen. Die darüber liegenden Wege und elemente wären dann gestrichelt gezeichnet..

chris66 wrote:

Cobra wrote:

Sämtliche kreuzende Fahrspuren sind verbunden

Ist ja auch korrekt. Der Router erkennt sonst Abbiegevorgänge nicht korrekt.

• facepalm* Du DARFST und KANNST da gar nicht abbiegen, da hat der Router absolut nix zu sehen.
  

Beispiele:

Verrätst du mir bitte, was ein Router mit der Info "da ist ne andere Straße, aber die ist hier nicht erreichbar" anfangen soll?

Eine Verständnisfrage: Ist das nicht so, dass nach geltendem Paradigma zwei Straßen, die auf einem level liegen und sich schneiden jeweils einen Schnittpunkt haben müssen?
WENN man sich darauf geeinigt hat (was meiner Meinung nach nicht sein sollte für <value>_link Elemente), dann muss man sie dummerweise jeweils mit entsprechenden Geboten bzw. Verboten beschreiben.

Je mehr ich mich damit befasse umso mehr bi nich der Meinung, dass die "link" Wege von dieser Regelung befreit weden sollten.
Beispiel: http://wiki.openstreetmap.org/wiki/File … ssing4.jpg
die Link Highways die auf dieser Skizze jeweils durch zwei blaue Knoten verbunden sind, führen NUR UND ALLEIN von einem blauen Knotenpunkt zu dem Anderen.
Würde man konsequent die Link Bezeichnung für solche Verbindungen benutzen, dann hätte man auch ken Rendering Problem: die Link Highways wären nur in der höchsten Zoomstufe gerendert und in geringeren Zoomstufen nicht, wodurch die Lesbarkeit der kartgrafischen Karte besser wäre.

Des Weiteren könnte und sollte man sich überlegen, ob die verschiedenen layer=<value> nicht eine leicht untershiedliche Farbe bzw Gradient bekommen sollten wenn der Anfang und Ende eines Weges verschiedene layer Werte hätten.

marek kleciak wrote:

Je mehr ich mich damit befasse umso mehr bin ich der Meinung, dass die "link" Wege von dieser Regelung befreit weden sollten.
Beispiel: http://wiki.openstreetmap.org/wiki/File … ssing4.jpg
die Link Highways die auf dieser Skizze jeweils durch zwei blaue Knoten verbunden sind, führen NUR UND ALLEIN von einem blauen Knotenpunkt zu dem Anderen.

Das ist ein vielversprechender Ansatz, wobei man IMHO zwischen solchen "kreuzungsinternen" Links (die ein Router ignorieren könnte) und den üblichen motorway_links (z.B.) die ein Router nicht ignorieren darf, unterscheiden muss.

Chris

Das reizvolle an der Idee ist: Der Routing könnte richtige Geometrie anzeigen und rechtzeitig auf Abbiegemanouver hinweisen.
Des Weiteren ist es für Newbies eifach zu verstehen und ist weniger Fehleranfällig.

Cobra wrote:

Verrätst du mir bitte, was ein Router mit der Info "da ist ne andere Straße, aber die ist hier nicht erreichbar" anfangen soll?

Um Abbiegevorgänge richtig ansagen zu können, muss ein Router natürlich erkennen können, dass dort eine Kreuzung ist.

chris66 wrote:

Cobra wrote:

Verrätst du mir bitte, was ein Router mit der Info "da ist ne andere Straße, aber die ist hier nicht erreichbar" anfangen soll?

Um Abbiegevorgänge richtig ansagen zu können, muss ein Router natürlich erkennen können, dass dort eine Kreuzung ist.

aber doch nicht an jeder verdammten Fahrspurkreuzung! Ich will nicht 50 "geradeaus"-Anweisungen sehen!
Herr, wirf Hirn...

Bei dem Beispiel "Mörsenbroicher Ei" sollte sich mal jemand diese beiden Relationen näher anschauen.
http://www.openstreetmap.org/browse/relation/105879
http://www.openstreetmap.org/browse/relation/105880

marek kleciak wrote:

Eine Verständnisfrage: Ist das nicht so, dass nach geltendem Paradigma zwei Straßen, die auf einem level liegen und sich schneiden jeweils einen Schnittpunkt haben müssen?
WENN man sich darauf geeinigt hat (was meiner Meinung nach nicht sein sollte für <value>_link Elemente), dann muss man sie dummerweise jeweils mit entsprechenden Geboten bzw. Verboten beschreiben.

Das kommt nur daher, dass in der Anfangszeit etliche Leute zu blöde waren, die Straßen gescheit zu verbinden. (Vor allem Potlatch1 war da sehr anfällig für Fehlbenutzung mit nur knapp nicht verbundenen Ways) Dadurch gab es dann massig unverbundene Straßen, wo man in der Realität aber rumfahren konnte. Daher gab es Fehlersuchtools, die das angemeckert haben. Und exakt diese Tools diktieren mit ihren Fehlermeldungen dieses "Paradigma". Meiner Meinung nach ist das ein klassischer Fall von "übers Ziel hinausgeschossen": einige Leute sind zu blöd, Nodes zu setzen, wo sie hingehören, also pappen wir alles überall zusammen, auch wenn es nicht zusammengehört, um es danach mittels eines weiteren Konstruktes auseinanderzudröseln.
Davon sollte man wegkommen.
Vergleich: früher haben die Leute Gebäude mit wgs84 abgezeichnet und rechtwinklig dargestellt, was dann als Rhombe gerendert wurde. Deshalb schreiben wir vor, dass alle Gebäude rechtwinklig sein müssen. Ist eins mal nicht rechtwinklig, muss eine Relation mit den tatsächlichen Eckpunkten angelegt werden.

Wir haben es ja auch geschafft, dass bridge=yes ausreicht, weil in den allermeisten (trivialen) Fällen klar ist, was oben und was unten liegt. Da darf also problemlos und eindeutig eine Straße mit bridge=yes ein andere ohne bridge=yes kreuzen, ohne dass sie einen gemeinsamen Node haben.

Cobra wrote:

Herr, wirf Hirn...

Dieses Forum überzeugt idR durch sachlichen Umgang. 🙄

Cobra wrote:

aber doch nicht an jeder verdammten Fahrspurkreuzung! Ich will nicht 50 "geradeaus"-Anweisungen sehen!
Herr, wirf Hirn...

Wir haben es ja auch geschafft, dass bridge=yes ausreicht, weil in den allermeisten (trivialen) Fällen klar ist, was oben und was unten liegt. Da darf also problemlos und eindeutig eine Straße mit bridge=yes ein andere ohne bridge=yes kreuzen, ohne dass sie einen gemeinsamen Node haben.

Irgendwie scheinst du das Prinzip nicht verstanden zu haben. Hier vergleichst du nämlich Äpfel mit Birnen.
Erstens ist die Straße mit bridge=yes jene Straße, welche oben ist oder bei mehreren Brücken ist das Problem nachwievor ungelöst.
Zweitens haben die Straßen, die durch eine Brücke oder einen Tunnel getrennt im dreidimensionalen Raum eben gerade kein Schnittpunkt und sollen daher auch in OSM keinen haben. Mit deinen Fahrspuren verhält sich das aber anders!

So habe ich das einfache Model von OSM verstanden.

Im Prinzip ist jede Straße egal ob baulich oder durch Markierung getrent für den Router nur eine Linie. OSM ist aber nicht allein für einen Router gedacht, sondern stellt GeoDaten bereit. Details auf der einen Seite zerstören die gewünschte Einfachheit auf der anderen Seite. Die Realität ist einfach sehr komplex.
Daher begrüße ich den Ansatz von Marek außerordentlich sich mit dem Thema Straßenflächen zu beschäftigen und das Gebiet vorzudenken. Denn dann wird es möglich sein Fahrspurchen und die Straßenfläche voneinander unabhängig zu gestalten. Außerdem kann mit einfachen Flächen eine Kreuzung markiert werden, damit der Router weis das ganze Konstrukt ist in der Realität eine Einheit und kann sich dann vielleicht sogar die Kreuzung vereinfachen und die Fahrspuren nur zur Visualisierung verwenden. Hey dann hätten alle was davon. Danke Marek.

rab wrote:

Bei dem Beispiel "Mörsenbroicher Ei" sollte sich mal jemand diese beiden Relationen näher anschauen.
http://www.openstreetmap.org/browse/relation/105879
http://www.openstreetmap.org/browse/relation/105880

Done.

Seoman

Ein wenig Offtopic: Ich habe den User Damnog ermuntert, seine Idee, die ich pfiffig finde, zu visualisieren.
Es ging um die Lesbarkeit der "Superkreuzungen" mit mehreren Ebenen. Was kann ich mit Straßen in solchen Bereichen machen, damit beim Rendern besser rauskommt was ganz oben ist und was ganz tief.

Die Idee ist grundlegend und eigentlich sehr naheliegend: Ich soll den Anfang und Endpunkt einer Strecke mit layer taggen damit man weiß au welcher (relativen) Ebene der Abschnitt beginnt und auf welcher er endet. Die Strecke zwischen beiden Punkten kann zusätzlich zu dem Farbwert auch mit einem Gradient belegt werden:

http://www.sendspace.pl/file/2445ca1798 … l-crossing

Ich bat Damnog eine Wiki Seite mit Beispielen und der Beschreibung anzulegen. Mal sehen...

Marek, ich weiß nicht, ob du meinen Vorschlag zur Lösung des Spurmapping-Problems unter https://wiki.openstreetmap.org/wiki/Use … lane_model mitbekommen hast. Ich habe den gepostet, in der Hoffung, das den interessierte Spurmapper vielleicht durchsehen und weiter verbessern, weil ist bestimmt noch nicht voll konsistent und fehlerfrei. Im Grunde ist es auch nur eine Versuch, meinen schon beschriebenen Lösungsweg mal testweise umzusetzen.

Das ganze ist doch im Grunde genommen ganz einfach:
Wenn man die Spur als Abstraktionsstufe ansetzt, so ist die höchstmöglichst mappbare Detailstufe, die Spur als Fläche zu mappen. Es hat auch keinen Zweck dei der Abstraktionsstufe Fahrbahn (area=highway) zu beginnen, wenn man eigentlich noch eine Stufe weiter ins Detail auflösen will. Die Straße enthält mehrere Fahrbahnen (unterschiedlicher Breite (getrennter Fuß-/Radweg=1 Fahrbahn mit 2 Fahrspuren) und für unterschiedliche Nutzungsarten) und diese können aus einer oder meheren Spuren bestehen. Wenn man die Fläche der Fahrspur nicht mappen kann oder möchte, abstrahiert man die Fahrspur ersatzweise (und zu ihrer Fläche austauschbar) zu einer Linie.

Gegenüber der Fläche, hat man da den Vorteil, das die Linie/Vektor (OSM-Way) ja nur 4 Seiten hat vorwärts (=in Richtung des Linienverlaufs), rückwärts, links und rechts, was auch gilt, wenn sie ein geschlossener Kreis (junction=roundabout) ist. Damit läßt sich bei einem Way auch leicht angeben, wer in welche Richtung fahren darf. Im Vorschlag ist es für jeden Way gemacht, aber wenn man sowieso eine extra Editor oder Tools für das Schema braucht, sind das sicher Relationen, wo man das für mehrere Wege zusammenfassen kann, besser.

Mehrere Fahrspuren sind dann die jeweilige Fahrbahn und eine oder mehrere Fahrbahnen dann die Straße. Das Hauptproblem bei flächigen Spuren ist ja, die möglichen Übergänge zwischen den Spuren abzubilden. Meine erste Idee war da einfach das betreffende Wegstück in eine Relation zu stecken und dann kann man für den Weg aus gemeinsamen Knoden ja wieder angeben, wer da von links und von rechts drüber/fahren oder gehen darf.

Obige Lösung ist Proof of Concept von meiner Lösung, deshalb ist da auch nicht unbedingt alle vollstänig und korrekt durchgetaggt. Weil wenn man nämlich jede Spur mappt, ist egal, ob sich vielleicht ein Teil der Kreuzung unter der Erde befindet. Außerdem spart man sich bei den 4-Richtungen einen haufen Relationen mit Abbiegebeschränkungen.

Hallo Fabi2,
ich habe auch darüber nachgedacht ob man nicht gleich besser die einzelnen Spuren als Flächen mappt, aber ich befürchte, dass es niemand auf einer Autobahn durchhält. Ich denke mir fast, dass wir für die Diskussion einige Testbereiche wählen sollten und dort verschiedene Schemata testen. Daraus würde sich der Aufwand ergeben sowie Vor- und Nachteile von jedem Ansatz.

Cobra wrote:

Das kommt nur daher, dass in der Anfangszeit etliche Leute zu blöde waren, die Straßen gescheit zu verbinden. (Vor allem Potlatch1 war da sehr anfällig für Fehlbenutzung mit nur knapp nicht verbundenen Ways) Dadurch gab es dann massig unverbundene Straßen, wo man in der Realität aber rumfahren konnte. Daher gab es Fehlersuchtools, die das angemeckert haben. Und exakt diese Tools diktieren mit ihren Fehlermeldungen dieses "Paradigma". Meiner Meinung nach ist das ein klassischer Fall von "übers Ziel hinausgeschossen": einige Leute sind zu blöd, Nodes zu setzen, wo sie hingehören, also pappen wir alles überall zusammen, auch wenn es nicht zusammengehört, um es danach mittels eines weiteren Konstruktes auseinanderzudröseln.
Davon sollte man wegkommen.

Wenn das so ist, dann plädiere ich dafür dass man solche Linine nicht miteinander verbindet. Die momentane Lösung ist fehleranfällig und für den Routing tödlich. Es produziert Unmengen an Relationen und unnötiger Arbeit.

Zu dem schon ziterten Bild: http://wiki.openstreetmap.org/wiki/File … ssing4.jpg ein Beispiel in der Karte: http://osm.org/go/0Oc0xvZVn--

Ich habe testsweise untersucht, was man aus den Straßenflächen mit entsprechendem Rendering rausholen kann.
Hier ein Beispiel:
http://wiki.openstreetmap.org/wiki/DE:S … _der_Karte

Bitte dort Bild C. mit D. vergleichen...

Ein User hat schon die Tests für einen Renderer angefangen: http://znajomy.home.pl/area/index2.html

Ihr wisst abr schon, dass Luftbilder schon erfunden worden sind?

SCNR

Wir kommen von "komplizierten Kreuzungen" und "Spurmapping" auf sowas? Das ist doch Mapping für den Renderer - hat aber nix mit der Vereinfachung oder idealen Darstellung von Kreuzungen zu tun...

Also ich verstehe das nicht ganz (muss ich vielleicht auch nicht...)

Ihr wisst abr schon, dass Luftbilder schon erfunden worden sind?

na ja, auf den Luftbilder sind die unterirdische Bereiche gewöhnlich ein wenig unterrepresentiert.
Außerdem sind wir nicht der Eigentümer der Luftbilder deswegen rendern wir auch jetzt Karten.

Generell wo ist die Grenze zwischen dem A. Mapping für den Renderer und der B. Abbildung der Realität?

Je detailliereter Du die Realität abbildest, umso mehr kann der Renderer damit anfangen.

Mapping für den Renderer ist einfach nur, dass man Dinge absichtlich falsch einträgt, damit sie in speziellen Renderern auf eine bestimmte Art dargestellt werden.

Bei deinem Beispiel könnte man zum Beispiel den Fußweg als cycleway eintragen, damit eben keine Zebrastreifen angezeigt werden. Oder das man footways mit ganz kleinem width als Mittelstreifen einträgt, oder oder....

Dann siehe ich diese Gefahr bei dem Konzept nicht 😉

marek kleciak wrote:

Cobra wrote:

Meiner Meinung nach ist das ein klassischer Fall von "übers Ziel hinausgeschossen": einige Leute sind zu blöd, Nodes zu setzen, wo sie hingehören, also pappen wir alles überall zusammen, auch wenn es nicht zusammengehört, um es danach mittels eines weiteren Konstruktes auseinanderzudröseln.
Davon sollte man wegkommen.

Wenn das so ist, dann plädiere ich dafür dass man solche Linine nicht miteinander verbindet. Die momentane Lösung ist fehleranfällig und für den Routing tödlich. Es produziert Unmengen an Relationen und unnötiger Arbeit.

Ich würde im Falle echter Straßen nicht von der bisherigen Regel (gemeinsamer Knoten bei physischer Verbindung ist unabhängig von den erlaubten Abbiegemöglichkeiten ein Muss) abweichen wollen.

Meiner Meinung nach etwas anders läge die Situation bei "Spurways" innerhalb einer Kreuzungsfläche, wenn auch die Kreuzungsfläche als solche eingezeichnet ist. Diese dürften sich dann gerne auch ohne gemeinsame Knoten schneiden. Cobras Beispiel sieht auf mich wie ein behelfsmäßiger Versuch aus, eine solche Darstellung mit den bisherigen highway-Tags nachzubasteln, allerdings halt ohne die Kreuzungsfläche.

Fabi2 wrote:

Marek, ich weiß nicht, ob du meinen Vorschlag zur Lösung des Spurmapping-Problems unter https://wiki.openstreetmap.org/wiki/Use … lane_model mitbekommen hast. Ich habe den gepostet, in der Hoffung, das den interessierte Spurmapper vielleicht durchsehen und weiter verbessern, weil ist bestimmt noch nicht voll konsistent und fehlerfrei. Im Grunde ist es auch nur eine Versuch, meinen schon beschriebenen Lösungsweg mal testweise umzusetzen.

Eigentlich fände ich auch bei einer solchen Idee mit Spurways eine zusätzliche highway-Area extrem hilfreich. Sie würde einen definierten Übergang zu Straßenstücken ohne Spurways schaffen - die Spurways müssten dann immer mit gemeinsamen Knoten zu einer Flächen-Trennkante beginnen. Ein Renderer wird womöglich auch auch die "Spuren" in einer Kreuzungsfläche, die sich überschneiden können, anders behandeln wollen als die entlang eines Straßenstücks. Eventuell könnte man mit den Flächen sogar auf eine Relation zum Zusammenfassen der Spurways verzichten, da sich die Zusammengehörigkeit ja aus der Lage in einer gemeinsmen Highway-Fläche ergibt.

Allerdings bin ich von der Idee, Spurways entlang von Straßen einzuzeichnen, generell noch nicht wirklich überzeugt. Die Alternative (Mittellinie mit Spurtags + Straßenfläche bei unregelmäßiger Breite und komplexen Kreuzungen) macht nicht nur vielerorts deutlich weniger Arbeit, sie produziert auch optisch saubere Resultate. In dem von Fabi2 verlinkten Beispiel schwanken die Abstände zwischen den Spurways wegen der unvermeidlichen Ungenauigkeit beim Zeichnen beachtlich, das würde man m.E. nicht so fürs Rendern verwenden wollen.

Tordanik wrote:

Eigentlich fände ich auch bei einer solchen Idee mit Spurways eine zusätzliche highway-Area extrem hilfreich. Sie würde einen definierten Übergang zu Straßenstücken ohne Spurways schaffen - die Spurways müssten dann immer mit gemeinsamen Knoten zu einer Flächen-Trennkante beginnen. Ein Renderer wird womöglich auch auch die "Spuren" in einer Kreuzungsfläche, die sich überschneiden können, anders behandeln wollen als die entlang eines Straßenstücks. Eventuell könnte man mit den Flächen sogar auf eine Relation zum Zusammenfassen der Spurways verzichten, da sich die Zusammengehörigkeit ja aus der Lage in einer gemeinsmen Highway-Fläche ergibt.

Hallo Tordanik, könntest Du eine, zwei Skizzen machenm, die diese Idee veranschaulichen?
Viele Grüße,
Marek

marek kleciak wrote:

Ich habe testsweise untersucht, was man aus den Straßenflächen mit entsprechendem Rendering rausholen kann.
Hier ein Beispiel:
http://wiki.openstreetmap.org/wiki/DE:S … _der_Karte

Bitte dort Bild C. mit D. vergleichen...

Warum hast du - direkt entgegengesetzt zu den Beispielen oben auf der Seite - ein Sternmapping hergenommen? Das ist eine sehr seltsame Lösung, die selbst auch etliche Probleme erzeugt. (Meiner Meinung nach ist das die mit Abstand schlimmste Lösung von allen)
Sonst hast du auf der Seite konsistent die Fahrspuren annähernd so, wie sie wirklich laufen. Ich finde, das verwirrt unnötig.

marek kleciak wrote:

Generell wo ist die Grenze zwischen dem A. Mapping für den Renderer und der B. Abbildung der Realität?

Gegenfrage: welchen Renderer meinst Du? Wenn man für den Renderer mappen will, müsste man dafür sorgen, dass man alle Renderer berücksichtigt (könnte aber relativ schwierig werden).

Hätte auch noch was schönes, die sogenannte "Binger(-brücker) Darmverschlingung":

http://www.openstreetmap.org/?mlat=49.9 … 8&layers=M

http://maps.google.de/maps?q=Bingen&hl= … z&t=k&z=18

Hallo Cobra,
es ist genau das, was Du schreibst: ein schlechtes Beispiel, seltsame Lösung die wir mal leider immer wieder treffen. Ich habe es absichtlich genommen um zu zeigen, dass beim schlechten Mapping auch schlechter Rendering rauskommt.

Eine Bearbeitung der Flächen führt - dessen bi ich mir mittlerweile sicher - zu einer nachträglichen Verbesserung der Karte. Warum? Wer die Flächen nachzeichnet, merkt meistens was an den Vektoren chlichtweg falsch ist. Eigentlich war dieses Beispiel genau dafür gedacht. Du hast aber recht, an dieser Stelle und mit diesem Kommentar verwirrt es eher. Ich werde es ersetzen sobald ich ein anders Beispiel generiert habe.

Es würde schon deutlich verständlicher werden, wenn du dazu schriebst, dass deine Bilder nicht aus den Daten gerendert wurden, die du oben als Rohdaten zeigst.

Hallo Aighes,
selbstverständlich, die Daten werden aus den Areas gerendert. Ich hab´s ergänzt..

Vorschlag für die (optionalen) Spurways?
z.B.
lane=secondary oder
highway=secondary_lane oder
lane:secondary=left_turn

Würde gerne meine spurgemappte Nachbarstadt entsprechend umstellen. (Bisher hab ich bei Routingfehlern die überflüssigen
als highway gemappten Spuren entfernt).
Chris

Um die Stimmung anzuheizen: User Dtevo und Pbabik werkeln an einem Renderer für sowas + indoor mapping...( wie z.B. hier: http://osm.org/go/0PMfQ2NvC-- )

Die Idee wäre noch eine Stufe mehr auf dem eigenen PC zu rendern, da die Informationsdichte wesentlich höher ist, und die gerenderten Kacheln upzuloaden.
vorteil: Keine Wartezeit, Entlastung von dem zentralen Server...

chris66 wrote:

Vorschlag für die (optionalen) Spurways?
z.B.
lane=secondary oder
highway=secondary_lane oder
lane:secondary=left_turn

Was spricht gegen den bewaehrten secondary_link in Kombination mit turn:[left|right|through|...]? Eigentlich ist so eine Spur doch genau das: Ein link zwischen zwei Highways mit vorgeschriebener Fahrtrichtung.

Na ja, ich würde gerne highway=* für echte baulich getrennte Fahrbahnen behalten.
Die kreuzungsinternen Link-Spuren (siehe Marek's Bild) sind ja nur eine Art Verfeinerung, die ein Router z.B. aus Performancegründen
(oder für die Ansage-generierung) ignorieren könnte.

chris66 wrote:

Die kreuzungsinternen Link-Spuren (siehe Marek's Bild) sind ja nur eine Art Verfeinerung, die ein Router z.B. aus Performancegründen
(oder für die Ansage-generierung) ignorieren könnte.

Wirklich ignorieren kann er sie nicht - die Spuren sind ja die einzige Möglichkeit von A nach B zu kommen.
Für die Ansage sollte so eine Spur ähnlich wie ein einziger Knoten behandelt werden bei der Bestimmung der Abbiegerichtung (siehe meine Fragen vor 2 Wochen).
Die ganzen nicht baulich getrennten Spuren bräuchte es ja nach Einführung von area=highway nicht mehr. Der Grund für das Spurmapping ist ja im Moment nur die Optik und das Problem gibt es dann nicht mehr - das wären wieder nur lanes eines highways.

Naja, er könnte sie ignorieren, wenn, wie gefordert, eine Kreuzungsfläche vorhanden ist, an die die higways davor münden. Dann kann der Router nämlich einfach von jedem eintreffenden zu jedem abgehenden highway routen, soweit das nicht durch restrictions verboten ist. Hat aber einen Nachteil: Wir brauchen auch dann restrictions für die highways, wenn die Situation aus den Spuren bereits klar wird.

Diese Art des Mappings hat natürlich noch weitere Vorteile: Man kann sich sogar aussuchen, wie detailiert geroutet werden soll: "Nur" abbiegen an der Kreuzung, mit Spur-Ansage oder bei jedem Fahrstreifenwechsel.

Vorschlag:
Sollten wir "offiziell" vorschlagen, bei den Überprüfungswerkzeugen wie keepright Ausnahmen von der Regel "keine kreuzenden highways ohne gemeinsamen Node" bei allen primary_link und niedriger (also alle links ohne motorway_link) einzuführen? Das würde in jedem Fall die Flut an nötigen turn restrictions eindämmen und hat auch keine negativen Auswirkungen auf das routing.

Sollten wir "offiziell" vorschlagen, bei den Überprüfungswerkzeugen wie keepright Ausnahmen von der Regel "keine kreuzenden highways ohne gemeinsamen Node" bei allen primary_link und niedriger (also alle links ohne motorway_link) einzuführen? Das würde in jedem Fall die Flut an nötigen turn restrictions eindämmen und hat auch keine negativen Auswirkungen auf das routing

Ich halte es für sinnvoll, allerdings sollte zugleich eine Informationskampagne gestartet werden: viele User lesen die Forumbeiträge nur sporadisch. Ich dachte auch, während des Treffens in Garching könnten wir eine kleine Spezifikation erarbeiten und diese verbreiten.

Doppelmapping (simpel und detailliert) finde ich genauso schwer wartbar wie die zusammengetackerten Spuren mit den Restrictions.

Komplett neue Tags finde ich problematisch, da man hier die gesamten Toolchains für alles (Editoren, Rendering, Routing, Validierungstools, Konverter in anwendungsspezifische Formate) anpassen muss - meist in Richtung "secondary_link wird in secondary umgebogen, die Zusatzinfo verworfen" - also nur Aufwand ohne Gewinn.
Ein zusätzliches Tag wie "lane=yes" (spontan erfunden) fände ich besser. Wer das auswerten will, kann es tun (noch gibt es soweit ich weiß nichts, was das tun würde). Wer das nicht will, dem geht auch nichts kaputt.
Ja, nur weil "irgendwas" kaputtgeht, müssen wir uns nicht völlig allen Innovationen verweigern. Ich sehe nur ein sehr, sehr schlechtes Kosten-Nutzenverhältnis. Wir "bekommen" damit weniger falsche Fehler in Validatoren. Wir "zahlen" aber damit, dass praktische alle produktiven Anwendungen kaputt sind und mit gewissem Aufwand angepasst werden müssen - man sieht ja immer wieder, was das für ein Problem ist, vor allem bei "schwierigen" Verantwortlichen.

Was keepright angeht, bin ich auch sehr dafür, nachzubessern. Die Kennzeichen für Spurmapping sind relativ eindeutig: viele kurze ways, meistens mit oneways-Tags, mit mindestens 2 anderen ways verbunden. Außerdem einige kreuzende Ways mit diesen Kennzeichen an einem Fleck. Damit ließe sich evtl. schon einiges an falschen Fehlern vermeiden.

Tordanik wrote:

Fabi2 wrote:

Marek, ich weiß nicht, ob du meinen Vorschlag zur Lösung des Spurmapping-Problems unter https://wiki.openstreetmap.org/wiki/Use … lane_model mitbekommen hast. Ich habe den gepostet, in der Hoffung, das den interessierte Spurmapper vielleicht durchsehen und weiter verbessern, weil ist bestimmt noch nicht voll konsistent und fehlerfrei. Im Grunde ist es auch nur eine Versuch, meinen schon beschriebenen Lösungsweg mal testweise umzusetzen.

Eigentlich fände ich auch bei einer solchen Idee mit Spurways eine zusätzliche highway-Area extrem hilfreich.

Das Beispiel setzt für die Dtraße überwiegend die vereinfachte Variante, wei der die Fläache der Spur als Weg dargestellt wird um. Am Rande habe ich aber experimentell Fußwege + Landuse als Fläche gemappt und da im Grunde genau das umgesetzt, was du hier nachfolgend mit:

Tordanik wrote:

Sie würde einen definierten Übergang zu Straßenstücken ohne Spurways schaffen - die Spurways müssten dann immer mit gemeinsamen Knoten zu einer Flächen-Trennkante beginnen.
[...] Eventuell könnte man mit den Flächen sogar auf eine Relation zum Zusammenfassen der Spurways verzichten, da sich die Zusammengehörigkeit ja aus der Lage in einer gemeinsmen Highway-Fläche ergibt.

beschreibst, wobei ich denke das man auf Zusammenfassung der Spuren mit Relationen eher nicht versichten kann, da mußte man aber noch mal genauer drüber nachdenken. Die Spurflcähen sind mit den Linien in meinem Modell beliebig austauschbar.

Tordanik wrote:

Ein Renderer wird womöglich auch auch die "Spuren" in einer Kreuzungsfläche, die sich überschneiden können, anders behandeln wollen als die entlang eines Straßenstücks.

Mist, an die Spuren als Flächen-Vollmapping im Kreuzungsbereich habe ich jetzt gar nicht gedacht, wenn die Flächen sich aber überlappen, könne man einfach die Spurflächen nacheinander gleich rendern und das ergibt dann die Fläche der Kreuzung.

Tordanik wrote:

Allerdings bin ich von der Idee, Spurways entlang von Straßen einzuzeichnen, generell noch nicht wirklich überzeugt. Die Alternative (Mittellinie mit Spurtags + Straßenfläche bei unregelmäßiger Breite und komplexen Kreuzungen) macht nicht nur vielerorts deutlich weniger Arbeit, sie produziert auch optisch saubere Resultate.

Klar kann man auch die Alternative des Street-Area-Ansatzes umsetzen und die Straße dabei in zig Stücke teilen, aber der Ansatz geht immer davon aus, das die Spuren sich die zur Verfügung stehende Breite der Fläche symetrisch aufteilen und keine Spur smaler ist oder vielleciht noch ein paar Ausbuchtungen am Rand hat.

Tordanik wrote:

In dem von Fabi2 verlinkten Beispiel schwanken die Abstände zwischen den Spurways wegen der unvermeidlichen Ungenauigkeit beim Zeichnen beachtlich, das würde man m.E. nicht so fürs Rendern verwenden wollen.

Das Lienenmodell ist nicht ungedingt as hochgenauer Rendervorlage gedacht, dafür sollten die Spuren flächig gemappt werden, sondern dafür, die Anzahl ud den ungefähren Verlauf der Spuren abzubilden. Zum rendern kann man die carraigeway-Relation der Spurwege nehmen, denn das ist schließlich die Fahrbahn, oder eben die highway-Reklation als Ersatz für den highway-Weg. Du tutst ja fast so, als würden die momentanen highway-Wege die genaue Straßengeometrie wiedergeben... Die lieneienhafte Umsetzung soll aber nur die Notlösung bei fehlenden ordentlichen Luftbildern sein und ich habe mir auch nicht extra besondere mühe gegeben die Wge für die Spuren extakt anzuordnen, da es mit mehr um die Idee an sich ging.

mueschel wrote:

Die ganzen nicht baulich getrennten Spuren bräuchte es ja nach Einführung von area=highway nicht mehr. Der Grund für das Spurmapping ist ja im Moment nur die Optik und das Problem gibt es dann nicht mehr - das wären wieder nur lanes eines highways.

Soweit mir bekannt, ist area=highway ja die Abstraktion für die jeweilige Fahrbahn. Soll das jetzt gleichzeitig auch dfür benutzt werden um Spuren darzustellen? Gut, für OpenCarMap, mag das ausreciehn und was schert einen als Autofahren, ob die Fahrbahnen vielleicht in Wirklichkeit nur Fahrspuren sind, aber in Hinblick auf andere Anwendungen und auf die korrekte Abbildung der Realität, wo eben eine Fahrspur ja nun mal nicht das Gleiche ist wie eine Fahrbahn, kann ich diese Verwürfelung, wenn ich es jetztrichtig verstanden haben sollte, nicht begrüßen.

mueschel wrote:

Vorschlag:
Sollten wir "offiziell" vorschlagen, bei den Überprüfungswerkzeugen wie keepright Ausnahmen von der Regel "keine kreuzenden highways ohne gemeinsamen Node" bei allen primary_link und niedriger (also alle links ohne motorway_link) einzuführen? Das würde in jedem Fall die Flut an nötigen turn restrictions eindämmen und hat auch keine negativen Auswirkungen auf das routing.

Klar, das sollte auf jeden Fall so umgestzt werden und entsprciht auch meinem vorgeschlagenen Schema. Außerdem macht man das ja bei Wege über z.B. landuse-Flächen schon jetzt so. Ein gemeinsamen Knotenpunkt heißt immer, das dort eine Wechsel möglich ist, wenn es keinen gibt, kann man da auch nicht wechseln, habe mich schon gewundert, warum man das beim bisherigen oneway=yes-Einzelspurmapping überhaupt so gemacht hat.

Fabi2 wrote:

Mist, an die Spuren als Flächen-Vollmapping im Kreuzungsbereich habe ich jetzt gar nicht gedacht, wenn die Flächen sich aber überlappen, könne man einfach die Spurflächen nacheinander gleich rendern und das ergibt dann die Fläche der Kreuzung.

Solche Hacks kann man bei klassischem 2D-Rendering machen, aber für 3D-Geometrien oder auch z.B. saubere Vektorgrafiken will man das nicht haben. Da braucht man schon eine ordentliche Kreuzungsfläche.

Fabi2 wrote:

Tordanik wrote:

Allerdings bin ich von der Idee, Spurways entlang von Straßen einzuzeichnen, generell noch nicht wirklich überzeugt. Die Alternative (Mittellinie mit Spurtags + Straßenfläche bei unregelmäßiger Breite und komplexen Kreuzungen) macht nicht nur vielerorts deutlich weniger Arbeit, sie produziert auch optisch saubere Resultate.

Klar kann man auch die Alternative des Street-Area-Ansatzes umsetzen und die Straße dabei in zig Stücke teilen, aber der Ansatz geht immer davon aus, das die Spuren sich die zur Verfügung stehende Breite der Fläche symetrisch aufteilen und keine Spur smaler ist oder vielleciht noch ein paar Ausbuchtungen am Rand hat.

Schmaler ist nicht zwangsläufig ein Problem - dafür gibt's width - und solange nur eine Spur unregelmäßig ist (z.B. der Gehsteig) bekommt man das über Verteilung der "Restfläche" neben den Spuren mit Standardbreite schon auch hin.

Du hast trotzdem recht, dass die tag-basierte Spurdarstellung nicht wirklich für komplex geformte Straßen passt. Allerdings sind relativ parallel verlaufende Spuren wohl eher der Normalfall, so dass ich lieber ein paar fehlende Ausbuchtungen bei ungewöhnlichen Situationen in Kauf nehme als die unzähligen künstlichen Ausbuchtungen an eigentlich völlig geraden Straßenstücken, die durchs ungenaue Zeichnen von Spurways zustandekämen.

Das Lienenmodell ist nicht ungedingt as hochgenauer Rendervorlage gedacht, dafür sollten die Spuren flächig gemappt werden, sondern dafür, die Anzahl ud den ungefähren Verlauf der Spuren abzubilden. Zum rendern kann man die carraigeway-Relation der Spurwege nehmen, denn das ist schließlich die Fahrbahn, oder eben die highway-Reklation als Ersatz für den highway-Weg.

Wenn es nicht als Rendervorlage dient, hat es aber auch keinen Vorteil hinsichtlich der Ausbuchtungen etc., die du oben genannt hast.

Für die bloße Angabe von Anzahl und Art der Spuren würde ich sowohl beim Mappen als auch bei der Auswertung dann doch so was bevorzugen, statt die Information aus Ways zu rekonstruieren. Die carriageway-Relation hilft eventuell beim Verallgemeinern weiter, aber nicht beim spurgenauen Rendering.

Ein gemeinsamen Knotenpunkt heißt immer, das dort eine Wechsel möglich ist, wenn es keinen gibt, kann man da auch nicht wechseln, habe mich schon gewundert, warum man das beim bisherigen oneway=yes-Einzelspurmapping überhaupt so gemacht hat.

Nein, das gibt die bestehende Konvention falsch wieder. Ein gemeinsamer Knotenpunkt heißt, dass dort eine physische Verbindung besteht (und die Straßen daher z.B. auf gleicher Höhe liegen). Das ist eine Voraussetzung dafür, dass ein Wechsel möglich sein kann, aber er muss keineswegs auch tatsächlich möglich sein - das ist dann abhängig von Tags und Restrictions.

Genauso wie man ja auch auf Bahnübergängen o.ä. gemeinsame Knoten setzt: Nicht um eine Wechselmöglichkeit auszudrücken, sondern zur Abbildung der physischen Kreuzung der Verkehrswege.

Natürlich wäre für Einzelspurmapping von Kreuzungen eine andere Konvention geeigneter. Da highway=* aber sowieso das falsche Tag für Einzelspurmapping ist, sind die Warnungen dort angebracht.

Cobra wrote:

Doppelmapping (simpel und detailliert) finde ich genauso schwer wartbar wie die zusammengetackerten Spuren mit den Restrictions.

Komplett neue Tags finde ich problematisch, da man hier die gesamten Toolchains für alles (Editoren, Rendering, Routing, Validierungstools, Konverter in anwendungsspezifische Formate) anpassen muss - meist in Richtung "secondary_link wird in secondary umgebogen, die Zusatzinfo verworfen" - also nur Aufwand ohne Gewinn.

Es wird sich vorrobergehend aus meiner Sicht nicht vermeiden lassen, das man die alten highways zusätzlich zum neuen Schema noch mit in den Daten hat. Wenn das Schema erweiterbar udn damit dann auch leider komplizierter wird, braucht man langfristig dafür eh entsprechende Tool-Unterstützung. Schwer wartbar ist das nicht, weil die alten hiways sind/sollen ja noch zumindest so lange vorhanden sein, bis man das komplexe Spurmodell halbwegs fehlerfrei in die Datenbank gezaubert bekommt. Somit hat man sowieso doppelte Daten, bestenwalls benutzt man eine der neuen Spurwege als Ersatz für den alten highwy.

Cobra wrote:

Ein zusätzliches Tag wie "lane=yes" (spontan erfunden) fände ich besser.

Nö, das Tag ist eine schamlose Raubkopie von https://wiki.openstreetmap.org/wiki/Use … lane_model , ich werde gleich meine Anwälte auf dich hetzen. 😉

Cobra wrote:

Wer das auswerten will, kann es tun (noch gibt es soweit ich weiß nichts, was das tun würde). Wer das nicht will, dem geht auch nichts kaputt.

Cobra wrote:

Wir "zahlen" aber damit, dass praktische alle produktiven Anwendungen kaputt sind und mit gewissem Aufwand angepasst werden müssen - man sieht ja immer wieder, was das für ein Problem ist, vor allem bei "schwierigen" Verantwortlichen.

Nein, es geht nichts kaputt und gezahlt wird eher mit Unübersichtlichkeit, Komplexität und der Notwendigkeit neuer Tools für das Spurmappingschema, aber kaputt geht nichts. Wie du ja auch vorgeschlagen hast, könnte man die alten highways teilweise auch als Spuren für das neue Schema recycklen, wo es paßt, nur ob es dadurch übersichtlicher wird, als wenn man die Sachen doppelt einträgt, sei mal dahingestellt.

Cobra wrote:

Die Kennzeichen für Spurmapping sind relativ eindeutig: viele kurze ways, meistens mit oneways-Tags, mit mindestens 2 anderen ways verbunden. Außerdem einige kreuzende Ways mit diesen Kennzeichen an einem Fleck. Damit ließe sich evtl. schon einiges an falschen Fehlern vermeiden.

Aus aktuellem Anlaß: *Werbeblock für meinen Vorschlag* (Link siehe oben). Den sollte man verbessern und z.B. die Kompatibilitätssacehn noch genauer ausarbeiten.

Fabi2 wrote:

mueschel wrote:

Die ganzen nicht baulich getrennten Spuren bräuchte es ja nach Einführung von area=highway nicht mehr. Der Grund für das Spurmapping ist ja im Moment nur die Optik und das Problem gibt es dann nicht mehr - das wären wieder nur lanes eines highways.

Soweit mir bekannt, ist area=highway ja die Abstraktion für die jeweilige Fahrbahn. Soll das jetzt gleichzeitig auch dfür benutzt werden um Spuren darzustellen? Gut, für OpenCarMap, mag das ausreciehn und was schert einen als Autofahren, ob die Fahrbahnen vielleicht in Wirklichkeit nur Fahrspuren sind, aber in Hinblick auf andere Anwendungen und auf die korrekte Abbildung der Realität, wo eben eine Fahrspur ja nun mal nicht das Gleiche ist wie eine Fahrbahn, kann ich diese Verwürfelung, wenn ich es jetztrichtig verstanden haben sollte, nicht begrüßen.

Ich meine das so: Wenn es nicht baulich getrennte Spuren sind, gibt es eine area und ein way. Der way ist mit entsprechenden lane:* Tags versehen um die Spuren wiederzugeben. Sind es baulich getrennte Spuren, so gibt es eine (oder mehrere, je nach Situation) Areas und in jedem "Ast" einen way, ggf. mit lane-Tags.
Damit ist sowohl die Geometrie (insbesondere Ausdehnung) durch die Area als auch die logischen Beziehungen durch die ways hinreichend wiedergegeben.

mueschel wrote:

Fabi2 wrote:

mueschel wrote:

Die ganzen nicht baulich getrennten Spuren bräuchte es ja nach Einführung von area=highway nicht mehr. Der Grund für das Spurmapping ist ja im Moment nur die Optik und das Problem gibt es dann nicht mehr - das wären wieder nur lanes eines highways.

Soweit mir bekannt, ist area=highway ja die Abstraktion für die jeweilige Fahrbahn. Soll das jetzt gleichzeitig auch dfür benutzt werden um Spuren darzustellen? Gut, für OpenCarMap, mag das ausreciehn und was schert einen als Autofahren, ob die Fahrbahnen vielleicht in Wirklichkeit nur Fahrspuren sind, aber in Hinblick auf andere Anwendungen und auf die korrekte Abbildung der Realität, wo eben eine Fahrspur ja nun mal nicht das Gleiche ist wie eine Fahrbahn, kann ich diese Verwürfelung, wenn ich es jetztrichtig verstanden haben sollte, nicht begrüßen.

Ich meine das so: Wenn es nicht baulich getrennte Spuren sind, gibt es eine area und ein way. Der way ist mit entsprechenden lane:* Tags versehen um die Spuren wiederzugeben.

Wie gibst du da z.B. eine Fahrbahn mit 2 Spuren und einer Radspur wieder? Die zusätzliche Fahradspur soll dabei aus einem einmündenden, baulich getrennten, Radweg hervorgehen.

mueschel wrote:

Sind es baulich getrennte Spuren, so gibt es eine (oder mehrere, je nach Situation) Areas und in jedem "Ast" einen way, ggf. mit lane-Tags.
Damit ist sowohl die Geometrie (insbesondere Ausdehnung) durch die Area als auch die logischen Beziehungen durch die ways hinreichend wiedergegeben.

Es reicht, wenn die Ausdehnung, also die Spurfläche, und die gemeinsamen Kanten (d.h., genauer: ein Weg mit min. 1 gemeinsamen Knoten) der möglichen Übergänge für bestimmte Verkehrsteilnehmer zu anderen Flächen definiert sind. Das erfüllt den gleichen Zweck wie deine zusätzlichen highways, welche man konstruieren kann, indem man z.B. die Mittelpunkte der Knoten der gemeinsamen Grenzwege bestimmt und miteinander verbindet. Ob man dann als Verkehrsteilnehmer x zwischen der flächigen Darstellung der Spur A zur Fläche von Spur B wechseln kann, sollte in der Relation angegeben werden, mit der genau diser Grenzweg an den Flächenübergängen definiert wird.

Kann man die Spurfläche nicht einzeichnen, wird die Fläche der jeweiligen Fahrspur (ob getrennt oder nicht ist bei mir egal, Sachen wie kerb=* könnte man optional da noch als Grenzwegrelation an die Flächenübergänge basteln) ersatzweise vereinfacht als Weg dargestellt.

Der Übergang zwischen Spur als Fläche und Spur als Weg wird bei meinem Schema dadurch realisiert, indem die Wegdarstellung der Fahrspur ersatzweise als modellhaft als Fläche aufgefaßt wird und man dann dafür wieder angeben kann, ob z.B. motor_vehicel, in Verlauf der Wegrichtung gesehen,nach links fahren darf. Links kann dann z.B. eine als Fläche gemappte Spur sein, womit klar ist, das dieser Übergang dann erlaubt ist.

Ein Bild sagt mehr als 1000 Worte.
Ein Vorschlag also:

Ich suche etwa vier verschiedene Situationen zusammen und dann kann jeder der sich hier aktiv an der Diskussion beteiligt aufmalen, wie er sich die richtige Lösung vorstellt. Ansonsten kann diese Disskusion für viele schwer nachvollziehar sein. Manchmal meint man das Gleiche nur beschreibt man es anders.

Ich habe erstes "Testgebiet" : http://osm.org/go/0HoNAi__O--
Dazu zwei Bilder:
Hitergrund: http://wiki.openstreetmap.org/wiki/File … rgBing.jpg
und
http://wiki.openstreetmap.org/wiki/File … gAreas.jpg als Begrenzungsflächen.
Da es verschiedene Ansätze für das Thema gibt, möchte ich Euch bitten die Skizze zu ergänzen, damit die Unterschiede einzelner Ideen, Auffassungen sichtbar werden.

Grüße,
Marek

mueschel wrote:

Fabi2 wrote:

Ich meine das so: Wenn es nicht baulich getrennte Spuren sind, gibt es eine area und ein way. Der way ist mit entsprechenden lane:* Tags versehen um die Spuren wiederzugeben.

Wie gibst du da z.B. eine Fahrbahn mit 2 Spuren und einer Radspur wieder? Die zusätzliche Fahradspur soll dabei aus einem einmündenden, baulich getrennten, Radweg hervorgehen.

Vor der Einmündung: Straße lanes=2 + Fahrradweg.
Nach der Einmündung lanes=3 access:lanes = ||bicycle
(Ja, das entspricht nicht der momentan Verwendung von access und müsste noch einmal genau durchdacht werden)
Es gibt (mindestens) 2 Areas, eines für die Straße, eine für den Fahrradweg vor der Einmündung.

Zum Beispiel von Marek:

Mal grob gezeichnet um meinen Punkt klarzumachen - keine vollständige Lösung.
Legende: Schwarz - highway:secondary (oder was genau passt); Blau - secondary_link

http://imageshack.us/f/12/osmkreuzung.png/

Links wie es üblicherweise bei Einzelspurmapping aussieht, rechts wie man die Ways vereinfachen kann wenn Areas für die Optik verwendet werden.
Jeder way muss mit lanes, turn:lanes, access:lanes ausgestattet werden - dann sehe ich keine Stelle an der nicht mit einfachen Mitteln klargestellt werden kann, welche Spur in welche mündet.

Punkt 1: Viel weniger Kreuzungspunkte.
Punkt 2: Routingsoftware kann Abbiegerichtungen sehr einfach bestimmen: wenn ein *_link im Spiel ist, nimm den Winkel zwischen dem letzten nicht-link vor der Kreuzung und dem ersten nicht-link nach der Kreuzung. In der herkömmlichen Variante ist das nicht so einfach möglich. Selbst wenn man diese Intelligenz nicht einbaut: Die Winkel zwischen zwei Linien sind sehr viel deutlicher als bei normalem Mapping.

Diese Kreuzung empfinde ich übrigens als relativ einfach - es gibt kaum Abbiegebeziehungen.

mueschel wrote:

mueschel wrote:

Fabi2 wrote:

Ich meine das so: Wenn es nicht baulich getrennte Spuren sind, gibt es eine area und ein way. Der way ist mit entsprechenden lane:* Tags versehen um die Spuren wiederzugeben.

Wie gibst du da z.B. eine Fahrbahn mit 2 Spuren und einer Radspur wieder? Die zusätzliche Fahradspur soll dabei aus einem einmündenden, baulich getrennten, Radweg hervorgehen.

Vor der Einmündung: Straße lanes=2 + Fahrradweg.
Nach der Einmündung lanes=3 access:lanes = ||bicycle
(Ja, das entspricht nicht der momentan Verwendung von access und müsste noch einmal genau durchdacht werden)
Es gibt (mindestens) 2 Areas, eines für die Straße, eine für den Fahrradweg vor der Einmündung.

OK, du splittest dann also den Weg, wenn ich es richtig verstanden habe.

Wenn ich die Maximalversion von meinem Vorschlag, was komplettes Flächenmapping aller unterschiedlichen (Verkehrs)Flachen der Kreuzung wäre (ich habe angefangen, mich dann aber lieber für 'ne bebilderte Doku entschieden), könnt ihr, bei der Komplexität, vor Weihnachten wahrscheinlich nicht mit einem Ergebnis rechnen, dafür hat die Kreuzung einfach zu viele unterschiedliche Sperr-/Verkehrsflächen und Landuses. Weil damit kann man nämlich die Realität mappen und muß sich nicht mit einer Einzellinienabstarltion mehrerer Spuren zufrieden geben.

Mein Schema (Doku, derzeit noch ohne Straßenmodell: https://wiki.openstreetmap.org/wiki/File:Glm-doc.pdf) kann man aber mit den richtigen Tools leicht maschinell erzeugen lassen. Ja, und es funktioniert, weil was kommt denn in der Praxis im OSM-Datenmodell bei Wegen/Spuren noch anderes vor als ein Übergang zwischen Linien, einer Linie und einer Fläche und mehreren Flächen?

Hi Mueschel und Fabi2,
ich werde Montag ebenfalls die Skizze fertigstellen.
Ich denke, es wäre schön die 3 Skizzen in einer Tabelle nebeneinander zu stellen, pros und cons aufschreiben und dann weiter gemeinsam überlegen. Vielleicht könnte noch jemand eine Skizze mit dem Lösungsvorschlag hinlegen?

Cobra?

Ansonsten stimmt - wir bräuchten noch für den Vergleich eine Standardkreuzung mit dem vorzeitigem Abbiegen nach links. Vielleicht diese: http://osm.org/go/0Oc0xvXsi-- ?

Fabi2 wrote:

Kann man die Spurfläche nicht einzeichnen, wird die Fläche der jeweiligen Fahrspur (ob getrennt oder nicht ist bei mir egal, Sachen wie kerb=* könnte man optional da noch als Grenzwegrelation an die Flächenübergänge basteln) ersatzweise vereinfacht als Weg dargestellt.

Für Borde gibt es bereits schon barrier= kerb in Verbindung mit height. In Linerichtung ist rechts unten und links oben. Das kann man so weiter nutzen und ggf. um Breite und die Angabe rechts und links ist unten usw., für breitere alleinstehende ohne zwischen liegende Fläche, ergänzen.

Ich bin schon dabei, so etwas und area:highway für meine ganze Ecke nachzutragen. Ich warte nur auf endgültig festgelegte Tags, die ich, wenn sich noch etwas ändern sollte, in einem Rutsch umstellen kann und dann wäre hier schon alles bereit für flächige Auswertung. Zu Kreuzungen kann ich leider nichts beisteuern, haben wir hier nur simple. Das einzige was im Moment brennt, ist Fläche über Fläche bei z.B. Brücken. Drüber legen mit Layer 1 oder was macht man? Und Mischnutzung wie z.B. ein Bahnübergang. Etwas eigenes wie z.B. area:highway + railway=yes für die Fläche des direkten Übergangs, also die Gleiseindeckung, oder nutzt man einfach area:highway + landuse=railway?

Das einzige was im Moment brennt, ist Fläche über Fläche bei z.B. Brücken. Drüber legen mit Layer 1..?

Absolut ja! Wobei es für ebene und NICHT steil auf/absteigende Fläche gelten soll. Ich werde es noch beschreiben. Stellen wir uns ein Verbindungsstück wie hier: http://osm.org/go/0HoOXPyHg-- vor. Sie sind im Grunde eine Rampe zwischen zwei Ebenen. Ein Tag dafür muss man noch erfinden, ab besten basierend auf den Höhenangaben benachbarter Ebenen... Vorschläge Eurerseits?

Hallo Marek,

marek kleciak wrote:

Ein Tag dafür muss man noch erfinden, ab besten basierend auf den Höhenangaben benachbarter Ebenen... Vorschläge Eurerseits?

da kommt das zum tragen, was mir in diesem Zusammenhang durch den Kopf schwebt: genau wie Straßen müssen auch Dämme und einschnitte als Fläche behandelt werden: z.B. area=embankment und area=cutting ggf. mit einer Höhenangabe. Das wäre meiner Ansicht nach konsequent.

Sven

marek kleciak wrote:

Absolut ja! Wobei es für ebene und NICHT steil auf/absteigende Fläche gelten soll.

Mir würde erst einmal etwas klares zu einer einfachen Brücke reichen. Da kann die normale Straßenfläche ja bis Ende Widerlager gehen, egal ob flach oder Rampe. Liegt zwar höher als die Umgebung ist aber bis ins Fundament noch die von der Straße eingenommene Fläche. Dazwischen, also der frei schwebende Teil zwischen den Widerlagern, den muss man entsprechend kennzeichnen und über die Fläche darunter bringen. Das sollte man so einfach wie möglich halten und von irgendwelchen komplizierten auseinanderdröselungen von Rampenflächen usw. absehen. Die kann man für komplizierte Spezialfälle vorbehalten, wo sich Spezialisten austoben können.

BTW sind mir doch noch schöne Kreuzungen eingefallen. Zum Beispiel Riebeckplatz in Halle http://osm.org/go/0MGFNthsU-- auch mit mehreren Ebenen, wobei man die schon entschärft hat. Leipzig hat auch einige schöne.

Ich denke, ihr solltet erst mal ein Pflichtenheft machen mit dem Inhalt, was alles berücksichtigt werden soll. Dann einen Schlussstrich unter die Anforderungen ziehen und dann schauen, wie man das in unser Datenmodell pressen kann.

Es nutzt nicht sehr viel, wenn man auf der einen Seite schon nach der Umsetzung sucht und auf der anderen Seite noch nicht weiß, was umgesetzt werden muss. Das endet dann in der Regel in einem Flickenteppich.

aighes wrote:

Es nutzt nicht sehr viel, wenn man auf der einen Seite schon nach der Umsetzung sucht und auf der anderen Seite noch nicht weiß, was umgesetzt werden muss. Das endet dann in der Regel in einem Flickenteppich.

Nicht nur das, am Ende wird soviel Zeit in das Ausfeilen von Sonderfällen investiert und man kann wirklich alles Komplexe darstellen, dass es zu kompliziert wird als das es dann jemals in der Breite wirklich angewendet wird. Für die vielleicht 3% des Straßennetzes die in Großstädten liegen, wo sich entsprechend viele Leute mit dem entsprechendem Wissen tummeln und die vielleicht 2% Spezialfälle ohne Frage etwas mehr verlangen, kann man gerne entsprechendes ausfeilen. Man darf aber auch nicht die restlichen 97% vergessen und da braucht es nicht kompliziert werden. Ja darf es auch nicht, weil das ansonsten kaum einer umsetzen wird. Denn alleine schon das Flächen zeichnen an sich ist wirklich aufwendig und um so weiter man in die Fläche kommt, umso weniger werden auch heute noch so spezielle Sachen wie Bordsteinhöhen etc. eingetragen.

Wenn man also eine weit verbreitete Anwendung wünscht, muss erst einmal eine einfache und für jeden zu verstehende Basis her. Darauf kann man dann tiefer gehendes aufsetzen und jeden entscheiden lassen, wie detailliert er vorgehen will bzw. überhaupt kann. Umgekehrt wird es häufig eher kompliziert.

@geokyf, @aighes: Volle Zustimmung.

marek kleciak wrote:

wir bräuchten noch für den Vergleich eine Standardkreuzung mit dem vorzeitigem Abbiegen nach links. Vielleicht diese: http://osm.org/go/0Oc0xvXsi-- ?

Ich hätte noch diese hier in Frankfurt: http://osm.org/go/0D0ZZE7Y9-- - insbesondere wegen der vielen Radspuren. Fotos gibt es ein sehr gutes bei Aerowest.

Zu schiefen Ebenen: Üblicherweise kann man unter solchen Verbindungen zwischen zwei Ebenen fast auf der ganzen Fläche auch untendrunter durchgehen (z.B. Treppe unter der sich Fahrradständer befinden). Ich denke man sollte beim bewährten layer=1 bleiben und die Höhe unter dieser Ebene genauer spezifizieren.

Ich denke, ihr solltet erst mal ein Pflichtenheft machen mit dem Inhalt, was alles berücksichtigt werden soll. Dann einen Schlussstrich unter die Anforderungen ziehen und dann schauen, wie man das in unser Datenmodell pressen kann.

+1

Es nutzt nicht sehr viel, wenn man auf der einen Seite schon nach der Umsetzung sucht und auf der anderen Seite noch nicht weiß, was umgesetzt werden muss.

Ekhm, ich weiß es (aus meiner Sicht natürlich) so ziemlich genau. Wir sammeln ja verschiedene Vorstellungen zusammen, um in Garching Alternativszenarien durchzuspielen und . Bitte um ein Wenig Geduld: es ist ja nicht schnell gemacht.

Hallo Marek, bitte nicht falsch verstehen, ich will euch nicht vorschreiben, wie ihr arbeiten sollt.

Voraussetzung wäre erstmal denke wie auch schon vor zwei (?) Jahren bei area:highway, dass die Flächen nur zusätzlich zu den vereinfachten highway=* existieren sollen.

Nun würde ich mir überlegen:
Was soll dargestellt werden können?
- Straßenflächen mit verschiedenen Oberflächenarten und allerlei weißen Linien
- ...

Wenn die Basisliste abgeschlossen ist, kann man dann anfangen und überlegen, wie man das simpel erfassbar, erweiterbar und auswertbar einträgt. Dabei muss am Anfang nicht gleich eine Lösung raus kommen, der jeden Spezialfall abdeckt.

Lieber Henning, so kam es auch nicht an, keine Sorge.

Ich möchte meinerseits, dass Alternativszenarien entstehen die verschiedene Optionen abdecken und dass wir in Garching entscheiden, welche Lösung für die Community voraussichtlich die vernünftigste ist - im Sinne einfacher Multiplikation durch die User.

Beste Grüße,
Marek

aighes wrote:

Ich denke, ihr solltet erst mal ein Pflichtenheft machen mit dem Inhalt, was alles berücksichtigt werden soll. Dann einen Schlussstrich unter die Anforderungen ziehen und dann schauen, wie man das in unser Datenmodell pressen kann.

Es nutzt nicht sehr viel, wenn man auf der einen Seite schon nach der Umsetzung sucht und auf der anderen Seite noch nicht weiß, was umgesetzt werden muss. Das endet dann in der Regel in einem Flickenteppich.

Ich empfehle auch, nicht nur an Kreuzungen und Straßen allgemein zu denken, sondern auch an Fuß- und Radwege.

In Augsburg habe ich von einem Rollstuhlprojekt der Uni mit der Stadt Flächen erhalten, die

• Bürgersteige darstellen mit Längs- und Querneigungsangaben sowie
  
• schmale Straßen ohne Bürgersteige (Altstadtviertel, Kopfsteinpflaster), bei denen in Straßenmitte ein 1m breiter etwa Paving-Steinorientierter Streifen für Radfahrer und Fußgänger/Rollis
  

vorhanden sind.

An deren Import in OSM habe ich vor einem Jahr erstmal verzweifelt, weil ich da area:highway noch nicht kannte. Details zu den Daten, wen es interessiert [1]

Habt Ihr Euch auf den Autoverkehr spezialisiert und wollt dafür eine Lösung oder können meine Anliegen auch schon berücksichtigt werden?
Je nach Terminsetzung für Garching könnte ich evtl. teilnehmen, weil aus Augsburg.

Viele Grüße

Dietmar aka okilimu

[1] http://wiki.openstreetmap.org/wiki/Augs … lit%C3%A4t

Fußwege erfasse ich ebenfalls schon flächig. Nur mit irgendwelchen Neigungen sind wir schon wieder bei absoluten Spezialinteressen für einen ganz kleinen Kreis. Maße kann man noch gut abschätzen bzw. im Bildmaterial mit bekannten Referenzobjekten einigermaßen genau abmessen. Aber es wird kaum einer mit einer Waage über den Bürgersteig kriechen. Mit meinem Tablet wäre das an sich kein Problem, der hat alle nötigen Sensoren direkt im Gerät, nur dauert die Erhebung ewig und man muss auch aufpassen, dass einen keiner beobachtet und das Auto mit den Eckigen Rädern ruft. 🤣

Sehe ich recht ähnlich. Ich denke es ist schon ein sehr großer Schritt, wenn man halbwegs flächendeckend die Straßen als Fläche zur Verfügung hat (Straßen meint hier allgemein Wege).

Die Neigung des Weges wäre für mich jetzt eher ein routing-relevantes Feature, was ich eher am Linienobjekt sehen würde.

Hallo Dietmar,
es geht um eine allgemeine Lösung. Navigation für Autos ist zwar wichtig, aber in meinen Augen sind Fußgängernavigation, Fahrrad- und Rollstulfahrer Anwendungen gleichwertig.

Die Querschnittsneigung des Weges zu messen ist in der Tat schwierig. Ich sehe hier schon in Verbindung mit der Oberflächeninformation, berechneter Kurve der Straße und der Autodagten die Möglichkeit ein Mehrwert zu generieren. Nur diese Daten zu erfassen wird wohl NOCH nicht einfach sein. Einige Mobiltelefone und einige Tablets erlauben das. Haben wir in Zukunft Tools die eine solche Datenerfassung im Freien ermöglichen, wird die Sache dann anders aussehen..

marek kleciak wrote:

Haben wir in Zukunft Tools die eine solche Datenerfassung im Freien ermöglichen, wird die Sache dann anders aussehen..

Das zu erheben ist eigentlich nicht das Problem, wenn auch extrem zeitraubend und und bei einigen Pisten ein Stückwerk an Daten. Die nötigen Werkzeuge hat der eine oder andere schon. Die Städte haben das einfacher, weil das schon vorab in der Bauplanung feststeht und die keinen dafür raus schicken müssen. Daher sind sicher auch die Daten von Dietmar.

Nur wie sieht das für uns aus? Nicht nur, dass man sich selber schon bescheuert dabei vorkommt, irgendeine OSM Weste macht es da eher noch schlimmer als besser, das gibt Fragen, bis hin das man für bescheuert erklärt wird. Deswegen bemühe ich mich schon immer fast schon auffällig unauffällig vorzugehen. Viel Bild und Video aus der Hüfte, wo es kaum einer bemerkt. Trotzdem wollte mir mal ein Schäfer, der wohl irgendwas zu verbergen hatte, meine Kamera über den Schädel ziehen. Zum Glück blieb mir bei der Hausnummernerfassung bisher wenigstens die Polizei erspart. Man kann vieles erfassen wollen und mir gehen die Ideen bei den erfassbaren Details auch nicht aus. Es gibt aber leider Grenzen. Und die fangen zum Beispiel da an, dass ich nicht auf einer unter Verkehr stehenden Kreuzung irgendwelche Vermessungen anfangen kann und die gehen bis dahin, dass man sich als Hobbyvermesser mit gewissen Aktionen komplett zum Obst macht. Wer da komplett schmerzfrei ist, kann das ja machen, nur dürften das nicht so viele sein.

Hallo Geokyf,
ich kenne dieses ungute Gefühl bei der Datenerfassung: Ich war mit einem der ersten 3D Laserscanner, einigen Meter Kabel und einem Autoakku vor dem Bundeskanzleramt. Es war lustig... Noch besser war es vor dem Jüdischen Museum in Berlin. 😉
Die Neigungsmessung sind nur dann möglich wenn ein App die GPS Spuren+Neigungswerte liefert. Voraussetzung: Ich fahre Auto und mein "Neigungserfassungsgerät" ist kalibriert.

So eine App ist sicher nicht so schwer zu bauen, brauchte bisher nur keiner. Das wäre etwas für den OSM Tracker, den ich sehr schätze. Nur wäre es kein Ding jetzt z.B. das Smart Tool her zu nehmen und in gewissen Abständen zu messen.

In Berlin mag das noch gehen. Da siehst du an jeder Ecke irgendwelche abgerissenen Typen und fällst gar nicht auf. Notfalls versteckst du dich in einer silber angesprühten NVA Uniform und verdienst nebenher noch Geld mit Bildern, hätte ich sogar noch Bestände zum einfärben im Keller. 🤣 Aber dort ist die Chance klein, das man sich zweimal sieht und es ruft auch keiner so schnell bei der Polizei an. Nur hier ist das wieder komplett anders. Da schaut jeder auf jeden, jeder kennt jeden, für die Datenhalter der Stadt bin ich fast schon so etwas wie Pussy Riot und da fällt schon einiges Flach. Selbst so simple Sachen wie Garagennummern sind ein Problem. Die werden hier oft hops genommen und da bist du schon verdächtig, wenn du nur zwei Sekunden zu viel auf eines der Tore schaust. Wenn ich könnte wie ich wollte, hätte ich hier schon bis zur Körnung der Hauswände alles erfasst. Für die Erfassung der Hydranten, Netzkopplungspunkte Gas und anderer Kleinteile, bin ich damals im Hochsommer Sonntag früh um 5 Uhr los. Die einzige Zeit, wo man hier mal nicht sofort beobachtet wird. 😄

Damals besuchte ich den Datenschutzbeauftragten des Landes und bat um einen Sechzeiler in dem erklärt wurde dass meine Arbeit gesetzeskonform ist. Auch hatte ich Flyer dabei die den Sinn der Arbeit erklärten. Im Zweifelsfall bat ich nervige Leute selbst, dass ich Polizei anrufe falls sie mich bei meiner wichtigen Arbeit stören.

Trotzdem: Du hast Recht, es gibt Gegenden, wo das Mappen absolut irritierend ist.
Wir werden uber pros und Cons für solche Daten reden, persönlich bin ich der Meinung, dass es noch ein Wenig zu früh für Neigungsprofile ist.

Geokyf wrote:

Zum Beispiel Riebeckplatz in Halle http://osm.org/go/0MGFNthsU--

In der Tat - als Beispiel sehr gut, die anderen die erwähnt wurden auch.
Bei dem Riebeckplatz bietet es sich an diesen Ausschnitt zu verbessern - ich meine Die Gebäudegrundrisse scheinen im Vergleich zu den Straßenmittelachsen verschoben zu sein. Was mir an diesem Beispiel gefällt ist die Treppe die so breit ist dass man sie eigentlich auch als Fläche zeichnen sollte. Ich mache einen eigenen Topic daraus.

Wenn du dort etwas ändern möchtest kannst du das ja gerne versuchen. Ich fasse da nichts mehr an, die Zeiten sind vorbei. Du darfst dich hier nicht großartig an Fixaktionen wie damals die massenhaft vorhandenen unverbundenen Straßen, falsche layer etc. oder Importaktionen wie ISIS beteiligen, wodurch zwangsläufig ganz fix die Bearbeitungen steigen. Und bloß nicht zu sauber Arbeiten, manch völlig unwissender dankt einem die Arbeit hinterher unter anderem so http://www.mail-archive.com/thueringen@ … 00357.html, bis in alle Ewigkeiten so nachzulesen und statt Sorry zu sagen, liest man hier lieber still mit.

Geokyf wrote:

Und bloß nicht zu sauber Arbeiten, manch völlig unwissender dankt einem die Arbeit hinterher unter anderem so http://www.mail-archive.com/thueringen@ … 00357.html, bis in alle Ewigkeiten so nachzulesen und statt Sorry zu sagen, liest man hier lieber still mit.

Ich bin ein Perfektionist um möchte exakt die Realität widergeben wenn die Daten vorliegen. Wenn das einer besser machen kann, soll er es tun, ansonsten bin ich da sehr dickhäutig 😉 Ein Hinweis dass Etwas zu genau ist - well, die Zeiten ändern sich, die Karte ist ja eben immer genauer und wir arbeiten daran, dass sie noch besser und genauer wird. Ich sehe da nichts Schlechtes...

Ansonsten vielen Dank für den Hinweis, Geokyf.

marek kleciak wrote:

Ich bin ein Perfektionist um möchte exakt die Realität widergeben wenn die Daten vorliegen. Wenn das einer besser machen kann, soll er es tun, ansonsten bin ich da sehr dickhäutig 😉

Das sind wir schon 2 und in der Regel kommt man sehr gut aus. Funktioniert aber nur so lange, bis man irgendwohin kommt, wo einem Protektionismus gepaart mit gepachteter Meinungshoheit und Geringschätzung entgegen schlägt. Dann sind Stunden an Arbeit mit einmal komplett gelöscht und gleich mal irgendwelche Vorwürfe im Raum. Weil ich beispielsweise Weichennummern eingetragen hatte, die jeder auf den Antrieben lesen kann. Aus heutiger Sicht zum totlachen, die Leute erfassen heute teilweise noch detaillierter. Und dabei ging es damals nur um etwas was heute lange normal ist, gleisgenaues Mappen. Das war selbst mir zu viel. Der Protektionismus war erfolgreich, aber den Schaden hatten dann letztendlich alle, die auf meinen Daten basierend weiter gemacht haben, umsonst.

Ich wünsche dir ne ganze dicke Haut und mach am besten einen ganz weiten Bogen um Köln und Umgebung. 😄

Für solche Fälle von "alles meins" und "das ist irrelevant, ich lösch das" haben wir mittlerweile andere Möglichkeiten außer Weglaufen.
Wer sinnvolle (und lizenzkonforme) Daten löscht, wird schnell wegen Vandalismus gesperrt. Durch die Probleme beim Lizenzwechsel ist auch das Bewusstsein für problematisches Verhalten stärker - ob es Massenedits, Importe oder Cut'n'Paste ist.
Wenn ihr euch also an die üblichen Spielregeln haltet und irgendein anderer Mapper meint, euch dafür ans Bein pissen zu müssen (egal in welcher Form), kriegt der eine drauf.

Dicke Haut habe ich, ganz lieben Dank!

Ich war damals nicht dabei. Zwar beobachtete ich OSM so ziemlich von Anfang an, habe mich aber nicht an den Diskussionen beteiligt. Ich kann also schlecht mitreden. Das Projekt ändert sich aber kontiniuerlich. Was damals einem vielleicht merkwürdig schien, ist heute selbstverständlich.
Und eines habe ich über die Jahre gelernt: Wenn Du Etwas ändern/weiterentwickeln möchtest, MUSST Du Dicke Haut haben. Ich habe erst nach Jahren begriffen, warum viele Leute bei der Innovation skeptisch sind und zum Teil auch Recht haben:
Ich begutachte nun selbst die Innovation: Auf meinem Schreibtisch landen Patentideen aus vielen Länder und Kontinenten. Immer wieder ist es so, dass Ideen geliefert werden, die sich entweder technich nicht verwirklichen lassen, nicht finanzierbar sind oder in einem andern Kontext bereits existieren. Es fällte dann einem schwer dies zu erklären, zumal die Leute meistens sehr von der Idee überzugt sind. Es gibt ja aber immer wieder Fälle wo mich jemand überzeugt und nachweist, dass ICH falsch lag. Ich schätze solche Menschen sehr. Sie bringen die Firma nach vorne.
Nun, die Mehrheit sieht eben viel Arbeit, die jetzt und heute erledigt werden muß. Die Innovatoren sind für sie gewissermaßen diejenigen die kontraproduktiv sind: Binden nötige Ressourcen und machen Etwas was von dem Rest abweicht. nun muß man wissen, dass es unter Innovatoren auch tatsächlich mal wieder Verrückte gibt. Das erschwert die Arbeit. Daher: einfach geduldig und beharrlich an der Sache arbeiten, zuhören, diskutieren und keineswegs böse werden. Alle wollen eine bessere Karte und früher oder später setzen sich die neuen Gedanken durch.

Cobra wrote:

Für solche Fälle von "alles meins" und "das ist irrelevant, ich lösch das" haben wir mittlerweile andere Möglichkeiten außer Weglaufen.

Gab es damals nicht und ich stand so ziemlich alleine. Ich hatte sogar noch angeboten Frederik, als einen neutralen in der Sache, Quellen offenzulegen. Weil ich es nicht einsah, einem BerndW noch alles mit Schleifchen auf den Tisch zu legen, damit ich dort arbeiten "darf". Zumal er ja auch gar keine Diskussion anfing, sondern in ganz schlechtem Stil gleich über Nacht kommentarlos löschte. Ging man nicht einmal darauf ein. Darauf hin habe ich den Rest dort, bis auf die Geschäfte im HBF Köln, Coloneum und weniges anderes, wieder revertet, weil man es wohl sowieso gelöscht hätte und habe einen Strich drunter gezogen. Ich hätte aber vielleicht weiter gemacht und sogar dem Wechsel zugestimmt, wenn es dann nicht noch lange nach meiner Abwesenheit munter weiter gegangen wäre. Eben solche Legenden wie oben im Link oder das z.B. BerndW es sich nicht verkneifen konnte, bei jeder Erwähnung meinerseits, stets und ständig auf die, nach seiner subjektiven Meinung, Zweifelhaften und für ihn Sinnlosen Detailarbeiten hinzuweisen, waren dann der Point of no return. Umso mehr finde ich es jetzt urkomisch, dass BerndW meine damalige und durch den Wechsel verloren gegangene Grunderfassung in der DomRep per Bing zu wiederholen versucht. Die Bilder hätte ich noch alle, ebenso die Tracks. Aber da das ja sowieso zweifelhaft und sinnlos war, viel Spaß beim so abmalen. 😄

Hallo Mirko

Auch von mir ein herzliches Willkommen zurück, ich freue mich auf eine friedliche Zusammenarbeit mit Dir.

Aber ich habe nichts dagegen, dass Du in Köln mappst, unser Disput sollte aber damals, das gilt auch heute noch. nicht in Öffentlichkeit gehen. Du solltest Dich zumindest überzeugen, ob jemand auch die ML liest, wenn Du ihn schon anschwärzt

Und ich habe auch nicht tagelange Arbeit vernichtet, sondern 8 Gleisstücke, beim revertieren hast Du mehr entfernt.

😉

Bernd

Na, dann auf´s Neue liebe Freunde! 🙂

Wer zu viel nach hinten schaut, stolpert.

Viele Grüße,
Marek

Hallo Bernd,

das mit der Öffentlichkeit hatte sich schon damals erledigt. Ich habe alles nachgelesen und lasse das damals wie heute auch nicht auf mir sitzen. Wie viel letztendlich gelöscht wurde, es war mehr und da war ja auch noch jemand weiteres involviert, oder nicht, spielt auch keine Rolle. Da kann man drüber reden, aber definitiv nicht einfach kommentarlos in die Rundablage damit, hinterher auf unerwünschte Details verweisen, dann einfach mal eine Anschuldigung in den Raum stellen und hinterher auch noch nachtreten, wenn derjenige schon lange nicht mehr dabei ist. So sollte es definitiv nicht laufen.

Wie dem auch sei. Der Schmarren wurde zuhauf gepostet und den bekommt man leider nicht mehr aus den Archiven. Das Ding ist gegessen und um Köln brauchst du dir auch keine Sorgen machen, da bleibt das GPS daheim. Ich konzentriere mich nur noch auf die Wiederherstellung und Anpassung an neues in meinem kleinen Eckchen, bis da endlich mal wer anderes lokales kommt und weiter macht. Die Hilfe bei den Grenzen war nur eine Ausnahme und ansonsten fasse ich nichts weiter mehr an. Neue Ideen zum Detailtagging sind auch nicht zu befürchten, das überlasse ich anderen.

Gruß
Mirko

Mirko

Wenn Du mal nach Köln kommst, bring das GPS mit, wahrscheinlich gibt es dort noch Stellen die ich auch noch nicht kenne.

Alles andere zwischen uns dürfte überwiegend aus Missverständnis passiert sein und sollte im Nebel der Vergangenheit verschwinden

Bernd

Hallo Bernd,

so oft komme ich da nicht hin und Köln kennst du sicher 10 mal besser wie ich. Da kann ich, nach 2 Jahren und vielen dort aktiven und nachdem man dort nun so gute Bilder hat, dass man sogar die PZB Magneten in den Gleisen von oben erkennt, sicher nichts mehr beisteuern. Alles andere ist, wie schon gesagt, Schnee von gestern.

Gruß
Mirko

Da kommt man nach drei Wochen Urlaub mit OSM-Enthaltsamkeit im Interesse des Familienfriedens sowie einer Woche Seminar ohne Chance, das Forum zu besuchen wieder und findet diese Diskussion 😎
Da mich das Thema auch beschäftigt, werfe ich jetzt einfach auch meinen Ansatz vom Jahresbeginn in den Ring:
http://forum.openstreetmap.org/viewtopi … 18#p223018

Ich dachte zwar Mitte August, ich könnte das Fallbeispiel schnell diskussionsfähig machen und veröffentlichen. Wurde aber leider nix draus 🙁 Vielleicht klappt es diese Woche.

Ich denke, mein lane-Modell könnte mit Ergänzungen durchaus dazu dienen, parallel zu einem Flächenmodell für das rendering, die routing-Fähigkeit zu verbessern und den bisher üblichen "Missbrauch" der highway=* für die Spurbildung zu ersetzen.

@marek:
Du kennst das ja schon 😉

hurdygurdyman wrote:

...
Ich dachte zwar Mitte August, ich könnte das Fallbeispiel schnell diskussionsfähig machen und veröffentlichen. Wurde aber leider nix draus 🙁 Vielleicht klappt es diese Woche.

Ich denke, mein lane-Modell könnte mit Ergänzungen durchaus dazu dienen, parallel zu einem Flächenmodell für das rendering, die routing-Fähigkeit zu verbessern und den bisher üblichen "Missbrauch" der highway=* für die Spurbildung zu ersetzen.
...

Ich hab's fertig 🙂
Da es weniger um Flächen zur optischen Darstellung als um Spuren für routing geht, obwohl es zur Gesamtproblematik gehört, habe ich das alles hier
http://forum.openstreetmap.org/viewtopi … 07#p276007
veröffentlicht, denn unter dem Thema "Spurmapping" passt die Diskussion wohl besser.