Absolutely Harry. I'm keeping a careful eye on this post because I definitely don't want it to turn into a set of "slag off the noobs" answers. I'm interested in finding where the common problems are so we can help the noobs (and everyone else).

As a new user who's registered but not (yet) edited the map, I'll suggest that some sort of introduction to editing the map is desperately needed. Or if there is one, it needs to be much more prominent; I found my way to this "help centre" looking for such a guide, and still haven't found one. I'll be glad to have a go at mapping once I figure out how!

Update: Via the blog post linked above, I found my way finally to the Beginners' guide, but I'll suggest that it should be much easier to find!

I'm not surprised that MANY people sign up then give up. The instructions and answers are spread over many different systems and I haven't found answers to some pretty basic questions yet. I had to create a second login to post this comment and more logins are required to participate in discussion groups. I tried watching a video, but it's just too large for my rural connection. I am very discouraged at this point. I edited databases from '75 to '88 and continued with systems design work until '01 but I'm not sure that I can find out how to help here.

Hello, I registered today since I am using OSM heavily on my ANDROID phone during my trip in Japan and intend to contribute. Looking for a tutorial, I came here. Here a good tutorial on creating OSM maps: https://help.openstreetmap.org/questions/28251/interactive-tutorial-to-getting-started-editing-osm including the following links: http://learnosm.org/en/ http://wiki.openstreetmap.org/wiki/Beginners%27_guide This should save you at least 30 minutes of searching around for tutorials, beginners guides, OSM basics, etc.....

Yes, and it is also helpful to try to avoid "big" changesets, and make them small enough that the description is precisely referring to the actual changes made.

sometimes with potlatch2 I start editing and save and give a description of the edit, then go on editing and the program doesn't ask me for a new description... so my second save inherits a description that isn't necessarily correct.

You can ask Potlatch 2 to close a changeset by pressing "c". Then the next time that you save, it'll ask you for a new changeset comment.

In general I'd say this is not so much a "common mapping mistake" but more of a thing we'd like new users to "graduate" onto doing, once they're getting the hang of editing. I don't think it should be regarded as essential, or rude not to. I do always try to add a good comment. Techy people are very fastidious about this kind of thing, but it might take some new users a while to pick up the habit, and that's fine.

@miriotomo yes. I make the same mistake quite a lot when dipping into Potlatch editing. I know about the 'c' button, but tend to save by mistake expecting to be asked (like in JOSM)

@SomeoneElse You might want to add "and creating changesets than span continents". It's exactly the same problem, as the following mappers can't see what has happened. It also completely breaks the history page of openstreetmap.org.

I know this subject has been pounded into the dirt, however, the primary/secondary/tertiary and footway/cycleway/pedestrian/path distinctions seem to cause the most troubles.

In Portugal and Cyprus I have entered roads with highway=road because it is impossible to rate them on a survey. However all these have been edited to highway=unclassified.

In Cyprus, even some dense residential areas do not have street names but block names (eg Sea View Gardens on one side of the road and Sunset Villas on the other) and I still have not figured out how to name the highway=residentials.

I have sometimes used landuse=residential name=Sunset Villas but what about the addresses when one side of road belongs to Sunset Villas and the other to Sea View Gardens?

This is not a forum. You should convert your comment to a new question ;-)

You can see this quite often in Italy: highest highway class in urban centres (sometimes quite big ones with place=city) is tertiary or unclassified. All primaries stop before the city and restart after it. Up to some time ago even Milan had only tertiary streets inside the city, but fortunately this is slightly improving now.

That's a good one! I only recently started converting some of the streets that I (and others) had tagged as tertiary to unclassified. I had completely misread originally what unclassified meant. And I do live in one of those countries, for which this classification means little. I don't know if this is cheating, but when in doubt I peek at Google Maps. They only have two colors: white and yellow. I have decided that Google's yellow covers our primary, secondary and tertiary. If a road is not yellow in Google, I tend not to tag it higher than unclassified. Or is that another mistake? ;)

because it's reported by almost all quality assurance tools and cannot be fixed without a second survey

I've more then once found where people who look at the quality assurance tools think they can fix this without a second survey. They draw a bridge where there is no bridge in the real world. This is really irritating, because it replaces a very visible error with an error that is hard to find.

For truck routing it would be also extremely useful if you could as well specify, if there are any height restrictions underneath bridges!

Please check the OSM Wiki for Maxheight tag. There's also a QA tool around to help you find potential missing maxheight tags in your area (-> search wiki for "Maxheight Map").

Note that segments are gone in the latest version of the API.

@Arlo James Barnes : I think this is a misunderstanding, Pierzen used segment in its ordinary not special OSM sense as a type of element.. Like me (and this help forum) he started editing OSM long after segments as OSM elements disappeared.

Bing offsets are frequent in its satellite imagery (correct medium resolution but imagery is not rectified) : Africa, Russia, Canada, Latin America, most of Asia.

But in US and most of Europe, where high-resolution orthophotography is available, this is no longer a problem as most areas are covered (but there remains a few spots in Europe only covered by satellite, e.g. Corsica, Sardinia and Sicilia, most of Switzerland and Austria, a North-West sector in Germany near the Netherlands, and about one half of UK).

I'd disagree that "this is no longer a problem" in Europe where aerial photography is available. Maybe 100m offsets are a thing of the past there, but imagery still needs aligning.

I often find myself going to Google Earth to get better angles on hidden objects, looking at it for reference because of the higher quality at max zoom, or using Streetview. Is that considered "copying"? Its practically required considering how much I do detailed edits, that my edits are more detailed than even traditional micro-mapping.

@Mxdanger yes, unfortunately we can't use Google Earth even for "reference".

All those unneeded nodes make the database a lot bigger without even adding a single bit of detail (sometimes, making it even harder to align the road better, or introducing curves where there are none).

So I agree with this one, straight ends don't need nodes, and those nodes should be deleted when editing a way.

Note however that straight highway are not really straight above some distance (almost never for streets in cities at distances higher than 50 meters: you need additional nodes for changes of lanes, parking lots, turning lanes, and trafic calming reduction of widths; even for motorways in rural areas, the line is not straight above about 200 meters. Placing nodes correctly at reasonnable distance improves the precision and avoids making deviation angles visible when there's effectively a very clight curve. As a rule place the nodes as exactly as possible in the middle of the road on the visible painted signals between the two directions, and avoid this line to cross more than a single lane or getting out of the road (through side drains or though kerbs separating side walkways or through security barriers.)

yes, you will need more nodes for detailed mapped features even if they consist of straight lines, because of changing properties and intersecting ways. As a rule of thumb, when mapping highways in "significantly incomplete" areas, you can put a node on each intersection, even if you don't add the crossing highways at that time.

I wish Potlatch2 gave better tools for adding source easily. For example: similarly to how R replicates all tags from the last touched object of the same class (which is awesome), so S or Ctrl-R or some hotkey should replicate just the last entered source.

I know this is not the place for Potlatch wishlist (although now that I typed this up I might just create a Trac ticket :), but I'm just trying to explain why I, for one, am being bad about stating the source. Too much work, too little to show for it (literally).

I suppose we could at least add the source to the changeset, if that helps.

Ponzu, I found out quite recently, the key "B" shortcut for Potlatch2. Just press it in same manner as "R" replicates, and "B" puts in the current background as the Source - great for when u are tracing from Bing or the like.

Please don't use source=* on single objects. Instead, use it on the changeset. On a node with several tags, nobody knows which tag (or maybe its position?) the source tag refers to. If you feel that you use multiple sources for your changeset, either make your changeset smaller, state all sources or further elaborate your changes in the changeset comment.

@Chaos99 That works if every item in a changeset has the same source, but not if they don't. As for sourcing individual tags (if it's necessary, which it usually isn't!) Taginfo shows that "source:blah" is well-used and accepted.

Basically - use whatever's needed to communicate with future mappers, whether that's changeset source tags, item source tags or even something more granular.

@SomeoneElse I've already mentioned splitting the changeset, giving multiple sources and using the changeset comment. source:bla indeed solves the reference issue, but still pollutes the database. We should at least use the method most suited to the specific task. 10000x "source=BING arial imagery" on building outlines doesn't give us any more info than once on the changeset.