Ich versuche eben den letzten Teil von Russland (Chutoka) zu rendern und scheitere an einem verrückten Problem.
Das Border-Poly geht über die OSt/West Grenze (+/- 180°) und das resultierende File sieht so aus
Sowahl Osmosis als auch Pyghtmap rendern nun sozusagen das “Negativ” des polys.
Öffnet mal dieses poly in Josm (mit aktivierten poly-plugin) oder auch das GPX, dann seht Ihr was ich meine.
Wie rendert man Karten die über die ost/west-Grenze laufen bzw. wie muss man das poly modifizieren um Osmosis zu einem korrekten Auschnitt zu überreden?
Das ist vermutlich überall derselbe Programmier-/Entwurfsfehler:
Die Anzeige darf nicht an 180 bzw. -180 enden, sondern muss modulo 360 - 180 weitergeführt werden, d.h. am rechten Rand von Sibirien muss sich Alaska anschließen und umgekehrt.
Das Mapping dort ist ein einziger Krampf: In die Kreisgrenze z.B. wurden zwei gerade Stücke entlang Längengrad +/- 180 eingefügt, damit man geschlossenen Polygone erhält. Die beiden Hälften liegen um die ganze Erde getrennt am rechten und linken Rand der Darstellung.
Man muss entweder Koordinaten größer 180 / kleiner -180 zulassen und Modulo 360 umrechnen oder zulassen, dass die linke Begrenzung größer als die rechte ist. Die Zweideutigkeit kann man dadurch beseitigen, dass immer die kürzere Linie gewählt wird.
Google Maps macht es übrigens richtig
Wenn ich den Äquator angebe: meine ich dann die Nordhalbkugel oder die Südhalbkugel?
Entweder endet die Welt bei ±180°/±90° und man kann ungerichtete Polygone als Flächenangabe benutzen oder die Welt ist rund und man kann es nicht. Das liegt in der Natur der Sache und kein Fehler von irgendjemand.
Google Maps folgt Renemans Vorschlag und rendert von beiden Seiten. An der einen oder anderen Stelle sind die Unstimmigkeiten beim Zusammensetzen auch recht deutlich.
Da ja in unseren Daten alle Flächen an der Datumsgrenze geschlossen werden und alle Linien enden, bekommt man sowieso eine merkwürdige Kante quer durch das Bild, das kann man durch zweiseitiges Rendern nicht mehr hässlicher machen.
Das Google Maps Beispiel sieht mir danach aus, als würde man jeweils zwei Objekte rendern, ohne dabei die restlichen Nodes der anderen Hälfte zu berücksichtigen. Das führt dann dazu, dass zwischen beiden Flächen ein Leerraum entsteht. Ich würde jedoch spontan zwei Objekte mit allen Nodes rendern.
Wenn das der Renderer kann, wäre es gut. Ich hab allerdings fast nur schlechte Erfahrungen mit der Datumsgrenze gemacht. Mein Mapserver reagiert jedenfalls sehr zickig, wenn man seine Linien nicht an der Kartengrenze aufhören lässt und malt dann Flächen quer durchs Bild, statt am Kartenrand abzutrennen.
Sieht z.B. so aus, wenn man die Kartenmitte auf 180° legt und den Rand auf 0°:
(zur Verdeutlichung wurde Großbritannien rot eingefärbt, das jetzt auf beiden Seiten der Karte liegt, gefüllt wird der Zwischenraum, also alles ausser GB. Gelb ist Algerien)
Im Prinzip richtig. Allerdings stimmt der Winkel der Linien nicht mehr, wenn du den Längengrad einfach auf 180 setzt.
Theoretisch wäre es besser den auf die korrekte Position über 180° hinaus zu setzen. Also -179° sind dann 181°.
Ich weiß allerdings nicht ob die Renderer mit Werten über 180 was anfangen können.
Weder noch, genauso wie die Zahl 0 weder positiv noch negativ ist. Abgesehen davon geht es hier um die Längen- und nicht die Breitengrade. Es ist nur gut, dass es an den Polen so kalt ist, sonst hätten wir noch viel größere Probleme.
Darüber, ob das Verhalten bei 180° ein “Fehler” ist, will ich nicht streiten. Fakt ist, dass die auf OSM basierenden Tools und Karten, die ich kenne, dort eigentlich nicht zufriedenstellend sind.
Die Erdoberfläche ist endlich, aber unbegrenzt (ich falle nirgends über den Rand). Die Grenze +/-180 ist nur pragmatisch begründet. Die Kugelkoordinaten sind auch für Werte außerhalb definiert, sie können jedoch durch modulo auf eindeutige Punkte auf der Oberfläche abgebildet werden. Auch eine Linie (179,89)-(181,89) kann dargestellt werden und ist identisch mit (179,89)-(-179,89).
Bei Google Maps korrigiere ich mich: Dort wird auch nur mit dem +/- 180-Rechteck gearbeitet. Für die Ansicht wird nur das Rechteck links und rechts wiederholt. Die Gebiete um 180° hängen aber nicht logisch zusammen und sind auch getrennt bearbeitet worden, was man an halbierten Seen, Versatz in Straßen und ähnlichem sehen kann.
Die genutzten Algorithmen gehen offensichtlich von einer an den Rändern begrenzten Welt aus. Im Beispiel von maxbe wird das deutlich: Da in GB nicht wie in Sibirien alle Objekte bei 0° aufgeteilt wurden, kommt der Renderer völlig aus dem Tritt, da er nun Nodes zu beiden Seiten des Nullmeridians quer über den Rest der Welt zu verbinden versucht.
Als schwacher Trost bleibt nur, dass auch andere Systeme mit dem Modulo-Sprung so ihre Probleme haben: Die Datumsgrenze wurde nicht zufällig weitgehend auf den 180°-Meridian gelegt.
Ich glaube, ich bin dem was ich sagen wollte nicht durchgekommen. Ich versuchs nochmal:
Wir hättten natürlich die realistischere Kugelform anstelle der platten Fläche mit Rand nehmen können. Wenn wir das getan hätten, dann können wir Flächen nicht durch durch ungerichtete einfache Polygone angeben, da jede solche Linie auf einer Kugel zwei Flächen definiert und es kein Innen und Außen gibt (Der Äquator war nur ein Beispiel).
OSM hat sich dafür entschieden, Flächen über ungerichtete einfache Polygone angeben zu können. Damit war auch die Entscheidung für eine endliche Welt mit Rand gefallen.
OK, jetzt verstehe ich auch die Anmerkung mit den Polygonflächen. Bis auf die Großkreise (wie den Äquator) könnte man versuchen, innen und außen über die kleinere Fläche zu definieren. Bei großen Flächen und komplizierten Konturen wird das aber beliebig mühsam.
Gerichtete Polygone hätte man auch nehmen können, dann wäre innen und außen eindeutig definiert. Aber wenn man sich die Probleme ansieht, die die wenigen gerichteten Ways wie Kliffs und Küsten machen, ist das auch keine praktikable Alternative.
Seien wir nur froh, dass OSM nicht am Kap Deschnew entwickelt wurde und es in der Antarktis keine Städte gibt. Nicht umsonst hält die Merkatorprojektion einen Sicherheitsabstand zu den Polen ein.
Wenn wir festlegen, dass OSM-Objekte in der Länge nur eine Ausdehnung von weniger als 180° haben dürfen (wobei die Datumsgrenze überschritten werden darf) und Flächen keinen der Pole enthalten dürfen, wird das Zeichnen sowohl von Linien als auch von Flächen wieder eindeutig bei relativ einfacher Mathematik. Bei weniger als 90° wird die Mathematik dazu vollends trivial.
Und das bei hinreichend geringer™ Beschränkung der Allgemeinheit.
Seh ich ein. Das wäre die von seichter genannte Variante mit den kleineren Polygonen, aber etwas weiter eingeschränkt, so dass man die Flächen nicht ausrechnen muss.
Da komm ich im Moment nicht drauf…ist aber ja auch schon spät.
