Flughafen Berlin-Schönefeld extremer Routingfehler

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.

Junge, das Stadtzentrum, muss ich hier nicht definieren, ich spreche nicht mal von Flächen. HIER, gin eine Stadt ein und Teste funktioniert lustiger weise immer, zumindest ist mir noch nichts anderes untergekommen.

Das kann manchmal richtig schiefgehen:

Rot: ST_Centroid(way)
Blau: ST_PointOnSurface(way)
Grün: Place-Node

Gruss
walter

Eltville ist dann ja quasi das reale Paradebeispiel für den Unterschied von ST_Centroid und ST_PointOnSurface. Danke, Walter!

Moin,

Rot und Blau sind das rein geometrische Problem.
Die Verwechslung zwischen Pink (Gemeinde) und Grün (Ortschaft) ist dann das logische Problem, mit dem sich noch viele zusätzlich ein Bein stellen.

Grüße, Georg

Da kann die arme Geometrie aber nix für. Das ist nun mal das, was Renderer und auch andere Software verwenden (müssen), wenn es keinen “Hint” gibt. Und die geometrisch berechneten “Zentren” liegen dann zu geschätzten 99% richtig.

Das verstehe ich nicht. Welches Pink? Und wer verwechselt hier was?

Gruss
walter