Caching mechanisms on GPX layers

Niklas B b.n.burchard at gmail.com
Sat Sep 15 13:24:38 UTC 2018


... 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.burchard at gmail.com
>:

> Am Sa., 15. Sep. 2018 um 22:41 Uhr schrieb Dirk Stöcker <
> openstreetmap at 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
>


More information about the josm-dev mailing list