Wikipedia Diskussion:WikiProjekt Georeferenzierung/Archiv4

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Wikipedia Diskussion:WikiProjekt Georeferenzierung/Archiv4#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Wikipedia_Diskussion:WikiProjekt_Georeferenzierung/Archiv4#Thema_1

Vorlagenbenennungs-Thematik

Formatvorlage:Berg

In der Formatvorlage:Berg werden die Koordinaten über eine weitere Vorlage:Bergtabelle Koordinaten in die Tabelle eingebunden. Bis jetzt wurden ca. 10 Berge so mit Koordinaten versehen. Nachteilig ist, dass neben {{Geokoordinate..}} und {{Geokoordinate..}} noch eine weitere Vorlage so hinzukommt, und die Abfrage nach Koordinaten immer komplexer wird. Wollen wir das so? Oder sollten wir da nicht fix eingreifen? -- sk 7. Jul 2005 15:54 (CEST)

Siehe eins tiefer, wenn mans in "KoordinateBerg" umbenennt, wär's doch in Ordnung. Die einzelnen Vorlagen an sich beinhalten ja gleich die Tabellenformatierung, da ist die Frage auch erstmal, ob die Formatvorlagen:Berg-Benutzer das überhaupt in dieser Art benutzen wollen. --BLueFiSH ?! 7. Jul 2005 17:30 (CEST)

Eine Vorlage umbenennen!

Derzeit muss man immer zwei SQL-Abfragen machen um die Geokoordinaten herauszufiltern, da die eine Vorlage "Geokoordinate" und die andere Vorlage "Koordinate" heißt. Da wir noch am Anfang des Projektes stehen, können wir noch recht problemlos einen verbesserten Standard durchsetzen. Mein Vorschlag wäre, einen der beiden Vorlagen umzubenennen. Wenn z.B. die "Koordinate" in "Geokoordinate-Text" umbenannt wird muss man nur noch "Geokoordinate" suchen und bekommt alle Ergebnisse. Oder es wird die "Geokoordinate" in "Koordinate2" umbenannt, dann muss man nur noch nach "Koordinate" suchen und bekommt alle Ergebnisse. Die erste Variante bevorzuge ich, da wir 2106 x "Geokoordinate" nutzen und nur 1212 x "Koordinate". -- sk 7. Jul 2005 15:54 (CEST)

"Koordinate2" find ich ganz in Ordnung und auf diese Weise könnte man auch eine "KoordinateBerg" einführen, dann wären die anderen auch glücklich. In der en:wp gibts ja auch "coor d", "coor dm" und "coor dms". "Koordinate" wird in Zukunft auch häufiger verwendet werden, nämlich wenn die Formatvorlagen um den Koordinatenlink erweitert werden. "Geokoordinate" nimmt man ja eher für Artikel, in die noch gar keine Koordinate eingetragen war. --BLueFiSH ?! 7. Jul 2005 17:27 (CEST)

Koordinate0 für Artikelreferenz (unsichtbar im Text aber oben eingeblendet), Koordinate1 für Textreferenzen (im Text eingeblendet und sonst nichts), Koordinate2 für Artikel-und-Text referen (im Text eingeblendet und am Artikelrand wiederholt). Ich find, das merkt sich ganz gut. GuidoD 9. Jul 2005 11:42 (CEST)

jo, das Koordinate2 find ich gut, dann würde aber diese am ehesten für Städte mit Formatvorlage passen. Eigentlich würde Koordinate2 rein logisch betrachtet, dann die am meisten verwendete werden und Koordinate0 mit Sicherheit die am wenigsten verwendete. Aber damits noch logischer ist: Koordinate1 + Koordinate2 = Koordinate3 ;-) --BLueFiSH ?! 12:49, 11. Jul 2005 (CEST)

OK, da keine weiteren Anmerkungen oder Proteste kommen, werde ich jetzt mal die Vorlagen erstellen. -- sk 20:48, 12. Jul 2005 (CEST)

Ich hab grad mal probiert wie die neuen sich jetzt machen und muss leider sagen, dass es bei Verwendung eines anderen Skins für viele inakzeptabel aussieht. Die Leute werden jetzt den Koordinatentext der "Koordinate3" doppelt sehen und dann noch mit inklusive Zeilenumbruch, was sich im Fließtext ganz besonders gut macht. Ich glaub da wirds dann viele Aufreger drüber geben... vielleicht sollten wir somit doch bei den Vorlagen bleiben, die den Output nur einmal ausgeben.. schade. --BLueFiSH ?! 21:45, 12. Jul 2005 (CEST)

Oder kann man es so einstellen, dass der Output oben rechts in der Ecke ausschließlich im Monobook angezeigt wird? --BLueFiSH ?! 21:46, 12. Jul 2005 (CEST)

Der Terminus "Koordinate2" deutet intuitiv nicht auf Georeferenzierung des Gesamtartikels. Noch dazu ist es in der derzeitigen Anlage so, dass es keine Vorlage:Koordinate1 gibt. Ich finde die derzeitige Ausgestaltung nicht hinreichend. {überarbeiten}. GuidoD 10:06, 18. Jul 2005 (CEST)

Dann schlag doch einen besseren Terminus vor, lieber Guidod. -- sk 12:56, 18. Jul 2005 (CEST)

Habe ich schon. Steht gleich da oben, datum 9. Juli. "0" für "nicht im text, nicht additiv, keine liste". "1" für "einmal im text, ein punkt in liste, mehrfache verwendung addiert je 1". Die "2", nunja, ist nicht uebereinstimmend mit der jetzt angefangenen variante 2/3. Wobei ich noch ueber nichts gestolpert bin, wo das drin auftaucht. Aber ihr werdet das schon durchdruecken. GuidoD 13:32, 18. Jul 2005 (CEST)

Ich denke die weitere Verwendung von "Koordinate" macht grade deswegen Sinn, weil an dieser nichts geändert werden muss. Bei einer Umbenennung werden nochmal etliche Artikel angefasst. Eine Zahlenneutrale Variante von "Geokoordinate" bzw. "Koordinate2" wäre evtl. "KoordinateGeo" oder was weiß ich. "Koordinate0" "Koordinate1" "Koordinate2" etc ist, wenn man unbedingt so will, genauso quatsch wie "Koordinate" "Koordinate2" "Koordinate3" nur mal so am Rande. Dann lieber gänzlich ohne Zahlen, die eh sich keiner so richtig merken kann, sondern gleich mit angehängten Text wie vorgeschlagen "Berg", oder "Box" oder sonstwas... --BLueFiSH ?! 15:55, 18. Jul 2005 (CEST)

Schon richtig, nur dass im Deutschen die Unterbestimmung i.d.R. durch Voranschreibung erfolgt. Ich hatte allerdings auch mal mit jemandem geredet, der die gleichzeitige Verwendung von {Koordinate} und {Geokoordinate} nicht sah - insofern ist das "Geo" auch nicht intuitiv. Man braeuchte sowas wie "KoordinateArtikel", was aber ziemlich lang ist. Vll KoordinateText oder KoordinateTitel oder KoordinateMeta ;-) ... GuidoD 16:10, 18. Jul 2005 (CEST)

Deswegen habe ich ja ganz oben vorgeschlagen Geokoordinate-Text (bzw. GeokoordinateText). Aber irgendwie wurden dann die Zahlen bevorzugt. Um jetzt möglichst schnell zu einem Ende der Diskussion zu kommen mache ich noch mal einen gewagten Vorstoß. Folgender Vorschlag:

• {Koordinate} für gesamten Artikel (rechts oben)
• {KoordinateImText} für Koordinaten in Text/Tabellen (nur dort wo es steht)
• {KoordinateUndImText} für gesamten Artikel + in Text/Tabellen (rechts oben und dort wo es steht)

Problem: Wir müssten alle noch mal umbenennen! Aber danach wäre Ruhe. Außerdem ist der Name der Vorlagen etwas lang, vielleicht wieß von euch ja einer einen kürzeren Namen, der sich einfach merken lässt. Wenn wir uns auf {Geokoordinate} festlegen könnten, dann hätten wir bei ca. 2100 Artikeln nix umzubenennen. Deswegen hab ich oben diesen Namen bevorzugt. Vielleicht kommen ja die Astronomen auch noch darauf den Sternartikeln Koordinaten zu geben. -- sk 16:15, 18. Jul 2005 (CEST)

Also, gerade {Koordinate} wuerde ich ungern aendern. Lass uns lieber noch ein paar Ersetzungen fuer Geokoordinate durchspielen. KoordinateRef, KoordinateLage, usw. Das Ding mit KoordinateGeo taugt uebrigens als Minimalkonsens, da es so grosse Aehnlichkeit zum bisherigen hat, und somit auch von all jenen verstanden wird, die hier vor Monaten mal reingeschaut haben. Mal anmerk, keine Vorzugsaeusserung. GuidoD 22:35, 18. Jul 2005 (CEST)

der begriff geokoordinate trifft fachlich auf alle varianten zu. er bezeichnet einen koordinate auf der erde. bei manchen artikel könnte es auch eine koordinate auf dem mond sein. koordinate als grundeinheit ist daher eine gute wahl. was eine geokoordinate wohl nicht ist: die position eines markup innerhalb einer wikipedia-seite. die schwirrt nämlich elektronisch irgendwo in der weltgeschichte herum. das problem ist IMO die vermischung von zwei sachverhalten: koordinaten und textgestaltung. bei dem markup von bildern gibt es ja auch nicht tausend versionen von <bild>: <bild links>, <bild klein>, <bild etc> sondern eine klare trennung von dem was es ist - ein "bild" und wie es erscheinen soll: [[Bild:Smile.png|left|thumb|Ein Smiley]]. ebendso sollte bei geokoordinaten vorgegangen werden: {{Koordinate|....|position:upperright}}. Arcy 23:46, 18. Jul 2005 (CEST)

Den Vorschlag von Acry finde ich sehr gut. Schade dass diese Variante mir nicht schon eher eingefallen ist.

• {{Koordinate|....|style:Text}}
• {{Koordinate|....|style:Artikel}}
• {{Koordinate|....|style:TextundArtikel}}

Wäre das eine Lösung? Können wir das mit den Möglichkeiten bei den Vorlagen umsetzen? Wenn jemand sich dazu in der Lage sieht, dann bitte versuch es einfach mal in einer eigenen Vorlage umzusetzen. Wenn es dann funktioniert, dann können wir das ja für die Vorlage Koordinate machen. -- sk 08:15, 19. Jul 2005 (CEST)

Gute Idee, aber bekommen wir da nicht Probleme mit der Vorlage, weil man dann nicht genau weiß, bei welchen Artikel diese Angaben enthalten sind und bei welchen nicht? "style:Text" sollte dann als Standard definiert sein, dann müsste man evtl. erstmal nur die anderen Vorlagen auf diese anpassen.. --BLueFiSH ?! 10:40, 19. Jul 2005 (CEST)

• könnten wir bei der Gelegeheit nicht das Prinzip aus der EN:WP verwenden, um ein einheitliches Aussehen der Ausgaben zu erzwingen? (dabei kommt dann {{Koordinate|48|46|36|N|121|48|51|W|type:isle_region:DE-BE|style:Text}} bei raus) Müsste man dann allerdings die "_" durch "|" ersetzen und eine entsprechende Ausgabe basteln. Ist dann zwar (falls es wirklich mal im Fließtext als Satz geschrieben wird) nicht mehr optisch so schön weil das "nördliche Breite" nicht ausgeschrieben da steht, aber wer will sowas eigentlich wirklich lesen? nen einfaches N oder O reicht ja auch. Dadurch könnte man auch die von GuidoD vorgeschlagene Umbruchsvariante mit den vielen HTML-Sonderzeichen verwenden, die ja sicherlich von den wenigsten verstanden, akzeptiert und verwendet wird. Nochwas: In der EN:WP wird ja die Vorlage in den Weblinks platziert und erhält dadurch große Aufmerksamkeit. Ich fänd es auch schön, wenn es weiterhin (bei Monobook) oben rechts stehen bleibt, aber auf jeden Fall in anderen Skins (und bei Monobook zusätzlich) als Unterpunkt bei den Weblinks auftauchen könnte, das würde eine größere Leserschaft abdecken und vielen ist ja bekanntermaßen gar nicht klar, dass sich hinter "koordinate sowieso" eine Seite mit vielen Mapping-Tools verbirgt.. --BLueFiSH ?! 10:40, 19. Jul 2005 (CEST)

Eine einheitliche/koordinierte Vorgehensweise mit der EN:WP halte ich bezüglich der Vorlage auch für sinnvoll und angebracht.
Den Hinweis, dass viele Leser mit Koordinate nicht viel anfangen können, bzw. nicht wissen was sich dahinter verbirgt (Karten) sollte bei einer Umbenennung der Vorlage berücksichtigt werden. Wieso das Kind nicht mit seinem Namen nennen: {{Karte|...}} ? Arcy 16:53, 19. Jul 2005 (CEST)

Neeeeee, Koordinate ist erstmal nur die semantische Auszeichung des Textbereiches, was damit an Funktionalitaet verbunden wird, naemlich eine Karteneinblendung, das ist methodisch zweitrangig. Mit anderen Worten {Karte} ist enger gefasst als {Koordinate}.

- Zurück zum Thema, mit völlig anderen Auszeichungsvarianten. Die meisten davon lassen sich nicht mit der Funktionalität von Vorlagen darstellen, technisch hat man da nicht die Flexibilität alle Varianten mit drei/vier/fünf Koordinatenteilen plus Rudel an Hilfsmarkern mal eben zu verarbeiten. Mal hier bitte nicht die WikiFunktion [Bild] mit einer VorlagenInstanz {Bild}abgleichen. Wer sich versuchen will, bitte, ich lass mich durch Beispiel vom Gegenteil überzeugen, glaube aber nicht dran.

- Wer zu einer neuen WikiFunktion greifen will, der darf sich übrigens auch gleich Auszeichungen für verbundene Koordinaten überlegen, etwa Straßenzüge oder flächige Objekte. Die vielgeliebten Google Earth kml-dingsda kennen sowas, und das hat schon seinen Grund. Aber ich kann da nur immer wieder hinausrufen: um variantenreiche Auszeichungsformate kümmere man sich später, jetzt geht es erstmal um die Verortung vorhandener Artikel, und die Idee der Umbenennung einer Vorlage dient ursprünglich auch nur genau diesem Zweck: nämlich beide Varianten so zu haben, dass sie in einer Sql Anfrage mit LIKE Operator erfasst werden.

- Insofern, brauchen wir einfach zügig eine Benennung. Koordinate2 haut mir jeder um die Ohren, schon jetzt bekommen ich alle drei Tage die Anfrage, warum denn Koordinate und Geokoordinate beide in einem Artikel auftauchen. Der hiesigen Diskussion nach scheinen die Begriffe Koordinate/Text und Koordinate/Artikel als besonders intuitiv zu sein. Also nehme man doch einfach die Langvariante, Geokoordinate wird KoordinateArtikel, wir nehmen KoordinateUndArtikel hinzu, und lassen Koordinate erstmal so wie ist. Deal? GuidoD 09:03, 20. Jul 2005 (CEST)

"KoordinateUndArtikel" ist nicht schön. Wenn, dann "Koordinate Text und Artikel", aber das ist schon wieder so lang, dass "Koordinate3" besser ist. --Fuzzy 09:35, 20. Jul 2005 (CEST)

Ich mag die Laenge ja auch nicht, aber Koordinate3 versteht halt keiner. Darum. GuidoD 10:41, 20. Jul 2005 (CEST)

Ich habe es sofort verstanden. Der Teil, der hinter dem | kommt, ist da deutlich komplizierter... --Fuzzy 17:43, 20. Jul 2005 (CEST)

Ich finde Koordinate123 auch sehr eingängig; man muss sich nie überlegen, wie die Vorlage jetzt geschrieben wird (bei [ WikiProjekt Georeferenzierung/Archiv4] bei IMDbVorlage:IMDb/Wartung/IMDb-Kennung fehlt brauche ich immer 10 Versuche) und wenn man das verhalten nicht mehr auswendig weiß probiert man halt alle 3 durch. --Habakuk <>< 18:29, 20. Jul 2005 (CEST)

Dann sollten wir das auch mit zur Auswahl stellen, oder? --Fuzzy 18:54, 20. Jul 2005 (CEST)

(Diskussion in nachfolgendem Abschnitt fortgeführt)

Abstimmung Koordinaten Vorlagen

Danke GuidoD, für die tolle Moderation der Diskussion. Ich glaube wir sind schon fast am Ziel. Dann halte ich mal fest {{Koordinate_Text}} und {{Koordinate_Artikel}} stehen soweit fest! (Hab den Unterstrich zur besseren Lesbarkeit eingefügt.)! Einzig die Frage wie {{Koordinate3}} mit Koordinaten im Text und am Artikelanfang jetzt heißen soll ist noch nicht festgemacht. Vorgeschläge wären {{Koordinate_Text_und_Artikel}}, {{KoordinateUndArtikel}} oder {{Koordinate_TuA}} (für Text/Tabelle und Artikel). Welche Vorlage wollt ihr haben? Stimmt bitte ab oder schlagt weitere vor -- sk 11:37, 20. Jul 2005 (CEST)

Ich kann einfache {Koordinate} unmöglich für eine Artikel-"Singularität" akzeptieren, ich denke da an zukünftige Mehrfachverwendung für Linien und Flächen. Die Verwendung von Koordinate als Oberbegriff und Anfügung der Verwendungmodi mit zwichenliegenden Leerzeichen, hmmm, ja, geht so. Da kann man dann aber auch das "und" wieder weglassen, also {Koordinate_Text_Artikel} schreiben wenn man beide Verwendungen haben will. Ich hab im Nachfolgenden drei Varianten nachgetragen, und die Unterstriche durch Leerzeichen ersetzt (hoffe, das war auch so gemeint). Bis auf zwei Kontras halte ich alle für akzeptabel, habe mit Pro nur meine bevorzugten gekennzeichnet, aber eigentlich sind das nur die etwas kürzeren. GuidoD 12:23, 20. Jul 2005 (CEST)

findet ihr es nicht etwas übertrieben ein Meinungsbild zu machen für Wie nenne ich die Vorlage ?! ich meine am ende ist es doch sowas von egal?! ...Sicherlich ^Post 16:31, 20. Jul 2005 (CEST)

Nicht übertrieben, denn wir sprechen hier von tausenden von artikeln, die modifiziert werden. Einzige alternative: alles belassen, wie es ist. Obwohl, das trage ich gleich mal unten dran. GuidoD 16:41, 20. Jul 2005 (CEST)

Bitte nicht weiter abstimmen! Das Meinungsbild endete am 29. Juli 2005.

Koordinate für gesamten Artikel

• {{Koordinate Artikel}}
  •  Pro -- sk
  •  Pro -- GuidoD GuidoD 14:25, 22. Jul 2005 (CEST)
  •  Kontra --HaSee 19:39, 20. Jul 2005 (CEST)
  •  Pro --Mazbln 22:03, 20. Jul 2005 (CEST)
  •  Pro --MikeKrueger 22:32, 21. Jul 2005 (CEST)
  •  Pro --BLueFiSH ?! 21:34, 22. Jul 2005 (CEST)
  •  Pro -- Nonanet 11:48, 24. Jul 2005 (CEST)
  •  Pro --Trainspotter 13:31, 24. Jul 2005 (CEST)
  •  Pro --Jwnabd 00:03, 26. Jul 2005 (CEST)
  •  Pro --Kwerdenker 08:10, 26. Jul 2005 (CEST)
  •  Pro -- Fleasoft 13:44, 27. Jul 2005 (CEST)
  •  Neutral -- Mkaiser30 17:38, 30. Jul 2005 (CEST)

• {{KoordinateArtikel}}
  •  Kontra -- sk
  •  Kontra -- Fuzzy 17:43, 20. Jul 2005 (CEST)
  •  Neutral -- GuidoD GuidoD 14:25, 22. Jul 2005 (CEST)
  •  Kontra --HaSee 19:39, 20. Jul 2005 (CEST)
  •  Neutral --Mazbln 22:03, 20. Jul 2005 (CEST)
  •  Neutral --BLueFiSH ?! 21:34, 22. Jul 2005 (CEST)
  •  Neutral -- Nonanet 11:48, 24. Jul 2005 (CEST)
  •  Kontra -- Mkaiser30 17:38, 30. Jul 2005 (CEST)

• {{Koordinate}}
  •  Pro -- sk
  •  Pro -- Fuzzy 17:43, 20. Jul 2005 (CEST)
  •  Kontra -- GuidoD
  •  Kontra --Mazbln 22:03, 20. Jul 2005 (CEST)
  •  Kontra --BLueFiSH ?! 21:34, 22. Jul 2005 (CEST)
  •  Kontra -- Nonanet 11:48, 24. Jul 2005 (CEST)
  •  Pro -- Mkaiser30 17:38, 30. Jul 2005 (CEST)

• {{Koordinate2}}
  •  Pro --Habakuk <>< 18:19, 20. Jul 2005 (CEST)
  •  Pro -- Fuzzy 18:54, 20. Jul 2005 (CEST)
  •  Pro --HaSee 19:39, 20. Jul 2005 (CEST)
  •  Kontra -- GuidoD
  •  Neutral --Mazbln 22:03, 20. Jul 2005 (CEST)
  •  Pro --BLueFiSH ?! 21:34, 22. Jul 2005 (CEST)
  •  Kontra -- Nonanet 11:48, 24. Jul 2005 (CEST)
  •  Neutral -- Mkaiser30 17:38, 30. Jul 2005 (CEST)

Koordinate in Text / Tabelle

• {{Koordinate Text}}
  •  Pro -- sk
  •  Pro -- Fuzzy 17:43, 20. Jul 2005 (CEST)
  •  Pro -- GuidoD GuidoD 14:25, 22. Jul 2005 (CEST)
  •  Kontra --HaSee 19:42, 20. Jul 2005 (CEST)
  •  Pro --Mazbln 21:58, 20. Jul 2005 (CEST)
  •  Pro --MikeKrueger 22:32, 21. Jul 2005 (CEST)
  •  Pro --BLueFiSH ?! 21:34, 22. Jul 2005 (CEST)
  •  Pro -- Nonanet 11:49, 24. Jul 2005 (CEST)
  •  Pro --Trainspotter 13:31, 24. Jul 2005 (CEST)
  •  Pro --Jwnabd 00:03, 26. Jul 2005 (CEST)
  •  Pro --Kwerdenker 08:10, 26. Jul 2005 (CEST)
  •  Pro -- Mkaiser30 17:45, 30. Jul 2005 (CEST)

• {{KoordinateText}}
  •  Kontra -- sk
  •  Kontra -- Fuzzy 17:43, 20. Jul 2005 (CEST)
  •  Neutral -- GuidoD
  •  Kontra --HaSee 19:42, 20. Jul 2005 (CEST)
  •  Neutral --Mazbln 21:58, 20. Jul 2005 (CEST)
  •  Neutral --BLueFiSH ?! 21:34, 22. Jul 2005 (CEST)
  •  Neutral -- Nonanet 11:49, 24. Jul 2005 (CEST)
  •  Kontra -- Mkaiser30 17:45, 30. Jul 2005 (CEST)

• {{Koordinate}}
  •  Pro -- GuidoD
  •  Pro -- sk
  •  Kontra --HaSee 19:42, 20. Jul 2005 (CEST)
  •  Kontra --Mazbln 21:58, 20. Jul 2005 (CEST)
  •  Pro --BLueFiSH ?! 21:34, 22. Jul 2005 (CEST)
  •  Kontra Nonanet 11:49, 24. Jul 2005 (CEST)
  •  Pro -- Fleasoft 13:46, 27. Jul 2005 (CEST)
  •  Neutral -- Mkaiser30 17:45, 30. Jul 2005 (CEST)

• {{Koordinate1}}
  •  Pro --Habakuk <>< 18:19, 20. Jul 2005 (CEST)
  •  Pro -- Fuzzy 18:54, 20. Jul 2005 (CEST)
  •  Pro --HaSee 19:42, 20. Jul 2005 (CEST)
  •  Neutral -- GuidoD
  •  Pro --Mazbln 21:58, 20. Jul 2005 (CEST)
  •  Neutral --BLueFiSH ?! 21:34, 22. Jul 2005 (CEST)
  •  Kontra -- Nonanet 11:49, 24. Jul 2005 (CEST)
  •  Neutral -- Mkaiser30 17:45, 30. Jul 2005 (CEST)

Koordinate in Text / Tabelle und gleichzeitig für ganzen Artikel (z.B. Städte)

• {{Koordinate Text und Artikel}}
  •  Pro -- sk
  •  Kontra -- GuidoD GuidoD 14:25, 22. Jul 2005 (CEST)
  •  Kontra --Habakuk <>< 18:19, 20. Jul 2005 (CEST)
  •  Kontra --HaSee 19:44, 20. Jul 2005 (CEST)
  •  Neutral --Mazbln 22:01, 20. Jul 2005 (CEST)
  •  Pro --MikeKrueger 22:32, 21. Jul 2005 (CEST)
  •  Neutral --BLueFiSH ?! 21:34, 22. Jul 2005 (CEST)
  •  Kontra -- Nonanet 11:51, 24. Jul 2005 (CEST)
  •  Pro -- Mkaiser30 17:43, 30. Jul 2005 (CEST)

• {{KoordinateTextUndArtikel}}
  •  Kontra -- GuidoD GuidoD 14:25, 22. Jul 2005 (CEST)
  •  Kontra -- Fuzzy 17:43, 20. Jul 2005 (CEST)
  •  Kontra --Habakuk <>< 18:19, 20. Jul 2005 (CEST)
  •  Kontra --HaSee 19:44, 20. Jul 2005 (CEST)
  •  Kontra --Mazbln 22:01, 20. Jul 2005 (CEST)
  •  Kontra --BLueFiSH ?! 21:34, 22. Jul 2005 (CEST)
  •  Kontra -- Nonanet 11:51, 24. Jul 2005 (CEST)
  •  Kontra -- Mkaiser30 17:43, 30. Jul 2005 (CEST)

• {{Koordinate Text Artikel}}
  •  Pro -- GuidoD GuidoD 14:25, 22. Jul 2005 (CEST)
  •  Kontra --HaSee 19:44, 20. Jul 2005 (CEST)
  •  Pro --Mazbln 22:01, 20. Jul 2005 (CEST)
  •  Pro --BLueFiSH ?! 21:34, 22. Jul 2005 (CEST)
  •  Pro -- Nonanet 11:51, 24. Jul 2005 (CEST)
  •  Pro --Trainspotter 13:31, 24. Jul 2005 (CEST)
  •  Pro --Jwnabd 00:03, 26. Jul 2005 (CEST)
  •  Pro --Kwerdenker 08:10, 26. Jul 2005 (CEST)
  •  Pro -- Fleasoft 13:47, 27. Jul 2005 (CEST)
  •  Kontra -- Mkaiser30 17:43, 30. Jul 2005 (CEST)

• {{KoordinateUndArtikel}}
  •  Kontra -- sk
  •  Kontra -- Fuzzy 17:43, 20. Jul 2005 (CEST)
  •  Neutral -- GuidoD GuidoD 14:25, 22. Jul 2005 (CEST)
  •  Kontra --Habakuk <>< 18:19, 20. Jul 2005 (CEST)
  •  Kontra --HaSee 19:44, 20. Jul 2005 (CEST)
  •  Kontra --Mazbln 22:01, 20. Jul 2005 (CEST)
  •  Kontra --BLueFiSH ?! 21:34, 22. Jul 2005 (CEST)
  •  Kontra -- Nonanet 11:51, 24. Jul 2005 (CEST)
  •  Kontra -- Mkaiser30 17:43, 30. Jul 2005 (CEST)

• {{Koordinate_TuA}} (für Text/Tabelle und Artikel)
  •  Pro -- sk
  •  Pro -- Fuzzy 17:43, 20. Jul 2005 (CEST)
  •  Kontra -- GuidoD
  •  Kontra --Habakuk <>< 18:19, 20. Jul 2005 (CEST)
  •  Kontra --HaSee 19:44, 20. Jul 2005 (CEST)
  •  Kontra --Mazbln 22:01, 20. Jul 2005 (CEST)
  •  Kontra --BLueFiSH ?! 21:34, 22. Jul 2005 (CEST)
  •  Kontra -- Nonanet 11:51, 24. Jul 2005 (CEST)
  •  Kontra -- Mkaiser30 17:43, 30. Jul 2005 (CEST)

• {{Koordinate3}}
  •  Pro --Habakuk <>< 18:19, 20. Jul 2005 (CEST)
  •  Pro -- Fuzzy 18:54, 20. Jul 2005 (CEST)
  •  Pro --HaSee 19:44, 20. Jul 2005 (CEST)
  •  Kontra -- GuidoD
  •  Pro --Mazbln 22:01, 20. Jul 2005 (CEST)
  •  Pro --BLueFiSH ?! 21:34, 22. Jul 2005 (CEST)
  •  Kontra -- Nonanet 11:51, 24. Jul 2005 (CEST)
  •  Neutral -- Mkaiser30 17:43, 30. Jul 2005 (CEST)

Alles belassen wie es ist

• •  Neutral -- GuidoD 16:41, 20. Jul 2005 (CEST)
  •  Kontra --HaSee 19:45, 20. Jul 2005 (CEST)
  •  Kontra --Mazbln 22:02, 20. Jul 2005 (CEST)
  •  Kontra -- sk 09:00, 21. Jul 2005 (CEST)
  •  Kontra --BLueFiSH ?! 21:34, 22. Jul 2005 (CEST)
  •  Pro erhlich gesagt, ich finde dieses meinungsbild das unsinnigste seit langem. wer stimmt den schon über namen ab? und wieso soll überhaupt was geändert werden, ich mein, es lief doch alles super!?! Schaengel89 @me 22:48, 22. Jul 2005 (CEST)
  •  Kontra --Kwerdenker 09:13, 26. Jul 2005 (CEST) die Spezifikation 1,2,3 sagt nichts über die Funktion der Vorlage aus. Das ist für die Phase der Entwicklung ausreichend. Wird jedoch die Verwendung im großen Stil begonnen, sind Bezeichnungen, die die Funktion näher beschreiben, leichter zu merken und steigern dadurch die Qualität.
  •  Kontra -- Mkaiser30 17:40, 30. Jul 2005 (CEST) Schließe mich Kwerdenker an

Kommentare

Nach einigen weiteren Diskussionen, tendiere ich jetzt zu der Auffassung, eine Variante zu nehmen, die nahe einer Wiki-Funktion liegt, bei der Untervarianten von Koordinate mittels optionaler Argumente geliefert werden. Dabei liesse sich {Koordinate_Text_Artikel} in [Koordinate|Text|Artikel] überführen. Die Variabilitaet der Optionen einer Wiki-Funktion kann dadurch schon jetzt hereingeholt werden, auch in dem es erlaubt sei, weitere Vorlagen anzulegen, solange diese mit {Koordinate_} beginnen. Bei solcher Liberalisierung waere obige Abstimmung teilweise ueberfluessig, denn man braucht nur noch eine Festlegung der Basis-Optionen. Ich aendere mein Stimmgewicht entsprechend. GuidoD 14:25, 22. Jul 2005 (CEST)

Die Abgabe der Stimmen hätte nicht für jeden einzelnen Vorlagentitel einzeln aufgeführt werden sollen, sondern lieber für die jeweils 3 zusammengehörenden Vorlagentitel gemeinsam. Ich sehe es schon kommen, dass wir am Ende {Koordinate Artikel} und {Koordinate Text} und {Koordinate3} gemischt haben. Das wäre nun wirklich sub-optimal. --BLueFiSH ?! 21:41, 22. Jul 2005 (CEST)

An der Stelle können wir dann ja so mutig sein und einfach den zweitplazierten nehmen, {{Koordinate Text Artikel}} -- sk 09:23, 23. Jul 2005 (CEST)

Apropos Options-Attribute, eigentlich waere es doch aehnlicher zu bisherigen Wiki-Funktionen, wenn die Optionsschritte andersherum waeren, also {{Koordinate}} für jedweder Textkoordinate, {{Koordinate Artikel}} für die Hauptkoordinate, die auch am Rand erscheinen darf (wenn der Skin es unterstuetzt, sowie {{Koordinate Meta Artikel}} wenn es gar nicht im Text erscheinen soll. Da einige Skins den Artikel-Meta jetzt zumindest ausblenden können, wäre das doch nur richtig, oder? GuidoD 11:01, 23. Jul 2005 (CEST)

Ich mag vielleicht zu spät dran sein, aber ich finde die Lösung mit "Koordinate <spezifizierung>" am besten - das ist leicht zu parsen (aus dem DB-dump), erweiterbar ("Koordinate Text Kapitel Bild" oder "Koordinate Geburtsort Artikel" bei Personenartikel usw.), und erlaubt die Angabe einer Koordinate für mehrere Verwendungen. Und - nicht zuletzt - ist das ein "wenig" einfacher zu merken als Koordinate4711 vs. Koordinate0815 für einen bestimmten Verwendungszweck. (Disclaimer: Mir ist klar, dass im Moment für alle Permutationen der <spezifizierung> eine eigene Vorlage erstellt werden muss, aber wollen wir uns wirklich mit Software-Limits herumschlagen, anstelle die Struktur logisch zu gestalten?) Nonanet 11:56, 24. Jul 2005 (CEST)

Ergebnis Koordinaten Vorlagen

Das Meinungsbild lief nur knapp zwei Wochen, um moeglichst zuegig weiterzukommen in der inhaltlichen Aufgabe der Verortung von Artikeln. Die Abstimmungbeteiligung von 12 Wikipedianern in dieser Zeit ergibt nur ein schwaches Meinungsbild in der Breite. Es existieren zwei Tendenzen in den Wertungen, wobei ein Vorschlag mehr als doppelte Zustimmung hat, um als Grundlage weiterer Arbeit zu taugen.

Die Abstimmung ergab einen Vorteil von 10:1(0)/10:1(0)/8:1(0) für die Vorlagenform von {Koordinate_Option_Option_etc}. Dabei wird gleichmaessig {Koordinate} als Einleitung verwendet, gefolgt von ganzen Worten zur Bestimmung von Varianten, jeweils getrennt durch Leerzeichen. Die Option "Artikel" erzwingt die Auszeichung am Artikelrand, die Option "Text" erzwingt die Auszeichnung im Fliesstext.

Die Abstimmung ergab einen zweite Tendenz von 4:2(1)/4:1(2)/5:2(0) für die Vorlagenform von {KoordinateNummer}. Dabei wird {Koordinate} als Einleitung verwendet, unmittelbar gefolgt von einer fortlaufenden Nummer, die die Varianten unterscheidet. Die Wirkung der Nummer wird nachgeschlagen oder nacheinander probiert, hat dabei den Vorteil besonders kurz zu sein.

Die weiteren Abstimmungspunkte wurden zu ZweiDrittel negativ beschieden. Die geringste Beteilung betrung sechs Stimmen. GuidoD 12:44, 30. Jul 2005 (CEST)

Ergebnis Diskussion Vorlagen

(a) Wird die Tendenz von allen akzeptiert? /ja/ (b) Werden Koordinate Option Vorlagen angelegt und zukuenftig ausschliesslich verwendet? /ja/ (c) Bleiben ehemalige KoordinateNummer befristet erhalten? /ja/ (d) Bleibt ehemalige Geokoordinate befristet erhalten? /egal/ - Falls etwas umgehend auf neue Vorlagen umgesetzt werden soll, kann ich auch einen Bot losschicken. GuidoD 12:44, 30. Jul 2005 (CEST)

mir persönlich ist die umbenennung ja grundsätzlich eh total egal (und wie mir auf Grund der wenigen teilnehmer auch vielen anderen) .. aber ein ändern der bisher eingesetzten vorlagen halte ich für eine sehr sinnfreie idee weil Quellcode-kosemtik. solange keine wichtigen Funktionalitäten eingeschränkt sind würde ich bitten davon abstand zu nehmen (also c & d ein klares JA .... a) total egal, b verstehe ich nicht wirklich ;) )...Sicherlich ^Post 13:17, 30. Jul 2005 (CEST)

Pro Beibehaltung bisheriger Koordinate2/3 weil unnötige Mehrarbeit aber Pro langfristige Nebenbeiänderung von Koordinate2/3 wenn man eh was am Artikel ändert. Pro mittelfristige (1 Monat) Umbenennung von Geokoordinate (aber nur (sofern Stadtartikel o.ä.) in Verbindung mit dem Verschieben als "Koordinate Text Artikel" IN die Townbox; da hat der GeoBot bisher viele Baustellen hinterlassen). Pro ab sofort Verwendung der neuen Vorlagen-Varianten (ich leg die gleich mal an, falls noch nicht geschehen). --BLueFiSH ?! 17:14, 30. Jul 2005 (CEST)

Was machen mit den heute hinzugekommenen Stimmen von Mkaiser30? entfernen oder drin lassen und ignorieren oder drin lassen und in Abstimmungsergebnis einrechnen. Der Hinweis auf das Ende der Abstimmungsende war ja zu dem Zeitpunkt noch nicht drin. --BLueFiSH ?! 18:46, 30. Jul 2005 (CEST)

Ignorieren, es aendert am Ergebnis nichts, ist aber ein weiterer Hinweis drauf, dass die Varianten mit begrifflichen Optionen fuer neue Nutzer am verstaendlichsten ist. ............. Ich selbst wuerde die Diskussion gerne dahingehend fuehren, dass die Hauptkoordinate mit nur einer Extraoption angegeben wird, nicht mit {K_T_A}. Da die Probleme um Koordinate3 jetzt behoben sind, sollte es ja der Normalfall in den Townboxen werden. Wie weiter oben schon geschrieben, wuerde ich es am liebsten sehen, wenn {K_A} die Hauptkoordinate bezeichnet (ehemals K3}, waehrend die Meta Koordinate dann eben {K_M_A} oder sowas waere (ehemals K2/Geo). Das einfach {K} braucht dann ebenfalls keine Verlaengerung als {K_T} - Text ist implizit, nur NoText muss angegeben werden. Deshalb hatte ich jetzt nicht umgehend angefangen, die Vorlagen anzulegen. Sozusagen geaenderte Ausgangsbedingungen gegenueber Anfang des Meinungsbildes. GuidoD 19:07, 30. Jul 2005 (CEST)

Koordinate Vorlage

Ich kann bei euch noch nicht so richtig den Widerspruch herauskitzeln. Tss. Also bittschön, ich finde die Angabe "Text" als Option völlig überflüssig. Wennschon, dann müsste es heissen

• {Koordinate|x|y} - jedweder Koordinate im Text
• {Koordinate Artikel|x|y} - Hauptkoordinate im Text und am Artikelrand
• {Koordinate Artikel NoText|x|y} - Koodinate nur am Artikelrand, zukünftig seltener.

aber vielleicht ist das ja auch etwas lang und holprig. Die Nummer-Varianten hatten ja auch so ihren Zuspruch. Wie wäre es denn mit folgendem

• {Koordinate|x|y} - jedweder Koordinate im Text
• {Koordinate Ref|x|y} - Hauptkoordinate im Text und am Artikelrand
• {Koordinate Ref Geo|x|y} - Koodinate nur am Artikelrand, zukünftig seltener.

kurz, prägnant/verständlich, erweiterbar, und das geo erinnert an früheres. Also, hmm, wenn es nicht missfällt, kann ich das ja die Vorlagen so anlegen. *zwinker* GuidoD 10:39, 31. Jul 2005 (CEST)

Halt! Bitte nicht noch mehr Vorlagen! Warum hast du das nicht eine Woche eher vorgeschlagen? --Fuzzy 10:51, 31. Jul 2005 (CEST)

*schmoll* hab ich doch. Und zwar letzte Woche. Aber erstmal sollte das Meinungsbild abgewartet werden. Jetzt ist es durch, und hey, bevor andere Sachen tatsaechlich in Verwendung kommen, muss es auf den Tisch. GuidoD 10:57, 31. Jul 2005 (CEST)

haben wir uns jetzt nicht auf die neuen offiziellen Namen geeinigt? warst nicht du derjenige der das MB gestartet hat um endlich Klarheit zu erhalten? gegen zusätzliche Koordinaten wie eine "Koordinate Berg" (siehe neue formatvorlage Berg) spricht ja nichts, aber ich ging davon aus, dass wir jetzt mit den neuen Namen arbeiten und nicht wieder von vorne diskutieren. Ich benutze die neuen Namen seit gestern. --BLueFiSH ?! 11:19, 31. Jul 2005 (CEST)

Das Meinungsbild wurde von Stefan Kühn gestartet, ich hab mich dann weiterhin drum gekümmert. U.a. auch den Hinweis eingebracht, dass "Text" eigentlich überflüssig ist. Wie oben zu sehen, mochte ich nach dem Ende des MB eine Diskussion starten, und hatte auf deine Notiz ('jetzt Vorlagen anlegen') umgehend geantwortet. Da keine Reaktion, habe ich einen neuen Abschnitt eingefügt, gross und fett. Ja, mensch, was soll ich denn noch machen. GuidoD 11:44, 31. Jul 2005 (CEST)

es kam darauf keine Reaktion mehr, weil ich im Grunde keine Lust auf neue Grundsatzdiskussionen habe. --BLueFiSH ?! 13:17, 31. Jul 2005 (CEST)

Zu grundsatzdiskussionen kann es dabei nicht mehr kommen. Es wurde für andere Vorlagen gestimmt, und diese sind zum Glück leicht erweiterbar. Der Rest sind nur noch Wort hier oder Wort da, dass keine schweren Kontroversen befürchten lässt. GuidoD 19:22, 31. Jul 2005 (CEST)

? hallo? endlich wurde gemeiungsgebildet wie es heißt und nun weil es so schön war machen wir es neu? vielleicht erstmal alle artikel versorgen? der Name ist doch wohl sowas von egal ...Sicherlich ^Post 13:24, 31. Jul 2005 (CEST)

Nein, eine neuerliche schwere Kontroverse steht nicht zu befürchten, ein Meinungsbild wird nicht nötig sein. Die jetztige Form bietet Raum, in der auch zukünftigen Möglichkeiten Platz haben, und auf {Koordinate} ausgerichtete Tools voll unterstützt. Die Frage des Namens ist nicht völlig egal, wenn Du bedenkst, dass ein Bot durch die Artikel rennt. Wenn nur Einer unter Hundert ein Problem mit irgendwas hat, stapelt sich das dutzendfach. Insofern müssen die Möglichkeiten in WP:GEO definiert sein. GuidoD 19:22, 31. Jul 2005 (CEST)

? hä? wenn jemand ein problem damit hat ob die vorlage Koordinate Ref oder koordinate9 oder Koordinate Artikel oder was weiß ich wie heißt hat dann hat er IMO nicht verstanden dass am ende nur zählt was angezeigt wird. .. vielleicht verstehe ich dich falsch aber wenn jetzt die 3. Version der Namen (im übrigen dann wohl entgegen des meinungsbildes) angefangen wird dann wird wohl keiner mehr durchblicken ...Sicherlich ^Post 19:28, 31. Jul 2005 (CEST)

Vor Beginn des Meinungsbildes war der Fall von Text-und-Artikel die Ausnahme, zukuenftig wird es der Regelfall. Das Problem ergibt sich daraus, was hier auf der WP:GEO Frontseite geschrieben steht, denn danach hat der Bot sich zu richten (ausgenommen es waere ein Portal-spezifischer Bot). Ein mangelnder Durchblick ist dann nicht erforderlich, wenn man die Dinge standardisiert. Genau darauf ziele ich hier: ganz besonders darauf, dass auf der Frontseite all der Kram um die "Text" Option rausfliegt - vor wenigen Minuten hat BLueFiSH.as da einen Satz hinzugebaut, der unter Garantie irgendwann hier aufschlagen wird, wenn das Brimbamorium um die Umbenennung teils vergessen ist. Und das geht bei Wikipedia eigentlich ziemlich schnell. GuidoD 19:42, 31. Jul 2005 (CEST)

Den Satz hab ich gestern mit Fragezeichen in der Zusammenfassung reingeschrieben ("wegen "Vorlage:Koordinate": kann man doch so schreiben, oder?") Wenn er nicht genehm ist, dann entfern ihn bitte. Was mich so wie dich auch stört, dass jetzt "Vorlage:Koordinate" -> "Vorlage:Koordinate Text" heißen soll - ist unpraktisch, einfach mal deswegen weil man dann wenigstens eine hätte, die man nicht ändern muss und weil "Koordinate" so schön frei verwendbar ist. Meinetwegen müssen wir nicht "Vorlage:Koordinate Text" verwenden, meine Stimme im MB war auch dahingehend. Ich hab halt nur entsprechend deiner Zusammenfassung des MB den Text vorne hingeschrieben. Bzgl. deines Vorschlags von "koord ref geo" bzw. "Koordinate Artikel NoText": die gemeinungsbildeten Varianten finde ich da deutlich besser und verständlicher. --BLueFiSH ?! 23:32, 31. Jul 2005 (CEST)

Ach, der Satz ist Ausdruck des Status Quo. Und der ist halt nicht berauschend. Wenn die langen Optionsworte genehmer sind, bitte schoen, aber wenn wir "Text" noch entfernen wollen, muss es schnell gehen, da dann {K_T_A} zu {K_A} wird, was aber meinungsgebildet eine andere Bedeutung hat. Ich persoenlich finde das okay, aber der Umstand sollte auch allen klar sein. Daher auch die Frage, nach veraendert Nennung - was natuerlich nicht zwingend ist, wenn sich alle ueber die Verschiebung im klaren sind. GuidoD 23:51, 31. Jul 2005 (CEST)

Bei "Koordinate Text Artikel" kann man Text aus genau dem Grund eben nicht weglassen. 09:25, 1. Aug 2005 Fuzzy

Eben deshalb war ein Diskussionsbeitrag nötig - auf dass man sich einig werde, es doch wegzulassen. *seufz* stecke ich zufällig gerade in einem SEP-field oder was ist hier Phase. *grr* GuidoD 18:03, 1. Aug 2005 (CEST)

Ich will ja kein party pooper sein, aber so ganz sehe ich es nicht ein, dass die kurze {Koordinate} verschwinden soll und dass der Einsatz von {Koordinate Artikel} propagiert wird. Erstere sollte die Standardvorlage für Fließtext-Koordinaten-Verlinkung sein und zweitere muss auch immer eine verlinkte Koordinate an Ort und Stelle erzeugen, weil eine Koordinate nur oben-rechts keine Option ist, denn diese Info kann von Skin zu Skin unterschiedlich sein oder gar nicht erst dargestellt werden. Soll heißen: {Koordinate Artikel} oder ...Lemma} oder ...Kontext} übernimmt den Job von {Koordinate Text Artikel} und {Koordinate} den von {Koordinate Text}. Weitere Formen gibt es nicht. Die Leute müssen also alle Koordinaten auch in den Fließtext einbauen, damit diese Info halt nicht verloren geht, wie z. B. bei der Druckversion, oder damit blinde Besucher keine kontextlose Koordinate vorgesetzt bekommen. --messi 21:18, 8. Sep 2005 (CEST)

Da geht nichts verloren - bei Skins, die die Vorlage nicht oben rechts einblenden, wird sie im Text angezeigt, und zwar sinnvollerweise am Ende des Artikels: Diese Vorlage sollte fast am Ende des Artikeltextes nach den Weblinks und vor evtl. vorhandenen Vorlagen (also damit auch vor Kategorien und Interwiki) eingefügt werden. In den Fließtext einbauen ist in vielen Fällen nicht angebracht; wenn es sinnvoll ist, nimmt man Koordinate Text Artikel. --Fuzzy 22:51, 8. Sep 2005 (CEST)

Revision der Vorlage

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

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

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

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

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

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

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

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

1. Zwei klare Datenbanklinks, einer eingebettet im Text und einer für ganze Artikel.
2. Format 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 <span style="font-family:monospace;">{{CATEGORIES}}</span> ü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)

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.org/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 Geographische 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 National Monument). 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).

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)

Formatierungen des Koordinatentextes

Ich hoffe, ich habe es nicht bei dieser Diskussion überlesen, aber gibt es eigentlich eine einheitliche Formatierung für den Textteil der Koordinatenangaben? Mir fällt immer wieder auf, dass es mehrere Arten der Angabe gibt. Zum Beispiel ein Konstrukt wie

• 51° 27' 33" n. Br., 6° 37' 11" ö. L. (z.B. bei Moers), oder
• 48° 47' N, 09° 11' O (wie z.B. bei Stuttgart)

und auch andere Varianten habe ich schon gesehen - z.B. nördliche Breite... also nicht abgekürzt, oder aber auch die wissenschaftlich korrektere Form, die dann statt O ein E benutzt. Ich fände es schön, sich auf etwas Einheitliches zu einigen und würde 51° 27' 33" N, 6° 37' 11" E vorschlagen. - Gruß Gesus 19:52, 10. Feb 2006 (CET)

Was ist denn an E „wissenschaftlich korrekter“ als an O? Das ist nur englischer.

Ansonsten sollten natürlich die „korrekten“ Minuten- und Sekundenzeichen ( ' ? ) verwendet werden. Ich persönlich benutze auch sehr gerne führende Nullen bei den Zahlenwerten (00° 00' 00? N, 000° 00' 00? O), dann werden zum Beispiel Zahlenfehler leichter zu erkennen. --::Slomox:: >< 21:11, 10. Feb 2006 (CET)

Das mit den führenden Nullen und den korrekten Zeichen ( ' ? ) unterstütze ich. Um auf deine Frage mit der wissenschaftlichen Korrektheit zurückzukommen: In zeitgemäßer, deutschsprachiger Fachliteratur zu Themen bzgl. physischer Geographie, Kartographie oder Geodäsie gibt es kein O bei dieser Art der Angabe von geogr. Koordinaten. Da wird halt die internationale Schreibweise verwendet. - Gruß gesus 21:43, 10. Feb 2006 (CET)

Ich bevorzuge auch die Kurzform also N/O. Ich glaube auch das versteht jeder. Kolossos 23:58, 11. Feb 2006 (CET)

Ich fände eine Vorlage wie bei den Personendaten besser. Mir würde es reichen, wenn man die Zahlen nur einmal eingeben muss und pro Zeile.
Also {{Koordinate|
BREITE = 40 23 22,00 N
LAENGE = 12 33 33,00 O
TYPE = ...
REGION = ...
}} und fertig. -- Simplicius 22:19, 10. Feb 2006 (CET)

Wie unterscheidest du dabei {{Koordinate Text... }}, {{Koordinate Artikel..}} und {{Koordinate Text Artikel...}}? Ich finde die drei Varianten sehr wichtig. Bei der Erzeugung der letzten KML hab ich auch die Vorlage:Ort Schweiz genutzt um Koordinaten der Schweizer Ortschaften zu generieren. Da ich der Meinung bin, das über kurz oder lang die Infoboxen auch bei deutschen Ortschaften genutzt werden wird (wegen der besseren Lesbarkeit), sollten wir das bei einer Neuformatierung mit bedenken. Ich habe keine Lust für jedes Land eine neue Diskussion anzufangen, dann lieber gleich richtig machen, eine globale tragbare Variante finden und die 25000 bestehenden Koordinaten gleich per Bot umwandeln. Es müsste also sichergestellt werden, dass die neue Vorlage in einer Infobox-Vorlage voll unterstützt wird. Bei den Schweizern fehlt z.B. die Region nach ISO 3166-2 (insbesondere die Kantonabkürzung). Weiterhin sollte überlegt werden, wie mit Objekten, die zwei Regionen zugeordnet werden können verfahren wird. Ich habe für Gipfel, Bergpässe schon "region:AT/IT" gesehen, aber das sollte auf jeden fall geklärt werden. Bei den "type"-Angaben, bin ich der Meinung sollten wir alles so belassen wie es ist, denn da haben sich die Kategorien zur Verfeinerung bestens bewährt und man vermeidet Doppelarbeiten.--sk 10:20, 11. Feb 2006 (CET)

Mein Vorschlag zielt vor allem auf eines ab:

• die Koordinaten nicht doppelt eingeben zu müssen (doppelte Arbeit für das Gleiche ist vom IT-Standpunkt aus unnütze doppelte Arbeit, und ggf. widersprüchlich, weil man ja doch was anderes eintragen kann),
• Umbrüche einzusetzen, um nicht mehr mit den Zeichen für "Leerschritt" rummachen zu müssen, damit einige Browser den Bandwurmcode aus Versehen zerlegen

Was Koordinaten in der Box oder überhaupt angeht, kann man auch eine Lösung finden, die nach vier Parametern pro Zeile Ausschau hält und die sie korrekt formatiert in der Anzeige präsentiert.

Auf Koordinaten im Text würde ich ganz verzichten, weil Sätze, die Koordinaten angeben, letztendlich doch uninformativ sind, weil sich unter 33° Ost 23° Nord ja doch niemand was vorstellen kann, auch wenn da ein Frachter gesunken sein mag.

Kurzum, mir geht es um eine Vorlage, die übersichtlich ist, statt bei Daueranwendung zur Erblindung führt. -- Simplicius 23:07, 11. Feb 2006 (CET)

Simplicius, versuch doch mal eine Vorlage zu schreiben, die mit deiner Idee klar kommt, damit kann man Leute vielleicht eher überzeugen als mit theoretischen Anstellungen. Aber ich glaube dein Vorhaben scheitert schon an der Umformatierung von "BREITE = 40 23 22,00 N" zu "BREITE = 40° 23´ 22,00´´ N". Die Dopplungen haben auch ihr gutes, so kann man am Beispiel Mosambik bei der Nutzung der von/bis Werte sehen.

Mein eigentlicher Grund warum ich schreibe ist meine Idee, dass es bei den {KoordinatenText|....} äußerst sinnvoll wäre da noch einen zusätzlichen Namen mit angeben zu können. So wäre es endlich möglich einen Artikel mit mehr als einem Punkt wie TU Chemnitz halbwegs zu gereferenzieren, was bis jetzt immer daran scheiterte, dass die TU mehrere Standorte in der Stadt hat. Man hätte also {KoordinatenText|....Name=Standort A} und {KoordinatenText|....Name=Standort B}. Auf einer Karte gäbe es dann die Ansicht "TU Chemnitz#Standort A", somit würde auch die Links weiterhin funktionieren. Bei einem Fluß könnte ich mir dann die Quelle und die Mündung vorstellen.... Kolossos 23:58, 11. Feb 2006 (CET)

Ich vermute da kein Problem, bei einer Anzeige Text1 + Variable1 + Text 2 + Variable 2 usw. zusammenzubauen, und per Bedingung falls leer, eine 0 dazuzutun.

Wenn es irgendwo eine Seite gibt "Wie kreiere ich eine Vorlage?", würde ich es gerne mal lesen.

Alternativ kann man auch einfach nur noch schreiben "Geolink" statt den Koordinaten. Wen stört es, dass die Koordinaten fehlen? Hauptsache, man kann draufklicken, oder nicht?

Bezüglich des Vorschlags "Name" wäre das über ein "Name=" jedenfalls übersichtlicher zu ergänzen, wenn die Vorlage vertikal aufgebaut wäre. -- Simplicius 14:32, 12. Feb 2006 (CET)

Zum Vorlagenbau schau mal auf Hilfe:Vorlagen, ist wirklich es interessante und leistungsstarke Fähigkeit des Mediawikis. Kolossos 19:22, 12. Feb 2006 (CET)

Mein Vorschlag wäre:
{{Koordinate|
BEZUG = Text/Artikel/Text Artikel
BREITENGRAD = 40
BREITENMINUTE = 40
BREITENSEKUNDE = 22,00
BREITE = N
LAENGEGRAD = 12
LAENGEMINUTE = 33
LAENGESEKUNDE = 33,00
LAENGE = E
TYPE = city/landmark/waterbody/mountain/country/adm1st/adm2nd
EINWOHNER = 100.000 (Wichtig für die Übergabe aus der allgemeinen Stadt-Infobox
HOEHE = 4500 (Höhe für Pässe und Berge, aber auch für Puntdaten (Profil einer Route) etc.)
REGION = DE-BY,AT (mit Komma getrennt für mehrere Regionen )
SCALE = 25000
NAME = Wrack der Titanic
}}
Ich denke damit müssten wir alles abdecken. -- sk 15:59, 12. Feb 2006 (CET)

Mit einer integrierten Vorlage:If können wir dann wohl auch das E in ein O umwandeln und auch die Sekundenzeichen "´´" nur dann ausgeben wenn bei der Variable LAENGESEKUNDE ein Wert eingetragen wurde. Nur eine statt drei Vorlagen wäre natürlich elegant. Soll ich da mal was in die Richtung bauen? Grad/Min/Sek würde ich allerdings immer auf einer Zeile zusammenfassen, nicht dass bei einem kurzen Artikel der Geotag länger wird als der Rest. Kolossos 19:22, 12. Feb 2006 (CET)

Mit dieser Vorlage wäre ich vorsichtig. Ich habe die Diskussion um diese Vorlage nicht groß verfolgt. Die Vorlage wurde aber in der en:wp schon mal zur Löschung vorgeschlagen. Ansonsten sind die logischen Templates sicherlich eine interessante Angelegenheit
Weitere Infos unter en:Wikipedia:Avoid using meta-templates, en:Wikipedia:High-risk_templates
--Arcy 08:29, 13. Feb 2006 (CET)

Hallo,
Ich habe oben schon bei "Dringender_Bedarf_zur_Revision_der_Vorlage" einen entsprechenden Vorschlag gemacht. Zu diesem stehe ich immer noch mit folgendem Zusatz: In letzter Zeit hat eine weltweite Normierung im Bereich der Koordinaten-Codierung (geotagging) eingesetzt. Diese wird von ISO, W3C, dem Open Geospatial Consortium und weiteren Organisationen unterstützt. Neuerdings ist dort auch Google vertreten. Dabei sind Vertretungen verschiedener Organisationen oft mit denselben Personen besetzt.

Speziell zu erwähnen ist aber eine Homepage einer "virtuelle Gruppe", namens Georss.org, die sich speziell dem Geotagging widmet.Dort steht klar zur Codierung: "WGS84, latitude, longitude (in that order), using decimal degrees". Aufgrund dieses Trends und zusammen mit Euren Vorarbeiten schlage ich daher folgende Syntax vor. Diese sollte den Anforderungen sowohl der Wiki-Autoren als auch einigen Informatik-Prinzipien genügen.

Syntax:

{{Koordinate|
BEZUG = enum (oblig.; Wertebereich: enum= Text/Artikel/Text Artikel)
LATITUDE = +DD.SSSS (oblig.; Wertebereich: -90.000 .. +90.0000)
LONGITUDE = +DDD.SSSS (oblig.; Wertebereich: -180.0000 .. +180.000)
ELEVATION = mmmmm (opt.; Wertebereich: -99999..+99999 in Meter über Meer, bzw. Normalnull)
EXTENSION = mmmmm (opt.; Wertebereich: 1 .. 99999 in Meter)
TYPE = enum (Wertebereich: enum= city/landmark/waterbody/mountain/country/adm1st/adm2nd/other)
REGION = cc-rr (opt.; Wertebereich: enum= siehe ISO-Norm)
POPULATION = pppppp (opt.; Wertebereich: 0 .. 99.999.999)
}}

Beispiel 'Wrack der Titanic':

{{Koordinate|
BEZUG = Text
LATITUDE = 41.76666
LONGITUDE = -50.23333
ELEVATION = -3821
EXTENSION = 2
TYPE = other
}}

Diskussion: Gegen eine 'Eindeutschung' der Schlüsselwörter habe ich grundsätzlich nichts (dann aber kein Mischmasch); eine Verdoppelung der Koordinaten wäre nach wie vor fehlerbehaftet, dessen Format in Dezimalangabe ist mit GeoRSS genormt; die EXTENSION ist ein vollwertiger Ersatz von SCALE (nur mehrfachverwendbarer) und TYPE habe ich mit other ergänzt und weise nochmals auf die (vorläufig nicht vermeidbare) Redundanz zu Kategorien hin.

Name ist mir unklar: Der Artikel hat ja schon einen? Das bringt mich sowieso auf ein Problem: Der Bezug bei 'Koordinate Text' ist unklar: Auf welchen Textabschnitt oder auf welches Wort bezieht sich dieser Datebnanklink wirklich?? -- Geonick 00:18, 13. Feb 2006 (CET)

Also die Eindeutschung scheint mir sehr wichtig, da sonst viele Leute das ganze falsch schreiben oder falsch ausfüllen. Wozu der Type "other" gut sein soll verstehe ich noch nicht ganz. Ich glaube "landmark" und "other" wird nie klar zu trennen sein. Der Eintrag Name ist dafür, wenn z.B. Im Artikel Universität Trier zwei Koordinaten auftauchen einmal für Campus I und dann für Campus II. Wie lösst du das Berg/Pass Problem, die nicht eindeutig einer Region zugeordnet werden können, weil sie auf der Grenze liegen? Ansonsten könnte ich mit deinem Vorschlag leben. -- sk 16:23, 13. Feb 2006 (CET)

Was wir statt einen Typ "other" wirklich brauchen ist ein Typ "district" also Stadtteil, da diese in einer Karte wirklich schlecht aussehen wenn ist genauso dargestellt werden wie die eigentliche Stadt. Die Vorteil einer dezimalen Schreibweise mit +/- kann ich aus programmiertechnischer Sicht wirklich nachvollziehen, aber aus Sicht einer ordentlichen Koordinatendarstellung über eine Vorlage würde ich das für einen echten Rückschritt halten. Besonders die N/S O/W- Angabe sollte schon sein. Wenn es um eine einheitliche (automatisierte) internationale Verwendung diese Vorlage geht, sollten wir vielleicht doch dem englischen den Vorzug geben. Die Vorlage von sk funktioniert jedenfalls auch mit dezimalen Gradangaben wenn man die Min und Sek wegläßt, somit würde ich ihr den Vorzug geben. Kolossos 19:13, 13. Feb 2006 (CET)

Ich habe mal als Diskussionsgrundlage eine relativ "kranke" Vorlage geschrieben mit der es möglich ist :

{{Geokoordinaten|lat-deg = 10|lat-min = 20|lat-sec = 30|lat = N|lon-deg = 40|lon-min = 50|lon-sec = 59|lon = W}}

in Vorlage:Geokoordinaten umzuwandeln.

Die ausgeschriebenen Nord West sind nur um zu zeigen, das eine Internationalisierung mit der Vorlage möglich ist. Ebenso kommt die Vorlage mit dezimalen Grad angaben klar:

{{Geokoordinaten|lat-deg = 10.12345|lat = N|lon-deg = 40.234234|lon = W}}

ergibt: Vorlage:Geokoordinaten.

Diese Vorlage wollte ich dann noch in eine zweite Vorlage stecken um die Fälle Text/Artikel/Text Artikel über if-Abfragen abzudecken das sollte nicht das Problem sein. Vorher sollte man aber abklären, ob wir unserem Servern die Vorlage wirklich zumuten wollen (Performance, Zuverläßigkeit,...). Kolossos 21:24, 14. Feb 2006 (CET)

Ich bin GEGEN eine dezimale Schreibweise von Koordinaten. Ja ich weiß, dezimale Werte können leichter verarbeitet werden. Aber man sieht diesen Koordinaten nicht mehr an, wie genau sie georeferenziert wurden! Gerade Daten aus Ortsdatenbanken sind oft nur auf Grad und Minute genau. Das führt besonders bei kleinen Orten zu (bis zu 2km) weit "verschobenen" Markierungen. Beispiel: Aus 51°13' wird dezimal 51,216667 mit (beliebig) vielen Nachkommastellen. Mit der Angabe 51° 13' 32" bzw. 51,225556 wäre der Punkt aber besser positioniert. Das macht uns die Arbeit zum Nachpflegen genauerer Koordinaten leichter. --Glg 13:13, 16. Feb 2006 (CET)

Das bedeutet dann aber auch, wenn man auf das Risiko der 20 If-Templates in meinem Vorlage-Vorschlag nicht eingehen möchte, dass es bei der Redundanz der Koordinaten bleibt. Ich könnte damit leben, weil sich die Koordinaten nachträglich nicht mahr ändern und wir in der Zwischenzeit auch Werkzeuge zur einfachen Eingabe haben. Kurzes Meinungsbild dazu? Oder sagt einfach so jeder seine Meinung dazu? Kolossos 13:30, 16. Feb 2006 (CET)

Ich finde den Einwand von Glg sehr gut. Die Genauigkeitsprüfung wird durch die dezmiale Schreibweise nicht unterstützt. Was mir gerade noch einfällt: Wegen der Stadtinfoboxen! Wenn wie bei der Schweiz die Koordinaten eingebaut werden, dann wird die eigentliche Koordinatenvorlage erst bei Generierung der HTML-Seite vom Server erzeugt. Das heißt, dass ich bei einer Suche nach der Vorlage in der Datenbank in diesem Artikel keine Koordinatenvorlage finde. Wichtig wäre also eine Umsetzung, die direkt in die Stadtinfoboxen integriert werden kann, da wir sonst die Datenbank nach den verschiedenen Typen von Stadtinfoboxen durchsuchen müssten. -- sk 13:38, 16. Feb 2006 (CET)

Siehe auch GISWiki:Datenqualität von Geodaten
@sk: *g* Dann sollten wir doch alle "ungenauen" dezimalen Angaben schnell wieder rausschmeissen . *g* Arcy 11:38, 28. Feb 2006 (CET)

Also ich wäre sehr dafür, wenn man sich langsam auf eine Verbesserung der Vorlage einstellen könnte - sowohl für Autoren (= keine doppelten Eingaben) als auch für die Verarbeitung (= klarere Formattierung ohne Schnickschnak, wie Spaces, oder Spezialzeichen wie -, ', " oder °).
Der Einwand, dass man Koordinaten in reiner Dezimalnotation (ddd.dddd) nicht mehr ansieht, wie genau sie erfasst wurden, ist nicht ganz korrekt: Es gibt natürlich auch in der anderen Richtung Beispiele mit nicht-abbrechenden Zahlenreihen... Und genauso wie bei der Altgrad-Notation ist es auch bei Dezimalnotation nützlich - wenn auch nicht hinreichend - sich auf die Anzahl Stellen zu einigen. Ich habe die entsprechenden Nachkommastellen-Bereiche nicht genau im Kopf; ich vermute, dass vier (allenfalls mit Nullen aufgefüllte) Nachkommastellen für unsere Zwecke genügen. Wenn eine Aussage über die Genauigkeit (bzw. Qualität?) der Koordinatenangaben wichtig würde, dann geht es nicht ohne zwei weitere Attribute, wie z.B. Lage- und Hoehengenauigkeit. Das wären aber Angaben, die ich im Rahmen dieses Projektes vorläufig als unrealistisch betrachte.<br\> In Anlehnung an Kolossos' Vorschlag komme ich damit auf folgende Vorlagen:

 
Variante englisch:
  {{Geocoordinates|context=text|lat = 10.1234|lon = 40.2342|extension = 2|type = landmark}}
Variante deutsch:
  {{Geokoordinaten|kontext=Text|ostwert = 10.1234|nordwert = 40.2342|ausdehnung = 2|typ = Landmarke}}
  

In Ergänzung zu meinem Vorschlag oben sind dabei die in Datenbanklinks üblichen Trenner '|' und bei der eingedeutschten Variante die konsequente Deutschschreibung (Bsp. "landmark => Landmarke") zu beachten. -- Geonick 01:09, 28. Feb 2006 (CET)

• Eine vertikale Variante der Koordinatenvorlage würde ich jedenfalls vorziehen. Die Vorschläge oben finde ich alle ganz gut.
• Die Scale-Angabe würde ich rauslassen und stattdessen eine Angabe über die Grösse des Objekts vorsehen, die dann für viele Applikationen eine Umrechnung für einen Betrachtungsabstand/winkel/ausschnitt zulässt. Der Parameter ausdehnung ist eine gute Lösung. -- Simplicius 13:45, 28. Feb 2006 (CET)

Nur damit wir uns nicht falsch verstehen ich bin nach meinen Experimenten mit der Vorlage eher zur Überzeugung gekommen, dass im Moment kein Weg an den redundanten Koordinateneingaben vorbeiführt. Kolossos 20:40, 1. Mär 2006 (CET)

Warum müssen die Koordinaten doppelt eingeben werden? Damit wird nicht nur das Prinzip der Konsistenzhaltung sondern auch dasjenige der 'Sichtkontrolle' verletzt, denn es wird nicht das dargestellt, was maschinell weiterverarbeitet wird. --Geonick 00:22, 12. Mär 2006 (CET)

Nochmals zu Dezimalnotation:
"Der Einwand, dass man Koordinaten in reiner Dezimalnotation (ddd.dddd) nicht mehr ansieht, wie genau sie erfasst wurden, ist nicht ganz korrekt: Es gibt natürlich auch in der anderen Richtung Beispiele mit nicht-abbrechenden Zahlenreihen... Und genauso wie bei der Altgrad-Notation ist es auch bei Dezimalnotation nützlich - wenn auch nicht hinreichend - sich auf die Anzahl Stellen zu einigen."
Mir geht es nicht im die reine Anzahl der Nachkommastellen. Natürlich kommt es bei einer (Rück-)Umwandlung von Dezimalen Koordinatenwerten in die Grad-Minuten-Sekunden-Schreibweise auch wieder zu Rundungsfehlern und nichtabbrechenden Zahlenreihen. Aber man kann an einer Dezimalschreibweise nicht mehr erkennen, ob die Koordinaten aus einer "kastrierten" Datenbank kommt (d.h. der Sekundenwert wird nicht bekanntegeben) oder nicht. Die Werte aus der GeoDB Ortsdatenbank finde ich unzureichend, auch viele Internet-Kartenanbieter unterdrücken absichtlich die genauen Koordinaten (Sekundenwerte). Leider. Die Schreibweise in der Vorlage kann ruhig einfach gehalten werden, ohne die Trenn- und Sonderzeichen ° ' " , also schlicht 23 45 67 N 12 34 56 W in einer oder zwei Zeilen.
Bei der Gelegenheit: Woher wollt ihr die Höhenangabe beziehen? Sag bitte nicht GTOPO30 oder SRTM oder gar GoogleEarth... Das Höhenmodell dort ist nur für Orte im Flachland geeignet. Für Gebirge sind die horizontalen Raster (ca. 1km bei GTOPO30 bis 90m bei SRTM) und die somit interpolierten Werte dazwischen nicht das Gelbe vom Ei. Da verschwindet so mancher Berg im Raster ;-) --Glg 17:48, 2. Mär 2006 (CET)

Die Höhe ist bei der hier diskutierten Vorlage, bzw. deren Verbesserung noch nicht gross angesprochen worden. Sie kann m.E. bis auf weiteres weggelassen werden, denn sie kann 'jederzeit' aus einem (natürlich möglichst genauen) Geländemodell hergeleitet werden unter der Annahme, es werde alles auf die Erdoberfläche projiziert. Was die Dezimalangabe betrifft: Hier verstehe ich das Argument nicht "Aber man kann an einer Dezimalschreibweise nicht mehr erkennen, ob die Koordinaten aus einer "kastrierten" Datenbank kommt (d.h. der Sekundenwert wird nicht bekanntegeben) oder nicht": Niemand kann eine Herkunft an einer Zahl erkennen, oder? Auch wenn die Sekundenangabe noch da wäre, dann wären dies reine Vermutungen.

. Ich gebe zu, dies war unpräzise ausgedrückt. Lass es mich ausführlicher umschreiben: Die meisten Koordinaten, die zu Wikiartikeln erfasst wurden, stammen aus Datenbanken wie z.B. OpenGeoDb, geonames.org oder anderen frei zugänglichen Kartendiensten. Diese liefern leider nur Koordinaten mit Grad- und gerundeten Minutenangeaben (ddd°mm'). Genauere referenzierte Daten mit Sekundenwerten oder Minutenwerte mit Nachkommastellen sind dort (nicht mehr!?) frei zugänglich. In einigen wenigen Wikiartikeln haben sich Autoren bereits die Mühe gemacht, Orte auf Bogensekunde genau zu georeferenzieren. Beide lassen sich bisher prima an der Schreibweise der Koordinaten unterscheiden: 51°13'N <-> 51°13'32"N . Soweit, sogut. Werden die Koordinaten aber in der Dezimalschreibweise erfasst, sieht man der Koordinate deren "Genauigkeit" nicht mehr an: 51,216667 N <-> 51,225556 . D.h. man müsste jeden Punkt in einer Karte nochmals genau betrachten und dann entscheiden, ob er zur Verbesserung der Georeferenzierung korrigiert werden sollte oder nicht (sprich den Wert der Bogensekunde nachpflegen). Siehe auch Stichwort: "bei kleineren Orten liegen weisen sie häufig auf Punkte außerhalb des Ortsgebiets, manchmal sogar auf Machbarorte". - hab ich mich nun verständlicher ausgedrückt? --Glg 17:03, 16. Mär 2006 (CET)

Ich - und alle Roboter - wäre(n) froh, wenn die Meinungen auf die oben erläuterte Verbesserung der Vorlage Koordinate 'konvergieren' könnten. Dabei möchte ich abermals betonen, dass man mit der aktuellen zwar leben kann, wenn es auch schmerzt, da Redundant und entgegen dem 'Sichtbarkeitsprinzip' (vgl. oben). Noch 'schlimmer' als die aktuelle Koordinate zu verwenden ist nur noch, eine ganz andere zu nehmen, wie das offenbar bei verschiedenen Vorlagen (wie z.B. unten bei "Ein ' sind wieviel m?" diskutiert) immer noch der Fall zu sein scheint. --Geonick 00:22, 12. Mär 2006 (CET)

Verbesserte Vorlage Geokoordinate und Umgang mit Infoboxen

Zwei Fragen

Bevor ich auf die zwei essentiellen Fragen zurückkomme, möchte ich darauf hinweisen, dass wir (Stefan und unser Roboter/Parser) zurzeit _nur_ die Vorlage Koordinate beim Auslesen berücksichtigen und wir nun nahe daran sind, diese zu verbessern. Zur Erinnerung: Der erstmalige Crawl-Vorgang der deutschen Wikipedia dauert zurzeit auf einem typischen Intel-Rechner ca. 10 Stunden.

1. Bei der ersten essentiellen Frage geht es um die Verbesserung der Vorlage Koordinate zur Vorlage Geokoordinate. Zur Hilfe für diejenigen, die sich nicht die Mühe nehmen wollen, den Text oben zu lesen: Es geht um die Dezimalnotation (= GPS?) auf der einen und DMS.DD mit N/O-Angabe auf der anderen Seite sowie um selbstdokumentierende, mit '|' getrennte Attributnamen-Werte-Paare (Breitengrad=40 |Breitenminute=40, etc. ). Beides wäre ein klarer Fortschritt gegenüber der jetzigen Notation. Bei der Dezimalnotation kann man noch darüber reden, ob anstelle Minuszeichen eine Angabe zu N/S und W/O gemacht werden soll. Zu dieser Frage gebe ich zu bedenken, dass zurzeit ein Standard namens GeoRSS rasch Verbreitung findet und der verwendet die Dezimalnotation mit Minus-Zeichen.
2. Wenn wir die erste Frage geklärt haben (Dezimal oder DMS.DD), kommen wir zur zweiten essentiellen Frage: Ich möchte Kolossos beipflichten und nachdoppeln, dass wir mit dem "Abrücken von einer einheitlichen Koordinaten-Vorlage viele effiziente Möglichkeiten aufgeben". Natürlich gibt es Crawler und natürlich könnten 'zig Varianten programmiert werden. Das bedeutet aber nicht, das nun bei jeder neuen Infobox oder Vorlage mit Ortsbezug die Codierungs-Diskussion hier losgeht, bzw. wieder ein Crawler oder eine Programm-Anpassung geschrieben werden müsste - sonst diskutieren wir am Ende noch das Alphabet...! Also: Die Frage hier ist, wie gehen wir mit Infoboxen-Vorlagen um? Dort ist für mich nur noch die Frage, ob die Vorlage (Geo-)Koordinaten tel-quel eingebettet werden soll, oder ob deren Attribute (ohne geschweifte Klammer) eingebettet werden sollen. --Geonick 20:56, 12. Mär 2006 (CET)

Darf ich nochmals nachdoppeln? Ich habe festgestellt, dass tatsächlich die meisten Artikel der Kategorie "Ort in der Schweiz", "Ort in ..." sowohl in der Infobox, als auch unten Koordinatenangaben enthalten. Gegeben die aktuelle suboptimale Vorlage Koordinate bedeutet das, dass z.Zt. dieselben Koordinaten dreimal(!) eingegeben werden müssen: Einmal in der Infobox und zweimal in der Vorlage Koordinate. Da gibt es Handlungsbedarf.

Ab ca. Ende nächster Woche wird unser Projekt Wikipoint zur Bereitstellung von Artikeln mit Koordinaten freigeschaltet. Ohne weitere Anpassungen (z.B. aufgrund Feedback von euch) werden Koordinaten in Infoboxen ignoriert. Zudem könnte eine zusätzliche Vorlage Geokoordinate berücksichtigt werden, wie es dem letzten Stand unserer Diskussion (vgl. Artikel_ohne_Koordinate) entspricht. --Geonick 00:02, 16. Mär 2006 (CET)

ich weiß nicht recht was der geowebdienst so tun soll, aber was meinst du mit koordinaten in infoboxen werden ignoriert ...Sicherlich ^Post 09:52, 16. Mär 2006 (CET)

Der Dienst ist auf meiner Benutzerseite beschrieben. Wichtig für Benutzer und Computer ist, dass Koordinaten nur mit *einer* einzigen Syntax eingetragen werden und die ist bis auf Weiteres die "Vorlage Koordinate", und deren Syntax beginnt zurzeit so: {{Koordinate Artikel|47_20_58_N_8_43...}}. In den letzten Tagen wurden Infoboxen (z.B. Polen) und Vorlagen entworfen (z.B. Bergtabelle), die Koordinatenvorlagen enthalten, die davon abweichen (vgl. Kategorie:Vorlage_mit_Koordinate). Diese Koordinaten werden Crawlern wie unseren ignoriert.

Wie die Koordinatenvorlage in Vorlagen eingebettet wird, ist eine offene Frage (vgl. oben). Wenn aber immer wieder weitere Variationen von Vorlagen-Namen entstehen, die für sich beanspruchen, Koordinaten zu enthalten, dann bricht das Chaos aus!! Dann müssten Crawler ständig testen, ob wieder jemand Lust bekommen hat, eine neue Vorlagenvariante mit Koordinaten zu entwerfen (was dann wieder einen 10-stündigen Prozess zur Folge hätte). Bitte erzeugt also keine neuen Vorlagen Koordinaten bis das nicht geklärt ist... --Geonick 17:25, 16. Mär 2006 (CET)

ahja .. naja Polen gibt es nun schon ;) und ist auch schon in reichlich artikeln drin; müsste also angpasst werden oder Polen bleibt weiß ;) ... eine vereinheitlichung der vorlage nach polnischem Prinzip gern; mir egal ob die Variablen GradN oder GradNord oder wie auch immer heißen ;) ...Sicherlich ^Post 21:26, 16. Mär 2006 (CET)

Nochmals: Sprache und Zweck dieser Vorschläge

Allgemeine Frage: Wo gab es überhaupt jemals Probleme mit der Namensgebung? Englisch ist doch bezüglich Koordinaten Standard hier. Oder habe ich mich da verTyped. Shouldte ich da my landamrk qannders setze ? oder irre ich mich? Arcy 01:24, 17. Mär 2006 (CET)

Also: Das Wiki-Projekt Georeferenzierung hat doch zum Ziel, Artikel/Seiten oder Textabschnitte zu georeferenzieren, indem 'Tags' mit Koordinaten in den Wikitext eingefügt werden. Damit ist es nicht nur möglich zu Online-Karten (kvaleberg-Service) zu verlinken, sondern man kann die Daten herausziehen (crawlen und parsen), um eine Geonamen- bzw. Orte-von-Interesse-Datenbank zu erhalten. Diese DB ist das Ziel meines Services auf dem Toolserver. Aus dieser können wiederum Dienste, wie z.B. ein KML für Google Earth, aufsetzen. Es geht nun in beiden Fragen oben primär um den Vorlagen-Namen, der z.Zt. ({{Koordinate Text|...}}) heisst (sekundär dann um die Attribut-Werte-Paare). Ein Crawler/Roboter sucht nun regelmässig alle (geänderten oder neuen) Artikel nach diesem Schlüsselwort (beginnend mit doppeltgeschweiften Klammern) ab. Wenn dieses Schlüsselwort ändert, dann findet der Roboter nichts, auch wenn es eine (allenfalls Koordinaten-ähnliche) Vorlage ist und auch wenn GradN dort steht. Oben versuchte ich auch zu erläutern, dass es für den Computer wenig Sinn macht, Vorlagen zu verlinken, weil dies zur Folge hat, dass immer wieder das ganze Wiki danach von vorne neu abgesucht werden müsste! --Geonick 09:04, 17. Mär 2006 (CET)

falls das letzte an mich und die polnische vorlage gerichtet ist; ja du hast es erläutert aber auh ich habe meinen standpunkt erläutert ...Sicherlich ^Post 09:14, 17. Mär 2006 (CET)

Ich kann deinen Argumenten leider nicht richtig folgen. Ich richte meine Überlegungen an alle Infoboxen - die Vorlage "Schweizer Ort" ist da z.Zt. auch nicht brauchbarer. Ich interpretiere damit den Stand der Diskussion so: 1. Für die Frage 1 oben "Verbesserte Vorlage Geokoordinate anstatt Vorlage Koordinate" bleiben wir bis auf weiteres bei Vorlage Koordinate. 2. Für die obige Frage 2 (Umgang mit Infoboxen) werden Infoboxen entweder ignoriert (Artikel können immer noch unten Vorlage Koordinate haben) oder sie werden derart angepasst, dass die "Vorlage Koordinate" ({{Koordinate Text|...}}) an der Stelle eingebettet wird, wo zurzeit Länge/Breite, etc. steht. Bei der Umstellung der betroffenen Artikel könnte dann sehr wohl ein Crawler/Bot beigezogen werden. --Geonick 12:47, 17. Mär 2006 (CET)

dann ignorier sie wenn du dein Programm nicht umprogrammieren willst; ein umstellen der polnischen Infoboxen wird Sicherlich nicht erfolgen, die benutzerfreundlichkeit der boxen ist IMO viel zu bedeutend außerdem können durch diese Boxen andere Bots besser mit den Daten umgehen; ein einzelnes Programm welches nicht entsprechend programmiert ist ist halt pech...Sicherlich ^Post 14:01, 17. Mär 2006 (CET)

Lösungsvorschlag 1 für Vorlagen mit Georeferenzierung

Ich kann Geonick nur zustimmen, dass es extrem unpraktikabel wäre, nach hunderten von verschiedenartigen Vorlagen suchen zu müssen. Vor allem wenn immer andere Schlüsselwörter für die Koordinateninformationen genutzt werden. Wir müssen uns hier deshalb einmalig für einige Schlüsselwörter und deren Einsatz in den Vorlagen aussprechen und deren Nutzung beschreiben. Vorlagen, die sich nicht an diese Reglung halten, werden nicht in die Weiterverarbeitung mit aufgenommen. Die drei bestehenden Vorlagen "{{Koordinate ...}}" haben weiterhin Bestandsschutz, da derzeit nicht alle sofort durch eine Infoboxen und ähnliches ersetzt werden können. Im Laufe der Zeit werden aber viele davon in bestimmten Vorlagen (z.B. Stadt-, Berg-, Unternehmens- oder Museumsvorlagen) aufgehen und so die Nutzung und Wartung extrem vereinfacht. Um uns von anderen Schlüsselwörtern abzuheben, schlage ich vor sie alle mit Koordinate anfangen zu lassen:

|Koordinate_Breite = N/S (obligatorisch)
|Koordinate_Breitengrad = 44 (obligatorisch, hier auch Dezimalangabe möglich)
|Koordinate_Breitenminute = 44 (optional)
|Koordinate_Breitensekunde = 44,00 (optional)
|Koordinate_Länge = O/W (obligatorisch)
|Koordinate_Längengrad = 12 (obligatorisch)
|Koordinate_Längenminute = 33 (optional)
|Koordinate_Längensekunde = 33,00 (optional)
|Koordinate_Name = Wrack der Titanic (optional, bei mehreren Koordinaten in einem Artikel sinnvoll, z.B. verschiedene Standorte etc.; wenn kein Name da, dann gilt Artikelname )
|Koordinate_Scale = 25000 (optional)
|Koordinate_Type = city/landmark/waterbody/mountain/country/adm1st/adm2nd (optional)
|ISO 3166-2=DE-BY,AT-9  (optional, mit Komma getrennt für mehrere Regionen bei Bergen/Seen im Grenzgebiet)
|Einwohner = 100000 (optional)
|Höhe = 4500  (optional, Höhe für Pässe und Berge)

Type wurde weggelassen, da es durch die Funktionalität der "Koordinate_Name" entfällt, bzw. in der Vorlage ja definiert ist, wie die Koordinate angewendet wird. Bitte macht jetzt eure Verbesserungsvorschläge, dann können wir abstimmen. -- sk 14:20, 17. Mär 2006 (CET)

Ich kann den Vorschlag von sk fast unterstützen. Sein Vorschlag geht über 14 Zeilen, da käme es also auf 2 zusätzliche Zeilen auch kaum noch an, darum würde ich vorschlagen die Angaben in einer eigenen Geo-Vorlage zu kapseln. Wenn sich dann also z.B. was mit Kvaleberg oder mit dem CSS ändert oder so, müßte nur diese eine Vorlage geändert werden.

Zum Thema Benutzerfreundlichkeit: Benutzerfreundlich ist nicht nur dass, was "für Benutzer freundlich ist" sondern auch was es unseren Programmieren ermöglicht stumpfsinnige Routinearbeiten zu automatisieren, dazu zählt für mich perspektivisch auch die Übertragung der Geokoords. auf andere Sprachwikis oder die Bot unterstützte Übernahme aus anderen Geoquellen. Von da her ist ein Standard wichtig. Für einen Bot wäre eine gekapselte Vorlage sicherlich besser. Ob man mit 14 Zeilen wirklich soviel einfacher kommt wie mit der jetzigen 1 Zeile erschließt sich für mich auch nicht ganz. Trotzdem würde ich mich einer Meinungsmehrheit natürlich anschließen können. Übrigens: Schön wäre noch eine Ergänzung von Koordinate_Type um einen möglichen Wert district für Stadtteile, oder gibt es da Probleme. Kolossos 19:23, 17. Mär 2006 (CET)

hmm finde den vorschlag von sk ganz gut; habe aber noch eine bitte bzw. frage; Infobox:Polen ist immer eine stadt; die vorlage an sich gibt das auch so aus (siehe quelltext Vorlage:Infobox (Polen)): dem Programm müsste man doch beibringen können das auszulesen? ... das selbe würde ja für infobox von bergen etc. gelten und bei den meisten städten könnte man dann auch die Koordinate_Breite entsprechend in die vorlage "versteckt" integrieren und so die boxen entschlacken ...Sicherlich ^Post 19:45, 17. Mär 2006 (CET)

Hatte ich auch schon dran gedacht ob man die Mediawiki-Funktion zum parsen nutzen könnte, wäre gut wenn es gehen würde. Kolossos 21:03, 17. Mär 2006 (CET)

ohne mich im detail auszukennen; aber am anfang der Box steht ja der vorlagenname; also müsste das progrämmchen das erkennen und dort entsprechend die fehlenden daten abfragen ... vielleicht geht es auch anders - nur so als idee ;) ...Sicherlich ^Post 21:16, 17. Mär 2006 (CET)

@Kolossos: Eine Kapselung der Vorlage ist genau das was wir ja eigentlich nicht wollen, weil dann wieder die eigentliche Erzeugung außerhalb der Artikeltexte passieren könnte (wie derzeit bei Schweizer Orten). Ich dachte mir dabei, dass die Stadtvorlagen diese Schlüsselwörter direkt benutzen. Wenn also der Bot im Artikeltext dieses Schlüsselwort findet muss er nur "{{" und "}}" der entsprechenden Vorlage finden und dann die anderen vorhandenen Schlüsselwörter auslesen.
@Sicherlich & Kolossos: Das Parsen von einigen Angaben der Koordinaten z.B. Type oder Breite ist ja gerade jetzt schon das Problem, weshalb ich davon dringend abraten möchte, diese Bestandteile außerhalb des Artikels zu generieren. Derzeit muß eine Software nur den Artikel anschauen um alle relevanten Infos zu bekommen. Wenn wir einen Teil woanders hin auslagern verdoppeln wir den Aufwand, da bei jeder gefundenen Koordinate erst mal die externen Infos noch zusätzlich angeschaut werden müssten. Bei derzeit 30000 Koordinaten geht das vielleicht noch, aber wir stehen ja erst am Anfang. Der Aufwand würde sich nicht lohnen für die paar eingesparten Zeilen! -- sk 08:00, 18. Mär 2006 (CET)

hmm ca. 900 Städte in Polen mit je drei eingesparten Zeilen sind 2.700 eingesparte Zeilen ... das auf die städte der welt hochgerechnet und bedacht, dass jedesmal die zeilen mit gespeichert werden müssen wenn ewas an dem artikel geändert wird ... ;) ...Sicherlich ^Post 11:08, 18. Mär 2006 (CET)

Also ich finde Stefans Vorschlag übersichtlich und seine Argumentation (soweit ich sie verstehe - ich bin kein Programmierer) nachvollziehbar. Die paar eingesparten Zeilen hören sich nach Sicherlichs Berechnung sicherlich recht viel an, dürften aber bei der gesamten Wikipedia-Datenmenge wirklich kaum ins Gewicht fallen. --Mazbln 11:51, 18. Mär 2006 (CET)

Lösungsvorschlag 2 für Vorlage Geokoordinate und Vorlagen mit Georeferenzierung

@Sicherlich: Respekt vor deinen Beiträgen zur Georeferenzierung von Polen-Artikel, die du offenbar vor wenigen Tagen geleistet hast. Du warst es denn auch, der uns auf das Problem der Infoboxen gebracht hast. Dieses wirft grundsätzliche Fragen auf, auf die wir schon mit der Type-Angabe gestossen sind. Gehe davon aus, dass alle verfügbaren (knappen) Programmier-Ressourcen eingesetzt werden, auf die ein Wikipedia-Projekt ebenso zählen kann wie auf aktive Benutzer. Wir sind uns z.B. einig, dass Benutzerfreundlichkeit und Einfachheit Priorität hat. Und die Überlegungen von sk und kolossos gehen in die richtige Richtung.

Lasst mich zunächst die Vor- und Nachteile der bisherigen Vorschläge klären um dann einen Vorschlag zu machen, bevor wir abstimmen:

1a. Im Vorschlag von sk gibt es Verbesserungspotential: Scale sollte durch Ausdehnung ersetzt werden (Diskussion siehe oben) aber - noch wichtiger: Typ und Typ-Werte sollten deutsch sein und in Schlüsselwörtern dürfen keine Leerzeichen vorkommen.

|Koordinate_Ausdehnung = 10 (optional) in km, allenfalls mit Dezimalangabe (0,5)
|Koordinate_Typ = Stadt/Landmarke/Gewässer/Berg/Land/Admin1/Admin2 (optional)
|ISO_3166-2 = DE-BY,AT-9 (optional, Komma getrennt für mehrere Regionen bei Bergen/Seen im Grenzgebiet)

Die Idee dieser alleinstehenden Schlüsselwörter ist nun, dass sie eindeutig erkannt werden wenn sie in beliebigen künftigen Vorlagen mit Datenbanklinks verwendet werden. Eine zusätzliche Angabe der Vorlage "Koordinate Artikel" im selben Artikel ist unerwünscht, falls mind. die erwähnten obligatorischen Schlüsselwörter vorhanden sind. Vorlage "Koordinate Text" wäre weiterhin in allen Fällen anwendbar.

1b. Infragegestellt ist der Umgang mit Type: Der Name der Infobox (d.h. der Textes zwischen {{ und dem ersten "|") könnte zwar herausgelesen werden, würde aber die von den einen gewünschte Type-Aufzählung (Stadt/Landmarke/Gewässer/Berg/...) frei den Benutzern überlassen und würde zudem - wie Type - eine 'Konkurrenz' zu Kategorien darstellen. Wenn ich mich entscheiden müsste zwischen Type-Angabe, die aus Infobox-Werten herausgelesen würde und Kategorien dann ist für mich klar, was den Vorrang erhielte: die Kategorien unten. (@Sicherlich: Was für ein Typ wäre nun z.B. {{Infobox (Polen)|...? @sk: Du hast Typ optional bezeichnet; willst du damit diese Angabe aufgeben, falls Infoboxen als 'Ersatz' für Vorlage "Koordinate Artikel" gelten sollten? Falls Typ obligatorisch wäre *und* dargestellt würde, wie erklären wir das den Lesern im Vergleich zu Kategorien?)

2. Der Nachteil einer so lockeren Regelung ist, dass der Hypertext-Linkmechanismus nicht mehr wie zurzeit bei Vorlage "Koordinate ..." funktioniert. Änderungen an diesen Schlüsselwörtern hätte auch eine Änderung von vielen CSS zur Folge (statt nur einer wie bei Vorlage Koordinate). Diese Regelung ist auch potentiell unklar, da sowohl Menschen wie auch Bots ein z.T. sehr weites Textumfeld lesen müssen, um den Zusammenhang zu sehen. Nun haben die englischen Kollegen eine weitere Mediawiki-Variante vorgeschlagen: vgl. z.B. beim Matterhorn das Vorlagen-Fragment {{Bergtabelle Koordinaten|45_58_N_7_39_E_type:mountain|45° 58' N; 7° 39' O}}. Der Vorteil davon ist, dass mind. Koordinaten-Angaben wieder schön doppeltgeschweift geklammert sind, was wieder mit vernünftigen Mitteln als Link interpretiert werden kann. Abgesehen davon, dass dieses Beginn-Ende eine Vorlage komplizierter macht, ist damit aber das Problem des redundanten Typs, der Höhe oder der Einwohner nur unbefriedigend gelöst.

Fazit mit Vorlage Geokoordinate

Nach reiflicher Überlegung komme ich daher zum Vorschlag, dass wir einerseits die "Vorlage Koordinate" leicht verbessern (Basis Vorschlag sk) und andererseits empfehlen, in Infoboxen keine Koordinatenangaben zu verwenden (dass in Infoboxen Höhe, Einwohner, etc. vorkommen, wäre weiterhin denkbar). Jeder georeferenzierte Artikel sollte also nach wie vor mind. einen Eintrag Vorlage "Koordinate..." enthalten (max. 5 gemäss heutiger MediaWiki-Version). Damit sind weitergehende Erweiterungen, wie sie oben bereits angedacht wurden (z.B. nur eine Koordinate in allen Wikis) leichter möglich. Diese Regelung ist einfach zu handhaben, entspricht der ursprünglichen Datenbank-Links-Idee und verlangt nach wie vor nur eine Darstellungsregelung (CSS). Sie wäre übrigens auch ganz ähnlich wie die vollständige Wikipedia:Personendaten-Liste. Hier also mein Vorschlag auf Basis von sk und Kolossos oben in leicht verbesserter Form: --Geonick 12:24, 18. Mär 2006 (CET)

{{Geokoordinate Artikel/Text/Text Artikel
  |Breite = N/S (obligatorisch)
  |Breitengrad = 44 (obligatorisch, hier auch Dezimalangabe möglich)
  |Breitenminute = 44 (optional)
  |Breitensekunde = 44,00 (optional)
  |Länge = O/W (obligatorisch)
  |Längengrad = 12 (obligatorisch)
  |Längenminute = 33 (optional)
  |Längensekunde = 33,00 (optional)
  |Name = Wrack der Titanic (optional, bei mehreren Koordinaten in einem Artikel sinnvoll, 
          z.B. verschiedene Standorte etc.; wenn kein Name da, dann gilt Artikelname )
  |Ausdehnung = 10.000 (optional) in km, allenfalls mit Dezimalangabe (0,5)
  |Typ = Stadt/Landmarke/Gewässer/Berg/Land/Admin1/Admin2 (optional)
  |ISO_3166-2 = DE-BY,AT-9 (optional, Komma getrennt für mehrere Regionen bei Bergen/Seen im Grenzgebiet)
  |Einwohner = 100000 (optional)
  |Höhe = 4500  (optional, Höhe für Pässe und Berge)
}}

• geokoordinate in eine eigenen box zu basteln wie wohl der vorschlag von dir geonick ist halte ich für nicht sinnvoll, weil es einfach eine redundante datenerfassung ist;
  • zum einen kommen in die Boxen je nach typ eh die angaben Einwohner, Höhe usw. weil es einfach grundlegende angaben sind.
  • Weiterhin gehören nach meinem (und wenn ich mir dir boxen so angucke nach der von vielen/der meisten) auch die korrdinaten in die Box. Die Box "darunter" zu basteln und quasi als teil der Box darzustellen dürfte spannend werden da die boxen sich wohl optisch unterschieden dürften.
  • Die Problematik der redundaten datenerfassung wird schnell klar; einwohnerzahlen bei orten ändern sich regelmäßig und müssten also stets in zwei boxen erfasst werden; wird regelmäßig nicht gepflegt werden
  • welcher typ die mit Vorlage:Infobox (Polen) gekennzeichneten boxen sind kannst du leicht an dem Quelltext erkennen dort steht "type:city"
  • nicht verstehe ich " Der Nachteil einer so lockeren Regelung ist, dass der Hypertext-Linkmechanismus nicht mehr wie zurzeit bei Vorlage "Koordinate ..."" ... tut er doch? siehe Łódź habe rechts oben den link?! oder meinst du was anderes
  • einem programm sollte doch beizubringen zu sein innerhalb einer box welche mit {{ anfängt nach einem schlüsselwort wie Breitengrad zu suchen und sich dann auch die anderen entsprechenden daten noch zu nehmen. ist das schlüsselwort nicht drin passiert nix und gut?!...Sicherlich ^Post 15:05, 18. Mär 2006 (CET) PS: habe erstmal mit dem boxenerneuern für pl-städte aufgehört, da es ja zumindest bzgl. der benamsung änderungen geben könnte

Sicherlich: Bitte informiere dich, woher die Vorlage (Geo-)Koordinate (en:Template:coor) kommt. Und nochmals ganz in Ruhe: Ich bin deiner Meinung, dass Höhe und Einwohner und auch Typ(!) redundant und daher zu vermeiden sind. Alle diese könnten aus dem Wiki-Text gelesen werden (Typ City könnte z.B. eine zusätzliche Kategorie 'Ort' sein). Als Kompromiss sind sie noch da aber optional. Die Vorlage "Infobox (Polen)" nutzt geschickt die Möglichkeit, andere Vorlagen einzubetten. Im Wiki-Text von Łódź ist von Vorlage "Koordinaten..." (und von type:city) nichts zu sehen: MediaWiki holt sich die Information von der Vorlage "Infobox (Polen)". Das bedeutet, dass die Vorlage "Koordinate..." in anderen Vorlagen vorkommt, d.h. Abhängigkeiten entstehen. Vorlagen in Vorlagen sind unerwünschte Indirektionen und sowohl technisch wie auch aus Autorensicht umstritten (Sichtbarkeitsprinzip: Man soll dem Wiki-Text von Lodz ansehen, dass "Infobox (Polen)" vom type:city ist und Vorlage "Koordinate Artikel" enthält).

Fazit mit Vorlage Geokoordinate und gemeinsamen Attributnamen

Nun habe ich einen neuen, alten Regelungsvorschlag, welcher alles unter einen Hut zu bringen versucht: Alle Schlüsselwörter (='Tags': Breite, Breitengrad, Breitenminute, Breitensekunde, Länge, Längengrad, Längenminute, Längensekunde, Name, Ausdehnung, Typ, ISO_3166-2, Einwohner, Höhe, alles deutsch, gemäss Vorschlag oben) in Vorlage "Geokoordinate Artikel/Text/Text Artikel" und in allen anderen Vorlagen sind gleich zu benennen mit dem Unterschied, dass in 'normalen' Vorlagen "Georef_" (oder "Geokoordinate_" oder "GPS_"?) vorangestellt wird und in Vorlage "Geokoordinate" nicht (da fehlt dann eine logische Klammer um alle Geo-Schlüsselwörter, was eine Sünde im grossen Wiki-Bruder XML ist, und wer instruiert dann alle Infoboxen-'Bastler', aber lassen wir's...). Wo diese Schlüsselwörter (Georef_Breite, Georef_Breitengrad) in Infoboxen vorkommen, darf die Vorlage "Geokoordinate Artikel" nicht vorkommen. Diese muss als Vorlage in die Infobox-Vorlage eingebaut sein (einzig wegen dem Link, ohne versteckte type-Angaben und wehe, wenn die Vorlage Geokoordinate nochmals ändert...). Typ muss in Vorlage "Geokoordinate" optional sein nur schon für den Fall, dass er in Infoboxen-Vorlagen nicht vorkommt (Sichtbarkeitsprinzip). Lieber wäre mir, wenn Typ ganz in Kategorien integriert würde. --Geonick 21:42, 18. Mär 2006 (CET)

"Vorlagen in Vorlagen sind unerwünschte Indirektionen und sowohl technisch wie auch aus Autorensicht umstritten" - nunja umstritten zeigt wohl das es durchaus vorkommt also es leute gibt die den nutzen sehen ;) ... wenn ich deinen vorschlag richtig verstehe dann sollte die Infobox (Polen) jetzt Geo Infobox (Polen) heißen und dein Progrämmchen merkt dann "oh da steht geo also praktische infos für mich?!" .. und was noch drin steht ist ihm wurst? damit könnte ich leben. für den typ:city ...weiß nicht ob ich das selbe meine, aber das könnte anhand der kats ja schon erkannt werden oder? wenn da steht Kategorie:Ort in XYZ ist es wohl ein ort?! wenn dadurch type:city wegfällt fände ich das toll!...Sicherlich ^Post 19:05, 19. Mär 2006 (CET)

Vorlagen in Vorlagen kommen vor, weil es Benutzer gibt, die einfach mal 'was machen... und die brauchts' auch! (man beachte auch, dass MediaWiki 'over-engineered', d.h. kaum wartbar geworden ist!). Nun ist aber Einfachheit und Nachnutzbarkeit der Georeferenzierungs-Arbeit angesagt. Stelle dir z.B. vor, man beschliesst später, jeder Koordinate noch eine Qualitätsangabe zuzuordnen: Würde nur Vorlage Geokoordinate verwendet, wäre alles klar...! Nun also: Das mit der Namensgebungs-Regelungen von Vorlagen (Infobox (Polen) => Geo Infobox (Polen)) innerhalb der von dir bevorzugten Regelung "Fazit mit Vorlage Geokoordinate und gemeinsamen Attributnamen" ist kein schlechter Vorschlag. Ich denke aber, dass das nicht nötig ist. Wichtig ist hier, dass Attributnamen (Koordinate_Breite, |Koordinate_Breitengrad, etc. vgl. oben) wirklich einheitlich sind und explizit im Wikitext erscheinen (was beides bei Infobox Polen nicht der Fall ist aber leicht noch geändert werden könnte). In der Zwischenzeit habe ich mich nochmals über die Syntax der Bergtabelle informiert (vgl. de:Matterhorn und en:Matterhorn): Diese hat den Vorteil, dass die Vorlage Geokoordinate (die ja hier immer noch im Zentrum steht), direkt im Wikitext sichtbar ist - also etwas, was genau eines der Probleme beim Lösungsvorschlag a la "Infobox (Polen)" ist. --Geonick 15:09, 22. Mär 2006 (CET)

so habe unter Vorlage:Geo Stadt (Polen) mal gebaut wie es wohl sein soll; allerdings nur demo; die vorlage an sich ist noch nicht angelegt. weiterhin würde da die vorlage {{Koordinate Text Artikel ... eingebaut sein; bis es anders geht. zu der vorlage

1.) ich finde es nach wie vor nicht sinnig die angaben wie "Koordinate_Breite=W" & "type=city " die in der vorlage eh immer gleich sind in die artikel einzubauen; das sollte ein Programm sich aus der zugrundliegenden Vorlage nehmen können wo man es "versteckt" einbauen kann

2.) muss die Vorlage "Geo Stadt (Polen)" heißen oder geht auch "Infobox (Polen)" weil das progrämmchen einfach die stichworte wie "Koordinate_Breitengrad=" erkennt?! ...Sicherlich ^Post 18:56, 22. Mär 2006 (CET)

Zu 2.) "Infobox (Polen)" genügt, weil das Progrämmchen - welches wächst und wächst - damit nichts besonderes anfangen kann ausser zunächst mal mit der öffnenden Doppelklammer ("{{"). Am liebsten wäre es ihm wie gesagt, es dürfte sich nur auf "{{Koordinate" konzentrieren... :->

Zu 1.) Ich beschwöre dich, Sicherlich: lass' "Koordinate_Breite=O" so drin. Das Progrämmchen kann nicht ahnen, dass der Artikel, den es vor sich hat, eine Stadt östlich Greenwich ist und dann landet Lodz noch in der Porcupine Abyssal Plain. Und verstecke bitte nichts, sondern pack' alles was dir lieb ist in die Infobox, bzw. in den Wikitext wie es z.Zt. der Fall ist. Der Artikelinhalt ist damit für jeden kontrollierbar - ich nenne es das Sichtbarkeitsprinzip. Der Wikitext ist die beständigste Information, die wir haben.

Noch etwas: Beim Betrachten deiner neuen Vorlage ist mir aufgefallen, dass die Koordinate(n)-Schlüsselworte konsequenterweise ohne '_' geschrieben werden sollten (also z.B. "KoordinateBreite). --Geonick 22:08, 22. Mär 2006 (CET) P.S. und "ISO 3166-2" sollte unbedingt "ISO_3166_2" geschrieben werden, damit es keine Unklarheiten gibt.

Ich kann mich Geonick nur anschliessen, was das Auslagern angeht. Bitte nix auslagern, da sonst alles nur komplizierter würde, für Benutzer und für Software. Die "ISO_3166_2" würde nach einigen Überlegungen doch besser in "Koordinate_Region" umbenennen! Wir haben auch Positionen die nicht ISO-konform sind z.B. Berge auf einer Grenze oder Punkte in Ozeanen (Ölplattform, Untergangsstelle etc.). Die sollten wir dort auch mit einbringen können. -- sk 08:11, 23. Mär 2006 (CET)

Zum "Progrämmchen:". Wie sieht dieses Progrämmchen aus? Welche Konstrukte kann das Programm auswerten? Kannst du es nicht mal hier posten (oder Teile davon)? --Arcy 08:08, 23. Mär 2006 (CET)

Das tu' ich gerne - es ist einfach noch nicht fertig. Es wertet z.Zt. Vorlage "Koordinate ..." aus und ich bin bereit dieses auch auf Schlüsselwörter "KoordinateBreite, KoordinateBreitengrad, KoordinateBreitenminute, Breitensekunde (etc...)" zu trimmen. Nur: Wir kämpfen auf dem Toolserver noch mit Dingen, die uns hier eh' fast keiner glauben würde:-> --Geonick 00:57, 24. Mär 2006 (CET)

@Sichtbarkeitsprinzip; ist ja auch in der jetzigen form für jeden kontrollierbar; wer die box verstehen will muss sich eh die vorlage angucken und in letzter konsequenz müssten die vorlagen alle jeweils mit {{subst: eingebaut werden; wegen der sichtbarkeit ... wird bei {{Koordinate ... aber glaube ich nicht gemacht ;o)

@ISO 3166-2 ... also wenn dann ISO_3166-2 .. wenn das so heißt sollte WP das nicht umdefinieren weil es besser aussieht; damit der nutzer eine chance hat zu wissen was es ist: "Koordinate_Region" sollte es auch nicht heißen; begrünung wie zuvor; keine Wikipedia-Geheimcodes ...Sicherlich ^Post 10:01, 23. Mär 2006 (CET)

Schau dir bitte den Wikitext von Lodz an ("Seite bearbeiten"); hier siehst weder du noch irgend ein Progrämmchen irgendetwas von 'type:city', denn diese Angabe ist nicht dort sondern in der aktuellen "Infobox (Polen)" und zwar 'versteckt' wie du es oben selber genannt hast. ISO_3166-2 ist problematisch, da es mehr als drei Möglichkeiten gibt für Bindestriche (vgl. Artikel Typographie); 'Koordinate_Region' (bzw. KoordinateRegion) ist tatsächlich noch besser (sk: das hatten wir doch schon mal?), da es ein sprechender, selbstdokumentierender Name ist (ISO_xxx_yy ist eher ein Wertebereich und Zahlen man sich eh' schlechter merken als 'Region'). Bleibt höchstens noch die KoordinateAusdehnung anstelle von KoordinateScale (???), dann wären unser Progrämmchen und ich happy! --Geonick 00:57, 24. Mär 2006 (CET)

Kommentare zu den beiden Regelungsvorschlägen

Wer soll den Text da oben noch mitverfolgen? Da könnt ihr doch gleich Telefonkonferenz machen. *grummel*

(a) Die Kommentare zu Type und ähnlichem versteh ich nicht - der kvaleberg hat die doch verarbeitet, als müssen die doch auch rein?! Die Verbesserungen betreffen dann also Dritt-Tools. Oder will wer einen de-spezfischen Kartendienst als kvaleberg-Ersatz aufstellen?

(b) Die ganzen Benennungen/Umbenennungen/Formate kranken mir an der fehlenden Sicht, Tools und Daten zwischen den Sprachvarianten der Wikipedia austauschen zu können. Je einfacher umso besser. Viele schoene Varianten machen Arbeit, die irgendwann wiederholt werden muss, wenn wieder wer was auszusetzen hat. Oder noch eine Box-Variante dazukommt, umgestellt wird, zwischen Wikis abgeglichen wird.

(c) Die Frage nach der Koordinaten-Notation ist mal fix ausgeklammert worden (taucht nur einmal am Anfang auf). Ich hab noch keine Zeit gehabt, denn ich denke, es hängt davon ab, was bei Kartenmaterial heutzutage als Gitter bevorzugt auftaucht - die historische DMS notation, die nautische DM.X notation, oder über GPS eingeflossene dezimale D.XX Notation. Letztere beiden würde viele Vorlagenprobleme/varianten nichtig machen.

cheers, GuidoD 16:51, 20. Mär 2006 (CET)

@(b) - du meinst die bisherigen Stadtboxen sind nicht geeignet bots dazu zu nutzen informationen zu aktualisieren, ergänzen und anzupassen und die "polnische box" ist dazu sehr gut geeignet? ...Sicherlich ^Post 20:13, 20. Mär 2006 (CET)

Zu a) GuidoD: Wir (vgl. Unterschrift) sind daran, eine Datenbank mit Arbeitstitel 'WikiPoint' aufzustellen. Die Funktionalität des kvaleberg-Services ist davon nicht betroffen - ausser wir verbessern die Vorlage, was meiner Meinung nach nötig ist. So wird dort type z.B. ja gerade nicht verarbeitet! Zudem werden die Parameter unsauber - d.h. ohne eigenen Namen - übergeben (vgl. dort: ?params={{{1}}} {{{2}}}). Daher die Verbesserungsvorschläge zur Vorlage "Koordinate ..." oben.

Und für alle, denen es wie mir Sorgen macht, dass der Kvalebergs Dienst offenbar nicht beeinflusst werden kann, mache ich auf dem Toolserver einen Weiterleitungs-Service, so dass eine allfällige neue Vorlage Geokoordinaten-Vorlage immer noch mit dem kvaleberg-Service zusammenpasst.

Zu b) Ganz deiner Meinung: unser 'WikiPoint'-Datenbankprojekt dient u.a. auch der Grundlage für die Integration von Koordinaten in Sprachvarianten. Daher mein Vorschlag oben, sich auf die Verbesserung der Vorlage "Geokoordinate Artikel/Text/Text Artikel" zu konzentrieren und folglich Koordinaten aus Infoboxen fernzuhalten. Alle Infoboxen (@Sicherlich: auch diejenige von Polen!) - müssten in diesem Falle nochmals vereinfacht werden und Koordinaten-Angaben der Vorlage "Geokoordinate..." im Wikitext selber überlassen.

Zu c) Die Frage nach der Koordinaten-Notation ist nicht ganz ausgeklammert worden: sk schlug vor, alternativ die Dezimalnotation zu verwenden, was ich einen guten Vorschlag finde und übernommen habe (vgl. Fazit oben) --Geonick 08:25, 21. Mär 2006 (CET)

Stadtboxen zu kürzen nur um eine zweite Box einzuführen halte ich für nicht sinnvoll ... daher wird die polnische box wohl so bleiben. Wenn es bessere Ideen gibt bitte ggf. auf Portal:Polen bescheid sagen. Bis dahin werden wir die neue Box verwenden ...Sicherlich ^Post 09:42, 21. Mär 2006 (CET) Sicherlich: Könntest du bitte Argumente bringen oder mal nix sagen und in der Zwischenzeit dich über die Vorlage Koordinate informieren? Danke, Geonick.

Argumente; gern nochmal:

1. Stadtbox soll koordinaten enthalten weil sie einfach da rein gehören, siehe auch die deutsche Stadtbox welche wenn ich mich recht erinnere per Meinungsbild entstand (oder damals noch abstimmung)
2. eine zweite Box ist optisch schwer an die erste anpassbar, da die boxen optisch recht unterschiedlich sind (weil ja wohl auh berge etc. rein sollen)
3. einen extra box würde redundante datenerfassung bedeuten
4. in der polnischen Box liegen die daten in maschinenlesbarer form vor
5. die polnische Box ermöglicht ein abgleich von verschiedenene daten per bot, auch zwischen verschiedenen wikipedias,

...Sicherlich ^Post 10:32, 21. Mär 2006 (CET)

@Sicherlich: Wir sind hier im "Kommentar zu den beiden Regelungsvorschlägen". Darf ich deinen Worten entnehmen, dass du für das "Fazit mit Vorlage Geokoordinate und gemeinsamen Attributnamen" votierst (womit ich leben kann)? Damit sind Stadtboxen berücksichtigt - vorausgesetzt wir einigen uns noch auf Attributnamen (Vorschlag siehe Syntax im "Fazit mit Vorlage Geokoordinate"). Das hiesse auf Infobox Polen - aber nicht nur diese! - bezogen, dass man die Namen anpassen müsste, falls das Ziel sein soll, Koordinaten maschinell weiterzuverarbeiten.

• Zu 2 und 3: Vorlage "Geokoordinate" ist keine Box sondern ein Datenbanklink. Keiner der beiden Regelungs-Vorschlägen oben führt zu redundanter Erfassung und keiner schlägt eine zweite Box vor (habe ich am Beispiel Bergtabelle in deinem Sinne als nicht sinnvoll bezeichnet). Der Hauptunterschied von beiden Regelungen ist, dass im Wikitext bei "Fazit mit Vorlage Geokoordinate" immer eine Vorlage "Geokoordinate..." verlangt wird (Koordinaten nur dort) und im Falle von Stadtboxen und Bergtabellen z.B. eine ausgefüllte Vorlage "Infobox (Polen)" (ohne Koordinaten) _und_ unten eine Vorlage "Geokoordinate" existieren würde. Eine Vorlage "Koordinate" gibt es schon lange (inkl. Meinungsbilder) und braucht's so oder so (dann halt als zusätzlicher(!) Bestandteil der polnischen Vorlage!).
• Zu 5: Die aktuelle polnische Box arbeitet bezüglich Koordinaten mit Vorlagen in Vorlagen (du müsstest sagen "Box in der Box") sowie mit nicht einheitlichen Attributnamen. Beides erschwert den Abgleich. Oben stehen daher zwei Regelungen zur Diskussion.

Beachte also, dass es auch bei der von dir bevorzugten Regelung hier noch eine Diskussion zu Vorlage "Geokoordinate..." braucht. Nun bin ich interessiert, mal noch andere Stimmen hier zu hören. --Geonick 11:54, 21. Mär 2006 (CET)

• • ich votiere noch gar nicht; warte noch auf die antwort auf meine Fragen eine überschrift weiter oben. da ich mich eigentlich nicht betroffen fühle (alles was ich nutze funktioniert) werde ich jettz einfach mal die Box weiter einbauen; bis hier irgendwas relevantes passiert wird es wohl noch dauern...Sicherlich ^Post 12:07, 22. Mär 2006 (CET)

Ok; ist recht aufwändig, dir das Denken zu erleichtern ;-> aber Wikipedia braucht auch 'Macher' wie du. --Geonick 15:13, 22. Mär 2006 (CET)

Grundsätzliche Anmerkungen zu dieser Diskussion

Nachem ich gestern auf diese Diskussion hingewiesen wurde und wir mit unserem Projekt direkt von den hier diskutierten Varianten betroffen wären, ein paar Anmerkungen. Vorneweg: ich bin noch immer WP-Neuling, d.h. kenne mich mit den technischen Möglichkeiten nur sehr oberflächlich aus. Deshalb sei mir verziehen, wenn ich evtl. unrealistische Ansätze beschreibe. Aber vielleicht hilft ja genau eine Sicht, die noch nicht von zu viel Details verstellt ist, hier zu einem konstruktivem Ergebnis zu kommen. Zunächst scheint mit, dass in dieser Diskussion mehrere Gruppen aufeinander treffen, die aufgrund unterschiedlicher Nutzungsszenarien der Geo-Daten zu komplett unterschiedlichen Anforderungen kommen: z.B: Editoren, d.h. Leute die Artikel für WP schreiben, Vorlagenbauer, die an einer Standardisierung von Artikelgruppen arbeiten (und damit die Qualität von WP insgesamt verbessern und die Arbeit für die Editoren erleichtern) und Bot-Entwicklern, die die in WP gespeicherten Informationen nutzen wollen um daraus Mehrwert-Dienste zu bauen (die auch wiederum die Qualität von WP steigern helfen können). Auch wenn ich selbst der letzeren Gruppe zugehöre, bin ich der Meinung, dass im Zweifel immer das Interesse der Editoren im Hinblick auf eine einfache und robuste Erstellung von Artikeln im Vordergrund stehen muss. Von diesem Standpunkt ausgehend ergibt sich für mich zwangsläufig, dass es nicht sein kann, dass Vorlagen so umfassend ausgelegt sind, dass eine umfassende Auszeichnung von Artikeln mit Information durch den Editor erfolgt. Vorlagen sollten nach meiner Überzeugung ja gerade auch bestimmte Implikationen und Festlegungen vorgeben können, d.h. wenn es eine Vorlage "Infobox (Polen)" für Orte in Polen gibt, so sollte dies auch implizit festlegen, dass es sich um einen type=city, region=pl handelt und dass alle Geo-Koordinaten implizit im nördlichen und östlichen Koordinatenraum liegen. Eine entsprechende Erfassung durch den Editor ist dann nicht notwendig. Dies kann auch helfen, komplexe Ausnahmefälle, die aber nur in wenigen Konstellation auftreten i.d.R. gar nicht an den Editor rankommen zu lassen (will man z.B. für eine alle Orte eine Auszeichnung vornehmen, auf welchem Kontinent sich ein Ort befindent, so könnte dies für die meinsten Länder implizit festgelegt werden, und nur Vorlagen für Orten in kontinentübergreifenden Ländern bräuchten hier eine Information des Editors). Auch könnte jede nach Art des zu beschreibenden Objekts unterschiedlich komplexe Auszeichnungsformen genutzt werden. So könnte für einfache Locations die Auszeichnung eines Punkts mit Durchmessers ausreichend sein, für sehr grosse, unregelmässige Objekte (z.B. Kontinente) will man vielleicht deren Begrenzung durch Geo-Polygone beschreiben.

Ich denke, dass es sehr viele Informationen gibt, die einerseits sinnvoll beschrieben werden können, und für eine automatische Auswertung auch sinnvollerweise strukturiert erfasst werden sollten, aber andererseits die konkreten Optionen nur für jeweils begrenzten Teilmengen von Artikeln anwendbar sind. Deshalb würde ich eine "Eierlegende-Wollmilchsau-Vorlage" nicht für sinnvoll erachten. Sie würde entweder auf eine unnötig kleine gemeinsame Teilmenge hinauslaufen oder zu komplex werden, dass sie akzeptiert und korrekt genutzt werden würde.

Mein Fazit ist deshalbt, dass es für die qualitätsgesicherte und leicht erlernbare Erstellung von Artikeln sinnvoll ist Vorlagen zu nutzen, die bestimmte Implikationen und Vorgaben mit sich bringen. Entsprechend halte ich den Ansatz von "Infobox (Polen)" für sehr sinnvoll.

Bleibt das Problem, dass dann wir Bot-Entwickler ständig mit neuen Vorlagen zu kämpfen haben.

Nicht geeignet halte ich den Versuch, standardisierte Namen (oder Namensbestandteile) für Vorlagen-Parameter zu vergeben, da es hierfür m.W. in WikiMedia keine Validierungskonzepte gäbe, und es meines Erachtens nicht realistisch ist, dass sich Vorlagen-Entwickler aus einem Themenbereich über Konventionen in anderen Bereichen informieren, bevor sie sich einen Namen für einen Parameter ihrer Vorlage ausdenken. Das führt nur zu Problemen und Abstimmungsdiskussionen.

Gleichzeitig wäre es für mich als Bot-Entwickler aber auch nicht praktikabel, wenn ich für jede neue Vorlage einen speziellen Parser programmieren müsste, der die spezifischen Implikationen jeder Vorlage programmtechnisch umsetzt.

Statt dessen würde ich mir wünschen, dass es sowas wie "Meta-Vorlagen" gibt, die in den eigentlichen Vorlagen Verwendung finden (nicht in den Artikeln selbst) und die wiederum Implikationen und Konventionen der jeweiligen Vorlage für einen Bot beschreiben. Teile der Probleme von "Vorlagen in Vorlagen" könnten von vorneherein ausgeschlossen werden, wenn die Meta-Vorlagen selbst keinen Output erzeugen, sondern nur dokumentierenden Charakter haben. Deshalb könnten sie auch im <noinclude> stehen. Jetzt müsste man nur noch einen "Meta-Vorlagen"-Bot schreiben, der alle (Artikel-)Vorlagen findet, die direkt oder indirekt die für den eigentlichen Bot relevanten Meta-Vorlagen nutzen und die darin definierten Regeln auswertet.

Dies alles ist dann natürlich für Bot-Entwickler deutlich aufwändiger: Jeder Bot-Entwickler der Informationen auf Basis der Meta-Vorlagen nutzen will, müsste zunächst den "Meta-Vorlagen-Bot"-schreiben, der ihm dann rekursiv alle Vorlagen herausfindet, die direkt oder indirekt die für ihn relevanten Meta-Vorlagen nutzen. Darüberhinaus müsste jeder Bot dann auch noch die Vorlage-Ersetzungs-Mechanismen von MediaWiki nachimplementieren um von den Vorlagen-Parametern des Artikels zu den Parametern der der für ihn relevanten Meta-Vorlage zu kommen. Ein zweiter Nachteil ist die Performance bei der Suche nach zu parsenden Artikeln. Schon heute dauert bei uns die Suche in der Datenbank nach allen Artikeln die {{Koordinate enthalten fast ebenso lang, wie die anschliessende detaillierte Analyse aller geoindizierten Artikel. Dies würde noch deutlich langsamer werden, wenn nicht nur nach einer, sondern nach eine Vielzahl von Vorlagen gesucht werden müsste. Entsprechend wäre es wünschenswert, wenn direkt aus MediaWiki heraus Unterstützung für ein entsprechendes Feature vorhanden wäre. Alternativ könnte man natürlich auch einen eigenen Wiki-Meta-Vorlagen-Bot-Dienst aufbauen, der die Meta-Vorlagen-Suche, Artikel-zu-Meta-Vorlagen-Indizierung und Meta-Vorlagen-Parameter-Ermittlung implementiert und diesen anderen Bots zur Verfügung stellen.

Das mag erstmal nach viel Arbeit für Bot klingen (was es wahrscheinlich auch ist), erwwährleistet jedoch, dass man als Bot-Entwickler nicht ständig in der Angst leben muss, dass mal wieder eine neue Vorlage auftaucht, für die man dann die Bot-Programmierung anpassen muss. Die Entwickler der neuen Vorlage werden wahrscheinlich selbst darauf achten, die zutreffenden Meta-Vorlagen in ihre Vorlagen einzubauen. Und falls es doch mal ein Vorlagen Entwicker übersehen hat, kann man leicht selbst die Meta-Vorlage dort nachtragen. Auch scheint es mir dann leichter möglich, auch nach neuen Aspekte zu suchen, indem man ein neue Meta-Vorlage definiert und sie in den bestehenden Vorlagen einträgt, die diese Anspekte herleiten lassen.

Ein (aus meiner Sicht ein riesiger) weiterer Vorteil eines solchen Ansatzes könnte sein, dass Meta-Vorlagen, da sie ja nicht dafür vorgesehen sind, in Artikeln verwendet zu werden von vorneherein international ausgerichtet sein könnten, d.h. deren Namen und Parameternamen in allen Wikis gleich sein könnten. Dies würde einerseits die Arbeit für Bots die mehrsprachig arbeiten erheblich vereinfachen, gleichzeitig aber auch eine "diskussionsarme" Integration erlauben, da sie zwar in bestehende Vorlagen eingebaut werden müssten, jedoch nichts an deren Verhalten oder Parameter-Liste ändern würden.

Soweit meine grobe Ideenskizze. Kommentare von alten Wikipedia/Wikimedia-Hasen bezüglich Sinnhaftigkeit und Machbarkeit würden mich sehr freuen.

Noch ein paar Anmerkungen zu den diskutierten konkreten Vorlagen-Parametern und Notationen:

• Da man in Wiki-Vorlagen (im Gegensatz zu Bots) nicht umrechnen kann, sollten m.e. immer die für die Darstellung in Wikipedia geeignetste Notation gewählt werden. Bei den Koordination heisst dies aus meiner Sicht die Grad/Minuten/[Sekunden[.Hunderstel]]-Notation anstelle einer Dezimalnotation.

• Zur Ermittlung der Ausdehnung eines Objekt ist der bisher verfübare Scale m.e. völlig ungeeignet. Selbst wenn es möglich wäre ihn umzurechnen, bezweifle ich dass sich jemand die Arbeit machen würde. Gleichzeitig benötigten unterschiedlche Objekte evtl. unterschiedliche Arten der "Ausdehnungsangabe". Überschaubar grosse Objekte werden wahrscheinlich am einfachsten mit einem Durchmesser (in Metern/Kilometern) beschreiben. Für Länder wird man hingegen vielleicht eher die begrenzenden Längen/Breitengrade angeben. Und für Objekte, bei denen man möglichst genau und Überschneidungsfrei die Ausdehnung beschreiben will, macht sich vielleicht sogar jemand die Mühe und bestimmt ein Geo-Polygon.

• Was die Frage der Nutzung von Kategorien für Dinge wie "Type" angeht, so sind Kategorien m.e. nur bedingt geeignet eine Typisierung innerhalb einer (begrenzten) Typ-Klasse vorzunehmen, da WP hier zu leicht erlaubt neue Kategorien anzulegen (was ja für Wikipedia auch gut ist) und dann hier die Bot-Programmierer ständig am hinterherprogrammieren wären, wollen sie vernünftig klassifizieren. Allerdings könnte ein oben beschriebener Meta-Vorlagen-Mechanismus auch hier evtl. weitehelfen: Wenn in einer Kategorie-Seite "Orte in Bayern" eine Meta-Vorage "GeoType" festlegt, dass es sich um eine Artikel dieser Kategorie GeoType=city haben, wäre einerseits die Redundanz aus den Artikel entfernt, gleichzeitig aber auch automatische sichergestellt, wenn jemand eine neue Kategorie "Orte in XXX" anlegt und dort auch die Meta-Vorlage nutzt, dass die Bots auch dies korrekt erkennen werden.

• Ein Erweiterungswunsch von unserer Seite wären noch Parameter, die "Ist Teil von" oder "Liegt in"-Beziehungen zwischen von Artikeln beschrieben Locations (z.b. für Stadtteile (1:n-Relation) oder Seen (n:m-Relation)) darstellen. Für unsere Anwendung (und bestimmt viele andere auch) wäre es super, wenn wir z.B. nicht nur wüssten, dass ein Artikel einen Stadtteil beschreibt, sondern auch, von welcher Stadt. Selbst wenn wir zustätzlich zu den Koordinaten zu allen Artikeln noch eine Ausdehnung (als Radius) bekommen würden, könnten wir dies im allgemeinen nicht fehlerfrei automatisch ermitteln da die so beschriebenen Ausdehnung eines Objekts mit einem Radius nicht exakt und auch nicht überschneidungsfrei mit anderen Objekte festgelegt werden können. Hierfür müssten für jedes Objekt "Grenzpolygone" definiert werden -- was aber nicht praktikabel ist. Und da man nicht für jede dieser Beziehungen eine eigene Kategorie (z.B. Stadtteile von München) anlegen wollen wird, scheinen hierfür definierte Parameter, die Referenzen zu anderer Artikel aufnehmen, der beste Weg zu sein. Auch diese könnten dann wieder mit Hilfe von Meta-Vorlagen gefunden und automatisch ausgewerten werden. Hat man jedoch dann eine (einfach beschriebene) Ausdehnugn eines (Grossen) Objekts und gleichzeitig eine Vielzahl von Objekten, die sich als Unterobjekte des Grossen erklären, kommt man hier sehr schon sehr weit.

Ptma 09:35, 24. Mär 2006 (CET)

Vielen Dank, Ptma, für deine ausführliche Stellungnahme. In unseren Falle der Georeferenzierung versuchte ich immer genau die drei Standpunkte (Editoren, Vorlagen-Bauer und Bot-Entwickler), die du schön skizziert hast unter einen Hut zu bringen, um aus Mediawiki das Beste für alle herauszuholen. Als Software-Mensch ist mir eigentlich nichts zu schade. Aber wenn ich deine Ausführungen richtig verstehe, dann muss ich dich enttäuschen, denn diese sind aus verschiedenen Gründen nicht umsetzbar, denn: Die Erweiterungen sind sehr gross, erst recht mit dem aktuellen MediaWiki-Code. Und aus finanziellen und organisatorischen Gründen sind sie einfach nicht machbar in absehbarer Zeit. Und wie ich schon mehrmals ausführte, ist es unabdingbar und auch sinnvoll dass type:city und Breite=O _in den Wikitext_ kommt (Copy&Paste kostet nichts)! Soeben mussten wir übrigens einsehen, dass ein Direktzugriff auf Wikipedia.de über den Toolserver nicht geht. Bleibt also noch der Dump der Artikel (ohne Vorlage oder sonstige Tabellen): Da hinein muss die ganze Information!!! Ich habe auf de:WikiProjekt_Georeferenzierung#Fazit_mit_Vorlage_Geokoordinate_und_gemeinsamen_Attributnamen einen Kompromiss vorgeschlagen, der die Wünsche "der Editoren" noch stärker gewichtet. Und wir sind so nah dran... --Geonick 21:00, 24. Mär 2006 (CET)

Vorschlag: Kategorien differenzieren

Siehe: Wikipedia:Fragen zur Wikipedia#Vorschlag: Kategorien differenzieren

Dieser Vorschlag zielt dahin, auch in Google Earth etwas differenzierter auf die Objekte schauen zu können. -- Simplicius 11:11, 14. Mär 2006 (CET)

Verstehe nicht, welche Kategorie du differenzieren möchtest: Geht es um die Type-Angabe (aber die ist ja englisch) oder um 'echte' Kategorien (dort finde ich keine Kategorie 'Ort', nur 'Ort in der Schweiz', etc.)? -- Geonick 23:47, 15. Mär 2006 (CET)

Es ist vorstellbar über Werkzeuge wie CatScan oder Back-Category auch eine Kategorie 'Ort in Schweiz' auf seine unterordnung in Kategorie 'Ort' zurückzuführen. Die Stadtteile sind wirklich ein unschönes Problem, ich weiß nur nicht ob wir über eine Type-Angabe:district oder tausende Kategorien 'Stadtteil in XY' schneller und einfacher zum Ziel kommen. Kolossos 20:08, 16. Mär 2006 (CET)

Dass Kategorie 'Ort in Schweiz' auf Kategorie 'Ort' zurückgeführt werden kann, ist klar. Kategorien werden in MediaWiki ja in separaten Tabellen verwaltet. Type zu verfeindern ist eine reine Frage der Abmachung: Da es weltweit keine klare Definition Stadtteil gibt, wurden ja die Begriffshierarchie Admin1- und Admin2 gemacht. Nun müsste man einfach Admin3 zulassen. --Geonick 13:47, 18. Mär 2006 (CET)

Ich verstehe immer noch nicht, wo das Problem liegt: Kategorien können doch mit den MediaWiki-Mitteln jederzeit ergänzt werden. War ja übrigens schon immer mein Vorschlag, Koordinaten-Typ wegzulassen und durch Artikel-Kategorie(n) zu ersetzen. Ein Parser wie unserer kann ohne weiteres neben Vorlage "Koordinate Artikel/Text/Text Artikel" auch Kategorien auslesen. --Geonick 13:47, 18. Mär 2006 (CET)

Hola, mein Vorschlag bezog sich auf die Kategorien ([[Kategorie:...]]), nicht auf den Type.
Wobei "Kategorie" und "Type" in der Tat nach Doppelmoppel riechen, aber man muss immer schauen, ob etwas unbegrenzt oder abgezählt ist. Beim "Type" sollte man zu schätzen wissen, dass es eine abgesprochene, abgeschlossene Menge gibt. Hier fällt es zum Beispiel leichter, grafische Symbole zuzuordnen. Kategorien hingegen laufen immer auf eine händische Nachbearbeitung hinaus, fürchte ich.
Die Diskussion wegen neuer Kategorien ist schon im Archiv gelandet, leider. Siehe hier....
Was über die Facettenkategorisierung gesagt wurde (= Schnittmengensuche) finde ich auch richtig. -- Simplicius 17:01, 18. Mär 2006 (CET)

Den Vorteil der Abgeschlossenheit der 'Kategorie' Typ sehe ich auch. Daher bin ich (noch) nicht für dessen gänzliche Ablösung durch Kategorien. Betreffend Kategorien kann ich dir immer noch nicht folgen: Möchtest du Kategorien ändern, d.h. 'Ort' einführen? --Geonick 09:06, 19. Mär 2006 (CET)

Ja, ich möchte für Stadtteile eine andere Kategorie als schlichtweg "Ort", zum Beispiel "Ortsteil".

Für Deutschland gibt es eine geschlossene Anzahl kreisfreier kreiszugehöriger Städte sowie kreiszugehöriger Gemeinden. Hier macht die Angabe der Einwohnerzahl recht viel Sinn.

Die anderen Stadtteile, Quartiere, eingemeindeten Dörfer usw. sollte man in Google Earth und ähnlichen Applikationen zwar darstellen, aber nicht grössenbezogen nach Einwohnern.

Die Einwohnerzahl ist etwas verwaltungspolitisches. Hagen in Westfalen soll als Stadt ein Symbol kriegen je nach der Anzahl der Einwohner. Zum Beispiel rot. Hagen-Vorhalle soll auch ein Symbol bekommen, aber nicht einwohnerzahlbezogen, sondern eben nur als Ortsteil. Zum Beispiel rosa.

Also ist die Frage, wie die Kategorien nun heissen sollen usw. -- Simplicius 17:24, 20. Mär 2006 (CET)

Welche Notation für Geokoordinaten

Als bessere Basis einer Diskussion, habe ich ein paar Gedanken als Artikel zusammengefasst.

Wikipedia:WikiProjekt Georeferenzierung/Geokoordinate

ich selbst plädiere natürlich für dezimale Notation, ist einfach zukunftsträchtiger. Und mehr als Grad hat der Durchschnittsmensch für Orte eh nicht im Kopf. GuidoD 19:10, 20. Mär 2006 (CET)

Zur Info

Wikipedia:Formatvorlage Stadt (Polen) ist neu ...Sicherlich ^Post 19:36, 30. Mär 2006 (CEST)

Danke für die Initiative. Ich würde noch folgende kleine Verbesserungen begrüssen: Folgende Zeilen

 |ISO 3166-2=
 ...
 |type=city
 |Koordinate_Breite=N
 |Koordinate_Breitengrad=
 |Koordinate_...

sollten aufgrund der oben diskutierten Gründe so aussehen:

  |ISO_3166_2=
  ...
  |KoordinateTyp=city

.

Damit könnte ich leben und wir könnten die Diskussion zu "Koordinate..." und Infoboxen zu einem vorläufigen Abschluss bringen. Dabei möchte ich nochmals darauf hinweisen, dass hier die Attribute "KoordinateTyp, KoordinateBreite, etc. ein Ersatz der üblicherweise empfohlenen Vorlage "Koordinate Artikel" darstellen; d.h. dass letztere (unten) im Artikel nicht mehr ein zweites Mal verwendet werden soll (die Verwendung von "Koordinate Text" im Lauftext ist natürlich weiterhin möglich). --Geonick 18:11, 1. Apr 2006 (CEST)

Ja sieht gut aus, aber bei "ISO_3166_2=" sollte der komplette Code also "PL-SL" und nicht nur "SL" stehen. -- sk 21:13, 1. Apr 2006 (CEST)

Nachtrag: Ich wäre für "Koordinate_Breite" da das besser vom Menschen zu lesen ist. Mein Programm hat damit zumindestens keine Probleme. -- sk 12:18, 18. Apr 2006 (CEST)

Ok; habe mein Codebeispiel oben gekürzt und schliesse mich der Variante "Koordinate_Breite" an - Hauptsache, die Koordinaten-Namen sind *in sich* einheitlich benannt. --Geonick 14:12, 18. Apr 2006 (CEST)

Google Earth und Vorlage

Die Satellitenbilder von Google Earth sind ja nun flächendeckend für Deutschland hochaufgelöst, falls es nicht noch ein paar Ausnahmen gibt. Wie ich sehe, müsste man nun insbesondere für Gebäude viele Koordinatenangaben nachjustieren.
Ehe ich damit in den nächsten Wochen anfange, habe ich dazu aber auch mal eine Frage: was macht die Abstimmung darüber, die Vorlage in die Senkrechte zu bringen, sodass man die Koordinaten nur einmal eintragen muss statt doppelt?
Eine andere Frage noch zur Zuverlässigkeit der Positionierung der Google Earth Aufnahmen der Erdoberfläche: welchen Ellipsoiden verwendet Google Earth eigentlich überhaupt und entspricht dieser noch den alten gröberen Aufnahmen? -- Simplicius 16:58, 15. Apr 2006 (CEST)

Da ich gelegentlich mein GPS-Gerät mitlaufen lasse, kann ich für Dresden, Chemnitz und Hannover einen max. Gesamtfehler von 3-10m abschätzen, dieser Fehler kann z.T. auch durch das GPS-Gerät bedingt sein. Also aus meiner Sicht sind die Bilddaten gut für Gebäude verwendbar. GE arbeitet genauso wie der GPS-Standard und auch wir hier mit WGS84, somit muß man zum Glück keine Ahnung von der Koordinatenumrechnung und den Ellipsoiden haben.

Wenn es erstmal bei der alten Vorlage bleibt, sollte es mit dem Koordinaten-Ermittlungstool eigentlich ganz gut gehen.

Kolossos 17:24, 16. Apr 2006 (CEST)

Ok, dann trage ich WGS84 mal im Artikel über Google Earth ein.

Das Tool ging bei mir übrigens nicht im Internet Explorer, wohl aber im Mozilla. Wohl irgendwelche Sicherheitseinstellungen bei mir im Browser.

Mit nur einem einfachen GPS-Gerät ohne Referenzstation dürfte man wohl kaum besser als 3-10 m messen. Jedenfalls können unterschiedliche Ellipsoiden schon mal um bis zu einige hundert m abweichen, das war der Grund für meine Frage nach dem System. -- Simplicius 18:40, 16. Apr 2006 (CEST)

Leider hat Sicherlich auf die Verbesserungsvorschläge auf Zur_Info von sk und mir noch nicht reagiert. Meines Wissens herrscht daher immer noch 'status quo': Wer will, dass 'seine' Artikel auch in Google Earth erscheinen, sollte also weiterhin mit der Vorlage 'Koordinate Artikel' arbeiten - also auch dort wo in Infoboxen Attribute wie 'KoordinateBreite' (etc.) enthalten sind. Sobald wir dort zu einer 'Harmonisierung' kommen, kann in diesen Fällen die Vorlage 'Koordinate Artikel' weggelassen werden. --Geonick 15:39, 17. Apr 2006 (CEST) (P.S. Wir sind bald endlich fertig mit dem Basistool, das die Basis für einen aktuellen Index mit georeferenzierten Artikel bildet).

Was spricht denn dagegen, bereits die Vorlage Koordinate Artikel per Bot zu ändern? -- Simplicius 16:34, 3. Mai 2006 (CEST)

Vernünftige Bedienungsanleitung

Die Vorlage {{Lagewunsch}} verweist auf Wikipedia:WikiProjekt Georeferenzierung, doch ist diese Seite als Bedienungsanleitung reichlich ungeeignet.

Zum Beispiel, der Einsatz der Parameter region=... type=... wird nicht vernünftig erklärt.

Ergebnis: Stefan Kühn ist ständig in den neu verorteten Artikel am nachbasteln.

Lösung: Eine vernünftige Bedienungsanleitung - und das am besten für eine neue, vertikale Vorlage - muss her.

Und zum Thema vertikale Vorlage noch ein Hinweis: In der englischsprachigen Wikipedia sind die Koordinaten in der Städtebox ein Zweizeiler:

{
...
| latd = 42 | latm = 16 | lats = 31.26 | latNS = N
| longd = 83 | longm = 43 | longs = 51.02 | longEW = W
...
}

Das steht abgekürzt für Latitude und Longitude, degree, minute und second, sowie North South und East West. Sieht doch narrensicher aus.

Grüsse, Simplicius 13:01, 6. Mai 2006 (CEST)

Die Nutzung von Latitude und Longitude finde ich schlecht, weil 99% der Leute das so oder so verwechseln. Ich arbeite eigentlich nur dass nach, was am Anfang vergessen wurde, wo man den Sinn von type und region noch nicht so richtig sah. Die neuen Koordinaten sind fasst alle korrekt. Einzig und allein sind irgendwelche Schusselfehler, die immer mal wieder auftreten, ständig zu finden. Ich hab gerade bei cirka zehn deutsche Orte das region:BE ausgewechselt. Warum auch immer das dort stand? Ansonsten würde ich es so wie es gerade ist lassen. Die Umformatierung kann später auch ein Bot übernehmen. Lieber würde ich die Infobox für Deutschland einführen und dort die Koordinateneinbindung so vornehmen wie es bei der Infobox für polnische Orte gemacht wurde.-- sk 17:41, 6. Mai 2006 (CEST)

Eingedeutscht könnte man sicherlich

{
...
| Breite_G = 42 | Breite_M = 16 | Breite_S = 31.26 | Breite_NS = N
| Laenge_G = 83 | Laenge_M = 43 | Laenge_S = 51.02 | Laenge_OW = W
...
}

verwenden. Die polnische Alternative ist:

|Koordinate_Breite=N
|Koordinate_Breitengrad=52
|Koordinate_Breitenminute=13
|Koordinate_Breitensekunde=0
|Koordinate_Länge=O
|Koordinate_Längengrad=21
|Koordinate_Längenminute=02
|Koordinate_Längensekunde=0

Das Wort "Koordinate_" finde ich etwas zuviel des Guten. Kann man sich da irgendwo in der Mitte mal treffen? -- Simplicius 19:28, 6. Mai 2006 (CEST)

Ich sehe derzeit nur die Möglichkeit über eine Abstimmung zu einem Ziel zu kommen. Du kannst ja mal eine Abstimmung vorbereiten. Weil wir ja damit auch eine ganze Menge Vorlagen um uns herum extrem beeinflussen und die Bots eine Menge arbeit bekommen werden. Ich muss generell der deutschen Community ein Lob aussprechen, dass hier nur sehr wenige Koordinatenvorlagen existieren. Das Chaos in der englischen Wikipedia ist extrem kontraproduktiv und erinnert stark an den Turmbau zu Babel. Ich hab gerade den englischen Dump durchforstet und stehe nun vor vielen neuen Problemen in den 43000 Koordinaten. -- sk 20:27, 6. Mai 2006 (CEST)

Ich persönlich fände es am sinnvollsten, wenn man sich auf den Zweizeiler einigen könnte, denn trotz mehrere Variablen sind es ja eigentlich nur zwei Werte. Ich spreche mal Herrn Sicherlich dazu an. -- Simplicius 21:09, 6. Mai 2006 (CEST)

hmm ich finde den einzeiler übersichtlicher (und könnte jetzt auf pl verweisen wo das so gemacht wird ;) ) ... außerdem ist es IMO deutlicher es es um koordinaten handelt und nix anderes; mit kurzen variablen habe ich gerade dumme erfahrungen gemacht (bsp war Gemeinde - schön kurz aber jetzt dumm weil sie eine andere logische verwendung "blockiert" ;) .. gibt es eigentlich auf de schon andere vorlagen die die koordinaten in anderer version verwenden (also nicht {{Koordinate .. sondern so wie in der pl-box?..Sicherlich ^Post 21:26, 6. Mai 2006 (CEST)

achja; die pl-box ist schon in einigen mehreren artikeln drin ... ich würde ungern nochmal alle ändern lassen nur um externen programmen die bearbeitung zu ermöglichen ...Sicherlich ^Post 21:28, 6. Mai 2006 (CEST)

Diese Zugänglichkeit ist durchaus wichtig. Geoinformation ist Information wie andere auch, der Mensch befriedigt seine meisten Bedürfnisse nun mal im Raum, wie nicht nur Geografen wissen. Und wir schreiben die Sachen ja auch hier in diese Datenbank und nicht auf Papyrus, um diese Informationen vielfältig erschliessen zu können.

Jede neue Vorlage im Alleingang, was anderes ist die Infobox zum Beispiel für Polen wohl nicht, macht es schwieriger. Auf der anderen Seite braucht man solche Experimente auch, um zu sehen, wie etwas ausschauen könnte. Das soll also kein Vorwurf sein. -- Simplicius 21:52, 6. Mai 2006 (CEST)

dem "Vorlage im Alleingang" möchte ich vehement widersprechen; sowohl im portal:Polen als auch mit pl-WP erfolgte eine abstimmung; da wir ein internationales projekt sind ja durchaus relevant. Ansonsten würde ich sie mal in marketingsprache "first mover" nennen. Denn sie hat die sache ja scheinbar angestoßen. Aber anyways; für mich ist die untereinanderschreibung und die deutliche benennung übersichtlicher und scheint mir auch für den nutzer klarer ... aber natürlich IMO ... (ein meinungsbild wo jeder mal sagen kann wie man eine variable nennen will die zudem noch nur für externe programme relevant ist halte ich für übertriebene selbstverwaltung) ...Sicherlich ^Post 22:14, 6. Mai 2006 (CEST)

Ich kann mir aber eigentlich nicht vorstellen, dass es Euch völlig egal ist, ob polnische Ortschaften in Google Earth auftauchen?

Irgendwo habe ich auch eine Vorlage in einer Vorlage gesehen, interessante Konstruktion. In der Informatikersprache nennt man manche Vorstösse auch Insellösungen. Sie verhungern irgendwann.

In der Open Source-Bewegung bemüht man sich übrigens immer um [offene] Standards, damit nicht-bezahlte Programmierer in einer endlichen Zeit noch weiterkommen. -- Simplicius 22:23, 6. Mai 2006 (CEST)

@ google-earth; man könnte auch andersherum argumentieren ;) und wenn du mich persönlich fragst; ja mir egal .. ansonsten wie gesagt; die aktuelle version besteht bereits; nachteile in der einführung einer neuen version sehe sind m.E.: weniger leserfreundlich und es müssten viele inhaltslose edits durchgeführt werden. Vorteile sehe ich nicht ...Sicherlich ^Post 23:05, 6. Mai 2006 (CEST)

achja und die aktuelle pl-Lösung wurde ja auch mit dem geo-leuten abgestimmt und extra nochmal geändert; also in zwei wochen kommt der nächste mit noch nem besseren einfacheren, schöneren, schnelleren oder wie auch immer vorschlag? naja vielleicht wäre es mal wichtiger optische probleme durch die koordinaten wie beim Flughafen Krakau anzugehen statt variablen hin und her zu benennen ...Sicherlich ^Post 23:08, 6. Mai 2006 (CEST)

Auch ich bin für eine kleine Abstimmung, auch wenn ich dabei die alten Vorlagen befürworten werde, da diese deutlich kompakter, einheitlicher und flexibler sind als alles neue. So können z.B. diese Vorlagen mit und ohne Sekundenangaben betrieben werden. Die alten Vorlagen können auch problemlos in beliebigen Boxen betrieben werden. Kolossos 13:25, 7. Mai 2006 (CEST)

ich weiß ja nicht, ob die "polnische variante" zu den neuen zählt; aber auch diese kann problemlos mit oder ohne sekundenangabe betrieben werden. wenn die alte das {{Koordiante Artikel Text .. ist dann glaube ich eigentlich nicht, dass sie durch die "neuen" abgeschafft wird ...Sicherlich ^Post 13:31, 7. Mai 2006 (CEST)

Was die Sache mit den ggf. fehlenden Sekunden angeht, wie Kolossos anmerkt, lässt sich das wohl lösen.

Momentan gibt es zwei Varianten in den Infoboxen: a) Boxen, in denen Zeilen für die Geoangaben vorhanden sind, in der Regel fehlen region, type usw. b) Boxen, in die die Vorlage mit geschweiften Klammern eingefügt wird.

Habe ich das eigentlich verständlich formuliert?

Die erste Variante finde ich übersichtlicher, weil man nicht geschweifte Klammern innerhalb der geschweiften Klammern hat.

Die zweite Variante garantiert aber eines: Einheitlichkeit. Ich vermute, dass dies deshalb der bessere Weg ist.

Zwar gehen die meisten Infoboxen (auch in der englischen Wikipedia) schon einen anderen Weg, aber: die zweite Variante garantiert circa 4 diskrete Versionen (Artikel, Artikel Text usw.), die Anzahl der Infoboxen wird wachsen, die Infoboxen werden verändert, sie werden umbenannt, langfristig müsste Stefan Kühn (DER Leistungsträger bei der Auswertung der Dumps) also ein Ministerium für Infoboxen eröffnen.

Etwas anderes als die 3 Grundtypen sollte Stefan daher auch gar nicht mehr weiter erfassen, mögen die Createurs de Infoboxen (oder wie heissen die in der Autowerbung?) ihre Boxen anpassen.

Insbesondere braucht man dringend eine Vorlage, die es erlaubt, 20 Objekte in einem Artikel zu referenzieren, also muss dann (nur) in diese Vorlage auch der Parameter "Name/Bezeichnung/Titel" oder so aufgenommen werden.

Ich sag mal so:

• man braucht wohl mal eine Seite, in denen drei neue Fassungen vorgestellt und dann diskutiert werden (z.B Wikipedia:WikiProjekt Georeferenzierung/Vorlagen)
• dabei sollte eine Kommentierung (Bedienungsanleitung) stehen
• eventuell sollte man auch die entsprechenden Vorlagen mal testweise setzen
• angesichts der Zahl der bereits per Koordinantenvorlage und/oder Infoboxen irgendwie georeferenzierten Artikel (30.000) sollte es auch ein Meinungsbild geben - anhand dessen sich die Benutzer auch informieren können.

Grüsse -- Simplicius 11:06, 10. Mai 2006 (CEST)

ohja zum glück wurde ja schon lange nicht mehr darüber diskutiert also nur hier oder hier hier und ist ja auch schon einen ganzen monat her! das kann ja nicht so bleiben.. aber nur zu; zum glück gibt es nicht viel anderes zu tun als die umgestaltung der geo-referenzierung und anpassung der boxen die vor gar nicht so langer zeit wohl okay waren ...Sicherlich ^Post 11:20, 10. Mai 2006 (CEST)

Yep, ihr könnt die Infobox Ort in Polen doch gerne weiterverwenden. Es gibt noch 200 andere Länder, die sicher bald folgen werden a la "Ort in Mexiko". Es wird also nicht bei nur ein paar Vorlagen für Berg und See bleiben.

Mein Ziel ist es, dass eine Geo-Standardvorlage einfach eingebettet wird und kein Eigenweg stattfindet. Dazu muss sie einfach genug sein.

Ein paar Fragen stelle ich hier. Ich hoffe Wikipedia:WikiProjekt Georeferenzierung/Vorlagen erfasst den Stand der Vorschläge von Stefan Kühn und anderen. -- Simplicius 12:01, 10. Mai 2006 (CEST)

Generell sehe ich derzeit keine Notwendigkeit, die bestehende Form der Koordinateneingabe umfassend zu ändern. Einzig die Infoboxen sollen durch eine neue Form (so wie Polen) besser nutzbar gemacht werden. Wichtig ist dabei einen Standard zu definieren und auch zu propagieren. Alle anderen bisher aufgetrettenen Probleme lassen sich durch minimale Änderungen sehr schnell und einfach lösen (mit den bestehenden Mittel. Siehe meine Sammlung_bekannte_Probleme-- sk 18:57, 10. Mai 2006 (CEST)

Die doppelte Eingabe (bzw. Korrektur) nervt aber und da ist Sicherlichs Vorstoss sogar schon einen Schritt voraus, den die Standardvorlagen auch gehen sollten. Das ist eben noch die andere Seite der Initiative, abgesehen davon, dass die bekannten Probleme gleich mitgelöst werden sollten. -- Simplicius 23:08, 10. Mai 2006 (CEST)

Gibt es den überhaupt schon eine Vorlage, die eine einmalige Koordinateneingabe mit der Möglichkeit verbindet sowohl mit Minuten- als auch mit Sekundengenauigkeit zu arbeiten? Kolossos 13:30, 11. Mai 2006 (CEST)

Ja, siehe Krakau und die Vorlage von Sicherlich et al., oder eigentlich sämtliche Vorlagen in der englischsprachigen Wikipedia, soweit ich sehen konnte. -- Simplicius 13:50, 11. Mai 2006 (CEST)

Ich unterstütze die Meinung von sk. Wie oben schon mehrmals gesagt, wäre ich froh um die 'neue' Vorlage; inkl. Infobox-Regelung. Wir wollten unsere automatische und hochaktuelle Extraktion von Koordinaten aus der deutschen Wikipedia schon lange fertig haben, aber wir kämpfen noch mit notorischen Stabilitätsproblemen des vom Verein e.V. bereitgestellten Toolservers... Geonick 22:52, 11. Mai 2006 (CEST)--

Neue Vorlage mit Koordinaten

Hallo, ich habe heute die Vorlage:Koor dms erzeugt, die sich an dem englischen en:Template:Coor dms orientiert. Meiner Meinung nach ist diese Vorlage um einiges gelungener, als die deutsche Variante Vorlage:Koordinate Text Artikel. Zum einem ist sie viel kuerzer zu schreiben (=> echt minimalistisch) und redundanzfrei (und weniger fehleranfaellig), da die Koordinaten nicht zweimal angegeben werden muessen. Zusaetzlich ist der Text, der von dieser Vorlage erzeugt wird, auch besser, da er immer im selben Format ist (und keinerlei Spielereien wie "nördl. Breite" anstatt "N" oder so etwas zulaesst). In Infoboxen, wie Vorlage:Infobox Flughafen, wo Koordinaten in einem Feld uebergeben werden (und man somit in einem Artikel die Koordinaten Vorlage komplett ohne Zeilenumbruch in einer Zeile zu schreiben hat), waere so eine Angabe mittels Koor auch wesentlich uebersichtlicher, da um einiges weniger Text dastehen wuerde, was dem Editor zugute kommen wuerde. --LugPaj 18:33, 24. Jul 2006 (CEST)

Ist so schon mal nicht zu gebrauchen, da sie zwingend Grad, Minute und Sekunde voraussetzt und keinerlei Platz für type, region oder scale lässt. Beachte bitte auch die lang geführten Diskussionen um eine Reform der Koordinate weiter oben. --BLueFiSH ✉ (Klick mich!) 19:19, 24. Jul 2006 (CEST)

Das Muss zu Grad, Minute, Sekunde sehe ich weniger als Problem an (unbekannte Werte kann man ja nullen); allerdings fehlen definitiv die Metadaten wie type und region. -- fragwürdig ?! 19:37, 24. Jul 2006 (CEST)

Das sehe ich anders. Zum einem gibt es sehr wohl Platz fuer type, region und scale (Parameter 9). Hier[2] kann man auch eine Beispiel sehen, wie in der englischen Wikipedia dies benutzt wird. Wegen den Sekunden, finde ich das nicht wirklich schlimm. Man kann sie immer mit 00 auffuellen. In dieser Art haette man auch immer ein einheitliches Bild von Stunden/Minuten/Sekunden. Man koennte es aber auch abaendern und die Sekunden optional machen, in dem man checkt, ob ein 8. Parameter uebermittelt wurde. (Wenn >= Parameter, dann mit Sekundenangabe, ansonsten ohne), was ich allerdings nicht als schoen empfinden wuerde. Die obige Diskussion habe ich durchgelesen, allerdings kam finde ich nichts fuer mich brauchbares raus, da ich nach einem minimalistischen Ansatz suche, den man komplett auch in eine zeile schreiben kann (zB innerhalb von Vorlagen Parametern) und sich immer noch uerbersichtlich editieren laesst. --LugPaj 19:44, 24. Jul 2006 (CEST)

Hallo LugPaj, generell möchten wir hier eher keine neuen Vorlagen einführen. Da dann ähnlich wie im englischen demnächst hunderte andere sich dazu gesellen. Eine Datenbankabfrage ist dann fast nicht mehr machbar. Wenn ich das richtig sehe, dann brauchst du es für die Infoboxen der Flughäfen. Könntest du dich mit der polnischen Variante anfreunden? (Vorlage:Infobox (Polen) Bsp. Warschau.) Das wird aus meiner Sicht die Zukunft für die Infoboxen sein. Grund: Mit der Aufdrösellung der Angaben kann man leicht weitere Dienste einbauen (z.B. Karte etc). Und es müssen keine Angaben doppelt eingetragen werden. Wichtig wäre halt, dass wir für alle Infoboxen einen Standard finden. Und die polnische Variante ist bisher das Beste. Wenn alle die selben Schlüsselwörter benutzen, dann kann man auch automatisch neue Infoboxen finden, die Geokoordinaten beinhalten. -- sk 19:59, 24. Jul 2006 (CEST)

Hallo sk, im Prinzip kann ich mich damit anfreunden. Allerdings kann man bei der polnischen Vorlage keine Region angeben. Der Type airport waere eh vorgegeben. Die _ gefallen mir nicht wirklich, konsistent ist das in dieser Vorlage leider eh nicht (wenn ich mir die Felder KreisfreieStadt und Koordinate_Breite) anschaue. Ein Leerzeichen wuerde mir da besser gefallen. Aber egal, solange es ein "standard" waere. --LugPaj 21:23, 24. Jul 2006 (CEST)

Die Region wird automatisch gebildet aus dem fest vorgegebenen „PL-“ und der Variable für den ISO 3166-2:PL-Code. --Raymond ^Disk. 21:39, 24. Jul 2006 (CEST)

Das mit PL- hab ich vor ein paar Minuten schon bei als hier angeregt. Die sollen das bitte umstellen. -- sk 22:19, 24. Jul 2006 (CEST)

Ah, ok, habe das nun mit der Region verstanden..:). Ich wuerde in der Flughafen inbox dann dasselbe Schema wie in der Vorlage:Infobox (Polen) benutzen, oder gibt es Einsprueche dagegen? Die Vorlage:Koor dms wuerde ich dann loeschen lassen. --LugPaj 22:50, 24. Jul 2006 (CEST)

Das wäre das beste. Ich würde dann beim nächsten Dump das mit rausfiltern. -- sk 10:05, 26. Jul 2006 (CEST)

Hmmm Ich würde auch nur ungerne eine weitere Variante einführen wollen. Zudem finde ich es verwirrend, wenn man die Sekunden „Nullen“ müßte. 0 hat für eine andere Bedeutung als gar keine Angabe der Sekunden. --Raymond ^Disk. 21:08, 24. Jul 2006 (CEST)

Eine Zusammenführung der verschiedenen Vorlagen zu einer einzigen (redundanzfreien) Vorlage fände ich besser, als noch mehr Vorlagen einzuführen.

Aber zu den Argumenten:

Es wäre kein Problem, die Vorlage Koor dms um zwei Felder region und type zu erweitern. Ausserdem könnte man anhand es Types für Ortschaften die Anzeige der Sekunden vielleicht auch unterdrücken. -- Simplicius - ☺ 09:09, 25. Jul 2006 (CEST)

Bin auch gegen neue Vorlagen, aber ich finde, es ist Zeit, mal die Frage der Doppeleingabe der Werte anzugehen. Es ist wesentlich eleganter und weniger fehleranfällig, nur einmal den Wert für Grad, Minuten und Sekunden einzugeben bzw. später abzuändern, anstatt zweimal, wie es derzeit erforderlich ist. Auch eine Vereinheitlichung der Vorlage mit derjenigen der englischen Wikipedia bzw. Wikimedia Commons wäre auch wünschenswert zwecks Synergieeffekten / leichterer Mitarbeit in anderen Projekten. Longbow4u 13:10, 25. Jul 2006 (CEST)

Vorlage:Infobox Flughafen

Hallo, ich hatte weiter oben schon angefangen zu diskutieren. Ich wollte dann folgende Felder in der Vorlage:Infobox Flughafen einfuegen. Eigtl habe ich das Beispiel von weiter oben hier uebernommen, aber Vorlage:Infobox_(Polen) ist fast (bis auf den type) identisch. Den type braeuchte man eigtl nicht, da es nur um airports geht und man das fest in die Vorlage einbauen sollte. Bei der Polen Infobox steht anstatt Koordinate_Type=city type=city. Nun ist meine Frage, ob ich nun Koordinate_Type oder type (was ich nicht schoen finde...) verwenden soll, bzw ob der type wirklich wichtig ist, oder ob man den als Feld nicht weglassen koennte.

|Koordinate_Breite = N/S
|Koordinate_Breitengrad = 44
|Koordinate_Breitenminute = 44 
|Koordinate_Breitensekunde = 44
|Koordinate_Länge = O/W 
|Koordinate_Längengrad = 12
|Koordinate_Längenminute = 33
|Koordinate_Längensekunde = 33
|Koordinate_Type = airport 
|ISO 3166-2=DE-BY,AT-9  

--LugPaj 23:38, 25. Jul 2006 (CEST)

Den „type“ würde ich hier weglassen und direkt in der Vorlage fest vorgeben. Statt „ISO 3166-2“ würde ich die Variable „Koordinate_Region“ nennen. Ansonsten schaut es doch gut aus :) --Raymond ^Disk. 00:18, 26. Jul 2006 (CEST)

Ich denke es geht darum, dass man aus den Vorlagen Parametern auch alle wichtigen Informationen rausparsen kann, in dem man immer dieselben Parameter bei verschiedenen Vorlagen benutzt. Deshalb dachte ich, dass der type auch reinmuss, auch wenn er eigtl fest vorgegeben ist.--LugPaj 08:23, 26. Jul 2006 (CEST)

Hmm gutes Argument. Ich denke, da können die Profiparser unter uns (u.a. sk) mehr zu sagen. Da halt ich mich dann lieber mal bedeckt ;-) --Raymond ^Disk. 08:37, 26. Jul 2006 (CEST)

Dezimalangaben müssen (wegen Kvaleberg) mit Punkt geschrieben werden --BLueFiSH ✉ (Klick mich!) 06:20, 26. Jul 2006 (CEST)

Bitte mit rein Type mit reinschreiben. So muss man beim Parsen sich nur den Artikel anschauen um zu wissen, das es sich um einen Flugplatz handelt. Wenn das erst in der Vorlage steht muss man jedesmal noch die entsprechende Vorlage einlesen. Also lieber die Type-Angabe mit eintragen. -- sk 10:07, 26. Jul 2006 (CEST)

@sk, waere es nicht besser, dann Koordinate_Type und Koordinate_Region (wie von Raymond angeregt) anstatt type und ISO 3166-2 zu bentutzen? Somit waeren diese Parameter besser als Block zu erkennen.--LugPaj 10:55, 26. Jul 2006 (CEST)

Habe gerade erst den Abschnitt Zur Info hier in dieser Diskussion gelesen. Dort wurde "KoordinateTyp" vorgeschlagen, (welche immerhin kein deutsch-englischer Mischmasch ist) allerdings denke ich, wenn dann sollte man das mit Unterstrich schreiben. --LugPaj 17:54, 26. Jul 2006 (CEST)

Damit kann ich auch leben. Dieser Standard entwickelt sich ja noch, aber der Weg ist der richtige. Dann müssen wir halt noch mal per Bot durch die Polnischen Orte turnen. Das haben die demnächst so oder so vor, da kann man das gleich mit einfädeln. -- sk 21:18, 26. Jul 2006 (CEST)

"|type=city" --> "Koordinate_Typ=city" und "|ISO 3166-2=MZ" --> "Koordinate_Region=PL-MZ" hab ich mal bei Wikipedia_Diskussion:Formatvorlage_Stadt/Polen#Bei_einem_Botlauf_zu_.C3.A4ndern hier vorgeschlagen. "_Typ" damit alles deutsch ist. -- sk 21:23, 26. Jul 2006 (CEST)

Danke, dann besteht von meiner Seite jedenfalls nun Klarheit.--LugPaj 21:58, 26. Jul 2006 (CEST)

Sollte die Region nicht besser in zwei Teilen, also das Land und das Bundesland getrennt in zwei Feldern notiert werden???--Tobi 00:15, 27. Jul 2006 (CEST)

Dann wollen die Leute das gleich wieder wegrationalisieren, weil es z.B. in polnischen Städten nie ändert. Aber ein weiteres Problem sind Grenzfälle. Also z.B. Berge die genau auf der Grenze liegen z.B. "DE-BY/AT-7" wäre bei einer Aufteilung problematisch einzubinden. Ich würde die Region so zusammen lassen. -- sk 08:34, 27. Jul 2006 (CEST)

Ich würde anstelle dieser übermäßig langen und wenig standardisierten Koordinaten-Parameter eher die in der englischen und anderen Wikipedias bereits häufig genutzte englischsprachige Schreibweise lat_deg = 44 usw. bevorzugen. Zur Diskussion bitte hier. --TM 02:48, 1. Sep 2006 (CEST)

Vereinheitlichung des Ausgabetextes & Vereinfachung des Interfaces

Ich habe die Vorlagen:

Benutzer:Divisor/Vorlage:Koordinaten_Text,
Benutzer:Divisor/Vorlage:Koordinaten_Artikel und
Benutzer:Divisor/Vorlage:Koordinaten_Text_Artikel

nach dem Vorbild der GEO-Koordinate Vorlagen erstellt.

Statt:

{{Koordinate Text Artikel|15_8_0_N_120_21_0_E_type:mountain(1486)_region:PH_scale:25000|15° 8'  N,
120° 21' 0" O}}

kann ich jetzt ganz einfach:

{{Benutzer:Divisor/Vorlage:Koordinaten Text Artikel|15|8|0|N|120|21|0|O|mountain(1486)|PH|25000}}

schreiben.

Das ist kürzer, weniger redundant und der Ausgabetext ist auch gleich einheitlich formatiert. Weiters können der letzte, die letzten beiden, sowie die letzten drei Parameter ohne Probleme weggelassen werden. Außerdem wäre der Text noch kürzer wenn sich die Vorlagen nicht in meinem Benutzernamensraum befänden. Was das Ausgabetextformat anbelangt, so habe ich mich für das ggg° mm' ss" N/S, ggg° mm' ss" W/O Format entschieden. Zusätzlich wird der Ausgabetext, falls möglich, gekürzt. (0" bzw. 0' 0" werden nicht dargestellt)

Was haltet ihr von diesem Konzept?

-- divisor 22:05, 28. Aug 2006 (CEST)

Das ist ein Thema, das immer wieder kommt. Der meiner Meiung nach letze brauchbare Stand ist hier bei Vorlagendiskussion (Archiv4) festgehalten. Die Frage zeigt mir, dass Handlungsbedarf da ist, denn die jetzige Vorlage ist wie schon oft gesagt redundant und auch nicht auf Linie, Fläche erweiterbar. Man sollte sicher Geduld haben und Rücksprache halten mit bestehenden 'Datennutzern und -veredlern' wie sk und Kolossos (und mir => wer noch?). Ob nun die Vorlage Koordinate, Geo_Koordinate oder Geo_Punkt heisst, ist eher sekundär. Ich sehe diese Diskussion mittlerweile als Prozess und meine, dass bald die Zeit reif sein könnte. Dann können wir den Geo_Linienzug gerade zusammen mit einer neuen Vorlage Koordinate (= Geo_Punkt) einführen.

Oben wird nach Linienzug-Codierung gefragt. Nachfolgend eine Idee basierend auf den Archiv4-Diskussionsstand, wie ein Linienzug gemäss GeoRSS Simple-Spezifikation und -Metamodell ausschauen könnte:

{{Geo_Linienzug Artikel/Text/Text Artikel
  |Geometrie = 45.256 -110.45, 46.46 -109.48, 43.84 -109.86
  ...
  |Name = Rhein
  |Typ = Gewässer (optional)
  ...
}}

Die Art und Weise, die Codierung so zu machen, stützt sich einerseits auf 'Best Practices' von 'Vorlagen' und andererseits auf eine sehr, sehr lange Diskussion innerhalb der mittlerweile erfolgreichen georss.org-Spezifikation. Stellt euch vor, die Codierung wäre ähnlich, wie sie faktisch weltweit akzeptiert ist (in W3C, allen Produkten grosser SW-Herstellern etc.)... GeoRSS wird es ziemlich sicher sein! Geonick 22:25, 31. Aug 2006 (CEST)

Die verkürzten Vorlagen von Benutzer:Divisor sind, so muss ich leider sagen, nicht praxistauglich. In der Programmierung gibt es den Grundsatz, dass nur Funktionsaufrufe mit einem, zwei (z. B. Vergleiche(Text, Text)) oder maximal drei Parametern (z. B. Extrahiere(Text, von, bis)) bedenkenlos verwendet werden sollten, nämlich immer dann, wenn die Parameter einer intuitiven, merkbaren Ordnung folgen. Hier sprechen wir von 11 oder sogar 12 unbenannten Parametern – eine endlose Fehlerquelle. Hinzu kommen Kleinigkeiten: Was passiert, wenn ich der Vorlage nicht Sexagesimal- sondern Dezimalzahlen übergeben will? Soll ich die Parameter 2, 3, 6 und 7 dann einfach leer lassen? Meiner Meinung nach muss die Vorlage nicht kürzer sondern eher noch länger, aber auch flexibler werden. --TM 02:37, 1. Sep 2006 (CEST)

Wie können die Angaben überprüft werden ? Arcy 08:07, 1. Sep 2006 (CEST)

Die Argumentation ueber die Parameteranzahl ist doch ein wenig Augenwischerei. Ob die Parameter jetzt durch _ oder | getrennt sind spielt fuer den Endnutzer keine Rolle. Und die Redundanz ist m.E. die weitaus groessere Fehlerquelle. --Dschwen 10:14, 1. Sep 2006 (CEST)

Ich komme beim durchzählen einer Benutzer:Divisor/Vorlage:Koordinaten_Text_Artikel auf 32 IF-Abfragen, so eine ähnliche Lösung hatte ich auch schon mal zur Disk. gestellt. Aber wollen wir das uns und unseren Servern wirklich antuen? Ich bin aber auch der Meinung, das man nicht jeden Parameter wie Breitengrad-Minuten,u.s.w. einzeln angeben muß, um die Vorlage nicht unmäßig aufzublähen. Kolossos 09:01, 1. Sep 2006 (CEST)

Die If abfragen werden nur beim Auswerten des Templates durchgenudelt, d.h. wenn die Templateparameter beim bearbeiten der Seite auch veraendert werden. Der impact auf die Server duerfte minimal sein, insbesondere mit der Parsererweiterung die seit einiger Zeit conditionals behandelt (gegenueber den alten qif templates). Das bisschen Serverzeit wuerde ich jederzeit fuer eine deutliche Syntaxvereinfachung opfern. --Dschwen 10:14, 1. Sep 2006 (CEST)

In der Informatik spricht man von Key-Value-Paaren und für eine Codierung nur in dezimaler Schreibweise wäre ich sofort zu haben (man beachte die Ähnlichkeit zu Geo_Linienzug oben sowie Archiv4): Geonick 21:02, 1. Sep 2006 (CEST)

{{XXX_xxx Artikel/Text/Text Artikel
  |Punkt = 45.256 -110.45
  ...
  |Name = Quelle
  |Typ = Gewässer 
(optional)
  ...
}}

Ich habe jene Vorlagen, welche ich oben in diesem Abschnitt vorgestellt habe, grundsätzlich überarbeitet.

Folgende Argumente sind jetzt unter anderem möglich:

{{Benutzer:Divisor/Vorlage:Koordinaten Text|1|N|1|W}}
{{Benutzer:Divisor/Vorlage:Koordinaten Text|1.0|S|1.2|W}}
{{Benutzer:Divisor/Vorlage:Koordinaten Text|34|1.56546|N|1.32556654756|E|mountain|PH|12500}}
{{Benutzer:Divisor/Vorlage:Koordinaten Text|34|1|33.967534|N|0|O}}
{{Benutzer:Divisor/Vorlage:Koordinaten Text|1|2|3|N|4|5|6|W}}
{{Benutzer:Divisor/Vorlage:Koordinaten Text|28|||S|159|||E}}
{{Benutzer:Divisor/Vorlage:Koordinaten Text|2||S|19||E}}
{{Benutzer:Divisor/Vorlage:Koordinaten Text|-1.45|-28.4|mountain}}

Diese Vorlagenaufrufe resultieren dann in:

::{{Benutzer:Divisor/Vorlage:Koordinaten Text|1|N|1|W}}
::{{Benutzer:Divisor/Vorlage:Koordinaten Text|1.0|S|1.2|W}}
::{{Benutzer:Divisor/Vorlage:Koordinaten Text|34|1.56546|N|1.32556654756|E|mountain|PH|12500}}
::{{Benutzer:Divisor/Vorlage:Koordinaten Text|34|1|33.967534|N|0|O}}
::{{Benutzer:Divisor/Vorlage:Koordinaten Text|1|2|3|N|4|5|6|W}}
::{{Benutzer:Divisor/Vorlage:Koordinaten Text|28|||S|159|||E}}
::{{Benutzer:Divisor/Vorlage:Koordinaten Text|2||S|19||E}}
::{{Benutzer:Divisor/Vorlage:Koordinaten Text|-1.45|-28.4|mountain}}

-- divisor 17:53, 2. Sep 2006 (CEST)

Die Keys (= die Argumentnamen) fehlen, so müsste z.B. "-1.45" so "Breite=-1.45", bzw. "Koordinaten_Breite=-1.45" aussehen. Geonick 12:58, 3. Sep 2006 (CEST)

Der Verzicht auf Argumentnamen war eine Designentscheidung. Die Vorlagen sollten nämlich so kurz und flexibel wie möglich werden. Andererseits wäre ein in der selben Vorlage parallel existierendes System mit Argumentnamen ohne Probleme möglich. Für welche Zwecke würdest du eine derartige Vorlage denn benötigen? Und welche konkreten Argumentnamen würdest du bevorzugen? -- divisor 15:58, 3. Sep 2006 (CEST)

Ich würde, wie bereits hier argumentiert, die seit Mitte 2005 in der englischen und anderen Wikipedias genutzte Schreibweise lat_deg=-1.45 bevorzugen. --TM 17:27, 3. Sep 2006 (CEST)

Argumentnamen lat_deg, lat_min, lat_sec, lat, lon_deg, lon_min, lon_sec, lon, type, region und scale hinzugefügt. Leider bisher nur oberflächlich getestet. Ich gehe jetzt schlafen. -- divisor 03:25, 4. Sep 2006 (CEST)

Ich habe in der letzten Woche die Architekur meiner Vorlagen umgekrämpelt, die Performanceprobleme in den Griff bekommen und außerdem einige Fehler beseitigt.

Nun werden auch seltsamere Parameterkonstellationen wie zum Beispiel:

{{Benutzer:Divisor/Vorlage:Koordinaten Text|1.234|-23.44|23432.555|N|200.1234|-444|-23.3434|W}}

halbwegs logisch zu {{Benutzer:Divisor/Vorlage:Koordinaten Text|1.234|-23.44|23432.555|N|200.1234|-444|-23.3434|W}} verarbeitet.

Die Argumentnamen lat_deg, lat_min, ... gibt es natürlich immer noch.

-- Divisor 16:43, 10. Sep 2006 (CEST)

Ist da noch jemand? -- Divisor 15:23, 16. Sep 2006 (CEST)

Ich kann es ja ertragen ignoriert zu werden, aber nicht einmal ignoriert zu werden, das nimmt mich dann schon etwas mit. Aber sei's drum. Ich habe meine Vorlagen überarbeitet, dokumentiert sowie eine kleine Diskussionsplattform für sie erstellt. Sollte also noch irgend jemand Interesse an meinen Vorlagen haben, bitte dort posten. -- Divisor 18:41, 5. Okt 2006 (CEST)

Ich stehe den neuen Vorlagen zwiegespalten gegenüber. Einerseits ist es ja recht komfortabel für den Nutzer, andererseits erschwert eine derartig große Vielfalt an verwendbaren Parameter Syntaxen die automatische Verarbeitung der Koordinateninformationen sicherlich (z.B. für die Google-Earth Koordinaten). Im Grundegenommen wird es höchste Zeit, dass die GIS extension enabled wird. Dann hätten wir die ideale Lösung. Die userfreundlichen Templates könnten im Backend den GIS-Extension Text erzeugen und die Auswerte-Tools könnten direkt auf die DB zugreifen (=Performancegewinn).

1. Kann ein Template einen Mediawiki-Extension Block erzeugen?
2. Funktioniert die GIS-Extension mit Mysql?

--Dschwen 19:52, 8. Okt 2006 (CEST)

Ich kann und werde keiner Vorlage zustimmen, welche ich nach einer halben Stunde immer noch nicht voll verstanden habe. Es wiederspricht dem Wikiprinzip und wahrscheinlich auch dem EVA-Prinzip wenn Vorlagen nur noch von ganz wenigen Informatiker verstanden werden können. Mir gefällt das simple Manske Formular da besser [3] . Und sorry, es war vielleicht gemein dich so warten und aushungern zu lassen, anstatt dir gleich die Meinung zu sagen. Kolossos 21:45, 8. Okt 2006 (CEST)

So so, Koordinate nach Vorlage Konverter. Da kann ich ja gleich mal Werbung für meine Version dieses Themas machen :-). Wenn Interesse besteht kann ich das gerne beliebig erweitern. Erscheint mir prakischer als das externe Tool. --Dschwen 21:59, 8. Okt 2006 (CEST)

Zu Wikiprinzip: Vorlagen (Divisor) in der Wikipedia sind gemeinschaftlich bearbeitbar (= Wikiprinzip)
Scripte (Manske Formular) auf einem anderen Server sind gemeinschaftlich nicht bearbeitbar (≠ Wikiprinzip). Ich glaube, Kollossos, da hast du das Wikiprinzip nicht so ganz verstanden ;-).

Zu GIS-Extension: Die Diskussion zur GIS-Extension geht ja nunmehr ins soundsovielte Jahr. Eine Übernahme der extension in die WP scheint mir auf absehbare Zeit nicht geplant zu sein. Nebenbei: die GIS-Extension ist meines Wissens von Kvaleberg entwicklet worden. Gemäß seiner Aussage (zitiert oben in der Diskussion "Umstellung_von_kvaleberg") sehe ich da auch in Zukunft erstmal schwarz.

Zu Google Earth: Man könnte machmal den Eindruck bekommen, als sei das Projekt Georeferenzierung primär dafür da für die Software von Google Daten zu gewinnen. Es ist imho aber allemal sinnvoller den vielen Nutzern der WP die Eingabe als den wenigen Nutzern ausserhalb der WP (!!) die Übernahme der Arbeit in eigene Google-Earth-Projekte zu erleichtern .

--Arcy 08:32, 9. Okt. 2006 (CEST)

Zu Verständlichkeit:

Zu Code-Verständlichkeit: Mit jeder, auch noch so komplexen Programmiersprache, kann man verständlichen Code schreiben, falls

A) der Code mit Zeilenwechseln, Leerzeichen und Tabulatoren in eine vernünftige Form gebracht werden kann und

B) der Code an beliebiger Stelle kommentiert werden kann

ohne die Funktionalität des Codes zu verändern. Beides ist bei MediaWiki-Vorlagen nicht möglich, da dies das Resultat der Vorlage, also ihre Funktionalität, verändern würde. Dadurch ist es prinzipiell unmöglich, komplexe Vorlagen halbwegs verständlich zu codieren.

Zu Architektur-Verständlichkeit: MediaWiki-Vorlagenprogrammierung ist chronisch ineffizient. Beim switch-Statement beispielweise

{{#switch:<X>
|<1>=<A>
|<2>=<B>
|<3>=<C>
|<4>=<D>
|<5>=<E>
}}

wird zuerst <X> berechnet, danach <1>, <A>, <2>, <B>, ... und erst zuletzt wird das Ergebnis von <X> mit den Ergebnissen von <1>, <2>, ... verglichen und der der ausgewählten Zuweisung zugehörige String als Resultat der switch-Anweisung festgelegt.

Diese Ineffizienz gibt es beim if-Statement natürlich ebenso.

Dadurch kann es bei sehr vielen aufwendig zu berechnenden Möglichkeiten sehr schnell zu ersthaften Performanceproblemen kommen. Genau dies war bei meinem Vorlagen-System der Fall. Aus diesem Grund musste ich die Architektur des Systems großflächig verändern und leider auch verkomplizieren. Denn ein fürchterlich unverständliches aber schnelles System ist weit brauchbarer als ein verständliches aber fürchterlich langsames System.

-- Divisor 19:04, 9. Okt. 2006 (CEST)

Damit bestärkst du mich jetzt natürrlich in meine Meinung, denn wenn die "MediaWiki-Vorlagenprogrammierung chronisch ineffizient ist" dann bevorzuge ich doch eine einfach, verständliche und schnelle Vorlage, so wie wir sie jetzt haben. Damit sind wir auch flexible wenn Änderungen wie ein zusätzliches optionales Feld wie "spezifischer Name" oder anderes dazukommen sollte. Und so schlecht wächst das Projekt nun auch trotz der Koord-doppeleintrag auch nicht. Manche heulen schon, weil es in Sachsen nix mehr zu tuen gibt. Kolossos 19:16, 9. Okt. 2006 (CEST)

"Manche heulen schon ..." Meinst Du damit die vielen fleissigen Wikipediabienchen, die möglichst bei der Arbeit noch eine Stahlkugel am Bein haben möchten, damit der Honig zu dem großen Bären "Google Earth" fließen kann? ;-) --Arcy 08:27, 10. Okt. 2006 (CEST)

Vorlage:Geo-Koordinate

Nachdem ich keine entsprechende Diskussion gefunden habe, habe ich mich mal getraut diese Vorlage zu erstellen, die m.E. mehrere Vorteile gegenüber der bisherigen Vorlage:Koordinate Text hat (und Co.) hat:

• die doppelte Angabe für die Textausgabe entfällt, womit Fehler minimiert werden sollten;
• die Textausgabe kann zentral vereinheitlicht werden;
• die Umrechnung von dezimalen Koordinaten in Minuten/Sekunden erfolgt automatisch;
• die Eingaben werden etwas geprüft.

Ich hoffe, ich habe hier keine triviale Erkenntnisse umgesetzt. Gibt es dazu Meinungen? --Farino 01:58, 4. Dez. 2006 (CET)

Benutzer:Divisor arbeitet seit Monaten an genau der gleichen Idee, siehe hier. Seine Vorlagen sind deutlich flexibler aber auch deutlich undurchsichtiger. Unter anderem deshalb ist ein Großteil der an diesem Projekt interessierten Benutzer nicht von solchen Vorlagen überzeugt. --TM 10:32, 4. Dez. 2006 (CET)

Ich habe in den letzten Wochen einige Hundert "Infobox Berg"-Anpassungen gemacht und die umständliche, doppelte Eingabe der Geo-Koordinaten waren mit die fehlerträchtigste Sache. Ob nun meine Vorlage oder die von Benutzer:Divisor (sorry für die schlechte Recherche meinerseits) zum Zuge kommt ist mir reichlich egal. Die Erstellung der Vorlage nimmt ja nur einen Bruchteil des Aufwandes ein, den die Diskussion darüber ausmacht. Ob ich nun ...65_43_21_N_1_2_3_E_type:mountain(1234)... oder ...65|43|21|N|1|2|3|E|type=mountain(1234)... schreibe, kann ja nicht das Hammerargument gegen solche Vorlagen sein und die Serverbelastung tritt ja nur beim Speichern eines Artikels mit dieser Vorlage auf, und das ist IO- und CPU-mäßig ja wirklich zu vernachlässigen. --Farino 10:57, 4. Dez. 2006 (CET)

Schau dir bitte mal die Vorlage:Infobox Ort in Deutschland an, dort kommen wir (aus Sicht der Artikelautoren) völlig ohne eine Koordinaten-Vorlage aus. Die von dir oben genannten Vorteile werden erfüllt. --TM 11:34, 4. Dez. 2006 (CET)

Die kannte ich und ich weiß natürlich, dass die Erschließung der deutschen Orte einen großen Teil ausmachen. Dafür habe ich die Vorlage aber auch nicht geschrieben, sondern für die anderen Tausende Aufrufe (die wahrscheinlcih die zweite Hälfte der Geo-Referenzierungen ausmachen), bei denen z.T. auch noch dezimale KoordinatenAngaben bestehen. --Farino 12:16, 4. Dez. 2006 (CET)

Vorlage:Infobox Ort in Deutschland Vorlage:Infobox Flughafen sind doch alles Umgehungsversuche und machen im Grunde auch nichts anderes als der Vorschlag von Farino auch. Ich bin für das Schweizer Kilometernetz! Das sind nur zwei Parameter und innerhalb der Schweiz können diese auch nicht verwechselt werden. Eindeutig die beste Lösung. Also wir von der Ort in der Schweiz Fraktion können die Argumente und Entscheide der Autoren von Infobox Ort in Deutschland nicht nachvollziehen. Einfach unverständlich, dass der Rest der Welt keine SN Norm haben will.

Zum Thema: Eine Integration der SrtringFunctions wäre hingegen keine Symptombekämpfung. Ein- und Ausgabe Formate wären fast beliebig definierbar. -- visi-on TWW 19:32, 13. Dez. 2006 (CET)

Ergänzende Angabe für die Vorlage Koordinate Text

Es stört mich seit geraumer Zeit, dass wir pro Artikel nur eine Koordinate für Karten auslesen können. Artikel auf die das zutrifft sind z.B. Hamburger Flaktürme, Airbus#Werke und diverse Listen. Um dieses zu verändern schlage ich vor eine Angabe des section zu ermöglichen. Dafür soll es zwei Möglichkeiten geben: Wenn es eine zur Koordinate passende Unterüberschrift gibt soll die Angabe section:sub reichen. Die Kartenansicht würde sich dann aus dem Titel und dem Abschnittstitel zusammensetzen, also z.B.: Hamburger Flaktürme#Flakturm IV in St. Pauli und somit gleich an die richtige Stelle im Artikel verlinken. Ansonsten kann ein eigener Titel vergeben werden, z.B. bei einem Bismarck-Denkmal section:Chemnitz.

Ich hoffe das ist verständlich. Wenn es keinen Widerspruch gibt, werde ich es in das Projekt einfügen. Kolossos 16:09, 31. Dez. 2006 (CET)

Absolut! Ist 'ne sehr gute Idee. Kann ich nur unterstützen. Würde einige Artikel in Sachen Koordinaten einfacher lesbar machen. -- Monsterxxl <°))))> 11:24, 1. Jan. 2007 (CET)

Die Artikel werden deshalb nicht besser lesbar. Die Angaben erscheinen ja nicht offensichtlich.

Es wird eine "Regel" nötig sein, dass die Kapitelüberschriften nur noch im "Notfall" geändert werden dürfen. Ansonsten ist seitens der Koordinatennutzer ein stark erhöhter Aktualisierungsaufwand nötig um angesichts der sehr viel häufiger auftretenden Änderungen der Kapitelüberschriften auf dem neusten Stand zu bleiben.--Arcy 12:12, 1. Jan. 2007 (CET)

Die Section-Struktur hat nichts mit der Listenstruktur gemeinsam. Hier würde nie etwas "richtig verlinkt" werden.--Arcy 12:12, 1. Jan. 2007 (CET)

Jo. Schon klar. mit "lesbar machen" wollte ich eigentlich nicht auf das optische Bild ansprechen. Sondern eher auf die maschinelle Auswertbarkeit.

Wegen dem Aktualisierungsaufwand, dass sehe ich nicht so derb, da die meisten Koordinaten mit Sicherheit mit dem String section:sub eingebunden werden und damit ja die Teilüberschrift automatisch verlinkt ist. Und mit jedem neuen Auslesen der Koordinaten aus dem Dump wird die Beschriftung der Koordinate entsprechend aktualisiert. Oder stehe ich da grad irgendwie auf dem Schlauch? -- Monsterxxl <°))))> 14:20, 1. Jan. 2007 (CET)

@Monsterxxl: Ja so war es gedacht. Und selbst wenn sich Abschnittsüberschrift zw. den Dumps ändert (was aber aus meiner Sicht auch nicht so oft passiert), so landet man zumindest im richtigen Artikel. Kolossos 19:16, 1. Jan. 2007 (CET)

Die Idee ist generell nicht schlecht, aber es wird viele Probleme mit sich bringen. Z.B. werden dann plötzlich Leerzeichen und Sonderzeichen in den Link eingebaut werden können "section:Überhäßlich und Unterhäßlich". Ob das der Server mag wei0 ich nicht. Aber ich finde eine kompakte schreibweise mit Klammern besser. z.B. selection(XYZ...), da weiß jeder wo der Spaß anfängt und wo er endet. -- sk 21:33, 7. Jan. 2007 (CET)

Danke für den Hinweis mit dem Leerzeichenproblem, über Nacht ist mir auch die mögliche Lösung dazu eingefallen. Als komplett getrennte Vorlagenvariable mit einem eigenem Namen, würde der Eintrag von den Vorlagen ignoriert und würde nicht im Link landen:

{{Koordinate Text|5_10_N_112_13_W_type:city(1200)_region:DE-BY|5° 10' n. Br., 112° 13' w. L.|section=Kuhdorf in Bayern}}

ergibt:{{Koordinate Text|5_10_N_112_13_W_type:city(1200)_region:DE-BY|5° 10' n. Br., 112° 13' w. L.|section=Stadtteil xy von Kuhdorf}}

ist sogar unabhängig von der Position innerhalb der Vorlage unabhängig (nur zu Vorführzwecken):

{{Koordinate Text|section=Kuhdorf in Bayern|5_10_N_112_13_W_type:city(1200)_region:DE-BY|5° 10' n. Br., 112° 13' w. L.}}

ergibt: {{Koordinate Text|section=Stadtteil xy von Kuhdorf|5_10_N_112_13_W_type:city(1200)_region:DE-BY|5° 10' n. Br., 112° 13' w. L.}} Das wärs doch,oder? ---Kolossos 14:46, 8. Jan. 2007 (CET)

Am Besten gefällt mir die Variante "Koordinate Text|section=Stadtteil xy von Kuhdorf|5_10_N_....", wobei ich ganz das Attribut "section" in "name" umtaufen würde. Für die Fall, dass man die die vorhergehende Überschrift nutzen möchte, würde ich statt "sub" "subtitle" vorschlagen (Ist eindeutiger). Es wäre dann also möglich "|name=XY|" oder "|name=subtitle|" zu schreiben. So könnten wir zahlreiche weitere Koordinaten einbinden, für die es keine eigenständige Artikel gibt. -- sk 17:20, 10. Jan. 2007 (CET)

Falls das 'section'-Schlüsselwort (= Attributname) gleich an den Anfang gestellt wird, verschieben sich alle anderen Vorlagen-'Attribute' um eins nach hinten. Die Syntax '=' hilft zum Glück etwas, um dies zu erkennen. Ich habe schon lange dafür plädiert, die Vorlagensyntax endlich auf '|attributname=wert' umzuschreiben. Würde konsequent "Koordinate Text|section=Stadtteil xy von Kuhdorf|lat=5.xx|lon=112.xx|..." verwendet, müsste in einem Fall wie diesem keine bestehenden Programmen umgeschrieben werden! Ist jetzt der Zeitpunkt für die Umstellung gekommen? Ob section ein glücklicher (d.h. selbstdokumentierender) Name ist, müsste auch noch diskutiert werden. --Geonick 17:40, 13. Jan. 2007 (CET)

Teilweise findet diese Umstellung auf Attributnamen durch Vorlage:Positionskarte und Vorlage:Infobox_Ort_in_Deutschland ja schon statt. Eine Umstellung der Vorlage:Geo-Koordinate Text Artikel finde ich jedoch nicht nötig, da die schöne Kürze und interne Einfachheit der jetzigen Vorlagen verloren geht. Nenn mich altmodisch, aber die komplette Umstellung halte ich für unnötig. Über die Dezimalschreibweise brauchen wir hier glaube ich nicht mehr diskutieren.

Allerdings, für eine bevorstehende botbetriebene, internationale Ausdehnung könnte man allerdings gleich richtig loslegen, da die 8 Parameter ala Vorlage:Coor_dms wirklich ein Krauen sind.

Was das Attributnamen "name=subtitle" angeht, damit könnte ich gut leben (schöne kurze Schreibweise). Man müßte das nur so dokumentieren, dass der Name wirklich nur im genannten Fall zum Einsatz kommt. Kolossos 18:33, 13. Jan. 2007 (CET)

Umwandlung der Angabe scale in dim

Bei der Gelegenheit wollte ich die Angabe scale durch dim wie Dimension (Abmessung) ersetzen. Dabei handelt es sich um den ungefähren Objektdurchmesser in Metern. Da scale leider nie richtig definiert war, ist da sehr viel Mist eingetragen wurden, somit bedarf es eines klaren Schnittes. Da wir bis jetzt auch ganz gut ohne diese Angabe auskamen würde ich das allerdings nicht zum Pflichtfeld machen. Ohne sämtlich Diskussionen neu aufzurollen, gibt es dazu Meinungen? Kolossos 16:19, 31. Dez. 2006 (CET)

Hört sich ganz gut an, aber ich verstehe noch nicht ganz, wie du das umsetzen willst. Hast du vor die Angabe in dieser Art (dim(Durchmesser in m)) zu machen, oder wie stellst du dir das vor? -- Monsterxxl <°))))> 11:28, 1. Jan. 2007 (CET)

Für einen Durchmesser von 5000m ungefähr so:

{{Koordinate Text|5_10_N_112_13_W_type:city(120000)_region:DE-BY_section:sub_dim:5000|5° 10' n. Br., 112° 13' w. L.}}

Kolossos 11:52, 1. Jan. 2007 (CET)

Was ist mit den ganzen Programmen die eventuell nach scale auswerten?
Dann schreibst du "Dabei handelt es sich um den ungefähren Objektdurchmesser in Metern. Da scale leider nie richtig definiert war". Was war sie denn nun definiert oder nicht definiert?
Deine dim Geschichte soll dagegen "ungefähr so" arbeiten ?
--Arcy 12:04, 1. Jan. 2007 (CET)

Naja zumindest wäre dann mal eine Einheit definiert. Ok, ich gebe zu nach Abschätzung von Nutzen und Aufwand können wir es bleiben lassen. Kolossos 19:18, 1. Jan. 2007 (CET)

Mir gefällt die Idee mit dem dim sehr gut. Mit dem Durchmesser lässt sich mehr anfangen als mit der Angabe skale, die meines wissens von niemanden richtig genutzt wurde. Bin für eine Einführung! -- sk 21:28, 7. Jan. 2007 (CET)

Bin auch für dim anstelle scale (siehe Diskussionen im Archiv). Bin nur etwas irritiert, dass oben sub_dim steht, statt dim... -- Geonick 00:50, 16. Jan. 2007 (CET)

Inwiefern ist diese - auch meiner Meinung nach sinnvolle - Änderung mit anderen Systemen (Wikipedien, Koordinatenutzer) abgesprochen. Siehe auch "Wildwuchs" in der Diskussion Wikipedia_Diskussion:WikiProjekt_Georeferenzierung#type:city --Arcy 08:25, 16. Jan. 2007 (CET)

Betreffs, sub_dim: siehe den Abschnitt drüber. "sub" gehörte zu einem anderen neuen Parameter.

Betreffs Abstimmung, da noch nicht mal auf die erste Parameteränderung auf en eine Reaktion kam, ist eine Absprache schwierig. Information wird erfolgen. Koordinatennutzer können ja hier mitlesen und mitdiskutieren. --Kolossos 08:38, 16. Jan. 2007 (CET)

hjl_get_CoorM - Dimensionsangaben

Ich habe das Tool dahingehend erweitert, das die neue Dimensionsangabe "dim" mit eingetragen werden kann. --Arcy 13:49, 17. Feb. 2007 (CET)

Sehr gut! Könntest du bitte dein Tool noch so erweitern, dass nach der 6. Nachkommastelle schluß ist. Die Gradangaben aus deinem Tool haben manchmal 12 Nachkommastellen, was eine unrealistische Genauigkeit vorspielt. Danke! -- sk 13:21, 7. Mär. 2007 (CET)

Hallo Stefan. Ich habe mir mal Zeit genommen und die Nachkommageschichte implementiert. Es gibt nun drei Möglichkeiten, die Nachkommastellen festzulegen:

• keine Änderung
• mittels festem Wert
• in Abhängigkeit vom Google-Scale und Darstellungsart.

--Arcy 18:21, 7. Mär. 2007 (CET)

Hallo Arcy, also dass ist nicht hilfreich, weil die meisten dann immer noch die 12 Nachkommastellen nutzen. Ich würde generell 5 oder 6 Nachkommastellen festlegen, weil man eine höhere Genauigkeit einfach nicht hinbekommt. Und das mit dem Google-Scale ist auch so eine Sache. Ich zoome rein, verorte, zomme wieder raus und bekomme dann eine schlechtere Koordinate. Bitte mach dir nochmal die Mühe und lege es auf 5 oder 6 Nachkommastellen fest. -- sk 20:23, 7. Mär. 2007 (CET)

Ich werd mich morgen mal dran setzen. --Arcy 20:38, 7. Mär. 2007 (CET)

So. 5 Nachkommastellen sind nun Voreinstellung. Weniger oder die Google-Scale-abhängige Anzahl können aber noch bei Bedarf gewählt werden. Auch fünf Nachkommastellen können ja noch eine fehlende Genauigkeit vortäuschen. Bezüglich der Auswahl der Nachkommastellen und des Google-Scale-Modus vertrau ich ansonsten dem Sachverstand der Nutzer. --Arcy 17:37, 8. Mär. 2007 (CET)