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 traffic_calming=choker. - 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 traffic_calming=table. - 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 served. - 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 asphalt/cobblestone/ground/etc. Gregory
_______________________________________________ Talk-GB mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-gb
