Author: tom[at]compton.nu
[Added to the original trac issue at 3.57pm, Monday, 7th July 2008]

What exactly do display issues in Merkaartor and JOSM have to do with the api?

Author: osm[at]slimak.info
[Added to the original trac issue at 11.12pm, Tuesday, 8th July 2008]

Your question suggests that you have not read description of problem. If you have, then please explain why this ticket is invalid.

Author: tom[at]compton.nu
[Added to the original trac issue at 11.17pm, Tuesday, 8th July 2008]

Because you didn't provide a description of the problem! Instead you expected me to go and try and extract it from the history of a JOSM bug.

As far as I can tell from the JOSM bug your complaint is that points are not grouped by trace and returned in order by the API but that is a deliberate feature. We deliberately loose the relationship between points and the trace they came from, and hide the timestamps (and hence the ordering) for privacy reasons.

Author: osm[at]slimak.info
[Added to the original trac issue at 11.47pm, Tuesday, 8th July 2008]

I am sorry, I thought that amount of noise in JOSM bug was small enough to not make problems while reading it, and that making a copy of non noise data from there was therefore not needed. My apology.

My complaint is that API returns points from two traces mixed together, so after connecting them, instead of two parallel lines I see big zig zag. This is the first time I have seen such behaviour. I think that

1. Ability to see order of points in editor is beneficial to people using it.
2. Flash editor does not mix those points, so this information is available (if someone is determined, he can get it by using Potlach).

Please reconsider your resolution of this ticket.

Author: tom[at]compton.nu
[Added to the original trac issue at 12.03am, Wednesday, 9th July 2008]

Yes I know that Potlatch doesn't follow the same rules, and I pointed out to the author at the time that this resulted in a greater exposure of data from the traces than we had previously allowed.

To be completely accurate, as far as I know the GPX API does actually return the points in order (because it pretty much has to in order to return the data in chunks) although we don't actually advertise that fact or guarantee that it will always be that way.

What it doesn't do is order by trace, so if you have two traces with overlapping timestamps they will be mixed up. That seems like it is something that is not likely to happen very often though.

I suspect what you are really seeing is that Potlatch is able to use the timestamps to break the line whenever there is a large jump in timestamp (because it does that on the server) but JOSM is not able to do that as the timestamps are not returned by the API, something that definitely will not be changing. I don't see that there is much I can do about that.