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--

Plenty of duplicate nodes still to be resolved in Texas too:
http://matt.dev.openstreetmap.org/dupe_nodes/?zoom=8&lat=31.65821&lon=-99.32729&layers=BT

It would have been good if these comments had been entered individually with each changeset rather than after the event :)

OS VectorMap District is due for release as part of OS OpenData in May 2010, in theory less than a month away.

It is not a beta, but a developer platform preview release - one every 2 months prior to the actual beta builds. It won't work on XP, so no improvement in standards for the current majority user base. If only M$ had started in 2004.

Obviously spam. I'd block this user if I could, except I can't. I'd remove the content from the blog page too, except I can't and no-one else seems able to.

I've long been pondering a way to get my GPS tracker above my head when walking for increased accuracy. It doesn't support an external antenna so the best I can achieve currently is holding it with an extended arm. I'd really like one of those Ordnance Survey GPS poles with sub-millimetre accuracy :)

I agree, spam.

Cunningly the spam links are in the Lokko profile, rather than the posting.