[OSM-talk-fr] Trouver les noeuds non rapportés à un bâtiment avec JOSM

[Marc Sibert]

Le 19/05/2014 14:57, Marc SIBERT a écrit :
> Bon j'ai un petit schéma :
>
En fait il ne passe pas donc voici un lien :
http://eirl-marc.wp.sibert.fr/files/2014/05/Dessin2.png
>
> C'est bien clair : BANO synthétise et produit ; OSM est l'une des 
> sources (la meilleure ?)
>
> A+
>
>
> Le 19 mai 2014 12:38, Vincent Pottier <vpottier at gmail.com 
> <mailto:vpottier at gmail.com>> a écrit :
>
>
>     Le 19/05/2014 11:38, Pieren a écrit :
>
>         Je ne suis pas très à l'aise vis à vis de ce projet. D'un côté, je
>         comprend l'envie d'aller vite et d'offrir une base adresse
>         s'affranchissant des contraintes de l'import dans OSM. C'est
>         aussi à
>         cette tentation qu'à céder mapbox en créant le projet
>         "openaddresses"
>         ([1]), en voulant s'affranchir, lui, des problèmes de licences. Ca
>         nous fait donc déjà deux bases adresses "libres".
>         On voit bien où ça nous mène : un fork des données avec des
>         outils qui
>         seront obligés de jongler avec plusieurs bases (OSM pour la
>         navigation
>         et bano pour le géocodage, par exemple). C'est exactement
>         contre ça
>         qu'OSM a été créer : ne plus avoir à chercher à gauche et à droite
>         voir qui fait quoi, qui fait le mieux et comment et avec quelle
>         license pour travailler avec des données géographiques mais
>         avoir le
>         tout centralisé dans une seule base (et aussi pour les mises à
>         jour).
>
>         Donc "hourra pour bano" si ça sert à accélerer l'intégration des
>         adresses dans OSM. Mais "bof" si ça devient une solution
>         pérenne pour
>         compenser nos faiblesses comme dans la modélisation ou les
>         contraintes
>         de l'import (et qu'il vaudrait mieux surmonter).
>
>     OSM reste bien le réservoir de données autours duquel se développe
>     un écosystème.
>     Par nature, base de donnée ouverte, OSM a besoin de cet écosystème
>     pour la fourniture de données stabilisées.
>     OSM ne permet pas de connaître la qualité des données fournies :
>     précision, cohérence, libellés, exhaustive...
>     On le voit dans de nombreux exemples : trait de côte, limites des
>     collectivités territoriales...
>     Ce ne sont pas des données brutes OSM qui sont fournies, mais des
>     données au moins vérifiées dans leur intégrité, voire simplifiées.
>     Ce sont des interfaces de nature diverse qui fournissent ces
>     données avec un minimum d'information sur la qualité de celles-ci.
>
>     Il me semble, si j'ai tout compris, que BANO s'inscrit bien dans
>     la logique OSM en étant une double interface.
>     D'un côté l'aspect QA, permettant de compléter et corriger OSM (et
>     non d'importer dans OSM, ça a bien été répété)
>     De l'autre côté, proposer un jeu de données stabilisées, échappant
>     aux vicissitudes intrinsèques d'OSM : non permanence des ids,
>     risques d'introductions d'erreurs...
>     BANO permet que :
>     * à terme OSM soit bien le réservoir de données,
>     * à terme des jeux d'adresses cohérents soient fournis à qualité
>     standardisée (exhaustivité, précision, libellés, références...).
>
>     Comme il y a plusieurs fournisseurs de cartes Garmin à partir des
>     données OSM, comme il y a de nombreuses cartes en lignes, il y
>     aura probablement plusieurs fournisseurs de données stabilisées...
>     --
>     FrViPofm
>
>
>     _______________________________________________
>     Talk-fr mailing list
>     Talk-fr at openstreetmap.org <mailto:Talk-fr at openstreetmap.org>
>     https://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
>
> -- 
> Marc Sibert
> marc at sibert.fr <mailto:marc at sibert.fr>


-- 
Marc Sibert
mailto:marc at sibert.fr

-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20140519/1068eea3/attachment.htm>