OpenStreetMap Forum

The Free Wiki World Map

You are not logged in.

#501 2018-01-11 10:36:30

glglgl
Member
Registered: 2014-06-19
Posts: 317

Re: Internationale Admingrenzen 2017

SimonPoole wrote:
glglgl wrote:

..

Mit "keine Wahl" stimme ich nicht zu. Man könnte bei einer Verarbeitung einer Linie (oder letztendlich auch Relation) zunächst feststellen, ob sie überhaupt von dem Problem betroffen ist (sprich, ob ein Längengradsprung über die ±180°-Linie hinweg vorhanden ist). Falls ja, wäre lediglich die Operation einmal im ±180°-Raum und einmal im 0…360°-Raum durchzuführen und beide Ergebnisse zu bewerten.

Das bringt eben nichts.

Grundsätzlich ist es so, dass wenn du einen Wertebereich von 360° hast, du die Information nicht in den Koordinaten kodieren kannst. Da kann man solange hin und her schieben und modulo rechnen wie man will, es braucht immer eine zusätzliche Konvention (im Fall von OSM ist es den Grosskreissegment zu nehmen, dass die Datumslinie nicht kreuzt).

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.


glglgl

Offline

#502 2018-01-11 10:40:36

glglgl
Member
Registered: 2014-06-19
Posts: 317

Re: Internationale Admingrenzen 2017

BTW, wie ist es eigentlich mit dem Routing innerhalb http://osm.org/relation/3241868? Funktioniert das?


glglgl

Offline

#503 2018-01-11 10:51:14

SimonPoole
Member
Registered: 2010-03-14
Posts: 1,624

Re: Internationale Admingrenzen 2017

glglgl wrote:
SimonPoole wrote:
glglgl wrote:

..

Mit "keine Wahl" stimme ich nicht zu. Man könnte bei einer Verarbeitung einer Linie (oder letztendlich auch Relation) zunächst feststellen, ob sie überhaupt von dem Problem betroffen ist (sprich, ob ein Längengradsprung über die ±180°-Linie hinweg vorhanden ist). Falls ja, wäre lediglich die Operation einmal im ±180°-Raum und einmal im 0…360°-Raum durchzuführen und beide Ergebnisse zu bewerten.

Das bringt eben nichts.

Grundsätzlich ist es so, dass wenn du einen Wertebereich von 360° hast, du die Information nicht in den Koordinaten kodieren kannst. Da kann man solange hin und her schieben und modulo rechnen wie man will, es braucht immer eine zusätzliche Konvention (im Fall von OSM ist es den Grosskreissegment zu nehmen, dass die Datumslinie nicht kreuzt).

Die zusätzliche Konvention wurde ja schon genannt: der kürzeste mögliche Weg ist zu nehmen.

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.

Last edited by SimonPoole (2018-01-11 11:02:13)

Offline

#504 2018-01-11 11:12:07

glglgl
Member
Registered: 2014-06-19
Posts: 317

Re: Internationale Admingrenzen 2017

seichter wrote:

Auch an den Polen kommt man mit den Längengraden ziemlich in Schwierigkeiten, aber da kommt man beim Mapping ebenfalls nur selten hin.

Sprich: nie. Die Werte für die breite liegen bei OSM im Intervall ±85,x°.


glglgl

Offline

#505 2018-01-11 11:34:56

seichter
Member
Registered: 2011-05-21
Posts: 2,413

Re: Internationale Admingrenzen 2017

SimonPoole wrote:

Eine mögliche Lösung wäre ein Wertebereich von -360° bis +360° Grad für die geographische Länge zuzulassen (was aber eben bedeuten würde "alles" zu ändern).

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.

Offline

#506 2018-01-11 11:49:23

SimonPoole
Member
Registered: 2010-03-14
Posts: 1,624

Re: Internationale Admingrenzen 2017

glglgl wrote:
seichter wrote:

Auch an den Polen kommt man mit den Längengraden ziemlich in Schwierigkeiten, aber da kommt man beim Mapping ebenfalls nur selten hin.

Sprich: nie. Die Werte für die breite liegen bei OSM im Intervall ±85,x°.

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.

Offline

#507 2018-01-11 12:15:55

SimonPoole
Member
Registered: 2010-03-14
Posts: 1,624

Re: Internationale Admingrenzen 2017

seichter wrote:
SimonPoole wrote:

Eine mögliche Lösung wäre ein Wertebereich von -360° bis +360° Grad für die geographische Länge zuzulassen (was aber eben bedeuten würde "alles" zu ändern).

Bräuchte man nicht, wenn man modulo rechnet.

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.

Offline

#508 2018-01-11 12:48:10

MKnight
Member
Registered: 2012-08-01
Posts: 1,676

Re: Internationale Admingrenzen 2017

glglgl wrote:

BTW, wie ist es eigentlich mit dem Routing innerhalb http://osm.org/relation/3241868? Funktioniert das?

Wenn's beruhigt: google kann's auch nicht...


gesammelte Overpass-abfragen zu QA (hauptsächlich Strassenfehler) + verschiedene Stats zu Strassen-eigenschaften

Offline

#509 2018-01-11 13:30:22

glglgl
Member
Registered: 2014-06-19
Posts: 317

Re: Internationale Admingrenzen 2017

SimonPoole wrote:
seichter wrote:
SimonPoole wrote:

Eine mögliche Lösung wäre ein Wertebereich von -360° bis +360° Grad für die geographische Länge zuzulassen (was aber eben bedeuten würde "alles" zu ändern).

Bräuchte man nicht, wenn man modulo rechnet.

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.

Wo hier nun die Datumsgrenze ins Spiel kommt (oder kam), erschließt sich mir nicht. Sie ist es nämlich nicht, an der es nicht funktioniert.

Vernünftig implementiert, würde alles funktionieren, auch das im anderen Beitrag (s. u.) angesprochene Routing innerhalb von Fidschi.

MKnight wrote:
glglgl wrote:

BTW, wie ist es eigentlich mit dem Routing innerhalb http://osm.org/relation/3241868? Funktioniert das?

Wenn's beruhigt: google kann's auch nicht...

Ein schwacher Trost. Ich könnte mir vorstellen, dass das den Menschen vor Ort (so sie diese Dienste nutzen) das nicht so prickelnd finden.

Edit: Fidschi, nicht Tahiti.

Irgendwie sind wir hierfür aber im flhcasen Thread :-O

Last edited by glglgl (2018-01-11 13:32:30)


glglgl

Offline

#510 2018-01-12 17:33:34

Schienennagelhammerträger
Member
Registered: 2017-03-03
Posts: 65

Re: Internationale Admingrenzen 2017

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 ...

Offline

#511 2018-01-31 02:00:56

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 15,439
Website

Re: Internationale Admingrenzen 2017

-snip-

Last edited by wambacher (2018-01-31 02:01:22)

Offline

Board footer

Powered by FluxBB