Strassen als Fläche

Rogehm · 2015-08-23 14:11:08

Eigentlich bräuchten wir dafür was Neues. Habt Ihr Vorschläge?

Wir sollten hier nicht zu viele Sachen neu einführen. Rein theoretisch wäre das tag schon gut geeignet dafür mit Änderung der Beschreibung. Probleme: Es wird nirgendwo gerendert und das tag ist approved. Also da kann man höchstens eine Erweiterung beschreiben. Diese Flächen als amenity=parking zu markieren, halte ich für die schlechtere Lösung. Dann spiekt es später überall mit kleinen gelben Flächen.

Oft sind es ausgewiesene Anwohnerparkplätze, wo ich auch noch nichts gefunden habe. (access=private passt ja auch nicht, höchstens access=residents)

edward17 · 2015-08-23 17:32:16

Hallo,

ich habe 2 Plätze in Wiki-Seite gefunden, die meiner Meinung nach korrigiert sein sollen:

1. Applies to: - ich denke, dass {{IconArea}} dort hinzugefügt sein soll.
2. In Tagging:
"highway=footway with footway=yes" -> "highway=footway with footway=crossing", nicht wahr?

Rogehm · 2015-08-23 18:39:32

Also, ein area tag mit footway funkt. auch über die mapnik-Standardkarte: https://www.openstreetmap.org/#map=18/50.96122/6.97771
Hier im Kölner Zoo hatte ich zuerst ein pedestrian getaggt. Es geht aber auch mit einem highway=footway + area=yes.
Man muss sich überlegen und noch weiter austesten, ob footway areas insgesamt getaggt werden können mit rendering, auch mit weiteren Attributen und wie das routing funktioniern könnte.. Bin hier noch nicht ganz sicher.
Möchte auch gerne in Köln den angrenzenden Park "Flora" mit flächigen Wegen taggen. Teste die Tage dies aus.
Also, wenn die Flächen eines Footways in verschiedenen Möglichkeiten gerendert werden, muss man sich da gegenseitig anpassen, oder? Doppeltagging wäre imho nicht sinnvoll.

Edit

Last edited by Rogehm (2015-08-23 19:46:20)

seawolff · 2015-08-23 21:30:33

Rogehm wrote:

Also, ein area tag mit footway funkt. auch über die mapnik-Standardkarte: https://www.openstreetmap.org/#map=18/50.96122/6.97771
Hier im Kölner Zoo hatte ich zuerst ein pedestrian getaggt. Es geht aber auch mit einem highway=footway + area=yes.

Dass "highway=*" mit "area=yes" von Mapnik dargestellt wird, ist nicht neu.
Es ist aber nicht der Sinn von OSM eine bestimmte Darstellung durch Mapnik zu erreichen (siehe auch DE:Taggen für den Renderer).
Auch "layer=1" dient nicht dazu, ein bestimmtes Renderergebnis zu erzwingen.

In OSM hat man sich dafür entschieden, Wege als Mittellinie zu erfassen.
Eine doppelte Erfassung ist nicht sinnvoll und schafft viele Probleme.
Deshalb entstand der Vorschlag, die Fläche der Wege mit a:h und nicht mit "highway" und "area=yes" zu taggen!

Also, wenn die Flächen eines Footways in verschiedenen Möglichkeiten gerendert werden, muss man sich da gegenseitig anpassen, oder?

Ja, man muss "highway=footway", "area=yes", "layer=1" schnellstmöglich löschen.

Der Kölner Zoo scheint an vielen Stellen für den Renderer gemalt.
Es gibt Attraktionen mit Namen "Luftballons" und "Bollerwagen", einen Teich der "Wasservögel" heißt und
ein Objekt namens "Persischer Wildesel", das gleichzeitig Attraktion, Sandfläche, Tier und Zaun ist und
sich zwischen einem Baum am Boden und einer Grasfläche auf Level 2 befindet.

Rogehm · 2015-08-23 21:59:28

Dass "highway=*" mit "area=yes" von Mapnik dargestellt wird, ist nicht neu.
Es ist aber nicht der Sinn von OSM eine bestimmte Darstellung durch Mapnik zu erreichen (siehe auch DE:Taggen für den Renderer).

Ja, und? Dann ist es doch gewollt. Sonst würde es nicht gerendert. Man könnte hier auch für andere Renderer taggen, z.B. Ist das Gebäude im Nachbar Area "Flora" für F4 getaggt.
Hat man damit ein Problem?
Die Wege sind alle als Mittelinie erfasst. Das "Rand" Routing ist so oder so nicht zu bewältigen, egal ob pedestrian oder footway. Da müssten die Routerprogramme sich was überlegen.
Hier wird erstmal nichts gelöscht. Entweder sind die Wege "Flächen" als "Footway" oder als "Pedestrian". Die anderen Fehler im Zoo werden noch behoben.
Ich sehe hier erstmal Konflikte zwischen dem Mapnik Stile und dem hiesigen Proposal.

Kontinentalverschieber · 2015-08-23 22:12:14

Zu welchem Blödsinn das führt, so wie im Kölner Zoo derzeit getaggt ist, kann man beim Routing sehen: Ganz tolle Route.

Zwei Fußwege übereinander, um Flächen und Mittellinien zu haben, ist völlig unbrauchbar. Es gibt einen Fußweg als Mittellinie und wenn man meint Flächen zu brauchen, dann muss das anders getaggt werden. Wenn es derzeit von Mapnik noch nicht gerendert wird, dann ist das so. Aber das soll hier auch nicht MS-Paint sein, wo es darum geht, ein schönes Bild mit geometrischen Figuren auf den Bildschirm zu malen. Ich kann seawolff nur vollumfänglich zustimmen.

marek kleciak · 2015-08-23 22:34:49

Kontinentalverschieber wrote:

und wenn man meint Flächen zu brauchen, dann muss das anders getaggt werden. Wenn es derzeit von Mapnik noch nicht gerendert wird, dann ist das so.

+1. Daher tagge ich solche Flächen nur noch als area:highway=footway.
Je mehr wir solche Objekte haben, umso wahrscheinlicher ist es, dass man diese Objekte beim Rendern berücksichtigt.

Grüße,
Marek

Last edited by marek kleciak (2015-08-23 22:35:46)

Rogehm · 2015-08-23 22:51:55

Yo, immerhin führt der gleiche Router für das läppische Eintrittsgeld (Maut) für 17,50 den kürzesten Weg von hier nach dort. Also, alles noch in der Konstruktionsphase.

P.S. Die Flächen werden gerendert. Nicht das hier Missverständnisse aufkommen. Ist aber auch egal. Entweder area tagging von footwaw / pedestrian oder area:highway.

Kombiniertes Doppeltagging versuche ich mal morgen in Nürnberg, der schönen Stadt.

Last edited by Rogehm (2015-08-23 23:01:53)

Kontinentalverschieber · 2015-08-23 23:04:57

Und auf der Domplatte routet er gar nicht...

Aber das ändert nichts daran, dass das im Kölner Zoo kompletter Unsinn ist. Denn selbst wenn das ein hochgradig perfekter Router wäre, würde er im Kölner Zoo verzweifeln (und ein perfekter Renderer erst recht). Denn dort gäbe es einen flächigen Hochweg (layer=1) über einem linienförmigen Tiefweg (kein Layer --> layer=0). Diese beiden sind dann an Randpunkten bei ausbrechenden Wegen miteinander verknüpft und ergeben so ein lustigeres Wegesystem als jeder Baumseilgarten. Und die von seawolff beschriebene Wildeselanlage mit den Hängenden Gärten von Babylon ist da dann nur noch die Krönung.

Der Zoo ist wirklich ein Fall für den Kuriositätenthread, wenn man ihn von der Datenstruktur anschaut. Man lacht sich wirklich kaputt.

marek kleciak · 2015-08-23 23:17:24

Rogehm, danke für Deine Hilfe in Nürnberg.
Es gibt dort bereits Einiges zu sehen
http://osmapa.pl/w/areade/?lat=49.4776& … =12&ol=BPN

Rogehm · 2015-08-23 23:28:45

Der Zoo ist wirklich ein Fall für den Kuriositätenthread, wenn man ihn von der Datenstruktur anschaut. Man lacht sich wirklich kaputt.

Machs besser, ich halte dich nicht davon ab. Nur Rumgemotze kann ich auch. Außerdem war es auch noch Baustelle, die sich leider schlecht darstellen lässt.

Marek wrote:

Rogehm, danke für Deine Hilfe in Nürnberg.

Nö, war keine Hilfe, Aber Danke dafür. War nur Einarbeitung. Ich versuche, die "Ecke" noch fertigzustellen.

P.S. In der Hoffnung, auch in NRW demnächst "was zu sehen". Der Server scheint gut zu funktioniern mit den 1 h Updates.

Last edited by Rogehm (2015-08-23 23:39:22)

marek kleciak · 2015-08-23 23:49:05

Ich spreche das erneut an.
Mittlerweile wird in der poln. Version auch a:h=traffic_island+landuse=grass farbig unterstützt. service roads, bus und amenity=parking_space als Area gezeichnet bekommen auch leicht anderen Farbton als die üblichen a:h.

http://osmapa.pl/w/area/?lat=53.43303&l … =19&ol=BPo

Ich mag die Darstellung mit der Visualisierung der turn:lanes : http://osmapa.pl/w/area/?lat=52.39961&l … ol=PEFGABR

Sie ist leider in der Dt. Version noch nicht implementiert. Kommt aber.

RadFr · 2015-08-24 07:01:19

Neuerdings gibt es sogar area:highway=bridge. IMO total falsch, eine Brücke ist kein highway.
https://www.openstreetmap.org/browse/way/268663549

Taggen für den Renderer!

edward17 · 2015-08-24 08:07:53

Soll in diesem Bild area:highway=bridge durch man_made=bridge ersetzt sein?

Rogehm · 2015-08-24 08:28:51

Welcher Renderer? Höchstens Tagging für die Zukunft. Aber da gibt es ja genug "tote" Beispiele. Dieses tote Tagging wartet eben solange, bis es ins Leben gerufen wird. Genauso könnte man jedes 3D Tagging so bezeichnen. Tagging für den Renderer. What else?

RadFr · 2015-08-24 09:05:36

Rogehm wrote:

Welcher Renderer? Höchstens Tagging für die Zukunft. Aber da gibt es ja genug "tote" Beispiele. Dieses tote Tagging wartet eben solange, bis es ins Leben gerufen wird. Genauso könnte man jedes 3D Tagging so bezeichnen. Tagging für den Renderer. What else?

Einerseits werden IMO unnötige MP-Relationen gemappt, mit der Begründung Vermeiden doppelter Linien und damit weniger zu speichernde Daten, andererseits wird totes Tagging produziert, was den Datenumfang erheblich vergößern dürfte.

Tagging für die Zukunft oder nicht? So manche haben da ihren eigenen Kochtopf.
Das Wiki ist ein inkonsistentes Gemurkse.

Beispiel:
http://wiki.openstreetmap.org/wiki/Prop … ea#Tagging

The existing approach, highway=* with area=yes can be extended with addition of drawing street surfaces with the tagging:
area:highway=value Values are the same as for the current highway=* tag, under the lists "roads" or "paths".

area:highway=yes for unknown road type.

Dann findet weiter unten area=highway=bridge usw.
BTW, area:highway=yes wurde IMO abgelehnt.

Demnach What else? zu urteilen, könnte man das Ganze auch einfach löschen.

Last edited by RadFr (2015-08-24 09:13:07)

marek kleciak · 2015-08-24 09:09:31

edward17 wrote:

Soll in diesem Bild area:highway=bridge durch man_made=bridge ersetzt sein?

Ja. a:h=bridge brauchen wir nicht, weil schon man_made=bridge existiert.

seawolff · 2015-08-24 10:58:50

Rogehm wrote:

Dass "highway=*" mit "area=yes" von Mapnik dargestellt wird, ist nicht neu.
Es ist aber nicht der Sinn von OSM eine bestimmte Darstellung durch Mapnik zu erreichen (siehe auch DE:Taggen für den Renderer).
Ja, und? Dann ist es doch gewollt. Sonst würde es nicht gerendert.

Mapnik ist nur eines von vielen Programmen, das OSM-Daten auswertet.
Eine korrekte Darstellung in Mapnik beweist nicht, das die Daten korrekt sind.
Eine falsche oder fehlende Darstellung in Mapnik beweist nicht, das die Daten falsch sind.

"highway=*" mit "area=yes" wird benutzt, um ungerichtete Flächen abzubilden
(die dann keinen "highway=*" zusätzlich erhalten). Für eine Grundsatzdiskussion,
ob Wege als Linie erfasst werden sollen, kommst du 10 Jahre zu spät.

Man könnte hier auch für andere Renderer taggen, z.B. Ist das Gebäude im Nachbar Area "Flora" für F4 getaggt.

So wie man für Straßenflächen a:h und nicht ein nochmals "highway" verwendet,
so werden dort Gebäudeteile mit "building:part" und nicht "building" getaggt.

seawolff · 2015-08-24 11:28:08

marek kleciak wrote:

a:h=bridge brauchen wir nicht, weil schon man_made=bridge existiert.

Streiche am besten den gesamten Abschnitt "Rendering of bridges".
"man_made=bridge" ist unabhängig von a:h.
Die Eissenbahnbrücke hat mit a:h auch nichts zu tun.

Bitte streiche auch den Abschnitt über stop lines.
Die Idee ist völlig unausgereift und verwirrend.
Die Datenstruktur passt nicht zu OSM und ist mit bestehenden Renderern nicht darstellbar.

Das Bild Mockup more complex example finde ich unseriös.
Es suggeriert, dass diese Darstellung mit den zuvor genannten Datenstrukturen erzeugt wurde.
Es enthält aber viele Details, die damit gar nicht umsetzbar sind, und widerspricht in Teilen der OSM-Karte darunter.
Vermutlich hast du das Luftbild mit Photoshop nachgemalt.
Ersetzte das Bild bitte durch ein echtes Renderergebnis.

Es würde dem Proposal sehr helfen, wenn man es auf den Kern a:h beschränkt.

edward17 · 2015-08-24 11:53:53

Ich bitte, nächste Teile des Proposals möglichst schnell zu erneuen, weis sie veraltet sind, und deshalb Mappers in einen Irrtum verfallen.

In case of an intersection of two roads with different classes, e.g. tertiary and residential the area:highway=crossing gets additionally still tag crossing= <value of the street with higher priority>

- crossing -> junction, etc (hier)

Q: Which area:highway values should be used, when several different types of road meet, e.g. crossing of secondary and residential road? should area of residential road be splitted? Or one new mix tagging should be used?
A: The rendering of streets as surfaces, does not need such attribution, because the logical representation level; with roads drawn as centerlines, already contains this information
The attributtation with values: secondary, residential is used for correct rendering of streets as midlines. The area representation as proposed here, does not require in principle an additional information.

- soll entfernt sein (hier)

Dieses Bild - area:highway=bridge -> man_made=bridge
Dieses Bild - crossing=y_junction -> junction=y_junction

Und mit diesem Satz (hier) ist etwas falsch:

The nodes K of treet center line edges (red on the picture) must have common points with street areas.

marek kleciak · 2015-08-24 15:21:21

Erledigt.
Danke für Deine Aufmerksamkeit!

marek kleciak · 2015-08-24 16:02:46

Neu: rendering von way - highway=cycleway + cycleway=crossing
http://osmapa.pl/w/area/?lat=51.13176&l … 19&ol=BPoR
z
Yebra Streifen links oben ist falsch getaggt um den Unterschied aufzuzeigen.
DEmnächst kommt auch der Rendering von bicycle@path

Nachdem alle Tests abgeschlossen sind kann man auch die Dt. Seite upgraden.

Tordanik · 2015-08-24 16:03:29

Wow, das Thema ist ja ganz schön in Fahrt gekommen. Ich würde mich auch aus 3D-Sicht sehr über Straßenflächen freuen.

Was ich mir noch wünschen würde, wären einige Klarstellungen in Detailfragen. Speziell wäre es aus meiner Sicht sinnvoll, die folgenden Hinweise zu ergänzen:

Parallele Ways sollten jeweils ihre eigene Straßenfläche haben, z.B. bei Autobahnen, aber auch bei mit separaten Way gezeichneten Radwegen etc.
Flächen für Spuren (im weiteren Sinne), also z.B. area:highway=bus und area:highway=shoulder, sollten innerhalb der Straßenfläche liegen. Für 2D-Renderer macht das keinen Unterschied, aber für 3D wäre es eine große Hilfe.

Vielleicht ist insbesondere der erste Punkt sogar offensichtlich, aber dem Programmierer erleichtern solche Annahmen die Arbeit deutlich.

marek kleciak · 2015-08-24 16:36:48

Tordanik wrote:

- Parallele Ways sollten jeweils ihre eigene Straßenfläche haben, z.B. bei Autobahnen, aber auch bei mit separaten Way gezeichneten Radwegen etc.
- Flächen für Spuren (im weiteren Sinne), also z.B. area:highway=bus und area:highway=shoulder, sollten innerhalb der Straßenfläche liegen. Für 2D-Renderer macht das keinen Unterschied, aber für 3D wäre es eine große Hilfe.

Absolut richtig. Kannst Du mir helfen und diese Hinweise in dem engl. Proposal einbauen?

Auch finde ich dad das Rendern der area:highway=emergency viel besser gelingen könnte, wenn man Deinen Vorschlag mit der Richtung einer Textur der Fläche zuweisen könnte. Ich habe jetz kein Beispiel zur Hand, aber es ist ofensichtlich das ein Spitzdreieck mit Kreuzschraffur schlecht aussieht, wenn man die Schraffur parallel zu einer der längeren Außenkanten hat.

Tordanik · 2015-08-24 17:09:45

Mit der Schraffur hast du absolut recht. Ich könnte mir zwar vorstellen, dass man die Schraffur automatisch so dreht, dass sie annehmbar aussieht, aber wenn man die Richtung so haben will, wie sie in der Realität ist, dann braucht man zwangsläufig ein direction-Tag o.ä.

PS: Ich habe die Klarstellungen jetzt im englischen Proposal ergänzt.

Announcement

#151 2015-08-23 14:11:08

Re: Strassen als Fläche

#152 2015-08-23 17:32:16

Re: Strassen als Fläche

#153 2015-08-23 18:39:32

Re: Strassen als Fläche

#154 2015-08-23 21:30:33

Re: Strassen als Fläche

#155 2015-08-23 21:59:28

Re: Strassen als Fläche

#156 2015-08-23 22:12:14

Re: Strassen als Fläche

#157 2015-08-23 22:34:49

Re: Strassen als Fläche

#158 2015-08-23 22:51:55

Re: Strassen als Fläche

#159 2015-08-23 23:04:57

Re: Strassen als Fläche

#160 2015-08-23 23:17:24

Re: Strassen als Fläche

#161 2015-08-23 23:28:45

Re: Strassen als Fläche

#162 2015-08-23 23:49:05

Re: Strassen als Fläche

#163 2015-08-24 07:01:19

Re: Strassen als Fläche

#164 2015-08-24 08:07:53

Re: Strassen als Fläche

#165 2015-08-24 08:28:51

Re: Strassen als Fläche

#166 2015-08-24 09:05:36

Re: Strassen als Fläche

#167 2015-08-24 09:09:31

Re: Strassen als Fläche

#168 2015-08-24 10:58:50

Re: Strassen als Fläche

#169 2015-08-24 11:28:08

Re: Strassen als Fläche

#170 2015-08-24 11:53:53

Re: Strassen als Fläche

#171 2015-08-24 15:21:21

Re: Strassen als Fläche

#172 2015-08-24 16:02:46

Re: Strassen als Fläche

#173 2015-08-24 16:03:29

Re: Strassen als Fläche

#174 2015-08-24 16:36:48

Re: Strassen als Fläche

#175 2015-08-24 17:09:45

Re: Strassen als Fläche

Board footer