Datei Diskussion:HmProfil.jar.kmz

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:

vorher: hinterher:

• 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)

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)

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)