Account Options

  1. Sign in
The old Google Groups will be going away soon.
Switch to the new Google Groups.
Google Groups Home
« Groups Home
PBP Planning resources: New planning spreadsheet & GPS file from Nick Bull
There are currently too many topics in this group that display first. To make this topic appear first, remove this option from another topic.
There was an error processing your request. Please try again.
flag
  3 messages - Collapse all  -  Translate all to Translated (View all originals)
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Don Bennett  
View profile  
 More options Jun 16 2011, 2:56 pm
From: Don Bennett <d...@donbennett.org>
Date: Thu, 16 Jun 2011 11:56:21 -0700
Local: Thurs, Jun 16 2011 2:56 pm
Subject: PBP Planning resources: New planning spreadsheet & GPS file from Nick Bull

I have uploaded another planning spreadsheet and a GPS file from Nick Bull:
see https://sites.google.com/site/pbp2011usa/home/maps?pli=1 .

GPS notes -

Attached is a GPS file for PBP. * [See attachment below,
PBP2011-NickBull.gdb]* It is based primarily on the official GPX files
posted on the PBP website.  I and George Moore separately created GPS files
then compared them with each other, with my GPS track from 2007, and with
the cue sheet to fix any possible computing glitches.  We used two different
base maps for computing the routes.  There are some known glitches, such as
in Fougeres where the road has apparently been re-routed.  Control locations
should be interpreted as approximate -- e.g. sometimes the control itself is
down an access road that is not on the map.  Riders still need to keep their
wits about themselves.  The cue sheet and arrows on the course are the
primary source of route information, though I'm not sure which takes
precedence when they contradict each other.  The GPS should always be
checked against the cue sheet and arrows.

Anyone who plans to use this file should set their GPS as follows:

Go to the Setup->Routing page and set as follows:

Guidance Method: Follow Road
Follow Road Method: Shortest Distance
Next Turn Pop-Up: On
Follow Road Options:
Off Route Recalculation: Prompted
Calculation Method: Best Route
Calculate Routes for: Car/Motorcycle
Avoid: (set to none – the route itself should control this)

By the way … make sure that your GPS either has maps already downloaded, or
select the relevant maps around the routes.  I cannot guarantee that these
will keep you on the official route, but if you have your GPS set some other
way, it is entirely possible that it will take you off route, possibly onto
unsafe roads.
The GPS file contains "climbing waypoints" before all of the "significant"
climbs.  Generally, "significant" means more than 400 feet, since that's
about when I start wondering if the climb will ever end.  But I think I put
in some near the end that are a tad less than 400 feet.  But that still
potentially leaves out hills that riders may think are "significant" while
they're climbing them -- a 200 foot climb with a 20 percent grade will
probably get your attention.  The way to read the climbing waypoints is as
follows: "C8.7k45to74" means "Climb for 8.7 kilometers for a total of 450
feet to an altitude of 740 feet".  Sometimes there are ups and downs in a
climb: These are ignored in the measurement of feet of climb.  Typically the
climb is measured from the "local minimum" -- e.g. the stream in the valley
floor -- to the top of the climb.  So it's often the case that the start of
the climb is pretty gradual and the "real" climbing comes a little later.

Planning spreadsheet notes -

For me, the trouble with most planning spreadsheets is that they start by
having you put in how fast you can ride on each segment.  But unless I know
how hilly the segments are, I don't know how fast I can ride it.

So this spreadsheet starts with GPS track information so that I know what
the terrain will be like.  It then uses that information, plus variables
that can be controlled by the user (e.g. their total weight with bicycle,
the weight of the bicycle, where and for how long they expect to sleep,
etc), and combines that with the results of an econometric model to generate
a raw forecast of the ride.  That raw forecast can then be hand-modified, if
desired (I have added fifteen minutes to each control, because PBP control
logistics can be expected to be slower).  Finally, the expected arrival time
at the end of each leg is shown.  This can be used to create an annotated
cue sheet with expected arrival times at any given point.  A summary page
shows the expected arrival time at controls.

The spreadsheet has a "notes" page that may be helpful in understanding how
to use it.

While this spreadsheet might be considered by many to be laughably
overcomplex, I have been using the same basic methodology to forecast rides
and to help stay on track with the ride for the last couple of years, and I
and others have found it useful.  I like to annotate the cue sheet with
expected arrival times every fifteen miles or so.  It's particularly helpful
in really hard sections where you feel like you are running way behind, but
then when you get to the next time mark you find you are doing just about as
expected.

Control times are overly generous.  I could hand-adjust those down, but
prefer to see how much I can beat those control times by, and get "ahead of
schedule."


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Discussion subject changed to "Using BikeRouteToaster [Re: PBP Planning resources: from Nick Bull]" by Yiping Lin
Yiping Lin  
View profile  
 More options Jun 17 2011, 7:16 am
From: Yiping Lin <wilde...@gmail.com>
Date: Fri, 17 Jun 2011 04:16:12 -0700 (PDT)
Local: Fri, Jun 17 2011 7:16 am
Subject: Using BikeRouteToaster [Re: PBP Planning resources: from Nick Bull]
On Jun 16, 2:56 pm, Don Bennett <d...@donbennett.org> wrote:

> Planning spreadsheet notes -

> For me, the trouble with most planning spreadsheets is that they start by
> having you put in how fast you can ride on each segment.  But unless I know
> how hilly the segments are, I don't know how fast I can ride it.

Let me also share my own experiences.

I have used BikeRouteToaster.com (BRT) to create the course files for
navigation in Garmin Edge 500 (it's not a map but a route profile) and
to estimate the "maximum" course time. After trying this for my all
qualifying brevets, I now can get a good estimation (e.g. PA600k
brevet in May & two permanents 200k+200k last weekend).

How-to:
1. In Map/Options: first set the "virtual partner"'s speed: Speed On
Flat (kph) and Climbing Speed (m/min) [press "Save"]
2. Draw or import your route. If import, check "Add Height Data"]
3. In Summary/Course Details, you get the estimated time.

It's very important to know your average speed on the flat & climbing
speed (see the explanation on "Time" to understand what climbing speed
means http://www.bikeroutetoaster.com/HelpOptions.aspx).
I lowered the default Speed On Flat & Climbing Speed, and adjusted
them again after 200k & 300k brevets. (I'm a slow rider...)

I set these two parameters such that I have more chances to "beat" the
virtual partner and to "win" the stage. :-) Not only good for my
spirits, it also serves as the minimum average speed I should have on
the course.

Yiping


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
NickBull  
View profile  
 More options Jun 17 2011, 9:00 am
From: NickBull <nick.bike.b...@gmail.com>
Date: Fri, 17 Jun 2011 06:00:37 -0700 (PDT)
Local: Fri, Jun 17 2011 9:00 am
Subject: Re: Using BikeRouteToaster [Re: PBP Planning resources: from Nick Bull]
Interesting, thanks.  If that had been available when I started
randonneuring, I might never have bothered to develop the model that I
did.

FWIW, my forecast takes into account bodyweight, bike+luggage weight,
climbing in the current leg, total climbing so far in the ride,
descending on the leg, cumulative distance on the ride, whether you're
drafting, whether it is nighttime, whether you are sick, and whether
the temperature is "XTRM" (below freezing or above 90 degrees).  The
spreadsheet doesn't bother to take into account "XTRM" weather because
I'm assuming France in August will not be "XTRM".  There are numerous
other variables that I've tried, like whether it is raining or not,
how windy it was on the day of the ride (average and gust), how long
it's been since the last control, etc.  But as of the last time that I
checked, none of these came in statistically significant.  I run
separate regressions for whether the ride was a brevet or not, whether
it was ridden hard or not (some brevets you are just putzing along
with friends), and also for whether the ride is on a tandem or not.
The input data for the regression is GPS data for 158 events I've
ridden over the last five years.  The regression in the posted
spreadsheet assumes that you are riding PBP as a hard ride on a solo
bike.  If anyone is riding it on a tandem and cares to see a variation
of the spreadsheet with the tandem forecast, contact me off list.
Also, if you ride ten percent faster than me at a given weight, then
you can easily bump various regression parameters to modify the
forecast.

Nick

On Jun 17, 7:16 am, Yiping Lin <wilde...@gmail.com> wrote:


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
End of messages
« Back to Discussions « Newer topic     Older topic »