The prototype for map interface for bus routes experienced some downtime and halt in further development. This spring the project received further enthusiasm from the bus company in Trondheim and Professor Amble at NTNU. They found the prototype interesting and wanted further exploration of different map integrations for bus route systems.
Mats Taraldsvik, a student at Geomatics NTNU volunteered to program several demo systems for different ideas. This resulted in some excellent prototypes. Essentially the ideas developed differed a bit from the main idea of map interface. On this project the core idea was to integrate maps rather than use a map as the primary interface.
1. First test of communicating the bus route in a map.
The goal was to have the user provide the “to and from” address/bus stop then query the route answer engine (BussTUC) as well as display a map containing the bus route. The result can be found here:
The bus route calculations done in 1. was to inaccurate using Google Maps driving directions, in addition it didn’t include the walking directions very well. This demo illustrates the possibilities of including an accurate bus route as well as (simple) walking directions. Demo here: http://geomatikk.eksplisitt.net/taraldsv-bussrute/
All of the above prototypes are intended as prototypes only – and all have large potential for improvement and further integration. However, I find the idea of integrating maps in this way very handy, especially for non bus-spotters (i.e. tourists, non-frequent bus’ers etc) which probably is (or should be) the target group for a bus route query system.
Of course I still think the idea of using a map as the primary interface is a good idea which should be further explored. Mainly the problem relies on the data holders/owners of the bus route and stops. If this data is made freely available the step from prototype to “beta” could be made. (hint hint data owners…)
For the sake of data sharing you can find a dump of the current bus stops and their coordinates on: http://geomatikk.eksplisitt.net/bussMap/data/ The data is formatted in CSV with the first line being header text. Coordinates are in WKT and EPSG:4326 (WGS84:lat/lon) accuracy or availability is never guaranteed.
Ever found yourself struggling to figure out the bus routes when you are planning to get from A to B?
Obscure bus stop names are almost a de-facto standard, at least in Norway – and quite often they do not have a name (or any other identifier) at all. Even if you know the bus stop name from where you are going to take the bus and the destination, you don’t always know where these stops are.
In Trondheim a natural language system has been developed called BussTUC (Buss The Understanding Computer) or more commonly “Bus Oracle”. Here you can write, in natural language, a question about bus routes. I.e. “When is the next bus from busStopA to busStopB?” and similar. The answer is quite good, and is correct according to the current routes.
However, the problem occurs when you don’t know the bus stop name – but you know where you want to travel, or approximately where you want to travel.
To better fit this Atle and I developed a prototype of a map interface to BussTUC. In essence it is a map where you can click where you are and where you want to go. The system then finds the nearest bus stops to this and suggest the closest, all represented visually in the map. While using the map interface to input where you want to go, suggestions of relevant query to BussTUC are suggested – and a link to submit the query is provided.
The system currently knows about almost all bus stops provided by Team Trafikk and works quite well.
Extensions to the system are:
Enable for mobile devices – primarily location-enabled devices
Add the spatial route-data suggested by BussTUC in the map (i.e. draw the actual route)
Speed up BussTUC or develop own route suggestion system based solely on spatial information
Suggested improvements (numbered for identification purposes only):
Display all nearest markers regardless of selected (emphasize the one selected) [Thanks to anders]
Enable user to define “near” using circle (or similar + visual representation
On the fly display of near markers when hovering mouse (i.e. indicate what to expect from query)
Enable user to config how many markers to display near a point