Wikipedia Diskussion:Technische Wünsche/Topwünsche/Bessere Unterstützung von Geoinformationen

Bitte achtet auf einen freundlichen Umgangston. Das Projekt Technische Wünsche lebt vom Austausch. Alle Beiträge sind willkommen, solange sie konstruktiv sind. Das Projektteam bittet von persönlichen Angriffen oder beleidigenden Kommentaren abzusehen. Siehe dazu auch: Wikiquette, Wikiliebe, Keine persönlichen Angriffe

Status Quo der Flächen und Liniendarstellung in der Artikelkarte

Robin Strohmeyer (WMDE) hat sich in der Abstimmungs-Diskussion gewünscht, dass man sich auch nach der Abstimmung an der Diskussion zum Projekt beteiligen solle. Das will ich dies hiermit tun. Leider wurde weder hier noch in der Abstimmungsdiskussion erwähnt, wo diese Diskussion stattfinden soll. Ich nehme daher an, dass hier. Wie schon in der Abstimmungsbeschreibung wird hier oben der Kartographer als einzige Konkretisierung des Abstimmungsthemas im Kommentar des Teams Technische Wünsche in den Mittelpunkt gestellt. Aus diesem Grund würde ich gerne beim Team Technische Wünsche erfragen, wie es um die Altlasten aus der früheren fünf Jahre alten Abstimmung bestellt ist.

In jedem Artikel mit Geokoordinate und Wikipedia oder Wikidata Tag am entsprechenden Objekt in OpenStreetMap wird dieses als Linie oder Fläche in derjenigen Karte dargestellt, die bei Klick auf das Lupensymbol rechts oben im Artikel auftaucht. Meines Wissens lief früher jede Nacht ein Crawler durch OSM und Wikipedia, der die neu eingetragenen Objekte erfasst und die Darstellung in der Artikelkarte initiiert hat. Dies funktionierte bis vor cirka sechs Jahren. Danach eingetragene Objekte werden nicht mehr aktualisiert bzw. nicht angezeigt. Beispielsweise die Bundesautobahn 72 die in den letzten Jahren in ihrem nördlichsten Zipfel gemäß Realität und OSM einen neuen Verlauf nimmt, zeigt in der Artikelkarte noch die inzwischen zur Bundesstraße 95 abgestufte alte Trasse. Daher habe ich folgende Frage: Sehe ich es richtig, dass nur der ehemals funktionierende Crawler wieder funktionstüchtig gemacht werden müsste, damit auch neuere Objekte wieder aktualisiert bzw. angezeigt werden? Denn die Anzeige der über sechs Jahre alten Einträge und Objekte funktioniert heute noch einwandfrei. Inwieweit wird an diesem Problem im Rahmen des Schwerpunktes gearbeitet oder ist dies vorgesehen? Wird dabei die alte Erfassungsfrequenz jede Nacht oder eine andere angestrebt? -- Tirkon (Diskussion) 15:59, 16. Aug. 2020 (CEST)

Auch ich würde mich freuen, wenn es eine erste Zusammenstellung der Problempunkte geben würde. Und vielleicht eine Darstellung wie man gedenkt die Aufgaben anzugehen (grober Projektplan/Zeitplan) . --Kolossos 20:44, 19. Aug. 2020 (CEST)

@Tirkon:, @Kolossos: Ich erlaube mir, die Fragen auf die Diskussionsseite zu verschieben. Hier sind sie definitiv richtig. Inhaltliche und (zeit)planerische Informationen folgen in Kürze. Mit Bitte um etwas Geduld --Robin Strohmeyer (WMDE) (Diskussion) 15:49, 21. Aug. 2020 (CEST)

@Robin Strohmeyer (WMDE): Darf man nochmal nachfragen wie es jetzt weitergeht? Gibt es schon einen Verantwortlichen oder einen groben Plan? --Kolossos 19:09, 29. Sep. 2020 (CEST)

@Kolossos: Klar darfst du nachfragen. Wir werden in den nächsten Monaten mit der Recherche zu Geo Informationen anfangen. Ein Teil davon wird sein, dass wir Interviews mit Nutzenden vereinbaren, um zu verstehen, wo Verbesserungen nötig sind! -- Für das Team Technische Wünsche: Max Klemm (WMDE) (Diskussion) 12:20, 6. Okt. 2020 (CEST)

Hinweis: Aktuelle Diskussionen finden derzeit unter Wikipedia:Technische Wünsche/Topwünsche/Bessere Unterstützung von Geoinformationen/Ideensammlung statt. --Kolossos 10:26, 21. Dez. 2020 (CET)

Mangel im Fragebogen Technische Wünsche

Im Rahmen der Fortentwicklung des Gewinner-Themas Geoinformationen wurden die User gebeten, einen Fragebogen auszufüllen. Dieser Fragebogen hat den Mangel, dass schon das Anschauen der Fragen als Teilnahme gewertet wird, ohne dass man auch nur eine Frage beantwörtet hätte. Anschließend können die Fragen auch nicht nochmals angeschaut werden, weil man schon an der Umfrage teilgenommen hat. -- Tirkon (Diskussion) 15:59, 16. Aug. 2020 (CEST)

Vielen Dank für diesen Hinweis, das ist natürlich nicht optimal. Wir werden prüfen, ob es möglich ist, die Einstellungen anzupassen. --Robin Strohmeyer (WMDE) (Diskussion) 23:34, 20. Aug. 2020 (CEST)

Aufzählungen und Infinitiv mit zu

Hallo, ich habe mich gefragt, warum mir der folgende Satz im Abschnitt „Status und nächste Schritte“, welcher nach /Ideensammlung verknüpft, nicht richtig und schwer verständlich vorkommt:

• „Alle sind eingeladen hier Probleme, Wünsche und Ideen zu sammeln, strukturieren, weiterentwickeln und diskutieren.“

Der Hauptgrund ist das weggelassene „zu“ bei der Aufzählung von Infinitiven mit zu. Da ich mir dachte, dass es wohl keine „Infinitiv-Aufzählung mit und ohne zu“ geben wird, habe ich den Duden konsultiert. Im Duden werden zwar bei den Kommaregeln zu Aufzählungen und zum Infinitiv mit zu Angaben gemacht, nicht aber zur Kombination beider Themen (Aufzählungen von Infinitiven mit zu). Meine weitere Suche ergab u. a. das folgende Thema als Treffer:

• Duden → Sprachwissen → Sprache und Stil → „Nicht zu empfehlende Ellipsen“.

Dort steht (als letzter Absatz):

• „Ein zu beim Infinitiv kann nicht weggelassen werden. Daher nicht: Wir sind durchaus in der Lage, diese Mengen zu produzieren und *liefern, sondern nur: Wir sind durchaus in der Lage, diese Mengen zu produzieren und zu liefern.“

Das heißt, wenn man „zu sammeln“ hinschreibt, muss es auch „zu strukturieren“, und „zu diskutieren“ lauten. Aus „weiterentwickeln“ wird entweder „weiterzuentwickeln“ oder „weiter zu entwickeln“; je nachdem, ob man Weiterentwicklung betreiben möchte oder ob man Entwicklung weiter betreiben möchte (was sich sinngemäß nicht unterscheidet).

Man könnte auch ein Komma zwischen eingeladen und hier setzen, zumindest nach meinem Kenntnisstand (siehe D124). Daraus ergäben sich z. B. diese beiden Formulierungen:

• „Alle sind eingeladen hier Probleme, Wünsche und Ideen zu sammeln, zu strukturieren, weiterzuentwickeln und zu diskutieren.“
• „Alle sind eingeladen, hier Probleme, Wünsche und Ideen zu sammeln, zu strukturieren, weiter zu entwickeln und zu diskutieren.“

Da die Verknüpfung nicht auf das Wort „hier“ begrenzt wurde, erkennt man nicht gleich, dass „hier“ sich auf eine andere Seite, nämlich die Unterseite /Ideensammlung, beziehen soll. Deshalb schlage ich unter dem Strich etwas in dieser Art vor:

• „Alle sind eingeladen, auf der Unterseite Ideensammlung Probleme, Wünsche und Ideen zu sammeln, zu strukturieren, weiterzuentwickeln und zu diskutieren.“

MfG --Dirk123456 (Diskussion) 17:27, 30. Dez. 2020 (CET)

Anzeige der Artikelkoordinaten in mobiler Version und App

Dieser umseitig benannte Punkt wird in den nächsten Monaten per WP:Meinungsbilder/Darstellung der Seiten-Koordinaten angegangen; zumindest erstmal dahingehend, dass es überhaupt anklickbare und angezeigte Geoinformationen geben wird. VG --PerfektesChaos 17:32, 29. Mär. 2021 (CEST)

Einbindung via JSON API

Hallo! Ich habe das hier nur ganz am Rande mitbekommen und habe ganz sicher nicht die Zeit, hier tief einzusteigen. Aber von wo auch immer die Geodaten eingebunden werden sollen, wäre wohl eine JSON-API die standardisierte Schnittstelle. Hierzu habe ich in der "Technik-Werkstatt" den Abschnitt Extension:External Data angelegt, da diese Extension genau so eine Schnittstelle ist, auch projektintern. Leider ist diese Extension, die man bereits anno 2009 mal groß ins Gespräch gebracht hat, in den eigenen Wikiprojekten nirgends aktiviert, noch nicht mal testweise auf Mediawiki. Man könnte so viele Dinge vereinfachen/automatisieren damit. Also bitte mal in Erwägung ziehen! Grüße, Uwe Martens (Diskussion) 02:32, 28. Apr. 2021 (CEST)

@Uwe Martens: Vielen Dank für den Hinweis. Wir nehmen das in unsere aktuell laufende Recherche-Phase mit auf. Da es viele spannende Vorschläge gibt, wir aber nur wenige umsetzen können, können wir nichts versprechen. Grüße --Timur Vorkul (WMDE) (Diskussion) 13:34, 7. Mai 2021 (CEST)

Lage bzw. Positionskarten funktionieren nicht mit Konvertern wie mediawiki2latex (evtl. auch für pediapress Produkte nicht??)

Lage bzw. Positionskarten, die im Browser mit Pins überlagert werden, siehe z.B. Tischtennis#Deutschland, funktionieren in mediawiki2latex nicht (7.39 getestet), dort kommt nur die Basiskarte (ohne Pin-Überlagerung) an, was für den, den es stört, händische Nacharbeit bedeutet.

Interessanterweise beherrscht die derzeit verwendete Funktion "Als PDF herunterladen" der deutschen Wikipedia diesen Nutzungsfall korrekt (Screen-Ausgabe und PDF geben zumindest das gleiche Bild) - hier wird vermutlich ein Screenshot der HTML-Ausgabe des Renderresultats der Vorlagen erstellt, während mediawiki2latex stattdessen nur das Basisbild lädt.

Statistiken, die z.B. mit der graph Erweiterung in Artikeln eingebunden wurden, können mit graph canvas2svg, einer Funktion des Vega Editors in svg ausgegeben werden, was sich wiederum leicht in LaTeX Dokumente setzen lässt (entweder direkt, oder über den svg2pdf Umweg, beide Methoden ohne Bitmap-Rasterungs-Zwang).

Hirngespinst: Evtl. sind die Vorlagen für die Lage- und Positionskarten derart umgestaltbar, dass sie allesamt auf die graph Erweiterung aufsetzen: Falls diese Erweiterung Basiskarten-SVGs in das canvas Objekt laden/zeichnen kann und die Objekte der Überlagerung ebenfalls obendrauf in Vektorversion gezeichnet werden, ist ein einheitlicher Workflow für Konverter denkbar, die nicht von einer HTML-Engine/Javascript interpretierte Ausgabeformate erzeugen. Die Konverter könnten die <graph> Objekte mittels graph2svg-Tools als SVG laden, das dann vielfältig weiter verarbeitbar ist.

U. a. für Demographie-Graphiken kommt die <graph> Erweiterung bereits in den Artikeln zum Einsatz, womit die Konverter also ohnehin angehalten sind, diesen Fall zu unterstützen.

Die Alternative ist, die Vielzahl an Lösungen, die auf CSS-Tricks und dynamischen Javascript aufbauen in den Konvertern zu unterstützen

• einfachste Methode: per HTML-Screenshot in ein HTML-unabhängiges Rastergrafik-Format wandeln, so wie es "Als PDF herunterladen" momentan zu bewerkstelligen scheint
• komplexe Methode(n): für jede Wiki-Vorlage einen eigenen Vorlagen-Interpreter für das jew. Ausgabeziel schreiben, was derzeit eine Option von mediawiki2latex ist

Im Browser sind Vorlagen wie Positionskarte und co. zuverlässig und brauchbar, aber für alles ohne HTML-Engine im Ausgabeziel i. d. R. problematisch. --84.135.124.98 05:35, 29. Apr. 2021 (CEST)

proof-of-concept mit <graph> (Umrechnung lat-lon in offsets nicht enthalten, aber der Teil wird derzeit ohnehin schon von den Vorlagen bewältigt, so dass eigentlich nur die Parameter img/wikifile und die Datentabelle zu parametrisieren wären;(geändert) die Axen sind ausblendbar, hier unklar ist, ob graph auch eine Verlinkung der Text-Labels erlaubt):

EDIT: domain und range gesetzt, womit nun direkt Lat/Lon Paare als Eingabe in table möglich sind, die Umwandlung der Koordinaten in die Pixel-Offsets erfolgt durch das graph-interne mapping von domain zu range Werten (siehe vega docs), falls alle Umrechnungen in den Positionskarte-Vorlagen linearer Natur sind, ist ein Umschreiben der Vorlagen somit evtl. einfacher als gedacht.

EDIT2:

• Text-Labels sind nach derzeitigem Kenntnisstand mit <graph> nicht verlinkbar.

⇒ Lösbar mit den gleichen Mechanismen, die bisher zum Einsatz kommen - auch das canvas-Element lässt sich mit CSS-positionierten div-Elementen überlagern. Falls alle Grafik-Elemente sauber im canvas-Element verbleiben und die divs im CSS-Overlay z.B. nur transparente PNGs für die Verlinkung nutzen, können Konverter eine 1:1 Grafikreproduktion erhalten (siehe nächster Anstrich), ohne dass im Web Einbußen bei der Funktionalität gegenüber den bisherigen Verfahren gemacht werden müssen, siehe CSS-überlagteres Beispiel unten. --84.135.114.228 06:52, 1. Mai 2021 (CEST)

• Nicht HTML5-konforme Webbrowser (canvas-Element nicht verfügbar) werden mit der fallback-Methode zwar unterstützt, erwarten aber ein statisches Bild des Graphs, das auf commons hochgeladen wurde - Snapshoterstellung und das Hochladen auf Commons erfolgen dabei nicht automatisch. Würde man also derzeit z.B. die Positionskarte-Vorlage zur Nutzung von <graph> im Backend umschreiben, bestünde das Problem, dass für alle Vorlagennutzungen so ein Fallback erstellt werden müsste, um Kompatibilität mit älteren Browsern zu gewährleisten.

Das ist technischer Mist/Datenduplizierung und nach jeder Änderung des Graphs wäre das Fallback zu erneuern.

Dieser Punkt ist also derzeit ein "showstopper", aber mw:Extension:Graph#User_defined_fallback verspricht, dass dies in Zukunft nicht mehr nötig sein wird, um ein fallback png zu erhalten, Zitat:

„This is a temporary solution until a new service is put in place to provide server side rendering to replace the soon to be decomissioned Graphoid service.“, siehe dazu auch T249419 auf phabricator

• Zudem scheint das referenzierte SVG des img marks nicht als Vektorversion im canvas-Element zu landen, sondern vorher gerastert zu werden. Der mit graph2svg exportierte Graph enthält ein image tag. Verweist dieses auf eine svg Datei, wird diese z.B. von Inkscape gerastert und somit als Bitmap-Objekt eingebunden, statt einfach den SVG Inhalt zu übernehmen. Das ist prinzipiell kein "showstopper", aber suboptimal. (Die <use href=".." /> Methode, um ein SVG in ein anderes SVG einzubetten funktioniert, nach kurzem Test, hier nicht, wird aber auf stackexchange als Lösung dargestellt, abgesehen davon, dass graph2svg ohnehin derzeit kein use Element ausgibt, weil das img mark als image Element geschrieben wird.) Konkret bedeutet dies, dass bei hochauflösendem Druck eines nach LaTeX exportierten Dokuments die Hintergrundkarte pixelig, die überlagerten Pins mit Beschriftungen jedoch scharf aufgelöst ausgegeben würden.

Beispiel mit Axen Die Darstellung von Grafiken ist aktuell auf Grund eines Sicherheitsproblems deaktiviert.	Beispiel ohne Axen Die Darstellung von Grafiken ist aktuell auf Grund eines Sicherheitsproblems deaktiviert.	Nutzung von c:Data:Germany.map mit graph Die Darstellung von Grafiken ist aktuell auf Grund eines Sicherheitsproblems deaktiviert.
Nutzung der Bundes- und Nachbarländer DataMaps mit graph bzw. CSS-Overlay-Verlinkung in erster Spalte
Die Darstellung von Grafiken ist aktuell auf Grund eines Sicherheitsproblems deaktiviert.	Die Darstellung von Grafiken ist aktuell auf Grund eines Sicherheitsproblems deaktiviert.

Die letzten drei Beispiele funktionieren nur mit Scribunto-Hilfe derzeit richtig, weil die equirektanguläre Projektion der ersten zwei um den Faktor 1.5 in der Vertikalen gestreckt ist und sich diese Streckung derzeit mit der Vega2 basierten Graph-Erweiterung nicht einfach umsetzen lässt. Ein Parameter scaleY, wird erst ab Vega-Version 5.8 unterstützt... --84.135.124.98 20:20, 29. Apr. 2021 (CEST)

Scribunto-Hilfe meint die Funktion scaleMapData in Modul:GraphHelfer, welche MapData Daten aus commons liest, vorskaliert und anschließend an Graph übergibt. Dies ist ein Workaround für die fehlende "scaleY" Funktionalität des path marks. --84.135.118.241 10:23, 30. Apr. 2021 (CEST)

In dem Teil "Projections" der Vega-Dokumentation sind Export-Links erkennbar (Graph-Source, PNG, SVG als Tripel), wenn der Cursor über den Graphen bewegt wird. Für Konverter wie mediawiki2latex wäre es vermutlich sehr hilfreich, wenn man über die MediaWiki-API bzw. einen CGI-Parameter in der URL das Ausgabeformat für Graph-en (also Art der HTML-Einbettung) bestimmen könnte. Im Browser bliebe dann das gewohnte, ggf. auch interaktive canvas-Element bestehen, aber der Konverter "sieht" und bezieht ein SVG oder PNG für eine statischere Weiterverarbeitung. --84.135.118.241 10:45, 30. Apr. 2021 (CEST)

EDIT: graph-Beispiel ergänzt, das der von NordNordWest erstellten SVG map nahe kommt.

EDIT: CSS-Overlay-Beispiel zur Verlinkung von graph-Elementen ergänzt (nutzt selbes Prinzip, wie in Vorlage:Positionskarte+, Vorlage:Positionskarte~) Bitte beachten, dass auch Grünwettersbach verlinkt ist, hier wurde ein transparentes PNG eingebunden. Idealerweise, sollten alle CSS-positionierten Link-Elemente so eingebunden werden, damit in einem produktiven Einsatz die Ausgabe der Grafik an einen Konverter (Druck/Buch/etc.) unverändert ist (bisher nicht der Fall: Anzeige im Web und Konvertersicht unterscheiden sich).(umgesetzt:Red_pog.svg wird für alle Pins vom Graphen gezeichnet, in der Link-Schicht sind nur noch transparente Elemente) --84.135.114.228 01:06, 1. Mai 2021 (CEST)

Problem #1

Wenn man einen Artikel anlegt, der 1 Ortsbezug hat, müsste man die Koordinate dort eintragen. So kennen wir das. Meisten haben schon 10 oder mehr andere Schwestern-Wikis die deutschsprachige Wikipedia längst überholt und schon längere Artikel oder stubs angelegt und auf Commons steht die Coordinate eingetragen.

Hier für uns fehlt die Anleitung für alle, wie man einen Bezug direkt zu den Koordinaten auf Commons oder Wikidata oder Interwiki aller Art herstellen kann, ohne diese Koordinaten noch mal (oder gar noch eigene abweichende Koordinaten) eintragen zu müssen. -- SXXXB (Diskussion) 00:33, 30. Mai 2021 (CEST)

Überholt im Umfang vielleicht, aber oft nicht in Qualität. Viele Artikel in der engl. Wikipedia sind ungepflegt. Ob eine Datenkonzentration an einem Ort sinnvoll ist, darüber lässt sich streiten. Leider hast du kein konkretes Beispiel genannt für einen Artikel in einer anderssprachigen Wikipedia, der Koordinaten von woanders bezieht, so dass deine Argumente schwer nachvollziehbar sind.

Interaktive Infoboxen, die pro Pageview dynamisch erzeugt werden, bergen außerdem das Problem, dass die Artikelhistorie lückenhaft wird und u.U. nicht mehr nachvollzogen werden kann, was sich wann und wie ändert - schließlich sind interaktive Infoboxen Teil des Artikels, ihr Dateninhalt jedoch nicht. Für letzteren ist das Schwesterprojekt verantwortlich, deren Autoren können aber durchaus, auch unabsichtlich im Interessenkonflikt mit denen des Artikels stehen. Es ist schon vorgekommen, z. B., dass Inhalte von Infoboxen deshalb andere Informationen angeben, als im Fließtext des Artikels erscheinen. Für Leser des Artikels ist so ein Zustand inakzeptabel.

Dem folgend auch noch den Ortsbezug von extern zu laden hat nicht nur Vorteile und die einfache Phrase "dt. Wikipedia längst überholt" wäre zu überdenken. --93.201.172.140 16:56, 9. Jun. 2021 (CEST)

Wikidata-Verknüpfungen aus OpenStreetMap

Vielleicht nicht ganz zum Thema, deswegen hier nur als Verlinkung/Information auf der Diskussionsseite: Es gibt auch seitens OpenStreetMap (OSM) die Möglichkeit, Dinge (Wikidata und Wikipedia-Artikel) auf OSM zu verknüpfen. Auch für bestimmte Eigenschaften gibt es da sehr viele Untertags. Es besteht bspw. für die „Brand” (also Marke) auch die Idee, dies in der App StreetComplete zum einfachen Hinzufügen (unterwegs) einzubinden. --rugk (Diskussion) 21:48, 22. Jun. 2021 (CEST)

@Rugk: Vielen Dank für den interessanten Hinweis! Wir haben die Möglichkeit der Verknüpfung zu Wikidata und Wikipedia auf OSM und das osm.js Script in unsere Sammlung der Referenzen und Ressourcen in diesem Etherpad aufgenommen. --Timur Vorkul (WMDE) (Diskussion) 13:13, 1. Jul. 2021 (CEST)

dringendes Akutproblem mit geohack

aktuell ist die bisher von User:Alexrk2 bereitgestellte Koordinatentransformation nicht mehr funktionsfähig. Dies betrifft 21 externe Kartendienste (https://de.wikipedia.org/wiki/Vorlage:GeoTemplate/GeolinkConfig), hauptsächlich mit DACH-Bezug. Es wird jemand gesucht, der entweder das Tool übernimmt und auf eine stabilere Plattform migriert oder der den Geohack auf ganz neue Beine stellt. Es wäre mE günstig, zentrale Komponenten wie den Geohack nicht der Freiwilligkeit von UserInnen zu überlassen. Daher meine dringende Bitte, ob das Team Technische Wünsche da was machen könnte. Siehe auch Wikipedia Diskussion:WikiProjekt Georeferenzierung#Suche neuen Hoster bzw. Betreiber für den Geolink-Service. Bevor hier losgeschossen wird, sind vielleicht Überlegungen zum Ersatz von Geohack anzustellen. @Timur Vorkul (WMDE), Johanna Strodt (WMDE): für das Team TW. lg --Herzi Pinki (Diskussion) 17:04, 18. Aug. 2021 (CEST)

Hallo Herzi Pinki, danke für deine Anfrage. Leider ist die Liste der Themen, die wir uns im Projekt Technische Wünsche bereits vorgenommen haben – und die vor allem durch Community-Abstimmung priorisiert wurden – schon sehr lang. Ein weiteres Problem mit aufzunehmen, können wir im Team also nicht leisten, aber vor allem entspricht es auch gar nicht unserem Prozess, denn wir arbeiten ja an Themen, die per Community-Abstimmmung festgelegt wurden. In den aktuellen Themenschwerpunkt Geoinformationen hätte das Problem jetzt zufällig passen können, aber es wurde gerade Anfang des Monats durch eine Abstimmung hier im Wiki festgelegt, dass sich das Team damit beschäftigen wird, Kartographer auf dewiki nutzbar zu machen. Unser Vorschlag wäre daher auch, in der technischen Community zu fragen, ob jemand das Tool übernehmen kann und auf Toolforge umzuziehen. Tut mir leid, dass ich keine zufriedenstellendere Antwort habe. -- Timur Vorkul (WMDE) (Diskussion) 11:37, 24. Aug. 2021 (CEST)

Ach, wie das so ist mit den Wünschen. Ich verstehe den Prozess, ich verstehe die Bürokratie, die dahintersteht, ihr baut was dazu und woanders bricht die Basis weg. Es ist, was es ist, sagte die Fee. lg --Herzi Pinki (Diskussion) 11:43, 24. Aug. 2021 (CEST)

Diese Antwort ist eines der Grundprobleme mit der technischen Infrastruktur. NEIN, die freiwilligen können das nicht leisten. Denn wie freiwillige so sind, sie sind dann auch mal weg und dann brechen sehr wichtige Funktionen weg... Aber macht mal, ich denke eine neue Farbe für "Rot-Links" ist DRINGEND nötig Vorlage:Smiley/Wartung/:(  --Itti 12:34, 24. Aug. 2021 (CEST)

Die WMF hat 450 Angestellte, WMDE noch mal ganz viele (wo kann ich das eigentlich nachlesen?), wofür, wenn nicht für so etwas, leisten wir uns diese Devs (und deren Wasserkopp)? Wenn irgendeine Babelvorlage nicht mehr funzt ist daqs ja eher irrelevant, wenn ein Bot nicht mehr geht, wird es schon schwieriger, ist aber im Zweifel auch nix dringendes, wenn der GeoHack nicht mehr geht ist das allerdings was komplett anderes. Ob das jetzt vom Team Technische Wünsche oder irgendwem anders bei WMF/WMDE abgearbeitet wird ist dabei für us Freiwillige völlig nebensächlich, Hauptssache, die vielen von unseren Geldern bezahlten Kräfte kümmern sich darum (und nicht um solchen Unsinn wie Rebranding oder Linkfarben). --Grüße vom Sänger ♫ ^(Reden) 13:29, 24. Aug. 2021 (CEST)

Habe Geolink auf Toolforge migriert. --DB111 (Diskussion) 18:31, 8. Sep. 2021 (CEST)

Ich bemerke gerade, dass bisher niemand auf diesen schlichten Satz von @DB111 reagiert, geschweige denn gedankt hat (vielleicht heimlich, mit der "Danken"-Funktion?). Dann will ich das mal nachholen - es ist klasse, dass Du hier für den Anbieter dieser kleinen Website in die Bresche gesprungen bist! Viele Grüße, ein lediglich nutzender --emha ^d℩^b 22:22, 26. Jan. 2022 (CET)

Abschalten von tiles.wikimedia.org

Da es für tiles.wikimedia.org keinen Maintainer mehr gibt, wird dieser abgeschalten ( Beispielkachel: https://tiles.wmflabs.org/hillshading/9/272/182.png ). Wir verlieren damit unsere hikebikemap und das hillshading. Aber ok, vermutlich bin ich der einzigste der darum trauert und bei einem Spendenziel von 9,2 Mio. kann man halt nicht alles am Leben halten. --Kolossos 09:16, 25. Jan. 2022 (CET)

Nettovermögen hat sich ja auch nur um 50 Millionen USD erhöht im letzten Jahr. (https://de.wikipedia.org/wiki/Wikimedia_Foundation#Finanzierung) --Hi, future humans! (Diskussion) 11:24, 25. Jan. 2022 (CET)

Nochmal auf die sachliche Ebene zurückkommend (und meinen Frust zurückhaltend): Die HikeBikemap ist wahrscheinlich wirklich tot, weil der Maintainer schon seit Jahren nicht mehr aktiv ist und diese Karte aufgrund ihrer Inhalte wirklich Aktualisierung braucht. Aber das Hillshading von damals ist noch immer gültig. Man könnte auch das Projekt mit neuen Daten (siehe https://www.opendem.info bzw. TanDEM-X...) verfeinern und weltweit ausbauen. Bei https://adv-smart.de kann man sehen wie genial Karten mit hochaufgelöster Schummerung aussehen können (Konnte jetzt allerdings keine Angaben zur Quelle finden). --Kolossos 15:05, 25. Jan. 2022 (CET)

In der wunderbaren und weltweit gerenderten OTM (zB https://opentopomap.org/#map=12/47.6818/13.7602) können die Lonvia Wander- und Radrouten eingeblendet werden. Grüsse, --Dromedar61 (Diskussion) 15:19, 25. Jan. 2022 (CET)

Auf Wikivoyage nutzen wir die Wander- etc. -Karten von https://www.waymarkedtrails.org. --RolandUnger (Diskussion) 15:41, 25. Jan. 2022 (CET)

Mir wurde auf meiner Disk.-seite auch schon CycleOSM von osm.fr als Alternative empfohlen. Ich denke sowohl CycleOSM und OpenTopoMap sollten zumindestens auf Wikimedia-Seite gecached werden, das fordert auch die Fair-use-policy und so eine Proxy-Cache würde auch den Datenschutz verbessern. Für den Cache sehe ich mich nicht in der Lage diesen aufzusetzen und zu pflegen. Vielleicht könnte das WMDE/WMF übernehmen. --Kolossos 21:50, 26. Jan. 2022 (CET)

Es fehlen Höhenlinien im Kartographer

Es fehlen Hóhenlinien im "Open Street Map", ebenso, wie im Google Earth. Topografische Basiskarten wären da hilfreicher. Speziell bei der Präsentation von Landschaften, wie Gebirgszügen, Auen, Tiefebenen, Flusseinzugsgebieten usw. sind Open Street Map unbrauchbar. Viele Wikipedianer haben Qgis oder auch Arc gis und Arc View usw... Hier ein Zugriff auf topografische Karten (1:25 000 und 1.50 000) in .shp Format als Basis, mit welchen man dann selber Karten herstellen könnte wären da sehr hilfreich--Kelbraer (Diskussion) 01:36, 1. Jul. 2022 (CEST).

Selbstgewählte Ausschnitte aus www.opentopomap.org in Wikipediaartikel hineinbauen zu können wäre super. Ich wüsste auf Anhieb schon drei Artikel, wo das Geländerelief für den Artikelgegenstand eine Rolle spielt, die man mit Worten (für die man dann auch noch Quellen finden muss) nur viel umständlicher ausdrücken kann als mit so einem Stück Karte (auch ohne darauf auch noch irgendetwas malen oder schreiben zu müssen). --DK2EO (Diskussion) 22:07, 7. Jul. 2022 (CEST)