[OSM-talk-fr] Les adresses... -- devient molo molo sur l'anarchie du bâti

Ven 25 Juin 09:49:29 UTC 2010

Je me réponds à moi-même ^^

Pour éviter d'avoir des zones abandonnées de tous, l'idée du bot reste
séduisante, en complément de l'utilisation "en manuel" par les utilisateurs
pressés de voir les batiments apparaitre dans leur secteur.

Cela peut être un bon point de départ pour des utilisateurs pas trop
"techniques" (je me mets dans le lot).
Je m'explique
Si le bot avance commune par commune, on peut lui imposer des priorités ("tu
seras gentil de me traiter mon village avant ceux de ta liste")
Pour l'utilisateur, c'est au moins la garantie que tout le processus
automatisé de l'import se fera le plus sérieusement possible, avec les
scripts les plus sûrs

En mettant quelques garde-fous, qui peuvent être :
Les imports demandés par X sont réalisés par changesets "sous le nom de X",
un peu comme les modifications raw sous Osmose.
Pas plus de n communes (20 ?) par utilisateur dans la file d'attente
Pas plus de n' communes demandées par utilisateur et par jour
Pas forcément du "premier arrivé premier servi". (Ne attendre que les 400
demandes précédente en attente soient traitées pour voir sa première commune
intégrée)
-> mais les demandes d'utilisateurs priment sur "l'automatique exhaustif"

Bon, le Bot-à-Bâti, on y est pas encore ... quoique ;-)

Le 25 juin 2010 10:37, Ab_fab <gamma.gts at gmail.com> a écrit :

> J'ai un peu le même feeling
>
> L'utilisation du script est une aide précieuse pour lancer le mapping des
> bâtiments, mais il y a un "service après-vente" à assurer ensuite (affiner
> la nature des batiments).
> Le fonctionnement commune par commune, sur le même mode que pour les
> limites administratives me plait mieux, parce que la personne qui aura
> initié l'import fera très probablement dans la foulée l'insertion des
> informations complémentaires.
>
> Il est nécessaire de bétonner l'outil pour éliminer au plus tôt dans le
> processus d'import les erreurs / artefacts qui auront été identifiés comme
> récurrents et pour lesquels une correction automatique est nécessaire. Sans
> compter les nouvelles fonctions.
>
> D'ailleurs, s'il est possible de lancer une traçabilité de son évolution,
> je vote pour (indice de révision, date). N'étant pas développeur, je suis
> mal placé pour donner la voie à suivre.
> Mais en tant que "end user" potentiel, j'ai envie d'utiliser l'outil le
> plus robuste, qui m'évitera le "Hall of shame" des dupe nodes, et surtout
> d'avoir à passer beaucoup de temps à tout mettre d'équerre.
>
> Idem pour les dépots de fichiers OSM.
> Comment savoir par quelle évolution du script ils ont été générés ?
>
> Honnêtement, même en ayant du temps pour suivre les discussions, je ne sais
> pas où on en est.
> Lever le pied pour intégrer ce genre de choses me parait raisonnable.
>
> La frénésie des jours passés est simplement à la hauteur de l'attente.
> Il semble que tout le monde était dans les starting-blocks.
> Cumulé à l'indisponibilité du site et à la crainte de voir la génération de
> PDF "généreux en infos" disparaitre du site du cadastre, c'est amusant à
> voir :-)
>
>
>
> Le 25 juin 2010 09:57, Balooval <val.poub at gmail.com> a écrit :
>
> Je tiens juste à apporter mon témoignage:
>>
>> Toute la journée d'hier j'ai importé le bâti d'une quinzaine de village de
>> mon coin ( http://wiki.openstreetmap.org/wiki/France:Gard ). Tout en
>> lisant les message inquiets sur cette liste, inquiets au point
>> qu'aujourd'hui certains suggèrent même de ne plus rendre accessible les
>> fichiers tirés des pdf.
>> Je pense avoir correctement importé les données, je n'ai pas pris trop de
>> risques, m'étant limité aux toutes petites communes (moins de risque de
>> plantage à l'upload, relativement léger à traiter dans josm, et sans
>> batiments préalablement présents).
>>
>> Bref, ce que je voulais dire c'est que pour une fois l'import de données
>> "en masse" est accessible au plus grand nombre. Pas besoin de savoir faire
>> des requêtes PostGre (?), scripts pythons ou autres. Ce n'est pas réservé à
>> "l'élite" (sans animosité aucune!). Voilà pourquoi je pense continuer. Bien
>> sûr je reste attentif a vos messages, comprend qu'une réflexion pourrait
>> améliorer les choses, mais que voulez-vous, je pars du principe qu'il vaut
>> mieux une donnée incomplète que pas de donnée du tout.
>>
>> Et puis ça m'amuse tellement de contribuer que s'il faut repasser sur mes
>> imports ce sera avec plaisir :)
>> A+
>>
>> Le 25 juin 2010 09:19, Pieren <pieren3 at gmail.com> a écrit :
>>
>>> 2010/6/25 Yann SLADEK <yann.sladek at free.fr>
>>>
>>>  Je suis d'accord avec ce qui a été dit, vu le boulot pré import, il doit
>>>> y avoir un moyen de faire ca proprement (facon CLC) et plus rapidement (si
>>>> on veut faire correctement une commune, c'est au moins 1h00)
>>>> Par contre, je pense qu'il serait judicieux de ne plus rendre les
>>>> données accessibles (notamment sur cquest.com)
>>>>
>>>> Yann
>>>>
>>>>
>>> Chercher à améliorer l'outil est, bien entendu, une bonne chose. Mais de
>>> là à demander d'arrêter les contributions actuelles, non. OSM a toujours
>>> fonctionné comme ça, par erreur/correction. Là, c'est comme si vous
>>> demandiez aux rédacteurs wikipedia de ne soumettre que des articles
>>> complets, référencés et sans fautes de français. Ou aux contributeurs
>>> français de ne plus tracer à partir de leur GPS en ville parce que ça serait
>>> plus "efficace" d'utiliser le cadastre qui est meilleur en zone urbaine.
>>> - vouloir distinguer la source humaine du script ? Pourquoi pas. Mais ça
>>> n'est pas indispensable. Si ç'est pour automatiser les tâches de maintenance
>>> ultérieures, il faudra de toutes les manières traiter de la même façon les
>>> sources humaines et les sources automatiques car toutes les deux peuvent et
>>> seront altérées dans la base par d'autres contributeurs.
>>>
>>> Pieren
>>>
>>>
>>> _______________________________________________
>>> Talk-fr mailing list
>>> Talk-fr at openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>> _______________________________________________
>> Talk-fr mailing list
>> Talk-fr at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> --
> ab_fab
>
> "Il n'y a pas de pas perdus"
>

-- 
--
ab_fab

"Il n'y a pas de pas perdus"
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20100625/f6ee35dc/attachment.htm>