See the Prototype!

See our latest prototype at www.BikeZip.com!. The prototype site lets you identify routes but doesn't let you save anything yet. Consider it a proof of concept. It relies heavily on the Google Maps application programming interface (API).

What's New

8/19/08 Updated the data model. Added concept of hidden bikeways to include minor residential streets that would clutter up the map if displayed. Made minor changes to list of segment fields.
8/25/08 Added more detail in user interface description.
8/31/08 Started adding design text.
5/27/09 Corrections and adjustments on data fields.

Why BikeZip?

That's why the Collaborative Bike Map Project was conceived… to bring cyclists' knowledge and needs together. We are building a website called BikeZip.com (or just BikeZip) that will let cyclists work together to create an enormous map of roads and bike routes, wiki-style. Our prototype website, showing how users might enter route information, is here. We believe collaboration is the best way to provide a comprehensive, accurate and current map that's truly useful to cyclists, pedestrians and others not well-served by standard maps.

This project sponsored in part by Montgomery Bicycle Advocates (MoBike), a group dedicated to improving bicycling in Montgomery County, Maryland.

Basic Features

Our plan is for BikeZip to initially provide the following features, then expand from there:

User Interface and Data Model

We want BikeZip to be known for the usability of its interface and for the robust information it can store for each road and bikeway.

The BikeZip map consists of a Google map overlaid with colored lines representing bikeways. BikeZip is designed to store information about every road and path, regardless of bikeability. Any street or path stored in the database is called a route. A route corresponds to one name, so if a street changes names in the middle it is considered two routes. A route is broken up into segments such that one segment ends where the next begins. Segments correspond to sections of a route with unchanging basic characteristics such as bikeway type and road skill level. Routes or segments of routes deemed useful for bicyclists are designated as bikeways and assigned a bikeway type. Bikeways are displayed as color-coded lines. Bikeway segments have an associated zoom level, which indicates the smallest (broadest) zoom level at which the segment is still to be displayed. By default, non-bikeways are not displayed at all by BikeZip (excluding whatever is displayed by the underlying Google map). Minor bikeway segments that would clutter up the map, such as minor residential streets, are tagged as "hidden" and are no displayed by default. The map user may explicitly ask BikeZip to display hidden bikeways or non-bikeways.

Route Fields

The following displayable information is stored for each route:

Segment Fields

The following displayable information is stored for each segment:

Points

A route can be viewed as a series of BikeZip points connected by straight lines. Points are defined at segment start and end locations (boundary points), intersections (intersection points), heading changes, and wherever a point comment is needed (comment points). Points are not defined anywhere else. Point comments must be at a point, but span boundaries do not have to be points.

The following displayable information is stored for each point:

Comments

Comments are not going to be implemented in the initial release, so the following specifications may change. Informative comments can be attached to points along a route or to arbitrary stretches of route called spans. Comments are noted by icons whose image indicates the comment category.

Point comments are comments attached to points and have text such as "gap in shoulder", "blind curve", "bike shop", etc. Point comments have the following fields:

Multiple point comments are not allowed at the exact same location. Multiple points with comments can lie very close together (above some distance threshold), in which case the user may have to zoom in to click on each point's icon individually. For multiple conditions (comments, alerts, etc.) at the same location, one comment point must be defined to cover all the conditions.

Span comments are similar to point comments, but apply to a specific length of route (a span) defined for that comment. Span comment text might include "steep hill", "lane narrows", etc. They too have category-specific icons. The icon of a span comment will be displayed somewhere along the span. If part of a span is clipped at the edge of the visible map, the icon will be displayed along the visible part of the span. Spans can overlap each other and can overlap more than one segment (but not more than one route). There is nothing to prevent two spans from covering an identical section of route.

Comment icons are only displayed if that part of the route is not hidden due per zoom level, filtering, minor bikeway hiding, etc. If the comment applies to more than one segment (e.g. a long span comment or an intersection point comment), at least one of the segments must be visible for the comment icon to be displayed. An exception may be bike repair icons (not initially supported), which can be turned on or off as a group.

Selecting Items

The user may select a segment directly by clicking on the line of that segment. This automatically selects the containing route as well. Selection behavior with respect to map display is as follows:

The user may select a comment point or span by clicking on its icon. This also automatically selects the parent segment (no more than one) and route.

Information Display

BikeZip displays textual information about currently selected items in the information pane. This pane has the following areas:

Pop-up bubbles are used to display information about selected comment points and spans. The simplest design is to have the bubble open whenever the user left-clicks on the icon, and close when the user clicks elsewhere on the map or clicks a close "x" in the bubble (but not when the user clicks on the information pane or a command button). Selecting a comment point or span icon has the side-effect of selecting the segment (or one of the segments) that the point or span belongs to. If the length of text in the bubble exceeds a certain amount, a scroll bar is provided within the bubble.

Mouse rollover detection might serve a purpose. The following behavior will be prototyped. If the user rolls over a comment point or span icon, BikeZip will display the pop-up bubble described above as long as the mouse is over the icon, except that both the opening and closing of the rollover bubble will delayed by 1 or 2 seconds. (An entirely different solution would be to open a mini-bubble during rollover, containing a truncated version of the comment point or span text and a note saying "click on the point to see full text". In that case, clicking on the point would bring up the full text in an area of the information pane instead of in a bubble.)

Colors

A color scheme hasn't been fully defined, but the colors used in the prototype are:

Markers

Markers are generally not used along routes except for icons used to denote comments.

Further Design

Data Download

Map data will be downloaded from the server to the client upon request by the client using AJAX techniques. Routes within the visible (clipped) map region and meeting parameters such as zoom level and basic filtering (w.r.t. non-bikeways and hidden bikeways) are downloaded, and a ledger is kept of what map areas under what parameters have already been downloaded and are still retained, to avoid redundant downloading. As memory limits are reached, the ledger will have to be cleared.

Data Display

If too many routes or markers are displayed at one time, either routes will have to be hidden as if zoom level were deeper than it actually is, or the map area will have to be reduced. Remember that non-comment points will be merged during display.

Point Merging

Map points that would be displayed too close together to be useful will be merged into one point, with the following exceptions. Segment boundary points will not be merged with other segment boundary points, and comment points will not be merged at all. It's possible that points can be left unmerged but skipped as far as drawing the line of the route (TBD). Intersection points may be merged with nearby points of either route, effectively "moving" the intersection (but not eliminating it or creating more than one).

Database Schema

The database has the following basic tables:

Wiki Updates

Additional Features

Our goal is to provide many useful features as the project expands, such as:

Underlying Technology

The prototype uses HTML/CSS with gratuitous amounts of JavaScript code invoking the Google Maps API. The backend database (not yet integrated with the prototype) is a MySQL database accessed through server-side PHP. This is expected to be the platform used for development of the full BikeZip website. Third-party APIs built around the Google Maps API may be used to provide extra map features (for example, dotted lines).

GIS Data Sources

Government-based GIS databases contain plenty of street data and may contain some bikeway data, but the bikeway data is often inaccurate and terribly incomplete. They miss many routes and provide few details about suitability for cyclists.

Other scattered data sources exist but they too have problems relating to accuracy, scope and data format. Published bike maps like ADC's in the Washington D.C. area are typically proprietary and may be based on the same spotty public data. Bike guide sites and advocacy sites contain lots of valuable information but cover limited areas and use a wide variety of approaches and formats. In order to create a single map that meets our project goals, wiki-style collaboration appears to be the ideal solution.

The Google Petition

There's a petition circulating right now asking Google to provide a "bike there" function at www.petitiononline.com/bikether/petition.html. Sign this petition to support better bike mapping! Of course our project might provide a "bike there" function too, or we could assist Google. Regardless of who provides the "bike there" function, it would surely require more accurate and comprehensive data about bike routes than exists today. The most feasible way to generate that data is through collaboration. Our project goal is not to compete with any other service but rather to support collaboration and produce a highly useful bike map.

More Documentation

Project Information

Montgomery Bicycle Advocates

This Collaborative Bike Map Project is sponsored in part by Montgomery Bicycle Advocates (MoBike). MoBike is an organization that advocates for better bicycling in Montgomery County, Maryland.

Contact Information

Montgomery Bicycle Advocates
7121 Thomas Branch Drive
Bethesda, Maryland 20817

Email contact: bikezip@earthlink.net
Project website: www.BikeMapProject.org