Wikipedia:WikiProjekt Georeferenzierung/Archiv/Vorlagen

Vorbereitung Meinungsbild

Das Wikiprojekt Georeferenzierung hat sich zur Aufgabe gesetzt, in der deutschsprachigen Wikipedia Artikel, die einen ein Raumbezug aufweisen, zu georeferenzieren.

Dadurch sind im Wesentlichen zwei Dienste möglich:

• Die Hyperlinks in den Artikeln übergeben die Parameter an den Server Kvaleberg. Hier sind eine Reihe von Geodiensten verfügbar (Beispiel: Reichstagsgebäude).
• Zum anderen sind Auszüge der Koordinaten aus der Datenbank möglich (string-Suche per SQL), die Stefan Kühn auf seiner Homepage für Google Earth und NASA World Wind anbietet: Geokoordinaten aus Wikipedia.

Die Hauptdiskussion des Wikiprojekts Georeferenzierung findet hier statt. Hier auf dieser Seiten sollen nur die Vorlagen neu diskutiert werden.

Ausgangssituation

Es gibt momentan drei Grundtypen

• ({Koordinate Artikel|...}} als Standardform für Artikel mit Platzierung am Artikelende
• {{Coordinate Text|...}} für die Verwendung innerhalb des Fliesstextes
• {{Coordinate Text Artikel|...}}) für die Verwendung in einer Infobox

Wenn alle Parameter wie empfohlen gesetzt sind, sieht die Vorlage zum Beispiel so aus (am Beispiel Reichstagsgebäude):

 {{Coordinate Artikel|52_31_07.00_N_13_22_34.00_E_type:landmark_region:DE-BE|52° 31' 07" N, 13° 22' 34" O}}

Ferner existieren aber auch Vorlagen für Infoboxen, die eigene Systeme betreiben:

• Bergtabelle Koordinaten (Beispiel: Zugspitze, Ätna)
• Infobox Polen (Beispiel: Warschau)
• ...

Entwurf

Grundzüge:

1. neu gestaltete Vorlagen, in denen die Koordinaten nicht mehr - wie bisher - doppelt eingegeben werden müssen
2. mehrere Zeilen statt einer Bandwurmzeile, die durch jeden neu eingeführten Parameter immer länger werden wird
3. drei Grundtypen, die auch in den Infoboxen eingesetzt werden sollen, aber nun auch die Angabe mehrere Objekte in einem Artikel erlauben

Ziel: Vereinfachung des Systems für alle Anwender und Entwickler von Infoboxen. Auch das Auswerten der Datenbank soll erleichtert werden.

   {{Coordinate Artikel/Text/Text Artikel
     | Breite_G = xx | Breite_M = xx | Breite_S = xx.xx | Breite_NS = x
     | Laenge_G = xx | Laenge_M = xx | Laenge_S = xx.xx | Laenge_OW = x
     | Typ =          (Sonstiges/Gewässer/Berg/Insel/Admin1/../Admin7) 
     | Region =       (nach ISO 3166-2)
     | Ausdehnung =   (optional, in m)
     | Name =         (optional, für Aufzählung mehrerer Objekte in einem Artikel, die eigene Bezeichnungen erhalten sollen)
     | Einwohner =    (optional für Ortschaften)
     | Höhe =         (optional, in m, für Berge und Pässe, in Metern)
   }}

Am Beispiel Reichstagsgebäude:

   {{Coordinate Artikel
     | Breite_G = 52 | Breite_M = 31 | Breite_S =  7.00 | Breite_NS = N
     | Laenge_G = 13 | Laenge_M = 22 | Laenge_S = 34.00 | Laenge_OW = E
     | Typ = Sonstiges 
     | Region = DE-BE
     | Ausdehnung =  200
   }}

Man muss sich dabei auch vor Augen führen (zum Beispiel bei den Infoboxen), dass Open Source nur dann funktioniert, wenn man hin und wieder auch gemeinsame Standards findet. Das gilt für Gestaltungen und Koordinatenauswertung auch.

Vorschlag

Testweise soll diese Vorlage für neu zu referenzierende Artikel eingesetzt werden dürfen. Nach einigen Monaten soll darüber abgestimmt werden, ob sie sich bewährt haben.

Vordiskussion

Fragen

Mich interessieren folgende Fragen:

1. Funktioniert eine Vorlage in der Vorlage auch dann, wenn sie Zeilenumbrüche enthält?
2. Wie funktioniert momentan der scale-Parameter für Kvaleborg? Ist eine Fallunterscheidung möglich, so dass nach einer Angabe des Durchmessers in Metern eine Übergabe des scale-Wertes erfolgen kann?
3. Braucht man wirklich ein scale, wo schon auch eine Fallunterscheidung nach Typ erfolgt? Ist der Parameter Ausdehnung also nicht überflüssig?

Hinsichtlich ISO 3166-2 fehlen wohl auch noch Unterartikel.

Die Koordinaten per zwei Zeilen habe ich aus einer englischen Vorlage abgekupfert. Bei Zugspitze fahren die aber auch andere superkurze Konstrukte wie Coordinates = {{coor dm|47|25|N|10|59|E|type:mountain}}. Immerhin muss man hier auch nichts doppelt eintippen, aber etwas übersichtlicher soll es ruhig sein.

Grüsse, Simplicius 12:47, 10. Mai 2006 (CEST)

Zu 1) Sollte eigentlich funktionieren. 2) und 3) Den Scalewert würde ich ganz abschaffen und dort den Durchmesser angeben. So lassen sich die Landmarke Kontinent und Säule besser voneinander trennen. -- sk 18:25, 10. Mai 2006 (CEST)

Sammlung bekannte Probleme

• Problem:ISO 3166-2 gilt nur für Landfläche. Ein Äquivalent für Meere ist noch nicht gefunden worden.
  Lösung: ?
• Problem: Die Regionangabe kann bei Seen, Naturschutzgebiete, Brücken derzeit nur einen ISO 3166-2 Code zulassen.
  Lösung: DE-BY/DE-BW also Regionen durch Schrägstrich trennen.
• Problem: Scale Funktion wird fast nicht genutzt. (Aktuell 861 Mal bei 31456 Artikeln mit Koordinaten (2,7%)).
  Lösung: Durchmesser in Meter angeben und dann bei z.B. KML-Generierung auf die dort mögliche Parameter anpassen.
• Problem: Beim Type city lassen sich die Stadtteile nicht klar von richtigen Ortschaften trennen.
  Lösung: neuer type:Stadtteil.
• Problem: Bei mehrere Koordinaten in einem Artikel benötigt man einen zusätzlichens Namensatribut.
  Lösung: neues Attribut name(Untergangstelle von U100)
• Problem: In den Infoboxen werden Daten mehrmals erfasst (z.B. Einwohner).
  Lösung: Standardisierte Attributnamen (wie bei Info Polen)
• Problem: Entstehung von tausenden Koordinatenvorlagen (Bergtabelle und Co), dadurch keine maschinelle Auswertung mehr möglich
  Lösung: Begrenzung auf vier Vorlagen (Text, Text Artikel, Artikel und die neuen Infobox Standardattribute (wie bei Info Polen))
• Problem: Administrative Einheiten sind derzeit auf zwei Ebenen begrenzt, (Bundesland, Kreis); In manchen Fällen könnte man mehr Ebenen brauchen (Stadtteile, Regierungsbezirk etc)
  Lösung: aus adm1nd wird adm1, aus adm1st wird adm2 und dann wären noch adm3, adm4 ... adm9 möglich.
• Problem: Nutzung von Fremdsprache bei Attributnamen und typangaben in der deutschsprachigen Wikipedia.
  Lösung: Per Bot alles eindeutschen.

(von sk)

Iso und Scale

• Zum Thema ISO 3166, ISO 3166-2 und Weltmeere: Tobias Conradi kritisiert, dass sie keine freien Codes seien. Er schlägt alternative Codes vor und hat sich dabei auch mit den Weltmeeren auseinandergesetzt (Free Geocodes). Ich habs noch nicht genau gelesen (in etwa, wer es in seinem Programm nutzen will, sei verpflichtet, sich die Schwarte als Printversion zu kaufen).
  Nun gibt es auch hier noch einen Ansatz, welche Meere man überhaupt mindestens unterscheiden könnte: Arctic Ocean, Atlantic Ocean, Baltic Sea, Eastern Mediterranean, Indian Ocean, Mediterranean Sea, North Atlantic Ocean, North Pacific Ocean, Pacific Ocean, South Atlantic Ocean, South China and Eastern Archipelagic Seas, South Pacific Ocean, Western Mediterranean. Man sollte sich daraus selbst etwas bauen, finde ich.
  Der Bereich AA ist zum Beispiel für private Zwecke reserviert und daraus hat er weitere Kombinationen entwickelt. Eventuell würde schon 1 Kennziffer für "extraterritional" reichen? -- Simplicius 19:22, 10. Mai 2006 (CEST)

Also das mit dem nicht frei ist sehr weit hergeholt. Der ISO-Sprecher meinte das eine Firma z.B: Softwareentwickler, der den aktuellen korrektesten Code haben möchte, ihn sich bei ihnen kaufen kann, aber zur Nutzung ist er völlig frei. Das Wikipedia ja so langsam alle Codes sammelt, sollten wir nix neues entwickeln. Bei den Meerescodes hab ich mal einige deutsch Institute angemailt. Mal sehen was da als Reaktion kommt. Im schlimmsten Fall machen wir uns eine eigene AA-.. Liste AA-OS=Ostsee etc. -- sk 18:59, 11. Mai 2006 (CEST)

• Zur Schrägstrich-Variante bei Bundesländern: Kurze Frage: was genau ist der Zweck. Bei Kvaleberg liesse sich doch nur eine Seite aufrufen, also müsste vermutlich der erste Wert bis zum Schrägstrich verwendet werden. Würde für die KML-Sammlung dann ein Objekt in beiden Bundesländern genannt werden? -- Simplicius 19:49, 10. Mai 2006 (CEST)

Richtig, es geht mir darum dass die Info enthalten ist, dieses Objekt liegt auf einer Grenze (Berge, Seen, Brücken etc.). In der KML wird es wahrscheinlich im ersten Land auftauchen oder man legt ein neuen Ordner DE/FR an. Mal sehen. -- sk 20:18, 10. Mai 2006 (CEST)

• Die Angabe des Durchmessers ist oben bereits vorgeschlagen, momentan "Ausdehnung" genannt und in "km" angedacht, was aber auch geändert werden kann.
  Nun muss man aber den Durchmesser noch eine eine Range-Angabe später umrechnen. Per Fallunterscheidung? Oder per Formel?
  Jetzt gerade versuche ich eine Formel zu bestimmen. Ist es ok, wenn man sagt, dass ein Objekt von x km Durchmesser mit 333 px Ausdehnung in Google Earth dargestellt werden soll? Gemessen für Trier:
  Range Google Earth [immer in m] = 2,60 * Durchmesser Objekt [in m] -- Simplicius 19:45, 10. Mai 2006 (CEST)

Die Ausdehnung würde ich lieber in Metern angeben lassen, damit nicht so viele Kommafelhler passieren. Meter kann man sich IMHO auch leichter vorstellen. -- sk 14:07, 11. Mai 2006 (CEST)

• Das Attribut "Name" ist im Vorschlag schon erfaßt. -- Simplicius 20:17, 10. Mai 2006 (CEST)

• Die Verwaltungsebenen Adm1/Adm2/../Adm9 sind im Vorschlag aufgenommen, müssten aber später in einer Tabelle näher erläutert werden. Das Stadtteil- bzw. Ortsteilproblem ist damit auch gelöst. -- Simplicius 08:32, 11. Mai 2006 (CEST)

• Geht die Bezeichnung "KoordinateNeu" erstmal in Ordnung? -- Simplicius 14:57, 11. Mai 2006 (CEST)

Nenne es doch "Koordinate" die alte Vorlage gibt es ja nicht mehr.--sk 15:14, 11. Mai 2006 (CEST)

Gemacht. Moment, die jetzige Vorlage heisst Koordinate. -- Simplicius 18:37, 11. Mai 2006 (CEST)

• Ein Problem ist bei dieser Koordinatenangabe die Einbettung in Fließtext oder? -- sk 15:14, 11. Mai 2006 (CEST)

Guter Punkt. Prozentual, wie oft kommt Vorlage Text etwa vor? -- Simplicius 18:37, 11. Mai 2006 (CEST)

• Wenn wir die Ausgabevarianten (T,A,TA) als extra Attribut z.B. "Ausgabe = Text Artikel" nehmen, brauchen wir statt drei nur noch eine Vorlage für die Koordinaten. Oder geht das technisch nicht? -- sk 18:55, 11. Mai 2006 (CEST)

Ich verstehe. Das wäre eine Fallunterscheidung hinsichtlich der Wiedergabe (drei verschiedene Formatierungen). Da müsste ich mal mehr nachlesen (hier und hier), was die Vorlagen betrifft. Melde mich später dazu noch mal. Sieht nicht so aus. Vielleicht kommt aber der switch in Frage(hier). Das sieht nach einer Möglichkeit aus. -- Simplicius 19:02, 11. Mai 2006 (CEST)

Hinweis zwischendurch: eine mehrzeilige Vorlage hindert nicht an der Einbettung in einen Fließtext. Das Fehlen einer Sekundenangabe stört die Wiedergabe der Koordinaten kaum und die Weitergabe an Kvaleberg gar nicht. Woran ich noch zu knacken haben werde: Fallunterscheidung für die Ausgabevarianten hinsichtlich der Formatierung usw. - in einer einzigen Vorlage. -- Simplicius 11:50, 12. Mai 2006 (CEST)

Gedankengänge für administrative Ebenen

Gebietskörperschaften in D

Mal laut nachgedacht über administrative Ebenen:

• Admin1: Staat (Beispiele: Deutschland, USA, treten in der WM gegeneinander an)
• Admin2: Bundesland (Beispiele: Nordrhein-Westfalen, Bayern, Hamburg, Berlin), State (Beispiele: Texas, Kalifornien), Kanton (Beispiel: Thurgau)
• Admin3: Regierungsbezirk (Beispiele: Oberfranken, Regierungsbezirk Arnsberg)

• Admin4: Kreis, Landkreis
• Admin5: Gemeindeverband, Samtgemeinde, Marktgemeinde
• Admin6: Gemeinde, kreiszugehörige Stadt (Beispiel: Hattingen)
• Admin7: Ortsteil, Siedlung, Hofgruppe, Gemarkung

bzw.

• Admin4: Kreisfreie Stadt (Beispiele Trier, Dortmund)
• Admin5: Stadtbezirk (Beispiel: Wattenscheid), Ortsbezirk (Beispiel: Trier-Ruwer/Eitelsbach)
• Admin6: Stadtteil (Beispiel: Essen-Steele)
• Admin7: Ortsteil, Siedlung (Beispiel: Margarethensiedlung)

Siehe auch: Gemeindearten in Deutschland

Die Pendants aus weiteren Staaten sollten eingeordnet werden. -- Simplicius 12:14, 12. Mai 2006 (CEST)

Das sieht ja schon mal sehr gut aus. -- sk 17:25, 12. Mai 2006 (CEST)

Danke. Ich hab noch einen weiteren Programmierschritt vor, heute abend. -- Simplicius 18:20, 12. Mai 2006 (CEST)

Gedankengänge zu Seegebieten

Also zum Problem mit dem Regionalcode für Meeresregionen hab ich mich mal bei den Meeresforschern umgehorcht. Am besten fand ich die Bemerkung "diese Anfrage kommt, glaube ich, mindestens ein Jahrzehnt zu früh, denn meiner Kenntnis nach gibt es sowas (noch) nicht". Also scheinbar haben die wirklich bis jetzt noch nix richtiges entwickelt. Hauptsächlich auch deshalb weil die Namensgebung nicht eindeutig ist. Zitat: "In Skandinavien bezeichnet man z.B. die Nordsee verständlicherweise auch als Westsee". Man hat mich auch auf einige interessante Publikationen hingewiesen. Am einfachsten zu verstehen war die Zahlencodes, aber es gibt auch Namensfestlegungen für Meeresregionen bzw. Unterwassserobjekte

• Zahlencodierung Nr 1
• Zahlencodierung Nr.2
• Namensfestlegungen für Meeresregionen bzw. Unterwassserobjekte

Es gibt auch eine Liste aus dem Jahre 1953 von der "The International Hydrographic Organization" (IHO), die die einzelnen Meere in kleiner Einheiten unterteilt. ( www.iho.shom.fr --> Publications -->Download List ---> Special Publications S-23). Dort gibt es auch drei Karten, die man als Grundlage nehmen muss.

Mein Vorschlag wäre jetzt, das wir uns auf einen selbstdefiniert einigen, die möglichst einfach zu verstehen und international genutzt werden kann. ISO 3166 bietet ja das Kürzel AA für eigene Definitionen an. Also wäre die Nutzung der englischen Namen sinnvoll

• AA-AO = Atlantischer Ozean (evt. nochmal nach Nord und Süd unterteilen AA-AN,AA-AS)
• AA-PO = Pazifische Ozan
• AA-BS = Baltisches Meer Usw.

Diese Liste müsste einmalig erstellt werden, so dass Doppelbelegung vermieden werden. Aber das sollte zu schaffen sein. -- sk 18:27, 12. Mai 2006 (CEST)

Zwischenstand Vorlage Koordinate (12. Mai 2006 23:57 Uhr)

@Stefan & Partner: Ich arbeite an Vorlage:Koordinate bzw. Vorlage Diskussion:Koordinate.

Stefan hat vorgeschlagen, die Art der Vorlage nicht durch den Namen der Vorlage festzulegen, sondern durch eine weitere Variable (Variante = Text/Artikel/ Infobox). Das habe ich mit einer Switch-Anweisung in der Vorlage hinbekommen. Es funktioniert.

Ausgearbeitet habe ich bereits die Variante "Text". So erscheinen für das Reichstagsgebäude wie gewünscht die Koordinaten im fließenden Text. Die anderen Varianten habe ich noch nicht fertiggestellt.

Die Typen werden wie gewünscht deutsch bezeichnet. Im Deutschen ist die Landmarke ein im Umkreis sichtbares Objekt, im Englischen eine Sehenswürdigkeit wie etwa ein Museum. Ich habe daher als Typ "Sonstiges" gewählt. Eine Switch-Anweisung wandelt es für Kvaleberg in "landmark" um. Theoretisch wären noch mehr Bezeichnungen möglich (etwa Museum, Theater, Staudamm, doch nur nach definierter Liste, der Rest wäre Sonstiges), für die man an Kvaleberg ein "landmark" weitergeben kann. Das sollte man noch einmal sacken lassen.

Die Stufen Admin1 bis Admin7 werden an Kvaleberg in Form von "country", "state", "adm1st", "adm2nd", "city" weitergegeben.

Soll ich eine Formel einbauen, die aus der Ausdehnung des Objekts einen scale-Faktor an Kvaleberg weitergibt?

Gute Nacht erst mal, Simplicius 23:57, 12. Mai 2006 (CEST)

Als Landmarke kann man aber auch Orientierungspunkte anderer Art bezeichnen. Ich finde mit den landmark oder POI (Point of interest) sollten wir weiter als Landmarke bezeichnen. Durch diese weitergefassten begriff passt dort problemlos alles rein. -- sk 08:20, 13. Mai 2006 (CEST)

Ja, auf Neudeutsch habe ich den POI (interessanter Ort) noch dazugesetzt, der wird als landmark nach Kvaleberg weitergegeben.

Jedenfalls habe ich es so verstanden, dass deutsche Begriffe für den Typ gewünscht waren. Die Übersetzung erfolgt recht übersichtlich mit einer Switch-Anweisung, die es noch gar nicht so lange gibt.

Was mir dabei auffällt: Man könnte theoretisch auch Begriffe wie Staat oder Bundesland weiterfahren und für Orte und Gebietskörperschaften einen Parameter "Verwaltungsebene =" einführen so wie man auch Parameter für die Einwohner und die Höhe hat. Naja, mal schauen. -- Simplicius 10:49, 14. Mai 2006 (CEST)