Wikipedia Diskussion:WikiProjekt Georeferenzierung/Archiv/2011-III

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

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

[[Wikipedia Diskussion:WikiProjekt Georeferenzierung/Archiv/2011-III#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

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

⊙

Das ICON0 von {{Coordinate}} erscheint bei mir nur als ein kleiner, windschiefer Knubbel: ⊙ Formatiere ich es dagegen mit <span style="font-family:monospace;"> als monospaced, wird es recht ansehnlich: ⊙. Dass das Ganze system- und CSS-abhängig ist ist mir klar. Trotzdem mal die Frage: Ist das bei euch auch so, dass „⊙“ besser aussieht als „⊙“? Vielleicht wäre es ja einen Versuch wert, das Ding generell mit <span style="font-family:monospace;"> zu formatieren. --PM3 03:47, 21. Jul. 2011 (CEST) PS: Screenshot

Kann ich nich betätigen: Unter Win7+FF5 und Win7+IE9 sind beide schön. Unter XP+IE8 und XP+FF5 sind beide kleiner und eckiger, die <span style="font-family:monospace;">-Version schlechter. Bei anderen Browsern und Systemen gibt's bestimmt wieder andere Resultate. Besser Finger weg von solchen "Unterstützungen", die Browser- oder Font-Schwächen übertünchen wollen. --Spischot 06:11, 21. Jul. 2011 (CEST)

Sehen beide nicht so toll aus. Irgendwie unrund. Google Chrome (akt.), auf Vista und auf XP probiert. --Hedwig in Washington (Post?)•B 06:40, 21. Jul. 2011 (CEST)

Auf Win7 mit Opera, Firefox und IE kein Unterschied und beide schön rund. --тнояsтеn ⇔ 17:49, 21. Jul. 2011 (CEST)

Das dürfte von der Schriftgröße (die bei <tt> ein wenig anders sein mag) und lokalen Antialiasing-Fähigkeiten abhängen. Auf meinem Laptop ohne ClearType ist das Pixel in der Mitte eines geradzahlig-pixel-breiten Kreises immer verschoben, mal links oben, mal rechts unten. Dazu kommen noch Probleme, weil das Schriftzeichen aus keinem Standardfont stammt. Ich wäre für rausnehmen :-)

Das Rendering dürfte verschieden genug sein, dass es sich nicht lohnt ein semantisch falsches, den Parser zusätzlich belastendes Tag einzubauen. --✓ ^Bergi 18:36, 21. Jul. 2011 (CEST)

ok, schade --PM3 18:43, 21. Jul. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --PM3 18:43, 21. Jul. 2011 (CEST)

Keine Koordinate - Störung?

Im Artikel Klauser (Unternehmen) wird keine Koordinate (oben rechts) angezeigt, liegt eine Störung vor? Vor ein paar Tagen ging es noch. --Atamari 10:48, 21. Jul. 2011 (CEST)

Das ist doch der Artikel mit der Zuerich-Koordinate gewesen? Oh, schlechte Erinnerungen..... :) Heftiges Replication lag auf S3 lt Toolserver Koennte das Problem sein. Kolossos?? --Hedwig in Washington (Post?)•B 11:13, 21. Jul. 2011 (CEST)

War ein Backslash zuviel bei den Einzelnachweisen. Habs repariert. --тнояsтеn ⇔ 11:23, 21. Jul. 2011 (CEST)

Danke. (Kleiner Fehler - große Auswirkung). --Atamari 11:28, 21. Jul. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Atamari 11:28, 21. Jul. 2011 (CEST)

Wo Georef?

Kollege Platte hat mich gebeten, in Artikeln ueber

„Bahnstrecken (wo mehr als ein Punkt nötig wäre), Unternehmen oder sonstigen abstrakten Gebilden, die zur besseren Auffindbarkeit in den Ortskategorien untergetaucht sind.“

– Platte in Benutzer Diskussion:Hedwig in Washington#Lagewünsche

keine Koordinaten, bzw. den Lagewunsch einzutragen. Haben wir hier eigentlich eine Art Arbeitsgrundlage, sprich Liste, ueber Lemmata die referenziert werden soll, bzw. keine Koordinate haben sollen? M.E. sollten moeglichst alle Artikel, soweit nicht beweglich :), referenziert werden. Bahnstrecken koennten z.B. Start- und Endziel, sowie besondere Merkmale der Strecke, im Text verlinken. Was denkt Ihr? --Hedwig in Washington (Post?)•B 17:08, 19. Jul. 2011 (CEST)

Wir haben durchaus schon georeferenzierte Bahnstrecken, bei denen der Artikel auf den Start- bzw. Endpunkt verlinkt ist.

Für Unternehmensartikel mit mehreren Standorten haben wir eine eindeutige Zuordnung, nämlich Einordnung nach dem Sitz der Muttergesellschaft (des Konzerns). Nur nach diesem Kriterium wird in Kategorien eingeordnet, und danach lässt sich auch georeferenzieren. Hin und wieder kann man Ausnahmen machen, wenn der Sitz nur ein kleines Büro mit Briefkasten irgendwo ist, aber der bekannte Unternehmensort eine große Fabrik woanders. So einen Fall hatte ich letztens; da hab es der Fabrik zugeordnet.

Etwas gestolpert bin ich über die HiW-Bot-Lagewünsche für verteilte Objekte wie Stadtbefestigung Koblenz. Wo soll man das zuordnen? Die Festung Mainz hab ich auf die Zitadelle als fortbestehendes Hauptbauwerk verlinkt - aber was macht man bei Koblenz? Auf irgendein kleineres Relikt setzen? --PM3 18:58, 19. Jul. 2011 (CEST)

Also bei Bahnstrecken können die einzelnen Betriebsstellen (in der Streckenbox) georeferenziert werden und dann wird die Vorlage All Coordinates eingebunden (Beispiel_ Benutzer:Richtest/Aartalbahn. So ähnlich würde ich das bei der Stadtbefestigung auch machen, damit hat man dann direkt Zugriff auf eine Lagekarte mit allen wichtigen Objekten.. --Richtest 19:11, 19. Jul. 2011 (CEST)

Klar, nur ist das keim Job für das WP:GEO-Projekt, das die Lagewünsche abarbeitet, sondern für die jeweiligen Artikelautoren. Da muss ja überhaupt erst mal eine systematische Liste mit den Einzelteilen erstellt werden. Wenn das direkte Eintragen von Koordinaten nicht möglich ist, sollte sowas m.E. nicht in Kategorie:Wikipedia:Lagewunsch auftauchen.

Kann man den Lagewunsch-Baustein in so einem Artikel durch einen Vermerk ersetzen, der weitere Bot-Einträge verhindert? Oder genügt es, dein einfach auszukommentieren und mit einem kleinen Kommentar zu versehen? --PM3 19:36, 19. Jul. 2011 (CEST)

Die Eisenbahner diskutieren gerade ueber die Koordinaten in der Streckenbox. Ja, bei solchen Dingen wie der Stadtbefestigung bin ich auch am gruebeln. Schoen waere natuerlich eine Art Datenreihe auf der Karte zu haben, die den Verlauf (in etwa) nachzeichnet.

Auskommentieren reicht aus (solange {{Coord drinne bleibt) Der Bot sucht nach Lagewunsch und Coord, wenn vorhanden, dann SKIP. Kein Problem. Sollte fuer solche Zwecke wie Stadtmauern -ich denke grad an die Chin. Mauer- eine andere Form des Lagewunsches erstellt werden? KatzeinSchwanzbeiss, da sind wir dann wieder bei All Coordinates. Oder?

Ich baue mal eine How-To-Liste mit div. Objekten. --Hedwig in Washington (Post?)•B 03:43, 20. Jul. 2011 (CEST)

Erster Abriss der Liste hier

Ich darf an folgende Diskussionen (2008) erinnern:

• WP:GEO Disku "Koordinaten für Artikel mit "gestreuten" Objekten"
• und insbesondere Disku zu Hochschulen und Unternehmens

Aus diesem Grund haben wir noch manche nicht georeferenzierte Hochschul-Artikel. Gruß, --emha d|b 11:44, 20. Jul. 2011 (CEST)

Liste ergänzt. Soll ich die Liste in die Doku verschieben? Oder sollten wir eine extra Seite einrichten?? --Hedwig in Washington (Post?)•B 22:57, 20. Jul. 2011 (CEST)

Ich denke, die Liste muss noch etwas reifen, bevor sie auf die Userschaft losgelassen werden kann:

• "Gebäude" -> "Bauwerke"
• Artikel punktförmigen oder flächig-zusammenhängenden Einzelobjekten (Haus, Stadion, Kaserne, Kirche, Flughafen, See etc.) sind trivial, ich denke das braucht man nicht einzeln zu erläutern
• Unternehmen und Organisationen kann man schlecht unter "Gebäude" subsummieren; das ist eine eigene Klasse von Objekten, die man Gebäuden zuordnen kann. Das mit den Briefkasten hast du jetzt sehr wörtlich genommen :-)
• dito Veranstaltungen
• wir haben jede Menge Infoboxen mit Koordinatenangabe: Kategorie:Vorlage:mit Koordinate - da gilt natürlich generell, dass die Koordinaten in die Infobox kommen
• "Stadtmauer, Wall - Besondere Punkte können referenziert werden." Nur, wenn man den Artikel entsprechend umschreibt. Oder ist ein besonderer Punkt pro Objekt gemeint?
• Kanäle kann man teilweise via Infobox Fluss erschlagen
• zentrale Punkte / Mittelpunkte müssen nicht die besten Punkte sein. Genau an den zentralen Punkten stehen z.B. oft die Beschriftungen bei OSM, Google etc., daher setze ich meine Links gerne etwas exzentrisch, damit man sich nicht gegenseitig stört, besonders bei kleinen Objekten wie z.B. Dörfern.
• Eisenbahnstrecken werden derzeit - wie gesagt - teils auch via einem der beiden Endpunkte referenziert. Nicht alle haben Streckenboxen.
• Warum bei einem Stausee nicht einen Punkt im See verlinken, der sich in dem der Staumauer zugewandten Teil befindet? Dann hat man beides mit einem Link erschlagen.

Es gibt viele, viele Details, nach denen man sich richten kann, aber da wird auch jeder wieder seinen persönlichen Stil haben. Bei Gebäuden setze ich die Links z.B. selten in die Mitte, sondern meist etwas in Richtung der Zugangsseite; damit hat man gleiche eine zusätzliche Information untergebracht. Oder gestern hatte ich einen Fußballverein, da gab es als Hauptort das lokale Stadion, aber auch noch Nebengebäude und ein paar hundert Meter ein Vereinslokal. Da habe ich den Link ins Stadion, aber nahe des Eingangsbereichs = in Richtung der anderen relevanten Objekte platziert.

Vielleicht erst mal mit einem einfachen Grundregelsatz anfangen, und uns dann Gedanken um die Problemfälle machen?

1. Wenn Infobox verfügbar: per Infobox einbinden.
2. Wenn es eine zusammenhängende Fläche ist: an sinnvoller Stelle innerhalb der Fläche verlinken. Das kann in der Mitte sein, oder auch in einem besonders markanten / relevanten Bereich.
3. Wenn es eine linienartige bzw. langgestreckte Struktur ist: Wenn möglich an einem besonders markanten / relevanten Punkt, z.B. Startpunkt oder einem der beiden Endpunkte eines Wegs, herausragendes Bauwerk einer Stadtmauer etc. Wenn es keinen besonderen Punkt gibt: irgendwo in der Mitte der Strecke verlinken. Wenn sie geschlossen ist: irgendwo auf der Strecke.
4. Objekte, die sich über verschiedene Orte verteilen: Wenn möglich, das Hauptobjekt verlinken, zum Beispiel
   • den Hauptsitz eines Unternehmens oder einer Organisation
   • den bekanntesten/relevantesten Einzelort
   • das Hauptbauwerk von mehreren

   Wenn dies nicht möglich ist, nur die Einzelteile im Text verlinken, nicht den Gesamtartikel.

Damit hätten wir auch einen Anhaltspunkt für Verkehrswege ohne passende Infobox: Die fallen unter Nr. 3. Für Bundesautobahnen und Bundesstraßen gibt es Strecken-Infoboxen, aber wohl noch ohne Koordinaten.

Vielleicht wäre es auch das Beste, bei den Infoboxen anzufangen, die noch keine Koordinatenfelder haben, z.B. {{Infobox Unternehmen}}. Und dann ggf. in Zusammenarbeit mit den Fachbereichen in der jeweiligen Infobox-Doku erklären, wie verlinkt wird. --PM3 01:43, 21. Jul. 2011 (CEST)

Insbesondere Briefkaesten nehme ich sehr woertlich! ;) Ist auch OMA-safe verstaendlich. Ich werde die Liste entspr. deiner Liste oben erweitern / anpassen. Den Einbau in eine Infobox kannst Du doch sicher hier in einem Satz erklaeren? :))) Ich habe mich die letzten Wochen mit der InfoboxNRHP kraeftig verhoben. Das haette ich in einem Jahr nicht geschafft.

Die Liste wollte ich erstmal hier in die Disku verschieben, btw.

OK, werde stricken gehen..... --Hedwig in Washington (Post?)•B 05:53, 21. Jul. 2011 (CEST)

Besser so? --Hedwig in Washington (Post?)•B 07:29, 21. Jul. 2011 (CEST)

ja --PM3 20:44, 22. Jul. 2011 (CEST)

Verschoben. Danke fuer Deine Hilfe! --Hedwig in Washington (Post?)•B 19:12, 24. Jul. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Hedwig in Washington (Post?)•B 19:12, 24. Jul. 2011 (CEST)

Hilfe benötigt

Ich binde gerade in dem Artikel Liste der Kulturdenkmäler in Frankfurt-Höchst Koordinaten ein – aus unerfindlichen Gründen landet oben rechts am Artikelanfang alles in der Ecke, obwohl sie im weiteren Text auch korrekt angezeigt werden. Bin zugegeben aber Anfänger in der Georef-Syntax. Was mache ich falsch? Herzlichsten Dank im Voraus --Roland.M 20:28, 5. Jul. 2011 (CEST)

Innerhalb von {{Coordinate|article=/|text=/|....}} bedeutet der Parameter "article", daß die Koordinate rechts oben angezeigt wird, der Parameter "text", daß die Koordinate im Text (also dort, wo sie angegeben ist) angezeigt wird. Man kann grundsätzlich auch beide Parameter (oder keinen) angeben, aber rechts oben darf natürlich nur maximal eine Koordinate stehen. Im vorliegenden Fall gehören also die ganzen "article=/|" raus. Dann hat der Artikel als ganzer keine Koordinate, was richtig ist. --Telford 20:54, 5. Jul. 2011 (CEST)

Außerdem musst du noch jeder Koordinate einen sinnvollen Namen, z.b. name=Zuckschwerdtstraße 058|… hinzufügen. Dann müsste es gehen. --Spischot 20:57, 5. Jul. 2011 (CEST)

Ja, das hatte ich vergessen. Was mir auch noch aufgefallen ist: man sollte die Bogensekunden auf maximal 1 Nachkommastelle runden. Dies entspricht etwa 2 bis 3 m Genauigkeit, jede "genauere" Georeferenz ist Augenwischerei. --Telford 21:04, 5. Jul. 2011 (CEST)

Sollte da nicht anstatt text=/ besser text=DMS stehen? Ich dachte text=/ sollte nicht verwendet werden? --Hedwig in Washington (Post?)•B 21:06, 5. Jul. 2011 (CEST)

logisch ist DMS und / meist identisch (soll heißen, erzeugt dieselbe Zeichenkette), allerdings ist DMS etwas performanter, da / in Abhängigkeit von region auf das Koordinatensystem gemappt wird, und dies bei Direktangabe von DMS entfällt. Bei langen Listen mit vielen Koordinaten ist daher DMS vorzuziehen, bei einzelnen Koordinaten oder in der Schweiz (!) eher /. (siehe auch Vorlage:Coordinate#Artikel-_und_Fließtextkoordinate) --Herzi Pinki 21:57, 5. Jul. 2011 (CEST)

Also grundsaetzlich in NICHT-CH Artikeln DMS im Fliesstext und in Listen einsetzen. DMS wird doch genau wie / in der Karte dargestellt. Oder bezieht sich das eher auf externe Anwendungen (Google Maps, GeoHack)?? --Hedwig in Washington (Post?)•B 23:46, 5. Jul. 2011 (CEST)

Habe die bestehenden Coordinaten wie folgt geandert: article=/ entfernt; text=/ mit text=DMS ersetzt; name="" vor region eingefuegt. Die Namen muessen noch nachgetragen werden. Roland.M informiert.--Hedwig in Washington (Post?)•B 23:59, 5. Jul. 2011 (CEST)

Verstehe zwar nur die Hälfte von den letzten zwei Absätzen, aber herzlichen Dank für eure Bemühungen und das Fixen! --Roland.M 00:16, 6. Jul. 2011 (CEST)

Noch nicht ganz erledigt: Roland, bitte trage überall bei name="" einen Sinnvollen Namen des jeweiligen Objekts ein. Positionen ohne sinnvollen Namen machen sich in der Geo-Datenbank (und in Google) schlecht. --Spischot 20:16, 7. Jul. 2011 (CEST)

Man sollte, ich habe es schon auf der Vorlagendiskussion angemerkt, die Eingabemöglichkeite article=/ und text=/ vollständig entfernen. Zum einen verwirrt das nur die Benutzer, zum anderen ist darin Code involviert, der andernfalls nicht notwendig ist. Inwieweit das auf das allgemeinen Performanceproblem bei Listen Auswirkungen hat, weiß ich jedoch nicht. --Matthiasb ^{(CallMyCenter)} 20:05, 12. Jul. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --PM3 04:06, 1. Aug. 2011 (CEST)

Vorlage:Lage

Allgemeine Diskussion

Habt ihr das mitbekommen? --Matthiasb ^{(CallMyCenter)} 22:13, 5. Jul. 2011 (CEST)

jetzt schon, danke. Siehe auch {{Koordinate Weltkugel}}. Die Performance in großen Listen ist halt ein Problem und user sind erfinderisch. Solange die Performance so ist, bleibt das Kämpfen für eine einheitliche Koordintenvorlage ein Kampf gegen Windmühlen. Resignierend --Herzi Pinki 22:27, 7. Jul. 2011 (CEST)

hier der Link zu einem Tool für die Umwandlung von allen Koordinate-Einbindungen aus einem Artikel nach Vorlage:Lage. Es wandelt auch DMS nach Dezimalgrad um. Man sollte aber, bevor man den Artikelinhalt ersetzt, nochmal die Änderungen checken; die Umwandlung ist recht schlicht und deckt bestimmt nicht alle Spezialitäten der Koordinate-Vorlage ab (Schweizer Landeskoordinaten o.ä.) --alexrk 14:39, 8. Jul. 2011 (CEST)

also automatische Konvertierung finde ich aber doch etwa frech. Es handelt sich um eine redundante Vorlage, gegen die ein LA gestellt werden sollte, ... lg --Herzi Pinki 19:21, 10. Jul. 2011 (CEST)

Tja, die Proliferation nimmt ihren Lauf :) In Anbetracht der Performance ist das ja eigentlich auch ein schlüssiger Workaround. Ich habe es mal an einer Straßenliste verglichen: 47sec vs. 6sec für einen Seitenaufruf. Ich versteh nicht, was das Vorlagen-Geraffel an sich hat, dass so eine simple Koordinaten-Vorlage sooo langsam sein kann. Ich hoffe, die führen da irgendwann mal eine vernünftige Template-Engine ein. --alexrk 12:02, 11. Jul. 2011 (CEST)

Angesichts der weitreichenden Auswirkungen halte ich es für absolut problematisch, irgendwelche Hau-Ruck-Lösungen ohne Abstimmung flächendeckend einzuführen. Besser wäre, das erst mal vorher hier zu diskutieren und eine wirklich saubere Lösung zu suchen. Für mein Gefühl ist diese neue Vorlage weniger kiss als quick&dirty, und so was rächt sich bei komplexen Systemen erfahrungsgemäß irgendwann. --Telford 14:55, 11. Jul. 2011 (CEST)

Volle Zustimmung. --тнояsтеn ⇔ 15:05, 11. Jul. 2011 (CEST)

Nichts gegen Diskussionen, nur die Seiten, die jetzt auf die schlanke Vorlage umgestellt wurden, waren definitiv nicht mit der Koordinaten-Vorlage machbar, wenn ein Aufruf über 40 Sekunden dauert. Ich möchte auch nochmal darauf hinweisen, dass das Problem mit der Performance schon seit Ewigkeiten ohne Besserung herumgärte. So wundert es wenig, wenn jetzt eine für Listenartikel brauchbare Alternative auf fruchtbaren Boden fällt. --alexrk 16:04, 11. Jul. 2011 (CEST)

Hey, das hier ist ein Wiki. {{Coordinate}} wurde sicher auch nicht von einem Gremium entworfen sondern begann quick'n'dirty, oder? Man probiert etwas aus, und wenn es gut ist setzt es sich durch, und wenn nicht verschwindet es wieder. So sind übrigens auch das Internet, das WWW und die Wikipedia entstanden. --PM3 23:25, 11. Jul. 2011 (CEST)

Hallo PM3, Hier kannst du die Geschichte der Vorlage Coordinate nachlesen, immerhin währte die Diskussion bis zur finalen und flächendeckenden Umsetzung von Nov. 2007 bis Juni 2009, inklusive einer breiten Diskussion und einem notwendigen Meinungsbild. Die wesentliche Verbesserung, die mit der flächendeckenden Einführung der {{Coordinate}} verbunden war, war die deutliche Verbesserung der Datenqualität der Altdaten (snapshot), aber auch massive Unterstützung bei der Aufrechterhaltung der Datenqualität bei neuen Koordinaten (gemessen im Vergleich zur WP:en), etwa durch kontinuierliche Abarbeitung der Kategorien Parameterfehler und Geographische Lage gewünscht. Ausgangspunkt für die Arbeiten damals war übrigens auch eine Vielzahl von unterschiedlichen Vorlagen für denselben Zweck. lg --Herzi Pinki 05:42, 12. Jul. 2011 (CEST)

Ok, verstehe. Die fehlende Parameterprüfung halte ich auch für ein großes Problem der neuen Vorlage, bzw. für das einzige wirklich ernsthafte. Aber bei Seitenladezeiten über 30 Sekunden hört halt auch der Spaß auf - wenn der Server mal höher belastet ist, kann sich das Vervielfachen (beim Bearbeiten im BNR kommt nochmal Faktor 2 drauf, wegen geringerer Prio auf dem Server), und dann kriegt man Timeouts beim Speichern.

Lösungsmöglichkeiten:

• Eine möglichst weit abgespecke Version von Vorlage:Coordinate, die wenigstens Faktor 3-4 schneller ist
• Ein neuer Parameter geprüft für die Vorlage:Lage, der erst nach Prüfung durch einen Dritten (manuell oder durch einen Bot) gesetzt werden darf. Hilft natürlich nichts bei nachträglichen Änderungen.
• Ein Bot, der regelmäßig alle (geänderten) Artikel mit Vorlage:Lage durchgeht und die Parameter prüft.

Macht alles eine Menge Arbeit. --PM3 06:39, 12. Jul. 2011 (CEST)

• Stelle Löschantrag. --Matthiasb ^{(CallMyCenter)} 07:42, 12. Jul. 2011 (CEST)

Vielleicht bekommen wir aus der angeheizten Diskussion genügend Energie, um eine deutliche Performance.Verbeserung der {{Coordinate}} zu erzeugen. Zwei Denkansätze dazu: Ich habe (erst vor wenigen Tagen) irgendwo in den Diskussionsarchiven eine Diskussion zwischen Visi-on und einem anderen Benutzer gefunden: Der andere bot an, eine Erweiterung {{#coordinate:…}} für die Media-Wiki-Syntax zu schreiben, sofern Visi-on die Spezifikation dazu schriebe, was dieser zusagte. Leider finde ich die Stelle nun nicht mehr (vielleicht findet noch jemand den Link). Diese Lösung wäre aus meiner Sicht sehr sinnvoll. Eine alternativer Ansatz: Ich vermute, dass die Performance vor allem für die Parameterprüfung und die Fehlerbehandlung drauf geht - das müsste man man zunächst mal genau untersuchen. Falls dem so wäre, zahlten wir in der täglichen Anwendung einen aus meiner Sicht unangemessen hohen Preis um wenigen Unterstützern in gelegentlichen Fällen die Qualitätssicherung zu erleichtern. Ein Ansatz könnte daher sein, die Fehlerbehandlung auszukommentieren und nur für wenige Tage im Jahr im Rahmen einer jeweils konzertierten Aktion für kurze Zeit zu aktivieren, um Listen für die Pflege abzufragen. Im Alltag könnte der teue Code auskommentiert bleiben. --Spischot 09:25, 12. Jul. 2011 (CEST)

Halte ich für keine gute Idee, aber wenn, dann umgekehrt: Man ersetze den Inhalt von Vorlage:Lage hin und wieder durch einen Aufruf von Vorlage:Coordinate! Dann hat man (a) optimale Performance da, wo es nötig ist und (b) mehr Fehlersicherheit als bei deinem Vorschlag, weil die allermeisten Artikel weiter Coordinate verwenden und permanent geprüft werden. --PM3 09:45, 12. Jul. 2011 (CEST)

Matthiasb hat in der Löschdiskussion den Vorschlag gemacht, die Unterstützung für "text=/" und "article=/" aus der Vorlage herauszunehmen und alle ensprechenden Vorkommen durch "=DMS" zu ersetzen. Würde das wirklich soviel helfen?

Generell muss man m.E. aber auch nicht an einer einheitlichen Vorlage festhalten, sondern man kann auch eine abgespeckte Version für Tabellen bereitstellen, wo nur die notwendigsten Parameter enthalten sind (NS, EW, type, region, text, name) und nicht z.B. article, map und die ganzen Folgeparameter, dim, globe usw.

Eine schneller arbeitende Vorlage ist jedenfalls unbedingt erforderlich, aus meiner Liste Münchner Brücken habe ich die Koordinaten alle wieder rausgeschmissen. Ist zwar schade (v.a. wegen der jetzt mit der Vorlage:All Coordinates gegebenen Möglichkeiten, aber die Ladezeit war für die Leser einfach unzumutbar. -- Bjs M S 14:42, 12. Jul. 2011 (CEST)

Den Vorschlag, die Option "article=/" aus der Vorlage zu entfernen halte ich im Rahmen der Qualitässicherung und Vereinheitlichung für sinnvoll – ich erwarte daraus allerdings kaum Beschleunigungen bei Aufrufen, die heute schon "article=DMS", denn die "teuren Parserfunktionen" werden in diesem Fall auch nicht mehr aufgerufen.

Der Vorschlag, nur die notwendigsten Parameter in eine schnelle Vorlage aufzunehmen, ist dagegen nicht sinnvoll. Die Anzahl der übergebenen Parameter spielt für die Geschwindigkeit weder bei der {{Lage}} noch bei {{Coordinate}} eine wesentliche Rolle – vielmehr kommt es darauf an, was die Vorlage mit den übergebenen Informationen so alles veranstaltet. Falls wir also eine Vorlage wie {{Lage}} aus Performance-Gründen behielten, spräche alles dafür, möglichst vollständige Informationen zu übergeben damit eine spätere Nachpflege nicht unter dem Informationsverlust zu leiden hätte und damit die Argumente der Gegner bezüglich des Informationsverlustes vom Tisch wären (selbst wenn diese Zusatzinformationen zunächst mal gar nicht verwendet würden). Die lästige Arbeit, diese Parameter beim Aufruf zu bestimmen möchte weiterhin noch erledigt wissen, denn nur der Artikelschreiber kann sagen, welches Objekt er da eigentlich georeferenziert. Nach wie vor bin ich aber eher gegen die zweite Vorlage und statt dessen für eine Beschleunigung der {{Coordinate}}. --Spischot 15:07, 12. Jul. 2011 (CEST)

So Leute, die Vorlage:Lage hat jetzt eine vollständige Plausibilitätsprüfung sämtlicher Parameter, inlusive Einordung in in Kategorie:Parameterfehler und ohne erkennbaren Performanceverlust. Hat mich exakt zwei Stunden Zeit gekostet, den Code dafür ... --PM3 15:33, 12. Jul. 2011 (CEST) (belanglosen Rest gelöscht)

(Quetsch) Danke für die Mühe, schon mal seeeehr interessant! Zum Ersten zeigt es, dass die von vielen für wesentlich erachteten Informationsmengen und auch einige Prüfungen tatsächlich fix gehen könnten, d.h. innerhalb der {{Coordinate}} besteht latentes Optimierungspotential (zumindest das gefühlt Wichtige wird scheinbar erledigt), auch wenn noch nicht klar ist wo und wie dieses Potential gehoben werden kann. Weiterhin ist es spannend, dass die Parameterprüfung nicht pauschal teuer sein muss, wie ich dies noch oben vermutet hatte. Jetzt werde ich wirklich neugierig, wohin die Performance denn verschwindet. Die von mir oben geforderte Performance-Analyse wird jetzt richtig spannend. Ich hoffe, dass ich in den kommenden Tagen ’was rausbekomme. Um Missverständnisse zu vermeiden: Bis auf weitere nehme ich an, dass die {{Coordinate}} schon jetzt recht clever programmiert ist die Performance vor allem an der angebotenen Funktionalität zusammen hängt. Und weiterhin gehe ich davon aus, dass alle Funktionnen irgendwo auch ihre Daseinsberechtigung haben. Im Zweifel bin ich aber, ob der zu zahlende Performance-Preis bei jedem Aufruf dem Nutzen angemessen ist und ob dieser Zusammenhang im Rahmen einer einheitlichen Vorlage unumgänglich ist. --Spischot 16:41, 12. Jul. 2011 (CEST)

Scheint doch langsamer geworden zu sein. Ich bastel mal weiter. --PM3 16:28, 12. Jul. 2011 (CEST)

Meine Parameterprüfung ist - obwohl sie recht kompakt aussieht, doch langsamer als erwartet. Es braucht wohl viel Erfahrung mit Vorlagenprogrammierung, ob sowas gut zu optimieren. Bei gecachten Kopien von Liste der Kulturdenkmäler in Worms ist meine Lösung nicht schneller als Vorlage:Coordinate, aber um 20% langsamer als Vorlage:Lage. Bei ungecachten Daten konnte ich bislang nur Coordinate und Lage vergleichen, und da war letztere um Faktor 4 schneller.

Der Codeablauf von Vorlage:Coordinate scheint schon verdammt gut optimiert zu sein; ich denke, da kann man nicht mehr viel rausholen. Was die viele Zeit kostet, ist anscheinend das Expandieren der Vorlagen, wenn der Artikel nicht im Cache ist (d.h ne Viertelstunde oder so nicht mehr abgerufen wurde). Hier könnte eventuell ein Aufteilen von Vorlage:Coordinate & Untervorlagen in kleinere Teilstücke helfen. Also die seltener benötigten Features in Untervorlagen auslagern.

In die Vorlage:Lage habe ich inzwischen auch die Parameter type und dim eingebaut; das hat wirklich keine messbare Performance gekostet. --PM3 17:36, 12. Jul. 2011 (CEST)

Bei gecachten Artikeln komme ich auf ähnlich gute Zeiten wie mit der Vorlage:Lage ohne Parameterprüfung. Wenn ich jetzt noch ein paar Sekunden beim Expandieren der Vorlage einsparen kann, wäre es ein toller Kompromiss: NS, EW, region, type und dim (evtl. weitere) mit 100%iger Prüfung und automatischer Einordnung in Kategorie:Parameterfehler, aber mindestens dreimal so schnell wie Vorlage:Coordinate bei nichtgecachten Artikelversionen. --PM3 18:19, 12. Jul. 2011 (CEST)

Weiterentwicklung

Da ich nicht weiß, ob hier jemand Vorlage Diskussion:Lage liest, schreibe ichs lieber auch nochmal hier hin. Ich versuche im Moment, das Ding um wichtige Features zu erweitern, ohne dabei den Performancevorteil aufzugeben. Also Vorlage:Lage in Richtung Vorlage:Coordinate zu entwickeln, weil mir das 10mal einfacher erscheint, als aus Vorlage:Coordinate die nötige Performance rauszuquetschen.

Bereits eingebaut:

• Parameterprüfung
• type
• dim
• Mikroformat

Geplant:

• text
• sortkey
• globe
• elevation

--PM3 18:40, 13. Jul. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --PM3 03:17, 1. Aug. 2011 (CEST)

Performance-Verbesserung Vorlage:Coordinate

Da es offensichtlich ein Problem gibt und unterschiedliche Ansichten der Lösung, versuche ich mal hier so neutral wie möglich zusammenzufassen und den Anfang für einen gemeinsamen Arbeitsraum für eine Lösung zu machen. Alle die sich an der Diskussion beteiligen wollen, sollen es in sachlicher Art hier an dieser Stelle tun. Es geht um Verbesserung, nicht um pro oder contra.

Problemdefinition

Die Vorlage {{Coordinate}} ist bei vielfacher Verwendung zu langsam.
Dies betrifft hauptsächlich Listen von georeferenzierten Objekten, aktuell gerade massiv die Denkmallisten. Zweite betroffene Stelle sind Positionskarten mit vielen eingetragenen Positionen, die über idente Mechanismen erzeugt werden. Um dieses Problem in Listen zu lösen wurde eine neue Vorlage {{Lage}} mit stark reduzierter Funktionalität aber deutlich besserer Performance geschaffen (it's a wiki), gegen die aktuell ein LA läuft.

Abgrenzung des Problems

Wie schon oben in der Problemdefinition angeführt, tritt das Problem bei (langen) Listen auf. In anderen Fällen einzelner Verwendungen von {{Coordinate}} gibt es aktuell keinen erkennbaren Handlungsbedarf, die Performance zu verbessern. Listen haben aber einige zusätzliche Eigenschaften, die uns Ansätze für Optimierungen bieten.

Optimierungsansätze bei der Verwendung in Listen

(bitte ergänzen und kommentieren)

• globe=earth kann vorausgesetzt werden. Bis wir die Denkmäler auf dem Mond listen (und mehrere hundert Einträge zusammenbekommen), wird es noch dauern.

   Ok wird im neuen simple-Modus ignoriert

Anmerkung: Es existieren sehr wohl lange Listen von verorteten Objekten auf anderen Himmelskörpern; tw. noch unverlinkt (1, 2, 3, 4, 5, 6, 7, 8), tw. direkt auf den Geohack verlinkt, (9, 10). --Spischot 08:01, 1. Aug. 2011 (CEST)

globe kostet zwei #if und ein #switch. Müsste ich mal schauen, was das von der Performance her ausmacht. Das sind Listen mit max. ca. 150 Koordinaten, also die liegen mit Bergis Optimierung bei max. 15-20 Sekunden; mit simple=y vielleicht bei 7-8. --PM3 09:04, 1. Aug. 2011 (CEST)

• In Listen / Tabellen werden keine Artikelkoordinaten (aus den einzelnen Einträgen) erzeugt.

   Ok war schon immer so, Parameter article wird im simple-Modus ignoriert

• In Listen / Tabellen werden keine maps aus den Koordinaten generiert

   Ok map-Parameter werden im simple-Modus ignoriert

• eine abgespeckte Version von {{Coordinate}} kann da also durchaus Sinn machen und ich denke, dagegen kann man sich nicht verwehren. (Dies könnte aber auch durch einen zusätzlichen Schalter in der {{Coordinate}} erreicht werden.)

   Ok neuer Schalter simple=y --PM3 03:15, 1. Aug. 2011 (CEST)

Randbedingungen

(bitte ergänzen und kommentieren)

• sinngemäß Wikipedia:WikiProjekt_Georeferenzierung/Neue_Koordinatenvorlage, inklusive MB. Außer es wird hier anders entschieden.
• Jede alternative Lösung sollte den kompletten Parametersatz an der Schnittstelle anbieten und auch einfordern (zumindest in Form von Doku), damit jederzeit auf Coordinate oder andere gemeinsame Alternativlösungen redirectet werden kann. Eine Auswertung kann dabei natürlich tw. unterbleiben.

   Ok neuer simple-Modus akzeptiert alle Parameter und prüft alle notwenigen

• Eine gesonderte Implementierung für Listen ist ausdrücklich als Lösung erlaubt, nur sollte sie in ihrer Funktionalität nicht gegen die Vorlage:Coordinate zurückfallen, was
  • Parameterprüfung (inklusive region)

     Ok wird im simple-Modus geprüft

  • identische Schnittstelle zum Geohack (type, dim, region, …)

     Ok ist im simple-Modus identisch

  • identische Schnittstelle zu den Kartendiensten bing, google maps und OSM.

     Ok braucht keine besondere Berücksichtung, geht via Geohack-Link

  • Verwendung von Mikroformaten

     No Microformat ist im simple-Modus vorerst nicht drin, weil unklar ist, ob es überhaupt genutzt wird. Kann bei Bedarf in 5 Minuten nachgerüstet werden, kostet dann aber Preprozessor-Speicher.

  • Printverhalten

     Ok ist im simple-Modus berücksichtigt

  • Schweizbezogenheit (CH1903 statt DMS)

     Ok text=CH1903 ist im simple-Mode verfügbar und kann in schweizer Artikel verwendet werden; automatische Formatwahl per text=/ entfällt zur Optimierung --PM3 03:15, 1. Aug. 2011 (CEST)

  • Mobile Endgeräte (/wiki/Liste_der_denkmalgeschützten_Objekte_in_Berndorf_(Niederösterreich) Bsp, könnten auch von Coordinate besser unterstützt werden),

anbetrifft.

• Jede alternative Lösung ist, abgesehen von ihren Einschränkungen, sinngemäß gegen Vorlage:Coordinate/Test zu testen.

Tja, da ist die Vorlage:Coordinate dann schon durchgefallen, die produziert dort jede Menge Fehler von verschiedener Art. --PM3 22:48, 12. Jul. 2011 (CEST)

• Auch wenn für Listen eine eigene Vorlage / eine Variante von Coordinate geschaffen würde, sollte die im MB geforderte Einheitlichkeit nicht durch weitere Vorlagevarianten aufgeweicht werden.

   Ok Einheitlichkeit im simple-Mode ist durch Einbindung in {{Coordinate}} und einheitliche Parametersyntax gegeben. --PM3 03:15, 1. Aug. 2011 (CEST)

Das Wegfallen einer dieser Randbedingungen wäre gut zu begründen.

Anmerkungen

• Bing zeigt über {{All Coordinates}} (und auch sonst) nur max. 200 Koordinaten an, insoferne machen mehr als 200 in einer Liste ev. aus diesem Grund wenig Sinn.
  • Eine externe technische Beschränkung bei genau einem Anbieter darf kein Grund dafür sein, alle betroffenen Inhalte an die Möglichkeiten diesen Anbieters anzupassen. --jergen ? 22:16, 12. Jul. 2011 (CEST)
• Eine Einschränkung es Formats auf nur Dezimalgrade halte ich für ungünstig aus Gründen der Benutzerfreundlichkeit. Man sollte generell eine Umrechnung von 60er System auf Dezimalsystem von Benutzern nicht verlangen, viele der mir untergekommenen Fehler resultieren genau daraus. Und die GIS Systeme werfen mal das eine, dann das andere aus, nicht jeder weiß das in google maps etwa umzustellen.

  Kann per {{XDMS}} übersetzt werden. In abgeleiteten Vorlagen ist teils schon eine Logik drin, die den simple-Mode nur aktiviert, wenn Dezimalgrad angegeben ist. --PM3 03:15, 1. Aug. 2011 (CEST)

• Es scheint allerdings auch bei vielen Koordinaten ein schnellerer Seitenaufbau zu erfolgen, wenn die Koordinaten tatsächlich dezimal vorliegen. (in etwa vergleichbare Beispiele 89 mal DMS vs. 80 mal dezimal) --Matthiasb ^{(CallMyCenter)}

Abschätzung

{{Lage}} inklusive aller Prüfungen wurde von PM3 vermessen und im Falle, dass die Seite sich nicht schon expandiert im Cache befindet, um einen Faktor 3 gegenüber Coordinate beschleunigt. Es gibt Leute, die bereits 30 Coordinaten in einer Seite von der Performance für schwer erträglich halten, mit einem Faktor 3 käme man daher auf 100 Listenelemente und damit an die Grenze, bei geduldigeren Personen bei etwa 300-400 Koordinaten. Dies würde also immer noch nicht ausreichen, um die denkmalintensivsten Städte Deutschlands in einer Liste unterzubringen. Aber natürlich in den meisten Fällen Erleichterung schaffen.

Liste der Straßen und Plätze in Berlin-Mitte hat aktuell 237 Koordinaten und kommt non-cached mit Vorlage:Coordinate auf ca. 55 Sekunden Ladezeit, mit der überarbeiteten Vorlage:Lage auf ca. 20 Sekunden, wozu sicher die gigantische Tabelle einiges beiträgt. Die Schmerzgrenze bei solchen Artikeln würde ich bei 60 Sekunden ansetzen, also bei diesen Daten ca. 700 Koordinaten mit den vorhandenen Mitteln. Bei mehr als 60 Sekunden läuft in Hochlastzeiten, oder wenn man eine Kopie im BNR editiert (geringere Serverprio!) leicht in einen Timeout. --PM3 22:06, 12. Jul. 2011 (CEST)

Serverseitige Lösung

Eine bereits einmal angedachte, leider nicht weiter verfolgte, aber sicher zielführende Lösung wäre eine serverseitige. Etwa durch ein plugin, das ein tag <coordinate> (mit gleichen Parametern und bot-Umsetzung) entsprechend umsetzt. Die Lösung hier über Vorlagen ist immer ein Krampf. Rein von der Performance her, abgesehen von der Performance. Ein solches Tag sollte natürlich international verwendbar sein. Probleme dabei dürften sein:

• Lokalisierung (Formatierung der Koordinaten, Namen der Himmelsrichtungen, Koordinatensystem (z.B. CH), Fehlermeldungen)
• Neutrale, serverseitige Modellierung des ISO Regionsbaums (derzeit hier über lokale Vorlagen)
• Integration mit den Positionskarten / map Erzeugung
• Abstimmung mit und Durchsetzung bei der Foundation

--Herzi Pinki 20:51, 12. Jul. 2011 (CEST)

Das dauert vorraussichtlich ewig... . --Kolossos 19:03, 13. Jul. 2011 (CEST)

... und es ist fraglich, ob es dann wirklich kompatibel zu {{Coordinate}} sein wird. Wird ja auch die Koordinatenbedürfnisse aller anderen Sprachversionen berücksichtigen müssen; die haben dafür ihre eigenen Vorlagen. --PM3 19:08, 13. Jul. 2011 (CEST)

Weitere Diskussion

Ist denn bekannt, warum {{Coordinate}} so langsam ist? Wenn nicht, wäre das wohl der erste Schritt zur Lösung, oder? --Alex 21:34, 12. Jul. 2011 (CEST)

Ich persönlich bin der Meinung, daß die Performance bei den fraglichen Listen vor allem durch das Zusammenwirkung von Tabellensyntax und Koordinatenvorlage erzeugt wird. Es wird ja praktisch eine Tabellenzeile geschriebenm dann der Link zum Geohack und die Koordinatenbeschriftung erzeugt, dann wird die n§achste Tabellenzeile geschrieben usw.

Ich glaube, daß das Problem nicht primär in der Vorlage liegt. Man mußte vermutlich mal analysieren, in welcher Reihenfolge der Krempel jeweils geladen wird. Da läuft vermutlich einiges nicht optimal, vor allem zwischen den ganzen Skripten, die sonst noch geladen werden.

Es ist auffällig, daß bis 30 oder 40 Koordinaten kein Zeitverlust offentsichtlich ist, ab so etwa 150 Einbindungen dauert es wirklich lang. --Matthiasb ^{(CallMyCenter)} 21:59, 12. Jul. 2011 (CEST)

Habe keine guten Tools (Profiler) oder Hinweise zum Aufspüren des Performance-Leaks gefunden, nur etwa [1]. Jedenfalls sollte man vor einer Änderung der Funktionalität doch nochmals versuchen, den Vorlagen-Code zu optimieren. Aufgrund eines kurzen Code-Reviews würde ich Folgendes ausprobieren:

• Zu CoordinateLAT und CoordinateLONG je ein privates Subtemplate bauen mit 4 unbenannten Argumenten für Grad, Minuten, Sekunden, Himmelsrichtung; den CoordinateLAT/LONG-Code dorthin übertragen (ohne ParmPart, {{#if:{{{4}}}{{{3}}}{{{2}}}...); diese nur aus CoordinateLAT/LONG mit 1 (Dezimalgrad) oder 4 Argumenten aufrufen, spart je ein gutes Dutzend ParmPart-Aufrufe pro Vorlagenaufruf, dafür zwei Template-Aufrufe mehr. Oder mit Variable-Extensions arbeiten, falls das geht.
• Falls möglich analoge Subtemplates für region/map/caption-Teil, da dort ebenfalls Variablen anstelle der mehrfachen ParmPart-Aufrufen hilfreich wären.
• Bereichsprüfung à la -90 <= x <= 90 mit abs impl.
• Himmelsrichtungen nur als Grossbuchstaben 'N', 'S', 'E', 'W' akzeptieren (spart wenige uc:-Aufrufe)

Macht wohl alles nur ein paar Prozent aus, aber vielleicht gibt's noch mehr davon? Hinweis: Habe noch nie Vorlagen programmiert, nur anderes Zeugs. Vielleicht liege ich also mit den Vorschlägen daneben… --Meleager 22:10, 12. Jul. 2011 (CEST)

zu Matthias: Mit Vorlage:Lage erreicht man im identischen Artikel mit gleicher Tabelle ein Drittel der non-cached-Ladezeit (siehe #Abschätzung); mit der alten Variante war es sogar in Viertel. Also liegt es definitiv im Wesentlichen an der Vorlage. Und da die Vorlage:Coordinate aus dem Cache ausgesprochen fix ist - 10% schneller als meine Variante - kann es nicht an den Codelaufzeiten liegen, sondern eigentlich nur am zu expandierenden Codeumfang. Das Ding ist inklusive aller eingebundenen Untervorlagen einfach verdammt groß, und wenn man das dann 200mal expandiert, dauert das halt so lange.

Bei 30 Koordinaten-Einbindungen hat man kaum eine Chance etwas zu messen, da dürften die Unterschiede innerhalb der natürlichen Schwankungen der Serverlast/-antwortzeiten liegen.

@Meleager: Vergleich mit/ohne abs() war eins der Dinge, die ich heute mit Vorlage:Lage durchtetestet habe. Auch bei großen Artikel kein messbarer Unterschied. --PM3 22:16, 12. Jul. 2011 (CEST)

Danke. Auch das uc: wird nicht teuer sein. Vermutlich muss man wirklich die Anzahl Aufrufe bzw. die zur Laufzeit entstehende Datenmenge (Parse Tree) minimieren. --Meleager 22:37, 12. Jul. 2011 (CEST)

Ich glaube ich hab eben einen Denkfehler gemacht: Das Expandieren und Parsen dürfte ein zusammenhängender Vorgang ein; die Daten aus dem Cache werden nachher bestimmt nur noch en bloc kopiert. Aber das passt ja trotzdem zu dem parse tree. Untervorlagen werden anscheinend nur expandiert, wenn wirklich darauf zugegriffen wird - vielleicht kann man die Datenmenge auf diese Weise minimieren. --PM3 00:38, 13. Jul. 2011 (CEST)

Schalter in Vorlage

Also ich bin auch für das Testen des oben gewähnten Schalters in der Vorlage Coordinate, ich könnte mir dafür sowas wie "list=yes" oder "simple=yes" vorstellen. Man hätte also an der Spitze eine einzige if-Abfrage und würde dann entweder in das springen, was Vorlage:Lage so macht oder halt in die komplexen Ausführung von Vorlage:Coordinate (samt aller Untervorlagen) springen.

Ich denke das könnte funktionieren. Falls nicht, so hätte aus meiner Sicht eine zweite Vorlage für Listen Ihre Berechtigung. Diese Vorlage sollte dann so schlicht wie möglich gehalten werden, also kein Plausibilitätsprüfung und vorallem keine Koordinatenumwandlungen.

Könnte das mit dem Schalter bitte mal jemand ausprobieren? --Kolossos 19:21, 13. Jul. 2011 (CEST)

Noch einfacher: Angabe von simple ohne Parameter, um es einzuschalten. Ich probiere es mal aus. --PM3 19:50, 13. Jul. 2011 (CEST)

Hab eine Testreihe gemacht, mehrmals abwechselnd zwischen verschiedenen Versionen. Ergebnis:

• simple-Variante: kein erkennbarer Unterschied zu Vorlage:Lage
• normal-Variante: ca. 15 ms Performance-Verlust pro Einbindung gegenüber der bisherigen Vorlage:Coordinate → vernachlässigbar

Also: Testergebnis positiv!

Das sähe dann so aus:

1. Der Codeteil von {{Coordinate}} wird nach {{CoordinateFull}} kopiert
2. Hilfsvorlage {{Lage/Fehler}} wird nach {{Coordinate/SimpleError}} kopiert
3. Der Codeteil von {{Coordinate}} wird ersetzt durch den Codeteil aus {{Lage}} (mit Anpassung an die umbenannte Fehler-Vorlage) plus einen Aufruf von {{CoordinateFull}}, falls nicht simple=y gesetzt ist

Parameterprüfung & Einordnung in Kategorie:Parameterfehler würde ich auch bei simple=y drin lassen; das kostet auch nur so um die 15 5-10 ms pro Einbindung. --PM3 21:56, 13. Jul. 2011 (CEST) Parameterprüfung beschleunigt --PM3 21:35, 14. Jul. 2011 (CEST)

Ich wäre bereit mich um alles zu kümmern und die simple-Option in {{Coordinate}} einzubauen, unter der Voraussetzung dass ich bis auf Weiteres Schreibzugriff auf {{Coordinate}} behalte, um weiter Optimierungen und Verbesserungen an der simple-Variante vornehmen zu können. Vor allem möchte ich noch text und sortkey einbauen, sofern es keine nennenswerte Performance kostet. Also Vollsperrung für {{CoordinateFull}} und nur Halbsperrung für die neue {{Coordinate}}. Morgen bin ich weg; ab übermorgen hätte ich Zeit dafür. --PM3 22:18, 13. Jul. 2011 (CEST)

Schön, das schein ja ein Fortschritt zu sein. Ich hätte folgende Anliegen:

• in den österreichischen Denkmallisten wird nicht der Text Lage, sondern der Text Standort verwendet, manchmal Karte (Liste der Brücken in Berlin). Könnte man sicher vereinheitlichen, aber vielleicht könnte Lage den Parameter text auswerten. Default kann ja Lage sein.
• in vielen langen Listen stehen Koordinaten im Format DMS, um allgemein nützlich zu sein, sollte also auch der Wert text=DMS unterstützt werden. etwa Liste von Vulkanen in Bolivien
• es gibt auch rein textuelle Koordinaten, die auf die Vorlage umgestellt werden können sollten. etwa Liste der Segelfluggelände in Deutschland (da hat schon jemand vor der Performance resigniert).
• Tabellen hatten bisher die Möglichkeit der Sortierung nach Koordinaten (entweder von O nach W oder von N nach S). Parameter sortkey.
• Prüfung auf EW scheint nicht stattzufinden. {{Lage|NS=-30|EW=70/10/10/E|type=landmark|region=AT}}: {{Lage|NS=-30|EW=70/10/10/E|type=landmark|region=AT}}

--Herzi Pinki 22:30, 13. Jul. 2011 (CEST)

zu deinem Angebot, das alles umzusetzen. Gerne. Aber die Vorlage wird mehrere 100000mal verwendet. Es ist nicht gut, auf so einer Vorlage etwas auszuprobieren. Kannst du die fertige Implementierung unter einem temporären Namen bereitstellen, damit damit ausführlich getestet werden kann. Es denken im Moment andere auch noch über (Teil-)Lösungen nach. die sollten dann zusammen aktiviert werden. lg --Herzi Pinki 22:38, 13. Jul. 2011 (CEST)

Bitte sehr, hier ist die fertige Vorlage zum Testen:

{{Benutzer:PM3/Coordinate}}

Zusammen aktivieren mit anderen Lösungen ist nicht nötig, weil beides unabhängig voneinander ist und an verschiedener Stelle eingebaut würde: Die in der Vorlagenwerkstatt diskutierte Lösung wäre eine Optimierung der non-simple-Variante und fände dann komplett in {{CoordinateFull}} (s.o.) & Untervorlagen statt.

NS und EW werden vollständig geprüft mit Ausnahme des Zeichens /, aus Performancegründen. Ich werde versuchen, dafür noch eine Lösung zu finden. Die übrigen Wünsche von dir werden alle funktionieren, sobald die Parameter text und sortkey eingebunden sind; das habe ich für die nächsten Tage vor. --PM3 22:58, 13. Jul. 2011 (CEST)

/ in EW und NS wird jetzt auch als Fehler erkannt, damit sollte die Prüfung nun vollständig sein. --PM3 23:10, 13. Jul. 2011 (CEST)

Danke für eure Arbeit, seh ich das richtig, dass die Angabe simple=y die Angabe der Koordinaten in Dezimaldarstellung erwarten wird? Danke --Richtest 10:36, 15. Jul. 2011 (CEST)

Ja. Zusätzlich können wir eine Vorlage bereitstellen, die die Formate ineinander umrechnet, vgl. Vorlage:LageDMS. Also man gibt dort Grad/Minuten/Sekunden ein, und das Ding schreibt dann ein {{Coordinate|simple=y|...}} mit Dezimalbrüchen in den Artikel. --PM3 15:12, 15. Jul. 2011 (CEST)

Ok, mir gehts um die Koordinateneinbindung in Bahnstreckenboxen, da ist die simple-Form wegen der zu erwartenden Menge nötig, es ist andererseits praktisch, auch °'" formatierte Koordinaten zum Beispiel aus Bahnhofsartikeln kopieren zu können. NS und EW werden dabei als Parameter angegeben und nicht direkt die Vorlage im Quelltext angegeben. Eventuell kann man aber in die Streckenvorlage noch eine Abfrage einbauen, die jeweils die passende Koordinatenvorlage einbindet.. --Richtest 15:21, 15. Jul. 2011 (CEST)

Ich nehme an, ihr habt dazu zwei Parameter für Breitengrad und Längengrad in eurer Vorlage. Dass kann genauso gelöst werden, wie ich oben geschrieben habe, zum Beispiel:

  {{Infobox Bahn-XYZ
  | ...
  | Breitengrad = {{subst:CoordinateDMS|NS=50/48/39/N}}
  | Längengrad = {{subst:CoordinateDMS|EW=6/28/57/E}}
  | ...
  }}

Folgendes würde dann in den Artikel geschrieben:

  | Breitengrad = 50.810833
  | Längengrad = 6.4825

--PM3 16:24, 15. Jul. 2011 (CEST)

Stimmt, danke. --Richtest 16:31, 15. Jul. 2011 (CEST)

Die neue Vorlage dafür heißt nun {{XDMS}}, anwendbar so:

  {{Infobox Bahn-XYZ
  | ...
  | Breitengrad = {{subst:XDMS|50/48/39/N}}
  | Längengrad = {{subst:XDMS|6/28/57/E}}
  | ...
  }}

--PM3 16:56, 19. Jul. 2011 (CEST)

Testergebnisse

• Ich habe mal die Performance nachgemessen.
• Probleme mit Bing konnte ich nicht nachvollziehen.

lg --Herzi Pinki 22:07, 14. Jul. 2011 (CEST)

Danke. Die Daten sind noch etwas verzerrt, weil Lage und PM3/Coordinate auch den Inhalt von region prüfen. Coordinate prüft nur, ob region vorhanden ist, das spart Zeit. Ich teste das gleich nochmal mit mehr Koordinaten und unter gleichen Bedingungen, d.h. ich baue d←en region-Syntaxtest aus. --PM3 22:51, 14. Jul. 2011 (CEST)

Es braucht mE nicht mehr Koordinaten, das Verhalten dürfte linear sein, bis an die Parserlimits gestoßen wird. Du kannst aber gerne meine Messflles modifizieren und eigene Messwerte eintragen (neue spalte). --Herzi Pinki 23:08, 14. Jul. 2011 (CEST)

Danke, Herzi Pinki, endlich mal Fakten! Ich habe die Präprozessor-Daten hinzugefügt und die Formatierung aufgehübscht. Hat schon jemand eine Tendenz von Bergis Zwischenstand? --Spischot 23:13, 14. Jul. 2011 (CEST)

Hab jetzt mal mit timeit wget auf der Kommandozeile gemessen und komme auf etwas andere Zeiten. Die region-Prüfung in Lage und PM3/Coordinate hatte ich vorher abgeschaltet, zur besseren Vergleichbarkeit (bleibt b.a.w. auch abgeschaltet). --PM3 01:03, 15. Jul. 2011 (CEST)

Umsetzung

Entwurf für die neue Vorlagenstruktur (Einbindungshierarchie):

• {{Coordinate}} ← Code aus Benutzer:PM3/Coordinate + VNR-Anpassungen
  • {{CoordinateFull}} ← {{Coordinate}}
    • bestehende Untervorlagen CoordinateXXX
  • {{CoordinateSimple}} ← {{Lage}}
    • {{CoordinateParamError}} {{CoordinateError}} ← {{Lage/Fehler}}
    • ggf. weitere Untervorlagen für weitere Features, insbes. text und sortkey

Das Ganze wäre in umgekehrter Reihenfolge anzulegen und stufenweise zu testen, bevor als Letztes die Vorlage:Coordinate ausgetauscht wird. --PM3 17:14, 15. Jul. 2011 (CEST)

Außerdem, sehr wichtig:

• {{CoordinateSimpleDMS}} ← {{LageDMS}}

Das Ding muss aber noch verbessert werden, da kümmere ich mich in den nächsten Tagen drum. --PM3 19:46, 15. Jul. 2011 (CEST)

• move bei Coordinate müsste doch reichen, danach gibt es einen redirect und der wird bald mit deinem wrapper gefüllt?
• was meinst du mit importupload?
• Vorlage:Coordinate/Doku muss angepasst werden, aber das ist nicht kritisch.
• was hältst du davon statt {{CoordinateParamError}} oder {{Lage/Fehler}} die vorhandene {{CoordinateMSG}} zu verwenden. Fehler treten nicht in der Menge auf, dass die Ausgabe von Fehlermeldungen ein Performanceproblem darstellen würde. Wäre eine Vorlage und eine Redundanz weniger.

--Herzi Pinki 21:10, 15. Jul. 2011 (CEST)

Wikipedia:Importwünsche/Importupload, bei copy notwendig um die Bearbeitungshistorie zu übernehmen. Beim move überflüssig. Move ist im .o.g Fall aber ungut, weil dann bis {{Coordinate}} ← Code aus Benutzer:PM3/Coordinate + VNR-Anpassungen erst mal nix mehr geht. --Spischot 21:34, 15. Jul. 2011 (CEST)

habe gerade eine Testvorlage verschoben, der Aufruf über WL hat klaglos funktioniert. Wo siehst du die Probleme? Coordinate leitet weiter und der wrapper kann gestestet werden (solange er nicht Coordinate heißt). --Herzi Pinki 23:02, 15. Jul. 2011 (CEST)

Hast ja recht. Ich habe nur versucht, mich in PM3s Ideen hineinzuversetzen, aber mit redirect sehe ich (entgegen meiner etwas unüberlegten Behauptung) keine Probleme. --Spischot 23:12, 15. Jul. 2011 (CEST)

Dass Vorlageneinbindung per Redirect geht, wusste ich noch nicht. Und ihr zwei garantiert mir, dass das 100%ig safe ist? Wie oft die Vorlage eingebunden ist, wisst ihr ja. Und dass auch keine unvorhergesehenen Probleme beim Austausch von {{Coordinate}} auftreten und nachher nicht irgendein Admin vor den Problem steht, nicht auf "zurücksetzen" drücken zu können?

Wass passiert denn mit dem Link auf die Vorlagen-Doku bei einer Verschiebung? Der geht ja relativ zum Seitenname. Muss man die dann auch verschieben? Möglichst zeitgleich? Und nachher wieder zurückverschieben, möglichst zeitgleich mit dem Überschreiben des Redirect? --PM3 23:58, 15. Jul. 2011 (CEST)

die doku gar nicht verschieben, redirect von Vorlage:CoordinateFull/Doku auf Vorlage:Coordinate/Doku einrichten (für die anderen subfiles detto), erst danach die Vorlage verschieben. Damit findet CoordinateFull auch seine Doku, die dort bleiben kann, wo sie immer war. Man muss zwar vorsichtig sein, ja bitte!, aber ich denke, das aufwändige importupload kannst du dir sparen. (Die doku ist auch relativ wurst, tut keinem weh, wenn die mal falsch verlinkt sein sollte.) --Herzi Pinki 00:10, 16. Jul. 2011 (CEST)

Ok, auf deine Verantwortung. Dann mache ich das bei den anderen beiden Vorlagen auch per Verschieben. Das gibt dann vorübergehend Chaos mit der Doku, bis {{Lage}} überall ausgetauscht ist, aber egal. --PM3 00:52, 16. Jul. 2011 (CEST)

Vor dem finalen Austauschen von {{Coordinate}} würde ich gerne alles noch einmal durchtesten. Wenn wir das mit Move machen, wäre {{Coordinate}} eine zeitlang inexistent; das geht nicht.

{{CoordinateMSG}} passt nicht, weil ich andere Fehlermeldungen brauche, teils aus Performancegründen (zusammengefasste Fehlerklassen) und teils wegen eingeschränktem Funktionsumfang (kein DMS, unerlaubte Parameter). Davon abgesehen hat {{CoordinateMSG}} so viel interne Redundanzen, dass die eine zusätzliche nicht mehr ins Gewicht fällt.

Meine Liste oben zeigt nur die neue Vorlagenstruktur, weil ich die nicht alleine entscheiden möchte. Meine Todo-Liste für die Umstellung ist wesentlich umfangreicher. --PM3 22:00, 15. Jul. 2011 (CEST)

darum auch die Anmerkung mit {{CoordinateParamError}}, {{Lage/Fehler}}, {{CoordinateMSG}}: du hast vielleicht Angst, deine superschnelle simple=y Vorlage über so eine Vorlage wieder auszubremsen. Aber ich kenne noch keine Messung, die diese Vorlage als Performanceleak herausgefunden hat. --Herzi Pinki 23:02, 15. Jul. 2011 (CEST)

Die Performance der Fehlervorlage spielt keine Rolle, weil sie im Normalfall nicht expandiert wird. --PM3 23:53, 15. Jul. 2011 (CEST)

Ich verkürze {{CoordinateParamError}} zu {{CoordinatePE}}, das sollte 42 Bytes pro Einbindung einsparen. Was {{CoordinateMSG}} angeht: Machbar wäre, der Vorlage einen zusätzlichen Parameter simple=y zu spendieren, sodass sie sich bei bestimmten Fehlercodes anders verhält. Dann könnte ich die Fehlerbehandlung dort zumindest an einer Stelle zusammenfassen. {{CoordinateParamError}} würde aber trotzdem bleiben, um Übergabeparameter zu übersetzen. Damit kann ich auch nochmal ca. 50 Bytes pro Einbindung einsparen (wertvoller Präprozessor-Speicher). --PM3 06:14, 16. Jul. 2011 (CEST) bringt netto alles keinen Vorteil --PM3 17:59, 16. Jul. 2011 (CEST)

 Ok eledigt:

• simple-Parameter in {{Coordinate}} eingebaut und dokumentiert
• {{Lage}} überall durch {{Coordinate|simple=y}} ersetzt
• neue Vorlagen {{DMS2Grad}} {{XDMS}} und {{CoordinateSimpleDMS}} zur Übersetzung von DMS-Koordinaten
• LA auf Vorlage:LageDMS

Vielen Dank auch an Herzi Pinki für die konstruktiven Verbesserungsvorschläge. Das mit dem Zusammenführen von {{CoordinateMSG}} kam leider nicht in Frage, weil es in jedem Fall Performance gekostet hätte. --PM3 01:35, 18. Jul. 2011 (CEST)

Gerne, und alle Achtung für die schnelle und saubere Umsetzung

allerdings widersprichst du dir (Die Performance der Fehlervorlage spielt keine Rolle, weil sie im Normalfall nicht expandiert wird.).

obiges waren keine Vorschläge, sondern Anforderungen:

• in vielen langen Listen stehen Koordinaten im Format DMS, um allgemein nützlich zu sein, sollte also auch der Wert text=DMS unterstützt werden. etwa Liste von Vulkanen in Bolivien
• es gibt auch rein textuelle Koordinaten, die auf die Vorlage umgestellt werden können sollten. etwa Liste der Segelfluggelände in Deutschland (da hat schon jemand vor der Performance resigniert).

Es ist schade (weil es weiterer Sonderlösungen bedarf), dass text=DMS von simple nicht unterstützt wird. Die Konvertierung der Dezimalwerte auf DMS kostet Performance, aber das mag doch jede Liste selbst entscheiden. Im Fall, dass nur Text ausgegeben wird, schlägt dieser Performancepenalty ja nicht zu.

• {{Coordinate|text=DMS|simple=y|NS=47|EW=16|region=AT|type=landmark|name=irgendwo}} erzeugt 47° 0′ 0″ N, 16° 0′ 0″ O und das ist eine Katastrophe, da
  • alle Stellen mit text=DMS dahingehend überarbeitet werden müssen.
  • der sich anbietende Workaround {{Coordinate|text=47° N 15°|simple=y|NS=47|EW=16|region=AT|type=landmark|name=irgendwo}} erzeugt 47° N 15° O (der Fehler ist Absicht),
  • genau jene Redundanzen zurückbringt, die als eines der ganz wesentlichen Ziele der Umstellung der ehemaligen Vorlage:Koordinate Text auf Coordinate entfernt worden sind
  • damit wieder eine Latte uneinheitlicher Formatierungen hervorbringt (welches Zeichen für Minuten? ', ´ oder ′).
• nach der gleichen Logik ist natürlich auch text=/ zu unterstützen. Zumindest darf im text nicht / als Ausgabetext stehen bleiben, sondern sollte als DMS interpretiert werden.
• gleiches gilt für text=DM

Und dann gibt es noch jede Menge direkt links auf den geohack, die sollten auch durch Coordinate ersetzt werden. (http://toolserver.org/~geohack/geohack.php, z.B. Wikipedia:WikiProjekt Bremen/WLM2011/Liste Bremen/Östliche Vorstadt, leider sind da alle über Coordinate indirekt eingebundenen auch dabei. - aber vielleicht gibt es ja eine zielgenauere Abfrage).

lg --Herzi Pinki 09:07, 18. Jul. 2011 (CEST)

Lieber Advocatus Diaboli,

• Anforderugen in Sachen Funktionsumfang legen wir nach meinem Verständnis von Wikipedia-Arbeit gemeinsam fest, im Konsens und vor allem auf Grundlage der Wünsche von den Listenautoren, die das Ding einsetzen. Einzelne Leute können dazu Vorschläge und Meinungen und Hinweise beisteuern. (Jetzt bitte nicht mit dem alten Meinungsbild drohen: das hatte das Problem mit der Performance nicht berücksichtigt.)
• Deinen Seitenhieb von wegen: ich widerspäche mir selbst - und das als Einschränkung der Anerkennung meiner Arbeit - finde ich schade. Ist sowas nötig? Oben ging es um die Performance der {{CoordinateMSG}} selbst - also wie effizient diese implementiert ist - und die spielt in der Tat keine Rolle. Allerdings müssten für deren Einbindung, wie ich inzwischen festgestellt habe, zusätzliche Parameter angegeben werden, und das kostet ebenfalls etwas Performance - auch wenn sie nicht aufgerufen wird.
• Solche Fälle wie die Segelplätze würde ich individuell mit nem Macro-Recorder-Editor erschlagen. Ist eine Sache von 10-15 Minuten, sowas per Editormakro umzustellen.
• text=DMS kann man mit einem einfachen search-and-replace durch text=Lage ersetzen. Man muss eh mit search-and-replace drübergehen, um das simple=y einzubauen bzw. die Vorlage {{CoordinateSimpleDMS}} einzusetzen; da tut ein zweiter Durchlauf auch nicht weh.

Die DMS-Option würde ich auch gerne einbauen, aber ich überblicke noch nicht, was das an Performance und Speicherplatz kostet. Auch wenn es nicht aufgerufen wird, kostet es etwas für die reine Einbindung, siehe oben.

Mit text=DMS und DM alleine ist es ja nicht getan, sonder da kommt noch CH1903 und / und sortkey hinzu, und dann möchtest du als nächstes die Weltkugel haben, und wenn ICON2 drin ist sollte konsistenterweise auch ICON0 und ICON1 gehen. Ich schätze mal, dass das alles zusammengenommen die Performance und den Speicherbedarf (d.h. maximale Koordinatenzahl pro Liste) bereits um 5-10% verschlechtert, wenn es nicht verwendet wird. Wenn wir die Icons weglassen, eher 5 als 10%. Müssen wir uns nun überlegen, ob es das wert ist. Quarz sagt nein; ich denke: ja. --PM3 16:12, 18. Jul. 2011 (CEST)

Woher weißt du? :-) Im Ernst: Es geht den Leuten mit den fetten Listen (die nicht mehr sachgerecht geteilt werden können) um Performance, Performance, Performance. Wenn ich sehe, dass eine Liste mit GeoHack-Link (oder der Urform der {{Lage}} rund 8 Sekunden braucht, bis der Benutzer eine Reaktion am Bildschirm sieht (nicht bis zum Ende des Ladens), unter Verwendung des simple=y-Zweigs von {{Coordinate}} bereits 18 Sekunden, wachsen mir angesichts der Erweiterungswünsche Dackelfalten. Das befeuert meine Neigung, bei den Links zu bleiben. Auf den von mir betreuten Listen kann ich darauf achten, dass die valide sind. --Quarz 16:50, 18. Jul. 2011 (CEST)

8 vs. 18 (vs. 60) Sekunden in der drittgrößten Liste einer der größten Listen der gesamten de.WP, mit 600 Koordinaten. Mit der text=DMS-Erweiterung dürften daraus ca. 18,5 bis 19 Sekunden werden. Schlimm? --PM3 18:16, 18. Jul. 2011 (CEST)

... wobei mir auch nicht klar ist, wo die 4 Sekunden bei der Umstellung von Benutzer:PM3/Coordinate auf die nun identische Vorlage:Coordinate verlorengangen sind. Ich mache mich mal auf die Suche. --PM3 18:29, 18. Jul. 2011 (CEST)

60 s? Damit hatten wir dort nichts zu tun - die Listen, die wegen Totalblockade per Adminanfrage gelöscht werden mussten, waren viel kleiner. Ich bin ja froh um die 18 Sekunden statt ich weiß nicht was. Und wenn DMS tatsächlich einen Effekt im Bereich des Rauschens hat, kann ich dem leicht zustimmen. Nur machen mir die Begehrlichkeiten Sorgen. Es muss klar sein, dass Geschwindigkeit einen Preis hat. Man muss im Zweifel auf Features verzichten. --Quarz 18:46, 18. Jul. 2011 (CEST)

Ich hatte es eben nachgemessen: 62 Sekunden sind es mit {{CoordinateFull}} (der ex-{{Coordinate}}). Nur mal so zum Vergleich.

PM3/Coordinate und Coordinate hab ich auch gerade nochmal verglichen; sind identisch. Der Unterschied zwischen 16-20 Sekunden Ladezeit heute und 14-15 Sekunden vor ein paar Tagen kommt wohl durch aktuell höhere Serverlast. --PM3 18:53, 18. Jul. 2011 (CEST)

So, text-Option ist eingebaut. Wie erwartet liegt der Performance-Verlust in der Größenordnung von ca. 1 ms pro Einbindung, also ca. 0,5 Sekunden für Wikipedia:WikiProjekt Bremen/WLM2011/Liste_Bremen/Mitte. Preprozessor-Speicher kostet es erstaunlicherweise gar keinen.

Alle text-Optionen werden unterstützt, von DMS bis zum Weltkugel-ICON2, mit Ausnahme von /, von dim-abhängigem D(M(S))-Format und von allen weiteren Spezialfeatures, die ich evtl. übersehen habe. sortkey habe ich erst mal außen vor gelassen; das würde auch wieder in ähnlicher Größenordnung Performance kosten.

Das Ganze baut auf den bestehenden Funktionen wie {{Coordinate to DMS}} etc. auf, und die sind elend langsam; text=DMS kostet z.B. 20-25 ms pro Einbindung, d.h. der Zeitbedarf der Vorlage verdoppelt sich damit. Hier dürfte allerdings die neue Bergi-Optimierung eine Verbesserung bringen.

@Herzi Pinki: Kannst du noch die neue Vorlage:CoordinateSimpleText halbsperren? Die übrigen neuen Vorlagen habe ich schon halbsperren lassen. --PM3 04:05, 19. Jul. 2011 (CEST)

sortkey ist jetzt auch drin; Performanceverlust bei Nichtverwendung ist vernachlässigbar, nur ca. 0,5 ms pro Einbindung. Hab auch mal eine Performanceübersicht bei Verwendung der einzelnen Optionen erstellt: Vorlage:Coordinate#Vorlage zu langsam? / eine Seite runterscrollen. --PM3 18:39, 19. Jul. 2011 (CEST)

Habe text=DM(S) nun um Faktor 4 optimiert (nur in Verbindung mit simple=y). Damit ist diese Option nun auch in großen Listen wieder interessant. --PM3 07:02, 20. Jul. 2011 (CEST)

Hallo PM3, danke. Die eine Vorlage habe ich halbgesperrt (und ICON0/1 ergänzt.). --Herzi Pinki 01:02, 21. Jul. 2011 (CEST)

Mainroutine schlank und modularer Aufbau

ausserdem möchte ich bei einem ausgewachsenen programm wie dieser vorlage (die in wikisystax programmieren zu müssen, ist ja wirklich eine leistung, die wäre selbst in COBOL noch effektiver: mein respekt) nochmal an einen grundsatz des objektorientierten programmierens erinnern:

die routine main besteht ausschliesslich aus unterroutinenaufrufen

sie tut also nichts anderes, als die eingabeparameter in weitergegebene parametersätze zusammenzustellen. eine if-anfrage hat in einer hauptroutine eigentlich nichts verloren: imho gehört sowohl die ausgabeerstellung (article output) als auch etwa die sortkey-subroutine und ImDruckVerbergen ausgelagert
dann kann man nämlich

1. ganz speziell nur das aufrufen, was man braucht
   • so braucht die artikelkoordinate und die in einer IB definiv kein nach-geolage-sortieren, der ist für listen
   • auch muss bei einer definition von text explizit kein sort erzeugt werden, weil die tabelle nach dem angegeben text sortieren muss, nicht nach geo-breite oder -länge (die einleitende phrase {{#if:{{{text|}}}|{{#if:{{{sortkey|}}}|{{CoordinateSORT|… ist imho ein denkfehler) - und ist text im fliesstext definiert, brauchts sowieso kein CoordinateSORT
2. viel leichter sowohl fehlersuchen (also prüfwerkzeuge bauen), als auch nur module austauschen, ohne die coordinate selbst neu laden zu müssen

imho ist also CoordinateSimple und CoordinateFull nicht der rechte weg: viel mehr brauchen wir mehr schalter-variablen, die einen schlankeren, angepassteren aufruf ermöglichen (statt der eierlegenden wollmilchsau), etwa:

• mode=IB nur für infobox-implementierungen, dort DMS zu verwenden, sollte sowieso standard sein, also kann man sich alle anderen output-abfragen sparen - oder haben wir eine IB, die das nicht so macht
• oder eben mode=LIST, und dann erfolgt standardmässig ein verschlankter aufruf/ausgabe für listenelemente, was auch mehr einheitlichkeit in die listen bringen würde, gerne auch mode=CELL, wenn die koordinate allein in einer zellenspalte zu stehen kommt (dann und nur dann brauchts ein sortier-feature)
• umgekehrt sollte sich der autor aussuchen dürfen, ob er W-O oder N-S in seiner tabelle sortieren will, wenn er dieses feature nutzen will: dann wäre es aber auch explizit anzugeben, dass CoordinateSORT gewünscht wird (was jetzt, solange es die Vorl:Lage in Listenartikeln gibt, noch aufwärtskompatibel möglich ist)

für jedes neue feature sollten aber mindestens drei andere features, die dann unnötig sind, abgeschalten werden: dazu unterscheidet man zwischen datenvariablen, und schaltervariablen: die routine main kümmert sich ausschlisslich um zweitere (daten sind ihr egal), die subroutinen ausschlisslich um ihren datensatz und die sie betreffenden schalter, egal, ob sie der WP-autor oder main erzeugt - denkt nur daran, wie schnelle komandozeile funtioniert: ein befehl, 3 eingabedaten (wie einen dateipfad, einen text), aber 50 schalter, was jetzt genau getan werden soll damit --W!B: 20:10, 16. Jul. 2011 (CEST)

OOP in Wikiepdia-Vorlagen? Das werden wir beide nicht mehr erleben. :)

Die Vorlage wird gerade optimiert → bitte hier weiterlesen: WP:WVW#Vorlage:Coordinate --PM3 01:55, 17. Jul. 2011 (CEST)

ah, ich sehe, genau das meinte ich, gute sache.. ;) --W!B: 09:06, 17. Jul. 2011 (CEST)

Erledigt

Soweit ich das überblicke, ist dieser Punkt erledigt; die Checkliste von Matthias ist im simple-Modus umgesetzt, und das Ganze ist inzwischen mehrtausendfach eingebunden und funktionoert.

Das Microformat habe ich vorerst draußengelassen, da ich keine Hinweise darauf habe, dass es überhaupt funktioniert und irgendwo gebraucht wird. Wenn's fehlt, wird sich schon jemand hier beschweren.

Das mit der serverseitigen Lösung ist noch offen, aber das werden wir in diesem Jahr und hier wohl nicht mehr lösen. Bei den Optimierungen (Beitrag W!B:) gehe ich mal davon aus, dass ✓ den besten Überblick hat und das Optimum rausholt. --PM3 03:15, 1. Aug. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --PM3 03:15, 1. Aug. 2011 (CEST)

Soll die All Coordinates-Vorlage ein gleichweitiger Ersatz für die Coordinate-Vorlage sein?

Soll die All Coordinates-Vorlage ein gleichweitiger Ersatz für die Coordinate-Vorlage sein? In dem Artikel Radetzkyplatz scheint mir einiges falsch zu laufen, ich habe die Vorlage {{Coordinate}} eingesetzt, die von einem Benutzer entfernt wurde. Leider ist damit der Artikel, also das Lemma selbst nicht georeferenziert. In der {{All Coordinates}} steht, dass sie für die Einbindung in Listen oder Kategorien gedacht ist, also damit kein Ersatz für eine Georeferenzierung des Lemmas.... (siehe auch Disk bei mir). --Atamari 10:41, 2. Aug. 2011 (CEST)

Nein, sie soll nicht. Die Georeferenzierung von Objekten erfolgt ausschließlich über {{Coordinate}}. Dabei muss sichergestellt werden, dass nur eine der Koordinaten das Lemma verortet, also die sogenannte Artikelkoordinate angibt. Die übrigen Koordinaten sind dann erst mal zunächst nur im Text zu sehen, aber nicht oben rechts mit der OSM-Kartenansicht und Link auf den Geo-Hack.

Hier kommt jetzt {{All Coordinates}} ins Spiel: Diese Vorlage erlaubt, die per {{Coordinate}} angegebenen nicht-Artikelkoordinaten gemeinsam in einer Karte anzuzeigen. --Spischot 11:05, 2. Aug. 2011 (CEST)

PS: Zum Radetzkyplatz: Man könnte es durchaus so lassen, wie es jetzt ist. Wenn man aber was verändern will, muss man das gescheit tun:

1. Artikel-Koordinate bestimmen (nicht einen Lagewunsch; bei einem derart bekannt umzingelten Ort ist das echt albern)
2. {{All Coordinates}} mit section in den Abschnitt Radetzkyplatz#Beschreibung verlagern.

Ohne diese beiden Aktionen ist die Bearbeitung nicht gut; da muss ich dem Kollegen (ungeachtet des Tonfalls) recht geben. --Spischot 11:17, 2. Aug. 2011 (CEST)

Dein Wunsch war mir Befehl ;-) :Archivierung dieses Abschnittes wurde gewünscht von: Telford 12:04, 2. Aug. 2011 (CEST)

Fehlermeldungen bei fehlenden Parametern

Hallo, im Kontext meiner Überarbeitung der Vorlage:CoordinateFull und der Diskussion zur region-Prüfung: Derzeit werden in der Vorlage:CoordinateMAIN durch die Syntax {{#if:{{IstZahl|0{{{PARAM}}}|R|2}}||{{MSG}} }} mit der vorangestellten 0 keine fehlenden Parameter (pop und elevation) erkannt. CoordinateMSG sieht dafür aber (noch?) Wartungslinks vor. Wurde das mit Absicht rausgenommen, um den Parser von der ineffizienten MSG-Vorlage zu entlasten? Wie soll damit umgegangen werden? --✓ ^Bergi 18:44, 21. Jul. 2011 (CEST)

pop und elevation sind optional; Eintrag in die Wartungskategorie sind nur für falsche Zahlenformate vorgesehen. Also das sieht ok aus. --PM3 19:54, 21. Jul. 2011 (CEST)

Ach, in Vorlage:CoordinateMSG ist ja tatsäch auch Code für fehlendes elevation oder pop drin. Beide waren von Anfang an optional, wurden aber bis zum 29. Juni 2009 als Parameterfehler einsortiert: [2] Wenig sinnvoll - wenn überhaupt, dann hätte man es vom Typ abhängig machen müssen. In der Kat. Parameterfehler wars auch von Anfang an nur als "Fehler in der Höhenangabe / Einwohnerzahl" dokumentiert. [3]

Also das passt schon so, und der Code für fehlendes elevation und pop aus Vorlage:CoordinateMSG kann raus. --PM3 04:29, 22. Jul. 2011 (CEST)

Danke, das werde ich in die neue Vorlage (und die neue Fehlervorlage) einfließen lassen. --✓ ^Bergi 20:43, 23. Jul. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Hedwig in Washington (Disk?)•B 20:46, 14. Aug. 2011 (CEST)

Vorlage:Positionskarte

 Info:Ich habe mit Vorlage Diskussion:Positionskarte#Textebene auf Positionskarte hinzufügen einen Vorschlag zur erweiterten/veränderten Verwendung der Positionskarten gemacht. Ich würde mich dort über Feedback aus dem Projekt Georeferenzierung freuen. --Spischot 11:14, 22. Jul. 2011 (CEST)

Weiterer Hinweis: Vorlage Diskussion:Positionskarte#Alternativkarte. --✓ ^Bergi 21:11, 28. Jul. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Hedwig in Washington (Disk?)•B 20:45, 14. Aug. 2011 (CEST)

Anzeige auf Google Earth

Weiß jemand, über welche Koordinaten Google Earth die Wikipedia-Artikel verlinkt? Nur über die im Artikelkopf angezeigten? Oder die erste im Artikel vorhandene? Oder alle, die irgendwo im Artikel stehen? --PM3 21:18, 2. Aug. 2011 (CEST)

Meinst du GoogleEarth oder GoogleMaps? Aber nein, das weiß niemand so genau, siehe auch Vorlage Diskussion:Coordinate#Manche Artikel erscheinen nicht auf Google-Maps. Vielleicht werten sie die Dumps aus, vielleicht nehmen sie die Geohack-Links, vielleicht schauen sie aufs Microformat. --✓ ^Bergi 21:40, 2. Aug. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Hedwig in Washington (Disk?)•B 20:44, 14. Aug. 2011 (CEST)

Georeferenzierung von Kanälen, Straßen, Wegen

Hallo, wenn in Artikeln von Straßen, Wegen, Kanälen Geodaten eingefügt werden, sollen diese dann im Artikelkopf erscheinen? Hintergrund ist, dass ich in einigen Artikeln die Lagewünsche oder Geodaten entfernt hatte Spezial:Beiträge/217.246.208.173. Diese wurden mir revertiert. Meiner Meinung nach gehören in solche Artikel Geodaten bestenfalls in den Fließtext. Eure Meinung? --217.246.202.39 19:40, 3. Aug. 2011 (CEST)

Hmm, also ich finds schon praktisch, wenn überhaupt Koordinaten vorhanden sind. Bei der A1 macht es natürlich weniger Sinn als bei ner nur ein paar Kilometer langen Straße. Auf Dauer ist es für mich zu bevorzugen, die Koordinaten von Häusern, Schleusen oder ähnlichem im Fließtext einzubauen und diese mit der Vorlage:All Coordinates aufzurufen. --Richtest^D 19:57, 3. Aug. 2011 (CEST)

Siehe auch:

• Wikipedia Diskussion:WikiProjekt Georeferenzierung/Archiv/2011-III#Wo Georef?
• Wikipedia:WikiProjekt Georeferenzierung/Hilfe#Linienartige bzw. langgestreckte Struktur

Ansonsten wie Richtest: besser eine Koordinate im Artikelkopf als gar keine, aber noch besser alle relevanten Punkte im Text. --PM3 20:09, 3. Aug. 2011 (CEST)

OK, wenn ich es richtig sehe sollten solche Angaben besser im Text untergebracht sein. Die Seite Georeferenzierung/Hilfe ist ziemlich neu, kannte ich nicht. --217.246.209.230 05:45, 4. Aug. 2011 (CEST)

Um den Artikel auf Google maps und Konsorten als WP Artikel angezeigt zu bekommen, braucht es vermutlich eine Artikelkoordinate (sowohl auf Google maps als auch Earth habe ich bei einer Stichprobe jetzt nur Artikelkoordinaten gefunden). Bin da nie ganz sicher, da das Interface zu Google nicht dokumentiert ist. Keine Artikelkoord würde dann heißen, kein WP Symbol auf der Karte. Wollen wir das? Bei langen eindimensionalen Objekten (Donau, Autobahn A1) lassen sich gleichwertig Anfangs- und Endpukt markieren und bringen auch Mehrwert auf einer Karte. Hier könnte die Vorlage:All Coordinates helfen und alle Koordinaten mit einem Klick auf der gewählten Karte darstellen. Allerdings hat auch bei willkürlicher Bevorzugung einer der beiden Koordinaten der GeoHack eine Vorlage:All Coordinates entsprechende Funktion (Alle Koordinaten / Alle Links, unten in der box). Bei kurzen linearen Objekten (etwa den hier angeführten Kanälen mit Längen von 4, 10, 40 km würde ich eine Artikelkoordinate extrem hilfreich finden. Ein Punkt auf dem Kanal, ein Klick auf die Koordinate und ich bin am Kanal in der Karte. Mit einer geeigneten Wahl des Parameters dim (Länge in Metern), wird mir das gesamte Objekt auf einer Karte angezeigt und ich finde es auch. Bei flächigen Gebilden (Gemeinden, Landkreise, Seen, Meere, Gebirge) machen wir ja auch einen Punkt in die Mitte. lg --Herzi Pinki 20:33, 4. Aug. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Hedwig in Washington (Disk?)•B 20:43, 14. Aug. 2011 (CEST)

Koordinaten auf der Venus

Hallo, laut Venus#Erdgebundene Erforschung wird auf der Venus nur nach Osten gemessen (ebenso laut Geohack auf Englisch). Die Vorlage:Coordinate wandelt dies jedoch in West-Koordinaten um (Beispiel: Maat Mons). Sollte die Vorlage das anders machen, gibt es noch weitere globes, für die derartiges gilt? --✓ ^Bergi 18:08, 5. Aug. 2011 (CEST)

Ich hatte vor einer Weile ebefalls versucht, mir da einen Überblick zu verschaffen. Am Ende meiner Recherche kam ich zu folgenden Erkenntnissen:

1. Die Definition von West und Ost und vom Vorzeichen hängen von der Rotationsrichtung des Himmelskörper (im Vergleich zur Erde) ab.
2. Zusätzlich zu obigen Regel gibt es einzelne Himmelskörper, bei denen die Richtung genau entgegen der Regel festgelegt ist. Außerdem ist die Lage des Wertebereichs (-180° bis +180° vs. 0° bis 360°) pro Himmelskörper festgelegt (0° bis 360° überwiegt deutlich, die Venus ist also kein Einzelfall). (Wenigstens kann man sich darauf verlassen, dass Norden immer oben ist; mathematisch: der Winkel zwischen den Rotationsachsen von Himmeslkörper und Erde ist immer kleiner als 90°)
3. DV-Umgebungen, die ich gefunden haben (Google Earth, Google-Moon, Google-Mars, NASA World Wind, Geo microformat, Vorlagen in verschiedenen Wiki-Sprachversionen, Koordinaten auf diversen Web-Seiten, ... ) geben Postitionen (immer mit gleichem Vorzeichen und mehrheitlich mit der gleichen Lage) an, wie auf der Erde: Längengrade ±180°, positiv nach rechts, Breitengrade ±90°, positiv nach oben.

Meine Schlussfolgerung: Eine Sonderbehandlung des Ausgabetextes in Abhängigkeit des Himmelskörper in der Vorlage ist nicht sinnvoll; für den Geohack sogar hinderlich. Parameterangaben (beim Aufruf der Vorlage) im Bereich 0° bis 360° sollten aber von der Vorlage verstanden werden. (Weitere Details habe ich wieder vergessen). --Spischot 11:19, 8. Aug. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Hedwig in Washington (Disk?)•B 20:37, 14. Aug. 2011 (CEST)

Eigenartiger Effekt beim Parameter «name»

Wenn im Parameter «name» der Begriff Quelle vorkommt, wurde mir die verlinkte Seite im Quelltext geöffnet. Habe ich da etwas übersehen oder falsch gemacht? Kann man das beheben? Beispiel. -- Хрюша ^?? 00:52, 24. Aug. 2011 (CEST)

Kann ich hier nicht nachvollziehen (Win XP, IE 8). --тнояsтеn ⇔ 07:55, 24. Aug. 2011 (CEST)

Ich kann es auch nicht mehr nachvollziehen :0{. War mit Safari unter MacOS X. Lag aber eindeutig daran, parallel mit gleichen Parametern und gleicher Syntax getestet: Quelle raus → saubere Seitendarstellung, Quelle rein → Quelltext-Anzeige. Der auch noch mit drin stehende / war übrigens nicht mitschuldig. -- Хрюша ^?? 08:58, 24. Aug. 2011 (CEST)

Im Firefox 3 unter WinXP ist auch alles in Ordnung. Magst Du dann Quelle wieder in den name-Parameter einbauen? Solche merkwürdigen Effekte ohne vernünftige Erklärung gibt es gelegentlich; falls sie nicht reproduzierbar sind kann man sie getrost vergessen. --Telford 09:20, 24. Aug. 2011 (CEST)

So, ich habe es wieder reingesetzt. Mit Safari unter WinXP funktioniert es jedenfalls. Danke für die Hinweise. -- Хрюша ^?? 09:37, 24. Aug. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Хрюша ^?? 09:37, 24. Aug. 2011 (CEST)

Darstellung Landesgrenzen mit OpenStreetMap

Bei Grenzübergang Jarinje wird auf der OpenStreetMap-Einblendung (hier auch direkt) der Grenzverlauf zu Serbien derzeit fälschlicherweise südlich des Kontrollpunktes angezeigt, so dass er in Serbien zu liegen scheint, zum Vergleich bei Google maps aber hingegen korrekt nördlich, so das der Grenzübergang im Kosovo liegt. Ist das ein bekanntes Problem? --Grossenhayn 01:26, 29. Jul. 2011 (CEST)

Vielleicht mal hier nachfragen? --PM3 01:40, 29. Jul. 2011 (CEST)

Es geht mir mit meiner Frage nicht um diese speziellen Geodaten, mir ist klar, dass dafür die OSMler verantwortlich sind, sondern ob die derzeit von OpenStreetMap gelieferten politischen Karten generell noch nicht die notwendige Genauigkeit haben. Eine Einschätzung wäre hilfreich. --Grossenhayn 01:19, 22. Aug. 2011 (CEST)

Nach meiner persönlichen Einschätzung ist die Genauigkeit von OSM generell hoch genug, um über die Karteneinbindung einen Mehrwert darzustellen. Übrigens sind auch die kommenziellen Kartendienste nicht überall genau. --Spischot 08:34, 22. Aug. 2011 (CEST)

Die Genauigkeit der OSM Daten ist abhängig von der Motivationslage und Anzahl der Bearbeiter pro Region. Dementsprechend ist die Genauigkeit insbesondere in Industriestaaten und dort wiederum in Ballungsräumen entsprechend hoch, z.T. höher als andersweitiges Material. In nichtindustriellen Ländern sowie im ländlichen Raum sieht die Qualität oftmals anders, bzw. schlechter aus. Ein Vergleich bezüglich der Qualität fand sich, so weit ich mich erinnere letztes Jahr (?) in der c't. Bei politischen karten wäre ich entsprechend um so vorsichtiger, je detailierter die darzustellenden Fakten sein sollen. --ArcyGeo 19:11, 22. Aug. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Grossenhayn 01:53, 30. Aug. 2011 (CEST)

Anregung Koordinaten

Hallo,

ich füge gerne Koordinaten ein, aber wenn ich jedesmal vor dem Problem stehe, daß verschiedene Bezugssysteme (mal Minuten, mal Grad...) verwendet werden, dann vergeht mir langsam die Lust! Ist es nicht möglich, daß man ein einheitliches System (Infobox oder Ähnliches mit deutlichen Vorgaben) verwenden muss? Würde einiges an Arbeit und Ärger sparen. LG --M1968h 19:26, 28. Aug. 2011 (CEST)

Ich verstehe dein Problem nicht. Die Vorlage {{Coordinate}} ist doch so flexibel, dass du die Koordinaten einfach so einfügen kannst, wie du sie vorliegen hast. Den Rest macht die Vorlage. Ein Zwang zu einem einheitlichen Format würde dich dagegen zu einer Umrechnung zwingen. --Spischot 19:55, 28. Aug. 2011 (CEST)

Ganz so unrecht hat er nicht. Bei Vorlage:Coordinate#Vorlage zu langsam? dürfen die Daten nur im Dezimaleingabe erfolgen. --Knochen 20:42, 28. Aug. 2011 (CEST)

Auch das ist mit {{subst:XDMS}} kein Problem --Spischot 21:25, 28. Aug. 2011 (CEST)

Danke für die Hinweise! LG --M1968h 18:08, 29. Aug. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Spischot 18:19, 29. Aug. 2011 (CEST)

Georefs in Stadt Aist

Moin,

ich hoffe ich bin hier richtig...

Der Artikel beinhaltet so ein Fusionsprojekt aus drei Gemeinden (1, 2, 3). Fällt euch was ein zu Georeferenzierung? Eben so, dass am Ende über Geohack eine brauchbare Ansicht des Umkreises dieser 3 Orte bei rauskommt?

Danke & Grüße, rbrausse (Diskussion Bewertung) 22:13, 5. Sep. 2011 (CEST)

Entweder {{Linked Coordinates}} [4] oder 3 Fließtextkoordinaten und {{All Coordinates}}. --✓ ^Bergi 12:30, 6. Sep. 2011 (CEST)

Danke, optimal wäre jetzt Linked Coordinates mit dem Parameter section aus All Coordinates :)

aber das ist schon sehr hilfreich, ich bastel da mal was rein. rbrausse (Diskussion Bewertung) 13:08, 6. Sep. 2011 (CEST)

hmm, habe ich die Vorlagen verkehrt eingebunden? Die Einbindung mit All Coordinates im Abschnitt Geographie funktioniert nur bei OSM, Bing und Google behaupten, es seien keine Koordinaten übergeben worden. rbrausse (Diskussion Bewertung) 13:45, 6. Sep. 2011 (CEST)

jetzt geht's... ich denk da nicht weiter drüber nach, bedanke mich und schließe das hier ab.

Archivierung dieses Abschnittes wurde gewünscht von: rbrausse (Diskussion Bewertung) 15:18, 6. Sep. 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)

Archivierung dieses Abschnittes wurde gewünscht von: тнояsтеn ⇔ 13:55, 9. Nov. 2011 (CET)

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)

Archivierung dieses Abschnittes wurde gewünscht von: тнояsтеn ⇔ 13:59, 9. Nov. 2011 (CET)

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)

{{Vorlage:XDMS}} ({{subst:XDMS|50/8/8/N}} → 50.135556) --Spischot 20:40, 25. Sep. 2011 (CEST)

Genau sowas brauche ich. Problem ist nur, dass die Vorlage so aufgebaut ist, dass sie nur gesubst werden kann. Ich brauche das aber ohne subst. Bei mir geht es nur im Wartungsfälle bei Infoboxen und Artikel mit solchen sind nie Listen und haben somit keine Performanceprobleme. Ist eine Erweiterung erlaubt? Merlissimo 21:59, 25. Sep. 2011 (CEST)

Ich habe die Möglichkeit ohne subst mal eingebaut, aber etwas tricky, damit es nicht jeder nutzt. Merlissimo 22:40, 25. Sep. 2011 (CEST)

Das geht mit {{CoordinateLAT}} und {{CoordinateLONG}}. --PM3 14:59, 26. Sep. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: тнояsтеn ⇔ 14:05, 9. Nov. 2011 (CET)

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)

Wurde umbenannt nach Kategorie:Wikipedia:Koordinaten-Parameterfehler. Sind alle betroffenen Vorlagen angepasst worden, wer hat den Überblick? --тнояsтеn ⇔ 13:04, 19. Nov. 2011 (CET)

Vorlage:CoordinateMSG, Vorlage:CoordinateError und Vorlage:Coordinate/Test/MSG sind angepasst. Ich denke, das sind alle. --PM3 14:41, 30. Nov. 2011 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: тнояsтеn ⇔ 15:05, 30. Nov. 2011 (CET)

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)

Habs mal versucht umzusetzen. --тнояsтеn ⇔ 12:48, 4. Dez. 2011 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: тнояsтеn ⇔ 19:28, 4. Dez. 2011 (CET)

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)

Archivierung dieses Abschnittes wurde gewünscht von: --PM3 02:02, 3. Jan. 2012 (CET)

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)

Archivierung dieses Abschnittes wurde gewünscht von: Glückauf! Markscheider Disk 17:49, 6. Jan. 2012 (CET)

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: [5] - 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)

Man schaue sich mal Liria (Südsudan) an: Die eingebundene Südsudan-Karte ist mit Central Equatoria untertitelt. Ist so wohl nicht erwünscht, oder? … «« Man77 »» 18:43, 1. Dez. 2011 (CET)

Da könnte man statt region=SD-17/SS einfach region=SS/SD-17 schreiben und es wäre in Ordnung. NNW 10:13, 2. Dez. 2011 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: тнояsтеn ⇔ 20:26, 22. Mai 2012 (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)

ICON2 ist ein Bild, das sollte überall gehen. --Kolossos 23:59, 15. Okt. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: тнояsтеn ⇔ 20:26, 22. Mai 2012 (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)

Jetzt WD:Kartenwerkstatt/Archiv5#PDF-Karten der USA. --тнояsтеn ⇔ 20:50, 24. Jan. 2012 (CET)

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)

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
• Amerikanische Jungferninseln
• 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
• Hong Kong
• Heard und McDonaldinseln
• Kaimaninseln
• Kokosinseln
• Macao
• Martinique
• Mayotte
• Montserrat
• Neukaledonien
• Niue
• Nördliche Marianen
• Norfolk-Insel
• Pitcairn
• Puerto Rico
• Réunion
• Saint-Pierre und Miquelon
• Sint Maarten
• Spitzbergen und Jan Mayen
• Südgeorgien und die Südlichen Sandwichinseln
• 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)

Habs gerade nochmal getestet: Wenn ich z.B. in Anguilla die Koordinatenparameter aus der Vorlage entferne, wird ein Eintrag für Kategorie:Wikipedia:Lagewunsch (AI) erzeugt. Das ist dann lästig für die Artikelautoren. Einige der Kategorien existieren inzwischen schon; den Rest lege ich nun an. --PM3 06:08, 25. Jan. 2012 (CET)

Ah, hier gibt's nochmal Unterschiede: Es gibt abghängige Gebiete wie Kategorie:Französisch-Guayana, das unter den unter Kategorie:Frankreich eingeordnet ist. Da klappt das auch mit der Einsortierung der Lagewünsche für Französisch-Guayana unter denen für Frankreich. Andererseits gibt es solche wie Kategorie:Anguilla, das unter keinem Staat eingeordnet ist, und dort landen die Lagewünsche auch nicht in der GB-Kategorie. Und dann gibt es Fälle wie Kategorie:Cookinseln, wo wir die Kategorie unter Neuseeland einordnen, das mit den Lagewünschen aber trotzdem nicht funktioniert.

Blickt jemand durch, was da los ist? Das Kategorieanlegen stoppe ich erst mal wieder, bis das geklärt ist. --PM3 06:27, 25. Jan. 2012 (CET)

Es gibt wohl Diskrepanzen zwischen der Handhabung bei den ANR-Kategorien und den ISO-Vorlagen. Die Bouvetinsel ist z.B. laut Vorlage:Info ISO-3166-2:BV Level 0, d.h. nicht administrativer Teil eines Staates, aber Kategorie:Bouvetinsel hängt unter Norwegen. Ich denke ersteres ist hier richtig. --PM3 14:47, 25. Jan. 2012 (CET)

Alles, was nicht automatisch in einer anderen Wartungskategorie landet, habe ich nun angelegt und ggf. unter den Staaten eingeordnet, von denen die Gebiete abhängig sind. Wünschenswert wäre, dass das automatisch passiert, aber ich weiß nicht, ob man an den ISO-Vorlagen so einfach rumbasten kann, wie ich es probehalber bei Svalbard & Jan Mayen getan habe: [6]--PM3 15:50, 25. Jan. 2012 (CET)

In dem Fall: nein, das hat die Positionkarten in Bellsund u.a. zerschossen. Auch sonst bin ich davon nicht so begeistert: ISO 3166 ist ein streng hierarchisches System, ein …-1-Code hat nunmal kein top/upper (und die Vorlage ist auch in Vorlage:Info ISO-3166-2/Info/Wartung-Widerspruch aufgetaucht). Dass sich das System nicht an die politische Gliederung hält ist schade, aber kaum änderbar.

Regionen, denen sowohl ein …-1 als auch ein …-2-Code zugeteilt wurde sind natürlich schwierig – bis hin zu semantisch falsch. Ein anderes Beispiel wäre ISO 3166-2:UM. Hier wurde dieselbe Bastelei versucht, allerdings besser umgesetzt mit einer Weiterleitung von Vorlage:Info ISO-3166-2:UM auf Vorlage:Info ISO-3166-2:US-UM. Mit der Folge, dass sich jetzt die UM-Codes beschweren, dass sie eigentlich Level-2-Codes sein müssten wenn sie dem Level-1-Code US-UM untergeordnet sind. Will ich jetzt aber auch nicht zurücksetzen, sowas sollte jedenfalls unter Vorlage Diskussion:Info ISO-3166-2#Ein Gebiet, zwei Codes (zum zweiten)) weiter besprochen werden. -- ✓ ^Bergi 19:23, 25. Jan. 2012 (CET)

Bergi, Problem verstanden. Und eben es bleibt mit diesen doppelt vergebenen Codes ein Bastel. Weiterleitungen sind wohl der beste Lösungsansatz. Garantiert immerhin Einheitlichkeit in der WP. Und das Gemotze wegen falschem Level lässt sich wohl auch noch umgehen. wenns nicht mit weiterleitung geht so kann ja die eine vorlage die andere mit den richtigen Parametern aufrufen. kostet dann halt etwas mehr als die blose Weiterleitung-- visi-on 12:22, 26. Jan. 2012 (CET)

Problem nicht verstanden ;-)

Mir gehts darum, von einem abhängigen Gebiet wie den Kokosinseln (Vorlage:Info ISO-3166-2:CC) automatisch auf den ISO-Code des Staates zu kommen, zu dem dieses Gebiet verwaltungstechnisch gehört (hier: Australien, Code AU). Unter AU existiert kein Subcode für die Kokosinseln, d.h. es ist kein Ziel für einen Redirect oder einen Vorlagenaufruf vorhanden. Ich bräuchte also neben der Information admtype=Außengebiet Australiens in Vorlage:Info ISO-3166-2:CC zusätzlich die Angabe code=AU. --PM3 12:33, 26. Jan. 2012 (CET)

Das klingt nach einer Lösung. Machen wir sie zu validen Level-0-Codes, aber führen wir weitere Parameter wie belongsto (z.B. in CC auf AU) und synonym (UM auf US-UM) ein - wobei es zu SJ kein Synonym gibt, hier muss der Verweis auf NO genügen. -- ✓ ^Bergi 18:59, 26. Jan. 2012 (CET)

Kann es vorkommen bzw. macht es Sinn, dass belongsto auf etwas anderes als Level-0 zeigt? Ansonsten sollte ein Parameter für beides genügen. Wäre insgesamt einfacher auszuwerten. --PM3 03:31, 27. Jan. 2012 (CET)

synonym und belongsto hat bei bergi unterschiedliche Semantik. Aber synonym lässt sich durch Weiterleitung/Einbindungen implizit und eben einheitlich in der jeweils gewünschten Richtung (abhängig von der Autonomie) realisieren. dh. ein level 1 code könnte sowohl auf den level 0 gehoben als auch ein von 0 zu 1 gesenkt werde. Dann würde der code belongsto genügen.-- visi-on 08:49, 27. Jan. 2012 (CET)

PS das umbiegen vom einen zum andern Code sollte man mit den betroffenen Portalen aushandeln ;-) -- visi-on 09:02, 27. Jan. 2012 (CET)

@PM3: Keine Ahnung, das hab ich grad erst erfunden :-)

Natürlich würde ein belongsto genügen. Simple Programmierung: Alles was ein belongsto hat wird in dessen Kategorie einsortiert, alles andere in seine top-Kategorie. Um aufwändige Programmierung zu verhindern (etwa „top of synonym/belongsto of upper“), wird einfach bei allen UM-Vorlagen belongsto=US eingefügt.

synonym war bloß als semantischer Zucker gedacht. Sollten wir mal festlegen wollen, statt US-UM nur noch UM an den Geohack zu übergeben oder sowas, dann könnte man diese Info durch Auswerten von Synonymen kodieren. Und vor allem ließe sich in der Info-Vorlage ein fetter Kasten einbauen der auf den Sachverhalt hinweist, und den fände ich durchaus auch heute schon sinnvoll (kann man aber auch als Parameter der Infovorlage gestalten).

@Visi-on: Was genau muss man da erst mit den Portalen aushandeln? Die Information sollte durchaus in die Vorlagen eingepflegt werden. Oder meinst du, man solle erst die Karibik-Georeferenzierer fragen, ob sie nicht ihre eingenen Kats behalten wollen, und die Festlandfranzosen, ob sie Karibik-Lagewünsche in ihrer Kat haben wollen? -- ✓ ^Bergi 15:23, 27. Jan. 2012 (CET)

das eine ist die faktische Selbständigkeit und das andere de jure die Abhängigkeit. Da ist schon Interpretationsspielraum unter welchem Code nun in der WP eingeordnet werden soll. Und genau dafür sind die Fachportale da. Denn Erfahrungsgemäss sind die einen Codes historisch und die andern zukünftig. Der Weg in die Unabhängigkeit wird aber selten an einem Tag erledigt.-- visi-on 14:38, 30. Jan. 2012 (CET)

Sollte auf jeden Fall mit den Kategorieeinordnungen übereinstimmen, z.B. Kategorie:Anguilla derzeit nicht unter GB eingeordnet, dagegen Kategorie:Sint Maarten unter NL. --PM3 16:06, 30. Jan. 2012 (CET)

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, [7])? --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/Mitarbeit/Wartungslisten/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/Mitarbeit/Wartungslisten/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)

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. Beispiel Zone 32T, 381189 / 5200911 (46° 57′ 4″ N, 7° 26′ 19″ O)46.9510817.438637
  2. Beispiel 600000 / 200000 (46,9511° N, 7,4386° O)46.9510817.438637
  3. Beispiel 46,9511° N, 7,4386° O (Zone 32T, 381189 / 5200911)46.9510817.438637
  4. Beispiel 46° 57′ 4″ N, 7° 26′ 19″ O (600000 / 200000)46.9510817.438637
  5. article46.9510817.438637
  6. article46.9510817.438637

• 1. article46.9510817.438637

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 [8]? --✓ ^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: [9] ü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 [10] 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)

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)

So was in die Richtung macht die Vorlage:ISO Kat. --тнояsтеn ⇔ 08:52, 19. Sep. 2012 (CEST)