Flughafen Berlin-Schönefeld extremer Routingfehler

Es mach überhaupt keinen Spaß, eine solche müßige Diskussion führen zu müssen, wir reden über den drittgrößte Flughafenstandort Deutschlands mit 33,3 Millionen Passagieren im Jahr 2017.
Das Netz ist verständlicherweise voll mit Fragen nach der richtigen Anschrift, da diese zum Beispiel auch bei OSM nicht richtig hinterlegt ist.
Bevor jetzt wieder die Debatte mit dem Polygon kommt, Deine Argumentation ist falsch und nicht zu Ende gedacht.
Die Lage des Schwerpunktes vom Flughafen Polygon ist nur von der Form allein abhängig, je weniger kreisförmig und Länglich der Umriss ist, desto falscher liegt der Schwerpunkt.
Ohne einen einzigen Anhaltspunkt, wie der korrekten und eindeutig verorten Adresse wird es keinem Renderer oder Router gelingen die korrekte Straße zu ermitteln. Weiterhin würde sich bei jeder Veränderung des Grundstückes jedesmal der Schwerpunkt verändern.

Bei kleineren Gebäuden funktioniert das ohne Frage richtig und gut, bei Flughäfen funktioniert es aufgrund der Größe niemals, nicht einmal bei den Flughäfen München und BER, obwohl dort das Terminal exakt in der Mitte sitzt.

Eine Ausnahme sind hier Parks und Wälder, weil hier der Besucher nicht an einem Punkt, sondern in einem Gebiet ankommen möchte.

Die Strecke sollte maximal 0-300m Fehler betragen, wir reden bei alles betrachteten Flughäfen immer über mehrere Kilometer Fehler:

Flughafen Berlin-Tegel
Fehler-Distanz: 1.7km. Zeit: 0:21.
Adresse des Polygons: Flughafen Berlin-Tegel Otto Lilienthal, Mecklenburgweg, KGA Neuland I, Tegel, Reinickendorf, Berlin, 13629, Deutschland
richtige Adresse des POI: Flughafen Berlin-Tegel, Tegel, Reinickendorf, Berlin, 13405

Routing
https://www.openstreetmap.org/directions?engine=graphhopper_foot&route=52.5574%2C13.2805%3B52.5544%2C13.2894#map=16/52.5533/13.2922

Flughafen Berlin-Schönefeld
Fehler-Distanz: 5.4km. Zeit: 1:05.
Routing
https://www.openstreetmap.org/directions?engine=graphhopper_foot&route=50.03938%2C8.59676%3B50.05068%2C8.57152#map=13/50.0354/8.5973

Flughafen Frankfurt/Main
Fehler-Distanz: 3.9km. Zeit: 0:47 zu Fuß

Routing
https://www.openstreetmap.org/directions?engine=graphhopper_foot&route=52.3734%2C13.5113%3B52.3889%2C13.5188#map=14/52.3802/13.5276

OSM-Fehler zwischen Adresse als Punkt 0m
OSM-Fehler zwischen Adresse als Gebäude-Polygon <100m
OSM-Fehler zwischen Adresse als als Flughafen-Polygon >4.000m

Weil das alles ermüdend ist, hat sich jetzt jeder ein Bier im Terminal des Flughafen Berlin-Schönefeld verdient, ab indie Marché Zigolini Bar, oh verdammt, keine 10.8km Extra-Fußweg, sondern Null Fehler.

Sollte man jetzt nach Kneipen navigieren, um zum Flughafen zu kommen???

Wenn Das so in Ordnung ist möchte ich das nur bestätigt haben, dann werde ich diese Anomalie akzeptieren, ansonsten wäre es vielleicht nett, wenn jemand zu einer korrekten Lösung beitragen könnte, den Status “funktioniert nicht” haben wir ja bereits.

Viele Grüße
Stefan

So, liebe Leuts: Ich hab mal ein paar Eingänge zugefügt, nach bester Interpretation der Mapillary-Bilder. https://www.openstreetmap.org/changeset/56612233 . Ich habe v.a. diese Sequenz hier https://www.mapillary.com/app/?lat=52.388743&lng=13.518711&z=17&pKey=G2IhEqGl6_8tiorPqc7diw&focus=photo genommen.

Bitte kontrollieren und jemand der sich a) damit und b) da auskennt an den Eingängen die korrekten Tags erfassen (z.B. Adresse).

1 Like

Keiner hat gesagt, dass alles in Ordnung ist. Ich habe immer nur gesagt, dass der Flughafen richtig gemappt ist und der Fehler woanders liegt, deshalb sehe ich nicht, was wir auf Mappingseite daran ändern können, und deshalb geht deine Fehlermeldung an die falsche Adresse.

Wenn ich damit falsch liege, dann sag mir bitte, was wir ändern sollen.

Das Problem ergibt sich daraus, dass als Suchergebnis ein Polygon ermittelt wird, der Router dann einen Punkt dieses Polygons nimmt (nehmen wir mal an, den Schwerpunkt) und diesen als Endpunkt des Routings setzt.

Zusammenfassung:

  • Das Routing selbst (vom dem Router übergebenen Startpunkt zum ihm übergebenen Endpunkt) ist in Ordnung. Der Router weiß ja nicht, dass er mitten auf dem Rollfeld losfährt. Er routet von Koordinate A zu Koordinate B so gut wie möglich anhand der Straßen, die er dazwischen sieht, und das macht er in diesem Fall korrekt.
  • Das Mappen des Flughafens aus Polygon ist auch in Ordnung.
  • Was nicht in Ordnung ist, ist der Schluss, der (angenommen) Schwerpunkt des Polygons sei ein geeigneter Start- oder Zielpunkt fürs Routing. Aber diesen Schluss können wir von Mappingseite aus (soweit ich weiß) nicht beeinflussen, darum müssen sich diejenigen kümmern, die solche Schnittstellen bauen.

–ks

Diese Route hier entspricht aber auch nicht dem Fußweg vom Bahnhof zu Halle, den vor einer Weile gegangen bin:
https://www.openstreetmap.org/directions?engine=graphhopper_foot&route=52.39083%2C13.51283%3B52.38890%2C13.51880#map=17/52.38932/13.51764

Der Fehler liegt mit an Sicherheit grenzender Wahrscheinlichkeit an den Access-Tags hier: http://www.openstreetmap.org/?mlat=52.38867&mlon=13.51765#map=19/52.38866/13.51765&layers=N

access=private + bicycle=no + foot=no verhindert ein erfolgreiches Routing… Wer weiß, wo noch solche versteckten Gimicks zu finden sind… Ich habs für den kurzen Abschnitt mal rausgenommen…

Sven

zusätzlich zum polygon einen POI setzen und nur dort eine gültige Adresse reingeben, das scheint es zu verbessern

ja, würde aber wohl auf “tagging für den router” hinauslaufen :wink:

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: