champagne anarchist | armchair activist

Data

Het meest irritante verkeerslicht staat op de Middenweg

Het meest irritante verkeerslicht staat op de kruising van de Middenweg en de Wembleylaan in de Watergraafsmeer, zo blijkt uit een poll onder fietsers in Amsterdam. De Amsterdamse afdeling van de Fietsersbond noemt de top–10 van irritante verkeerslichten in een reactie ‘herkenbaar’. De organisatie heeft in het verleden al aan de bel getrokken over deze kruispunten.

Opvallend veel fietsers hebben de moeite genomen om hun keus toe te lichten, wat een schat aan informatie oplevert. Daaruit blijkt dat ze zich niet alleen ergeren aan de lange wachttijden, maar dat ze zich ook zorgen maken over de veiligheid, vooral op plekken waar veel (school-) kinderen moeten oversteken. Sommige fietsers houden even goed de moed erin: Genoeg tijd voor een espresso daar!!.

Rode en oranje stippen laten zien waar irritante verkeerslichten staan. Als er opmerkingen over het verkeerslicht zijn gemaakt is de stip rood. Klik op een rode stip of type hieronder enkele letters om de opmerkingen over een bepaald kruispunt te bekijken.

De top–10 is als volgt:

  1. Middenweg / Wembleylaan
  2. Amstelveenseweg / Zeilstraat
  3. Middenweg / Veeteeltstraat
  4. Rozengracht / Marnixstraat
  5. Meer en Vaart / Cornelis Lelylaan Nz
  6. IJburglaan / Zuiderzeeweg
  7. mr Treublaan / Weesperzijde
  8. Frederiksplein / Westeinde
  9. Nassauplein / Haarlemmerweg
  10. Van Eesterenlaan / Fred Petterbaan

Soms gaat het om routes waar de gemeente vrij baan geeft aan auto’s, ten koste van fietsers en voetgangers. Maar fietsers staan ook vaak voor rood licht terwijl er helemaal geen verkeer is. Wellicht komt dit doordat er bezuinigd is op het onderhoud van de lussen die zorgen dat fietsers worden gedetecteerd.

Er zijn flink wat klachten over auto’s die door het rood rijden (levensgevaarlijk!) of die het kruispunt blokkeren. Verder is niet iedereen tevreden met kruispunten waar alle fietsers tegelijk groen krijgen. Dit is handig als je linksaf moet omdat je dan in één keer door kan fietsen, maar het kan ook voor chaos zorgen.

De Fietsersbond vindt dat er bij de afstelling van verkeerslichten meer rekening moet worden gehouden met de belangen van fietsers en voetgangers. Uit onderzoek van DTV consultants blijkt dat het beter afstellen van verkeerslichten een eenvoudige en goedkope manier is om de doorstroming van fietsers te bevorderen en dat dit bovendien goed is voor de veiligheid.

Aanleiding voor de poll was een analyse van cijfers van de Fietstelweek, waaruit blijkt dat fietsers bij sommige verkeerslichten in Amsterdam gemiddeld meer dan 30 seconden verliezen.

Dank aan de Fietsersbond en aan Eric Plankeel voor inhoudelijke input, aan alle fietsers die hebben gestemd en vooral ook aan degenen die hun keuze hebben toegelicht. Meer over het meest irritante kruispunt in het Parool

Amsterdam’s most irritating traffic light is at the Middenweg

Amsterdam’s most irritating traffic light is at the crossing of Middenweg and Wembleylaan, according to a poll among cyclists. The Amsterdam branch of cyclists’ organisation Fietsersbond says the top 10 most irritating traffic lights are well-known problem sites.

Comments made by participants in the poll show that cyclists are not just annoyed about long delays; they are also concerned about safety, especially at locations where many (school) children cross the street. Some cyclists nevertheless keep their spirits up: Plenty of time for an espresso there!!

Red and orange dots show locations of irritating traffic lights. If any comments have been submitted, the dot is red. Click on a red dot, or type a few letters below, to see comments about a particular crossing (comments are mostly in Dutch).

Here are the ten most irritating traffic lights:

  1. Middenweg / Wembleylaan
  2. Amstelveenseweg / Zeilstraat
  3. Middenweg / Veeteeltstraat
  4. Rozengracht / Marnixstraat
  5. Meer en Vaart / Cornelis Lelylaan Nz
  6. IJburglaan / Zuiderzeeweg
  7. mr Treublaan / Weesperzijde
  8. Frederiksplein / Westeinde
  9. Nassauplein / Haarlemmerweg
  10. Van Eesterenlaan / Fred Petterbaan

Some are at routes where the city gives priority to car circulation, at the expense of cyclists and pedestrians. However, cyclists say they frequently have to wait at red lights even though the crossing is empty. This could be a result of budget cuts on maintenance of the systems that detect waiting cyclists.

Quite a few cyclists complained about cars running red lights (perilous!) or blocking the crossing. Further, not everybody is happy with crossings where all cyclists simultaneously get a green light. Such a set-up is nice if you have to make a left turn, for it will spare you having to wait twice, but it may result in chaos.

The Fietsersbond wants traffic lights adjusted to create shorter waiting times for cyslists and pedestrians. Research by DTV consultants found that adjusting traffic lights is a simple and cheap way to improve the circulation of cyclists, and that it also improves safety.

An analysis of location data from cyclists’ smart phones found that there are traffic lights in Amsterdam where the average time lost exceeds 30 seconds.

Thank you to the Fietsersbond and to Eric Plankeel for their input; and to all cyclists who participated in the poll.

How much delay for cyclists is caused by traffic lights

Road segments near traffic lights

The other day I posted an article on how much time cyclists lose at traffic lights in Amsterdam. Someone asked if I can calculate what percentage of total time lost by cyclists is caused by traffic lights. Keep in mind that delays can be caused by traffic lights, but also by crossings without traffic lights, crowded routes and road surface.

Here’s an attempt to answer the question, although I must say it’s a bit tricky. Again, I’m using data from the Fietstelweek (Bicycle Counting Week), during which over 40,000 cyclists shared their location data. This time I’m using the data about links (road segments). For each link, they provide the number of observations, average speed and relative speed.

With this data, it should be possible to estimate what share of total delays occurs near traffic lights. But what is near? It’s to be expected that the effect of traffic lights is observable at some distance: people slow down while approaching a traffic light and it takes a while to pick up speed again after. But what threshold should you use to decide which segments are near a traffic light?

One way to address this is to look at the data. I created a large number of subsets of road segments that are within increasing distances from traffic lights, and calculated their average speed. For example, segments that are within 50m from a traffic light have an average speed of about 16 km/h. The larger group of segments that are within 150m have an average speed of about 17 km/h.

Judging by the chart, it appears that the effect of traffic lights is diminishing beyond, let’s say, 150m. You could use this as a threshold and then calculate that delays near traffic lights constitute nearly 60% of all delays.

However, there’s a problem. Even if a delay occurs within 150m of a traffic light, the traffic light will not always be the cause of that delay. I tried to deal with this by estimating a net delay, which takes into account how much delay normally occurs when cyclists are not near a traffic light (in fact, I used two methods, that have quite similar outcomes). Using this method, it would appear that over 20% of delays are caused by traffic lights.

Now, I wouldn’t want to make any bold claims based on this: these are estimates based on assumptions and simplifications (in fact, if you think there’s a better way to do this I’d be interested). That said, I think it’s fair to say that average bicycle speeds appear to be considerably lower near traffic lights and that it’s plausible that this may be the cause of a substantial share of delays for cyclists.

UPDATE - I realise that the way I wrote this down sort of implies that you could reduce delay for cyclists by perhaps 20% just by removing traffic lights, but that would of course be a simplification.

Method

I used Qgis to process the Fietstelweek data. I used the clip tool to select only road segments in Amsterdam. I had Qgis calculate the distance of each segment and extract the nodes, which I needed to get the coordinates of the start and end points. Further processing was done with Python.

The dataset contains a relative speed variable (it is capped at 1, which means that it only reflects people cycling slower than normal, not faster). A relative speed of 0.8 would mean that people cycle at 80% of their normal speed. I calculated total delay at segments this way:

number of observations * (1 - relative speed) * distance / speed

You can then calculate delay at segments near traffic lights, as a percentage of the sum of all delays.

I tried to get an idea of how much of delay is actually caused by traffic lights, by estimating net delay. For this, I needed net relative speed. I used two methods to estimate this: 1. divide the relative speed of a segment by the median relative speed of all segments that are not near a traffic light; and 2. divide the speed of a segment by the median speed of all segments that are not near a traffic light.

Python code here.

DuckDuckGo shows code examples

Because of Google’s new privacy warning, I finally changed my default search engine to DuckDuckGo.[1] So far, I’m quite happy with it. I was especially pleased when I noticed they sometimes show code snippets or excerpts from documentation on the results page.

Apparently, DDG has decided that it wants to be «the best search engine for programmers». One feature they’re using are the instant answers that are sometimes shown in addition to the ‘normal’ search results. These instant answers may get their contents from DDGs own databases - examples include cheat sheets created for the purpose - or they may use external APIs, such as the Stack Overflow API. Currently, volunteers are working to improve search results for the top 15 programming languages, including Javascript, Python and R.

One could argue that instant answers promote the wrong kind of laziness - copying code from the search results page rather than visit the original post on Stack Overflow. But for quickly looking up trivial stuff, I think this is perfect.


  1. I assume the contents of the privacy warning could have been reason to switch search engines, but what triggered me was the intrusive warning that Google shows in each new browsers session - basically punishing you for having your browser throw away cookies.  ↩

Embedding D3.js charts in a responsive website - a better solution

I often use D3.js to create charts which I embed on my website (the chart below is included merely as an illustration; it was copied from here). Normally you set the width and height of the embedded page in the embed code, but with a responsive layout it’s not so simple. The challenge is to adapt the iframe width to varying screen sizes and change the height so that the chart still fits.

After struggling with this issue for quite a while I thought I had come across the solution and wrote an article about it. However, this solution has two problems:

  • You have to define the aspect ratio in both the embed code and the D3 code; ideally, you shouldn’t have to do that in more than one place;
  • More importantly, it doesn’t take the height into account of any title and captions that are not part of the D3-created svg. You could handle this by making the title and caption part of the svg itself, but this is a bit awkward, especially with multiline captions.

A while ago, I came across a different approach which uses HTML5’s postMessage. The embedded page posts a message containing it’s own height to the parent page. The parent page picks up the message and changes the iframe height accordingly.

A smart variant has the embedded page not only send its height, but also its url to the parent page. That way, you can identify the corresponding iframe by its src attribute and thus make sure the right iframe gets updated - which is nice if you have more than one iframe on a web page.

Here’s how it works. In the D3 code, set the width of the chart to the width of the div the svg is attached to and use the aspect ratio to calculate the chart height. Also add the following code to the embedded page. It will send its height and url to the parent page:

function sendHeight() {
  var height = $('body').height();
  window.parent.postMessage({
    'height': height,
    'location': window.location.href
  }, "*");
}
 
$(window).on('resize', function() {
  sendHeight();
}).resize();

And here’s the code for the parent page. It will pick up the message, identify the corresponding iframe and update its height (note that Drupal requires jQuery instead of $):

window.addEventListener('message', function(event) {
    if (event.origin !== 'https://dirkmjk.nl') return;
    var data = event.data;
    var height = data.height + 32;
    jQuery('iframe[src^="' + data.location + '"]').css('height', height + 'px');
}, false);

In the second line, the domain should be replaced with the domain where the embedded page is hosted (the line checks for the origin of the posted message for security reasons).

I haven’t extensively checked this but it works on iOS and Android. Since it uses postMessage, it will not work on some older browsers. Then again, D3.js won’t work on some older browsers either.

Credits go to thomax and Jan Werkhoven.

Pages