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:

http://geomatikk.eksplisitt.net/taraldsv/

2. Walking directions from arbitrary address to the nearest bus stop

Using Google Maps walking directions combined with the local database over bus stops the system is able to display the shortest walking path to and from the bus stop. Demo here: http://geomatikk.eksplisitt.net/taraldsv-gangkart/

3. Combining and refining bus route display

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 more ideas and thoughts on the map/bus integration take a look at this wiki page: http://folk.ntnu.no/alexanno/projects/index.php/BussMap

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):

1. Display all nearest markers regardless of selected (emphasize the one selected) [Thanks to anders]
2. Enable user to define “near” using circle (or similar + visual representation
3. On the fly display of near markers when hovering mouse (i.e. indicate what to expect from query)
4. Enable user to config how many markers to display near a point
5. Clustering/star-shaping overlapping markers (ClusterMarker)
6. Visual-magnifier over selected areas (i.e. similar to: Map Magnifier)
7. Retain simplicity of system, regardless of functionality (i.e. enable configuration)
8. Release Open Source (CC, Public Domain, limited license?) [Atle, Magnus]

The system is developed in PHP, JavaScript with a PostGIS enabled database. Source code is available by contacting me or Atle. Give it a try and give some feedback!

http://geomatikk.eksplisitt.net/atle/buss/

Screenshot of BussTUC map interface

The system is (unfortunately) not affiliated with Team Trafikk and is a prototype not designed to scale very good.

[update:] Small bugfix, fixing last eaten and times eaten.

Tools which enable easier decision making is very interesting. GIS is said to be one such tool – however, many exist.

Every day I have to make a vital decision which will inevitably affect my life quality for the rest of the day. Namely, what to have for dinner? Trivial you say? Well, it might be – but still a trivial, vital decision needs to be taken.

Several years into the dinner-decision-making-process I have recognized that some attributes of recipees tend to manipulate the decision:

1. Well known and used recipees tend to be chosen more often than innovative recipes (at least in a hectic week day situation)
2. Time since last eaten is crucial – it the time span is less than some days it ranks poor in the decision making.
3. Suggestions are always appreciated – especially if their from the “well known set”.
4. However, suggestions are not always welcomed. The lack of creativity and part-time memento motivates for listing all well-known recipes and their attributes.
5. Comprehensive recipes are not inspiring – you know how to make them – you just need to navigate to the right one.

In a response to these recognitions I rapidly (almost lightspeed) implemented a system which provides a solution to the decision making problem. To what degree the system will perform in terms of; usefulness, technology acceptance, coding errors – will stand the test of time through comprehensive empirical research – conducted by myself with myself as participant.

Anyway, enough rambling. The point is. I have this problem of dinner decision. I eat dinner everyday. “All” others eat dinner everyday. Well, don’t need to be a Rocket Surgeon (!?) to figure out that probably some other finds use of this.

Thus, the system is open-sourced.

Licenses are probably worth about Ø, however, it is licensed under 

Essentially, do what you like – just give me a pop here if you like it:)

Requirements are; MySQL, PHP – no testing of browser support! (only FF3.0)

What the system supports:

• Automatically wrapping links with <a href>  tags
• Automatically wrapping image links with <img> tags
• Automatically make the first line a header (<h2>)
• Storing when you ate the dinner
• Counting how many times you have eaten the dinner
• Users (very low-level, but still, working)

And for all those wondering. Yes, this is a procrastination work. Master thesis writing is really inspiring – although inspiring in probably not the correct direction :)

Screenshot