Posts Tagged maintenance

Letter to Glasgow City Council about cycle-paths

Jun 7, 2011 at 14:23 · Filed under Cycling ·Tagged , , , , , ,

Dear Sir/Madam,

On monday morning, the 6th of June, while cycling along the cycle-path along the clyde, from Victoria Bridge to the George IV Bridge, I noticed a significant amount of glass near the Victoria Bridge end – no doubt from weekend drinking. The shards were large, and I warned cyclists coming in the opposite direction. Unfortunately, I did not report it to the council myself – I naively presumed someone else would have and/or that the council would clean the cycle path daily. This morning, Tuesday the 6th, the glass at that location had been mashed into finer pieces and spread everywhere (no doubt in part by unfortunate cyclists). My rear tyre was punctured by this glass, and I know at least 2 other cyclists received punctures. This is the 2nd time I’ve had a puncture on that stretch of cycle-path, in only a few months of cycling it (2/3 of all my punctures).

I would ask that you clean this cycle path today. Generally, I would ask you to clean it and all others preferably daily, or failing that on at least the same schedule as the main roads, or failing that to at least on Monday mornings clear the path of the debris from weekend drinkers. Additionally, I intend to recover from you the costs of a new inner tube (£5), tyre (£29) and the labour to have them fitted.

Another maintenance issue is that one of the poles at the entrance of the side-street alongside the Broomielaw, by the Gala Riverboat car-park, has a piece of metal sticking out at the top of it which is likely one of these days to catch and injure a cyclist trying to enter that side-street.

Also, I have some general comments to make about cycle paths in Glasgow City on their design and maintenance.

* It can be very hard to distinguish which paths are dual-use and which are not, due to poor signage and/or very poor cycle-path design.

E.g. the toucan crossing at George IV bridge going west to the Gala Riverboat appears to lead cyclists onto a foot-path – at least it has a raised kerb to the entrance to the car-park which seems to clearly suggest that path is not intended for cycling. However, if it is not meant to be a cycle-path, then the toucan crossing to that path is encouraging cyclists to proceed down it and so commit an offence. On the other hand, if it is still a cycle-path, then why are there raised kerbs along it? Clear signage here, either way, would be useful. Removing the kerbs and making this cycle path continuous would be an idea, if it is a cycle-path. If the kerbs are intended to make cyclists give way to the car-path traffic, I would suggest reversing things and raising the cycle-path so it is level and giving cars a gradient to traverse and give way to a clearly marked cycle/footpath (there are few cars using this car-park in the morning).

If a cycle path is not easy to distinguish, then some cyclists will stick to the general road – to ensure they do not commit the offence of cycling on the pavement. If a cycle path is inconvenient, they will similarly stick to the road.

* Cycle paths away from the road need to be cleaned frequently.

E.g. the path along the Clyde mentioned above is regularly filled with broken glass from beer and Buckfast bottles. It’s particularly bad underneath the foot-bridge over the clyde – drinkers presumably congregate under there for shelter.  It needs frequent cleaning in order to be useful as a cycle-path. If the means do not exist for the council to do this, then the council should installs signs directing cyclists along Clyde St road instead and create a cycle lane on Clyde St road. It should be noted this same cycle-path (National Cycle Route 75) is also terribly glass-filled along many sections further up-river, such as around Dalmarnock and Carmyle. Parts of the cycle lane on Alderman St are quite debris filled, particularly in those parts where there are dividers between the general road and the cycle lane.

If cycle-paths are full of glass, but the roads are not (cars have a cleaning effect & roads seem to be cleaned more regularly), then clearly cyclists will be encouraged to favour roads over cycle-paths.

* Cycle lanes need to have their surface maintained equally as well as the general road surface.

There are many places in Glasgow where the condition of the surface of on-road cycle lanes is terribly poor. Incredibly, in some cases the general road has clearly had some resurfacing work done to it while the cycle lane has NOT – as the road surface is quite different between them (e.g. parts of Kelso St).

Poor cycle lane surfaces cause cyclists to have to cycle out on the general road surface for their comfort, to make progress and for their safety.

* Cycle lanes should be designed to be convenient, without arbitrary sharp turns or deliberately rough surfaces.

Taking just the NCR 75 in the city as an example, there are several places where the cyclist must make sharp turns. E.g. to rejoin it just after Victoria Bridge, the cyclist must make a sharp turn and go over cobble – the gate that would allow the cyclist to avoid the cobbles is always closed. Next, at the relatively modern underpass for the Glasgow Bridge at Bridge St, there is a very sharp turn at each end and a ridiculous requirement for cyclists to dismount. This section could easily have been designed with a progressive bend on and off the underpass, and the underpass could have been made wider. Further along, where it goes under the M8, there are again sharp turns.

Having to scrub hard-gained momentum because of poorly designed facilities is incredibly frustrating for cyclists. The roads alongside NCR75 seem to manage to stay fairly straight along the same course, increasing the attractiveness of the road to some cyclists.

In summary: Capital expenditure on cycling infrastructure can be wasted, if that infrastructure is not maintained at least as well as the roads, discouraging cyclists from using them. Such capital expenditure is further wasted if its very design incorporates inconveniences to the cyclist (be it deliberately, in order to artificially force cyclists to give way to cars, or unintentionally because the designer simply is not a cyclist). Such issues may cause cyclists to ignore the infrastructure and use the general road instead – risking the wrath of the occasional motor-vehicle driver who considers the road to be solely theirs.

I would ask you to continue to invest further in cycling infrastructure, to encourage Glaswegians to take more to their bikes. The benefits of cycling to public health & traffic congestion would make such investment cheap in the long-run.

Comments (5)

How to make it easy for a maintainer to apply your patch

Jun 8, 2009 at 19:15 · Filed under Quagga ·Tagged , , , , ,

  • If you don’t know git, take a day or two to learn (it’s not that hard, and the gitk and git-gui GUI tools can help a lot)
  • Read through the existing commit messages to get a feel for the common style – and try use this style in your own commit messages:
    • A one-line summary as the 1st line of the commit message. You may wish to start it with ‘applicability:’, e.g. ‘bgpd:’, ‘netlink:’, ‘freebsd:’, etc. This is used for release announcements.
    • The body of the commit message, containing a high-level description of the goal of the changes, including the problem being addressed and the reasoning for the commit, on a change by change basis (e.g. per file, even per-function, if that’s appropriate). For a large commit, an introductory overview may be needed.The goal is two-fold: To force the submitter to perform a self-review of the commit (and so catch problems); and to give the reader the required context to review the commit.
    • An honest indication of the confidence you have in the patch, including what, if any testing has been done.
    • If the patch contains work done by others, e.g. because it is a rework of some other patch, indicate this. Though, ideally, the original patch should be a separate commit, attributed correctly with the –author argument to git-commit.
  • Read the HACKING document (parts are out of date though)
  • Prepare a branch, based on the Quagga.net master, that contains your changes and nothing else (merges from master are ok; if you need to merge it together with other things for your own purposes, then use another branch – they’re cheap).
  • If you like to rebase published branches, please name-space such branches with a ‘volatile/’ prefix.
  • Order the commits so the that the safest, least-contraversial commits are earlier in the branch than patches that are less likely to be mergeable. This allows maintainers to, perhaps, still be able to pull part of your branch if some patches are deemed problematic.
  • If you have a large and/or less-obviously-safe patch, try to split the patch up into smaller ones. E.g. there may be infrastructural improvements that can be factored out and go in first.

It’s extremely rare that contributors do all of the above. Commit messages in particular are often free-form. Sometimes they describe the problem, but not why the change fixes it. Sometimes the change is described, but without reference to the problem. Sometimes the message is akin to a C-to-english transliteration.

It might seem like a pain to force submitters to spend 5 to 10 minutes to go through their patch and construct a structured, detailed, but high-level description of their patch and their intent. However not doing so forces the reviewer to spend even more time to mentally construct the same. If you have many contributors feeding patches to a small number of maintainers, then it just doesn’t scale unless contributors make an effort to make their patches as reviewable and easy-to-integrate as possible.

In short, try to make life easy for your maintainer. There are several small, maybe even apparently trivial, things you can do quite easily which help reduce their load, and help smooth your patches’ path.

Updates: Git strips out []’s, so change section recommending patch subjects encode information in them.

Leave a Comment