Wikivoyage Diskussion:Kartenprojekt/Stand Ende 2009

Ende 2009 haben wir knapp 1700 Karten auf shared: liegen. Die meisten stammen von MediaWiki/Commons, einige wurden hier nachbearbeitet und manche wurden auch durch WV-Autoren von Hand erstellt. Auf jeden Fall ein buntes Sammelsurium unterschiedlichster Projektionen, Größen und Layouts. Ich möchte auf dieser Seite gerne den derzeitigen Stand bzgl. Karten diskutieren. -- Hansm 16:31, 28. Nov. 2009 (CET)

Lizenzen

Ich kann kaum glauben, dass der Großteil unserer derzeit eingesetzten Karten mit unserer Lizenz vereinbar ist. Trotz intensiver Suche habe ich keine in unserem Sinne freie Quelle gefunden, die global politische Grenzverläufe hergibt. Staatsgrenzen gibt es noch, darunter kann man sich aber alles in mühevoller Kleinarbeit zusammen suchen, wenn das überhaupt möglich ist. Ich würde auch davon ausgehen, dass solche Grenzverläufe in der OSM-Datenbank vorhanden wären, wenn es sie wirklich so frei geben würde. Auf sehr vielen unserer Karten sind allerdings relativ hochauflösende Grenzlinien zu sehen. Woher kommen sie? Klar: "Own work". Wer will das glauben? Ich habe auch hochauflösende Grenzlinien von GADM, aber mir ist eben auch klar, dass sie nicht frei sind. Es gibt möglicherweise jurstische Winkelzüge, mit denen man hindiskutieren kann, dass Grenzverläufe per se keinem Urheberrecht unterliegen können, auch wenn es um digitale Datensätze geht. Ansonsten liegt für meine Begriffe eine groß angelegte URV vor, die auch bei der WP niemand wahrhaben will. -- Hansm 16:31, 28. Nov. 2009 (CET)

Politische Unterteilung auf Karten

Auf vielen von Commons importierten Karten ist eine politische Unterteilung zu sehen. Natürlich, das ist ja für ein Lexikon auch interessant. Ich habe den Eindruck, dass wir zunehmend dem süßen Gift erliegen und diese Unterteilungen einfach übernehmen, wenn sie schon mal auf der Karte sind. In Japan haben wir z.B. eine umfangreiche Sammlung von Skelett-Artikeln über Präfekturen. Die meisten haben wir noch von WT geerbt. Warum gibt es diese Artikel? Meiner Meinung nach aus einem einfachen Grund: Weil die Präfekturen auf der Karte eingezeichnet sind. Noch ein Beispiel: Was hat Hattuşa in der Türkische Schwarzmeer-Region zu suchen, obwohl es ca. 300 km Luftlinie von der Küste entfernt liegt, durch einen mächtigen Gebirgszug vom Meer getrennt ist und landschaftlich klar zu Zentralanatolien gehört? -- Es liegt in der Provinz Çorum und diese ist in Bild:Turkey black sea region.png der Schwarzmeer-Region zugeordnet.

Wohlgemerkt, ich will politische Unterteilungen nicht generell verdammen, aber sie sollten in jedem einzelnen Fall hinterfragt werden. Unsere Karten müssen sich nach unserer Hierarchie richten, nicht umgekehrt.

-- Hansm 16:31, 28. Nov. 2009 (CET)

Flexibilität

Karten machen einen Haufen Arbeit. Änderungen darauf ebenso. Jüngstes mir bekanntes Beispiel ist Image:Regions Africa.svg. Kamerun wurde von West- nach Zentralafrika verschoben, nachdem User:(WV-de) Pinter gute Gründe dafür bringen konnte. Die Karte hat sich dabei natürlich nicht geändert und zeigt jetzt eine falsche Einteilung an. Sie ist auch klickbar, natürlich jetzt ebanfalls falsch. Ich fürchte, es ist eine Frage der Zeit, bis jemand diese Unstimmigkeit bemerkt und unsere Hierarchie der vorhandenen Karte anpasst. -- Hansm 16:31, 28. Nov. 2009 (CET)

Weiche Grenzen

Viele unserer Regionen haben keine scharfen Grenzen. Es liegt im Ermessen der Autoren, wie ein Artikel eingeordnet wird. Stellenweise führt das zu einem wilden Flicketeppich mit stark zerlöchterten Regionen. Es wurde an einigen Stellen der Versuch unternommen, solche Regionen über anklickbare Karten zu verlinken. An dieser Stelle legt sich der Kartenautor fest, welche Flächenstücke der Karte er welcher Region zuordnen will. Als Leser würde ich dann natürlich erwarten, dass ich einen Artikel zu einem Ort finde, wenn ich auf die entsprechende Stelle der Karte klicke. Dummerweise passen solche handgefertigten Karten oft nicht mit der tatsächlichen Einteilung zusammen, so dass sich Benutzer leicht ins Nirvana klicken können. -- Hansm 16:31, 28. Nov. 2009 (CET)

Hierarchie in ständigem Fluss

Wenn man die letzten Änderungen in der LocDB verfolgt, sieht man, dass immer mal wieder neue Regionen erzeugt werden oder umsortiert wird. Damit Karten mit eingezeichneten Regionen oder gar anklickbare Karten funktionieren können, müssten sie eigentlich ständig aktualisiert werden. Das ist von Hand nicht zu schaffen. -- Hansm 16:31, 28. Nov. 2009 (CET)

Skalierbarkeit

Spätestens nach meiner Türkei-Reise im Sommer, bei der ich zunächst nur mit WV-Ausdrucken bewaffnet war, bin ich zu der festen Überzeugung gelangt, dass Karten nicht skalierbar sind. Es geht nicht um die Türkei-Artikel, sondern um ein allgemeines Problem. Ich behaupte, die allermeisten Karten in unseren Artikeln haben lediglich die Funktion eines überdimensionierten Klick-Buttons. Erkennen kann man darauf gar nichts mehr, weil sie schlicht und einfach nicht für die übliche Größe von Bildern in Artikeln gemacht sind. Wenn man Karten in Artikeln haben will, müssen sie geneu für die dargestellte Größe designed worden sein. Eine Kartenunterschrift der Art "3mal klicken um die Karte benutzen zu können" kann nicht mehr als ein Provisorium sein. Konsequenterweise muss man dann aber bereit sein, Karten für unterschiedliche Auflösungen anzufertigen. Von Hand? -- Hansm 16:31, 28. Nov. 2009 (CET)

(kopiert von Wikivoyage Diskussion:Expedition 'Karten' -- Hansm 13:48, 29. Nov. 2009 (CET))

Was die Ausgabe und Druckerei angeht. Ich bin da absolut für eine Spezialseite, die eine Karte im brauchbaren Format liefert. Eine spontane Lösung weiss ich nicht. Vielelicht wäre es eine zukünftige Lösung wenn man zu jedem Eintrag in der LocDB neben der Koordinaten auch einige Spezifikationen der korrespondierenden Karte wie ihre Dimensionen usw. mitgeben könnte. Die Bestückung wäre dann zwar etwas für die Profis, aber das Ergebnis vielleicht wert. So bekommt der Nutzer eine in ihrer gedruckten Form brauchbare Karte. -- (WV-de) DerFussi 17:16, 28. Nov. 2009 (CET)

Dazu kommt, dass Karten sprachabhängig sein können. Entsprechend müsste man das auch in der LocDB verwalten.

Da steckt aber noch mehr dahinter. Es kommt ja auch darauf an, zu welchem Zweck man die Karte benutzen will. Am einfachsten ist es, wenn man die Karte einfach nur anzeigen will. Wenn es aber darum geht, bestimmte Features (z.B. rote Punkte bei einer Lagekarte, Sehenswürdigkeiten im Stadtplan etc.) dynamisch darzustellen, muss man die genauen Projektionsparameter kennen.

Wir werden aber mindestens mittelfristig auf handgefertigte Karten angewiesen bleiben, da der OSM-Datensatz noch viel zu viele Lücken hat.

Ich könnte mir einen Mechanismus vorstellen, mit dem man eigene Karten als Stadtplan, Übersichtskarte, Topologische Karte etc. registrieren kann und diese dann über eine Spezialseite ausgegeben werden.

-- Hansm 13:58, 29. Nov. 2009 (CET)

Interaktive OSM-Karten

Bei uns auf de: hält sich der Gebrauch der Vorlage:OpenStreetMap glücklicherweise einigermaßen in Grenzen, aber auf it: scheint sie einen Freund gefunden zu haben. Solche Karten sind vielleicht zunächst verlockend, weil sie klein gehalten werden können und die Illusion vermitteln, man könne durch Verschieben und Zoomen prinzipiell alles erkennen. Letztendlich verzögern sie aber den Aufbau des Artikels auf unangenehme Weise und verschaffen nicht den nötigen Überblick. Die OSM-Karten sind nämlich auch nicht für solch kleine Größen ausgelegt. -- Hansm 16:31, 28. Nov. 2009 (CET)

Optisches Layout

Fussi hat zum Start von WV den Versuch unternommen, eine Richtlinie für das Layout von Karten zu erstellen. Das hat aber nicht geklappt. Unser Kartenmaterial wirkt ausgesprochen heterogen und zusammengestückelt. -- Hansm 16:31, 28. Nov. 2009 (CET)

(kopiert von Wikivoyage Diskussion:Expedition 'Karten' -- Hansm 13:48, 29. Nov. 2009 (CET))

Ja, das mit dem Layout ist richtig. Da merkt man ganz schnell, wie einem die Zeit davon rennt. Für einen alleine ist das, wenn er kein totaler Freak ist, nicht zu bewältigen. Ich hatte damals damit angefangen, hoffe aber, dass es mal wieder an Fahrt aufnimmt. Es gubt halt hier jede Menge Baustellen. -- (WV-de) DerFussi 17:16, 28. Nov. 2009 (CET)

Ja, und so wird es auch weiterhin bleiben. Das Layout einer bestehenden Karte zu ändern mag noch gehen, wenn sie als SVG vorliegt. Karten im PNG-Format kann man eigentlich gleich neu zeichen, wenn man ein anders Layout haben will. -- Hansm 13:48, 29. Nov. 2009 (CET)

Landmarken in der Ortsdatenbank

Bei den verschiedenen Gebirgsregionen (auch: Mittelgebirge) wäre es, zur genaueren Differenzierung der Grenzen des Gebietes, von Vorteil in der Ortsdatenbank markante Landmarken als untergeordnete Orte anzulegen, für die aber ein eigener Artikel bei WV auch künftig eigentlich nicht sinnvoll ist (Berggipfel, Berghütten, Naturdenkmäler etc. siehe im Artikel Ammergauer Alpen). Macht das, auch hinsichtlich der geplanten künftigen Gestaltung der Ortsdatenbank Sinn ?--(WV-de) Bbb 10:46, 21. Dez. 2009 (CET)

Keine einfache Frage. Man muss sich grundsätzlich darüber klar werden, wie genau Grenzen für Regionen sein müssen. Prinzipiell gibt es mindestens zwei Ansätze:

1. Grenzen werden als Polygone definiert
2. Grenzen werden durch Voronoi-Facetten abgeschätzt.

Ansatz 1 sehen wir z.B. bei den von Hand gefertigten klickbaren Karten oder auf vielen von Commons importierten Karten. Bei politischen Grenzen funktioniert das ganz gut, weil sie in der Regel exakt definiert sind und kaum Änderungen unterliegen. Vorausgesetzt natürlich, dass man die Grenzverläufe aus einer freien Quelle beziehen kann.

Viele unserer Regionen sind aber alles andere als exakt definiert. Hier scheint mir Ansatz 2 mit Voronoi-Facetten geschickter. Die Särke liegt darin, dass Grenzverläufe so genau abgeschätzt werden, wie es der Dichte unserer Artikel entspricht. Unter der Voraussetzung, dass alle Locations Koordinaten haben, würde man jeden Artikel finden, wenn man in der Karte auf die Stelle klickt, an der der Ort liegt. Wenn man keinen Artikel findet, heißt das anders herum, dass es auch keinen gibt.

Deine Frage läuft dann darauf hinaus, ob es sinnvoll ist, Infos zum genaueren Abschätzen von Grenzverläufen zu sammeln. Zum Auffinden eines Ortes anhand der automatischen Karten ist das nicht nötig. Ästhetische Gründe mögen dennoch dafür sprechen. Sieht halt besser aus, wenn ein Tal nicht über Bergrücken läuft. Auf jeden Fall ist klar, dass auf diese Weise abgeschätzte Grenzverläufe nie so genau sein können wie handgezeichnete Polygone. Wir sollten nicht der Versuchung erliegen, uns hier zu verkünsteln, aber ein bisschen Kosmetik finde ich OK.

Ich denke schon darüber nach, in wie weit sich quasi-statische Grenzpolygone (z.B. für Staatsgrenzen) mit Voronoi-Facetten kombinieren lassen. Ich habe aber noch keine endgülitge Idee dazu.

-- Hansm 13:29, 21. Dez. 2009 (CET)

An den Kuesten abschneiden

Bei Kuestenregionen sehen die Karten natuerlich etwas ulkig aus, da die Regionen immer weit in das Wasser hinaus gehen. Liegen die Kuestenlinien auch als auswertbare Polygone vor? Dann waere es vielleicht moeglich, die Regionen immer entlang der Kuestenlinien verlaufen zu lassen, bzw. die Grenzen der Regionen mit den Kuestenlinien zu schneiden, damit man in den Meeren keine anklickbaren Flaechen hat. -- (WV-de) DerFussi 09:25, 24. Dez. 2009 (CET)

Prinzipiell ja, aber ...

1. Kleine Inselchen im Meer trifft man dann kaum noch, weil sie u.U. eine Fläche von nur einem Pixel einnehmen.
2. Die Fläche einer Region zerfällt u.U. in viele kleine Teile (z.B. Bahamas). Nach welchem Algorithmus soll man beschriften?
3. Die Landpolygone liegen als Shapefiles vor, die man leicht in die DB einlesen kann. Um damit zu rechnen, d.h. Schnittmengen zu bilden, ist aber nötig, dass die Polygone sauber sind. Ich habe bisher nicht getestet, ob das überall der Fall ist.
4. Große Polygone, wie z.B. Eurasien, sind ausgesprochen aufwendig zu handhaben, wenn man damit rechnen will.
5. Es gibt auch noch einen anderen Datensatz von SWBD, der die Landpolygone in 1°x1° Kacheln liefert, hier weiß ich aber, dass er kaum zu bändigen ist, weil viele Polygone Selbstüberschneidungen haben.

-- Hansm 10:26, 24. Dez. 2009 (CET)