Re: [sfx: Discuss] The Balancing Act That Bike-Share Riders JustWatch - NYTimes.com

[Marcus G. Daniels]

> one would have to determine the main
> "sources and sinks" -- the places where riders show up needing
> transport and where they most often reach their destination,
> relinquishing the bikes.

For designing a sharing program, I would immediately think of an agent
based model layered built on a geospatial database or a graph.  The
database/graph would encode the features of interest in the region, and the
constraints and distances of connectivity between the features.  The
relevant sites could be collected from travel brochures or guides, or
expected business travel (e.g. restaurant owner runs across town to buy
small items from cash-n-carry).  The distances would come from the database
(a map).  

I imagine what would happen is that the users of the bicycles would have
some itinerary, drawn from some set of known-popular or expected
attractions and starting locations (e.g. hotels, time shares, etc).  I
expect a person touring all day would have to intend to start early, while
other folks just zipping across town would have fewer time constraints.  So
there could be more or less variance in when they started their trip.  

Anyway, define your itineraries and sample from it randomly.  Bicycles make
their trips and are deposited and reclaimed.  Iterate that process hundreds
or thousands of times and see where the bikes tend to pile up vs. where
they tend to get exhausted.   Prioritize load balancing between those two.
To close the loop, introduce agents that are the bike movers (pick-up
trucks) which automatically load balance..  Continue to iterate to make
sure a steady state is achieved and that exhaustion events are rare.

Or, if the sharing program is already underway, do site-by-site human
surveillance (or put a GPS/RFID on each bike with the needed
telemetry/sensors) and directly enter the data into a geospatial database.
Prioritize the load balancing between the high and low demand regions on
whatever frequency is needed.  Do bikes run out in a day, a week or what?
A geospatial database makes it easy to calculate those averages over
different periods and plot 'em.

I haven't looked into the APIs for Google Maps, but one way might be to
drive that with a robot agent, and scrape/collect the trips from "Get
directions" pages.  That is, don't be concerned with an explicit
representation of the map in the model, but rather just think of it
transactionally.  "I was at Site A now at Site B", with the elapsed time a
linear function of the distance of the "Get Directions" guidance of Google
Maps.  

Marcus

--------------------------------------------------------------------
myhosting.com - Premium Microsoft® Windows® and Linux web and application
hosting - http://link.myhosting.com/myhosting



============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

[Steve Smith]

I'm having trouble with the Discuss list, having chimed in several times
but not seeing my "chime" show up.   Let's see how FRIAM handles this.

Unfortunately *everyone* (t)here seems to be ignoring the most obvious
premise... there simply are not enough resources (bicycles and/or
parking locations for them) to meet the transient demand *during*
commute hours *at* specific sources (some subway terminals).  The city
is trying to make up for that by re-using bicycles during these peak
moments, moving them in trucks from sink back to source.   Trips/riders
roughly conserve over a day, but during the commute, there is a huge
disparity.

Ignoring implementation details (like a good FRIAMer), why not set up an
"options market" for the bicycles... ultimately the price of bicycles at
high-demand (source) nodes would be higher than ones at low demand
(sink) nodes.  Entrepreneurs could deliberately seek out reverse commute
routes and make money riding bikes in a "counter-rotation" cycle.  
Thrifty commuters might adjust their schedules (nominally early and
late) to minimize the negative spread or even adjust their pickup/drop
points... getting off a subway stop early or late for a "cheaper" pickup
and under/overshooting their destination for a better dropoff price...

The Network Queuing theory and/or agent models could help entrepreneurs
*find* cycles in the graph...   essentially riding upstream for a few
hours every morning (with some short walks between nearby stations) to
optimize the spread.

Given the article's claim that bikes can tow other bikes, there is an
immediate multiplier on whatever spread there is.   Move 3 bikes at once
at a $3 spread and make $9 for a leg...   Add PediCabs to the mix and
one can now circulate (carrying passengers downstream and bikes
upstream)...

Could this system be implemented ON TOP of the current system (e.g.
without permission of the city authorities)?   Would it be managed by
mobile apps or something simpler?   I don't see how they currently
manage membership/utilization... do you insert a card into a rack to
retrieve a bike and then again to return it? Perfect opportunity for a
debit/credit transaction.

There is a need for some game-theoretic analysis to avoid creating a
situation where entrepreneurs would "game" the system.   Show up early
to get a "discount" then "shark" that bike to someone at  a higher
pickup rate?   Maybe this is a feature... suddenly these sharks become
alternative "parking"... allowing 100 bikes to be available
conventionally and maybe 100 more in the hands of sharks ready to hand
off a bike?

With mobile apps, it seems like the options market could extend to
"doorstep delivery".   Put out an "ask" for a bicycle to be at your
doorstep at a certain time for a certain price. Entrepreneurs would pick
up a bike, drop it off, etc. as needed if the price was right.  Maybe
the spread would include enough value that some people would ride a bike
home from their subway terminus in the evening knowing they can get a
higher "bid" in the morning at the same location?

Imagine roving bicycle "trains" acting a lot like cabs... a line of
pedicabs with bicycles in tow queued up at a busy location offering to
drop a bike with you (for a price) then when empty, offer a ride to some
location near a "sink" where more bikes can be picked up for a low "bid"
price?

I don't know what ever happened to the Apps that purported to let you
"sell" your parking space to someone else as you were leaving and then
"buy" one at the other end from someone else.   I don't know if they
were tendered in real $$ or in some kind of credit within the system.  
The bike situation is less symmetric (people either need to get to
work/home and can't be moving bikes around for others, though some
shift-workers/reverse commuters might be able to supplement their income
this way?).

>> one would have to determine the main
>> "sources and sinks" -- the places where riders show up needing
>> transport and where they most often reach their destination,
>> relinquishing the bikes.
> For designing a sharing program, I would immediately think of an agent
> based model layered built on a geospatial database or a graph.  The
> database/graph would encode the features of interest in the region, and the
> constraints and distances of connectivity between the features.  The
> relevant sites could be collected from travel brochures or guides, or
> expected business travel (e.g. restaurant owner runs across town to buy
> small items from cash-n-carry).  The distances would come from the database
> (a map).
>
> I imagine what would happen is that the users of the bicycles would have
> some itinerary, drawn from some set of known-popular or expected
> attractions and starting locations (e.g. hotels, time shares, etc).  I
> expect a person touring all day would have to intend to start early, while
> other folks just zipping across town would have fewer time constraints.  So
> there could be more or less variance in when they started their trip.
>
> Anyway, define your itineraries and sample from it randomly.  Bicycles make
> their trips and are deposited and reclaimed.  Iterate that process hundreds
> or thousands of times and see where the bikes tend to pile up vs. where
> they tend to get exhausted.   Prioritize load balancing between those two.
> To close the loop, introduce agents that are the bike movers (pick-up
> trucks) which automatically load balance..  Continue to iterate to make
> sure a steady state is achieved and that exhaustion events are rare.
>
> Or, if the sharing program is already underway, do site-by-site human
> surveillance (or put a GPS/RFID on each bike with the needed
> telemetry/sensors) and directly enter the data into a geospatial database.
> Prioritize the load balancing between the high and low demand regions on
> whatever frequency is needed.  Do bikes run out in a day, a week or what?
> A geospatial database makes it easy to calculate those averages over
> different periods and plot 'em.
>
> I haven't looked into the APIs for Google Maps, but one way might be to
> drive that with a robot agent, and scrape/collect the trips from "Get
> directions" pages.  That is, don't be concerned with an explicit
> representation of the map in the model, but rather just think of it
> transactionally.  "I was at Site A now at Site B", with the elapsed time a
> linear function of the distance of the "Get Directions" guidance of Google
> Maps.
>
> Marcus
>
> --------------------------------------------------------------------
> myhosting.com - Premium Microsoft® Windows® and Linux web and application
> hosting - http://link.myhosting.com/myhosting
>
>
>
> ============================================================
> FRIAM Applied Complexity Group listserv
> Meets Fridays 9a-11:30 at cafe at St. John's College
> to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
>

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

[Tom Johnson]

I vote for Steve Smith's approach as the best thinking so far.  The foundational key is, it seems to me, the ability to tow a second or third bike.  With that, the options market could be do-able.

-tj

On Mon, Aug 19, 2013 at 4:25 PM, Steve Smith <[hidden email]> wrote:

I'm having trouble with the Discuss list, having chimed in several times but not seeing my "chime" show up.   Let's see how FRIAM handles this.

Unfortunately *everyone* (t)here seems to be ignoring the most obvious premise... there simply are not enough resources (bicycles and/or parking locations for them) to meet the transient demand *during* commute hours *at* specific sources (some subway terminals).  The city is trying to make up for that by re-using bicycles during these peak moments, moving them in trucks from sink back to source.   Trips/riders roughly conserve over a day, but during the commute, there is a huge disparity.

Ignoring implementation details (like a good FRIAMer), why not set up an "options market" for the bicycles... ultimately the price of bicycles at high-demand (source) nodes would be higher than ones at low demand (sink) nodes.  Entrepreneurs could deliberately seek out reverse commute routes and make money riding bikes in a "counter-rotation" cycle.  Thrifty commuters might adjust their schedules (nominally early and late) to minimize the negative spread or even adjust their pickup/drop points... getting off a subway stop early or late for a "cheaper" pickup and under/overshooting their destination for a better dropoff price...

The Network Queuing theory and/or agent models could help entrepreneurs *find* cycles in the graph...   essentially riding upstream for a few hours every morning (with some short walks between nearby stations) to optimize the spread.

Given the article's claim that bikes can tow other bikes, there is an immediate multiplier on whatever spread there is.   Move 3 bikes at once at a $3 spread and make $9 for a leg...   Add PediCabs to the mix and one can now circulate (carrying passengers downstream and bikes upstream)...

Could this system be implemented ON TOP of the current system (e.g. without permission of the city authorities)?   Would it be managed by mobile apps or something simpler?   I don't see how they currently manage membership/utilization... do you insert a card into a rack to retrieve a bike and then again to return it? Perfect opportunity for a debit/credit transaction.

There is a need for some game-theoretic analysis to avoid creating a situation where entrepreneurs would "game" the system.   Show up early to get a "discount" then "shark" that bike to someone at  a higher pickup rate?   Maybe this is a feature... suddenly these sharks become alternative "parking"... allowing 100 bikes to be available conventionally and maybe 100 more in the hands of sharks ready to hand off a bike?

With mobile apps, it seems like the options market could extend to "doorstep delivery".   Put out an "ask" for a bicycle to be at your doorstep at a certain time for a certain price. Entrepreneurs would pick up a bike, drop it off, etc. as needed if the price was right.  Maybe the spread would include enough value that some people would ride a bike home from their subway terminus in the evening knowing they can get a higher "bid" in the morning at the same location?

Imagine roving bicycle "trains" acting a lot like cabs... a line of pedicabs with bicycles in tow queued up at a busy location offering to drop a bike with you (for a price) then when empty, offer a ride to some location near a "sink" where more bikes can be picked up for a low "bid" price?

I don't know what ever happened to the Apps that purported to let you "sell" your parking space to someone else as you were leaving and then "buy" one at the other end from someone else.   I don't know if they were tendered in real $$ or in some kind of credit within the system.  The bike situation is less symmetric (people either need to get to work/home and can't be moving bikes around for others, though some shift-workers/reverse commuters might be able to supplement their income this way?).

one would have to determine the main
"sources and sinks" -- the places where riders show up needing
transport and where they most often reach their destination,
relinquishing the bikes.

For designing a sharing program, I would immediately think of an agent
based model layered built on a geospatial database or a graph.  The
database/graph would encode the features of interest in the region, and the
constraints and distances of connectivity between the features.  The
relevant sites could be collected from travel brochures or guides, or
expected business travel (e.g. restaurant owner runs across town to buy
small items from cash-n-carry).  The distances would come from the database
(a map).

I imagine what would happen is that the users of the bicycles would have
some itinerary, drawn from some set of known-popular or expected
attractions and starting locations (e.g. hotels, time shares, etc).  I
expect a person touring all day would have to intend to start early, while
other folks just zipping across town would have fewer time constraints.  So
there could be more or less variance in when they started their trip.

Anyway, define your itineraries and sample from it randomly.  Bicycles make
their trips and are deposited and reclaimed.  Iterate that process hundreds
or thousands of times and see where the bikes tend to pile up vs. where
they tend to get exhausted.   Prioritize load balancing between those two.
To close the loop, introduce agents that are the bike movers (pick-up
trucks) which automatically load balance..  Continue to iterate to make
sure a steady state is achieved and that exhaustion events are rare.

Or, if the sharing program is already underway, do site-by-site human
surveillance (or put a GPS/RFID on each bike with the needed
telemetry/sensors) and directly enter the data into a geospatial database.
Prioritize the load balancing between the high and low demand regions on
whatever frequency is needed.  Do bikes run out in a day, a week or what?
A geospatial database makes it easy to calculate those averages over
different periods and plot 'em.

I haven't looked into the APIs for Google Maps, but one way might be to
drive that with a robot agent, and scrape/collect the trips from "Get
directions" pages.  That is, don't be concerned with an explicit
representation of the map in the model, but rather just think of it
transactionally.  "I was at Site A now at Site B", with the elapsed time a
linear function of the distance of the "Get Directions" guidance of Google
Maps.

Marcus

--------------------------------------------------------------------
myhosting.com - Premium Microsoft® Windows® and Linux web and application
hosting - http://link.myhosting.com/myhosting



============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

--

==========================================
J. T. Johnson
Institute for Analytic Journalism   --   Santa Fe, NM USA
505.577.6482(c)                                    505.473.9646(h)
Twitter: jtjohnson

http://www.jtjohnson.com                  [hidden email]
==========================================

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com