For outlets/concessions of one brand mapped within a larger store of a different band, if I was adding the address to an OSM object for the former, I would typically include the name of the larger store in the addr:housename=* tag. This then leads to a sensible address, when you compile the various addr:* tags. For example:

• Tiny Town Post Office (name)
• Co-op Daily (addr:housename)
• Main Street (addr:street)
• Tiny Town (addr:city)
• TT1 1AA (addr:postcode)

So I’d use that for the Carphone Warehouse outlets, adding a addr:housename=Currys PC World to the Carphone Warehouse node. (I’ve already done this for a few of them I spotted, which will allow me to automatically remove false positives from https://osm.mathmos.net/ghosts/ when Carphone Warehouse gets added to that tool next month.)

You’ve made highway=unclassified and highway=residential narrower than they currently are – presumably to distinguish them from highway=tertiary, which is now the same colour. That’s fine in general, but when road names are displayed on these roads, the font used in the examples above, doesn’t seem to fit nicely inside the road casings. I’d suggest either reducing the font size or increasing the road widths slightly, to get a better fit.

It’s ok with the overhanging lettering on z=15 when there isn’t much other detail to see, but I’d do something on z=16,17,18,19. A bit of overhang on z=16 would probably be ok, but I’d go for less than you currently have. On 17 I’d probably make the font a bit smaller, and on 18 and 19 make the unclassified and residential roads slightly wider.

For UK use, it’s vital that the style distinguishes between highway=trunk and highway=motorway, as the two roads have different rules and restrictions. If the number of different types of roads that can be distinguished is limited, then it would make more sense to group highway=trunk and highway=primary together – although that wouldn’t really be ideal either.

I understand why it would be advantageous to avoid using green and blue for road colours, but in the UK, those are the commonly used colours for motorway and trunk roads on many different popular maps – as are derived from the colour of the road signs on those roads. For UK users, maps using different colours are going to look strange, and that may harm adoption. Perhaps we need to look at using different colour schemes for different countries…

Is the new “shift-click away from a way” stuff documented anywhere? I’d recently noticed that sometimes it was moving an existing node rather than inserting a new node, when I wanted the latter (old) behaviour. Knowing more about what it’s doing now and why/when would be good.

The Overpass API at http://overpass-api.de/ can be used to query the OSM database in lots of different ways. If you want to extract all the ways and nodes that make up the UK railway network, both past and present, then you’ll probably want to find any ways tagged with railway=rail, disused, dismantled, abandoned, preserved, and possibly narrow_gauge too.

The Overpass Turbo service at http://overpass-turbo.eu/ can be used to test queries and get a quick visual output of the objects that the query returns. Something like the following may be what you want: http://tinyurl.com/bl2gawv (Once the page has loaded, adjust the map view as required, then click on “run” in the top left to get the results.)

Once you’ve got the output from the Overpass API, you’ll need to convert the JSON or OSM XML data into the format (eg GPX) that you want.

Of course, there may well be gaps in the disused railway network in OSM. Opinion is divided on whether or not we should store old railway routes which are no longer visible on the ground. Some people suggest using railway=dismantled for this, rather than disused or abandoned.

If you want to extract specific old lines automatically, then they would need tagging in some way to identify them. Again it is debatable whether this is appropriate, given that the OSM database is primarily there to record the current situation. However, it may be permissible to tag former railways with something like former_operator=* or former_line=*. Alternatively, one could create route relations for former lines, mirroring the relations used for current lines, e.g. http://www.openstreetmap.org/browse/relation/138808 . (For more information about relations, see http://wiki.openstreetmap.org/wiki/Relation .) But please discuss what you plan to do on the talk-gb mailing list before going ahead.

This looks great. Would I be right in thinking that the map data being used is a snapshot taken from OSM at some point in time?

Are they using the raw OSM data (possibly with some transformations before rendering) or did any manual edits need to be made outside OSM? How is it planned to mange merging in future changes that occur in OSM?