kimaidou wrote > Bonjour, > > Sur l'idée de la base tierce, en effet je me suis un peu emballé. Je > pensais à une application libre que chacun pourrait installer chez soi > pour > gérer les liens entre OSM et ses données métiers, si elles sont privées. > Par contre, l'idée d'une base commune ferait encore sens pour les bases de > données métiers libres (par exemple celles en ODBL libérées via > l'opendata). > > Je ne pensais pas forcément à une super api qui gère les flux. Pourquoi > pas > à l'avenir. Mais dans un premier temps, une "simple" table qui stocke les > liens entre objets osm et objets métiers suffit. On peut ensuite utiliser > les outils comme osmWatch ou autre (à développer...) pour écouter les > diffs, vérifier s'ils concernent des liens, puis lancer les actions (rss > pour laisser manuellement, suppression automatique du lien, etc.). A noter > qu'il n'est pas obligé d'avoir une "vraie" base de données métiers. Ce > sytème fonctionnerait aussi bien sûr avec des fichiers de type CSV, > tableau, etc. Tant que des objets "métiers" ont un identifiant, on peut > créer un lien. > > Au sujet de la base tierce qui "doit connaître les objets osm" et les > stocker chez elle, c'est vrai qu'il faut à un moment pouvoir lire les > liens, par exemple pour comparer la donnée. Mais je ne vois pas de souci > technique ici. On peut imaginer des outils > * qui aident à créer les liens > * qui aident à créer des données "fusionnées" via les liens (par exemple > prend moi la géométrie OSM et colle y les colonnes A, B et C de ma table > métier > * qui alertent les personnes lorsqu'une donnée a été supprimée ou modifiée > d'un côté ou de l'autre > * qui montre les liens avec un système sympa de double panneau, etc.
En fait, je dois quand même vous alerter sur un points : les collectivité sont de plus en plus consciente de l'intérêt de gérer en interne une base exhaustive de leur voirie. Or, cela sous-entend de pouvoir identifier chaque voie de manière unique dès la création de cette voie, d'où, l'identifiant. Qu'avons nous comme identifiant voirie : - Rivoli : c'est un code créé et géré par la DGFiP - l'ID de la BDAdresse : idem pour l'IGN Il faut donc créer un identifiant interne dans la commune car la commune est la source de cette information. Or, certaines communes ont déjà travaillé sur ce type de référentiel en interne, parfois même cartographié leur réseau. On ne peut pas leur demander de refaire le travail, d'où ma question : => OSM est-il capable de supporter un identifiant unique pour la voirie provenant directement des communes sans en avoir forcément la même structure (nous, on a pris <CODE_INSEE><TYPE><NUMERO>) ? Je pense que oui et que cela permettrait de faciliter les connexions entre les données de différentes bases (vous savez que je suis fan des "passerelles" entre bases de données). -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5755819.html Sent from the France mailing list archive at Nabble.com. _______________________________________________ Talk-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-fr
