ServiceSeeker Toronto -
Or "Where in Toronto would you like to live?"

Team:

James McCrae, Abayomi King, Andrew Borzenko

Video:

Updates:

November 21, 2009 - Added datasets for Toronto pharmacies, hospitals, and aerodromes. Updated video format again (hopefully it works for everyone this time!)
November 1, 2009 - Application updates include new datasets: public/private/separate schools, TTC stations, and banks. Interface updates include mouseover to view address information for objects on the map. Added caching scheme for lat/long results from the geocoder, and now uses either of Yahoo/Google geocoder services. Created posters for our demostration at Toronto City Hall November 2nd and 3rd.
October 25, 2009 - Added compass and legend to the application. Sorted results and used cleaner-looking table. Prepared script for presentation. Put together a video that motivates our work and shows our working prototype.
October 19, 2009 - Presented project idea to class, with slides, demographic video and demo application. Our goal is to discover more sources of data.
October 5, 2009 - Proposed project idea.

Overview:

Features:

• The process of using the application is done in just three easy steps. In fact, the third step is where the user can browse the results.
  
• Initially, a 2D map of Toronto is viewable with street names.
  
• A translucent compass is displayed on the lower left, conveying the camera's orientation relative to the North Pole.
  
• If explicit control is required, the map can be navigated using traditional 3D camera operations (pan, orbit, zoom).
  
• The user can enter the addresses of any place that he is interested in within Toronto. These locations appear as green houses on the map.
  
• There are a variety of services for the user to select, and the user can give different importance weights for each.
  
• As a user selects a service as being important, 3D buildings immediately populate the 2D map, showing the user all service locations in Toronto at once.
  
• Each service has representative 3D geometry. Colours, icons, and geometry are diverse so that individual service types are easily discernable.
  
• Mouse over any building for the name of the institution and the address, as specified by GIS data.
  
• A semi-transparent legend dynamically changes to show the relationship between each selected service, and its representative geometry.
  
• The results are displayed in ascending order, ranked quantitatively (lower values are better) based on the sum of distances to each service, multiplied by the importance weight set for each service.
  
• Arcs connect each of the residences to all of the closest services. The height of each arc indicates the relative importance weighting supplied by the user.
  
• Each row of the results table has a GO button, that when clicked causes the camera to make a transition to frame that residence and its closest services. The user can now easily left-drag to orbit that property for further inspection.
  
• At any time, the user may go back to previous steps to modify any input parameters.
  

Implementation Details:

The application is written in C++, and uses the OpenGL and QT libraries.

Our application approximates the Earth's surface locally as a plane. Since this program provides a service for a specific community, the locality of the map mitigates distortion caused by the curvature of the Earth's surface effectively offsetting the points laid on the planar map. Had the application needed to find all services between Toronto and Chicago the distortion may be noticeable, but for our purposes this geometric approximation works fine.

Our approach toward geocoding (that is, finding the latitude and longitudes) the addresses entered by the user is fairly robust: for each address, we first check for a matching string in a local cache. If not found there, we use the Yahoo geocoder (5000 requests per IP per day), and if this fails, the Google geocoder (limitations on requests per day not as clear). When resorting to using Yahoo/Google for geocoding, we of course add the newly geocoded string to the cache. The HTTP requests made by the application have a simple structure and the returned output is either a single string with a comma delimiter, or in a basic XML format, so both are easy to parse. The two HTTP requests look like:

GET local.yahooapis.com/MapsService/V1/geocode?appid=KEY_GOES_HERE&location="toronto" (YAHOO)
GET www.google.ca/maps/geo?output=csv&q="toronto" (GOOGLE)

The application contains code to do 2D Delaunay Triangulations and their dual Voronoi Diagrams. Our intention was to use these as data structures for fast indexing of nearest neighbours as well for exploring visualizations. The two images below show DT/VD for the Toronto subway stations.