track list showing all gpx files from one folder

[mnagel]

Currently the GpsPrune workflow implies that you explicitly open one gpx file (using the very generic operating system file picker) and then operate on that. (Is this correct?)

Personally, I have a lot of gpx files in one/few folders and would love to have a nice overview over multiple gpx files.

For the beginning I would be perfectly happy with a simple table listing all gpx files in one folder, giving me different columns such as

• track name/comment
• track date
• track duration
• track distance
• average speed
• number of waypoints/photos

The table should be sortable and clicking a row should open the file as if the gpx file had been selected from the file picker.

Ideally, the following would work, too:

• one should be able to customize the displayed columns
• there should be one column with an embedded thumbnail of the track

Please let me know what you think of this idea.
Is it a good fit for GpsPrune?
Would you consider adding something like this to GpsPrune yourself?
Would you like me to further plan this feature and provide a mockup?
Would you help me to implement this feature and merge it into the upstream?

---

Market survey: What do other programs offer? Look at this image from the Locus Play Store page:
https://lh3.googleusercontent.com/C8U3sExbwsFaxeOhEB0gQJuPOGfFJ299Atoct-j1YdQaTgV-hIW79RbxYCU5TFwyX1E=h900-rw

[activityworkshop]

Thanks for your ideas, it's great to receive feedback which completely rethinks an aspect of the program!

Currently the GpsPrune workflow implies that you explicitly open one gpx file (using the very generic operating system file picker) and then operate on that. (Is this correct?)

More or less correct. Actually you can open more than one and they will be loaded consecutively. Another way to open files is to select them in your regular file browser window and drag them into your open GpsPrune window. It's also important to note that GpsPrune doesn't only open gpx files, that's why you can select kml, kmz, txt, csv, nmea or other files in the same way.

For the beginning ... a simple table listing all gpx files in one folder, ... the table should be sortable and clicking a row should open the file as if the gpx file had been selected from the file picker.

I think it would be a good idea to isolate what is the problem you're trying to solve. Currently, as you say, GpsPrune assumes that the question is "I want to open a file and I know what it's called", and you're completely right, that's not always true. But you seem to be answering one (or both) of the following questions:

• "I want to open a file and I don't know what it's called but I do know something else about the file"
• "I want to see an overview of several files and see things like how my lap times are improving over time"

In the first question, you want help finding a file so you can open it and work on it as before, in the second case you may not even want to open any files, you just want to see aggregated data for several files at once. Maybe you think they're the same question, or maybe you really want to do one rather than the other?

Finding a file

If what you really want to do is find a file, then let's look at what is already there for finding a file. If I know something about the file, like part of the name or timestamp or size, then I can use other tools to find the filename, like for example searching with a file manager, and then dragging the file over into GpsPrune. If I know something about the contents of the file, like a word in the description or a waypoint name, then I can use grep or again a file manager (assuming the coordinate file isn't compressed).

I don't think I would use factors like average speed or track distance to help me find a file, because they're too variable - they might be interesting to look at but I wouldn't know the average speed of that file I'm trying to find but don't know the name of.

If I am trying to find a file, what would be most useful for me is to ask "I want to open any file which has points inside this rectangle", because I know I was there before but can't remember when. That doesn't seem to be covered by your table idea.

What I usually do in this scenario is load several of the files and see if any of them cover the area - if not I undo the load, and if they do then I can click on a point and see which file it came from, and then load just that file.

What I'm most concerned about with your idea of putting this function inside the "open file" functionality, is that it would probably get in my way over 99% of the time. If I do know which file I want, then I definitely do not want GpsPrune to read, unzip, parse and summarize all 200 files in that directory, some of which may be painfully large, just so I can scroll through a space-eating table instead of a simple list of filenames. So that means it would have to be configurable to switch it on and off, and it would have to save its results somehow and only read and recalculate when files are modified or added. Where and how these results would be stored, I don't know. Plus it's important to note that although gpx files can be loaded without user input, text files can't, so I guess the table would have to have blank cells for those files which couldn't be automatically parsed and summarized.

Summary table

Alternatively, maybe you don't want to open a file at all, but just want to see this summary table anyway. Again you'll probably want to store the results somewhere to speed things up, but the aim of it is different and the way to get to it would be different maybe. I can see that it could be useful for summarizing training runs etc. But I think what you would be creating here would be a kind of "library" of static tracks, which could be part of GpsPrune or could be a separate application. In the same way that you might have one application for organising your photos (with cached thumbnails, tags, time-view etc) and a separate one for editing them.

That's not to say I don't like the idea or I don't think it should be part of GpsPrune, I'm just throwing ideas around to clarify what you're aiming for. When you say "For the beginning..." it gives the impression that it could expand later once people see it and use it, so it would be nice to have a definite idea of what the purpose is and where it fits.

tl;dr

In short, I think there are (at least) three options, depending on what you're looking for:

• add an optional possibility to the "open file" process to help you select a file you don't know the name of.
• add some kind of "search for file" functionality, separate from the direct "open file" process, again with the aim of helping you find a file, but allowing you to enter some kind of criteria before it starts (searching for text, or minimum / maximum track length etc).
• build a "library" of tracks with stored information about each one, kind of like a photo organiser. Then you could browse, search and sort views on this track database, and query it for nearby tracks like the gpsies search. Tracks could be added to the library when you open them in GpsPrune, or you could point it at a given directory and it could load whatever it can find recursively.

What do you think?

[mnagel]

Thank you very much for your very insightful feedback!
My want/need is most concerned with the summary table/library aspect of the problem.
I had some free time and thus implemented a prototype/proof of concept.
You can find it here: https://github.com/mnagel/gpxplore
Feel free to close this issue or use it for further discussion.

Best Regards and thanks for your work and your feedback!

[activityworkshop]

I was able to try this out, and it looks really cool. Thanks for letting me know about this. I had to tweak the code a little bit to run with python 3.5 though.

I love the thumbnails, and I don't mind the restriction of only gpx files and only a single directory (without subdirectories). I do think it would be great to be able to select a different directory without closing and reopening the window.

The details are also useful (except I don't care about distance_3d, it's never going to be amazingly different from distance_2d for my tracks). And as I said I'd love to be able to search for a word inside the track metadata of name and description.

Well, this probably isn't the best place to write about suggestions for your GPXlore project, so if I find anything further I'll raise an issue over there. Meanwhile I'll keep this issue here open because I'd be interested in more thoughts on this.