Datei Diskussion:HmProfil.jar.kmz: Unterschied zwischen den Versionen
3mk (Diskussion | Beiträge) |
3mk (Diskussion | Beiträge) |
||
(15 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
Zeile 39: | Zeile 39: | ||
:::: Aber das ist wohl wirklich ein schwieriges Thema. Auf einer 5 km langen Geraden sind Punkte alle 100 m bereits sinnfrei. Man könnte natürlich zusätzlich zum Abstand noch den Kurs ausrechnen... Mit der Transparenz könnte man auch noch andere nette Dinge treiben: | :::: Aber das ist wohl wirklich ein schwieriges Thema. Auf einer 5 km langen Geraden sind Punkte alle 100 m bereits sinnfrei. Man könnte natürlich zusätzlich zum Abstand noch den Kurs ausrechnen... Mit der Transparenz könnte man auch noch andere nette Dinge treiben: | ||
::::: Im Prinzip hast du recht, aber wegen der speziellen Berechnungsmethode der POI-Abstände zum Track gibt es da Probleme mit zuwenig Punkten auf geraden Stecken. Es wird nämlich der POI-Abstand zum nähesten Trackpunkt berechnet und nicht das Lot auf den Trackvektor gefällt. Das betrifft sowohl die Perl- als auch Java-Programme. --[[Benutzer:Jmages|Jürgen]] ([[Benutzer Diskussion:Jmages|Diskussion]]) 09:37, 28. Feb. 2015 (CET) | |||
:::: [[Datei:Etsch_temp_trans.png]] | :::: [[Datei:Etsch_temp_trans.png]] | ||
:::: BTW: In den Höhenprofilen gibt es oft eine Punktedichte, die zwar nicht zu einer weißen Lücke, aber immerhin zu einer "ausgefransten" unteren Kante reicht. Ich hoffe, Du weißt, was ich meine. Ist das auch ein Feature? Wenn nein, bekommst Du das Problem mit "BasicStroke.CAP_BUTT" statt "BasicStroke.CAP_ROUND" in Zeile 133 von Profil.java in den Griff. | :::: BTW: In den Höhenprofilen gibt es oft eine Punktedichte, die zwar nicht zu einer weißen Lücke, aber immerhin zu einer "ausgefransten" unteren Kante reicht. Ich hoffe, Du weißt, was ich meine. Ist das auch ein Feature? Wenn nein, bekommst Du das Problem mit "BasicStroke.CAP_BUTT" statt "BasicStroke.CAP_ROUND" in Zeile 133 von Profil.java in den Griff. | ||
::::: Ist mir noch nicht aufgefallen, wäre aber natürlich eine Verbesserung. | |||
:: — Zum hinterlegten Grid: Ich würde dem gern ein möglichst einheitliches Aussehen verpassen. Nach oben und nach rechts variiert das gern von Strecke zu Strecke. Gibt es vielleicht weitere Wünsche (von wem auch immer), die an dieser Stelle mit einfließen könnten? Gab es hilfreiche Diskussionen zu den Höhenprofilen? | :: — Zum hinterlegten Grid: Ich würde dem gern ein möglichst einheitliches Aussehen verpassen. Nach oben und nach rechts variiert das gern von Strecke zu Strecke. Gibt es vielleicht weitere Wünsche (von wem auch immer), die an dieser Stelle mit einfließen könnten? Gab es hilfreiche Diskussionen zu den Höhenprofilen? | ||
Zeile 59: | Zeile 63: | ||
:::: Habs gefunden. Also offenbar nach wie vor keine Freischaltung zum Hochladen von SVGs. Das meintest Du wohl mit fehlender Unterstützung. Schade. Gibt es eigentlich die Möglichkeit, innerhalb des Wikis SQL-DBs anzulegen? Gute Nacht --[[Benutzer:3mk|Martin]] ([[Benutzer Diskussion:3mk|Diskussion]]) 23:42, 27. Feb. 2015 (CET) | :::: Habs gefunden. Also offenbar nach wie vor keine Freischaltung zum Hochladen von SVGs. Das meintest Du wohl mit fehlender Unterstützung. Schade. Gibt es eigentlich die Möglichkeit, innerhalb des Wikis SQL-DBs anzulegen? Gute Nacht --[[Benutzer:3mk|Martin]] ([[Benutzer Diskussion:3mk|Diskussion]]) 23:42, 27. Feb. 2015 (CET) | ||
Hallo Martin, ich antworte hier mal pauschal, weil es sonst zu unübersichtlich wird: Die transparente Farbe finde ich genial, weil man so das Grid noch sehen kann. Was die Erweiterung von MediaWiki durch neue Module angeht, sehe ich seitens der Forumsbetreiber leider wenig Spielraum. Das derzeit dringendste Wiki-Problem, nämlich der Umlautfehler (siehe [[Benutzer_Diskussion:Maze#Dateien_mit_Umlauten_lassen_sich_weder_hochladen_noch_l.C3.B6schen_noch_umbenennen|hier]]), ist jetzt seit einem dreiviertel Jahr noch nicht gefixt. --[[Benutzer:Jmages|Jürgen]] ([[Benutzer Diskussion:Jmages|Diskussion]]) 08:40, 28. Feb. 2015 (CET) | |||
: Hallo Jürgen. Bin in Eile (Fahrrad-km statt Java), deswegen nur kurz: die transparente Fläche geht nicht mit dem bisherigen Strich-Ansatz, da mehrere transparente Striche übereinander auch wieder eine satte Farbe ergeben (siehe qualitativen Eindruck vom Nachbesserungsbedarf). Was mich interessiert: die Abstandsberechnung zu den POIs. Kannst Du mir Datei und Zeile nennen (Java bitte!), wo das stattfindet. Ich finde mich im Quellcode noch nicht so gut zurecht :( Die Probleme mit den Umlauten habe ich nicht vergessen. Allerdings steht noch die angekündigte GM-Änderung im Raum und ich habe das Gefühl, dass sich das Umlaut-Problem dann von selbst erledigt — weil man nämlich zu OSM wechselt... --[[Benutzer:3mk|Martin]] ([[Benutzer Diskussion:3mk|Diskussion]]) 11:06, 28. Feb. 2015 (CET) | |||
:: Die Berechnung ist hier: class GPS_Track : public int getClosestPoint (GeoPoint placeMark) | |||
:: Die Umlautproblematik bezieht sich leider nicht nur auf GM sondern auch auf den Dateiupload. Gute Fahrt, [[Benutzer:Jmages|Jürgen]] ([[Benutzer Diskussion:Jmages|Diskussion]]) 11:34, 28. Feb. 2015 (CET) | |||
Ein neuer Layout-Vorschlag mit der Bitte um Kommentare. --[[Benutzer:3mk|Martin]] ([[Benutzer Diskussion:3mk|Diskussion]]) 22:40, 2. Mär. 2015 (CET) | |||
[[Datei:Etsch temp2.png|miniatur|links|Etsch]] [[Datei:Colchester-Dover_temp.png|miniatur|links|Colchester-Dover]] | |||
: Gefällt mir gut. Die Trackpunktlücken sind aber jetzt weg, oder? Naja, aber die Transparenz ist schon ein schönes Feature! Dank + Gruß, [[Benutzer:Jmages|Jürgen]] ([[Benutzer Diskussion:Jmages|Diskussion]]) 07:38, 3. Mär. 2015 (CET) | |||
:: Auf die Trackpunktlücken komme ich später noch zurück, das ist alles noch work in progress (bin GPS-Neuling und muss mich erst ein wenig einarbeiten). Derzeit geht es mir um Fragen wie: Ist das Grid nicht überladen? Sollten 100er-Linien anders dargestellt werden? Was hat sich der erfahrene Radreisende hinsichtlich der Höhenprofile schon immer gewünscht? Größere Flüsse? | |||
Z.B. kann man sich eine Strategie zum Ausrichten der Ortsbezeichnungen überlegen: | |||
[[Datei:Etsch temp3.png|Ort]] | |||
Gruß und bis demnächst (habe heute wegen des Lehrerstreiks in Berlin die Kinder an der Backe) --[[Benutzer:3mk|Martin]] ([[Benutzer Diskussion:3mk|Diskussion]]) 08:03, 3. Mär. 2015 (CET) | |||
Doch weniger Streik als gedacht, deswegen tapezier' ich hier mal: | |||
[[Datei:Etsch temp4.png]] | |||
Oben: Lücken ab 1000m Abstand zwischen zwei Track-Punkten, Mitte: 500m, unten: 250m. Zur Sinnhaftigkeit dieser Bewertungsmethode hatte ich mich ja schon geäußert. Gruß --[[Benutzer:3mk|Martin]] ([[Benutzer Diskussion:3mk|Diskussion]]) 17:00, 3. Mär. 2015 (CET) | |||
[[Datei:Europa-Radweg R1 750.png|miniatur|links]] | |||
Hier noch der R1 mit Lücken ab 750m. Erstaunlich ist die Qualität in Berlin... --[[Benutzer:3mk|Martin]] ([[Benutzer Diskussion:3mk|Diskussion]]) 18:00, 3. Mär. 2015 (CET) | |||
== Umlaut-Problematik == | |||
Ich habe die Datei "Test_Umlaute_äöüß.jpg" hochgeladen. Beim eigentlichen Hochladevorgang gab es keine Fehlermeldung. Anschließender Aufruf der Datei liefert einen 404er (The requested URL /images/Test_Umlaute_äöüß.jpg was not found on this server). Hast Du FTP-Zugriff auf die Dateien? Wenn ja, wie sieht der Dateiname direkt auf dem Server aus? --[[Benutzer:3mk|Martin]] ([[Benutzer Diskussion:3mk|Diskussion]]) 15:32, 28. Feb. 2015 (CET) | |||
: Den 404er bekomme ich auch. FTP-Zugang haben nur Maze und Zak. Seltsamerweise konnte ich die Datei löschen, was bisher nicht möglich war. --[[Benutzer:Jmages|Jürgen]] ([[Benutzer Diskussion:Jmages|Diskussion]]) 18:28, 28. Feb. 2015 (CET) | |||
: Der Umlautfehler ist seit dem letzten MediaWiki-Update ([[Spezial:Version|Info]]) aufgetreten. --[[Benutzer:Jmages|Jürgen]] ([[Benutzer Diskussion:Jmages|Diskussion]]) 18:37, 28. Feb. 2015 (CET) | |||
:: Von außen betrachtet liegt es an unzutreffenden Encoding-Einstellungen (Wiki und/oder DBMS (MySQL?)). Man muss aber wohl unterscheiden zwischen früher hochgeladenen Dateien mit Umlauten im Namen und späteren Uploads. | |||
:: '''Frühere Uploads''' (z.B. Weiße Elster): | |||
:: * http://maps.google.com/maps?q=http:%2F%2Fradreise-wiki.de%2Fimages%2FWei%C3%9Fe_Elster.kmz&t=p So steht's im Radfernweg unter GPS-Tracks. Dieser Link funktioniert nicht (mehr). %C3%9F ist das richtige Encoding für ein ß, der Link stimmt also also vermutlich. Trotzdem kann der Wiki-Server die Datei nicht (mehr) finden. | |||
:: * http://radreise-wiki.de/images/Wei%C3%9Fe_Elster.kmz Kein Problem. Gut, aber warum? | |||
:: * http://maps.google.com/maps?q=http:%2F%2Fradreise-wiki.de%2Fimages%2FWei%25C3%259Fe_Elster.kmz&t=p Das Encoding für ein %-Zeichen ist %25. Wenn man %C3%9F (ein ß) nochmals encoded, wird daraus %25C3%259F, und damit funktioniert es. Hier wären die Server-Logs aufschlussreich. Darin sind alle get-Anfragen aufgelistet und man kann erkennen, was Google beim Wiki-Server wirklich anfragt. | |||
:: '''Spätere Uploads''': | |||
:: * Grundproblematik: s.o. | |||
:: * http://radreise-wiki.de/images/Test_Umlaute_.jpg Die Umlaute einfach weggelassen, liefert erstaunlicherweise einen 403er (You don't have permission to access /images/Test_Umlaute_.jpg on this server). Vielleicht heißt meine hochgeladene Datei ja so!? | |||
:: * Vermutung: Im Zusammenhang mit der Verarbeitung des Dateinamens beim Upload gibt es ein Encoding-Problem. D.h., dass eine Einstellung nicht wie notwendig auf UTF-8 steht, sondern z.B. auf ISO 8859-15. Die im Namen enthaltenen Buchstaben äöüß sind UTF-8-kodiert, werden aber anders interpretiert (als ANSI ergibt sich eben der Buchstabensalat der Fehlermeldung: äöüß). | |||
:: Ich habe eben noch lokal ein Wiki installiert (Version 1.24.1), um anhand verschiedener Einstellungen das Fehlverhalten zu reproduzieren. Wenn ich da die Datei "Test_Umlaute_äöüß.jpg" hochlade, bekomme ich folgende Meldung: "Fehler beim Hochladen: Dieses Wiki unterstützt keine Dateinamen, die Sonderzeichen enthalten." — Sie werden wissen, warum. Gute Nacht --[[Benutzer:3mk|Martin]] ([[Benutzer Diskussion:3mk|Diskussion]]) 00:53, 1. Mär. 2015 (CET) | |||
:: Die Fehlermeldung "Dieses Wiki unterstützt keine Dateinamen, die Sonderzeichen enthalten." hat damit zu tun, dass ich das lokale MediaWiki unter Windows installiert habe. Bei Gelegenheit installiere ich nochmal unter Linux. --[[Benutzer:3mk|Martin]] ([[Benutzer Diskussion:3mk|Diskussion]]) 10:43, 1. Mär. 2015 (CET) |
Aktuelle Version vom 3. März 2015, 17:00 Uhr
Hallo Jürgen. Ist der Quellcode auf dieser Seite aktuell, oder gibt es eine neuere Version? Gruß von Martin --3mk (Diskussion) 09:33, 25. Feb. 2015 (CET)
- Hallo Martin. Sollte aktuell sein. Gruß, Jürgen (Diskussion) 10:21, 25. Feb. 2015 (CET)
Überarbeitete Version von Profil.java
Hallo Jürgen. Ich habe mir die Erstellung der Höhenprofile im Detail angesehen und als Diskussionsgrundlage einige Teile abgeändert:
- Die weißen Bereiche in einigen Bildern, die entstehen, wenn benachbarte GPS-Punkte zu weit auseinanderliegen, werden wohl kein Feature sein. Mit einem Polygonzug, der den orangenen Bereich beschreibt, kann das recht einfach gelöst werden. Beispiel Etsch:
- Die Höhenangaben auf der linken Seite sind meiner Meinung nach rechtsbündig hübscher. Ebenso würde ich die Kilometerangaben eher zentrieren. Das ist natürlich Geschmackssache.
- vorher:
- hinterher:
Quelltext und Jar
Du kannst Dir Profil.java ja mal ansehen und HmProfil.jar ausprobieren: Datei:Profil.zip.kmz und Datei:HmProfil mod.jar.kmz herunterladen und entpacken (zip). Aber Vorsicht: Die Namen der enthaltenen Dateien sind nicht geändert! Überschreib Dir nix.
Beste Grüße --3mk (Diskussion) 11:22, 27. Feb. 2015 (CET)
- Hallo Martin. Die weißen Bereiche sind tatsächlich ein Feature ;-) Man soll sehen, wo der Track noch Lücken hat und somit Nachbesserungsbedarf besteht. Würde ich daher lieber drinlassen. --Jürgen (Diskussion) 12:26, 27. Feb. 2015 (CET)
- Bei den Achsenbeschriftungen finde ich deine Lösung deutlich schöner. Sollten wir übernehmen. Danke, dass du dich kümmerst - hatte alle Hoffnung schon aufgegeben :-) --Jürgen (Diskussion) 12:28, 27. Feb. 2015 (CET)
- — Ab welcher Distanz zwischen zwei GPS-Punkten besteht denn Nachbesserungsbedarf? Ich meine Meter (ggf. in Relation zur Gesamtlänge), nicht Pixel oder Strichbreiten. Oder anders ausgedrückt: Was sind die (numerischen) Merkmale einer hohen/niedrigen Trackqualität?
- Schwer zu sagen. Aus der Erfahrung heraus: Solange alles Gelb ist, ist der Track ausreichend mit Punkten versorgt. Bei Lücken von 100 m und mehr fehlen Punkte.
- Wenn man ein wenig mit der Transparenz rumspielt, bekommt man einen qualitativen Eindruck vom Nachbesserungsbedarf:
- Aber das ist wohl wirklich ein schwieriges Thema. Auf einer 5 km langen Geraden sind Punkte alle 100 m bereits sinnfrei. Man könnte natürlich zusätzlich zum Abstand noch den Kurs ausrechnen... Mit der Transparenz könnte man auch noch andere nette Dinge treiben:
- Im Prinzip hast du recht, aber wegen der speziellen Berechnungsmethode der POI-Abstände zum Track gibt es da Probleme mit zuwenig Punkten auf geraden Stecken. Es wird nämlich der POI-Abstand zum nähesten Trackpunkt berechnet und nicht das Lot auf den Trackvektor gefällt. Das betrifft sowohl die Perl- als auch Java-Programme. --Jürgen (Diskussion) 09:37, 28. Feb. 2015 (CET)
- BTW: In den Höhenprofilen gibt es oft eine Punktedichte, die zwar nicht zu einer weißen Lücke, aber immerhin zu einer "ausgefransten" unteren Kante reicht. Ich hoffe, Du weißt, was ich meine. Ist das auch ein Feature? Wenn nein, bekommst Du das Problem mit "BasicStroke.CAP_BUTT" statt "BasicStroke.CAP_ROUND" in Zeile 133 von Profil.java in den Griff.
- Ist mir noch nicht aufgefallen, wäre aber natürlich eine Verbesserung.
- — Zum hinterlegten Grid: Ich würde dem gern ein möglichst einheitliches Aussehen verpassen. Nach oben und nach rechts variiert das gern von Strecke zu Strecke. Gibt es vielleicht weitere Wünsche (von wem auch immer), die an dieser Stelle mit einfließen könnten? Gab es hilfreiche Diskussionen zu den Höhenprofilen?
- Die Höhenprofile sollten standardisiert sein:
- Höhenmeter: 20 m Unterteilung (16 Pixel pro 20 m)
- Streckenlänge: 5 km Unterteilung (42 Pixel pro 5 km)
- Die Höhenprofile sollten standardisiert sein:
- Damit kann man sie besser vergleichen. Diskussionen gab es schon viele (z.B. hier).
- Danke für den Link zu Ulrichs Handmade-Höhenprofil, schöner Input! In vielem, was er schreibt, hat er absolut recht. Ich behalte das als mögliches Ziel im Hinterkopf. Fruchtbarer ist aber zunächst die schrittweise Verbesserung dessen, was heute schon problemlos läuft.
- — Irgendwo habe ich über SVG-Ansätze gelesen. Gibt es davon ein Beispiel? --3mk (Diskussion) 13:14, 27. Feb. 2015 (CET)
- Wäre interessant. Aber soweit ich weiß, kann das Wiki die nicht anzeigen. --Jürgen (Diskussion) 16:48, 27. Feb. 2015 (CET)
- Habs gefunden. Also offenbar nach wie vor keine Freischaltung zum Hochladen von SVGs. Das meintest Du wohl mit fehlender Unterstützung. Schade. Gibt es eigentlich die Möglichkeit, innerhalb des Wikis SQL-DBs anzulegen? Gute Nacht --Martin (Diskussion) 23:42, 27. Feb. 2015 (CET)
Hallo Martin, ich antworte hier mal pauschal, weil es sonst zu unübersichtlich wird: Die transparente Farbe finde ich genial, weil man so das Grid noch sehen kann. Was die Erweiterung von MediaWiki durch neue Module angeht, sehe ich seitens der Forumsbetreiber leider wenig Spielraum. Das derzeit dringendste Wiki-Problem, nämlich der Umlautfehler (siehe hier), ist jetzt seit einem dreiviertel Jahr noch nicht gefixt. --Jürgen (Diskussion) 08:40, 28. Feb. 2015 (CET)
- Hallo Jürgen. Bin in Eile (Fahrrad-km statt Java), deswegen nur kurz: die transparente Fläche geht nicht mit dem bisherigen Strich-Ansatz, da mehrere transparente Striche übereinander auch wieder eine satte Farbe ergeben (siehe qualitativen Eindruck vom Nachbesserungsbedarf). Was mich interessiert: die Abstandsberechnung zu den POIs. Kannst Du mir Datei und Zeile nennen (Java bitte!), wo das stattfindet. Ich finde mich im Quellcode noch nicht so gut zurecht :( Die Probleme mit den Umlauten habe ich nicht vergessen. Allerdings steht noch die angekündigte GM-Änderung im Raum und ich habe das Gefühl, dass sich das Umlaut-Problem dann von selbst erledigt — weil man nämlich zu OSM wechselt... --Martin (Diskussion) 11:06, 28. Feb. 2015 (CET)
- Die Berechnung ist hier: class GPS_Track : public int getClosestPoint (GeoPoint placeMark)
- Die Umlautproblematik bezieht sich leider nicht nur auf GM sondern auch auf den Dateiupload. Gute Fahrt, Jürgen (Diskussion) 11:34, 28. Feb. 2015 (CET)
Ein neuer Layout-Vorschlag mit der Bitte um Kommentare. --Martin (Diskussion) 22:40, 2. Mär. 2015 (CET)
- Gefällt mir gut. Die Trackpunktlücken sind aber jetzt weg, oder? Naja, aber die Transparenz ist schon ein schönes Feature! Dank + Gruß, Jürgen (Diskussion) 07:38, 3. Mär. 2015 (CET)
- Auf die Trackpunktlücken komme ich später noch zurück, das ist alles noch work in progress (bin GPS-Neuling und muss mich erst ein wenig einarbeiten). Derzeit geht es mir um Fragen wie: Ist das Grid nicht überladen? Sollten 100er-Linien anders dargestellt werden? Was hat sich der erfahrene Radreisende hinsichtlich der Höhenprofile schon immer gewünscht? Größere Flüsse?
Z.B. kann man sich eine Strategie zum Ausrichten der Ortsbezeichnungen überlegen:
Gruß und bis demnächst (habe heute wegen des Lehrerstreiks in Berlin die Kinder an der Backe) --Martin (Diskussion) 08:03, 3. Mär. 2015 (CET)
Doch weniger Streik als gedacht, deswegen tapezier' ich hier mal:
Oben: Lücken ab 1000m Abstand zwischen zwei Track-Punkten, Mitte: 500m, unten: 250m. Zur Sinnhaftigkeit dieser Bewertungsmethode hatte ich mich ja schon geäußert. Gruß --Martin (Diskussion) 17:00, 3. Mär. 2015 (CET)
Hier noch der R1 mit Lücken ab 750m. Erstaunlich ist die Qualität in Berlin... --Martin (Diskussion) 18:00, 3. Mär. 2015 (CET)
Umlaut-Problematik
Ich habe die Datei "Test_Umlaute_äöüß.jpg" hochgeladen. Beim eigentlichen Hochladevorgang gab es keine Fehlermeldung. Anschließender Aufruf der Datei liefert einen 404er (The requested URL /images/Test_Umlaute_äöüß.jpg was not found on this server). Hast Du FTP-Zugriff auf die Dateien? Wenn ja, wie sieht der Dateiname direkt auf dem Server aus? --Martin (Diskussion) 15:32, 28. Feb. 2015 (CET)
- Den 404er bekomme ich auch. FTP-Zugang haben nur Maze und Zak. Seltsamerweise konnte ich die Datei löschen, was bisher nicht möglich war. --Jürgen (Diskussion) 18:28, 28. Feb. 2015 (CET)
- Der Umlautfehler ist seit dem letzten MediaWiki-Update (Info) aufgetreten. --Jürgen (Diskussion) 18:37, 28. Feb. 2015 (CET)
- Von außen betrachtet liegt es an unzutreffenden Encoding-Einstellungen (Wiki und/oder DBMS (MySQL?)). Man muss aber wohl unterscheiden zwischen früher hochgeladenen Dateien mit Umlauten im Namen und späteren Uploads.
- Frühere Uploads (z.B. Weiße Elster):
- * http://maps.google.com/maps?q=http:%2F%2Fradreise-wiki.de%2Fimages%2FWei%C3%9Fe_Elster.kmz&t=p So steht's im Radfernweg unter GPS-Tracks. Dieser Link funktioniert nicht (mehr). %C3%9F ist das richtige Encoding für ein ß, der Link stimmt also also vermutlich. Trotzdem kann der Wiki-Server die Datei nicht (mehr) finden.
- * http://radreise-wiki.de/images/Wei%C3%9Fe_Elster.kmz Kein Problem. Gut, aber warum?
- * http://maps.google.com/maps?q=http:%2F%2Fradreise-wiki.de%2Fimages%2FWei%25C3%259Fe_Elster.kmz&t=p Das Encoding für ein %-Zeichen ist %25. Wenn man %C3%9F (ein ß) nochmals encoded, wird daraus %25C3%259F, und damit funktioniert es. Hier wären die Server-Logs aufschlussreich. Darin sind alle get-Anfragen aufgelistet und man kann erkennen, was Google beim Wiki-Server wirklich anfragt.
- Spätere Uploads:
- * Grundproblematik: s.o.
- * http://radreise-wiki.de/images/Test_Umlaute_.jpg Die Umlaute einfach weggelassen, liefert erstaunlicherweise einen 403er (You don't have permission to access /images/Test_Umlaute_.jpg on this server). Vielleicht heißt meine hochgeladene Datei ja so!?
- * Vermutung: Im Zusammenhang mit der Verarbeitung des Dateinamens beim Upload gibt es ein Encoding-Problem. D.h., dass eine Einstellung nicht wie notwendig auf UTF-8 steht, sondern z.B. auf ISO 8859-15. Die im Namen enthaltenen Buchstaben äöüß sind UTF-8-kodiert, werden aber anders interpretiert (als ANSI ergibt sich eben der Buchstabensalat der Fehlermeldung: äöüß).
- Ich habe eben noch lokal ein Wiki installiert (Version 1.24.1), um anhand verschiedener Einstellungen das Fehlverhalten zu reproduzieren. Wenn ich da die Datei "Test_Umlaute_äöüß.jpg" hochlade, bekomme ich folgende Meldung: "Fehler beim Hochladen: Dieses Wiki unterstützt keine Dateinamen, die Sonderzeichen enthalten." — Sie werden wissen, warum. Gute Nacht --Martin (Diskussion) 00:53, 1. Mär. 2015 (CET)
- Die Fehlermeldung "Dieses Wiki unterstützt keine Dateinamen, die Sonderzeichen enthalten." hat damit zu tun, dass ich das lokale MediaWiki unter Windows installiert habe. Bei Gelegenheit installiere ich nochmal unter Linux. --Martin (Diskussion) 10:43, 1. Mär. 2015 (CET)