Kelso’s Corner

I published a Google Maps mashup for The Washinton Post on January 20th (view at washingtonpost.com/taxifares/) that allows a consumer-focused price comparison between the current zone-based fare structure and the planned time-distance meter system. The tool allows a user to enter their own route or try a sample route.

The approximate route is plotted on a Google Map and the prices are shown and compared to calculate the taxi rider’s savings (or loss). The map is fully interactive: markers can be repositioned if the user don’t know a street address but does know a map or satellite image location. The switchover to time-distance meters is now scheduled for May.

This blog post will describe how and why the interactive taxi fare estimator was created and share who’s using the tool and determine if the zone or meter system would be cheaper based on actual usage with a sample pool of nearly 17,500 unique visitors and over 50,000 trips calculated.

 

Screenshot of final Washington Post District Taxi Fare Estimator interactive.

Background

One of my bosses, Larry Nista, approached me late in 2007 about building an online tool to compare estimated prices between the zone and meter taxi fare systems. Our department had already been experimenting with simple online content this seemed like a good project to create a more complex Web 2.0 site where a user was given a higher level of interaction and meaningful, customized results. A non-work friend and I had previously talked of making a cell phone text based service for determining zone fares so this projected peaked my curiosity.

My previous experience were relatively simple projects like:

• Dog Parks Mashup
• Iraq Bombing Hotspots
• Events in Burma
• New Orleans Flooding Recap and
• Cape Cod Sea Level Rise

Most these projects are very procedural, 1, 2, 3 style projects with a limited set of outcomes that could be hand designed and linked. The taxi project required a more general solution. I had already been programming in ActionScript for Flash and was fairly competent at that (several unpublished projects) and my experience with the Dog Parks project showed me how similar ActionScript was to JavaScript, which is the language Google Maps API is written in.

It became obvious this project should be done using the Google Maps API early on and I set about learning all the different data structures and functions. At first I thought I could use web services provided by the District of Columbia GIS mapping team online, but it would still have needed to combine that with the Google Maps map tiles so I decided to do all the mapping with the Google Maps API.

Project Phases

1. Conceptualization of the project:
   

   Compare fares between meter and zone taxi fare rate structures

2. Discovery.

DC GIS web services, Flash, Google Maps API, HTML, CSS

3. Design.
   

   Mockup in Illustrator of basic features and design

4. Implementation.

Dreamweaver HTML, Javascript coding, more discovery of Maps API routine

5. Redesign
   

   Increase user interactivity (draggable map markers)

6. Redesign based on comments

Price comparison, look and feel & bug squashing (cross-browser compatibility)

7. Final implementation and release
   

   Including tracking code via Google Analytics

Why Google Maps API?

I used Google Maps API as it could quickly calculate route distance and estimated travel time. I could use the API to draw the map and the route line and icons interactively. Finally, I could use it to do basic map algebra like “is the start point in what taxi zone polygon” which was needed to determine the zone-based fare.

The Washington Post had also been investigating how we could better integrate Google mashups into our online workflow and this was a good project to learn more about the API. I have written previously on mashups in the news here: http://kelsocartography.com/blog/?p=15.

My programming skills had to improve during the project and the extensive Google Maps API learned. I had a general solution working in a couple days but it was not very intuitive and it did not calculate good wait times based on heavy traffic. I’d say 15% to 20% of the time was spent figuring out how to calculate traffic wait times. Professor Mahmassani proved invaluable to this task due to his familiarity and expertise with the topic and providing of source material with discussion and formulas. I made contact with him while he was still at Univeristy of Maryland at College Park thru a colleague at The Post.

Similar Projects Around the Web

One of the best comparable taxi fare mashups out there is from Yellow Cab NYC. They don’t have draggable markers. But you can click and click to set start and destination and the address fields update to the street address equivalents for the map markers. It also shows tips. But the site does not take into account traffic wait times, although it has a good “rush hours” time menu since the charge is increased during certain periods. Under the latest plan for DC there will be no more rush fees.

Another decent taxi fare mashup is from Taxi Wiz, which has a DC edition. They have a Airport or Landmark popup for start and stop locations. They feature a similar “click and click” map based start and destination interface with no draggable markers. The pricing for DC is completely wrong (mileage versus zones). User beware!

The District of Columbia GIS team has had a web-GIS tool online for several years that works well for the zone system. It has not been updated for the time-meter system yet. Their tool has the "point of interest" search as well as specific DC taxi fare pricing additions. This was the best tool, until mine came along 😉

 

INITIAL OBJECTIVES

1. Compare prices between zone and estimated meter based fares
2. Let the user pick their own route (start and destination addresses)
3. See route on a map
4. Advanced settings for additional passengers, large luggage, radio dispatch, snow emergency and other DC specific fare parameters.

DESIGN LESSONS

1. Is a Google Mashup appropriate?

• Yes, street-level analysis and routing information is key. By “outsourcing” the mapping to Google I was able to concentrate on building a good user interface and investigate the traffic time equation.

2. Provide an entry point

• Provide a clear entry point and flow for the user via the numbered headers (1) Plan your travel and (2) Compare estimated fares.
• In the first section, the user can either try one of our sample routes or create their own. The first is useful for getting a feel for how the tool works. The 2nd is for the user who wants more details.
• The interactive map with draggable start and destination markers is useful for users who cannot recall street addresses.

3. Stay focused

• Will the new system benefit the consumer? Price compare and tell the user.
  
• Pricing is dependent on traffic wait times. Provide prices accordingly but using a smart formula.
• The map shows the route and acts as an interface to adjust the route only.
• The map is separate from the routing and pricing sections. We are primarily interested in the prices. Many mashups make the mistake of cramming these primary elements onto the mashup.

4. Provide levels of information for basic and advanced users

• The advanced settings area allows meter-specific and general-fare pricing parameters to be set.
  
• onDrag marker events make it easy for the user to reposition the route start and destination markers live on the map without worrying about exact street addresses. Over half the visitors to the interactive use this "onDrag" feature.
  
• mouseOver “tooltip” behavior tell the user they can reposition the markers or zoom in to them.
• onClick events for the map markers zoom the map to that neighborhood in satellite view to enable precise placement of the start and destination on an individual building.
• All three events supplement explicate buttons to do the same action. These features supplement the explicate GUI––they are not hidden features but power-user bonus features.
• There is a feature where points of interest (such as “us capitol” or “white house” or “ballpark”) can be typed into the address fields and it will be converted to a street address automatically.

5. Other Map Features

• The map automatically changes to satellite view when it zooms in past a certain level. There is no need to include a button for this.
• The map automatically zooms to the correct extent based on each new route. This had to be writen by hand as the Google function did not work reliably.
• There is a Google Maps API feature where the area of interest can be set to improve geocoding of user addresses that are incomplete (street address only with no city or state).
• When the sample routes are used, the addresses are still put into the start and destination fields. When a map marker is dragged the address changes to “Map location”.
• The start and destination map symbols (markers) are keyed in the Plan your travel section.
• When the map first loads, there is a legend which explains the map line symbols (blue, black, and red lines) used in the mashup.

 

Screenshot of final Washington Post District Taxi Fare Estimator interactive.

Collaborative Project

This was a large project that I undertook as lead designer and programmer over several months of on-and-off again development. While it was my project, a variety of people provided assistance along the way. Primarily my coworkers at The Washington Post newspaper (print side) provided design critique and suggestions (Gene, Laris, Larry, etc). I worked hard to make this project look like a traditional Washington Post print graphic but translated onto the web to take advantage of that medium.

Coworkers at WPNI (Washington Post – Newsweek Interactive) provided technical support in HTML and Javascript programming. They helped me implement the design interface in HTML and how to implement programming functionality. They also provided countless hours of testing and troubleshooting solutions, especially related to cross-browser compatibility between Internet Explorer, Firefox, and Safari.

I also thank several friends outside of The Post who I have known since university. We regularly critique each other’s work as it develops and their insight was invaluable. The final design of the price comparison is inspired by a conversation I had a Christmas while visiting a friend in San Francisco. Professor Mahmassani was crucial to understand and calculate non-linear traffic wait times.

Original sketch for Washington Post District Taxi Fare Estimator interface (Gene Thorp).

Promotion of the Interactive

There was a full page spread in that Sunday’s Commuter Page (January 20th, 2007) about the taxi fare changes and promoting the online District Taxi Fare Estimator with screenshots, explanation, and URL. At the same time washingtonpost.com promoted the tool on the homepage for a few hours. This lead to the first spike of readers. Click here to see PDF of the newspaper page promoting the interactive.

Feedback

The general response at the newspaper and website has been great. Management is encouraged by the project and would like to see more like it. I have received several emails about this project after it published from readers. That is on par for larger projects here. One was generally praising, two had nitpicks with how the site functioned.One pointed out an error in the calculations due to zone-boundary logic. For instance: U street is the zone boundary and the boundary runs down the center of the street. But if you start in Zone 1 (downtown) and get let off on the NORTH side of U Street, even though that is technically the next zone up, because it is on the boundary street, it is just counted as 1 zone traveled, not two. I have already fixed the nitpicks but I am still programming the solution for the boundary condition.

Usage Statistics

There have been around 17,500 unique visitors with over 52,500 trips calculated with an average time on site of 4 min 10 sec (very good). Most visitors to the site are from DC (45%) while the metro area (including DC) is 76%. Worldwide: 96% are from the US but there have been visitors from 98 countries (every continent). There have been visitors from every US state except Montana. These stats reflect the wide readership of The Washington Post and the nature of our readership in the DC metro where people from all over the globe visit and travel out from.

Page views highly correlate to promotion in the newspaper and the website due to pegging with news stories (the taxi strike last month, for instance).

However, there is a steady stream of visitors to the site on a daily basis from bookmarking it and search engine hits. Small daily numbers but this “long tail” forms nearly half of the overall pageviews.Only 58% are using Internet Explorer, which was surprising. 86% on Windows. 40% have 17″ monitors but the remainder have much larger (eg more affluent, not just gov’t workers on old PCs). At this point 10% of visits are returning, so I assume people are using the site for zone calculations to determine fares today, not just estimate for May’s change over.

There has been some discussion on how to redesign the tool to be promoted more directly in pages with the taxi content instead of linking to a separate full-page tool.

Which Fare Structure is Cheaper?

Hands down the planned time-distance meter system with taxi fare interactive users taking 38,000 trips (72%) that were cheaper than the existing zone system. Surprisingly 14,500 would still be cheaper under the existing zone system. This has to do with trips that are from the far edge of one zone area to the opposite far edge of the same zone or the next zone over. This longer trips will be more expensive under the new system, especially when traffic congestion charges are factored in.

Most users went a total of 2, 3, or 4 zones (40% of trips) or 2.8 miles. Half the trips taken with the estimator start downtown. Excluding the downtown trips, 40% take place in Northwest. The remaining 10% are sprinkled throughout NE and SE evenly. This data is determined only from the start and destination zone–it is not collected on an address basis!

The DC Government estimates taxi drivers will face a sharp decline in yearly wages because of the shift to meters. It remains to be seen if more people will take taxis with the simplified and cheaper system to make up for the loss in individual fare profit.

Resources

• Get Maps API key
• Official Google Maps API Documentation
• Blackpool Community Church Google Maps Tutorials
• Google Analytics

• Zone map and fares
• Planned distance-time meter fares
• Adjustment to meter fares

Tags: district, fare estimator, google maps mashup, how-to, Mashup, taxi

This entry was posted on Thursday, March 20th, 2008 at 7:40 pm and is filed under Best practices, Design, Google Map Mashup, Interactive, Mapping, Mashup, Self promo. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.