Wikivoyage:Expedition 'Georeferenzierung'
 |
EXPEDITION GEOREFERENZIERUNG |
Diese Seite dient der Erarbeitung von Grundlagen und Lösungen zur Georeferenzierung von Artikeln.
Möglichkeiten
Wikimedia extension
- wikimedia extension - eventuell könnte uns diese extension weiterhelfen.
- point mapping extension - hier auf GIS Wiki wird sie weiter beschrieben, die Lizenz ist CC-BY-SA 2.0 DE
Freie Daten
- Die Daten dieser Quelle einlesen und verwenden. Daten sind PD.
- NOAA - High Resolution Shore Lines.
- Bei NOAA gibt es coastline Daten und politische Grenzen von WDB II. Wegen Zerstückelung der Daten eigentlich nur für interaktiven Gebrauch nützlich.
- SRTM - Höhendaten mit 3 Bogensekunden (90 m) Auflösung weltweit, ohne Schnick-Schnack Klick-dich-tot User-Abschreckungs-Interface. Direkt auf FTP-Server. USA auch mit 1 Bogensek. Auflösung.
- World Data Bank II - Küsten, Flüsse, pol. Grenzen von CIA, 1980. Gedacht für Maßstab 1:2.000.000
Weitere Datenquellen
- Hier gibt es die VMAP 0 Daten, es sind Vektordaten.
Lizenz: The following caveats are expressed by NIMA regarding VMAP0:
* The data structure and information content of NIMA's digital products are prescribed by DoD
Military Specifications. Deletions, additions, or modifications to NIMA's digital files by
users become local transaction files (no longer NIMA products) and are the responsibility
of the user to control.
* Several maps and charts many be based in whole or in part on information from other official
U.S. Government sources. Copyright, classification or othr restrictions may continue to
exist. Refer to the original source and compilation material for this information.
* The representation of international boundaries on the various maps and charts is not
necessarily authoritative.
* Users should refer corrections, additions, and comments to the NIMA Customer Help Desk:
1-800-455-0899, Commercial, 314-260-1236, DSN 490-1236, or write to:
- Höhen- und Tiefenangaben interessant als globales Relief
- Die NASA hat mit world wind ein interessantes open source Projekt. Es ähnelt google earth ist aber anpassungsfähiger und bietet mehr Daten.
- Linksammlung - Washington State Geospatial Data Archive
- Linksammlung - Bibliotheksseite aus den USA
- Penn State University DCW (Digital Chart of teh World) als ftp download
Web basierte Ausgabe
Kommentare
Die serverseitige Generierung von Karten scheint mir der richtige Weg zu sein, denn damit ist auf jeden Fall gewährleistet, dass die Karten das gleiche Look and Feel haben. Außerdem können sie mit relativ geringem Aufwand durch Benutzer erzeugt werden. Aber auch die Probleme werden in den Beschreibungen klar: CPU- und RAM-Belastung. Bezüglich des Algorithmus scheint die Positionierung der Beschriftungen das größte Problem zu sein, was ich mir auch gut vorstellen kann. Dennoch: Ich meine, dass wir mit den Extensions etwas experimentieren sollten. Zur Zeit haben wir noch einige Reserven mit unserer Hardware. -- Hansm 15:11, 2. Mär. 2007 (CET)
- GNS kommt mir bekannt vor. Ich glaube, ich bin da schon mal drüber gestolpert. Das Hauptproblem bei der Verwendung dieser Daten ist immer noch der Algorithmus zur Platzierung der Namen.
- Für mich sieht der grobe, mittel- bis langfristige zeitliche Fahrplan so aus:
- Locations Datenbank, auch mit Hinblick auf Geo-Daten
- Serverseitige Generierung von Karten
- Printausgabe individueller Reiseführer im PDF-Format
- Die Herausforderungen nehmen von Punkt zu Punkt zu. Es ist richtig, alles im Auge zu behalten und zu sammeln, aber konkrete Auswertung erst, wenn es an der Zeit dafür ist.
- World Wind ist für meine Begriffe eher ein nettes Spielzeug, aber ich glaube nicht, dass wir es für unsere Zwecke verwenden können. Es benutzt u.a. SRTM, das werden wir sicher brauchen, aber als eigenständige Datenquelle.
- Die Original-Doku für VMAP 0 Daten ist an Grausamkeit kaum zu überbieten. Über 250 eingescante Schreibmaschinenseiten, wo es mit „Eine Datei ist eine Folge von Bytes“ anfängt, sich ansonsten aber in einem Dschungel von internen Verweisen verliert. Ich habe es bisher nicht geschafft, die Kodierung dieser Daten zu verstehen. Der Inhalt ist aber genau das, was wir noch brauchen.
- Bei VMAP 0 steige ich so langsam durch. PDF war zum Glück doch nicht eingescant, sah nur so aus. Damit funktioniert wenigstens die Suche im Text.
- Wo sollen denn bei NOAA politische Grenzen zu bekommen sein? Die finde ich nicht.
- Unter Coastline Database ist ein drop down Menu, da gibts "all political boundaries".--(WV-de) Der Reisende 17:51, 13. Mär. 2007 (CET)
- Danke, jetzt hab ich's kapiert. Dieses neumodische Zeug mit Maus und Pull-Down-Menü ist einfach nix für alte Leute. Die Daten machen einen besseren Eindruck als die von VMAP0. Auf jeden Fall kommt man ohne Umschweife zu dem, was man eigentlich braucht. -- Hansm 10:25, 14. Mär. 2007 (CET)
- Ich habe mich heute nochmal genauer mit VMAP0 befasst und meine, inzwischen einigermaßen gut verstanden zu haben, wie die DB aufgebaut ist und wie man die Daten da herausbekommt. Das ganze Zeug ist ist gut 10 Jahre alt und auf Stand-Alone-Desktops der Kategorie 486er ausgelegt. In entsprechend kleine Stücke sind die Daten zerhackt. Man findet zwar alles in der Doku, aber sie ist nicht gerade leserfreundlich. Letztendlich ein Dschungel an (impliziten) Verweisen, der eigentlich gar nicht nötig wäre, wenn man alles in einer großen DB hätte. Trotz allen Unannehmlichkeiten hat VMAP0 einiges zu bieten. Die Grenzverläufe (leider nicht ganz so frei) sind z.B. bei ungefähr gleicher Auflösung aktueller als die von NOAA. Dort gibt es noch die DDR mit ihren Bezirken (hihi). Man kann schätzungsweise bis auf einen Maßstab von 1:200.000 herunter fahren, ohne dass es allzu furchtbar aussieht.
- Bisher setze ich auf eine Mischung aus VMAP0 (Flüsse, Straßen, Bahn), NOAA (Küstenlinien, politische Grenzen), GNS (Koordinaten und Beschriftung von Städten und markenten Punkten) und SRTM (Höhenprofile, Relief). Alle Daten müssten in eine DB (PostGIS) importiert werden (hoffentlich reichen da unsere Harware-Resourcen). Wenn man das mit der geplanten Location-DB, besonders Koordinaten und IstIn-Info, kombiniert, müsste es eigentlich möglich sein, als Hintergrund-Job im Laufe der Zeit zu jeder Region eine halbwegs brauchbare Roh-Karte automatisch zu erzeugen. Ganz perfekt wird sie nicht sein, so dass manuelle Nacharbeit meistens nötig ist, aber wenigstens eine Basis für eine Karte. Besonders die Platzierung der Beschriftungen ist ein Problem für die Maschine. Und natürlich gibt es bestimmt auch Fehler in den Daten. Wenn man dann manuelle Korrekturen in die DB zurückfüttern könnte, hätten wir vermutlich eines der kühlsten Kartensysteme im Netz. (Utopien müssen sein!)
Wikivoyage rules.--(WV-de) Der Reisende 08:28, 15. Mär. 2007 (CET)
- Sure. Aber: Also das mit VMAP0 ist ja schon eine ganz schön vertrackte Sache. Entweder, ich habe irgendeinen saublöden Fehler beim Einlesen der Daten gemacht, oder die Daten sind alles andere als selbst-konsistent. Im Großen und Ganzen sieht das ja erst mal ganz vernünftig aus, aber wenn man sich das genauer ansieht, hat man den Eindruck, dass hier Topologen ein sehr schönes, aber wenig zielorientiertes Konzept aus der Schublade gezogen haben, das die Informatiker nur teilweise kapiert haben und von den Kartographen vollkommen ignoriert wurde. Entsprechend strubbelig sind die Daten. Da ich nur ein Programm für aussterbende Betriebssysteme gefunden habe, das die Daten interpretieren kann, und ich das ganze sowieso lieber selbst in der Hand haben will, habe ich testweise ein paar Probedaten in eine PostgrSQL/PostGIS Datenbank gezogen (Fehler nicht ausgeschlossen, Schwerpunkt Wasser). Ca. 20% der Wasserflächen, h.d. Seen sind bei mir keine. Statt dessen sehe ich ein teilweise etwas wirres Liniensystem, das u.U. Flussläufe representieren könnte. Aber dass sich Flüsse kreuzen, ist mir ehrlich gesagt neu. Kurz und gut: So erschöpfend schlau werde ich aus den VMAP0-Daten noch nicht. -- Hansm 23:05, 19. Mär. 2007 (CET)
- Ein Programm gibt es von globalmapper als kostenloses Demo. Das kann zumindest die Daten lesen und grafisch aufbereiten. Die könntest Du dann vergleichen. Es gibt einen open source Flugsimulator namens Flight Gear, der seine Geländeinformationen (Was ist Was) aus VMAP Daten bezieht. allerdings weiss ich nicht genau wie. Ein Opensource Programm namens TerraGear ist involviert.--(WV-de) Der Reisende 08:38, 20. Mär. 2007 (CET)
- Naja, die Dateiendung .exe kommt mir seltsam vor. Wenn ich mich dunkel erinnere, wird sie ebenfalls von einem aussterbenden Betriebssystem benutzt. Ich werde wohl nicht drumrum kommen, WINE (Windows Emulator) zu installieren. -- Hansm 10:00, 20. Mär. 2007 (CET)
Check mal open map basiert auf Java und schsu Dir mal diese Linksammlung an. Ich habe leider keine Ahnung von Datenbanken. VMAP Download geht auch von hier, vielleicht haben die eine bessere Aufteilung der Daten. Habe noch was gefunden gvsig, hört sich interessant an. Ist GNU--(WV-de) Der Reisende 12:44, 20. Mär. 2007 (CET)
Noch was gefunden! hier macht Bilder aus Daten und hier Gis Programm. --(WV-de) Der Reisende 13:10, 20. Mär. 2007 (CET)
- Inzwischen sehen meine Seen wirklich wie Seen aus. Ich glaube, jetzt habe ich die Datenstruktur von vmap weitestgehen verstanden. -- Hansm 00:48, 21. Mär. 2007 (CET)
Ideen zur Umsetzung
Datenquellen
Wir sind auf freie Daten, die auch kommerzielle Nutzung erlauben, angewiesen. Ob es mittel- oder langfristig möglich ist, Datensätze zu kaufen, ist fraglich. Bleiben wir also bei freien Daten. Es gibt eine fast unüberschaubare Menge an lokalen Datensätzen, die nur bestimmte Länder oder Regionen oder nur bestimmte geologische Aspekte abdecken. Die USA sind hier scheinbar besonders freigiebig. Was die Sache schwierig macht, ist, dass praktisch jeder Anbieter sein eigenes Datenformat benutzt. Die Handhabung ist entsprechend kompliziert. Es sind jedoch auch einige wenige globale Datensätze verfügbar. Für den Anfang ist das vermutlich die am meisten erfolgversprechende Möglichkeit.
Nach dem bisherigen Stand der Erkenntnis sind folgende Quellen interessant:
- SRTM3 - Höhendaten zwischen den beiden 60. Breitengraden mit 3 Bogensekunden (ca. 90m) Auflösung, jedoch einige Datenlöcher.
- SRTM30/GTOPO - Höhendaten mit 30 Bogensekunden Auflösung weltweit ohne Löcher.
- SWDB - Küstenlinien, Seen und breite Flüsse mit 30 Meter (!) Auflösung, basierend auf SRTM-Daten, also nur zwischen den beiden 60. Breitengraden.
- NOAA - Ebenfalls sehr hochauflösende Küstenlinien, etwas ungenauer als SWBD, aber dafür weltweit.
- ETOPO2 - Meerestiefen auf 2 Bogenminuten genau. (Landhöhen auch, aber durch SRTM nicht mehr interessant)
- VMAP0 - Flussläufe, Seen (nördl. des 60. Breitengrads), Straßen, Eisenbahn, Vegetationszonen, Gletscher mit ca. 2km Genauigkeit. Pol. Grenzen unterliegen leider für uns nicht akzeptablen lizenzrechtlichen Einschränkungen.
- WDBII (Wold Data Base II) - Politische Grenzen, Stand 1980, Auflösung ca. 5km.
- GNS - ca. 6,5 Mio. Orts-, Fluss-, Gelände- und Regionennamen, leider nur mit einer Auflösung von ca. einer Bogenminute (ca. 1,5km).
Alle diese Daten liegen bereits auf dem Server, ca. 15-20 GB (!).
Zielsetzung
Wir haben nicht die Resourcen um einen eigenen interaktiven Map-Server aufzubauen. Die Anforderungen an Prozessorleistung, RAM und Festplattenplatz wären zu hoch für unseren Server. Es sollte jedoch möglich sein, Karten als Hintergrundprozess zu erzeugen. Die Zeit zur Erstellung der Karten ist dann kaum von Bedeutung, dafür können wir es uns leisten, auf Qualität zu optimieren. Es sollte möglich sein, nach und nach für jede Region eine brauchbare Karte zu erstellen. Die Genauigkeit der geophysikalischen Daten (Höhen, Wasser) reicht für Maßstäbe bis 1:200.000, mit Abstrichen auch darunter. Transportwege (Straßen, Bahn) und Grenzverläufe halten da nicht ganz mit. Hier wird eine manuelle Nachbearbeitung nötig sein. Koordinaten der Orte sind durch die Geo-Vorlage prinzipiell in ausreichender Genauigkeit vorhanden, allerdings müssten sie erst in eine Locations-Datenbank aufgenommen werden, damit sie ohne großen Aufwand ausgelesen werden können.
Datenbank
Für PostgrSQL gibt es eine GIS Erweiterung, die einen sehr vielversprechenden Eindruck macht. Die Daten aus den verschiedenen Datensätzen müssen in ein möglichst einheitliches Datenbankformat gebracht werden, damit sie leicht aufbereitet werden können. Rasterdaten (Höhen) werden als Binärdateien gespeichert. Grundsätzlich sind die verschiedenen Datenformate ausreichend gut dokumentiert. (Ich habe inzwischen für alles ein kleines Progrämmchen zur Konvertierung.)
Probleme
- SRTM3-Daten müssen in teilweise größerem Umfang interpoliert werden. Das ist ein einmaliger Vorgang, der auch etwas länger dauern darf. (Wie das genau geht, ist mir noch nicht ganz klar. Irgendwie mit Flächen-B-Splines und Stützpunkten aus SRTM30.)
- Transportwege und Flussläufe sind in den VMAP0-Daten nicht fein genug kategorisiert, so dass nicht so einfach zu entscheiden ist, was bei größeren Maßstäben weggelassen werden sollte.
- Transportwege (teilw. auch Flussläufe) haben Lücken, die nur manuell gefüllt werden können.
- Grenzverläufe sind eigentlich zu alt (Da gibt es noch die DDR.).
- Layout der Wikivoyage-Karten sollten Experten übernehmen.
- Anbindung an MediaWiki noch unklar, nur grobe Idee.