Aus Geokoordinaten Lokalzeit berechnen

[Meflin]

Moin moin!

Dieses Thema steht bewusst in Programmieren allgemein, da es mir nicht um die Umsetzung in einer bestimmten Sprache, sondern vielmehr um die Problematik im Allgemeinen geht.

Auf einer Weltkarte können beliebige Punkte markiert werden. Zu diesen Punkten sind die Geokoordinaten bekannt (GPS-Koordinaten). Zu diesen Punkten soll nun automatisch die dortige Lokalzeit berechnet werden.

Das ganze wäre ja schön einfach, wenn die Zeitzonen strikt eingehalten worden wären. Dann müsste man nur den Längengrad betrachten und wüsste, was man dazu bzw. wegrechen muss. Bekanntlich ist das ja aber leider nicht der Fall und es geht da teilweise "drunter und drüber"
(vgl: http://www.mygeo.info/karten/zeitzon...e_cia_2007.png )

Die einzige Idee, die ich nun spontan hatte, wäre die Zeitzonen irgendwie in Poygone zu packen und die Geokoordinaten irgendwie in das Koordinatensystem dieser Polygone zu übertragen. In welchem Polygon sich ein Punkt befindet sollte ja mathematisch lösbar sein. Aber auch das ist nur eine vage Idee und weit von einer konkreten Implementierungsstrategie entfernt.

Habt ihr irgendwelche anderen / besseren / detaillierteren Ideen, wie man dieses Problem lösen könnte?

[LuCSteR]

Ich denke das der Ansatz mit Recht - und Vielecken nicht zu vermeiden ist. Die Frage ist nur wie genau die Bestimmung sein muss. Schließlich verlaufen Zeitzonen u.a. an Ländergrenzen entlang, die in Polygonen erfasst werden müssten. Da hast ja ewig zu basteln.

Die Karte hier würde die Arbeit erheblich erleichtern ^^
Zeitzonen

[Phoenix]

Schau mal bei den Webservices der Earthtools vorbei ;-)

[Meflin]

Zitat:

Zitat von LuCSteR

Die Frage ist nur wie genau die Bestimmung sein muss.

Die Antwort ist einfach: So genau wie praktikabel :mrgreen:

@Sebastian: OK, Danke, das ist sicherlich auch eine Lösung. Von der ich aber nicht unbedingt abhängig sein möchte. Erstens weiß niemand, wie lange es den Dienst (in dieser Form, kostenfrei, unter diesen Lizenzbedingungen, überhaupt) noch gibt, und er setzt in meiner Anwendung zwingend einen Internetzugang vorraus :( Und zweitens seh ich da auch die Performance als Problem. Da kann die Abfrage von 1000 Koordinaten ja schnell mal ne halbe Stunde dauern, was in 0,nix berechnet wäre.

[Phoenix]

Er schreibt in der Beschreibung, dass er die Daten auch Lizenzieren würde (insbesondere, wenn es viele Abfragen wären und man vor hätte, die über einen längeren Zeitraum zu cachen).

[Meflin]

Zitat:

Zitat von LuCSteR

Schließlich verlaufen Zeitzonen u.a. an Ländergrenzen entlang, die in Polygonen erfasst werden müssten.

Hm, die Ländergrenzen könnte man sich wiederum als Koordinaten von Openstreetmap holen. Die Frage ist dann: Wie bekommt man daraus dann Polygone.

ein weiteres Problem sind ja dann noch die unregelmäßigen Zeitzonengrenzen, die aber NICHT an Ländergrenzen entlang gehen. Wo sind die denn definiert? Gibts für die vielleicht auch irgendwo Koordinaten? Sonst könnte man die ja nur schätzen :(

[Jakob Ullmann]

Wie wärs mit einem eingefärbten Bitmap? Dirty, klar, aber es würde gehen. :)

[kalmi01]

Zitat:

Zitat von Jakob Ullmann

Wie wärs mit einem eingefärbten Bitmap? Dirty, klar, aber es würde gehen. :)

wieso ist diese Lösung "schmutzig" ?
Die Auflösung der Bitmap bestimmt die Genauigkeit und könnte somit später erhöht werden, wenn notwendig.
Einzig der Speicherbedarf der Bitmap mag irgendwann sehr gross sein.

[Der Jan]

Die Idee mit der Bitmap ist in der Tat nicht schlecht. Die Auflösung hinge dann von der Genauigkeit der Koords ab. Wenn die nur gradgenau sind, wäre die gar nicht so hoch (360 Grad = 360 Pixel). Was du berücksichtigen musst, viele Länder haben keine Sommerzeit und es gibt, oder gab zumindest mal, Verschiebungen um halbe Stunden. Das war, glaube ich im mittleren Osten, Pakistan oder so.

[Meflin]

Zitat:

Zitat von Jakob Ullmann

Wie wärs mit einem eingefärbten Bitmap? Dirty, klar, aber es würde gehen. :)

Gut, diese Lösung verschiebt aber nur das Problem: Woher bekomme ich ein ausreichend genaues Bitmap? Angenommen das Bitmap wäre 1000px breit, dann würde jeder Pixel immernoch ca. 50km Repräsentieren. Die Koordinaten liegen auf wenige Meter genau vor. Das wäre also VIEL zu ungenau :shock:

So ca. eine Genauigkeit von < 1000m würde ich schon anstreben! Das bedeutet das Bitmap müsste über 50.000 Pixel breit sein :stupid:

Wie gesagt, zu Zeitzonen an Ländergrenzen dürften sich genaue Daten bekommen lassen. Zu den regelmäßigen Zeitzonen auch, da sie ja genau auf den Graden verlaufen. Problem sind dann eigentlich nur noch die Ausreißer, die aber nix mit Ländergrenzen zu tun haben :gruebel:

[Meflin]

Zitat:

Zitat von Meflin

Problem sind dann eigentlich nur noch die Ausreißer, die aber nix mit Ländergrenzen zu tun haben :gruebel:

*push*

keiner ne Idee, wo die genauer definiert sein könnten? :(

[Jakob Ullmann]

Genau deshalb hab ich gesagt "schmutzig". Und weil es kantig aussieht. Man könnte das Problem dann aber folgendermaßen lösen:

1. Du nimmst mehrere Bitmaps und lädst immer nur das gebrauchte aus einer Datei.
2. Oder du rechnest ein bisschen.

Beides würde sich natürlich auch kombinieren lassen. Also du bestimmst erst via Bitmap die Zeitzonen, die überhaupt in Frage kommen. Und dann rechnest du genau nach. Meistens ist das ja nicht so das Problem, weil man ja allerhöchstens zwei Strecken hat, die ausschlaggebend sind.

Aber suchst du jetzt nur nach einem Lösungsansatz oder auch eine (vertrauenswürdige) Quelle?

[Der Jan]

Also Ideen hab ich echt langsam keine mehr, aber vlt. findest du hier ne passende Map.

Dieses Bild ist dir sicherlich zu ungenau :)

[BoolString]

Die Geschichte mit dem Bild ist ja vielleicht halbwegs praktikabel. Aber du müsstest dann keine Karte mehr haben, sondern farbige Streifen. Schließlich soll das ganze ja auch auf dem Wasser gehen und es gibt sicherlich sinnvollere Anwendungen für Geopositionierungsgeräte als jemandem den Weg zur nächsten Bäckerei zu zeigen (wobei denjenigen die Zeitzone dann vermutlich nur in Bezug auf Öffnungszeiten interessiert).
Wie Meflin schon sagte: Erschwerend kommt hinzu, daß sich Bundesländer des gleichen Staates teilweise in den Zeitzonen unterscheiden. Ebenfalls sind Satellitengebiete und Enklaven teilweise an die Zeit des Mutterlandes gekoppelt und damit ganz woanders eingeordnet, als wie es ein GPS Signal vermuten läßt.

Ich bin mir nicht sicher, ob eine Auflösung <1000m wirklich nötig ist. Meiner Meinung nach ist das ein immenser Aufwand, bei dem man die Realisation zum angestrebten Ziel nicht aus dem Auge verlieren sollte. Innerhalb Europas hast du schon das erste Beispiel an der Grenze Spanien/Portugal (Mäander and der galizischen Grenze, wo auf einem Transekt parallel zu Fluß alle paar hundert Meter zwischen Spanien und Portugal wechseln müsstest). Ich denke für die meisten Fälle genügt, wenn du die die Grenznähe auf 10km genau erkennst und vielleicht ein kleines Symbol einblendest, was den Nutzer auf die Nähe zur Zeitzone aufmerksam macht (damit kannst du deutlich geglättete Polygone verwenden). Außerhalb Europas gelten sowieso oft andere Zeitmaßstäbe und die Menschen können sich prima damit anfreunden, daß sie Zeit in einer Spanne von 1-2 Stunden genau angeben können ;-)

Schau dir mal den Seitenquelltext zu diesem Link an:

http://upload.wikimedia.org/wikipedi...ectangular.svg

Da hast du auf jeden Fall schon mal eine vektorisierte Form der einzelnen Länder, größeren Seen und Wasserflächen. Die müsstest du dann aber per Hand noch auf dein Kartendatum umrechnen. Wenn du GPS verwendest vermute ich mal, daß es sich dabei um WGS84 handelt.

Ansonsten Google mal nach GTOPO und ETOPO Karten und Layern. Es gibt freies Kartenmaterial für wissenschaftliches Mapping mit Auflösung <30 Sekunden. Allerdings hast du dann eine riesigen Datenberg, Bestimmung von Punkten in Polygonen wird bei solchen Sachen aasig langsam und du musst dir Importroutinen für das Format schreiben...

Jan

[hazard999]

check mal das:

Zeitzonenkarte in SVG


da das ganze ja eine Vectorgrafik ist, hättest du schon deine Polygone.

Nur mehr auf UTM oder GeoDez umrechenen, PointInPoly implementieren, fertich.