Wikipedia Diskussion:WikiProjekt Georeferenzierung/Archiv/2007-III

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/Archiv/2007-III#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Wikipedia_Diskussion:WikiProjekt_Georeferenzierung/Archiv/2007-III#Thema_1

Falsche Koordinaten von Kloster Schaaken

Ich habe im Artikel die Koordinaten 51_19_8991 N und 8_83_3630 O eingegeben, die Benutzer:Cosal angegeben hat. Wenn man nun auf die Koordinaten klickt, kommen aber auf der Seite irgendwelche anderen Koordination hoch, und zwar: 51° 20′ 29.91″ N 9° 23′ 36.3″ E Was mache ich falsch? --Sr. F 20:40, 8. Jul. 2007 (CEST)

60 Bogenminuten sind 1 Grad und 60 Bogensekunden sind 1 Bogenminute. Das wär, wie wenn du sagst, 1 Minute und 80 Sekunden. Das sind auch 2 Minuten und 20 Sekunden (bessere Erklärung fällt mir gerade nicht ein). Gruß --тнояsтеn ⇔ 20:51, 8. Jul. 2007 (CEST)

Nachtrag: Daran lag es wohl nicht, das ist ein ganz anderes Gebiet. Woher stammen denn die Koordinaten? Welche Website, welches Programm oder sonstige Quellen? --тнояsтеn ⇔ 20:58, 8. Jul. 2007 (CEST)

Nachtrag die Zweite. Auf der Diskussionsseite kommt so langsam Licht ins Dunkel. --тнояsтеn ⇔ 21:10, 8. Jul. 2007 (CEST)

Kurz: das Dezimaltrennzeichen fehlt, es sollte wohl eher heißen: 51_19_89.91 N und 8_83_36.30 O (nur der Vollständigkeit halber) --Rohieb 会話 +/- 22:14, 8. Jul. 2007 (CEST)

Das führt aber nicht zum richtigen Ort. Im Artikel sind jetzt die richtigen Koordinaten. Ich bin immer noch ein bisschen am Rätseln, woran es lag. Wohl eine Mischung aus allem gepaart mit einem falschen Ort ;-) --тнояsтеn ⇔ 22:20, 8. Jul. 2007 (CEST)

Ergebnisse

Ich will keine Diskussionen lesen, sondern Resultate sehen. Mir ist reichlich egal, welche Alternativen existieren. Ich brauche ein Benutzerhandbuch und danach gedenke ich zu arbeiten. Ich habe die Diskutiererei hier nicht verfolgt, eher den Eindruck gewonnen, dass mehrere um des Diskutierens willen hier etwas dazu geschrieben haben. Gibt es eine Zusammenfassung, ein Resultat? Wo stehts? --SonniWP 17:52, 30. Jul. 2007 (CEST)

Darf man fragen von was du redest, von was du Ergebnisse, Resultate, Zusammenfassungen lesen willst? --BLueFiSH ✉ (Langeweile?) 17:54, 30. Jul. 2007 (CEST)

Die Ergebnisse sollten alle auf der Projektseite zu finden sein, und die Diskussionsseite sollte meiner Meinung nach auch zu nichts anderem als zur Diskussion dienen... Gruß, Rohieb 会話 +/- 19:18, 30. Jul. 2007 (CEST)

Um es nochmal für Nordfriesen zu sagen (sorry für das Klischee): "Wer keine Diskussionen sehen will, darf nicht auf Diskussionsseiten gehen". Oder gibt es konkrete Kritik an der Übersichtlichkeit der Projektseite? Als Resultate kann ich ggf. auf http://tools.wikimedia.de/~kolossos/wp-world/karte.php?la=de verweisen. --Kolossos 20:26, 30. Jul. 2007 (CEST)

Ich kann vielleicht aus dieser Formulierung eine Absicht heraus lesen - aber DAS wäre MEINE Interpretation. Ich bin dort geboren und deshalb akzeptier ich die Formulierung - sie fordert mich höchstens zu gleichem auf - dazu bin ich zu faul! Der Internetlink ist ok, damit kann ich leben, ne gute Bedienungsanleitung wär mir lieber, eine genauer Wikilink, wo die Diskussion zur Bedienung dieses Tools steht, wäre schon erheblich kürzer als der Zwang, zum Auffinden den gesamten Diskussionssalat analysieren zu müssen. Als Abstraktionswerkzeug für Diskussionen habe ich nicht einmal ein Werkzeug vom Charakter eines Babelfish und selbst zum Diagonallesen steht hier noch zuviel. --SonniWP 20:49, 30. Jul. 2007 (CEST)

hier kommen wirklich brauchbare Werkzeuge

und hier natürlich auch: --Arcy 20:42, 30. Jul. 2007 (CEST)

• PinToMap durchsucht die gesamte Wikipedia-Datenbank nach Koordinaten und visualisiert diese mit Hilfe von Google Maps.
• tegmento, stellt die deutschen und englischen Geokoordinaten ebenfalls mit Hilfe von Google Maps dar.
• mygeotags, nutzt neben den Geokoordinaten noch ein Ortsverzeichnis mit 7,5 Mio Orten zur Suche nach Wikipedia Artikeln und Orten.
• www.geonames.org, mehr als 600'000 georeferenzierte Wikipediaartikel in 185 Sprachen. Webservice für Volltextsuche über Wikipedia-Artikel und Reverse Geocoding.
• pediaX, ein „Ajax-Wikipedia-Mirror“, zeigt zeigt die 20 populärsten Artikel im gewählten Google-Maps-Karten­ausschnitt, Selektion nach Typen (Berge, Gewässer) ist dabei möglich. Einnahmen über die laufenden Kosten hinaus kommen als Spenden dem Wikimedia e. V. zugute.
• Wiki By Map stellt die deutschen Wikipedia-Artikel nach Kategorien (z.B. Städte, Berge, Leuchtürme, Unis, Flugplätze, Unternehmen usw.) zur Verfügung.

und Nachklapp zur Disk.

Das sieht alles konstruktiv aus. Ich brauch Zeit. --SonniWP 20:51, 30. Jul. 2007 (CEST)

Ich habe hier einen Kommentar abgesetzt, weil mir anläßlich einer Revertierung eines Textes im Zusammenhang mit einer von mir eingesetzten Georeferenz kommentiert wurde "siehe dort". Dann habe ich mich hierher gewendet und versucht eine Antwort zu erhalten und habe nur von mir nicht verstandene Diskussionsbeiträge zu sehen bekommen. Deswegen meine Frage, die ihr als Disk.beitrag verstanden habt. Also ein Mißverständnis aus der Hektik heraus - ok - Entschuldigt obigen Wirrwar - im Augenblick der Bearbeitung, haben alle Beteiligten wohl Meldungen über Arbeitskonflikte bekommen - Ich werde das in einer ruhigen Phase mal aufräumen. --SonniWP 21:07, 30. Jul. 2007 (CEST)

Georeferenzierung und Weblinks zu Google Maps

Ich bitte um Beachtung dieser Diskussion zu Wikipedia:Weblinks über die Sinnhaftigkeit bzw. Zulässigkeit von Weblinks auf Google Maps bei gleichzeitig bestehender Georeferenzierung. Gruß --Superbass 16:25, 2. Aug. 2007 (CEST)

Mein Eindruck: Das Projekt WP:GEO döselt momentan so vor sich hin

Ich möchte mal nachfragen, ob es anderen genauso geht ? --Arcy 21:35, 9. Aug. 2007 (CEST)

Muss die Sommerhitze sein. --Dschwen 21:48, 9. Aug. 2007 (CEST)

Ich bin zwar woanders beschäftigt, lausche aber euren erhabenen Äußerungen. --SonniWP 21:56, 9. Aug. 2007 (CEST)

Wieso? Werden weniger Koordinaten eingetragen? Ist das messbar? Das ist das Projekt, nicht das Gelaber auf der Disk-Seite. --BLueFiSH ✉ (Langeweile?) 22:04, 9. Aug. 2007 (CEST)

Hab nicht den Eindruck - die Produktion läuft durchaus ziemlich geschmiert. --SonniWP 22:12, 9. Aug. 2007 (CEST)

Gibt es diesbezüglich eigentliche irgendwelche Statistiken ? --Arcy 22:14, 9. Aug. 2007 (CEST)

Keine Ahnung, ob die fleißigen Bienchen immer noch den Honig zum Imker tragen, zumindestens wird hier seit geraumer Zeit nich mehr konzeptionell über das Projekt nachgedacht. --Arcy 22:14, 9. Aug. 2007 (CEST)

Vielleicht ist es dann angebracht, mal zu formulieren, was denn bei den Dislussionen übrignlieb und nun wohl funktioniert. --SonniWP 22:16, 9. Aug. 2007 (CEST)

kannste gerne machen --Arcy 22:20, 9. Aug. 2007 (CEST)

Ich habe auch den Eindruck, dass gerade jetzt wo alles so schön automatisch archiviert wird, das Gerede nachgelassen hat, na sei es drum. Da der Maybe-Checker auch relativ konstant bei 7389 offenen Einträgen steht, könnte jeder der sich langweilt daran setzen (die Daten sind aktuell eingespielt). Eine weitere offene Aufgabe sehe ich in dem Erstellen freier Kartenicons. Die Nutzung der Koordinaten z.B. über den Geohack mit monatlich 1 Mio. Zugriffe erscheinen mir recht konstant und das ist ja mit die Hauptsache. Diskussionsbedarf sehe ich momentan eher im internationalen Umfeld. --Kolossos 08:37, 10. Aug. 2007 (CEST)

Was meinst Du mit "internationalen Umfeld" Kolossos? Ich persöhnlich sehe dort auch Handlungsbedarf. Zum Beispiel bei der Vereinheitlichung der Koordinatenvorlagen. Mich würde interessieren, ob euer Wikipediaworld bezüglich der Internationalisierung etwas gebracht hat. --Arcy 18:57, 10. Aug. 2007 (CEST)

Mit dem "Internationalen Umfeld" sehe ich die anderssprachigen Wikipedias, wir sind dabei nie den Weg gegangen, denen dort vorzuschreiben, "Nemmt diese oder jene Vorlage,...". Mag sein, dass das besser gewesen wäre, aber es wäre wohl auch kaum gegangen. Zumindest haben wir jetzt einem Überblick wer was macht. Zum "Internationalen Umfeld" zähle ich auch commons:Commons:Geocoding, was von unseren Erfahrungen und Skripten doch ein klein bisschen profitieren konnte (Ich finde das Projekt toll, und mein Dank für die geleistete Arbeit geht an Para).

Zu der Frage, ob es was gebracht hat:

• Ich denke, ein Wachstum von 141.000 auf 238.000 gesammelte Koordinaten seit November letzten Jahres ist nicht schlecht und ich glaube wir haben einen Teil zur Motivation der Leute beigetragen.
• Wenn wir es schaffen in Zukunft mit unseren Koordinaten auf KDE Marble dabei zu seinen und dieses über KDE (Linux) international vertrieben wird, ist das sicherlich auch ein Erfolg.
• Ich habe monatlich ca. 600.000 Zugriffe auf die Datenbank. Und das sind nicht nur de oder en Abfragen.
• Die Italiener benutzen jetzt eine vernünftige Vorlage [1] und blenden sogar standardmäßig den Wikiminiatlas ein.

Also es tut sich was, auch wenn es natürlich mehr sein könnte. Deshalb mein Aufruf an alle: Wer Fremdsprachenkenntnisse hat oder jemanden aus anderen Projekten kennt, möge bitte weiter Werbung machen. So, jetzt habe ich aber genug geschwafelt... zurück zur Arbeit. --Kolossos 20:20, 10. Aug. 2007 (CEST)

Ach die Italiener auch. Ich habs neulich nur zufällig bei den Portugiesen gesehen. Und auf Commons ist er natürlich auch standardmäßig aktiv. Ich hatte noch nie ernsthaft daran gedacht das für de.WP vorzuschlagen (die kam mir so konservativ vor in Sachen JS). Aber vielleicht wäre es jetzt mal einen Versuch wert. --Dschwen 20:26, 10. Aug. 2007 (CEST)

Na ja ... vielleicht liegt die Antwort darauf, wieso es so still hier geworden ist, ja auch irgendwie in den obigen Antworten. Sie zeigen Neuigkeiten auf, die im Projekt vormals noch nicht zur Sprache gekommen sind. Ich denke die Plattform WP:GEO hat z.T. auch einfach ihre Schuldigkeit getan. Den Platz nehmen mittlerweile diverse respektable Einzelprojekte ein, die sich der Arbeit des Projektes bedienen. --Arcy 23:55, 10. Aug. 2007 (CEST)

Welche Projekte meinst du denn? --Rohieb 会話 +/- 00:44, 11. Aug. 2007 (CEST)

Die oben erwähnten beispielsweise. --Arcy 14:33, 11. Aug. 2007 (CEST)

Ja, die aber ohne WP:GEO als Basis aufgeschmissen wären. Siehs mal positiv. Wenig Diskussionsbedarf (wenig Hick-hack) kann doch auch ein Zeichen für Stabilität sein. --Dschwen 00:37, 11. Aug. 2007 (CEST)

Ich seh doch gar nichts negativ! Wir in den Projekten auch schon nicht mehr geredet (-; ? ;-) oder sind das alles Projekte von Einzelpersonen ? --Arcy 14:33, 11. Aug. 2007 (CEST)

Hier noch ein Link zur Motivation: http://www.heise.de/open/artikel/93983/4 --Kolossos 12:54, 13. Aug. 2007 (CEST)

CH: 1903

Wie gebe ich also Schweizer Landeskoordinaten anstelle von {{Koordinate|Text Artikel|00|00|00.00|N|00|00|00.00|O|type=landmark|region=rr}} ein? mit Benutzung der Vorlage:CH1903-WGS84? Kannst Du mir ein Beispiel hier hinschreiben? Danke, -- Gruss, Saippuakauppias ⇄ 19:30, 5. Jul. 2007 (CEST)

mit der Vorlage:CH-Koordinate, Vorlage:CH1903-WGS84 wird da nur intern verwendet, brauchst du nicht. Beispiele findest du hier, etwa Schnebelhorn, da schaut das so aus (nach dem Abspeichern):

{{CH-Koordinate
   |Text   =X
   |Artikel=X
   |LAT    =47.325658<!--{{subst:CH1903-WGS84|716.481|242.787||koor=B|subst=subst:}}-->
   |LONG   =8.979582<!--{{subst:CH1903-WGS84|716.481|242.787||koor=L|subst=subst:}}-->
   |TYPE   =mountain
   |VALUE  =1292
   |REGION =CH-SG/CH-ZH
   |ONLY=LOCAL
   }}

vor dem Abspeichern hat es noch so ausgesehen:

{{CH-Koordinate
   |Text   =X
   |Artikel=X
   |LAT    ={{subst:CH1903-WGS84|716.481|242.787||koor=B|subst=subst:}}
   |LONG   ={{subst:CH1903-WGS84|716.481|242.787||koor=L|subst=subst:}}
   |TYPE   =mountain
   |VALUE  =1292
   |REGION =CH-SG/CH-ZH
   |ONLY=LOCAL
   }}

--Herzi Pinki 00:23, 6. Jul. 2007 (CEST)

Vielen Dank für de Antwort! Weitere Frage: Die Höhenordinate scheint nicht zu funktionieren, da ja nicht das ganze Geländemodell der Schweiz abrufbar sein kann. Richtig? Also wozu/wann benötigt man diese Ordinate?

{{subst:CH1903-WGS84|716.481|242.787||koor=H|subst=subst:}}

Gruss,  Saippuakauppias ⇄ 12:09, 6. Jul. 2007 (CEST)

Tja, weiß ich auch nicht, müsstest du Benutzer:visi-on fragen. Die Höhenangabe über VALUE wird benötigt für die type-Angabe in der aus den Angaben generierten Geokoordinate WP:GEO. Komplettes Höhenmodell gibt es aber keines.

War auf Urlaub, daher die lange Reaktionszeit, sorry. lg --Herzi Pinki 00:24, 27. Jul. 2007 (CEST)

Umrechnung von Schwerefeld bezogene Meter über Meer in elipsoide WGS84 Höhen (und umgekehrt). Sozusagen auf Vorrat implementiert, da ies immer mehr GPS Benutzer gibt. -- visi-on 17:22, 23. Aug. 2007 (CEST)

ToDos

(bitte ergänzen)

Na ja. Auch wenn sich mitlerweile ja viele in eigene Projekte begeben haben, denke ich, dass es noch einiges zu tun gibt. Mir fallen spontan zwei Sachen ein. --Arcy 22:40, 12. Aug. 2007 (CEST)

Internationale Vereinheitlichung der Koordinatenvorlagen

Die Vielfalt der Koordinatenvorlagen erschwert die Übernahme der Koordinaten von einer WP zur anderen WP. Kolossos hat oben ja schon mal einen Überblick der international verwendeten Vorlagen aufgezeigt. Ich denke dafür sollte auf dem meta-Wiki (als dafür zuständig) ein entsprechendes Projekt eingestellt werden, und auf den nationalen WPs dafür Stimmung gemacht werden. Hier mein erster Ansatz (schon was älter). --Arcy 22:40, 12. Aug. 2007 (CEST)

Automatisierung der Koordinatenhaltung

Die Koordinaten können nur bei einer automatisierten Speicherung +/- zeitnah auch wieder geliefert werden (CSV, SQL ...). Vielversprechend finde ich den Weg, beim Abspeichern eines Artikels über einen Datenbankabgleich herauszufinden, ob ein Neueintrag oder eine Änderung eines Koordinateneintrag vorliegt. Sollte dies der Fall sein, kann eine Datenbank dementsprechend aktualisiert werden. Die mittlerweile in die Jahre gekommene Extension von Markus Manske hat da schon seinerzeit den Richtigen Weg aufgewiesen. Ich habe selber mal vor einiger Zeit damit rumgespielt. (Siehe GISWiki). --Arcy 22:40, 12. Aug. 2007 (CEST)

Schau dir mal commons:Commons:Geocoding an, die Google Earth-Anbindung von Para läuft schon in Echtzeit, was natürlich äußerst motivierend ist. Allerdings sind die Commons-Edits z.B. gegenüber der engl. WP recht überschaubar, es gibt nur 1-2 Vorlagen auf Commons (siehe oben), es ist nur ein einzigstes Wiki und dort werden nicht noch die Kategorien, Interwikilinks etc. ausgewertet. Es muß also der Resourcenhunger geprüft werden. Wenn Stefan Kühns und meine Zeit mal wieder ausreicht, wollen wir uns das mal versuchen. Es kann sich aber auch gerne ein anderer mal dran versuchen. Auf dem Toolserver laufen auch Bestrebung die Volltexte verfügbar zu machen, dann wäre man zumindest nicht mehr auf die Dumps angewiesen. --Kolossos 08:58, 13. Aug. 2007 (CEST)

Pfade / Linien

Um die Wikipedia:WikiProjekt_Georeferenzierung/Pfad-Koordinaten ist es zu ruhig geworden. Ich weblinke jetzt zwar auf meinem Server liegenden Pfaddateien auf Google Maps (Beispiele: Erft, Schnellfahrstrecke Köln–Rhein/Main, jeweils unter Weblink als "Verlauf als Luftbild") aber das ist insgesamt eher unschön (Googlemonopolismus, Vermischung von Koordinaten und ihrer Darstellung etc.). Es wäre schön wenn jemand mal auf dem Toolserver was implementiert, was analog zu den normalen Punktdaten funktioniert. Eine Implementierung mit Unterseiten dürfte am einfachsten sein. --Walter Koch 11:30, 13. Aug. 2007 (CEST)

Schön, ich denke die Inormation kann hilfreich sein, besonders störend finde ich allerdings, die notgedrungene Nutzung eines privaten Servers (Zukunftssicherheit, Abhängigkeit,..). Schau mal unter http://commons.wikimedia.org/wiki/Commons_talk:Geocoding#Geocoding_of_Maps_as_an_overlay da haben wir eine Lösung gefunden um Karten als Overlay in Google Earth zu plazieren. Die Daten dafür liegen als KML auf commons. Die Vorgehensweise habe ich mal angefangen unter Benutzer:Kolossos/overlay zu dokumentieren. Das sollte auch für deine Pfade funktionieren. Da KML ein für Mensch und Maschine lesbarer Standard ist, sollte es kein Problem sein, die Daten auch in ein x-beliebiges Format umzuwandeln bzw. es wird von immer mehr Programmen unterstützt. Der Stein der Weisen ist es für diesen Anwendungsfall aber sicher noch nicht, es wurde wie gesagt für etwas anderes entwickelt. --Kolossos 11:48, 13. Aug. 2007 (CEST)

Da hab ich auch schonmal was programmiert fuer commons. Siehe commons:Template:GeoPolygon und dieses Beispiel (das waere die Loesung als Template, laesst sich aber mit wenig Aufwand an die Unterseitenloesung anpassen. --Dschwen 12:28, 13. Aug. 2007 (CEST)

Ja hatte ich übersehen. Commons als Datenträger ist zwecks internationaler Nutzung schon der richtige Platz. Templates sind auch immer gut. --Kolossos 08:35, 14. Aug. 2007 (CEST)

Auf commons wird auch über Zulassung von KML-Uploads nachgedacht. Das wäre dann die sauberste Lösung. KML Anzeige sollte auch im WikiMiniAtlas machbar sein mit ein wenig Programmierarbeit. --Dschwen 09:23, 14. Aug. 2007 (CEST)

OK, KML wäre das Praktischste. Wenn KML nicht patentiert ist, sollte die Aufnahme in Commons kein Problem sein. Ein Toolserverskript und eine Vorlage hier und in en.wikipedia und gut ist. Weisst Du, wie lange das noch dauern wird?
Was machen wir bis dahin? Nichts? Schon mal per Pseudobild/overlay.kml auf Commons auslagern (klappt das denn auch ohne Bild?) --Walter Koch 18:58, 14. Aug. 2007 (CEST)

Ich hab mal eine Vorlage Geopfad Vorlage:GeoPfad gebaut. Damit Geopfade bei Existenz einer Toolserverseite leicht umgebogen werden. --Walter Koch 23:42, 28. Aug. 2007 (CEST)

Globe

Wird der Parameter globe eigentlich bei der Datenauswertung mitberücksichtigt? Werden nur Erdkoordinaten extrahiert? Wie ist das eigentlich mit dem Karten-Datum auf extraterrestrischen Himmelskörpern? --Dschwen 22:27, 21. Aug. 2007 (CEST)

Ich hatte bei Diskussion:Mond/Archiv#Verweise_auf_Mondkarten_.2FGoogle-Moon und auch beim Mars schonmal versucht sowas anzusprechen, allerdings war die Resonanz gleich null. Für mich gibt es keinen Grund, das nicht über eine getrennte Vorlage abzuwickeln. Die Verlinkungsteueurung über den Globes-Parameter gibt es meines Wissen nach nicht. Frag noch mal in en nach, ansonsten einstampfen und für jeden Planeten eine eigene Vorlage. Der Geohack könnte sich vielleicht über den Trick mit der Sprache="Mondländisch" verwenden lassen, ohne dass Änderungen notwendig wären. Ansonsten erstmal mit einer direktverlinkenden Vorlage auf die wenigen Quellen anfangen. Für das Kartendatum , siehe Selenografie. --Kolossos 23:38, 21. Aug. 2007 (CEST)

Ich frag primär, weil ich jetzt auch einen Mond-Modus für den WikiMiniAtlas habe (development version siehe Settings), da werden aber zur Zeit noch Erd-Marker eingeblendet, schön wärs, wenn in der WikiPediaWorld DB auch der Globe verzeichnet wäre :-). Ich fände eine einheitliche Vorlage schon sinnvoll, wo es doch schon extra den Parameter globe gibt.--Dschwen 23:59, 21. Aug. 2007 (CEST)

Ich bin mir ziemlch sicher, dass eine Trenung der dominaten Erdkoordinaten vom Rest sinnvoll ist. Schließlich wurde der globe Parameter hier nicht, sondern nur in der englischen Wikipedia dokumentiert. Zudem sind die Links deutlich andere und ich möchte einfach nicht die WikipediaWorld-DB weiter verkomplizieren. Für dich wäre das einfach nur ein Zugriff auf eine andere Tabelle. Die DB für die Astronomen könnte dafür schön schlank sein. Kolossos 11:52, 22. Aug. 2007 (CEST)

Na ja, letztendlich ist es mir gleich, und ich kann Deinen Standpunkt durchaus nachvollziehen. Ich wuerde mich in jedem Fall ueber Astro-Koordinaten-Daten freuen :-). --Dschwen 12:20, 22. Aug. 2007 (CEST)

Ich würde mich auf jeden Fall auch freuen. Oftmals (Beispiel: Kategorie:Mare) sind Koordinaten schon vorhanden und müßten nur in eine Vorlage eingepflegt werden. Grundlage wäre also erstmal eine kleine Vorlage, dabei müßte man nur folgendes noch entscheiden:

• Ob man für jeden Himmelskörper ein eigene Vorlage wählt? Persönlich würde ich das bei einer einheitlichen Schreibweise bevorzugen, also { {Koordinate-Mond|lat|lon|size}}}, { {Koordinate-Mars|...|...|...}} und so weiter. Von wievielen Gestirnen reden wir eigentlich, Jupiter und andere Gaskörper fallen ja wohl weg?
• Und ob man einen Geohack-Klon braucht um Koordinatenformate umrechnen zu können oder ob man aufgrund der geringen Anzahl von Kartenanbietern die Anbieter einfach direkt in der Vorlage und damit im Artikel verlinkt. Dezimalangabe der Koordinaten würde ich in dem Fall bevorzugen. Welche Kartenanbieter gibt es aus Google und möglicherweise dir denn noch? --Kolossos 12:52, 22. Aug. 2007 (CEST)

z.B. http://www.mapaplanet.org/ (aber die haben gerade Serverprobleme). --Dschwen 13:15, 22. Aug. 2007 (CEST)

Wir sollten uns nicht nur um die Globe kümmern sondern auch überlegen die Stellare Objekte wie den Katzenaugennebel und Galaxien zu unterstützen, hab gerade gemerkt, das Google Earth in der Version 4.2 http://www.heise.de/newsticker/meldung/94715 einfach mal ein ziemliches gutes Planetarium in die Software reingepackt hat. Da scheint die Zusammenarbeit mit der Nasa Früchte zu tragen. Wir sollten da auch nicht fehlen, werden aber wohl Hilfe von unseren Astronomen brauchen. --Kolossos 23:32, 22. Aug. 2007 (CEST)

Ich freue mich schon auf die Referenzierung des Froschsterns B. ;-) --Kolossos 08:56, 23. Aug. 2007 (CEST)

Achso, die Russen verlinken jetzt schon auf: Wikisky.org wie man an ru:NGC_9 sehen kann. --Kolossos 09:20, 23. Aug. 2007 (CEST)

Verlinkung auf den Google-Sternenhimmel sollte jetzt schonmal gehen: http://tools.wikimedia.de/~kolossos/world-link-sky.php?ra=1&dec=50.01&range=200000&name=WerrusX Version 4.2 vorrusgesetzt. Kann mir jemand die Rangeangabe erklären? --Kolossos 18:56, 23. Aug. 2007 (CEST)

Antwort auf eigene Frage: http://code.google.com/apis/kml/documentation/kmlsky.html --Kolossos 18:29, 26. Aug. 2007 (CEST)

Problematische Lesereihenfolge in Screenreadern

Die Vorlage Koordinate Text Artikel ist für die Verwendung innerhalb des Artikeltextes oder in Infoboxen vorgesehen und wird dort üblicherweise wie folgt eingebaut.

Koordinate: {{Koordinate Text Artikel|…}}

Momentan wird das von Screenreadern als "Koordinate: Koordinate: 10° N, 14° O10° N, 14° O" vorgelesen, was offensichtlich nicht besonders hübsch ist. Wenn man die Reihenfolge der beiden Elemente im Vorlagenquelltext vertauscht und ein Leerzeichen einfügt

<span class="coordinates">[…]</span> {{Text oben rechts|1=Koordinaten: […]}}

ändert sich für den sehenden Benutzer nichts, Benutzer von Screenreadern lesen dann jedoch "Koordinate: 10° N, 14° O Koordinate: 10° N, 14° O". Das ist (technisch bedingt) immer noch doppelt, wird aber zumindest in einer etwas sinnvolleren Reihenfolge vorgelesen. --TM 09:16, 22. Aug. 2007 (CEST)

Der Sinn von span ist, die Koordinate zu umschließen. Ein Herausnehmen der Koordinate aus dem span ist keine Alternative. --BLueFiSH ✉ (Langeweile?) 09:25, 22. Aug. 2007 (CEST)

Kann man nicht per CSS das vorlesen unterdrücken? Es gibt doch StyleSheets für diverse Medien. --Dschwen 09:32, 22. Aug. 2007 (CEST)

Ich fürchte, ihr habt mich falsch verstanden. Ich will nichts „aus dem span herausnehmen“. Ich will, dass der Quelltext

{{Text_oben_rechts|1=Koordinaten: [{{KoordinateURL}}{{{1}}} {{{2}}}]}}<span class="coordinates">[{{KoordinateURL}}{{{1}}} {{{2}}}]</span>

in

<span class="coordinates">[{{KoordinateURL}}{{{1}}} {{{2}}}]</span> {{Text_oben_rechts|1=Koordinaten: [{{KoordinateURL}}{{{1}}} {{{2}}}]}}

geändert wird. Das ist nur ein Vertauschen von zwei Elementen, von denen eines ohnehin absolut positioniert wird, und das Einfügen eines Leerzeichens, wie ich oben schon schrieb. --TM 10:02, 22. Aug. 2007 (CEST)

Achso. Na wenns weiter nichts ist. Das Leerzeichen kann allerdings nicht an dieser Stelle stehen; ich habe es in den span geschoben. --BLueFiSH ✉ (Langeweile?) 10:29, 22. Aug. 2007 (CEST)

Nur zum besseren Verständnis, sachlich ergibt das ja keinen Unterschied: Warum darf das Leerzeichen nicht außerhalb des span stehen? --TM 12:56, 22. Aug. 2007 (CEST)

Weil ich dann möglicherweise im Fließtext auch mal "( 50° 10' N ...)" zu stehen habe, was ein Plenk ist. --BLueFiSH ✉ (Langeweile?) 18:52, 22. Aug. 2007 (CEST) Ist natürlich quatsch, hab falschrum gedacht. Das im Span ist ja nicht der Teil oben rechts, sondern andersrum. Eigentlich darf in der Vorlage darum gar kein Leerzeichen stehen wenn ich es mir recht überlege.. --BLueFiSH ✉ (Langeweile?) 18:55, 22. Aug. 2007 (CEST)

Mist, du hast Recht. So geht es aber wirklich: --TM 19:30, 22. Aug. 2007 (CEST)

<span class="coordinates">[{{KoordinateURL}}{{{1}}} {{{2}}}]</span>{{Text oben rechts|1=&#32;Koordinaten: [{{KoordinateURL}}{{{1}}} {{{2}}}]}}

Massenhafte Änderungen nach Volkszählungen etc

Hi,

seit einiger Zeit geht mir etwas durch den Kopf. Hier ist vielleicht nicht ganz der richtige Ort, aber ich glaube die Leser hier sind am nächsten dran. 2010 findet die nächste Volkszählung in den USA statt, irgendwann 2011 sollen die Daten veröffentlicht werden. Nachdem die Einwohnerzahl ja Teil der Geokoordinate ist, stellt sich die Frage ob und wie wir die Daten mit möglichst wenig Handarbeit einpflegen können (in die Koordinaten und idealerweise auch in den Fließtext). Ist es jetzt schon an der Zeit für irgendwelche Ideen? 2011 sind dann mehrere große europäische Staaten dran. --h-stt !? 22:34, 23. Aug. 2007 (CEST)

Genau, so zum Beispiel auch 2011 in Deutschland. --ALE! ¿…? 10:05, 24. Aug. 2007 (CEST)

Wenn das halbwegs standartisiert geschrieben ist, erscheint mir das Problem im Jahre 2010 mittels Bot lösbar. Bis dahin mach ich mir noch keine Gedanken. Nur die Zuordnung bei verschiedenen Schreibweisen könnte schwierig werden, da könnte ich mir eine Vorlage {offizieller Ortsname} vorstellen. --Kolossos 10:41, 24. Aug. 2007 (CEST)

Maybe-Checker: Wieviele Kategorie-Ebenen durchsucht das Tool?

Hi, ich habe in den letzten Tagen immer wieder mal den Maybe-Checker auf US-Bundesstaaten angewendet und mittlerweile im Westen der Vereinigten Staaten alle Bundesstaaten abgearbeitet. Allerdings scheint das Tool nur eine begrenzte Anzahl an Unterkategorien zu berücksichtigen, denn auch wenn die Kategorie:Kalifornien als abgearbeitet gemeldet wird, gibt es in der Kategorie:San Francisco noch was zu tun. Wie tief sucht das Tool und wo muss man wieder von Hand einsteigen? --h-stt !? 12:31, 27. Aug. 2007 (CEST)

Oh, das würde mich allerdings auch mal interessieren. Ich gebe als Kategorie immer nur Japan ein, und wundere mich, dass da nichts mehr ist... --Rohieb 会話 +/- 18:15, 27. Aug. 2007 (CEST)

Ach mensch, warum ist denn der Toolserver schon wieder down... :-/ --Rohieb 会話 +/- 18:21, 27. Aug. 2007 (CEST)

Dann will ich mal das Geheimnis lüften. Da die Kategorien sehr instabil sind und oft ihre Namen wechseln und feiner untergliedert oder zusammengefasst werden, bringt es nichts, direkt nach einzelne Orts/Gebietskategorien zu filtern. Deshalb gehe ich nur nach Kategorien vor, die ein Thema beinhalten. Also suche ich nicht nach "Kirchen in Sachsen" und "Kirchen in Holland" sondern nutze alle Kategorien, die das Wort "Kirche" beinhalten. Das klappt sehr gut, aber z.B. bei "Gebäude" kommt auch die Kategorie:Gebäudeteil. Ich hab mir also eine Liste erstellt, die viele georeferenzierbare Objektearten (Bahnhof, Stadion, Denkmal, Kirche, Tempel, Garten, Berg, Ort, ...) beinhaltet. Wenn jetzt also ein Objekt in z.B. Japan eine sehr seltene Kategorie besitzt, dann wird es von meinem Skript nicht erfasst. Sollten euch große Lücken auffallen nehme ich gerne weitere Kategorien auf. Anbei stelle ich mal die Wörter nach denen ich filtere hier ein. -- sk 18:47, 27. Aug. 2007 (CEST)

de: "Ort" "See" "See" "Schloss" "Burg" "Berg" "Pass" "Turm" "Brücke" "Museum" "Kloster" "Gebäude" "Kirchengebäude" "Denkmal" "Naturdenkmal" "Kulturdenkmal" "Stadion" "Flughafen" "Flugplatz" "Insel" "Bauwerk" "Festung" "Theater" "Kulturzentrum" "Bahnhof"

en: "City" "Lake" "Castle" "Mountain" "Museum" "Building" "Church" "Airport" "Airport" "Isle" "Venues"

Achso. Und die Unterkategorien zu diesen gefundenen Kategorien werden dann nicht berücksichtigt? --Rohieb 会話 +/- 19:12, 27. Aug. 2007 (CEST)

Richtig, wenn es eine Kategorie Hügelchen in der Kategorie Berg gibt, dann wird die derzeit nicht erfasst. Der Algorithmus war nur dafür gedacht zahlreiche Vorschläge zu machen, die noch nicht georeferenziert sind. Er kann nicht alle finden. Spätestens wenn überhaupt keine Kategorie in einem Artikel drin ist, dann versagt er. Für Verbesserungsvorschläge bin ich jederzeit offen. -- sk 20:14, 27. Aug. 2007 (CEST)

Wie ist das mit Kategorie:Geographie (Vereinigte Staaten) und allen Unterkategorien? Werden die erfasst? --h-stt !? 19:17, 27. Aug. 2007 (CEST)

Die meisten Artikel in der Kategorie haben "See", "Berg", "Naturdenkmal", "Insel" als Kategorie im Artikel stehen. Deshalb werden sie vom Skript größtenteils erfasst. Yuma-Wüste hat nix von diesen Wörtern in einer ihrer Kategorien und wird deshalb nicht mit erfasst. Sammelt doch hier einfach noch ein paar "Schlüsselwörter", die ich mit erfassen soll. Also "Wüste" wäre z.B. ein mögliches. -- sk 20:17, 27. Aug. 2007 (CEST)

"Geographie" wäre wohl ein gutes Stichwort. Damit erfasst du schon mal alle Artikel, die direkt unter Kategorie:Geographie (Vereinigte Staaten) und den jeweiligen Unterkats der Bundesstaaten liegen. Für die Kategorie:San Francisco oder Kategorie:Los Angeles fällt mir jetzt kein Suchkriterium ein. Vielleicht, dass sie eine Kat unter Kategorie:Vereinigte Staaten nach Ort liegen? Oder besser Kategorie:Nordamerika nach Ort, damit erwischst du auch die Kanadischen und Mexikanischen Ortskats. Lässt sich das abbilden? --h-stt !? 21:10, 27. Aug. 2007 (CEST)

Kategoriebäume lassen sich in Datenbanken recht schwer beherrschen wenn es um Durchforstung aller Äste geht. Catscan kann das jedoch bis zu einer gewissen Tiefe. Vielleicht wirst du ja damit glücklich. --Kolossos 21:34, 27. Aug. 2007 (CEST)

Einfacher ist es, wenn du sagst, ich möchte alle "Zoo"s und alle "Wüste"n etc. Das kann ich problemlos einbauen. Aber für regionale Eigenkategorien möchte ich es nicht machen, weil die sich zu häufig ändern. Ich will ja nicht jeden zweiten Tag das Skript anpassen müssen. Deshalb hab ich auch diesen unscharfen Weg genutzt. -- sk 16:32, 28. Aug. 2007 (CEST)

Nun gut, was mir zur Stichwort-Liste grad noch so einfällt: Staat, Land, Bezirk, Dorf, Präfektur, Bistum, Provinz, Region, (Land-)Kreis, County, Provinz, Landkreis, County, Komitat, Arrondissement, D[e|é]partement, Depart[a|e]mento, Kraj, Borough, Powiat, Verwaltungseinheit (ach wirklich), Gouvernement, Gemeinde, Kommune, Amt, Grafschaft, Munizip, Qark, Oblast, Woiwodschaft, Kanton, Gebiet (zb Kategorie:Abhängiges Gebiet und Unterkategorien), Nation, Distri[c|k]t, Stadtteil, Enklave, Exklave, Subnationale Entität ;-), Territorium, Park, Museum, Platz, Viertel, Kirche, Straße, Station, Weltkulturerbe, und was ganz nettes: Grenze, ähm ja. Das wars erstmal. Da gibts bestimmt genug von. --Rohieb 会話 +/- 23:36, 28. Aug. 2007 (CEST)

Super! Werde das entsprechend für den nächsten Durchlauf mit einbauen. Weitere? -- sk 07:46, 29. Aug. 2007 (CEST)

Geokoordinaten, die nur ungefähr bekannt sind

Ich befasse mich zur Zeit mit Ausgrabungsstätten in Mesopotamien. Dort werden offenbar viele Stätten nur ungefähr beschrieben. Um diese Orte praktikabel zu verlinken, würde es meiner Ansicht nach sinnvoll sein, die bekannten Angaben zu nutzen (also etwa bei "in unmittelbarer Nähe von Ras Al Ain" eben diesen Ort zu referenzieren). Zusätzlich wäre es dann aber doch gut, zusätzlich ähnlich der Vorlage:Lagewunsch einen Baustein einzufügen, dass diese Koordinate verbesserungsbedürftig ist. Ich habe im Diskussionsarchiv dazu nichts gefunden und hoffe, hier keine schon längst geführte Diskussion weiter breitzutreten. Gibt es hier Vorschläge/Lösungen? -- Tobias Tilemann 01:59, 3. Sep. 2007 (CEST)

Da es in dem Beispiel für den Ort Ras Al Ain keine Geokoordinate gibt, bleibt einem wohl nix anderes übrig als die Koordinaten in dem Artikel zur Ausgrabung zu verzeichnen. Den zweiten Teil der Vorlage kann man dann verwenden um über die Unexaktheit zu informieren. Ich hab mal Geonames.org nachgeschaut und könnte mir folgendes vorstellen: vorstellen. Dank amerikanischer "Friedenspolitik" ist Mesopotamien übrigens sehr gut abgelichtet und vielleicht findet sich ja im Layer der Google Earth Community ein genauer Eintrag der Ausgrabungsposition, (manchmal werde ich da fündig). --Kolossos 09:20, 3. Sep. 2007 (CEST)

Die verschiedenen Google-Layer habe ich, ebenso wie die Webseiten der beteiligten Universitäten und Institute, bereits durchsucht. Auch nach längerer Suche konnte ich den Grabungsort von Tell Halaf, um das es sich handelt, nicht identifizieren – dort, im Grenzgebiet Syriens zur Türkei sind die Fotos leider nicht so gut. Die Grabungen sind auch erst letztes Jahr (seit 1911) wieder aufgenommen worden.

Vielleicht bekommt man ja Angaben von den beteiligten Wissenschaftlern, vielleicht wollen sie aber auch die Stätte mit guten Gründen nicht veröffentlichen.

Ich wollte das Problem aber zunächst grundsätzlich klären: Ähnlich ist es z.B. bei dem ehemaligen Brutreaktor auf dem Gelände des Forschungszentrum Karlsruhe. Für diesen Artikel wurde ein Lagewunsch geäussert. Veröffentlicht ist aber nur die allgemeine Lage des Forschungszentrums (und steht auch im dortigen Artikel). Ich hatte an eine ähnlich Lösung wie Kolossos gedacht und werde sie umsetzen, wenn es hier keine Bedenken gibt. --Tobias Tilemann 13:04, 3. Sep. 2007 (CEST)

Tja, die Lösung wäre vielleicht ein Parameter für die Genauigkeit, ebenso wie ein Parameter für die Ausdehnung des Objekts.

Dann müsste man aber auch mal von den Bandwurm-Vorlagen weg. -- Simplicius ☺ 13:56, 3. Sep. 2007 (CEST)

Hab ich auch gedacht. Nach einigem Überlegen halte ich das jedoch höchstens als Trigger für praktikabel, also dimensionslos, etwa im Sinne von genau/ungenau. Denn die Grösse der Ungenauigkeit wird man oft nicht angeben können. Wenn der per default auf genau stehen würde, könnte man die Koordinaten sicherlich auch per Bot ersetzen. Allerdings befürchte ich, dass das die Koordinate weiter überfrachtet und schwerer handhabbar macht. Deshalb fände ich eine Lösung wie von Kolossos besser, mit dem Nachteil, dass das nicht automatisiert detektierbar wäre. -- Tobias Tilemann 14:43, 3. Sep. 2007 (CEST)

Eine Alternative wäre es, die Koordinate in den Text zu verlegen und dort auf einen Ort bezugzunehmen, der bekannt ist. Allerdings fände ich es eleganter, wenn man weiterhin mit der Artikelkoordinate arbeiten könnte, wenn es sich im Grunde darum, und nicht um die Referenz handelt. --Tobias Tilemann 14:47, 3. Sep. 2007 (CEST)

Oder die Einführung einer Vorlage entsprechend Lagewunsch, die die Koordinate als ungenau bezeichnet. --Tobias Tilemann 14:56, 3. Sep. 2007 (CEST)

Hätt ich nichts dagegen, wie zB {{Koordinate Artikel ungenau}} oder {{Koordinate Artikel|ungenau=1|...}}, Kennzeichnung im Ausgabetext ((ungenau) 50° 35" N...) und Schaffung einer Kategorie:Ungenaue Koordinaten o.ä. Mir ists nämlich auch schon öfters so gegangen, und ich hab lieber von einer Koordinateneinbindung abgesehen, obwohl man ja schon für Benutzer, die sich in der betreffenden Landschaft besser auskennen, "Zuarbeit" leisten und gleichzeitig für solche, die sich überhaupt nicht dort auskennen, wenigstens einen ungefähren Anhaltspunkt liefern könnte. Vielleicht war auch schonmal jemand (bswp. mit einer Reisegruppe) dort und kann sich genau an die Gegebenheiten vor Ort erinnern, aber weiß nicht, wie er dorthin (bspw. mit dem Bus mitten in die Pampa) hingekommen ist. --Rohieb 会話 +/- 20:50, 3. Sep. 2007 (CEST)

Was sprich dagegen die Koordinaten der englischen Wikipedia en:Tell_Halaf zu nutzen? Mit Grad und Minutenangabe schätze ich den Fehler auf ca. 2 km. Zu dem anderen Ideen: mein Vorschlag war ja ein zu mindest für den Menschen lesbarer Trigger. Ohne das für dafür die Vorlage ändern müssen, ansonsten die Diskussionen für eine neue Vorlage laufen ja gerade. --Kolossos 15:31, 3. Sep. 2007 (CEST)

Da spricht eigentlich nichts dagegen, ausser eigener Dummheit bzw. Schlamperei. Allerdings ist die englische Koordinate ihrerseits falsch: Nach Augenschein und Beschreibung muss der Fundort, am Südufer des Chabur gelegen, entweder westlich oder nördlich der Ortschaft sein. Die englische Koordinate ist östlich - fern jedes Flusslaufs. Insofern wäre das auch eine Koordinate, die man ehrlicherweise mit einem "Unsicherheitsradius" versehen sollte. Ich habe jetzt angefangen, diese "In-der-Nähe-von"-Koordinaten zu verwenden; falls diese Diskussion sinnvoll und relevant sein sollte, ist es vielleicht gut, sie gesondert zu archivieren. Deshalb meine Frage: Ist es O.K., das redigierte Archiv dieser Diskussion "zu befüllen", oder machen das die Admins? Und findet ihr den Punkt überhaupt diskussionswürdig? --Tobias Tilemann 19:39, 3. Sep. 2007 (CEST)

Das macht dann beizeiten der ArchivBot. Ich würde die Ergebnisse aus dieser Diskussion in die Projektseite einarbeiten. --Rohieb 会話 +/- 20:50, 3. Sep. 2007 (CEST)

Ich habs mal in Wikipedia:WikiProjekt_Georeferenzierung#Vorlagen-Inhalt eingearbeitet. --Arcy 22:09, 3. Sep. 2007 (CEST)

Danke! --Tobias Tilemann 23:08, 3. Sep. 2007 (CEST)

Nochmal: Vorlage:Coor dm und Vorlage:Coor dms

Die aus en "importierten" Koordinatenvorlagen liefern vielfach vollends falsche Geokoordinaten. Ich habe unlängst den englischsprachigen Beitrag "List of Torres Strait Islands" in die deWP übertragen (Liste von Torres-Strait-Inseln), dabei aber erst jetzt festgestellt, dass sämtliche Koordinaten schlichtweg falsche Ziele anpeilen. So führt die Koordinate der Aipus Island ({{coor dm|9|941|S|142|172|E|region:AU-QLD_type:isle}}) zwar nach Australien, aber nicht mal in die Nähe der Torres-Straße. Dabei spielt es keine Rolle, ob man Google Earth oder NASA World Wind einsetzt. Ich halte daher die en-Coor-Vorlagen - gelinde gesagt - nicht für sinnvoll; diese sollten baldigst per Bot durch unsere bewährten "Koordinate Text" bzw "Koordinate Artikel" ersetzt werden. Andernfalls lacht man uns ja aus, wenn plötzlich hunderte von Inseln im Landesinneren georeferenziert sind... Gruß --Zollwurf 14:01, 9. Sep. 2007 (CEST)

Das liegt aber nicht an der Vorlage coor dm sondern an der Herkunft der Koordinaten. Es wurden in der englischen Wikipedia massiv Datensätze ungeprüft aus irgendwelchen Datenbanken übernommen. Es gibt scheinbar nirgendwo auf der Welt eine umfangreiche, handverlesene Koordinatensammlung, die frei zugänglich wäre. Deshalb bauen wir hier sowas ja auf. ;-) -- sk 14:51, 9. Sep. 2007 (CEST)

Das liegt imho nicht an der Vorlage, sondern an den eingetragenen Koordinaten dm 9|941 soll ja z.B. 9° und 941 (!!!) Minuten bedeuten. 941' / 60 = 15,6°. 15,6° + 9° = 24,6 ° S und 172' / 60 = 2,86°. 2,86° + 142° = 144,86° E. Die (falschen) Koordinaten zeigen genau das (richtig) an, was (falsch) eingegeben wurde. Das Problem sitzt also vor dem Rechner ;-). --Arcy 14:57, 9. Sep. 2007 (CEST)

Freilich ist mir das mit 9|941 auch aufgefallen. Wenn es für GeoKoor-Vorlagen eine Plausibilitätskontrolle gäbe, könnte man bestimmt derartige "Unfälle" vermeiden, egal ob in der de- oder en-Wikipedia. Nur, ist so etwas mit einfachen Mitteln denn überhaupt machbar? Mit etwas Programmierkenntnisen ist das bei einem Stand-alone-Programm kein Ding (hab mir sowas selbst erstellt), aber für die breite Wikipedia-Welt? Na, ich weiß nicht... --Zollwurf 15:31, 9. Sep. 2007 (CEST)

Die Plausibilitätskontrolle ist sofort nach Koordinateneingabe verfügbar. Es ist der Link zum Geohack. --Arcy 16:34, 9. Sep. 2007 (CEST)

Stimmt ;-) Aber was nun mit den en/de-Vorlagen? Parallel, Austauschen oder wie es einem beliebt? Fehler der Vorlagen ignorieren? Ich werde künftig jedwede undefinierbare en-Coor Vorlage entfernen, es sei denn Du rechnest sie mir vorab um... --Zollwurf 19:12, 9. Sep. 2007 (CEST)

Wenn Du meinst ... Nur zu ;-) Aber es war kein Fehler speziell in der en-Coor Vorlage. Alle Vorlage zeigen mit falschen Eingabedaten falsche Positionen an. Als weitere Plausibilitätskontrolle empfehle ich einen kurzen Blick auf die Koordinaten (-; 999 Minuten ;-) --Arcy 20:27, 9. Sep. 2007 (CEST)

Held der Arbeit

Hallo Wikipedianer! Ich hatte mal zwei fleißige Helfer der Georeferenzierung vorgeschlagen, siehe hier. Was ist denn aus dieser Aktion geworden? Gruß 84.155.104.17

Es haben viele zugestimmt, aber keiner hat den "Blue Marble Orden" dann dem Benutzer angeheftet. Bisher hat meines Wissens nur Benutzer:Lilleskut von mir einen bekommen. Scheinbar traut sich sonst keiner den zu verleihen. Also sei mutig. -- sk 17:05, 15. Sep. 2007 (CEST)

Wenn es von einer IP kommt, finde ich es irgendwie nicht so toll... 84.155.111.66 11:49, 23. Sep. 2007 (CEST)

Ok, das stimmt auch! Ich hab den beiden jetzt mal den Orden an die Brust geheftet! Vielen Dank an Benutzer:Eriosw und Benutzer:Thgoiter. --sk 19:25, 23. Sep. 2007 (CEST)

Extrem unterschiedlicher Anzeigemasstab bei Google Maps und Windows Live Lokal

Zur Info: Hab bei Sprogø die Koordinaten etwas verfeinert. Kontrolle mit Google Maps, Yahoo Maps, Windows Live Local. Dabei ist bei Windows Live Lokal der Masstab extrem unterschiedlich. Breite des Bildausschnittes bei Google und Yahoo ca 15Km, Bei Windows Live Lokal etwa 125 Yards. Wird anscheinend ein Parameter nicht richtig übergeben. Viele Grüsse -- Moneyranch 04:15, 21. Sep. 2007 (CEST)

In der Koordinate steht doch weder das alte scale noch das neue dim! Da wird einfach nur die Koordinate übergeben und dann das an die Webseiten weitergeleitet, ohne auf den Maßstab zu achten. -- sk 14:14, 22. Sep. 2007 (CEST)

Habs auf meiner Spielwiese getestet, gleicher Effekt. Map sources/GeoHack sagt: mit einem Maßstab von ungefähr 1 : 100000. Hab auch das Beispiel reinkopiert, ebenfalls gleicher Effekt. Anscheinend wird der Massstab vom Type-Parameter genommen, hab ein bichen mit der Dim Variable rumgespielt, kein Erfolg. Es darf gerne auf meiner Spielwiese editiert werden. -- Moneyranch 23:02, 22. Sep. 2007 (CEST)

Das ist ein Problem des Aufrufs der jeweiligen Seite von Geohack aus. Für Google: spn=0.01,0.01; für Live Local der typ; Yahoo mag=6 usw. usf.

Das ist einfach der derzeitige Wissensstand über die Schnittstelle des jeweiligen Kartenanbieters. Irgendwie muss ich das Gewünschte dem Service erst mal mitteilen.-- visi-on 00:28, 23. Sep. 2007 (CEST)

Der Dim-Parameter hat keinen Einfluss auf den Kartenmassstab Hab das Projektbeispiel (Porta Nigra Trier) auf meiner Spielwiese mit verschieden dim Angaben getestet (inzwischen als Koordinate Text). jeweils Masstab 1:10000 bei dim:25; 250,; 2.500; 25.000. der Type-Parameter beeinflusst den Kartenmasstab (gibts auch auf meiner Spielwiese), geht aber so nicht aus der Beschreibung hervor. -- Moneyranch 03:59, 23. Sep. 2007 (CEST)

Nachtrag: Windows Live Lokal hat anscheinend seine Parameter geändert. [2] ist der funktionierende Permalink nach Trier. Die Trennung der Koordinatenwerte erfolgt durch eine Tilde, die Reihenfolge der Parameter umgestellt und es scheint zu klappen. Die Anzeige der Stecknadel sollt auch funktionieren; werd ich nach ein paar Stunden Schlaf erkunden (Cahce leeren und solche spielchen)... Südlich des Äquators und westlich von 0° werden jeweils durch ein negatives Vorzeichen angegeben. Hoffe ich hab mit den Angaben etwas helfen können -- Moneyranch 04:44, 23. Sep. 2007 (CEST)

Wo soll man kml/kmz-Dateien speichern?

Ich habe mal unter Mekong Weblinks eine Kaskade von 5 Talsperren und dazu 2 Städte georeferenziert. Mit Google Maps lassen sich diese 7 Elemente schön anzeigen.

• Wo soll die kmz-Datei abgespeichert werden? Geht das inzwischen bei Wikipedia? Habe mich heute bei der GoogleEarth Community angemeldet, um die kmz-Datei dort abzulegen. Aber so einfach scheint das nicht zu sein. Derzeit liegt die Datei auf meiner privaten Homepage.

• Hatte erst die Vorlage GeoPfad benutzt. Damit konnte ich nur die Satellitenkarte aufrufen. Der direkte Aufruf von GoogleMaps ist hier praktikabler ( http://maps.google.de/maps?f=q&hl=de&t=m&q= ). Der t-Parameter steuert den Karten-Typus (siehe Google Map Parameters. Für mich persönlich ist es angenehmer, wenn ich mich erst auf einer Landkarte orientiere und erst danach in das verschiedene Grün und Braun der Satellitenaufnahme blicke. Allerdings habe ich bei See Pangong_Tso unter Weblinks nur eine Satellitenaufnahme mit dem GoogleMaps Zoomlevel 9 platziert,also wieder ohne die Vorlage GeoPfad, weil in der verlassenen Himalaya-Gegend eine Landkarte nicht weiterführt.

• Als Symbole habe ich irgendwelche Symbole von GoogleEarth verwendet. Man sollte sich bei Wikipedia auf Standardsymbole einigen (Beispiel geonames.org mit Buchstaben als Unterscheidung für Stadt, Land, Fluss, ...). Gibt es bereits passende Ikonen bei Wikipedia?

• Das Hochladen von kmz-Dateien wurde mir bei Commons untersagt. Ich hoffe, man überprüft nicht nur die Dateiart (jpg, ...). Ist auch eine Virenprüfung damit verbunden? Ansonsten ist für mich bisher nicht begreiflich, warum man so relativ kleine kmz-Dateien (Größenordnung wenige KB) nicht hochladen können sollte. Hablu 17:35, 24. Sep. 2007 (CEST)

Auf Commons geht das leider nicht (siehe diverse Diskussionen auf dieser Seite). Ob es jemals gehen wird, weiß ich nicht. Laß sie erstmal auf Deiner Homepage. Die Geopfad-Vorlage kannst Du gerne mit Zusatzparametern anpassen, so daß man Hybrid, Satelitt oder Karte wählen kann. Diese Vorlage ist eh nur ein Notbehelf, damit überhaupt mal was Strukturiertes passiert. Allerdings ist Vorlage:GeoPfad für Pfade (Flüsse, Pipelines etc.) gedacht, nicht so sehr für Sammlung von Punkten (obwohl es auch dafür schon verwendet wird). Für geringe Anzahl von Nichtpfadpunkten würde ich auch gar keine KML haben wollen, da sind Einzelpunkte, wie in allen anderen Artikel m.E. für den Leser besser. --Walter Koch 18:02, 24. Sep. 2007 (CEST)

Na dann versuche ich auch mal kurz zu antworten:

• "Die Wikipedia ist keine Google Earth Community". Zumindestens stand man lange Zeit sehr kritisch einem Format eines einzelnen Herstellers gegenüber, durch offene Standardisierung und die Nutzung durch andere Anwendungen ändert sich das ggf. bald. Durch deine Nutzung der "Koordinate Text"-Vorlage werden die Koordinaten in ca. einem Monat auch so in die Wikipedia-Geodatenbank einfliessen und damit auch in Google Earth nutzbar sein. Also, private Homepage ist zwar Mist, geht aber momentan nicht anders.
• Dazu kann ich nix sagen.
• Icons sind leider noch Mangelware, siehe: commons:Category:Map_icons
• Bei den zum Upload zugelassenen Dateiarten geht es nicht nur um die Dateigrößen, sondern darum, dass eine Format dauerhaft von der Community gepflegt werden kann. Da es Google Earth z.B. lange Zeit auch nur für Windows gab, wäre es damals einem Admin unter Linux nicht möglich gewesen den Inhalt der Datei zuprüfen, auch gilt es Wildwuchs vorzubeugen. Siehe dazu: commons:Commons:File types. ---Kolossos 21:11, 24. Sep. 2007 (CEST)

Vielen Dank für die Antworten. Offensichtlich liege ich mit meinem Vorgehen nicht ganz falsch. Ich habe heute zum ersten Mal mit GoogleEarth Pfade gezeichnet. Zeichnen ist weder meine Stärke noch Leidenschaft. Und der Effekt ist auch nicht besonders.

• Talsperren Kaskade am oberen Mekong mit zusätzlich eingezeichnetem Pfad für den Mekong. Die Datei mekongcascade3.kmz ist 140 KB groß. Mein triviales Aha-Erlebnis: Jeder Flussknick im Gebirge erfordert nicht nur Geduld des Zeichners, sondern macht die Datei auch größer und langsamer. Laden und Aufbau spürt man in der Antwortzeit.
• Talsperren Kaskade ohne Mekong-Pfad. Die Datei mekongcascade4.kmz ist nur etwa 1,5 KB groß.
• Mekong von der Quelle bis zur Mündung
• Mit dem Automatismus habe ich so meine Zweifel. Bei der Talsperren-Kaskade geht es zum Beispiel auch darum, dass China damit seinen südlichen Nachbarn in den nächsten Jahrzehnten das (lebensnotwendige) Wasser abgräbt. Wie schauen solche Talsperren aus und wo stehen sie? Ein umständliches Navigieren in Datenbanken ist keine Alternative für einen Eye-Catcher per Mausklick.
• Meine heutige erste Bekanntschaft mit der GoogleEarth Community war bisher kein Erfolgserlebnis. Wenn man mit GoogleEarth rumspielt, dann stören die vielen kmz-Dateien. Wo aber meine erste kmz-Datei mekongcascade.kmz beim Hochladen im GoogleEarth-Pool verblieben ist, weiß ich nicht. Die Philosophie der Community habe ich bisher nicht verstanden. Aber ich werde die Datei suchen und hoffentlich auch finden. Denn eine kmz-Datei auf der eigenen Homepage ist kein Lösungsweg.Hablu 22:35, 24. Sep. 2007 (CEST)

Punktdaten werden hier urheberrechtlich als unbedenklich eingeschätzt, beim Abzeichnen von Pfaden ist das was anderes und hier noch ungeklärt, siehe Rechte an Geoinformationen. Ein weiterer Grund warum der Upload von KMLs hier nicht einfach erlaubt ist. Mit dem offizielle GE -Forum kam ich auch nie richtig klar, aber unter Diskussion:Google_Earth/Archiv/01#Weblinks_4 gibt es ja diverse Alternativen. --Kolossos 10:58, 25. Sep. 2007 (CEST)

Externer Zugriff auf Wikipedia Commons?

Das Dam Icon in commons:Category:Map_icons für eine kmz-Datei (siehe obiger Diskussionsbeitrag kml/kmz-Datei in Commons?) habe ich in eine png Datei umgewandelt, weil GoogleEarth zumindest lokal keine svg Dateien akzeptiert. Aus der aktuellen Adresse http://upload.wikimedia.org/wikipedia/commons/4/4d/Dam_icon.png vermute ich, dass die Commons Dateihierarchie für externe Anwendungen nicht gedacht ist, weil diese Anwendungen nicht über eine Wikipedia-Schnittstelle (image:) zugreifen können. Und deshalb ist es auch nicht sinnvoll, kmz Dateien für GoogleMaps in Commons abzulegen. Im Gegensatz zu GoogleMaps läuft die Software GoogleEarth zwar lokal beim Anwender ab, kml/kmz-Dateien werden entsprechend runtergeladen (von Windows-Benutzern durch Doppelklick auf die Datei), aber für den schnellen Blick auf eine Karte ist GoogleEarth ungeignet. Für kmz/kml-Dateien mit einer derartigen Verwendung (GoogleEarth) sehe ich auch keinen Bedarf.

Gibt es einen Denkfehler meinerseits? Wenn nein und wenn Wikipedia Commons mit externen Anwendungen wie GoogleMaps nicht zusammenpasst, stellt sich die Frage, ob man hierfür einen eigenen Dateienpool schaffen sollte (stabile Dateiastruktur), der im Gegensatz zu einer Homepage für alle Wikipedianer zugänglich ist?

Beispiel Erfurt. Hier gäbe es einige Unterartikel aus Erfurt einzubinden, ganz zu schweigen von den zahlreichen Fotos in

Commons: Erfurt – Sammlung von Bildern, Videos und Audiodateien

. Der Besucher ist vielleicht spontan interessiert, was er in zwei Stunden oder an einem Nachmittag alles besichtigen könnte. Da hilft ihm zum Beispiel eine Googlemaps-Karte mit Wikipedia Artikeln und Wikipedia Bildern.

Hablu 12:34, 25. Sep. 2007 (CEST)

Für sowas gibt es schon den WikiMiniAtlas, sieht dann z.B. so aus: Bild:Wikiminiatlas new basemap.png. --тнояsтеn ⇔ 15:42, 25. Sep. 2007 (CEST)

Ist der WikiMiniAtlas schon allgemein zugänglich? Die DEMO-Version schaut gut aus.Hablu 11:40, 27. Sep. 2007 (CEST)

Und auch der Google Earth Layer von Wikipedia:WikiProjekt_Georeferenzierung/Wikipedia-World#Dynamisch und commons:Commons:Geocoding laufen zufriedenstellend. Die von dir vorgestellte Erfurter Themenkarte erscheint mir keine sonderlich günstige Lösung. --Kolossos 16:33, 25. Sep. 2007 (CEST)

km*-Dateien sind ein recht pragmatischer Weg Punktsamlungen, Pfade, Fläche u.ä. in Dateien abzubilden. Daß Google Maps und Earth solche Dateien benutzen ist für uns recht nützlich und deswegen wird der Typ ja auch verwendet.

Allerdings vermischt dieser Dateityp die Werte und ihre Darstellung. Anstatt zu sagen "Da ist ein <Staudamm> auf Koordinate <xy>" gibt man dort halt "Da ist ein Bildchen <dam.png> auf Koordinate <xy>" an. Eine reine Kordinatensammlung wäre besser. Aber das ist ja nur eine Übergangslösung bis der Toolserver da eine Weiterleitungsseite hat. --Walter Koch 22:55, 25. Sep. 2007 (CEST)

Ich bin gerade von en:User:Para informiert wurden, dass die englische Wikipedia eine Vorlage en:Template:GeoGroupTemplate eingeführt hat. Damit kann man sich mehrere Punkte eines Artikels wie z.B. en:Manchester, Bolton and Bury Canal in verschiedenen Programmen anschauen. --Kolossos 21:13, 26. Sep. 2007 (CEST)

Ah, clever. Ein Skript auf dem Toolserver sucht den Artikel nach Koordinaten ab, und generiert daraus KML- oder GeoRSS-Dateien. Damit könnten wir den alten Vorschlag von Unterseiten wieder aufgreifen: Eine Unterseite mit den Koordinaten, ein Template und ein Skript auf dem Toolserver, und schon gehts. Dazu noch ein Tool, das die Koordinaten aus existierenden KML-Dateien in Text für eine Unterseite umwandelt. --Walter Koch 21:57, 26. Sep. 2007 (CEST)

GeoGroupTemplate funktioniert

Das ist die Lösung für mein eigentliches Problem. Wenn ich zum Beispiel im Artikel Mekong Staudämme georefefernziere (habe ich verlagert in Entwicklungsprogramm_für_den_Westen_Chinas#Mekong), dann soll der Leser über welches Tool auch immer diese Staudämme mit einem Klick auf einer Landkarte betrachten können. Ich habe es in der englischen Wikipedia ausprobiert: en:Mekong#Dams. Es funktioniert sehr gut!!! Das Ergebnis: en:Mekong#External_links . Leider ist mein Englisch miserabel. Dehalb bitte ich Entschuldigung, dass ich den Unterartikel Mekong#Dams nicht ausführlicher ausformuliert habe. Außerdem habe ich im Unterartikel Mekong#Bridges noch eine Brücke georeferenziert.

Aber diese Funktion hat natürlich Auswirkungen auf bereits benutzte Vorlagen.

• Die Quelle des Mekong ist in GoogleMaps als Referenz mit dem Namen #1 zu sehen. Der englische Artikel verwendet das Template Vorlage:Geobox River und gibt darüber die Koordinaten an. Außerdem gibt es über diese #1 keinen Bezug zum Wikipedia-Artikel Mekong im Gegensatz zu den anderen fünf oder sechs Talspeeren (Dams).
• Man kann entweder GoogleMaps oder GoogleEarth aufrufen (außerdem GeoRSS).
• Wenn man die Funktion auf eine Stadt (obiges Beispiel Erfurt) anwendet, dann gibt es neue Anforderungen an eine Typisierung: Bahnhof, Museum, Flugplatz, Kirche, ... Eine praktikable Alternative ist allerdings die Typisierung über Unterartikel, weil die Titel der Unterartikel beim KMZ-Export eingebunden sind.
• Bei der Schnittstelle GoogleEarth zu GoogleMaps ist in der KML/KMZ eine URL-Referenz auf das gewünschte Icon angebbar oder bei lokalen Icons wird dieses mit in die KMZ-Datei verpackt. Da sind wir wieder bei meiner obigen Frage des externen Zugriffs auf Wikipedia Icons commons:Category:Map_pointer. Das geht ja bisher nicht. Also muss das Icon in die KMZ-Datei eingefügt werden, die man an GoogleMaps übertragt, und zwar in allen möglichen Formaten, aber nicht als svg (Vektorgrafik).

Vermutlich muss noch einiges für die deutsche Wikipedia angepasst werden, oder? Für Stadtbeschreibungen, wie oben Erfurt, ist das auch eine tolle Sache.Hablu 11:40, 27. Sep. 2007 (CEST)

Die interessanten Koordinaten von Erfurt haben wir größtenteils in den einzelnen Erfurter Artikeln, das jetzt nochmal im zentralen Artikel zu sammeln erscheint mir unnütze Redundanz. Kolossos 12:39, 28. Sep. 2007 (CEST)

JPG-Bilder mit EXIF

Bezüglich der JPG-Bilder habe ich die Frage, wie man konkret die Koordinaten in den EXIF-Bereich einstellen sollte? Es geht ja manuell mit diversen Tools. Gibt es da von Wikipedia schon irgendwelche Helferchen? Und wenn man dann Bilder mit Georeferenz hat, wie werden die dann wohin (WikiMiniAtlas, GoogleEarth, ..) vermittelt?Hablu 11:40, 27. Sep. 2007 (CEST)

Geodaten in EXIF Tags is m.E. nur bei automatischem Tagging sinnvoll (Kamera hat eingebautes GPS, oder Du synchronisierst einen GPS trail im Nachhinein mit den Photos (dazu gibt es Programme)). Sonst wuerde ich erstmal weiter die GeoTagging Templates verwenden. Ich habe vor ein paar Monaten mal nach Geo-EXIF Tags bei commons geschaut. Eine DB-Abfrage hat mir zwei getaggte Bilder aus 1.5mio ausgegeben. Ich schau die Tage nochmal. Dann kann man sicher auch einen Bot schreiben, der die EXIF Daten als Templates in die Bildbeschreibung einfuegt (mit einer MW-Extension wuerde ich erstmal nicht rechnen). --Dschwen 15:52, 27. Sep. 2007 (CEST)

Vielen Dank für die schnelle Antwort auf meine neugierige Frage. Eine externe Einbindung von Bildern bei der KML/KMZ-Erstellung mit GoogleEarth habe ich mal vor langer Zeit problemlos ausprobiert. Das Zusammenführen von Geo-Koordinate und Bild oder Bildern ist so recht einfach. Andrerseits habe ich heute im Internet festgestellt, dass die Geo-Koordinaten schon in einer EXIF-Spezifikation (V2.2 ???) am Ende des letzten Jahrtausends festgelegt wurden. Und vor einigen Jahren habe ich mal mit Tools wie EXIFER, JjoThumb, ... Daten in JPEG-Bilder geschrieben. Gibt es denn außer für das Medium Presse (Pressefotos) und für das Militär einen Anwendungsbedarf, dass man die Geo-Koordinaten aus dem JPEG-Bild ermitteln kann? Das „Austauschformat“ KML geht doch wohl bisher davon aus, dass die Geo-Koordinaten explizit und nicht implizit über ein Bild übergeben werden, oder ist das ein Trugschluss von mir?Hablu 16:56, 27. Sep. 2007 (CEST)

Das es bei Flickr über 2 Mio. geogetaggte Bilder gibt zeigt wohl, dass nicht nur bei Militär und Presse Interesse daran besteht, genauso dieses Panoramio. --Kolossos 12:39, 28. Sep. 2007 (CEST)

Interne Links

Gibt es für die Darstellung solcher Koordinatengruppen auch ein Wikipedia-Tool? Wäre das zum Beispiel WikiMiniAtlas?Hablu 11:55, 27. Sep. 2007 (CEST)

Leider baut mein Internet-Provider (aus welchen Gründen auch immer (Engpass)) die Verbindung unregelmäßig ab und wieder auf, so dass mein Beitrag zerstückelt ausschaut.

Die Frage nach internen Links möchte ich an Beispielen konkretisieren.

1. Im Artikel KZ Auschwitz-Birkenau habe ich in der Positionskarte Polen mal alle KZs eingetragen, die in der Wikipedia für Polen vorhanden sind. Es hat mich einfach mal interessiert, weil ich über einen anderen Artikel auf das KZ Ausschwitz kam. Diese Neugier ist zukünftig wohl auch über die obige Vorlage (siehe GeoGroupTrmplate) extern mit GoogleMaps und intern mit WikiMiniAtlas zu befriedigen?
2. Für den Artikel Mekong habe ich mal eine Positionskarte Mekong erstellt und auf der Positionskarte einige Merkmale wie Städte, Zuflüsse und Talsperren mit ihren Geo-Koordinaten platziert. Andrerseits habe ich in die Positionskarte auch Ländernamen eingetragen, die so positioniert wurden, dass sie die obigen Geo-Referenzen nicht überlappen. Im Artikel Mekong sind also in der Positionskarte Mekong Geo-Koordinaten und Angaben für die Positionierung von Ländernamen vermischt.
3. Bei der heute erstellten „Positionskarte Gelber Fluss“ habe ich nachträglich festgestellt, dass das Bild krumm und schief, also als Basis für eine Positionskarte ungeeignet ist. Wie kann man diese Positionskarte wieder löschen? Die Positionskarte ist nicht mehr so interessant, weil hoffentlich bald der Flussverlauf auch über GoogleMaps oder WikiMiniAtlas betrachtet werden kann. Dafür braucht man ja die ungefähre Angabe zweier Geo-Koordinaten (Quelle und Mündung), um den Flussverlauf gleich im richtigen Zoom präsentiert zu bekommen, die man mit der entsprechenden Vorlage (GeoGroup) übermittelt.Hablu 18:09, 27. Sep. 2007 (CEST)

Bei deinem KZ Auschwitz Eintrag möchte ich deine Euphrie etwas bremsen. Wenn das gehört die Grafik zumindest in eine Vorlage um unsägliche Redundanz in allen KZ-Artikeln zu vermeiden. Und ist sie denn vollständig? Das sollte alles erstmal in einem größeren Rahmen besprochen werden. --Kolossos 12:39, 28. Sep. 2007 (CEST)

DE-07, DE-15, DE-02, DE-05

Kann mir jemand erklären wo diese Regionsangaben herkommen, die ich grad ca. 25 mal auf die korrekten korrigiert habe?? --BLueFiSH ✉ (Langeweile?) 21:07, 25. Sep. 2007 (CEST)

Ich vermute von diesem Tool: http://www.mcaviglia.ch/gmap/coor_de_v2.html. --Arcy 21:26, 25. Sep. 2007 (CEST)

(Bearbeitungskonflikt) Wir haben so ein "tolles Tool" http://www.mcaviglia.ch/gmap/coor_de_v2.html auf unserer Projektseite. Ich hatte den Author schonmal angeschrieben, siehe Benutzer_Diskussion:Mcaviglia#Wikikoordinaten. Da er nicht mehr aktiv scheint, hilft wohl nur das Tool aus unserer Projektseite zu löschen, es nützt ja nix wenn wir alles nacharbeiten müssen. --Kolossos 21:32, 25. Sep. 2007 (CEST)

Ich hab den entsprechenden Eintrag auskommentiert. Wenns korrigiert ist, kanns ja wieder sichtbar gemacht werden. --BLueFiSH ✉ (Langeweile?) 21:45, 25. Sep. 2007 (CEST)

Exklaven

soll bei Exklaven auch die Region des Umschliessenden Auslands angegeben werden? Also im Falle von

• Büsingen region=DE-BW/CH-SH
• Horn TG region=CH-TG/CH-SG
• usw.

Eine verbindliche Festlegung ist sicher hilfreich. -- visi-on 11:55, 27. Sep. 2007 (CEST)

Nee lieber nicht. Wird halt weiter ganz normal behandelt, halt wie eine Insel im Auslands-Meer. -- sk 23:11, 30. Sep. 2007 (CEST)

Ausgabetext durch Vorlage automatisch erstellen

Auch auf die Gefahr hin, dass das Thema schon mal behandelt wurde (kann mir nun unmöglich alles inkl. Archive durchlesen): Wäre es bei einer programmierten Vorlage nicht möglich, dass der Ausgabetext zumindest optional weggelassen werden kann und aus den Koordinaten im ersten Teil generiert wird? Ich hielte es schon für eine Vereinfachung, gerade für ungeübte Nutzer, aber auch mich stört es, wenn ich die Koordinaten zweimal in verschiedenen Formaten aufführen muss. Ganz nebenbei würde man so vielleicht auch eine Standardisierung (Leerzeichen, keine Umbrüche usw.) für alle Artikel hinbekommen. --Niteshift 10:15, 21. Aug. 2007 (CEST)

Bei der Einführung der Vorlage gab es meines Wissens nach noch nicht die Möglichkeit programmierte Vorlagen zu nutzen. Ich denke man könnte darüber nachdenken, aber es sollten hier erstmal alle Möglichkeiten der Ausgabe zusammengesammelt werden, bevor man mit einer Umsetzung beginnt. Generell, stimme ich dir aber zu. -- sk 10:28, 21. Aug. 2007 (CEST)

Man koennte auch mal laut ueber eine Einfuehrung von en:Template:coord nachdenken. Ich weiss, ganz wohl ist mir dabei auch nicht, es gibt schliesslich ein gut funktionierendes bewaehrtes und durchdachtes Templatesystem auf de.WP, aber ein Angleichen der Templates koennte die Zusammenarbeit ueber Spachgrenzen hinweg foerdern, ausserdem ist coord auch schon von anderen WPs angenommen worden. --Dschwen 10:45, 21. Aug. 2007 (CEST)

Ich würde die beiden Dinge jetzt nicht unbedingt mit einander verbinden. Wir sollten weiter unsere drei Basis-Vorlagen (KA,KTA,KT) pflegen und weiterentwickeln. Ich persönlich sehe in coord nur ein Zwischenschritt, der erstmal alles vereinheitlicht, aber als nächster Schritt, wäre ein wirkliche Vereinheitlichung notwendig. Derzeit sind in coord einfach noch zu viele möglichkeiten enthalten, als dass man es wirklich vernünftig weiternutzen könnte. Ich lese coord ja schon mit aus, aber ich würde jetzt nicht in DE alles umstellen. Durch unsere Entwicklung in DE können wir auch einen Gegenpol zu EN bieten und zeigen, dass es auch besser geht. Wenn erstmal alle Projekte auf coord umgestellt sind, wird man sich noch schwerer tun, die Vorlage zu vereinfachen. -- sk 11:16, 21. Aug. 2007 (CEST)

Ich könnte mir ja vorstellen Template:coord zu unterstützen, wenn ich es nur verstehen würde, was diese Vorlage und ihre 20 Untervorlagen so genau machen. Habs versucht, bin aber am Syntax gescheitert. Ein KA,KTA,KT könnte man sicher auch noch drum basteln. Man sollte sich aber auch im klaren darüber sein, dass eine Flexibilität der Ausgabe, wie sie im Artikel Russland bzw. Pesterwitz genutzt wird, wohl wegfällt. Oder man integriert eine Alternativausgabe auch noch in die Vorlage. Der größte Nutzen wäre wohl der das jeder sich die Koordinateneinträge aus einem Artikel schnappen könnte und in ein Wiki einer anderen Sprache kopieren könnte. --Kolossos 12:46, 21. Aug. 2007 (CEST)

Coord bietet die Möglichkeit die Koordinate auf sehr unterschriedliche Art einzugeben. Aber das sehe ich als ihr größtes Problem. Denn beim Weiternutzen muss man alle Möglichkeiten mühsam aufdröseln. Deshalb wäre es gut die für den Menschen am einfachsten zu lesende Eingabe zu nutzen und daraus alle möglichen Ausgaben zu generieren. Bsp: {{Koordinate|50_10_0_N_12_23_23_S|type=KA|output=dec|name=Eiffelturm|type=landmark|dim=100|region=FR }}" Natürlich könnte man auch die Koordiante noch splitten "NS=50.3|EW=12.2|" oder anders. Durch die Parametrisierung wäre auch eine einfachere Filterung z.B. über die Vorlagenauswertung möglich. -- sk 13:29, 21. Aug. 2007 (CEST)

*zwischendrängel* Also soo viele Möglichkeiten sinds nun auch nicht, auf jeden fall nix was man nicht mit 2-3 regexps parsen könnte. Einen Mittelweg aus Komfort für den Anwender, und Komfort für den Datennutzer zu finden wird schwierig sein, da hat jeder seine Vorstellung von dem was nötig und was komfortabel ist :-). Das ist der Stoff aus dem Diskussionsseiten mit millimeter-kurzen Schiebern in der Bildlaufleise sind ;-). --Dschwen 20:39, 21. Aug. 2007 (CEST)

Stefan, wenn du in diesem Beispiel aus dem "S" noch ein "E" bzw. "O" oder "W" machen würdest, fände ich diese Vorlage auf Anhieb gut! -- Simplicius ☺ 13:42, 21. Aug. 2007 (CEST)

Wie meinen? NS ist die Breite und EW die Länge? Wie hättest du es gerne? Es sollte ja international verständlich sein. Mir fällt auf, dass ich zweimal das Wort "type" benutze, das sollte man auch ändern. -- sk 13:52, 21. Aug. 2007 (CEST)

Achso, du meinst bei "50_10_0_N_12_23_23_S"! Tippfehler! ;-)

2.Versuch: {{Koordinate|NS=50.3|EW=12.2|base=TA|output=dec|name=Eiffelturm|type=landmark|dim=100|region=FR }} Aber das würde noch nicht das Beispiel Russland abdecken. -- sk 14:07, 21. Aug. 2007 (CEST)

3.Versuch: {{Koordinate|NS=50.3|EW=12.2|base=TA|output=dec|outputtext=SpezialRussland|name=Eiffelturm|type=landmark|dim=100|region=FR }} So, das würde alle unsere bisherigen Koordinatenvorlagen abdecken. Glaub ich. -- sk 14:09, 21. Aug. 2007 (CEST)

Ist NS=50.3 = 50.3 N oder 50.3 S ? Mit NS oder EW müssen die Werte negativ/positiv sein um unterscheidbar zu sein.--Arcy 17:19, 21. Aug. 2007 (CEST)

Richtig erkannt! In dem Beispiel sind beide positiv, also N und E. -- sk 17:25, 21. Aug. 2007 (CEST)

Was soll base=TA sein? Und wie soll man da 50° 23' 46" O eingeben? O statt E sollte auch ausgegeben werden. --BLueFiSH ✉ (Langeweile?) 17:48, 21. Aug. 2007 (CEST)

base=TA meint "Koordinate Text Artikel", als Standard würde ich A einsetzen und T ist halt nur Text. Dadurch reduzieren wir 3 Vorlagen auf eine. Das mit der Eingabe 50° 23' 46" O würde nach dem Modell nicht mehr gehen. Ich war zwar lande Zeit Verfechter, aber ich glaube jetzt die Dezimalzahl ist zukunftstauglicher. Intern wird ja so oder so umgerechnet. Also 50.396111 sollte auch eingebbar sein. Ich weiß das wird vielen nicht schmecken, andererseits kann man sich als Normalsterblicher besser 50.53 vorstellen als 50° 31' 48". Denkbar wäre auch eine Eingabe wie die Schweizer es machen, die automatisch in das richtige Format umwandelt. -- sk 18:41, 21. Aug. 2007 (CEST)

Eine "perfekte" neue Vorlage zu bauen, halte ich so oder so für nicht verkehrt. Und dann soll ein Meinungsbild zeigen, ob wir umsteigen wollen. Das Dezimalsystem finde ich aber noch nicht wirklich schön. Auch den richtigen internationalen Nutzen kann ich nur erkennen, wenn wir uns an der Coord-Schreibweise orientieren oder unsere Schreibweise international durchsetzen können, ansonst können wir es auch so wie gehabt bleiben lassen. --Kolossos 19:15, 21. Aug. 2007 (CEST)

automatisierte Ausgabe: Anstatt alle Kraft in die Entwicklung einer neuen Vorlage zu stecken, die eventuell dann auch noch den Anspruch hat, von internationalem Nutzen zu sein, sollte die Arbeit in die Erweiterung der Mediawiki-Software gesteckt werden, um nicht nur eine automatische Ausgabe, sondern darüber hinaus auch eine automatische Speicherung der Koordinaten zu erreichen. Ich hatte diesbezüglich einen kurzen Schriftwechsel mit Magnus Manske (geohack). Eine Erweiterung der Software ist kaum ein Problem. Die größte Arbeit besteht - und so sehe ich es auch - in der Überzeugung der Developer, dass eine solche Erweiterung der Software auch von wirklichem Nutzen ist. Angesichts der ganzen Diskussionen zur eierlegenden "Wikidata"datenbank kann ich eventuellen Unwillen seitens der Entwickler aber auch verstehen. Mittels einer einheitlichen Datenbankschnittstelle würde sich imho auch recht schnell die Problematik der überbordenen Anzahl an Vorlagen klären. --Arcy 20:36, 21. Aug. 2007 (CEST)

Es gab und gibt zahlreiche Bemühungen, vermeintlich bessere Varianten der etablierten Vorlage:Koordinate Text usw. zu schaffen, siehe zum Beispiel Vorlage:Geo-Koordinate oder Benutzer:Divisor/Vorlage:Koordinaten Text. Diese Versuche kann man allesamt als gescheitert betrachten:

• Sie verkürzen zwar die Eingabe, vereinfachen sie aber kaum. Zwar wird der hintere, doppelte Teil der Eingabe weg gelassen, aber dieser Teil war nie ein Problem, da man ihn im einfachsten Fall problemlos durch Kopieren des ersten Teils erzeugen kann. Den weitaus komplizierteren ersten Teil vereinfachen die neuen Vorlagen dagegen kaum. Es werden lediglich ein paar Sonderzeichen durch andere Sonderzeichen ausgetauscht.
• Sie sind unflexibel, da dem Autor die Entscheidung genommen wird, wie die Koordinate dargestellt werden soll. (Kleinere Objekte benötigen sekundengenaue Koordinaten, bei größeren Objekten genügen unter Umständen ganze Grad. Manchmal ist die dezimale Schreibweise sinnvoll, manchmal die sexagesimale.)
• Sie basieren auf sehr komplizierten Vorlagenquelltexten, die man nur schlecht pflegen kann.

{{Koordinate Text|
  5_10_N_112_13_W_type:city(120000)_region:DE-BY|5° 10′ n. Br., 112° 13′ w. L.}}
{{Benutzer:Divisor/Vorlage:Koordinaten Text|
  5|10|N|112|13|W|city(120000)|DE-BY}}
{{Geo-Koordinate|
  5|10||N|112|13||W|type=city(120000)|region=DE-BY}}

So wie ich das sehe, ist das ein Job für eine noch zu schaffende Mediawiki-Extension, über die ebenfalls schon oft diskutiert wurde (z. B. <geo></geo>). --TM 09:57, 22. Aug. 2007 (CEST)

Hmm, alle bisherigen Vorlagen wurden nicht umgesetzt, weil sie von oft von Einzelkämpfern gestartet wurden, oder weil sie sich als nicht wirklich besser erwiesen. Warum sollte man also ein funktionierendes System in ein anderes funktionierendes gleichwertiges System umwandeln. Aus der Arbeit mit der Vorlagenauswertung hab ich gelernt, dass eigentlich das beste System möglichst einfach zu warten sein sollte. Und das ohne großen Aufwand. Wenn ich mir das hier anschau, sehe ich auf einen Blick wo wir Eingabefehler haben und kann diese dann korrigieren. Das geht so mit den aktuellen Vorlagen nicht. Deswegen wäre ich für Wünsche und Anregungen was eine Umstellung anbelangt sehr dankbar. Möge die beste Vorlage gewinnen! Wie gesagt, je einfacher die Auswertung umso einfacher die Wartung und Nutzung. @TM: Genau die von dir angesprochenen Punkte, scheinen doch aber durch die oben vorgeschlagene 3.Version alle behoben zu sein, oder siehst du noch Änderungsbedarf?-- sk 13:00, 22. Aug. 2007 (CEST)

Vierte Version

So ich hab noch mal weiter überlegt. Es wäre eigentlich bei einem solchen Schritt, wie ich ihn jetzt hiermit auch vorschlage, also der Umstellung auch noch wünschenswert die Parameter Höhe und Einwohnerzahl zu trennen. Der Vorschlag hat nix mit der schon existierenden Vorlage Koordinate zu tun, nur um Verwechslungen zu vermeiden.

{{Koordinate
|NS         = 50.3                        maximal x Nachkommastellen
|EW         = -12.2                       negativ ist Süd bzw. West
|type       = city                        landmark, city, airport
|pop        = 100000                      nur bei Orten Einwohnerzahl (Länder und Regionen denkbar) 
|height     = 8000                        nur bei Bergen Höhe
|dim        = 100                         Durchmesser Umkreis
|region     = DE-SN                       Region
|base       = TA                          Standard A=Artikel, möglich A,TA=Text Artikel, T=Text
|output     = dec                         Ausgabeformat jedes denkbare möglich, UTM, GKK, GK, Zeilenumbruch
|outputtext = 41°-78° N, 58°O - 170°W      Alternative Ausgabetext der Koordinate
|name       = Eiffelturm                  Alternative Ausgabetext des Titels (nur bei Textkoordinate)
}}

Ich sehe damit eigentlich alle Kritikpunkte beseitigt. Wir vermeiden Redundanz, wir sind extrem flexibel. Die Vorlage hat international verständliche Parameter, der Vorlagenname kann durchaus national angepasst werden. Die Vorlage kann als Einzeiler und auch als Mehrzeiler eingebunden werden. Durch die mehrzeilige Variante haben wir ähnlich wie bei den Personendaten ein einfacheres Benutzen. Die Vorlage kann ganz oder Teilweise in andere Sprachen problemlos übernommen werden. Die Benennung der einzelnen Parameter erleichtert die Auswertung extrem. Mit der Vorlagenauswertung steht quasi schon ein Überwachungstool zur Verfügung.
Die Nachteil: Man kann nur noch dezimale Gradangaben eingeben. Die Vorlage muss noch programmiert werden. Die bestehenden Vorlagen muss per Bot auf die neue umgestellt werden. Alle existierenden Vorlagen (Infoboxen) müssen angepasst werden.
Viel zu tun also! Packen wir es an. Verbesserungsvorschläge?!? -- sk 18:24, 22. Aug. 2007 (CEST)

Hm, bevor sich unsere Schweizer wieder melden: Wie ists mit dem Bezugssystem, was ist wenn man die Ausgabe in Schweizer (oder anderen) Koordinaten haben will? Ich denke, das müsste die Vorlage dann irgendwie umrechnen? Dass man nur noch dezimale Koordinatenangaben angeben kann stört mich persönlich nicht so wirklich, solange die entsprechenden Google-Maps/-Earth-Plugins angepasst werden ;) Nochwas: wenn man nur mal kurz im Text auf eine Koordinate verweisen will, ist mir das ganze eigentlich zu lang. Man sollte auf jeden Fall für bestimmte Parameter (sinnvolle) Standardwerte festlegen, oder auch optionale Argumente erstellen, die nicht unbedingt für die URL auf den Geohack gebraucht werden (zB region, dim, height). --Rohieb 会話 +/- 22:58, 22. Aug. 2007 (CEST)

Mit output kann man jedes erdenkliche Format aus den Dezimalangaben rauswerfen. Also ich könnte mir da z.B. ein "output=ch" für die Schweizer problemlos vorstellen. - Mir fällt auf, dass wir bei "base" eigentlich zwei Sachen vermischen. Eigentlich brauchen wir da nur T=Text und A=Artikel für den Bezug der Koordinate. TA=Text Artikel vermischt ja Bezug und Ausgabe, das könnten wir also problemlos rausweren. Muss halt dann bei dem Parameter "output" entsprechend angegeben werden, wie und wo es ausgegeben werden soll. Das mit der Länge sehe ich nicht als Problem. Wenn Standard base=A und output=GMS ist, dann wäre eine normale Landmarke/Stadt so in einer Zeile zu georeferenzieren.

{{Koordinate|NS=50.3|EW=-12.2|type=landmark|dim=100|region=DE-SN}} 
{{Koordinate|NS=50.3|EW=-12.2|type=city|pop=10000|region=DE-SN}} 

- Weitere Anmerkungen? -- sk 23:46, 22. Aug. 2007 (CEST)

versteh ich nicht was bei base vermischt sein soll -- visi-on 17:03, 23. Aug. 2007 (CEST)

Mir fällt noch auf das man EW als Einwohner interpretieren könnte. Wäre X und Y besser? Lat und Long halte ich für unbrauchbar, da nur Fachleute mit den Begriffen wirklich arbeiten und der Normalnutzer da immer erst nachschlagen muss, was jetzt was genau ist. Außerdem fällt mir gerade ein, dass man ja für die Schweizer auch durchaus die Region-Angabe nutzen kann. So das bei allen Koordinaten wo ein "CH-" in Region auftaucht, die Angabe zusätzlich in Schweizer Koordinaten ausgegeben wird. -- sk 23:51, 22. Aug. 2007 (CEST)

Das mit der Region auswerten hatte ich mir auch schon überlegt. Da unser Wiki aber immernoch keine substr function kennt ist das bei Grenzfällen schwierig. man könnte ja noch bei CH-SH/DE-BW auf die Schweizer Koordinaten verzichten, aber was machst du bei CH-ZH/CH-AG usw. ausserdem sind auch die Höhenbezugssysteme verschieden. Momentan biebe da nur mindestens drei Höhen und Regionen als Parameter zuzulassen. Das ist nicht wirklich elegant. Bei den Höhen könnte man die WGS84 Höhe auf das Regional gültige Höhenbezugssystem umrechnen. Dir Stefan könnte das noch gefallen. Da aber 99% der User unter Höhe etwas schwerefeldbezogenes mit Bezug zum Meeresspiegel verstehen sehe ich das auch nicht als durchsetzbar an.-- visi-on 17:03, 23. Aug. 2007 (CEST)

Und sie bewegt sich doch, halte deinen Vorschlag für sinnvoll:

• Mit base=TA braucht es eigentlich 2 unterschiedliche Werte von output=, will man die momentane Formatierung von Vorlage:CH-Koordinate nachbilden (oder eine entsprechende Linearkombination von Werten im Parameter output). Ich würde aber dafür plädieren, a) für beide Ausgabetexte denselben Text zu erzeugen und b) in Spezialfällen über einen Parameterwert für output und intern unterschiedlichen Formaten für T und A zu arbeiten. (etwa für CH)
• Ein Weglassen von der Variante TA würde wieder Redundanz bedeuten, da diese Variante ja durch doppelte Koordinaten (einmal T, einmal A) erreicht werden könnte. Bevor diese Variante gestrichen wird, sollte also ihr Redundanzpotential überprüft werden. Ich würde sie nicht streichen, gerade im Kontext Infoboxen wird die Variante TA gerne (aber nicht generell) verwendet, ist aber dort auch ein lokales Problem der Programmierung der Infobox.
• Für Infoboxen i.A. ist die direkte Verwendung dieser Vorlage als Parameter nicht sinnvoll, sinnvoller wäre ein Aufruf der neuen Vorlage in der Programmierung der Infobox. Nicht alle Parameter der neuen Koordinatenvorlage sind an der Schnittstelle der Infobox relevant, z.B. ist für Berge oder Orte (und für die meisten anderen Infoboxen?) der Parameter type als Infobox-Parameter redundant, für die Positionskarten bräuchte man die Werte von EW und NS direkt, Höhe wird nicht nur in der Koordinate, sondern auch in der Infobox gebraucht, ... Ich habe keinen Durchblick, wie die automatische Auswertung mit geohack und verwandten Tools funktioniert, aber ich erinnere mich, gelesen zu haben, dass ihr von diesem Projekt alle verwendeten Koordinatenvorlagen kennen müsst, um sie richtig parsen zu können. Daher meine Bitte, bei der Gelegenheit der globalen Koordinatenumstellung in ziemlich vielen Artikeln eine gemeinsame Schnittstelle für Infoboxen zu definieren, wie die Parameter für die neue Vorlage durch Infoboxen durchgeschleust werden können. (Natürlich sollte es weiterhin möglich sein, die expandierte Vorlage als Parameter für die Infobox zu verwenden).
• Zu den Ausgabeformaten und der Genauigkeit: Was haltet ihr davon, die Ausgabegenauigkeit vom Parameter type einerseits und vom Parameter dim andererseits abhängig zu machen. Berge(gipfel) z.B. sind punktförmig, daher ist hier die maximale Genauigkeit nicht falsch (maximal wäre zu definieren, 10 Stellen (bei den Sekunden) wie in manchen CH-Artikeln sind sicher zuviel), bei Städten mit mehr als 100000 Einwohnern reichen vermutlich Minuten, bei landmarks, die sich über einen Umkreis von dim=10000 erstrecken (etwa Gletscher), vermutlich auch, usw.
• Was vielleicht noch fehlt, ist eine Angabe der Genauigkeit der Messdaten in der Vorlage. Es macht einen Unterschied ob die Daten auf Minuten oder auf 10000stel Sekunden ermittelt worden sind. Diese Genauigkeit ist für die Darstellung relevant, insbesondere wenn Umrechnungen im Spiel sind. Bei der CH-Koordinate ist mir schon aufgefallen, dass CH1903 Koordinaten auf km (600.000/200.000) für Bern auf hundertstel Sekunden in der Sexagesimaldarstellung umgerechnet werden.
• Wenn du Befürchtungen hegst, EW könnte mit Einwohner verwechselt werden, vielleicht hilft die Umbenennung von pop auf population an dieser Stelle?

--Herzi Pinki 23:21, 23. Aug. 2007 (CEST)

Zum Punkt Redundanz in Infoboxen: Man könnte die Infoboxen so umschreiben, dass die Parameter der Koordinate aus den Parametern der Infobox erzeugt werden, bspw.

{{Infobox|Hoehe=34|Einwohner=345153|Koordinate-Nord=54_34_34.65|Koordinate-Ost=5_24_67.43|...}}

oder ähnliches wird dann vorlagenintern eingebunden als

{{Koordinate|NS={{{Koordinate-Nord}}}|EW={{{Koordinate-Ost}}}|pop={{{Einwohner}}}|height={{{Hoehe}}}|...}}

und die Werte werden gleichzeitig auch in der Infobox formatiert dargestellt (kann man das Zahlenformat u.U. vielleicht irgendwie dann noch formatieren, dass zB die Einwohnerzahl durch Tausenderpunkte getrennt wird?) --Rohieb 会話 +/- 00:45, 24. Aug. 2007 (CEST)

@Rohieb: ist schon klar, dass das technisch so geht. Aber meine Anmerkung hat sich auf zu definierende Parameter über alle Infoboxen bezogen (z.B. Hoehe, das nicht einmal height, HEIGHT, Höhe, HOEHE, usw. heißen sollte), immer unter der Vorraussetzung, dass die Parameternamen geparst werden müssen. BTW, dein Beispiel mit Koordinate-Nord ist ungünstig, da ohne die Funktion substr() dieser String nicht in einen Dezimalwert umgerechnet werden kann. --Herzi Pinki 00:51, 24. Aug. 2007 (CEST)

@Rohieb: lieber wäre mir ein geschütztes schmales Leerzeichen. Des Deutschen Punkt ist des Briten Komma und des Schweizers Hochkomma. Das ist international nicht Kompatibel. CSS würde es erlauben dem &nbsp; eine angemessene Breite zu geben. Diese Vorlage bleibt aber von dieser Diskussion unberührt. Formatierung der Einzelwerte bleibt Aufgabe der Infoboxen-- visi-on 11:24, 24. Aug. 2007 (CEST)

Halte diesen Vorschlag auf den ersten Blick ebenfalls für sinnvoll, erfüllt sie doch einige meiner Anregungen von früher (v.a. key/values)... Für die Doku. nicht vergessen, was die Masseinheiten sind, indbes. für height und dim. -- Geonick 08:26, 24. Aug. 2007 (CEST)

Es bewegt sich nicht nur, es geht sogar in die richtige Richtung! :-) Der Vorschlag kommt doch CH-Koordinate sehr nahe. Bereiten mir nur noch die Regionen unbehagen. Die Kombination mit „/“ bleibt mit den derzeitigen Mitteln unauswertbar. -- visi-on 11:24, 24. Aug. 2007 (CEST)

Stimmt die Koordinaten für Punkte auf Ländergrenzen sind nicht eindeutig. Four Corners ist auch ein Beispiel. Dafür sollten wir noch eine Lösung finden. Am saubersten wäre ein optionales Feld wie hier

|region     = US-AZ
|region2    = US-CO 
|region3    = US-NM
|region4    = US-UT

Oder kann man das irgendwie innerhalb eines Feldes "region=" besser zerteilbar machen (, ; - ...)? -- sk 11:35, 24. Aug. 2007 (CEST)

ohne substring Funktion kommst du da nicht ran. -- visi-on 14:30, 24. Aug. 2007 (CEST)

Zusätzliche "regionX" machen aber sicherlich die Abfrage komplizierter, da ja nicht sicher ist ob z.B. CH in region3 oder region4 drin steht. Lösungsvorschläge? -- sk 14:50, 24. Aug. 2007 (CEST)

selbst wenn die Substr Funktion zur verfügung stehen würde, das Parsen wäre auch nicht ganz trivial. Es müssen in jedem Fall alle regionX ausgewertet werden. das gibt in der Tat etwas komplexerer Ausdrücke. Finden wir hier aber keine vertretbare Lösung, so fürchte ich, hat auch dieser Versuch der Vereinheitlichung kaum chancen sich durchzusetzen. Das würde ich persönlich sehr bedauern. Der regionX Ansatz ist bisher der beste Vorschlag. -- visi-on 15:13, 24. Aug. 2007 (CEST)

Sauberer in der Programmierung wäre aber schon nur einmal region einzubinden. Die paar Ausnahmefälle sollten wir verschmerzen können. Es trifft ja eigentlich nur Berge, Grenzposten etc. Ich würde aber vielleicht besser das Komma zur Trennung nehmen, da das besser lesbar ist.

|region     = US-AZ, US-CO, US-NM, US-UT    Komma und Leerzeichen
|region     = US-AZ,US-CO,US-NM,US-UT       nur Komma
|region     = US-AZ/US-CO/US-NM/US-UT       Schrägstrich

Was meint ihr dazu? Oder gibt es wichtige Gründe den Schrägstrich beizubehalten? -- sk 16:18, 24. Aug. 2007 (CEST)

Nur? Du machst vielleicht Scherze. Zeig doch mal auf wie du das Land extrahieren willst, sobald mehr als eine Region aufgezählt wird. Ich hätte da noch einen "besseren" Vorschlag:

|region     = US-AZ|US-CO|US-NM|US-UT       senkrechter Strich

Das ist doch fast wie bereits gehabt ;-) Ich weiss, ich bin ein Schelm -- visi-on 16:37, 24. Aug. 2007 (CEST)

Senkrechte Striche sind ganz schlecht, weil sie zum Abtrennen der einzelnen Vorlagenbereiche genutzt werden. Am besten finde ich die Kommas. -- sk 18:26, 24. Aug. 2007 (CEST)

Du denkst aber bitte daran, dass der senkrechte Strich als Trenner für Vorlagenparameter zählt? Wenn schon, geht nur {{!}} oder sonstwas. --Rohieb 会話 +/- 18:29, 24. Aug. 2007 (CEST)

Genau das war mein listiger Gedanke, das war sehr wohl bedacht: Ich habe die Regionen einzeln als Parameter und Stefan hat seine Aufzählung. -- visi-on 18:43, 24. Aug. 2007 (CEST)

Aber das geht wirklich nicht, dann haben wir ja wieder Werte, ohne Parameter "xyz=" und das wäre kontraproduktiv. Wie gesagt, auswerten kann ich alles, die Frage ist, was die Mediawiki-Software können soll. -- sk 18:54, 24. Aug. 2007 (CEST)

Dann also doch Variante regionX. Aus meiner Sicht verbauen wir uns zuviel wenn wir den regioncode nicht auswerten können.-- visi-on 20:35, 24. Aug. 2007 (CEST)

Wenn der Parameter region der letzte ist (erspart zusätzliche Plausibilitätsprüfugen), könnte mann da unter umständen schon eine Ausnahme(als Turn around bis die Funktion substr zur Verfügung steht) machen. -- visi-on 10:03, 25. Aug. 2007 (CEST)

Vierte Version - weitere Diskussion

{{Koordinate

|NS         = 50.3                        maximal x Nachkommastellen
|EW         = -12.2                       negativ ist Süd bzw. West
|type       = city                        landmark, city, airport
|pop        = 100000                      nur bei Orten Einwohnerzahl (Länder und Regionen denkbar) 
|height     = 8000                        nur bei Bergen Höhe
|dim        = 100                         Durchmesser Umkreis
|region     = DE-SN                       Region
|regionX    = DE-TH                       weitere Regionen (Objekte auf Grenzen) (X=2,3,4,..)
|base       = TA                          Standard A=Artikel, möglich A,TA=Text Artikel, T=Text
|output     = dec                         Ausgabeformat jedes denkbare möglich, UTM, GKK, GK, Zeilenumbruch
|outputtext = 41°-78° N, 58°O - 170°W      Alternative Ausgabetext der Koordinate
|name       = Eiffelturm                  Alternative Ausgabetext des Titels (nur bei Textkoordinate)
}}

output: regelt dieser Parameter nur die Darstellung der Textausgabe oder auch im Artikel? Ich meine die Artikel Ausgabe sollte standardisiert GMS sein, lokale Formate (zB CH) in Klammern. Im Artikel sollten auch nur zivil häufig benutzte Formate berücksichtigt werden, so wie das zB in der Schweiz oder Grossbritanien der Fall ist. Falls T und A Ausgabe gesteuert werden soll, sollten es zwei Parameter outputA und outputT geben. Alternativ könnte man aber auch an Stelle von base und output Parameter text und artikel nehmen. ist der entsprechende Parameter nicht abgefüllt, erfolgt am entsprechenden Ort keine Ausgabe, Inhalte steuern die Ausgabe. Sind text und artikel leer erfolgt Standard (GMS) Ausgabe Artikel. Fände ich sogar besser als base und output-- visi-on 10:03, 25. Aug. 2007 (CEST) outputtext: kann man das nicht weglassen?-- visi-on 17:16, 25. Aug. 2007 (CEST)

Ich hab mal eine neue Zwischenüberschrift eingeführt. Und noch mal die Vorlage eingefügt. Hmm, also output sollte eigentlich beide Darstellungen gleichermaßen steuern. Warum sollte man zwei verschiedene Darstellungen brauchen? Man könnte es aber ja auch so machen, dass die Artikelkoordinate immer als GMS ausgegeben wird und die Textkoordinate dann entsprechend der Vorgabe. - Der Vorschlag mit Parameter text und artikel führt doch aber wieder dahin, dass wir die Koordinate mehrmals eintippen müssen oder verstehe ich das falsch. Sie soll doch automatisch geschrieben werden und nur in sonderfällen durch den Parameter "outputtext" ersetzt werden. -- sk 17:38, 25. Aug. 2007 (CEST)

mein Vorschlag: die Parameter Artikel und Text steuern ob und wie die Ausgabe zu erfolgen hat. Wobei ich das Outputformat bei Artikel sehr standardisiert sehe. zB immer WGS84 in GMS. Lokale Formate höchstens zusätzlich und mit Name zB für die Schweiz CH1903:(600000/200000). Ich denke das Erscheinungsbild eines Artikels sollte in diesem Punkt nicht vom Autor abhängig sein. Das ist sozusagen eine Marke der Wikipedia. Im Fließtext entsprechend dem Kontext und was eben an Umrechnungen angeboten ist, auch in entsprechender Rundung (GMSss, GMSs, GMS, GM, G, DEC, DEC1, DEC2, CH1903). Zum das schön machen können hätte ich natürlich gerne die Region auswertbar zur Verfügung.

{{Koordinate
|Artikel    = GMS              (optional) Die Georeferenzierung des Artikel ist im GSM Format
                                          Leer bedeutet keine Ausgabe. (Text= ) -> Standardausgabe
|Text       = GMS/CH1903       (optional) Im Fließtext GMS plus Schweizer Landeskoordinaten
                                          Leer bedeutet keine Ausgabe
|name       = Eifelturm        (optional) Alternativer Ausgabetext
|NS         = 50.3                        maximal x Nachkommastellen
|EW         = -12.2                       negativ ist Süd bzw. West
|type       = city                        landmark, city, airport
|pop        = 100000                      nur bei Orten Einwohnerzahl (Länder und Regionen denkbar) 
|height     = 8000                        nur bei Bergen Höhe
|dim        = 100                         Durchmesser Umkreis
|region     = DE-SN                       Region
|region1    =                  (optional) Region1
|region2    =                  (optional) Region2
|region3    =                  (optional) Region3
}}

-- visi-on 18:13, 25. Aug. 2007 (CEST)

Also könnten ja standardmäßig die Parameter Artikel und Text weggelassen werden, weil ja in den meisten fällen der ganze Artikel referenziert wird. Nur bei Infoboxen oder Koordinaten im Fließtext müsste man diese Parameter einfügen. Den einzigten Fall, den dein Vorschlag jetzt nicht abdeckt ist eben die fragliche Ausgabe der Koordinate bei Ländern Russland, wo der Mittelpunkt des Landes genommen wird und dann seine Ausdehnung angegeben wird. Aber ich denke das ist verschmerzbar. Oder hat da jemand ein Problem mit? Bei en:Russia wird es ja auch nicht gebraucht. Weitere Verbesserungsvorschläge? -- sk 21:08, 25. Aug. 2007 (CEST)

ja, die optionalen Felder entfallen beim Standardaufruf. Height würde ich übrigens immer zulassen, denn jede Koordinate hat auch eine Höhe, stört ja nicht solange sie richtig ist, würde der alten Diskussion (landmark/mountain) bei Pässen auch ein Ende setzen. Man müsste einfach explizit vorschreiben, dass die Höhe an der Koordinate gilt. pop macht nur bei country, state, adm1st, adm2nd und city Sinn. Was du damit machst steht auf einem andern Blatt stören sollte es dich jedenfalls nicht. -- visi-on 23:37, 25. Aug. 2007 (CEST)

wieso dim ist doch drin, könnte man sogar für Standardrundung ranziehen. ich bin mir bei den doch sehr unterschiedlichen Ausdehnungen nicht so sicher ob hier Defaultwerte für die einzelnen Typen sinnvoll sind.

type:country, state         dim=1000 km round GM
type:state, adm1st, adm2nd  dim= 100 km round GM
type:city                   dim=  10 km round GMS
type:isle                   dim=  10 km round GMS
type:airport                dim=   5 km round GMS
type:mountain               dim=   1 km round GMSss
type:waterbody              dim=  10 km round GMS
type:landmark               dim=   1 km round GMSss

kann man machen aber ob wir uns da einig werden? Zu bedenken gebe ich, dass das auch zusätzlich zu wartenden Code gibt. Reicht, wenn wir abhängig von dim die Ausgabe runden. Das erwähnte Beispiel Bern (600000/200000) ist ein schlechtes Beispiel, denn diese Koordinate ist per Definition milimetergenau. Um der Fehlerrechnung genüge zu tun, müssten wir zusätzlich die Quelle (machen wir im Wiki doch immer, Ehrensache) und deren Genauigkeit angeben. zB source=swisstopo/CH1903 oder Brockhaus/GM ... Stefan diese Anforderung müsstest aber von dir kommen. -- visi-on 23:37, 25. Aug. 2007 (CEST)

Ich bin dagegen jedes Ausgabeformat in die Vorlage pressen zu wollen, das wird wohl, (wenn man es nicht schafft das in Untervorlagen auszulagern), ein unsägliche Vorlagenmonster zur Beschäftigung unserer Server. Von der Notwendigkeit überzeugen lassen würde ich mich nur von Geonick, da er ein Schweizer und ein Fachmann ist. Schließlich beherrscht der Geohack die Umrechnung in CH-Koordinaten. --Kolossos 23:48, 25. Aug. 2007 (CEST)

Welche Obervorlage soll dann diese Untervorlage aufrufen, wenn nicht diese? Hat irgend wer behauptet die Outputformatierungen sollen alle direkt in dieser Vorlage vorgenommen werden? Ich gehe davon aus, dass auch dir der Trick bekannt ist wie man unnötige Vorlageexpansionen unterbindet, indem man diese Vorlagen variabel einbindet. Also keine Sorge, die Umrechnung in Schweizer Landeskoordinaten wird nicht weltweit eingebunden und die paar Schweizer Koordinaten verkraftet das System bereits heute. -- visi-on 01:27, 26. Aug. 2007 (CEST)

die Output Formatierung

sorry, hatte ich vorausgesetzt:

{{WGS84 to XYZ                            XYZ: das Zielformat (zB. GMS)
|NS         = 50.3                        maximal x Nachkommastellen
|EW         = -12.2                       negativ ist Süd bzw. West
|dim        = 100                         Der Durchmesser Umkreis steuert die Rundung
}}

-- visi-on 01:38, 26. Aug. 2007 (CEST)

Den Defaultwerte für die einzelnen Typen können wir uns sparen. Es gibt Länder (Luxemburg), die sind kleiner als manche Orte (Mexiko-City). Ich glaub da kommen wir ohne vorgaben auch gut weiter. Wer es genauer haben möchte muss halt dim eingeben. - Noch mal zu den Output-Formatierungen. Ich bin mir nicht sicher, aber so viele sollten das doch nicht werden. Lasst uns doch mal alle bekannten zusammentragen. Also G,GM,GSM, UTM-Koordinate, GAUS-Krüger (falls das mal einer braucht), die Schweizer Koordinaten und das englischen Koordinatensystem. Das wären alle, die mir als Ausgabeformat einfallen. Jetzt würde nur noch Kombinationen (wie bei Schweiz) oder Zeilenumbrüche dazukommen. Weitere? -- sk 09:40, 26. Aug. 2007 (CEST)

ja, Stereographische Projektion (UPS)-- visi-on 17:46, 27. Aug. 2007 (CEST)

noch eines: DEC -- visi-on 13:02, 29. Aug. 2007 (CEST)

Zeilenumbruch? Mach mal Beispiel wo das gebraucht wird und &nbsp; nicht ausreicht.-- visi-on 22:40, 27. Aug. 2007 (CEST)

G, GM, GMS sind aber nur verschiedene Rundungen des gleichen Formats. Runden über die Dimensionsangabe hat nur einen Hacken, eine Bogensekunde ist nicht überall gleich weit. Um der Allgemeinheit genügen zu können müssten wir da schon auf den Äquator abstellen. Ich mache es mir mal einfach und rechne (mit 10%Fehler) in Neugrad und dann entspricht 1 Grad etwa 100 km (UTM: 6° ≈ 800km). UTM, Gauss und CH1903 immer auf Meter gerundet.

dim	format
>500-1000km	G
>10-20km	GM
default, kombiniert	GMS (UTM, UPS, GAUSS, CH1903, OSGB36)

obige Tabelle gibt ungefähr wieder, wo ich die Grenzwerte in etwa sehe.-- visi-on 17:46, 27. Aug. 2007 (CEST)

Formatmatrix

	kein	DMS	UPS	UTM	Gauss	CH1903	OSGB36	Zusatzformat
DMS	TA		T	T	T	TA	TA
DEC	T	(T)
UPS	T	T
UTM	T	T
Gauss	T	T
CH1903	T	T
OSGB36	T	T
Hauptformat

-- visi-on 20:06, 27. Aug. 2007 (CEST)

Also bei den Infoboxen z.B:Flughafen Dresden wird häufig mit einem Zeilenumbruch gearbeitet, um die Spalte möglichst schmall zu halten. Kannst du mir mal ein Beispiel für UPS nennen? Mir fällt auf anhieb nix ein, wo wir sowas derzeit nutzen. - Mir fällt gerade noch was ein. Die Parameter "Text" und "Artikel" könnte man doch auch problemlos für Sonderfälle nutzen. Wenn also in einem Text nur "Lage" stehen soll (Bsp. Pesterwitz), dann gibt man statt GMS dort in das Feld entsprechend die gewünschte Ausgabe ein. Ich glaube das wäre die eleganteste Lösung. --sk 10:07, 28. Aug. 2007 (CEST)

Für Infoboxen ist es wichtig, dass gezielt mit geschützten und ungeschützten Leerzeichen gearbeitet wird. Dann bricht die Zeile am richtigen Ort um, sobald die Spalte zu schmal wird.-- visi-on 11:33, 28. Aug. 2007 (CEST)

Ich mach nur ungern das Tor für beliebigen Text auf. Denn wozu machen wir uns jetzt, mit der Erweiterbarkeit, die Mühe? Defaultwert "Lage" im Parameter Text ist aber ok. Ein sanfter Widerstand der Beliebigkeit kann nicht schaden. Wir sollten dann aber Erweiterungswünschen gegenüber offen sein. Bei Gauss-Krüger Frage ich mich auch, ob es sein muss, aber wenn einer die Formatierungsvorlage liefert, tut es wohl kaum weh. Es gibt auch keinen Zwang UPS bereits in vorauseilendem gehorsam zu implementieren. Bei OSGB36 ist auch noch die Frage wer die Umwandlung implementiert. Überlassen wir das den Briten? Es bleibt auf jedenfall, wie du darauf ingewiesen hast, eine überschaubare Menge von Formaten, sofern man sich auf die im öffentlichen Leben relevanten beschränkt. Relevanzkriterium: in welchem Format teile ich einem Rettungsdienst meine Koordinaten mit, wenn ich Hilfe brauche.-- visi-on 11:33, 28. Aug. 2007 (CEST)

Ok, das mit den Leerzeichen hast du richtig erkannt, dass sollte ausreichen. Allerdings, könnten auch einige speziell den Umbruch haben, egal wie breit die Spalte ist. Ich mach jetzt mal den Praxistest, damit wir sehen, ob wir soweit alles hinbekommen. Bei dem beliebigen Text würde ich durchaus flexibel bleiben, das stört ja niemanden.

{{Koordinate |NS=50.3|EW=-12.2 |type=city|pop=100000|region=DE-SN}}	50° 30' 0" N, 12° 12' 0" W	Koordinate oben rechts im Artikel
{{Koordinate |NS=50.3|EW=-12.2 |type=city|pop=100000|region=DE-SN |text=DMS}}	50° 30' 0" N, 12° 12' 0" W	Koordinate nur im Text
{{Koordinate |NS=50.3|EW=-12.2 |type=city|pop=100000|region=DE-SN |text=DMS|article=DMS}}	50° 30' 0" N, 12° 12' 0" W	Koordinate im Text und oben rechts
{{Koordinate |NS=50.3|EW=-12.2 |type=city|pop=100000|region=DE-SN |text=Lage|name=Wrack der Titanic}}	50° 30' 0" N, 12° 12' 0" W	Link "Lage" im Text, zusätzlicher Info "Wrack der Titanic"
{{Koordinate |text=CH1903|article=CH1903 |NS=47.372577|WE=8.687162 |type=landmark|region=CH-ZH|dim=500 |name=Bluetmatt}}	47° 22' 21.28" N, 8° 41' 13.78" E CH1903: (694296/247610)	Lemma: Mord von Greifensee, Koordinate oben rechts im Artikel: 47° 22' 21.28" N, 8° 41' 13.78" E CH1903: (694296/247610) Koordinate im Text: (694296/247610) zusätzliche Info: "Bluetmatt"

Hab ich das jetzt richtig aufgedröselt? Oder fehlt uns noch was? -- sk 14:40, 28. Aug. 2007 (CEST)

Zeit für Zusammenfassung und schauen was die andern meinen.

Offene Punkte sind noch: Schwellenwerte von dim für die Rundung, regionX ja/nein

freie Texteingabe ungern aber daran soll es nicht liegen. An regionX ist mir sehr gelegen.-- visi-on 20:40, 28. Aug. 2007 (CEST)

regionX fänd ich auch sehr gut. Wie ich das jetzt verstanden habe, sollte die Rundung ja nur in der Ausgabe stattfinden und sich nicht in der Koordinate im KML (oder sonstwo) niederschlagen. Dann wäre ich für die oben von Visi-on vorgeschlagenen Grenzen. Allerdings halte ich es auch noch für wichtig, dass Zehntel- oder Hundertstelsekunden, wenn benötigt, auftauchen (zB wenn man ziemlich kleine Objekte referenzieren will, Bushaltestellen oder so ;-) ) --Rohieb 会話 +/- 23:03, 28. Aug. 2007 (CEST)

das ist in der Dezimaldarstellung bei 6 Stellen nach dem Komma der Fall (auf einen Meter). Aber bitte nur so viele Stellen angeben wie bekannt sind. für zehntel Sekunden müsste man einen weiteren Schwellenwert festlegen (zB dim <= 200m). Nur für Objekte die kleiner sind als 20m würden sich Hundertstel aufdrängen. Man bedenke aber, dass dann auch der Kartenausschnitt sehr klein wird.

dim (Meter)	format
> 500000	D
> 10000	DM
> 200, default, kombiniert	DMS (UTM, UPS, GAUSS, CH1903, OSGB36)
> 20, kombiniert	DMSd (UTM, UPS, GAUSS, CH1903, OSGB36)
<=20, kombiniert	DMSdc (UTM, UPS, GAUSS, CH1903, OSGB36)

-- visi-on 13:31, 29. Aug. 2007 (CEST)

So ich glaub wir haben hier fast alles zusammen. Ich schlage vor, eine neue Unterseite Wikipedia:WikiProjekt Georeferenzierung/Neue_Koordinatenvorlage anzulegen und dort alles nochmal zusammenzutragen. Dort können wir das ordentlich alles auseinanderpflücken und interessierten Lesern Vor- und Nachteile erklären. Bevor ein Bot startet sollte die Community unbedingt in den Prozess mit eingebunden werden. Quasie erst haben sich die Fachidioten was ausgedacht und dann muss das Volk noch überlegen, ob was übersehen wurde. -- sk 13:46, 29. Aug. 2007 (CEST)

einverstanden. Wir haben hier geschlossen.-- visi-on 14:00, 29. Aug. 2007 (CEST)

Weitere Diskussion ausgelagert

Bitte unter Neue Koordinatenvorlage weiter diskutieren. -- sk 15:57, 29. Aug. 2007 (CEST)

Die Diskussion nähert sich dem Abschluss. Einführung? -- visi-on 17:27, 27. Nov. 2007 (CET)

Meinungsbild in Vorbereitung.-- visi-on 21:50, 11. Dez. 2007 (CET)