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 <b.n.burch...@gmail.com> 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 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 Niklas B < > b.n.burch...@gmail.com > >: > > > 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 locally and the connected > > points don't really make any sense at all, on productive data I had > > connected trackpoints that were multiple months apart and on the other > side > > of the globe... (just for clarification btw: My implementation cuts > > timewise overlapping tracks) > > > > Here's an example (it looks that weird because I'm planning on using it > > for unit tests and it's supposed to cover pretty much every specific > case, > > e.g. entire "high level" track segments being between two waypoints of a > > "low level" track etc.) > > > > This is how it looks like directly after merging: > > > > > > And this is how it's supposed to look like / how it looks after > converting > > it back and forth: > > > > > > The GpxData is correct, at least when being exported, so I'm pretty sure > > it's some kind of caching / rendering issue... > > > > But if nobody has an idea I'll just finish the patch first, maybe someone > > finds the bug after I published it. I just thought that there might be > some > > kind of caching somewhere that I wasn't aware of. > > > > Cheers > > Niklas > > >
