Le 27/06/2015 17:37, Vincent de Château-Thierry a écrit :
Bonjour,
(attention c'est long)
Le 27/06/2015 13:53, Frédéric Rodrigo a écrit :
Le 27/06/2015 09:49, Christian Quest a écrit :
Je ne vois non pas trop l'intérêt non plus du addr:postcode sur la boite
aux lettres.
Ça ne peut pas faire de mal.
Ça n'est pas parce que c'est fourni dans la source qu'on en veut
forcément en base, si ? On peut en avoir un usage indirect, si ça permet
de valider la cohérence d'une couche de polygones de codes postaux par
exemple, mais de là à dire que le code postal est un attribut des boîtes
aux lettres *dans* OSM, il y a de la marge.
D'une manière générale, tous les épisodes d'intégration d'OpenData nous
apprennent au moins une chose, c'est qu'on doit être critiques par
rapport aux sources. Ça ne s'applique pas qu'aux valeurs d'attributs ou
à la géométrie, le choix des tags est aussi concerné...
Bon. Si ce tag ne va a personne je l'enlève.
Il est est quand même évident qu'il faut corriger les positions à la
main avant intégration dans OSM.
Mais est-ce si évident ? Pour moi clairement non. Il est très simple
(trop ?) de valider les propositions de création de nodes telles que. Or
en dehors de sa propre connaissance du terrain, on n'a rien à confronter
à la source OD pour vérifier sa qualité. Ici rien n'est visible depuis
une orthophoto, on ne peut pas faire la même démarche qu'avec les routes
ou les bâtiments, où on a au moins bing et le Cadastre à confronter pour
se faire un jugement.
Pour des boîtes aux lettres, comme pour les bancs, les hydrants et
autres "micro" contenus, en dehors des endroits couverts par Mapillary,
on n'est dépourvu de sources à confronter/comparer.
Et comme il est simple de vérifier, sur des boîtes aux lettres de son
environnement, le côté pifométrique de la source (par chez moi c'est
flagrant, avec géocodage à la rue par exemple, ce qui est un non sens),
je suis plus que réservé sur l'intérêt de la proposition d'intégration.
Ce que je verrais plus volontiers :
- proposition de conflation pour les boîtes détectées mais dépourvues de
tag ref
- et simple visualisation (sans possibilité de bascule vers un éditeur)
pour les autres. C'est un simple porté à connaissance, qui peut
aiguiller chacun sur son territoire pour aller vérifier sur place
l'existence *et le positionnement* des boîtes.
Ça paraîtra fastidieux et/ou radical à certains, de mon côté je suis
convaincu de cette nécessité. Sans positionnement fin de ce type
d'objets (je mets les hydrants dans le même sac) OSM n'a pas de valeur
ajoutée à les intégrer. S'il s'agit juste de les accumuler en base sans
apport de qualité, on peut déjà le faire, d'un point de vue utilisateur,
sans passer par la case OSM.
vincent
Je trouve que tu fait à l'intégration le même procès que à l'import.
L'intégration n'a de sens que si entre le clic de souris et la chaise il
y un cerveau, je suis d'accord. Mais c'est justement pour cela que l'on
passe par une intégration et non une importation.
Je ne souhaite pas limite un outil sous prétexte qu'il est trop facile
(et rapide) à utiliser. Je fais assez confiance au cerveau qui se met au
bout de la souri avant de cliquer dessus. Je suis toute fois d'accord
que plus d'implication sur Osmose serait la bien venue. Je me pose
d’ailleurs de plus en plus la question de la pertinence de séparer les
intégrations dans un autre "Osmose".
Frédéric.
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
