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.
If you have Mac OSX 10.4, Apple provide both a 1.4 java runtime and a 1.5 java runtime. GpsPrune requires at least version 1.5 of java to run, so you need to make sure that your system uses the 1.5 runtime. By default, OSX will try to use the 1.4 runtime, so GpsPrune will fail to start with the error "UnsupportedClassVersionError". You should be able to check your java version by typing
java -version in your terminal window.
According to this explanation at macosxhints.com you can change the preferences of your system so that it uses the 1.5 runtime by default, as follows:
For Java applications that are supplied as a ".jar" file, the settings in the "Java Application Runtime Settings" section of the "Java Preferences" app will determine which Java version is used when you double-click the ".jar" file in Finder. If you drag the "J2SE 5.0" to the top of the list in the "Java Application Runtime Settings", then a double-clickable jar application will use Java 5.
There are also other ways to specify this as detailed in the above link, including adding scripts to be able to switch back and forth between 1.4 and 1.5. You should also make sure you have the update from Apple called "JavaForMacOSX10.4Release7" to get the latest version of 1.5.
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-220.127.116.11/jre/lib/fonts/, so to let java find them you need to make a link:
cd /usr/lib/jvm/java-1.6.0-sun-18.104.22.168/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".
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, don't forget to call the program "
pgnuplot" (rather than
gnuplot). If you call
gnuplot, the chart will be drawn but will disappear again immediately. To fix this, go to Settings -> Set program paths in GpsPrune, and give the path to
pgnuplot.exe instead. See the gnuplot faq for more information on this. Thanks to Javier for the feedback.
Update: It appears that in the latest Gnuplot versions 5 and above, they have helpfully decided to remove the
pgnuplot executable and suggest that the
gnuplot executable should work with pipes now. However it appears that neither
wgnuplot_pipes behave the way GpsPrune expects them to, and so without
pgnuplot it doesn't work :( For the moment it's recommended to use Gnuplot version 4.6.7 and its
pgnuplot as before, until a way can be figured out to use v5. Thanks to Nick for the feedback.
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.
Problem 1 - the track seems to upload ok but when I view the web page, it just shows me the main gpsies page and I can't find my track!. Answer - probably your username and/or password is wrong. Gpsies doesn't give any error message if the login details are wrong, so it looks like the track has been uploaded but it hasn't. Check your password by logging into gpsies.com in your browser. If that works, then the same password should work from GpsPrune too.
Problem 2 - the track seems to upload ok but I can't see the track because it's "locked"? Answer - if you marked the track as "private" when you uploaded it, then you can only see the track details if you're logged in in your browser too (obviously). Log in and try again, if you want to make the track public then go into the "Edit or delete" section and change the track status.
Problem 3 - the track doesn't upload properly, it just gives an error "Die Datei enthält keine Daten. Bitte wähle eine neue Datei aus". Answer - gpsies ignores waypoints, which means all the points with names. If your track only has waypoints, then gpsies thinks the track is empty. To turn the waypoints into track points, select a range and then use the "Delete field values" function for the "name" field to delete the waypoint names. You'll probably want to do a "Merge track segments" operation too to join the track points into one big track segment so that you can see it properly in gpsies. Now do the upload again.
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.
On some systems, the main menu and the popup menu behave properly if the window is not maximized, but get very confused about the mouse position when the window is maximized. This isn't a bug in GpsPrune, it's a bug in java, it affects all the java programs, and unfortunately rather an old problem. The symptoms might include the menus closing themselves immediately (because they think the mouse has gone somewhere else), the wrong menu entry being highlighted (even if the mouse is somewhere else entirely), the popup menu appearing in the wrong position, and other weirdness. It can also be triggered when you resize the top or the left of the window, and is really annoying.
If you're using the desktop called Maté then the problem should be fixed with the latest release. If not, there are a couple of workarounds. If your window isn't maximized but you're still having this problem, just move it a little bit by dragging the title bar. If you want it maximized, move it to the top-left of the screen first, and then maximize it (or drag the bottom-right corner to make it nearly maximized).
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.
So obviously it could be that the point was recorded in a different timezone, and then it would be nice to display the local time at that point. GpsPrune can't do this yet, it always shows timestamps according to the current system's timezone, to make things simpler for the usual case. But being able to specify the timezone inside GpsPrune has been suggested, and may be coming with version 19.
In the meantime, there is a workaround, where you can tell java to set its system timezone to a different one, just for the running of this particular java runtime instance. So you're not changing your system settings, you're just over-ruling them for this one run of GpsPrune. You can do this with a command-line argument when you invoke GpsPrune, using the
user.timezone property. You can specify this using the name of the timezone, for example:
java -Duser.timezone=America/Phoenix -jar gpsprune.jar
Or you can specify the offset to GMT in + or - hours and minutes, so for example to use the timezone which is 11 hours behind GMT, you could use:
java -Duser.timezone=GMT-1100 -jar gpsprune.jar
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!