06.09.2012, 19:20
Hallo Christian,
Ich fahre den Routeconverter dashalb auch mit 10 GB und das System ist auch nicht das langsamste. ;-)
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.
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.
Klar, ich kann mir das mal anschauen, wenn's mal wieder eine ruhige Minute gibt.
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.
Hintergrund ist folgende Überlegung. Man könnte so verschiedene Implementierungen intern parallel haben, die man nur über eine -D-Option oder eine versteckte Option umschaltet.
Man könnte so z.B. eine Variante machen, die "schnell, aber ungenau" ist. Und eine andere, die "langsam, aber genauer" ist. Hinzu käme, dass man so leichter das Ergebnis der Änderungen/Optimierungen vergleichen kann.
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.
Wenn man das machen würde (bzw. falls das schon jetzt gemacht wird), so müsste das Ausdünnen der verbleibenden Kurve beim großen und auch beim kleinen File von mir mit den identischen Punkten arbeiten und dann auch ein identisches Ergebnis liefern.
Das ist jetzt nur mal so eine Idee. Ich weiss natürlich nicht, ob das so einfach geht und wo die Fallen sind.
Ihr habt euch mit dem Thema sicher schon deutlich länger beschäftigt, als so ein dahergelaufener Entwickler wie ich.
Gruß
Thomas
(06.09.2012, 07:56)routeconverter Wrote: 596039 Positionen, 148 MByte Dateigröße ist auch nicht alltäglich. Das Laden erfordert mehr als 512 MByte Heap für die Java VM und dauert 2 Minuten.Das geht bei mir zum Glück deutlich schneller. Du hast auch nur die "kleinen" Dateien bekommen. Die wirklich großen sind 600 MB groß. ;-)
Ich fahre den Routeconverter dashalb auch mit 10 GB und das System ist auch nicht das langsamste. ;-)
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.
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.
(06.09.2012, 07:56)routeconverter Wrote: Magst Du vielleicht helfen?
BaseMapView#reducePositions ist ein guter Startpunkt:
Klar, ich kann mir das mal anschauen, wenn's mal wieder eine ruhige Minute gibt.
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.
Hintergrund ist folgende Überlegung. Man könnte so verschiedene Implementierungen intern parallel haben, die man nur über eine -D-Option oder eine versteckte Option umschaltet.
Man könnte so z.B. eine Variante machen, die "schnell, aber ungenau" ist. Und eine andere, die "langsam, aber genauer" ist. Hinzu käme, dass man so leichter das Ergebnis der Änderungen/Optimierungen vergleichen kann.
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.
Wenn man das machen würde (bzw. falls das schon jetzt gemacht wird), so müsste das Ausdünnen der verbleibenden Kurve beim großen und auch beim kleinen File von mir mit den identischen Punkten arbeiten und dann auch ein identisches Ergebnis liefern.
Das ist jetzt nur mal so eine Idee. Ich weiss natürlich nicht, ob das so einfach geht und wo die Fallen sind.
Ihr habt euch mit dem Thema sicher schon deutlich länger beschäftigt, als so ein dahergelaufener Entwickler wie ich.
Gruß
Thomas