Re: Caching mechanisms on GPX layers

Hi, I just had a short look at the patch that is attached to the ticket, assuming it contains the code you used to split things. I did not have a deep look at it, but from what I can tell, you copy over the waypoints to a new layer. Mind that this should not be done. New WayPoints always

Re: Caching mechanisms on GPX layers

Just checked that again, yes it is being called (by the event listener, as expected). And I assume it wouldn't update the layer at all if that wasn't the case. Thread [main-worker-0] (Suspended (breakpoint at line 1485 in > GpxDrawHelper)) > owns: GpxData (id=703) >

Re: Caching mechanisms on GPX layers

Did you check if GpxDrawHelper.gpxDataChanged is called? This is where the GPX drawing cache is reset. Le sam. 15 sept. 2018 à 15:25, Niklas B a écrit : > ... and this is why I hate mailing lists. > How it looks like after merging: > http://fs5.directupload.net/images/180915/n57lqu5o.png > And

Re: Caching mechanisms on GPX layers

... and this is why I hate mailing lists. How it looks like after merging: http://fs5.directupload.net/images/180915/n57lqu5o.png And after converting back and forth: http://fs1.directupload.net/images/180915/bjg4nn5a.png Sorry for the mess Niklas Am So., 16. Sep. 2018 um 01:20 Uhr schrieb

Re: Caching mechanisms on GPX layers

Am Sa., 15. Sep. 2018 um 22:41 Uhr schrieb Dirk Stöcker < openstreet...@dstoecker.de>: > Maybe your troubles come from the fact that JOSM has different settings > for local and server based GPS data (i.e. distances for continuous track > handling)? No, unfortunately not. All tracks were loaded

Re: Caching mechanisms on GPX layers

On Sat, 15 Sep 2018, Niklas B wrote: (maybe this time..?) Hi, I'm currently implementing an option to cut overlapping GPX tracks when merging them into one layer (followup of #16681 "*allow multiple tracks to be processed and prioritized (from