Feature: Display multiple tracks on a map

Title

Display multiple tracks on a map

Id

0011

Requestor

Ian

Status

Closed, 3 Jun 2009 12:06

Progress

Description

Currently each track is presented in isolation. This makes it difficult to see how each track relates to those around it. A consequence of this isolation is that it is difficult to plan a ride that includes several tracks.

It would be good to show how nearby tracks relate to each other. One possibility would be to display the 'Connecting Tracks' on the map in addition to the track being described.

Perhaps the 'Connecting Tracks' list could be redefined to be a list of 'Adjacent Tracks' that it is helpful to display on the same map, even if they don't actually connect to the track being described.

The additional tracks could be displayed in a different colour, to distinguish them from the main track of interest. Displaying a track in a colour that differs from the kml style is possible, though it requires some JavaScript to parse the file and set the colour manually, rather than using the defined style.

A key problem with this idea is that the Google Maps API doesn't cope well with multiple kml files or many track points. That is, the map displays very slowly or not at all if there is too much data. It would take some investigation to find a solution that has satisfactory performance.

Comments

Yes showing the 'connecting' tracks would be good.

I like the 'adjacent tracks' idea. A long time ago there were 2 categories, 'connecting' and 'nearby' but I simplified it.
Jonny, 18 Mar 2009 05:53


I will investigate.
Jonny, 18 Mar 2009 05:54


The problem with displaying with a lot of points on a map can be resolved by using the google maps api "encoded polyline". http://code.google.com/apis/maps/documentation/overlays.html#Encoded_Polylines This allows the lines to be simplified when zoomed out which improves performance on maps with lots of lines. This would involve parsing the kml to produce the encoded polyline.
capuchin, 22 Mar 2009 15:36


I had a play with encoded polylines a few months ago. At that time they improved the map performance, but still often didn't work very well.

However, it seems that the API's performance has since been improved significantly. I've mocked up an example to show how multiple encoded polylines display on a map. This is just a test of a few ideas, rather than a firm proposal.

The most important aspect is that it works, and hence drawing multiple tracks on a map looks to be feasible.
Ian, 26 Mar 2009 19:25


Another approach to this problem could be to use the google earth browser plugin. I have not had a opportunity to test this but it may be worth investigating: http://code.google.com/apis/earth/
capuchin, 27 Mar 2009 10:10


Tracks already includes the Google Earth browser plugin - it is the "Earth" map type button at the top-right of each map.

Unfortunately, the Google Earth plugin is currently broken, as it won't display the track lines. This seems to be a problem with Google's API rather than anything we've done.
Ian, 27 Mar 2009 11:14


Looks like the Google Earth API is fixed - I can see the tracks in "Earth" map type now, but you don't get the nice labelling when you scroll over them. Nice encoding example Ian, did you drop each track into the HTML form encoder or download their Java encoder?
Graham, 19 Apr 2009 09:44


Graham - yes, the Earth API has been fixed, so it shows the tracks again. However, it is slow to load the 37 tracks in my example and, as you say, the labels don't work.

As for encoding, I used this form. There are also scripts available at that site for automatically encoding tracks, which may be more useful than the manual approach I used for the example.
Ian, 19 Apr 2009 21:30


Ian, that's awesome! I will probably start work on this by using your examples and code. Is this ok by you?
Jonny, 27 Apr 2009 01:09


Jonny, feel free to use the code from my example – that's what it is for.

I've been working on a further example that adds/changes some features, specifically:
- uses xml data files, extended to include more data.
- the xml could easily be extended further – perhaps consistent with your 27 Apr comment on Issue 40?
- the lines on the map are formatted to reflect the track condition and grade. That is, the track colour is a function of grade and the track line width is a function of condition (narrow for single track, wide for roads).
- Earth map type interaction is possible, but it is currently incomplete.
Ian, 28 Apr 2009 01:51


I have put up the first cut onto Stage (stage.tracks.org.nz)

Current functionality:
- multiple tracks shown per page
- encoded data held in db
- current prod kml files will get parsed at prod release time
- uploading a new kml file will encode new path
- multiple paths per kml file supported (sub-path names are currently lost, I will fix this)
Jonny, 28 Apr 2009 04:08


I had a quick play with the stage.tracks.org.nz version. Looks good so far. A couple of observations:
- it doesn't cope well with tracks that have markers, as neither the track nor the map controls are shown. eg. Spoonhill.
- I'm concerned that my further example is trying to show too much information at once. ie. the proliferation of colours is a bit ugly. One possibility would be to only have two colours (main and adjacent tracks - like example 1), and have the line widths vary by track type. Then on mouseover show a line colour for the selected track that relates to its difficulty. Or something like that.
Ian, 28 Apr 2009 13:26


Some more (slow) progress on Stage:

First of all thanks for the cool examples Ian, they rock!

- I have used a little of v3 in the current iteration (mostly mouse-over of tracks, with bug: each sub-line has the main track length).
- I might leave adding multiple colours/line widths to a future version
- sub-path names are included
- markers are still being lost. Are these just the youtube videos? I can add an optional media section that has video and picture links
- I want to move to a system where a "track" can be made up of multiple smaller tracks, nearly there now. Each of these smaller tracks would have their own length and profile.
- The xml output idea would not use files but an api type system, seems to be the way these days. Input files for track paths should be via kml or gpx I think...

Jonny, 17 May 2009 05:35


I've added some more pieces of the puzzle in another example. This one uses image overlays and a few other tricks to get around the limitations of the Google Earth map type. The result is that the 2D and 3D map types interact in more-or-less the same way. There are some quirks though, as noted in the bullet points.

As for markers, there are a few variations scattered around, eg. Mt Climie has a couple of peak markers.
Ian, 18 May 2009 21:28


Another issue to consider: in a few places I've used different colours to indicate different track access types - for example, 'Foot only' for the middle section of Duck Creek, or track sections under construction for Car Parts Extension. It would be good to retain this sort of distinction and apply it consistently (not that I always have).
Ian, 19 May 2009 07:37


I have implemented some of this. To make sure it is continued refer to feature 0045.
Jonny, 3 Jun 2009 12:06

Created

17 Mar 2009 21:13

Updated

3 Jun 2009 12:06


Show all

 
A Cheeky Monkey production, sweet as bro!