Strassen als Fläche

Hallo Athemis,

der Proposal lag ruhig rum und die Leute haben angefangen zu mappen.
Wenn jemand verspricht die über Tausend a:h=crossing Dinge mit einem Bot umzutaggen dann können wir das mit der Änderung im Proposal natürlich gerne tun.

Deine Argumente verstehe ich, die machen auch Sinn. Nun, es ist bereits passiert. Was nun?
Ach so, schick mir bitte Kreuzungsbereiche die aus Düsseldorf die aus Deiner Sicht problematisch sind.
Wir können uns das gern gemeinsam ansehen.

Viele Grüße und danke für Deine Edits!

Marek

Hallo Marek,

Das sehe ich nicht so problematisch. Umtaggen geht per Bot sobald das Proposal akzeptiert wurde notfalls noch immer :wink: Das ist die Gefahr, wenn man nach einem Proposal taggt. Das ist in der Regel ein “bewegliches Ziel”, Änderungen können (wenn sie gut begründet sind) vorkommen. Ähnliches hatten wir ja auch mit dem ÖPNV-Tagging. Es wurde bereits im Proposal-Status (OXOMOA bzw. PTP2) danach getaggt und im Diskussionsprozess bis zur endgültigen Annahme dann noch diverse Dinge verändert. Der Auf- und Umräumprozess dauert bekanntlich bis heute an :stuck_out_tongue:

Das mit a:h=crossing ist ja kein Problem, dass nur Spezialfälle betrifft. Es wird auch einwandfrei funktionieren, wenn es alle so einsetzen, wie vorgesehen, aber genau da sehe ich das Problem. Es ist geradezu prädestiniert für Missverständnisse und falschen Gebrauch, wenn man vom “normalen” Straßenmapping anhand von Linien kommt und es dort bereits ein highway=crossing gibt, das aber eine völlig andere Bedeutung hat. Du orientierst Dich ja in Deinem Proposal an den althergebrachten highway-Tags, was die Benutzung enorm vereinfacht, da man im Prinzip nicht umdenken muss, sondern einfach die bestehende Linie mit einer Fläche umgibt, entsprechend taggt und dem “highway” ein “area:” voranstellt. Da ist dann das a:h=crossing ein unschöner Bruch und wird sicherlich zu Verwirrung führen.

Da Du ein Beispiel möchtest, hier wäre eines: http://www.openstreetmap.org/#map=19/51.17597/6.80997
Ich habe dort einmal testweise versucht die Straßenflächen zu erfassen. Die Kreuzungsfläche habe ich dort aber zwar separat für “a:h=crossing” erfasst, aber zunächst nur mit “a:h=yes” getaggt. Im Kreuzungsbereich befinden sich mehrere Fußgängerüberwege. Wie gesagt, das kommt sich alles rein formal nicht ins Gehege, aber intuitiv sträubt sich alles in mir, einen Tag der highway=crossing beinhaltet doppelt in unterschiedlichen Bedeutungen zu verwenden.

Eine ultimative Lösung kann ich natürlich nicht anbieten, wie Du ja anmerktest, wird der Tag schon häufig benutzt. Das ändert aber nichts daran, dass er vermutlich nicht optimal ist. Da es sich aktuell noch um ein Proposal handelt, kann sich eigentlich niemand beschweren, wenn Du Dich in diesem Stadium entscheidest, Ungereimtheiten auszubügeln. Meine Befürchtung wäre nämlich, dass sich spätestens in der Abstimmungsphase jemand an genau demselben Punkt abarbeitet und das einem dann im Abstimmungsergebnis auf die Füße fällt. Allerdings sind bis dahin dann noch einige Tausend Einträge mehr hinzugekommen, die man dann auch noch ändern müsste. Ergo: Wenn ändern, dann so bald wie möglich :slight_smile:

In Kürze:
Was denken die Anderen hier im Forum? Wenn´s machbar ist dann habe ich nichts dagegen.

Zu der Kreuzung:
Alles gut gemacht, mach weiter :wink:

Hallo zusammen,

ich wähle area:highway=junction statt area:highway=crossing. Ich bin ganz einverstanden mit der Argumenten von Athemis.

Viele Grüße
Eduard

hmm, area:highway=junction please :wink:

In diesem Jahr wurden ein Link und ein Leerzeichen geändert.
Natürlich sind in der RFC Phase Korrekturen möglich. Dafür ist sie da. Aber neue Vorschläge sollten nicht mehr eingefügt werden.
“kerb” ist natürlich kein Beispiel für ein erfolgreiches Proposal. :wink:

Die dunklen Straßenflächen finde ich eher unschön.
Bis z=18 bevorzuge ich die klassische Darstellung.
Bei z=19 rendert die Standardkarte die Straßen zu dünn, aber das ließe sich auch noch korrigieren.
Aber der Vergleich zweier gerenderter Karten entscheidet nicht über den Sinn eines Datenkonzepts.

Die Vorteile solltest du uns nennen.
Ich sehe folgende Nachteile:

  • es existieren zwei inkompatible Vorschläge
  • die Mapper müssen eine zusätzliche Fläche erstellen
  • auf vielen Stadtplänen sind Haupt- und Nebenstraßen unterschiedlich gefärbt.
    Die Hauptstraße ist dann auf der Kreuzung mit konstanter Breite gefärbt, die Einmündungstrichter in der Farbe der Nebenstraße.
    Eine solche Darstellung wäre ohne a:h=junction möglich, mit dieser Fläche kann man nur die gesamte Kreuzung wie die Hauptstraße färben.

Ja, danke :slight_smile:

Technisch ein Vorbild: Ja.

Aber man sieht hier das Problem von Luftbildmappern bzw. man kann die Karte auf diesem Niveau nicht aktuell halten. Der komplette Kreuzungsbereich wird seit längerem massiv umgebaut und schaut derzeit nicht mehr so aus - und wird nicht mehr so werden. Und jetzt müsste ich das anpassen, was wegen fehlender Luftbilder nicht geht, oder das jetzt Falsche löschen!? Geht das überhaupt, wenn in kürzester Zeit der nächste Luftbildmapper das wieder “ergänzt” :roll_eyes:

PS: An der Antalyastraße ganz in der Nähe habe ich die “ganz frisch” vom Luftbild abgemalte Straßenfläche grob an die mittlerweile geänderte Realität angepasst. Bin gespannt, wie lange das dauert, bis das wieder nach Luftbild korrigiert wird…

PPS: Bei der Hoffläche des Autohauses sollte man sich auch entscheiden, ob die Parkplatzflächen jetzt Teil von area:highway sind. Teilweise sind nur nur die Zufahrtsflächen zu den Stellplätzen inbegriffen, teilweise sind die Stellplätze Teil der “grauen Fläche” - was nun? Oder ist “area:highway” nur ein verbrämtes “surface=paved+highway=*”??

note=
Machen wir doch oft bei Gebäuden die “abadoned” sind, damit sie keiner “neu” erfindet.
Das Problem mit dem Ältern der Daten verschärft sich natürlich generell umso mehr wir in Detail gehen.
Wir können es nur durch mehr Mapper wettmachen. Aber die Tendenz gibt es glücklicherweise.

Nein, sind nicht. Proposal: amenity=parking_space - drawing of parking areas along the street.
Zugegeben, icht im Sinne des Erfinders weil er hier nur Einzelparkplätze vorgeschlagen hat.
Ich fand aber in Erlangen (ein Dorf nördlich von Nürnberg :wink: ) Flächen die so getaggt wurden, dies brache mich auf die Idee: warum nicht, wenn dies schon so verwendet wird für kleiner Parkflächen?

PS: Ich schätze Deine sachliche Bemerkungen. Du bist dabei nicht persönlich sondern kümmerst Dich um die Sache. Darf ich Dich bitten sonstige Details der a:h in Nürnberg zu checken?

Grüße,
Marek

parking_space sollte wenn möglich immer einzeln getaggt werden und dann alle spaces mit einer Relation verbunden werden. Es ist aber auch erlaubt mit “capacity” mehrere spaces zusammen zu fassen. Den Kompromiss bin ich beim Verfassen des Proposals damals eingegangen. Das Proposal ist aber eher für komplexe Parkmöglichkeiten gedacht. Für einfache kleine Parkplätze solltest du meiner Meinung nach beim alten amenity=parking bleiben.

Ich finde die Farbe auch zu dunkel, allerdings ist diese Darstellungsart m.M.n. nur für den höchsten Zoom-Level sinnvoll.
Straße zu dünn, z=19: Na ja, das ist eben ein Dilemma. Ich muss es wiederholen: Es ist praktisch unmöglich, eine “richtige” Breite zu finden außer man macht´s dünner. Die Logik des Grafenroutings zwing uns zu generalisieren, und da passiert es, dass die Mittelachse Straße gar nicht richtig “sitzt”. Macht man sie zu dick, verdeckt sie andere Elemente. Es ist kein Zufall das Here eine Technologie entwickelt bzw. entwickelt hat, mit der das Erfassen der Außenkante Straße möglich ist.

Die Straßendarstellung als Mittelachsen sollte für alle Layer bis auf den höchsten erhalten bleiben.
Auf dem höchsten Zoom Level spielt es keine Rolle welche Straßenkategorie das ist die Färbung zeigt: Dies ist Asphalt, dies ist ein Gehrweg, dies ist ein Radweg… Für die Orientierung in einer unbekannten Kreuzung ist eine solche Darstellung hilfreich, ebenso für Fußgänger.
Diese Art der Erfassung macht das Navigieren für blinde Passanten besser:
Die Flächendarstellung zwingt zu mehr Präzision beim Erfassen der Daten und kann das Melden “Du bist auf der Außenkante Straße bzw. Du gehst gerade quer durch den Fahrradweg” erleichtern.
Ich habe gelernt das a:h Mapping viel Zeit in Anspruch nimmt. Man braucht Geduld, aber man korrigiert dadurch an vielen Stellen die Karte. Ein Gebäude das auf einem Fußweg mit einer Ecke liegt, weil es mit alten Yahoo Bildern abgezeichnet wurde, fällt sofort auf.

Nicht unbedingt. Ich halte mich nicht für schlauer als der Rest der Mapper. Sie sollen entscheiden.

Ich habe den Vorschlag A. gemacht: a:h=crossing + crossing=roadclass
Athemis machte den Vorschlag B: a:h=junction + junction= roadclass

Um ganz ehrlich zu sein, kann ich persönlich mit beiden Vorschlägen leben.

Wer ist für A, wer ist für B ?

Bin für a:h=junction.
Crossing ist recht zweideutig, sollte lieber wie bisher auch für Übergänge verwendet werden.

+1

Die visualisierung der turn:lanes geht wieder, ich hinterlege ein Screenshot für alle Fälle. Marimil werkelt an dem Thema weiter.

http://wiki.openstreetmap.org/wiki/File:MarekCrossingVisualizationMarimil.JPG

Hallo,

Ich möchte mich gerne auch einarbeiten in die Materie und euch dabei nicht “ins Gehege” kommen.
Da ich mich in Nürnberg auch tlw auskenne, habe ich mir mein “Hotel-Gebiet” ausgesucht.
Kann ich dort “fuhrwerken”, sprich das tagging ausprobieren, ohne Konkurrenz?

http://www.openstreetmap.org/#map=17/49.46088/11.07709

Anh.: Oh Je , da gibt es ja massenweise Gebäudekorrekturen nachzuarbeiten. Ok. Muss ja gemacht werden…

Sicher Rogehm,
da gibt es extrem viel zu tun. Ich werde hier werkeln:
http://osmapa.pl/w/areade/?lat=49.43315&lon=11.0431&zoom=15&ol=PB

Aus Polen kamen zwei Mal für a:h=junction sonst Enthaltung.
Wenn dies mit Bot machbar ist ( a:hcrossing-> a:h=junction), sollten wir uns drum kümmern.
Wer kann es umsetzen?

Hallo Marek,

Danke, werde ich :wink:

Das Umtaggen per Bot sollte der allerletzte Schritt sein. Wichtig wäre, zunächst das Proposal im Wiki entsprechend anzupassen und die Änderungen auch in den Kreisen zu kommunizieren, die das Schema aktuell bereits anwenden, um zu vermeiden, dass a:h=crossing bei neu erfassten Kreuzungen verwendet wird. Soweit ich das sehe, wären das vor allem die polnische und die deutsche Community.
Da es bezüglich des Proposals offensichtlich Diskussionsbedarf und einige Baustellen gibt, wäre ich mit einem mechanischen Edit zu diesem Zeitpunkt sehr vorsichtig. Wenn das Proposal irgendwann in einer bestimmten Fassung angenommen ist, kann man darüber nachdenken, per Bot entsprechend der Mechanical Edit Policy die jeweiligen Anpassungen an das verabschiedete Schema vorzunehmen, aber solch eine mechanischer Bearbeitung muss gut begründet sein. Meiner Meinung nach reicht ein in Entwicklung befindliches Proposal als Grundlage da nicht aus. Darüber hinaus muss das auch auf der Mailing-Liste angekündigt und diskutiert werden. Auch da wäre meine Vorhersage, dass ein Proposal dort nicht aus ausreichender Grund angesehen würde.

Kurz:

  • Wenn a:h=crossing zu a:h=junction geändert werden soll, muss dass möglichst schnell im Proposal umgesetzt und die Personen, die nach dem Schema taggen über die Änderung informiert werden, damit sich nicht mehr a:h=crossing ansammeln.

  • Mechanischer Edit per Bot macht meiner Meinung nach erst nach Verabschiedung des Proposals Sinn und ist vorher auch problematisch zu begründen.

Beste Grüße

Alex

Hallo Arthemis,
danke :).

Also ändern wir die Kreuzungsdefinition in:

area:highway=der höchste Wert der highway im Kreuzungsbereich
+
junction=yes/roundabout/y_junction

richtig?

Wenn ja, dann lade ich Dich zum Editieren und Bereinigen des Proposals ein. Wie schon geschrieben, ich halte mich für nicht schlauer als die Anderen und ein so wichtiges Thema soll ein gemeinsames Werk sein.

PS: Lieber Seawolff, sieh Dir bitte dies an: http://www.openstreetmap.org/way/319492481
deswegen wird es nie mit einer Straßenbreite als Funktion der Anzahl der Fahrspuren klappen.
Man müsste noch zusätzlich definieren wieviele Farspuren links bzw. rechts von der Mittelachse sind und selbst dann decken wir die Übergangsbereiche nicht richtig ab.

Da ist man mit a:h einfach schneller und generiert saubere Ergebnisse.

Grüße,
Marek

Würde ich sagen, außer, es gibt begründete Einwände dagegen :slight_smile: