I think I’ve posted stuff on this before, but I don’t think I every really got the answer I was looking for, so I thought I’d ask again… sorry for repeating myself.
I have a folder of 763 NMEA text files, totaling about 300MB of someone driving around a town.
I’m pretty new to this mapping thing, so really don’t know what I’m doing, the following is what I know and am happy with:
JOSM is to be used as virtual tracing paper, it opens a small number of tracks (1 or 2) and roads are then drawn manually from that (I don’t really know how yet, but will learn);
Names have to be manually entered, I can do that;
nmea is converted into more useful gpx using gpsbabel;
I have a BAT file that will take (with a great deal of messing about) the nmea files and turn them into 1 month period concatenated files, however attempting to use this inexplicably corrupts the data, I have yet to identify the route cause.
I still don’t have a workable solution for loading all of a small area into JOSM for tracing, I have considered the following:
Upload all tracks (in concatenated chunks?) to the server, and download it again in geographical chunks using josm (is this too much data?);
Attempt to set up a really complex set of filters to get gpsbabel to split the data geographically.
How does everyone else handle these (frankly normal) situations, and how should I proceed?
There might be a filter in gpsbabel to split tracks every time there is at least 2 hour between log points.
zip those files together with 7zip in to a zip archive
upload that archive to the server
download the area you want to edit.
I agree that it isn’t a perfect solution having to download all data again but you get the feature you need most in the easiest way.
I was not aware that you could zip them and upload them like that.
Having done a small test, it seems that joining tracks together in that way leads to lines flying all over the place between the end of one and the start of another track. To avoid that I’m going to have to upload each one individually – even if I do zip the bits that fit, I’m still going to have 300+ files.
Is there no way to do it other then manually using the web form for each one?
The road names will be coming largely from memory, or from site visits.
It’s possible to bulk upload data to openstreetmap (wiki), though we put lots of responsibilty on the client/user since it’s important to have good data before import. You can also try the NMEA upload web form, but I don’t know how that works and if it handles multiple tracks.
But the zip archive upload should work. It should split up every file into a seperate track and not joining end #1 with start #2, if it does then it’s a bug. Are you sure it’s not you GPX files?
“If you have multiple files to upload, you may compress them into a zip archive and upload it. It will then be treated as one big gpx file (that is, only one entry in your trace list is created).”
I take that to mean what I say above; I do believe there is a very real possibility that I could be getting confused as you suggest however.
This is about the GPX files (tracklogs from GPS devices). It’s not about uploading .osm, gis or autocad files. If you have many tracklogs lying around and do not want to upload them 1-by-1 then you can add them to a zip file and upload that (zipped size up to 10MB afaik). It’s just that simple.
Re all the lines flying all over the place when you re-download them in JOSM, that won’t stop stop if you upload them in single files. You can go into JOSM’s preferences and deselect the option to draw lines between the GPX points.
Hrm, there is a help link on the upload of the GPX form, and it seems that people don’t read it. Imagination required to get people to…
Please try it! If you have problem with a ZIPed GPX upload, then please post a link to it and we will solve this issue, ZIP file upload should not work as you describe.
You should know that NMEA dumps and GPX files are very different, and you need to have correct start and ends of your tracks to get a good GPX file.
ok, if someone could please clarify that I’ve got this all straight in my head – if I set gpsbabel to start a new track after a 5 minute gap, and rig it so that every track is in a separate file (I’m not sure exactly how to do that, but will work on it) then take the (roughly) 700 files, zip them all, and upload it, there should be next to no lines flying?
I believe that a gpx file with more than one track will only have the first track read on upload, is that not correct?
I shall see if I can sort out a small subset of the data to check exactly where the problem is being introduced.
All data you upload into the GPX upload form should be insterted into the database, if it doesn’t then that’s abug and it should be fixed that’s the main idea. I’ve read the code and it did support importing more than one track per GPX back in ~2006.
Right – I’ve done some exploration into the situation of uploading multiple tracks per gpx file.
The uploader takes the files, and seems to treat them as a single track, so that josm displays them with incorrect connecting lines everywhere (about 9 that are visible to me). The track in question:
I downloaded the existing data form the area in josm, uploaded the track, then downloaded the same area again into another layer. The file displays perfectly in josm before upload. Data was filtered in gpsbabel so that 100 meter+ gaps start a new track.
I personally don’t normally display connecting lines when viewing josm, so don’t mind, but i don’t know if anyone else will mind.
Is this correct functionality, a documented low priority issue to be ignored, or is this a bug?
I have so far loaded 12mb of 126mb of gpx files, and it looks okish, does anyone see any problems with me just uploading the rest as is?
I have a few ideas for how to reduce the connecting lines issues, but I don’t know if it’s worth the hassle.