Re: [sf-bike-planner:0] Digest for sf-bike-planner@googlegroups.com - 2 Messages in 1 Topic

[Garlynn Woodsong]

Great agenda, I look forward to chatting with everybody about these issues tomorrow night.

I might add that, with so many concurrent efforts going on, figuring out the best collaborative approach to move forward to achieve the goal of a bay-area-wide bicycle trip planner ASAP should be our goal... and I'll try to provide as much information and contacts as I can to help with this.

See you there!

cheers,

~Garlynn

On Tue, Dec 1, 2009 at 3:50 AM, <sf-bike...@googlegroups.com> wrote:

  Today's Topic Summary

Group: http://groups.google.com/group/sf-bike-planner/topics

• Wednesday's SF Bike Planner Meeting [2 Updates]

 Topic: Wednesday's SF Bike Planner Meeting

Matt H <mheb...@gmail.com> Nov 30 03:45PM -0800

 
Hello again,
 
I'm really encouraged by the response to my call for collaboration on
the SF Bike Mapper. Thanks to Nick for agreeing to host at his office.
 
I hesitated to put together an agenda, since I don't want this to feel
too much like work, but here are a bunch of potential items for
discussion. This shouldn't be considered binding, but a jumping-off
point. See you at 6:30 on Wednesday.
 
Cheers,
Matt
 
__Agenda__
 
1. Introductions
a. Shall we take notes for those who are interested and could not
attend?
 
2. State of the Map, December 2009
a. 511.org – online bike mapper was never satisfactory. After being
down for a while and then re-launched, the result is less than
thrilling.
b. Google – has quietly announced that it will offer cycling
directions sometime soon.
c. Bikethecity.com -- say they're already working on the entire SF
Bay area
d. East Bay Bike Coalition : “EBBC is working on our interactive
digital map of the East Bay and we are contracting to create map
layers for a launch to include 2010 Bike to Work Day Energizer
Stations (along with our existing "hazard" and "shop" maps). It sounds
like you are mainly interested in the navigation part; something that
is only one component of our mapping goals and will likely be the last
part that we tackle.”
 
e. Other cities – A number of other cities have bike route finders:
bycycle.org, Vancouver, ridethecity.com, etc.
f. Bay Area Prototypes:
i. Amar’s SF Bike Mapper
ii. John’s Bikesf.com
iii. Matt’s East Bay Bike Mapper
 
3. Shall We Collaborate?
a. What should the collaboration look like?
b. Mission/Vision for the site
c. Profit model vs. public benefit
d. Leadership, decision-making, and contributor-ship
 
4. What should the ideal Bay Area Bike Mapper look like?
a. Routing
i. Hill tolerance (shortest route vs. flattest route)
ii. Traffic tolerance vs. extra distance
iii. Bike paths/lanes
iv. Traffic counts, speed limits, shoulder width, on-street
parking
v. Road hazards (grates, RR tracks, narrow bridges, etc.)
 
b. User Interface
i. Multiple destinations vs. single start and finish
ii. Modify route by dragging and dropping endpoints and/or route
polyline
iii. Zoom to segment of route
iv. Classify segment by route type (path, lane, on-street) and/or
slope
v. Google street view where available?
 
c. Options
i. Links to transit? (BART, bus, Caltrain, Amtrak, other)
ii. Pollution tolerance (avoid air pollution on congested routes)
iii. Display additional overlays (traffic counts, road hazards,
scenic routes, bathrooms, drinking fountains, pubs, bike shops, etc.)
 
d. Output
i. Turn-by-turn text directions
ii. Elevation profile plot
iii. Feel-good information about health and pollution benefits
(calories burned and CO2 emissions avoided by not driving)
 
5. Technology Choice
a. Server side: python, php, C+, other?
b. Map: Yahoo, Google, OpenStreetMap, other?
c. Javascript library: jQuery, YahooUI, scriptaculous, other?
d. Routing algorithm: PostGIS pgRouting? Djikstra, A*, roll our own?
(should include turn restrictions, one-ways, etc.)
e. Database: MySQL, PostGRE, other?
f. GIS data format: shapefile, geodatabase, GML, WKT?
g. Geometry type: Coordinates for geometries may be 2D (x, y), 3D
(x, y, z), 4D (x, y, z, m) or 2D with a m value (x, y, m)
h. Minimizing the steps between editing data and updating the online
database
 
6. GIS data development
 
a. Data sources: OSM, Tiger, Navteq, TeleAtlas, other?
b. Turn restrictions
c. One-way streets
d. Highways (delete)
e. Alleys and bike bridges (add)
f. Adding necessary attributes.
 
7. Geography
a. Coordinate system (UTM, state plane)
b. Elevation datum (NGVD29 vs. NAVD88)
c. When is the data ready to publish?
d. Adding Polyline MZ data
i. Terrain Data Sources (DEM or DTM)
ii. Issues that arise from draping vector data over a DEM:
1. Bridges
2. Tunnels
3. Roads on steep slopes
4. Elevated roadways
 
iii. Cleaning and correcting results – necessary, but time
consuming. Tools to simplify or partially automate this procedure?
 
8. Funding:
a. Apply for grant to Oaklandish, Rose Foundation, other?
b. What would we use it for? (pizza and beer, pay a college intern,
hosting, publicity?)
c. Sell iphone apps?
 
9. Collaboration:
a. Email group? (how much should be public vs. private?)
b. Wiki?
c. Copyright, Licensing, code maintenance, and updating?
i. Use Google code, Subversion, Trac?
 
10. Other Issues?


 

Jason Toy <jt...@jtoy.net> Nov 30 06:52PM -0500

 
I would love to see notes. I originally was going to attend, but will
not be able to make it.
 
Regards,
Jason
 
 
 
Jason Toy
6176064373
 
 
 
 


 

--

You received this message because you are subscribed to the Google Groups "sf-bike-planner" group.
To post to this group, send email to sf-bike...@googlegroups.com.
To unsubscribe from this group, send email to sf-bike-plann...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sf-bike-planner?hl=en.

--
               O
       O           ...let's go do
   O                        something
 O                              i n t e r e s t i n g
O                 .garlynn.g.woodsong.
...............................................................
http://undergroundscience.blogspot.com
o  o  o  o  o  o  o  o  o  o  o  o  o  o  o  o  o  o

[Nicolas Block]

Great meeting everyone. My mental notes include:

data sources: openstreetmap or MTC, in a conversation with Garlynn we
concluded that the MTC data is much better quality and regularly
updated.

GIS programs: some of us have software that is capable of mashing
terrain data with MTC data

existing systems: three systems, one in C with a PostgreSQL db, one in
python with the data stored in some sort of flat file or something, i
didn't understand what it was exactly, a third with a sql db and not
sure what the app was written in.

programmer's needs: well formatted data can be added to the existing
systems immediately. the programmers should supply the group with the
data requirements for each system

licensing / business model: open source, non-profit, some sort of GPL-
like license

organization: we all suggested that amongst us there are 2 architects,
1 project manager, 1 advisor, several committers, several GIS
specialists

goal: create an extensible route planning system that uses highly
local information to generate accurate bike routes thereby encouraging
bike commuting in the bay area. hopefully, to have this available on
the next bike to work day, and to have a product that can be
publicized through the existing bike to work organizers, regional
transit organizations, other NGOs

here's my personal take on it:

It seems like there are a couple of core issues here:

1. openstreetmap or MTC data. i prefer my information free, but it
doesn't sound like openstreetmap is very complete.


2. How do we treat data. I imagine several data layers:

a. MTC/openstreetmap data at the bottom can be updated periodically
b. Terrain data
c. A base layer of edits, such as removing highways, corrected terrain
data for tunnels, bridges etc. other edits that are fairly permanent.
d. index
e. A user generated layer of data which can apply human judgement to
route calculation, eg: valencia not advised 8/20/09 - 2/15/10, or 25
users recommended X instead of Y, or users traveling on A arrived
faster than users traveling on B
f. index

If it was possible to abstract this in a way so that a. could be
updated without affecting b. c. or e. and new indexes could be
generated as a., c. and e. are updated... well then we'd have a truly
flexible structure. Can this be done in our application layer?


3. Storage. PostgreSQL has some libraries that are helpful when
working with GIS data, if say we wanted to achieve what I suggested
just now, would we be using these libraries, or is that something
completely different.


4. Application. We can use python and we can always extend it with
C. Several in attendance have worked with python before, so that
seems like a natural choice.


5. Requirements for bike to work day usage. If our goal is to produce
something useful for an event like bike to work day, we'll need to
meet the following minimum requirements:

a. including transit stations around the area would make the tool
infinitely more useful to commuters. It could be as simple as
suggesting that a route between San Leandro and San Francisco goes to
the nearest Bart station and picks up again at Embarcadero. It
doesn't need to be so sophisticated as to suggest train schedules, but
if we provide commuters that day with a tool that suggests a route to
the Oakland waterfront and picks up again at the Ferry Building, we're
not doing anyone any favors. So we need a strategy to provide the
minimum amount of multi-nodal? routing necessary to construct usable
routes.
b. our interface should be as usable as possible, meaning that it
should basically replicate the most frequently used and most user-
tested system. I'm betting that's google maps.
c. our route maps should clearly indicate what class the road is, to
help inexperienced cyclists anticipate and prepare for road conditions.


6. Cost. cost should at least take into account inclines and road
class. the most sophisticated system would also account for speed,
accident rate, traffic and cyclist preference.


7. Mobile Apps. platform-specific mobile apps could help contribute
data on average speed and cyclist preference, but for routing purposes
there is little difference between a mobile-optimized web app and a
platform specific app.


8. Collaboration. we should make sure that everyone who's working on
the same thing, all the local governments, NGOs, etc-- that everybody
knows what we're up to, gets updates on our progress, is invited to
participate, and is onboard to support it when its finished. ideally,
we'll have a product that everyone can be proud of, not resent.


9. Where to begin. We could start by connecting the python app the
PostgreSQL storage system, formatting additional GIS data for the east
bay and fixing the known bugs. Next we could meet with MTC to discuss
a strategic partnership. After that, we could try to include basic
data for BART, Caltrain et al. We could then reconvene to discuss the
GUI and incremental improvements.

just some thoughts...

thanks for attending. and/or thanks for reading.

Nick

[Matt H]

Thanks for your notes, Nick. I typed up mine before I saw them. Here
are mine:

SF Bike Planner
Notes from First Meeting
December 2, 2009
at Headline Shirts in the Mission

In attendance:
Matthew Heberger mheb...@gmail.com
David Asbury david...@gmail.com
Peter Robinett pe...@bubblefoundry.com
Amar Pai jcru...@gmail.com
John Roark john....@gmail.com
Jerry Jariyasunant jjar...@berkeley.edu
Brian Fulfrost br...@dceplanning.com
Nicolas Block ni...@revelindustries.net
Garlynn Woodsong gar...@gmail.com

*Welcome & Introductions
Matt will try to facilitate and take notes. He is a hydrologist, works
for the nonprofit Pacific Institute in Oakland, amateur programmer,
and creator of the prototype East Bay Bike Planner at http://ebmgh.com/

Peter is a programmer, web designer, mobile app developer
Overall, I was extremely impressed with the level of interest, and
more impressed by the range of expertise among those present.

Amar is a programmer, works at Google, creator of the SF Bike Planner,
http://amarpai.com/

John is a programmer, creator of prototype at http://ridesf.com

Jerry is a graduate student in Transportation Studies at UC Berkeley,
has created a real-time transit trip planner, interested in merging
bike routing into it

Nick is the Technical Director at Headline Shirts, works on web, media

Brian is and Remote Sensing professional, works on bike master plans
for CA cities, has long-standing interest in online bike mapping

David is GIS user/cartographer at Center for Ecosystem Management

Garlynn is a planner, formerly at MTC for several years, developed the
original 9-county bike GIS layer, has great deal of knowledge of the
failed history of bike map development in the Bay Area


*What is the Groups Vision/Ideas for the SF Bike Planner?

Simple - Should be easy to use, intuitive for users. This is where the
commercial map applications excel (Google, Yahoo, Mapquest, etc.) and
existing bike mappers fall short, in my opinion. The user interface
needs to be simple, intuitive, and uncluttered.

Local Data - Application only as good as its data. Our advantage: we
are locals, and have a great deal of knowledge about local roads and
bike routes

User Feedback/Contributions - The site should have very good local
mapping data
Many agreed that we should aim to have ongoing updates to the data,
and make it easy for users to submit corrections or ratings

Public Benefit (not for profit)- Consensus that no one is primarily
motivated by profit or money-making; we are creating something for the
public and ecological benefit, that is good for communities and the
environment.

Mobile -Several suggested it should eventually be a mobile app, or at
least optimized to work well on small devices and phones. (Amar said
about 10% of the traffic on his site is from mobiles.) Peter and Jerry
are both mobile developers, and could help there. Developing a mobile
app can be very time-consuming.

Open Source - Consensus on an open source model

License - there are many license agreements from which we may choose.
We may want one that makes our code and data freely available for non-
commercial use
Complexity - Agreed that we should aim to do one thing very well:
provide turn-by-turn bike directions and mapping.


*Discussion - Sites/Resources

Matt's new blog has a roundup of some of the existing bike route
planners:
http://ebmgh.com/blog/

LA's bike map has been around since 2001 (considered one of best?
really?)
http://www.bikemetro.com/

(I thought this site was down because typing http://bikemetro.com
gives a 404 error.)

OSM now has routing, including for bikes
http://www.yournavigation.org/

Wiki Page for YOURS, Yet Another OpenStreetMap Routing Service
http://wiki.openstreetmap.org/index.php/YOURS

uDig - a desktop GIS application that works in a browser and can view/
edit PostGIS databases (http://udig.refractions.net/)

qGIS - another (more fully-functional?) desktop GIS that can edit
PostGIS databases. http://www.qgis.org/


*History of Online Bike Mapping in the Bay Area
Garlynn provided some history, as he worked at MTC, the Metropolitan
Transportation Commission, developed the first 9-county bike network
GIS layer, and wrote the specifications for the 511 online bikemapper.
He too has been frustrated by their lack of progress. http://www.mtc.ca.gov/

The firm that created http://bikemetro.com/, LA's bike mapper,
submitted a bid to create a mapper for the Bay Area for $250,000.

The San Francisco Bike Coalition (http://sfbike.org/) got a grant to
create an online bike planner. They gave a contract to MTC, which was
held up for about 2 years over their domestic partner benefits policy.
(!) Ultimately, MTC has failed to deliver (at least so far).

Garlynn suggested that we ought to coordinate with MTC, or try to get
network data from them (even filing a Freedom of Information Act
Request?). Amar, Matt, and John are unsure about this, as we have each
tried contacing them, and gotten no reply, or terse, unhelpful
replies.

There are several others working on some form of a bike mapper in the
Bay area, including MTC, the East Bay Bike Coalition, ridethecity.com,
and, oh, Google. If one of them came out with something really useful
(and to which I could contribute in a meaningful way), that would be
great, even if it kills our initiative.

My goal is to have something that I can use, and that is useful to the
community and good for the environment. However, there are serious
doubts that any of these will really be usable. A bike planner for SF
MUST know about hills and give the user options to avoid them,
otherwise it is useless.


*Way Forward
GIS Capability - A consistent theme that came up was that programmers
who tried to tackle the problem got slowed down or stuck because they
did not have GIS software or knowledge. Often, it's hard to even know
how to search for information on what your trying to do if you don't
know the right vocabulary. This should be a problem of the past: we
now have a network of willing volunteers, several have GIS expertise
and industrial-strength software.

Several of us agreed that the PostGRE/pgRouting platform is a good one
to work with.

Language: Python is a common denominator that several agreed would be
a good choice. We could potentially write wrappers to use John's code
written in C (which is an unusual choice of language for web
development?).

Overall, there are many decisions to be made about the way forward.
Much will depend on who has time to contribute. Matt strongly believes
that we need one or maybe two people to be the final arbiters for
design and development decisions, and to propose tasks that volunteers
can work on. Brian has significant project management experience and
offered to help with that.

Amar's codebase has "open bugs" in the repository on Google Code. An
immediate way for someone to help with his project is to request
privileges to edit and commit his code, and submit patches.
http://code.google.com/p/sf-bike-planner/
Others wondered about how scalable his architecture is? Major downside
is that the route data is stored in a Python dictionary, and theere is
no easy way to visualize the data or update it.

Interim step - Matt and John agreed to upload our code to the SF Bike
Planner Google Code page. Anyone interested can look at it. This may
help evaluate some of the options.

Garlynn will try to set up a meeting with MTC in Oakland.

We will be in touch via the Google Group. Among the things to discuss:
what is the best architecture/platform to use going forward?

We have a group of volunteers, with a great deal of expertise, and
willing to contribute. We agreed to have a very open system of
communication. Anyone having ideas, suggestions, critiques, please be
in touch via the Google Group.

Agreed to meet monthly - next meeting will be in January, and
announced on the Google Group.

[Peter Robinett]

Hi all,

I just wanted to say it was a great to meet you last week. I would be
happy to take the lead in going through everyone's code and taking the
software development forward. However, I have a big deadline at work
this week, so it may be a little while before I can really dive into
the code.

Peter

On Dec 3, 5:39 am, Matt H <mheber...@gmail.com> wrote:
> Thanks for your notes, Nick. I typed up mine before I saw them. Here
> are mine:
>
> SF Bike Planner
> Notes from First Meeting
> December 2, 2009
> at Headline Shirts in the Mission
>
> In attendance:

> Matthew Heberger        mheber...@gmail.com
> David Asbury    davidasb...@gmail.com
> Peter Robinett  pe...@bubblefoundry.com
> Amar Pai        jcrue...@gmail.com
> John Roark      john.ro...@gmail.com
> Jerry Jariyasunant      jjari...@berkeley.edu
> Brian Fulfrost  br...@dceplanning.com
> Nicolas Block   n...@revelindustries.net
> Garlynn Woodsong        garl...@gmail.com

>
> *Welcome & Introductions
> Matt will try to facilitate and take notes. He is a hydrologist, works
> for the nonprofit Pacific Institute in Oakland, amateur programmer,

> and creator of the prototype East Bay Bike Planner athttp://ebmgh.com/

>
> Peter is a programmer, web designer, mobile app developer
> Overall, I was extremely impressed with the level of interest, and
> more impressed by the range of expertise among those present.
>

> Amar is a programmer, works at Google, creator of the SF Bike Planner,http://amarpai.com/
>
> John is a programmer, creator of prototype athttp://ridesf.com

> really?)http://www.bikemetro.com/
>
> (I thought this site was down because typinghttp://bikemetro.com
> gives a 404 error.)
>
> OSM now has routing, including for bikeshttp://www.yournavigation.org/
>
> Wiki Page for YOURS, Yet Another OpenStreetMap Routing Servicehttp://wiki.openstreetmap.org/index.php/YOURS

>
> uDig - a desktop GIS application that works in a browser and can view/
> edit PostGIS databases (http://udig.refractions.net/)
>
> qGIS - another (more fully-functional?) desktop GIS that can edit

> PostGIS databases.http://www.qgis.org/

>
> *History of Online Bike Mapping in the Bay Area
> Garlynn provided some history, as he worked at MTC, the Metropolitan
> Transportation Commission, developed the first 9-county bike network
> GIS layer, and wrote the specifications for the 511 online bikemapper.
> He too has been frustrated by their lack of progress.http://www.mtc.ca.gov/
>

> The firm that createdhttp://bikemetro.com/, LA's bike mapper,

> privileges to edit and commit his code, and submit patches.http://code.google.com/p/sf-bike-planner/