Plätze taggen

Es ist alles eine Frage des WAS WILL MAN HABEN. So langsam kommt man mit einer schönen, detailierten Karte in Regionen, wo man andere Sachen einschränkt bzw. kaputt macht. Für die Erstellung von Routinggraphen braucht man lineare Objekte. Mit Flächen ist ein Routing nicht sinnvoll möglich. Ja und auch die Krücke mit dem Routing entlang der Flächenbegrenzung ist kein sinnvolles Routing.

Wenn die Wege die Optik stören, ist es für den Renderer kein Problem, die Fläche über die Straßen zu malen. Auch ein Tag, der ausdrückt, dass der Weg nur fürs Routing gedacht ist wäre eine Lösung, ähnlich wie das indoor=yes für Wege in Gebäuden.

Warum ist Routing entlang der Flächenbegrenzung nicht sinnvoll? Grundsätzlich stimmt es aber schon, dass wir in Zukunft eventuell eine Trennung von Objekten für Routing und für Renderzwecke brauchen könnten.

A) die Darstellung ist unsinnig
B) die Routinganweisung biege links/rechts ab auf Platz usw. ist unsinnig, denn ich will ja eigentlich gerade aus.
C) die Streckenlänge passt nicht

Wenn man auf einem rechteckigen Platz entlang einer Kante will ist es egal, will man aber einen Plus-förmigen Platz einfach nur gerade queren wird das ganze großer Unsinn.
Ein weiterer Punkt sind die unklaren access-Regelungen.

Nun, dann sollte ein Router eben annehmen, dass bei Plätzen (also area=yes) gilt, dass direkt von jedem Punkt zu jedem Punkt geroutet werden kann. Den virtuellen Weg zu Berechnen sollte ja so schwer nicht sein.

Hallo errt,
ich interessiere mich auch einwenig für Navigation für Blinde. Ein Blinder würde so fehlgeleitet und mit Hindernissen konfrontiert. An Platzrändern befinden sich häufig Poller, Bäume, Bänke usw.

Ciao Holger

Das sage ich auch immer. Dann bekomme ich immer zu hören, dass mkgmap das nicht kann. Nur Gott weiß, warum das keiner reinprogrammieren kann.

Gut, dann bleiben wir bei der Plus-förmigen Fläche, der Nutzer möchte aber nicht gerade aus, sondern nach links “abbiegen”. Das sind noch triviale Fälle, man könnte sich einen virtuelle Schwerpunkt berechnen und darüber routen. Bedenke aber, dass die Flächen frei geformt sein können, dass auch der Schwerpunkt außerhalb der Fläche liegt. Oder trivialerweise im Schwerpunkt der Plus-förmigen Fläche ein Haus steht oder oder oder. Selbst wenn man für jeden Fall eine Lösung finden würde, müsste man den Fall auch erst mal erkennen…

Dann leg doch los mit dem programmieren… :wink:

Ich schlage vor, die Flächen zu skelettieren, um die routbaren Wege darüber zu bestimmen. (skeletonize wie in Bildverarbeitungen). Das routet dann zwar nicht unbedingt die allerkürzeste Route, aber doch wahrscheinlich eine leidlich kurze, meidet die Außenkanten und sollte halbwegs sinnvolle Abbiegeanweisungen geben. Und es kommt mit mherfach zusammenhängenden Flächen klar.

Es sei denn, jemand hat noch bessere Vorschläge.

Baßtölpel

  1. mkgmap routet nicht “über” Plätze sondern nur an den Kanten der Fläche => mkgmap ist (noch) zu dumm.
  2. Zusätzliche Wege entsprechen nicht der Realität => Wir taggen nicht für Renderer.

Ist es erlaubt die Fläche so zu zerlegen, dass Kanten entstehen, die durch die urspüngliche Fläche hindurchgehen? Wenn diese Kanten kürzer wären als der Weg außenrum, dann würde ein Router diese bevorzugen. Wenn nicht, dann macht es auch keinen Sinn durch die Mitte zu routen.

Freie Plätze haben unter anderem die Eigenheit, daß sie frei begehbar sind. Eingezeichnete Wege entsprechen somit nicht der Realität. Um zu einem Ziel auf der anderen Seite des Platzes geführt zu werden, wird ein intelligenter Router benötigt und keine verfälschte Karte.
Des weiteren können sich auf dem Platz verschiedene Zielobjekte befinden. Würde man der Argumentation für die eingezeichneten Wege folgen, müßte man zu jedem dieser Objekte hin- und wegführende Wege in alle Richtungen eintragen. Das ergibt ein völlig unsinniges Wegenetz im Kartenbild.
Die Idee Wege grundsätzlich unter Plätzen verschwinden zu lassen, um die optisch nicht vorhandenen Wege zu verstecken, ist mE nicht zuende gedacht. Es ist denkbar, daß auf einem großen Platz durch besondere Pflasterung z.B. Wegspuren für Radfahrer definiert werden, wenn der Rest des Platzes nicht befahren werden soll. Die würden dann auch unter dem Platz verschwinden.

Real vorhandene Wege und reine Routingspuren (so sie denn unbedingt sein müssen) müssen für Renderer (egal für welchen) unterscheidbar sein, damit man in den Renderregeln festlegen kann, wie sie ausgewertet werden sollen.

Gruß
tt

Alles nicht nötig. Wenn man Löcher und konkave Ränder berücksichtigen will, genügt folgende Logik: Es werden alle Nodes miteinander in geraden Linien verbunden, aber alle Verbindungslinien ignoriert, die ganz oder teilweise außerhalb der Fläche liegen.

Wenn man’s noch genauer machen will, müsste man zu äußeren und inneren Rändern eine halbe Fahrzeugbreite Abstand lassen, aber das wird dann komplizierter, und diesen Genauigkeitsgrad haben wir mit OSM sowieso noch nicht.

Offen gesagt hab ich an Routing kein persönliches Interesse, und ich hasse Java. Aber wenn du mir sagst, in welchem dieser komischen Sourcefiles das geändert gehört, versuche ich mal mir das anzuschauen.

Wenn eine Fußgängerzone ein Platz ist, dann sollte das auch erkennbar sein. Aber eine Fußgängerzone muss nicht unbedingt ein Platz sein.
Die von Holger angeführte Fußgängerzone zeigt das ganz deutlich: der Anger in Erfurt. Dieser „Anger" ist eine Fußgängerzone, die sich zum Einen aus einem sehr unförmigen Platz (http://www.openstreetmap.org/?lat=50.977026&lon=11.035372&zoom=18&layers=M) und zum Anderen aus einem linienartigen Gebilde (http://www.openstreetmap.org/?lat=50.974952&lon=11.03247&zoom=18&layers=M) zusammensetzt. Insgesamt ist das eine Fläche mit einheitlicher Oberfläche, d.h. es gibt keine vorgegebenen, baulich abgesetzten oder markierten Fahr- oder Radbahnen. Nur die Erfurter Straßenbahn führt in alle Richtungen über diese Fläche. Die Zulassung des Liefer- und Radverkehrs in bestimmten festgelegten Zeiten ist ein anderes Thema.

Bleiben wir erst einmal bei dem unförmigen Gebilde. Das ist m. M. nach eindeutig ein Platz. und dieser ist entsprechend der Wiki als highway=pedestrian+area=yes zu definieren. Das habe ich bisher auch immer gemacht. Und so lange es keine andere nachvollziehbare Lösung gibt, werde ich das auch weiter so machen. Es sei denn, es definiert hinterher jemand um. Und das Wiki ist nun mal eine Richtlinie.

Ich habe keine Ahnung, wie ein Routing funktioniert. Ich kann mir aber gut vorstellen, dass es hier Probleme gibt. Einige sind ja schon angesprochen worden und nachvollziehbar. Ich denke aber, dass die hier dargestellt Variante „Anger" auch nicht stimmt. Es werden Fußgängerzonen als way über eine Fußgängerzone als area gelegt. Das stimmt ja so nicht. Ein Platz bietet ja unendlich viele Möglichkeiten über diesen zu gehen oder auch bestimmte Ziele aufzusuchen. Wollen wir die alle eintrage? O. k., dass ergibt dann aufgrund der Vielzahl und der Überschneidungen auch wieder eine Fläche. :wink:
Grundsätzlich gefällt mir die Variante einen path oder einen footway auf die area zu legen (siehe Willi-Brandt-Platz) besser. Obwohl auch das nicht optimal ist.

Es wird ja immer wieder und in schöner Regelmäßigkeit betont, dass ja jeder, der seine eigenen Karten bastelt, entsprechende Regeln aufstellen und die „area" nach oben legen kann. Aber genau so gut kann dann dieser Kartenbastler auch seine, zum Routen notwendigen Wege, quer über den Platz vorgeben. Es gibt aber fertige Karten im Internet, die das nicht tun. Und ich kenne genügend Leute, die gerade diese Karten nutzen und diese werden hier fehl informiert.

Über den linienförmigen Bereich des Angers kann man ja geteilter Meinung sein. Ich hätte (und habe) auch in diesem Fall highway=pedestrian+area=yes definiert. Ich denke aber, dass hier auch gut ein highway=pedestrian möglich ist. Was ich nicht gut finde, sind die beiden „Fußgängerzonen" rechts und link neben der Straßenbahntrasse. Hier sollte m. M. nach nur ein highway=pedestrian vorhanden sein. Aber da gibt´s die nächste Fragestellung: wird diese mit dem railway=tram zusammen definiert oder liegt sie darunter. Aber das ist ein anderer thread. :wink:

Danke. Ich frage mich wirklich, warum immer so getan wird, als sei das Finden von Wegen über eine frei begehbare Fläche eine gewaltige Herausforderung, obwohl es sich um eine schon lange gelöste Standardaufgabe handelt.

Dem entnehme ich, daß ein Spinnennetz von Wegen auf frei begehbaren Plätzen salopp gesagt als “Mumpitz” anzusehen ist. Ein korrekt programmiertes Routing-Tool sollte eine Platzquerung ohne Krücken schaffen. Möglicherweise stören die “Krücken” sogar.

Gruß
tt

Das habe ich auch so heraus gelesen.

@Holger, auch wenn das kein Erfurter bzw. Thüringer Problem ist, nimm´s als Thema am 24.3. mit zum OSM Stammtisch auf die Tagesordnung. Da kann dann entschieden werden, ob bzw. wer den Anger ggf. wieder ändert.

Aber eine Frage bleibt bestehen:
Was macht man mit dem linienförmigen Gebilde zwischen Angermuseum und altem Angerbrunnen? http://www.openstreetmap.org/?lat=50.974952&lon=11.03247&zoom=18&layers=M
highway=pedestrian+area=yes oder highway=pedestrian?

Flächige Straßen können als area:highway eingetragen werden, wie es in Erfurt auch der Fall ist. Diese Eintragung erfolgt aber immer zusätzlich zu einem normalen way.

Zustimmung. Besonders, wenn es sich um Einbahnstraßen handelt. Sowas ist nämlich mit areas nicht zu erfassen!

gruß,
ajoessen

Das kann man natürlich machen. Und das habe ich auch schon gesehen.

Aber wo liegt der Vorteil bzw. der Nutzen?
Entweder ein Renderer stellt diesen area:highway (ich kenne bisher keinen) dar und man sieht dann beides - nämlich area:highway und den highway. Das entspricht dann der Fragestellung wie sie urspünglich von thread-Eröffner gestellt wurde.
Oder die area:highway wird nicht dargestellt und dann brauche ich sie aber auch (noch) nicht eintragen.
Hier werden mit dieser Variante zwei Fußwege neben der Straßenbahn dargestellt, die dann am alten Angerbrunnen in die Straßenbahn übergehen.

Meine Frage zielte darauf, ob man einem langezogenen Platz/Fußgängerzone - also einer breiten Straße ohne Aufteilung in Fahrbahn, Gehbahn, Radbahn oder was auch immer - auch entsprechend der Wiki als highway=pedestrian+area=yes definiert. Das ist ja eine gängige Lösung und würde auf alle Fälle das Problem von übereinanderliegenden Ways für den beschriebenen Fall lösen.

Eine Fußgöngerzone als Einbahnstraße? Ist mir noch nicht untergekommen.

Tja, mir aber:
http://www.panoramio.com/photo/44224292

Und während in Erfurt da ne Straßenbahn durchrauscht, gibts anderswo auch Fußgängerzonen mit Busverkehr, z.B. in Mönchengladbach. Da ist ein linienhafter way schon von Vorteil.

gruß,
ajoessen