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.

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.

Why not? What happens when you try to upload?

"check that all the ways are nicely connected and in the right order"

Don't be silly. Any programmer worth their salt can sort route relations into the right order. Mappers are our most valuable commodity; we shoudn't impose additional burdens on them to help lazy programmers. Route relations are not required to be ordered and nor should they be.

I've fixed the way-deleting bug but it needs a little API change, and we just need Matt to consent to Tom committing my patch for that. ;)

We discovered a 'blocker'-level bug the other day which is probably what's causing stuff to be lost in P2. Basically, it happens if you delete a way where some of the nodes are off-screen, but are also shared by other ways. Unfortunately fixing this will require a minor change to the server API - otherwise I'd have committed a fix already - but hopefully we'll be able to get it sorted in the very near future.

You should be able to hide the stuff to the left of Potlatch - press 'M' (for maximise) after you've started editing. :)

Every successful save will go into the database. You can have several saves within one changeset, so even if the last one fails, earlier ones will still be fine.

"What do all OSM editors have in common?"

Let me guess - you haven't contributed any code to any of them?

Sorry, cheap shot. But we're volunteers like you and doing the best we can - honest. If you look at the amount of changes (read: improvements) made to Potlatch 2 alone recently, it's pretty staggering: http://trac.openstreetmap.org/log/applications/editors/potlatch2 . 100 changes in under a fortnight. From what I see of the logs, the JOSM and Merkaartor codebases are just as active. It's not enough - we could do with more developers, but OSM has had a chronic shortage of developers since day one. Potlatch 1 was largely a single-person effort. With P2 we're up to three or four core developers, which is a huge improvement (and unlike me, the other two or three are proper programmers ;) ), but still pretty minuscule.

With upload errors - we're looking at it but Flash (or strictly speaking the NSAPI plugin architecture) doesn't make it easy for us; if there's an error, there is no way for Potlatch 2 to find out what it was. Which sucks astronomically. There are almost certainly ways round it but it's not the sort of thing where we can commit a three-line, ten-minute code change to fix it, believe me.