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) > GpxDrawHelper.gpxDataChanged(GpxData$GpxDataChangeEvent) line: 1485 > GpxData.lambda$38(GpxData$GpxDataChangeEvent, > GpxData$GpxDataChangeListener) line: 959 > 429616353.fire(Object) line: not available > ListenerList<T>.fireEvent(EventFirerer<T>) line: 150 > GpxData.fireInvalidate() line: 959 > GpxData.mergeFrom(GpxData, boolean) line: 234 > GpxLayer.mergeFrom(GpxLayer, boolean) line: 318 > MergeLayerAction.lambda$0(List, Object) line: 93 > 589689845.run() line: not available > Executors$RunnableAdapter<T>.call() line: 514 > FutureTask<V>.run() line: 264 > ProgressMonitorExecutor(ThreadPoolExecutor).runWorker(ThreadPoolExecutor$Worker) > line: 1135 > ThreadPoolExecutor$Worker.run() line: 635 > Thread.run() line: 844 Am So., 16. Sep. 2018 um 01:33 Uhr schrieb Vincent Privat < vincent.pri...@gmail.com>: > 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 >> > >> >
