Good one.

Then you simply cannot achieve your task. Or change your goals, do you really need all POI’s in Europe ? we have some tools to filter pbf files directly.

I don’t understand your questioning about the destination reference. Why not simply use the tag ‘ref’ on the link way if it’s valide after the junction node ?

wow, “bicycle tube vending machines” or “electric charging stations”. This is what we can call points of interest for all the people and not just for a limited category of users :-) lol

I’m assigned to this “challenge”: http://openstreetmap.us/iD/release/#id=w157598950&map=18.72/-122.27129/47.50951

What is wrong here ? is it possible that “bridge=viaduct” is not recognized by the QA tool ?

This is a really stange survey. You ask if the tag for a “park” is correct or not by pointing some examples in OSM. But you don’t show any aerial or on the ground pictures. Then only the local mappers can answer to your questions or we have to switch to another project just to find a possible answer. Next time, insert pictures or hi-res aerials in you survey !

About the size on disk, I agree that this is not the issue. In France, we had similar discussions about the “cadastre” source tag. But here, we must think first for the contributors. If some newcomer arrives to an already mapped city with 5 or 6 “addr” tags, he will be relunctant to do the same task for the new or missing or failing addresses where he could help and where only 2 are really necessary.

The KISS principle shall apply to the contributors and for that, “addr:housenumber” and “addr:street” are enough. Btw, I’m also against the relation “associatedStreet” more or less for the same reasons (keep it easy for the contributors and on all editors).

Well, if nobody stops the process, then it’s a kind of passive consensus. And this is not a small one, it’s about 30..50 million tags, I don’t know exactly.

Je note les buts et bonnes intentions. Si j’ai écris ce commentaire, c’est parce que la dernière phrase m’a fait tilté. Je pense que lorsqu’on se lance dans un projet d’import d’une telle ampleur, sans être assuré d’avoir assez de temps pour aller jusqu’au bout, il vaut mieux aller moins vite sur l’objectif final (compléter le bâti du département) et passer un peu plus de temps pour faire l’intégration correctement par commune.
Si le temps (ou l’envie) s’arrête avant d’avoir terminer, il vaux alors mieux laisser dans OSM des communes non importées et des communes importées mais proprement, plutôt que d’avoir importé toutes les communes mais avec beaucoup de problèmes qui restent à corriger derrière et qu’on laisse à d’autres. Le travail d’intégration avec l’existant est une part importante de l’import lui-même (même si c’est pas la partie la plus sexy).
C’est malheureusement avec ce type d’actions que les imports ont très mauvaise réputation au sein de la communauté OSM (ce que je déplore parce que je pense que c’est inévitable pour avoir au final la meilleure carte, ce que nous voulons tous).

Bon mapping,

“vous êtes libre de corriger les imperfections … A vous de jouer !”

Je trouve ça un peu facile d’avoir créer de nombreuses erreurs comme des routes qui traversent des bâtiments et de dire ensuite “démerdez-vous”. Lorsqu’on fait un import, cela implique aussi la responsabilité de l’intégrer avec l’existant. Et cela implique aussi de corriger la position des routes déjà mappés. Sinon c’est de l’import bourrin. Personnellement, je n’hésiterais pas à faire des reverts et demander un blocage du compte si je constatais un tel comportement dans mes zones d’intérêt.

-1 If it’s “non-editable”, then it has nothing to do in OSM. Create a mashup with external data if you are not happy. Admin borders are changing anyway, it shall be possible to modify them and I dont want to see a new elitist caste of super-contributors in OSM. And what after borders ? motorways ? place names ? population ? coastline ? bus routes ? etc… What we need more is QA tools monitoring the quality of the data in general. Special tools are already checking admin borders and coastline.

+1 to create a status of ‘new contributor’ with reduced write access to the db. But this should be limited in time (e.g. max. 3 days of contributions).

Your example in France is outdated:

osm.org/#map=17/43.95028/0.37758

Don’t copy others complains withtout rechecking ;-)

And I see no issue of importing buildings before tracing highways. Nothing in OSM is forcing a priority in features mapping. If you want to start with roads, good for you. If someone else wants to map postbox, forest, fire hydrants or buildings before any roads, why not !? ^^

Happy mapping

For history, just remember that the wiki page has been create a 1st april -> April Fool’s joke

Problem with public_transport is a birth defect : since its first porposal and during approval process, it was never clearly asking to deprecate “highway=bus_stop” for the simple reason that the new solution was more complex than the previous one for simple bus stops and the submitters knew they would fail in such way (by experience, all proposals starting with “depecrates this and that” are always slaped by responders).
The PT is nice for complex stations and multimodal connections. It’s also nice when you map PT networks from the operator point-of-view. But it is too complicate for the simple contributor who just care about a simple bus stop/halt.
My proposal : keep simple scheme for simple stops, “bus_stop” for a bus stop, “tram_stop” for a tram stop. And switch to the PT scheme for complex/multimodal cases only.

+1 with Richard’s comments.

I mapped several bus stops as a public transport (PT) user in the past but I stoped with the new tagging approved. See why:

The old scheme (ignore all optional/common tags like ‘name’, ‘operator’, ‘ref’, etc):
1 node where PT users are waiting + 1 tag (“highway=bus_stop”)

The new scheme:
1 node where PT users are waiting + 2 tags (“public_transport=platform” + “bus=yes”)
1 node where the vehicle itself stops + 2 tags (“public_transport=stop_position” + “bus=yes”)
1 relation “type=public_transport” + “public_transport=stop_area”

The new scheme is nice for complex cases, especially stop areas mixing several types of transportation (e.g. tram+bus). But this is painfully over-complicated for the ~95% simple bus stops. How can you convince newcomers that 2 nodes, 1 relation and 6 tags is “better” than 1 node + 1 tag ?

If the NYC government wanted to copy buildings that have changed from OpenStreetMap to the NYC building dataset they couldn’t as their data needs to remain in the public domain.

In the other way, if OSM license becomes PD, it will not be be possible to import data sources others than PD themselves. And many public data in Europe still gets some licenses which are ODbL or compatible but not PD.

Well, I’m not a lawyer but … I agree with Bart about legal expertise. The argument saying “odbl is complicated, move to public domain” is true in first part but is not enough for promoting the second. OSM could be more widely used if we (or the foundation) could provide a better support to developers, projects or companies questions about the license (better than “I’m not a lawyer but ..”).

Reporting something on trac doesn’t required power-users expertise. Between some hypothetical “easy reporting in one-click tool” and nothing, the “trac” tool already exists and the process of using it could be set-up quickly.

Do we really need a new reporting system ? we could reuse the trac tool with a special category “spam”