Perhaps you could render highway=street_lamp as point light sources?

Create a new relation, with type=restriction, and restriction=no_right_turn tags and add to the relation the way before the junction with role 'from', the junction node with role 'via' and the restricted right turn way with role 'to'. Be aware that not all routing algorithms currently support turn restrictions, but the surviving ones likely will.

You could use addr:housename for the taught subject and addr:housenumber for the building identifier, then use the name tag to display the building code by default.

Double posting shouldn't be possible if a simple content hash is made and compared before adding another entry on the server.

Spam with compliments :)

Soccer and football are shortened terms for Association Football, so rather than use a tag that's specific to US/Australia (but it is distinct in meaning) I opt for sport=association_football, which is a similar name format to the other options. It's up to the renderers to apply a suitable graphic for that tag. Soccer may be shorter, but the rest of the world calls it football.

Spam didy do dar spam!

There doesn't appear to be a means of saying that the spots should be ignored because of being false positives like the KeepRight site can do.

If you look at the changeset(s) containing the uploaded Juli POIs and click on some of the nodes then you should be able to see the node history and consequently the user account that changed their visibility state to hidden, i.e. 'deleted'. You could send a message to this user account to ask why they made such deletions. In theory the visibility states of the original, deleted nodes could have also been made visible again.

See the "Copyright & License" link from the left-side menu first.

That first link should be:
osm.wiki/List_of_OSM_based_Services

To re-render, right click on a Mapnik (the renderer) PNG tile at a certain zoom level to get its URL from image properties, then append /status to the path and request this URL in a new window/tab to find out its current render status. Replace /status with /dirty and refresh if you wish to manually add the tile to the re-render queue.

The obvious thing is that OSB should notify OSM users with registered locations near the reported problem locations just once. That will bring things to people's attention with a push-type rather than hoping that they manually check up on these things or are even aware of OSB.

Maybe the server should use a hash of the post and prevent duplicates by looking at previous posts by the user in the same thread.

Any particularly reason you're not using the more secure Firefox 3.6.6?

I haven't actually asked for any changes. I do more additions to OSM than what I download from it. I was just concerned about the longevity and usefulness of the project where lack of tectonic drift accounting means that everything loses accuracy with time. I accept that compromises have to be made for a non-commercial project.

What initially got me concerned was seeing Ordnance Survey quote 1 metre per year as a maximum for tectonic movement. However, having looked into the rates more I realise that was mainly in the vertical component and thus not that applicable to OSM. The largest lateral movements tend to be 10 cm / year, which equates to around 6 metre drift within my lifetime. I do apply the right source tags for OS OpenData imports, but what I shall also do is tag a record of the UTC date when the conversion into WGS84 was made.

Except people who have imported OS OpenData such as political/administrative boundaries which aren't physically there and don't tend to change, except within OSM. Most of the data being added is of course low accuracy, +/- 2 metres for my GPS unit itself. But OSM shouldn't be throwing away accuracy and precision where it is freely available from governmental sources.

The road in question can be seen at: osm.org/go/eu26DmCRr--

The road in question can be seen at: osm.org/go/eu26DmCRr--