Strassen als Fläche

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:

Geändert.
Wie in #129 geschrieben: Macht bitte bei dem Proposal aktiv mit.

Grüße,
Marek

Und so sieht die a:h in der Ukraine aus:

http://osmapa.pl/w/areaua/?lat=48.6&lon=30.9&zoom=6&ol=BP

Wenn ich in dieses Beispiel aus der Ukraine hineinzoome, finde ich hier in der Mitte des Kreisverkehrs einen Supermarkt, der als zur Straßenfläche zugehörig eingezeichnet ist.

Ebenso finde ich hier auch die Waldstücke zwischen den Fahrbahnen als a:h eingezeichnet.

Meine Vorstellung war, nur die asphaltierten Flächen bzw. höchstens auch die angrenzenden Fußwege als a:h einzuzeichnen.

Franz

Lieber Marek, ich bin kein Gegner von a:h und habe es selbst schon vor mehr als zwei Jahren benutzt.
Ich bewundere dein Engagement in dieser Sache.
Bei der allgemeinen Euphorie dieses Tag sofort zu beschließen fehlte jemand, der auf die (sinnvollen!)
Formalien hinwies und kritische Fragen zum Proposal stellt. Diese Rolle habe ich dann übernommen.

Das obige Beispiel ist gut. Es wäre schön, wenn ein Renderer alle Tags der Straße darstellt und ein anderer a:h darstellt.

Deine Frage

hatte ich interpretiert als:
Ob wir eine eigene Fläche für die Kreuzung brauchen, die als junction oder roadclass getaggt wird, oder wir die von flaimo vorgeschlagene einfache Variante ohne Zusatzfläche haben wollen.
Diese Frage halte ich weiterhin für diskussionsbedürftig.
Die Begründung im Proposal “More flexible rendering possible…” stimmt nur teilweise, da sie die in Stadtplänen übliche Darstellung gerade nicht erlaubt.

Im Proposal fehlt noch eine Definition, wo genau die Grenzen der “crossing area” liegen.
Soll jede Einmündung als “crossing area” erfasst werden? Auch “service” und “track”?

Hallo Franz,

ich bin aus der Ukraine und kann dir antworten.

Dort sind area:highway=* falsch bezeichnet. Sie werden in Zukunft korrigiert sein.

Deine Vorstellungen sind hier richtig.

Viele Grüße
Eduard.

Habe ich schon auf polnische Forum nachgefragt und von Marek weiß, dass es genau ohne service und niedriger sein sollte. Also residential, unclassified etc.