I think the west approach does physically separate into four at the junction but not as far back as the separation point; I’d have to take another look to be absolutely sure.

There are 6 lanes entering from the west;

• one lane left
• two straight ahead
• one bus-only lane right that feeds into;
• two unrestricted lanes right

The left lane could peel off just before the junction but should IMHO remain distinct as the flow-control for it is different than straight-ahead. The bus lane and general right turn should remain distinct due to different legal access and flow control. There is also some physical separation of this lot.

In general, I agree about physical separation - the northern approach was originally a single two-way but has been turned into two one-ways which is a bit of a nonsense.

Here’s a start. At least we have some rational connectivity back:

osm.org/browse/changeset/11708472

I considered this a while back and then gave up - I had a number of overhead bridge-linked buildings where the bridge footways just stopped at the edge of the building rather than joining up together via the internal building walkways. Should all levels be put in including stairs/elevators to make the routing work? It gets messy...

eg: osm.org/go/eurWIaVYX--

btw. you might like to consider using the covered=yes tag.

Hmm, I've uploaded some new ones and the old ones all appear to be back...

Indeed, neither route is completely finished yet... The 'suggest' stops was a good start though. In most cases where it added erroneous stops, it indicated that I had a bad role setting or misaligned way/naptan stop.

I'm no legal expert.

It looks like using the data directly (eg. importing the Post Codes or street names) requires creative commons attribution (http://creativecommons.org/licenses/by/3.0/). I don't know if that's a show-stopper for OSM.

Using the data indirectly (eg. for tracing or reference purposes) may require attribution at the point of reference only. If so, I imagine the mapping could be pulled into potlatch as a background layer and derived work would be license-free.

Yes; there's some related info here osm.wiki/Topographic_maps_for_garmin_devices#Combining_the_data

The process is similar if using gmappsupp files; essentially you need to ensure that the family name/ID of the map tiles in one gmappsupp are different to the name/ID of the tiles in another gmappsupp. You can use gmt to query the details and alter them as necessary. You can also use gmt to join them together. On your garmin (I have an eTrex Legend), go the the setup->map setup page. Move across to the option where you can select individual tiles to display and then (and this is the important bit) hit the Menu button. The popup menu allows you to selectively show/hide whole map families within your combined gmappsupp. I only recently discovered the whole family show/hide option, previously thinking that the only way to achieve this was to tick/untick each individual tile img.

Take a look at http://openmtbmap.org/