GpsPrune is available to download from the downloads page, with the latest released version being version 24.4. Details of the development of forthcoming versions are given here.
Please also look at the user guide for details about the user guide now available (in PDF and EPUB formats) for GpsPrune. Your feedback is valuable and much appreciated.
The following features are on the list for version 24.* and 25. Please also see the wishlist for new features which have been proposed by users of GpsPrune, and what's new for the recently developed features.
... and maybe also ...
Version 24 is now available in two forms, because it turned out there were runtime issues with Java 8. I thought that compiling with Java 11 with a target of Java 8 would work properly, but it turns out not, so there's now a separate Java 8 jar produced by a Java 8 JDK, which in turn required a handful of minor tweaks. You can get the source code from github if you use the "java8" branch.
This was a misunderstanding on my part — I understood that the two openweathermap services which GpsPrune uses for the forecasts will be discontinued in June 2024 so I thought that we need to either replace or remove the functionality. But it turns out after contacting the operators that those two will actually continue to work, so the removal of this function can be reverted :)
Some improvements in the colour selection are ongoing, as can be seen on this preliminary screenshot. There are a few things going on here, most obviously the colour selection popup on the right.
With this, you now have three tabs to choose your colour in different ways, instead of the previous single set of three RGB sliders. This might be useful if, for example, you want to choose two colours with the same hue, or two colours differing only by hue. Previously that wasn't so easy given only the opportunity to select the red, green and blue components.
Secondly, there's a new "Preview" bar at the bottom of the "Set colours" dialog. This shows the colours used by the selected colourer, and works for both the discrete colourers (like colouring by segment) and as shown here for the continuous colourers like altitude or speed. Obviously as you change the colourer type, or the start or end colours, or the maximum number of discrete colours, then this preview bar updates dynamically to show the effects.
And lastly there's a new pair of radio buttons controlling the "Hue interpolation". The name is a little awkward, but there are basically just two choices when interpolating between the start hue and the end hue. I've called them "Narrow" and "Wide" here but that might change if anyone can come up with more descriptive names!
Previously the colour interpolation was conceptually based on a linear scale, through the rainbow from red to violet. So if I chose to go from a kind of purple to a yellowy-green as shown here, then it would go through indigo, blue and green to get there. This is the "long way" round the colour circle, but you could also choose to go the "short way" round the circle instead, going from violet to red, orange and yellow.
So the same colour gradients are still possible with the expanded dialog, but now there are more options too. It gives more control over the hues used along the range, and hopefully makes it easier to more clearly visualise the data values.
Gpx is a very flexible data format for our coordinate data, but most of this flexibility comes from a variety of non-standard extensions. And the handling of extensions is different depending on whether the file is Gpx version 1.0 or version 1.1.
GpsPrune has a limited and non-perfect understanding of these extensions, which is particularly apparent when it comes to representations of heart rate, course, speed, and geocache details. GpsPrune tries to overcome this limited understanding by copying the source xml (if it can), thereby usually preserving the Gpx 1.0/1.1 information and the extension tags, but there are cases where this breaks down — particularly when files with different specifications are combined (for example a 1.0 file and a 1.1 file together, or files using different extensions), or when new fields are added to a point which already has extensions.
Current status: with experimental code we can load, display and edit the values of these extension fields, importantly even if the particular extension is not known in advance. So this should cover the various ways in which for example heart rate can be saved under different names. The profile chart can now also show this data, making it already interesting. What's not yet possible is the exporting (and also charting).
One consequence of this is that the export dialog will have to be made a little bit more complex by allowing the user to choose between Gpx 1.0 and 1.1. Most users of course don't know or care about this, and GpsPrune's current approach of exporting as it was loaded (or 1.0 by default) works for most situations. But to handle the extensions properly, we need to more strictly control the versions.
Once this is there, it immediately raises the possibility of loading a 1.0 file and exporting as 1.1, so we need to define what happens if points have speeds — these are valid in 1.0 but not valid in standard 1.1. Do the speeds get silently removed, is a warning shown, or can an extension be selected?
If a point does use extensions (either using Gpx 1.0 or 1.1), these will need to be translated if the export version isn't the same as the loaded version. Plus, if a file using extension X is loaded together with another using extension Y, how are these exported? Are both extensions used, or should the user have to choose one? Should the user have to choose whether to convert the heart rate values from extension Y into the right structure for extension X or vice versa? Mixing extensions makes things complicated.
I think this means that the checkbox "Copy source xml" can be removed though, as the xml will in future always be regenerated and never copied, so internally we can probably get rid of the GpxCacherList and the GpxSlicer too.
Also, as noted in one of the github issues, this also affects Kml 2.1, 2.2 and 2.3, along with the gx extensions and any other arbitrary extensions. So the kml/kmz export will also need to provide the option to choose the output format and extensions.
Call for help: in order to ensure that as many different file formats and extensions are supported, we need to collect simple, representative file samples showing how the data is stored. The coordinates and values can all be fake, but having a variety will really help with testing. If you have such data containing things like heart rate, pedal cadence, power output, temperature, wind speed or anything else like that, and it's stored in either gpx or kml format, please supply (small) valid examples from your device or tool. You can do this by email or by attaching to the github issue 75.
A smaller little addition, this works like point project except it projects each of the points in the current range. So for example you can select a part of the track which (for some reason) is a bit too far south, and project that range to the north by a given distance. Then you can choose whether to shift the existing points, or to create copies of the points (like the project point feature does).
We've already got interpolating points, and since 24.3 also the timestamps are interpolated too. But what if you don't want to create any new points, you just want to assign timestamps to the points which are lacking them, using their neighbour points?
Another new function to the rescue — just select the whole segment, select to interpolate the timestamps, and GpsPrune will now look for points without timestamps, and for those which are between timestamped points it will calculate the distances and "fill in" the timestamps assuming a constant speed.
So that's a new way of faking timestamps, you can just set the timestamp of the first and last points in a segment and call the function. Obviously it only interpolates within track segments, and ignores waypoints.
This one is still ongoing, but results are so far promising. The idea is, you collect tracks when you do the same route multiple times — these could be jogging, running, walking, cycling, roller blading or whatever. Now you want to see whether you're improving, whether you're faster or slower than previous times you've done the same route.
This new function works on a pair of segments, so probably loaded from two separate files but they don't have to be. Firstly you choose the two segments, which hopefully match more or less, and the earlier one becomes the "reference" segment. The second segment might start earlier or later, might diverge a little here or there, maybe takes detours or stops for rests, but hopefully GpsPrune can find lots of places where the position of the reference segment can be matched against the second one.
Now for each of those matches, GpsPrune can calculate the distance along the reference segment, and the two durations (since the first match, on both segments). So imagine that the reference segment makes a "ghost driver", and along the route the second segment is either ahead of the ghost or behind the ghost, by a varying number of seconds. This can then make a useful chart of where you're pulling ahead of the ghost and when it's catching you up.
GpsPrune can also do a similar thing to calculate the position of the second racer at the time corresponding to the ghost's position - so in that way calculating what distance ahead of the ghost or behind the ghost the second segment is.
These two graphs share some features - for example it's easy to see when the ghost stops for a rest and the second racer doesn't, because the second racer immediately gets a sudden time and distance advantage. Similarly when the second racer later stops for a rest, the ghost immediately catches up. But the varying speeds of the two segments change the shape of the distance graph, so for example if the racer is a fixed time ahead of the ghost going up a hill, both graphs will be fairly flat, but when one of the racers gets to the top of the hill and speeds up, the distance advantage will start increasing, until the second racer gets to the faster stretch too.
Currently GpsPrune is just outputting the numbers so that they can be pasted into a spreadsheet for visualisation, but as it's already looking useful it will probably be extended to call Gnuplot as well.
As always, all help with the translations will be very welcome! Please help to expand and improve the coverage of your favourite language. Please see the "translations" section below if you'd like to help.
Since February 2015, GpsPrune has a repository at GitHub. It's got all the history since version 1 in there, and the plan is to keep it updated with the latest released code. For those who find submitting git pull requests easier than submitting diffs by email or sourceforge, then this might be something for you to look at. It's also a good way of raising issues if you have questions or bug reports. I'm guessing that for most people, especially those without github accounts and those unfamiliar with git, the other methods of bug reporting and patch submission will continue to serve well.
| Language | Completion for 23.* | Completion for 24.* |
|---|---|---|
| English, German, Swiss German, Dutch, French, Italian | 100% | 100% |
| Spanish | 98% | |
| Portuguese | 93% | 94% |
| Polish | 92% | |
| Chinese, Catalan | 95% | 90% |
| Russian, Hungarian | 92% | 87% |
| Romanian, Swedish | 89% | 84% |
| Finnish | 87% | |
| Afrikaans, Czech | 85% | 80% |
| Norwegian | 12% | 77% |
| Korean, Japanese | 63% | 60% |
| Turkish | 40% | 38% |
| Ukrainian | 26% | 25% |
| Welsh | 18% | 22% |
| Danish | 22% | |
| Indonesian, Farsi | < 10% | |
The translations of GpsPrune are in greatly varying stages of completion. This table on the right summarizes the percentage of translations which are complete for each language. If you want to help with these translations, there are now three (count them, three!) ways for you to do this. The idea is that if the translation process is made as easy as possible for the translator, then the likelihood is higher that somebody might feel like helping out. So to make the entry barrier as low as possible, here are the options, in order of preference:
Obviously it would be great to get the nearly-complete languages back up to 100% again, especially those which were complete for earlier versions of GpsPrune, like for example Spanish, Catalan and Chinese.
Unfortunately there are also several languages here less than half-complete, which is why they've not been included in the release jars. You can use these files if you want (available from the download page), but obviously most of the texts are still in English. Any thoughts from users of these languages? Is there any interest in reviving or boosting these translations?
There's an interesting tool called SLOCCount, which goes through a code tree and counts up how many lines of code there are and in which languages. It seems to ignore blank lines, and comment lines and so on, so its figure for GpsPrune is (at the time of writing) 36 thousand lines rather than the 52 thousand which a simple wc -l gives. But anyway, then it uses a formula to estimate how many person-months it would take to develop a traditional commercial product of the same size, and how many dollars you'd have to budget for it (including a bunch of overheads such as project planning and specifications etc). Clearly most of those assumptions and parameters are completely invalid for a small open-source project, but just out of interest, I tried it out. As of version 15, GpsPrune is now worth over 1 meeellion dollars! And for you, it's free :)
The estimator at openhub however comes up with a figure of only around half a million dollars, even using apparently the same parameters, so that might give some indication how meaningful the estimates are! Oddly, this tool completely ignores valuable comments in the code, and valuable text files and properties files, but inconsistently does count an xml file the same as raw code(?) and also cares whether a logical line of code is split into several lines for readability or not. Is a four-line if block really worth so much more (or so much more costly to produce) than exactly the same expression in a one-liner?
Update: there's a bunch more on this topic at development stats, including some pretty charts of GpsPrune's metrics.
There's a very interesting tool called gource (like source but with a g), which makes very pretty animations to visualise a software tree as it grows and develops. Using the logs from the source control repository, it knows the file tree structure, it knows when each file was added, edited or removed, and by whom. And it's able to animate this, with each file represented by a little coloured ball, and each checkin causing balls to appear, move and shuffle around the bouncing tree. Check it out on youtube, it's mesmerizing.
So I tried this little tool out on the GpsPrune tree, and it works great. It shows the bursts of development (new files, often concentrated in single areas, reorganisations of files between directories) between long periods of testing and fixing (mainly edits to files, especially translations and build files). It shows the appearance of new functions like little flowers bursting into bloom, and the gradual transformation from a small bunch of dots into the current package hierarchy, as shown in this screenshot.
The purple dots shown here are the java files, the blue and green dots are the images, there's a bunch of blue translation files, and a small scattering of other file types such as xml and txt.
The following credits also appear in the "About" screen of the GpsPrune application, but it's worth repeating here - grateful thanks to all those who have helped contribute so far, by whatever means!
| GpsPrune code written by : | activityworkshop.net |
| Exif code written by : | Drew Noakes (drewnoakes.com) |
| Many icons provided by : | |
| Services : | SRTM data courtesy of the U.S. Geological Survey |
| Deprecated services : | Maps from |
| Translators : | Ramon (ch), Miguel (es), Inés (es), Piotr (pl), Petrovsk (fr), Josatoc (it), weehal (pl), theYinYeti (fr), Rothermographer (ro), Sam (zh), Rudolph (af), nazotoko (ja), katpatuka (tr), Rémi (fr), Marcus (pt), Ali (fa), Javier (es), Jeroen (nl), prot_d (cz), György (hu), HooAU (ko), Sergey (ru), Gilles (fr), serhijdubyk (ua), Péter (hu), Matteo (it), Peter (hu), Oana (ro), Cristian (ro), Roman (ru), Erkki (fi), Paolo (it), Maciej (pl), Erik (sv), Carlos (es), Tche333 (fr), J.M. (ca) |
| Technical feedback and patches : | Piotr, freegeographytools, Rudolf, Steven, Jose, Jeshi, Denny, Thomas, Jozef, Gregor, Robert, Jani, zapfen, Joerg, Alexandre, Anti, José, Arvee, Sebastic, PeHar, fperrin |
| Mac know-how : | Tyme, Daniel, Michael, Richard, Marek |
| Translations helped by : | Open Office, |
| Development tools : | GNU/Linux (originally Mandriva, now Debian and Mint), Java (originally Sun, now OpenJDK), an IDE (originally Eclipse, now moving to IDEA), version control (originally Subversion, now git), Gimp, Inkscape, bug-spotting (was findbugs, now IDEA and spotbugs) |
| Other tools : | Garble, GPSBabel, Povray, Exiftool, Google Earth, Gnuplot, JOSM, TeX Live, Sigil |
| Thanks to : | Friends and loved ones, for encouragement and support |
As discussed above, the appearance of the standard java/swing GUI under linux (especially the fonts) is sometimes disappointing. So if the "Nimbus" or "GTK" themes don't please everyone, we could perhaps think of alternatives to java and Swing to present the GpsPrune GUI.
This first idea has been floated for a while now, with the following basic prototype made to demonstrate the basic functionality. It shows the compilation of C++ code into a GUI application, shows the basic layout including menus, toolbar, status bar, the split main screen and various resizing behaviour. It also shows the techniques for internationalization of all the texts using Qt's standard translation mechanism.
This example uses natively-compiled C++, but in theory it could use Python and Qt instead. This has the advantage that the GpsPrune code wouldn't need to be natively compiled separately for each possible platform (of which there are many!) but instead could just be distributed as one single source file. However it would have two disadvantages - it would need a python runtime in order to run, so an additional large dependency for everybody to install, and more importantly it would also rely on the PyQt library to be installed, which adds more fiddling.
In October 2014, a new experiment started to rebuild the main GpsPrune GUI using Java and SWT. The results are shown to the right, laying out the basic GUI elements and getting the resizing to work properly. There's a menu and toolbar, a status bar, and exactly the same multi-language support from the "normal" GpsPrune application rather than a separate Qt technique. This saves translation effort as the identical files can be simply re-used.
This needs some more investigation to see if it's worthwhile, or if the SWT requirements could cause problems for users on the various platforms. But all it needs is a java runtime and the SWT library, both of which are platform-dependent but available for all the major platforms. For the major linux distributions these things are already included.
The current idea is to gradually expand this prototype, gradually taking in more components from the "normal" GpsPrune and seeing what difficulties arise. Apart from simply replicating the existing dialogs and functions, there are two proposed guidelines to shape further improvements. Firstly, each dialog should be able to rebuild itself, so that changing the language will have an instant effect everywhere without requiring a restart. And secondly, the functions which need dialogs should be completely separated from the actual data manipulation that they do - this will make automatic testing easier and will also allow a "Redo" button to be implemented.
Update 2022: OK, so the "current idea" didn't really come to fruition, but the "Redo" function is finally on its way (planned for maybe version 25). It's turning into a huge refactoring exercise, but the data manipulation will at the end be separated from the Gui, and the benefits of testing are already apparent. There's still no huge incentive to push for SWT, and no loud calls from users unhappy with the Swing look. Maybe the introduction of the themes has reduced the pressure.
The following jar is for those interested in what this SWT version could look like. It's very basic so far, and doesn't actually do much editing or display of the files. But at least you can see if SWT works on your platform, try out the Help menu and Settings menu, load a kml or gpx file to scroll through the points, see the altitude profile and delete a single point.
 |
SWT code for testing (300 kB) |
This seems to be a fairly promising start, with a few things working already, but obviously an enormous amount of functionality still missing. Looking at the time taken to get this far, and the amount of (re)work required to get everything back up to the usefulness of the regular GpsPrune application, it seems like the proposed benefits are perhaps not great enough to justify the effort. Maybe the translation to SWT would be more reasonable if that was the only change required, rather than the restructuring of Functions and TrackOperations being done here, but then the benefit is even smaller, basically just an improved appearance on some platforms. This effort could probably be more usefully applied to enhancing the existing GpsPrune rather than re-doing a lot of the existing work.