Trackserver v5.0 released

So… here we are! A new version of my Trackserver WordPress plugin was released! If you don’t know what Trackserver is, please have a look at its dedicated page on this website and the plugin’s details on WordPress.org.

Almost five years have passed since the last major release, and the last minor release, v4.3.2, was more than three years ago. In the first few months after the last release, a lot of work was done on restructuring the plugin, but the job at hand turned out to be bigger than expected, and before I could finish it, life got in the way.

So here’s a small disclaimer: after so much time, and so many failed attempts to release a new version, I decided to just do it: release a new version on WordPress.org, exactly as it currently is on Github. This means that some features, and most notably the upgrade process have not been tested very well. Version 4.3.2 is old, and I have always been running the latest code myself. It also means that not every known issue that may still be present in v5.0 is fixed. If things don’t work for you the way you expect, I apologize. Please open an issue, preferably on Github, and I’ll try to help you as well as I can.

As with every major release, there are a few big changes that deserve some special attention. Here we go.

Universal URL slug for all supported apps

In earlier versions of Trackserver, each supported client app (TrackMe, OruxMaps, etc.) had its own URL slug, which allowed Trackserver to quickly pick a the right protocol to listen for.

Trackserver v5 introduces a new universal slug, that can be used in all supported clients. The server will use different heuristics to pick the correct protocol. This means that all clients have to be reconfigured to use the new slug, which is ‘trackserver’ by default. You can configure the slug in Trackserver’s options.

To illustrate this with an example:

With v4, in TrackMe, you would use https://yourhost/wp/trackme in the ‘URL Header’ setting.

In OruxMaps, you would use https://yourhost/wp/mapmytracks.

With v5, you would use https://yourhost/wp/trackserver in either of them!

Your Trackserver profile in the WordPress backend will display this URL at the top of the page. The old, app-specific URL slugs still work in Trackserver v5.0, so nothing will break right away, but they are marked deprecated in the options page, and they will be removed in a future version.

The universal URL does, however, take two different forms. It is possible to embed authentication credentials in the URL, for apps that do not support a more secure method of authentication, like HTTP POST or HTTP basic authentication. TrackMe, OsmAnd and SendLocation are the known clients that need this. In earlier versions this was already possible (and necessary) for some apps, while for example OsmAnd would normally be configured to send the credentials as URL parameters (?username=abc&password=xyz). In v5, I decided to standardize this on having the credentials in the URL as components, rather than as parameters, although the parameters still work. For named apps, the Trackserver URL would look like this:

https://yourhost/wp/trackserver/<username>/<password>

Either of these methods are inherently insecure, because the credentials will likely be logged in the webserver’s access logs. That’s why Trackserver stopped requiring your WordPress password for these apps a long time ago. And please, please, please.. always use HTTPS!!

And that brings me to the second big change that needs some more explanation.

App passwords

In earlier versions of Trackserver, there were different authentication credentials for different apps:

• Some apps (OruxMaps, OwnTracks) were considered secure enough to use your WordPress password.
• For the other apps, each one had a different ‘secret’ in your Trackserver profile.

Apart from the confusion and the hassle of managing all these different secrets, there was the problem of sites that use SSO for logging in to WordPress, in which case users don’t really have WordPress password to use with Trackserver.

In version 5, these app-specific passwords and access keys have been transformed into ‘App Passwords’, and are now app-independent. Existing access keys are automatically converted to App Passwords during the upgrade, and will all be valid for all supported apps, including the apps that worked with your WordPress password before.

Your WordPress password will still work for those apps, but that may change in a future release. Switching to App Passwords is recommended, regardless of the app you use for tracking. The main benefit is an increase in security, because your WordPress password will no longer be necessary for using Trackserver. Trackserver App Passwords can be changed often without impacting WordPress logins. As an added bonus, App Passwords also work in WordPress installs that use SSO mechanisms like OAuth2 for user logins.

App passwords can be managed in your Trackserver profile. They also have permissions attached to them: ‘read’, ‘write’ and/or ‘delete’. Most apps only create tracks and send location updates, and they would only need ‘write’ permission for that. If you configure an app password with only write permissions, it cannot be used to download your tracks or delete anything, in case it would fall into the wrong hands.

Some apps, like TrackMe for example, have functionality that requires read and/or delete permissions. If you use that functionality, you have to configure an app password with appropriate permissions. But even TrackMe can be used for online tracking with only write permissions.

Other changes

There were also a lot of more or less minor changes, that I should mention here:

• You can now search / filter tracks with a search box at the top of the tracks list.
• A bulk action for duplicating tracks was added.
• The PHP code was restructured in a major way, separating code into different classes in a logical way.
• Leaflet was updated to version 1.9.3.
• Experimental support for µlogger.
• Numerous small changes and fixes, improving usability, robustness and error handling.

A complete list of changes can be found in the changelog.

No changes at all were made in the shortcode or the presentation side of things.

Trackserver v4.0 released

After another year of slow development, Trackserver v4.0 was released today. If you don’t know what trackserver is, you can read about it on its dedicated page on this website.

I will update this post later with some more in-depth information and some nice screenshots. For now, I’m afraid I will have to keep it down to the changelog, which you can find below. Where v3.0 was a big update on the front-end, the changes in v4.0 are much more in the back-end. Most of the work has been done in the WordPress admin, a little work was done in client / protocol support for live tracking (geofencing!) and a few minor improvements on the presentation side. Only one new shortcode parameter this time, and no real changes to existing ones.

Version 4.0 is the first version to feature a tangible contribution from someone other than myself. Thanks must go to Dainius Kaupaitis, who contributed a Lithuanian translation.

Here are the changes, plain and simple:

Added

• A track editor in the WP admin, based on Leaflet.Editable. It allows you to move and delete track points and split tracks.
• Bulk action for viewing multiple tracks at once in the admin. Editing them also works.
• Geofencing support, allowing you to hide or drop location updates within certain areas.
• A proxy for external KML and GPX tracks, to work around CORS restrictions.
• ‘maxage’ shortcode parameter to impose time-based limit on live tracks.
• OwnTracks HTTP support, locations request handling only for now.
• Bulk action for downloading tracks as GPX.
• A {distance} tag for infobar template, for total track distance in meters.
• Information about live tracking URLs and howto’s for mobile apps on the user’s Trackserver profile.
• Information on how to use live tracking in OsmAnd.
• Lithuanian translation, thanks to Dainius Kaupaitis.
• PHP coding style checks and automated testing with TravisCI.

Changed

• Make the ‘infobar’ shortcode attribute accept a string, to override the template set in the user profile.
• Show a popup on the map with an internationalized message when there are no tracks to display.
• When a (live) track that is currently shown on the map is no longer present in the server response, show a nice popup, suggesting a page reload.
• Limit the TrackMe ‘gettriplist’ command to the 25 latest tracks, serve them in reverse order.
• Increase WP-admin ‘View track’ modal window size to 1024×768.
• Updated Polyline encoder from Eric McConville to v1.3.
• Updated Leaflet to version 1.3.1.
• Updated Leaflet-fullscreen to version 1.0.2.

Fixed

• In JavaScript, store track information from the server more reliably.
• Improve HTTP responses around authentication failure.
• Recalculate the total track distance after merging multiple tracks.
• Easier access to Leaflet map object from 3rd party JavaScript (issue #9).
• Handle localized decimal numbers from SendLocation (issue #12).
• Some minor JavaScript and PHP issues.
• Many many many PHP coding style fixes.

Trackserver v3.0 released

Almost 14 months after the last big update, Trackserver v3.0 was released today. Since this is quite a big update, with lots of new features and improvements mainly on the presentation side, I thought I’d spend another blog post on it. If you don’t know what Trackserver is, you can read my initial blog post on it, and the update on v2.0 in December 2015. I will present some demos at the end of this post to give you a better idea.

First I will sum up some of the smaller changes. I will get to the big ones later.

• Leaflet was updated from 0.7.7 to v1.0.3. This brings in all the great work that the creators of Leaflet have done for their 1.0 release in September 2016. For Trackserver, this mainly means performance improvements, not to mention the mere joy of having up-to-date dependencies 🙂
• Our own hacked version of Leaflet-omnivore was synchronized with version 0.3.4.
• The PNG images that served as markers to indicate the start and the end of a track have been replaced by L.CircleMarker objects. These objects were already used for ‘points’ style tracks that were added in v2.2 and now also for the normal markers.
• The infobar that’s available on live maps gained some extra tags: {userid}, {userlogin} and {displayname}, only the last of which is somewhat interesting, I guess…
• Bugfixes!

All the tracks

Perhaps the biggest change is in the communication between the server side of Trackserver and the JavaScript that is responsible for creating the maps and drawing the tracks. Trackserver has since long distinguished between 3 basic types of tracks:

1. Static tracks from the Trackserver database, referred to by their ID
2. Live tracks from the Trackserver database, referred to by the word ‘live’
3. External tracks in GPX or KML format, referred to by their URL

It was possible to mix these types, but in very limited ways. On top of that, each track, regardless of the type, was downloaded separately, one HTTP request per track. For maps with a lot of tracks, that wasn’t the best design, performance-wise. Both these shortcomings led to a new scheme for getting tracks from Trackserver.

• First of all, it is now possible to mix all types of tracks in unlimited numbers. Just specify track=a,b,c user=@,x,y,z gpx="URL1 URL2" kml=URL3 and you get them all in one map. The ‘@’ in the user attribute, by the way, is a shortcut for your own username, so user=@ becomes a replacement for track=live, and the former is preferred as of Trackserver 3.0.
• All the tracks that need to be downloaded from Trackserver are downloaded in a single HTTP request.
• You can show multiple users’ live tracks in a single map. The live update feature can only ‘follow’ one of them, but the red markers that mark the current locations can be clicked to start following that particular track. The infobar will display the info for the track that is currently followed. On page load, the map will follow the first user that is listed in the user attribute.
• The new track loading mechanism makes use of JavaScript promises, which are somewhat of a novelty (Chrome >= 49, Firefox >= 50, Edge >= 14, Safari >= 10, all except Chrome released late 2016. No version of MSIE supports them). A polyfill for this is included and loaded automatically to support older browsers. There are multiple Promise polyfills to choose from on the web, but I went for this one, by Taylor Hakes.

Don’t forget: if you want to display GPX or KML files, you are bound to the limitations of CORS.

Shortcode attributes

The [tsmap] shortcode gained some attributes for more control over the maps and how the tracks are displayed:

• As explained above, the user attibute is now used to specify one or more users’ live maps. You need the ‘trackserver_publish’ capability to publish other people’s tracks. This capability is granted to administrators and editors by default.
• The live attribute can be used to force enable or disable live-updates. For example, this can be used to turn any track (even an externally hosted GPX file!) into a live track.
• The zoom attribute can be used for some control on the initial zoom factor when the track is first drawn. This is most useful with maps that have live tracks, because Trackserver would normally zoom in on the latest position in the track, rendering other tracks invisible without zooming out first. For live maps, the argument to the zoom attribute is absolute: what you set is what you get. For maps that have no live tracks, the behaviour is a bit different. By default, Trackserver chooses the zoom factor that makes the best fit for all tracks combined. In this case, the zoom attribute serves as an upper limit, a maximum zoom level, so you can use it to zoom out (but not in) the initial view.

Tracks with style

Trackserver already had some options to style your tracks: markers, color, weight, opacity and (since v2.2) points. However, these style options were per-map, rather than per-track. You would have all markers, or no markers at all. You could have really fat, purple lines for your tracks, but you would have them for all tracks.

Not any longer.

All the styling options now support comma-separated lists of values. Multiple values in such a list will be applied to the specified tracks in order. For example:

[tsmap track=1,2 color=red,#8400ff weight=1 points=n,y]

will draw two tracks on the map: ID 1 in a really thin red line and ID 2 in a collection of purpleish points. I think you get the idea. If less values than tracks are given, the last value is applied to all remaining tracks, so track=1,2,3,4,5 color=red,blue will give you one red track (ID 1) and four blue ones (IDs 2-5).

There is one thing to keep in mind though, when you specify multiple values. While track order will be preserved within each track type, different track types are evaluated in a specific order, and styling values are applied in that order too. The order is:

1. Static tracks (track=a,b,c)
2. Live user tracks (user=x,y,z)
3. GPX tracks (gpx=…)
4. KML tracks (kml=…)

Example: [tsmap gpx=/url/for/file.gpx user=jim track=10,99 color=red,blue,green,yellow]

In this case, the GPX track will be yellow, Jim’s live track will be green and tracks 10 and 99 will be red and blue respectively.

GPX downloads

Trackserver has a new shortcode: [tslink], perhaps not the most intuitive name. This shortcode produces a link, with which the specified tracks can be downloaded as a GPX file. Other formats are on the horizon, please open a feature request issue on Github if you need a specific format. [tslink] is used almost the same as [tsmap], except that it lacks all the styling attributes.

[tslink track=12,87,525 user=patrick]

will give you a link to a dynamically generated GPX file, containing tracks with IDs 12, 87 and 525, as well as Patrick’s latest track. There is also a class attribute that can be used for styling the resulting <a> element, and a format attribute whose only valid value is ‘gpx’ at this time.

What do you think?

If you use Trackserver, I would LOVE to know about it!! If you have problems with it, please open a support request or an issue in Github. If you are happy with it, please leave a review. And if you absolutely love it, please consider a small donation to support development. It will be much appreciated!

Demo time

A bigger collection of demos can be found on this dedicated demo page, but here are just a couple of them to give you an idea:

[tsmap user=trackserver1]:

[tsmap track=564,575,656,657,658,625,627,628,629,622,623,624,619,618,620,621,647,630,646,648,653,655 color=black,blue,red,green,#8400ff weight=2 continuous=y opacity=1]

Post-processing Garmin Zumo track logs

Whenever I leave the house to do something interesting (riding my motorcycle, snowboarding, hiking) I take my Garmin Zumo 550 with me, to log my tracks if not for anything else.
The great thing about a device like the Zumo is, that it always logs the GPS location, there is no need to turn that on specifically, so you can’t forget it either. So, if you like taking photographs, and you make sure you have a GPS log, you can easily tag your photos with a location, for example with my Taggert software.

Unfortunately, the Zumo suffers from some annoying bugs, that make using its track logs a little less efficient. As you can read on the linked page, the Zumo creates track archives in GPX files, but sometimes it duplicates data and sometimes it partially duplicates data. Sometimes it duplicates data across different files, but in the worst case, it happens that data is partially duplicated within the same file. This means that you end up with a GPX file, that contains two equally named tracks, one of which is complete and the other one is not. Nice, huh?

The amount of tracks in a single archive file and the timespan they were recorded in are not really predictable. I guess it mostly depends on the total number of track points in all tracks together. For my own purposes, it would be most convenient to have all tracks from a single day together in a single file. And of course, there should be no duplicate tracks and the tracks that remain should be the complete ones.

To post-process the Zumo’s track logs, I created some Python scripts. The README on Github pretty much explains what they do in detail, but in short, they do what is necessary to get what I want:

• One file per day, containing all tracks for that day
• Only the complete tracks are kept, (incomplete) duplicates are discarded

The scripts are written in -and tested on- Python 2.7 on Linux, but since they don’t have any external dependencies, I don’t see why they shouldn’t work on Windows or other platforms as well. They are released under the Apache 2.0 license. Please use them as you see fit.