Beim Editieren auf www.openstreetmap.org habe ich (bei beiden Editoren, iD und Potlatch) das Problem, dass obengenannter Way https://www.openstreetmap.org/way/289652148#map=17/24.28650/45.65954 (eine Autobahn-Richtungsfahrbahn in Saudi-Arabien) nicht beim Bearbeiten der Karte angezeigt wird. Der Way war erst gestern in einer meiner Bearbeitungen involviert, damals wurde er korrekt angezeigt. Das Abfragen mit dem Fragezeichen-Tool funktioniert auch.
Zusammengefasst wird dieser Weg auf openstreetmap.org bei mir zwar hier angezeigt: OSM-carto (und die 3 anderen Kartenstile) Objektabfrage
Aber in den Editoren nicht: iD Potlatch 2
Habt ihr dieses Problem auch? Es wäre empfehlenswert, das Gleiche wie ich auszuprobieren. Falls der Fehler bei euch auch auftritt, handelt es sich wohl um einen Datenbank-Fehler – der Weg kann gerendert und seine Informationen angezeigt werden, jedoch nicht im Editor abgerufen werden.
Interessant wäre auch, ob der Fehler in JOSM (oder anderen Offline-Editoren) auftritt …
Du musst die Karte soweit verschieben, dass auch ein Knoten des Ways angezeigt wird. Dann lädt er den Weg automatisch nach. Der Weg hat auf der Geraden keine Nodes. Daran liegt das.
Ein Weg wird nur dann geladen, wenn mindestens ein Punkt in der Bounding-Box des Editors liegt. Da die Autobahn schnurgerade ist kann es sein dass man einen Abschnitt lädt in dem keine Punkte liegen, dann wird der Weg auch nicht geladen obwohl er da durch führt.
Tatsächlich wundere ich mich, dass eine spatitiale Datenbank dieses Problem nicht besser löst. Das Ergebnis sieht ja so aus, als ob zunächst nur die Knoten innerhalb einer gegebenen bbox gesucht werden und dann die referenzierenden Objekte (Weg → Relation). Ist die Performance der Grund?
Also mal abgesehen davon, dass der Sachverhalt nicht neu ist (aka mehr als ein Jahrzehnt bekannt), ist es nicht nur eine Performancefrage. Wie du weisst haben im aktuellen Datenmodel Ways schlicht und einfach keine eigene Geometrie (zum Thema gabs in Milano letztes Jahr einige Diskussionen, aber man darf den Aufwand das zu ändern nicht unterschätzen), deshalb würde eine spatiale Datenbank zuerst einmal gar nichts bringen. Natürlich könnte man das umgehen (sprich z.B. eine Way Boundingbox in der DB speichern und bei Lageänderungen der Way-nodes die Boundingbox updaten), aber schlussendlich ist es vielleicht doch besser einfach ein paar zusätzliche Punkte in den Way zu machen.
Soweit ich weiß, ist die Hauptdatenbank ist gar keine spatiale (räumliche, geographische) Datenbank, sondern eine reine PostgreSQL ohne PostGIS Erweiterung [1] [2]. Die räumliche Indizierung der Nodes erfolgt über eine eigene “QuadTiles” Implementierung [3] [4].
OSM-carto (und die 3 anderen Kartenstile)
iD