Oxfam Trailwalker Madrid 2017

I have been a member of Oxfam for several years now, but only last summer I learnt about the Trailwalker. As you can read in their webpage:

Trailwalker is the greatest team challenge of the world fight against poverty. The challenge consists of four member teams walking 100km in less than 32 hours. The members of the team must start together, stay together and finish together.
The aim? To fight poverty and injustice around the world. That is why the teams commit themselves to obtain donations for Oxfam Intermón. Each contribution improves many lives, so encourage your family and friends to help. 

[...]

Trailwalker was originally a military training exercise for the Gurkha Regiment in Hong Kong. In 1986, it became an Oxfam event for fundraising and since then it has grown to become one of the most important sport challenges, held annually in different countries around the world.

100km in less than 32 hours and obtaining at least 1500€ in donations requires some work, so after talking with my family and convincing a group of colleagues at work and friends, we managed to set up a team around November 2016 for the Trailwalker Madrid 2017. Below is the team webpage (as per June 2017, after having finished the race and having obtained 1830€ in donations).



The Trailwalker Madrid 2017 webpage is very well organized, with loads of tips on training and fund raising. We tried to read all of it and get organized as soon as possible.

Fund raising

For fund raising we didn't organize any events, and mainly we just created a poster to put up at work and to distribute it via:

• e-mails to work colleagues and friends
• WhatsApp messages
• word of mouth

The poster looked like this (version in Spanish):

We also created a Facebook page (https://www.facebook.com/astrowalkers/), so that people could follow our training and fund raising progress.

I have to say that fund raising was more difficult than we had anticipated and full of surprises (in some cases total strangers donating large sums of money, while no money coming from people we were 'sure' would help us). In any case, at the end we managed to go well past the minimum required of 1500€ and collected for Oxfam a total of 1830€.

Training

All the members being quite busy at work, we decided that we would train individually most of the time, but try to meet once per month to do a team session together. That would mean six training sessions together (December - May). Simone had some trips and could not join all the sessions, but he is the fittest of the group, so he was going to cope well anyway. The six training sessions were:

Training 1: 

Powered by Wikiloc

 

 Training 2:

Powered by Wikiloc

 

Training 3:

Powered by Wikiloc

 

Training 4:

Powered by Wikiloc

 

Training 5:

Powered by Wikiloc

 

Training 6:

Powered by Wikiloc

Race day

After all these preparations, we were quite ready for the Trailwalker, but we were always assuming that the weather was going to be hot and dry (which suits us nice, living in Tenerife). But as the race day got closer, the forecast was of rain (a lot of rain and storms), which made me quite anxious and concerned about blisters, my main issue in all the previous training days.

As it turned out, the weather was quite good throughout the race, except for some rain and hail in the first hours (there was also quite a heavy storm the following day, more or less about 30 hours after the starting time, but we managed to avoid this one completely, having finished in about 27.5 hours).

The race started on June 3rd, at 09:00. Not being a competitive race, the atmosphere was really friendly and supportive of each other. In total there were six intermediate stops, where everything was very well organized and Oxfam provided water, fruits, coffee, etc. plus physiotherapy and feet care services, and our support team was always ready to prepare us some meal or get us anything that we might need.

In total it took us some 27.5 hours to complete the 100km. Our original plan was to try and do it in 24 hours, but in the end our stops were a bit longer than planned, and towards the end we started having some serious blister issues, which forced us to go much slower. Here it is the final route (more detailed stats can be seen at: https://www.endomondo.com/users/10020566/workouts/939149852)

Powered by Wikiloc

Some memories from the day:

 

 

Overall, this was a fantastic experience, even more when we know that all the effort we made was for a good cause. For the Trailwalker'17 edition (consisting of three races: Girona, Euskadi and Madrid), all together we were able to raise for Oxfam Intermón a total of 1059384.53€, which will be used to help improve the quality of life of many people around the world (http://trailwalker.oxfamintermon.org/en/about-trailwalker).

Well done everyone involved and many thanks to all our supporters!!

GPX hyperlapse

In the last post I described how to create a virtual hiking tour (http://angel-de-vicente.blogspot.com.es/2015/04/creating-visual-tour-of-hiking-tour.html), and then I wondered if I could do something similar, but at street level, taking images from Google Street View. The goal was to take GPS data (either from a route that I have followed myself on foot, on bike, etc. or from data points generated by the driving directions of Google maps).

If we want driving directions from Google Maps, one easy way to generate GPS data points in a .GPX file is to:

• use google maps to generate a route

• grab the URL generated above in Google Maps and feed it to GPS Visualizer to get a .gpx file with the GPS data points following the given route

If, instead, we want GPS points from a route that we did previously, we can just, for example, download the GPX file directly from Endomondo.

At these point, we can try our luck with sites like http://gpxhyperlapse.com/ or http://alban.atchoum.fr/hyperlapse/ but if we want finer control, we will need to do some extra work.

If we use the .gpx files above, the results will not be very good, since there will be not many data points and/or due to the GPS receiver limitations, the points can be outside roads, resulting in shaky and jumpy street view images. So, we can do two things to improve this.

First, we are going to generate more data points by interpolating, with GPSbabel  (see http://www.gpsbabel.org/htmldoc-development/filter_interpolate.html) For example, to get data points every 5 meters:

gpsbael -i gpx -f track.gpx -x interpolate,distance=0.005k -o gpx -F newtrack.gpx

Second, we can try to fit those GPS points to a proper road (assuming we were on a bike tour, running, etc. on roads). To do this, we can use the site https://mapmatching.3scale.net/. You need to apply for an API key. Once you do that, we can convert our original shaky GPS data with

curl -X POST -H 'Content-Type: application/gpx+xml' --data-binary @newtrack.gpx "http://test.roadmatching.com/rest/mapmatch/?app_id=YOUR_APP_ID&app_key=YOUR_APP_KEY&output.waypoints=true" -o output.xml 

This works OK with the GPX file from Endomondo, which has time stamps, but it will break (the developer knows about this, so perhaps it is fixed when you try it) for the Google Maps generated GPX file, which doesn't have time stamps. To fix it, we just have to add timestamps to the GPX file before accessing test.roadmatching.com. So I turn all the trkpt from something like:

to something like (you can just put the same timestamp for all the trkpt's):

The output from TrackMatching matches the roads much better, hopefully, than the original GPX data, but it comes in an unfamiliar format that I have not been able to convert easily to a GPX file (if you know how to do it with some GPS conversion software, please let me know). I was too lazy to write a script to do the necessary transformations automatically, and instead I used search/replace in my text editor, so that from the output.xml file I extract all the wpt ....="" stuff and modify each waypoint of the form wpt y="28.465961" x="-16.269638" to (if you don't know how to do search/replace with regular expressions, this is a good time to learn!):

Now in the .gpx file obtained with GPSBabel, delete all the trkpt entries (so there will be an empty section, and in their place put all these new trkpt definitions.

With the help of GPS Visualizer again, you can verify that the new .gpx file is matched to roads better than the original one. Just use the options to convert a .gpx file to Google Maps as follows:

As an example, this is how the track looks like with the .gpx file directly downloaded from Endomondo:

And this after massaged by TrackMatching:

Now that we have .gpx files with many data points and nicely following roads, it is time to get the Google Street View images to put everything together. The code I used is a minimal variation of the code available at http://pastebin.com/FnsY8QFR (discovered at http://www.cyclechat.net/threads/my-cycling-video-c-o-python-strava-google.135566/). In case the pastebin expires, I uploaded the code to GitHub (https://gist.github.com/cac3a4434c4bd5b756ea.git). You can download it with:

git clone https://gist.github.com/cac3a4434c4bd5b756ea.git


The file gpxhyper.py is still very crude, so you will have to change things by hand. It will work by default on a file called input.gpx (either change that or make a symbolic link named input.gpx pointing to the file you want to work with). Next, leave uncommented the appropriate line: for the .gpx file coming from Endomondo:

gpx_trackseg = gpx_file.getroot()[1][3] # For Endomondo .gpx

For the .gpx file coming from Google Maps:

gpx_trackseg = gpx_file.getroot()[3][1] # For GPSBABEL .gpx

You should also have a Google Street View Image API Key (if you don't have one, you can get instructions at https://developers.google.com/maps/documentation/streetview/#api_key). Put it in gpxhyper.py (in place of YOUR_GOOGLE_API_KEY) and execute it as:

python gpxhyper.py

and all the corresponding images will be downloaded from Google Street View.

From these images use your favourite method to create a video. For example:

avconv -r 10 -i %5d.jpeg -b:v 1000k input.mp4

(Downloading the images takes a while, so make sure you calculate the appropriate rates beforehand. I found that around 10 FPS is a good number above (the images are taken at intervals, and if you try a normal video rate of 24FPS, the video will be too shaky). Assuming the 5 meters interval given to GPSBabel above, this will mean a virtual speed of 50 m/s or 180 km/h. Depending on the effect you want to create and the place where the images are taken (for example a city vs. a very open road with nothing near), this might be too fast or too slow. You will have to experiment a bit).

As an example, here it is the result for an Endomondo generated track (a bicycle route):




And here for a .gpx file generated via Google Maps as explained above (for this one, at the beginning there were some 'bad' frames that I removed by hand with Kdenlive video editor):

Creating a virtual hiking tour

Lately I'm back to hiking and when I do a route I use my mobile phone with a GPS application (at the moment I use Wikiloc) to record the track. Last week I climbed Teide, and Wikiloc offers the possibility of easily embedding the data from their site, which is nice:



But you shouldn't stop there and you can also create a guided tour of the route. Doing it is quite simple, and I list below the steps I took to create the video tour of the Teide climb:

• First, download the file from Wikiloc in KML format, and open it with Google Earth. Then, select the route and you can see an icon in the right part of the left panel that says "Play Tour" (play it a couple of times first to cache all the necessary images). Options to modify the speed, camera angles, etc. are available at Tools::Options::Touring.
• Then, when we are ready, we just play it and at the same time record it with, for example, Kazam (30 FPS gives pretty good quality).
• The resulting file is pretty big. To make it smaller we can use WinFF with output as MPEG-4 (very high quality). As an example, from 656MB this turns the file into 71MB, which can now be mildly edited with Kdenlive, and we render it all together for Web site::YouTube 1280x720. The resulting video is now 51MB, and we can upload it directly to YouTube: https://youtu.be/HgzXkAG7XjM