Le 17/10/2016 à 23:25, Vincent de Château-Thierry a écrit :
> Bonsoir,
>
> Le 17/10/2016 à 22:56, pepilepi...@ovh.fr a écrit :
>> Le 17/10/2016 à 22:42, osm.sanspourr...@spamgourmet.com a écrit :
>>>
>>> A minima le nom de la ville est faux (*Beaumont lès Valence* et non
>>> Beaumont-lès-Valence).
>>>
>> Bin c'est ce que j'ai mis...
>
> La version souhaitée est celle avec les traits d'union.

OK, c'est corrigé.


> Le bureau de poste à côté de ton ajout mériterait le même soin.

Il va y passer, c'est le prochain sur ma liste. Ça fait plusieurs années
qu'il est incomplet, il attendra bien une semaine ou deux, il me servira
de cobaye pour tester QGis ou l'API.

>
>>> Je l'interroge sur l'intérêt de addr:country
>>> <http://wiki.openstreetmap.org/wiki/Key:addr:country?uselang=en> FR
>>>
>> OK.
>> C'était dans le wiki, je l'ai mis...
>>>
>>> Ce n'est pas faux mais la position du nœud le donne déjà.
>>>
>>> Un is_in, je dirais non. Là je me pose juste la question de l'intérêt.
>
> Oui, la mention du pays n'est pas nécessaire par défaut, considérant
> que la situation géographique du point "dans l'emprise du pays" donne
> l'information, indirectement certes. Des outils de manipulation de la
> donnée (SIG [1], BD spatiale) permettent de retrouver/calculer cette
> info aisément.
>
>>> Pour les imports (ou plutôt les ajouts assistés), QGis n'est-il pas
>>> plus adapté ?
>>>
>> Je débarque dans la grande communauté OSM. C'est quoi QGis ?
>> Là encore toute doc et tout exemple sont bienvenus.
>
> QGis [2] est un logiciel de manipulation de données géographiques (un
> SIG) très bien foutu, mais pas orienté OSM plus que ça. Il est
> volontairement généraliste. Comme tu es familier de JOSM, je ne vois
> personnellement pas l'intérêt de recourir à QGis pour éditer dans OSM.
> Pour analyser la donnée en revanche il peut être plus pratique que
> JOSM selon le besoin.
>
> Pour revenir à ta question initiale, en effet remplir mécaniquement un
> fichier avec les bonnes caractéristiques peut être une action assez
> rapide et mécanique. Le format serait celui de l'API 0.6 [3]. Ce qui
> reste fastidieux comme tu l'as identifié, c'est le travail de
> consolidation & dédoublonnage avec l'existant, puisqu'il ne s'agit pas
> de créer des doublons. Et ce travail là ne relève au final pas d'un
> algo, mais bien de décisions prises par un humain derrière son écran. 

Nan, c'est pas trop monstrueux. J'ai une liste de lieux et d'adresses,
etje connais le patelin. Donc pour chaque lieu je peux voir très
rapidement s'il existe déjà dans OSM. Si oui je note son nodeId, sinon
je le crée manuellement avec le minimum d'info et je le traite ensuite
comme un existant.

> Si tu trouves ton chantier fastidieux, un moyen peut consister à
> l'organiser pour le partager entre plusieurs contributeurs. En ayant
> au préalable traité le sujet de la licence associée aux données que tu
> évoques (d'où viennent-elles ?), histoire de ne pas faire de boulette.

Les données, c'est la municipalité qui les fournit. Aujourd'hui sur une
feuille de papier... Je vais essayer de négocier un fichier.

Et ce qui me gène ce n'est pas "fastidieux", c'est INUTILEMENT
fastidieux. Il y a certes certaines tâches qui sont forcément manuelles,
comme ici l'identification des points. Mais ce qui me casse les pieds
c'est de passer trois heures à des actions répétitives qui pourraient
être automatisées. Comme l'affectation des tags aux points.

En tous cas merci pour ces infos, je vais m'y plonger

JP

>
> vincent
>
> [1]
> https://fr.wikipedia.org/wiki/Syst%C3%A8me_d%27information_g%C3%A9ographique
> [2] http://qgis.org/
> [3] : http://wiki.openstreetmap.org/wiki/API_v0.6
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr



_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Répondre à