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)

Das Problem liegt von außen betrachtet ziemlich sicher an unzutreffenden Encoding-Einstellungen im Wiki. Der Link, um eine Strecke in GM anzuzeigen, liefert schon konkrete Hinweise (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. Interessanterweise ist %C3%9F das richtige Encoding für ein ß. Dieser Link ist also richtig, aber die Datei auf unserem Server heißt anders. Und genau deswegen meine Frage (s.o.). Ohne diese Information komme ich nicht weiter.

* 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.

* http://radreise-wiki.de/images/Test_Umlaute_.jpg (die Umlaute einfach weggelassen) liefert übrigens einen 403er (Forbidden, You don't have permission to access /images/Test_Umlaute_.jpg on this server). Vielleicht heißt meine hochgeladene Datei so!?

* http://radreise-wiki.de/images/Test_Umlaute_%25C3%25A4%25C3%25B6%25C3%25BC%25C3%259F.jpg (doppelt encoded) liefert dagegen wieder einen 404er.

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: äöüß). --Martin (Diskussion) 22:06, 28. Feb. 2015 (CET)