The following sections address possible problems encountered when running GpsPrune, and suggestions for solutions. It should be read in conjunction with the how-tos page which describes how to complete common tasks. If you have any questions or feedback please use the email address at the bottom of the page.
If you do not have a direct connection to the internet, but you have a proxy server, you can use this proxy server to fetch the openstreetmap map tiles for use in GpsPrune. To do this, you can set the java runtime's system properties when you launch GpsPrune, like this:
java -Dhttp.proxyHost=myproxyserver.com -Dhttp.proxyPort=80 -jar gpsprune.jar
Where of course the proxy host name and port number should correspond to your local settings. And of course you can include these parameters in your shortcut or alias so that you don't have to type them in each time you run GpsPrune.
It might be that when using the Chinese or Japanese languages, the Chinese characters appear as empty squares instead of the proper characters. To get the display working properly, you have to make sure you have Chinese fonts properly installed (just because Firefox displays them properly isn't always enough). For example, on Mandriva you have to install an extra package "fonts-ttf-chinese". The second step is to let java know where to find these fonts. This is platform-dependent, but it may mean adding a shortcut in the java runtime's font directory. Again using Mandriva as an example, the fonts are installed in /usr/share/fonts/TTF/chinese/ and the java runtime looks for its fonts at /usr/lib/jvm/java-1.6.0-sun-1.6.0.10/jre/lib/fonts/, so to let java find them you need to make a link:
cd /usr/lib/jvm/java-1.6.0-sun-1.6.0.10/jre/lib/fonts/ ln -s /usr/share/fonts/TTF/chinese/ fallback
Thanks to Li Zhao for the tip!
It seems like there are (still!) common problems with running GPSBabel under linux, especially with USB Garmin devices. Sometimes you may get an error message about a module "garmin_gps" blocking access to the USB device, other times the error message is not so meaningful. Basically there are two main problems - this garmin_gps kernel module may work for some people but doesn't work for many. If it doesn't work, the kernel module has to either be removed (with rmmod garmin_gps) or, better still, blacklisted by an entry in the file /etc/modprobe.conf using a line like "blacklist garmin_gps". The exact location of this modprobe.conf file may depend on your distribution.
There is also a second problem using certain linux distributions, in that the root user is then able to call gpsbabel successfully (using the device "usb:"), but normal users are not, and just get an error message about a module ''. Again the solution to this appears to be distribution-dependent, but it often involves making a new rule file for udev. For more information see gpsbabel's linux page. Note that on some distributions it was okay to say group="plugdev" before, but newer versions of udev only seem to work if it's uppercase GROUP="plugdev".
With more recent GPS receivers there's a third problem with GPSBabel, in that GPSBabel doesn't support the newer binary communication modes. According to developer answers that's deliberate, and the answer is to not use GPSBabel at all any more - for such GPS receivers the recommendation is to switch the receiver to USB mass storage mode and just use GpsPrune's open file and export gpx functions to access the receiver's storage. You may still have a need to use the "Import using GPSBabel" function for certain file types, however.
Some of the terminology used in GpsPrune might be confusing if you're not familiar with using GPSs. The myriad of file formats and strange terminology (routes, tracks, waypoints) might be overwhelming. This is what I wrote in an email to someone asking about the differences:
Firstly, it is important to understand the difference between "track points" and "waypoints". As an example, let's say I walk from my house to the bakery. I switch my GPS on at my house, and make a waypoint, called "HOUSE". Then I record the way I walk, with lots of points, and then when I get to the bakery I make a new waypoint called "BAKERY". When I load this data into Prune, I get two things. I get two waypoints, and I probably get them in alphabetical order, so that's "BAKERY" and then "HOUSE". The order doesn't matter, but these two points have names attached to them. They may have timestamps too but probably not. I also get lots of track points, all without names, but here the order does matter, so I get the points in the order in which they were recorded, from my house to the bakery.
The basic point types can be summarized like this:
For drawing charts from GpsPrune, and if you're using a Microsoft system, you have to follow different rules according to the version number of Gnuplot that you're using.
Up to version 4.6.7 the executable that you need is called "pgnuplot.exe" (rather than gnuplot.exe). To fix this, go to Settings -> Set program paths in GpsPrune, and give the full path to pgnuplot.exe instead. See the gnuplot faq for more information on this. Thanks to Javier for the feedback.
After version 4.6.7 and before 5.2.6 - sorry but it doesn't work. The developers helpfully decided to remove the pgnuplot executable making it all stop working, as gnuplot also didn't do what it should. Thanks to Nick for the feedback.
From 5.2.6 it seems that they have finally fixed the Windows problems, but now you need to configure the path (the whole path!) to bin\gnuplot.exe. Thanks to Patrick for the feedback.
On linux it's much simpler, just use any version of Gnuplot you like, and configure the path to be gnuplot.
If you've got a recent version of Gnuplot, it could be that the charts under View -> Charts stopped working. Whether you choose to output to screen or to an svg file, some setups give absolutely no output at all, or a warning message or any kind of terminal output. Unfortunately this problem affects older versions of GpsPrune too, even if they were previously working fine.
The solution I've found (which works on the linux distributions I've tried but may be different for other distros) is to manually install the package "gnuplot-x11" which has the effect of also removing the package "gnuplot-nox". The addition of this x11 package allows gnuplot to use the terminal called x11, which isn't otherwise available, and so the output to the screen can't work.
I still have two mysteries, firstly why the output to file using the terminal svg doesn't work in this case, and secondly why the nox package is installed by default. I guess that GpsPrune's package should have a recommends entry for the x11 package too.
The API provided by Gpsies for the download and upload doesn't work any more, so it's been removed from version 20. So any problems with the uploading to gpsies aren't a problem any more I suppose.
A problem with saving of GPX files on Mac OSX has been reported (thanks, Erich!). We've been through XML-encoding problems before, so now GpsPrune asks the system which file encoding is being used, and writes the name of this encoding in the file. Apparently though there's a problem with Mac OSX, which reports that it's using the encoding called "MacRoman", but actually writes the file using UTF-8. So if you want the file to be readable by other programs, you apparently have to go and edit the file, to change this "MacRoman" specifier to read "UTF-8" instead.
I haven't had chance to verify this problem yet or find a reasonable solution. If anyone does have an elegant solution, please let me know!
The services which GpsPrune calls to find wikipedia articles are provided (for free) by geonames.org. If the server gets overloaded, it will just return error messages - the best thing to do is just wait and try again.
The function to download OSM information for the current track area used to use OpenStreetMap's XAPI, but this now seems to be discontinued. GpsPrune now uses their Overpass API instead, and it seems to work well, but as has been said before, OpenStreetMap's own export function has improved greatly recently, so perhaps GpsPrune's function is superfluous. Feedback?
Apparently there is a known problem with java's standard xml-parsing libraries failing to cope with XML files with version 1.1 (almost every GPX and KML file I've ever seen uses XML version 1.0). The bug is annoying but what's worse is that it doesn't give any error message or anything, it just delivers the wrong values, usually for the latitude value in the cases I've seen (thanks to the GpsPrune user who alerted me by email).
One solution is to edit the files to say xml version="1.0" instead of 1.1, and this will probably work unless your xml file really relies on the special features of xml 1.1. Another solution (if you have GPSBabel installed) is to use GpsPrune's function "Import file with GPSBabel", but that's awkward to do for every file. A better solution is to use an external xml library called Xerces to do the loading instead. Xerces is still optional, and not necessary if you only deal with xml 1.0 files, but if you do need it then you can download it and put it in the java classpath where GpsPrune can find it.
The timestamps of track points and waypoints are calculated and stored in the UTC timezone, but we as users of GpsPrune are generally more interested in the local time at which the point was stored. So in GpsPrune's "point details" panel, the timestamps are converted into the system's local timezone for display.
Since GpsPrune version 19, there is the possibility to change this in the Settings, to choose a different timezone for display. This can be especially useful if you're looking at tracks you recorded on vacation in a different timezone - then if you choose the correct timezone in the Settings then the times will be displayed in local time where you were instead of local time where you are now. Of course, if your vacation spanned several timezones then there isn't a simple solution for this!
Thanks to Joachim for the suggestion!
It has been reported that a component of Apple's OSX called "GateKeeper" keeps a note of whether jar files were downloaded from the internet or generated by the user themselves. So if you download GpsPrune from this site (or anywhere else) and try to double-click the jar file, you are now presented with a confirmation dialog warning you that this jar is untrusted.
There appear to be a few different options to workaround this annoyance: right-clicking and selecting "open with" apparently lets you run it with the Java Runtime, although this is obviously more clicks. If you can tell GateKeeper to not ask again for this particular file then this may work, but I'm not sure of the conditions under which such an exception is allowed. Or you can build the jar yourself, for which you will need a Java Compiler and an installed version of Java3D. Another option is to take the downloaded jar and package it into an "app", which for some bizarre reason makes it suddenly trusted - for this you will need a build.xml file and something called "Java-Appbundler", but perhaps this solution is more trouble than it's worth. It also has the disadvantage that it seems to bundle up the entire Java Runtime into this new "app", which I assume means that every time the Java Runtime gets updated, you need to figure out which apps you've bundled the Runtime into and then re-generate each of them. Sounds like a pain.
Something which is probably worth trying is to make your own launch script, just calling java -jar gpsprune.jar and double-clicking this launch script instead of double-clicking the jar file. I would welcome feedback whether the GateKeeper still complains with this launch method, because you've generated the script file yourself and I guess it should be trusted?
Many thanks to Erich for the feedback on these issues and the xml file!
GpsPrune usually uses Java3D version 1.5.2, which is several years old now, and still works fine. If you're trying to use a more recent version of Java3D like 1.6 or 1.7 and having difficulties, then you're not the only one.
Java3D's original home page is now dead, but an organisation called "Jogamp" has taken it over and are publishing a bewildering array of files with names like jogl, gluegen and newt. Following their instructions to install Java3D on Windows 10 just gives error messages with their version verification for me, so I haven't been able to even run their examples yet. If anyone has managed to get anything working (on any platform), please let me know.
We're certainly not going to drop support for Java3D 1.5.2 as that seems to be still the stable, working solution (even after so many years). But if there's a way for GpsPrune to use either 1.5.2 or 1.6 or 1.7 then that would be the best forward-looking solution. I'm assuming that at some point in the future, 1.6 will be pushed to the linux repositories and be a painless and functioning alternative, but the fact that it's not even in the experimental repositories yet indicates perhaps that there's some deeper problem.
Things in the java world don't stay working for very long, and if you're using Java 17 you may have noticed that the 3D views don't work properly. In the console there might be an error message about an error accessing a module, and this is because of changes with Java 17 and restrictions on what is allowed to access what.
The answer appears to be to make the launch command even more complicated, like this example for debian:
java --add-opens=java.desktop/sun.awt=ALL-UNNAMED -jar gpsprune_22.2_debian.jar
This ugly command tells java to allow specific access to parts of the java.desktop module which would otherwise be forbidden. But it's ok, you shouldn't have to type in that long command every time you launch GpsPrune, just save it in a launch script somewhere (maybe somewhere in /usr/bin/) and then it'll work as before.