Feature: Automatically populate Adjacent Tracks list


Automatically populate Adjacent Tracks list









Currently the Adjacent Tracks list needs to be manually populated. It would be helpful if the list was populated automatically when a track is created or a map's view is updated.

It should still be possible to add Adjacent Tracks manually. For example, adding a track that is just outside the map view, but which is a natural extension of the current track. Manually removing automatically added tracks should also be possible (though perhaps hidden rather than removed – see Status comment below).

There's a limit to the number of tracks that can be displayed on the map, so there would need to be a mechanism for limiting the number of automatically added adjacent tracks – maybe based on the adjacent track's distance from the current track? This distance parameter should be a user input. An additional rule to limit the number of tracks would be to restrict automatically added tracks to only those within the current's tracks area (perhaps as a user-selectable option).

It would be a computationally intensive task determining whether any part of any track is visible within the map view of the current track. However, shortcuts are possible – for example, for each track store its north, south, east, and west bounds (recalculated whenever a track's kml file changes) then determine if the rectangle defined by those bounds overlaps the rectangle defined by the bounds of the current track (extended by a margin to allow for nearby tracks that may fall just inside or outside the map view). There are standard procedures for determining if rectangles overlap.

Perhaps mark each adjacent track in the list to indicate its status (visible when editing the list): ie. automatically added and displayed; automatically added but manually hidden; and manually added.


Nice. This will not be hard to do. Cheers!
Jonny, 15 Jan 2010 10:26

As an experiment to see how many tracks the Google Maps API can handle, I've put together a set of test cases.

As the number of simultaneously displayed tracks increases, the browser can become sluggish – especially when zooming in/out. Firefox generally performs much better than Internet Explorer. The speed of the computer also matters. For example:

On a fast PC, running Firefox 3.5.6, 800+ tracks is a bit slow to redraw when zooming, but otherwise performs well.

On a slower laptop PC running Firefox 3.5.6, the limit for reasonable performance is around 100 tracks.

On the same laptop but using IE 7, 50 tracks would be about the limit of acceptable performance.

Ian, 30 Jan 2010 13:57




8 Dec 2009 07:29


15 Jan 2010 10:26

Show all

A Cheeky Monkey production, ooh yeah!