Benutzer Diskussion:Plenz/OSM for Wiki

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Darstelung mit Nummern

[Quelltext bearbeiten]

Die Bing-Darstellung mit den Nummern auf den Nadeln gefällt mir bis jetzt am besten, da man auch ohne Mausbewegung eine Zuordnung hat. --Seewolf 10:40, 20. Mai 2011 (CEST)Beantworten

Ja, im Prinzip schon, aber:
  • die Zuordnung verschwindet sowieso, wenn Icons übereinander liegen oder wenn es -zig Icons gibt
  • die Bing-Icons sind relativ groß. So könnte ich nur 4 verschiedene Icons haben statt 8.
Aber was nicht ist, kann noch werden. Ich denke, Bing verwendet auch "leere" Icons wie ich und blendet die Ziffern nur nachträglich drüber. --Plenz 10:55, 20. Mai 2011 (CEST)Beantworten

Funktion redir

[Quelltext bearbeiten]

Wozu dient denn der &redirect=plenz-Parameter in deinem Beispiellink? -- Bergi 13:06, 22. Mai 2011 (CEST)Beantworten

Zur Zeit nur aus Kompatibilitätsgründen, mein Programm macht damit gar nichts, aber wenn kmlexport mein Programm aufrufen soll, dann (denke ich) wird dieser Parameter gebraucht. --Plenz 13:27, 22. Mai 2011 (CEST)Beantworten
Achso. Dein Programm muss aber nicht weiterleiten, der redir-Parameter wird nur an kml-Export übergeben; von dort weitergeleitet wird ihn dein Programm nicht mal mehr in der URL der KML-Datei sehen. -- Bergi 14:56, 22. Mai 2011 (CEST)Beantworten
Ich hab mich mal getraut, den Betreiber des Tools anzumailen und auf die neue Möglichkeit hingewiesen. -- Bergi 15:17, 22. Mai 2011 (CEST)Beantworten
Just dieses habe ich heute auf seiner Commons-Seite getan. Aber wer weiß, wie oft er dort hineinschaut, doppelt hält auf jeden Fall besser. --Plenz 17:12, 22. Mai 2011 (CEST)Beantworten

Meinungen und Ideen

[Quelltext bearbeiten]
Welche Informationen würdest du denn darstellen wollen, die Quelle ist ja klar (solange du deinen Dienst nicht zu einem allgemeinen KML-Darstellungsprogramm ausbaust)? Ein Iframe mit der Druckversion des verlinkten WP-Artikels wäre möglich, imho aber nicht nötig. Ich fände es besser, wenn einfach bei Überfahren des Icons der Link in der Liste links hervorgehoben wird. -- Bergi 13:59, 22. Mai 2011 (CEST)Beantworten
Die Zeile mit dem Link wird beim Überfahren des zugehörigen Icons rosa hinterlegt. Funktioniert das bei deinem Browser nicht, oder meinst du etwas anderes? --Plenz 20:08, 22. Mai 2011 (CEST)Beantworten

Autoscroll, Mapnik etc.

[Quelltext bearbeiten]

Sieht sehr gut aus. Allerdings wenn die Menge der Objekte sehr groß ist (Beispiel), helfen einem die Toolstipps nur selten weiter. Man müßte automatisch die Liste an die richtige Stelle schieben. Die "Stecknadeln" wirken etwas zu sehr dreidimensional in meinen Augen. Ich würde auch Mapnik gegenüber tiles-at-home bevorzugen, auch Geschmackssache, aber auch um dem Nutzer aus der Wikipedia erstmal immer die gleiche Karte anzubieten. Gib doch dem Markers-Layer eine Attribution mit einem Link z.B. hier auf die Projektseite, dann wissen die Leute, wo sie sich bei Problemen/Lob/Tadel melden können.
Insgesamt halte ich das Skript aber schon für nutzbar. Jetzt müßte man es in die Vorlage einbauen und diese dann irgendwie ausklappbar gestalten, damit das den Artikel nicht überfrachtet. Achso wenn dein Skript vom Toolserver aus laufen würde, könnte man sich den Proxy sparen, den du wohl benutzt. --Kolossos 23:24, 22. Mai 2011 (CEST)Beantworten

Danke, das automatische Scrollen einer langen Liste ist eine wichtige Idee, auf die ich noch nicht gekommen war.
Mapnik und Stecknadeln sind Geschmackssache. Ich mag den Osmarender eigentlich lieber.
Das mit der Attribution habe ich nicht verstanden. Wo soll der Link erscheinen und auf welche Aktion hin?
Das Script muss erst mal vom kmlexport aufgerufen werden können (ist angebahnt), dann kommt das Einbinden in die Vorlage dran. In der Vorlage habe ich aber keine Aktien. Dein Vorschlag wurde aber bereits irgendwo diskutiert. Ich find's gerade nicht, Vorlage_Diskussion:All_Coordinates oder Wikipedia:WikiProjekt Vorlagen/Werkstatt oder in deren Archive. --Plenz 01:17, 23. Mai 2011 (CEST)Beantworten
Wenn du auf meine Karte schaust, findest du unten rechts einen Link zu einer Hilfe-Seite. Gelöst ist das einfach durch "Mißbrauch" der Attribution-Funktion in OpenLayers.
Wie meinst du das: "Das Script muss erst mal vom kmlexport aufgerufen werden können" ich sehe es genau umgekehrt, dein Skript wird von der Vorlage aufgerufen und dein Skript ruft wiederum das kmlexport-Skript von Para auf und bindet die Daten dann ein. Wie ist das eigentlich wird das KML eigentlich auf deinem Server in eine Liste verwandelt oder läßt du das OpenLayers auf dem Client machen[1]? --Kolossos 15:51, 23. Mai 2011 (CEST)Beantworten
OK, Info-Link an den Lizenz-Text anfügen, kann ich machen.
Wenn ich die Funktionsweise richtig kapiert habe, läuft das so:
  • Das Template ruft kmlexport auf und übergibt den Parameter redir=google
  • Aufgrund des redir-Parameters bastelt kmlexport einen Link zusammen, der auf GoogleMaps zugeschnitten ist
  • Aufgrund dieses Aufrufs fordert GoogleMaps die kml-Daten von kmlexport an
kmlexport wird also zweimal benutzt: einmal um den Kartenanbieter korrekt aufzurufen und zweitens um diesem die kml-Daten zu übermitteln. Beim ersten Mal wird redir benötigt, beim zweiten Mal nicht.
Mein Programm zerpflückt die angelieferten kml-Daten selbst. Es sortiert sie von Norden nach Süden und wählt verschieden ausgerichtete Icons aus, falls mehrere auf dem selben Koordinatenpunkt liegen. --Plenz 17:37, 23. Mai 2011 (CEST)Beantworten
Ich denke für die deutsche Wikipedia könnte man sich den Umweg erstmal sparen und dein Skript direkt in die Vorlage einbinden. Später ist es natürlich von Vorteil, wenn man die URL für die vers. Sprachversionen der WP zentral anpassen könnte.
Hab jetzt auch mal kurz in deinen Quelltext geschaut, das erklärt einiges. Hier noch der Link zur alten Diskussion: Wikipedia:Fragen_zur_Wikipedia/Archiv/2011/Woche_15#Vorlage:All_Coordinates. --Kolossos 20:49, 23. Mai 2011 (CEST)Beantworten

Ich habe jetzt doch die Mapnik-Karte voreingestellt. Sie ist zwar nicht so schön wie die Osmarender-Karte, zeigt aber weniger Fehler. --Plenz 17:14, 19. Jun. 2011 (CEST)Beantworten

Schönheitsfehler

[Quelltext bearbeiten]

Dass die Struktur der HTML-Seite unübersichtlich ist, ist mir bewusst. Das ist aber momentan Absicht. Jetzt in der Entwicklungsphase besteht das ganze Programm aus einer einzigen Datei (ein Perl-Script, alles erzeugt). Egal an welcher Stelle ich etwas ändere, ich brauche immer nur diese eine Datei auf meinen Server zu laden. Wenn die wesentlichen Funktionen laufen, werde ich JavaScript und CSS auslagern und vor allem mehr kommentieren, um alles übersichtlicher zu machen und damit ich in einem Jahr noch durchblicke. --Plenz 13:33, 22. Mai 2011 (CEST)Beantworten

Ich meinte vor allem das DOM an sich, nicht die Quelltextformatierung. Statt Tabellen über Tabellen lieber mehr semantische Elemente mit passender CSS-Formatierung. Mein Vorschlag:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
   <!-- Scripte sind eh klar -->
   <style type="text/css">
      siehe unten
   </style>
</head>
<body>
   <div id="map">
      <noscript></noscript>
   </div>
   <div id="leiste">
      <div id="toolbar"></div>
      <dl id="sektionslos">
         <dd>
            <input type="checkbox" checked="checked" value="lon/lat1" />
            <a href="http://de.wikipedia.org/wiki/…"></a>
         </dd>
      </dl>
      <dl class="open">
         <dt>erste Überschrift</dt>
         <dd>
            <input type="checkbox" checked="checked" value="lon/lat2" />
            <a href="http://de.wikipedia.org/wiki/…"></a>
         </dd>
         <dd>
            <input type="checkbox" checked="checked" value="lon/lat3" />
            <a href="http://de.wikipedia.org/wiki/…"></a>
         </dd>
         <dd></dd>
      </dl>
      <dl class="open"></dl>
   </div>
</body>
</html>
mit folgendem CSS:
/* Spalten-Layout */
* { padding:0; margin:0; }
body, html { width:100%; height:100%; position:relative; }
#map, #leiste { height:100%; position:absolute; }
#map { left:10em; right:0; }
#leiste { left:0; width:10em; border-right: 1px solid grey; overflow-y:auto; }

/* Klapp-Stile der Leiste */
dt { font-weight:bold; padding-left:20px; background:left no-repeat; }
dl.open   dt { background-image: url(minus.png); }
dl.closed dt { background-image: url(plus.png); }
dl.closed dd { display:none; }
dd { padding-left:1.5em; }
dd input[type="checkbox"] { margin-left:-1.2em; }
dd:hover, dd.highlighted { background-color: #FC9; }

Das Javscript beruht insbesondere auf Klassenänderungen, ids werden ziemlich unnötig. Aber dazu später mehr. -- Bergi 14:53, 22. Mai 2011 (CEST)Beantworten

Sorry, ich möchte jetzt keinen Streit über Programmierästhetik anfangen. Und jetzt wo alles so weit prima funktioniert, möchte ich die Funktionsweise auch nicht total umkrempeln.
dd kannte ich bis jetzt noch gar nicht. Ich habe Tabellen benutzt, um zu verhindern, dass die Linktexte unter die Checkbox fließen.
Viel mehr würde mich interessieren, wie man ein stufenloses Resizen realisieren kann. --Plenz 17:28, 22. Mai 2011 (CEST)Beantworten
Resizen ist erledigt. Hoffentlich geht es auf einem schnelleren Rechner als meinem alten Notebook einigermaßen flüssig. --Plenz 20:06, 22. Mai 2011 (CEST)Beantworten
Wenn ich dich richtig verstanden habe, wechselt dein Vorschlag die Farben, indem das betreffende Element einer anderen Klasse zugeordnet wird. An sich eine interessante Idee, aber als ich heute diese Methode ausprobierte, musste mal wieder feststellen: was mit dem Firefox klappt, geht beim IE noch lange nicht. Ich musste dann doch wieder die Eigenschaften einzeln ändern. --Plenz 20:58, 26. Mai 2011 (CEST)Beantworten

Browser-Tests

[Quelltext bearbeiten]

Hallo Plenz, das Tool funktioniert auch mit altem IE (6 & 7), sowie mobil mit Dolphin HD und dem Android Stock-Browser (WebKit-basiert). Heute Abend teste ich noch mit Opera und Mobile Safari. Gruß--Coatilex 10:20, 24. Mai 2011 (CEST)Beantworten

WOW, du bist ja umfangreich ausgestattet. Danke für die Testergebnisse!
Mir scheint, die größte Hürde ist immer der IE. Wo Firefox sich gutmütig zeigt, macht der IE Zicken. Wenn man es dann geschafft hat, dass es mit dem IE funktioniert, klappt es auch bei den anderen Browsern. --Plenz 11:28, 24. Mai 2011 (CEST)Beantworten
So, des Testes zweiter Teil: Mit dem Opera 11 klappt es problemlos. Leider sieht es mit dem Mobile Safari nicht so gut aus. Während es mit den mobilen Browsern für Andorid anstandslos geklappt hat, macht der Apfel zicken. Die Seite wird geladen und funktioniert auch (d.h. Stecknadeln lassen sich entfernen, Links funktionieren,Karte lässt sich verschieben etc.) aber zwischen dem Frame rechts mit den Links und der Karte selbst ist ein großer Weißraum (mindestens 3 mal so breit wie der rechte Frame) und der Frame mit der Karte ist sehr schmal, nur etwa so breit wie der rechte Frame.
Jetzt ist natürlich ein mobiler Browser für diese Anwendung nicht so entscheidend aber es könnte ein Hinweis darauf sein, dass es generell mit dem Safari Problme gibt. Leider habe ich keinen "großen" Mac und kann das nicht testen.
Gruß--Coatilex 09:34, 25. Mai 2011 (CEST) PS: Es folgt noch ein dritter Teil, für den ich meine Linux-Maschinchen anwerfe ;-)Beantworten
Danke nochmal für deine Mühe.
Was den Safari betrifft: hast du mal versucht, die Grenze zwischen den Frames zu verschieben? Entweder oben auf die Pfeile klicken oder die Grenze durch Anfassen verschieben. Das sollte eine Neuberechnung der Framegrößen in Gang setzen. Wenn das klappt, sollte eine verzögerte erzwungene Neuberechnung nach dem Programmstart das Problem lösen.
Nach deiner Beschreibung ist die Linkliste rechts und die Karte links, stimmt das wirklich? --Plenz 10:19, 25. Mai 2011 (CEST)Beantworten
Peinlich, nein ich meine das andere rechts. Da hab ich wohl heute früh ein bisschen schneller getippt als gedacht. Kurz noch zur Info: Zuerst sieht alles beim Laden ganz normal aus (also Karte direkt neben den Links) aber dann "flackert" es kurz und man sieht nur noch den Weißraum. Beim Scrollen stellt man dann fest, dass die Karte noch da ist aber ganz an den rechten Rand gequetscht. Ich hab den Apfel jetzt nicht dabei, probiere das verschieben der Framegrenze dann heute Abend. Gruß --Coatilex 12:12, 25. Mai 2011 (CEST)Beantworten
Ich glaube, an dieser Funktion muss ich sowieso noch mal basteln. Der IE macht wie immer Ärger. Wenn man die Grenze mit der Maus verschiebt, nimmt er die gedrückte Maustaste zum Anlass, alles mögliche zu markieren. Ich muss wohl während des Verschiebens ein paar durchsichtige Elemente über die gesamte Seite legen, die das Markieren abfangen. --Plenz 13:55, 25. Mai 2011 (CEST)Beantworten
So, ich habe die Resize-Funktion jetzt überarbeitet. Versuch es bitte noch mal mit dem Safari. --Plenz23:46, 25. Mai 2011 (CEST)Beantworten
Wenn man die Seite jetzt aufruft tritt der Fehler nicht mehr auf aber man darf nicht Zoomen. Sobald man in die Seite reinzoomt fliegt die Karte wieder an den Rand und der Weißraum wird angezeigt. Die Begrenzung der Frames kann ich übrigens mit dem Mobile-Safari nicht verschieben, wenn ich versuche die zu erwischen will der Browser immer die Karte als Bild abspeichern. Noch eine erfreuliche Nachricht: Mit dem Xandros-Browser gibt es keine Probleme. Braves Linux ;-)--Coatilex 10:14, 27. Mai 2011 (CEST)Beantworten
Gilt deine Beschreibung für das Zoomen mit dem Mausrad (falls vorhanden) oder auch wenn man den Zoom-Regler verschiebt oder auch wenn man durch Klicken auf die Zoom-Skala zoomt? Nur mal aus Interesse, ich glaube, ich kann sowieso nichts daran ändern. Ich müsste jetzt nur mal jemanden finden, der einen "ausgewachsenen" Apple hat. --Plenz 11:32, 27. Mai 2011 (CEST)Beantworten
Da die Eingabe über Touchscreen erfolgt meinte ich Zoomen via Multi Touch. Also mit zwei Fingern auseinander ziehen des ganzen Bildes und nicht der Karte über die angezeigten Regler.--Coatilex 14:25, 27. Mai 2011 (CEST)Beantworten
Ah, verstehe. Aber ich glaube, darin habe ich überhaupt keine Aktien. Keine Ahnung, welchen Wert mobile Geräte für Variablen wie window.innerWidth setzen: den echten Bildschirm oder die theoretische Größe des gezoomten Fensters inklusive das, was über den Bildschirm hinausragt. Und wer weiß, ob das eine Gerät es so macht und das andere Gerät anders.
Wie auch immer... nochmal vielen Dank für deine Tests. Ich habe inzwischen auch zwei User angeschrieben, die laut ihrer Babel-Bausteine Macs benutzen. Mit deren Hilfe kann ich die Tests dann wohl abschließen. --Plenz 16:58, 27. Mai 2011 (CEST)Beantworten

Probleme mit Mac

[Quelltext bearbeiten]

Hi Plenz, (ich arbeite inkognito auf Mac): im Safari geht es nicht. Ich sehe nur die Listen, aber überhaupt keine Karte. Alle handles sind tot, die Menüzeile oben ist halbversteckt und ich kann die checkboxen, deren unteren Rand ich sehe, nicht anklicken. die zwei Pfeile ganz rechts auch Fehlanzeige. lg --Herzi Pinki 23:00, 6. Jul. 2011 (CEST)Beantworten

Ehrlich gesagt, bin ich hin und her gerissen: einerseits möchte ich gern perfekte Ergebnisse liefern, andererseits habe ich wenig Lust, den Safari zu installieren.
Hat der Safari eine Fehlerkonsole wie der FF bzw. eine Debugging-Funktion wie der IE? Dann wüsste ich mal gern, was er zu bemeckern hat. --00:15, 14. Jul. 2011 (CEST)

Vorlage

[Quelltext bearbeiten]

Wenn man das mit dem Aufklappen sich bei den Navileisten anschaut, sieht man dass das wohl zu aufwendig für unsere kleine Anwendung wird. Ich habe daher mal geschaut, ob sich das Problem nicht auch einfach durch einen Zeilenumbruch lösen läßt. Eingebaut ist die Vorlage mal probeweise bei Liste Coburger Brunnen eingebaut. Die Vorlage läuft bei mir momentan unter Benutzer:Kolossos/Selektion. Ich denke mal so würde es schon gehen. --Kolossos 23:17, 24. Mai 2011 (CEST)Beantworten

Es jedem recht machen kann man sowieso nicht. Bei mir verdeckt dein Template die Links "Verschieben" und "Beobachten" sowie "weitere Änderungen sichten". Bei anderen Leuten verdeckt es wahrscheintlich etwas anderes, je nach Einstellungen und Änderungen in ihrem monobooks. Daran würde auch das Aufklapp-Feature nicht viel ändern.
Also, meinen Segen hast du. Wenn ich all die vielen Klammern sehe, vergeht mir sowieso schon jede Lust am Vorlagenbasteln. Vielen Dank für deine Mühe. --Plenz 00:52, 25. Mai 2011 (CEST)Beantworten

Selektieren

[Quelltext bearbeiten]

Prima Skript, vielen Dank!

Ist es möglich, die Referenzen und Koordinaten zu unterscheiden?
Beispiel: hier ist eine Tabelle mit Koordinaten: Liste_der_Stationen_des_preußischen_optischen_Telegrafen.
Mit dem Skript sieht sie so aus. Es werden alle Stationen angezeigt -- leider auch die anderen Querverweise. Wenn es jetzt möglich wäre, die eigentlichen Koordinanten für Station i, Station i+1, ..., vom Rest zu abzusetzen...

...dann könnte das Skript auch die Vorlage {Positionskarte+} ersetzen. Hier zwei Beispiele: Drehfunkfeuer
Die Österreichkarte erfordert eine eigene Liste der Punkte innerhalb der Vorlage.
Die Deutschland-Karte wurde per Hand erzeugt. Denn die Vorlage versagt bei so vielen Punkten.

Auch {Linked Coordinates} zeigt leider nicht nur die Koordinanten der Stationen, sondern auch all die anderen Links innerhalb eines Abschnitts.

Vermip 19:01, 27. Mai 2011 (CEST)Beantworten

Erst mal grundsätzlich: welche Koordinaten angezeigt werden und welche nicht, ist nicht Sache meines Programms. Die Koordinaten liefert das Script kmlexport, und das will richtig "gefüttert" werden. Dafür soll eigentlich das Template All Coordinates dienen, dort sind die Parameter beschrieben, die ich deshalb hier nicht weiter erläutert habe.
Um es kurz zu machen: lass den Parameter "linksfrom=1" weg, und dann sollte es so sein, wie du es dir vorstellst. Hoffe ich jedenfalls. --Plenz 00:14, 28. Mai 2011 (CEST)Beantworten

rote Baloons

[Quelltext bearbeiten]

Ich sehe seit heute solche roten Baloons mit "testing testing testing" wenn ich mit der Maus auf die Stecknadeln gehe. Ich hoffe mal das ist keine Dauerzustand. --Kolossos 17:27, 2. Jun. 2011 (CEST)Beantworten

Danke... so was kommt, wenn man eigentlich sofort ins Bett sollte, weil es wieder mal viel zu spät ist, aber vorher muss man unbedingt noch etwas ausprobieren... --Plenz 23:32, 2. Jun. 2011 (CEST)Beantworten

l=0 bei OSM

[Quelltext bearbeiten]

kmlexport hat l=0 als parameter für unlimitierte Tiefe im Kategoriebaum, die aktuelle Implementierung von Plenz nimmt das literally, also level=0 (d.h. es werden keine koord angezeigt) l=0 sollte ebenfalls als vollständig expandierter Katbaum interpretiert werden. lg --Herzi Pinki 00:50, 1. Jun. 2011 (CEST)Beantworten

Danke für die Fehlermeldung, ich habe die Sache heute repariert. War gar nicht so leicht, eine passendes Testkategorie zu finden, aber es ist mir dann doch gelungen. Siehe Testlinks auf der Projektseite. Je nach Anzahl der Ebenen bekommt man 3, 19, 48 oder 173 Orte zu sehen. --Plenz 22:39, 7. Jun. 2011 (CEST)Beantworten

Fidschi...

[Quelltext bearbeiten]

...macht immer noch nicht ganz das, was es soll. Siehe [2] und dann nach Levuka zoomen. Da ist etwas zu viel rechteckiges Land. --тнояsтеn 20:15, 10. Jun. 2011 (CEST)Beantworten

Damit habe ich nichts zu tun. Das sind Kacheln, die nicht korrekt gerendert sind. Wahrscheinlich stammen sie noch von sehr grobem Datenmaterial aus den USA, aus dem ursprünglich mal die Küstenlinien hergestellt wurden. Klick mal auf das (+) oben rechts und wähle Mapnik, da sind die Quadrate weg. --Plenz 08:40, 11. Jun. 2011 (CEST)Beantworten
Ah OK... hatte es bei OSM gecheckt, aber dort eben auch Mapnik eingestellt. --тнояsтеn 12:58, 11. Jun. 2011 (CEST)Beantworten

momentan keine Karte

[Quelltext bearbeiten]

Momentan bekomme ich über den OSM link bei {{All Coordinates}} überhaupt keine Karte, nur die Liste der Orte. lg --Herzi Pinki 07:16, 2. Jul. 2011 (CEST)Beantworten

sorry, zu ungenau: gilt im Safari, im Firefox bekomme ich eine Karte. --Herzi Pinki 22:55, 6. Jul. 2011 (CEST)Beantworten

Sections

[Quelltext bearbeiten]

{{All Coordinates}} erlaubt die Angabe eines Abschnitts (section), allerdings funktioniert das bei OSM nicht richtig (siehe auch hier). Da deine OSM Implementierung das kmlexport script vom toolserver aufruft, könnte ich nur raten, mit welchem encoding die sections an die OSM Implementierung übergeben werden. Vielleicht hast du eine Lösung? Danke --Herzi Pinki 07:25, 2. Jul. 2011 (CEST)Beantworten

Defekt? & WIWOSM

[Quelltext bearbeiten]

Hallo, der Dienst scheint nicht zu funktionieren: http://www.lenz-online.de/cgi-bin/wiki/wiki-osm.pl?project=de&linksfrom=1&article=Burg+%28Begriffskl%C3%A4rung%29

Dazu kommt meine andere Frage, ob jetzt wo es WIWOSM gibt, man das nicht irgendwie beides miteinander verknüpft. Am Beispiel einer Bundesstraße, von der Wikipedia käme der Anfangs- und Endpunkt und von WIWOSM der Rest dazwischen als extra Layer. Dann müßten wir nichts an der Vorlage ändern. --Kolossos (Diskussion) 21:24, 24. Mär. 2012 (CET)Beantworten

Sorry, ich habe diesen Eintrag erst aufgrund deiner E-Mail gesehen. Ja, der Sache muss ich mal nachgehen. Der alternative Aufruf [3] erzeugt eine Fehlermeldung. Aber mit Google funktioniert die Sache.
Ehrlich gesagt, habe ich mich noch nie mit Relations beschäftigt. Deshalb kann ich mir unter "irgendwie" auch nicht viel vorstellen. --Plenz (Diskussion) 13:57, 28. Mär. 2012 (CEST)Beantworten
Das Gute ist, du mußt dich nicht mit Relationen von OSM auseinandersetzen. Man ruft bei WIWOSM ein Skript mit Sprache und Artikelname auf und bekommt eine GeoJSON Datei zurück. Du müsstest nur aus meinem Quelltext die Zeilen 260-309 bei dir rein kopieren (so die Theorie) und dann hättest du den Layer. Umgekehrt würde es auch gehen, aber mein Skript vielleicht unnötig aufblähen. --Kolossos (Diskussion) 19:58, 28. Mär. 2012 (CEST) (P.S.: in IE8 scheint das Skript auch ein Problem zu haben, da sehe ich nur die Tabelle aber nicht die Karte.)Beantworten
Heute bin ich ein bisschen zum Debuggen gekommen, da klappt ja einiges nicht, was bisher geklappt hat. Liegt vermutlich daran, dass ich meinen Server kürzlich von Lenny auf Squeeze upgegradet habe, und da läuft wohl einiges nicht wie gewohnt. Ich habe jetzt keine Fehler mehr im Error-Log, aber irgendwo hapert es immer noch, sprich: jetzt wird es erst richtig schwierig. Kann keine Prognosen abgeben, wann es wieder läuft, geschweige denn sogar mit den IE, der immer Extrazicken macht. --Plenz (Diskussion) 16:40, 1. Apr. 2012 (CEST)Beantworten
So, ich denke, ich habe die Sache erledigt. Der obige Link funktioniert, und das sogar auch im IE :)
Um dein Anliegen kümmere ich mich irgendwann später. Ich muss das schlechte Osterwetter noch für andere Programmierprojekte ausnutzen. Nur so viel: einfaches Kopieren dürfte schon daran scheitern, dass ich in Perl programiere. --Plenz (Diskussion) 23:03, 6. Apr. 2012 (CEST)Beantworten

Pluszeichen

[Quelltext bearbeiten]

Seiten mit Pluszeichen (+) wie Benutzer:Amga/Test+mit+Plus funktionieren nicht mit osm4wiki: https://tools.wmflabs.org/osm4wiki/cgi-bin/wiki/wiki-osm.pl?project=de&article=Benutzer%3AAmga%2FTest%255Bmit%252BPlus&section=Werkverzeichnis

Siehe: Vorlage Diskussion:All_Coordinates#Von zwei identischen Seiten zeigt eine die OSM-Karte an, die andere nicht --Fomafix (Diskussion) 15:13, 20. Okt. 2014 (CEST)Beantworten

Wann geht's weiter?

[Quelltext bearbeiten]

Wollte mal höflich nachfragen, wann man wieder mit dem tool arbeiten kann? Gruß und frohes Fest, --Berihert • (Diskussion) 14:01, 22. Dez. 2014 (CET)Beantworten

Kartentiles sind momentan veraltet

[Quelltext bearbeiten]

Ich stelle fest, dass das Projekt seine eigene Tile-Engine verwendet. Vermutlich, weil die von OSM bereitgestellten Tiles Restriktionen unterworfen sind.

Leider sind die hier verwendeten Tiles teilweise stark veraltet. Besteht die Möglichkeit, sie wieder neu zu generieren oder aber doch (über einen Cache) die OSM-TIles zu verwenden?

--glglgl 14:26, 10. Okt. 2016 (CEST)Beantworten

Die Kacheln kommen zumindest jetzt von tiles.openstreetmap.org. --nenntmichruhigip (Diskussion) 08:51, 19. Jan. 2017 (CET)Beantworten

HTTPS für Kartenkacheln

[Quelltext bearbeiten]

Die URL der Kartenkacheln sollte auf HTTPS umgestellt werden. Ich sehe da gerade nur rot, weil sie als Mixed-Content nicht geladen werden dürfen :-) --nenntmichruhigip (Diskussion) 08:51, 19. Jan. 2017 (CET)Beantworten

Warnungen in error.log auf Tool Labs

[Quelltext bearbeiten]

Dein Tool osm4wiki produzierte zahlreiche Warnungen für nicht definierte Variablen, etc. in der Datei /data/project/osm4wiki/error.log, die daraufhin sehr schnell wuchs. Ich habe letztes Jahr den Originalquelltext als /data/project/osm4wiki/public_html-backup-2016-12-10T04:41:20+0100.tar.bz2 gesichert und einige der Warnungen mit einem Patch mehr oder minder gefixt, wie auf phab:T151568 dokumentiert. Leider war es mir nicht möglich, das „vernünftig“ zu tun, da der Quelltext weitgehend unkommentiert ist und von außen es schwer ist zu erkennen, welche Variable an welcher Stelle welchen Wert haben sollte (bzw. vorher diese Werte kommen). Mittlerweile ist das Wachstum von error.log in einem akzeptablen Rahmen, aber es wäre natürlich trotzdem hilfreich, die noch verbleibenden Warnungen zu korrigieren und eventuell den Quelltext, vielleicht mit Hilfe von anderen Entwicklern, „aufzuhübschen“. Vielen Dank! --Tim Landscheidt 05:37, 1. Feb. 2017 (CET)Beantworten

osm4wiki - Daten extrahieren

[Quelltext bearbeiten]

Wow, ein tolles Projekt. Gibt's dabei eine einfachere Möglichkeit, die damit gesammelten Daten zu exportieren? Beispiel [4]... ich würde gerne die Koordinaten der Sender direkt haben, um die in meiner Nähe herauszufiltern. --Traut (Diskussion) 19:15, 9. Dez. 2017 (CET)Beantworten

Kodierungsproblem bei OSM for Wiki

[Quelltext bearbeiten]

Hallo Plenz (auch an Kolossos), wenn in der de-Wikipedia, bei einer Verwendung der Vorlage:Coordinate, der dem Parameter name zugeordnete Wert (der in dem von der Vorlage:Coordinate erzeugen Hyperlink zum Tool GeoHack als Wert des URL-Parameters title übergeben wird) ein Schriftzeichen enthält, dass in der URL-Kodierung aus drei Bytes besteht im Unicode in mehr als einem Byte kodiert ist (also alle Zeichen ab U+0100 aufwärts) (was z. B bei den Schriftzeichen –, „ und “ der Fall ist), wird es zwar in dem über die Vorlage:Coordinate verlinkten Tool GeoHack korrekt wiedergegeben, aber in OSM for Wiki (z. B. bei Verlinkung über die Vorlage:All Coordinates) nicht. In OSM for Wiki wird in diesem Fall nur das erste Byte als ISO-8859-1 oder Windows-1252 interpretiert, die beiden hinteren Bytes jedoch ignoriert, d. h. gar nicht interpretiert oder dargestellt (z. B beim – im name-Parameter „Lechstaustufe 2 – Prem“ in der Liste der Seen in Bayern). Darüberhinaus erzeugt dieser Fehler noch einen weiteren: Bereits ein einziges, URL-kodiert aus drei Bytes bestehendes im Unicode in mehr als einem Byte kodiertes Schriftzeichen im name-Parameter einer Verwendung der Vorlage:Coordinate führt dazu, dass OSM for Wiki für diesen Artikel auch alle aus zwei mehr als einem Bytes bestehenden, UTF-8 basierten URL-Kodierungen (z. B bei den Schriftzeichen ä, ö, ü und ß) in den title-Parametern der Hyperlinks zum GeoHack (die durch Verwendungen der Vorlage:Coordinate erzeugt werden) sowie in den von kmlexport exportierten Überschriften der Abschnitte (einschließlich Unterabschnitte, Unter-Unterabschnitte usw., wobei jeweis nur der niedrigste relevant ist), in denen die Vorlage:Coordinate eingebunden ist, – die an sonsten von OSM for Wiki korrekt interpretiert werden (z. B. ö und ü in den Verwendungen von OSM for Wiki in den Artikeln Nationalpark Hohe Tauern oder Welterbe in Deutschland) – nun ebenfalls als ISO-8859-1 oder Windows-1252 interpretiert und die Schriftzeichen daher nun falsch dargestellt werden (interessanterweise werden dabei bei den Schriftzeichen ä, ö und ü die beiden Bytes einzeln als ISO-8859-1 oder Windows-1252 interpretiert und dargestellt, während beim Schriftzeichen ß nur das erste Byte als ISO-8859-1 oder Windows-1252 interpretiert und dargestellt wird, das zweite Byte hingegen ignoriert wird). Eine Erläuterung zum Problem der fälschlichen ISO-8859-1- oder Windows-1252-Kodierung ist in http://i18nqa.com/debug/bug-utf-8-latin1.html zu finden (siehe dazu auch die UTF-8 Encoding Debugging Chart). Das Problem tritt hingegen nicht auf, wenn osm4wiki im Parameter article der Titel einer Kategorie übergeben wird (z. B. https://tools.wmflabs.org/osm4wiki/cgi-bin/wiki/wiki-osm.pl?project=de&l=0&article=Kategorie:Schiffswrack ), in diesem Fall werden die selben Schriftzeichen, die bei Übergabe des entsprechenden Artikeltitel falsch dargestellt werden, korrekt dargestellt. Bei der Verwendung der Vorlage:Linked Coordinates tritt das Problem dann auf, wenn im Wikitext der Wikipedia-Seite, in der {{Linked Coordinates}} im Wikitext steht, sich im Wert des Parameters name einer Vorlage:Coordinate eines der problemauslösenden Zeichen befindet; solche Zeichen in den verlinkten Wikipedia-Seiten sind unschädlich. Wie lässt sich das Problem beheben? --X:: black ::X (Diskussion) 01:43, 10. Feb. 2018 (CET), präzisiert 12:23, 13. Feb. 2018 (CET), umgeschrieben 14:33, 13. Feb. 2018 (CET), korrigiert 14:46, 13. Feb. 2018 (CET), korrigiert 13:19, 14. Feb. 2018 (CET) und 17:51, 20. Mär. 2018 (CET), ergänzt 20:29, 21. Mär. 2018 (CET) und 13:08, 10. Apr. 2018 (CEST)Beantworten

Since I got also complaints from CZ, I answer in English.
I want to explain that my tool uses another tool named "kmlexport" which extracts coordinates from articles. My tool only displays the result which comes from "kmlexport".
For any bug, we have to find out which tool is the reason. Please use the table below to show examples. Create/copy/paste a new line and change all links according to your examples.
Version 1 and Version 2 have different ways to call "kmlexport" but should show exactly the same results.
In general: if the example is OK in Google, "kmlexport" works well and my tool is buggy. If the example is buggy in Google, "kmltool" is the reason.
--Plenz (Diskussion) 21:49, 14. Feb. 2018 (CET)Beantworten
Functions Article Google OSM 4 Wiki OSM 4 Wiki
List of coordinates in the article Zeche Zollern Google Version 1

Version 2

Coordinates from linked articles 1571 Google Version 1

Version 2

List of coordinates in the article cs:Středověké památky v Kosovu Google Version 1

Version 2

List of coordinates in the article cs:Seznam kostelů v Brně Google Version 1

Version 2

I discussed this topic also with skwiki technicians and yeah, it seems like this is a problem in kmlexport. More specifically, kmlexport outputs file with broken encoding, which osm4wiki can handle partially, but wm-world or mapycz tools can not handle such a broken kml file at all. (PS: I added examples of broken behavior to the table, so it is obvious). I contacted kmlexport author over a week ago but I haven't got any answer yet (he abandonded the project relatively a long time ago). --Dvorapa (Diskussion) 00:03, 15. Feb. 2018 (CET)Beantworten
Okay, we have currently three problems with the tool on cswiki:
  1. Can not show lines: e.g. subway line with stations, as discussed here this might not be fixed
  2. Shows additional point at 0°0'0'' in some cases: as discussed here this might be fixed
  3. Shows broken encoding for some articles: encoding issue in KMLexport tool, I filled in a task for Toolforge and asked the original author (after a month without a response).
--Dvorapa (Diskussion) 19:18, 17. Feb. 2018 (CET)Beantworten
OK. Today I succeeded to re-activate my wmflabs access and now I can start to debug my program. There seems to be one more problem - so please be patient, it might take some time.
Indeed, point 1 is not on my todo list, and I don't think it will ever be. Those things are against my basic understanding about Wikipedia.
BTW: perhaps you might be interested of working with the Benutzer:Plenz/OSM_for_Wiki#International_Language_File? --Plenz (Diskussion) 23:22, 17. Feb. 2018 (CET)Beantworten
Sure, I'll create Czech translation, maybe tomorrow. --Dvorapa (Diskussion) 23:31, 17. Feb. 2018 (CET)Beantworten
Another issue: Sometimes osm4wiki can not show labels, see for example this KML file in action here. --Dvorapa (Diskussion) 20:48, 18. Feb. 2018 (CET)Beantworten
If your term label means the content of the name-tag of a KML-file, the issue is probably also already described here (see the second to last contribution). --X:: black ::X (Diskussion) 12:44, 19. Feb. 2018 (CET)Beantworten
Ad Dvorapa, if you wonder why your translation on Benutzer:Plenz/OSM for Wiki/languages isn't working already: the length of each text line is limited to a maximum of 70 characters (see Benutzer Diskussion:Plenz#OSM for ca.wiki), but your translation for the timeout-line unfortunately is 4 characters longer. --X:: black ::X (Diskussion) 12:30, 20. Feb. 2018 (CET)Beantworten
HTML entities are making the text 2x longer :/ It is already pretty concise. --Dvorapa (Diskussion) 21:47, 20. Feb. 2018 (CET)Beantworten
Are you sure that you can't use the characters themselves, instead of the HTML-entities? The characters should be displayed correctly. Are you sure, that &Ccaron;,&zcaron;,&rcaron; and &ccaron; are valid and working HTML-entities? When I tested them, they didn't work. If these HTML-entities are inevitable, you could use HTML-entities of the structure &#268;, &#269;, &#345; or &#382; instead, which would be about two characters shorter each, what would make you meet the 70 characters maximum. The other option is to ask Plenz to increase the limit again. --X:: black ::X (Diskussion) 23:25, 20. Feb. 2018 (CET), extended 23:42, 20. Feb. 2018 (CET) and 00:02, 21. Feb. 2018 (CET), corrected 12:40, 22. Feb. 2018 (CET)Beantworten
They are valid HTML5 entities, but maybe they lack support. I don't know, there is written they should be used, so I used them. --Dvorapa (Diskussion) 06:41, 21. Feb. 2018 (CET)Beantworten
You are absolutely right, there is written HTML-entities should be used and Plenz also did so in the definition for de language. But valid HTML 4, HTML 5 and XHTML entities containig the term „caron“ are only &Scaron; and &scaron;. They are listed by the World Wide Web Consortium (W3C) at https://www.w3.org/TR/html401/sgml/entities.html and https://www.w3.org/TR/xhtml1/DTD/xhtml-special.ent, in selfhtml at https://wiki.selfhtml.org/wiki/Referenz:HTML/Zeichenreferenz#Lateinisch_erweitert and at en:List_of_XML_and_HTML_character_entity_references. &Ccaron;, &ccaron;, &ecaron;, &rcaron; and &zcaron; are no officially defined character entities in HTML. They are supported by some browsers but wikipedia seems to inactivate them before, so you probably will have to use the unnamed HTML-entities &#268;, &#269;, &#283;, &#345; and &#382; to display the characters Č, č, ě, ř and ž. I dont know If they are counted as one or as six characters but each of them is two characters shorter anyway. By the way, the author of the ca language version did not use HTML-entities for the characters ó à é but my browser displays them correctly despite of this. --X:: black ::X (Diskussion) 11:43, 21. Feb. 2018 (CET), corrected 12:27, 21. Feb. 2018 (CET), extended 13:01, 21. Feb. 2018 (CET), corrected 12:40, 22. Feb. 2018 (CET) and 13:26, 23. Feb. 2018 (CET)Beantworten
Most of them is officially defined in HTML5, see https://www.w3.org/TR/html/syntax.html#named-character-references. I'll fix those not working in Firefox. --Dvorapa (Diskussion) 15:02, 21. Feb. 2018 (CET)Beantworten
You are right, these character reference names are supported by HTML 5 and they are also supported by Mozilla Firefox, but the wikipedia inactivates them by changing the &rcaron; in the Wikicode to the HTML sourcecode &amp;rcaron; before delivering the HTML-file to a browser, see view-source:https://de.wikipedia.org/w/index.php?title=Benutzer:Plenz/OSM_for_Wiki/languages&oldid=174162252. Wikipedia does so with all entities it doesn't know. phabricator:T94603 mentions this problem. So thank you for modifying the Wikicode. I asked Plenz to consider, if it would be a good idea to increase the maximum limit for the numer of characters in one line, or to allow/enable the use of the characters themselves. --X:: black ::X (Diskussion) 12:40, 22. Feb. 2018 (CET)Beantworten
I see, thank you for pointing out the task. I think it is not needed to increase the maximum chars allowed limit, because ASCII entities fixed the issue with timeout line right? --Dvorapa (Diskussion) 16:09, 22. Feb. 2018 (CET)Beantworten
The Wikicode
timeout = &#268;as vypr&scaron;el – v&aacute;&scaron; po&#382;adavek byl p&#345;&iacute;li&scaron; n&aacute;ro&#269;n&yacute;
is changed by wikipedia to the HTML sourcecode
timeout = &#268;as vypr&#353;el – v&#225;&#353; po&#382;adavek byl p&#345;&#237;li&#353; n&#225;ro&#269;n&#253;.
I learned that the differece in the number of characters between a named character reference (named HTML entities) and its corresponding decimal numeric character reference (decimal numeric HTML entities) in this case is irrelevant, as wikipedia—when processing Wikicode to HTML sourcecode—replaces the named character references by decimal numeric character reference (except &gt;, &lt; &amp; and &quot; [for >, < & and "]); as far as I know this is done because of XML compatibility (more information may be at rev:82413 respectively phabricator:rSVN82413). Benutzer Diskussion:Plenz#OSM for ca.wiki states, that in osm4wiki the current limit would be 70 characters. osm4wiki gets
&#268;as vypr&#353;el – v&#225;&#353; po&#382;adavek byl p&#345;&#237;li&#353; n&#225;ro&#269;n&#253;
from wikipedia, and is expected to output it as:
Čas vypršel – váš požadavek byl příliš náročný
. The input has 101 characters (if one also counts the space after “=” 102 characters), the expected output would have 46 characters (if one also counts the space after “=” 47 characters). As the cs-translation is not used by osm4wiki at the moment, I expect this is due to exceeding the limit. --X:: black ::X (Diskussion) 13:26, 23. Feb. 2018 (CET)Beantworten
Hello Dvorapa, I could find out what triggers kmlexport, to put out wrongly encoded KML files, when extracting from pages of the cs-wikipedia. I've updated the description of the problem, as it appears in the cs-wikipedia, here. --X:: black ::X (Diskussion) 13:51, 9. Apr. 2018 (CEST)Beantworten
Hi, I know what causes the problem, there already is a possible solution in Georeferenzierung WikiProjekts diskussions. On April 22, there will be a Toolforge workshop in Prague, CZ, so I'll then try to create a tool, which will serve as a middle point between GeoHack and KMLexport and fix these three bytes to two bytes on the place where needed => Not between Article and GeoHack, but between GeoHack and KMLexport. Until tthat you can use Lua module mentioned on that WikiProjekt's talk and created by members of the WikiProjekt. --Dvorapa (Diskussion) 18:32, 9. Apr. 2018 (CEST)Beantworten
Hi Dvorapa, be aware, that (compared to the de-wikipeida), in the cs-wikipedia it are the same chracters that cause the problem, but at a different location in the wikitext. While in de-wikipedia, characters in the parameter title of the URL of the link to the GeoHack cause the kmlexport-encoding-problem, in cs-wikipedia, characters in the headings of the sections, subsections or sub-subsections (in each case only the lowest one) the cs:Šablona:Souřadnices are in, cause the problem. Characters in the parameter title are affected if vulnerable, but do not trigger the problem; in the de-wikipedia, it's the other way round (only characters in the parameter title can trigger the problem, characters in the headings are only affected, if vulnerable). But while the value of the parameter title is not displayed in the wikipedia-page, and is created by a Template (Vorlage:Coordinate respectively cs:Šablona:Souřadnice), which can be altered (as it was done in Vorlage:Coordinate), the content of the headings of the sections, subsections or sub-subsections is displayed in the wikipedia-page, and the headings are not created by a template, but directly by wikitext-markup. Thus, for cs-wikipedia would have to be found a way, to, on the one hand display the typographicly correct heading in the wikipedia-page, and (at the same time) on the oher hand forward a second version of this heading to kmlexport, which is reduced (at least) to characters of the Unicode range 0x0000 to 0x00FF (the ISO-8859-1 characters). I whish you all the best for the workshop and hope you will succeed, creating such a tool. It would surely be helpful. --X:: black ::X (Diskussion) 13:08, 10. Apr. 2018 (CEST)Beantworten
I know about this issue. This is why I can not just use kmlHack to cswiki, but create a tool on Toolforge based on that kmlHack. --Dvorapa (Diskussion) 14:10, 10. Apr. 2018 (CEST)Beantworten
Ad Dvorapa: Perhaps also using anchors would be an interesting option to achieve improvements, see Wikipedia Diskussion:WikiProjekt Georeferenzierung#Workaround für Problem mit OSM / kmlexport / bestimmten Zeichen (the three last posts). --X:: black ::X (Diskussion) 12:08, 14. Apr. 2018 (CEST)Beantworten

OSM-Karte für Schiffswracks

[Quelltext bearbeiten]

Hallo Plenz :-) erstmal Danke das Du Dich für die Verbindung der Wikipediadaten und Karten einsetzt. Im Portal:Schifffahrt habe ich dazu dort einen Merker gesetzt. Die Möglichkeit über Kategorien die Schiffswracks anzuzeigen ist ein tolles Feature. Was ich bisher genutzt habe:

Bei Nutzung aufgefallen/notiert:

  • das für Schiffswracks die Bezeichnung |type=landmark| etwas unglücklich ist, habe ich dort angesprochen.
  • zu den Wracks finden sich teilweise mehrere Positionsangaben ... die Position des Wracks und diverse "Events" => z.B. Untergang, Versenkung, torpediert, und so weiter. ob das Sinn (besonders bei nahe zusammen liegenden Positionen) macht ist fraglich. Check dazu: Positionen zur Titanic
  • das Label welches mit der OSM-Kartebasis angezeigt wird, ist oft unbrauchbar. Beispiel zur Behebung: |name=Lage| nach |name=Wrack der xyz xyz|. Wie wir das den Autoren am besten vermitteln, überlegen wir gerade dort.
  • vorläufige Anwendungsbeispiele per Wikipedia:Formatvorlage Schiffswrack an jener Stelle.

Nun gibt es dazu weitere Fragen. Das die Server (unsere "Hamster") manchmal etwas Zeit brauchen, bis geänderte Werte durchgereicht werden kann man verstehen und sie mit Purge nochmals beschäftigen. Unsicher werde ich, wenn man nicht verstehen/reproduzieren kann warum es mal klappt und mal nicht. Gestolpert bin ich zuletzt an jenen Stellen:

Frage dazu: Kann es sein, dass die Reihenfolge der Parameter eventuell beeinflusst das/ob es mal klappt und mal nicht? Anfangs habe ich es mit der Entfernung von |article:/| versucht, was teilweise geholfen hat. Sorry ich komme nicht dahinter warum es manchmal nicht funktioniert.

Die OSM-Version mit der Liste links ist schön, weil man per Wracknamen (+crtl-f) die Postition schnell auf der Karte finden kann. Allerdings ist die Reaktion auf den Mauszeiger bei der OSM-Kartenversion etwas zu sensibel ... die Karten(-auschnitte) springen zu schnell weg. Die Googleversion naja ... gut das die auch funktioniert ... irgendwie ... bing hab ich nicht testen können.

Tja ... ich weiß nicht ob Du Dich nun über das Feedback "ganz doll" freust oder vielleicht eher weniger. Ich warte einfach mal Deine Reaktion ab. Herzliche Grüße --80.187.97.165 19:28, 18. Feb. 2018 (CET)Beantworten

Die von Dir – in den aufgelisteten Beispielen – in den Wert des Parameters name der Vorlage:Coordinate (oder einer anderen, diese Vorlage einbindenden Vorlage) eingefügten Anführungszeichen ( und ) werden möglicherweise lösen das teils hier und teils hier beschriebene Kodierungsproblem auslösen, das allerdings in der Tat nicht vollständig geklärt ist, da z. B. die Anführungszeichen und öfters, aber – wie an den Artikeln Admiral Nachimow (1885), City of Rio de Janeiro, HMS Swordfish (61S), HMS Umpire (N82), HMS Vandal (P64), Ostmark (Schiff, 1936) zu sehen, die in der Kategorie:Schiffswrack verlinkt sind – nicht immer dieses Problem auslösen; was „normale“ Nutzer jedoch nur dann betrifft, wenn in der Seite, in der die Vorlage:Coordinate in den Wikitext eingetragen ist, auch die Vorlage:All Coordinates oder die Vorlage:Linked Coordinates durch Eintrag in den Wikitext eingebunden ist. (Nicht ausgelöst wird das Problem, wenn die Vorlage:All Coordinates in einer der Kategorie-Seiten eingebunden ist in die die betreffende Seite eingeordnet ist, ebensowenig wird das Problem ausgelöst, wenn die Vorlage:Linked Coordinates in einer anderen Seite eingebunden ist und das über sie aufgerufene Tool die betreffenden Seite in seiner Ergebnisliste aufführt. Im davon unabhängigen Tool GeoHack gibt es ebenfalls kein Kodierungsproblem.) Die Ursache für das dort beschriebene Problem liegt allerdings bei dem – ebenfalls auf Toolforge gehosteten – Tool kmlexport (Projektseite, Tool account). Erklärt das die Ursache Deiner Verwunderung, warum es mal klappt, und mal nicht, oder hast Du noch ein dadurch nicht erklärbares Problem festgestellt? Die von Dir als „Googleversion“ erwähnte Anwendung googlmaps-proxy des Tools wp-world nutzt ebenfalls kmlexport und ist daher auch von diesem Kodierungsproblem betroffen, kann aber im Gegensatz zu dem Tool osm4wiki (OSM for Wikipedia) – bei dem nur einige Schriftzeichen, in den den Koordinaten zugeordneten Namen falsch dargestellt werden – KML-Dateien mit Kodierungsfehlern gar nicht verarbeiten. Weitere Informationen zu manchen Anwendungen des Tools wp-world findest Du in Wikipedia:WikiProjekt Georeferenzierung/Anwendungen/World und Wikipedia:WikiProjekt Georeferenzierung/Hauptseite/Wikipedia-World. Zu Bing Maps siehe Vorlage Diskussion:All Coordinates#Bing und Vorlage Diskussion:All Coordinates#Das ist aber auch nicht mehr, was es mal war. --X:: black ::X (Diskussion) 12:31, 19. Feb. 2018 (CET), ergänzt 13:08, 19. Feb. 2018 (CET), 14:00, 19. Feb. 2018 (CET), 14:20, 19. Feb. 2018 (CET) und 16:16, 19. Feb. 2018 (CET), korrigiert 18:27, 22. Mär. 2018 (CET)Beantworten
Danke für Deine Mühe die Sache zu untersuchen ... tja uff ... einerseits ist man als Wiki-Autor gewohnt bescheiden zu sein und noch selbst irgendwelchen Wiki-Code einzutippen ... anderseits ist man verwöhnt was Tools & Gimmiks angeht. Hm hm hm was sich mit den Hamstern abspielt, ist mir inzwischen zwei bis drei Nummer zu hoch ... und ich mag es in meinem Alter auch nicht mehr lernen. Ein Hinweis à la mach es so oder mach es andersrum wäre schon gut ... zumal dieses Wissen auch noch weitergegeben werden muss. Man kann sich sehr gut darauf einigen nur die OSM-Version zu nutzen. Allerdings ist die Maussteuerung deutlich zu nervös (Firefox 58.0.2 (64bit), Linuxmint, Kernel 4.10.0-42). Beim Wechsel von Liste zur Karte oder Karte zur Liste ist meist wieder alles verschoben ... der Karten-Zoom macht auch grad was er will. Wenn die Anwendung nicht so genial wäre den Artikelbestand von Kategorien / Fachbereichen aus einem völlig anderem Blickwinkel zu betrachten ... ja dann würde ich bestimmt nicht hier nachfragen. Du merkst es einfach nicht, wenn beispielsweise ein Wrack statt unter Wasser stattdessen im Gebirge liegt. Dank der Karte konnten wir schon etliche Fehler beheben. Das wir dann auch die Label in der Karte richtig sehen möchten, ist nur verständlich. Sag bitte einfach was wir machen sollen. Herzlichen Gruß --80.187.100.94 19:46, 19. Feb. 2018 (CET)Beantworten
Zunächst mal als allgemeine Information zu mir: Ich bin nicht der Wart des Tools osm4wiki (das ist Plenz), sondern nur jemand der sich etwas mit dem von mir angeführten Kodierungsproblem im Tool kmlexport beschäftigt hat.
Die Punkte, die Du – wie oben von Dir beschrieben – bereits an anderer Stelle dargestellt hast, sind dort gut aufgehoben und sollten meiner Meinung nach auch dort diskutiert und entschieden werden.
Was Deinen Punkt „zu den Wracks finden sich teilweise mehrere Positionsangaben ... die Position des Wracks und diverse "Events" => z.B. Untergang, Versenkung, torpediert, und so weiter. ob das Sinn (besonders bei nahe zusammen liegenden Positionen) macht ist fraglich. Check dazu: Positionen zur Titanic“ angeht, so ist dies Sache der Autoren der jeweiligen Artikel zu den einzelnen Wracks und sollte meines Erachtens in den Diskussionsseiten der einzelnen Artikel diskutiert und entschieden werden.
Dein Punkt „Die OSM-Version mit der Liste links ist schön, weil man per Wracknamen (+crtl-f) die Postition schnell auf der Karte finden kann. Allerdings ist die Reaktion auf den Mauszeiger bei der OSM-Kartenversion etwas zu sensibel ... die Karten(-auschnitte) springen zu schnell weg.“ beziehungsweise „Man kann sich sehr gut darauf einigen nur die OSM-Version zu nutzen. Allerdings ist die Maussteuerung deutlich zu nervös (Firefox 58.0.2 (64bit), Linuxmint, Kernel 4.10.0-42). Beim Wechsel von Liste zur Karte oder Karte zur Liste ist meist wieder alles verschoben ... der Karten-Zoom macht auch grad was er will.“ ist eine Angelegenheit des Tools osm4wiki, diesbezüglich ist dessen Wart Benutzer:Plenz gefragt; auf dieser Seite bist Du mit diesem Problem aber schon am richtigen Ort.
Was das Kodierungsproblem im Tool kmlexport angeht, so hat Para im Phabricator unter phabricator:T92963#2265237 erläutert, dass er da nicht mehr viel Arbeit reinstecken möchte. Das Problem ist unter phabricator:T187625 beschrieben, harrt aber noch einer Bearbeitung. Bislang ist auch unklar, warum die Schriftzeichen – ’ „ “ č ć š (und vermutlich noch einige andere, insbesondere in drei Bytes kodierte Schriftzeichen [Anmerkung: das erste der aufgelisteten Schriftzeichen ist ein Halbgeviertstrich (–), das Bindestrich-Minus (-) sollte kein Problem bereiten]) im Wert des Parameters name der Vorlage:Coordinate oftmal das Kodierungsproblem auslösen (durch das dann auch einige andere Schriftzeichen in osm4wiki falsch dargestellt werden) es aber auch Beispiele gibt in denen die Zeichen „ “ š das Problem nicht auslösen (z. B š in cs:Seznam chráněných území v okrese Havlíčkův Brod oder „ “ in den Artikeln Admiral Nachimow (1885), City of Rio de Janeiro, HMS Swordfish (61S), HMS Umpire (N82), HMS Vandal (P64), Ostmark (Schiff, 1936)). Daraus folgt: in den Fällen, in denen diese Schriftzeichen das Problem nicht auslösen, sollten sie stehen bleiben, es sei denn es besteht ein inhaltlicher Grund, den Wert des Parameters name zu ändern; Wie bereits erwähnt stoßen „normale“ Nutzer nur dann auf das Problem, wenn in der Seite, in der die Vorlage:Coordinate in den Wikitext eingetragen ist, auch die Vorlage:All Coordinates oder die Vorlage:Linked Coordinates durch Eintrag in den Wikitext eingebunden ist. (Nicht ausgelöst wird das Problem, wenn die Vorlage:All Coordinates in einer der Kategorie-Seiten eingebunden ist in die die betreffende Seite eingeordnet ist, ebensowenig wird das Problem ausgelöst, wenn die Vorlage:Linked Coordinates in einer anderen Seite eingebunden ist und das über sie aufgerufene Tool die betreffenden Seite in seiner Ergebnisliste aufführt. Im davon unabhängigen Tool GeoHack gibt es ebenfalls kein Kodierungsproblem.) Gibt es in einer Seite keine solche Einbindung der Vorlage:All Coordinates oder der Vorlage:Linked Coordinates muss man sich bezüglich des Problems demnach auch keine Gedanken machen; in allen anderen Fällen ist die Vorlage:All Coordinates oder die Vorlage:Linked Coordinates in eine Seite eingebunden, muss man sich entscheiden: entweder man verwendet das typographisch korrekte Schriftzeichen, das im GeoHack ja auch korrekt dargestellt wird, und akzeptiert dafür, dass im osm4wiki einige Schriftzeichen falsch dargestellt werden und die Anwendung googlmaps-proxy des Tools wp-world gar nicht funktioniert, wie dies z. B. im den Artikel Liste der Seen in Bayern (oder in den Artikeln cs:Seznam kostelů v Brně und cs:Středověké památky v Kosovu der cs-Wikipedia, in der das Problem jedoch eine etwas andere Ursche hat) der Fall ist (jeweils auf den „OSM“- beziehungsweise den „Google“-Link in der Artikelseite klicken), oder man verzichtet (in den Fällen, in denen das Kodierungsproblem auftritt) auf die alle Schriftzeichen die nicht im Unicodeblockes Basis-Lateinisch (U+0000–U+007F) oder im Unicodeblockes Lateinisch-1, Ergänzung (U+0080–U+00FF) stehen (also auf Schriftzeichen wie z. B. den Halbgeviertstrich (–), den Geviertstrich (—) oder ’ „ “ č ć š). , wie z. B. in Im Artikel Albatros (Schiff, 1926) z. B. ist zwar keine der betroffenen Vorlagen eingebunden, da in diesem Artikel aber wo statt der typographischen Anführungszeichen und das ASCII-Zeichen " (das unmittelbar auf der Tastatatur vorhanden ist) verwendet wird, würde bei der Einbindung der Vorlage:All Coordinates das Problem nicht auftauchen, siehe: https://tools.wmflabs.org/osm4wiki/cgi-bin/wiki/wiki-osm.pl?project=de&article=Albatros%20(Schiff,%201926) und https://tools.wmflabs.org/wp-world/googlmaps-proxy.php?page=http://tools.wmflabs.org/kmlexport?article=Albatros_(Schiff,_1926)%26project=de%26usecache=0&output=classic. --X:: black ::X (Diskussion) 01:10, 20. Feb. 2018 (CET), ergänzt 01:27, 20. Feb. 2018 (CET), korrigiert 01:44, 20. Feb. 2018 (CET), erweitert 10:29, 20. Feb. 2018 (CET) und 11:28, 20. Feb. 2018 (CET), korrigiert 14:21, 20. Feb. 2018 (CET) und 18:27, 22. Mär. 2018 (CET)Beantworten
Au weia ... zuallererst einen (ichkanngarsagenwie) dollen Dank für Deine ausführliche Antwort. Du hast es nicht "mal eben so geschrieben" sondern Dich tiefergehend mit den beschriebenen Problemen befasst. Wenn das mit den "Mauszickereien" behoben werden kann wäre es toll ... und wenn Du das mit Plenz besprechen kannst ebenso. Du merkst schon, dass ich eigentlich nur diese tolle Toos für den "Normaloautor" besser nutzbar machen will? Pittimann hat sich zum Beispiel "sowas von" gefreut, als ich ihm den Tip zu Karten seiner vielgeliebten Bergwerke liefern konnte ;-) Also nochmals vielen vielen Dank für Deinen Einsatz ... das Tool ist super und wenn konstruktive Kritik hilft, es besser zu machen freuen wir uns alle. LG --80.187.100.231 13:31, 22. Feb. 2018 (CET) P.S. Events/Landmarks etc. werden vielleicht pragmatisch gelöst. Der verlässliche Transfer der Inhalte von |name= xyz| bleibt natürlich wichtig. Als "Softie" der "uralten Garde" würde ich empfehlen den Inhalt des Feldes ohne Betrachtung 1:1 zu übernehmen und die Verknüpfungen über andere geeignete Datenbankeinträge herzustellen. :-)Beantworten
Plenz hat erst kürzlich am Ende des Diskussionsabschnittes Benutzer Diskussion:Plenz#osm4wiki tool does not work for some pages und in der Mitte des Diskussionsabschnittes Benutzer Diskussion:Plenz/OSM for Wiki#Kodierungsproblem bei OSM for Wiki angekündigt, sich um zwei andere Probleme in osm4wiki kümmern zu wollen, dafür aber Zeit zu brauchen. Da diese Seite eine Unterseite seiner Benutzerseite ist, gehe ich davon aus, dass er Deinen Beitrag lesen wird und, wenn er Zeit dazu hat, gegebenenfalls auf Deine Ausführungen zu dem zu sensiblen Mauszeiger (und gegebenenfalls vorhandenen Zoom-Problemen (???)) antworten wird.
Was den verlässlichen Transfer der Inhalte von name angeht, so kann Plenz zwar, durch Änderungen im seinem Tool osm4wiki, erreichen, dass osm4wiki die Inhalte von name-Tags in korrekten KML-Dateien, die direkt über den Parameter kml in osm4wiki geladen werden, auch wiedergibt – für eine korrekte Kodierung der name-Tags in jenen KML-Dateien, die ein anderes Tool (derzeit das Tool kmlexport)  – auf die entsprechende Anfrage von osm4wiki hin – aus den Geokoordinaten der von osm4wiki übergebenen Wikipedia-Seite (Artikelseite, Kategorieseite oder andere Seite) erstellt, kann jedoch nur dieses die KML-Datei erstellende Tool sorgen. Dazu müsste entweder das Tool kmlexport (Projektseite, Tool account) verbessert, durch ein neu zu schaffendes Tool ersetzt oder – sofern dies zulässig ist oder wird – geforkt und verbessert werden. Siehe dazu wikitech:User talk:Para#License and publish code so you can get some help with maintenance? und phabricator:T92963 insbesondere ab phabricator:T92963#2264687. --X:: black ::X (Diskussion) 10:56, 23. Feb. 2018 (CET), korrigiert 11:00, 23. Feb. 2018 (CET)Beantworten
Du schriebst: „Anfangs habe ich es mit der Entfernung von |article:/| versucht, was teilweise geholfen hat.“ War das Problem da auch, dass bei der Benutzung von osm4wiki Fehler bei der Dekordierung von Schriftzeichen auftraten und die Anwendung googlmaps-proxy des Tools wp-world nicht funktionierte, oder war das Problem ein anderes? Falls es das gleiche Problem war, kannst Du noch mitteilen, bei welchen Artikeln (bzw. welchen Artikelversionen) die Entfernung von |article:/| geholfen hat? --X:: black ::X (Diskussion) 13:58, 24. Feb. 2018 (CET)Beantworten

Pole

[Quelltext bearbeiten]

Hallo Plenz, vielen vielen Dank, dass Du Dich um die Wartung und Optimierung Deines sehr hilfreichen und nützlichen Tools kümmerst. Mir ist klar, dass bei der von osm4wiki verwendeten OSM-Karte die Positionierung/Darstellung von Markern für die Koordinaten der Pole zwangsläufig Probleme bereiten muss. Beim Südpol ist mir diesbezüglich allerdings ein besonderes Problem aufgefallen. Nutzt man osm4wiki für dessen Artikelseite (https://tools.wmflabs.org/osm4wiki/cgi-bin/wiki/wiki-osm.pl?article=S%C3%BCdpol&project=de), und zoomt man auf der Karte per Klick auf − raus, so erscheint ein Markerpaar (Paar wegen doppelter Verlinkung derselben Koordinate), je nach Zoomstufe, westlich von Afrika, in Afrika oder noch ganzwoanders, das – wenn man den Mauszeiger auf einen der Marker positioniert – in der Liste durch Hervorhebung als Geographischer Südpol ausgegeben wird. Positioniert man den Mauszeiger hingegen auf einen der entsprechenden Listeneinträge, so wird die „Südpollinie“ der Karte in den Mittelpunkt geschoben zugleich aber der jeweilige der weiter oben gelegenen Marker hervorgehoben, sofer er denn noch innerhalb des auf dem Bildschirm angezeigten Kartenausschnittes liegt. Beim Nordpol hingegen wird kein Marker angezeigt, siehe: https://tools.wmflabs.org/osm4wiki/cgi-bin/wiki/wiki-osm.pl?article=Nordpol&project=de. Das Probem hat vermutlich auch zu diesem Diskussionsbeitrag geführt. --X:: black ::X (Diskussion) 15:39, 19. Feb. 2018 (CET), korrigiert 15:40, 19. Feb. 2018 (CET)Beantworten

Ein anderes Zeichenkodierungsproblem

[Quelltext bearbeiten]

Hallo Plenz, habe ein anderes Problem mit der Zeichenkodierung in osm4wiki (OSM for Wikipedia) entdeckt, dass bei Verwendung des Tools wp-world/googlmaps-proxy.php nicht auftritt. Es könnte daher seine Ursache in osm4wiki haben:
In https://tools.wmflabs.org/osm4wiki/cgi-bin/wiki/wiki-osm.pl?project=de&article=Liste_der_Kunstwerke_im_öffentlichen_Raum_in_Graz/Andritz (wo das aus dem Tool kmlexport bekannte Zeichenkodierungsproblem nicht auftritt) liegt hinter der Zeile „Trink-Brunnen, Grazer Straße 34e“ ein Link mit der URL
https://de.wikipedia.org/wiki/Liste_der_Kunstwerke_im_%C3%B6ffentlichen_Raum_in_Graz/Andritz#Trink-Brunnen,_Grazer_Stra%EF%BF%BDe_34e . Der URL müsste aber
https://de.wikipedia.org/wiki/Liste_der_Kunstwerke_im_%C3%B6ffentlichen_Raum_in_Graz/Andritz#Trink-Brunnen,_Grazer_Stra%C3%9Fe_34e lauten (statt %EF%BF%BD müsste %C3%9F stehen, um das Schriftzeichen ß im Wort Straße in korrekter Weise zu URL-kodieren), nur dann würde der Link auch tatsächlich – wie beabsichtigt – auf den vorhandenen Anker zeigen und springen, und nicht nur auf Seitenebene funktionieren. In https://tools.wmflabs.org/wp-world/googlmaps-proxy.php?page=http://tools.wmflabs.org/kmlexport?article=Liste_der_Kunstwerke_im_%C3%B6ffentlichen_Raum_in_Graz/Andritz%26project=de&usecache=0&output=classic funktioniert der Link korrekt. Das Problem tritt in gleicher Weise auch in der Seite https://tools.wmflabs.org/osm4wiki/cgi-bin/wiki/wiki-osm.pl?project=de&article=Liste_der_denkmalgesch%C3%BCtzten_Objekte_in_Eibiswald auf, in der der Link hinter „Fundstelle (Latènezeit) und Grabhügel beim Aichberger, Aichberg“ auf
https://de.wikipedia.org/wiki/Liste_der_denkmalgesch%C3%BCtzten_Objekte_in_Eibiswald#Fundstelle_(Lat%EF%BF%BDnezeit)_und_Grabh%EF%BF%BDgel_beim_Aichberger,_Aichberg , statt auf
https://de.wikipedia.org/wiki/Liste_der_denkmalgesch%C3%BCtzten_Objekte_in_Eibiswald#Fundstelle_(Lat%C3%A8nezeit)_und_Grabh%C3%BCgel_beim_Aichberger,_Aichberg zeigt.

Anders gelagert ist das Problem, das in https://tools.wmflabs.org/osm4wiki/cgi-bin/wiki/wiki-osm.pl?project=de&article=Liste_der_denkmalgesch%C3%BCtzten_Objekte_in_Eibiswald bei dem hinter dem Text „Kruzifix/Kreuz, "Kreuzigungsgruppe", bei Hörmsdorf 23“ liegenden Link besteht: dieser weist auf
https://de.wikipedia.org/wiki/Liste_der_denkmalgesch%C3%BCtzten_Objekte_in_Eibiswald#Kruzifix/Kreuz,_ statt auf
https://de.wikipedia.org/wiki/Liste_der_denkmalgesch%C3%BCtzten_Objekte_in_Eibiswald#Kruzifix/Kreuz,_%22Kreuzigungsgruppe%22,_bei_H%C3%B6rmsdorf_23 wird also vor dem Zeichen "abgeschnitten. Dieses Problem tritt gleichermaßen auch in https://tools.wmflabs.org/wp-world/googlmaps-proxy.php?page=http://tools.wmflabs.org/kmlexport?article=Liste_der_denkmalgesch%C3%BCtzten_Objekte_in_Eibiswald%26project=de&usecache=0&output=classic auf, was eine Verursachung durch das Tool kmlexport nahelegt, aber nicht beweist. Kannst Du eindeutig feststellen, in welchem Tool das Problem entsteht? --X:: black ::X (Diskussion) 00:13, 21. Mär. 2018 (CET), erweitert 20:32, 28. Mär. 2018 (CEST), korrigiert 12:25, 6. Apr. 2018 (CEST)Beantworten

Mobilgeräte

[Quelltext bearbeiten]

Hallo, danke für dieses Tool. Schön wäre folgendes für Mobilgeräte (z. B. Android Chrome/Firefox):

  • Reaktion auf Antippen eines Markers auf der Karte
  • Anzeige des aktuellen Standorts

Vielleicht lässt sich das ja machen :) Gruß --dealerofsalvation 20:46, 24. Sep. 2018 (CEST)Beantworten

Sometimes kmlexport gets malformed parameter

[Quelltext bearbeiten]

@Plenz: Hello, sometimes kmlexport gets malformed project parameter "lang'A" from your tool. It happens cca once in 24 hours (1 request of 17 000 reqests yesterday), therefore it is not much important. If you would like to know more, see the following log entries:

error.log
DBI connect('jaawiki_p:jaawiki.labsdb:3306','s52168',...) failed: Unknown MySQL server host 'jaawiki.labsdb' (-2) at /data/project/kmlexport/public_html//kmlexport.pl line 519.
access.log
172.16.6.39 tools.wmflabs.org - [12/Feb/2019:15:42:37 +0000] "GET /kmlexport?project=ja'A=0&article=Category:%E6%97%A5%E6%9C%AC%E3%81%AE%E5%87%BA%E7%89%88%E7%A4%BE HTTP/1.1" 301 0 "-" "Wikipedia-OSM tool by Plenz"
172.16.6.39 tools.wmflabs.org - [12/Feb/2019:15:42:38 +0000] "GET /kmlexport/?project=ja'A=0&article=Category:%E6%97%A5%E6%9C%AC%E3%81%AE%E5%87%BA%E7%89%88%E7%A4%BE HTTP/1.1" 200 459 "-" "Wikipedia-OSM tool by Plenz"
requests.log
Tue Feb 12 15:42:38 2019	jaa.wikipedia.org/wiki/Category:日本の出版社

The page on jawiki seems to be working correctly. In error.log I can find mainly "enawiki", "jaawiki" and "commonsawiki" entries. It can be some random network error too. I was just curious and this is what I've found out. --Dvorapa (Diskussion) 01:41, 13. Feb. 2019 (CET)Beantworten

OSM4wiki not working

[Quelltext bearbeiten]

Hi, osm4wiki was behaving badly and was temporarily shut down by Toolforge project maintainers, see T220164. --Dvorapa (Diskussion) 10:27, 6. Apr. 2019 (CEST)Beantworten

Error report

[Quelltext bearbeiten]

Hello Plenz !

I report you that Japanese characters are not displayed properly on OSM_for_Wiki, and ask you to fix it.

I show you the Japanese article ja:逓信省印旛地方航空機乗員養成所 and map page

The letter 滑走路(01/19) should be displayed as 滑走路(01/19)

I use GOOGLE Chrome.

Thank you.--Flight 736 (Diskussion) 07:18, 8. Mai 2019 (CEST)Beantworten

osm4wiki Ebenen-Parameter

[Quelltext bearbeiten]

Hallo Plenz, bei osm4wiki scheint der Ebenen-Parameter nicht mehr zu funktionieren. Egal was ich z.B. bei [5] für l angebe, es werden immer nur die Artikel der 1. Ebene angezeigt (also nicht der Unterkategorien). Außerdem gibt es ein Problem bei der Zeichenkodierung, siehe z.B. [6].--Sinuhe20 (Diskussion) 09:13, 25. Mai 2019 (CEST)Beantworten

+1 Probleme mit der Zeichencodierung habe ich auch festgestellt. Kartenauswahl:

und so weiter. Wäre schön wenn das gefixt werden könnte. LG --Thombansen (Diskussion) 13:31, 3. Jun. 2019 (CEST)Beantworten

@Plenz: Bitte die Probleme so schnell wie möglich beheben, osm4wiki ist über die Vorlage:All Coordinates in tausenden von Artikeln und Kategorien eingebaut.--Sinuhe20 (Diskussion) 09:09, 13. Jun. 2019 (CEST)Beantworten

Ich bedaure, aber zur Zeit bin ich auf einer langen Reise und bin vermutlich (!) erst im August wieder zu Hause. Ich habe nur mein Notebook mitgenommen, aber die Zugangsdaten und Passwörter für das Projekt sind auf meinem PC zu Hause.
Die Sache mit den Ebenen hatte ich absichtlich abgeschaltet, weil das Programm vor einiger Zeit als Speicherfresser aufgefallen war und von den Admins stillgelegt worden war. Warum so viel Speicher gebraucht wurde, hatte ich nicht herausfinden können und nahm an, dass bei zu vielen Ebenen vielleicht hunderte oder tausende von Koordinaten dargestellt werden könnten und dass diese Anzahl das System überlastet.
Als ich dieses Programm schrieb, dachte ich auch nur an Koordinaten, die in einem Artikel vorkommen. Maximal an übereordnete Artikel wie Jahreszahlen-Artikel, bei denen die Verlinkung von einer (1) Ebene sinnvoll ist. Aber Kategorien? Wer braucht denn so etwas? Und ganz ehrlich: unter einem Problem, das schnellstens gefixt werden muss, verstehen ich etwas, wo die Leser sich massenweise beschweren und über die grottenschlechte Wikipedia meckern. Ist das bereits irgendwo passiert?
Der einzige, der sich mit meinem Programm beschäftigt hat, ist Kolossos. Vielleicht findet er die Stelle, wo ich die Ebenen ausgeschaltet habe. Allerdings wäre dann die Frage, ob wieder ein hoher Ressourcenverbrauch auftritt. --Plenz (Diskussion) 19:56, 23. Jun. 2019 (CEST)Beantworten
Hallo Plenz, also ich finde die Funktion mit den Unterkategorien schon sehr nützlich, z.B. wenn ich nach geographischen Objekten in einer Region suche. Könnte man dein Programm nicht mit Petscan kombinieren? Das Tool ist sehr schnell beim Finden von Artikeln in Kategoriebäumen. Zur Not könnte man ja auch eine Maximalanzahl für die angezeigten Artikel als Standard festlegen, z.B. 200, die man aber individuell verändert könnte. Vielleicht wird so die Speicherlast dann etwas verringert.--Sinuhe20 (Diskussion) 07:54, 24. Jun. 2019 (CEST)Beantworten
Hi, Ihr Lieben! Danke @Plenz, Kolossos: für das Projekt, und @Sinuhe20: für den Bugreport! Auch ich finde den Anwendungsfall mit den Unterkategorien durchaus wichtig, bspw. bei Kategorie:Osnabrück werden nun entgegen der Erwartung lediglich die Koordinaten der wenigen Artikel eingeblendet, die zufällig in keine der Unterkategorien passen, eine recht nutzlose Sammlung, was dieser Parameter eigentlich mit Klick auf "++" beheben sollte. Auch wenn man's spezifischer angeht, etwa in Kategorie:Bauwerk in Osnabrück ergibt sich mit deren Unterkategorien exakt dasselbe Problem. Wenn ich bspw. eine Karte des Osnabrücker Stadtteils Innenstadt betrachten möchte mit allen dort georefenzierten WP-Artikeln, dann hilft mir Kategorie:Innenstadt (Osnabrück) nicht weiter, weil dadurch die in anderen Hierachiezweigen verlinken Artikel nicht angezeigt werden, sondern diesen Zweck würde nur Kategorie:Osnabrück mit l=0 erfüllen. Ohne diesen Parameter ist die Kategorienhierarchie in osm4wiki völlig unzweckmäßig abgebildet, und mit den Links OSM (+1, +2, ++) irreführend. Ich würde stark annehmen, dass der Ressourcenverbrauch kaum durch hunderte verschiedene an OSM zu übergebende Koordinaten belastet wird, sondern eher durch die Durchsuchung der Unterkategorien, was aber noch durch Messung bestätigt werden sollte. Falls zutreffend, wären Caching/Petscan vmtl. zielführende Ansatzpunkte. LG Kevin Price (Diskussion) 00:16, 14. Jul. 2019 (CEST)Beantworten

Issues

[Quelltext bearbeiten]

Still the result is full of broken diacritics, see e.g. [7]. Also kml files are not working anymore: [8]

Is there any chance to fix any of these? --Dvorapa (Diskussion) 20:57, 27. Dez. 2019 (CET)Beantworten

OSM bei Karte mit allen Koordinaten Liste der Stolpersteine in Frankfurt am Main

[Quelltext bearbeiten]

Hallo, ich bin von zwei Kollgen bei Wiki auf dich verwiesen worden. Ich habe ein kleines, großes Problem. Wenn ich die Karte per Tool OSM4WIKI bei Liste der Stolpersteine in Frankfurt am Main anfordere, so bekomme ich einen Stand der eingetragenen Stolpersteine von ca. 2010 angezeigt. (geteset bei Altstadt). Kannst du dort Helfen?
Altstadt mit OSM
--Vielen Dank und Grüße Woelle ffm (Uwe) (Diskussion) 09:28, 28. Feb. 2021 (CET)Beantworten

Projekt für außerhalb von Wikipedia

[Quelltext bearbeiten]

Hallo Plenz, WMAT betreibt das österreichische RegiowikiAT - ist es möglich, auch hier dein Tool einzusetzen und wie? -- danke und lg -- K@rl Aus dem Babyelefanten ist ein Erwachsener geworden 16:47, 13. Mai 2021 (CEST)Beantworten

Errors at en:Hatfield Chase

[Quelltext bearbeiten]

Clicking on "Map all coordinates using: OpenStreetMap" at Chase results in this page, where "#1" and "Tunnel Pits region:GB type:city" are shown at the top of the list of places. Is this problem caused by this tool, or is there something that needs to be fixed at en.WP? Jonesey95 (Diskussion) 15:39, 7. Jun. 2022 (CEST)Beantworten

List of rivers of Burundi, mouse click on marker

[Quelltext bearbeiten]

I have added w:en:template:GeoGroup to w:en:List of rivers of Burundi. It is very useful, and when there are many markers the collapsed groups are useful in preventing too much clutter on the map. It does not work so well on a phone. Maybe there is some way to float the sidebar above or below the map.

You ask, "what do you expect from this mouse click?" when a user clicks on a marker. Two answers:

  • With some markers, the corresponding entry is visible in the sidebar, and when I hover over the marker it is highlighted in green. With others the entry is not visible in the sidebar, and nothing happens. With these, I would expect a click to make the scrollbar scroll down to make the marker highlighted and visible. But I would prefer the scroll to happen automatically when I hover over the marker, without the need to click.
  • If automatic scrolling was implemented, I would like a click on a marker to bring up a text box with an excerpt from the article. It would hold the formatted text that surrounds the place where the coordinates are defined, with a link to the nearest heading or anchor in the article before the coordinates. I have no idea how difficult this would be.

Again, this is a really useful tool. Thanks, --Aymatth2 (Diskussion) 00:53, 2. Sep. 2024 (CEST)Beantworten