Wikipedia Diskussion:WikiProjekt Georeferenzierung

Einleitung dieser Diskussionsseite anzeigen

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:

Dringender Bedarf zur Revision der Vorlage

Liebe Wikipedianer: habe mich ja schon unten an mehreren Stellen stark gemacht, für eine Revision der aktuellen Vorlage (bzw. dieses Datenbanklinks). Ich realisierte nun, dass diese(r) im Stile wie

 {{Koordinate Artikel|52_30_18_N_13_16_41_E_type:landmark_region:DE-BE|52°nbsp;30'nbsp;18"nbsp;N, 13...}}

noch revisionsbedürftiger ist, als ich dachte. Daher habe ich diesen Diskussionsabschnitt mal an den Anfang getan.

Ich habe diese Vorlage mal nach technischen Gesichtspunkten analysiert und mit anderen verglichen und stelle folgendes fest: Die Vorlage hat drei Werte (jeweils getrennt mit '|'): 1. Koordinate Artikel, 2. Koordinatenwert und 3. Text. Über den ersten Wert herrscht gemäss Archiv3 offenbar Konsens (Koordinate Artikel, Koordinate Text, Koordinate Text Artikel). Wie schon gesagt, ist m.E. im zweiten Wert der type (type:landmark) als Ballast und potentielle Fehlerquelle zu bezeichnen, wo man hingegen region noch knapp durchgehen lassen kann als Hinweis für Benutzer und die verarbeitende Software - obschon auch diese Angabe einer Geonamen-Datenbank über die Koordinate bereits klar wäre. Der letzte als Text bezeichnete Vorlagen-Wert (52°nbsp;30'nbsp;18"nbsp;N, 13°nbsp;16'nbsp;41"nbsp;O) ist ja wie gesagt nicht nur (zu) lang sondern innerhalb der Vorlage doppelt, was also erst recht Ballast ist. Innerhalb des Koordinatenwerts werden nun noch stärkere Regeln gebrochen: Da werden in einen einzelnen Wert gleich vier(!) Angaben 'hereingepackt' (lat, lon, type und region) und alles - auch Koordinatenwerte in sich - wird gleichartig mit '_' abgetrennt. Das alles widerspricht der Syntax und Semantik von Vorlagen, bzw. Datenbanklinks. Sinngemäss und richtigerweise sollte es z.B. heissen:

 {{Koordinate Artikel|lat=52.505|lon=13.278|type=landmark|region=DE-BE|52°nbsp...}},

wobei ich mir erlaubt habe, die 'Darstellungsorgie' des letzten Werts ('52°nbsp...') wieder etwas zu kürzen;nbsp;nbsp;... D.h. der '_' muss weg, das 'N' und 'E' ebenfalls und alles müsste mittels '|' abgetrennt werden und korrekterweise mit '=' zugewiesen werden. Mit dieser Syntax (am liebsten ohne type und text; vgl. Vorschlag 2) könnte man viele Diskussionen abkürzen und würde sich einies Programmierer-Kopfweh sparen. Sogar die Frage nach einer Höhenangabe wäre auf dieser Basis elegant lösbar. (es folgt nun die bisherige Diskussion) -- Geonick 15. Okt. 2005 (CEST)

Doppelung der Koordinatenangabe unnötig

Die Doppelung ist gar nicht notwenig sondern besteht aus einer Abwälzung von Programmierfaulheit auf unnötige Arbeit beim Wikipedia-Autor. Statt 52_30_18_N_13_16_41_E|52°nbsp;30'nbsp;18"nbsp;N, 13°nbsp;16'nbsp;41"nbsp;O könnte man auch einfach nur 52°nbsp;30'nbsp;18"nbsp;N, 13°nbsp;16'nbsp;41"nbsp;O schreiben (by the way: kann man statt den nsbp; nicht das ganze in ein div- oder span- packen, bei dem Zeilenumbruch ausgeschaltet ist?). Die Software (hier: das Skript, dem die Koordinaten übergeben werden) soll gefälligst so schlau sein, die Angaben zu parsen, egal ob sie nun mit oder unter Unterstriche, dezimal oder in Grad etc. geschrieben sind! Für den Anfang würde auch ein Skript reichen, dass das Parsen übernimmt und dann an den kvalberg-Server weiterleitet - dafür muss noch nicht mal was bei MediaWiki oder Kvalberg geändert werden. Es ist nur einfach noch niemand dazu gekommen, einen Parser für verschieden-formatierte Koordinaten-Angaben mit eingesprengselten HTML-Fragmenten zu schreiben. Zusätzlich kann jetzt schon mit {{PAGENAME}} der Artikel übergeben werden, von dem der Link kommt.

Also sollte es nur noch heissen:

{{Koordinate Artikel|52°nbsp...|type:landmark region:DE-BE}}

Das unsägliche type:landmark_region:DE-BE ist zwar blöd aber ohne Plugins o.Ä. Eingriffe im MediaWiki soweit ich es beurteilen kann nicht zu machen. Stattdessen könnte der Kartenservice in bspw. in einem Dump der Kategorien nachschauen, um was für eine Art von Artikel es sich handelt oder sich per raw den Artikeltext holen und nach Kategorien, Regionen etc. durchparsen. -- Nichtich 15:20, 25. Okt 2005 (CEST)

Diese Syntax erfüllt bereits einige Forderungen, die ich oben und unten aufgestellt habe. Der Link soll tatsächlich aus Sicht des Benutzers einfach zu handhaben sein (falls er sich Wikitext gewohnt ist). Demnach sind aber m.E. Spezialzeichen wie ° oder ' wieder eine Quelle der Unsicherheit bei der Eingabe; ev. sind Dezimalangaben (ohne '_') noch einfacher. Der Hinweis auf die pragmatische Lösung mit type und region ist nicht falsch solange der erwähnte Kartenservice das nicht mir Kategorien macht. Auch bei dieser Syntax gibt es Verbesserungspotential etwa durch klare Trennung zwischen type und landmark (ob mit '|' oder etwas anderem, nur nicht mit '_'), sonst kommt noch einer auf die Idee 'landmark_region' gehöre zusammen... -- Geonick 20:52, 25. Okt 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 4. Okt. 2005

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}}:

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).
Zweitens erscheint eine Kategorie (Typ) obschon eine solche schon existiert;
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:

Zwei klare Datenbanklinks, einer eingebettet im Text und einer für ganze Artikel.
Format am Beispiel Artikel 'Berliner Funkturm': {{Koordinate Artikel|declat=52.505|declon=13.278056}}.

Die Darstellung auf einer Mediawiki-Seite übernimmt die Software; der Umgang mit mehreren Kategorien und deren Aggregierung ebenfalls (und das geht). Bei der Ausführung von Datenbanklinks könnten Kategorien mit einer neuen seitenabhängigen Variablen {{CATEGORIES}}</tt> übergeben werden. Geonick 5. Okt. 2005 (CEST)

Ok, das klingt alles recht vernünftig, aber ich muss ganz ehrlich sagen, das "declat=" und "declon=" mir nicht gefallen. Ich verwechsle immer lat und lon, weshalb ich hier "Laenge=" und "Breite=" vorschlagen würde. Wieso willst du die "Vorlage:Koordinate Text Artikel" abschaffen? Sie hat auch ihre Berechtigung und wird vielfach in den Stadttabellen genutzt.-- sk 13:38, 26. Okt 2005 (CEST)Es geht hier wieder um die Frage, ob das Prinzip der Trennung von Inhalt und Darstellung eingehalten ist: der Koordinaten-Erfasser soll sich nur darum kümmern, zu was die Koordinate gehört: Zum ganzen Artikel oder zu einem Abschnitt. In den Erläuterungen steht nun "und zur zusätzlichen Anzeige in der rechten oberen Ecke". Ob die Koordinate nun zusätzlich - wo auch immer - angezeigt wird (weil es z.B. zufällig die einzige ist in diesem Artikel), soll gefälligst der Computer übernehmen. -- Geonick 21:50, 27. Okt 2005 (CEST)Das Prinzip der Trennung von Inhalt und Darstellung ist ja sehr lobenswert, aber wie willst du es anders umsetzen? Da scheint mir das mit der dritten Koordinatenvorlage doch am einfachsten oder kennst du einen noch einfacheren Weg? -- sk 09:23, 28. Okt 2005 (CEST)Per Extension z.B. Dort würde die Software die Formatierung / Darstellung einer Koordinate übernehmen. Nichts anderes macht das MediaWiki Markup allgemein. Im GISWiki findet sich Beispiele für die Eingabe von Koordinaten und deren Formatierung durch eine Extension. Man kann z.B. 48 46 36 N 121 48 51 W eingeben und erhält 48°46′36″ N 121°48′51″ W als Ergebnis. Auch das Tool hjl_get_CoorM.htm macht nicht viel anderes für die Aufbereitung von Koordinaten für die WP--Arcy 19:47, 28. Okt 2005 (CEST)BR und NBSP und Browser

Durch unglueckliche Umstaende wander ich derzeit des oefteren mit dem Microsoft Explorer 6.0.x durch die Wikipedia Bestaende. Dabei fiel mir eine Unart ins Auge - der bricht die Koordinaten nach scheinbar wilden Regeln. Ein kleiner Test auf der Wikipedia:Spielwiese erhellte meinen Geist. Lasst mich berichten.

Zuerst mal, es ist in einigen Orts-Artikeln schon voellig ueblich, die Koordinate mittels hartem <br> anzugeben - womit die Angabe immer zweizeilig wurde obwohl die Koordinate in den sehr vielen Faellen auch auf eine Zeile passt. Aber man geht falschen Umbrueche aus dem Wege, wenn da Leerzeichen zwischen X° und Y' steht. Nun gut, ich hab da einfach mal auf die   Schreibung umgestellt, und oftmals die Grad/Sekunden zusammengeschrieben. Was durchaus korrekt ist - aber...

Wenn der Microsoft Explorer 6.0.x folgendes sieht:
..... 52°00'00" N 10°00'00" O
dann laesst er es durchaus zu, nach dem 10° einen Umbruch einzufuegen. Das sieht dann voellig haesslich so aus:
52°00'00" N 10°
00'00" O

Aber irgendwie macht er das nicht immer. Wenn man naemlich nach dem Grad-Zeichen noch einen Hardspace einfuehrt, dann wird er nicht mehr nach dem Grad-Zeichen trennen wollen. Also, eine Schreibung der Form
..... 52° 00' 00" N 10° 00' 00" O
wird immer das richtige ergeben, naemlichst
52° 00' 00" N
10° 00' 00" O

Diese Unart duerfte damit die beste Schreibung fuer Koordinaten fixieren: zwischen die Grad-Zeichen, Sekunden-Zeichen usw gehoert jeweils ein Leerraum, und zwar ein Hardspace   gesetzt. Dann wird bei mangelndem Platz auch tatsaechlich zwischen den beiden Koordinatenhaelften umgebrochen. Und zwar nur dann, wenn mangelnder Platz. GuidoD 6. Jul 2005 18:46 (CEST)

Was genau ist der Gedanke hinter den ungleichen Abständen zwischen Grad und Minute (nbsp)und Minute und Sekunde (Leerzeichen + nbsp)? Das sieht gar nicht gut aus! Auch zwischen Sekunde und Himmelsrichtung steht Leerzeichen + nbsp, was meiner Meinung nach zu viel des guten ist. fragwürdig ?! 08:05, 13. Okt 2005 (CEST)Ich versteh die Frage nicht. nbsp folgt hinter Grad, Minute und Sekunde. Zwischen der Ziffer und nbsp folgt das Einheitenzeichen. Denk nochmal über deine Frage nach. --BLueFiSH ?! 22:25, 13. Okt 2005 (CEST) Vielleicht auch einfach mal vorne in der Hauptseite gucken, da steht geschrieben wie es aktuell gemacht wird: Wikipedia:WikiProjekt_Georeferenzierung#Vorlagen-Ausgabetext --BLueFiSH ?! 22:29, 13. Okt 2005 (CEST)Denk du bitte lieber über deinen Ton nach. Ich bin doch nicht blöd und schreibe sowas aus Jux und Dollerei. Der Abstand nach Minuten- und Sekundenzeichen war definitiv größer als nach dem Gradzeichen. fragwürdig ?! 22:42, 13. Okt 2005 (CEST)Ich denke... kein Fehlverhalten erkannt. Ums nochmal auf den Punkt zu bringen: wahrscheinlich hast du eine schlecht formatiertes Koordinate gesehen, denn so wie es aktuell eingefügt wird, entspricht es nicht dem von dir geschilderten Aussehen. Wenn du nen Link anbringst, kann man sich davon auch ein Bild machen. --BLueFiSH ?! 00:21, 14. Okt 2005 (CEST)Gerne: Paldiski, allerdings offensichtlich nur im IE6.0 bei mir auf Arbeit. Genauer besehen scheint das Problem zu sein, daß die Sekunden- und Minutenzeichen beim benutzten Font fast so aussehen als ob ein Leerzeichen hinten dran hängt. Ich habe jetzt keine Zeit zum Hochladen, aber am Montag oder Dienstag könnte ich mal einen Screenshot präsentieren. fragwürdig ?! 08:37, 14. Okt 2005 (CEST)In Paldiski wird ein   als Trennzeichen der Koordinatenausgabe gar nicht verwendet. Habs aber jetzt mal angepasst. --BLueFiSH ?! 08:44, 14. Okt 2005 (CEST)Es sieht leider immer noch falsch aus. Wie gesagt, es scheint ein Problem der Sekunden- und Minutenzeichen zu sein und nicht des  . Hier ein Beispiel: -- fragwürdig ?! 14:29, 14. Okt 2005 (CEST) ja, so sollte es natürlich nicht aussehen, aber bei meinem Firefox 0.8 und IE 6 (SP1) sieht es nicht so aus wie bei dir. Ist das denn die Regel oder nur eine Ausnahme bei diesem speziellen Artikel? --BLueFiSH ?! 14:46, 14. Okt 2005 (CEST)Leider die Regel (stichprobenartig getestet) im IE 6.0 SP2. Ich werde das aber später noch mal bei mir zuhause im IE testen. fragwürdig ?! 15:19, 14. Okt 2005 (CEST)Erstaunlich, die Energie, welche hier in doppelte Information gesteckt wird. Was spricht dagegen, wenn man sich auf Dezimalangaben konzentrieren könnte? Im Archiv habe ich bisher keine Argumente dagegen gefunden, lasse mich aber gerne belehren. Die DIN-Norm jedenfalls wird hier ja auch nicht eingehalten! Habe zudem an anderer Stelle schon darauf hingewiesen, dass man die Koordinaten-Angaben nur einmal eintragen sollte; diese Angaben können im Wikitext dann automatisch formattiert werden (und zwar für das ganze Wiki einmal definiert und zentral abgelegt - da kann man dann die Darstellung so lange ändern, bis sie allen gefällt...) -- Geonick 15. Okt. 2005 (CEST)Es werden schräge statt gerader Ticks verwendet. Die Stichprobe ist fragwürdig, da ich es selbst nie verwende. Ich hab das im Ursprungsposting auch nie empfohlen, die Anzeige des "Sekundenzeichens" war mir verschiedentlich zu grausam. Tatsächlich ist, von mir leider bisher unbemerkt, die Verwendung des schrägen Sekundenzeichens statt gerader Apostroph/Gänsefüsschen auf die Hauptseite dieses Artikels gekommen, und wird in der copy-n-paste Vorlage auf kvaleberg vorgegeben. Ich betrachte das als groben Fehler. GuidoD 02:23, 31. Okt 2005 (CET)Vorschlag: Reform der VorlageFragen

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)VorschlagLasst 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? -- ArcyOb 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.

http://www.mysql.com/doc/en/Spatial_extensions_in_MySQL.html 134.106.146.46 10:51, 27. Sep 2005 (CEST) (Arcy)Ich stelle fest: Die KML-Anwendung, die man im Kopf hatte, erreicht eine Kategorisierung auch ohne doppelspurigen type, während es Lösungsvorschläge (nur Vorlage Koordinate, Kategorien wie bisher) gibt, die allen möglichen Anwendungen nützen. -- Geonick 8. Okt. 2005 (CEST)

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)

Bin für Vorschlag 2 unten. Grund:

"zwei verschiedene Vorlagen noch immer zu viel": Es gibt zwei Anwendungen der Georeferenzierung mit je mit unterschiedlichen Darstellungen: Koordinaten, die sich auf den ganzen Artikel beziehen und solche, die sich auf Abschnitte (bis Einzelworte) beziehen. Daher 'Geokoordinate Artikel' und 'Geokoordinate Text'."die Sache mit der Infobox rausnehmen." Richtig, keine doppelten Eintragungen zum gleichen Sachverhalt im gleichen Artikel."Die Eingaben sollten nur nach dem System Grad Minuten ... stattfinden." Die reine Dezimal-Angabe lässt die Anzahl stellen offen (im Ggs. zur zitierten Weise) und ist daher vorzuziehen. Jemand hier hat zu Recht gesagt: "sagen mir eh nichts..."."Es kann doch nicht sein, dass ich da einen Mega-Einzeiler baue, mit ersetzten Leerzeichen." Niemand will einen Mega-Einzeiler, weder die Leute noch die Browser! Lasst uns also einen einfachen bauen und "und nur nach 1 System laufen".Der anschliessende Vorschlag ist hochgradig redundant und verletzt das WYSIWYG-Prinzip. Ersteres macht die Sache kompliziert und letzteres erschwert die Kontrolle (alles was eingegeben wird, sieht man). "NAME, KURZBESCHREIBUNG, STATE, ADMIN1, ADMIN2, CITY, TYPE" sind also überflüssig und Benutzer-unfreundlich. BREITE und LAENGE werden dezimal und separat codiert: declat=<BREITE>, declon=<LÄNGE>, so wie dies andere Standards auch tun. Damit reduziert sich der Vorschlag zu Vorschlag 2 unten. 62.202.96.137 8. Okt. 2005 (CEST)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 SlomoxAlso 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 scheint mir ein weiterer wichtiger Hinweis zu sein, type von Koordinaten trennen. Damit werden zwei Dinge vermischt und unnötigerweise Redundanzen schafft, während es andere Lösungen gibt, welche alle bisher erwähnten Nutzungen des Wikitextes einschliessen, wie namentlich KML extrahieren und Egil's Erweiterung (welche noch weiter ausgebaut werden könnte). Kommt dazu, dass die aktuelle Handhabung von type (und beispielsweise auch Personendaten) ein weiteres Prinzip verletzt (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, aber das ist eine andere Geschichte). 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)

Ich unterstütze diesen Vorschlag (vgl. oben "1.2 Vorschlag" und "1.3 Argumente für Vorschlag 2 unten"). Das würde die Sache für alle einfacher machen und könnte trotzdem funktionieren: kurzer Datenbanklink, die notwendigen Informationen sind nur einmal vorhanden, Kontrolle dank Sichttext, sowie Entmischung von Codierung und Darstellung. Die Benutzer und die Kontrolleuere hätten es einfacher. Die Software ist vorhanden, bzw. müsste nur geringfügig ausgebaut werden (Seiten-Variable CATEGORIES) und die Stefans und die Bots machen den Rest. Bleibt nur noch die Ärmel hochzukrempeln und die Artikel zu verorten und mit korrekten Kategorien versehen :-> Geonick 8. Okt. 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)

Vielen Dank, Stefan, für deine Arbeit. Ich habe das heute mal getestet und es macht auf den ersten Blick einen guten Eindruck.
Beim Drehen der Erdkugel sind mir dann auch gleich einige Länder aufgefallen, wo es noch kaum Koordinaten gibt, während bei anderen schon eine gute Abdeckung vorhanden ist. Ein gutes Beipiel sind da das ziemlich gut erfasste Ecuador (wo ich selbst viele Koordinaten eingetragen habe) und Kolumbien, wo so gut wie noch keine Koordinate vorhanden ist. Hier bleibt also noch viel zu tun, und vielleicht sollten sich die Aktivisten hier als ersten Schritt mal alle Kategorien Ort in xy vornehmen und die häufig vorhandenen Koordinaten in einfachem Text in die Vorlage umwandeln.
Außerdem ist mir aufgefallen, wie wichtig es gerade für einen solchen Export auf eine Karte/ein Satellitenbild ist, dass die Koordinaten einigermaßen genau sind (das heißt für Ortskoordinaten auf die Sekunde in der Ortmitte). Ein gutes Beispiel ist hier die Koordinate von Berlin-Friedrichshain, die mitten in Prenzlauer Berg liegt. Hier zeigt sich auch mal wieder, wie wichtig vorausschauendes Denken ist: ich erinnere mich noch an eine Aussage auf der Wikipedia:Formatvorlage Stadt vor etwa einem Jahr, dass die Genauigkeit von einer Minute bei der Koordinatenangabe für einen Ort ausreichend ist und die Daten von OpenGeoDb einigermaßen genaue Ergebnisse liefern. Das beides so nicht stimmt, zeigt sich jetzt deutlich. Da bin ich nur beruhigt, dass ich seit der Einführung des Kvaleberg-Links wirklich ausreichend genaue Angaben gemacht habe und jetzt nicht alle Orte irgendwo im Wald liegen. --Mazbln 20:50, 8. 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)Die Gliederung nach Regionen (Städten, etc.) ist ja genau das, was Kategorien u.a. leisten. Weitere Kategorien dienen der Attributierung wie 'Sehenswürdigkeit', 'besonders schöne bayrische Sehenswürdigkeit' etc... Dazu kommt das legitime Bedürfnis, zusätzliche Angaben wie Einwohnerzahl zu erhalten. Auch hier zeigen sich bereits jetzt die Grenzen des aktuellen Ansatzes mit type: Warum darf denn type:country/state/adm1st/adm2st nicht auch Einwohner haben? Und warum diese Angaben im Wikitext verstecken? Habe irgendeine Stadt herausgepickt, z.B. Bogotá: Da steht zur Zeit in der sichtbaren Infobox 7.185.889 Einwohner und im Datenbanklink type:city(7'102'602)?! Fazit: Für Eigenschaften, die über eine Kategorisierung hinausgehen, müssen Vorlagen so ergänzt werden, dass diese Eigenschaften als Attributwerte definiert sind. Diese Attribute sind im Wiki-Rohtext formal definiert und erscheinen auch im Sichttext. Nun könnt ihr (fast) alles haben: Regionen, Kategorien, Einwohner in Orten, in Ländern - alles der Zauber strukturierter (Geo-)Datenbanken... -- Geonick 9. 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)Neitram: Das Problem der Handzeichnung ist, dass sie mit Liebe einmal und für einen Zweck erstellt wird und dann nur einmal für diesen Zweck verwendet werden kann. Wenn man aber erst einmal die Rohdaten (sprich: Geodaten) erfasst hat, dann kann man daraus verschiedenste digitale Karten generiereren. Dies, sei es automatisch oder aber man nimmt sich die Mühe und bessert sie von Hand aus - bis die nächste Fortführung kommt... Zu den automatisch generierten Karten gehört dann auch diejenige, die Simplicius gerne hätte (aber nur falls Geodaten und Kategorien vorhanden sind und nur wenn die Einwohnerzahlen nicht nur im type:city(xxx) sondern in formalisierteren Vorlagen sind; vgl. Diskussion um Vorlage 2 oben). -- Geonick 9. Okt. 2005 (CEST)Schon klar, die vollautomatische Generierung von Karten ist eine tolle Sache. Aber wie gesagt, ich habe bis jetzt noch keine solche Karte gesehen, die Layoutqualität von teilmanuell erstellten Karten heranreicht. Beispiele für vollautomatisch generierte Karten, die mir bekannt sind: OMC, DEMIS, irgendein Routenplaner. Im Vergleich dazu Beispiele für teilmanuell generierte Karten: [2], [3], [4]. Wohlgemerkt: selbstverständlich basieren teilmanuell erstellte Karten ebenso wie die vollautomatisch erstellten auf Geodaten. Aber was den layouttechnisch erfahrenen Menschen (mit Computerunterstützung) IMHO noch immer dann unverzichtbar macht, wenn man eine gute Karte möchte und nicht nur irgendwas in - ich sag mal - "Routenplanerqualität", ist die Platzierung der Beschriftungen (Orts-, Fluss-, Berg-, Straßennamen usw.). Wie gesagt: wenn mir jemand ein Gegenbeispiel zeigen kann, nehme ich alles zurück und reihe mich nur zu gerne in die Ränge der Map-Engine-Puristen ein. Übrigens noch eine Randbemerkung dazu: Wenn man in Vektorgrafik und nicht in Bitmapgrafik "zeichnet", ist jeder Punkt jeder Linie auch zugleich eine Geokoordinate. Es besteht also kein prinzipieller Unterschied zwischen dem Zeichnen und dem Erfassen von Geodaten wie z.B. dem Verlauf eines Flusses oder einer Straße. Vielleicht verliert das Wort "Zeichnen" damit den Schrecken der Vorstellung, dass die in eine solche Karte hineingesteckte Arbeit nicht für andere Karten wiederverwendbar sei. Selbstverständlich soll sie das sein, und SVG sollte das ja auch ermöglichen. Oder liege ich da falsch? --Neitram 15:15, 10. Okt 2005 (CEST)Ja; das wird jetzt schwierig, auf so engem Platz zu debattieren. Es geht mir kurz gesagt um digitale, Rohdaten, die noch nicht graphisch aufbereitet (und daher mehrfach-verwendbar) sind (vgl. dazu Abb.3. in diesem PDF). Diese Geodaten sollen z.B. topologisch korrekt sein (auch bei Tunnels und Unterführungen) und nehmen (geometrisch) bewusst noch keine Rücksicht auf andere Objekte, bzw. spiegeln die modellierte reale Welt (keine Generalisierung über den Erfassungsmasstab hinaus). Ich sage dies in dem Sinne, dass die Erfassung von "Regionalkarten mit Städten und Straßen" zuerst sich um die 'rohen' Geodaten kümmern sollte. Man spricht dann nicht von (Grafik-)Ebenen sondern von Gebäude- und Strassen-Objekten. Deren Namen sind z.B. zunächst einfach einem Objekt zugeordnet. Auf dieser Basis können dann die einen automatisch Karten erstellen und Kartographen können 'schöne' Karte ableiten, sprich: Generalisieren und händisch Namen platzieren - im Hinblick auf einen (meist einzigen) bestimmten Zweck und Massstab. -- Geonick 01:10, 10. Okt. 2005Projekt "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)Ausgezeichnete Idee, die Kartenbilder zu verorten! Der Vorschlag mit der en:World_file scheint mir nützlich. Man könnte dies ja in eine Vorlage tun, welche sowohl in normalen Artikel als auch in Commons zum Zuge kommen könnte! Ein weiterer Einstiegspunkt ist sicher auch Kategorie:Bild:Karte. Wer sich nicht alles in 200er-Schritten durchklicken will, der kann es mit meinem Prototyp geometa.info - der Suchmaschine für Online-Karten und Geodaten - versuchen: Suche nach 'Bild Karte'. -- Geonick 9. Okt 2005

Das en:World_file-Format hat imho einen Nachteil, weil es mit der Bild-Auflösung verbunden ist. Die Angabe der NW-NO-SW-SO-Koordinaten der Bildecken erscheint mir sinnvoller oder sollte zumindestens zusätzlich angegeben werden. 134.106.146.46 09:41, 10. Okt 2005 (CEST)

Ja; stimmt eigentlich - und noch 'schlimmer': es fehlt eine allenfalls optionale Angabe des Koordinatenreferenzsystems! Aber wenn das Bild in Wikipedia abgelegt werden soll, dann ist es ja sowieso nicht einfach, das Worldfile als File beizulegen. Viel sinnvoller wäre es, die Angaben über eine strukturierte Vorlage festzuhalten. -- Geonick 11. Okt. 2005Georeferenzierung 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)

Korrektur der KML Datei

Hallo Leute, habe gerade die KML-Datei aktualisiert. Hauptstädte nach oben, Orte mit weniger als 1000 EW in extra Ordner und anderes Symbol für Naturobjekte. -- sk 19:38, 9. Okt 2005 (CEST)

Sehr schön. Frage: Haben Sie schon einmal versucht, Koordinaten-Artikel anstelle mit type mit Kategorien zu extrahieren? -- Geonick 15. Okt. 2005 (CEST)Hi Geonick, kannst mich ruhig duzen. Also bei der jetzigen KML-Datei wurden als Groborientierung der Type genutzt. Wenn einige Unterordner dann zu voll wurden und leicht über bestimmte Kategorien weiter veredelt werden konnten, dann hab ich das hier gemacht. So sind z.B. alle Brücken erst als Landmarke registriert worden und dann weiter über die Kategorie:Schrägseilbrücke, Kategorie:Hängebrücke etc. in den Unterordner Brücke einsortiert worden. Das funktioniert sehr gut. Man muss halt nur ab und an mal schauen, wo es noch weiteren Feinsortierbedarf gibt. Einzigstes Problem ist, dass bei der KML jede Koordinate nur in einen Unterordner kann und man dadurch Präferenzen setzen muss. Also wenn eine Brücke Weltkulturerbe ist, dann ist sie z.B. in Weltkulturerbe einsortiert. -- sk 13:46, 16. Okt 2005 (CEST)Ok; vielen Dank. Meine eigentliche Frage aber war, ob du es schon mit Kategorien versucht hast? War das der Grund, warum einige Diskussionsteilnehmer hier Kategorien nicht mochten und 'type' einführen wollten? Aus meiner Sicht ist das nur ein vermeintliches Problem, denn man könnte beim Generieren von KML - oder welches Grafik-Outputformat auch immer - entweder direkt die Oberkategorie Brücke selektieren oder aber eine Konfiguration verwenden, welche dafür sorgt, dass die Unterkategorien Schrägseilbrücke, Hängebrücke etc. zur Oberkategorie (= Unterordner) Brücke aggregiert werden. -- Geonick 16. Okt. 2005 (CEST)Deutschsprachige Seite für Koordinatenangaben

Kann die kavelbergseite auch in deutscher sprache zur verfügung gestelt werden?

Du meinst jetzt sicherlich die Seite, die angezeigt wird, wenn man nicht "region:DE" in der Koordinate hat. Das müsste ja über ein Auslesen der Browsereinstellungen erfolgen und kann somit nur durch Hr. Kvaleberg eingerichtet werden. --BLueFiSH ?! 00:21, 14. Okt 2005 (CEST)Es stimmt, dass die Sprache von externen Webseiten (bzw. Datenbanken) von den entsprechenden Betreibern abhängt. Das Bedürfnis, Webseiten in einer bestimmten Sprache anzuzeigen hat aber wenig mit dem Fakt zu tun, den man mit "region:DE" einem Artikel oder Textabschnitt (oder beidem) zuordnen will. Ganz flexibel wäre folgendes: Die Sprache einer Webseite wird aufgrund des HTTP-Headers des Browsers eingestellt und allenfalls mittels URL-Parameter oder Cookie übersteuert. Damit erhält ein deutschsprachiger Benutzer von welchen Orten auch immer (in Zukunft) die Möglichkeit, die Seiten einer Datenbank (hier kvaleberg) auf deutsch zu sehen während dieselbe Seiten ein Norweger auf norwegisch sieht. "region:DE" dient in beiden Fällen - neben der besseren menschlichen Einordnung - dazu, die Koordinaten eines Artikels ins Koordinatensystem einer Region umrechnen zu können (vgl. z.B. region:CH). -- Geonick 15. Okt. 2005type:PPL, type:PPLX und type:RGN

Ich hab gerade mal ein paar Korrekturen bei einigen Koordinaten in der Wikipedia vorgenommen. Jetzt hab ich noch diese drei Typen, mit den ich nicht so richtig weiß wohin. z.B. Samtgemeinde Hagen (PPL), Berlin-Mahlsdorf (PPLX) und Barnim (RGN). Alle typen kommen mehrmal in der Wikipedia vor und ich würde sie mit dem Sk-Bot ersetzen, wenn ich wüsste was ich da für einen type hinschreiben soll. Vielleicht habt ihr ja eine Idee. -- sk 18:22, 14. Okt 2005 (CEST)

Samtgemeinden sollen unter type:adm2st einsortiert werden. --Fuzzy 19:56, 14. Okt 2005 (CEST) type:adm2st wäre doch eher der Landkreis. Oder haben wir evt. type:adm3st für solche Samtgemeinden? -- sk 20:03, 14. Okt 2005 (CEST) nebenbei: über adm2st hab ich mich letztens schon mal extremst gewundert. müsste es nicht adm2nd lauten? Analog zur englischen Zählweise 1st, 2nd und 3rd... Siehe auch mal google-Ergebnisse: adm2nd=1630 Hits gegen adm2st=8 Seiten und diese alle in der Wikipedia... das sollte man nochmal überdenken und korrigieren. Im Übrigen zählt für mich die nächstkleinere Ebene unter den Bundesländern dazu. Der Unterschied von PPL und PPLX hat sich mir auch noch nicht erschlossen. --BLueFiSH ?! 22:15, 14. Okt 2005 (CEST) Gemeint war wohl in der 'deutschen' Übersetzung adm2nd. Diese Frage - zusammen mit den mit der Typisierung verbundenen Mühen - würde sich aber erübrigen, wenn man Variante 2 wählen würde. Frage an sk: Haben Sie schon einmal versucht, Koordinaten-Artikel anstelle mit type mit Kategorien zu extrahieren, um z.B. KML zu generieren? Bei einem Projekt rund um den Prototyp www.geometa.info hat's jedenfalls schon einmal funktioniert? -- Geonick 15. Okt. 2005 (CEST)Antwort auf die Frage sie Eintrag oben, von gerade eben. -- sk 13:49, 16. Okt 2005 (CEST)Neue Koordinaten aus en für Google Earth

Hallo Leute, ich hab mal den letzten Dump der englischsprachigen Wikipedia nach Koordinaten durchforstet. 27894 Koordinaten sind mir untergekommen, die brauchbar waren. Leider nutzen die dort kaum die Attribute "type" und "region", weshalb ich nicht so eine schöne Struktur hinbekommen habe, wie bei der KML-Datei aus der deutschsprachigen Wikipedia. Meiner Meinung nach zeigt das Konzept der strikten Nutzung von type und region in der deutschensprachigen Wikipedia seine Vorzüge, wenn man, wie ich es jetzt getan habe, die Koordinaten zusätzlich mit den vorhandenen Kategorien feinsortiert. In manchen Kategorienbereichen ist das sehr einfach. In anderen Bereichen sollten wir versuchen eine gleichförmige Struktur der Kategorienamen. Z.B. Kategorie:Kirchengebäude in Berlin und Kategorie:Pariser Kirchengebäude sollten auf "Kategorie:Kirchengebäude ..." vereinheitlicht werden, um eine einfachere Nutzung zu ermöglichen. (Ähnliches Problem hatten wir auch schon mal bei den Eishockespielern.) Was mir noch positiv aufgefallen ist, ist die konsequente Verwendung der Vorlagen " ... Artikel" und "...Text", die dazu führen, dass zwar in z.B. Personenartikel evt. Koordinaten verwendet werden können, aber diese sehr leicht rausgefiltert werden können. Negativ aufgefallen ist mir die Vorlage:Bergtabelle Koordinaten, die unsere Vereinheitlichungsbestrebungen torpediert. Wir versuchen alle Koordinaten mit "{{Koordinate ..." beginnen zu lassen, um sie leichter aus dem Datenbankdump filtern zu können und dort wird es wieder anders gemacht. Hoffentlich können wir das noch umbiegen. So das wärs erst mal so weit von mir. Ach ja die Webseite zum download. -- sk 21:39, 16. Okt 2005 (CEST)

Kategorie:Kirchengebäude in Berlin und Kategorie:Pariser Kirchengebäude sind beides Unterkategorien von Kategorie:Kirchengebäude. Wenn man die Kategorien ernsthaft nutzen will, wird man die Hierarchie wohl eh auswerten müssen. --Fuzzy 23:57, 16. Okt 2005 (CEST)Type-Kategorien (adm1st, adm2dn, city)Die Kategorien anstelle type zu nutzen ist genau mein Vorschlag - aber offenbar will man nicht...? Ich bin auch ziemlich sicher, dass es mit type (und region) funktionieren wird - aber eben: möglicherweise zum Preis der Doppelspurigkeit (bzw. der Integritätsgefährdung) sowie auf Kosten der Mehrfachnutzung, weil type eine Art Oberkategorie ist, die nach bestimmten Kriterien gebildet wurden. Apropos "bestimmten Kriterien": Was sind eigentlich genau die Zuordnungen zu adm1st und adm2nd, etc.?type-Kategorien Def. gemäss Wikipedia D A CH type:country für Länder Deutschland Österreich Schweiz type:state für Staatengebilde, nicht-souveräne Staaten - - - type:adm1st für Bundesländer, Kantone Bundesland, Regierungsbezirk Bundesland Kanton, Halbkanton type:adm2nd für Landkreise, Verwaltungsgemeinde... Landkreis, Samtgemeinde Bezirk Bezirk type:city für Orte Stadt, Ort, alle Gemeindearten Stadt, Ort, alle Gemeindearten Stadt, Ort, alle Gemeindearten

Habe adm2nd verwendet und mir erlaubt, adm3rd hinzuzufügen - schliesslich gibts ja noch Gemeinden... Diese Tabelle könnte man noch erweitern durch diejenigen Länder, in denen ebenfalls deutsch gesprochen wird: F, B, I, PL, CZ. Ich würde gerne mal einen Test machen und fände diese Zuordnung dazu nützlich: Ich wäre daher froh um Verbesserungshinweise. -- Geonick 17. Okt. 2005 (CEST)

Gemeinden sind type:city. Die Frage ist nur, ob für Ämter, Samtgemeinden usw. noch ein Typ benötigt wird. --Fuzzy 22:28, 17. Okt 2005 (CEST)Ok: adm2nd gelöscht und type:city eingefügt. Damit sind offenbar mit 'city' neben Gemeinden auch Städte, Orte und alle Gemeindearten gemeint. -- Geonick 17. Okt. 2005 (CEST)Samtgemeinde ist gemäss Gemeindearten eine der "unterste(n) Stufe(n) im Verwaltungsaufbau eines föderalistischen Staates" und müssten konsquenterweise in city und nicht in adm2nd eingeordnet werden (falls Gemeinden tatsächlich zu city gehören) -- Geonick 17. Okt. 2005 (CEST) Das ist falsch, steht im Artikel Gemeindearten aber auch gar nicht. Der Begriff Samtgemeinde wird dort nur einmal im Zusammenhang mit Einheitsgemeinden erwähnt. --Fuzzy 23:55, 17. Okt 2005 (CEST) Gut; dann ergänze ich Samtgemeinde auf Stufe adm2nd und stelle sie damit neben Landkreis. -- Geonick 17. Okt. 2005 (CEST)Wie ist ein Regierungsbezirk (z.B. Regierungsbezirk Freiburg) einzuordnen? 134.106.146.46 10:14, 18. Okt 2005 (CEST) (=Benutzer:Arcy)Samtgemeinde ist eine "Gebietskörperschaft, die sich aus (...) Gemeinden desselben Landkreises zusammensetzt", also eine "Aggregierung" und wurde daher auf Stufe Landkreis gehoben. Die Beschreibung von Regierungsbezirk scheint ähnlich - nämlich eine Aggregierung von Kreisen desselben Bundeslandes. Demnach müsste man konsequenterweise Regierungsbezirk auf Stufe Bundesland einordnen - oder? -- Geonick 19.10.2005 (CEST)

@Geonick, wenn man wie du vorschlägt nur die Kategorien benutzen würde, hätten wir ein Verschlechterung der jetzigen Situation. Durch die Typangabe kann sehr effizent eine Grobklassifizierung vorgenommen werden, ohne sich auch nur die Kategorien anschauen zu müssen (was sehr aufwändig ist). Ein weiteres Problem bei der Nur-Kategorien-nutzen-Strategie ist die nicht in einer Baumstruktur organisierten Kategorien. Wäre dies der Fall, würde ich sofort deine Strategie umsetzen, aber die Kategorien sind vielfach auch einfach anders organisiert, so das man fast von einem Netz sprechen müsste, welches nur schwer zur Einordnung eines Artikels in eine Hierachrchie nutzbar ist. -- sk 09:12, 18. Okt 2005 (CEST)

sk: "Einordnung in eine Hierachie": Meinst Du damit eine Hierachie für eine bestimmte Software bzw. passt nicht in das "System Google".? -- 134.106.146.46 10:14, 18. Okt 2005 (CEST) (=Benutzer:Arcy)Ich meine hierarchische Ordnung in Baumstruktur. In den meisten Softwarprodukten werden große Daten über eine Baumstruktur gegliedert. Ich meine nicht speziell Google Earth, aber dort sieht man es sehr gut. Man muss sich dort entscheiden in welchem Ast der Baustruktur man den Artikel einsortieren möchte. Wenn ich aber mehrere Kategorien in einem Artikel habe stehe ich wieder vor einem Entscheidungsdilema, welches nur durch eine grobe Vorsortierung gelöste werden kann. -- sk 11:01, 18. Okt 2005 (CEST)Ich finde es sehr ungünstig, dass in der Wikipedia fast nicht zwischen Gemeinde und Ort getrennt wird. So landet für Deutschland beides munter durcheinander in Kategorie:Ort in Bundesland. Orte sind Orte, Gemeinden sind Verwaltungseinheiten die mitunter aus einem Ort, oft aber auch aus einer Vielzahl Orten bestehen können. Ich denke das sollte man schon trennen. Aktuell ist der Großteil der Wikipediaartikel hierzu auf Gemeinden zugeschnitten, aber es gibt ebenso auch zahlreiche Artikel zu Orten, die nur Gemeindeteile sind. Das type-System, das nur die Hierarchienummer der Gebietseinheiten erfasst (also Gebiet erster Ordnung unterhalb der Staatsebene etc.) ist auch leicht willkürlich, wenn man ein adm1st in China und ein adm1st in sagen wir Nauru vergleicht. Darüber sollte zumindest noch mal nachgedacht werden. --::Slomox:: >< 19:59, 18. Okt 2005 (CEST)@sk: Nehmen wir das Beispiel "Zürich". Dies ist eine mehrdeutige Bezeichnung für Stadt, Gemeinde und Schweizer Kanton. Ohne weitere Angaben ist meist die Stadt gemeint. D.h. die Einstufung als type:city ist nicht falsch aber es ist nicht hinreichend. Dass type:city auch für Gemeinden verwendet wird, stellt Zürich demnach auf dieselbe Stufe wie Wiedenborstel (D) mit offenbar 6 Einwohnern... Noch 'schlimmer': Alle weiteren Charakterisierungen von Zürich (z.B. Hauptort) sind ausgeschlossen. Es ist nun nicht verwunderlich, dass ein Grossteil der Fragen zu type ein Gerangel um dessen Definitionen ist, denn es ist offensichtlich, dass eine einzige Einteilung von eigentlich mehreren Eigenschaften eines "Objektes" nie allen Bedürfnissen gerecht werden kann.Auf der anderen Seite haben wir die Möglichkeit, mehrere Kategorien pro Artikel zu vergeben und diese je nach Kommunikationsziel (wie die Kartographen sagen) auszuwählen. Dank der echten Hierarchisierung von Kategorien (im Ggs. zu type, wo dies nur mit adm1 -> adm2 -> city der Fall ist) kann man diese sogar wenn nötig zusammenzufassen.Mehrere Kategorien sind wie Attribute, die ein Objekt "Zürich" beschreiben. Das ist doch für die Erfassung eine Erleichterung und für die Darstellung (bzw. Auswahl) ein Vorteil! Wer nun mittels Kategorien (sinngemäss) z.B. alle Artikel mit Kategorie Stadt, Ort oder Gemeinde selektiert (wie die Datenbänkler sagen), sollte dasselbe erhalten wie mit type:city - mit dem Unterschied, dass derjenige, der nur Hauptstädte haben will, diese über eine entsprechende Kategorien-Abfrage ebenso erhält. Mit type ginge das umgekehrt nie - ausser jemand käme auf die verrückte Idee, die type-Angaben aller betroffenen Objekte je nach Zweck von Hand umzustellen... Ich bin beileibe nicht begeistert von allen Kategorien, die in Wikipedia real existieren: diese müssen sicher noch verbessert werden. Genauso klar ist aber, dass eine parallele Kategorisierung, wie dies type darstellt, erst dann gewählt werden sollte, wenn Kategorien ihren Zweck nicht erfüllen. In dem Sinne finde ich obengenannte Tabelle nützlich und bin froh um jede sachdienlichen Hinweis oder Frage. -- Geonick 19.10.2005 (CEST)Externer Geodaten-/Karten-ServerExterner Geodaten-/Karten-Server passend zu Koordinaten-Datenbanklinks

Der Hintergrund meiner Aktivitäten hier ist, dass ich mir überlege, etwas Ähnliches wie kvalebergs-Server anzubieten (Commons natürlich) - nur besser... Ich schlage vor bewusst einen eigenen Server einzusetzen (und diesen auch anzubieten) ganz im Sinne einer echten externen (GIS-)Datenbank, was ja die Idee hinter Datenbanklinks ist (vgl. ISBN, Fische, etc.). Dort könnte man auch KML-Links anbieten, Online-Karten via WMS, etc. Meine Hauptfrage dazu ist aber: 1. Ist so was erwünscht? 2. Was wollen wir eigentlich für (Karten-)Dienste zu Wikipedia-Artikel? und dann 3. Wie könnte ein solcher externer Karten- und Geodaten-Server heissen? Ich möchte alle einladen, hier mit zu diskutieren... -- Geonick 19.10.2005 (CEST)

1.) Gute Idee 2.)Visualisierung von Artikeln - Auswahl nach Kategorien - Darstellung aller Unterkategorien einer Kategorie - Darstellung nach Länder, Regionen etc. basierend auf Google Maps ? (da +/- "frei" verfügbar) 3.) Wikimaps Arcy 20:55, 19. Okt 2005 (CEST)zu 1.) Grundsätzlich gute Idee zusätzlichen Service anzubieten. Aber Kvalebergs-Service entfällt ja, sobald die Seite in die Mediawiki implementiert ist. zu 2.) Karten, die alle Umgebungsartikel aufzeigen und anklickbar machen. 3.) Bitte nicht Wikimaps, da dieser Name schon vom internen Projekt genutzt wird. -- sk 21:16, 19. Okt 2005 (CEST)

Zu 1.) Kommt Kvalebergs-Erweiterung wirklich? Ich glaube kaum in dieser Form, denn die Bandwurm-URL-Syntax ist schlicht nicht HTTP/URL-konform. Der Dienst sollte sich zudem entweder auf die Koordinate konzentrieren oder aber alles nützliche aus dem Artikel selber ausnutzen - z.Zt. fehlt z.B. der Name des aufrufenden Artikels und die Darstellung der externen URLs ist textlastig und länglich. Und ganz wichtig: Es darf Wikipedia nicht 'belasten'; Daher die Idee mit dem externen GeonamenDB-Service ganz im Sinne der Datenbanklinks.
Zu 2. Ich stelle zwei Grundbedürfnisse/Hauptfunktionen fest: Einerseits Wikipedia-Artikel räumlich darstellen/verorten (inkl. Nachbarn und die Möglichkeit wieder in Wikipedia weiter zu recherchieren) und andererseits andere Dienste via direkte URLs/Links zu nutzen, um mehr über einen (in Wikipedia gefundenen) Ort oder eine Sehenswürdigkeit zu erfahren. Die Konzentration auf Punktkoordinaten wäre eine weitere selbstauferlegte Beschränkung. Die Kvaleberg-Erweiterung deckt z.T. Letzteres ab während www.opengeodb.de ersteres anbietet. Opengeodb ist aber eher auf Datenerfassung ausgerichtet und weniger auf (Such-)Dienste; dann ist es nicht Wikipedia-spezifisch und die URL lässt auf leise Kommerzialisierung schliessen.
Zu 3.) Ich suche einen Namen, der obige zwei Hauptfunktionen wiedergibt; die Frage ist, ob der Name deutsch klingen soll und damit unsere Fokussierung betont - das hätte den Vorteil, die Sache dann unseren englischen Freunden übergeben zu können, bzw. nahtlos in ein übergeordnetes Projekt einfliessen zu lassen ohne die eigene Seite gleich aufgeben zu müssen. -- Geonick 20.10.2005 (CEST)

zu 1.: Die Wikipedia darf schon belastet werden, wenn der Nutzen im entsprechenden Verhältniss dazu steht. Wenn du ganzes Kartenmaterial erfolgreich anbieten willst brauchst du meiner Meinung nach skalierbare Server die man als Privatmann kaum stemmen kann. Außerdem schafft ein Wikimedia-Server vertrauen, schließlich sollen möglichst viele Leute Arbeit dort investieren. Und auch in der Wartung und Erweiterung wäre dann nicht nur einer allein beteiligt.zu 2.: Alles was mehr als nur einfache Punktkoordinaten wäre (z.B. die Kontur eines Sees oder von Berlin) , würde die Wikipediaartikel überlasten müßten also wirklich getrennt in der DB stehen und nur in der WP verlinkt sein.4: Es geht nicht nur um einen Server, sondern auch die Clientensoftware muß etsprechend Leistungsfähig sein, schließlich sind die Leute mittlerweile etwas verwöhnt.5: Für die Wikipedia wären historische Karten wichtig (Wanderung der Vandalen oder Ausdehnungen des Römischen Reiches.) Also insgesamt bin ich eher skeptisch, halte die Diskussion aber für sinnvoll und will auch niemanden bremsen. Kolossos 20:19, 20. Okt 2005 (CEST)

Kolossos: Wir sind uns weitgehend einig bis auf einen zentralen Punkt, wo wir uns möglichst klar werden und unsere Prioritäten setzen sollten:

Es geht hier (mir) nicht um das Anbieten von eigenem Kartenmaterial! Das gehört m.E. ins Projekt Wikiatlas oder Wikimaps. Es geht a) um einen "räumlichen Navigations-Webdienst", einer Visualisierung von georeferenzierten Wikipedia-Artikel (=Hauptfunktionsgruppe 1) sowie b) um Möglichkeiten, mehr über diesen Ort zu erfahren mittels 'direkten Links/URLs', was funktional ähnlich wie die Kvalebergs-Extension ist, nur umfassender (=Hauptfunktionsgruppe 2). Hauptfunktionsgruppe 2 ist vielleicht noch etwas erklärungsbedürftig: Da hinein gehören m.E. Funktionen, wie Google Earth KML-Links oder aber Aufrufe von Webdiensten, die nicht Koordinaten sondern z.B. PLZ verlangen. Für das "Umrechnen" von Koordinaten zu PLZ kommen dann Daten à la opengeodb.de, bzw. eben eine GeonamenDB ins Spiel. Für Hauptfunktionsgruppe 1 muss natürlich eine Basiskarte her sowie ein "leichtgewichtiger" Online-Karten-Client. Für beides bietet sich Google Maps an, es käme aber auch ein WMS-fähigen MapServer mit einem Browser-Client (in JavaScript, SVG oder Flash) in Frage. Das periodische Indexieren der Wikipedia-Artikel (Index, KML) sowie allfällige Anfragen scheinen mir schon einen externen Webdienst zu rechfertigen.

Die Idee einer GeonamenDB/GeoWikiDB wurde übrigens schon angedacht und es muss jetzt nicht sein, dass die zu findende Wiki...de-Adresse unter meinem Namen laufen muss. Ich könnte jedoch evtl. von einer Hochschule aus das Hosting anbieten und bin nun daran für das Sommersemester 2006 das Thema vorzubereiten. Bis dahin gibt es für euch noch nichts zu tun ausser Wikipedia-Artikel zu verorten und mit Kategorien (oder halt types) versehen... :-> sk würde ich gerne einladen, seine Konversions-Skripts auch hier zur Verfügung zu stellen.

korrigiert mich bitte, wenn ich falsch liege, aber ist es nicht schon längst geplant, kvaleberg in die wikimedia-welt zu integrieren und das kvaleberg außerdem nur als test-server läuft? Schaengel89 @me 19:59, 30. Okt 2005 (CET)Genau so ist es. Hr. Kvaleberg hat auch vor einiger Zeit auf dieser unserer Seite geschrieben, dass er nicht genügend Unterstützung hat, dass es mal ein Entwickler in MediaWiki integriert. --BLueFiSH ?! 20:16, 30. Okt 2005 (CET) Hallo Bluefish, Du hast die Seiten doch archiviert. Könntest Du den Link dazu hier reinsetzen. Ich find ihn oben in deiner Archivübersicht nicht. 134.106.146.46 12:47, 31. Okt 2005 (CET)Name für gesucht für externen Geo-Webdienst über und mit verorteten Wikipedia-Artikel

Hier noch meine Vorschläge für einen Namen: wikigeodb, geowikidb, wikiplanet, wikiplaces, ... -- Geonick 21.10.2005 (CEST)

Eure Meinung dazu ist mir wichtig: Vgl. dazu die Diskussion zu den Funktionen unten mit Begründung, warum es einen externen Geodatenbank-gestützten Geo-Webdienst braucht. -- Geonick 01:34, 24. Okt 2005 (CEST)

Stimmungsbild zu den FunktionenHauptfunktionsgruppe dafür dagegen egal 1 Karte mit Artikel im Zentrum plus Nachbarn Alle Nachbarn im Ausschnitt dargestellt --Geonick, Arcy, Simplicius - - 1 Karte wie oben, eingeschränkt nach Kategorie Geonick, Simplicius, Arcy - - 2 Liste mit KML-Export-Fn. (nach type/Kategorien) Geonick, KML ist gut -- Simplicius kann in einem zweiten Schritt erfolgen -- Arcy - 2 Liste v. Webdiensten (Koor., PLZ, Ortsname) Geonick - -

Habe mir erlaubt, mich selber schon mal einzutragen. -- Geonick 21.10.2005 (CEST)

Habe mir erlaubt, Tabelle sinngemäss anzupassen und eure Voten zu übernehmen. Nach der Diskussion unten zur Umkreissuche ist mir nun klarer geworden, wie vor allem die Hauptfunktionsgruppe 1 aufgerufen werden könnte:

Aufruf mit Wikipedia-Artikel. Aufruf mit WGS84-Koordinate und (optional) Ausschnitt (spn=...) oder (optional) Massstab (z=0..10). Aufruf mit beliebigem Ortsnamen oder mit beliebigem PLZ.

Alle jeweils mit optionaler type/Kategorie(n)-Angabe als Einschränkung (hat für mich 2. Priorität). In allen Fällen wird zuerst eine Karte dargestellt (= Hauptfunktionsgruppe 1). Der Benutzer kann dann nachträglich interaktiv umschalten auf eine Liste der nächstgelegenen Wikipedia-Artikel (= Hauptfunktionsgruppe 2a). Denkbar wäre auch, Funktionen anzubieten, die den aktuellen Ausschnitt als KML- oder GPX-Wegpunkt ausgeben (= Hauptfunktionsgruppe 2b). Dabei ist zu beachten, dass die Angabe mit Ortsnamen oder PLZ oft mehrdeutig ist oder aber keinen Treffer ergibt. Geonick 01:22, 24. Okt 2005 (CEST)

Umkreissuche (= weitere Anwendungsfälle)Eine Umkreissuche fände ich nicht schlecht, also man gibt Koordinaten an und sagt "zeige mir alle Artikel in 15 km Umkreis um diese Koordinate x,y". Da man das Ergebnis vielleicht nicht nur als Liste, sondern auch als Karte darstellen würde, also rechteckig, würde ein select ausreichen zum Beispiel mit Breite>x-1 Minute, Breite<x+1 Minute, Länge>y-1, Länge<y+1 - mathematisch haut das grob hin. Das käme einer Idee aus dem Galileo-Projekt "laut GPS bin ich hier, wo sind die Sehenswürdigkeiten" sehr nahe. -- Simplicius ☺ 01:51, 23. Okt 2005 (CEST)Bei der Darstellung als Karte von verorteten Artikeln wäre die Umkreissuche ja implizit gegeben für soviele "Umkreise" wie es im Kartenausschnitt Platz gibt (daher mein Kommentar in der Tabelle oben). Ist das in deinem Sinne? Interessant auch dein Hinweis auf meta:GALILEO_Masters_2004. Dort steht: "Der Benutzer erhält dann alle Artikel (...) zu den aktuellen Geo-Koordinaten von Wikipedia (...).". Im Unterschied, bzw. als Ergänzung zur Diskussion hier, erfolgt der Aufruf dort offensichtlich über eine (beliebige) Koordinate gemäss Benutzer-Eingabe oder einer PDA-Software. Beim vorliegenden Vorschlag hier bin ich davon ausgegangen, dass der Aufruf von einem verorteten Wikipedia-Artikel ausgeht. Alle diese Anforderungen (ausser der Aufruf von einer Seite mit Webdiensten mittels Artikel und Koordinaten, a la Kvaleberg's Erweiterung) führen übrigens zu einem Webdienst, der ausserhalb von Wikipedia ist (vgl. meta:Image:GALILEOArchitecture.png). Wichtig scheint mir nun, zwei weitere Anforderungen, bzw. Anwendungsfälle einzuführen, welche die Hauptfunktionsgruppen ergänzen: Ausgehend von einem verorteten Wikipedia-Artikel (evtl. via Kvaleberg's Erweiterung), Aufruf des zu schaffenden Webdienstes (Parameter: Artikel-Name plus (optional) lat/lon (WGS84)). Ausgehend von der zu schaffenden Webdienst-Seite, Benutzer-Eingabe von lat/lon (Parameter: lat/lon optional Ausschnitt oder Massstab analog Google Maps (spn- und z-Parameter)). Das eröffnet zudem die Möglichkeit, den Webdienst-Ausschnitt als Bookmark zu speichern sowie in Kvaleberg's Erweiterung und v.a. externen Programmen einzubinden, z.B. PDAs gemäss GALILEO-Idee. Dank der geplanten GeonamenDB im Hintergrund (die ja v.a. von Wikipedia gespiesen würde, vgl.meta:Image:GALILEOArchitecture.png) wären auch weitere Aufrufmöglichkeiten denkbar, z.B. mittels beliebigem Ortsnamen oder einer PLZ. In allen Fällen wäre die default-Anzeige eine (Welt-)Karte und das Resultat des Aufrufs wäre im ersten Falle eine Anzeige als "Karte aller Artikel im Ausschnitt mit aufrufendem Artikel im Zentrum" und im zweiten Falle "Karte aller Artikel im Ausschnitt mit GPS-Symbol im Zentrum" (vgl. Tabelle oben). -- Geonick 00:27, 24. Okt 2005 (CEST)Verhampelter Zufallsfund

Hallo Ihr, bei Linz wird die Koordinate, die eigentlich wohl ganz o.r. platziert sein sollte, momentan äußerst unschön über der roten Karte innerhalb der Townbox angezeigt. Woran liegt's? Bitte nachschauen und korrigieren, habe ich gerade keine Lust zu. Danke sagt :Bdk: 02:26, 18. Okt 2005 (CEST)

Das liegt an der div-townbox. ca 11 Artikel haben eine Formatvorlage in dieser Form. Ich habs mir schon auf meine todo geschrieben diese townboxen entsprechend der Wikipedia:Formatvorlage Stadt umzubauen, aber ist mühselig und so ;-) naja vielleicht mach ichs doch mal bevorzugt, das andere ist ja nicht so kritisch wie dieses. --BLueFiSH ?! 06:42, 18. Okt 2005 (CEST) Oh, fein :-) --:Bdk: 06:45, 18. Okt 2005 (CEST) Ähnlich ist es bei Döbling. Könnte sich vielleicht ein Experte darum kümmern? Vielen lieben Dank im Vorraus. --Geiserich77 17:48, 21. Okt 2005 (CEST) Das ist die andere Spielart des im Prinzip gleichen Problems wie oben geschildert. Aber da gibts noch hunderte, wenn nicht gar tausend veralteter Formatvorlagen in Artikeln. Die zu korrigieren hilft mir grad Schaengel89. Im Archiv gibts dazu auch ein paar Einträge, die das Problem näher erläutern. --BLueFiSH ?! 18:36, 21. Okt 2005 (CEST)Vermerk für gewünschte Koordinate?

Ist es ok, wenn ich einen Baustein {{Koordinatenwunsch}} mache, mit einer entsprechenden Kategorie, damit das dann abgearbeitet werden kann? -- Simplicius ☺ 13:02, 22. Okt 2005 (CEST)

Der hat dann aber sonst keinen weiteren Ausgabetext, oder? (Dann reicht das aber auch theor. nur als Kategorie-Eintrag) Also ich find die Idee gut und würd mich auch mit um die Abarbeitung kümmern. wobei der Name {{Koordinatenwunsch}} allerdings überdacht werden sollte, da dann in den SQL-Abfragen neben den normalen Vorlagen auch Artikel mit dieser Vorlage auftauchen... --BLueFiSH ?! 13:10, 22. Okt 2005 (CEST)Zum Pkt. 1: kein Ausgabetext im Artikel, nur eine Kategorie zu sehen. Zum Pkt. 2: guter Hinweis, Danke. Wäre {{Verortung}} ok? -- Simplicius ☺ 14:48, 22. Okt 2005 (CEST)Unter Verortung kann sich sicher niemand was vorstellen, vllt. {{GeografischeLageGesucht}}. Geograf.Lage ist ja auch immer der Text in den Formatvorlagen... --BLueFiSH ?! 15:05, 22. Okt 2005 (CEST)Wie wäre es dann mit {{Lage}}? Sollte immer so kurz sein, dass man sich nicht vertippen kann.-- Simplicius ☺ 15:14, 22. Okt 2005 (CEST)naja, an sowas ganz kurzem wäre mir wieder nicht erkennbar, wozu die Vorlagen dienen sollte (und dann kommen wieder Löschheinis und wollen die entfernen ;-). Muss ja nicht gleich heute eingeführt werden, man kann ja noch auf weitere Vorschläge warten. --BLueFiSH ?! 16:01, 22. Okt 2005 (CEST)Leg doch einfach unter Wikipedia:WikiProjekt Georeferenzierung eine Liste an, in der du die Koordinatenwünsche einträgst. Warum braucht es da eine Vorlage? --Fuzzy 16:10, 22. Okt 2005 (CEST)Dann nehmen wir doch einfach {{Lagewunsch}} für Kategorie:Geografische Lage gewünscht und {{Lagewunsch/NRW}} für Kategorie:Geografische Lage gewünscht (NRW) das sollte auf's Erste passen. Ich habe die TOPO 50 NRW auf meinem Rechner, um diese Artikel kann ich mich dann insbesondere kümmern. Löschantrag gibt's auch schon. -- Simplicius ☺ 16:23, 22. Okt 2005 (CEST)KoordinatenvorlageNoch mal an eine kurze Frage an die Erschaffer der Koordinatenvorlage: Ist {{Koordinate Artikel|51_25_40_N_07_11_39_E_type:landmark_region:DE-NW|51° 25' 40" N, 07° 11' 39" O}} als Baustein in NRW so korrekt? -- Simplicius ☺ 18:53, 22. Okt 2005 (CEST)Kann da nix falsches dran erkennen. Wenns "Koordinate Text Artikel" ist, wäre nur noch   wünschenswert. und bei Städten natürlich type:city bzw. type:city(pop). Das Zeichen ′ wäre auch noch ein Tick besser als ' (ist in der Sonderzeichenleiste enthalten) --BLueFiSH ?! 19:27, 22. Okt 2005 (CEST) an BLueFiSH: ist das ein abostroph oder ein anführungszeichen? wo ist das auf einer windows-tastatur? Schaengel89 @me 21:48, 22. Okt 2005 (CEST) Das ist der Apostroph, siehe auch Wikipedia:Typografie#Weitere_Zeichen. --BLueFiSH ?! 23:03, 22. Okt 2005 (CEST)Karte der Wikipedianer

Es mag etwas off-topic erscheinen, aber ich wollte die Koordinaten-Gurus mal auf diesen Eintrag hinweisen. Die Idee dazu stammt von hier. Jeder ist herzlich eingeladen, "seinen" Punkt hinzuzufügen, die Bedienung sollte für euch kein Problem sein. Sobald noch ein paar Punkte hinzugekommen sind (hoffentlich überdecken sie sich nicht zu 100% in Mitteleuropa ;-) ), plane ich eine Verschiebung in den Wikipedia-Namensraum.
Ein weiterer Punkt betrifft die Frage, ob man die Vielzahl von Ortslagekarten nicht nach einem ähnlichen System durch eine leere plus einen Punkt ersetzen könnte, dass würde die Zahl derartiger Bilder drastisch reduzieren. Dazu interessiert mich eure Meinung. --Schwalbe ^Disku 12:02, 25. Okt 2005 (CEST)

Ich find die Idee nett. Hab mal eine Tabelle und einen Punkt für München hinzugefügt (2 Pixel abgezogen, trifft nach Augenmaß so einigermaßen). Hier sind übrigens die Pendants dieser Karte in den anderen Sprachversionen: es:Wikipedia:Mapa_de_wikipedistas fr:Wikipédia:Cartographie des wikipédiens pl:Wikipedia:Atlas wikipedystów sr:Википедија:Карта википедиста Ein mögliches Problem bei den dynamischen "Lage von <Punkt> in <Land>"-Karten sehe ich darin, dass das nur für die Online-Wikipedia problemlos klappt - bei gedruckten Artikeln, auf der CD/DVD usw. machen solche Grafiken möglicherweise Probleme, oder? --Neitram 15:12, 25. Okt 2005 (CEST) Guter Punkt - zumindest im Artikel-Namensraum ist die Idee damit wohl unbrauchbar. Schade --Schwalbe ^Disku 16:39, 25. Okt 2005 (CEST)Eine ähnliche Lösung, die mit Koordinaten arbeitet, habe ich mit der Point-Mapping Extension (siehe auch GISWiki) entwickelt. Arcy 15:15, 25. Okt 2005 (CEST)

Alternativ könnte man auch die Technik der Georeferenzierung nutzen. Und auf den Benutzer- oder Stammtischseiten einfach sowas eintragen.

{Koordinate Artikel|51_25_40_N_07_11_39_E_type:Wikipedia-User:DE-NW|51° 25' 40" N, 07° 11' 39" O}

Der Rest könnte dann wie gehabt in sowas wie GoogleEarth extrahiert werden. Vorteil: Zoombarkeit.Kolossos 18:04, 25. Okt 2005 (CEST)

Mmh, liefert mir GoogleEarth auch eine Punktwolke aller so gekennzeichneten Artikel auf einer Karte? --Schwalbe ^Disku 18:41, 25. Okt 2005 (CEST)funzt aber nur mit windows (Windows 2000, Windows XP) Arcy 19:34, 25. Okt 2005 (CEST)@Schwalbe:Die Punktwolke wird schon in Google-Earth angezeigt (zur Info siehe http://www.webkuehn.de/hobbys/wikipedia/geokoordinaten.html www.webkuehn.de) @Arcy: Das Problem mit den hohen Hardwareanforderung ist mir bekannt.

Alternativvorschlag um doch etwas detailiertere Informationen zu bekommen, würde ich zwei Karten vorschlagen, eine Weltkarte für die wenigen brasilianischen Bearbeiter der deutschen Wikipedia und eine D/A/Ch-Karte für den großen Rest. Kolossos 20:45, 25. Okt 2005 (CEST)

@kolossos das ist kein hard- sonderen eine softwareanforderung. google earth ist nicht für freie betriebssysteme ausgelegt. -- Arcy 21:18, 25. Okt 2005 (CEST)

Am einfachsten kann eine zoombare karte mittels der nutzung von google maps und dem dazuladen einer xml-datei erreicht werden.

http://www.google.com/apis/maps/documentation/data.xml http://www.google.com/apis/maps/documentation/#Using_XML_and_Asynchronous_RPC_A

Arcy 21:27, 25. Okt 2005 (CEST)

Das ist natürlich eine gute Sache. Off-Topic ist es insofern nicht, als dass es alle möglichen Anwendungen gibt, sobald Artikel verortet sind - also auch Benutzer-Artikel! Vorlage 'Koordinate Artikel' genügt - den Rest erledigt eine Software gemäss Hauptfunktionsgruppe 1. Und wer noch eine schöne druckbare Karte machen will, kann den 'Computeroutput' aus Hauptfunktionsgruppe 2 nehmen und von Hand 'nachbessern'. Google Maps ist Ok aber irgendwann wird die XML-Datei zu gross und das Problem der 'Punktwolken' ist nicht gelöst. Clevere Programme (wie u.a. der UMN MapServer) können das potentiell besser und zwei Karten braucht es auch nicht; das ist genau Teil des Kartenservices, der hier zur Diskussion steht. -- Geonick 21:49, 25. Okt 2005 (CEST)

Vielen Dank allen Mitdiskutanten und Helfern. Ich habe die Karte jetzt nach Wikipedia:Weltkarte der Wikipedianer verschoben. --Schwalbe ^Disku 16:27, 31. Okt 2005 (CET)

Dynamische KML-Datei

Um das leichte Chaos in der KML-Datei von [[Benutzer:Stefan Kühn] einzugrenzen , dass entsteht wenn alle Städte in Deutschland aktiviert sind, wurde das ganze über PHP und MySQL so programmiert, dass nur noch die 60 größten Stadte im Blickfeld angezeigt werden. Also, das ganze steht erstmal. Einfach den kmz-Netzwerkordner downloaden. Der Rest sollte dann funktionieren. Zur Zeit enthält die Datenbank 7.200 Einträge.

Was man noch tun könnte?

Internationalisierung: Nutzer kann sich mehrere WP auswählen. unterschiedliche Symbolgrößen für die Städte in Abhängigkeit der Einwohnerzahl. Einstellmöglichkeit, ob man mehr oder weniger als 60 Städte auf einmal sehen möchte.

Vielleicht geht das ganze ja schon in Richtung des oben angesprochenen Geoservers. Auf jeden Fall würde mich mal eure Meinung interessieren.Kolossos 16:50, 26. Okt 2005 (CEST)

Meinungsbild der Wikipedianer einholen

Zum Thema Visualisierung der Wikipedia in Karten sollten wir IMHO zusätzlich mal ein Meinungsbild der User einholen. Wir diskutieren hier innerhalb eines recht kleinen Kreises und nahezu ohne Feedback von ausserhalb. Vielleicht würden auch entsprechende Postings in einschlägigen Projekten und Portalen weiterhelfen. Arcy 19:57, 26. Okt 2005 (CEST)

Na, ich denke ein Meinungsbild wäre etwas zuviel, wer das ablehnt braucht sich ja nicht einzutragen. Zum Rest natürlich Zustimmung. --::Slomox:: >< 19:18, 27. Okt 2005 (CEST)Das kann sicher nicht schaden. Ich frage mich nur, ob wir im tatsächlich noch kleinen Kreis genügend vorbereitet sind, was wir unter Visualisierung der Wikipedia verstehen und was nur schon hier eine Mehrheit will: Die einen sprechen von allen möglichen Artikeln, die in Google Maps-Karten (oder als KML-Export) dargestellt werden (= Karte), die anderen sind mit Wikipedia-Benutzer zufrieden oder schränken sich auf die paar type-Kategorien ein (= Karte mit Selektion). Wieder andere möchten Umkreissuche (= Liste). Dann wieder andere freie Atlanten (= schöne Grafik)... Darum habe ich versucht, ein Stimmungsbild zu den Funktionen einzuholen. -- Geonick 21:39, 27. Okt 2005 (CEST)Statt einem Meinungsbild würde ich ein weiteres BrainStorming vorschlagen. Ich könnte mir zum Beispiel vorstellen, daß Biologen die sich bis jetzt nicht für Georef. interessiert haben von einem System begeistert sein könnten, bei dem für jede Pflanzenart von verschiedenen Leuten auf der Welt ca. 1000 konkrete Standorte in ein Wiki-System eingegeben werden könnten und sich somit eine Karte mit den Verbreitungsgebieten der Pflanzen zeichnen ließe. Historiker oder Geologen haben bestimmt wiederrum andere Wünsche. Aber sowas wird man in einem Meinungsbild niemals erfahren. Kolossos 16:19, 31. Okt 2005 (CET)Geokoordinaten in Berlin

Die Geokoordinaten von Sehenswürdigkeiten in Berlin lassen sich besonders leicht mit http://www.berliner-stadtplan.com ermitteln - zu einem eingegeben Straßennamen+Hausnummer wird eine Karte aufgeblendet, auf der nahezu alle Sehenswürdigkeiten bereits enthalten sind, und es wird ein Zielkreuz eingeblendet, mit dem man über die Karte fahren kann, wobei darüber die exakte Koordinate innerhalb des Bildes im GPS/WGS System angegeben wird (allerdings in nautischer Kodierung). Viel Spass. GuidoD 02:03, 31. Okt 2005 (CET)

Diese war auch die Seite mit der ich einen Großteil der Berlin-Einträge im Juli ergänzt habe. nebenbei auch sehr hübsche und gut bedienbare Kartendarstellung von Berlin, wüsste keine Bessere ;-) --BLueFiSH ?! 03:41, 31. Okt 2005 (CET) Schoen ja, aber mein Lob ist eingeschraenkt, weil die Darstellung aus Autofahrer-Sicht schlicht irrefuehrend ist - hab mir gestern mal die Umgegend meines Wohnorts Berlin-Adlershof angeschaut, und geschaetze 40-50 Fehler bei Strassenführungen entdeckt. Aber gerade hinsichtlich Sehenswürdigkeiten und Einrichtungen der Infrastruktur findet man nirgendswo im freien Internet was besseres, m.E.n. GuidoD 13:47, 31. Okt 2005 (CET)Fehler in den Koordinaten der Artikel bei uns oder Fehler in der Darstellung dort? --BLueFiSH ?! 14:40, 31. Okt 2005 (CET) *lach* die Koordinaten sind absolut korrekt, es geht nur um Darstellungsdetails dort, die einen irritieren koennen - ich wuerde einfach niemandem empfehlen, sich einen Anfahrtsplan nach jenem Kartenmaterial zusammenzubauen. Sozusagen, das Ziel mag in der Karte richtig liegen, aber die anliegende eingezeichnete Strasse ist nicht nutzbar. Besonders häufig sind reale Sackengassen einfach bis zum naechsten Strassenzug verlaengert worden. Einen Fussgaenger mag das nicht stoeren, der schlaegt sich dann halt durch die Buesche, aber als Routenplan ist das voellig ungeeignet. GuidoD 15:19, 31. Okt 2005 (CET)Eure und meine Begeisterung für die obige 3D-Darstellung der Berliner Sehenswürdigkeiten war für mich der Anlass mal auszuprobieren ob das die Wikipedia nicht auch könnte. Weil ich kein anderes Programm kennen mit dem sich das umsätzen ließe geht das ganze mal wieder in Richtung GoogleEarth (gähn). Die Bilder stammen aus der Wikipedia, dabei wurde der Himmel transparent gemacht und das Bild etwas hochgesetzt. Für Leute ohne Google Earth gibt es hier einen Screenshoot, ansonsten ist die kmz-Datei zu bevorzugen.Später wäre die Datei ggf. durch einen oben bereits erwähnten Server zu ersetzen, der einen Bilder Upload erlaubt, die kml-Datein dynamisch nur für das Sichtfeld erzeugt und die Sehenswürdigkeiten bei einer bestimmten Entfernung ausblendet damit der Berliner Fernsehturm in der Anzeige nicht bis Lettland reicht. Gebe es daran Interesse? Ich teste das ganze halt eben in jede denkbare Richtung. Kolossos 16:06, 31. Okt 2005 (CET)

type-Kategorien	Def. gemäss Wikipedia	D	A	CH
type:country	für Länder	Deutschland	Österreich	Schweiz
type:state	für Staatengebilde, nicht-souveräne Staaten	-	-	-
type:adm1st	für Bundesländer, Kantone	Bundesland, Regierungsbezirk	Bundesland	Kanton, Halbkanton
type:adm2nd	für Landkreise, Verwaltungsgemeinde...	Landkreis, Samtgemeinde	Bezirk	Bezirk
type:city	für Orte	Stadt, Ort, alle Gemeindearten	Stadt, Ort, alle Gemeindearten	Stadt, Ort, alle Gemeindearten

Hauptfunktionsgruppe	dafür	dagegen	egal
1 Karte mit Artikel im Zentrum plus Nachbarn	Alle Nachbarn im Ausschnitt dargestellt --Geonick, Arcy, Simplicius	-	-
1 Karte wie oben, eingeschränkt nach Kategorie	Geonick, Simplicius, Arcy	-	-
2 Liste mit KML-Export-Fn. (nach type/Kategorien)	Geonick, KML ist gut -- Simplicius	kann in einem zweiten Schritt erfolgen -- Arcy	-
2 Liste v. Webdiensten (Koor., PLZ, Ortsname)	Geonick	-	-