The one thing that depresses me about all of this is the talk of "they", and the passive voice ("this was done").

OSM used to be a community where people mucked in and helped. Where people got involved, found out what the arguments were, and if they thought something could be done better, lent their time to make it so. That's what built a terrific, unique project.

Now, instead, people just sit and moan in diary entries. A real shame.

Chris is right on this one IMO - if we find that OS OpenData isn't compatible with the new license+terms (and I don't believe we will), we'll simply go through the database and delete anything with 'source=OS OpenData' or similar. After all, if we'd been told that it was incompatible, how could we leave such ways in?

Good luck. Shall be sorely disappointed if you come back without any unmapped roads...

paulbiv: define "many" - I'd estimate that the number clicking 'decline' because of OS concerns is less than 10.

alexz: either you're confused or I am. We're not moving from CC-BY to CC-BY-SA. We're moving from CC-BY-SA to ODbL.

No, I don't think it's being done for obscure reasons, I think it's being done for good reasons.

As for "just have to assume" - of course you don't. It's a community project. You can help.

Saying that your contributions are PD is more than just a poll. I can't see any circumstances in which OSMF would be dumb enough to sue someone for using data which has been explicitly declared by the data's creator to be public domain.

The supposed 'Community Update' has absolutely no official status and was just plain wrong on the delay.

The licence change has been discussed very, very extensively over the last few years. If you've missed it all then I envy you, but within the confines of a volunteer organisation I think they've done a good job. If you feel it could be done better, you are of course at liberty to put yourself forward to election for OSMF and help.

Basically multipolygons-in-relations are a horrible hack. Hopefully API 0.7 will move them into an area datatype, and let relations resume the 'association' role alone.

Indeed - I noticed that earlier. Suspect that something has happened during the migration to git. I'll look into it...

Great stuff; documentation is probably OSM's single weakest point. "Couldn't load the map" usually means that you're zoomed out a long way in a city - so the API will refuse to deliver the data to P2 as there's simply too much. If you get a Flash crash otherwise then let us know - either by a trac ticket (http://trac.osm.org/) or on IRC.

Great stuff; documentation is probably OSM's single weakest point. "Couldn't load the map" usually means that you're zoomed out a long way in a city - so the API will refuse to deliver the data to P2 as there's simply too much. If you get a Flash crash otherwise then let us know - either by a trac ticket (http://trac.osm.org/) or on IRC.

When you say the "dreaded error" - what do you mean? What happened, and do you know what you did to cause it? I've never encountered that in P2.

But please, save early, save often. :)

Zverik: "convincing" is pretty simple. Good UI, efficient, probably using OpenLayers, works in all browsers, API consistent with the rest of the site, coded in clean Ruby on Rails like the rest of the site. What isn't convincing: some hacky PHP with a MySQL backend on a third-party server.

It's been suggested a zillion times. No-one has, however, ever come up with good convincing code to actually do it.

It's difficult to predict.

If only two people download your Bada app, that's fine.

If 5000 people download it, we have a problem and your app will be blocked.

Make sure you follow the Tile Usage Policy, as alv says. Do not let your app even approach the situation where it may be blocked: that causes hassle for OSM and hassle for you. As soon as the app becomes popular, be ready to switch to another tile provider. You may want to talk to companies such as Geofabrik. Make sure you can remotely change the tile server URL on your customers' downloaded apps, so that you are ready for this.

In general you should not use OSM tileservers for any paid-for app. Serving tiles costs money, and OSM's servers and bandwidth are paid for by donations and sponsorship.

"how about changing the max_speed tags to the practical real world settings rather than the theoretical speed limits?"

No. max_speed is for the official speed limit. If you want to tag the average speed, choose a different tag, then use mkgmap's rules (or a preprocessor) to take account of that instead.

Editors could probably be changed

Use of the passive mood is discouraged in this context.

You should join the mkgmap mailing list to discuss Garmin routing: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/

But bear in mind that there's no chance of OSM "revisiting the way tagging convention". OSM tags for OSM. It's up to third-party utilities such as mkgmap to interpret that in any way they see fit. If mkgmap wants to upgrade the priority of link roads, it can do so without requiring mappers to change what they do.

Hm, very strange.

It sounds like somehow you have managed to create a way with 0 nodes, which the server won't accept. If you can find a way to reproduce this (i.e. a series of steps that always lead to that error) then let us know and we can fix it.