Anzeige-Problem (Herunterskalierung)

[routeconverter]

Hier gibts aber trotzdem gleich mal eine andere Frage, Wenn ich mich nicht irre, hälst du im Hintergrund noch das Original-GPX im Speicher, um nicht modifizierte Einträge wieder identisch speichern zu können.

Fast. Nicht das GPX sondern die durch JAXB erzeugten Objekte, die das GPX repräsentieren, werden noch im Hauptspeicher gehalten.

Vieleicht könnte man hier eine versteckte Option machen, die das nicht macht. Beim konvertieren in ein anderes Format, können beim Speichern die Files auch auf Basis der reinen Daten aufgebaut werden. Der Speicherbedarf dürfte damit bestimmt etwas geringer werden.

Ich habe keine Ahnung, wieviel Speicher das kostet. Das könntest Du mal messen. GpxPosition#origin ist das Attribut, das die JAXB-Daten referenziert.

Ich hab gerade mal mein Git wiederbelebt und einen kurzen Blick darauf geworfen. Was ich mich frage ist, ob man den Downscale Algorithmus nicht aus BaseMapView in eine eigene Klasse auslagern kann, die dann über ein Interface in BaseMapView angesprochen wird. Natürlich müssten dann noch Infos über den eigentlichen Anzeigebereich mit übergeben werden.

Klar kann man das - aus meiner Sicht ist das der 2. Schritt vor dem ersten. Ersteinmal möchte ich eine bessere Implementierung des Algorithmus' sehen - gerne als Patch zum existierenden Code - bevor es sinnvoll ist, drüber nachzudenken, wie man den Code integriert. Er könnte z.B. auch die bestehende Implementierung ersetzen und man spart sich die Abstraktion.

Bei der Optimierung der Punkte geistert mir im Kopf folgendes herum. Eigentlich müsste man ja alle Punkte wegwerfen können, die ausserhalb des Anzeigebereichs (etwas größer natürlich, damit man's nicht gleich beim Bewegen der Karte merkt) sind und wo auch der vorherige/nächste Punkt noch ausserhalb ist und die Linie nicht den Anzeigebereich schneidet.

Im einzelnen passiert schon derzeit folgendes:

• Reduktion auf 50000 Positionen durch Auswahl jeder Anzahl/50000. Position, damit der nächste Schritt akzeptable Laufzeit hat
  
• Reduktion durch Douglas Peucker mit empirisch ermitteltem Faktor für steigenden Detailgrad mit steigendem Zoomlevel
  
• Reduktion auf das 2,5fach des sichtbaren Bereiches - erst jetzt, sonst schneidet der vorige Schritt Kanten zu Linien außerhalb zu früh weg
  
• Reduktion auf heuristisch ermittelte Obergrenzen je nach Route, Track, Wegpunktliste bei denen der Internet Explorer noch stabil funktioniert durch Auswahl jeder Anzahl/Obergrenze. Positionen - damit erreichen den IE garantiert nicht mehr Positionen als er vertragen kann
  

Ihr habt euch mit dem Thema sicher schon deutlich länger beschäftigt, als so ein dahergelaufener Entwickler wie ich.

Eigentlich schrauben EddiVonDerAlm und ich da seit der Integration der Karte bei RouteConverter 1.6 herum