Re: [OSM-talk] JOSM update
On Fri, 28 Mar 2008, Frederik Ramm wrote: and you can also limit the length of these GPS connection lines (draw.rawgps.max-line-length=x, in metres), for those cases where you get crazy zig-zagging. I had noticed a while ago that JOSM appeared to handle GPX files incorrectly (and presumably the same goes for GPX data retrieved from the OSM server) - Not sure if it has been fixed (I'm using a relatively old JOSM at the moment): The GPX files consist of trk elements (tracks), with each track containing one or more trkseg element (track segment). JOSM seemed to be joining the end of a trkseg to the start of the next trkseg rather than leaving them unconnected. The trk elements themselves are handled correctly though - they are left unconnected. This might be the cause of a lot of the crazy zig-zagging (which actually makes the GPS data completely unusable in some locations - Nottingham, for example, is totally obscured by the zig-zagging lines if you ask JOSM to retrieve the GPS data from the server.) Which brings me to another point - why not run a sanitiser across the database to try and remove obviously broken GPS data. For example, if the distance between two GPS points exceeds several hundred metres they probably shouldn't be considered part of the same track segment so this could be fixed in the database itself. - Steve xmpp:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] http://www.nexusuk.org/ Servatis a periculum, servatis a maleficum - Whisper, Evanescence ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] JOSM update
On Fri, 28 Mar 2008, Frederik Ramm wrote: I'll investigate that. However with data retrieved from the server, you don't even get the trkseg structure, you just get a ton of individual points and have no chance of finding out whether they belong to the same segment or not! Ouch - I hadn't realised that. :) The problem I saw was for local GPX files - I was generating them from GPS data stored in a database and had originally used a single trk containing many trkseg elements. JOSM rendered them with every point joined to the next, even if those points were in separate trkseg elements. I modified my GPX generator so that it used many trk elements, each with a single trkseg and JOSM rendered that correctly. When I saw a similar problem with the data downloaded from the server, I assumed it was probably the same problem, but didn't investigate further. Anyway, I'll grab the latest JOSM and hopefully it'll make some areas a lot more readable without all those crazy tracks - good stuff. :) - Steve xmpp:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] http://www.nexusuk.org/ Servatis a periculum, servatis a maleficum - Whisper, Evanescence ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] JOSM update
On Fri, 28 Mar 2008, Frederik Ramm wrote: * It is now possible to have arrows on the lines connecting GPS points (draw.rawgps.direction=true), I'm seeing a couple of slightly odd things with the GPS direction arrows: (screenshot) http://www.nexusuk.org/~steve/josm-gpsarrows.png They are pointing the wrong way - the blue motorway loop in the screen shot is traversed in the anticlockwise direction, but the arrows on the GPS track are showing it to be clockwise (seems to be the case for all the GPS tracks, so this isn't just an odd data set). Also, I seem to be getting a few extraneous arrows which always point East (visible on the right hand side of the motorway loop. - Steve xmpp:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] http://www.nexusuk.org/ Servatis a periculum, servatis a maleficum - Whisper, Evanescence ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] JOSM update
Hi, They are pointing the wrong way - the blue motorway loop in the screen shot is traversed in the anticlockwise direction, but the arrows on the GPS track are showing it to be clockwise (seems to be the case for all the GPS tracks, so this isn't just an odd data set). Are you saying every single arrow points the wrong way? Because that would be an easy fix to make ;-) Also, I seem to be getting a few extraneous arrows which always point East (visible on the right hand side of the motorway loop. This happens when lines of length 0 are drawn. I suspect that those tracks that suffer from the east arrows have been uploaded twice, so that every point in them occurs twice, but I'll check that again. Maybe JOSM should be instructed to omit these arrows. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] JOSM update
On Fri, 28 Mar 2008, Frederik Ramm wrote: Are you saying every single arrow points the wrong way? Because that would be an easy fix to make ;-) Yes, seems to be the case :) This happens when lines of length 0 are drawn. I suspect that those tracks that suffer from the east arrows have been uploaded twice, so that every point in them occurs twice, but I'll check that again. Maybe JOSM should be instructed to omit these arrows. Ah, ok - that makes sense. - Steve xmpp:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] http://www.nexusuk.org/ Servatis a periculum, servatis a maleficum - Whisper, Evanescence ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] JOSM update
On Fri, 28 Mar 2008, Steve Hill wrote: Are you saying every single arrow points the wrong way? Because that would be an easy fix to make ;-) Yes, seems to be the case :) To complicate things more, the direction arrows on data imported from a local GPX file are the right way around, so this problem is only affecting data being retrieved from the OSM server. - Steve xmpp:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] http://www.nexusuk.org/ Servatis a periculum, servatis a maleficum - Whisper, Evanescence ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] JOSM update
In message [EMAIL PROTECTED] David Earl [EMAIL PROTECTED] wrote: On 28/03/2008 16:50, Raphael Mack wrote: Am Freitag, 28. März 2008 schrieb Steve Hill: On Fri, 28 Mar 2008, Steve Hill wrote: Are you saying every single arrow points the wrong way? Because that would be an easy fix to make ;-) Yes, seems to be the case :) To complicate things more, the direction arrows on data imported from a local GPX file are the right way around, so this problem is only affecting data being retrieved from the OSM server. mh, I guess this cannot be fixed in josm, since the the server returns the stored gps points in arbitrary order. I would even suggest not to draw any direction arrows for gps data from the server. They can be sorted by timestamp, can't they? They do have timestamps AFAICS. I believe that they are sorted by timestamp. What they aren't sorted by is the track they came from so you might get points jumbled up from different tracks. The API deliberately tries to expose limited information about the points for privacy reasons as some points may have come from traces that are not public. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] JOSM update / why does API return GPS points in descending order?
Hi, mh, I guess this cannot be fixed in josm, since the the server returns the stored gps points in arbitrary order. I would even suggest not to draw any direction arrows for gps data from the server. But they can't be too arbitrary since drawing lines in between the points would reveal a completely chaotic picture otherwise. I think David Earl is right about sorting by timestamp since this is what's in the API source: points = Tracepoint.find_by_area(min_lat, min_lon, max_lat, max_lon, :offset = offset, :limit = TRACEPOINTS_PER_PAGE, :order = timestamp DESC ) ... and the DESC nicely explains the observation that all arrows are in the wrong direction! I wonder why it is there. TomH? Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] JOSM update
On 28/03/2008 17:02, Tom Hughes wrote: In message [EMAIL PROTECTED] David Earl [EMAIL PROTECTED] wrote: On 28/03/2008 16:50, Raphael Mack wrote: Am Freitag, 28. März 2008 schrieb Steve Hill: On Fri, 28 Mar 2008, Steve Hill wrote: Are you saying every single arrow points the wrong way? Because that would be an easy fix to make ;-) Yes, seems to be the case :) To complicate things more, the direction arrows on data imported from a local GPX file are the right way around, so this problem is only affecting data being retrieved from the OSM server. mh, I guess this cannot be fixed in josm, since the the server returns the stored gps points in arbitrary order. I would even suggest not to draw any direction arrows for gps data from the server. They can be sorted by timestamp, can't they? They do have timestamps AFAICS. I believe that they are sorted by timestamp. What they aren't sorted by is the track they came from so you might get points jumbled up from different tracks. But the tracks are grouped and numbered too... David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] JOSM update / why does API return GPS points in descending order?
Frederik Ramm wrote: ... and the DESC nicely explains the observation that all arrows are in the wrong direction! I wonder why it is there. Because you want the most recent ones first? cheers Richard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] JOSM update / why does API return GPS points in descending order?
Hi, ... and the DESC nicely explains the observation that all arrows are in the wrong direction! I wonder why it is there. Because you want the most recent ones first? Does any application *not* read all pages returned? Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] JOSM update / why does API return GPS points in descending order?
Frederik Ramm wrote: Sent: 28 March 2008 5:10 PM To: Raphael Mack Cc: talk@openstreetmap.org Subject: Re: [OSM-talk] JOSM update / why does API return GPS points in descending order? Hi, mh, I guess this cannot be fixed in josm, since the the server returns the stored gps points in arbitrary order. I would even suggest not to draw any direction arrows for gps data from the server. But they can't be too arbitrary since drawing lines in between the points would reveal a completely chaotic picture otherwise. I think David Earl is right about sorting by timestamp since this is what's in the API source: And since its rare for two people to have the same time period for the same area by chance it generally works (just back to front). But of course that cant be guaranteed, especially if the area is large. Cheers Andy points = Tracepoint.find_by_area(min_lat, min_lon, max_lat, max_lon, :offset = offset, :limit = TRACEPOINTS_PER_PAGE, :order = timestamp DESC ) ... and the DESC nicely explains the observation that all arrows are in the wrong direction! I wonder why it is there. TomH? Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] JOSM update / why does API return GPS points in descending order?
Am Freitag, 28. März 2008 schrieb Frederik Ramm: Hi, mh, I guess this cannot be fixed in josm, since the the server returns the stored gps points in arbitrary order. I would even suggest not to draw any direction arrows for gps data from the server. But they can't be too arbitrary since drawing lines in between the points would reveal a completely chaotic picture otherwise. I think David Earl is right about sorting by timestamp since this is what's in the API source: points = Tracepoint.find_by_area(min_lat, min_lon, max_lat, max_lon, :offset = offset, :limit = TRACEPOINTS_PER_PAGE, :order = timestamp DESC ) ... and the DESC nicely explains the observation that all arrows are in the wrong direction! I wonder why it is there. TomH? Oh, this sounds nice. I expected, that the timestamps are not even stored in the db, since they are not included in the delivered gpx. Maybe one could implement this, when touching the code to change to ascending order? - This would allow to split the track into track segments which would help to draw arrows only if the time difference is less than some threshold... Rapha ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] JOSM update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tom Hughes wrote: | In message [EMAIL PROTECTED] | David Earl [EMAIL PROTECTED] wrote: | | On 28/03/2008 16:50, Raphael Mack wrote: | Am Freitag, 28. März 2008 schrieb Steve Hill: | On Fri, 28 Mar 2008, Steve Hill wrote: | Are you saying every single arrow points the wrong way? Because that | would be an easy fix to make ;-) | Yes, seems to be the case :) | To complicate things more, the direction arrows on data imported from a | local GPX file are the right way around, so this problem is only | affecting data being retrieved from the OSM server. | mh, I guess this cannot be fixed in josm, since the the server returns the | stored gps points in arbitrary order. I would even suggest not to draw any | direction arrows for gps data from the server. | They can be sorted by timestamp, can't they? They do have timestamps AFAICS. | | I believe that they are sorted by timestamp. What they aren't sorted | by is the track they came from so you might get points jumbled up from | different tracks. | | The API deliberately tries to expose limited information about the | points for privacy reasons as some points may have come from traces | that are not public. Why expose the timestamps of private tracks. Expose the order, but please don't expose the timing - apart from the positions themselves, this is the most private part of the data. Thanks, Robert (Jamie) Munro -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH7S2Rz+aYVHdncI0RAmFbAKD8v03s1x1xh0ed6AsPkuSD27QS6ACgub70 2M8xpalyerW3RC/NwR5oRlo= =19Pp -END PGP SIGNATURE- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] JOSM update / why does API return GPS points in descending order?
Frederik Ramm wrote: Does any application *not* read all pages returned? Well, in Potlatch the download points in current area is the primary method of reading tracklogs (as - mercifully - it doesn't have any access to your local file system), so yes, it does return only the most recent n000 points to avoid utterly boggling the server/your browser. That said, it doesn't use the XML API anyway so it's a bit of a moot point. cheers Richard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] JOSM update / why does API return GPS points in descending order?
On Fri, Mar 28, 2008 at 12:37 PM, Andy Robinson (blackadder) [EMAIL PROTECTED] wrote: Frederik Ramm wrote: Sent: 28 March 2008 5:10 PM To: Raphael Mack Cc: talk@openstreetmap.org Subject: Re: [OSM-talk] JOSM update / why does API return GPS points in descending order? Hi, mh, I guess this cannot be fixed in josm, since the the server returns the stored gps points in arbitrary order. I would even suggest not to draw any direction arrows for gps data from the server. But they can't be too arbitrary since drawing lines in between the points would reveal a completely chaotic picture otherwise. I think David Earl is right about sorting by timestamp since this is what's in the API source: And since its rare for two people to have the same time period for the same area by chance it generally works (just back to front). But of course that cant be guaranteed, especially if the area is large. Cheers Andy On the increasingly likely (as our userbase grows) chance that two or more users upload tracks with overlapping times, would it be possible to do a group by user so that the tracks will be logically clustered? I don't know the table schema--I'm not even sure if that table has a user column. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] JOSM update
Hi, I should point out that you can't synchronize an audio track to a GPS track without the exact timing information. But I'm confused now - if I look at GPS tracks on the third tab of the OSM home page, what I see is GPX style HTML with exact timestamps and ordered tracks. So if it is public there why suppress it when accessed through another route. That's a common misunderstanding. We store GPX tracks in two forms. One, the original GPX files, exactly as uploaded, with whatever extra private information your GPS emitted (waypoint 001, note=this is where I kissed Joanna yesterday). These are stored on the server, but only accessible to the public in this full form if you explicitly make them public. (There's an API call to retrieve lists of trace files and download the individual files if desired.) Furthermore, any uploaded track, public or not, is processed by a daemon and the individual GPS points with timestamps and a link back to the file where they came from are stored in the database. The API will, on request, return all GPS points within a certain bounding box, but you will ONLY get GPS points, ordered by timestamp but you don't see the timestamp, and you will not get the track structure or the note about Joanna. Apart from the web site where you can browse the individual tracks, all clients use the second interface that gives access to all GPS points, but not the extra data. This means that you will never be able to match an audio track to GPS points downloaded via the API all GPS points in bbox call, but that's probably not what you want anyway. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] JOSM update / why does API return GPS points in descending order?
Hi, Does any application *not* read all pages returned? Well, in Potlatch the download points in current area is the primary method of reading tracklogs (as - mercifully - it doesn't have any access to your local file system) Whoooa! Potlatch has just ruined my personal files! , so yes, it does return only the most recent n000 points to avoid utterly boggling the server/your browser. That said, it doesn't use the XML API anyway so it's a bit of a moot point. Right. I'll change JOSM to draw the arrows the other way for GPS tracks downloaded from the server, but please don't forget to speak up should you ever remove the DESC ordering ;-) Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] JOSM update / why does API return GPS points in descending order?
On Fri, Mar 28, 2008 at 5:37 PM, Andy Robinson (blackadder) [EMAIL PROTECTED] wrote: Frederik Ramm wrote: Sent: 28 March 2008 5:10 PM To: Raphael Mack Cc: talk@openstreetmap.org Subject: Re: [OSM-talk] JOSM update / why does API return GPS points in descending order? Hi, mh, I guess this cannot be fixed in josm, since the the server returns the stored gps points in arbitrary order. I would even suggest not to draw any direction arrows for gps data from the server. But they can't be too arbitrary since drawing lines in between the points would reveal a completely chaotic picture otherwise. I think David Earl is right about sorting by timestamp since this is what's in the API source: And since its rare for two people to have the same time period for the same area by chance it generally works (just back to front). But of course that cant be guaranteed, especially if the area is large. It would happen though when there's been a mapping party. Cheers Andy points = Tracepoint.find_by_area(min_lat, min_lon, max_lat, max_lon, :offset = offset, :limit = TRACEPOINTS_PER_PAGE, :order = timestamp DESC ) ... and the DESC nicely explains the observation that all arrows are in the wrong direction! I wonder why it is there. TomH? Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
