Wikipedia Diskussion:WikiProjekt Georeferenzierung

Archiv

Zur Archivübersicht

Wie wird ein Archiv angelegt?

Bevor du eine Frage stellst, solltest du bitte erst im passenden Archiv nachschauen, evtl. gibt es dort bereits eine Antwort.
Ältere Diskussionen bis Mai 2007 sind dort thematisch sortiert einsehbar. Seit Mai 2007 werden Beiträge automatisch archiviert.

Automatische Archivierung

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 7 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind.

Vorlage:Autoarchiv-Erledigt/Wartung/Festes_Ziel

weiterschaltbare mehrfachkarte PositionskarteX ISO

Hallo, habe eine neue Vorlage gebaut, die auf PositionskarteX (+) aufbauend und unter Auswertung des ISO-Codes einfach so eine weiterschaltbare Karte erzeugt. Dabei kommt sie ohne zentrale Definition der Karten a la Vorlage:PositionskarteX FR-29 aus. Beispiele hier und Diskussion dort (einstweilen noch alles im BNR, Feedback trotzdem willkommen.). lg --Herzi Pinki 15:54, 26. Jan. 2011 (CET)

Vorlage:Lagewunsch noch sinnvoll?

Hallo, ist die Verwendung einer separaten Vorlage:Lagewunsch überhaupt noch sinnvoll? Die gesamte Vorlage besteht ja ausschließlich aus der Einbindung der Vorlage:Coordinate und ist daher meiner Ansicht nach überflüssig. Die paar Verwendungen könnte ich mit dem Bot in ein paar Minuten substen, sodass auch hier kein Problem entstehen dürfte. Damit hätte man die Vorlage Coordinate als einzige und generelle Vorlage für Koordinaten und könnte die Vorlage Lagewunsch löschen. Grüße --Carport ^{(Disk. • ± • MP)} 15:35, 31. Jan. 2011 (CET)

Klingt für mich sinnvoll. --Spischot 16:09, 31. Jan. 2011 (CET)

Bin da neutral, allerdings finde ich es lustig, dass so viele Begriffe von englisch auf deutsch übersetzt werden, wie beim Bilder einbinden, auch wenn es doppelt so viel Schreibarbeit ist - da wär es dann umgekehrt ;-) --K@rl (Verbessern ist besser als löschen) 18:27, 31. Jan. 2011 (CET)

ach ich ging da abundzu die Einbindungen durch, ergänzte den ISO-Region-Code und substituierte ...

War auch noch ein kleines Zugeständnis an die man spricht Deutsch Fraktion. Kann man löschen tut aber auch nicht weh. -- visi-on 23:04, 1. Feb. 2011 (CET)

Nachdem keiner was dagegen hat, sollten wir das auch zuende bringen. @Carport: Steht dein Angebot zum substen noch? Abschließen bitter noch LA auf {{Lagewunsch}}, sonst kommt das Zeug immer wieder hoch. Ich habe {{Lagewunsch}} schon mal als veraltet gekennzeichnet und die Dokumentation Vorlage:Coordinate#Lagewunsch entsprechend angepasst. --Spischot 09:28, 7. Aug. 2011 (CEST)

Sorry dass ich mich erst jetzt melde, bin nach einer langen Wikipause heute zurück. Ja, das Angebot steht noch, der Bot könnte sofort drüberlaufen sobald es gewünscht ist. Grüße --Carport ^{(Disk. • ± • MP)} 11:23, 18. Aug. 2011 (CEST)

In meinen Augen auch überflüssig. Jedoch wird die Vorlage täglich in Artikel eingebunden und sollte daher zumindest als Weiterleitung auf Vorlage:Coordinate bestehen bleiben. --тнояsтеn ⇔ 12:32, 18. Aug. 2011 (CEST)

Deswegen würde ich ja auch alle Einbindungen mit dem Bot substen, sodass stattdessen die Vorlage Coordinate verwendet wird. --Carport ^{(Disk. • ± • MP)} 12:41, 18. Aug. 2011 (CEST)

Was ich meine: viele Nutzer kennen nur die Vorlage:Lagewunsch und binden diese in Artikel ein. Das sind geschätzt 5-10 neue Artikel pro Tag. Wird die Vorlage:Lagewunsch gelöscht, dann wissen diese Benutzer erstmal nicht, was das Problem ist. --тнояsтеn ⇔ 12:48, 18. Aug. 2011 (CEST)

Diejenigen, die die Vorlage tatsächlich noch einbinden, werden ja (nach der Löschung) beim Einbinden sehen, dass die Vorlage nicht mehr existiert, auf den Rotlink klicken und dort sehen, dass die Vorlage durch die Vorlage Coordinate ersetzt wurde. Das hat ja bei anderen Vorlagen bisher auch geklappt. Grüße --Carport ^{(Disk. • ± • MP)} 12:58, 18. Aug. 2011 (CEST)

Wenns in der Praxis klappt, soll es mir recht sein. --тнояsтеn ⇔ 13:14, 18. Aug. 2011 (CEST)

So, der Bot läuft jetzt gerade (~50 Verwendungen), um den restlichen Kram kümmere ich mich dann später. Grüße --Carport ^{(Disk. • ± • MP)} 13:50, 18. Aug. 2011 (CEST)

Ich finde diese Vorlage sinnvoll, (a) weil deutsch benannt und (b) weil übersichtlicher und einfacher in der Anwendung. Von der Doku bei {{Coordinate}} wird man erst mal erschlagen. Ich sehe auch nicht, welcher Nachteil durch die Existenz und Verwendung von {{Lagewunsch}} entstehen sollte. Klar behalten. --PM3 17:17, 18. Aug. 2011 (CEST)

Mein Vorschlag: Vorlage:CoordinateNO (bzw. ihren Nachfolger) auf Vorlage:CoordinateWunsch verschieben. Diese Vorlage ließe sich dann als Lagewunsch direkt einbinden und würde so eine ganze Vorlagenkaskade (Lagewunsch→Coordinate→CoordinateFull→CoordinateNO) ersetzen. Einziger Nachteil wäre, dass sie sich die Einbindung nicht automatisch an den NR anpasst (die Ausgabe natürlich schon, aber wenn ein Bot (etc) nach Wartungseinbinungen der CoordinateNO statt -NOx suchen kommen nun auch BNR-Artikel dran). Vorlage:Lagewunsch würde dann zum einfachen Redirect, um die Abwärtskompatibilität zu erhalten. --✓ ^Bergi 17:30, 19. Aug. 2011 (CEST)

Geht nicht, Vorlage:Lagewunsch hat eine andere Parametersyntax. Stattdessen könnte man CoordinateNO(x) in Vorlage:Lagewunsch per #if:{{NAMESPACE}} einbinden, oder wahlweise CoordinateSimple statt Coordinate. Aber so viel Unterschied würde das alles nicht machen; es gibt eh keine Performanceprobleme mit Vorlage:Lagewunsch. --PM3 22:03, 19. Aug. 2011 (CEST)

1. Ich benutze auch immer gerne Lagewunsch, weil ich das fast immer manuell tippe und ich die ganzen Parameter nicht aus den Kopf weiß.
2. an der Einbindungsliste von CoordinateNO hängen die ganzen Botscripte zur Identifiziertung der Lagewünsche (und nicht an den erzeugten Kategorien). Die Vorlage existiert auch nur wegen der Bots und Tools. Ein Verschieben der Vorlage bräuchte eine größere Änderung meiner Botscripte, die ich im Moment aus Zeitgründen nicht leisten kann. Bitte lasst die Vorlage dort mit dieser Bedeutung zur automatischen Auswertung. Die Unterschieung nach NO/NOx wurde übrigens eingebaut, damit ich nicht für Lagewunsch eine extra Namenraumbehandlung einbauen muss. Der BNR wird eh ignoriert, aber der VNR macht sonst Probleme, weil ich die anderen Bausteine dort melde.

Eine technische Vereinfachung für den Parser um von Lagewunsch nach CoordinateNO zu gelangen wäre mir natürlich egal. Merlissimo 22:23, 19. Aug. 2011 (CEST)

Vorlage:Infobox Erdbeben

Macht es in der Vorlage für Erdbeben Sinn, die Tiefe des Epienzentrums als Parameter elevation einzubauen? .-91.22.200.127 20:08, 16. Feb. 2011 (CET)

Nein und nein. elevation wäre der einzige englische Parametername. Und den Parameter Tiefe gibt es schon. Uwe Dedering 20:58, 16. Feb. 2011 (CET)

Sorry, falsch ausgedrückt. Der Parameter Tiefe der Erdbebenvorlage wird an die Coordinate-Vorlage weitergegeben (dort als Parameter elevation mit negativem Wert). Das meinte ich, sind dort negative Parameter gewünscht? Es kommt dann auch wieder zum allseits bekannten "von-bis-Problem", wie etwa in Iwate-Erdbeben 2008. --91.22.200.127 21:08, 16. Feb. 2011 (CET)

Die Höhenangabe beim Objekttyp landmark hat nur eine einzige Verwendung, und zwar wird sie in die Geo-Microformat-Tags geschrieben, von denen ich den Verdacht habe, dass sie gar nicht funktionieren.

Negative Werte sollten aber grundsätzlich ok sein, es gibt ja auch Stellen über der Erdoberfläche, die unter Meeresspiegel liegen. --PM3 04:39, 1. Aug. 2011 (CEST)

"Add-Tags":ein neues Werkzeug zur Verbindung Wikipedia-OpenStreetMap

Unter folgender Adresse gibt es ein neues Tool um verstärkt Wikipedia-Tags in die OpenStreetMap Datenbank einzupflegen und so die Verbindung beider Projekte voranzutreiben:

http://wiki.openstreetmap.org/wiki/JOSM/Plugins/RemoteControl/Add-tags

Später können wir dann wieder auf diese Einträge zugreifen und so auch Linien- und Flächenobjekte auf unserer OSM-Karte darstellen die in die Artikel integriert ist. Ganz nebenbei werden auch die als Interwikilinks hinterlegten Daten als Übersetzungen des Name-Tags übernommen. Startpunkt ist eine Catscan-Abfrage und eine Abfrage von OpenStreetMap-Objekten. Die Objekte werden dann versucht zu verknüpfen. Kontrolle ist dann in JOSM möglich. Dieser muss momentan scheinbar in der latest Version anstatt der stable Version laufen. Für Fragen, insbesondere zur Erstellung der passenden Abfragekriterien, stehe ich gerne zur Verfügung. --Kolossos 10:44, 9. Apr. 2011 (CEST)

Asiatischer Teil Ägyptens

Mir missfällt, dass zB bei Dahab die Positionskarteneinbindung per {{Coordinate}} die Asienkarte ausspuckt, nicht die Ägyptenkarte, auch trotz maplevel=national:

28.49305555555634.504722222222

Dahab​

Muss das sein? Könnte das wer ausbessern?… «« Man77 »» 23:33, 11. Apr. 2011 (CEST)

Kenn mich zu wenig aus, um es zu reparieren, aber es liegt an region=EG-JS. Allein mit region=EG geht es auch standardmäßig (ohne maplevel):

28.49305555555634.504722222222

Dahab​

--тнояsтеn ⇔ 19:06, 12. Apr. 2011 (CEST)

"Schuld" ist wahrscheinlich, dass EG als Afrika definiert ist, obwohl Teile nicht afrikanisch sind. Die Vorlage ist mir zu komplex, um da irgendwas rumzuschrauben, aber in meinen Augen ist das ein Manko, das in Richtung Bug geht. … «« Man77 »» 08:02, 13. Apr. 2011 (CEST)

Ja, schuld ist die Verteilung auf unterschiedlichen Kontinenten. Die Logik ist derzeit so, dass bei nationalem Kartenlevel (selbst wenn maplevel=adm1st gewählt ist, merkt die Vorlage dass die in Info ISO-3166-2:EG-JS eingetragenen Karte eine nationale ist) die Kontinentkarte genommen wird, wenn Region und Land auf unterschiedlichen Kontinenten liegen. Das dürfte eine Lösung für Kolonien etc. sein, damit pazifische Inselgruppen ohne eigene Poskarte keine Karte eines europäischen Landes bekommen. Umgehen wird man das bald (mit der neuen Vorlage) per mapname=Ägpten können, ist natürlich auch nur ein Workaround; ein anderer Trick wäre region=EG/EG-JS (die Karte wird nur nach dem ersten ausgesucht).

Wie könnte man die Logik denn am besten ändern? Die Wahl passiert in der Vorlage:Coordinate/Test/MAP/name, befüllt werden die Parameter in Vorlage:Coordinate/Test/MAP. --✓ ^Bergi 21:20, 3. Aug. 2011 (CEST)

In dem betreffenden Artikel wurde das Problem per region=EG/EG-JS gelöst [1]. --PM3 21:24, 3. Aug. 2011 (CEST)

Die Logik könnte man vielleicht sogar rauswerfen. Eine Auflistung von Codes, bei denen sie zur Anwendung kommt, ist unter Spezial:Linkliste/Vorlage:Info ISO-3166-2/Info/own continent without own map verfügbar. Oft wird das Problem durch {{Positionkarte ISO-3166-2}}, durch spezifische Einbindung der Vorlage:Positionskarte oder gleich eine Bild-Karte statt Poskarte umgangen. Ich habe jetzt jedoch noch keinen der Fälle angesehen, bei denen es benötigt wird. --✓ ^Bergi 15:39, 4. Aug. 2011 (CEST)

Bilder mit identischen Koordinaten

Das Tool von Kolossos ist beeindruckend, alle Commons-Bilder auf einer Karte anzuzeigen! Ich versuche, Tags nachzutragen, wobei ich Positionsfehler von eigen 100m in Kauf nehme. Frage: Wenn ich mehreren Bildern dieselbe Koordinate zuordne, lassen sie sich alle auf toolserver.org/~kolossos/openlayers/commons-on-osm.php abrufen, oder nur das erste? Vermip 13:01, 15. Mai 2011 (CEST)

Leider immer nur eines. Beim Einbinden in Google Maps ist über die Karte auch immer nur ein Bild an der selben Koordinate aufrufbar, über die Spalte links sind allerdings alle sichtbar ([2]). --тнояsтеn ⇔ 13:30, 15. Mai 2011 (CEST)

Danke für die Antwort (beim Nach-Taggen werde ich mich auf das schönste Foto geschränken...). Den Weg über Google kannte ich noch nicht. Vermip 15:16, 15. Mai 2011 (CEST)

Nun ja, vielleicht gibt es noch einen anderen Weg. Prinzipiell sollten alle Fotos georeferenziert werden können ohne Rücksicht auf die Auswertung der Daten. --тнояsтеn ⇔ 15:33, 15. Mai 2011 (CEST)

Ähm, der erwähnte Dienst.. zeigt der nicht die Bilder zu georeferenzierten Artikeln? Da haben die Geo-Tags auf Commons doch gar keinen Einfluss. --alexrk 18:15, 15. Mai 2011 (CEST)

Nee, Bilder von Commons: http://toolserver.org/~kolossos/openlayers/commons-on-osm.php --тнояsтеn ⇔ 19:57, 15. Mai 2011 (CEST)

Vorlage:All Coordinates für OSM

Zur Info: Wikipedia:WikiProjekt Vorlagen/Werkstatt#Testversion von Vorlage:All_Coordinates. --тнояsтеn ⇔ 22:31, 19. Mai 2011 (CEST)

Bzw. jetzt: Benutzer:Plenz/OSM for Wiki. --тнояsтеn ⇔ 09:23, 20. Mai 2011 (CEST)

Gerade wollte ich danach fragen: warum zeigt die Vorlage {Linked Coordinates} nur Artikel bei Google an? -- und entdecke hier den Hinweis.
Wird diese Vorlage nun auf OSM umgestellt?
Mit der linken Auflistung der Quellen ließen sich auch Bilder mit identischen Koordinaten darstellen (s.a. Wikipedia_Diskussion:WikiProjekt_Georeferenzierung#Bilder_mit_identischen_Koordinaten). Vermip 22:04, 23. Mai 2011 (CEST)

[GeoHack] USGS - The National Map 2.0

Hallo, bitte um freundliche Beachtung der Diskussion: Wikipedia_Diskussion:Kartenwerkstatt#PDF-Karten_der_USA ...es geht um die Einbindung von USGS-Karten in die Wikipedia. mE sollte das über den GeoHack laufen - es gibt neuerdings auch einen Webmap-Viewer für die neue National Map. Wäre wohl gut, den auf der GeoHack-Seite mit einzubinden (Beispiel-Link). --alexrk 16:10, 1. Jul. 2011 (CEST)

Fehlende region-Prüfung in Vorlage:Coordinate

Die Vorlage prüft bislang nur, ob region vorhanden ist, aber nicht, was drinsteht. Vermutlich haben wir jede Menge Artikel mit unerkannten Region-Fehlern.

Ich schlage vor, eine (vorerst) stille Prüfung in Vorlage:Coordinate einzubauen, die diese Fehler in Kategorie:Parameterfehler unter Buchstabe R einsortiert:

 {{#if: {{NAMESPACE}} 
   ||{{#if: {{Info ISO-3166-2:{{{region|}}}}} 
     |[[Kategorie:Parameterfehler|R{{FULLPAGENAME}}]]}} 
 }}

Kostet grob gepeilt 10 ms Performance, ich denke das ist verkraftbar. Vielleicht auch erst mal nur testweise, um zu schauen was es an Fehlern gibt, und um die einmalig abzuarbeiten. --PM3 01:20, 15. Jul. 2011 (CEST)

Damit wirst du laut meiner Glaskugel 647 Fehlermeldungen in 374 Artikeln erhalten. Du willst vermutlich gerne solche Fehler, wie in Liste europäischer Leuchttürme finden, wo BU statt BG für Bulgarien benutzt wurde oder Dampier-Archipel mit AZ-WA. Diese Art von Fehler entdeckte ich aber auf den ersten Blick kaum. Etwas häufiger kommt ein angehängter Bindestrich wie bei FR- in Schlacht bei Montmirail vor. Bei ein paar weiteren ist der region-Paramter mit einem Leerstring versehen.

Der weitaus überwiegende Teil enthält aber mehrere aneinandergereihte Regioncodes, die aber natürlich so als Vorlagenname nicht existieren, wie in Liste der Pässe in der Schweiz (CH-UR/CH-VS), CERN, Neuengland (US-CT/US-NH/US-ME/US-MA/US-RI/US-VT) oder Südamerika (AR/BO/BR/CL/CO/EC/PE/GF/GY/PY/SR/UY/VE).

Die ersten drei Fehlervarianten aus dem ersten Absatz habe ich in einer Liste zusammengestellt (jeder falsche Region-Code wird pro Artikel nur einmal aufgeführt). Vorlagendaten stammen aus dem templatetiger-Scan von 21.6. und die iso-Vorlagennamen von heute:

1. A.S. Création ()
2. Agennix ()
3. Andikythira (GR-A4)
4. Úpa (CZ-HK)
5. Barra do Garças (BRA-MT)
6. Bartlett Lake ()
7. Božena Němcová (CZ-KH)
8. Borgdorfer See ()
9. Dampier-Archipel (AZ-WA)
10. Duke-of-York-Inseln (PG-)
11. Emil Nolde (DK-)
12. Europaradwanderweg R1 (BE-)
13. Europaradwanderweg R1 (DE-)
14. Europaradwanderweg R1 (EE-)
15. Europaradwanderweg R1 (FR-)
16. Europaradwanderweg R1 (NL-)
17. Europaradwanderweg R1 (PL-)
18. Europaradwanderweg R1 (RU-)
19. Goodwin Sands (UK)
20. Guatemala-Stadt (GT-)
21. Isar (AT-TI)
22. Juan de Nova (TF-05)
23. Kythira (GR-A4)
24. Liste der Einschlagkrater der Erde (TD-BET)
25. Liste der Einschlagkrater der Erde (ZA-GT)
26. Liste der Tuamotu-Inseln (PF-TG)
27. Liste europäischer Leuchttürme (BU)
28. Liwa-Oase (AE-ZA)
29. Mangyŏngdae (KP-PYO)
30. Marklo (NL-OI)
31. Martim Vaz (BR-)
32. Nördlichste Orte der Erde (GL-01)
33. Ostseewelle ()
34. Pferdebahn Prag–Lana (CZ-SR)
35. Philadelphia Naval Shipyard ()
36. Primacom ()
37. Prutz (AT-TI)
38. PSI AG ()
39. Rücker AG ()
40. Rjukan (NO-TE)
41. Schlacht bei Montmirail (FR-)
42. Schloss Ratibořice (CZ-KH)
43. Sinan (BA-MO)
44. Solo Kleinmotoren ()
45. Stóragjá (IS-)
46. Storey County (US-)
47. Turracher Höhe (AT-K)
48. Tuvalu (TV-NIU)

Merlissimo 02:43, 15. Jul. 2011 (CEST)

Interessant, danke.

Verstehe ich Deine Antwort richtig: Es gibt Tools, mit denen man bestimmte Fehler bereits raussuchen kann, wenn man weiß, wonach man suchen muss? Oder gibt es bereits ein Tool, das alle Fehler auswirft, und das man irgendwie unter WP:GEO#To-do-Liste bereitstellen könnte? --PM3 03:30, 15. Jul. 2011 (CEST)

Ich bin der Meinung, dass man Fehler auch anders suchen kann, z. B. mit der Vorlagenauswertung (leider keine Life-Daten). Und die Leute können auch einfall auf die Koordinaten klicken und merken ja dann, ob Sie an der richtigen Stelle der Karte raus kommen. Die Performance sollte jedenfalls nicht damit übermäßig belastet werden. --Kolossos 16:32, 15. Jul. 2011 (CEST)

Wie gesagt: 10 Millisekunden pro Einbindung der vollständigen Vorlage:Coordinate. Auf die Kartenposition hat region allerdings keinen Einfluss. Geohack zeigt es nur an, ohne weitere Verwendung; von daher ist es die 10 ms wohl nicht wert. --PM3 17:26, 15. Jul. 2011 (CEST)

@Kolossos Die Liste basiert wie oben beschrieben auf den Daten deiner Vorlagenauswertung.

@PM3 Ich habe einfach mit mysql auf dem TS rumgespielt. Mein bash-Script für die Ausgabe oben:

MYTEMPFILE=`mktemp -t Coordinate.XXXX`
mysql -wBN -hdewiki-p.rrdb -e "SELECT SUBSTRING_INDEX(page_title,':',-1) FROM page WHERE page_namespace=10 AND page_title LIKE 'Info_ISO-3166-2:%'" dewiki_p > ${MYTEMPFILE}
SQL="
CREATE DATABASE IF NOT EXISTS u_%USER%;
USE u_%USER%;

CREATE TEMPORARY TABLE codes (codes VARCHAR(10) PRIMARY KEY);
LOAD DATA LOCAL INFILE '%TEMPFILE%' INTO TABLE codes; 

SELECT CONCAT('# [[',name,']] (',Value,')')
 FROM u_kolossos_tt_p.dewiki
 WHERE tp_name = 'Coordinate' AND entry_name='region'
  AND Value not in (SELECT codes FROM u_merl.codes) AND Value NOT LIKE '%/%'
 GROUP BY name, Value
"
SQL=`echo "$SQL" | sed "s/%USER%/$USER/g"`
SQL=`echo "$SQL" | sed "s|%TEMPFILE%|${MYTEMPFILE}|g"`
mysql -wBN -hsql -e "$SQL"

Merlissimo 20:27, 15. Jul. 2011 (CEST)

Aber hallo, ganz neue Fehler

• Fehler in der region von Artikelkoordinaten werden über http://de.wikipedia.org/wiki/Spezial:Linkliste/Vorlage:Info_ISO-3166-2:%3F%3F gefunden, für text koordinaten ist diese Prüfung nicht eingeschaltet worden, aber wie man an der obigen Liste sieht, macht Prüfung Sinn. Gibt es keine Prüfung, addieren sich die Fehler. Mit folgender Artikel/Text-Koordinate {{Coordinate|type=example|article=/|text=/|region=AT-K|NS=47|EW=16}} sollte hier aufscheinen.
• Also braucht es hier offensichtlich weitere Prüfungen. Wie kann man die obige Prüfung, am einfachsten zentral unter Kategorie:Parameterfehler einbinden (ohne manuelle Aufbereitung)?
• Fehlerprüfung oben ist zu einfach,
  • region kann auch durch / getrennt mehrere Werte annehmen und dann funktioniert obiger algorithmus nicht. DE-BY/DE-BW ist ein gültiger Wert für region.
  • region kann auch auf eine nicht existente Region verweisen, entweder weil die ISO Codes im Land neu organisiert worden sind und alte Codes entfallen oder weil für neue ISO Codes noch kein neues Info_ISO-3166-2: angelegt wurde (beides kommt öfter vor als man denkt). Daher sollten solche Unstimmigkeiten nicht zu einer roten Fehlermeldung im Artikel führen. Sondern über irgendwelche Nebenschauplätze abgehandelt werden. Geht maximal im BNR, aber die meisten User sind wohl überfordert, wenn sie für das Wegkriegen einer Fehlermeldung die entsprechende ISO-3166-2 erstellen müssten. Zum Glück gibt es aber inzwischen die meisten codes (Stand aber vor einem Jahr, danach sind mir keine Aktivitäten des Nachziehens von offiziellen ISO-Code Änderungen untergekommen)
• der obige Code ruft {{Info ISO-3166-2:AT}} auf, auch wenn dabei kein Code erzeugt wird, da kein Parameter übergeben wird, erhöht der Aufruf oben den Preprocessor node count um den Wert 19. Ist vermutlich verkraftbar. #ifexist ist wohl auch keine Lösung, da teuer.
• die obige Prüfung wird nicht im ANR wirksam. Meinst du das mit still? Wenn schon Prüfung, dann würde ich mir wünschen, dass auch im ANR geprüft wird, aber existierende Artikel nicht gerötet werden. Rote Fehlermeldungen in Artikel helfen nicht einmal bei der Neuanlage immer, aber bevor man was rot macht, muss man die Gründe für den Fehler in Altartikeln bereinigen.

@Merlissimo u. Fehlermeldungen

• eine leere Coordinate ohne region sollte nicht als Fehler betrachtet werden, Borgdorfer See ist aber aus anderen Gründen durchaus wertvoll gefunden zu werden. Spätestens beim Einhängen eines Bildes hätte man dort seine Wunder erlebt.
• bei den Unternehmen oben habe ich lange gesucht, aber keinen Grund für eine Beschwerde gefunden. Ev. falsch positiv?

lg --Herzi Pinki 20:34, 15. Jul. 2011 (CEST)

Ich hatte oben geschrieben Vorlagendaten stammen aus dem templatetiger-Scan von 21.6. Dieser Edit war erst danach. Ich hatte das hier ja nur durch Zufall gesehen. Die paar Scriptzeilen für die Query waren in zwei Minuten geschrieben (die Erstversion war natürlich für andere etwas unleserlicher als die oben gepostete). Ansonsten habt ihr mit Kolossos den Experten für diese Vorlagenauswertung schlechthin. Er kennt sich sowohl mit der Koordinatenvorlage und natürlich auch mit seinem eigenen templatetiger-DB aus. AND Value != '' würde die Leerwert ignorieren. Merlissimo 20:52, 15. Jul. 2011 (CEST)

Ach, entschuldige, wo war ich schon wieder, ich dachte, der 21. 6. war doch gerade eben. --Herzi Pinki 20:58, 15. Jul. 2011 (CEST)

Die obige Prüfung wird nur im ANR wirksam (doppelter || nach dem #if). Die ISO-3166-2-Vorlage wird aufgerufen, das kostet die erwähnten 10 ms.

Mit still meine ich, dass keine Fehlermeldung im Artikel erscheint, sodass wir erst mal die Lage peilen könnten und die Leute nicht zu sehr überfallen. Aber da diese Region-Angabe in Vorlage:Coordinate bislang wohl nirgendwo ausgewertet wird, ist das vielleicht alles nicht so wichtig. --PM3 22:06, 15. Jul. 2011 (CEST)

Hier ist ein weiterer Grund, die region-Prüfung einzubauen: Wikipedia:WikiProjekt Kategorien/Diskussionen/2011/Juli/16#Kategorie:Geographische Lage gewünscht (nach Region-Name) --PM3 22:23, 16. Jul. 2011 (CEST)

Das Problem mit meheren, /-getrennten ISO-Codes ließe sich lösen, indem wir nur den ersten davon prüfen - besser als nichts. Also so:

 {{#if: {{NAMESPACE}} 
   ||{{#if: {{Info ISO-3166-2:{{#titleparts:{{{region|}}}|1|1}}}} 
     |[[Kategorie:Parameterfehler|R{{FULLPAGENAME}}]]}} 
 }}

--PM3 02:07, 17. Jul. 2011 (CEST)

Koordinate Weltkugel: noch ein wunsch als erinnerung, wenn wir dabei sind

anlass hinter der Koordinate Weltkugel war übrigens:

1. dass in spalten das icon möglichst klein ist
2. die fehlermeldung (lagewunsch) dann aber die spalten enorm aufbläht

erschünscht wären also eine "stille" fehlermeldung, weil in listen fehlende koordinaten nicht für alle sichtbar sein brauchen: bringt sicher auch performance, den lagewunsch nicht erzeugen zu müssen (und der tabellenparser des browsers muss dann NACH erzeugen aller koordinaten die spalte erst recht wieder anpassen, und massig hidden-text herausrechnen: involviert ist also nicht nur die WP-serverleistung und die internet-datenrate, sondern auch die örtliche CPU & Grafikprozessor beim leser) vielleicht geht das dann gleich in einem, beim code-update, damit wir den zweiten fork auch noch gleich loswerden --W!B: 19:08, 16. Jul. 2011 (CEST)

Klingt sinnvoll; Einbau ist trivial. Zum Beispiel: neuer Parameter quiet=yes, dann in Vorlage:Coordinate an passender Stelle einfügen:

|quiet={{{quiet|}}}

und am Anfang von Vorlage:CoordinateNO:

{{#if:{{{text|}}} |{{#ifeq:{{{quiet|}}}|yes||<span id="{{#if:{{{name|}}}|{{anchorencode:{{{name}}}}}|text_coordinates}}" class="coordinates" style="background:#FFC" >Koordinaten fehlen! [[Wikipedia:WikiProjekt Georeferenzierung|Hilf mit.]]</span>}}}}

--PM3 22:59, 16. Jul. 2011 (CEST)

wow, ja! volltreffer - was ist eigentlich schneller, #ifeq oder #switch (also {{#switch:|yes=|default=…) - jedenfalls ist switch besser ausbaubar, falls noch andere werte kommen könnten

bei dieser vorlage gehts sicherlich um promille in der performance, wenn wir mit um die 500 einbindungen kalkulieren (und wie ich die wikifanten kenn, wenn 500 gut klappen, kommt bald einer mit 1500 ;) --W!B: 09:14, 17. Jul. 2011 (CEST)

Der Unterschied zwischen #if und #switch dürfte auch bei 500 Einbindungen noch unterhalb der Nachweisgrenze liegen. --PM3 15:02, 17. Jul. 2011 (CEST)

Andererseits: Wenn Koordinateneinträge gewünscht werden, dann sollte das m.E. auch an den entsprechenden Stellen im Artikel erkennbar sein. Das nur nach Kategorie:Geographische Lage gewünscht anzuwälzen und auf Artikelseite zu verstecken, finde ich kontraproduktiv. --PM3 00:55, 19. Jul. 2011 (CEST)

+1, Full ACK, PM3 --Herzi Pinki 00:45, 21. Jul. 2011 (CEST)

Kategorie:Geographische Lage gewünscht (nach Region-Name)

Zur Info: Diese Kategorie, die ausschließlich ansonsten unerwünschte Kat-Weiterleitungen enthält, wurde zur Löschung vorgeschlagen. Bitte dort mal die Argumente vortragen, ob diese Weiterleitungen grundsätzlich sinnvoll sind. Gibt es z.B. einen Bot, der darin einsortierte Artikel automatisch in die jeweilige Zielkat umsortiert, da solche Artikel ja nicht in der Zielkat angezeigt werden? Werden die Kategorien regelmäßig genutzt und kann man das irgendwo sehen, z.B. Botbeiträge, wo ein Bot die umsortiert hat? Wenn das nicht geschähe, wäre es ja grundsätzlich evtl. sinnvoller, Artikel mit falschem Parameter einfach in einer Wartungskat zur Umsortierung zu listen. Vielleicht kann jemand, der eine eventuelle Diskussion zur Einführung der Katweiterleitungen kennt, mal was in der LD dazu sagen. Außerhalb dieser Katweiterleitungen existieren übrigens keine weiteren, die werden nämlich sonst alle nach SLA automatisch gelöscht. Deshalb wäre mal eine gute Begründung hierfür sinnvoll. Ich hatte bereits selber mal überlegt, auf diese Kat einen LA zu stellen, hab es aber dann erst mal so gelassen, da ich davon ausgehe, dass ihr euch die Sache bei deren Einführung im Dezember 2008 gut überlegt habt. --Geitost 19:56, 16. Jul. 2011 (CEST)

Ich bilde mir ein, die Implementierung einigermaßen verstanden zu haben, aber deine Vermutungen (Weiterleitung, Bot, umsortieren, Zielkat, ...) ergeben für mich keinen Sinn. (Der Löschantrag übrigens ebensowenig). --Spischot 20:21, 16. Jul. 2011 (CEST)

Wenn man Artikel in Kat-WL einsortiert, werden diese nicht in der Zielkat angezeigt. Das ist einfach so. Das heißt, dass sie dort niemand finden kann. Und wer auf der WL landet, landet in der Zielkat und sieht auch nicht die Artikel in der WL. Dazu müsste man dann die WL erst mal zurückverfolgen. Oder halt irgendwie anschließend immer die Artikel in die Zielkat umsortieren, ob nun per Hand oder per Bot, spielt dabei erst mal keine Rolle. Und die Oberkat ist die einzige sinnvolle Möglichkeit, die Artikel einigermaßen komfortabel finden zu können, um sie dann umzusortieren. Man kann natürlich auch gleich die Artikel geodatieren stattdessen, dann bräuchten sie nicht mehr in die Zielkat. ;-)

Die Frage ist ja nun: Was passiert denn nun mit den Artikeln in den Kat-WL? Gibt es einen Bot, der darauf angesetzt wird oder wie werden die Artikel in diesen Kat-WL gefunden, um sie dann geodatieren zu können? Solange unklar bleibt, was mit solchen Artikeln passiert, macht natürlich auch ein solcher LA Sinn. --Geitost 02:29, 17. Jul. 2011 (CEST)

Danke für deine Erklärung, ich verstehe nun was du willst. Es gibt keine Artikel in den WL-KAts und es gibt keinen Bot. Für alles weitere sind ja jetzt genügend Spezialisten in der LD versammelt. --Spischot 10:44, 17. Jul. 2011 (CEST)

eigener ISO-Code, aber keine Wartungskategorie

Die folgenden Gebiete haben einen eigenen ISO-3166-1-Code, der teils auch mit {{Coordinate}} verwendet wird, aber es existieren keine Wartungskategorien unter Kategorie:Geographische Lage gewünscht (nach Region-Code):

• Åland Inseln
• Amerikanisch Samoa
• Anguilla
• Bonaire, Sint Eustatius und Saba
• Bouvetinsel
• Britische Jungferninseln
• Britische Territorien im Indischen Ozean
• Cookinseln
• Curaçao
• Französisch Guiana
• Französisch Polynesien
• Französische Südgebiete
• Guadeloupe
• Guam
• Heard Insel und McDonald Inseln
• Kaimaninseln
• Kokosinseln
• Marshallinseln
• Martinique
• Mayotte
• Montserrat
• Nauru
• Niue
• Nördliche Marianen
• Norfolk Insel
• Pitcairn
• Puerto Rico
• Réunion
• Saint Pierre und Miquelon
• Samoa
• Seychellen
• Sint Maarten
• St. Lucia
• Südgeorgien und die Südlichen Sandwichinseln
• Svalbard und Jan Mayen
• Swasiland
• Tokelau
• United States Minor Outlying Islands
• Wallis und Futuna
• Weihnachtsinsel

Ist das Absicht? --PM3 01:50, 17. Jul. 2011 (CEST)

Viele davon dürften Unterkats sein und bei Verwendung einfach in die Landesoberkat einsortiert werden, wie das immer ist, wenn die Unterkat fehlt. Das sollte also kein Problem sein. So z.B. bei den Gebieten von Frankreich, die sich irgendwo in Übersee befinden, die dann in der französischen Kat landen; auch die Niederlande und Großbritannien dürfte das betreffen bzw. die USA. Siehe auch deren länderspezifische ISO-Übersichten, wo es zu den wenigsten Überseegebieten Unterkats gibt. Die haben dann im Normalfall 2 mögliche ISO-Codes, mit und ohne das Länderkürzel davor. Svalbard gehört wohl zu Norwegen usw. Recht viele Inselgebiete deswegen. Wenn man die abzieht, was bleibt dann noch übrig von der Liste? --Geitost 02:20, 17. Jul. 2011 (CEST)

Was du beschreibst, ist die Ausnahme; die allermeisten dieser ISO-Codes sind in Verwendung. Zum Beispiel in Amerikanisch-Samoa, Anguilla, Bouvetinsel, Britische Jungferninseln, Britisches Territorium im Indischen Ozean, Cookinseln, Guadeloupe, Guam, Heard und McDonaldinseln. Das ist jetzt nur Buchstabe A-H, weiter habe ich nicht geschaut. --PM3 02:31, 17. Jul. 2011 (CEST)

Koordinatenimport von anderen Wikis

Wird sowas eigentlich schon gemacht? Ich habe gerade mal aus Spaß geschaut, wieviele plwiki Artikel die Koordynaty-Vorlage enthalten, der dewiki aber nicht (sind knapp 1200). Ist jemand an solchen Listen interessiert? Merlissimo 01:06, 19. Jul. 2011 (CEST)

Direktimport geht? Ich suche bisher alles selber raus und trage dann haendisch ein. Ich versuche alle Koordinaten selber zu finden, falls ich nicht fuendig werde, suche ich in anderen wikis. Tja, wenn das automatisiert werden koennte, ich bin dabei! Solange AWB mitmacht. :) --Hedwig in Washington (Post?)•B 08:18, 19. Jul. 2011 (CEST)

Hoffentlich werden die Koordinaten, bevor sie hier eingesetzt werden, noch einmal geprüft und nicht einfach nur übernommen. Die Angaben liegen manchmal katastrophal daneben, z.B. bei pl:Chartum über 100 km, immerhin eine eigentlich gut zu lokalisierende Hauptstadt. Das betrifft natürlich nicht nur die polnische WP. NNW 09:21, 19. Jul. 2011 (CEST)

Dispenser stellt doch so eine Liste wöchentlich bereit (WP:GEO#Artikel ohne Koordinaten, [3])? --Meleager 10:40, 19. Jul. 2011 (CEST)

Das Tool von Dispenser deckt aber nur die Fälle ab, wo bereits ein Lagewunsch auf dewiki gesetzt ist. Ich meinte vorhandene Artikelkoordinaten, aber überhaupt keine Koordinatenvorlage auf dewiki. Außerdem sprach ich von Listen und nicht von einer automatischen Übernahme in die Artikel. Merlissimo 11:36, 19. Jul. 2011 (CEST)

Das hatte ich auch so verstanden. Nur zeigt die Erfahrung, dass Koordinaten, soweit irgendwo vorhanden, gerne ungesehen übernommen werden. Mein Hinweis richtete sich also nicht an dich, sondern an diejenigen, die mit dieser Liste arbeiten wollen. NNW 11:44, 19. Jul. 2011 (CEST)

Deswegen würde ich das ja gerne erst einmal hier im Projekt ausprobieren wollen, bevor ich mir überlege, ob ich das später auch an die Portale verteilen kann. Merlissimo 12:01, 19. Jul. 2011 (CEST)

Ich habe Wikipedia:WikiProjekt Georeferenzierung/Referenzierte Objekte in anderen Wikipedias erstellt. Falls das angenommen wird müsse natürlich noch Erklärungstexte usw ergänzt werden. Aber auf die schnelle als Diskussionsgrundlage reicht das imo aus.

Also das sind fremdsprachige Artikel mit Artikelkoordinaten (also nicht im Fließtext) und auf dewiki ganz ohne Koordinaten (also weder Artikel noch Fließtext).

Um also einen Artikel langfristig aus der Liste zu entfernen muss man entwerder auf dewiki eine Koordinate einfügen (Fließtext reicht aus) oder die falschen Interwiki korrigieren.

Als Dritten bleibt noch der Fall, dass aufgrund anderer Anforderungen der dewiki-Artikel nicht für eine Koordinate geeignet ist. Solche Artikel müsste man irgendwo vermerken, damit es bei der nächsten Aktualisierung nicht wieder auftaucht. Dazu könnte man z.B. eine Unterseite analog zu Wikipedia:WikiProjekt_Interwikilinks/Commonslinks/Ignorieren erstellen auf denen man zu ignorierende Artikel verlinken kann. Aber vielleicht schaut ihr erst einmal, ob überhaupt jemand so eine Liste nutzen möchte. Merlissimo 13:40, 19. Jul. 2011 (CEST)

Wie wäre es mit einer Kennzeichnung automatisch importierter Koordinaten als "noch zu prüfen"?

{{Coordinate|NS=34.5657|EW=12.345|...|status=unchecked}}

→ Einordnung in Kategorie:Parameterfehler unter Nr. 0 (oder in eine neue Wartungskategorie), und nach Prüfung löscht man das status=unchecked raus. --PM3 14:31, 19. Jul. 2011 (CEST)

FYI: Ich bin auch nicht von stumpfem kopieren der Daten ausgegangen. Aber eine Liste, die die Arbeit vereinfacht ist schon nicht uebel. Z. Zt. erstelle ich mit CatScan eine Liste, die ich in Excel "reinige" und dann von Hand(!) mit AWB nach div. Regeln abarbeite. Bin gerade bei Unternehmen in DE-NI. :) Soweit dazu. Ich finde den Vorschlag von PM3 extrem praktisch. Die Parameterfehler werden ja eh mehrmals taeglich geprueft und bereinigt. --Hedwig in Washington (Post?)•B 16:55, 19. Jul. 2011 (CEST)

Alternativvorschlag: Es wird eine Liste anderswo verfügbarer Koordinaten erstellt. Abseits der Artikel. Diese Liste wird abgearbeitet und die Koordinaten werden geprüft, und dann in den Artikel übernommen. Hätte den gleichen Effekt wie oben, nur würden ungeprüfte Koordinaten niemals nicht in den Artikeln aufscheinen. Mir erschließt sich der Vorteil ungeprüfter Koordinaten in den Artikeln nicht so richtig --Herzi Pinki 00:11, 9. Aug. 2011 (CEST)

Und welchen Teil deines Vorschlages bezeichnest du nun als alternativ? Ob jemand Koordinaten ungeprüft übernimmt, hängt allein vom Bearbeiter ab.

Fakt ist, dass Wikipedia:WikiProjekt Georeferenzierung/Referenzierte Objekte in anderen Wikipedias innerhalb eures Projektes nicht funktioniert hat (nach einem Monat haben von 1000 Artikeln ganze drei Artikel auch eine Koordinate bekommen). Es gibt aber auch keine Äußerungen, dass diese Liste unbrauchbar sei. Wenn ich Zeit finde, werde ich deshalb die Liste wieder aus eurem Projekt nehmen und stattdessen in die Portallisten integrieren. Vielleicht klappt es dort besser. Nachteil ist natürlich, dass ihr vom Projekt keine zentrale Kontrolle mehr habt, sondern dies dann rein auf die Portale übergeht. Merlissimo 19:47, 19. Aug. 2011 (CEST)

Nachdem ich nun mit den US-Counties durch bin, wollte ich mich nun deiner Liste zuwenden. Wäre schön, wenn du sie gelegentlich aktualisieren könntest. Zwei, drei Dinge sollten noch gemacht werden:

• Alle (oder wenigstens die wichtigsten) Sprachvarianten des Artikels auflisten, die eine Lage enthalten. Im aktuellen Stand fehlen z.B. en, es, ru.
• Regelmässige automatische Aktualisierung der Liste
• Sortierung nach Land (ISO 3166-1) o.ä.: so kann man sich mal auf ein Gebiet konzentrieren und muss nicht ständig die Karten wechseln.
• Eventuell in zusätzlicher Spalte einen Vorschlag in de-Wiki-Syntax, generiert aus der Koordinate einer anderssprachigen Wiki, z.B. {{Coordinate|NS=-11|EW=36|type=adm1st|region=TZ-21}} für die erste Zeile (Ruvuma-Region). Im besten Fall kann man diesen direkt copy-pasten.

Ob es einen Ausschluss-Mechanismus für Falsch-Positive braucht, wird sich wohl erst im Laufe der Zeit zeigen. -- Meleager 21:55, 19. Sep. 2011 (CEST)

Die WMF-Wikis sind auf sieben Servercluster aufgeteilt. Queries zwischen zwei Wikis auf verschiedenen Clustern sind deutlich komplizierter. Deshalb fehlen z.B. en,es,ru,fr,ja, die auf anderen Clustern liegen. Hier muss sich erst mit den anderen Wikis zeigen, dass sich der Programmieraufwand auch lohnen würde.

Wie oben geschrieben habe ich vor, dass in die Portallisten zu integrieren. Das wird aber sicher noch 1-2 Monate dauern. Das würde dann auch häufiger aktualisiert und man könnte die Arbeitslisten der Länderportale nutzen um das auf ein Gebiet einzugrenzen.

Das mit den Quellcode wäre dann ein weiterer Schritt, den man sich überlegen kann, wenn das andere schon funktioniert. Wobei damit natürlich die Gefahr wächst, dass Leute dies unüberlegter per C&P übernehmen, weil sie sich selber keine Gedanken mehr machen müssen. Merlissimo 00:23, 22. Sep. 2011 (CEST)

Kategorie:Parameterfehler

Mal eine ganz andere Baustelle: Im Sinne der Neuordnung von Wartungskategorien würde ich gerne die Kategorie:Parameterfehler nach Kategorie:Parameterfehler Koordinateneinbindung (o.ä., sehr gerne mit WP-Präfix auf Kategorie:Wikipedia:Parameterfehler Koordinateneinbindung) verschieben. Das hätte ich auch schon längst getan, wenn Merlissimo nicht gemeint hätte dass davon evtl. Geo-Tools beeinträchtigt werden könnten. Sein Bot käme damit klar. Daher möchte ich noch um Eure Meinung bitten. Zudem suche ich einen Admin, der das in den geschütztzen Vorlagen umsetzen sowie die Kategorieseite mit ihrer beträchtlichen Versionsgeschichte verschieben (reimportieren) kann. --✓ ^Bergi 18:54, 21. Jul. 2011 (CEST)

Wie wäre es mit einem kürzeren Name? z.B. Kategorie:Wikipedia:Coordinate-Parameterfehler. --PM3 23:51, 28. Jul. 2011 (CEST)

Ja, nichts dagegen. Allerdings sollte(?) er sich nicht nur auf die Vorlage:Coordinate beziehen, da z.B. die Poskarte dieselben Fehler auslöst (und die Kat einbindet). --✓ ^Bergi 14:25, 29. Jul. 2011 (CEST)

Kategorie:Wikipedia:Koordinaten-Parameterfehler ? Wenn das geändert wird, muss es übrigens zeitgleich auch in Vorlage:CoordinateError geändert werden. --PM3 14:38, 29. Jul. 2011 (CEST)

Default-Koordinatenformat

So, bevor die neue Version von Vorlage:Coordinate in Betrieb gehen wird habe ich noch ein paar Fragen an euch:

• Die Vorlage:Coordinate/Test/Default (wie Vorlage:CoordinateRR DEFAULT, nur effizienter) erzeugt Werte für das Standardausgabeformat (anzuwählen per /) nach Regionscodes. Zurzeit wird nur zwischen Schweiz/Liechtenstein, alles andere und beides gleichzeitig unterschieden. Nachdem aber mittlerweile UTM zur Verfügung steht (und wahrscheinlich auch OSGB36 nicht mehr lange warten muss) möchte ich von euch gerne wissen wann denn mal was ausgegeben werden soll. Wo wird denn was angewandt? Gilt OSGB36 auch in Überseegebieten (mit GB-Isocode)?
• Die andere Frage beträfe die Bezeichnung. Bisher wurde das so gelöst, dass wenn in der Artikelkoordinate ein zweites Format (also CH1903) ausgegeben wurde davor das Kürzel des Formats - mit ausführlichem Tooltip - kam. Derartiges wird vermutlich häufiger nötig werden wenn mehr eher unbekannte Formate zur Verfügung stehen. Wie soll das gelöst werden, sollen wir dafür am besten einen neuen Parameter einführen? Oder gibt es eine bessere Lösung?
  1. Vorlage:Coordinate/Test/Neu
  2. Vorlage:Coordinate/Test/Neu
  3. Vorlage:Coordinate/Test/Neu
  4. Vorlage:Coordinate/Test/Neu
  5. articleVorlage:Coordinate/Test/Neu
  6. articleVorlage:Coordinate/Test/Neu
  7. articleVorlage:Coordinate/Test/Neu

Wie soll also vor allem die automatische Lösung für article aussehen?

• Und noch eins: Gibt man CH1903 immer mit Klammern an, ich habe dies mittlerweile entfernt (2. Beispiel)?
• Sowie: wie findet ihr die UTM-Umsetzung vom Format her, fehlt da ein „m“ für Meter, ein „Nord“ bzw. „Süd“? --✓ ^Bergi 21:51, 28. Jul. 2011 (CEST)

Vorsicht! Es gibt offensichtlich Performance-Probleme bei der Vorlage:Coordinate. Möglicherweise sind diese mit der neuen Überarbeitung erst mal beseitigt. Trotzdem sollte man nicht gleich wieder neue rechenaufwändige Funktionen einbauen, deren Nutzen ausgesprochen gering ist. Denn wozu braucht man die Koordinatenanzeige? Ich selber mache mir keine großen Gedanken über die angezeigteen Zahlenwerte, sondern klicke drauf und lande auf dem Toolserver. Der bekommt als Input aber nur geographiche Länge und Breite in Zentigrad und schert sich einen Dreck um die Darstellung im Artikel. Deshalb würde ich persönlich übrigens auch auf die Anzeige der schweizer Koordinaten im Artikel verzichten und die Standardanzeige DMS als einzige Möglichkeit (neben den Symbolen oder einem Text) vorsehen. --Telford 16:52, 29. Jul. 2011 (CEST) P.S. Der britische "National Grid" deckt nur Großbritannien (Insel) ab.

Nennenswert Performance kostet das nur, wenn man's wirklich verwendet. Bei einer oder wenigen Koordinaten pro Artikel haben wir kein Performanceproblem, und in Listen mit vielen Koordinaten kann man schnelle Ausgabevarianten verwenden. Das Schweizer Format muss ohnehin drinbleiben, und es gibt bestimmt Fachartikel, wo UTM nützlich ist. --PM3 17:23, 29. Jul. 2011 (CEST)

Ketzerisch gefragt: warum genau muss das schweizer Format drinbleiben? Anders formuliert: schreibt irgendwer tatsächlich die Koordinaten ab, um sie anderswo einzutippen? Und in welchen Artikeln wäre die UTM-Anzeige sinnvoll? --Telford 17:40, 29. Jul. 2011 (CEST)

Abschreiben wohl nicht, heutzutage guttenbergt man das :-) Mehr oder minder komplizierte Formate sind immer nützlich, da sie durchaus Anwendung finden (sonst gäbe es sie ja kaum). So kann man beispielsweise Angaben aus anderen Quellen leicht mit WP vergleichen, oder die Koordinaten direkt aus WP heraus verwenden (und UTM wird laut Artikel durchaus häufig gebraucht). Wozu brauchts denn sonst überhaupt eine Ausgabe, reichen nicht die Dezimalgrad in der Toolserverl-URL??? --✓ ^Bergi 17:58, 31. Jul. 2011 (CEST)

Wesentlicher Nachteil des bisher Üblichen ist halt, daß bei jedem Neuaufbau der Seite immer wieder die gleichen Berechnungen ablaufen, was bei vielleicht hunderten von Einträgen in einer Liste zu den bekannten Problemen führt. Dein Hinweis auf Guttenberg hat mich allerdings auf eine Guerilla-Lösung gebracht: statt

• 47° 3′ 10″ N, 8° 20′ 9″ O (668170 / 211695)47.0527777777788.3358333333333

(Quelltext: {{Coordinate|text=DMS/CH1903|name=Verkehrshaus|NS=47/3/10/N|EW=8/20/9/E|type=landmark|region=CH-LU}})

könnte man nämlich auch

• 47° 3′ 10″ N, 8° 20′ 9″ O; (668170 / 211695)47.0527777777788.3358333333333

(Quelltext: {{Coordinate|text=47° 3′ 10″ N, 8° 20′ 9″ O; (668170 / 211695)|name=Verkehrshaus|NS=47/3/10/N|EW=8/20/9/E|type=landmark|region=CH-LU}})

schreiben. Das sieht für den Leser völlig gleich aus, der Link auf den Toolserver ist der gleiche, und es entsteht (nach der allerersten Umrechnung) keinerlei weiterer Rechenaufwand für die Umwandlung zwischen den Koordinatensystemen. --Telford 09:44, 2. Aug. 2011 (CEST)

Sorry, aber die Koordinaten von Hand da reinzutippen, halte ich für ziemlichen Quatsch. --тнояsтеn ⇔ 12:46, 2. Aug. 2011 (CEST)

Wer hat denn von tippen geredet – c&p ist angesagt (noch mal Danke an Bergi!), und das kostet auch bei sorgfältigem Arbeiten pro Koordinate weniger als 5 Sekunden. --Telford 13:13, 2. Aug. 2011 (CEST) P.S. Falls diese Anforderung öfters vorkommen sollte (was ich eigentlich nicht annehme), könnte man dafür vermutlich auch relativ einfach einen Bot programmieren.

Ist dir bekannt, dass das Performanceproblem mit den Listen längst gelöst ist? Vorlage:Coordinate#Vorlage zu langsam?

Selbstverständlich hat die Koordinate nicht redundant im Text zu stehen, das provoziert Inkonsistenzen. --PM3 13:44, 2. Aug. 2011 (CEST)

Also, unter Vorlage:Coordinate#Vorlage zu langsam? lese ich: "Die Anzeige von CH1903-Koordinaten mit text=CH1903 ist relativ langsam." Mir scheint, daß diese Aussage auch für die Variante "simple" gilt. Falls dies zutrifft ist die Langsamkeit ganz sicher auf die Koordinatenumrechnung zurückzuführen. Natürlich ist das bei der Artikelkoordinate oder einer Handvoll Textkoordinaten völlig unerheblich, aber bei langen Listen mit vielen Koordinaten (und nur dort klemmt es ja!) schlägt das dann durch. – Ganz allgemein ist das Problem der Vorlage:Coordinate doch nicht, daß sie einen Haufen sinnvoller Berechnungen durchführt. Das Problem ist, daß diese Berechnungen bei jedem neuen Aufbau der Seite von neuem durchgeführt werden, auch wenn sich an einer Koordinatenangabe seit Dutzenden von Artikelversionen nichts geändert hat. Und die einzige Lösung dafür ist: möglichst viel nur einmal berechnen und dann "fest" einbauen. (Am liebsten würde ich Vorlage innerhalb von langen Listen SUBSTen: konsistente Daten, mögliche Fehler abgeprüft, schnell wie Sau. Hat leider geringfügige Nachteile...) Aber vielleicht ist unsere Diskussion auch bloß Theorie: gibt es schon eine Liste mit, sagen wir, mehr als 100 schweizer Koordinaten? --Telford 14:40, 2. Aug. 2011 (CEST)

Nein, anscheindend ist ihm das nicht bekannt.

Mit deiner „Guerilla“-Einbindung reduzierst du: die Ausgabe um ein Drittel, die Einbindungskomplexität um etwa 20% und die Aufwendigkeit um weniger als 10%, da die Vorlagenexpansion immer noch aufwendig ist. Wohingegen allein die neue Programmierung ersteres erweitert, zweiteres um 2/3 und letzteres um 1/3 verbessert. Was helfen würde wäre die Einbindung von <span id="Verkehrshaus" class="coordinates plainlinks-print">[http://toolserver.org/~geohack/geohack.php?pagename=Klaus_Dieter_Wolf&language=de&params=47.052777777778_N_8.3358333333333_E_region:CH-LU_type:landmark&title=Verkehrshaus <span title="Verkehrshaus"><span title="Breitengrad">47°&#160;3′&#160;10″&#160;N</span>, <span title="Längengrad">8°&#160;20′&#160;9″&#160;O</span>; (<span title="y easting">668170</span>&#160;/&#160;<span title="x northing">211695</span>)</span>]</span><span class="geo microformat"><span class="latitude">47.052777777778</span><span class="longitude">8.3358333333333</span></span> in deinen Artikeltext, das würde alles auf 0 reduzieren. --✓ ^Bergi 15:00, 2. Aug. 2011 (CEST)

<quetsch>Das substen war nicht wirklich ernst gemeint, allerdings hätte ich gedacht, das dabei genau das herauskommt was du in Deinem Beitrag geschrieben hast. Aber: das ist sicher nicht praktikabel, und mein Guerilla-Vorschlag lautet ja anders. --Telford 15:27, 2. Aug. 2011 (CEST) </quetsch>

Ja, er unterschlägt nur die Tooltips. Du kannst natürlich auch {{Coordinate|text=<span title="Breitengrad">47°&#160;3′&#160;10″&#160;N</span>, <span title="Längengrad">8°&#160;20′&#160;9″&#160;O</span>; (<span title="y easting">668170</span>&#160;/&#160;<span title="x northing">211695</span>)|name=Verkehrshaus|NS=47/3/10/N|EW=8/20/9/E|type=landmark|region=CH-LU}} schreiben, aber da ist dann vollständiges Substituieren genauso sinnvoll. --✓ ^Bergi 15:51, 2. Aug. 2011 (CEST)

Hier geht es nur um Features/Formatierungen der neuen komplexen Koordinateneinbindung, die in Listen sowieso nicht zur Verfügung stehen! Und dazu hätte ich als Vorlagenentwickler gerne Hinweise bezüglich (sachlicher) Richtigkeit und ausstehende Wünsche seitens Sachverständiger des betreffenden Projekts, das einzig hilfreiche bisher war das PS. --✓ ^Bergi 15:00, 2. Aug. 2011 (CEST)

Darf ich Deinen Wunsch so verstehen, daß er nur auf das Endergebnis, also das Ausgabeformat, abzielt? Das ist dann relativ einfach (alle Beispiele reiner Text ohne Vorlagenverwendung):

• Für Bern wird bei uns derzeit 46° 57′ 4″ N, 7° 26′ 19″ O; CH1903: (600'000 / 200'000) angezeigt. Swisstopo und map.geo.admin.ch schreiben Koordinaten (m) 600000 / 200000 bzw. Koordinaten(m): 600000,200000. Die Klammern gehören also offensichtlich nicht zur Georeferenz, und ob man durch / oder , trennt ist wohl auch egal. Übrigens ist auch die Angabe (m) nicht unbedingt erforderlich, da sie aus der Größenordnung der Zahlen (6-stellig) eindeutig folgt. Unsinn.
• Land's End liegt bei 50° 4′ 7″ N, 5° 43′ 58″ W. Der Geohack zeigt die britischen Landeskoordinaten SW3292225468 und die in UTM-Koordinaten 30U 304442 5549837 an. Dazu ein paar Bemerkungen:
  • Leerzeichen zwischen den Zahlengruppen machen die Sache lesbarer, also besser SW 32922 25468; sie sind aber nicht erforderlich. (Bei den britischen Koordinaten müssen beide Zahlengruppen die gleiche Anzahl Ziffern haben.)
  • Angabe des Koordinatensystems, also z.B. UTM: könnte für OMA nützlich sein, ist aber ebenfalls nicht erforderlich, weil es sich eindeutig aus den ersten zwei Buchstaben bzw. den ersten zwei Ziffern mit dem Buchstaben ergibt.
  • Angabe der Himmelsrichtungen gehört nicht in diese Koordinaten.
  • Angabe der Einheit (m) ist ebenfalls nicht üblich; sie ergibt sich aus der Anzahl von 5 Stellen bei OSGB36 und 6 bzw. 7 Stellen bei UTM.
  • Gröbere Angaben sind möglich, indem Ziffern weggelassen werden. Z.B. beschreibt "SW 329 254" die linke untere Ecke eines 100-m-Rasterfelds, und der eigentliche Punkt liegt irgendwo da drin. Für UTM ist so etwas auch möglich.
  • Falls Du wirklich eine Berechnung der britischen Landeskoordinaten implementieren willst: im Geohack fehlt der datum shift von WGS84 zu OSGB36, d.h. die angezeigten Koordinaten sind um bis zu etwa 130 Meter falsch.

Anzeige im Artikel wäre dann z.B. 50° 4′ 7″ N, 5° 43′ 58″ W; 30U 304442 5549837 oder (für OMA) 50° 4′ 7″ N, 5° 43′ 58″ W; UTM: 30U 304442 5549837. Alleinige Anzeige von UTM könnte man auch vorsehen; Anzeige britischer Landeskoordinaten analog. --Telford 18:18, 2. Aug. 2011 (CEST)

Nachtrag: Land's End war ein sch*** Beispiel: da hat sich jemand bei Koordinatenübernahme aus der en wp um eine volle Bogenminute verhauen :-(( . Erstaunlich, daß das seit 10 Monaten niemand gemerkt hat, das ist bei Google ja so was von klar erkennbar. Ich habs im Artikel geändert, lasse die alten Zahlen hier aber stehen. --Telford 18:56, 2. Aug. 2011 (CEST)

Danke. Unterscheibt der Rest des Portals das?

• Dein Vorschlag sieht vor, dass ein eventuelles zweites Format mit „;“ abgetrennt statt eingeklammert wird (gefällt mir persönlich für die Artikelkoordinate auch besser). Ist das im Text auch sinnvoll, sollte man das wählbar machen?
• Das mit der Schreibweise kann ich so verstehen, dass alles erlaubt ist was geht? Zusammenschreiben ist wohl nicht sinnvoll, ob Leerzeichen, „,“, „, “, „/“ oder „ / “ sollten wir zumindest mal einheitlich machen. Zurzeit haben wir letzteres, wenn etwas anderes gewünscht ist einfach ansprechen.
• Die Angabe des Koordinatenformats bei nicht-DM(S) ist in Artikelkoordinate und zweitem Textformat für OMA nicht nur sinnvoll, sondern notwendig (kein „normaler“ Mensch kann das aus Ziffernkombinationen rauslesen). Im Text sollte es möglichst wählbar sein?

  Die Logik für Artikelkoordinate sieht derzeit ja so aus: 1. Format ist immer DMS, ohne Angabe. 2. Format ist wählbar (in CH-LI/GB/etc. auch per default; und es ist nicht nochmal DMS), wird immer mit Angabe ausgegeben.

  Für Text sieht es so aus, dass beide Formate wählbar sind (nur nicht zweimal dasselbe), und das erste wird immer ohne sowie das zweite immer mit (nur bei DMS nicht) Angabe ausgestattet.

  Und natürlich kann auch nur ein Format ausgegeben werden. Obiges Beispiel gibt bloß jedes Format einmal als erstes und einmal als zweites aus. Jedenfalls dürfte diese Logik für die Textkoordinate nicht sinnvoll sein. Wenn nicht-DMS als Erstes ausgegeben wird, sollte das System ebenso angegeben werden? Und es sollte aber auch abschaltbar sein, wenn es sich aus dem Fließtext ergibt (und sei es in Infoboxen mit {{CoordinateSYSTEM}}, wobei dafür aber auch die Angabe des zweiten Formats abschaltbar sein sollte?).

• Angabe von Himmelsrichtungen: der Artikel UTM-Koordinatensystem erwähnt ausdrücklich, dass man hier Nord/Süd angeben muss, und wenn man es im Buchstaben für das UTMREF-Zonenband codiert kann es bei N und S zu Verwechslungen kommen. Dass es sich um das Zonenband handelt ist ja im Tooltip angegeben, reicht das? Das Koordinatenbeispiel unterscheidet auch ausdrücklich zwischen 33-Nord und 33U/QuadratVS….
• Gut, die „m“ lass ich weg.
• Rundung von UTM etc.: Ist das sinnvoll (implementieren ließe es sich einfach)? Sollte man dann doch per dam bzw. hm darauf hinweisen, sonst versteht es keiner? Es wäre schließlich ziemlich oft der Fall, dass mit round=0 gerundet wird - was etwa 100-Meter-Genauigkeit enspräche. Wenn ja, wo ist dann der Hinweis am besten untergebracht?
• OSGB36: An den datum shift hätte ich schon gedacht, das ist ja das anspruchsvolle :-) Wundert mich aber schon, dass der Toolserver das nicht kann.

Danke für die umfangreichen Antworten (wo ich doch so ungern nachfrage :-) --✓ ^Bergi 21:36, 2. Aug. 2011 (CEST)

Um erst mal nur auf UTM einzugehen: Runden würde ich nicht, weil OMA das Prinzip nicht versteht. Im UTM-Artikel habe ich das Beispiel verbessert. Angabe von "m" sowie "E" oder "N" ist unüblich, überflüssig und verwirrend (weil man z.B. "N" mit der geographischen Nordrichtung verwechseln könnte). Ich favorisiere eindeutig eine Anzeige der Art "32U 461344 5481745". --Telford 11:23, 3. Aug. 2011 (CEST)

Ah, du meintest diese Himmelsrichtungen, die hatte ich ganz übersehen. Ok, sind draußen. Das „Zone:“ kann man auch noch wegnehmen, das Komma und den Schrägstrich würde ich aber entweder drinlassen oder auch aus CH1903 entfernen. Beim Runden volle Zustimmung.

Freue mich auf weitere Antworten, --✓ ^Bergi 11:55, 3. Aug. 2011 (CEST)

Kommt schon: bei UTM (und auch OSGB) sind Komma und Schrägstrich definitiv falsch ;-) . --Telford 13:38, 3. Aug. 2011 (CEST)

Na gut… Ich meinte eigentlich Antworten auf die anderen Fragen. Und: Bist du eigentlich der einzige hier aktive Benutzer [4]? --✓ ^Bergi 14:43, 3. Aug. 2011 (CEST)

Also ab und zu schau ich schon mal noch vorbei ...
seh nur grad nicht was noch unklar sein soll und so schlimm dass ich grad das Veto ergreifen müsste ist es nicht. Ach so Schweizer Landeskoordinaten: im Text werden die üblicherweise in Klammern gesetzt. Der Schrägstrich ist etwas auffälliger. So sinds die Schweizer halt gewohnt. als Tausendertrennzeichen sieht man auch öfters den Punkt (zB beim SAC). Das wird dann aber als Kilometer gelesen. Die Koordinaten sind aber in Meter ... Ist halt schwer wenn Generationen Komma lesen und Punkt schreiben ... 46.126.153.200 21:39, 4. Aug. 2011 (CEST)

sorry das war ich -- visi-on 22:00, 4. Aug. 2011 (CEST)

Überschrift dieser Diskussion ist ja "Default-Koordinatenformat". Das ist gleichbedeutend mit der Frage: was soll "article=/" oder "text=/" bewirken? Meine persönliche Meinung dazu: so wenig Automatismus wie irgend akzeptabel. Derzeit ist der "/" wohl identisch mit DMS+CH1903 (für schweizer Artikel) und DMS (sonst). Eine Erweiterung dieses Prinzips auf Artikel zu Großbritannien und damit auf OSGB36 halte ich nicht für sinnvoll, weil von 100 Lesern im deutschsprachigen Raum vermutlich nicht viel mehr als einer mit den britischen Koordinaten etwas anfangen kann. Etwas anderes wäre die Anzeige diese Koordinaten als explizit gewählte Option. --Telford 14:38, 5. Aug. 2011 (CEST)

Wer halt in GB einen Rettungsdienst mit WGS84 Koordinaten alarmiert wartet unter Umständen halt eine Viertelstunde länger. Spätestens dann interessierts. Auch in Deutschland gehts wahrscheinlich mit UTM am schnellsten. -- visi-on 13:32, 6. Aug. 2011 (CEST)

Oh, dann habt ihr mich etwas missverstanden. Neben der Diskussion, was bei / geschehen soll, möchte ich auch wissen wie etwas ausgebeben wird (also Formatierung) wenn die Ausgabesysteme (-formate) bereits gewählt sind. --✓ ^Bergi 17:44, 5. Aug. 2011 (CEST)

Tausender-Trennzeichen gibts in der Vorlage eh keine mehr (die alte CH1903-Vorlage hatte sie auch nur bei [1-6]00000), die Koordinaten sind immer in m (alles andere verwirrt OMA). Submetergenauigkeit ist bei Konversion aus WGS84 eh Unsinn, also brauchts auch keine Kommazeichen.

Das ist aber auch nur so weil mal beschlossen wurde, dass nicht die Originalkoordinaten eingegeben werden dürfen. -- visi-on 13:32, 6. Aug. 2011 (CEST)

Wo eine Bezeichnung stehen soll werde ich wohl wählbar machen, da gibts einfach zu viele Möglichkeiten. Default bleibt: nur zweites Format beschriften. Zudem: DMS wird (kann) nie beschriftet werden.

Im Text wird das zweite Format immer eingeklammert, beim Artikel gibts nur einen Strichpunkt dazwischen ohne jegliche Klammerung.

Was ist jetzt mit CH1903? Mit oder ohne „/“? Mit oder ohne Klammern im Text? Auch mit Klammern im Text, wenn dahinter ein zweites (geklammertes) Format ausgegeben wird? Hier beispielsweise gehen die Klammern eher im Weg um, während sie wahrscheinlich oft auch gerade dafür benötigt werden. Disclaimer: der Edit war zu automatisiert, als dass ich davor gemerkt hätte dass es ein Schweizer Format wird. --✓ ^Bergi 17:44, 5. Aug. 2011 (CEST)

wie gesagt ich würds halt weiterhin Klammern weil so üblich, auch wenn ein weiteres Format folgt. -- visi-on 13:32, 6. Aug. 2011 (CEST)

CoordinateSimple in Tabellen / sortkey

{{CoordinateSimple}} weicht in seiner Darstellung bei gegebenen sortkey von CoordinateFull ab, macht gerade in Tabellen, mit vielen Coordinaten in einer Spalte untereinander stehen, für die diese Variante ja vorrangig gemacht wurde, keinen schlanken Fuß. Siehe Liste der Liste der Segelfluggelände in Deutschland oder

• !547.0000005508.000000547° 0′ 0″ N, 8° 0′ 0″ O simple
• !547.0000005508.000000547° 00′ 00,0″ N, 008° 00′ 00,0″ O478 full

Könntet man dieses Feature auch bei simple=y wieder reaktivieren? danke --Herzi Pinki 10:45, 7. Aug. 2011 (CEST)

Können schon - mit ein wenig Performanceverlust bei allen DM(S)-Ausgaben -, aber schlanker ist die jetzige Ausgabe in der simple-Variante. Ich finde die Zahlen mit den vielen führenden Nullen - besonders die dreistelligen Längengrade - auch schlechter lesbar. Macht es denn überhaupt Sinn, das Ausgabeformat an den sortkey-Parameter zu hängen, oder wäre hier nicht ein eigener Formatparameter wie text=0DMS sinnvoll? Mit der jetzigen non-Simple-Lösung ist man gezwungen, in einer sortierbaren Tabelle das blähigere Format mit den führenden Nullen zu verwenden, auch wenn es aus Platzgründen nicht angebracht ist. --PM3 13:47, 7. Aug. 2011 (CEST) Frage mit gleichzeitigem Danke klingt nach Kommando, finde ich nicht so schön.

sortkey ist für Tabellen gedacht, und nur in Tabellen tritt das Problem der Ausrichtung auf. Insoferne war es naheliegend, die beiden Features über einen Parameter zu steuern. Ein eigener Parameter bricht halt die Erwartungshaltung bei der Ausgabe, man müsste alle Koordinaten in Tabellen mit sortkey um diesen Parameter erweitern. Das andere ist Geschmackssache, aber gefällt dir der Flattersatz wie in Liste der Segelfluggelände in Deutschland wirklich? Ich halte dagegen und den Flattersatz für schwerer zu lesen. lg --Herzi Pinki 14:46, 7. Aug. 2011 (CEST)

Am besten gefällt mir hier die vorherige Variante: [5] übersichtlich dank zweistelliger (!) Längengrade und platzsparend. --PM3 14:53, 7. Aug. 2011 (CEST)

zweistellige Längengrade sind halt deutschlandlastig (DACH lastig), >100° oder <-100° ist halt 3stellig, kommt aber in DACH nicht vor. Man bräuchte dann unbedingt 2 Parameter, 0DMS und 00MDS, die Abstände sind vermutlich aufgrund typographischer Regeln notwendig. --Herzi Pinki 15:25, 7. Aug. 2011 (CEST)

Ich werd in den nächsten Tagen mal die Performance für das Nullen-Auffüllen nachmessen. Wird auf jeden Fall spürbar Zeit kosten, ich schätze in der Größenordnung 4-8 ms pro Koordinate bei Verwendung und 0,5-1 ms pro Koordinate bei Nichtverwendung. --PM3 22:40, 7. Aug. 2011 (CEST)

danke einstweilen. lg --Herzi Pinki 23:00, 7. Aug. 2011 (CEST)

Ich habe zwei verschiedene Implementationen gestet: Eine die Nullen per #ifexpr: ... < 10 generiert, und eine, die das gleiche per padleft macht. Letztere ist etwas schneller und platzsparender; hier die Messwerte:

zusätzliche Ladezeit pro Koordinate	sortkey	text=(0)0DM(S)
bei Nichtverwendung	ca. 0,5 ms	0,5 - 1 ms
bei Verwendung	3 - 6 ms	3 - 6 ms

Die angegebenen Bereiche enstehen im Wesentlichen durch schwankende Serverlasten.

Das heißt:

• Liste der Segelfluggelände in Deutschland lädt mit aufgefüllten Nullen ca. 1 Sekunde länger, d.h. aktuell 9 statt 8 Sekunden.
• Eine Liste mit 1000 Koordinaten - mit der simple-Option kein Problem - würde 3-6 Sekunden länger brauchen.

Speicherplatzbedarf +7%, egal ob man die Option verwendet, d.h. die maximale Koordinatenzahl pro Liste sinkt um 7%. Aktuell liegen wir bei ca. 2000, was man bei 60-80 Sekunden Ladezeit kaum ausreizen wird. Notfalls könnte man den Speicherverlust auch per Zerlegung von {{CoordinateSimpleText}} in 7-11 Einzelvorlagen wieder mehr als wett machen. --PM3 19:49, 12. Aug. 2011 (CEST)

Und nun? --PM3 16:32, 30. Aug. 2011 (CEST)

Bilder in Karte anzeigen

Weder der Link Commons on Google, noch Commons on OSM zeigt Bilder. Gibt es einen neuen Server, der die georeferenzierten Bilder aus den Commons auf einer Karte anzeigt? Vermip 17:05, 10. Aug. 2011 (CEST)

Geht [6] bei dir? (Google Maps läuft hier auf meinem momentanen Rechner nicht, zu viele Einschränkungen) --тнояsтеn ⇔ 17:35, 10. Aug. 2011 (CEST)

Dein Link hätte mein erster Link sein sollen: nein, auch dort sind keine Bilder aufgeführt. Kann ich irgendwo nachschauen, woran es liegt? (Jetzt haben wir eine Unmenge von georeferenzierten Bildern, und zu sehen bekommen wir nur die Bilder von Googles Panoramia...) Vermip 19:51, 10. Aug. 2011 (CEST)

Es hat beides schon funktioniert. Frag einfach mal bei den Erstellern der Tools nach: commons:User:Para und Benutzer:Kolossos. --тнояsтеn ⇔ 08:53, 11. Aug. 2011 (CEST)

Gibt es Alternativen? Oder stützt sich die gesamte Community zur Auswertung georeferenzierter Fotos auf die beiden? Vermip 12:31, 11. Aug. 2011 (CEST)

Ich denke mal bei Para ist die Datenbank irgendwie kaputt. Mein Skript arbeitet, sodass ich wenig machen kann. Fragt mal Para, aber leider ist er nicht mehr alzu sehr aktiv. Seine Tools sind aber wohl zu wichtig sie sterben zu lassen, also wäre es wohl gut wenn jemand mit in die Wartung dort einsteigen würde. --Kolossos 13:00, 12. Aug. 2011 (CEST)

Danke für die Antwort. Sehe ich genauso. Mindestens habe ich mir ein Buch über Open Layers gekauft...

Paras letzter Eintrag ist von Mai. Ohne das Skript macht das Georeferenzieren von Fotos keinen rechten Sinn. Zum Glück ist dein Service für Artikel nicht betroffen. Ließe sich dieses Skript nicht für commons Bilder adaptieren?.

PS: Auch der Service http://olm.openstreetmap.de/ von Rurseekatze ist seit Monaten nicht mehr erreichbar. Vermip 17:11, 12. Aug. 2011 (CEST)

Die Kenntnisse von OpenLayers sind noch nicht mal so wichtig, denke ich. Die Probleme liegenwohl derzeit auf der MySQL/PHP Seite. Bei der Datenbank kommt es auf geschickte Filterkriterien an. Para's Service hat Änderungen an Bildern immer sehr schnell übernommen, da bin ich aber auch überfragt, wie er das im Detail gelöst hatte und wo es jetzt ggf. klemmt. --Kolossos 11:23, 14. Aug. 2011 (CEST)

Es ist etwas erschreckend, daß das Funktionieren solcher zentralen Mechanismen wikipediaweit offensichtlich von einer einzigen Person abhängig ist. Es stellt sich die Frage, ob nicht ein Teil der Spendengelder sinnvoll eingesetzt werden sollte, immer dann, wenn absehbar ist, daß ein freiwilliger Entwickler/Mitarbeiter aus welchen Gründen auch immer (Zeitmangel, andere Interessenschwerpunkte, Krankheit, was auch immer) die Brocken hinschmeißt, solche Projekte in professionelle Betreuung übergehen zu lassen. -- smial 12:10, 20. Aug. 2011 (CEST)

Jerbi hat Recht, die Seiten funktionieren wieder. Dennoch ist deine (S) Frage nicht beantwortet: wer übernimmt die Wartung dieser Dienste? Wer könnte Hinweise geben, wie der Service funktioniert? Wem sage ich dankeschön? Könnte hier nicht Wikimedia.de helfen? Vermip 19:09, 21. Aug. 2011 (CEST)

Von mir ein herzliches Dankeschön an den unbekannten Mitstreiter, der das Problem gefixt hat. Wäre aber vermutlich trotzdem gut, wenn sowas auf mehrere Schultern verteilt wäre. -- smial 11:25, 24. Aug. 2011 (CEST)

Bilder aus einem Webdienst auslesen

Hey Leute, ich bräuchte mal eure Technische Hilfe. Das Bayerische Vermessungsamt hat eine Schnittstelle um Luftbilder mit 2m Bodenauflösung kostenlos nutzen zu können (Web Map Service (WMS) der Bayerischen Vermessungsverwaltung). Das Ding Funktioniert über Web Map Service ( http://www.opengeospatial.org/standards/wms ). Nun hab' ich da wirklich keine Ahnung davon und wollte euch mal Fragen wie es möglich ist dort dann an die Daten bzw. Bilder ran zu kommen? URL wäre http://www.geodaten.bayern.de/ogc/getogc.cgi? . Viele Grüße --Mrilabs 17:42, 19. Aug. 2011 (CEST)

Im einfachsten Fall über den BayernViewer --alexrk 18:01, 19. Aug. 2011 (CEST)

Das Problem ist ich brauch es über diese Schnittstelle - eben das die Bilder (im besten Fall alle) gespeichert werden können. Im Bayernviewer kann ich das ja nur abschnittsweise. Ich brauch die auch genau in der Zoomstufe wie bei dem Interface. Grüße --Mrilabs 20:00, 19. Aug. 2011 (CEST)

Dann bräuchtest Du sowas wie uDig zur Verarbeitung eines WMS-Dienstes. --alexrk 22:26, 19. Aug. 2011 (CEST)

PS: hab gesehen, dass der Dienst eine Beschränkung auf ca 2000x2000 Pixel hat - muss man also zwangsläufig abschnittsweise vorgehen. Allerdings ist so ein WMS-Dienst auch ohnehin nicht zum Saugen gigabyte-großer Datenmengen gedacht (wohl auch nicht im Sinn der Bayrischen Vermessungsverwaltung) --alexrk 12:29, 20. Aug. 2011 (CEST)

Das Programm funktioniert wunderbar, danke schon mal für diesen Tipp. Aber letzteres ist genau mein Ziel ;-) Das Bayerische Vermessungsamt wird die Bilder wohl - wenn alles gut läuft - unter cc-by-sa 3.0 stellen. Viele Grüße --Mrilabs 13:38, 20. Aug. 2011 (CEST)

Abschnittsweise speichern würde ja reichen. Man muss ja nicht gleich die ganze Karte saugen ;-) Grüße --Mrilabs 09:08, 24. Aug. 2011 (CEST)

Südsudan

Hallo erstmal, bin gerade über {{Info ISO-3166-2:SS}} und {{Info ISO-3166-2:SD-23}} gestolpert. Beides ist demnach Südsudan??? Kann das, zumal es die Seite ISO 3166-2:SS nicht gibt? Möchte da aber nicht rumfummeln, wil keine Ahnung. Schaut mal hier - Iso.org-Südsudan --Knochen 22:33, 21. Aug. 2011 (CEST)

Soweit ich das sehe, hat die ISO die Codes der staatlichen Untereinheiten 3166-2 für SS bislang noch nicht festgelegt. Sobald sie festgelegt sind, können wir sie in der WP einarbeiten; jetzt müssen wir jedoch noch abwarten. --Spischot 07:56, 22. Aug. 2011 (CEST)

Also, wenn ich das richtig sehe, steht SOUTH SUDAN - SS in der abrufbaren Liste zur ISO3166-2 schon drin: [7] - Ich würde dann die Seite ISO 3166-2:SS mal anlegen. Gruß --Lambdacore 14:29, 22. Aug. 2011 (CEST)

Spischot, du hast recht, die Liste der ISO-Codes der Bundesstaaten im Südsudan ist noch nicht veröffentlicht. Ich werde die Seite ISO 3166-2:SS analog zur englischen Wikipedia (en:ISO 3166-2:SS) mal anlegen, damit wir überhaupt mal Informationen hier haben. --Lambdacore 17:32, 22. Aug. 2011 (CEST)

Dass der ISO 3166-1 Code auf SS lautet ist unstrittig, aber für eine Seite ISO 3166-2:SS völlig unzureichend. Und auf der englischen Seite steht auch nix Vernünftiges, nämlich nur der ISO 3166-1-Code und die alten SD-Codes. Ich halte es für unsinning, veraltete Informationen an falscher Stelle einzupflegen. Und einen Artikel, der als einzige Information den Hinweis enthält, dass Informationen noch nicht vorliegen, halte ich auch für wenig hilfreich. --Spischot 18:57, 22. Aug. 2011 (CEST)

In Vorlage:Info ISO-3166-2:SS steht nun "Diese Vorlage enthält Daten auf der Basis der ISO 3166-2:SS-Liste", was falsch ist. --PM3 22:53, 23. Aug. 2011 (CEST)

Positionskarten - Was bedeuten die X/Y-Angaben in der Poskarten-Info?

Aus dem Archiv widerhergestellt:

Hallo, kann mir jemand sagen, welche Bedeutung die x/y-Prozentwerte in der Poskarten-Info haben ,bzw woraus die sich herleiten - zB hier? --alexrk 20:04, 13. Mär. 2010 (CET)

x/y-Prozentwerte werden dort angegeben, wo die Positionskarte als Kegelprojektion genutzt wird. (diese gibt es). Wie man die Werte erhält kann ich allerdings nicht sagen. Sie werden irgendeine Relation auf der Kegelprojektion angeben. Der Umherirrende 20:11, 13. Mär. 2010 (CET)

Siehe Vorlage:Positionskarte#Neue Karten erstellen (ab "Für einige Gebiete wie Kanada oder Russland...") --тнояsтеn ⇔ 20:13, 13. Mär. 2010 (CET)

Dank für die schnelle Antwort - also ich weiß, dass das für diese Spezialprojektionen ausgegeben wird. Ich weiß nur nicht, welche Bedeutung man von Fall zu Fall diesen Werten zuschreiben kann. Also für die Antarktis irgendwas von 52.64% und -101.64% - da kann ich mir keinen Reim drauf machen. Interessiert mich nur, weil STyx von der FR-WP grad gefragt hat, da er wohl gerne eine Gegenüberstellung der DE- und FR-Positionskartenvorlagen machen möchte. --alexrk 20:26, 13. Mär. 2010 (CET)

Bedeutung der Werte steht doch im von mir oben angegebenen Link: x und y sind Formeln, um aus den Koordinaten die relative Position der Markierung in Prozent zu berechnen. x reicht von 0 am linken bis 100 am rechten, y von 0 am oberen bis 100 am unteren Rand der Karte. Bei diesen Projektionen verlaufen die Längen- und Breitengrade eben nicht linear (bezogen auf die Kartengrafik). --тнояsтеn ⇔ 20:31, 13. Mär. 2010 (CET)

Die Bedeutung der Formeln im Quelltext ist wohl jedem klar. Ich denke mal, es geht um die „ausgerechneten“ Werte, die auf den einzelnen Seiten angezeigt werden, bei Vorlage:Positionskarte Antarktis: x = 52.646948309708 % und y = -101.64356710175 %. Diese Werte kommen dadurch zustande, dass die Variablen {{{2}}} und {{{3}}} standardmäßig den Wert 1 haben. Sie beschreiben also die Position des Punktes 1° N, 1° O auf der Karte und haben keine spezielle Bedeutung. --Entlinkt 20:44, 13. Mär. 2010 (CET)

Das meinte ich. Vielen Dank. --alexrk 20:50, 13. Mär. 2010 (CET)

Gibt es einen besseren Vorschlag? Keine Wertangeben führen zu Fehlermeldungen, daher hatte ich mal die 1 angegeben. Der Umherirrende 20:54, 13. Mär. 2010 (CET)

Die angezeigten Werte sind auch nur die Berechnung der im Quelltext hinterlegten Formel für den Wert 1. Sie haben an sich keine Aussage. Viel wichtiger scheint mir die Formel zu sein. Die Positionierung der Marker auf der Positionskarte scheint mir in Prozent zu sein. Wenn man sich den HTML-Quelltext der Seite anschaut, sieht man auf jedem Fall, das dort Prozentwerte stehen. Ganz sicher bin ich mir nicht, da ich nicht der Entwickler dieser Version der Positionskarte bin. Benutzer:Visi-on wird hier sicher besser Auskunft geben können. Der Umherirrende 20:54, 13. Mär. 2010 (CET)

Man könnte einfach die Formeln an sich ausgeben. Da die Formeln ohne #expr eingegeben werden sollen (#expr kann mit eingegeben werden, ist aber nicht notwendig), sollte es keine Fehlermeldungen geben. Alternativ könnte man 0 statt 1 nehmen. Schließlich ist der Ursprung des Koordinatensystems nicht bei 1° N, 1° O, sondern am Schnittpunkt von Äquator und Nullmeridian. Eine spezielle Bedeutung hätten die Werte aber auch dann nicht. --Entlinkt 21:08, 13. Mär. 2010 (CET)

Ich habe die Werte mal auf 0 gesetzt. Weglassen kann man sie nicht, da das #expr in der Vorlage steht, somit kann man die Formel nicht ausgeben, sondern es wird immer gerechnet. Der Umherirrende 21:41, 13. Mär. 2010 (CET)

Da Entlinkt die unnötigen #expr entfernt hat, habe ich jetzt die Anzeige geändert. Das Problem ist nun, das es etwas das Layout zerschießt. Wenn man kein führendes Leerzeichen nimmt, dann passt das Layout nicht mehr, wenn zwei Zeilen vorhanden sind (da diese in der Vorlage mit führendem Leerzeichen anfangen) Der Umherirrende 16:34, 15. Mär. 2010 (CET)

Ay dios mio, da kriegt der ahnungslose Betrachter gleich die ganz große Mathekeule an den Kopf :) Wenn ich mal nur nach Usability-Aspekten gehe, denke ich, am interessantesten dürfte an dieser Stelle eher noch ein Hinweis auf den Namen der Kartenprojektion sein. Das würde natürlich erfordern, dass dies irgendwo in der Vorlage als Parameter dokumentiert ist ...wäre aber vlt ohnehin eine gute Idee, wenn man mal die Formeln aus der Poskarten-Vorlage in wiederverwendbare (pro Projektionsarte eine) Vorlage auslagern wollte. So in der Art, wie es in der FR-WP gemacht wird - wzB hier. --alexrk 16:46, 15. Mär. 2010 (CET)

Diesen Vorschlag habe ich mal aufgegriffen und folgende Vorlagen erstellt:

• Vorlage:Positionskarte/Flächentreue Azimutalprojektion
• Vorlage:Positionskarte Afrika (Test)
• Vorlage:Positionskarte Europa (Test)
• Vorlage:Positionskarte/Info (Test)

Die Vorlagen befinden sich in einem Proof-of-Concept-Stadium. Es wäre zu überlegen, ob es sich lohnt, das weiter zu verfolgen und welche anderen Projektionen sonst noch gebraucht werden. --Entlinkt 18:01, 16. Mär. 2010 (CET)

Ich bin begeistert! Mal kurz überlegen, was man damit gewinnt:

• Die Poskarten-Info könnte man etwas aussagekräftiger und sinnvoller gestalten
• Das Erstellen solcher Poskarten-Vorlagen wird sicher etwas vereinfacht, weil man sich nicht mehr durch die Formeln wühlen muss
• Nachträgliche Änderungen/Korrekturen an den Formeln werden vereinfacht, weil zentral an einer Stelle
• Die Doku, an der hier grad gebaut wird, könnte ebenfalls etwas transparenter gestaltet werden

Weitere Kandidaten wären bislang:

• Mittabstandstreue Azimutalprojektion in Pollage - zB Antarktis - Parameter sind hier dokumentiert (kann man natürlich statt faktorH auch dx nennen, um es alles zu vereinheitlichen)
• Längentreue Kegelprojektion - zB Russland (hier müssen noch die Parameter geklärt werden)

Ggf Probleme, offene Fragen:

• Was wäre dann mit Karten mit Einklinker wie USA - ich hätte kein Problem damit, wenn in solchen (sehr seltenen) Fällen man halt nicht die Projektionsformel-Vorlage wiederverwenden kann, sondern man die x/y-Formeln wie bisher direkt in die Poskarten-Vorlage schreiben muss.
• Projektionszentrum wäre optional, nur anzeigen wenn latitude/longitude gesetzt --alexrk 20:08, 16. Mär. 2010 (CET)

Ich bin sehr dafür. Zur Frage nach weiteren Projektionen: Wie wär's mit der Mercator-Projektion und der UTM-Projektion? Dann könnten wir z.B. diese Karte nutzen bzw. hätten die Haiti Karten (1, 2) schon nutzen können, bevor die Karten als Plattkarten neu gemacht (1, 2) wurden. Vermutlich gibt es weitere Beispiele. Dabei liegt mit fern, Mercator als bevorzugte Projektionsart für neue Karten zu etablieren - vielmehr soll vorhandenes Kartenmaterial ausgenutzt werden. --Spischot 15:17, 19. Mär. 2010 (CET)

bzgl UTM und Mercator: wie Du schon angedeutet hast, im Poskarten-Bereich im Prinzip nicht weiter relevant. Wäre nur von Interesse, um bestehende Karten einzubinden (für die es noch keine fertige Poskarte gibt). Ich bezweifle aber, dass sich da der Aufwand lohnt. Man müsste ja auch jeweils erstmal die genaue Kartenbegrenzung und UTM-Zone ausknobeln (für Karten ohne Gradnetz schwierig). Und dann wird es vrmtl. nur in jeweils einem Artikel verwendet. Da kann man auch in der Kartenwerkstatt mal nachfragen, ob jemand die gewünschten Punkte einfach direkt in die Karte einzeichnet. Würde ich also mal auf uns zu kommen lassen.

Es wäre vrmtl auch erstmal ausreichend, wenn Du anhand eines Beispiels ein Muster fertig stellen könntest an dem wir uns orientieren und peu á peu weitere Projektionen ergänzen können. Würdest Du die Erweiterung dann in Vorlage:Positionskarte/Info vornehmen, oder wird das dann eine separate Info-Vorlage für diese Zwecke? Die Doku's würde ich dann direkt auf den neuen Vorlagen (also zB hier) ergänzen und bei Vorlage:Positionskarte ebenfalls die Doku anpassen. --alexrk 18:26, 20. Mär. 2010 (CET)

See fr:Aide:Géolocalisation/en.   <STyx @ (I promote Geolocation) 23:41, 30. Apr. 2010 (CEST)

Wiederaufgenommen: Projektionsvorlagen

Ich will das Thema mal wieder aufgreifen. Folgende Kartenprojektionen sind jetzt verfügbar:

Kartenprojektion	Projektionsvorlage	Beispiel für Positionskartenvorlage
Plattkarte	{{Positionskarte/Plattkarte}}	{{Positionskarte Welt (191)}}
Flächentreue Azimutalprojektion	{{Positionskarte/Flächentreue Azimutalprojektion}}	{{Positionskarte Afrika (Test)}}
Mittabstandstreue Azimutalprojektion in Pollage	{{Positionskarte/Mittabstandstreue Azimutalprojektion in Pollage}}	{{Positionskarte Arktischer Ozean (Test)}}
Längentreue Kegelprojektion	{{Positionskarte/Längentreue Kegelprojektion}}	{{Positionskarte Russland (Test)}}
Lineare Kegelprojektion (von hier)	{{Positionskarte/Lineare Kegelprojektion}}	(wird als Untervorlage der längentreuen Kegelprojektion verwendet)
Winkel-Tripel-Projektion	{{Positionskarte/Winkel-Tripel-Projektion}}	{{Positionskarte Welt (W3)}}
Einklinkung von Nebenkarten (alle Projektionen)	{{Positionskarte/Einklinker}}	{{Positionskarte Japan (Test)}}

Damit sind nach meiner Kenntnis alle Kartenprojektionen verfügbar, in denen derzeit Positionskarten vorliegen. Wenn weitere Positionskarten in einer dieser Projektionen gemacht werden, ist die Erstellung der passenden Positionskartenvorlage wesentlich einfacher – vorausgesetzt natürlich, die Parameter sind bekannt. Die {{Positionskarte/Info (Test)}} habe ich jetzt in {{Positionskarte/Info}} integriert; die Test-Vorlage kann gelegentlich entsorgt werden. Außerdem kann man für solche Vorlagen überlegen, die projektionsspezifischen Parameter explizit anzuzeigen und damit die doch etwas seltsamen x- und y-Ausgaben zu ersetzen. Die oben angefragten Einklinker sollten mithilfe dieser Vorlagen auch kein größeres Problem sein. --Spischot 21:07, 23. Aug. 2011 (CEST)

Das ist super! Die Parameteranzeige in der Info-Vorlage habe ich soeben eingebaut. Noch zu klären wäre:

1. Die expr-Tags kann man evtl. noch weglassen, sie würden eine Anzeige der Formel ermöglichen falls das irgendwann mal (wieder) gewünscht wäre
2. Die lineare Kegelprojektion macht Probleme: (1) der Parameter dx steht eigentlich für die horizontale Ausdehnung der Karte (in Winkelgrad), wird hier aber als horizontaler Skalierungsfaktor gebraucht. Das erschwert eine korrekte Anzeige, besser wäre die Umbenennung in sx. (2) Und statt einem aspectRatio würde ich eher einen y-Skalierungsfaktor dazu erwarten, genau kenne ich mich mit Projektionen auch nicht aus.
3. Die längentreue Kegelprojektion nutzt die andere Vorlage mit und übergibt ihr einen Default-Wert für dx, der damit in die Ausgabe gelangt. Entweder sollte die Ausgabe abgefangen werden (im selben #switch wie projection) oder die "Unter"vorlage mit leeren Parametern zurechtkommen.

Was meinst du eigentlich mit den Einklinkern? In die undurchsichtigen Projektionsvorlagen Einklinkoptionen einzubauen halte ich für ziemlich unmöglich. Wenn dann könnte man eine Vorlage für Plattkarten mit Parametern für Einklinker erstellen. --✓ ^Bergi 18:56, 25. Aug. 2011 (CEST)

Die Parameteranzeige finde ich klasse, Danke. Es gibt allerdings noch ein paar kleine Probleme dabei. Diese werde ich bei nächster Gelegenheit dort ansprechen. Zu 1: Klingt sinnvoll, ich schaue mir an, ob das ohne Nebeneffekte klappt. Zu 2.1: Verstehe, schaue ich mir am Wochenende mal an. Zu 2.2: Mathematisch sind dx, dy, und aspectRatio wechselseitig ersetzbar. Karthographisch ist dx für eine getreckte bzw. gestauchte Karte gedacht während aspectRatio für den Kartenausschnitt (auch bei nicht verzerrten Karten) notwendig ist. Diese verschiendenen Sachverhalte in einen gemeinsamen Parameter zu verwursten erschwert aus meiner Sicht die Anwendung unnötig. Zu 3: Stimmt; werde ich umbauen. Zu Einklinkern: Ich meine, dass man zukünftig solche Vorlagen leichter implementieren kann, indem man eine Fallunterscheidung der Position macht, und je nach Fall eine Projektionsvorlage aufruft und das Ergebnis (x und y) einfach wieder zusammensetzt. Ist nicht akkut – ich wollte nur alexrks Befürchtung von oben entgegentreten, dass die Projektionsvorlagen in diesem Fall nicht anwendbar seien; das Gegenteil ist richtig. --Spischot 20:03, 26. Aug. 2011 (CEST)

Parameter sind jetzt vereinheitlicht und in der {{Positionskarte/Info}} nachgezogen. Btw: Ist der Kommentar |NS={{#expr:{{{{FULLPAGENAME}}|latitude}}}}<!-- funktioniert nicht bei Kegelprojektion! --> eigentlich noch berechtigt? Ich kann im Moment keinen Fehler erkennen. --Spischot 12:30, 28. Aug. 2011 (CEST)

Der Kommentar ist hinfällig, ich hatte erst danach gesehen dass in diesem Fall latitude in der Projektionsvorlage aus latitude1 und latitude2 ausgerechnet wird.

Danke für die Parameterumbenennungen, bei der Vorlage:Positionskarte/Flächentreue Azimutalprojektion stimmt das aber noch nicht ganz: bei den beiden Beispielen werden die dx/dy-Parameter immer noch als (unwahrscheinlich hohe) Skalierungsfaktoren ausgegeben. --✓ ^Bergi 13:40, 2. Sep. 2011 (CEST)

Die unwahrschienlich hohen Skalierungsfaktoren durchblicke ich nur teilweise. Fakt ist, dass die Faktoren lineare Streckungen bewirken – so gesehen ist die Beschreibung nicht völlig abwegig. In der ersten Version hatte Entlinkt diese Parameter wohlweislich gar nicht beschrieben und die französiche Vorlage, von der die Parameter stammen, bleibt leider auch sehr vage. Es stimmt schon, dass die Parameter mehr machen, als nur zusätzliche Streckung/Stauchung gegenüber dem Standardwert. Daher ist ein Vorgabewert von 1 auch ziemlich sinnfrei. Falls ich eines Tages mal das Aufziehen auf die „normale“ Größe begreife, würde ich diese gerne über einen getrenntes Parameter-Pärchen rausziehen und dokumentieren, sodass für dx/dy nur noch die Zusatzverzerrung mit einem Wertebereich rund um Faktor 1 übrig bleibt. Bis dahin würde ich es einfach so lassen. --Spischot 17:43, 11. Sep. 2011 (CEST)

Außerdem noch: Ich habe noch {{Positionskarte/Einklinker}} erstellt, mit der man Nebenkarten in beliebigen Projektionen einklinken kann. Damit auch Plattkarten funktionieren, gibt’s auch die {{Positionskarte/Plattkarte}}. --Spischot 23:26, 11. Sep. 2011 (CEST)

OK, dann lassen wir die Skalierungsfaktoren erstmal so.

Die Einklinkervorlage macht den Quelltext imho eher komplizierter als einfacher. Die Japan-Vorlage habe ich mal vereinfacht, die Einklinkervorlage selbst sollte man auch noch verbessern. So kann doch eigentlich alles, was nicht der Ausgabe von x/y dient, vernachlässigt werden, da es sowieso nicht verwendet wird? Zudem geschieht die Entscheidung, ob der Einklinker verwendet wird, noch immer mit nict ganz koscheren (nur vereinfachten) Formeln in der jeweiligen Poskartenvorlage. Wirklich sinnvoll fände ich nur eine Einklinkervorlage, die man in x/y einbindet, und die selbst untersucht ob die übergebene Koordinate in ihrem Bereich liegt um dann die Prozentwerte zurückgibt. Zudem würde ich Projektion=Plattkarte lieber in der Einklinkervorlage abfangen und gleich berechnen, anstatt in eine eigene Plattkartenprojektionsvorlage auszugliedern.

Allerdings: Die umfassende Umstellung auf die Plattkartenvorlage, die gleich x/y zurückgibt, könnte die Poskarteneinbindung durchaus beschleunigen. --✓ ^Bergi 15:35, 12. Sep. 2011 (CEST)

Ich glaube, du hast bei deinen Argumenten so manches übersehen. Bei Einklinkern sollte es keine Annahmen über die Projektion von Haupt- und Nebenkarte geben. So ist es durchaus sinnvoll, Alaska in Kegelprojektion als Nebenkarte der 48er-USA ebenfalls in Kegelprojektion mit abweichenden Parametern darzustellen. Die Grenzziehung zwischen den Kartenteilen (bei Japan der 31. Breitengrad) ist in gewissen Maß willkürlich und lässt sich im Allgemeinen automatisiert weder aus den Grenzen der Haupt- noch aus denen der Nebenkarte ableiten. Bei meiner Implementierung der Einklinkervorlage habe ich mir zweitweise einen abgebrochen und war froh, als es dann irgendwie funktionierte. Die doppelte Einbindung der Hauptkartenprojektsvorlage war natürlich suboptiomal und kann durchaus schöner gelöst werden. Mein Hauptanliegen war, zu zeigen, dass die Einklinker gut mit Projektionsvorlagen harmonieren und ein Beispiel zu zeigen, wie man sowas machen kann. Deine Version, die gleich einen Spezialfall ausnutzt, um den Code oder gar die Ausführungsgeschwindigkeit zu optimieren, dafür aber die Allgemeingültigkeit opfert, finde ich für diesen Zweck nicht so toll. :-(

Womit du wiederum recht hast: Name, lemma, image, usw. brauchts für die x/y-Berechnung nicht und braucht in der {{Positionskarte/Einklinker}} daher auch nicht durchgeschleift zu werden. Allerdings entscheidet letztlich die Projektionsvorlage darüber, wass zur x/y-Berechnung herangezogen wird. Während die eine Projektion longitude nur als informativen Output verwendet, ist das bei der anderen Vorlage auch ein wesentlicher Input. Ich hab’ der Einfachheit halber mal alles mögliche durchgeschleift, auch um die Einklinker-Vorlage möglichst dumm zu halten. --Spischot 16:28, 12. Sep. 2011 (CEST)

Liste von Bergwerken im Harz

Kann es sein, daß die Vorlage Coordinate ab einer bestimmten Menge von Verwendungen in einem Artikel nicht mehr richtig funktioniert? Liste von Bergwerken im Harz#Wildemann, dort ab Eintrag "Grubenzug im Hüttschental, Tagesstollen" haut es nicht mehr hin. Wenn ich den Abschnitt Wildemann zum bearbeiten öffne, sieht in der Voransicht alles normal aus. In den Gesamtartikel komme ich nicht rein, sondern kriege eine Fehlermeldung vom Server. Anlaß war diese Anfrage. Glückauf! Markscheider Disk 20:50, 24. Aug. 2011 (CEST)

Das ist ein bekanntes Problem, wenn große Mengen an Koordinaten in einem Artikel auftauchen. Dafür wurde der Parameter simple eingeführt. Schau mal hier: Vorlage:Coordinate#Vorlage zu langsam? --тнояsтеn ⇔ 08:10, 25. Aug. 2011 (CEST)

Koordinaten in Weiterleitungen, wieder einmal

oftmals diskutiert - nun sehe ich, sowohl OSM, wie auch google und bing werten inwischen die koordinaten auch in WLs tadellos aus, und die WL-technologie klappt auch beim anklicken tadellos - für die kategorien/allcoord wäre es im sinne der vollständigkeit der abbildung natürlich sehr lustig
ich halte es jedenfalls für eine enorme inverstition in die zukunft. bei den weiterleitungen ist kategorisieren, und zwar vollständig, inzwischen ja standard (aktuell im rahmen wiki loves monuments etwa WL schlosskirche → schloss, klosterkirche → kloster uä, weil wir uns geeinigt haben, nicht die schlösser/klöster in den kirchenkategorien einzutragen, sondern die kirche nach ihrem namen, sie aber durchwegs bei der anlage beschrieben sind - aber auch der klassiker der ortsteile, nebengipfel, usw.). ich setzte nun im zielartikel konsequent einen hinweis, unter welchem lemma die WL katalogisiert ist (template: <!-- Kirchenkategorien in Weiterleitung [[]] -->), und dort ist dann auch der platz für die koordinate, sodaß wir keine doppeleinträge bekommen. und bei allfälligem auslagern eines untersachverhalts ist dann gleich die infrastruktur (lemma, koord, kats) schon fachkundig gemacht (etwa wenn die klosterkirche im lauf der zeit eigenständig groß-artikeltauglich wird und den rahmen des klosters schon strengt: Beispiel Stiftskirche und Bibliothek aus Stift Admont herausgezogen, jetzt wieder runderer artikel, aber die drei museen könnte man auch herausziehen, dort überbewertet, dann ausbaufähiger artikel: WLs für die museen wären jetzt schon angemessen)
daher die frage:

1. gibt es technische oder wartungsmässige probleme, sich das anzugewöhnen? gibt es einen expliziten grund, es NICHT zu machen?
2. und, wenn wir es machen, hat es sinn, eine wartungsinfrastruktur "WL mit Koordinaten" zu erstellen? --W!B: 14:39, 5. Sep. 2011 (CEST)

nachtrag: testen etwa: Schlosskapelle Thörl → Schloss Thörl, in Dekanat Bruck (Steiermark); Kategorie:Dekanat Bruck (Steiermark), Kategorie:Barbarakirche, usw.

seltsamerweise gibt es probleme, anfangs waren sie da, nun aber nicht mehr, wieso? werden WLs automatisch aus der datenbank entladen? --W!B: 14:57, 5. Sep. 2011 (CEST)

Noch ein weiterer Wunsch zum Thema: ist es technisch machbar, die Koordinaten auf der Weiterleitungsseite anzuzeigen (sind bisher im Quelltext "versteckt")? --тнояsтеn ⇔ 15:10, 5. Sep. 2011 (CEST)

Dieser Edit sollte rückgängig gemacht werden, das Koordinatenformat stimmt so nicht. Ansonsten: Kategorien in WL werden von MW sonderbehandelt, es wird immer noch nicht der Seiteninhalt ausgewertet (Vorlagen expandiert, Wikitext geparst); dazu gibts auch Bugreports. Als Begründung gilt, dass man die WL-Seite nicht ver(wiki)linken kann, ihren Inhalt also kein Otto Normalo zu Gesicht bekommt. Die Diff-Ansicht mag das anders machen, dürfte ein Problem des JS-Nachladens von Seiteninhalten sein.

Zum Thema: Das mag ja ganz sinnvoll sein, aber kommt es nicht dadurch zu Doppelkoordinatisierung? Wenn die Koordinate der Schlosskirche bekannt ist und diese im Schlossartikel beschrieben wird, wird eine Fließtextkoordinate dort auch eingesetzt werden. Werden jetzt beide Artikel in der Karte dargestellt, hat man einen Poppel zu viel. Dazu kommen noch Vor- und Nachteile der Redundanz. --✓ ^Bergi 15:18, 5. Sep. 2011 (CEST)

(ja danke, schon entdeckt, mein fehler, klappt eh tadellos)

und ja: das dürfte nur tief in der wikimedia-software möglich seien, es wird ALLES ausgeblendet, was auf der seite ist, versuch mal irgendeine vorlage, oder 5 KB text einzustellen - dazu müssten wir eine developper-anfrage stellen - jedenfalls steht die koordinate als <input type="hidden"> drin, nicht als geoclass

und zur kirche, nein, die schlosskoordinate liegt am hauptbau, die kirchenkorrdinate am kichentrakt nebenan, zu überprüfen über Kategorie:Thörl, wo beide drinstehen, schloss und kirche: sie liegen schön beisammen --W!B: 15:23, 5. Sep. 2011 (CEST)

Bug 14323 meinst du wohl (und soo viele duplicates). Bei <input type="hidden"> hast du dich verguckt, ich vermute mal du meinst dass die Vorlage nur im Quelltext und damit in der textarea vorkommt.

Zur Kirche: Ich meinte wenn die Kirche im Schlossartikel auch eine Fließtextkoordinate bekäme, würden zwei Boppel auf demselben Punkt liegen. Schon jetzt ist das Schloss ja auch in der Liste der denkmalgeschützten Objekte in Thörl enthalten, wo es eine Koordinate hat, die eigentlich mit der Artikelkoordinate von Schloss Thörl übereinstimmen sollte. Dadurch gibts auf der Karte dasselbe Objekt zweimal, entweder fälschlicherweise nebeneinander oder überflüssigerweise zweimal auf demselben Fleck. --✓ ^Bergi 16:50, 5. Sep. 2011 (CEST)

darum, koordinaten permanent auf doppeleinträge nachzukontrollieren, kommen wir nie herum, weil man nie weiß, welchem autor es einfällt, wo eine zu setzen - das ist davon, wo sie steht, völlig unabhängig: ob in der WL, kann auch in einer liste sein, im ortsartikel oder sonstwo (wie man an den denkmallisten sieht)

(zu Thörl: in dem fall machts nichts, das denkmal ist ein ensemble, angegeben ist die amtliche adresse, und es passt sogar gut, dann die einzelnen gebäude aufgeschüsselt zu haben: wie man sieht, "Tor-" und "Jägerturm" fehlen eigentlich verortet: es ist also kein doppeleintrag, sondern eine detaillierung einer anlage/gebäudekomplexes) --W!B: 17:03, 5. Sep. 2011 (CEST)

Revolutionäre Idee

Warum eigentlich kategorisieren wir georeferenzierbare Objekte eigentlich nicht direkt über die Koodinatenvorlage? Es ist eigentlich ziemlich nervig, wenn ich auf meiner Beobachtungsliste etwa sehe, daß die zig von mir angelegten Artikel zu Brücken im Laufe der Zeit von Kategorie:Brücke in den Vereinigten Staaten nach Kategorie:Straßenbrücke in den Vereinigten Staaten und Kategorie:Bogenbrücke in den Vereinigten Staaten und schließlich weiter nach einzelnen Straßenbrücken- und Bogenbrückenkategorien für einzelne Bundesstaaten und sogar große Städte hin und hersortiert werden.

Warum eigentlich gibt es nicht zu jedem Artikel gesonderte Metadaten mit Koordinaten, Sortierschlüssel, Kategorien, Interwiki und die Software zeigt direkt die Artikelkoordinaten an und bildet anhand der Kategorieangabe "Bauwerk" dann gleich die Kategorie:Bauwerk in Mannheim? Und warum geht das nicht vollig automatisch, das benötigte Kategorien angezeigt werden und nicht benötigte nicht. Warum kann man nicht in den Einstellungen definieren, ob man Winzkategorien will oder nicht. Warum eigentlich funktioniert eine CatScan-ahnliche Funktion nicht direkt in der MediaWiki und warum werden Kategorien nicht dynamisch nach Benutzerwunsch angezeigt?

Daß Mediawiki das derzeit nicht kann, ist klar, aber warum drängen wir nicht darauf, daß das in Zukunft möglich ist? Auch die Anforderungen an die Server wären ungleich größer, aber warum nicht darin investieren, statt in Kätzchenverteilsoftware und in Studien, ob Bildfilter notwendig sind? Millionen jährliche Kategorisierungsedits sind eigentlich völlig überflüssig. Die übrigens auch Serverperformance kosten. Nur mal so ins unreine gedacht. Entschuldigung für die Störung. --Matthiasb ^{(CallMyCenter)} 09:53, 16. Sep. 2011 (CEST)

Map24 in Nokia Maps aufgegangen

Der Link funktioniert leider nicht mehr. Nokia Maps verwendet Links folgender Art:

http://maps.nokia.com/services/#|50.1103731|8.6824651|14|0|0

(Koordinaten werden gefolgt von Zoom Level, hier 14, leider keine genaueren Infos zu den Parametern)

--Trifi 19:21, 17. Sep. 2011 (CEST)

Koordinatensymbol für Bahnstrecken

Moin, wegen der Einbindung von Koordinaten in Streckentabellen von Bahnstrecken gibt es ein Ergebnis. Leider stellt sich heraus, dass das ICON0 nicht auf allen Plattformen angezeigt werden kann. Dies ist natürlich nicht besonders nutzerfreundlich. Gibt es eine gute Alternative, was stattdessen verwendet werden könnte? Vielen Dank --Richtest^D 23:20, 17. Sep. 2011 (CEST)

Dezimalkoordinaten

Für Vorlage:Bilderwunsch bräuchte ich die Koordinaten in reiner dezimaler Form in WGS84. Gibt es eine Vorlage, die mir bei allen möglichen Eingabeformaten eines Längengrades bzw. Breitengrades der Coordiante-Vorlage den Dezimalwert zurückgibt? Also wenn dort z.B. 50/8/8/N steht bräuchte ich 50.1355. Merlissimo 20:00, 25. Sep. 2011 (CEST)