That doesn't necessarily apply for images. If someone uploads an original image to the wiki and releases all rights to it, OSM doesn't magically gain rights to it in the way that it might with data contributions or contributions to the text of the wiki. So if Richard creates a totally original image and decides that he wants to release all rights to it, then the image retains that status wherever it's used. Which is exactly why images uploaded to the wiki need to be correctly tagged with their licence independently of the text and data.

If this is what you're looking for, then start with the sample query under "Download an entire city" and change the number to 3600182130. If you've still got bits missing, then the relation either has the wrong ways in it or pieces are missing from it. I'd try it now but I'm at work so don't have my usual tools to hand.

I did make a thingy that would allow logins against OSM, but hit a few hurdles at the time - not least that the API would accept both username and email without telling you which was which, and reconciling name conflicts for those who have already set up wiki accounts with names that don't match. That said, in the time since I did that, Wikimedia has moved to a shared login and presumably had to deal with this so that part might be a solved problem.

So, how much mapping was eventually done at this "officially doing no mapping" event? :-)

If you're happy to have a map that's blank outside the city boundaries, find the relation or way that you need and stick it into the Overpass API. It has an option for doing something like this. I've used it to generate extracts of a single city district for testing. I think I managed to string together a query that would get everything within the bounding box and then complete any incomplete objects, though if I did they're now lost to history courtesy of a failed hard disk.

It looks like you might be 11 months too late ;-)

Of the major browsers, only Opera uses its own root UA. IE tends to use Mozilla/4.0 (compatible ...), and the others tend to be Mozilla/5.0. Looking down the list there appear to be a couple of spoofed UAs starting Mozilla/X.0, thouugh they do include the actual name of the app in them. The entries "Mozilla" and "Microsft Internet Explorer" concern me - are those inferences made by the server, or has something actually sent those strings as UAs? If the latter, then they're fake.

"People complain about JDownloadtiler with 0.5% when something called JOSM has 400+ UAs and more than double the downloads at 1.1x%"

The important difference being that JOSM is used by active contributors. OSM's primary product is data - the rendered tiles are just a convenient demonstration.

I would think we could regard the "Mozilla" UA as fake, since any such UA always includes a version, typically "Mozilla/5.0" if the browser is up to much.

Maybe we can serve rogue downloaders the equivalent of OpenWhateverMap?

Be careful in interpreting this figure. I discovered a couple of people in my area were tracing streets from Bing and adding their names from Locator without checking to see whether the names in Locator were actually correct. In the case of some of the streets, I only discovered the discrepancies by accident while driving through on a non-surveying expedition.

I figured the community at large might want to know before they find one day that a bunch of boundaries and parts of the Antarctic coastline have disappeared.

So, where did this (v3) come from? Or this (v2)? Or this (v6)? It's just that I know for a fact that there's no way you got those from the signs on the street. Particularly not in the case of the street that doesn't actually exist.

How much of this has come from fieldwork, and how much has come from "correcting" or "adding" names from OS Locator? I've seen more than one person do this around my way. I've probably spotted a couple of dozen streets in Swansea alone where the Locator name was wrong - spelling error, old name, or just plain wrong. That said, I did spot one street in Carmarthenshire where the street sign is wrong (and the residents have been complaining about it for the years since it was installed). I've also spotted a non-existent road, and bizarrely Morriston Hospital (which for some reason has a Locator bounding box smaller than the actual hospital has ever been, and nowhere near the entrance).

That sheds some new light on it. I wasn't aware it had been on Google Earth since late July. I would say something about getting it updated, but Mikel was on the ball right away.

They can say whatever they like - the maps are out of copyright, and "slavish reproduction" lacks originality. Unless they've gone to the trouble of rectifying them for you, or have restored them to such a degree that they could be argued to not be the same map, you don't need their permission to use what they don't hold exclusive rights to. The point made in the US in Bridgeman v. Corel was affirmed (albeit because it didn't apply) in the UK in Antiquesportfolio v. Fitch. Unfortunately for them, simply saying "you need our permission" doesn't magically make it so. The National Portrait Gallery tried a similar stunt with Wikipedia - and it backfired badly.

Geraniums were discussed at this meeting? I think we should be told!

It's arguable that you want the landuse= to move with the road if it is moved in future, so gluing the areas either side to the road does make sense (though not gluing the areas to the road also makes sense, for different reasons). There's an argument to be had about having separate landuse= for separate "areas" when each has its own name, which presumably can also be tagged with place= or addressing attributes, Or Something[TM].

I would suggest that actually the biggest problem is that coastlines are generally taken to be high water, which implies that for anywhere with a tidal beach the bit you want is not usually covered in water. That might pose a problem for the kayak. ;-)

I'd be brave and suggest that there's nothing wrong with a semi-colon value separator in the amenity field. If someone's "find me a cafe" tool won't pick up an amenity=restaurant;cafe then their tool is broken. This is the kind of nonsense that leads people to go and insert spaces or alternative separators (e.g. "x/y" or "x - y") because they think that "x;y" is ugly when rendered. It *is* ugly, but if it's rendered that way, the renderer is broken. I did raise this issue before but it seems to have been summarily ignored.