Wikipedia Diskussion:WikiProjekt Georeferenzierung

Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 8. Oktober 2005 um 17:48 Uhr durch Geonick (Diskussion | Beiträge) (Grenzübergreifende Typisierung). Sie kann sich erheblich von der aktuellen Version unterscheiden.

Bevor du eine Frage stellst, solltest du bitte erst im passenden Archiv nachschauen, evtl. gibt es dort bereits eine Antwort.
Die älteren Diskussionen sind dort thematisch sortiert einsehbar.

(Wenns hier zu voll wird, versuche ich das thematisch zu archivieren. Bitte hols wieder hervor, wenn was nochmal aufgerollt werden soll.)

Archiv 1: Technisches bezüglich der Paramter und der Ausgabe:

Archiv 2:

Archiv 3:

Vorschlag: Reform der Vorlage

Fragen

Immer eine Zeile? Sehe ich das richtig, dass die Koordinatenangabe deshalb in einer langen Zeile stehen muss, weil das Skript es sonst nicht mehr lesen kann - eine mehrzeilige Gliederung wie in "Personendaten" ist also nicht drin, obwohl sie vielleicht übersichtlicher sein könnte?

Doppelte Koordinatenangabe? Verstehe ich das richtig, dass man die Angaben mit Grad, Minute, Sekunde, Hundertstelsekunden, aber auch auf dem zweiten Weg Grad/Dezimal machen kann? Ist das der Grund, dass man alle Angaben immer doppelt eintippen muss? Ich finde das lästig. Mir wäre ein Baustein lieber, wo man die Koordinaten nur einmal einträgt.

Speziellere Typen? Kann man den Typ "Landmark" nicht in verschiedene genauere Typen auffächern? KML lässt das doch sicher zu. Also zum Beispiel Museum, Theater, Burg/Schloss, ...

Berge? Ist ein Typ Berg(Höhe) möglich?

Danke vorab für die Antworten. -- Simplicius 00:04, 26. Sep 2005 (CEST)

es gibt "type:mountain(hoehe)" wobei hoehe durch die Höhe ersetzt wird -> siehe vorne. Ich schreib die Koordinaten immer einzeilig, mehrzeilig hab ich noch nie gesehen und würde es auch jederzeit auf einzeilig korrigieren. Datenbankabfragen sind dadurch sicherlich einfacher zu machen, weil alle Eintragungen einheitlich sind, PD sind ja auch einheitlich und zwar immer mehrzeilig. Was meinst du mit "Doppelte Koordinatenangabe"? Das eine ist das eigentlich essentielle der Koordinate was zum Kvaleberg-Server geschickt wird, das andere lediglich der Ausgabetext, steht auch vorn erklärt. MfG --BLueFiSH ?! 01:02, 26. Sep 2005 (CEST)
Einmaliges Eintippen und Hilfen: vielleicht gehts mit dem Tool http://www.giswiki.de/hjl_get_CoorM.htm bei GISWiki ja einfacher.
Ein einmaliges Eintippen wäre über eine MediaWiki-Extension durchaus möglich, wird aber zur Zeit nicht unterstützt. Das Tool hjl_get_CoorM.htm (keine MediaWiki-Extension) z.B. verarbeitet die Gradangaben per Javascript und stellt das Ergebnis im gewünschten Format dar. 134.106.146.46 (Benutzer:Arcy) 09:23, 26. Sep 2005 (CEST)
Spezielle Typen: Bisher werden alle Angaben an die GIS-Extension von en:User:Egil (= http://kvaleberg.com/) weitergeleitet (siehe auch Diskussion oben). Solange die Wikipedia diese oder eine andere Extension nicht implementiert, werden wohl auch keine weitere spezielle Typen integriert. 134.106.146.46 09:36, 26. Sep 2005 (CEST) (Benutzer:Arcy)

Vorschlag

Lasst mich bitte mal etwas vorschlagen, ohne dass mich gleich der Türsteher gleich vor die Tür setzt:
  • Ich finde zwei verschiedene Vorlagen noch immer zu viel. Wofür brauche ich bei Ortschaften einen Eintrag in der Infobox? Einwohner: das sagt mir doch noch was. Geokoordinaten: es sagt mir eh nichts, ob ich da nun 7"60' oder 6"70' habe. Und bei einem Theater oder Sendeturm habe ich diese Angaben dann ja doch nicht in der Infobox - also wozu das? Mein Vorschlag: die Sache mit der Infobox rausnehmen.
  • Die Eingaben sollten nur nach dem System Grad Minuten Sekunden Hundertstelsekunden stattfinden. Das ist auf 15 cm genau. So etwas wie Grad+Dezimalanteile braucht man auch nicht. Umrechnen und abschaffen, fertig.
  • Die Vorlage sollte idiotensicher sein. Bis jetzt geht alles in der Wikipedia ohne Hilfsmittel. Ich brauche doch auch keinen Editor für den Editor. Man will doch einen breiten Erfolg, und den hat man doch nur, wenn alle Benutzer gerne mitmachen.
Es kann doch nicht sein, dass ich da einen Mega-Einzeiler baue, mit ersetzten Leerzeichen, damit es da keinen ungewünschten Umbruch gibt.
Die bisherige Vorlage ist laut [1] usw. provisorisch. Es ist aber schon längst bewiesen, dass es mit der Geofunktion geht. Also muss man da doch mal was entwickeln. Eine nicht mehr provisorische Vorlage sollte nach meiner Meinung so aussehen (als ein Pendant zu Personendaten), und nur nach 1 System laufen:
{{Koordinaten|
NAME=Reichstagsgebäude
|KURZBESCHREIBUNG=Sitz des deutschen Bundestags
|BREITE= 52 31 07 00 N
|LAENGE= 13 22 24 00 E
|STATE=Deutschland
|ADMIN1=Berlin
|ADMIN2=
|CITY=Berlin
|TYPE=Gebäude
}}
  • Es muss reichen, dass man die Koordinaten nur einmal eingibt - ansonsten ist es schon wieder doppelte Arbeit.
  • Es sollte wirklich zur Regel werden, dass man Land - Landkreis/Stadtkreis - Ortschaft mit eingibt, denn so kann man das in einer KML-Datei auch gut gliedern. Beispiel: ein Häkchen auf NRW und schon sehe ich alle Orte nur in NRW.
  • Wir brauchen mehr definierte Objekttypen (Gebäude, eventuell Turm, Schloss, Burg, Krankenhaus, Museum, Universität, Bergwerk usw.). Landmark lohnt sich doch gar nicht. Egil ist ein aufgeweckter Typ. Der wird mehr Variationen schon hinkriegen.
Danke für die Aufmerksamkeit. Meinungen? -- Simplicius 12:39, 26. Sep 2005 (CEST)
zu: Dezimalangabe: Stimmt schon. Eine übertriebene Gebauigkeit halte ich auch für übertrieben. Eine Minute (siehe Geografische Koordinaten kann in Europa zwischen aber schon zwischen 1 km und 1,5 km Unterschied ausmachen. Deziamlangaben bei nur Gradangaben aber auch bei Angaben in Grad und Minute machen daher durchaus Sinn. Sollte mal eine Eingabe 15 cm "genau" sein, wird die tatsächliche "Ungenauigkeit" dieser Angabe wohl nicht herausgerechnet worden sein. Generell sind aber alle Angaben immer auch mit Vorsicht zu geniessen, solange keine Informationen zur Genauigkeit mitgegeben werden.
zu: Objekttypen: Sollte egils Extension jemals in die Wikipedia übernommen werden, dann sind IMHO keine weiteren (Unter-) Objekttypen notwendig, da dann ein Zusammenhang zwischen Koordinate und Kategorie hergestellt werden kann. Man sollte sich diesbezüglich nicht doppelte Arbeit machen.
zu: Vorlage / provisorisch / Dezimalangabe: Generell ist - wie egil oben schon schrieb -, zu fragen, wann endlich eine GIS-erweiterung in die Wikipedia kommt, bzw. wiso dies noch nicht passierte. Bis dahin sollten wir noch mit der alten Vorlage weiterarbeiten. 134.106.146.46 13:13, 26. Sep 2005 (CEST), (Benutzer:Arcy)
  • Ich kann dir verraten, warum ich den Vorschlag mit 1 neuen Vorlage unterbreite: ich habe null Bock, mit den bisherigen Vorlagen weiter zu arbeiten. Damit werde ich nichts mehr machen.
  • Ein System mit Hundertstelsekunden = 15 cm finde ich durchaus gut und dem Entwicklungsstand von GPS angemessen, aber es sollte wirklich nur noch ein System sein.
  • Die Idee mit den Kategorien halte ich für zu unzuverlässig: es gibt pro Artikel in der Regel mehrere Kategorien und zwar teils mit Typ-Eigenschaften, teils auch ohne. Ich halte diesen Vorschlag für "fix geraten" :-)) -- Simplicius 13:25, 26. Sep 2005 (CEST)
zu Objektypen: Objekttypen sind IMHO nichts anderes als Kategorien. Die Problematik ist auch die gleiche. Es sollte daher bei der georeferenzierung kein Nebenkriegsschauplatz hinsichtlich der Objekttypbildung erfolgen. Die Kategorienbildung in der Wikipedia scheint mir schon kompliziert genug zu sein.
Zu Unzuverlässigkeit: Der Reichstag beispielweise ist schon in der Oberkategorie Gebäude drin. Das pro Artikel mehrere Kategorien bestehen ist nicht von Nachteil. Im Gegenteil: So bestände z.B. auch die Möglichkeit sich nur georeferenzierte historische Gebäude (Kategorie:Historistisches Bauwerk) zeigen zu lassen. 134.106.146.46 13:35, 26. Sep 2005 (CEST) (Benutzer:Arcy)
Beim Beispiel Reichstagsgebäude geblieben, da gibt es noch die Einordnungen: Lesenswert | Regierungsgebäude | Bauwerk in Berlin | Berlin (Politik) | Berliner Geschichte | Deutscher Bundestag | Historistisches Bauwerk | Architektur von Norman Foster Nach dem System "Hauptsache, man hat mindestens 4 Artikel in einer Kategorie drin, dann ist sie berechtigt." sind viele Kategorien viel zu sehr verschnitten worden. Mir geht es darum, dass für die Wikipedia KML-Dateien generiert werden können, deren Strukturierung nicht aussieht wie Krautsalat.
Und zweitens soll die Vorlage möglichst benutzerfreundlich sein. Darum dieser Vorschlag. -- Simplicius 14:09, 26. Sep 2005 (CEST)
zu kml: Google Earth & Co ist zwar momentan zimlich hipp, hat aber erstmal IMHO nichts mit der Wikipedia zu tun. Oder hat sich die WP auf diese GIS-Software festgelegt? Für die Wikipedia ist ja auch sehr lobenswert. Aber es kann doch nicht sein, dass die Wikipedia einer externen Software angepasst wird, die vor kurzem noch Geld kostete und zudem nicht einmal freie Software ist. In ein paar Monaten sieht der ganze Google Hype schon wieder ganz anders aus.
zu Kategorien: ist doch toll. Ich könnte mir nicht nur alle Gebäude anzeigen lassen, sondern gezielt nur die mit Bezug zur Politik, einer bestimmten Epoche oder weltweit alle von Norman Foster etc. Wie willst Du das mit dem Objekttyp "Gebäude" bewerkstelligen? -- Arcy
Ob Koordinatenlisten nun im Format KML oder beispielsweise GML abgelegt werden, ob für Google Earth oder für andere GIS-Datenangebote, ist nicht relevant für das gleiche Problem:
Es gibt bislang nur die Typen Orte, Inseln, Gewässer, Berge, Flughäfen, Landmarken und vor allem Typ fehlt und Typ unbekannt. So etwas wie "Bauwerk" oder gar "Vulkan", "Bergwerk", "Kraftwerk", "Weltkulturerbe" etc. gibt es hier noch nicht.
Das Reichstagsgebäude ist einfach nur "landmark" und eine Kurzbeschreibung gibt es nicht - oder die Einordnung nach Staat/Bundesland - obwohl so eine Erfassung eigentlich zum Greifen nahe ist.
Ich warte jetzt mal ab, was andere dazu sagen. -- Simplicius 15:14, 26. Sep 2005 (CEST)

Erstmal zur Frage von Arcy was hat Google Earth & Co. mit der Wikipedia zu tuen: Dahinter steckt wohl die Vision in Zukunft nicht nur die Richtung von der Wikipedia heraus ins Kartenmaterial zu surfen, sondern auch den umgekehrten Weg zu beschreiten, bei dem man aus der Karte seines Navigationsgerätes oder seines besseren Handys heraus auf interessante Artikel der Wikipedia in seiner Umgebung stößt. Und ich persönlich halte viel davon, da ich denke das es uns einen ganzen Schritt weiter zu einem universellen Reiseführer bringt. An Google binden wir uns damit keines Wegs da die Informationen ja allen zur Verfügung stehen.

Jetzt zu den Landmarken: Ehe wir uns an die Arbeit mit den Typeneintragungen machen, sollten wir das wirklich abklären sonst fangen wir danach gleich wieder von vorne an. Vorbild sollten IMO verschiedene Papierlandkarten sein, auch wenn wir nur die enzyklopädisch bedeutsamen betrachten müssen. Darin gibt es z.B. :

  • Bahnhöfe (davon gibt es in der Wikipedia auch schon einige (warum auch immer)),
  • Museen, (da muß man etwas mehr Zeit bei der Reise einplanen)
  • Kirchen (diese können auch als Orientierungshilfe in der Landschaft dienen)
  • Burg, Schloß, Ruine (manche Dinge würde ich zusammenfassen)
  • Bergwerk, Höhle, Tagebau, (dann weiß man, dass man nach unten schauen muß um es zu finden, Tagebaue sind aus dem Weltall betrachte je sehr markant)
  • Natursehenswürdigkeit
  • Industriebau (Hochhaus, Kraftwerk,nichtöffentliches Gebäude)
  • Denkmal
  • Orte und sehenswerte Orte (Wer will das entscheiden?)
  • Sportstadien, Bäder... (halte ich nur selten für relevant -> type:sonstiges)

Ich denke mal, dann steht der Reiseplanung nichts mehr im Wege.

Die Einordnung nach Staat/Bundesland ist für mich wesentlich uninteresanter da man ja weiß wo man sich befindet, dafür gibt es wirklich die Kategorien.

Was machen wir mit einem Artikel wie Bundesautobahn 4? Wohl besser nichts.

Für mich ist allerdings ein Vulkan erstmal ein Berg, denn wer will beurteilen wie aktiv er ist.

Auf die Kurzbeschreibung, würde ich verzichten da diese zuviel Arbeit macht und man ja auch den ersten Absatz der Wikipedia datentechnisch auslesen kann.

Eine anderer Punkt: Wenn mann aus der Datenbankabfrage mit abfragen könnte wie lang der Artikel ist (Anzahl der Textzeichen), dann ergebe sich daraus automatisch auch eine sehr schöne Filtermöglichkeit alle Stubs auszublenden. Baden-Würtenberg sieht in Google Earth wirklich schon verboten aus. Kolossos 20:03, 26. Sep 2005 (CEST)

Mir ist durchaus klar was hinter der ganzen Geschichte steckt. Was ich an dieser Diskussion aber nicht verstehe ist, wieso an den in der (den) Wikipedia (-en) vorhandenen Kats. vorbei eine zweite Kategorisierungswelle laufen soll. Alle (fast) oben angeführten Subtypen sind in der WP-Datenbank doch schon vorhanden. Das ganze führt doch in Teufels Küche. Aber mal grundsätzlich: Die type-Angabe bezieht sich auf die GIS-Extension von egil. Ist er überhaupt bereit eine solche Anpassung mitzumachen? Oder soll das ganze nur einfach schön in der Vorlagenklammer drinstehen, damit man es dort für irgendwelche Programme wieder rausfrimmeln kann? Arcy 21:52, 26. Sep 2005 (CEST)
Ich habe das ganze mal auch unter Wikipedia_Diskussion:Kategorien#Wikipedia_Diskussion:WikiProjekt_Georeferenzierung.23Vorschlag zur Diskussion eingestellt Arcy 22:12, 26. Sep 2005 (CEST)


Bevor man hier allzusehr ins Detail geht, sollte vielleicht überlegt werden, was denn die grundsätzlichen Funktionen, Ziele etc. der Georeferenzierung sind. Zuerst mal gibt es ja zwei Arten von Koordinaten: Einmal als Referenz auf Kartenmaterial zu einer im Text vorkommenden Koordinate (entspricht der Vorlage Koordinate Text), zum anderen als Metaangabe zum Artikel (Vorlage Koordinate Artikel). Im Moment werden beide gleich realisiert, nämlich als Referenz auf Kartenmaterial. Die Metadaten zum Artikel sollten, denke ich, aber vornehmlich nicht nur der Kartenreferenzierung dienen, sondern auch der Erstellung eines eigenen Atlas der Wikipedia (oder als eigenes Wikimedia-Projekt), der langfristig mit Sicherheit kommen wird (es mögen noch Jahre hin sein, wer kann das schon sagen, aber kommen wird es). Es sollte bei diesen Metadaten also ein klarer Fokus auf das Bereitstellen von Daten liegen, die für die Darstellung auf Karten notwendig sind. Dazu gehört ganz sicher der Typ des Kartenpunktes (sollte schon genau bestimmt sein, wenn die Kategorien dazu herangezogen werden sollen, müssten diese aber einer gründlichen strukturellen Überarbeitung unterzogen werden. Hier spielt unter anderem das Konzept der Anwendung von Mengenoperationen auf Kategorien mit rein, Schnitt- und Vereinigungsmengen sollten dazu gebildet werden können.).

Um eine größtmögliche Flexibilität des Systems zu erreichen, müssen zudem die in unseren Artikeln enthaltenen Informationen viel stärker strukturiert und formalisiert werden. Das Wikidata-Projekt (dessen Aktivitätsstatus mir nicht bekannt ist) plante etwas in der Richtung. Prinzipiell ging es darum, Daten von dem Typ, der meist in Infoboxen dargestellt wird, also alles was mit Zahlen, Zuordnungen etc. zu tun hat, zentral in entsprechend angepassten Datenbanken zu lagern und dynamisch in die Artikel zu integrieren, so dass zum Beispiel die aktualisierte Einwohnerzahl einer deutschen Stadt nicht separat und händisch in 100 verschiedensprachigen Artikeln zu korrigieren ist, sondern nur an einem zentralen Ort. Solche Daten wären enorm nützlich für die Darstellung als Karte. Ein funktionierendes Wikidata-System würde die Referenzierung durch Koordinate Artikel komplett überflüssig machen.

Ich warne also davor, hier ein übermäßig komplexes System aufzubauen, da es nur eine Übergangslösung sein wird. Wir sollten uns auf die Basisfunktionen beschränken. Dazu sind die aktuell vorhandenen Möglichkeiten meiner Meinung nach ausreichend. Wikidata und Wikiatlas werden kommen und die sehr funktionsbeschränkte Vorlage und viele andere Konstrukte innerhalb der Wikipedia wegwischen. Statt die Vorlagen mit Gimmicks vollzustopfen, sollte lieber darauf hingearbeitet werden, Daten im Artikel so zu formalisieren, dass sie automatisiert ausgelesen werden können. Statt Tuning der Krücken lieber reinen Tisch für einen sauberen Übergang zu einem besser geeigneten Instrument. --::Slomox:: >< 23:17, 26. Sep 2005 (CEST)

  • Was ist denn daran "übermäßig komplex"? Nichts. Neu ist eigentlich nur "Kurzbeschreibung". Alle anderen Angaben sind genau die, welche Egil verarbeitet, nur transponiert von der der Horizontalen (1 Megazeile) in die Vertikale über mehrere Zeilen.
  • Gut, ferner will ich die Koordinate nicht doppelt eintippen müssen. Und der Typ "Landmark" möge um eine Handvoll passenderer Typen bereichert werden.
  • Ansonsten aber haben nun mal nicht alle Artikel Infoboxen, ich habe ehrlich gesagt auch null Bock auf Infoboxen bei Schlössern oder Türmen oder Museen. Das halte ich für eine fette Sackgasse, Slomox, weil das niemand mitmachen wird. Da finde ich die Koordinatenvorlage noch eine leichte Übung gegenüber einer Infobox.
  • Und die Gliederung nach Staat/Land/Stadt ist ja nun Teil des Modells auf Wikipedia:WikiProjekt Georeferenzierung. Da habt Ihr wohl gar nicht gemerkt, dass ich das nur abgeschrieben habe.
  • Sie macht auch Sinn, denn auch eine kml-Datei mit 5.000 Punkten zwingt Google Earth schon in die Knie, und das ist noch gar nichts angesichts von 300.000 Artikeln. Es ist schön, eine Datei oder einen Abschnitt zu haben, wo man zum Beispiel nur NRW oder den Hochsauerlandkreis aktivieren kann.
  • Beschmiert ist es doch, sich in Deutschland alle Orte von Aaa bis Adc anzeigen lassen zu können.
  • Und was die Vulkane angeht, ob aktiv oder erloschen, es ist ein Vulkan und derer gibt es wohl 2.700 Stück. Und eine Datei nur mit den wichtigsten Vulkanen rund um den Globus fände ich schon cool.
  • Etwas daneben ist auch der Glaube, man könne mal eben den ersten Absatz als Kurzbeschreibung nehmen. Da gibt es überlange verschwurbelte Absätze, und in einer Datei mit z.B. 10.000 oder 20.000 Punkten sind solche Textmengen der Untergang bzgl. Download, Rechenleistung usw. -- Simplicius 01:13, 27. Sep 2005 (CEST)
Das habe ich ja auch nicht gesagt, dass der Vorschlag bereits übermäßig komplex ist. Mein Kommentar war jetzt mehr allgemeiner Natur und nicht auf den konkreten Vorschlag gerichtet. Ich möchte nur nicht, dass in Richtung einer redundanten, nicht zukunftssicheren Struktur gearbeitet wird (wozu ich explizit auch die bestehende Lösung zählen möchte). Wikidata soll ja auch nicht für jeden Artikel Infoboxen generieren, sondern nur Daten erfassen. Diese müssen im Artikel keineswegs verwendet werden, wenn das nicht erwünscht ist. Für einen Turm könnte ich mir zum Beispiel vorstellen, dass dieser in einer Klasse „Gebäude“ eingeordnet wäre, die als Parameter Standort (Ortsname), geografische Lage, Gebäudetyp erfassen würde. Ein Turm ist aber kein Beispiel für ein besonders Wikidata-geeignetes Objekt. Bessere Beispiele wären Personen (Wikidata wäre dann so eine Art Personendaten-Commons), Städte, Berge etc. Also Klassen von Objekten von denen es typischerweise viele gibt und bei denen immer die gleichen Kernwerte (Höhe des Berges, Einwohnerzahl etc.) auftauchen.
Ich möchte also lediglich, dass wir nicht kurzfristig auf die Anpassung an Google Earth und Konsorten, sondern längerfristig auf eine Implementierung eines Wikimedia-Projektes setzen, das alle Wikimedia-Ressourcen und -Möglichkeiten ausschöpfen kann. --::Slomox:: >< 02:06, 27. Sep 2005 (CEST)

Als Ersteller der KML-Datei möchte ich vor einer extra dafür eingeführten Objekttypen warnen. Für eine Verbesserung der jetzigen Objekttypen müssen wieder tausende Artikel bearbeitet werden. Das sollten wir vermeiden. Außerdem bin ich der festen Überzeugung, das bei besseren Abfragemöglichkeiten in Wikipedia solche Objekttypen sehr schnell aus den vorhandenen Kategorien erzeugt werden können. Vermeiden wir also bitte Doppelarbeit. Denn wer weiß, vielleicht möchte der Vulkanuloge nicht nur wissen ob dort ein Vulkan ist, sonder ob er aktiv, inaktiv, etc. ist (z.B. Devils-Tower-Nationalmonument). Die Aufspaltung in mehrere KML Dateien schwebt mir auch schon vor, aber ich weiß eben wieder nicht, ob ich nach Regionen, oder lieber nach Type aufspalten soll. Wahrscheinlich z.B. bei Deutschland wird beides Sinn machen. -- sk 09:12, 27. Sep 2005 (CEST)

zu Wikidata: Ich würde es begrüssen, wenn das Projekt Wikidata aufgespalten wird und vordringlich /parallel eine GIS-Datenbank als eigenständige DB in die Wikipedia integriert wird.
(A) MySQL unterstützt seit der Version 4.1 geographische Daten nach dem OpenGIS-Standard (http://www.opengis.de). Andere freie Datenbanken unterstützen ebenfalls Geodaten (z.B. http://postgis.refractions.net/). Die Entwicklung auf diesem Gebiet ist also schon weit fortgeschritten und mittlerweile reif für die Integration in Mediawiki.
(B) Logische Abfragen nach Kategorien stehen auf der to-do Liste von MediaWiki (http://meta.wikimedia.org/wiki/Development_tasks#To_do).
Die Artikel der WPs könnten also relativ schnell auch über geographische Abfragen erschlossen werden.

Stefan, nur gut 5.000 Artikel von 300.000 in der deutschsprachigen Wikipedia sind verortet. Da sind also noch zigtausend übrig, die zu tun sind. Ich habe nun folgende Möglichkeiten:

  • ich verzichte auf das feature "type", dann steht da später "Typ fehlt" - und die ganze KML-Datei ist vermurkst, wie es der aktuelle Auszug ist.
  • ich setze den Wert "landmark" - das ist völlig aussagelos und ergibt somit auch nur Massendaten ohne Erschliessung
  • ich setze vernünftige types, nach denen sich einzelne, typenbezogene Dateien herausgeben lassen

Kolossos hat es verstanden. Notwendig sind in etwa die Typen, wie sie auch auf einer Landkarte deklariert sind. Hingegen ist Architektur von Norman Foster und all das was unser wild gedeihendes Kategoriensystem hervorgebracht hat, in dieser Stufe noch höchst überflüssig oder ungeeignet.
Klar gibt es da auch Beschwerden von Leuten, die gegen alles von Verortung bis hin zu Google Earth eingestellt sind. Aber überflüssige edits gibt es doch am ehesten dann, wenn man etwas Unvollständiges oder Undurchdachtes an den Start bringt und dann später ständig nachbuttern muss. Du bist in meinen Augen auf dem besten Wege genau dahin.
Stattdessen könnte man die nächsten 5.000 tags schon ordentlicher machen. Wenn jeder die Features für die politische Zuordnung Staat, Land, Kreis nutzen soll, sollte die Vorlage zudem in die Vertikale gehen - wie das Muster Personendaten vorbildlich macht.
Das Beispiel "Personendaten" zeigt auch, wie man so etwas sehr erfolgreich an den Start bringt. Es gibt keinen Personenartikel ohne das mehr, und wegen der edits regt sich auch keiner auf. Hier hat man auch nicht auf "Wikidata" gewartet, was sicher ganz interessant sein wird - in ein paar Jahren. -- Simplicius 20:59, 27. Sep 2005 (CEST)

zu "Zum Raumbezug 1: Wikipedia:Meinungsbilder/Angabe Adressen, ÖPNV und Öffnungszeiten": Hallo Simplicius. Im angeführten Meinungsbild (in Vorbereitung) willst du für "Objekte wie Museen, Opern, Theater, Bühnen, Schlösser, Burgen, und öffentliche Eintrichtungen aller Art" weitere Angaben. Sollen diese "Gebäude" alle als "Typ Gebäude" laufen oder hällst du eine Untergliederung in z.B. "Typ Museum" für sinnvoll?. Um nur beim Beispiel Berlin zu bleiben: Wie würde eine Karte wohl aussehen in der undifferenziert zig Gebäude aufgelistet sind? 134.106.146.46 10:03, 28. Sep 2005 (CEST) (Benutzer:Arcy)

Für den type halte ich "Kirche", "Museum", "Schule", "Bahnhof", "Denkmal" usw. für sinnvoll. Kolossos beschreibt es ganz gut - das, was auf einer Landkarte in der Regel auch tpyologisiert ist.
Als Kurzbeschreibung fände ich "Heimatmuseum", "Griechische Antike" o.ä. wie zum Beispiel "Ehrendenkmal für den Deutsch-Französischen Krieg" eine gute Ergänzung.-- Simplicius 12:20, 28. Sep 2005 (CEST)

Argumente für Vorschlag 2 unten

Bin auch für den Vorschlag mit Koordinate, die bitte nur einmal einzugeben ist - alles andere ist Editor-unfreundlich und fehlerbehaftet - und ohne type, denn es gibt tatsächlich schon Kategorien (vgl. oben "wieso an den in der (den) Wikipedia (-en) vorhandenen Kats. vorbei eine zweite Kategorisierungswelle laufen soll.")! Das bildet die Datengrundlage für spätere externe Datenbanken a la Wikidata (mit MySQL oder PostgreSQL) oder allenfalls eingebaute Funktionen (welche die Antwortzeiten von Wikipedia nicht gerade erhöhen werden). Geonick

Lieber Geonick, den type gibt es doch schon längst, und airport könntest du so angeben, wenn du wolltest bzw. wüsstest, wie es geht. In der KML-Datei für Google Earth erscheint das dann als Untergruppe, wenn Stefan Kühn eine solche Zusammenstellung laufen lässt.
Wird das feature nicht benutzt, stehen die Einträge in der Datei als "Typ unbekannt", was wenig aussageloser ist als ein massenhaftes "landmark". Daher wären - nach Bedarfsbestimmung - vielleicht Gebäude oder gar Museum etc. sinnvoll.
Und hier gilt immer noch das EVA-Prinzip (Eingabe-Verarbeitung-Ausgabe). Das heisst, die Ausgabe ist nur so gut, wie die Eingabe richtig war!!! Bei den Personendaten kräht kein Hahn danach, dass in der Vorlage Daten stehen, die auch oben in den Kategorien enthalten sind, wie etwa geboren/gestorben. -- Simplicius

Allen die wie Geonick es für einfacher halten aus den in der Wikipedia betreits vorhandenen 5000 Kategorien eine sinnvolle Karte (auch für sowas wie ein späteres Wikiatlas oder Wikimaps) zu generieren anstatt sich auf ca. 10-15 nach kartographischen Gesichtspunkten sinnvolle Typen für Landmarks zu einigen, denen wünsche ich viel Spaß dabei. Zumal man dann garnicht mit solchen Typen wir Airport oder Ort hätte anfangen dürfen. Denn was pasierten beim vorgeschlagenen Weg mit den ganzen Doppelkategoriesierungen? Der Berliner Fernsehturm ist z.B. in den Kategorien "Aussichtsturm | Berliner Sehenswürdigkeit | Sendeturm | Wahrzeichen" gespeichert. Somit sind das einige Doppeleinträge zur Kategorie Turm. Außerdem muß erstmal eine Software geschrieben werden die mit Unterkategorie umgehen kann, oder werden dann die Mischkategorien wie "Berliner Bauwerk" wieder aufgehoben und in "Berlin und "Bauwerk" zerlegt? Kolossos 11:47, 29. Sep 2005 (CEST)

LOL... danke! Genauso isset. -- Simplicius

Soll der Berliner Fernsehturm den nun type:landmark (=Sehenswürdikkeit) oder einfach nur ein type:Turm sein? Arcy 22:06, 29. Sep 2005 (CEST)
Worauf zielt die Frage ab? Da hier noch nichts ausdiskutiert ist, ist der Status quo (nämlich die Verwendung von landmark) die einzige Option. --::Slomox:: >< 22:33, 29. Sep 2005 (CEST)
Die Frage war an Kolossos und Simplicus gerichtet. Hintergrund ist die Problematik der eindimensionalen Einordnung, die Kolossos und Symplicus propagieren. Der angeführte Berliner Fernsehturm, degradiert als einfacher Turm, wäre in den aus den type:-Informationen generierten Karten, keine Sehenswürdikkeit (landmark) mehr. Da wollte ich mal nachhacken. Arcy 22:56, 29. Sep 2005 (CEST)
Sorry, für die späte Antwort, das Problem ist mir bekannt ich halte es aber trotzdem für besser eine simple Lösung zu haben als gar keine. Im konkreten Fall würde ich mich für den Turm entscheiden da ich davon ausgehe das alles in der Wikipedia enzyklopädarisch wertvoll ist und somit halbwegs eine Sehenswürdigkeit darstellt. Eine nach menschlichen ermessen sinnvolle Begrenzung halte trotzdem für besser als mechanisch das ganze über die Kategorien zu jagen. Kolossos 18:56, 30. Sep 2005 (CEST)

Lieber Simplicius: Es geht hier um zentrale Fragen, die letztlich über den Nutzen von Wikipedia entscheiden. Wäre uns da nicht mehr gedient, wenn wir bei der Sache bleiben könnten?

Informationen sollen ja eindeutig codiert sein, will man sie maschinell weiterverarbeiten. Das gilt auch für Wikitext. Gleichzeitig sollen die Angaben auch konsistent/widerspruchsfrei und zudem für Menschen lesbar sein. In Bezug auf die Vorlage, bzw. dem Datenbanklink Koordinaten gibt es nun offensichtlich einige Probleme, wie das Beispiel Berliner Funkturm zeigt: {{Koordinate Artikel|52_30_18_N_13_16_41_E_type:landmark_region:DE-BE|52°nbsp;30'nbsp;18"nbsp;N, 13°nbsp;16'nbsp;41"nbsp;O}}:

  1. Erstens erscheint die Koordinate zweimal und erst noch unterschiedlich codiert (schlimmstenfalls nochmals in der Infobox, wo sie nicht mehr hingehört, wenn der Datenbanklink eingeführt ist).
  2. Zweitens erscheint eine Kategorie (Typ) obschon eine solche schon existiert;
  3. und drittens wird Codierung und Darstellung vermischt (obschon es SW gibt für die Darstellung).

Es geht also um die Prinzipien der minimalen Codierung, der Redundanzfreiheit sowie des 'Keep it simple (but not simpler!)'. Kommt noch das helfende Prinzip der Trennung von Codierung und Darstellung dazu.

Die meisten Bestrebungen hier gehen in die richtige Richtung und man kann damit leben, solange damit das gemeinsame Ziel erreicht wird, konsistente Aussagen aus diesen Informationen ableiten zu lassen. Dazu zähle ich nicht nur Karten und sicher nicht nur KML, sondern Auswertungen aller Art.

Wäre es nicht schön, wenn wir dies mit demselbem Aufwand aber etwas clevereren Datenbanklinks lösen könnten, die einfacher und so codiert sind, dass sie weniger Fehlerquellen zulassen? Die Tatsache, dass es type und airport schon lange gibt, macht die Sache nicht besser. Habe bei Kategorie:Datenbanklinks auf Anhieb ausser 'Koordinate' denn kaum eine Vorlage gefunden, welche obige Prinzipien derart verletzt.

Einig bin ich mit der Feststellung, dass das bei Wikipedia das Problem von 'garbage in/garbage out' akut ist; kommt noch dazu, dass es noch riesige Mengen an Daten zu verorten gibt. Geben wir nun die Kategorien auf, weil sie inkonsistent sind oder weil es schon zu viele falsch kategorisierte Artikel gibt?

In der Menge von 5000 Kategorien sowie bei den Doppelkategorien sehe ich jedenfalls nicht das Problem: Die hierarchischen Kategorien sind ja aggregierbar. Ebenfalls kaum ein Problem sehe ich in den mehrfachen Kategorien - im Gegenteil, die Diskussion, ob der Berliner Funkturm nun als Turm oder Sehenswürdigkeit zu kategorisieren sei, zeigt schön, dass er natürlich beides ist, je nachdem welchen Aussage man in einer Datenanalyse und Visualisierung (Karte) machen will...

Daher untersütze ich Vorschlag 2 unten von Arcy: Konzentration der Kräfte auf das Verorten neuer Artikel mit einer Koordinaten-Vorlage sowie das richtige Kategorisieren bestehender Artikel.

Konkret:

  1. Zwei klare Datenbanklinks, einer eingebettet im Text und einer für ganze Artikel
  2. Format-Beispiel für Artikel 'Berliner Funkturm': {{Koordinate Artikel|declat=52.505|declon=13.278056}}. Die Kategorien könnten mit einer neuen seitenabhängigen Variablen {{CATEGORY}}</tt> übergeben werden.

Geonick

Zwischenüberschift zur besseren Editierbarkeit

Also wenn ich das richtig verstehe, wollen die meisten von euch einfach den Typ landmark noch weiter aufdrösseln. Das lag mir auch schon immer am Herzen und ich wäre generell dafür, wenn man vor der Einführung die neuen Typen sehr klar definiert. Ich hab mal das Musterblatt zur TK25 von Rheinland Pfalz durchgearbeitet und einiges gefunden. Was haltet ihr von folgenden neu definierten Typen:

traffic    = Platz, Brücke, Straße, Bahnhof, Seilbahn, Fähren, Hafen, Rastplatz, Schiffshebewerk, Schwebebahn, Tunnel
commercial = Industrie- und Gewerbe, Hotel, Gaststätte, E-Werk, Wasserwerk, Mülldeponie, Steinbruch, Tagebau
religion   = Kirche, Kapelle, Kreuz, Bildstock
landmark   = Turm, Schornstein, Leuchturm, Sendemast, Fernsehturm
cementry   = Friedhof, Grabhügel, Steingrab, Hühnenstein, Opferstein
nature     = Naturdenkmal, Hervorragende Bäume, Findling, Parks, Garten, Wald, Höhle, Gletscher, Naturschutzgebiet, Naturschutzparks
military   = Burganlage, Ruine, Bunker, Wehranlagen, Militärische Anlage, Truppenübungsplatz
sport      = Sportanlage, Skischanze, Stadion, Schießstand, Schwimmbad, Galloprennbahn, Spielplatz, Freizeitanlagen
other      = Denkmal, Schloß, Windmühle, Wassermühle, Berghütte, Krankenhaus, Rathaus, ...

Vielleicht fehlen ja noch einige, aber das ist doch schon mal eine gute Ausgangsbasis. Type landmark bleiben dann nur noch weithin sichtbare Objekte. Listet doch mal bitte die Sachen auf, die ihr da noch nicht einsortiert bekommt. -- sk 23:02, 29. Sep 2005 (CEST)

*grins* Arcy 23:08, 29. Sep 2005 (CEST)

Typenvorschlag von Slomox

Also wenn schon ausweiten, dann aber noch konkreter werden. landmark (sozusagen das alte other) ist ziemlich unspezifisch. Aber die vorgeschlagenen Typen sind immer noch nur halbspezifisch. Sie geben nur eine thematische Orientierung. Wir sollten dann gleich den ganzen Weg gehen und relativ klar einordenbare Objekte wie Krankenhaus, Truppenübungsplatz oder Friedhof auch als solche angeben. Wir wollen ja an die Kartennutzung denken und da wäre es fatal, wenn man auf der Karte Krankenhäuser sucht und 'ne Wassermühle angezeigt bekommt ;-) Ist natürlich immer schwer auszumachen, wo die Grenze ist, Skischanzen und Schwimmbäder (wenn's keine Spaßbäder sind) sollten schon gemeinsam als Sportanlagen gelten.
Mein eigener Vorschlag basierend auf sks genannten Objekten (ohne die jetzt gleich mit englischen Begriffen zu verbinden). In Klammern sind die von sk genannten Objekte, die ich unter dem vor der Klammer genannten Begriff subsummieren würde:
  • Platz, Brücke, Straße, Bahnhof, Seilbahn, Fähre, Hafen, Rastplatz, Schiffshebewerk, Schwebebahn, Tunnel
  • Hotel, Gaststätte, Betrieb (Industrie- und Gewerbe, E-Werk, Wasserwerk), Mülldeponie, oberirdische Abbaustätte (Steinbruch, Tagebau), unterirdische Abbaustätte
  • Kirche, Kulttätte (Kapelle, Kreuz, Bildstock)
  • Turm, Schornstein, Leuchturm, Sendemast, Fernsehturm
  • Friedhof, Grabstätte (Grabhügel, Steingrab, Hühnenstein, Opferstein)
  • Naturdenkmal, Naturobjekt (Hervorragende Bäume, Findling), Park, Wald, Höhle, Gletscher, Naturschutzgebiet, Naturschutzpark
  • Burganlage (Ruine), Festungsanlage (Bunker, Wehranlagen, Militärische Anlage), Truppenübungsplatz
  • Sportanlage (Skischanze, Schießstand, Schwimmbad, Galopprennbahn, Spielplatz, Freizeitanlagen, für Sportbetrieb), Stadion (für Sportveranstaltungen)
  • Denkmal, Schloß, Mühle (Windmühle, Wassermühle), Krankenhaus, öffentlicher Verwaltungsbau (Rathaus)
--::Slomox:: >< 23:42, 29. Sep 2005 (CEST)

Noch eine kleine Anmerkung zur von Simplicius vogeschlagenen Vorlage. Die funktioniert mit vorhandener Software nur bedingt, da man die Gradangaben damit nicht korrekt formatieren kann. Dafür müsste die Angabe in 10 Parameter (je 2x Grad, Minuten, Sekunden, Hundertstel und Himmelsrichtung [die eigentlich nochmals in abgekürzter englischer sowie deutscher Ausführung]) aufgeteilt werden. --::Slomox:: >< 23:42, 29. Sep 2005 (CEST)

Es ist ein interessanter Querschnitt, alle Gebäude und ähnliches werden auf Fachrichtungen verteilt. Es ist als Idee gar nicht mal schlecht, weil konsequent. Man müsste dann education hinzufügen für Schule, Hochschule, Museum oder culture für Theater, Oper, Freilichtbühne. Landmark ist im Englischen übrigens weniger ein weithin sichtbares Objekt, sondern - hier liegt Arcy wohl eher richtig - hauptsächlich als Sehenswürdigkeit zu übersetzen. Aber eigentlich ist es als ehemaliger Platzhalter möglicherweise verbraucht.
Ich bin jetzt noch der Vorstellung verhaftet, die Objekte, die ich auf einer Landkarte beschriftet finden kann, von ihrerAnzahl im Wikipedia-Artikel-Raum zu betrachten. Wenn ich 1.000 Museen habe, würde sich type=museum nach meiner Meinung lohnen. Eine KML-Datei mit Museen würde damit schon ziemlich den Rechner auslasten. Eine KML-Datei nur für Objekte eines Bundeslandes hätte hiermit eine zahlreich repräsentierte Unterklasse vorzuweisen.
Meine Vorstellung sehe ich dadurch bestätigt, dass es den type=airport gibt, und nicht type=traffic - und so fort.
Wenn es eine Akzeptanz gäbe, würde ich mit Kolossos mal eine Liste der kollosal wichtigsten Typen entwerfen - der Nachteil wäre natürlich, dass viele Objekte so auf dem type=landmark hängen blieben, aufgrund ihrer geringen Anzahl, obwohl sie von der fachlichen Zuordnung her erfassbar wären. Deswegen, Respekt... Stefan. :-))
Ich bin hier gerade auch zu langsam am tippen, von Slomox kam noch eine Betrachtung hinzu, die ich noch lesen muss, aber wohl in diese andere Richtung geht, mit dem Problem der Restmenge. Stefans Vorschlag deckt alle in Frage kommenden Objekte fachlich ab und bringt eine gewünschte Struktur ins Datenchaos. -- Simplicius 00:00, 30. Sep 2005 (CEST)

@Simplicisimus: ich denke mal, dass wir das hier nicht als zwei Mannprojekt führen müssen sondern wirklich jede Idee gebrauchen können die wir kriegen können, schließlich kennt jeder hier wohl nur einen Teil der Wikipedia und hat somit immer einen subjektiven Blick darauf welche Objekte wichtig sind und außerdem hat jeder auch andere Ziele die er auf einer Karte erkennen möchte.

Der Unterschied zwischen Sk 9 englischen Hauptkategorien und den 45 Kategorien von Slomox liegt hauptsächlich in einer genaueren Aufdriesselung. Dabei finde ich beide gut, tendiere jedoch zur Aufführung von Slomox, würde diese jedoch um folgende Punkte kürzen Schiffshebewerke und Schwebebahnen (gibt es mir zu selten, fällt unter Betrieb), Fähre (fällt unter Hafen), Gaststätten und Mülldeponien (sind doch hoffentlich noch nicht Enzyklopädarisch wertvoll genug um in der Wikipedia zu stehen), Fernsehturm und Sendemast(sind doch sowas wie Türme), das Stadium (würde ich mit zur Sportanlage zählen, kann mich aber überreden lassen). Dafür würde ich die Freizeitanlagen(Disneyland und Zoo) aus den Sportanlagen rausnehmen. Unter "Militeria" dürften für uns noch die historischen Schlachtfelder interessant sein. Die von Simplicisius aufgeführte Schulen würde ich vielleicht unter den öffentlichen Verwaltungsbauen laufen lassen und dafür das Museum in die culture stecken. Also unbedingt noch eine Kategorie Culture dafür haben wir auch genug Artikel. Und eine Kategorie Wikipedia ist mir noch eingefallen:

  • Culture:Bühne (Theater, Kabarett, Oper, Freilichtbühne, Kino), Museum, Kunstobjekt, sonstige Kultur (Disco...)
  • Wikipedia: Benutzer, Wikpediatreffpunkt
  • Bild: Panorama, Detail

Mit Straßen, Fähren und Seilbahnen und auch mit Wäldern habe ich sowieso ein Problem, da sich diese mit einer Punktkoordinate nur begrenzt beschreiben lassen.Kolossos 18:56, 30. Sep 2005 (CEST)

Soll das heissen, das die hier diskutierte WP-Geodatenbank nulldimenional werden soll? Arcy 16:51, 1. Okt 2005 (CEST)
Hast du eine bessere Idee? Die Autoren der Wikipedia dürften sich auch freuen, wenn wir einen Artikel wie Berliner Mauer mit 2000 Koordinaten vollstopfen um den Pfad der Mauer zu beschreiben. Ich gehe davon aus das unsere Punkte über eine Karte gelegt werden in der Straßen und der gleichen eingezeichnet sind und das ganze zu 90% gut funktioniert, es aber auch ein paar Verluste geben wird. Ein Punkt kann ausreichen um ein Waldgebiet zufinden aber nicht um es zu beschreiben. Für alles andere bräuchten wir einen richtigen Geoserver. Und sowas wie die QuickWMS-Extension ist da als Clientensoftware noch nicht allzu befriedigend. Kolossos 17:38, 1. Okt 2005 (CEST)
Eine zusätzliche Angabe zum Geodatentyp im WKT (Well Known Text)-Format würde die Geodaten hinreichend beschreiben und auch die Eingabe mehrdimensionaler Objekte erlauben. Arcy 19:11, 1. Okt 2005 (CEST)

Ich habe die gewünschten Pictogramme mal auf Wikipedia:Bilderwünsche gesetzt vielleicht findet sich ja jemand.Kolossos 12:43, 8. Okt 2005 (CEST)

Grenzübergreifende Typisierung

Wie werden die WPs der Nachbarstaaten der deutschsprachigen WP integriert? Wie soll das ganze Grenzübergreifend z.B. nach Frankreich, Polen, Niederlande usw. funktionieren. Oder hört alles an der deutschen Grenze auf? Arcy 23:53, 29. Sep 2005 (CEST)

Ist es nicht so, dass jede WP ihre eigene Georeferenzierung für jedes Land der Erde macht? --Raymond 08:08, 30. Sep 2005 (CEST)
Ja. Für die englische Wikipedia hat Stefan Kühn eine Datenbank erzeugt, die gut 5.000 Einträge hat. Es ist natürlich zu überdenken, ob man nicht auf eine gemeinsame Verortung entwickelt, so wie man bei commons gemeinsam aus 80 oder mehr Sprachabteilungen auf Bilder zugreift. Fraglich. -- Simplicius 13:31, 30. Sep 2005 (CEST)
Jede Wikipedia hat für in seinem Sprachraum seinen Schwerpunkt. Allerdings erscheint mir die deutsche Wikipedia auch etwas als Vorreiter. So finde ich es erstaunlich das en:London in der englischen Wikipedia nicht georef. ist, in der deutschen jedoch schon. Aber der Eindruck kann täuschen. Das ganze ab einem bestimmtem Stadium auf einem zentralen Geo-Server zu verlegen sollte nicht das Riesenproblem sein wenn es dann von uns die richtigen Georef. und sowas wie Wikidata gibt. Man könnte natürlich auch mal überlegen einen Bot zu benutzen der überprüfte Georeferenzen ausliest und über die Interwikilinks an andere Wikipedias weitergibt. Es würde mich erstaunen wenn das deutsche London woanders liegt als das deutsche.Kolossos 18:56, 30. Sep 2005 (CEST)

blubb ich will auch mal. (a) die meisten jetzigen geo extra attribute sind uebergreifend, sie brauchen nicht in die koordinaten vorlage. "type" werten externe tools aus, das braucht man egils server nicht aufzubinden, der's nicht braucht. Also, mach doch zu extra attributen eine eigene dbvorlage. (b) soweit koordinaten im text klickbar erscheinen sollen, muss man das hier einpinnen, da reicht keine neue dbvorlage. Auch die perso daten werden ja nicht visualisiert, sondern man tickert ein geburtstdatum nochmal ein, als sichttext im datumsformat. (a+b) Daher, kein gegensatz zu existenten koordinate-vorlagen, die fuer sichttext noetig sind - aber aufblasen mit metaangaben kann man wegdruecken durch abgesetzte dbvorlagen. Externe tools koennen das sicher leicht wieder zusammenbringen. GuidoD 20:16, 1. Okt 2005 (CEST)

Das bringt mich auf ein weiteres Prinzip, welches mit type (und Personendaten) verletzt wird neben der damit eingeführten Redundanz (vgl. Diskussion oben): Angaben, die dem Benutzer nicht erscheinen können von Benutzern schwer auf Konsistenz zu geprüft werden (Google hält sich auch daran...). So etwas wie type brauchts und gibt es in Form der Kategorien. Alle erwähnten Anwendungen scheinen mir technisch machbar und mit den bestehenden Lösungen abgedeckt. Das alles spricht nocheinmal für Vorschlag 2, als Datenbanklink nur (einmal anzugebende) Koordinaten zu verwenden und sich auf die Verortung zu konzentrieren. Geonick 8. Okt. 2005 (CEST).

Vorschlag 2

Da es keine Datenbank gibt, in der die weiteren Daten zur Georeferenzierung von Wikipediaartikeln eingetragen werden, sollte sich die Georeferenzierung auf das einfache Eintragen der Koordinaten beschränken. Arcy 23:22, 29. Sep 2005 (CEST)

Die Wikipedia-Datenbanken, um die es geht, findest du u.a. in KML angegeben. Stfan Kühn legt gerade auch wieder eine neue an. Siehe weiter unten. -- Simplicius 13:27, 30. Sep 2005 (CEST)

Zeitplan

hallo Stefan. Wie sieht dein Zeitplan aus? Arcy 23:25, 4. Okt 2005 (CEST)

Ich bin gerade mit dem ersten Prototyp fertig geworden. Ca. 15000 Koordinaten werden euch beglücken. Ich werde morgen noch das Feintuning vornehmen. Also Kartenzeichen anpassen, Statistik erstellen und einige andere Feinheiten. Bin durch den Geographentag in Trier die letzten Tage nur kurzzeitig zum weiterarbeiten gekommen. Auf jeden Fall klappt das mit dem Sortieren der Koordinaten durch zusätzliches nutzen der Kategorien ganz gut. Einzig und allein das man eine Koordinate nur in einen einzigen Unterordner stecken kann, ohne sie doppelt abzulegen, beeinflusst manchmal die Einsortierung suboptimal. Aber dafür geht es halt automatisch und niemand muss die Koordinatenvorlage in der Wikipedia erweitern. Insgesamt denke ich, es ist so am praktikabelsten. - Geduldet euch also noch ein paar Augenblicke. Und dann stelle ich die Datei online. Größe derzeit 5,1 MB. Das werde ich aber noch optimieren und evt. als kmlz (also gezippt) bereitstellen -- sk 00:03, 5. Okt 2005 (CEST)
Vieleicht solltest du mal eine Anleitung schreiben, wie man am besten seine persöhnliche Struktur für eine KML-Datei aus den Kategorien entwickelt. Ich bin froh über deine Arbeit. Immerhin wird sie zeigen, dass die zuvor diskutierte Erweiterung der type:Angabe nicht notwendig ist. Arcy 00:44, 5. Okt 2005 (CEST)
Nur zur Info: Ich bin fast fertig, leider machen die Sonderzeichen, wie bei Lech-Wałęsa-Flughafen Danzig, noch Probleme. Kriege ich aber hoffentlich auch hin, hat ja bei den anderen Files auch geklappt. Feintuning und Statistik sind fertig. Gezippt ist die Datei 409 KB bzw. 4900 KB entpackt. Viel weniger wirds nicht. Da seit wenigen Tagen ein neuer Dump (2. Okt.) zur Verfügung steht, überlege ich ob ich den nehmen soll. Kopfzerbrechen bereitet mir nur, dass dieser plötzlich kleiner ist als der vorhergehende Dump. -- sk 00:13, 6. Okt 2005 (CEST)
Klasse. Ganz kleine Kritik: eine kmz-Datei noch mal zu zippen macht nicht ganz so viel Sinn (7 kB weitere Ersparnis), man könnte auch die .kmz-Datei gleich bereitstellen.
Andererseits könnte man eine kleine info.txt-Datei da mit reinwerfen, die den Leute erklärt: "Wer Google Earth schon installiert hat, kann diese Datei zum Importieren per Doppelklick importieren".
Vor allem aber erst mal super, vielen Dank!. -- Simplicius 19:36, 7. Okt 2005 (CEST)
Sieht gut aus. Ein paar Sachen sind mir aufgefallen:
  • Berge mit der Vorlage "Bergtabelle Koordinaten" fehlen
  • Orte unter 1000 Einwohner sind wohl versehentlich unter "keine Einwohnerzahl" einsortiert
  • Kann man die Hauptstädte in der Städteliste nach ganz oben setzen?
  • Naturschutzgebiete sind unter "Kultur > weitere Landmarken" eingeordnet
--Fuzzy 21:52, 7. Okt 2005 (CEST)

Das die kmz als zip gezippt ist, hat den Grund, das ich nicht möchte, das jemand die als Netlink in Google Earth einbindet. Das verursacht zu viel Traffic. Die info.txt werde ich bei Gelegenheit noch mit reinmachen. Die Vorlage Bergtabelle Koordinate ist mir so oder so ein Dorn im Auge, vielleicht könnte man die ja umbenennen nach Vorlage:Koordinate Text Artikel. Das mit den kleinen Orten muss ich noch mal überprüfen. Sollte eigentlich nicht passiert sein und die Hauptstädte sollten eigentlich auch oben sein. Naturschutzgebiete und zahlreiche andere Kategorien habe ich noch nicht rausgefiltert. Ich habe mir bei den weiteren Landmarken die häufigsten Kategorien angeschaut und diese dann rausgenommen. -- Sk-Bot 22:51, 7. Okt 2005 (CEST)

neue KML-Datei, wie weiter?

Was mir zum einen auffällt: eine Gliederung nach Staat, Bundesstaat bzw. Bundesland, Kreis, County etc. ist derzeit wohl wenig möglich, oder? Die Koordinatenvorlage wird hinsichtlich dieser Parameter nicht sonderlich genutzt und unsere Kategoriensystem ist für räumliche Zuordnungen nicht angedacht. Eine so strukturierte zweite Datei aus dem Datenmaterial zu genierieren, ist wohl nicht möglich? Also nur "Bayern" anklicken, oder nur "Nürnberg" zum Schaun, was es da so gibt.

Wenn ich sehe, dass für das Nördlinger Ries zum Beispiel die Einordnung Einschlagkrater fehlt - es liegt an der fehlenden Koordinate - würde ich gerne vorschlagen: die Vorlage {{Koordinatenwunsch}} mit der Kategorie:Koordinatenwunsch. Gibt es dagegen Einwände? -- Simplicius 20:16, 7. Okt 2005 (CEST)

Ich halte eine Gliederung nach Regionen nicht sinnvoll. Ich möchte nicht an irgendwelchen Ländergrenzen aufhören mir irgendwas anzuschauen. Deshalb habe ich auch bei den Städten erst die Einwohnerzahl als oberste Gliederungspunkt ausgewählt. Das mit dem Koordinatenwunsch finde ich sinnlos, zumindestens als Kategorie, da dort sicherlich tausende Artikel angesammelt werden, die keiner abarbeitet. -- Sk-Bot 22:45, 7. Okt 2005 (CEST)

Regionalkarten mit Städten und Straßen

Hallo! Ich wurde von Wikipedia:Fragen zur Wikipedia hierher verwiesen. Mein Anliegen: Bis jetzt haben wir in Wikipedia fast nur "leere" Karten, die nur die Umrisse und Lage eines Bundeslands/Landkreises anzeigen und/oder die Position einer Stadt darin. Es fehlen dringend Karten in der Art von Straßenkarten, die ausgewählte Ausschnitte, z.B. 20x20 km, 50x50 km oder 100x100 km, vor allem aus dem Raum Deutschland/Österreich/Schweiz, darstellen. Wo können wir gemeinfreie/GFDL-lizensierbare Karten solcher Art hernehmen, oder wie können wir solche selbst erstellen? Ich würde mich gern hier einbringen, da solche Karten meiner Meinung nach Wikipedia enorm aufwerten würden.

Aus Layoutgründen denke ich, dass diese Karten generell manuell erstellt werden müssen, z.B. mit Inkscape im SVG-Format. Ist ein Mix aus einer automatisch generierten "Basiskarte" mittels Geokoordinaten (für Städte, Grenzlinien) und "nach Augenmaß dazugezeichneten" (ausgehend z.B. von einer urheberrechtlich geschützen Karte, die als Vorlage dient) Objekten (z.B. Straßenverläufe, Flüsse, Seen, Stadtgrenzen, ...) eurer Meinung/Erfahrung nach sinnvoll und auch juristisch akzeptabel? --Neitram 13:52, 6. Okt 2005 (CEST)

An dieser Stelle kurz ein Hinweis auf mein Steckenpferd Rechte an Geodaten. -- Simplicius

Danke - die Rohdaten sind also urheberrechtlich nicht geschützt, nur die "eigenpersönlichen Züge" der Karte, das ist mal das Wichtigste. Wenn ich also als Hobby-Kartograf basierend auf den Rohdaten von einer oder mehreren bestehenden Karten eine neue Karte zeichne, dabei die "eigenpersönlichen Züge" der Karten nicht kopiere und statt dessen in meiner Karte meine eigenen "eigenpersönlichen Züge" verwende, ist das keine Urheberrechtsverletzung. --Neitram 11:49, 7. Okt 2005 (CEST)

Ich bin der Meinung es sollte nicht mehr von Hand gezeichnet werden. Im Hintergrund wird schon am so genannten Wikipedia-Atlas gearbeitet. Dort kann man über den Mittelpunkt den entsprechenden Kartenausschnitt automatisch generieren lassen. Alles anndere ist nicht sinnvoll. Schau einfach mal bei http://meta.wikimedia.org/wiki/Wikimaps rein. Da steht alles weitere. -- sk 17:00, 6. Okt 2005 (CEST)

Ich habe bis jetzt noch keine vollautomatisch generierte Karte gesehen, die auch nur annähernd an die Layoutqualität von teilmanuell erstellten Karten heranreicht (alleine die Problematik der Beschriftungen kennst du ja sicher). Wenn es solche gibt, kannst du mir ein paar Links zu Beispielen nennen? --Neitram 11:49, 7. Okt 2005 (CEST)
Ich hätte zum Beispiel gerne eine Karte von Deutschland, die sämtliche Landkreise und kreisfreien Städte anzeigt, als Pixel- oder Vektorgrafik, einmal ohne Beschriftung und einmal mit Beschriftung. Die Länder sollten etwas voneinander abgesetzt sein durch etwas dickere Linien. Haben wir so etwas schon irgendwo?
Leider finde ich auch nirgends eine entsprechende Tabelle bezgl. Flächen und Einwohnerzahlen hierzu. -- Simplicius 13:22, 7. Okt 2005 (CEST)

Projekt "Straßenkarte für Deutschland, Österreich, Schweiz"

Wie wäre es (in Einklang mit den bisherigen Gedanken und Projekten auf Wikimaps), ein Projekt "Erstellung einer freien Straßenkarte für Deutschland, Österreich und die Schweiz" zu starten? So wichtig weltweite Geodaten und Karten sind, könnte ich mir vorstellen, dass so ein Projekt viele Wikipedianer motivieren könnte, mitzumachen. Vor allem wenn wir nach dem Rapid-Prototyping-Prinzip vorgehen und rasch eine "noch ziemlich leere" Karte vorzeigen können, damit man schon mal was sieht, die den Rahmen vorgibt und an deren Füllung jeder mitarbeiten kann. Ich stelle mir vor, dass es eine einzige "große" Gesamtkarte von D/A/CH sein sollte, von der dann auch dank Vektorgrafik beliebige Ausschnitte für "Regionalkarten" verwendet werden können. Die verschiedenen Kartenelemente (große Städte, kleine Städte, große Straßen, kleine Straßen) sollten in getrennten Layern gezeichnet/geodatenprogrammiert sein, so dass sie je nach gewünschter Detailauflösung hinzugenommen oder weggelassen werden können. --Neitram 11:49, 7. Okt 2005 (CEST)

Kartenübersicht für die Wikipedia

Existiert eine Übersicht der in der Wikipedia vorhandenen/hochgeladenen Karten? Arcy 22:18, 7. Okt 2005 (CEST)

Es gibt da einen schwachen oder starken Trend, nämlich Commons, je nachdem wie sich das Meinungsbild entwickelt. In Sachen Kategorien und Übersichten versuche mal Maps. Hier in der deutschsprachigen WP werden die Kategorien ja schon demontiert bevor die Bilder überhaupt transferiert wurden. -- Simplicius 22:33, 7. Okt 2005 (CEST)
Ich denke mal viele Karten wie z.B. Bild:Lage Prenzlauer Berg in Berlin.png schwirren im Nirvana der deutschen Wikipedia und sind nur über den jeweiligen Artikel auffindbar. Kolossos 22:41, 7. Okt 2005 (CEST)
Vielleicht sollte man mal eine Übersicht der in der deutschen Wikipedia vorhandnen Karten erstellen. Ich denke dabei vor allem an eingescanntes Kartenmaterial und selbsterstellte Karten mit hohem Informationsgehalt. Auch diese Karten könnten mittels World Datei oder KML georeferenziert werden und in andere GIS-Programme oder Google Earth eingebunden werden Arcy 16:33, 8. Okt 2005 (CEST)
Natürlich. Aber am günstigsten wäre es schon, die Bilder würden zunächst migriert nach Commons, mit den Bildern in den dortigen Kategorien vereinigt, und dann könnte man die Verortung dort machen (die Deckungsgleichheit ist schon ein ziemliches Stück Arbeit) und sämtliche Benutzer aus 100 anderssprachigen Wikipedias hätten auch was davon.
Leider mauern sich da auch viele im Meinungsbild mit ihrem komischen "Leberkäse nur von und für Deutsche" ein. -- Simplicius 17:09, 8. Okt 2005 (CEST)

Georeferenzierung von historischen Stadtplänen

Ich habe mal auf Image:Munich 1858 - London, John Murray, 1858.jpg einen Link gesetzt der die Karte als Image-overlay in Google-Earth aufruft. Also eine Georeferenzierung der etwas anderen Art, an der man gut erkennen kann was sich in den Jahren der Kartenzeichnung bis heute so verändert hat, dafür ist der Schieberegler zur Transparenzeinstellung praktisch. Mich würde mal eure Meinung interessieren. Karten von größeren Gebieten scheitern übrigens an der unterschiedlichen Projektionsarten. Der alte Plan kann dann übrigens auch zur Georef. von Punkten dienen die in Google-Earth nicht zu erkennen sind. Kolossos 22:52, 7. Okt 2005 (CEST)

Köstlich. Wie macht man das? Wie kriegt man die Karte deckend? Steht das irgendwo in den unter KML verlinkten Anleitungen? -- Simplicius 23:23, 7. Okt 2005 (CEST)

Eigentlich kann jeder mitmachen (sogar ohne Programmierkenntnisse) hier die Kurzanleitung:

  • In Google-Earth in die Nähe zoomen
  • Im Menü Add/Image Overlay aufrufen
  • Die URL des gewünschten Kartenbildes in das Feld "Image URL or Filename" kopieren
  • erstmal Ok drücken damit das Bild geladen wird, dabei erscheint im Menü Places ein neuer Eintrag
  • dann rechte Maustaste auf den neuen Eintrag und "edit" auswählen
  • Jetzt läßt sich das Bild rotieren, verschieben oder an den Ecken strecken
  • Es empfiehlt sich wenn die Karte nicht eingenordet war zuerst die Rotation vorzunehmen, dann an einer Ecke einen markten Punkt auf Deckung und abschließend auf der gegenüberliegenden Seite die Deckung herzustellen. (Das kann etwas dauern). Und Ok drücken
  • Anschließend, rechte Maustaste auf den Eintrag und "Save As" *.kmz- file.
  • Als Abschluß die kmz-Datei (ca. 1kB groß) ins Internet hochladen und darauf verlinken.

Das Commons-Mediawiki darf leider keine kmz-Files im Upload erlauben sodaß man im Moment einen externen Link benötigt. Für Leute die keinen Webspace zur Verfügung haben, würde ich erstmal mein Wiki-Upload anbieten, den ich auch selber nutze.Kolossos 00:56, 8. Okt 2005 (CEST)