Flughafen Berlin-Schönefeld extremer Routingfehler

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

Hallo Mitstreiter,
nun sind 1,5 Jahre vergangen, viele Beiträge, keine Lösung, so hatte ich es erwartet.

Sieh es nicht so negativ. Es wurden etliche gute Aspekte in der Diskussion genannt, z.B. der, dass ein Flughafen kein Punkt ist und sich jeder Router unter der Eingabe daher etwas anderes vorstellen kann.

Zu deinem Vorwurf: An der OSM-technischen Erfassung des Flughafens ist offenbar nichts grundlegend falsch, das Problem liegt in der Interpretation der Daten, die dieser eine Router offenbar falsch versteht. Das Problem ist dann auf Routerseite zu lösen, und da bist du hier schlicht an der falschen Adresse. Wir hier erfassen Daten und hacken sie in die Datenbank rein. Die Programmierung irgendeines Routers wird nicht hier diskutiert, sondern auf der entsprechenden Maintainer-Seite.

Bildlich ausgedrückt: Wenn deine Waschmaschine nicht richtig läuft, dann rufst du auch nicht deinen Wasserversorger an. Wir hier liefern nur Geodatensätze, mit denen Router etwas anfangen können sollten, aber wenn sie das nicht richtig machen, ist das deren Problem, solange unsere Daten nicht nachweislich fehlerhaft sind.

–ks

Also nur um mal meinen Senf dazuzugeben und in diesem Falle Kreuzschnabel den Rücken zu stärken.

Ich persönlich nutze OSM nahezu gar nicht zum Routen, nutze OSM aber sonst enorm viel. Und ich erwarte von einem Flughafen POI eigentlich schon, dass er entweder in der geometrischen Mitte, dem Schwerpunkt oder dem Punkt am weitesten entfernt vom Umriss liegt. Das ist meine Erwartung an eine Suche nach “Flughafen Berlin-Schönefeld”. Und genau das tut die Karte auch. Ich sehe dort also ebenfalls keinen Fehler. Wenn ich jetzt jemand bin, der einen externen Zusatzservice nutzt (Router) wäre ich sicherlich auch nicht zufrieden mit dem Umweg. Ich sehe das Problem aber auch beim Router und nicht beim Mapping. Dann muss der Router eben für seine “Kunden” eine Translation vornehmen - hin zu dem was Kunden des Routers unter “Flughafen Berlin-Schönefeld” meinen.

Den POI irgendwo anders als in eine der oben genannten “Mitten” zu legen halte ich definitv für falsch. Andere Kommerzielle Router machen es im übrigen augenscheinlich exakt so wie ich das oben vorgeschlagen habe… Das große G routet solange die Route noch nicht finalisiert (also solange man noch per Drag und Drop arbeitet) ebenfalls Kilometerweise außenherum. Erst wenn man losläßt, greift mutmaßlich eine Routine die erkennt, dass wohl niemand außenrum fahren will und gibt die kurze (0-meter) Distanz aus. Da hat also der Router einen Spezialfall implementiert. Und genau so würde ich auch hier die Lösung sehen. Der Router muss einen Spezialfall implementieren, nicht aber die Karte selbst.

Nominatim hat das Problem als issue, aber mit “Implementier das selbst wenn du es haben willst, ich hab keine Zeit”: https://github.com/openstreetmap/Nominatim/issues/536 .

Aber ist Nominatim überhaupt der richtige Ansprechpartner? Weil vom Geocoding her passt es doch eigentlich auch. Bzw. also ich erwarte von einem Geocoder eigentlich genau das Ergebnis was wir Stand heute bekommen.

Ich seh da die Pflicht auf beiden Seiten.

Der Router sollte nicht einfach so den Flughafen-Zentroiden als Navigationsziel vorschlagen. Falsch ist es aber grundsätzlich nicht.

Auf der anderen Seite müssen wir Mapper aber auch sicherstellen, dass die möglichen Zielpunkte (z. B. Terminal 1, Terminal 2 Eingang A, Parkhaus P7, Cargo-Zentrum, Langzeitparken, Mietwagen-Return, Drop-off zone) gemappt und dem Flughafen zugehörig gemappt sind. Nur so kann ein Router sinnvolle Zielalternativen anbieten, wenn jemand nach Flughafen xyz sucht. Am hier kritisierten Flughafen Schönefeld findet man sogar “Flughafen Schönefeld Terminal” mit Nominatim, es ist allerdings ein Fußweg. Sicher nicht, wie es sein sollte.

1 Like