Flughafen Berlin-Schönefeld extremer Routingfehler

ACK, zumindest für den ersten Satz. Ein Polygon als Startpunkt zu nehmen, ist aus den offensichtlichen Gründen die schlechteste Wahl. Eine Linie wäre besser, ein Punkt das Optimum. Dementsprechend werden wohl auch Routingalgorithmen arbeiten.

Zwar mappen wir hier nicht expizit für den Router, aber einen Punkt (oder engen Bereich) zu definieren, wo er den Startpunkt wählen soll, wird denke ich erlaubt sein.

Von daher sehe ich folgende Möglichkeit:

Einen Punkt oder ein enges Gebiet definieren, welches hierfür herangenommen werden kann, und es entsprechend taggen. Zusätzlich könnte es sinnvoll/hinfreich sein, in eine Relation eine “Schwerpunkts”- oder Referenzdefinition angeben zu können.

Diese muss ggf. nach Verkehrsmittel getrennt definiert werden, denn für Fußgänger und Radfahrer mag anderes gelten als für Kfz-Fahrer, und für Luftfahrzeuge wird naheliegenderweise nochmal was anderes gelten.

Das ändert nichts daran, dass der Flughafen richtig als Multipolygon erfasst wurde.

Es gibt auch noch andere Anhaltspunkte, nennen sich Terminal und ggf. Haupteingang.

Nein, das ist nicht in Ordnung.
Lediglich der Flughafen wurde richtig als Fläche erfasst, die Terminals und die Straßen dahin auch und einige andere Dinge auch.
Das Problem ist aber kein Datenproblem (dafür sind wir Mapper verantwortlich), sonder ein Such- bzw. Router-Problem, dafür sind die entsprechenden Projekte verantwortlich, welche diese Daten verwenden und sinnvoll auswerten sollten.

Ok:

  1. Suche Flughafen (Fläche F)
  2. Suche Terminal (Fläche T) auf dem Flughafengelände (F)
  3. Suche Eingang (Punkt E) des Terminals (T)
  4. Suche die Straße (Weg S), welche zum Eingang (E) führt
  5. Route dorthin

OsmAnd sucht bei Gebäuden übrigens den Eingang und routet dann an diesen, nur falls kein Eingang vorhanden ist, wird der Schwerpunkt genommen.

Also versuche die entsprechenden Leute davon zu überzeugen, ihre Router bzw. Suche entsprechend anzupassen oder hilf dabei mit.

@SteMue: und es ist ja auch immer eine Frage dessen, wer wie danach sucht. Also ich würde gar nicht auf den Gedanken kommen in der Suche Flughafen Berlin Schönefeld einzugeben, sondern z.B. Terminal A, Schönefeld … und schwups werde ich direkt vor das Terminal geroutet

Danke Harald,
aber das kann ja wohl nicht Dein Ernst sei, Denke bitte noch einmal kurz an einen Touristen, oder sonst wen, der nicht mit dem Flughafen zu tun hat und dann wiederhole bitte noch einmal Deinen Satz.

es sollte mit beiden gehen, flughafen xyz muss immer gefunden werden und funktionieren

Ich glaube nicht, dass wir die berücksichtigen müssen. Eine Flugvorbereitung nach OSM-Router ist eine ziemlich sichere Methode dafür, bei der praktischen Flugprüfung durchzufallen.

–ks

Das sagt sich so leicht. Definiere „funktionieren“. Was ist mit Flughäfen, die für Verwaltung, Fracht, General Avation und Linienverkehr vier vollkommen unterschiedlich verortete Fahrziele haben? Woher soll eine Auswertesoftware wissen, was von den vieren mit der Anforderung „Flughafen xyz“ gemeint ist?

–ks

waäre zwar besser als jetzt, funktioniert aber dann auch nicht mehr, wie von kreuzschnabel erwähnt, wenn ich an jedes Terminal ein entrance=main mit jeweils der Adresse mappe, und gerade größere Flughäfen haben definitiv mehr als ein Terminal und mehrere gleichberechtigte Eingänge, welchen soll der Router dann als Start-/Zielvorgabe nutzen?

PS: Ich seh es noch kommen, dass es an dem Polygon in der Tat bald - wie von glglgl vorgeschlagen - einen key “coords_for_routing” gibt … weil dafür extra eine Relation anzulegen, nur um eine Referenzpunkt zu definieren, vielen vermutlich auch sauer aufstoßen würde…

hmm, solltest du mittlerweile aus dem anderen Thread gelernt haben, dass OSM keine allwissende Suchmaschine ist, sondern nur eine einfach stupide Datenbank?

und in einer Datenbank kann ich nicht nach Flughafen xyz suchen sondern nur nach Terminal A Flughafen xyz? Ist doch ein Witz jetzt, wenn ich den Flughafen finden will gebe ich Flughafen xyz ein und möchte ein Ergbnis haben das gültig ist, sonst hat alles keinen Sinn. Wenn es eine Datenbank ist, dann sperrt endlich die map zu und ändert den namen :wink:

Ich könnte mir das so vorstellen:

  • Alle größerflächigen Einrichtungen (das Problem kann sich ja auch bei Campus-Unis etcetera stellen, oder?) werden als site-Relation erfasst.
  • Die site-Relation trägt Name und Adresse der Einrichtung (offizielle Adresse laut Website-Impressum oder so).
  • Members der site-Relation sind:
    • der Umriss in der Rolle “outline”, entweder als geschlossener Way oder als Multipolygon (dann halt eine Subrelation)
    • Beliebig viele Routing-Zielpunkte, bspw. in der Rolle “destination” oder “target”.
      • Jeder dieser Routing-Zielpunkte ist mit Name (z.B. Abflug A) und ggfs. Adresse (wenn eine eigene) getaggt.

Das gäbe einem Auswerter die Möglichkeit, bei der Sucheingabe „Flughafen xyz“ rückzufragen, zu welchem der targets man will, weil dann die Zugehörigkeit abgebildet ist (genau dafür sind Relationen ja da).

–ks

Hast du mein Posting #31 gelesen und verstanden?

–ks

Ja hab ich, gibt es Antwortpflicht?

ich könnte jetzt ein paar Lösungen vorschlagen keine wird euch gefallen, weil alle “flasch” sind. Also bin ich leise, ich will mich nicht mit der Datenbank Fraktion Anlegen :stuck_out_tongue:

Man sollte es auf jeden Fall zu einer Priorität machen zu Flughäfen ordentlich geroutet wird, einfach so, aus stolz quasi :wink:

für wen gültig? für dich? für SteMue? Was bedeutet gültig? Schreib die Definition und das Regelwerk dazu ins Wiki, lass darüber abstimmen, und dann können sich die Router danach richten.

Ich sag jetzt lieber nicht, was ich als Motorgleitschirmflieger diesbezüglich als “gültig” erachte :stuck_out_tongue:

Gibt es natürlich nicht (geht’s auch etwas weniger aggressiv?), aber wenn du das darin angesprochene Problem deiner Forderung ignorierst und einfach die Forderung wiederholst, stellt sich mir die Frage halt. War nur eine sachliche Nachfrage, hätte ja sein können, dass du die zwei Zeilen übersehen hast.

Wenn du „Stuttgart“ als Fahrziel eingibst, erwartest du dann auch ein exaktes Routing dahin, wo du hinwillst? Das fände ich in etwa vergleichbar. Viele größere Flughäfen haben halt nicht nur ein sinnvolles Fahrziel, sondern mehrere, die alle mit der Anforderung gemeint sein können.

Ich habe in #35 eine vorgeschlagen, wie gefällt sie dir? Und ich möchte dich wirklich einladen, deine auch noch vorzustellen. Auch wenn sie der Datenbankidee nicht entsprechen, könnte doch viel Brauchbares drin sein.

–ks

Wenn ich eine Stadt als Ziel eingebe, erwarte ich ins Zentrum zu kommen, was quasi bei jeder Stadt zutrifft. (In OSM sind sie aber auch per Node vermerkt meist in Zentrumsnähe)

Dein Vorschlag klingt eh gut. Man kann noch Entrance setzen, POI mit Namen setzen, aber man muss es halt sinnvoll benennen, damit es auch sinnvoll in einer Suchliste als Vorschein aufscheint. (zB Haupteingang Flughafen xyz) wobei das alles mappen für die App ist, aber naja meine Einstellung dazu ist ja schon bekannt.

Bei manchen Flughäfen sind einfach gar keine Eingänge oder sonstige POI vermerkt die Adresse ist dann noch im Polygon gespeichert was auch suboptimal für die navigation ist.

Na klingt doch gar nicht sooo schlecht … und nein, das ich nicht alles mappen für die App sondern bildet die Realität vor Ort ab.

PS: Aber es hilft auch dann immer noch nichts einfach name=Terminal A zu setzen, der Chinese wird damit auch nichts anfangen können, d.h. man braucht zusätzlich noch semantisch eindeutige, auch von “maschinen” verständliche Tags.

name:cn vielleicht? bei den Airports die ich kenne ist überall eine ordentliche latte an name:LANGUAGE dran

Wieso? Finde ich gar nicht. Es ist eine Abbildung der wahren Verhältnisse. Da ist ein Flughafen (Relation), der belegt eine definierte Fläche (Polygon) und hat mehrere Anfahrtpunkte (target-Nodes).

Wenn der Tower außerhalb des Geländes steht (z.B. in Stuttgart), kann er auch noch mit in die Relation.

–ks

Definiere Zentrum. Auch das muss irgendwo vermerkt sein und kann nicht stupide über Flächenschwerpunkte definiert werden, denn das “Zentrum” der Aktivitäten, so nenne ich es mal, oder der Infrastruktur ist oft eben nicht genau in der Mitte der Fläche.