[Talk-GB] England Cycling data feedback

Gregory Williams gregory.williams at purplegeodesoftware.co.uk
Fri Jun 29 05:59:15 BST 2012

I've managed to complete a substantial portion of the merging of the England
Cycling data for the areas that I've put my name down for (Ashford,
Canterbury, and Swale), so I thought I'd provide some feedback on what I've
seen. Once I'm merged with these I hope to do parts of some of the other
areas that I've cycled in several times (and can therefore remember the
detail well); I've already done some merging near my parents, which is in
the Stevenage excerpt.


The data is pretty good overall. The merging process has been easy; it's
taken me only a few days to merge in just over 2/3 of the ways from three
pretty large areas. Given the recent CycleStreets announcement showing how
they use many of the extra tags that this new data provides I'm looking
forward to the enhanced routes that it'll be able to find cyclists.


Whilst doing the merging I've noticed these things:

-          There's a mistake in the translation of choker traffic calming
measures. The translated data has traffic_calming=choking, but it should be

-          It seems that the level of detail that the DfT data contains
about traffic calming measures isn't as fine-grained as ourselves. I've
encountered numerous roads where that translated data has
traffic_calming=cushion, but actually it's really traffic_calming=hump or

-          The existing traffic calming mapping that I've done here in Kent
is node based, rather than way based. I've done this because it's more
detailed and allows for determination of exactly which traffic calming
measures will be passed on a given journey - some roads have a variety of
different traffic calming measures down their length. Where the DfT data had
a traffic_calming key and I've already got the actual nodes mapped I haven't
copied across the traffic_calming key to the way, since it can be deduced
from the nodes and the presence on the way would just cloud the detail a
bit. I don't know whether CycleStreets uses the values from the nodes yet,
or whether it's just the ways? There are some places where the
traffic_calming tagging in the DfT data has enabled me to find places where
I hadn't managed to map the existing traffic calming measures for some
reason. So it's helped to increase our coverage too.

-          Some pedestrianised areas that I dealt with in Canterbury city
centre had some obscure tags in the DfT data, e.g. step_count=asphalt,
depth=yes, cycleway=yes. I obviously haven't copied the bits across that
weren't right, and it's pretty easy to spot them.

-          The DfT's translation hasn't taken into consideration the
distinction between cyclists being prohibited from using a highway (e.g.
some trunk roads) - i.e. bicycle=no, and where cyclists simply need to
dismount (e.g. the majority of footpaths) - i.e. bicycle=dismount, which
would be implied from a highway=footway, for example. So be careful to only
copy across bicycle=no when cyclists can't even walk their cycles there
(which is thankfully quite rare).

-          As has been mentioned before, the casing of cycleway:left=lane
and cycleway:right=lane wasn't translated correctly. Since these are pretty
obvious cases I did some mass translation of the cycleway:left=Lane and
cycleway:right=Lane to their lower case counterparts yesterday. Hopefully
I'll do that again to clear away any future merging issues. That should help
until Andy manages to get the case updated in the snapshots currently being

-          Whilst largely fine, the lit key values seem to have a few
mistakes in rural areas. I wonder whether some of them have simply been
computed by looking at the proximity of the way to lighting column positions
in local highways / DfT data. Certainly I note that in some rural locations
where the street lighting cohabits a pole with telecoms cables etc. the DfT
data seems to say lit=no, where it should say lit=yes. I guess that's
because these poles aren't full lighting columns and so aren't stored as
such in the local highways databases. Just a guess though.

-          In some places the surface tagging in the DfT data hasn't always
been completely accurate. Whilst it doesn't make much difference to cycle
routing there are a few places where the DfT data says surface=asphalt where
it should actually say surface=concrete. Other places which do potentially
affect routing are DfT data instances where it says surface=dirt but
surface=compacted would be more accurate.

-          The level of detail in the DfT data varies; not all relevant keys
have been captured in all places. So it'd be good to have some renderings of
the maps looking for holes in the full coverage. I wonder whether ITO may be
able to help with this? Here are some examples of maps that could be useful
for helping us reach a more full coverage:

o   highway=cycleway without segregated tag

o   highway=cycleway or highway=footway without either of the est_width or
width tags

o   Places where we have est_width, such that the pedantic amongst us can
actually go out and measure them and replace with a real width tag instead.

o   Highways without a surface.

o   Highways where the surface detail can be improved from paved/unpaved to



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-gb/attachments/20120629/59c52dbf/attachment.html>

More information about the Talk-GB mailing list