|
Post by whistler on Mar 30, 2015 14:58:47 GMT 1
I was looking at the stages for this week's Vuelta Ciclista a Pais Vasco and noticed that the stage with the most mountain sprints (stage 3) only has 5km of mountain (vs. 54km & 19km of mountain in stages 1 & 2) and the climbs awarded points are all short (8, 5, 5 & 8km) and not particularly steep (6, 5, 8 & 5% gradients) - so the mountain points classification will be decided by the flatest stage. In real life, climbs are categorised according to difficulty and points weighted towards steeper and longer climbs - en.wikipedia.org/wiki/Mountains_classification_in_the_Tour_de_FranceIn peloton there is no mechanism for weighting mountain sprint points, but maybe tour designers could select which climbs get mountain sprints based on length and gradient of climbs to achieve a similar outcome? Just wondering what others might think on this?
|
|
|
Post by rarau on Mar 30, 2015 16:10:15 GMT 1
Maybe ElGringo and Schizm think that hill trainer need their chance too.
Sprint points on Zierbana - Vitoria (stage 2)
3. Flat (5km, 0%) Sprint 8. Downhill (5km, -2%) Sprint 18. Flat (5km, -1%) Sprint
Sprint points on stage 1 (Vitoria - Zalla) are
3. Flat (18km, 1%) Sprint 8. Hill (12km, 6%) Sprint
So probably they want some diversification.
In big tours at least 80% sprint points are flat, at least 80% mountain sprints are mountain
|
|
|
Post by Schizm on Mar 30, 2015 16:20:06 GMT 1
To make a calendar you already have to take very much parameters into account, so I am against adding even more things to take into account. Also it isn't possible to change stages for the calendar of a year so we have to add a new version for every minor change (like we do now for the sprint stages for instance). On the other hand it is also hard to predict during race design how big the influence of the stage mountain points is. When we put a tour in a calendar we pick the 3 most suitable stages from the database based on the needs for that tour. These needs are based on the balance and variation within the season both in percantages and in finish terrain and in that we also have to avoid recently raced stages/combinations that have been done before. If we had combined the Ordizia stage with a flat and a flat-hill stage those mountain sprints would have seemed perfectly logical.
I am all in favour for categorizing mountain sprint based on gradient and length. And I have been thinking about a good automatic system for a while now. I want to achieve that goal without redesigning stages or putting extra fields in the database. But it isnt that straight forward as it seems at first (mountain points on a 5km - 4% stroke should be valued very differently if there are large (or many) strokes with high percentages before it).
My point is every system I could think off will have its disadvantages.
|
|
|
Post by whistler on Mar 30, 2015 20:56:42 GMT 1
When we put a tour in a calendar we pick the 3 most suitable stages from the database based on the needs for that tour. These needs are based on the balance and variation within the season both in percantages and in finish terrain and in that we also have to avoid recently raced stages/combinations that have been done before. If we had combined the Ordizia stage with a flat and a flat-hill stage those mountain sprints would have seemed perfectly logical. I am all in favour for categorizing mountain sprint based on gradient and length. And I have been thinking about a good automatic system for a while now. I want to achieve that goal without redesigning stages or putting extra fields in the database. But it isnt that straight forward as it seems at first (mountain points on a 5km - 4% stroke should be valued very differently if there are large (or many) strokes with high percentages before it). My point is every system I could think off will have its disadvantages. Don't get me wrong - I'm happy the game's just running, and grateful for all the behind the scenes work that got it going again. Would something as simple as categorizing future stages 'by eye' (or by % flat/hill/mountain) as flat, mixed, or mountain work? Then you could have a maximum of say 2, 4, & 6 mountain sprints for those types of stages? That way individual stages wouldn't need to 'know' what other stages were in a tour to work out how difficult the climbs were in the context of the tour. rarau: I have a mountain team, but I wasn't trying to argue just in a way to help mountain teams - the same would apply if stages 1 & 2 were both pure hill and stage 3 was mostly flat, but had more mountain sprints. Anyway, thanks for the new season - really enjoying it.
|
|
|
Post by ElGringo on Mar 31, 2015 9:14:02 GMT 1
There are a huge number os stages, about 1000 and many of them were made by several people. We don't know the criterium used to make the stages and the sprints. And every season we make new stages to use so for us to have a variety of stages we chose some of the old in the db and somethimes we have stages like this one.
Like Schizm said, we focus on other criteriuns to chose the stages.
|
|
|
Post by Schizm on Mar 31, 2015 14:32:10 GMT 1
We will try to take sprint points (both for green and polka dot) into the equation next time. But this will only work if we have enough similar stages to choose from. I did the calendar schedule only for the last 2 seasons and already often ended up with the same stages because they are the best fit , I expect this to even get worse when we avoid illogical sprint points.
BTW : what Rarau says is also partly true , we try to put something in it for everyone.
|
|