Strassen als Fläche

…und wenn kein surface vorhanden, dann bitte rot-grün kariert rendern… was meinst du, wie schnell dann Surface da ist… :smiley:

:slight_smile: :slight_smile: :slight_smile: :slight_smile: :slight_smile: :slight_smile: :slight_smile: :slight_smile: :slight_smile: :slight_smile: :slight_smile: :slight_smile:
Du hast mir den Tag gerettet streckenkundler.
Soll ich das in den Proposal aufnehmen? :stuck_out_tongue:

Hallo zusammen,

die Idee, die Straßenfläche zusätzlich zu erfassen finde ich auch spannend! Beim Einarbeiten in den Vorschlag ist mir allerdings folgendes aufgefallen (ich bitte um Korrektur, falls ich das schlicht falsch verstanden haben sollte):

Kreuzungsbereiche sollen, wenn mehr als 3 Wege aufeinandertreffen mit “area:highway=crossing” getaggt werden. Das halte ich persönlich für unglücklich gewählt, denn wir verwenden ja bereits highway=crossing für die Auszeichnung von Übergängen für Fußgänger und Radfahrer. Das macht die ganze Sache meiner Ansicht nach unintuitiv, da gleichlautende Werte für zwei unterschiedliche Dinge verwendet werden. Ist das eventuell auf eine direkte Übersetzung von “Kreuzung” und “crossing” zurückzuführen? Meiner Meinung nach wären a:h=junction (mein Favorit, da junction=* bereits in diesem Kontext genutzt wird) oder a:h=intersection besser geeignet. Wenn es denn unbedingt etwas mit “crossing” im Namen sein soll, böte sich a:h=street_crossing an :wink:

Beste Grüße

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?