What's new with GpsPrune

GpsPrune is available to download from the downloads page, with the latest released version being version 21.3. This page describes some of the features which are new with this version.

For information about the forthcoming version, see the development page.

Version 21.3

All of these fixes are quite minor, and the most important one (the scalebar fix) only affects you if your operating system uses display scaling. The last one (regarding coordinate list pasting) is just a small tweak to make pasting from TheCoordinator require fewer clicks.

Version 21.2

For version 21.2 there are two main, related, issues — the first covers pixel scaling of the whole GpsPrune application and its maps when faced with a high-dpi (tiny pixel) screen. For these screens it's common to compensate for the tiny pixels by telling the Operating System of the PC to scale everything bigger by a certain percentage to make things readable. Maybe the scaling is only 125%, maybe it's 200%, or maybe somewhere inbetween, but in this way everything on the screen is made bigger. This works for the labels and messages shown by GpsPrune, but the scaling of the maps from OpenStreetMap obviously causes unacceptable blurring and pixellation because that's what you've told the Operating System of the PC to do for you...

The solution for this first problem is to allow the Operating System to scale the GpsPrune window elements, but prevent it from scaling the actual map images. In this way the map images remain sharp (because they have no longer been magnified by the Operating System), but of course this brings the user back to the same place as before, where the writing on the OpenStreetMap images is again too small for their eyes to read easily.

So the obvious solution is to find a map source which renders the map information with extra-large fonts and extra-thick lines for users with poor eyesight and for users who have bought tiny pixels. Unfortunately, and rather surprisingly, these map sources appear to be rare, and the only ones I could find use a different tile format with 512-by-512 pixel tiles instead of the standard 256-by-256. So the second item for 21.2 is to make GpsPrune able to cope with this alternative tile format.

Another topic is Pluscodes — now the Pluscode system itself is a great invention - the system is open to everyone without paying a licence fee (unlike awkward proprietary systems like What3Words), the system is well described and can easily be implemented offline, and the result is unique. Sounds great. But then, Google starts using their own interpretation of this open system by truncating the Pluscodes and appending a city or area or country or something afterwards. So for example, when browsing Google Maps, and I click on a location, the info box tells me that the pluscode is 9GCR+M3 Zürich. That's no longer an open location code, that's a partial code which relies on the recipient knowing where the name "Zürich" corresponds to. And it's language dependent, so maybe it's "Zurich" or "Zurigo" or any other variation. That puts a terrible burden on the decoder, because they then have to look up a language-dependent string in some database, which immediately destroys a lot of the benefits of the supposedly open system. And it only saves four characters.

With previous versions of GpsPrune, it would refuse such truncated codes because they are not valid, they're not unique and it's in general very difficult to know which of the hundreds of Pluscodes matching this truncation you actually want. But with version 21.2 GpsPrune now tries to guess for you based on the current map position you're looking at. So if you're already looking at Zürich and you enter "9GCR+M3" then it'll guess the correct one (with prefix "8FVC") because that's the nearest one. Of course, if you're looking at Sardinia and enter the same truncated code, you'll get a completely different result, because that's what truncation does. Don't try to enter the "Zürich" part appended to the code, because parsing that is just hopeless.

Version 21.1

Fixes / changes for version 21

The most recent major release is version 21, which added, extended or removed several bits of functionality:

New features


Improvements gained with 1 arc-second data

For version 21, there's an extension to the SRTM functions where you can choose to continue using the lower-resolution (3 arc-second) data as before, or you can register at the NASA Earthdata website to receive higher-resolution (1 arc-second) data instead. As well as offering higher resolution and therefore more detail, it should reduce the voids and data artefacts as well.

Shown here on the left is an example of the improvements given by the higher resolution data. These screenshots are taken with the same 3d settings (grid resolution, terrain exaggeration, map imagery) but the one on the right uses the new data. You can clearly see the improvements, not just in the resolution but also the clarity and removal of the voids.

This example shows the large benefit when the terrain is steep and dramatic — when the terrain is more sane then the 3 arc-second data can often provide an acceptable representation.

A new function which geocachers might like is the new circle projection function, where an existing point can be projected to a surrounding circle with a given radius. Think of highlighting an area within a specified distance of a given location, either as a proximity zone or an exclusion zone. Depending on the current units, the distance can be given in metres or feet.

The "time estimation" function already uses a set of five parameters to estimate how long it will take you to cover the selected range of a track. Now with version 21, these parameters can be used to calculate all the estimated timestamps for each track point in the range, and set them accordingly. So depending on your use case it will either "fake" your timestamps for you, or help you estimate where you'll be around lunchtime.

The "delete by date" function has been extended with extra controls to make the dates easier to select, especially when the track contains a large number of dates. Also, the "add time offset" function has gained an extra "Weeks" field to make adding offsets of 1024 weeks (because of rollovers) easier.

There's a new function to truncate coordinates, rounding the values to a specified number of decimal digits. This is for when you want to publish some coordinates (either in decimal degrees, degrees & minutes, or degrees minutes & seconds), and want to see the effect of chopping the decimal digits off for brevity. And finally there's an extra option to use the "GTK" window style as one of the display settings, if this theme can be found on your platform.

Of course, the user guide has also been updated, and has expanded up to 175 pages. All the functions mentioned here are described in detail in the user guide, including screenshots and explanations.

Forthcoming versions

See the development page for details on what's coming with future versions.

Screenshots // How-tos // How-tos (français) // How-tos (deutsch) // How-tos (español) // User guide // Demo videos // Problem-solving // Configuration // Download // Dependencies // What's new // Development // Wishlist // History // Old Screenshots // Internet Fame // User survey