Activity Workshop

GpsPrune development

GpsPrune is available to download from the downloads page, with the latest released version being version 18.6. 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 (PDF, HTML, or EPUB) for GpsPrune. Your feedback is important.

Known bug in 18.5

There is unfortunately a bug with GpsPrune's SRTM altitude lookup function, which recently made itself apparent (thanks Jacek for the information!). The USGS have recently moved their SRTM data files, but GpsPrune wasn't following the redirection, it was just saving the redirection message instead. So if you've already saved the SRTM data in your cache, altitude lookups continued to work, but if it needed to download additional data, it wouldn't find it.

There is a fix for this now, included in the latest 18.6 release. Even if your SRTM lookups are currently working correctly, it's recommended to update to 18.6 anyway, to avoid confusion if you work with a different area or on a different computer without the cached SRTM data.

Features for version 19

The following features are under discussion for version 19. Please also see the wishlist for new features which have been proposed by users of GpsPrune.


As always, all help with the translations will be very welcome at any time! Please see the translation wiki if you'd like to help.

For Version 19, apart from some removal of some outdated features (see list above), the first main addition was a "Create marker waypoints" function. This lets you specify either a distance interval (in kilometres, metres or miles) or a time interval (in hours and minutes), and adds waypoints along the track according to that interval. This lets you for example put waypoints every 5 km along a planned route, or put waypoints for every hour along a recorded route.

Another addition is the expansion of the track display options on the main map. Previously one of the control icons let you cycle between points and lines, just points, and just lines. Now there's a fourth option: points and lines and arrows on the lines showing the direction of travel. So this control now has four options to cycle round instead of three. The arrows are only shown when there's space for them, so depending on your point spacing you may have to zoom in quite far to see them.

Waypoint icons and arrows New display settings dialog Available icon types

There is also now the possibility to choose which icon to draw for waypoints on the map, instead of the default black blobs. A new dialog available from the Settings menu lets you choose one style with which to show all waypoints on the map. (All waypoints are shown identically, regardless of waypoint type). An example is shown here to the left, including some track arrows showing the track direction.

The dialog collects together this new waypoint icon selection with two other settings which used to have their own entry in the Settings menu - the line width and the antialiasing checkbox. This cleans up the Settings menu a little bit. As well as which icon to use, you can also choose the icon size, from small, medium or large. Four different icons are provided to choose from, plus the default black blob. The icons themselves have some scope for tweaking during the test phase.

Timezone selection

Wishlist item 61 asks for the option to select a different timezone from the one normally used by the system. The problem is this: let's say you live in Europe and your computer is set to have everything in a European timezone. Then you take your GPS to California and record some tracks, and want to review those tracks back at home. It's confusing if the point timestamps are shown in European time, and when you colour the track points by date, the date breaks are according to European time, not Californian time. Similarly it's awkward to get the "delete points by date" function to work properly without either changing your system's timezone (which you obviously don't want to do) or using a temporary timezone with a java environment variable parameter (which is possible but awkward).

As shown in this screenshot, there's now a new dialog available in the Settings menu to let you choose an alternative timezone for GpsPrune to use. This will be remembered in the GpsPrune config but can easily be reset to the system timezone with the radio button.

Once this timezone has been set, the point timestamps (in the point details panel) will be shown according to the selected timezone, and the colouring by date and deleting by date will work as you expect.

There is an online service from (like the wikipedia ones which GpsPrune already uses) to find nearby "points of interest" from OpenStreetMap. It was hoped that this would provide an easy way to find nearby bus stops (and their names if the names aren't rendered on the tiles), amenities like restaurants and so on. GpsPrune was modified to call this service but it turned out that it didn't work very well at all, unfortunately. Maybe their database is not up-to-date with the OSM database, so can't find POIs even when they're rendered on the map? Whatever the reason, GpsPrune now uses OpenStreetMap's Overpass API directly instead of using geonames, and it works much better. Now there's an easy way to find that bar that you're sure is around there somewhere but its name isn't rendered on the map.

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. 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.

As an experiment I've also put the Spanish translations on the github wiki, to see if that generates any more interest than the one on Sourceforge. But so far, (after nearly 2 years of being available) unfortunately there hasn't been any interest at all, not a single addition or correction. Any ideas how we can encourage more translations or more translators? Any way we can make translating things easier for them?

Some other open-source projects are using a service called Transifex to manage their translations, would this be something worth looking into? Are there any translators who would love to use Transifex for GpsPrune translations? The only downside is that Transifex sounds quite complicated to configure and may not be able to do the same as our current system(s). And it's a proprietary, closed-source solution. Another alternative might be Fedora's Zanata, which is free and open-source. Anybody keen on using Zanata?

Development cost

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?

Development activity

Gource screenshot

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.

Fonts in OpenJDK

Up until recently I avoided using OpenJDK because I didn't like the look of the fonts, and I stuck with Sun's Java. Now I've switched to OpenJDK7, and I'm very disappointed to see that the same issues I saw with OpenJDK6 are still there. Lots of people are complaining about it (especially Ubuntu users), but noone seems to have a solution which works for me. I've tried all sorts of things with a file, but that seems to be ignored, and I tried the GTK look-and-feel, but that has other problems.

It seems this is a general problem, probably to do with font selection rather than antialiasing or rendering, and it affects all java applications, not just GpsPrune. It still works, but for me (some people don't mind), it just looks ugly. And it makes the java applications look jarringly different from the native programs on the same system, I can't see a reason why.

If anyone has an answer for me, how to manually specify which font is used for all the default labels and menus, I'd be very grateful!

If that doesn't work, then the very very last resort would be to move away from Swing and use something else like Qt (if there is a working java interface?) or perhaps SWT (like Eclipse uses) or even JavaFX. But SWT would bloat the dependencies and any rewrite of the GUI would require a lot of pain and time. And JavaFX would require everyone to have Java 8, which will probably take some time given that several people are apparently still using versions 5 and 6. Getting Swing to look better would be by far the better solution if possible.

Update: see the bottom of this page for more news on this issue.


for v17.2
for v18.6
English, German,
Swiss German,
Hungarian, Dutch,
Italian, Polish
Swedish, Indonesian11%

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, just have a look at the translation wiki, which has now moved to SourceForge. (You may need to register for a (cost-free) SourceForge login in order to edit pages). By the way, it would be great to get the nearly-complete languages like Chinese, Spanish, Portuguese and French back up to 100% again if anyone wants to help!

Unfortunately the Indonesian, Farsi and Danish translations are currently only around 10% 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 these translations?

Also, we've got several new Scandinavian languages appearing recently - Norwegian, Swedish and Danish are all extremely empty at the moment but maybe these starts will trigger some more interest?


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
Exif code written by :Drew Noakes (
Some icons taken from :Eclipse
Services :SRTM data courtesy of the U.S. Geological Survey, Wikipedia services by geonames, Gpsies services by, maps from Openstreetmap and (now deleted), weather forecasts from, geocaches from, photos 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)
Technical feedback
and patches :
Piotr, freegeographytools, Rudolf, Steven, Jose, Jeshi, Denny, Thomas, Jozef, Gregor, Robert, Jani, zapfen, Joerg, Alexandre, Anti, José, Arvee, Sebastic
Mac know-how :Tyme, Daniel, Michael, Richard
Translations helped by :Open Office, Gpsdrive, Babelfish, Leo, Launchpad
Development tools :GNU/Linux (originally Mandriva, now Debian and Mint), Java (originally Sun, now OpenJDK), Eclipse IDE, Subversion, Gimp, Inkscape, findbugs
Other tools :Garble, Gpsbabel, Povray, Exiftool, Google Earth, Gnuplot, JOSM, TeX Live
Thanks to :Friends and loved ones, for encouragement and support

Alternatives for the GUI

As discussed above, the appearance of the standard java/swing GUI under linux (especially the fonts) have taken a disappointing downturn since OpenJDK replaced Sun's java. I've no idea why that should be so, the fonts are certainly available and there's no reason I can see why it shouldn't look great under linux. Under Microsoft and Apple the GUI still looks fine, although maybe not quite exactly the same as native applications.

After many months, there doesn't appear to be any improvement on the horizon. So maybe it's time to think of alternatives to java and Swing to present the GpsPrune GUI.

Qt, using either C++ or Python

screengrab of Qt prototype

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.

Java, using SWT

screengrab of SWT prototype

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.

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.

Jar file

SWT code for testing (300 kB)
gpsprune_swt_011.jar - Get this one if you want to try out the very basic SWT prototype

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.