Je suis étonné par le niveau de ces question de la part de quelqu’un qui vient de créer un site internet spécialement pour améliorer la carto de Brazzaville dans OSM. Ou bien, est-ce pour améliorer la carto de Google Maps/Earth ? Auquel cas cet appel à contribuer pour Google sur le site internet d’OpenStreetMap serait tout à fait indécent.

qu’appelez vous:” l’éditeur en ligne id “?

Aller sur openstreetmap.org, cliquer sur “Editer”; ça ouvre une application sur le navigateur internet qui permet de modifier les données géographiques d’OSM.

Si je complete un plan avec OpenStreetMap, les modifications apparaitront-elles dans Goole Earth et Google Maps?

Non. C’est deux projets totalement séparés. Google Earth et Google Maps, c’est des données qui appartiennent ou qui sont achetées par Google. C’est un projet commercial dont le but principal est de vendre de la publicité ciblée et de connaitre la vie privée des internautes.
OpenStreetMap, c’est des données géographiques libres et ouvertes. N’importe qui peut s’en servir et de nombreux projets externes, y compris commerciaux mais aussi des projets libres, en profitent tous les jours (à condition de respecter la licence libre ODBL).

En serat-il de mème avec les images aériennes Bing?

On a le droit d’utiliser les images aériennes de Bing pour éditer et tracer les données dans OpenStreetMap. Mais uniquement les images aériennes. On ne peut pas, par exemple, copier les noms de rues d’une carte Bing Maps. Lorsque tu utilises un éditeur OSM comme iD ou JOSM, on peut facilement charger les images aériennes de Bing comme fond d’écran et tracer les routes et les rues par dessus.

Pieren

Effectivement, cette démarche est interdite pour OSM. Ni les noms des rues, ni leur tracé ne peuvent être pris sur Google Maps ou Google Earth. Si vous connaissez ces rues, faites-le directement avec l’éditeur en ligne iD ou n’importe quel autre éditeur, éventuellement en utilisant les images aériennes de Bing, qui nous avons le droit d’utiliser légalement. Je conseille fortement de ne pas suivre ce site internet.

Note : when the place node is a village or town, the role linking the admin boundary and the place node is ‘admin_centre’, not ‘label’ (which was intended for rendering purpose initialy). nominatim doesn’t distinguish the two roles but it’s better to use the correct one in OSM.

Good point. I will forward your request to the administrators of the humanitarian map tiles.

Hey, you forgot : “CLOSE OSM NOTES”.

Check these statistics for notes per countries: http://resultmaps.neis-one.org/osm-notes

Froggies : 7.8 closed for 1 open Roastbeefs : 0.9 closed for 1 open

omg the blog is a fake for google referencement. Plz don’t fall in the trap like a bot….

SPAM

Or use another tile server. Have a look at this one:

http://layers.openstreetmap.fr/?zoom=19&lat=48.82611&lon=2.35731&layers=B0000FFFFFFFFFFFFFFFFFFFFFF

More shops, more zoom levels, highway crossings, tennis courts, football piches detailed, and much more.

Yeah, probably the wiki has to be improved. The “protocol” should be the same as every contribution. it is common sens to verify, even when signed, from a second source (legal for OSM) what is requested for a change or addition.

all ‘notes’ have to be independently verified, anonymous or not.

Il n’y a rien d’étonnant. Le schéma de tags “public_transport” est assez massivement rejeté par les non-spécialistes du transport public de par sa complexité. La coexistance avec les anciens tags n’est pas prête de s’arrêter.

Oui, je viens de vérifier et il y a effectivement un problème. Ca n’est pas les noms qui ont été supprimé mais quelqu’un qui a changé les tags “railway=station” en ““public_transport=stop_position”. Je viens de poster un message sur la liste de diffusion talk-fr@openstreetmap.org pour voir ce que les autres contributeurs en pense. Amha, il n’aurait pas dû supprimer l’ancien tag. Il faut aussi que nous examinions ses autres interventions sur les autres lignes de métro ainsi que sur le RER et des lignes de bus.

La seule utilité du name sur la relation, c’est d’aider un humain à choisir la bonne relation dans la liste.

C’est le plus important, non ? Comme on n’est pas des machines, c’est les données qui s’adaptent aux humains et pas l’inverse. C’est pourquoi le tag name est finalement aussi souvent ajouté par les contributeurs, sinon on se retrouve, comme dans JOSM, avec des listes de relations dont on sait pas qui fait quoi. C’est donc une option quasi obligatoire pour les humains mais optionnel pour les machines. Différiencer le tag name n’apporte que de la confusion et n’est pas un conseil à suivre ni à donner.

Aie:

changement de nom ou typo c’est pareil non ? Et si le nom est à un seul endroit, pas de risque d’avoir en typo dans 1 des 40 endroits ou le nom est répété pour addr:street. Quant au nom de la relation, il est optionel et pas nécessairement identique au nom de la rue. Comme il sert juste à simplifier l’édition, ça m’arrive de l’abbréger (en virant “rue” par exemple) et/ou de rajouter des infos (nord/sud/etc).

C’est terrible si le nom est différent ! Des outils de controle qualité pourraient considérer que c’est une erreur. Le nom devrait être 100% identique sinon c’est la porte ouverte à toutes les interprétations.
Sinon, un changement de nom n’est pas identique à une correction de typo. Le premier ne se fait que si ça change dans le monde réel. Le deuxième corrige une erreur et ne change plus par la suite.

Mon billet ne s’intéressait pas aux avantages et inconvénients de chaque méthode. J’en ai déjà parlé sur la liste de diffusion talk-fr. Mais pour contre-balancer les avantages cités, je peux avancer ceci:

• “moins de temps à créer “ : faux. Ou alors, ça doit dépendre des outils parce qu’avec JOSM, si on n’a pas le plugin cadastre-fr, c’est la galère et la méthode “relation” est plus longue car elle nécessite plus de manipulations (ne serait-ce que pour ajouter une adresse à une relation existante).
• “moins de temps à maintenir si la rue change de nom” : c’est l’argument principal. Mais honnêtement, en 6 années d’OSM, je n’ai jamais changé le nom d’une rue. Par contre, j’ai corrigé beaucoup d’erreurs de typo, qui parfois étaient reproduites dans les adresses (quel que soit la méthode employée). Ben oui, même avec la méthode “associatedStreet”, le nom se retrouve dupliqué dans la relation avec le tag “name” (ce qui peut créer certaines incohérences, soit dit en passant, comme avec l’autre méthode).
• “évite la confusion” : là, je comprends pas trop. Ce que je sais, c’est que la méthode relation a aussi des inconvénients : certains ajoutent plusieurs ways en “street” alors qu’un seul devrait suffire. Il y a aussi ceux qui font plusieurs relations par rue. Il y a aussi les ways de rues qui commencent à faire partie de 4,5, voir plus, relations différentes (bus, vélo, street, boundary, etc) et ça devient franchement illisible.
• “plus facile à utiliser algorythmiquement” : euh, pas vraiment. La méthode du tag “addr:street” est directe et la plus rapide. On n’est pas obligé de faire une passe sur les éléments de type relation. On évite aussi l’écueil d’avoir des relations de relations qui ne sont gérées par aucun logiciel actuel (ça arrive si l’adresse est sur une relation multipolygon ou de type “site”).
• “moins de place en bdd” : mouais. Il faut arrêter de tagguer chaque arbre alors ;-) Ceux qui adoptent cette méthode devraient aussi s’intéresser aux polygones “building=yes” qui font 2 mètres carrés ou 50 nodes pour un arc de cercle. C’est fréquent dans les imports du bâti cadastral mais bien peu de contributeurs font les simplifications nécessaires. Il y a là un gain beaucoup plus important de place dans la bdd. On sait aussi que cet argument est rejeté par ceux qui ne voient aucun problème à répéter à l’infini le tag “source=blablabla” sur chaque élément…

Oui, j’ai oublié de mentionner un point important : je ne traite pas les tags anonymes et les tags signés de la même façon. Cuex qui sont signés permettent un véritable échange. Pour les autres, j’ai laissé quelques remarques mais je n’ai pas encore vu de retours. Je pense que les anonymes ont plus tendance à ne pas revenir. Mais il peut y avoir des exceptions.

Hi Alex,

Thanks for the (small) clarification. And congrats for the nice rendering of OSM map data.

Je n’ai pas les mêmes stats que toi avec mes 50 notes altérés mais je partage le même constat mais pas les mêmes conclusions. Le système doit rester ouvert et le plus facile d’accès possible : il s’adresse à ceux qui veulent améliorer la carte mais qui ne veulent pas entrer dans une démarche qu’ils jugent trop lourde (créer un compte, utiliser un éditeur, même iD) soit par manque de temps, soit par manque de motivation, soit par peur de mal faire. Ce qui sort de cette intention doit être éliminé : les notes personnelles, les commentaires trop vagues ou trop généralistes (“il manque les adresses dans cette ville”). Il faut rappeler qu’il est aussi rapide de fermer une “note” que de la créer. J’ai appris à ne pas perdre de temps avec certaines “notes”. Là où je suis encore dubitatif, c’est celles qui nécessitent une visite sur place. Pourquoi pas. Mais que penser si ces “notes” restent ouvertes pendant des mois, voir plus ? Si l’endroit est peu fréquenté, certaines “notes” pourraient subsister pendant des années. Il faudrait peut-être fixer une date limite au-delà duquel on peut décider de fermer la “note”. C’est peut-être une piste à explorer. Mais en aucun cas, il ne faut ajouter des barrières artificielles à ceux qui voudraient améliorer la carte par ce biais. Mais je suis d’accord qu’il faudrait d’avantage expliquer à quoi sert l’outil (un message avant la première contribution ?). Et qu’il faudrait aussi se mettre d’accord autour d’une politique générale concernant la fermeture des “notes”, par exemple sur une page dédiée dans le wiki.

In Denmark where all addresses are imported

That’s the point. Most of the addresses in OSM are today coming from mass imports. Finally only a few people fixed the convention. And the method is finally less depending on what is the best for OSM but only what is the easiest for the import. More interresting numbers would be to see the amount of contributors adopting one way or the others.

Could you develop the “two sliders via the layers context menu” ? This is something already available in standard JOSM. So what is missing here ?