It should really be marked as railway=construction construction=light_rail or something, with the name "DLR Stratford International Extension", the NLL all the way into Stratford is being converted supposedly (using the original platforms 1&2, since the mainline ones were moved) (according to wikipedia)

"One problem I am facing right now is that a single node movement can cause a way to change without the way being mentioned in the changeset. There is no way in the current API to find out which ways a node belonged to at a specified point in time. I can only guess this at the moment, maybe I will parse the history view on the OSM homepage in the future, as the way membership seems to be listed there."

Unfortunately, although its listed there, it is not correct, it always lists the current version, since the version of the node is not stored in the way's history table. (Since a node can be changed without a new version of a way being created (potlatch ignores this, and creates a new way version anyway))

testing bug on commenting that's cropped up on dev

Label rendering is an outstanding issue with mapnik, it tends to only render a name once on a way, meaning that on very long ones, they may get lost in the middle somewhere. It should however render shields more frequently, in fact one is visible on the D854 3 zooms in from your first link.

The unpaved tag should have no impact upon its rendering, since I don't think its yet used at all.

In this case, since these roads are the best the country has, I'd be very tempted to promote them to primary / secondary roads as appropriate. We already do have allowances for the usual highway types to be defined on a per-country basis - highway=*#International_equivalence

Thanks for the edits, it's a blank spot that I've been meaning to fix for an age now!

I was going wtf at purley, until I realised there's also a Purley on Thames.

Good news is that some over-zealous person has already deleted it. Or at least edited it to the extent a new way was created...

Ignore the error, representing it this way is fine. I've had a similar issue, but a barrier is between the two mini-roundabouts osm.org/?lat=51.365831&lon=-0.186636&zoom=18&layers=B000FTTT

Fantastic job, well done on all the detail.

As the current author of the software to convert the UK's NaPTAN database, we'd be interested to see the methods you've used for tagging the data up, since you noted that QROTI roughly followed the NaPTAN scheme on teh wiki.

I'd be interested what WML can do that OL can't :)

The mappa mercia OSB code is just a rip of the stuff from the OSB site, which isn't the nicest code in the first place, I'll probably get around to writing my own OL-side implementation of it.

Let me guess, Cloudmade product launch venue?

It's a shame to remove perfectly good data because it gets rendered badly - leave the data in and tell the renderer's author to fix the bug!

Be sure to add your import to osm.wiki/Import/Catalogue

Maybe a namefinder query would be a good start?
http://gazetteer.openstreetmap.org/namefinder/?find=Darwin

I'm sure there's a nice feed for it somewhere that could be stuck onto an OpenLayers OSM map.

A demo, http://ge.pythonmoo.co.uk/maps/osmrelations.htm
Also shows the upcoming method of vector handling in OL, currently broken with reprojectioning stuff. (Tower Hamlets)

Arrgh! You've used the evil piece of GPX code that should really be sent to /dev/null.
Anyway, there's an easier way to do this. Just grab the full OSM file from the API, and add it to OL using the Vector layer + OSM format.

Oh, great idea! I think thats a good excuse to get out.

There's an OSM app?

All fine, although I'd not personally use merkaartor (although only because of a dislike for qt)