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.
Bitte hols wieder hervor, wenn was nochmal aufgerollt werden soll.
(Wenns hier zu voll wird, versuche ich das thematisch zu archivieren. Kann auch gern jemand anders machen, aber bitte den Sinn dahinter beibehalten.)

Archiv

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 <tt>{{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)

Apostrophierung

Ich wuerde gern die Artikelseite und die kvaleberg copy-n-paste Vorlage auf gerade Apostroph/Gänsefüsschen anpassen - die Sekundenzeichen sind typographisch korrekter, aber in der Browserdarstellung viel zu uneinheitlich. Die Ascii-Striche haben dagegen über die Jahrzehnte eine sinnvolle Darstellung gefunden, und sind in der Verwendung an Stelle der speziellen Minuten/Sekundenzeichen schon längst verbreitet.

Eine verwandte Diskussion gibt es in Wikipedia Diskussion:WikiProjekt_Georeferenzierung/Archiv1#Symbole für Bogenminute und -sekunde, wobei damals noch typisch ohne dazwischenliegendem Extra-Leerraum gearbeitet wurde - Zitat:

die einzig richtigen™ Symbole gibt es hier nicht. Ganz simpler hintergrund: es gibt keine speziellen unicodes dafuer, die fuer ein "nachgestelltes einfaches apostroph" und "nachgestelltes doppeltes apostroph" gelten wuerden. Insoweit kann man sich nur der historischen papiernen typographie annaehern (so man das ueberhaupt will). Über angeschraegt oder nicht braucht man sich da noch nichtmal unterhalten - die diskussionen koennen ewig lang werden. Bei Wikipedia:Typografie#Weitere_Zeichen tendiert man zu den geraden ascii apostroph '/". Das macht auch am wenigsten probleme mit existen schriftschnitten. (auch weil im englischen sprachraum genau diese zeichen lange als zollzeichen herhalten mussten). Sowas wie ’/” koennen viele an ihrer tastatur gar nicht eingeben, und die zeichenfolge 00’00” hat bei mir im monospace einen (korrekten) drall nach links an der zahl, im helvetica-aehnlichen standardschnitt aber ein kerning nach rechts, das mittel-apostroph liegt glattweg über dem linken oberen bogen der dritten null. Tatsaechlich kann dir der typographische kram voellig egal sein, solange du ein einstrich/doppelstrich-aehnliches zeichen nimmst, und die georef angabe mittels einem semantischen markup {koordinate|x} ummantelst. Bei einer drucklegung koennen dann aufgrund der semantischen auszeichnung alle verschiedenheiten der zeichen in der quelle uebergebuegelt werden. Und wenn ich etwas grantig klinge: fass mir ja nicht tausend artikel an, und aendere die apostroph. Was immer irgendwie nach einem einfachapostroph oder doppelapostroph aussieht, sollte erstmal okay sein. GuidoD 01:34, 30. Mai 2005 (CEST)

Umstellung auf gerade Apostroph?

Pro GuidoD 20:10, 31. Okt 2005 (CET)
bin da leidenschaftslos, der schräge Apostroph hat sich halt so eingebürgert, dass das " in diesem Zusammenhang auch der falsche Strich ist, hab ich bisher gar nicht mitbekommen. Was ich als Abart schon mehrfach gesehen habe, war, dass der " mit '' (also zwei mal ') und manchmal sogar als <nowiki>''</nowiki> geschrieben wurde, weil er ja kursiv macht ;-) Das leichtere Eintippen wär natürlich schon von Vorteil. Auf den ′ ändern tu ich es auch nur wenn ich sowieso was im Artikel ändere, sonst juckt es mich nicht. Aufgrund von Wikipedia:Typographie#Weitere Zeichen bleib ich aber neutral in dieser Frage. --BLueFiSH ?! 22:06, 31. Okt 2005 (CET)
Neutral bis Pro Habe mir die Argumente durchgelesen und denke man kann/soll Erfassung und Darstellung strikt trennen (wird auch mehrmals hervorgehoben). Erfassung: bequem erfaßbar, Code gut lesbar, Mehrdeutigkeiten sollten egal sein (sofern durch Software kompensierbar). Darstellung: mir persönlich in diesem Fall egal, soferne es nicht "optimiert" für MS Internet Explorer ist. ;-) Roland2 22:34, 31. Okt 2005 (CET)
Pro --Zubi 11:31, 30. Nov 2005 (CET)
Im Prinzip Pro – ' und " sind jedenfalls besser (und außerhalb Wikipedias gebräuchlicher) als die Varianten ′ und ″ aus den Tiefen der Unicode-Spezifikation, die in der Darstellung (jedenfalls auf Windows-Systemen mit Standardschriftarten) zu horriblen Ergebnissen führen (zumal sie den vorgesehenen Leerabstand nach dem Minuten- und Sekundenzeichen bereits enthalten, was in den Georeferenzierungsrichtlinien allerdings ignoriert wird). Am besten finde ich aber die typographisch korrekten Zeichen – ’ (Alt + 146) und ” (Alt + 148) –, die ich selbst auch immer verwende. (Ich habe hier die jeweiligen Sonderzeichen bewusst in größerer Schrift eingefügt, um die Unterschiede zu verdeutlichen.) --Alib 11:02, 2. Dez 2005 (CET)

It's a wiki. Da keine Ablehnungen auf die "Auf jeder Tastatur zu findenden"-Standard-Striche kommen, "erlaube" ich der Pro-Fraktion die Änderung in vorstehender Seite und einigen Formatvorlagen. ;-) --BLueFiSH ?! 22:00, 2. Dez 2005 (CET)

Vorschlag: Reform der Vorlage

Fragen

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

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

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

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

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

es gibt "type:mountain(hoehe)" wobei hoehe durch die Höhe ersetzt wird -> siehe vorne. Ich schreib die Koordinaten immer einzeilig, mehrzeilig hab ich noch nie gesehen und würde es auch jederzeit auf einzeilig korrigieren. Datenbankabfragen sind dadurch sicherlich einfacher zu machen, weil alle Eintragungen einheitlich sind, PD sind ja auch einheitlich und zwar immer mehrzeilig. Was meinst du mit "Doppelte Koordinatenangabe"? Das eine ist das eigentlich essentielle der Koordinate was zum Kvaleberg-Server geschickt wird, das andere lediglich der Ausgabetext, steht auch vorn erklärt. MfG --BLueFiSH ?! 01:02, 26. Sep 2005 (CEST)

Einmaliges Eintippen und Hilfen: vielleicht gehts mit dem Tool http://www.giswiki.de/hjl_get_CoorM.htm bei GISWiki ja einfacher.
Ein einmaliges Eintippen wäre über eine MediaWiki-Extension durchaus möglich, wird aber zur Zeit nicht unterstützt. Das Tool hjl_get_CoorM.htm (keine MediaWiki-Extension) z.B. verarbeitet die Gradangaben per Javascript und stellt das Ergebnis im gewünschten Format dar. 134.106.146.46 (Benutzer:Arcy) 09:23, 26. Sep 2005 (CEST)

Spezielle Typen: Bisher werden alle Angaben an die GIS-Extension von en:User:Egil (= http://kvaleberg.com/) weitergeleitet (siehe auch Diskussion oben). Solange die Wikipedia diese oder eine andere Extension nicht implementiert, werden wohl auch keine weitere spezielle Typen integriert. 134.106.146.46 09:36, 26. Sep 2005 (CEST) (Benutzer:Arcy)

Vorschlag

Lasst mich bitte mal etwas vorschlagen, ohne dass mich gleich der Türsteher gleich vor die Tür setzt:

Ich finde zwei verschiedene Vorlagen noch immer zu viel. Wofür brauche ich bei Ortschaften einen Eintrag in der Infobox? Einwohner: das sagt mir doch noch was. Geokoordinaten: es sagt mir eh nichts, ob ich da nun 7"60' oder 6"70' habe. Und bei einem Theater oder Sendeturm habe ich diese Angaben dann ja doch nicht in der Infobox - also wozu das? Mein Vorschlag: die Sache mit der Infobox rausnehmen.
Die Eingaben sollten nur nach dem System Grad Minuten Sekunden Hundertstelsekunden stattfinden. Das ist auf 15 cm genau. So etwas wie Grad+Dezimalanteile braucht man auch nicht. Umrechnen und abschaffen, fertig.
Die Vorlage sollte idiotensicher sein. Bis jetzt geht alles in der Wikipedia ohne Hilfsmittel. Ich brauche doch auch keinen Editor für den Editor. Man will doch einen breiten Erfolg, und den hat man doch nur, wenn alle Benutzer gerne mitmachen.

Es kann doch nicht sein, dass ich da einen Mega-Einzeiler baue, mit ersetzten Leerzeichen, damit es da keinen ungewünschten Umbruch gibt.

Die bisherige Vorlage ist laut [1] usw. provisorisch. Es ist aber schon längst bewiesen, dass es mit der Geofunktion geht. Also muss man da doch mal was entwickeln. Eine nicht mehr provisorische Vorlage sollte nach meiner Meinung so aussehen (als ein Pendant zu Personendaten), und nur nach 1 System laufen:

{{Koordinaten|

NAME=Reichstagsgebäude

|KURZBESCHREIBUNG=Sitz des deutschen Bundestags

|BREITE= 52 31 07 00 N
;

|LAENGE= 13 22 24 00 E

|STATE=Deutschland

|ADMIN1=Berlin

|ADMIN2=

|CITY=Berlin

|TYPE=Gebäude

}}

Es muss reichen, dass man die Koordinaten nur einmal eingibt - ansonsten ist es schon wieder doppelte Arbeit.
Es sollte wirklich zur Regel werden, dass man Land - Landkreis/Stadtkreis - Ortschaft mit eingibt, denn so kann man das in einer KML-Datei auch gut gliedern. Beispiel: ein Häkchen auf NRW und schon sehe ich alle Orte nur in NRW.
Wir brauchen mehr definierte Objekttypen (Gebäude, eventuell Turm, Schloss, Burg, Krankenhaus, Museum, Universität, Bergwerk usw.). Landmark lohnt sich doch gar nicht. Egil ist ein aufgeweckter Typ. Der wird mehr Variationen schon hinkriegen.

Danke für die Aufmerksamkeit. Meinungen? -- Simplicius ☺ 12:39, 26. Sep 2005 (CEST)

zu: Dezimalangabe: Stimmt schon. Eine übertriebene Gebauigkeit halte ich auch für übertrieben. Eine Minute (siehe Geografische Koordinaten kann in Europa zwischen aber schon zwischen 1 km und 1,5 km Unterschied ausmachen. Deziamlangaben bei nur Gradangaben aber auch bei Angaben in Grad und Minute machen daher durchaus Sinn. Sollte mal eine Eingabe 15 cm "genau" sein, wird die tatsächliche "Ungenauigkeit" dieser Angabe wohl nicht herausgerechnet worden sein. Generell sind aber alle Angaben immer auch mit Vorsicht zu geniessen, solange keine Informationen zur Genauigkeit mitgegeben werden.

zu: Objekttypen: Sollte egils Extension jemals in die Wikipedia übernommen werden, dann sind IMHO keine weiteren (Unter-) Objekttypen notwendig, da dann ein Zusammenhang zwischen Koordinate und Kategorie hergestellt werden kann. Man sollte sich diesbezüglich nicht doppelte Arbeit machen.

zu: Vorlage / provisorisch / Dezimalangabe: Generell ist - wie egil oben schon schrieb -, zu fragen, wann endlich eine GIS-erweiterung in die Wikipedia kommt, bzw. wiso dies noch nicht passierte. Bis dahin sollten wir noch mit der alten Vorlage weiterarbeiten. 134.106.146.46 13:13, 26. Sep 2005 (CEST), (Benutzer:Arcy)

Ich kann dir verraten, warum ich den Vorschlag mit 1 neuen Vorlage unterbreite: ich habe null Bock, mit den bisherigen Vorlagen weiter zu arbeiten. Damit werde ich nichts mehr machen.
Ein System mit Hundertstelsekunden = 15 cm finde ich durchaus gut und dem Entwicklungsstand von GPS angemessen, aber es sollte wirklich nur noch ein System sein.
Die Idee mit den Kategorien halte ich für zu unzuverlässig: es gibt pro Artikel in der Regel mehrere Kategorien und zwar teils mit Typ-Eigenschaften, teils auch ohne. Ich halte diesen Vorschlag für "fix geraten" :-)) -- Simplicius ☺ 13:25, 26. Sep 2005 (CEST)

zu Objektypen: Objekttypen sind IMHO nichts anderes als Kategorien. Die Problematik ist auch die gleiche. Es sollte daher bei der georeferenzierung kein Nebenkriegsschauplatz hinsichtlich der Objekttypbildung erfolgen. Die Kategorienbildung in der Wikipedia scheint mir schon kompliziert genug zu sein.
Zu Unzuverlässigkeit: Der Reichstag beispielweise ist schon in der Oberkategorie Gebäude drin. Das pro Artikel mehrere Kategorien bestehen ist nicht von Nachteil. Im Gegenteil: So bestände z.B. auch die Möglichkeit sich nur georeferenzierte historische Gebäude (Kategorie:Historistisches Bauwerk) zeigen zu lassen. 134.106.146.46 13:35, 26. Sep 2005 (CEST) (Benutzer:Arcy)

Beim Beispiel Reichstagsgebäude geblieben, da gibt es noch die Einordnungen: Lesenswert | Regierungsgebäude | Bauwerk in Berlin | Berlin (Politik) | Berliner Geschichte | Deutscher Bundestag | Historistisches Bauwerk | Architektur von Norman Foster Nach dem System "Hauptsache, man hat mindestens 4 Artikel in einer Kategorie drin, dann ist sie berechtigt." sind viele Kategorien viel zu sehr verschnitten worden. Mir geht es darum, dass für die Wikipedia KML-Dateien generiert werden können, deren Strukturierung nicht aussieht wie Krautsalat.

Und zweitens soll die Vorlage möglichst benutzerfreundlich sein. Darum dieser Vorschlag. -- Simplicius ☺ 14:09, 26. Sep 2005 (CEST)

zu kml: Google Earth & Co ist zwar momentan zimlich hipp, hat aber erstmal IMHO nichts mit der Wikipedia zu tun. Oder hat sich die WP auf diese GIS-Software festgelegt? Für die Wikipedia ist ja auch sehr lobenswert. Aber es kann doch nicht sein, dass die Wikipedia einer externen Software angepasst wird, die vor kurzem noch Geld kostete und zudem nicht einmal freie Software ist. In ein paar Monaten sieht der ganze Google Hype schon wieder ganz anders aus.

zu Kategorien: ist doch toll. Ich könnte mir nicht nur alle Gebäude anzeigen lassen, sondern gezielt nur die mit Bezug zur Politik, einer bestimmten Epoche oder weltweit alle von Norman Foster etc. Wie willst Du das mit dem Objekttyp "Gebäude" bewerkstelligen? -- Arcy

Ob Koordinatenlisten nun im Format KML oder beispielsweise GML abgelegt werden, ob für Google Earth oder für andere GIS-Datenangebote, ist nicht relevant für das gleiche Problem:

Es gibt bislang nur die Typen Orte, Inseln, Gewässer, Berge, Flughäfen, Landmarken und vor allem Typ fehlt und Typ unbekannt. So etwas wie "Bauwerk" oder gar "Vulkan", "Bergwerk", "Kraftwerk", "Weltkulturerbe" etc. gibt es hier noch nicht.

Das Reichstagsgebäude ist einfach nur "landmark" und eine Kurzbeschreibung gibt es nicht - oder die Einordnung nach Staat/Bundesland - obwohl so eine Erfassung eigentlich zum Greifen nahe ist.

Ich warte jetzt mal ab, was andere dazu sagen. -- Simplicius ☺ 15:14, 26. Sep 2005 (CEST)

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

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

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

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

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

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

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

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

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

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

Ich habe das ganze mal auch unter Wikipedia_Diskussion:Kategorien#Wikipedia_Diskussion:WikiProjekt_Georeferenzierung.23Vorschlag zur Diskussion eingestellt Arcy 22:12, 26. Sep 2005 (CEST)

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

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

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

Was ist denn daran "übermäßig komplex"? Nichts. Neu ist eigentlich nur "Kurzbeschreibung". Alle anderen Angaben sind genau die, welche Egil verarbeitet, nur transponiert von der der Horizontalen (1 Megazeile) in die Vertikale über mehrere Zeilen.
Gut, ferner will ich die Koordinate nicht doppelt eintippen müssen. Und der Typ "Landmark" möge um eine Handvoll passenderer Typen bereichert werden.
Ansonsten aber haben nun mal nicht alle Artikel Infoboxen, ich habe ehrlich gesagt auch null Bock auf Infoboxen bei Schlössern oder Türmen oder Museen. Das halte ich für eine fette Sackgasse, Slomox, weil das niemand mitmachen wird. Da finde ich die Koordinatenvorlage noch eine leichte Übung gegenüber einer Infobox.
Und die Gliederung nach Staat/Land/Stadt ist ja nun Teil des Modells auf Wikipedia:WikiProjekt Georeferenzierung. Da habt Ihr wohl gar nicht gemerkt, dass ich das nur abgeschrieben habe.
Sie macht auch Sinn, denn auch eine kml-Datei mit 5.000 Punkten zwingt Google Earth schon in die Knie, und das ist noch gar nichts angesichts von 300.000 Artikeln. Es ist schön, eine Datei oder einen Abschnitt zu haben, wo man zum Beispiel nur NRW oder den Hochsauerlandkreis aktivieren kann.
Beschmiert ist es doch, sich in Deutschland alle Orte von Aaa bis Adc anzeigen lassen zu können.
Und was die Vulkane angeht, ob aktiv oder erloschen, es ist ein Vulkan und derer gibt es wohl 2.700 Stück. Und eine Datei nur mit den wichtigsten Vulkanen rund um den Globus fände ich schon cool.
Etwas daneben ist auch der Glaube, man könne mal eben den ersten Absatz als Kurzbeschreibung nehmen. Da gibt es überlange verschwurbelte Absätze, und in einer Datei mit z.B. 10.000 oder 20.000 Punkten sind solche Textmengen der Untergang bzgl. Download, Rechenleistung usw. -- Simplicius ☺ 01:13, 27. Sep 2005 (CEST)

Das habe ich ja auch nicht gesagt, dass der Vorschlag bereits übermäßig komplex ist. Mein Kommentar war jetzt mehr allgemeiner Natur und nicht auf den konkreten Vorschlag gerichtet. Ich möchte nur nicht, dass in Richtung einer redundanten, nicht zukunftssicheren Struktur gearbeitet wird (wozu ich explizit auch die bestehende Lösung zählen möchte). Wikidata soll ja auch nicht für jeden Artikel Infoboxen generieren, sondern nur Daten erfassen. Diese müssen im Artikel keineswegs verwendet werden, wenn das nicht erwünscht ist. Für einen Turm könnte ich mir zum Beispiel vorstellen, dass dieser in einer Klasse „Gebäude“ eingeordnet wäre, die als Parameter Standort (Ortsname), geografische Lage, Gebäudetyp erfassen würde. Ein Turm ist aber kein Beispiel für ein besonders Wikidata-geeignetes Objekt. Bessere Beispiele wären Personen (Wikidata wäre dann so eine Art Personendaten-Commons), Städte, Berge etc. Also Klassen von Objekten von denen es typischerweise viele gibt und bei denen immer die gleichen Kernwerte (Höhe des Berges, Einwohnerzahl etc.) auftauchen.

Ich möchte also lediglich, dass wir nicht kurzfristig auf die Anpassung an Google Earth und Konsorten, sondern längerfristig auf eine Implementierung eines Wikimedia-Projektes setzen, das alle Wikimedia-Ressourcen und -Möglichkeiten ausschöpfen kann. --::Slomox:: >< 02:06, 27. Sep 2005 (CEST)

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

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

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 Slomox

Also wenn schon ausweiten, dann aber noch konkreter werden. landmark (sozusagen das alte other) ist ziemlich unspezifisch. Aber die vorgeschlagenen Typen sind immer noch nur halbspezifisch. Sie geben nur eine thematische Orientierung. Wir sollten dann gleich den ganzen Weg gehen und relativ klar einordenbare Objekte wie Krankenhaus, Truppenübungsplatz oder Friedhof auch als solche angeben. Wir wollen ja an die Kartennutzung denken und da wäre es fatal, wenn man auf der Karte Krankenhäuser sucht und 'ne Wassermühle angezeigt bekommt ;-) Ist natürlich immer schwer auszumachen, wo die Grenze ist, Skischanzen und Schwimmbäder (wenn's keine Spaßbäder sind) sollten schon gemeinsam als Sportanlagen gelten.

Mein eigener Vorschlag basierend auf sks genannten Objekten (ohne die jetzt gleich mit englischen Begriffen zu verbinden). In Klammern sind die von sk genannten Objekte, die ich unter dem vor der Klammer genannten Begriff subsummieren würde:

Platz, Brücke, Straße, Bahnhof, Seilbahn, Fähre, Hafen, Rastplatz, Schiffshebewerk, Schwebebahn, Tunnel
Hotel, Gaststätte, Betrieb (Industrie- und Gewerbe, E-Werk, Wasserwerk), Mülldeponie, oberirdische Abbaustätte (Steinbruch, Tagebau), unterirdische Abbaustätte
Kirche, Kulttätte (Kapelle, Kreuz, Bildstock)
Turm, Schornstein, Leuchturm, Sendemast, Fernsehturm
Friedhof, Grabstätte (Grabhügel, Steingrab, Hühnenstein, Opferstein)
Naturdenkmal, Naturobjekt (Hervorragende Bäume, Findling), Park, Wald, Höhle, Gletscher, Naturschutzgebiet, Naturschutzpark
Burganlage (Ruine), Festungsanlage (Bunker, Wehranlagen, Militärische Anlage), Truppenübungsplatz
Sportanlage (Skischanze, Schießstand, Schwimmbad, Galopprennbahn, Spielplatz, Freizeitanlagen, für Sportbetrieb), Stadion (für Sportveranstaltungen)
Denkmal, Schloß, Mühle (Windmühle, Wassermühle), Krankenhaus, öffentlicher Verwaltungsbau (Rathaus)

--::Slomox:: >< 23:42, 29. Sep 2005 (CEST)

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

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

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

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

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

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

Soll das heissen, das die hier diskutierte WP-Geodatenbank nulldimenional werden soll? Arcy 16:51, 1. Okt 2005 (CEST)

Hast du eine bessere Idee? Die Autoren der Wikipedia dürften sich auch freuen, wenn wir einen Artikel wie Berliner Mauer mit 2000 Koordinaten vollstopfen um den Pfad der Mauer zu beschreiben. Ich gehe davon aus das unsere Punkte über eine Karte gelegt werden in der Straßen und der gleichen eingezeichnet sind und das ganze zu 90% gut funktioniert, es aber auch ein paar Verluste geben wird. Ein Punkt kann ausreichen um ein Waldgebiet zufinden aber nicht um es zu beschreiben. Für alles andere bräuchten wir einen richtigen Geoserver. Und sowas wie die QuickWMS-Extension ist da als Clientensoftware noch nicht allzu befriedigend. Kolossos 17:38, 1. Okt 2005 (CEST)

Eine zusätzliche Angabe zum Geodatentyp im WKT (Well Known Text)-Format würde die Geodaten hinreichend beschreiben und auch die Eingabe mehrdimensionaler Objekte erlauben. Arcy 19:11, 1. Okt 2005 (CEST)

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

Grenzübergreifende Typisierung

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

Ist es nicht so, dass jede WP ihre eigene Georeferenzierung für jedes Land der Erde macht? --Raymond 08:08, 30. Sep 2005 (CEST)

Ja. Für die englische Wikipedia hat Stefan Kühn eine Datenbank erzeugt, die gut 5.000 Einträge hat. Es ist natürlich zu überdenken, ob man nicht auf eine gemeinsame Verortung entwickelt, so wie man bei commons gemeinsam aus 80 oder mehr Sprachabteilungen auf Bilder zugreift. Fraglich. -- Simplicius ☺ 13:31, 30. Sep 2005 (CEST)

Jede Wikipedia hat für in seinem Sprachraum seinen Schwerpunkt. Allerdings erscheint mir die deutsche Wikipedia auch etwas als Vorreiter. So finde ich es erstaunlich das en:London in der englischen Wikipedia nicht georef. ist, in der deutschen jedoch schon. Aber der Eindruck kann täuschen. Das ganze ab einem bestimmtem Stadium auf einem zentralen Geo-Server zu verlegen sollte nicht das Riesenproblem sein wenn es dann von uns die richtigen Georef. und sowas wie Wikidata gibt. Man könnte natürlich auch mal überlegen einen Bot zu benutzen der überprüfte Georeferenzen ausliest und über die Interwikilinks an andere Wikipedias weitergibt. Es würde mich erstaunen wenn das deutsche London woanders liegt als das deutsche.Kolossos 18:56, 30. Sep 2005 (CEST)

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

Das 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).

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. 2005

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

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

Kartenübersicht für die Wikipedia

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

Es gibt da einen schwachen oder starken Trend, nämlich Commons, je nachdem wie sich das Meinungsbild entwickelt. In Sachen Kategorien und Übersichten versuche mal Maps. Hier in der deutschsprachigen WP werden die Kategorien ja schon demontiert bevor die Bilder überhaupt transferiert wurden. -- Simplicius ☺ 22:33, 7. Okt 2005 (CEST)

Ich denke mal viele Karten wie z.B. Bild:Lage Prenzlauer Berg in Berlin.png schwirren im Nirvana der deutschen Wikipedia und sind nur über den jeweiligen Artikel auffindbar. Kolossos 22:41, 7. Okt 2005 (CEST)

Vielleicht sollte man mal eine Übersicht der in der deutschen Wikipedia vorhandnen Karten erstellen. Ich denke dabei vor allem an eingescanntes Kartenmaterial und selbsterstellte Karten mit hohem Informationsgehalt. Auch diese Karten könnten mittels World Datei oder KML georeferenziert werden und in andere GIS-Programme oder Google Earth eingebunden werden Arcy 16:33, 8. Okt 2005 (CEST)

Natürlich. Aber am günstigsten wäre es schon, die Bilder würden zunächst migriert nach Commons, mit den Bildern in den dortigen Kategorien vereinigt, und dann könnte man die Verortung dort machen (die Deckungsgleichheit ist schon ein ziemliches Stück Arbeit) und sämtliche Benutzer aus 100 anderssprachigen Wikipedias hätten auch was davon.

Leider mauern sich da auch viele im Meinungsbild mit ihrem komischen "Leberkäse nur von und für Deutsche" ein. -- Simplicius ☺ 17:09, 8. Okt 2005 (CEST)

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. 2005

Georeferenzierung von historischen Stadtplänen

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

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

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

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

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)

Externer Geodaten-/Karten-Server

Externer 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)

Hier ist er: Wikipedia_Diskussion:WikiProjekt_Georeferenzierung/Archiv2#kvaleberg.com:_Was_geschieht_dort_mit_den_anfallenden_Daten.3F --BLueFiSH ?! 00:11, 1. Nov 2005 (CET)

Ich finde die Kvaleberg-Funktionen ein guter Anfang und begrüsse jede solche MediaWiki-Erweiterung. Ich möchte nur leise daran erinnern, dass Kvalebergs Funktionalität sich auf das Auflisten von Websites beschränkt; d.h. der Hauptfunktionsgruppe 2a im Stimmungsbild entsprechen, eingeschänkt auf Websites mit Koordinaten-Parameter. Geonick 23:33, 31. Okt 2005 (CET)

Ich möchte eine meiner Aussage oben korrigieren: Anstelle eines an einer Hochschule gehosteten Servers wurde der offenbar vom Wikipedia-Verein zur Verfügung gestelle Tool-Server vorgeschlagen. Geonick 23:33, 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 Funktionen

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

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)

ein paar infos aus der freegis-newsgroup

On Fri, Oct 28, 2005 at 09:47:17PM -0400, Robert Treat wrote:
> On Friday 28 October 2005 06:44, Arnulf Christl wrote:
> > Yet another idea:  Mediawiki (the
> > Wikipedia software) is also right now introducing geometries to the Wiki
> > database - obviously also using PostgreSQL/PostGIS. This would be
> > another cool multiplier.. and there we also meet with Google again.
> 
> Wha? mediawiki is planning to use postgis with thier software? I'm currently 
> working with some folks on a working port of wikimedia to postgresql 
> (allowing things like transactions and full text searching all in the same 
> database). That would certainly seem to dovetail into this... you have any 
> links I could read up on the wikipedia/postgis effort on ?
> 

There's nothing yet written down. There's some working code, and I'm
just improving it from "proof of concept" stage to pre-production level.
The code I'm working on is an extension to MediaWiki. It is independent
of the article storage. I'm sure storing everything in one DB would be
better from a design point of view, but it's easier for us to scale if
we keep things apart. Especially new features like these where we've no
idea about the performance impact.

If you're improving MediaWiki's Postgres support we'd of course be happy
to get your patches into the main code tree.

Regards,

JeLuF (jf@mormo.org)

An interesting bit of commentary from another list regarding structured
wiki's:

> On Friday 28 October 2005 06:44, Arnulf Christl wrote:
> > Yet another idea:  Mediawiki (the
> > Wikipedia software) is also right now introducing geometries to the Wiki
> > database - obviously also using PostgreSQL/PostGIS. This would be
> > another cool multiplier.. and there we also meet with Google again.
>
> Wha? mediawiki is planning to use postgis with thier software? I'm currently
> working with some folks on a working port of wikimedia to postgresql
> (allowing things like transactions and full text searching all in the same
> database). That would certainly seem to dovetail into this... you have any
> links I could read up on the wikipedia/postgis effort on ?
>
> --
> Robert Treat
> Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Interesting for a couple of reasons:

  1) Twiki, Ning, Salesforce, Jotspot, Google base, Openguides and others
are now attempting to provide generic datastores...  These datastores seem
to all be elliptically grazing the idea of RDF despite admonitions to the
contrary [ they're semi-structured, define schemas 'in grammer' and use
world unique subject identifiers among other things ].

  2) There seems to be a burgeoning new literacy (apparently there was a
talk on this subject at oscon 2005).  It could very well be that in the
near future we're going to see an inability to program being looked at as
something of a handicap; much like not being able to type.  This
also may imply pressure on software authoring tools to become perhaps not
simpler but more consistent; something way beyond what ruby on rails does
today... more like some kind of wizard or lego building block tool.

  - a

Google Earth

Icons

Also eigene Icons für Google Earth und die Wikipedia-KML-Datei(en) könnte man

auf Commons deponieren
mit einer eigenen Kategorie versehen
als png
in der Größe 32 x 32 Pixel
mit transparentem Hintergrund
mit englischen Dateinamen
zum Beispiel Icon-airport.png
ohne kreisförmige Umrandung.

Was haltet Ihr davon? -- Simplicius ☺ 12:01, 13. Nov 2005 (CET)

In KML sollten die Icons in der Style-Beschreibung deklariert werden, nicht bei jedem Objekt, denn sonst werden sie jedesmal neu aufgerufen, oder? -- Simplicius ☺ 12:01, 13. Nov 2005 (CET)

Ich nutze bisher die Standard-Icons, die bei der Software Google Earth mitgeliefert werden. Das hat den Vorteil, dass man auch ohne Internetanschluss zumindestens den Globus nutzen kann, wenn auch ohne hochauflösende Bilder. Das Ablegen auf Commons würde bedeuten, dass man immer Internetanschluß haben muss um es immer in der gleichen Darstellung zu bekommen. Das finde ich halt nicht so gut. -- sk 14:38, 13. Nov 2005 (CET)

Symbol-Icons für Geoobjekte sind natürlcih immer sinnvoll, und das nicht nur für Google Earth. Es sollten große Icons deponiert werden. 32 x 32 px halte ich für zu gering. 64x64 z.b. könnte man immer noch runterskalieren. Arcy 17:53, 13. Nov 2005 (CET)

64 x 64 Pixel mal 96 dpi Monitorauflösung geben 1,6 x 1,6 cm große icons auf dem Bildschirm. Ich sehe da momentan nicht den Sinn. Ist so etwas denn wirklich besser skalierbar für verkleinerte Darstellungen?

Was den Einwand mit der Offline-Nutzung angeht: nutzen diese Menschen dann KML-Dateien der Wikipedia? -- Simplicius 15. Nov 2005 (CET)

Ich bin auch noch nie auf die Idee gekommen Google-Earth ohne Internetanschluß zu starten. Aber es stimmt schon, der Server sollte schnell und zuverläßig sein, was man von den Commons in den Abendstunden nicht gerade behaupten kann. Kolossos 11:42, 15. Nov 2005 (CET)

Sollen die Icons denn NUR für Google Earth hochgeladen werden? 134.106.146.46 12:15, 15. Nov 2005 (CET)

Nein natürlich nicht, die Arbeit soll für möglichst viele Verwendungen (Worldwind, Legende (Karte),...) zur Verfügung stehen um den größten Nutzen zu erzielen, trotzdem könnte für GoogleEarth eine Kopie auf einen schnellen, externen Server dienen. Kolossos 21:46, 15. Nov 2005 (CET)

Rund um die Wikipedia-Koordinaten, und momentan ist Google Earth die Hauptanwendung der KML-Datei. -- Simplicius [[Benutzer Diskussion:Simplicius|☺]] 23:01, 15. Nov 2005 (CET)

Das stimmt natürlich für die Aussage "KML ist das Deteiformat von Google Earth" ;-). Das WikiProjekt Georeferenzierung hat aber nicht zum Ziel KML-Dateien zu erstellen. Siehe auch Wikipedia:WikiProjekt Georeferenzierung (Einleitung). Im Rahmen der WPs finden die Koordinaten Verwendung auf der wwww.kvaleberg.com Seite. Dort werden die Koordinaten zu diveresen weiteren Seiten weitergeleitet, wobei z.B. die Google Maps nicht aufgeführt werden. -- 134.106.146.46 10:15, 16. Nov 2005 (CET)

Interessanter Hinweis auf die englische Wikipedia. Ich habe mich immer gewundert, warum nicht alle nationalen Seiten auf kvaleberg.org eine Schnittstelle zu Google Earth aufweisen. Ich habe dort einen Kommentar hinterlassen.

Generell ist diese Technik der Datenübergabe XML. Auch NASA Earth Wind hat eine XML-Schnittstelle. Es ist also eine Grundsatzüberlegung, die aktuell wird, sobald man mindestens 1 in Frage kommende Anwendung hat. Die Frage, wie man auf den Karten die zusammengestellten Koordinaten darstellt (über 20.000), betrifft nicht nur die Icons, sondern auch die Farben für die Beschriftungen.

Der erste, der dieses Thema angeht, ist hier Vorreiter. Ich habe kein Problem damit, für die Offline-Version eine Online-Version zu ergänzen. So bleibt dann auch die andere Variante bedient, wenn Menschen die KML-Koordinaten offline nutzen wollen oder Commons ganz zusammenbricht. -- Simplicius 12:20, 16. Nov 2005 (CET)

Gute Idee, Simplicius! Stimme mit dir und Kolossos überein: Wie bei georeferenzierten Artikel geht es auch bei Icons (= Symbole) darum, dass "die Arbeit (...) für möglichst viele Verwendungen (Worldwind, Legende (Karte),...)" zur Verfügung steht. Bitte erfindet aber auch hier nicht die GIS-Technologien neu, denn: Bei GIS-, Kartographie- und GPS-Mapping-Produkten gibt es ja auch schon Symbole!!! Gleichzeitig muss ich aber zugestehen, dass es offenbar die GIS-Hersteller nicht geschafft haben, sich auf einen Standard zu einigen! Darum scheint mir eure Diskussion hier interessant. Es gibt folgende Standard-Kandidaten: TrueType und PNG für Pixel-Symbole, SVG sowie .sym (=> UMN Mapserver) für vektoriell definierte Symbole. Wenn der Bedarf nun steigt, so könnte ich mir ein Ausbau eines Symbol-Editors aus der eigenen Werkstadt anbieten. Bleibt noch die Frage nach einem 'Portal' für Icons/Symbole unter Commons Lizenz (hier eine Seite mit Symbolen). -- Geonick 01:32, 21. Nov 2005 (CET)

Ich würde zunächst mal .png vorschlagen, 32x32 px.

Die Frage nach dem Design ist gar nicht so einfach. Herkömmliche Karten aus dem 19./20. Jahrhundert sind in einer deutlich anderen Machart illustriert. Und natürlich gibt es auch Schraffuren etc. für Flächen, farbige Linien usw. die wir nicht nehmen können.

Ich schaue mir deine Beispiele gleich mal an und melde mich morgen wieder. -- Simplicius 16:10, 21. Nov 2005 (CET)

PS Mann, Mann... da gibt es so viele militärische Symbole, dass man den Zweiten Weltkrieg mit den ganzen Panzerdivisionen nachbauen könnte...

Neue dynamische KML-Datei

Unter www.alder-digital.de/Wikipedia_in_GoogleEarth finden sich die neuen KML/KMZ-Datein für Google-Earth mit den aktuellen 19000 Einträgen. Wenn das Wachstum des georeferenzierten Bestandes weiter so ist, kann dieses serverseitige Verfahren seine Vorteile immer besser ausspielen. Irgendwann kann das System dann von mir aus auf den Meta:Toolserver wandern.

Nachdem alleine in einer Stadt wie Hamburg noch ca. 60 Sehenswürdigkeit zu georeferenzieren waren, würde mich mal eure Schätzung interessieren auf wieviele Geo-Objekte man kommen würde wenn man die gesamte Wikipedia im aktuellen Stand sinnvoll durchreferenzieren würde. Gibt es überhaupt eine Statistik wieviele Artikel in der Wikipedia einen Ort, eine Person, ein historisches Ereignis oder einen Sachverhalt beschreiben? Kolossos 21:08, 24. Nov 2005 (CET)

Welches System? Soll Google nun in die Wikipedia integriert werden?. Ich konnte auf deiner Seite keinerlei "Verfahren" entdecken. Du scheinst lediglich die Daten von www.webkuehn.de nochmals anzubieten. Arcy 22:43, 24. Nov 2005 (CET)

Du kennst doch sicherlich den alten GIS-Spruch, dass 90 % aller Daten einen geographischen Bezug haben. Bei angenomenen 1.100.000 Artikel (weltweit) wären dies ca. 1.000.000 Objekte. Bei 20.000 Einträgen hat die Wikipedia demnach fast 2% georeferenziert. Gratulation! Arcy 22:43, 24. Nov 2005 (CET)

Acry, ich bereite die Daten für Kolossos auf und er wandelt sie in die dynamische KML um. In meiner nächsten KML werde ich seine Dateien mit aufnehmen. Zu der Objektanzahl, kann ich nur empfehlen sich mal das hier http://www.roscheiderhof.de/kulturdb/googleearth/KulturDB.kmz anzuschauen. Dort haben ein paar Leute eine Datenbank aufgebaut mit Kulturdingen für den Raum Trier. Sie hatten mich gebeten aus der DB mal eine KML zu machen. Das Ergebnis zeigt sehr anschaulich, wieviele Dinge man noch beschreiben kann. Ich glaub es waren so ca. 9000 Objekte, wenn auch nicht alle Wikipedia-tauglich sind. ;-) -- sk 23:23, 24. Nov 2005 (CET)

Ich frage mich nur, was an der ganzen Sache "dynamisch" ist. Hierunter verstehe ich eigentlich Arbeitschritte, die von einer Software übernommen werden. Eine KML-Datei ist IMHO so dynamisch wie eine TXT-Datei oder der Text den ich hier gerade schreibe. Arcy 23:50, 24. Nov 2005 (CET)

"Dynamisch" heißt das ganze weil mir noch kein besserer Begriff eingefallen ist. Aber die KML-Datei wird in Abhängigheit deines jeweiligen Blickfeldes in GE über PHP aus einer serverseitigen Datenbank gefiltert und erzeugt. D.h. in der DB könnten durchaus 1 Mio. Einträge stehen. Anfangs lädst du dir nur einen kleinen Webordner runter alles andere wird nachgeladen und dir wird nur das gezeigt was du sehen willst bzw. was auf deinen Bildschirm paßt. So werden Dörfer nicht angezeigt wenn du dir ganz Deutschland anschaust. Nachteilig ist nur das aller paar Sekunden ein Datenbankzugriff erfolgen muß und da weiß ich nicht wielange mein Provider mitspielt wenn es dann mehrere Anwender gibt. Kolossos 00:39, 25. Nov 2005 (CET)

Dann nenn es wie SK doch auch einfach nur Neue KML-Datei. Ansonsten ist schon klar, dass Du die Datei nicht mit einem Kugelschreiber erstellt hast. ;-)Arcy 22:18, 28. Nov 2005 (CET)

Dynamisch ist schon ok, ich würde es evtl. als Frontend bezeichnen. -- Simplicius 00:53, 29. Nov 2005 (CET)

Das Ergebis, eine KML-Datei, ist also das Frontend? Oder verstehe ich dich da falsch? Eine KML-Datei ist soetwas wie ein Web-Browser? Arcy 08:24, 29. Nov 2005 (CET)

Ich werde "das Ding" wohl in Zukunft serverbasierte KML-Datei nennen. Ich hoffe, Arcy hat sich "das Ding" und z.B. seine Downloadgröße von 8 kB mal angekuckt damit wir nicht aneinander vorbei reden.Kolossos 10:34, 29. Nov 2005 (CET)

Mit 8kb wurde das Programm, äh - dasFrontend ja so richtig klein programmiert. ;-) Arcy 11:29, 29. Nov 2005 (CET)

Ich habe es ausprobiert, um zu verstehen, was Kolossos meinst. Es ist cool. Irgendwas auf Zeile 310 und 400 führt aber immer wieder regelmässig zu einem Error.

Die Idee ist jedenfalls richtig. Analogie: man kann ja nicht gleich alle 10 TByte Bilddaten laden, sondern 1 MB, also auch nicht 1.000.000 Koordinaten, sondern 20.

Was ich jetzt noch nicht verstanden habe ist, wie Kolossos das machst... Allerdings habe ich immer noch nicht die Dokumentation von KML komplett gelesen. Werde ich heute nachmittag mal machen.

Zu Google Earth und KML: es geht hier doch nur um den Entwicklungsschritt nach vorne, in 5 Jahren gibts was anderes. Vielleicht legt die NASA ja noch mal nach.

Zur Georeferenzierung: ich finde den Baustein einfach etwas unhandlich, den Baustein für Personendaten zum Beispiel besser. Das "Werte doppelteintragen müssen" nervt. Und Softwarehilfen nur für 'ne Breiten und Längenangabe nutzen zu müssen... das muss einem doch zu denken geben.

Was die Orte angeht, viele Ortschaften (Gemeinden, Stadtteile) sind noch nicht erfasst. Sehenswürdigkeiten wie Museen, Theater, Zoos usw. hängen arg nach. Ich schätze den Anteil der Artikel mit konkretem Raumbezug auf 15-20 %.

Gäbe es einen zentralen Server, hätten wir die Fusion der englisch- und deutschsprachigen Koordinaten (Vereinigungsmenge = Summe - Schnittmenge). Zugleich könnte man auch Koordinaten hinzufügen, für die es (noch) keine Artikel gibt.

Hier wäre dann aber (noch mal) die 3 Fragen nach dem Typ zu klären: Soll auf den Typ über die Kategorien zurückgeschlossen werden, also mittelbar? Soll der Typ dann unmittelbar eingetragen werden, das sollte Mehrfachdeklarationen aber möglich machen wie "Schloss, Museum" oder "Berg, Vulkan". Soll die Anzahl der Typen begrenzt oder offen sein? Quelle, Datum, Genauigkeit, Bearbeiter sollten zu erkennen sein.

Kolossos' System, die Anzahl der Punkte im Fenster zu begrenzen ist ja der wesentliche Fortschritt, aber man muss Quellen auch ausblenden können, wenn man merkt, dass da ein dummer Datenbestand einfach reingeknallt wurde und Redundanzen bestehen. -- Simplicius 12:17, 25. Nov 2005 (CET)

Punkt für Punkt:Der von Simplicius oben genannte Bug sollte behoben sein, er hing mit dem Sonderlaut "&" in einem Namen zusammen.

Für das "Wie?" ist dieser Punkt im kml-Tutorial interessant. Die DB-Tabelle hat dann die Felder Name,lon,lat und pop bzw. psize. Psize enthält erstmal die Buchstabenanzahl des Artikels. Ich hoffe auch, daß die Nasa aus dem Knick kommt, ich würde WorldWind jedenfalls unterstützen wenn ich eine Möglichkeit hätte. Hast du mein obiges GE-Tool zur Georef. mal getestet? Ich finde viel einfacher geht es kaum noch, man muß nichts tippen. Den 15-20% Schätzung, würde ich mich anschließen vielleicht sogar etwas mehr. Auf jeden Fall sind wir dann bald bei 100.000 Artikeln. Zu den letzten beiden Punkten später mehr.Kolossos 17:28, 25. Nov 2005 (CET)

Ich wollte mal beim nächsten Dump die Interwiki-Links zu georeferenzierten Artikeln mit rausfiltern. Wenn ich also im englischen Artikel einen Interwiki zum deutschen Artikel finde, dort aber noch keine Koordinate verfügbar ist, dann soll die englische Koordinate mit übernommen werden. Umgekehrt geht da natürlich genauso. Muss mal sehen ob das klappt. Diese Schnittmenge könnte man dan gerne als Basis für eine Auslagerung nehmen. -- sk 17:19, 25. Nov 2005 (CET)

Vielleicht sollte man aber stattdessen schon einen Schritt weitergehen und eine Verlinkung auf einen zentralen Server schaffen.

Beide Modelle können auch noch parallel nebeneinander herlaufen, bis man die Umstellung verwirklicht hat. Wichtig ist nur, dass man nicht öfters klicken muss als bisher. Man muss durch einen Klick auf eine Art Kvalebergserver kommen.

Ich fände es schlauer, da jetzt was zu überlegen und zu machen, also eine zentrale Verwaltung. -- Simplicius 17:32, 25. Nov 2005 (CET)

Ich denke wir sollten hier auf die Freischaltung von Wikidata warten. Dort sind solche Dinge auch mit vorgesehen. -- sk 18:35, 25. Nov 2005 (CET)

Zu den Kategorien nochmal was. dieser Punkt müßte wirklich angefaßt werden, da auch andere Projekte davon profitieren könnten. Das Problem liegt ja in der Rückführung der Artikel (z.B.: aus der Kategorie Berg in Deutschland) auf die Oberkategorien (Berg). Der Lösungsprozeß müßte aus meiner Sicht in zwei Schritten erfolgen: Erstens, ausgehend von der Hauptkategorie für jeden Artikel jeder möglich Kategoriepfad in einer neuen sehr großen Tabelle aufgezeichnet.

Beispiel: Fichtelberg (Sachsen)

bzw.

In einem zweiten Schritt ist es dann relativ schnell möglich für einen Artikel eine Oberkategorie über SQL (Category like %|Berg|%) abzufragen. Ich scheue mich in der Umsetzung jedoch noch etwas vor dem ersten Schritt andererseits sind auch die Schlußfolgerungen z.T. problematisch, der Fichtelberg ist einfach kein Gebirge sondern nur ein Berg. Kolossos 13:36, 27. Nov 2005 (CET)

Die Geografie ist eine Wissenschaft mit vielen Teilgebieten. Geografen sitzen eigentlich nicht am Zeichentisch, um neue Berge und Seen einzuzeichnen, die Forscher entdeckt haben (etwa wie bei Saint Exupery, für kleine Berge muss ein kleiner Stein als Beweis her, für große Berge ein großer); genausowenig ziehen die wenigsten Biologen umher auf der Suche nach neuen Pflanzen und Tierarten.

"Berg" ist für Geografen vielmehr ein Begriff, verbunden mit Fragen a la "wie entsteht ein Berg", "wie vergeht ein Berg", "wie unterscheidet sich die Vegetation zu der auf dem flachen Land", "wo auf einem Berg regnet es am meisten" also Vegetations- und Klimazonen oder "wie kann man Berge nutzen".

Der gescheite Aufhänger ist eigentlich die Facettenkategorisierung. Typ:Natur/Geomorphologie/Vulkan oder Typ:Kultur/Werk/Bauwerk/Brücke/Hängebrücke

Letzendlich, konkret könnte man das alles zugleich an einer "Kategorie:Objekte mit Raumbezug" aufhängen, aber das momentane Kategoriesystem ist und bleibt eben unsauber. -- Simplicius 14:20, 27. Nov 2005 (CET)

Aus den oberern Bemerkungen werde ich nicht ganz schlau.Ich dachte uns geht es doch erstmal darum eine gute Karte zu zeichnen dafür müssen Icons zugewiesen werden, alles weitere kann man ja dann über die Links im Artikel erfahren. Aber du hast recht,über die Kategorien könnte man dann auch exotische Spezial-Karten serverseitig erzeugen, z.B.: Karte der Tagebaue in Deutschland oder deine Industrieroute im Ruhrgebiet, etc.. Kolossos 15:08, 27. Nov 2005 (CET)

Wir stimmen überein, dass wir die Einordnung von verkoordinateten Artikel anhand der Kategorien vornehmen, oder sie andersherum suchen.

1. Worauf ich hinweisen wollte ist, dass der in der Wikipedia verwendete Pfad "Geowissenschaft|Geographie|Geographisches_Objekt" ein Mißverständnis über das ausdrückt, was Geografen beruflich machen. Da gibt es nämlich auch geistige Themen.

2. Das real vorhandene System trennt nun auch nicht Objekte mit Raumbezug von Begriffen, so findest du in der Kategorie:Konzentrationslager Objekte wie KZ Uckermark oder KZ Moringen, aber auch abstrakte Begriffe wie Abzeichen in den Konzentrationslagern oder Arbeit macht frei. Darum wird es auch kaum eine Möglichkeit geben, über die man alle Artikel mit Raumbezug (mit und ohne Koordinaten) zahlenmässig wirklich erfassen kann. Eine Lösung wären die Präfix Typ: und Thema: gewesen. Das existierende Kategorisierungssystem ist etwas murksig.

Grüsse, Simplicius 16:45, 27. Nov 2005 (CET)

@Kolossos, den ersten Schritt habe ich vor einiger Zeit schon durchgeführt, leider ist das Ergebnis nicht sehr optimal gewesen, insbesondere was Orte in Deutschland angeht.

Kategorie:Bergbauunternehmen Hauptkategorie-Geowissenschaft-Bergbau-Bergbauunternehmen
Kategorie:Ort_in_Sachsen Hauptkategorie-Politik-Subnationale_Entität-Bundesland_(Deutschland)-Sachsen-Ort_in_Sachsen
Kategorie:Ort_im_Burgenland Hauptkategorie-Räumliche_Zuordnung-Europa-Ort_in_Europa-Ort_in_Österreich-Ort_im_Burgenland
Kategorie:Schiffshebewerk Hauptkategorie-Transport_&_Verkehr-Schifffahrt-Schiffshebewerk

Ich hab dabei für jede vorhandene Kategorie den kürzesten Pfad zur Hauptkategorie gesucht. Wenn du willst kann ich dir die Datei schicken. Insgesamt kam ich auf 14000 Kategorien, aber da ist wirklich jede Kategorie dabei -- sk 16:37, 27. Nov 2005 (CET)

@sk:"Nicht immer ist der kürzeste Weg der beste" -Ich meine damit,auf irgendeinem Weg, nicht unbedingt auf dem kürzesten, wird schon die richtige Oberkategorie dabei sein. Ich werd's ja vielleicht mal über den Datenbankdump probieren. Aber danke für das Angebot. Kolossos 20:29, 27. Nov 2005 (CET)

Benutzer_Diskussion:Kolossos#Interaktive_KML-Datei

Simplicus schlägt dort vor, das man "für freie Daten Dritter und solche Anwendungen [..] generell einen Server aufmachen [sollte], der vielleicht von einem gemeinnützigen Verein getragen wird, aber innerhalb des DFN situiert ist. -- Arcy

Gute Idee! Was ist der Unterschied zum Vorschlag oben? -- Geonick 15:50, 29. Nov 2005 (CET)

Gegen den obigen Vorschlag habe ich nichts, nur von WMS und echten GIS-Datenbanken habe ich keine Ahnung. Und ich sah bei den Plänen nicht so die Weiterentwicklung gegenüber den Kvalenberg-Seiten. Und die Kartensoftware sollte schon so weit ruckelfrei arbeiten das sie auch verwöhnten Nutzern genügt. Ansonten haben wir hier aus meiner Sicht durch die Verknüpfung zu den Artikeln schon einen Schatz den wir uns nicht von kommerziellen Anbietern wegschnappen lassen sollten. Also sobald ein Server steht, würd es wohl auch meinen Teil dazu geben. Bis dahin laßt mich erstmal so weitermachen. Kolossos 22:53, 29. Nov 2005 (CET)

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)

Zusammenarbeit mit OpenGeoDB

Auf der Mailingliste von OpenGeoDB wird zur Zeit über die beabsichtigte Umstrukturierung nachgedacht und diskutiert. Unter anderem wird dabei auch die Zusammenarbeit mit der Wikipedia angedacht. Ist eine Zusammenarbeit (OpenGeoDB als Datenbank und Projekt für Geodaten der Wikipedia) diesbezüglich kurzfristig möglich und wenn ja, wie? -- Benutzer:Arcy / 134.106.146.46 13:23, 16. Nov 2005 (CET)

Am einfachsten wäre eine Datenfeld in der OpenGeoDB das den Artikelnamen des entsprechenden Artikels in der Wikipedia enthält. Dadurch könnte man beide Datenbanken miteinander verknüpfen. Man könnte sich ja dann von Seiten der OpenGeoDB überlegen ob man pro Namen mehrere Objekte zulässt, zum Beispiel bei mehreren Gebäuden einer Uni oder so. Die haben halt dann alle alle den gleichen Artikelnamen. -- sk 13:36, 16. Nov 2005 (CET)

Der Heise-Verlag hat ja in der Mailing-Liste dort interessanterweise angeboten, Mitarbeiter(-Zeit) zur Pflege der DB zur Verfügung zu stellen. Nun wäre es tatsächlich sehr sinnvoll, wenn dies dazu genutzt würde, um die Kräfte hinter dieser DB und dem Projekt Wikipedia-Georeferenzierung zu bündeln. Konkret sehe ich das z.B. so: Die OpenGeoDB versteht sich ja als "Datenbank mit Geokoordinaten zu allen Orten und Postleitzahlen im deutschsprachigen Raum (D,A,CH)". Unter Orte wird offensichtlich etwas Ähnliches wie bei Wikipedia gemeint, nämlich einerseits das postalische Objekt (u.a. mit PLZ) und andererseits die die administrative Einheit mit Gemeinde-Nr. und Einwohnerzahl (was nicht immer dasselbe ist...). Das könnte ja als Selektion von (Wiki-)Kategorien aufgefasst werden! Es ist eine alte Idee von mir, diese Daten in einen Toolserver als Geonamen-Datenbank einfliessen zu lassen (vgl. meta:Wikimaps/GeonamenDB) und andererseits die Pflege und der Mehrwert, die in diese OpenGeoDB gesteckt werden, auch der Wikipedia wieder zufliessen zu lassen.

Was also nun noch zu tun wäre, das ist sich als georeferenziertes und kategorisiertes Wikipedia bei OpenGeoDB zu empfehlen und gleichzeitig alle Anstrengungen zu fördern, die Wikipedia als verlässliche, breit abgestützte Datenquelle erscheinen lassen. -- Geonick 02:08, 21. Nov 2005 (CET)

Fuer den Augenblick wuerde ich auch vorschlagen, dass man eine Uebergangsloesung mit moeglichst geringem Aufwand erzeugt. Mit Wikidata waere eine wiki-einheitliche Datenbankoberflaeche moeglich. Das Wikidata-Projekt duempelt aber leider recht muede dahin. Ansonsten faende ich im Augenblick auch interessant, wenn unter Wiki die Nutzungsmoeglichkeiten der Daten intensiviert wuerden - z.B. Links zu besonders guten praktischen Anwendungen, wie z.B. Auswertungsmoeglichkeiten, die mehrere Ergebnisse zusammenfassen (z.B. Karten, auf denen einzelne Punkte zu Flaechen zusammengefasst werden: PLZ-Gebiete, Landkreise usw.). -- Traut 10:53, 21. Nov 2005 (CET)

Gehören OpenGeoDB und das hier (730 MB Daten) zusammen? -- Simplicius 17:16, 21. Nov 2005 (CET)

Ja, etliche Daten der NGA bildeten den Grundstock fuer opengeodb. Aufloesung dort ist aber mau, und etliche Fehler stecken auch drin. -- Traut 12:16, 2. Dez 2005 (CET).

Ich bin der Meinung, dass wir uns um Punktdaten ganz gut selber kümmern können. Aber beim Eintrag von Straßen, Flüssen und Stadtteilen ströben sich mir bei unserer Methode die Haare. Vielleicht haben die Leute von der OpenGeoDB da eine Lösung bzw. Idee auf die wir dann verlinken könnten und sie auf uns. Auch eine Systemunabhängge Anzeige einer Wikipedia-Karte wäre schön. Kolossos 21:54, 21. Nov 2005 (CET)

Wo wird denn "unsere" DB automatisch aktualisiert? Arcy 22:09, 21. Nov 2005 (CET)

Darstellung von Lebenswegen

Ich bitte euch bei der Gelegenheit auch gleich die Lebenswege von berühmten Personen als mögliche Anwendungen im Blickfeld zu behalten, also z. B. Goethes Reise nach Italien oder die (nicht ganz friedlichen) Wanderung von Napoleon durch Europa. Letztentlich handelt es sich dabei auch nur um eine Menge von Punkten allerdings verknüpft mit Zeitangaben. Kolossos 13:01, 27. Nov 2005 (CET)

Das ist ein guter Hinweis. Hier geht zusätzlich zu den Zeitangaben auch um Richtungen. Die Feldzüge Alexander des Großen oder Napoleons. Die Seereisen von Humboldt, Cook oder Graf Luckner. Die Ausbreitung der Epidemie Englischer Schweiß, 1529, in Europa. Meeresströmungen, Fischschwärme, Vogelzüge etc. Die Wandertour vom Fähnlein Fieselschweif. Stromleitungen in NRW. Da können sich Wege auch überkreuzen oder aufteilen. Ein schönes Thema. -- Simplicius 13:48, 27. Nov 2005 (CET)

Grundsatzfrage

Ist unser jetztiges System überhaupt konsistent? Das wurde doch schon mal hier angesprochen. Jeder trägt in der deutschsprachigen Wikipedia seine Koordinaten ein, zum Beispiel für den Reichstag und Tower of London. So auch in der englischsprachigen Wikipedia. Bei 100 Sprachen muss also eine Verortung 100 mal gemacht werden, natürlich sind die Daten nicht exakt übereinstimmend, obwohl es sich um die gleichen Objekte handelt. Lade ich mir nun die Koordinaten für de und en, gibt es also schon Überschneidungen, oder?
Gegenvorschlag: Gemeinsame Datenbank. Jeder abzubildende Punkt bekommt eine eindeutige, laufende Nummer. In der deutschsprachigen, englischsprachigen oder anderen Wikipedia wird auf die Nummer des Punktes verwiesen. Vielleicht kann in der gemeinsamen Datenbank automatisiert erfasst werden: "in welchen Wikipedias in welchen Artikeln wird auf diesen Punkt verwiesen?".
Das könnte dann in einer einzigen gemeinsamen KML-Datei erfasst werden. Diese verweist auf die entsprechenden verschiedensprachigen Artikel, die zum Zeitpunkt der Erstellung vorhanden waren. -- Simplicius 17:27, 21. Nov 2005 (CET)

Also ich habe genau die gleichen Gedanken gehabt wie Simplicius, nur meine Lösung sieht etwas anders aus. Es muss ein Webseite wie Commons nur halt für Geodaten her. Der deutsche Artikel linkt dann auf die entsprechende Webseite diese Geoportals wie wir das auch schon bei Commons kennen und dort sind für den Artikel die Zentrumskoordinate und weitere Geoinformationen (Grundriß, 3D-Modell, etc.) abgelegt. Problemlos wären dann die Koordinaten und Grundriße nur einmal einzutragen und alle Sprachen können sie nutzen. Wen müssen wir wegen so einer extra Datenbank ansprechen? -- sk 19:59, 21. Nov 2005 (CET)

Ich schätze sowas fällt in den Aufgabenbereich von Wikidata. --BLueFiSH ?! 20:15, 21. Nov 2005 (CET)

Statt einer Nummer könnte man auch eine eindeutige Kennung nehmen. Der Baustein für die Georeferenzierung in unseren Artikeln wäre dann eines Tages vielleicht nur noch {{Geo|Reichstag Berlin}} und auf einem anderen Server wie kvaleberg.org gäbe es dann die Geometrie einzutragen, ja. -- Simplicius 20:32, 21. Nov 2005 (CET)

Auf den Reichstag Berlin könnte man dann auch noch verzichten, da das durch die Variable {{{pagename}}} übergeben werden kann. Ich würde diese Vorgehensweise auch einer jetzt schon praktizierbaren Lösung über einen Interwiki-Bot vorziehen, auch wenn ein Bot eine gute Möglichkeit darstellen könnte die deutsche mit der engl. WP abzugleichen und anschließend die Ergebnisse auf die kleineren WP zu übertragen. Kolossos 18:12, 24. Nov 2005 (CET)

Mit so einer Variablen geht das nach meiner Meinung nicht. Eine eindeutige Kennung sollte es schon sein, sonst entstehen manche dieser Objekte doppelt, dreifach bis hundertfach. Es ist ja auch nicht der Sinn von Commons, Bilder mehrfach zu haben. -- Simplicius 18:21, 24. Nov 2005 (CET)

Singular oder Plural?

Eine kurze Frage: Ist es üblich, den Singular "Koordinate" für Koordinaten zu verwenden? Immerhin werden mehrere Koordinaten, nämlich Längen- und Breitengrad, angegeben. Zumindest die Wikipedia-Artikel, die ich kurz überflogen habe, bestärken mich in meinem Sprachgefühl. Ich befasse mich allerdings nicht jeden Tag mit solchen Dingen, deshalb bin ich mir da nicht ganz so sicher.

Die Koordinate besteht aus dem Wert des Längen- und des Breitengrades. Das Kap der guten Hoffnung hat also genau eine Koordinate. Mehrere Kaps, also Kap Arkona, Kap Horn und ..., besitzen jeweils eine Koordinate und haben zusammen mehrere Koordinaten. Singular ist also durchaus üblich. --sk 18:01, 24. Nov 2005 (CET)

Hm. Ich bin mir da eben nicht ganz so sicher. en:Coordinates (mathematics) sagt dazu: The coordinates of a point are the components of a tuple of numbers used to represent the location of the point in the plane or space. Demnach ist eine Koordinate ein Eintrag eines Tupels. Im zweidimensionalen Fall (wie bei den Geokoordinaten) hätten wir dann zwei Koordinaten pro Punkt. Entweder ist beides möglich, oder an irgend einer Stelle in der Wikipedia wird die Bezeichnung im falschen Numerus verwendet. --zeno 22:14, 24. Nov 2005 (CET)

Also das wiederspricht dem deutschen Sprachgebrauch, meiner Meinung nach. -- sk 23:15, 24. Nov 2005 (CET)

Aus dem Artikel "Koordinatensystem": Man fasst die Koordinaten eines n-dimensionalen Raumes dann auch als ein n-Tupel von Koordinaten auf. Der Satz ist IMHO trotzdem nicht so gut formuliert. Es müsste wenn dann heißen "Koordinaten in einem n-dimensionalen Raum" --zeno 21:14, 25. Nov 2005 (CET)

*grins* der Satz ist ja schon sprachlich falsch, "Koordinaten sind n-Tupel von Koordinaten". GuidoD 22:26, 2. Dez 2005 (CET)

News bei Heise Online

Hi Leute, unser kleines Projekt wurde gerade prominent bei Heise Online verlinkt Siehe hier! -- sk 11:04, 29. Nov 2005 (CET)

... und hier grad' noch einer von Heise. Interessant die einleitenden Worte: "Entscheidend für den Erfolg eines Wiki sei die Strukturierung der verfügbaren Information.". Dies ist ja ganz in Sinne des Projektes hier, welches sich zur Strukturierung Vorlagen bedient - und eben Kategorien. -- Geonick 19:37, 29. Nov 2005 (CET)

Lustig fand ich ja den Verweis auf http://www.semapedia.org/ , die den umgekehrten Weg wie wir gehen, und in der realen Welt Barcode-Etiketten für einen Wikipedia-Link befestigen wollen. Da ich aber davon ausgehe, dass in Zukunft eh jedes Handy und jeder PDA ein Ortungssystem hat ist das vielleicht garnicht nötig. Kolossos 22:38, 29. Nov 2005 (CET)

Ich überlege mir gerade ob wir einigen Politikern so eine Barcode-Etiketten auf die Stirn kleben sollten, ich vergesse doch immer deren Namen und ihre Parteimitgliedschaft. ;-) -- sk 09:53, 30. Nov 2005 (CET)

Neue KML

Hallo Leute, die neue deutsche KML ist da. 20609 Punkte! In einem Monat gut 2000 neue Punkte! Respekt. Kleine Neuerung: alle Unterordner wurden noch mal regional nach Kontinenten, Ländern und teilweise auch Bundesländer unterteilt, dadurch sind die Listen nicht mehr ganz so lang und man findet die meisten Objekte schneller. Kleiner Service für Kolossos: Einwohner und Artikelgröße sind sind direkt in der KML integriert. :-) Viel Spaß. -- sk 21:10, 30. Nov 2005 (CET)

"Museum" ist doppelt - einmal unter "Kultur" und einemal unter "Sport und Freizeit". --Fuzzy 00:45, 1. Dez 2005 (CET)

Mist, eigentlich hatte ich den Fehler behoben, da muss ich noch mal fix schauen. -- sk 09:45, 1. Dez 2005 (CET)

Also, da hast du glaube ich noch die alte Datei erwischt. Ich hab mir die Datei extra noch mal heruntergeladen und angeschaut. Museum ist ein Unterordner von "Sport und Freizeit" welches wiederum ein Unterordner von "Kultur" ist. Genau so wie es sein sollte. -- sk 09:56, 1. Dez 2005 (CET)

Stimmt. Sorry, was wohl irgendein Cache-Fehler. --Fuzzy 11:59, 3. Dez 2005 (CET)

Wo kann man die KMl-Datei runterladen? --ALE! ¿…? 14:58, 5. Dez 2005 (CET)

KML. -- Simplicius 15:01, 5. Dez 2005 (CET)

Anzeige Koordinaten in den Datenboxen im IE

Seit gestern abend hat sich die Höhe des Koordinatenfeldes innerhalb aller Datenboxen verdoppelt, obwohl sonst eine Zeile ausreichte - seit heute morgen wird die untere Zeile rechts durch einen breiten, durchgehenden Strich verziert. Was ist da wieder passiert? Rauenstein 11:09, 4. Dez 2005 (CET)

Und nun ist das Problem auf wundersame Weise weg, tss Rauenstein 11:17, 4. Dez 2005 (CET)

http://de.wikipedia.org/w/index.php?title=Vorlage:Koordinate_Text_Artikel&action=history – sorry für meinen Teil. --BLueFiSH ?! 11:49, 4. Dez 2005 (CET)

Typen und Kategorien

Verzeichnissbaum

Vorab:Ich war in den letzten Tagen nicht ganz untätig, sondern habe mich etwas intensiver mit den Kategorien beschäftigt. Dabei ist folgender dynamischer Verzeichnisbaum entstanden. Alles weitere unter meta:Verzeichnisbaum.

Sozusagen als Abfallprodukt ist es mir nun möglich beliebige Listen von Artikeln zu generieren die zu einer Kategorie (z.B. Berg oder Museum) inkl. der Unterkategorien gehören. Mit einem Webserver auf dem die Wikipedia-DB Tabellen "page" und "categorylinks" könnte man damit dynamisch die bereits erwähnten spezial KML-Karten erzeugen. Andererseits könnte man somit bestimmen welches Icon ein Artikel in einer Karte bekommen soll.

Die beiden Tabellen (zusammen 40 MB) sind wenn man Konsolen-Zugriff auf eine Datenbank hat, eigentlich ganz gut zu händeln. Nur leider steht mir keine MySQL-Konsole mit Internetansschluss zur Verfügung und der Toolserver läuft vielleicht erst nächstes Jahr. Kolossos 23:49, 5. Dez 2005 (CET)

Kolossos, das ist der Hammer, was du da mit dem Verzeichnisbaum gemacht hast! Das zeigt, wie man mit mehreren Kategorien pro Artikel umgehen kann und dass es möglich ist, Artikel mit strukturierten Informationen zu ergänzen. Andererseits zeigt es auch, welcher Unsinn zum Teil in Kategorien gepackt wird; d.h. dass hier noch erhebliches Verbesserungspotential drin liegt (vielleicht hat jemand einen Draht zu 'Qualitätssicherern'?). --Geonick 00:40, 8. Dez 2005 (CET)

Reduziert auf Kategorien, in denen Koordinaten drin stecken sollte Verzeichnisbaum auch schon wieder anders aussehen. Arcy 09:52, 8. Dez 2005 (CET)

Schöne Sache. Musste auch noch mal in den archivierten Diskussionen zu diesem Thema rumstöbern. Arcy 09:52, 8. Dez 2005 (CET)

Der m:Toolserver ist echt eine nette Sache. Das neue Programm ist zwar noch nicht ganz fertig (Steuerung nur über die URL möglich,...), mich würde trotzdem mal eure Meinung dazu interesssieren. http://tools.wikimedia.de/~kolossos/georef/rek-cat.php?ober=Bauwerk_in_Hamburg&Templ=Stub,Koordinate_Artikel,Koordinate_Text,Koordinate_Text_Artikel

Nach meinen Tests arbeitet der Toolserver ohne merkbaren Zeitverzug (im allgemeinen war die Rede von 5 min bis 1h Zeitverögerung).

Die Variable "ober" beschreibt die oberste Kategorie anhand derer sich das Programm runter arbeitet, hier also bitte nix zu allgemeines eintragen. Die Variable "Templ" beschreibt ein Feld von Vorlagen, wobei dann Artikel markiert werden, die diese Vorlage benutzen. Ich hoffe das Werkzeug hilft weiterhin bei verschiedenen Qualitätssicherungsmaßnahmen, bei denen es auf die Arbeitsteilung nach verschiedenen Themengebieten geht. Es ist aber meiner Meinung nach schonmal gut zu sehen wo noch Georef. -einträge in einer Region fehlen.

Wenn man somit die Artikel mit Georef.-vermerk effektiv aus der DB auslesen kann, könnte man sich auch einen in kurzen Abständen aktualisierenden Geo-Server vorstellen. Kolossos 16:37, 15. Dez 2005 (CET)

Schick! Funktioniert aber noch nicht ganz richtig. Bei Oberkategorie "München" bekommt man nur eine leere Seite mit dem Text "M?en" zurück. Wenn man stattdessen "Oberbayern" eingibt, bekommt man auch München, aber die Moschee in Sendling ist dort unter Kategorie:Oberbürgermeister (München) eingeordnet?!

Unter "Bayern" bekommt man auch Frankfurt am Main, aber das ist dank Kategorie:Rhein-Main tatsächlich so vermurkst in der Wikipedia eingetragen. --Fuzzy 23:06, 18. Dez 2005 (CET)

Kategorie/Vorlage für fehlende Geodaten

Wie wär es mit einer Kategorie bzw. Vorlage für Artikel mit fehlenden Geodaten? --Kingruedi 10:44, 16. Dez 2005 (CET)

Gibt es schon: Kategorie:Geografische Lage gewünscht --Raymond 10:58, 16. Dez 2005 (CET)

Wunderbar, so ich werd mich mal in hjl_get_Coor einarbeiten und hoffe mal, dass ich das Projekt ein wenig unterstützen kann. --Kingruedi 19:25, 16. Dez 2005 (CET)

Spendenaufruf

Schon Lösungen wie man diesmal damit umgeht? --Saperaud ☺ 00:17, 17. Dez 2005 (CET)

Achso, du meinst die Vorlage rechtsoben. Hast du schon das Interview [5] mit Jimbo gelesen? Ich weiß nicht wie lange die Aktion dauert. Kann man da für die Zeit des Spendenaufrufs die Koordinaten nach rechtsunten setzen? Kolossos 14:06, 17. Dez 2005 (CET)

Ist voerst eh erledigt, da der Aufruf nicht ganz ins Eck geht. Grüße, ElRakı ?! 14:15, 17. Dez 2005 (CET)

{{Benutzer:Kolossos/georef-Test|50_50_00_N_12_55_00_E_type:city(247589)_region:DE-SN|50° 50' N, 12° 55' O}}

Das ist ja wohl Auflösungsabhängig ob ich die beiden Vorlagen ins Gehege kommen. Vielleicht funktioniert ja eine Vorlage in der Art siehe rechts unten. Scheitert allerdings am Internet-Explorer.

Hab ansonsten erstmal einen Zeilenumbruch eingefügt. Kolossos 14:49, 17. Dez 2005 (CET)

Weihnachtsedition

Hallo Leute, die neue KML-Weihnachtsedition ist da! Die letzte KML-Datei der deutschen Wikipedia wurde im Dezember 909 Mal heruntergeladen. Die englischsprachige Version 327 Mal. Die neuen Dateien enthalten jetzt 21457 (de) und 33801 (en) Punktsätze. Die deutsche Version wirkt schon sehr aufgeräumt, da die Leute fleißig type und region einsetzen. In der englischen Version gibt es noch starken Nachholebedarf. Nur 2714 Mal hab ich dort eine "region" in der Koordinate und 1697 Mal einen "type" gefunden. Wer also über Weihnachten nix zu tun hat, kann sich dort ja mal austoben. :-) Zum Download! Viel Spaß mit den neuen KML-Dateien. -- sk 21:33, 18. Dez 2005 (CET)

Danke für das nette Geschenk! Schöne Weihnachten, fragwürdig ?! 21:40, 18. Dez 2005 (CET)

Wenn ich mich nicht irre, ist das die erste KML, in der keine deutschen Städte mehr im arabischen Meer rumschwimmen... :) --Fuzzy 23:08, 18. Dez 2005 (CET)

Ich habe dann mal gleich die dynamische Version der englischen WP auf dem Meta:Toolserver eingebaut, die deutsche folgt sicher auch bald. Alles weitere im Artikel.Kolossos 21:17, 19. Dez 2005 (CET)

Frage zu Vorlagen

Sind die drei Vorlagen nur zur Verortung eines Artikels da? Also um weitere Koordinaten in einem Artikel zu nennen, gibt es nichts? Beispiel: Museum mit Aussenstelle oder so. -- Simplicius 15:18, 20. Dez 2005 (CET)

Genau. Ich habe mal nachgezählt in einem durchschnittlichen Artikel einer Großstadt wie Chemnitz in der nicht für jedes Museum oder Theater ein eigener Artikel vorhanden ist, gibt es ca. 100 Objekte die man georef. könnte, wenn man wollte. Der Artikel wäre dann aber wahrscheinlich optisch und für andere Bearbeitungen durch seine Überfüllung versaut.

Für die maschinentechn. Auswertung müßte in der Vorlage zumindestens der Name des Objekte wiederholt werden. Bsp.: {Koordinate Teilobjekt|Museum XY Außenstelle 2|....} Und was nützen einem die Georef. eines Objektes wenn man die Öffnungszeiten oder die Postadresse wissen möchte? Kolossos 16:08, 20. Dez 2005 (CET)

Zu letzerem habe ich noch ein Meinungsbild in Vorbereitung, ob zum Beispiel die Angabe von Adresse und ÖPNV-Haltestelle bei solchen Objekten wie Museen, Theatern und ähnlichen öffentlichen Institutionen überhaupt toleriert wird.

Für alle anderen Fälle sage ich "Aussenstelle", weil das ja in der Regel keinen eigenen Artikel rechtfertigt.

Wenn man auf die Anzeige verzichten würde und die Koordinate nur für die Datenbank/KML verwenden täte, würde ein Baustein {{Koordinate versteckt|Bezeichnung|...}} auch reichen? -- Simplicius 16:37, 20. Dez 2005 (CET)

SQL-Abfrage mit Mediawiki 1.5/1.6

Ist die Abfrage für Mediawiki 1.5 so sinnvoll formuliert? SELECT page_title, SUBSTRING(SUBSTRING(old_text FROM INSTR(old_text,'{{Koordinate Text Artikel|' )), 1, INSTR(SUBSTRING(old_text FROM INSTR(old_text,'{{Koordinate Text Artikel|' )),'}}')+1) AS 'Koordinate' FROM page,text WHERE old_text LIKE "%{{Koordinate Text Artikel%" AND page_latest = old_id LIMIT 10; Wäre ja nicht schlecht, wenn auch dafür Beispiele angegeben wären. --Fuzzy 21:23, 20. Dez 2005 (CET)

Cat Scan

Da das Georeferenzieren von Artikeln doch Ortskenntnis voraussetzt ist es schön, dass auf meine Anregung hin von Benutzer:Duesentrieb das Programm Cat Scan geschrieben wurde welches in Echtzeit Kategorien auf dem Toolserver durchscannt und bestimmte Vorlagen markiert. Also viel Spaß damit, und bitte keine allzu allgemeinen Categorien benutzen. Kolossos 23:00, 21. Dez 2005 (CET)