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 <[email protected]> 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<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<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<http://redfish.com/mailman/listinfo/friam_redfish.com>
>



-- 
==========================================
J. T. Johnson
Institute for Analytic Journalism   --   Santa Fe, NM
USA<http://www.analyticjournalism.com/>
505.577.6482(c)                                    505.473.9646(h)
Twitter: jtjohnson
http://www.jtjohnson.com                  [email protected]
==========================================
============================================================
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

Reply via email to