Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#1014 closed defect (wontfix)

Points of gps tracks downladed by api are displayed badly by josm and merkaator

Reported by: Jan Górski Owned by: Tom Hughes
Priority: major Milestone:
Component: api Version:
Keywords: Cc:

Change History (5)

comment:1 Changed 11 years ago by Tom Hughes

Resolution: invalid
Status: newclosed

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

comment:2 Changed 11 years ago by Jan Górski

Resolution: invalid
Status: closedreopened

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

comment:3 Changed 11 years ago by Tom Hughes

Resolution: wontfix
Status: reopenedclosed

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.

comment:4 Changed 11 years ago by Jan Górski

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.

comment:5 Changed 11 years ago by Tom Hughes

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.

Note: See TracTickets for help on using tickets.