@union4 Naturally if it is just a misunderstanding and you don’t intend to import but want to trace the outlines, sorry. However you should understand that we have suffered and continue to suffer from hit and run imports in the US that as a tendency tend to be badly executed on top of that.

Have you read osm.wiki/Import/Guidelines ?

The original question was

Is the workload more evenly spread throughout the community when it comes to Missing Maps tasks as opposed to HOT tasks?

I’m of the opinion that “workload” cannot be interpreted different than actual contributions to producing a usable map. Given that, you do not answer the question. You do however, again, try to spin things so that missing maps looks better than it is.

Das schöne an OSM ist, dass man ja viele verschiedene Sachen mappen kann. Gebäudemappen geht eigentlich allen auf den Geist mit der Zeit, mach einfach nach Bedarf (zum Beispiel wenn du Adressen hast zum Ergänzen).

Thanks mvexel.

Wrt MapRoulette the Notes/Osmose code was written with an eye to including further services with similar workflow, from that pov adding MapRoulette wouldn’t be an issue. However you would need a public API in some form (likely returning all tasks from all challenges in a bounding box and a call to update the state of a task).

Hmm, audio mapping was my preferred method of gathering data more than 5 years back when I started with OSM. It is bearable for larger features (name of the road you are currently on) and quite enviroments (non-moving or enclosed) but doesn’t really work due to:

• positional errors (I stll now and then run in to stuff that I ampped back then which is “one-off”)
• spelling (anything with a name is dicey)

@Hendric Stattmann Schweiz != Deutschland

@Pico47 kann ich dich noch motivieren ein bisschen bei osm.wiki/OSM_-_GWR_Street_and_Place_Names_Comparison resp. http://qa.poole.ch/ch-roads/ mitzuhelfen? Natürlich sind Hausnummern auch immer gern gesehen (und alles andere auch :-)).

Besides that reducing the size of the planet file by such a small amount woudn’t justify anything, removing the nodes creates a new version of the way adding to general database bloat.

Further none of the editors nor the API support downloading elements that have no nodes in the requested bounding box. As a result it makes sense to have not all too far apart nodes on even completly straight ways..

It should be noted that we have massively (as in multple nodes per meter) overnoded ways from imports that naturally can be simplified when detected.

@SimonPoole/diary/24124

@andygol how many of the increasing number of relation based turn lanes are from you and other Mapbox employed mappers?

@maning & @seav the wording is simply a bit ambigous. First citing a third party that the licence is incompatible and then continuing with “Even if the licence is compatible ….” it really isn’t and the permission we got for a handful of countries was after the fact in dire circumstances.

To be very clear: anybody that imports GADM data -now- -will- get caught and the data -will- be removed immediately..

I’m not sure why you are assuming that GADM data has a acceptable licence for OSM (no issue with the rest of your post though).

Please see: osm.wiki/Contributors#GADM_.28Global_Administrative_Areas.29

EdLoach naturally you could have created the note with Vespucci and in 0.9.7 uploaded it when you got home and checked all Osmose reported problems in the area too :-)

But seriously it really depends on what you are doing, some times I’ll just snap a photograph, sometimes I’ll enter stuff on the road immediately (typically POIs and housenumbers). I’m not claiming that there is a one size fits all solution, not even for myself.

BTW I believe that post 1.0 release versions of Pushpin are actually better than what I wrote and provide at least some support for non-node objects (pushpin overall isn’t a large source of edits in OSM in any case for my reasoning on that see below).

As to a user friendly editing tool, sure it is possible, just take the effort for iD and mulitply by 10. iD already tries to do smart things like automatically generating a multi-polygon when you split a polygon/closed-way and it serves as a good example to gauge how much extra effort would be needed to expand that kind of level of abstration to all of OSM and where the pitfalls are.

But the real question is: is there ienough breathing space between pure surveying apps and full blown editors (Go Map! and Vespucci) to actually get a enough of a user base that the developement effort can be justified., I’m fairly sure that either you simply want to survey with implied adding the data post-survey at home, or if you enter it in to OSM directly you don’t really want to touch it again and keep post-survey clean up to a minimum. The consequences of the later is that you really do need to able to do nearly everything that you can do on the desktop. I should point out that surveying on the move is not the only use case for mobile editors so they will tend to have more functionality than “add a POI” apps will have in any case.

BTW my recommendation for a survey app on Android continues to be OSMtracker plus OpenCamera if you just want to take photographs (OpenCamera works well Vespucci too).

Yepp, just as all the other apps which

a) don’t show you what is already in the OSM data

b) take the hammer approach to editing (replace nodes with nails)

pushpin is just one of a number with the same issue not worse or better than the whole lot.

@mvexel the basic notion that it can be “simple” to just add a “poi” is mistaken. It is a consequence of the OSM data model for better or worse that a POI can have many many different guises and the only way to handle that without breaking things is to have a full complement of the existing data available with all the complications that implies.

So maybe the answer is that android users would prefer not to break existing data, contrary for example to people that think push pin is good.

@ Duck the mode doesn’t really have a bearing on element selection (you still need to be able select nodes in the end), but I find the change I made for 0.9.6 with the smaller default node touch regions have made it significantly easier to select ways in high density areas.

Well a different way at looking at it would be to say well we have roughly 40’000 mistagged objects of a good 80’000’000 (just counting nodes with tags, in reality the number is larger)..

In other words: we have the incredibly large error rate of 0.05% aka “not a problem”.

Vespucci will allow you to do that.

However this is currently works slightly different than the normal editing mode and requires a mobile data connection (the Notes code is currently in the process of being refactored and will allow pre-survey bulk down- and post-suvey upload in the next version, similar to the normal editing mode).

Naturally if you are using vespucci you might as well directly add the stores to OSM.