... the user friendly GPS tool


Thread Rating:
  • 1 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Anzeige-Problem (Herunterskalierung)
#31
(23.10.2012, 21:17)lundefugl Wrote: Ganz so einfach bekomme ich den Effekt nicht mehr hin. Trotzdem ist er leider noch da. Welche Umstände dazu führen, kann ich aber nicht genau sagen. Wenn man etliche Verschiebe- und Zoomändervorgänge gemacht hat zeigt er plötzlich die Linie nicht an.

Kann es sein, daß die Positionen sehr weit auseinander liegen, so daß das Ziel der Linie außerhalb des gefilterten Bereichs liegt?

(23.10.2012, 21:17)lundefugl Wrote: Evtl. kann man mit den Logausgaben ein System erkennen, warum es manchmal funktioniert und manchmal nicht. Ansonsten kann ich auch am Wochenende debuggen.

Das wäre klasse: ich bekomme mit Deinen Dateien nichts reproduziert.

(23.10.2012, 21:17)lundefugl Wrote: Und noch eine andere Info. Auch wenn ich gesagt habe, dass der Downscale sehr gut funktioniert (was auch absolut richtig ist), so habe ich in meinen Daten eine Stelle gefunden, bei der der letzte Punkt fehlt (der dann die Linie ausserhalb des Sichtbereiches zieht). Die Stelle kann ich nicht genau erklären, da sie in einem sehr tiefen Zoom erst sichtbar wird. Hier werde ich am Wochenende mal selbst debuggen. Das ist sicher nur irgendein kleiner Index-Fehler oder kleiner/kleiner gleich Fehler.

Ich nehme an, der hat hiermit und der etwas kruden Heuristik
Code:
double visiblePositionAreaFactor = max(VISIBLE_POSITION_AREA_FACTOR * (zoom - MAXIMUM_ZOOM_FOR_SIGNIFICANCE_CALCULATION), 1) * VISIBLE_POSITION_AREA_FACTOR;
zu tun, die bei sehr hohen Zoomlevel den sichtbaren Bereich vergrößern soll, um Linien "nach außerhalb" nicht abzuschneiden.
--
Christian
Reply
#32
Hallo Christian,

(24.10.2012, 19:57)routeconverter Wrote:
(23.10.2012, 21:17)lundefugl Wrote: Ganz so einfach bekomme ich den Effekt nicht mehr hin. Trotzdem ist er leider noch da. Welche Umstände dazu führen, kann ich aber nicht genau sagen. Wenn man etliche Verschiebe- und Zoomändervorgänge gemacht hat zeigt er plötzlich die Linie nicht an.

Kann es sein, daß die Positionen sehr weit auseinander liegen, so daß das Ziel der Linie außerhalb des gefilterten Bereichs liegt?

beim Refreshproblem ist das auf jeden Fall nicht der Fall. Bei dem fehlenden letzten Punkt ist es evtl. möglich. Der Punkt hat auf jeden Fall einen deutlich weiteren Abstand zu den anderen Punkten, als diese zueinander. Hier ist ein Tunnel dazwischen, wo der GPS-Logger nichts getrackt hat. Ob das in deinem Sinne "sehr weit" ist, weiß ich nicht.

Ich werde mir wohl am Wochenende mal dann deine neue Filterlogik anschauen. Bei meinem Vorschlag hatte ich für diesen Fall immer den ersten Punkt ausserhalb am Leben gelassen - egal, wie weit weg der war.

Gruß
Thomas
Reply
#33
Hallo Christian,

(24.10.2012, 19:57)routeconverter Wrote: Das wäre klasse: ich bekomme mit Deinen Dateien nichts reproduziert.

was mir noch so durch den Kopf geschossen ist: Könnte es sein, dass du von der Annahme ausgehst GoogleMaps-Fenstergrösse == GoogleMaps-Anzeigebereich ?
Ich nutze den RC auf einem 30"-Monitor. Im GoogleMaps-Fenster hat man da graue Ränder, wenn man die Positionsliste zu schmal macht. Ich hab das bei mir zwar so eingestellt, dass die Fenstergröße auch dem maximalen Anzeigebereich von GoogleMaps entspricht, aber auf den Pixel genau kann ich das nicht garantieren.

Gruß
Thomas
Reply
#34
(25.10.2012, 06:11)lundefugl Wrote: was mir noch so durch den Kopf geschossen ist: Könnte es sein, dass du von der Annahme ausgehst GoogleMaps-Fenstergrösse == GoogleMaps-Anzeigebereich ?

Das weiß ich nicht: BaseMap#filterVisiblePositions greift im Endeffekt auf map.getBounds().getNorthEast() zu und verwendet WGS84-Koordinaten. Ich glaube die Fenstergröße hat da keinen Einfluß.
--
Christian
Reply
#35
Hallo Christian,

ich hab noch etwas herumgespielt und glaube das Auslösen des einen Effektes erklären zu können. Es passiert wohl, wenn man die Karte oft verschiebt (um in meinem Fall dem Track zu folgen) und dann den Zoomlevel ändert.

In meiner Version mit Logausgaben sieht man dann, dass keine Neuberechnung stattfindet und in BaseMapView#centerChanged beide contains()-Aufrufe trotzdem immer true zurückgeben, wenn man die Karte verschiebt.

Da du in BaseMapView#centerChanged nur den Cache für den aktuellen Zoom löschst, habe ich bei mir mal "reducedPositions.clear();" statt "reducedPositions.remove(getZoom());" eingebaut. Damit bekomme ich den Fehler auf die Schnelle nicht mehr hin.

Ich vermute daher mal, dass man bei BaseMapView#zoomChanged auch noch eine Bereichsprüfung einbauen muss, ob der Cache vor dem Repaint evtl. verworfen werden muss oder nicht.

Gruß
Thomas

Hallo Christian,

auch das zweite Problem habe ich gefunden - bzw. du hattest ja schon die richtige Ahnung.
Das passiert bei tiefen Zoomlevels, wenn der eine Punkt im real sichtbaren Bereich ist und der nächste Punkt ausserhalb des erweiterten Bereiches liegt.

Ich habe hier mal meine Lösung vom letzten Mal eingebaut, die dafür sorgt, dass immer der erste Punkt ausserhalb des Bereiches noch mit am Leben bleibt. Damit war dann der Fehler weg.

Ich werde dir dafür nochmal einen neuen Pull-Request schicken.
Wundere dich nicht über meinen Branchnamen. Ich hab nicht aufgebapsst und leider in meinem master-Branch alles gemacht.

Was du über die Commit-Historie auch sehen wirst, ist dass ich einen Unittest für filterEveryNthPosition gemacht habe. Die Funktion hatte ich eigentlich zuerst im Verdacht, da sie auch nicht ganz korrekt gearbeitet hat.

Gruß
Thomas
Reply
#36
(26.10.2012, 17:04)lundefugl Wrote: Da du in BaseMapView#centerChanged nur den Cache für den aktuellen Zoom löschst, habe ich bei mir mal "reducedPositions.clear();" statt "reducedPositions.remove(getZoom());" eingebaut. Damit bekomme ich den Fehler auf die Schnelle nicht mehr hin.

Du hast recht: das war überoptimiert, nur den aktuellen Zoomlevel zu aktualisieren. Wenn man dann den Zoomlevel ändert und der Kartenausschnitt hat sich deutlich verändert, sind im Cache nur Positionen, die nicht mehr sichtbar sind. Commit

(26.10.2012, 17:04)lundefugl Wrote: auch das zweite Problem habe ich gefunden - bzw. du hattest ja schon die richtige Ahnung.
Das passiert bei tiefen Zoomlevels, wenn der eine Punkt im real sichtbaren Bereich ist und der nächste Punkt ausserhalb des erweiterten Bereiches liegt.

Ich habe hier mal meine Lösung vom letzten Mal eingebaut, die dafür sorgt, dass immer der erste Punkt ausserhalb des Bereiches noch mit am Leben bleibt. Damit war dann der Fehler weg.

Das habe ich übernommen, die NullPointerException bei includeFirstAndLastPosition=false entfernt und einen Test gebaut. Schau mal auf den Commit

(26.10.2012, 17:04)lundefugl Wrote: Ich werde dir dafür nochmal einen neuen Pull-Request schicken.
Wundere dich nicht über meinen Branchnamen. Ich hab nicht aufgebapsst und leider in meinem master-Branch alles gemacht.

Bitte mach Deine Pull-Requests klein wie möglich, dann haben sie eine bessere Chance angewendet zu werden: ich verstehe leichter, was die Änderung ist und kann in github einfach "Accept" klicken.

(26.10.2012, 17:04)lundefugl Wrote: Was du über die Commit-Historie auch sehen wirst, ist dass ich einen Unittest für filterEveryNthPosition gemacht habe. Die Funktion hatte ich eigentlich zuerst im Verdacht, da sie auch nicht ganz korrekt gearbeitet hat.

Die Idee mit dem Test finde ich prima. Dabei habe ich auch herausgefunden, daß jeglicher Code, den wir da in #filterEveryNthPosition() bislang am Start hatten, nicht korrekt funktioniert hat. Schau mal auf den Commit
--
Christian
Reply
#37
Hallo Christian,

gleich zu Beginn die gute Nachricht. Ich hab die neuste Version probiert und keine Probleme mehr feststellen können. Es funktioniert alles, wie ich es erwarte - Super !.

(28.10.2012, 14:45)routeconverter Wrote:
(26.10.2012, 17:04)lundefugl Wrote: Ich habe hier mal meine Lösung vom letzten Mal eingebaut, die dafür sorgt, dass immer der erste Punkt ausserhalb des Bereiches noch mit am Leben bleibt. Damit war dann der Fehler weg.

Das habe ich übernommen, die NullPointerException bei includeFirstAndLastPosition=false entfernt und einen Test gebaut. Schau mal auf den Commit
Den anderen includeFirstAndLastPosition-Fall hatte ich überhaupt nicht beachtet. Wie gut, dass du alle UseCases auf dem Schirm hast.


(28.10.2012, 14:45)routeconverter Wrote:
(26.10.2012, 17:04)lundefugl Wrote: Ich werde dir dafür nochmal einen neuen Pull-Request schicken.
Wundere dich nicht über meinen Branchnamen. Ich hab nicht aufgebapsst und leider in meinem master-Branch alles gemacht.

Bitte mach Deine Pull-Requests klein wie möglich, dann haben sie eine bessere Chance angewendet zu werden: ich verstehe leichter, was die Änderung ist und kann in github einfach "Accept" klicken.
OK. Ich dachte, dass es ausreicht, wenn die Commit-Schritte nachvollziehbar sind. Mit Git und der Arbeitsweise damit bin ich immer noch Newbie.



(28.10.2012, 14:45)routeconverter Wrote:
(26.10.2012, 17:04)lundefugl Wrote: Was du über die Commit-Historie auch sehen wirst, ist dass ich einen Unittest für filterEveryNthPosition gemacht habe. Die Funktion hatte ich eigentlich zuerst im Verdacht, da sie auch nicht ganz korrekt gearbeitet hat.

Die Idee mit dem Test finde ich prima. Dabei habe ich auch herausgefunden, daß jeglicher Code, den wir da in #filterEveryNthPosition() bislang am Start hatten, nicht korrekt funktioniert hat. Schau mal auf den Commit

Hier haben wir wohl etwas unterschiedliche Vorstellungen, wie die Test und der Code aussehen sollen. Solange der Code funktioniert ist ja alles super.

Die Probleme sind jedenfalls behoben, worüber ich sehr glücklich bin - danke nochmals dafür.

Gruß
Thomas
Reply
#38
(28.10.2012, 18:52)lundefugl Wrote:
(28.10.2012, 14:45)routeconverter Wrote: Die Idee mit dem Test finde ich prima. Dabei habe ich auch herausgefunden, daß jeglicher Code, den wir da in #filterEveryNthPosition() bislang am Start hatten, nicht korrekt funktioniert hat. Schau mal auf den Commit

Hier haben wir wohl etwas unterschiedliche Vorstellungen, wie die Test und der Code aussehen sollen. Solange der Code funktioniert ist ja alles super.

Am Test oder Code hänge ich nicht. So wie eingecheckt verstehe ich, was er tut. Und das ist wichtig: Dein Code und mein Code haben schlicht nicht so funktioniert, wie wir uns das gewünscht haben. Bei der Reduktion einer 7-elementigen Liste auf 4 läßt sich das gut beobachten:

Code:
1 2 3 4 5 6 7

Man würde erwarten, daß die Ergebnisliste so aussieht, oder?

Code:
1 3 5 7

Nur soviel: Bei unseren bisherigen Lösungen kamen meist andere lustige Dinge heraus. Aber nun geht es.

(28.10.2012, 18:52)lundefugl Wrote: Die Probleme sind jedenfalls behoben, worüber ich sehr glücklich bin - danke nochmals dafür.

Danke für Deine Hilfe.
--
Christian
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)