Die zusätzliche Konvention wurde ja schon genannt: der kürzeste mögliche Weg ist zu nehmen.
Bei einer Linie zwischen 50°N, 179,999°E und 50°N, 179,999°W wird eine Linie von 0,002° in horizontale Richtung draus (was bei 50° Breite einer Linienlänge von 143 m entspricht).
Wenn ich 179,999 - (-179,999) rechne, erhalte ich zwar 359,998, modulo 180 ergibt dies jedoch -0,002°, Betrag somit 0,002°.
Alternativ könnte ich eine der beiden Seiten als Bezugssystem wählen, dann würde aus dem jeweils anderen Wert dann 180,001° bzw. -180,001°, wohlgemerkt als Zwischenergebnis, nicht in den Daten.
Und das würde alle in den Daten existierende Wege, die mehr als 180 Längengrade umspannen, die mit der jetzigen Konvention erstellt wurden, kaputt machen (und nach einem Wechsel wäre es auch nicht möglich ein solcher Weg zu erstellen).
Jetzt magst du zurecht sagen, dass solche Wege höchstens selten in den eigentlichen Daten vorkommen (ausser als bounding boxes von changesets, da ist das häufig), aber es ist natürlich so, dass es haufenweise Tools gibt, die auch die OSM Konvention verwenden und all die hätten mit einem Wechsel auch Probleme.
Bräuchte man nicht, wenn man modulo rechnet.
Nur: Der Aufwand (“alles” ändern) ist im Prinzip derselbe.
Zur Verdeutlichung: Die Linie zu nehmen, die den +/-180°-Meridian nicht schneidet, ist gleichbedeutend damit, dass dort die Welt zu Ende ist.
Aber zurück zur ursprünglichen Frage: Ich halte es nicht für ausgeschlossen, dass es Funktionen in einer GIS-Software (nicht OSM) gibt, die mit dieser Grenze umgehen können.
Noe, ±90°, die 85° sind nur wenn spherical mercator als Projektion verwendet werden, du kannst problemlos (halt ohne Standard-Tiles) in dem Bereich editieren und Objekte hinzufügen, wenn der Editor eine andere Projektion unterstützt.
Nochmals: dein Vorschlag würde nur eine Art von Geometrie (über die Datumsgrenze) die man in OSM nicht darstellen kann mit einer anderen (mehr als 180° “Länge”) ersetzen.
Das Darstellungsproblem könnte man ja lösen, indem man Liniensegmente, die auf dem Antimeridian liegen (automagisch detektiert oder nach Taggen desselben …), eben nicht darstellt (sollte irgendwo doch eine echte Grenze auf (-)180 liegen, ginge nur letzteres …)
Die Router müssten halt nachschauen, wenn der Endpunkt einer Straße auf b,180 liegt, ob es einen Straßenendpunkt auf b,-180 gibt, dann eben dort weitermachen …
