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. Bref c'est pas l'envie qui me manque, mais le temps en ce moment (je fais du Lizmap à fond). Bonne journée Michael Le 2 avril 2013 21:18, Guillaume Allegre <allegre.guilla...@free.fr> a écrit : > Le sam. 30 mars 2013 à 20:37 +0100, Guillaume Allegre a écrit : > > > > > 1) la boundary est une frontière de canton, qui coïncide avec un bout de > la frontière communale > > (Orange / Caderousse) > > http://www.openstreetmap.org/?way=171243851 mais qui n'est pas > confondue (points distincts) > > Selon moi, elle devrait être confondue, en tant que limite communale ET > limite de canton. > > Sur ce premier point, tout le monde est d'accord pour la fusion ? > > À terme, si ce schéma se généralise, ça veut dire que les limites de > communes seront également > découpées selon les limites de bureaux de vote. > Pas d'opposition ? > > > > > > 2) le way polling_station a une résolution bien plus élevée (1 point par > mètre dans les courbes), > > suivant les _anciens_ méandres de la Meyne, qui restent la limite > communale comme ici : > > http://www.openstreetmap.org/?lat=44.08722&lon=4.7789&zoom=17&layers=M > > A mon avis, c'est de la sur-résolution inutile, mais ça se discute. > > Pas d'autre avis sur ce point ? > > > -- > ° /\ Guillaume Allègre OpenStreetMap France > /~~\/\ allegre.guilla...@free.fr Cartographie libre et collaborative > / /~~\ tél. 04.76.63.26.99 http://www.openstreetmap.fr > > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
