See the Prototype!

See our latest prototype at www.BikeZip.com!. It's a proof of concept that doesn't let you save data yet. Please contact us at bikezip@earthlink.net.

Why BikeZip?

That's why we're building a website called BikeZip that will bring cyclists' knowledge and needs together. It will let cyclists themselves create an enormous map of roads and bike routes, wiki-style. We believe collaboration is the best way to provide a comprehensive, accurate and current map that's truly useful to cyclists and not just drivers. Bike map data gathered from government GIS databases is woefully incomplete and out-of-date, and routes entered by just a few cyclists in a community usually fall short as well. BikeZip uses "crowd-sourcing" to tap into the knowledge of thousands of cyclists, and provides features to make entering data easy.

See our prototype website to see how users might view and edit route information. Please contact us by email at: bikezip@earthlink.net.

Robust Data

BikeZip will record information about every street and path, not just streets considered to be bikeways. This will let a cyclist look beyond just the usual bike routes and determine how safe a particular street is, or have the website generate a route based on personal needs, or evaluate which roads should be improved by local government. Having this much data on hand will also provide a better basis for other applications or websites that might wish to make use of the data.

Viewing the Map

The BikeZip site will provide full-featured map viewer that lets cyclists see all BikeZip content, use filters to see just part of the content, and automatically generate best routes via a "bike there" function. BikeZip's database could also support other bike mapping services such as Google or Ride the City, to make those services as useful and accurate as possible, The BikeZip map viewer would have certain advantages over sites like Google that don't really let the user bring up a map showing all the routes or a custom subset of the routes.

Editing the Map

BikeZip is a wiki, so its own users create and edit the content. Users will have to register in order to make updates, and some users would have higher permissions than others. Some users in each region would be designated as "moderators" and have permission to approve or reject changes, resolve conflicts, manage or merge simultaneous changes, and grant rights to other users. BikeZip will keep an audit trail of all changes and will allow changes to be backed out.

We want BikeZip to be known for the usability of its interface!

Initial Features

The plan is to have BikeZip initially provide the following functionality, then expand from there:

Map Concepts

Routes

A route in BikeZip is any street or path that it knows about. The goal is for every street and path to be stored as a route in the BikeZip database, regardless of how bikeable it is, from superhightways to paved trails. A route is BikeZip's basic mapping unit. A BikeZip route normally corresponds to one street or trail name, e.g. "15th Street" or "Capital Crescent Trail". If two sections of a thoroughfare have different names, they are encoded as separate routes. It's possible that a very long street might be broken into multiple routes.

Points

A BikeZip route is made up of a series of points connected by straight lines. Points are located wherever a route changes direction (heading changes), at intersections, at the start and end of segments (see below), and where certain information is provided such as comments. Comments and various types of data (such as bike shops and drinking fountains) can be attached to points when the map is edited.

Segments

A route is broken up into segments such that one segment ends where the next begins. Segments correspond to sections of a route having unique characteristics such as bikeway type, road skill level, zoom level, etc. If two parts of a route have different values for one of these characteristics, they must be different segments. Segments are displayed as color-coded lines, up to one color per segment. The color indicates the bikeway type of the segment -- on-road, sidepath, on-road + sidepath, etc.

Bikeways

A bikeway is a route or set of segments of a route deemed reasonably safe for bicyclists, or important for bicyclists in any case. By default, non-bikeway segments are not displayed by BikeZip (although the underlying Google map displays routes that are streets). BikeZip still stores these segments as part of their routes and the user can turn on display of non-bikeway segments if he/she wants to see them.

Hidden Bikeways

These are bikeways that would clutter up the map, such as minor residential streets. They are tagged as "hidden" and are not displayed by default. The user can turn on display of hidden bikeways if he/she wants to see them.

Spans

BikeZip can also record one or more spans along a route (might be renamed to "stretches" - TBD). A span is not a fundamental part of a route like segments and points, but is just a stretch of route with a comment attached, like "big hill".

Zoom Level

Each route segment has a zoom level, which indicates the smallest (furthest out) zoom level at which the segment is still to be displayed. A zoom level of 10 means that when the Google map is zoomed in to zoom level 10 or even further to level 11 or 12 and so on, the segment is displayed, but at Google zoom level 9, which is "zoomed out" from zoom level 10, the segment is not displayed. That way fewer and fewer segments are displayed as you zoom out.

Colors

A final color scheme hasn't been completely determined at this time, but the bikeway colors used in the prototype are:

Initial Map Creation

For the first release of BikeZip, only a small number of users might be granted the ability to enter route data. The map could be "seeded" this way without having to provide full audit trail or automated conflict resolution capabilities. Even after the first release, regions newly covered by the map might be updated first by a designated group of users, then opened up for editing by a full community of users.

Initially, BikeZip location data will not be automatically synchronized with underlying Google streets and paths. Instead users will enter routes "freehand" on top of a Google map. Ultimately however, BikeZip routes will be anchored to actual streets and paths stored in Google or other GIS repository.

Please contact us by email at: bikezip@earthlink.net.

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

Below are many additional details, but this is still in flux.

User Interface and Data Model

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

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 and JavaScript code invoking the Google Maps API. The backend database (not yet integrated with the prototype) is a MySQL database, with the backend logic implemented in PHP. The client-server interface uses AJAX to pass XML data back and forth. The same technology will likely be used for the production release of the BikeZip website. Third-party APIs built around the Google Maps API may be used to provide extra map functionality.

More Documentation

Project Information

What's New on This Page

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.
9/14/09 Changes to reflect ongoing development.
12/16/09 Changes to reflect ongoing development.
3/19/10 Added lots of introductory material.

Contact Information

Montgomery Bicycle Advocates
7121 Thomas Branch Drive
Bethesda, Maryland 20817

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