[OSM-talk-fr] Intégration des Boites Postale dans Osmose

[Frédéric Rodrigo]

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.