„Wikipedia Diskussion:WikiProjekt Georeferenzierung“ – Versionsunterschied

Archiv

Archivübersicht

Wie wird ein Archiv angelegt?

WikiProjekt Georeferenzierung

• Über das Projekt
• Anwendungen
• Hilfe
• Lagewunsch
• Vorlage:Coordinate
• Vorlage:Positionskarte
• Vorlage:GeoTemplate
• Mitarbeit
• Archiv

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

Automatische Archivierung

Auf dieser Seite werden Abschnitte montags automatisch archiviert, deren jüngster Beitrag mehr als 360 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten. Die Archivübersicht befindet sich unter Wikipedia Diskussion:WikiProjekt Georeferenzierung/Archiv.

Automatische Archivierung

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

Vorlage:Autoarchiv-Erledigt/Wartung/Festes_Ziel

OSM4Wiki: neue Version sucht Tester

Die oben erwähnte neue Version ist fast fertig. Nun suche ich Leute, die das Tool testen möchten: verschiedene Browser/Betriebssysteme/Geräte, Artikel mit exotischen Sonderzeichen, Manipulationsversuche durch manuelle Adressen etc.

Außerdem hatte ich das Tool damals für die Vorlage:All_Coordinates geschrieben, aber da hat sich inzwischen einiges geändert, und weitere Vorlagen sind hinzu gekommen, die ich überhaupt nicht überblicke. Hier wäre von versierten Leuten zu prüfen, ob die neue Version kompatibel ist.

Die Voraussetzungen zum Testen sind einfach: man braucht nur ein paar Zeilen Javascript in "monobook.js" unter seiner Benutzerseite einzufügen, und alle Links auf das alte Tool werden automatisch auf das neue Tool umgeleitet, das derzeit noch auf meinem privaten Server installiert ist.

Die Frage ist: wo finde ich Tester? Hier? Oder sollte ich woanders zum Testen einladen? --Plenz (Diskussion) 02:05, 14. Mai 2024 (CEST)

Vielleicht könntest du dein Projekt Benutzer:Plenz/OSM for Wiki noch etwas näher beschreiben. Ein erster Blick auf deine Seite hinterlässt bei mir keinen guten Eindruck: Im Abschnitt "Zum Ausprobieren" erhalte ich bei den grünen und roten Feldern nur eine nichtssagende einfarbige Seite (vermutlich weil ich das Tool nicht aktiviert habe - aber wie soll ich es ausprobieren wenn ich nicht erfahre wie?), was die gelben Felder sollen wird nicht erläutert, weiter unten steht "ich teste nur mit den neuesten Versionen von Firefox und Internet Explorer" - wirklich Internet Explorer? Und wie das Tool überhaupt eingebunden ist und funktioniert, erfährt man auch nicht. -- Gerd Fahrenhorst (Diskussion) 13:23, 14. Mai 2024 (CEST)

Was ich oben geschrieben hatte, war nur eine Art Vorankündigung, um zu sehen, wer sich als Tester zur Verfügung stellt.

Ja stimmt, die oben verlinkte Seite ist uralt, die roten und grünen Felder funktionieren längst nicht mehr. Die gelben Felder zeigen das bisherige Projekt. Da kannst du sehen, worum es geht.

Inzwischen habe ich eine neue Seite für die neue Version erstellt: OSM_for_Wiki_v.2. Dort findet man auch ein kurzes Javascript-Programm, das im jeweils besuchten Artikel alle Links von der alten auf die neue Version umbiegt.

Wie das Tool eingebunden ist? Wie oben erwähnt: in der Vorlage All Coordinates und vermutlich auch in anderen Vorlagen. Wie die Einbindung genau funktioniert, habe ich längst vergessen.

Deshalb suche ich Leute, die sich mit diesen Vorlagen auskennen: in welchen Vorlagen ist das Tool bereits eingebaut? Welche Parameter werden übergeben? Bedient das Tool alle Parameter korrekt? Werden die Funktionen des bisher verwendeten Tools kmlexport korrekt ersetzt?

Diese Tests sind weit wichtiger, als verschiedene Browser zu testen. Ja sorry, ich meine eigentlich den Edge.

--Plenz (Diskussion) 12:56, 23. Mai 2024 (CEST)

@Plenz: Danke für die Version 2. Du solltest auf deiner Projektseite klarer herausstellen worum es geht. Viele Wikipedianer nutzen das zwar, kennen aber den Namen des Tools überhaupt nicht. (Vergleiche mal meine Toolpage c:User:Stefan_Kühn/Postcardcatfinder). Screenshoots machen sich immer gut. - Außerdem nutzt nicht jeder "monobook.js". Bei mir ist es "vector-2022.js". Also lieber von "Benutzerdefiniertes Javascript" schreiben. - Ich würde dich bitten als Default das Clustern der Koordinaten zu deaktivieren. Bei deinem Beispiel mit der Sonnenfinsternis clustert die Anzeige, obwohl das überhaupt nicht notwendig wäre aus (Aus Sicht des Kartografen). Beste Grüße --sk (Diskussion) 14:02, 23. Mai 2024 (CEST)

Die Sache mit dem monobook.js dient nur zum Testen. Mein Tool funktioniert aus Sicherheitsgründen nur, wenn es von einer Wikipedia-Seite aus aufgerufen wird.

Die Koordinaten bei der Sonnenfinsternis sind aus gutem Grund geclustert: die zwei Beobachtungsstationen in Thailand liegen sehr dicht zusammen. In Indien liegen zwar nur zwei Koordinaten dicht zusammen, aber weil die dritte Koordinaten das Cluster-Icon dieser beiden berühren würde, wird sie in den Cluster übernommen.

Ich habe jetzt Screenshots und einen Satz ganz oben hinzugefügt. --Plenz (Diskussion) 07:47, 24. Mai 2024 (CEST)

Jetzt funktioniert auch das Sammeln von verlinkten Seiten. Siehe 3. Beispiel-Link auf der Projektseite --Plenz (Diskussion) 12:35, 25. Mai 2024 (CEST)

OSM-Verlinkung von Abschnitten aus Vorlage Hinweis Seiten-Koordinaten alt Vorlage All Coordinates

Moin Moin zusammen, ich transportiere hier mal ein Thema her, da es schon des Öfteren aufgetaucht/angesprochen wurde, aber glaube ich, nie hier wirklich Thema war. Für getätigte Pings bitte ich im Voraus um Entschuldigung, wenn diese nicht erwünscht waren, aber vllt. könnt ihr auch etwas zur Aufklärung beitragen, jede Info ist gerne gesehen ;)

Problembeschreibung:
Als Beispiel nehmen wir den Artikel Liste von Burgen und Schlössern in Irland, da dieser auch an anderer Stelle bereits andiskutiert worden ist.
Wir haben hierzuwiki die Vorlage Hinweis-Seitenkoordinaten, welche einen Link zu OSM und zu WikiMap bereitstellt. In alter Vorlage hat das All Coordinates gemacht, diese soll aber abgelöst werden. Die entsprechende Vorlage und den Link findet man unten im Artikel. Klickt man diesen OSM-Link an, so wird von der gesamten Seite alle Koordinaten genommen und, augenscheinlich, nach OSM transportiert und auch sauber dargestellt!
Die Vorlage bietet aber auch, dann man Sektionen machen kann, also Unterüberschriften nehmen kann und dann funktioniert der Klick leider nicht mehr und es läuft ins Leere (Beispiel: Spezial:Diff/247057586, einmal als Hinweis Seiten-Koordinate unter der Tabelle, einmal mit alter All Coordinates oben in der Kopfzeile).

Bisher:
Anfrage an verschiedenen Stellen, bei verschiedenen Benutzer (hier z.B.). Dabei finde ich eine Aussage als wahrscheinlich bzw. einen guten Ansatz:

• Vor ein paar Monaten wurde das generierte HTML für Überschriften geändert, um es barrierefrei und allgemein Werkzeug-kompatibel zu machen, und dies auch rund ein Jahr im Voraus angekündigt.
  Diese Werkzeuge betreiben „Screengrabbing“, heißt: Sie lesen die Struktur des HTML-Dokuments aus, um diesen irgendwelche Informationen zu entnehmen.
  Wenn das Werkzeug seine Identifikation des HTML-Elements und des sichtbaren Überschriften-Textes (könnte ja verlinkt sein) nicht den veränderten Gegebenheiten angepasst hat, dann kann es seitdem keine Texte von Abschnitts-Überschriften mehr in der Seite finden.

Leider gibt es wohl keine Doku, wie das OSM aufgebaut ist bzw. die Auslesung macht und der Wunsch hier aufzuschlagen wurde immer wieder gemacht. Dies hole ich nun für all diese Personen mal nach. @Commander-pirx zur Kenntnis. Vllt. kann auch ✓ oder Herzi Pinki noch etwas sagen, da ihr in der Vorlage auch größere Änderungen mal gemacht hattet. Aber auch Benutzer:Plenz würde ich kurz mit pingen, da du ja ein JS entwickelt hast.

Blick nach Vorne:
Ich und auch alle anderen, welche von diesem "Problem"/Herausforderung betroffen sind, würden uns riesig freuen, wenn wir gemeinsam an einer Lösung arbeiten würden, vllt. hier ein Brainstorming machen und weitere Schritte machen/festlegen. Vielen Dank und Danke im Namen aller --Crazy1880 19:28, 24. Jul. 2024 (CEST)

Eine bekannte Doku-Serie berichtete auch davon:

• H:Ü #Struktur ab 2023
• Der Text der Überschrift stünde in der Sprache der Seite bzw. des Wikis, während die Linkbeschriftungen von Funktionsaufrufen in der Sprache des aktuellen Kontos und der GUI generiert werden.
• Die Screenreader sammeln alle Überschriftentexte der Seite ein und bauen aus denen und diversen weiteren gefundenen Wiki-Navigationselementen eine Navigation für Blinde. Da standen dann auch noch alle Abschnittswerkzeuge in den Überschriftentexten.
• Wer das bisher irgendwie analysiert hatte, wird es nun irgendwie anders lösen müssen.

VG --PerfektesChaos 21:13, 24. Jul. 2024 (CEST)

Bin auf Urlaub, mich bekommst du erst wieder in einer Woche. --Herzi Pinki (Diskussion) 22:50, 24. Jul. 2024 (CEST)

Nachtrag:

Da ich viel mit Listen (Burgen und so) arbeite, habe ich mal weitere gecheckt. Es scheint mir ein Problem mit den Abschnitten/section zu sein; bei z.B. Liste von Burgen und Schlössern im Kanton Zürich funktioniert die einfache Hinweis Seiten-Koordinaten-Vorlage ohne Probleme und gibt auf OSM und Wikimap alle Koordinaten korrekt an. Bei Liste der Burgen und Schlösser im Kanton Zug dagegen gibt die einfache Hinweis Seiten-Koordinaten-Vorlage auf OSM nur acht von neun Koord. an (die mit Artikel) die neunte ohne Artikel fehlt, auf Wikimap funktionierts für "alle Neune". Auf Liste von Burgen und Schlössern im Kanton Solothurn, die nur "Linked" aufrufen soll, funktioniert es nicht für OSM, aber wohl mit WikiMap. Ergo: schein es neben dem section Problem auch noch für unsere Vorlagen TEilprobleme beim Aufruf zu geben (damit es ja auch richtig kompliziert wird...). Leider bin ich kein Programmierer und kann da ausser testen und blöden Sprüchen (sorry) nicht viel helfen. (viele - die mit Listen arbeiten, würden sich aber freuen - eine Lösung zu finden) MfG --commander-pirx (disk beiträge) 11:50, 25. Jul. 2024 (CEST)

Die jetzt laufende neue Version von OSM4Wiki funktioniert mit den ersten beiden Links, soweit ich das sehe. Bei der Liste im Kanton Solothurn erhebt sich die Frage, welche Intelligenz von meinem Tool da gefordert wird. Woher soll es wissen, dass es nur die Artikel von Burgen und Schlössern nach Koordinaten durchsuchen soll? Die erste Tabellenzeile verlinkt Balm, Balm bei Günsberg und Grottenburg. All diese Lemmata werden dann natürlich auch nach Koordinaten durchsucht, und zwar ALLE verlinkten Lemmata, da die Suche ja nicht auf die Sektion "Liste" begrenzt ist. Dass mein Tool aktuell gar nichts findet, liegt daran, dass es "linked=" erwartet und nicht "linksfrom=". --Plenz (Diskussion) 22:04, 26. Jul. 2024 (CEST)

Wie PerfektesChaos schon analysiert hat, liegt es nicht an der Vorlage oder an dem generierten Link, und man kann da auch nichts daran ändern. "Leider gibt es wohl keine Doku, wie das OSM aufgebaut ist bzw. die Auslesung macht" - auf den von der Vorlage verlinkten Toolseiten wird auf Benutzer:Plenz/OSM for Wiki und Benutzer:DB111/Tools#WikiMap verwiesen, daher würde ich empfehlen bei den beiden nachzufragen. --✓ ^Bergi 23:32, 25. Jul. 2024 (CEST)

Ich arbeite schon seit geraumer Zeit an einer neuen Version von OSM4Wiki und hatte an verschiedenen Stellen um Unterstützung gebeten. Vor allem habe ich gefragt, ob auch andere Vorlagen außer AllCoordinates mein Tool benutzen. Diese Frage stellte ich an verschiedenen Stellen, aber niemand konnte mir etwas dazu sagen :(

Ich habe jetzt erst mal die neue Version aktiviert, auch wenn sie noch nicht ausgereift ist. Siehe dazu auch Vorlage_Diskussion:All_Coordinates.

Zuerst mal habe ich keine Lust, dieses Thema an mehreren Stellen gleichzeitig zu diskutieren. Bitte einigt euch auf EINE Seite. --Plenz (Diskussion) 13:41, 26. Jul. 2024 (CEST)

1. Die EINE Seite – ist die Dokumentationsseite des jeweiligen Werkzeugs, begleitet von einer Anlaufstelle für Anfragen und Problemberichte.
2. „auch andere Vorlagen außer AllCoordinates mein Tool benutzen“ – alle in Frage kommenden Vorlagen verwenden die gleiche URL zum Werkzeug. Wenn in der jeweiligen Werkzeug-Doku beschrieben wird, dass sich als breaking change etwas an dieser URL ändert und zukünftig die bisherigen Direktverlinkungen ohne Vorlagenbenutzung nicht mehr funktionieren würden, dann bekämen es alle anderen Kunden schon mit.

Die Vorlagen dekorieren lediglich die URL anders, die aus den Vorgaben generierte URL ist immer gleich.

VG --PerfektesChaos 14:29, 26. Jul. 2024 (CEST)

Moin, dann mache ich mal den Ping an DB111 und hoffe, dass er auch hierzu beitragen kann ;) Danke ✓ mfg --Crazy1880 15:36, 26. Jul. 2024 (CEST)

Hallo, wir können versuchen das alte Tool zu reparieren (wie PC schon anmerkte, haben Änderungen in der Abschnittsdarstellung die Section-Erkennung kaputtgemacht), ansonsten müsste Plenz (bzw. ihr) mal einschätzen, wie schnell & erfolgreich er das Tool durch seine neue Version ersetzen kann. Aber da die Reparatur eigtl. einfach gehen müsste, könnte man ja das alte OSM-Tool noch weiterbetreiben.

Da kommen wir zum schwierigen und untechnischen Teil der Geschichte: Meine Bemühungen, Zugang zum verantwortlichen Backend-Tools KMLExport zu kriegen, scheiterten schon bei den letzten Fehlern an übelster "Bürokratie" (der Originalautor hat dem Tool keine Lizenz angeheftet, damit darf/will die WMF, oder bd808, niemanden das Tool adoptieren lassen). Der Original-Autor (Para) ist nicht mehr Wiki-aktiv, er hat damals zum Glück einem Zweit-Autor noch Tool-Zugang gegeben, der leider auch nur sehr sporadisch aktiv ist und den ich um Bugfixes immer sehr "betteln" muss. Ich habe ihn jetzt nochmal gebeten, mir Tool-Zugang zu geben (verstehe seinen "Egoismus" da auch nicht, da es ja wie gesagt von Para und nicht von ihm geschrieben wurde), die zweite Möglichkeit wäre, dass ich das Tool als Kopie abspalte und selber weiterbetreibe (der Quellcode liegt vor). Soviel von mir, der mit dem OSM-Tool eigtl. nichts direkt zu tun hat, ich habe es nur am Leben gehalten (Bugfixes, Sonderzeichen-Fähigkeit, ...), während Plenz über die sieben Weltmeere schipperte :-) --DB111 (Diskussion) 13:24, 27. Jul. 2024 (CEST)

Danke für deine Bemühungen. Inzwischen funktionieren alle hier und anderswo bemängelten Artikel mit der neuen Version, und zwar ohne kmlexport. Dennoch würde es mich sehr interessieren, wie kmlexport arbeitet. Vor allem: wie kriegt es die vielen Artikel, die in einer Liste verlinkt sind, in Sekundenschnelle geladen??? --Plenz (Diskussion) 21:19, 27. Jul. 2024 (CEST)

Es führt einen Cache mit aktuell ca. 40.000 Artikelkoordinaten als Dateien in einem Unterordner. Das könnte das "Geheimnis" sein. --DB111 (Diskussion) 15:09, 28. Jul. 2024 (CEST)

Umpf... auf die Idee mit einem eigenen Cache war ich allerding auch noch nicht gekommen. Ich hatte den Verdacht, dass es irgend eine Möglichkeit geben könnte, direkt auf die Artikel-Datenbank von Wikipedia zuzugreifen ohne den Umweg über HTTP-Request. Weißt du vielleicht auch, wie WikiMap das macht? Benutzt das Tool ebenfalls kmlexport oder hat einen eigenen Cache? --Plenz (Diskussion) 17:46, 28. Jul. 2024 (CEST)

WikiMap nutzt die Wikipedia-APIs (performant, aber dadurch z.B. auch nicht Section-fähig), KMLExport eine Kombi aus Quelltextabruf per HTTP und Datenbankabfragen. Man könnte auch den ganzen Seitenquellcode per SQL laden, hier der KML-Export-Quelltext, da kannst Du schmökern (kein Geheimnis, hat Para im Phabricator so veröffentlicht, wenn auch etwas unglücklich, dass DB-Zugänge direkt enthalten sind). --DB111 (Diskussion) 21:54, 28. Jul. 2024 (CEST)

Danke für die Hinweise. Ich hatte schon den Verdacht, dass es so etwas wie Wikipedia-APIs geben könnte, hatte aber noch nicht danach geforscht. --Plenz (Diskussion) 22:20, 28. Jul. 2024 (CEST)

Die Liste von Burgen und Schlössern in Irland funktionieren jetzt auch. Die Ursache war: wenn da County Kerry als Section vorgegeben war, dann suchte mein Programm natürlich nach genau diesem Begriff mit Gleichheitszeichen davor und dahinter - und fand nichts wegen der zusätzlichen eckigen Klammern. Ich habe das jetzt so gelöst: wenn der Begriff nicht gefunden wird, wird noch mal mit je 2 eckigen Klammern davor und dahinter gesucht. Wobei ich nur hoffen kann, dass niemand auf die Idee gekommen ist, irgendwo in einer Sektionsüberschrift einen Wikilink mit Normaltext zu kombinieren. --Plenz (Diskussion) 22:30, 28. Jul. 2024 (CEST)

Hallo Plenz, stimmt leider nicht, Beispiel: County_Dún_Laoghaire-Rathdown. Bei mir werden im OSM-Link nur die ersten drei Burgen dargestellt, die restlichen 9 fehlen? Mhmm, ??? mfg --commander-pirx (disk beiträge) 00:03, 29. Jul. 2024 (CEST)

Geht jetzt. Falls du noch etwas findest, sag Bescheid. --Plenz (Diskussion) 21:46, 29. Jul. 2024 (CEST)

BESCHEID: Irgendwie funtioniert die section Darstellung mit OSM jetzt, aber im Menü links werden die Namen NICHT mehr oder UNVOLLSTÄNDIG angezeigt. [Beispiel...]. danke im voraus, mfg --commander-pirx (disk beiträge) 15:55, 1. Aug. 2024 (CEST)

Der Link zeigt auf das alte, reparierte Tool, der Link auf das Neu-Tool mit dem Problem wäre dieser. --DB111 (Diskussion) 19:57, 1. Aug. 2024 (CEST)

Moin Plenz, erstmal vielen Dank, ist ja super. Sage mal, könnte man auch standardmäßig die Pin-Ansicht aktivieren, anstatt die Gruppierung? mfg --Crazy1880 19:48, 29. Jul. 2024 (CEST)

Ja, du bist schon der zweite, der das wünscht. Aber erst mal muss das Tool korrekt laufen, dann kommen die Gimmicks an die Reihe. --Plenz (Diskussion) 21:44, 29. Jul. 2024 (CEST)

Das Tool wird auch international intensiv genutzt, vielleicht ein Grund mehr, das etwas defensiver anzugehen und nicht sofort das bewährte alte wegzuwerfen, siehe Disk z.B. hier. --DB111 (Diskussion) 12:04, 31. Jul. 2024 (CEST)

Ich habe nichts weggeschmissen, es handelt sich um eine Neuprogrammierung. Ich hatte schon vor Wochen an verschiedenen Stellen darum gebeten, mein Tool zu testen. Das mit der Pin-Ansicht und mit GeoGroups hätte mir schon längst mitgeteilt werden können. Die alte Version ist immer noch vorhanden und könnte in einer Minute wieder aktiviert werden, aber sie funktioniert ja leider überhaupt nicht mehr.

Neuestes Ärgernis: mein Editor "joe" ist verschwunden. Neuinstallierung wird verweiget. Wo kann ich das melden? --Plenz (Diskussion) 21:23, 31. Jul. 2024 (CEST)

Ich meinte, dass man die alte Version z.B. als wiki-osm.pl belässt und die V2 als wiki-osm2.pl vorsichtig vorlagenweise zuschaltet und testet. Keiner von uns kennt alle Verbauungen und die Commonsianer/ENler (und viele andere Länderwikis, die das Tool auch in ihren Vorlagen haben) lesen hier ja nicht mit und sprechen auch kein Deutsch. Das nimmt Dir auch den Druck. Es funktioniert in der alten Version ja nur der Section-Parameter nicht richtig und das liegt an KMLExport. --DB111 (Diskussion) 21:58, 31. Jul. 2024 (CEST)

OK, ich habe jetzt einfach ein Redirect auf die alte Version eingebaut, falls der Parameter "section" leer ist.

Ich versuche mich gerade an den Datenbank-Zugriffen. Den komplexen Ausdruck, der in kmlexport eingebaut ist, verstehe ich so gut wie gar nicht. In den Beschreibungen steht alles mögliche, aber ein Beispiel, wie man einfach nur einen Artikel aus der Datenbank holt, habe ich noch nicht gefunden. Kannst du da weiterhelfen? --Plenz (Diskussion) 11:06, 1. Aug. 2024 (CEST)

Ich würde jetzt trotzdem erstmal wie besprochen einen Fork vom KMLExport machen und dort zwei gravierende Fehler beheben (Links gehen auch nicht mehr, seit MediaWiki-DB-Änderung im Juni), Sections gehen nicht mehr. DAnn wäre das alte OSM4Wiki wieder funktionsfähig. Zu deiner Frage: Ganz ohne Joins wird es nicht gehen, meist muss man sich über ein paar Tabellen hangeln, hab es mir aber KMLExport noch nicht genauer angesehen. --DB111 (Diskussion) 14:46, 1. Aug. 2024 (CEST)

a) @DB111 und @Plenz: kann es sein dass das toolforging von OSM gerade überhaupt nicht funktioniert, es fkt momentan wohl kein Zugriff auf die OSM Koordinatendarstellung? mfg --commander-pirx (disk beiträge) 15:44, 1. Aug. 2024 (CEST)

b) @DB111: wie kann ich in Vorlage:Hinweis Seiten-Koordinaten mit section Parameter die Wikimap-Darstellung abschalten, da die Abschnitte ja nicht darstellen kann, sondern alle Korrd. des gesamten Artikels anzeigt..? mfg --commander-pirx (disk beiträge) 15:50, 1. Aug. 2024 (CEST)

„Darstellung abschalten, da die Abschnitte ja nicht darstellen kann“

• Nach Vorliegen einer vollständigen Werkzeug-Dokumentation des robusten Endzustands kannst du dich mit diesem Anliegen an WP:VWS wenden.

VG --PerfektesChaos 16:24, 1. Aug. 2024 (CEST)

@Commander-pirx Bei mir gehen beide Tools.

Wie PC schreibt, ist die Ausblendung von WikiMap bei Abschnitten bei der Vorlagenumstellung unter Tisch gefallen, kann die Vorlagenwerkstatt ganzmachen.

@Plenz Ich habe jetzt KMLExport geforkt/rudimentär repariert und Dein neues Tool testhalber mal in "wiki-new" umgeschoben, möchte erstmal Feedback kriegen, ob jetzt das Alt-OSM-Tool wieder besser läuft. Wir haben hier in Deiner Abwesenheit auch einiges an Arbeite reingesteckt (z.B. https://phabricator.wikimedia.org/T226481), wäre schade, jetzt sofort ein Neu-Tool an den Start zu bringen, wo wir Zeichnsatzprobleme usw. erstmal ausräumen müssen. --DB111 (Diskussion) 17:48, 1. Aug. 2024 (CEST)

@Plenz Gut finde ich Deinen neuen Unterbau auf Leaflet-Basis, der alte hat bestimmt schon lange auf dem Buckel. Wäre vielleicht ein guter Kompromiss, erstmal das Frontend zu modernisieren und das Backend auf KMLExport zu belassen?! --DB111 (Diskussion) 22:44, 1. Aug. 2024 (CEST)

Puh. Ich hatte das noch gar nicht gelesen, loggte mich auf dem Server ein und wollte schnell noch einen Bug beheben und war erst mal reichlich geschockt, die alte Version vorzufinden.

Nun ja. Lassen wir es erst mal so. Immerhin hatte die Umstellung dazu geführt, dass die neue Version endlich mal gründlich getestet wurde. Auf meine bisherigen Anfragen war ja kaum etwas gekommen.

Die Leaflet-Basis habe ich genommen, weil ich in irgend einem Forum eine Frage zu OpenLayers gestellt hatte und als Antwort bekam, so eine Frage wäre schon ewig nicht mehr gekommen, inzwischen haben alle auf Leaflet gewechselt, weil das besser läuft.

Falls du mit dem Frontend die Oberfläche mit den Ergebnissen meinst: das läuft doch schon perfekt (ich muss nur die Sache mit dem Cookie noch einbauen). Dass die Texte in der Tabelle nicht immer korrekt sind, liegt an der Auswertung der runtergeladenen Seiteninhalte, die offensichtlich nicht immer so vorliegen, wie ich mir das dachte. Ich hoffe, dass der direkte Zugriff auf die Datenbank einheitliche Inhalte bringt. --Plenz (Diskussion) 01:09, 2. Aug. 2024 (CEST)

Mitlesend:

• Ich würd ja nicht versuchen, Wikisyntax zu lesen.
• Weil da auch Vorlagen eingebunden sein können, und Überschriften von Vorlagen erst generiert werden können, ist das kein robuster Weg.
• Ich würde mir eher den Inhaltsbereich als HTML-Schnipsel vom Server holen.
• In dem lassen sich alle h1/h2/h3/h4/h5/h6 auflisten.
• Diese Elemente haben eine HTML-Eigenschaft text und die ist gerade der plain text ohne irgendwelche Formatierungen und Extrawürste.
• Weil das etwas aufwändig ist, würde ich sowas (section-text nebst Koordinatenliste) in einer Cache-Datenbank hinterlegen, wozu ich mich weiter oben bereits geäußert habe. Die Cache-Version mag minimal veraltet sein, aber das muss ja nicht ausgerechnet die hier interessanten Informationen betroffen haben. Zuerst wird also gemäß der Cache-Infos geantwortet, danach geguckt ob der Cache-Eintrag noch aktuell ist. Wenn kein Cache-Eintrag dann dauert die Antwort. Wenn Cache-Eintrag nicht mehr mit der aktuellen Seitenversion übereinstimmt, dann nach Beantwortung neu aufbauen.

VG --PerfektesChaos 01:27, 2. Aug. 2024 (CEST)

Eine Cache-Datenbank anzulegen und zu pflegen, halte ich für einen deutlich höheren Aufwand, als eine Artikelseite zu untersuchen. Und für eine riesige Ressourcenverschwendung. --Plenz (Diskussion) 16:05, 2. Aug. 2024 (CEST)

Ja, mit Frontend meinte ich die Ergebnisanzeige, wie PC schon schreibt sollte das Backend (also die eigtl. Programm-Logik) für Abschnitte schon einen echten HTML-Parser benutzen, sonst kommst Du vom hundertsten zum tausendsten und wirst nie alle Eventualitäten abdecken. Deswegen die Idee: Dein neues Frontend z.B. erstmal mit KMLExport lauffähig machen, so haben die Nutzer eine modernere Oberfläche und Du musst Dich (erstmal) nicht mir mit Parsen, Kategorien, Verlinkungen und Abschnitten rumschlagen. --DB111 (Diskussion) 15:25, 2. Aug. 2024 (CEST)

Das wäre erst mal ein riesiger Aufwand, weil diese Trennung zwischen dem, was du Frontend und Backend nennst, in meinen Vorstellungen gar nicht existiert. Die neue Version hat mit KML überhaupt nichts zu tun.

All diese Überlegungen sind mir viel zu theoretisch. Ich bin mehr der Typ "probieren geht über studieren". Wenn ich erst mal in der Lage wäre, einen Artikel direkt aus der Datenbank zu holen, dann könnte ich sehen, wie lange das dauert und wie einfach oder schwierig es ist, Koordinaten, Überschriften und Verlinkungen zu finden, und DANN könnte ich weitere Überlegungen anstellen. --16:33, 2. Aug. 2024 (CEST) --Plenz (Diskussion) 16:33, 2. Aug. 2024 (CEST)

Nachtrag: du sagtest, du hättest kmlexport repariert. Hast du eventuell auch etwas an der Verbindung geändert? Der Befehl "DBI->connect($dbi, 's521..." funktioniert nicht mehr, aber in dem Quellcode-Link steht er immer noch so drin. Fehlermeldung: " Unknown MySQL server host 'wiki.labsdb'". --Plenz (Diskussion) 20:07, 2. Aug. 2024 (CEST)

Der Host heißt z.B. für die deutsche Datenbank dewiki.labsdb. Bitte verwende auch Deine eigene Tool-Anmeldung (s51907) und nicht die vom Tool KMLExport. Das Passwort findest Du im OSM4Wiki-Projektverzeichnis in der replica.my.cnf. --DB111 (Diskussion) 22:01, 2. Aug. 2024 (CEST)

Das Tool ist repariert, da können wir die Disk hier schließen. --DB111 (Diskussion) 23:16, 2. Aug. 2024 (CEST)

Es gibt offensichtlich noch ein weiteres Problem mit kmlexport: das Tool lässt doppelte Koordinaten einfach stillschweigend unter den Tisch fallen. Die Liste Wikipedia:Kontor Hamburg/Stolpersteine/fehlende Fotos enthält mehrere doppelte Koordinaten, wo zwei nebeneinander liegende "Stolpersteine" die selben Koordinaten haben. Das Problem ließe sich sicherlich umgehen, indem die letzte Dezimalstelle von einer der Koordinaten um 1 verändert wird, aber das müsste erst mal bekannt gemacht werden. --Plenz (Diskussion) 19:59, 8. Aug. 2024 (CEST)

Hab ich mal geändert, Dubletten werden jetzt zugelassen. --DB111 (Diskussion) 14:37, 9. Aug. 2024 (CEST)

Sorry, aber das scheint noch nicht zu funktionieren. Bei den "Stolpersteinen" fehlt z.B. der Eintrag "James Wiener".

Außerdem gibt es überhaupt keine Ergebnisse, wenn man "section=" benutzt. --Plenz (Diskussion) 14:44, 10. Aug. 2024 (CEST)

Hm, ich sehe James Wiener. Und wo siehst du Abschnitte in der Liste? --DB111 (Diskussion) 15:59, 10. Aug. 2024 (CEST)

• [1] ist ohne James Wiener.
• [2] Aufruf ohne "section" bringt Ergebnisse
• [3] Aufuf mit "section" ist leer.

Oder sind diese Aufrufe verkehrt? --Plenz (Diskussion) 18:01, 10. Aug. 2024 (CEST)

Wie ich oben schrieb, musste ich für die Reparatur einen Fork (Abspaltung) vom kaputten KMLExport vornehmen, an das Originaltool ist leider kein Rankommen und es bleibt kaputt.

OSM4Wiki nutzt jetzt https://osm4wiki.toolforge.org/kmlexport/kmlexport.pl --DB111 (Diskussion) 18:12, 10. Aug. 2024 (CEST)

Ah, mit diesem Link funktioniert es tatsächlich. Und offensichtlich funktioniert auch die Option "section". Super Arbeit!

Nun denn. Meine Idee, kmlexport zu ersetzen, basierte vor allem darauf, dass es ewig lange brauchte, verlinkte Seiten zu durchsuchen. Während dieser Zeit war nichts zu sehen, was so manchen Benutzer veranlasste, die Seite neu zu laden. Deshalb meine Idee, verlinkte Seiten schrittweise zu durchsuchen. Aber diese Beobachtung stammt aus der Zeit, als ich anfing osm4wiki zu programmieren. Inzwischen habe ich keine großen Wartezeiten mehr feststellen können. Vielleicht existierte damals der Datenbankzugriff noch nicht, oder der Cache nicht, oder der Cache war noch leer. Ich werde mich dann mal auf die Verwendung von kmlexport konzentrieren.

Inzwischen lässt sich bei meiner Bastel-Version die Option "ohne clustering" in einem Cookie speichern. --Plenz (Diskussion) 12:08, 11. Aug. 2024 (CEST)

Danke, deswegen geht ja auch Dein V1-Tool wieder. Ich hab bei der Gelegenheit gleich noch paar Sachen optimiert, die eher administrativer Natur waren. Die periodische Langsamkeit des Tools lag an Such-Bot-Überflutungen, die enorme Serverlast erzeugten. Klar, die Koordinaten-Tool-Links sind ja auch quasi in jedem Artikel. Alles Sachen, die Otto Normalprogrammierer oft gar nicht auf dem Schirm hat und die WMF interessieren die Tools auch nicht, solange sie den Server nicht komplett lahmlegen.P.S.: Dein Ansatz, das Tool nur aus dem Wikiversum aufrufbar zu machen, war deshalb eigentlich genau richtig, aber viele wollen Kartenlinks scheinbar auch direkt an ihre Freunde weiterschicken, bei Facebook posten, usw.

Ich hatte WikiMap geschrieben und mit in die Vorlage genommen, weil Dein Tool ja jahrelang mehr tot als lebendig war, aber inzwischen haben wir es aufgepäppelt.

Super, da viel Erfolg, wir könnten sogar den Level-Parameter für mehrere Kategorie-Ebenen mal wieder testen, wenn wir ganz mutig sind. --DB111 (Diskussion) 14:13, 11. Aug. 2024 (CEST)

Ist ja witzig: ich habe mein Tool immer für sehr lebendig gehalten, dafür hielt ich kmlexport für mehr tot als lebendig. Dass ich an meinem Tool jahrelang nichts gemacht hatte, liegt nur daran, dass es einwandfrei lief. Die Motivation, eine neue Version zu basteln, entstand allein durch das Clustering.

Übrigens: bei Liste der Museen in Dortmund fügt kmlexport einen Pfeil nach links hinter jeden Eintrag. Was hat es damit auf sich? --Plenz (Diskussion) 22:56, 13. Aug. 2024 (CEST)

Das Hauptproblem war auch eher infrastrukturiell. Wenn das Tool mal hing, war es ohne aktiven Maintainer eben tagelang nicht verfügbar. Ansonsten hat vor allem die Sonderzeichenfähigkeit gefehlt, wir haben es dafür auf Unicode umgestellt.

Ich vermute, der Pfeil zeigt an, dass es eine verlinkte Koordinate ist?! --DB111 (Diskussion) 23:34, 13. Aug. 2024 (CEST)

Das nehme ich auch an. Aber WikiMap zeigt die Einträge ohne Pfeile. Da stellt sich die Frage, ob die Pfeile irgend einen Nutzen haben, oder ob mein Tool sie einfach entfernen sollte. --Plenz (Diskussion) 08:51, 14. Aug. 2024 (CEST)

Dein Tool (V1) zeigt doch auch keine Pfeile?! --DB111 (Diskussion) 10:26, 14. Aug. 2024 (CEST)

Tatsächlich, die alte Version beseitigt die Pfeile. Hatte ich völlig vergessen. Ich dachte, die Pfeile wären etwas ganz neues.

OK, die neue Version ist jetzt einsatzbereit. Ich habe die Verzeichnisse /work und /wiki wieder vertauscht. --Plenz (Diskussion) 22:09, 14. Aug. 2024 (CEST)

Spitze! Da sag uns noch, was die richtige Seite für Feedback ist, die hier? Da können wir hier schließen. --DB111 (Diskussion) 00:13, 15. Aug. 2024 (CEST)

Ja, genau diese Seite. Deine Antwort wurde auch wieder mal nicht in meinen Benachrichtigungen angezeigt, ich muss immer aktiv auf Suche gehen, ob mir jemand geantwortet hat. --Plenz (Diskussion) 10:17, 15. Aug. 2024 (CEST)

Bevor wir hier schließen: mir kam noch eine Idee wegen kmlexport. Da das Ding jetzt einen Fork im Verzeichnis von osm4wiki hat, würde es die Benutzung vermutlich beschleunigen, wenn es nicht umständlich über https aufgerufen werden müsste, sondern einfach direkt als Subroutine.

Meine Vorstellung:

• in einer separaten Datei makekml.pm steckt eine Subroutine makekml(), der die Parameter project, article etc. übergeben werden und die die fertige kml-Datei zurück gibt.
• kmlexport und osm4wiki binden diese Datei ein: require <Pfad>/makekml.pm
• kmlexport erzeugt je nach Parameter die kml-Datei, die Hilfe-Seite oder die Seite mit dem Quelltext
• osm4wiki benutzt die makekml() Subroutine direkt

Was hältst du davon? Hättest du eventuell Zeit, das zu erledigen, bevor ich daran herum pfusche? --Plenz (Diskussion) 20:07, 15. Aug. 2024 (CEST)

Wäre eine Idee, ich muss aber erstmal überlegen, ob ich das nicht ins offizielle KMLExport zurückführe, das ist ja auch tausendfach verlinkt und hat die Fixes noch nicht.

Kannst es natürlich zwischendurch zumindest mal so probieren, als Direktaufruf:

$ENV{QUERY_STRING}="project=de&article=Berlin";

my $kml=`../../kmlexport/kmlexport.pl`;

Die erste Zeile brauchst Du viell. noch nichtmal, wenn Deine OSM4Wiki-Parameter namenskompatibel sind und sich eins zu eins an KMLExport weiterleiten lassen. --DB111 (Diskussion) 21:29, 15. Aug. 2024 (CEST)

Das klappt so einfach leider nicht. Dein Befehl lädt nur die in Hochkommata definierte Zeichenkette in $kml. Ich bräuchte vermutlich doch eine richtige Funktion, die ich aufrufen kann.

Ob das allerdings mit dem originalen kmlexport möglich wäre, wage ich kaum zu glauben. Sind die einzelnen Tools nicht gegeneinander abgeschottet? Ich kann zwar "cd /data/project/kmlexport" machen, kann mir aber noch nicht mal den Inhalt anzeigen lassen.

Lass dir aber gern Zeit damit, ich bin erst mal weg bis Montag. --Plenz (Diskussion) 07:25, 16. Aug. 2024 (CEST)

Hast Du auch die richtigen (rückwärtigen) Hochkommata genommen wie oben bzw. es rauskopiert? Ich lass mir hier sowieso Zeit meines Ermessens, krieg noch nicht mal Geld dafür :-) Wir können die technische Disk. auch mal hier wegverlagern, können wir ja auf Tool- oder Benutzer-Disk weiterklären. --DB111 (Diskussion) 09:43, 16. Aug. 2024 (CEST)

Ich hab's jetzt geschafft, nachdem ich $ENV{'HTTP_ACCEPT_ENCODING'} = ""; gesetzt hatte, um das Komprimieren zu verhindern. Die Zeitersparnis bringt 0,4 bis 0,5 Sekunden, ist also nicht wirklich die Mühe wert. Wir können diese Diskussion nun schließen. --Plenz (Diskussion) 09:50, 21. Aug. 2024 (CEST)

Lint-Fehler: Doppelte IDs durch Koordinatenvorlagen

Die Vorlage:Coordinate erzeugt zahlreiche Fehler durch offensichtlich falsche Verwendung, bzw. die Belegung mit identischen Texten im Parameter |name=, diese dürfen laut Dokumentation jedoch immer nur einmal im Text vorkommen, um die Identifizierung des Objektes auf einer Karte zu ermöglichen. Viele Benutzer scheinen das nicht zu wissen, was nun zu dieser Problematik führt. Im Artikel werden dadurch zahlreiche identische Anker gesetzt. Ich würde vorschlagen, dass ein weiterer Parameter eingeführt wird, mit dem bei Mehrfachverwendung einer identischen Bezeichnung mit identischer Koordinate (beispielsweise Stolpersteine für mehrere Personen am selben Platz, aber an unterschiedlichen Stellen in Tabellen). Der Parameter sollte quasi so ähnlich funktionieren wie Nebenbox, also |mehrfach="1" und dadurch die identische ID unterdrücken.

{{Coordinate|NS=50|EW=7|type=landmark|text=ICON0|region=DE|name=Mehrfachangabe an dieser Stelle}}
{{Coordinate|NS=50|EW=7|type=landmark|text=ICON0|region=DE|name=Mehrfachangabe an dieser Stelle|mehrfach=1}}
{{Coordinate|NS=50|EW=7|type=landmark|text=ICON0|region=DE|name=Mehrfachangabe an dieser Stelle|mehrfach=1}}

Vermutlich ist auch Vorlage:CoordinateComplex davon betroffen, weil ein leerer Parameter |name= jeweils eine id="coordinates" erzeugt, die ebenfalls zu unerwünschten Doppel-IDs führt. Modul:Coordinates/kml? Teilweise ließe es sich vermutlich auch durch Zusammenlegung einzelner Tabellenzeilen abstellen, aber eben nicht in jedem Fall. Siehe beispielsweise Liste der Stolpersteine in Regensburg erzeugte 98 doppelte IDs. Teilweise zusammengelegt, anstatt doppelt eingebunden →Spezial:Diff/249405303/249409648#Stolpersteine für Ludwig Bär, Mathilde Bär, es sind aber noch →44 Fehler übrig. --Liebe Grüße, Lómelinde Diskussion 10:10, 14. Okt. 2024 (CEST)

Diese Vorlage(n) stehen auf der Abwrackliste.

• Niemand, der noch bei Trost ist, wird noch an denen herumprogrammieren.
• Erst recht nicht bei Einbindung in eine dreiviertel Million Artikel.
• Und Zusammenwirken von bald einem Dutzend Untervorlagen.
• Bloß nicht dran rühren.

Das Nachfolgemodell wird einen leicht anderen Parametersatz erhalten.

• Darunter auch id= nebst class= und style= wie heutzutage serienmäßig.
• Wer wirklich ein Sprungziel haben möchte, kann sich explizit ein geeignetes nicht kollidierendes aussuchen und reinschreiben.
• Von alleine gibt es sowas nicht mehr.

Wie bekannt, sind in den Nuller Jahren alle möglichen Elemente im Blindflug mit id= ausgestattet worden.

• Die allerwenigsten davon sind offenbar jemals zu irgendwas benutzt worden.
• Insbesondere ist mir noch nie aufgefallen, dass in einem Artikel jemand zu einer benannten Koordinatenangabe hingesprungen wäre.
• Eher kollidieren die mit Wunschzielen auf Abschnitte oder Tabellenzeilen, weil sie den gleichen Bezeichner verwenden.

Das alles erst nächstes Jahr.

• Es gibt 3–5 Leutchen, die sämtliche Anfragen und technische Wartungsaufgaben abarbeiten, und die sind auf viele Monate ausgelastet.
• Das Koordinatenthema ist von diesem Scheiß-Darkmode und dem ID-Kram abgeschossen worden, dazu einige Querulanten; dann zieht sich das eben länger hin.
• Zurzeit ist dein Wunsch betreffend FN in Abarbeitung; nachdem das abgeschlossen ist, kommt die nächste Anfrage dran.
• Irgendwie ist mir so, als ob ich die gleiche Anfrage vor einer guten Woche bereits einmal intensiv beantwortet hätte. Auch eine Methode, Ressourcen zu verbrennen.

VG --PerfektesChaos 12:40, 14. Okt. 2024 (CEST)

Das Problem ist eher, dass es, wie gesagt, für die Anzeige auf Karten verwendet wird. Trivial und eigentlich auch logisch wäre es, dass bei einem Friedhof nicht jede Koordinate „|name=Kreuz“ lauten darf, und bei 20 Stolpersteinen an einer Stelle, dürfen eben nicht 20 Personennamen übereinander geklatscht werden. Man kann scheinbar von der Karte aus auch wieder zurück zu eben diesem Ankerpunkt innerhalb der Tabelle springen (ich verwende so etwas echt nie). Es ist also durchaus nicht so Zitat: „Die allerwenigsten davon sind offenbar jemals zu irgendwas benutzt worden.“ →Karte 1 direkter Rücksprung und indirekt. Daher müssen die Anker ja eigentlich auch eindeutig sein und ich denke sie dürfen nicht entfallen. Du musst darauf auch nicht antworten. --Liebe Grüße, Lómelinde Diskussion 13:32, 14. Okt. 2024 (CEST)

NIH? Dann lieber neu machen. Das Koordinatenthema ist von diesem Scheiß-Darkmode und dem ID-Kram abgeschossen worden. Wird durch Einzelaktionen auch nicht wieder lebendig. Zu @Lómelinde:s Vorschlag: Dein Vorschlag hilft nicht. Es braucht Individualnamen und die müssen individuell und sinnhaft vergeben werden. Bei allen Anzeigen in Karten stehen diese Individualnamen links in der Navi, und erlauben onmouseover das highlighten der Punkte in der Karte und den Rücksprung an die Stelle, wo die Koordinate definiert ist. Wenn der Mausbeweger aber 20x Kreuz dort stehen hat, dann hilft dein neuer Parameter nicht, das richtige Kreuz zu finden. Auch ein automatisches Durchnummerieren würde den gleichen Namen keine benutzerlesbare Semantik verleihen. Das Problem, dass beim Lintern auftaucht, wird dadurch verursacht, dass der Parameter name als id verwendet wird und dass zu einem formalen Fehler führt, der jetzt genau welche praktischen Konsequenzen hat? Name in CamelCase zu schreiben, damit es der id-spec entspricht, wirft die Lesbarkeit über den Haufen um formales Zeugs ohne Relevanz abhaken zu können. Ansonsten gehören Koordinaten mE zum Core-Umfang der Mediawiki-SW und sollten dort umgesetzt werden. lg --Herzi Pinki (Diskussion) 00:54, 26. Okt. 2024 (CEST)

Vorlage:Coordinate, UTM-Koordinaten

Hallo Zusammen, ich würde gerne in der Vorlage:Coordinate UTM-Koordinaten eingeben, statt Grad/Minute/Sekunde oder Dezimalgrad. Also statt |NS = 55.742561 oder |NS = 55/44/33.22/Neinfach 77862.375

Gibt es da heute schon eine Möglichkeit das zu machen (ich habe leider auch mit subst nichts gefunden)? Sollte es noch keine Möglichkeit geben, wäre es mein Wunsch, dass man diese schafft. Ich habe gerade ein Liste mit Zuflüssen von einem Fluss in der Pipeline, wo ich aus der amtlichen Karte die UTM-Koordinaten der Quellen und Mündungen kopieren kann, aber da jeden Wert händisch umzurechnen ist mehr als mühsam...

Über jeden Tipp dankbar --The-Digit (Diskussion) 13:52, 4. Nov. 2024 (CET)

Das ist für die mittlere Zukunft so vorgesehen.

Die vorhandene Umsetzung musste mit den Mitteln um 2010 arbeiten, und die Vorlagenprogrammierung stößt dabei an Grenzen.

Basierend auf dem 2013 eingeführten Lua gibt es deutlich mehr Möglichkeiten, siehe BETA

UTM-Koordinaten haben allerdings ein Interpretationsproblem; 55.742561 könnte genauso UTM sein. 32 N 461344 5481745 und 32U 461344 5481745 transportieren hingegen die Information über das System.

VG --PerfektesChaos 15:05, 4. Nov. 2024 (CET)

Bzw. die Identifikation von Schreibfehlern wäre nicht möglich; die UTM-Zahlen sind zwar >180, aber ein vergessenes Dezimaltrennzeichen würde nicht mehr zur Fehlermeldung führen.

Fraglich ist jedoch, wer die Verzerrung umrechnen soll; alle unsere Werkzeuge basieren auf Kugelkoordinaten, und die UTM lassen sich zwar interpretieren, sind aber nicht mit dem Rest der Wiki-Welt kompatibel. OSM scheint mir zurzeit kein UTM zu akzeptieren? Wo fände ich die Umrechnungsformeln?

VG --PerfektesChaos 15:15, 4. Nov. 2024 (CET)

Hallo PerfektesChaos, vielen Dank für die schnelle Antwort. Nach der Umrechnungsformel habe ich heute auch schon gesucht und bislang nur ein Excel-Sheet gefunden, wo über gut 20 Spalten hinweg irgendwelche Rechenschritte unternommen werden. Daraus könnte man sie (mühsam) heraus schreiben und weiß dann erst nicht, ob das eine zuverlässige Quelle ist. Aber die muss ja auch irgendwo zu finden sein, ich kann da gerne noch etwas weiter suchen. Hab' vorhin aufgehört zu suchen, weil ich gehofft hatte, dass es schon eine wikiinterne Lösung gibt, zumal es den umgekehrten Fall ja gibt, zumindest wird das in der Doku Vorlage:Coordinate#Ausgabevarianten behauptet (ich hab's nicht ausprobiert, aber ich geh' mal davon aus, dass das geht).

Es ist einfach sehr nervig, wenn man aus der Karte Länge/Breite in UTM direkt rauskopieren kann und dann Länge und Breite einzeln in den Koordinatenumrechner rein kopieren muss um dann dort wiederum einzeln Länge und Breite mit copy&paste in die Wiki-Tabelle einzubauen. Wenn man nur zwei Punkte hat, geht das ja noch, aber wenn man das bei über 100 machen muss, wird man ja wahnsinnig.

Zum Interpretationsproblem, streng genommen sehen die ja so aus: 32U 438507.242 6177862.375, da wäre der Fall dann warscheinlich schon klar?!

Herzlichen Dank für den Job, den Du hier machst! --The-Digit (Diskussion) 16:51, 4. Nov. 2024 (CET)

Ich hatte mich kurz durch die von uns angebotenen Weblinks geklickt, die was umrechnend versprachen, aber da war erstmal nix konkret.

Grundsätzlich muss das gehen, denn da ist ja von einem Ellipsoid die Rede, ergo muss ein Sinus mit seinem Co einen Tango tangsen, und dann ließe sich das in der einen wie anderen Richtung mathematisch konvertieren.

Es muss nur irgendwer auf dem Planeten ein schlaues Lua-Modul schreiben, welches das hin und auch her umrechnet, nur die beiden Zahlenwerte und ggf. diesen Zonen-Code, und dann können alle Wikis das bei Bedarf aufrufen.

Erkennbar ist das vermutlich simpel: zwei?stellige Zahl – vielleicht Leerzeichen – Großbuchstabe – Leerzeichen – Zahl>999 – Leerzeichen – Zahl>999

VG --PerfektesChaos 17:55, 4. Nov. 2024 (CET)

Geht z. B. so: http://www.gpsy.com/gpsinfo/geotoutm/gantz/LatLong-UTMconversion.cpp.txt . Hier ist der umgekehrte Weg, wie unsere Vorlage die Ausgabe in UTM-Koordinaten bewerkstelligt: Vorlage:Coordinate/to UTM. --тнояsтеn ⇔ 19:44, 4. Nov. 2024 (CET)

Im Idealfall könnte man irgendwo im Wiki-System Bibliotheken ala PROJ (die nutze ich für Koordinaten-Umrechnungen im GeoHack-Umfeld) hinterlegen und dann z.B. per Lua aufrufen. Man implementiert ja eigtl. nicht mehr alles selber. --DB111 (Diskussion) 21:19, 4. Nov. 2024 (CET)

Venemodammen

Guten Morgen, im genannten Artikel hat Benutzer:Man77 die ISO-Region von NO-40 auf (die vermutlich korrekte) NO-38 geändert. Laut ISO 3166-2:NO ist die Änderung richtig, da NO-40 (derzeit) nicht definiert ist und lt. #iso:code:3166:NO wohl auch nie war. Da ich mit den Gepflogenheiten und auch Vorgängen in diesem Projekt nicht vertraut bin, bitte ich um Lösung des Problems. In meinen Augen müsste {{Info ISO-3166-2:NO-38}} wohl wieder hergestellt (auch wegen VG zum Nachvollziehen von Außenstehenden) werden und/oder auch der Artikel ISO 3166-2:NO aktualisiert werden. {{Info ISO-3166-2:NO-40}} wäre wohl irgendwann aufzulösen. --darkking3 ^Թ 09:08, 14. Jan. 2025 (CET)

Das Problem besteht darin, dass die ISO-Codes seit der letzten Verwaltungsänderung nicht angepasst worden sind, wir ISO-Codes aber für die Kategorisierung benötigen. Daher verwenden wir intern die neuen Codes, die noch nicht von ISO veröffentlicht worden sind, in der norwegischen Verwaltung aber schon verwendet werden, siehe Portal Diskussion:Norwegen/Archiv/2023#Änderung der Verwaltungseinteilung zum 1. Januar 2024. Auf ISO 3166-2:NO können wir das aber nicht vermerken, da es noch keine offiziellen ISO-Codes sind, und auch nicht irgendwo für den Leser sichtbar wie in den Artikeln zu den Fylkern. Das muss man also wissen. @Man77: In diesem Fall war daher NO-40 richtig. Links auf nicht vorhandene ISO-Code-Vorlagen sollten regelmäßig überprüft und korrigiert werden (findet meines Wissens per Herzi Pinkis Bot statt). NNW 11:03, 14. Jan. 2025 (CET)

ich vermute mal, dass es für die in der Verwaltung verwendeten Codes Quellen gibt? Manche ISO Artikel stellen ja den Verlauf der Codes dar, sodass man damit durchaus auch den Ausblick auf die nächste Änderung darstellen könnte, eben auch weil es offizielle Quellen gibt. Letztlich stimmt im Artikel der Satz Codes für die 2024 wiederhergestellten Fylker Akershus, Buskerud, Finnmark, Telemark, Troms, Vestfold und Østfold wurden noch nicht vergeben. nur zur Hälfte: Die Codes werden ja vermutlich vom jeweiligen Land festgelegt und an die ISO übermittelt, die dem zustimmen muss. Wenn die Verwaltung bereits andere Codes verwendet, sollte dies auch klargestellt und die Codes erwähnt werden. Als nicht involvierter Autor kann ich das schon nicht nachvollziehen, den die ISO-3166-2-Artikel sind meine erste Anlaufstelle zur Prüfung, ob Vorlagen vorhanden sein sollten oder nicht. --darkking3 ^Թ 11:54, 14. Jan. 2025 (CET)

Natürlich gibt es Quellen, sind auch auf der Portalsseite verlinkt (z.B. https://www.regjeringen.no/no/tema/kommuner-og-regioner/kommunestruktur/nye-kommune-og-fylkesnummer-fra-1.-januar-2024/id2924701/). Es kann nicht in den Artikel, da der ISO-Codes behandelt und es eben noch kein ISO-Code ist, nur einer der norwegischen Verwaltung. NNW 12:01, 14. Jan. 2025 (CET)

Wenn es kein ISO-Code ist, dann hättet ihr euch die Umstellung bei den betroffenen Artikeln auf Nicht-ISO-Codes eigentlich schenken können. Die Begründung dazu hast du ja selbst mit angegeben; auch die Vorlage:Coordinate#region sagt beispielsweise, dass gültige ISO-Codes zu verwenden sind. Ich kann aus eigener Erfahrung nachvollziehen, warum das Thema trotzdem vorausschauend abgearbeitet wurde. Dann sollten sich dazu allerdings auch ausreichende Informationen in den Artikeln befinden. Das Problem mit zukünftigen Angaben gibt es in vielen anderen Bereichen auch, wobei ihr noch den Vorteil habt, dies mit offiziellen Quellen (mit Ausnahme der ISO) belegen zu können. In meinen Augen sollte klar sein, dass die ISO die Subdivision-Codes nicht selbst festlegt und dies vielmehr auf Vorschlag des betroffenen Landes erfolgt. Sonst hättet ihr die Codes im Bestand nämlich auch nicht vorab geändert, da es zu einer erneuten Umbenennung kommen kann. Auch hier würde es dem ISO-Artikel gut zu Gesicht stehen, zumindest auf entsprechende Abschnitte in den passenden Artikeln zu verweisen. Die jetzt im Artikel enthaltene Aussage enthält nicht einen Link und lässt auch aufgrund der Position die bevorstehende Änderung nicht erkennen. --darkking3 ^Թ 17:17, 14. Jan. 2025 (CET)

Wie ich schon sagte, die Einführung von Nicht-ISO-Codes war notwendig wegen der Kategorisierung. Dass Norwegen die neuen Codes schon veröffentlicht hatte, war schön und praktisch, aber ich hätte ansonsten die Codes der Fylker von vor 2020 genommen. Ich hatte eigentlich damit gerechnet, dass es die wieder werden würden. Aber egal, es hätten auch Fantasie-Codes für einen Übergangszeitraum sein können, weil eine spätere Umstellung mit erwähntem Bot völlig unproblematisch ist.

In alle Artikel können wir das nicht schreiben. Natürlich wäre eine Anlaufseite für so ein Problem gut, haben wir bislang aber nicht und ich wüsste auch nicht, wie man sie leicht finden sollte bei dem Wust an Hilfsseiten in diesem WikiProjekt. Im Moment muss man das halt wissen. Nicht ideal, keine Frage. Bei Norwegen hatte ich allerdings darauf gehofft, dass das Problem zum jetzigen Zeitpunkt längst gelöst wäre. Aus irgendeinem Grund hat die ISO-Organisation nur schon das zweite Jahr in Folge keine Aktualisierungen vorgenommen. In Einzelfällen kann darauf gewartet werden, aber nicht bei einem Staat wie Norwegen. Wenn du einen guten und praktikablen Weg weißt, wie das Problem zu lösen wäre, nur her damit. Man könnte in die ISO-Vorlagen (wie Vorlage:Info ISO-3166-2:NO-40) einen weiteren Kasten einsetzen, aber auch zu der Vorlage muss man erstmal finden. NNW 21:28, 15. Jan. 2025 (CET)

Danke für die Erläuterung. Ich hätte zumindest erwartet, dass in ISO 3166-2:NO tatsächlich etwas mehr aufgeführt ist, wie etwa ein Link zu Verwaltungsgliederung Norwegens oder besser eigentlich Regionalreform in Norwegen#2024: Auflösung neuer Fylker. In der Vorlagendoku ließe sich auf jeden Fall in irgendeiner Form darauf hinweisen, wenn man z.B. Hinweisseiten als Unterseiten von {{Info ISO-3166-2/Info}} anlegt. Existiert eine Seite, wird sie in der Doku eingebunden. Zur einfachen Unterscheidung ist eine bei einer Gruppe gleiche Angabe zu wählen, hier z.B. NO oder Norwegen. Der Weg hätte auch den Vorteil, dass sich codespezifische Hinweise/Besonderheiten ablegen/dokumentieren lassen. --darkking3 ^Թ 08:50, 16. Jan. 2025 (CET)

Erklärung für meinen Edit: Ich wollte Wikipedia:WikiProjekt_Georeferenzierung/Coord_Plausi/NO abarbeiten. Die Koordinate stand bei NO-55 als Fehler drin. Dass das, sprich: der objektiv gegebene Fehler, schon korrigiert war, war mir nicht bewusst. LG, … «« Man77 »» Alle Angaben ohne Gewehr. 18:28, 14. Jan. 2025 (CET)

GeoHack ist tot

Liebe @Dispenser, Kolossos, Magnus Manske:, normalerweise bewegt er sich irgendwann wieder. lg --Herzi Pinki (Diskussion) 09:38, 18. Jan. 2025 (CET)

phab:T384092 --тнояsтеn ⇔ 12:01, 18. Jan. 2025 (CET)

Gerade läuft er wieder. Gestern gab es auch schon längere Ausfälle. --тнояsтеn ⇔ 13:38, 18. Jan. 2025 (CET)

Toolforge hat die PHP-Version geändert, das Skript hat Fehler geworfen. Jetzt angepasst. --Magnus Manske (Diskussion) 19:17, 21. Jan. 2025 (CET)

@Magnus Manske: Ist das möglicherweise auch der Grund für den Ausfall von https://petscan.wmcloud.org/? (siehe [4]) --Tkarcher (Diskussion) 20:34, 22. Jan. 2025 (CET)

Heute auch wieder massive Ausfälle. --тнояsтеn ⇔ 12:33, 22. Feb. 2025 (CET)

Siehe auch PD:GEO#Geohack-Kartenlinks defekt. --тнояsтеn ⇔ 21:39, 22. Feb. 2025 (CET)

amap.at hat Interface geändert

Hi, wir haben mehrere hundert links [5] der Gestalt

http://www.austrianmap.at/amap/index.php?setTo=1~150037~387758~153922~385281~@151978%7C386520~4~LAM_ETRS89~979~624

die uns nicht auf den Punkt, sondern nur auf ganz Österreich bringen. Der entsprechende korrekte Link ist

https://maps.bev.gv.at/#/center/10.04987,47.33155/zoom/16.2

Gibt es eine Möglichkeit, die Parameter der alten Links in die WGS84 Koordinaten umzurechnen? Dann könnte man die Links per bot fixen. lg --Herzi Pinki (Diskussion) 18:31, 17. Apr. 2025 (CEST)

Datenbankproblem mit geo_tags / syntaktisch fehlerhafte ISO-Region

Ausgangspunkt. Wir haben folgende Situationen mit den ISO-Regionen

1. AT und AT-9 (korrekte Werte)
2. AA, AT-09 (syntaktisch korrekte, aber ungültige Werte (kein definierter ISO-Code))
3. syntaktisch falsche Werte. Die Syntax für einzelne ISO-Regionen ist [A-Z]{2}(-[A-Z0-9]{1,3}]|). Beispiele sind Kleinschreibung (?), Unterstrich oder Abstand statt Bindestrich ([6]), mehr als 2 Buchstaben vorne (ABC) mehr als 3 Zeichen hinten (AT-4711), etc.
4. AT-7/DE-BY Grenzwerte

Mein User:ISO 3166 Bot prüft gegen die Datenbank auf die Fälle 1) und 2).

Die Fälle 3) und 4) landen nicht in der DB, d.h. die Koordinaten landen wohl in der DB, aber gt_country und gt_region sind null. Die beiden Fälle sind in der DB nicht zu unterscheiden. Ich würde es sinnvoll finden, auch die Fälle 3) und 4) zu prüfen. Bei Fall 4) geht es darum, die einzelnen Teilwerte den identischen Prüfungen zu unterziehen, wie normale ISO-Regionswerte (AA/AA oder AT-07/AT-08 fallen aktuell nicht auf, sind aber ungültig). Es geht nicht darum, die ISO-Regionen richtig zu kriegen, sondern eine Prüfung von Länge und Breite gegen die ISO-Regionen zu erlauben und so grobe Ausreißer und falsche Werte (weniger zuverlässig) bei den Koordinaten zu finden.

select count(*) from geo_tags where gt_country is null;

liefert aktuell 13724 Datensätze, darunter

• gt_page_id = 13322608 # Färberhof (Fall 3)
• gt_page_id = 126569# Similaun (Fall 4)

Was können wir tun, um die Fälle 3) und 4) in den Griff zu bekommen?

Ein Ansatz wäre, bei Grenzwerten (AT-7/DE-BY) zwei (oder mehr) Sätze in geo_tags anzulegen, einen mit AT-7 und einen anderen mit DE-BY. Wäre inhaltlich nicht falsch, aber ich kann nicht abschätzen, wie aufwendig das ist, wo das umzusetzen ist, wer das machen kann/will und welche Risiken damit verbunden sein könnten. Beim Verändern des ISO-Codes müssten jedenfalls solche Mehrfachsätze alle gelöscht und neu angelegt werden, damit keine ungültigen Reste bleiben, die dann schwierig aus der DB zu entfernen sind. Damit könnten bei Grenzregionen alle Teilwerte getrennt der identischen Prüfung wie Einzelwerte unterzogen werden.

Bei syntaktisch fehlerhaften ISO-Regionen könnte das Verhalten bleiben, wie es ist, gt_country auf null setzen. Ich wüsste dann zwar nicht welcher konkrete Wert falsch ist, aber dass ein Wert falsch ist, würde ich daran erkennen. Bei Grenzwerten würde dann eine Kombination aus definierten gt_country für die syntaktisch richtigen Teilwerte und gt_country=null für die syntaktisch falschen Werte entstehen. Besser wäre es, wenn der syntaktisch falsche Wert irgendwo in der DB aufscheinen würde, damit man zur Korrektur danach suchen kann.

Eine Alternative wäre es, die Prüfung auf syntaktisch falsche Werte irgendwo im Bauch von {{Coordinate}} einzubauen. Das würde ohne Änderung der Schnittstelle zur DB funktionieren, hätte aber die Nachteile:

• kritisch in Bezug auf Parserlimits (jede zusätzliche Abfrage in {{Coordinate}} bläht den Code auf)
• nicht auf anderssprachige Wikis zu übertragen (der jetzige Algorithmus von User:ISO 3166 Bot läuft zwar nur auf WP:de, könnte aber leicht auf andere WP / Commons ausgedehnt werden - ich habe das bisher unterlassen, da es dann auch Menschen geben müsste, die die Fehlermeldungen abarbeiten).

In der WP suchen ist keine wirkliche Alternative [7], die Suche mit regulären Ausdrücken über alle Artikel mit Coordinate überfordert unsere Suchinfrastruktur.

ins Blaue gepingt: @Kolossos, DB111, NordNordWest:

auch Alternativvorschläge?

siehe auch: Wikipedia:WikiProjekt Georeferenzierung/Coord Plausi/unmatched ISO 3166 codes für ungültige ISO-Codes und beispielsweise Wikipedia:WikiProjekt Georeferenzierung/Coord Plausi/CZ. --Herzi Pinki (Diskussion) 16:34, 18. Apr. 2025 (CEST)

Ich habe von den Datenbankdingen gar keine Ahnung. Da kann ich nicht helfen. NNW 22:04, 18. Apr. 2025 (CEST)

Habe eine Möglichkeit gefunden, das auch ohne DB-Änderung zu prüfen (fuzzy). Dazu lese ich alle Sätze aus geo_tags ohne gt_country aus der db und lese dann die zugehörigen WikiArtikel und suche nach den Werten für die ISO-Region, und prüfe diese. Fuzzy ist das Finden der Regionen im Sourcecode, da ich das nur am Schlüsselwort region etc. erkennen kann und das nicht 100% treffsicher ist. Beim Lesen aus der db sonst bekomme ich genau die Werte, die GEO als regionen erkannt hat und in die db geschrieben hat. lg --Herzi Pinki (Diskussion) 13:20, 20. Apr. 2025 (CEST)