Re: [OSM-talk-fr] expérimentations à Orange
Est-on d'accord pour que je modifie ref:orange et ref:FR:08 ou ref:FR:admin_level_08 ? -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5757001.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
pourquoi le zéro ? Ce n'est pas un code comme l'Insee c'est une valeur numérique propre à OSM, et on ne met jamais ces zéros dans les admin_level Le 14 avril 2013 09:58, Tony Emery tony.em...@yahoo.fr a écrit : Est-on d'accord pour que je modifie ref:orange et ref:FR:08 ou ref:FR:admin_level_08 ? -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5757001.html Sent from the France mailing list archive at Nabble.com. ___ 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
Re: [OSM-talk-fr] expérimentations à Orange
ref:xxx dans un tel cas doit servir à lier avec un unique jeu de donnée, pour moi le xxx doit contenir un identifiant unique vers le jeu de donnée et ne doit pas être générique. ref:INSEE indique bien qu'on parle du jeu de données de l'INSEE ref:FR:RATP du jeu de données de la RATP ref:mhs du jeu de donnée Mérimée etc... ref:FR:08 c'est quel jeu de données ? ref:FR:84xxx me semblerai plus approprié et oui, ça va faire plein de ref:FR:x mais ils sont nécessaires pour savoir à quel jeu de donnée on fait référence vu qu'il n'ont rien en commun les uns avec les autres ! Le 14 avril 2013 10:20, Philippe Verdy verd...@wanadoo.fr a écrit : pourquoi le zéro ? Ce n'est pas un code comme l'Insee c'est une valeur numérique propre à OSM, et on ne met jamais ces zéros dans les admin_level Le 14 avril 2013 09:58, Tony Emery tony.em...@yahoo.fr a écrit : Est-on d'accord pour que je modifie ref:orange et ref:FR:08 ou ref:FR:admin_level_08 ? -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5757001.html Sent from the France mailing list archive at Nabble.com. ___ 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 -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/shttp://openstreetmap.fr/sotmfr2013ynthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Bonjour, Le 14/04/2013 11:14, Christian Quest a écrit : ref:xxx dans un tel cas doit servir à lier avec un unique jeu de donnée, pour moi le xxx doit contenir un identifiant unique vers le jeu de donnée et ne doit pas être générique. ref:INSEE indique bien qu'on parle du jeu de données de l'INSEE ref:FR:RATP du jeu de données de la RATP ref:mhs du jeu de donnée Mérimée etc... ref:FR:08 c'est quel jeu de données ? ref:FR:84xxx me semblerai plus approprié et oui, ça va faire plein de ref:FR:x mais ils sont nécessaires pour savoir à quel jeu de donnée on fait référence vu qu'il n'ont rien en commun les uns avec les autres ! Et doncon est revenu au point de départ de la discussion :-) Je continue de penser que ref:FR:code INSEE de la commune est une galère potentielle, tant en gestion qu'en compréhension. Quitte à considérer qu'au sein d'une commune on n'aura pas de chevauchements d'identifiants, alors je préfère largement un unique tag qui serait quasi la proposition de Tony, à savoir ref:FR:admin_level8, avec comme valeur l'identifiant externe fourni par le SIG communal. Un seul tag, c'est déjà beaucoup plus simple à intégrer (une seule colonne dans un schéma de BD par exemple) et à documenter : une page unique plutôt que x déclinaisons, une par nouveau code INSEE. Quant à l'interprétation de ce tag, ce serait : la valeur du tag est un identifiant unique délivré par l'entité de type boundary=administrative+admin_level=8 dans laquelle se situe (géographiquement parlant) l'objet ainsi taggué. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Tout à fait d'accord, ce n'est pas mon idée de n'utiliser que l'admin_level qui n'est pas suffisant (on a des tas de données qui pourraient provenir de jeux sources maintenues par plusieurs communes simultanément sans qu'on puisse savoir laquelle, ou de plusieurs départements ou plusieurs régions j'avais déjà plaidé vers une identification des sources par leur code INSEE quand ce sont des collectivités. Au moins ça évitait les collision dans l'espace ref:FR:* et c'était assez court pour ne pas surcharger la base avec des clés interminables. Sinon une alternative au code INSEE est le code département suivi d'une abréviation du nom de la commune (par exemple ref:FR:35REN=* pour indiquer une source de la ville de Rennes et ref:FR:35CES=* pour Cesson-Sévigné sa voisine. Mais c'est inventer une nouvelle codification pour rien... Le 14 avril 2013 11:14, Christian Quest cqu...@openstreetmap.fr a écrit : ref:xxx dans un tel cas doit servir à lier avec un unique jeu de donnée, pour moi le xxx doit contenir un identifiant unique vers le jeu de donnée et ne doit pas être générique. ref:INSEE indique bien qu'on parle du jeu de données de l'INSEE ref:FR:RATP du jeu de données de la RATP ref:mhs du jeu de donnée Mérimée etc... ref:FR:08 c'est quel jeu de données ? ref:FR:84xxx me semblerai plus approprié et oui, ça va faire plein de ref:FR:x mais ils sont nécessaires pour savoir à quel jeu de donnée on fait référence vu qu'il n'ont rien en commun les uns avec les autres ! Le 14 avril 2013 10:20, Philippe Verdy verd...@wanadoo.fr a écrit : pourquoi le zéro ? Ce n'est pas un code comme l'Insee c'est une valeur numérique propre à OSM, et on ne met jamais ces zéros dans les admin_level Le 14 avril 2013 09:58, Tony Emery tony.em...@yahoo.fr a écrit : Est-on d'accord pour que je modifie ref:orange et ref:FR:08 ou ref:FR:admin_level_08 ? -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5757001.html Sent from the France mailing list archive at Nabble.com. ___ 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 -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/shttp://openstreetmap.fr/sotmfr2013ynthese-sotmfr ___ 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
Re: [OSM-talk-fr] expérimentations à Orange
Et ce n'est pas suffisant, les objets pouvant être à cheval sur plusieurs communes (une voirie, un parc, etc... ou être administré par une autre commune qui est locataire les lieux sités sur le territoire d'une autre (par exemple une déchetterie) Le 14 avril 2013 12:14, Vincent de Chateau-Thierry v...@laposte.net a écrit : Bonjour, Le 14/04/2013 11:14, Christian Quest a écrit : ref:xxx dans un tel cas doit servir à lier avec un unique jeu de donnée, pour moi le xxx doit contenir un identifiant unique vers le jeu de donnée et ne doit pas être générique. ref:INSEE indique bien qu'on parle du jeu de données de l'INSEE ref:FR:RATP du jeu de données de la RATP ref:mhs du jeu de donnée Mérimée etc... ref:FR:08 c'est quel jeu de données ? ref:FR:84xxx me semblerai plus approprié et oui, ça va faire plein de ref:FR:x mais ils sont nécessaires pour savoir à quel jeu de donnée on fait référence vu qu'il n'ont rien en commun les uns avec les autres ! Et doncon est revenu au point de départ de la discussion :-) Je continue de penser que ref:FR:code INSEE de la commune est une galère potentielle, tant en gestion qu'en compréhension. Quitte à considérer qu'au sein d'une commune on n'aura pas de chevauchements d'identifiants, alors je préfère largement un unique tag qui serait quasi la proposition de Tony, à savoir ref:FR:admin_level8, avec comme valeur l'identifiant externe fourni par le SIG communal. Un seul tag, c'est déjà beaucoup plus simple à intégrer (une seule colonne dans un schéma de BD par exemple) et à documenter : une page unique plutôt que x déclinaisons, une par nouveau code INSEE. Quant à l'interprétation de ce tag, ce serait : la valeur du tag est un identifiant unique délivré par l'entité de type boundary=administrative+admin_**level=8 dans laquelle se situe (géographiquement parlant) l'objet ainsi taggué. vincent __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Je peux prendre une exemple extrême mais réel : la maison de Victor Hugo située à Guernesey (Hauteville House) est entièrement gérée par la Mairie de Paris (avec le drapeau français à l'entrée, un administrateur local payé par la mairie de Paris. Pourtant elle n'est pas sur le territoire de la commune, ni en France. C'est une propriété privée de la Ville qui est un propriétaire comme un autre à Guernesey. Des cas où les communes sont amenées à gérer des choses hors de leur propre territoire sont assez nombreux peme si ce n'est le plus souvent pas si loin (mais même en restant en France, le Conseil général d'Ille-et-Vilaine gère des bâtiments et services à Paris ; la Corrèze aussi). Le 14 avril 2013 12:20, Philippe Verdy verd...@wanadoo.fr a écrit : Et ce n'est pas suffisant, les objets pouvant être à cheval sur plusieurs communes (une voirie, un parc, etc... ou être administré par une autre commune qui est locataire les lieux sités sur le territoire d'une autre (par exemple une déchetterie) Le 14 avril 2013 12:14, Vincent de Chateau-Thierry v...@laposte.net a écrit : Bonjour, Le 14/04/2013 11:14, Christian Quest a écrit : ref:xxx dans un tel cas doit servir à lier avec un unique jeu de donnée, pour moi le xxx doit contenir un identifiant unique vers le jeu de donnée et ne doit pas être générique. ref:INSEE indique bien qu'on parle du jeu de données de l'INSEE ref:FR:RATP du jeu de données de la RATP ref:mhs du jeu de donnée Mérimée etc... ref:FR:08 c'est quel jeu de données ? ref:FR:84xxx me semblerai plus approprié et oui, ça va faire plein de ref:FR:x mais ils sont nécessaires pour savoir à quel jeu de donnée on fait référence vu qu'il n'ont rien en commun les uns avec les autres ! Et doncon est revenu au point de départ de la discussion :-) Je continue de penser que ref:FR:code INSEE de la commune est une galère potentielle, tant en gestion qu'en compréhension. Quitte à considérer qu'au sein d'une commune on n'aura pas de chevauchements d'identifiants, alors je préfère largement un unique tag qui serait quasi la proposition de Tony, à savoir ref:FR:admin_level8, avec comme valeur l'identifiant externe fourni par le SIG communal. Un seul tag, c'est déjà beaucoup plus simple à intégrer (une seule colonne dans un schéma de BD par exemple) et à documenter : une page unique plutôt que x déclinaisons, une par nouveau code INSEE. Quant à l'interprétation de ce tag, ce serait : la valeur du tag est un identifiant unique délivré par l'entité de type boundary=administrative+admin_**level=8 dans laquelle se situe (géographiquement parlant) l'objet ainsi taggué. vincent __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 14/04/2013 12:20, Philippe Verdy a écrit : Et ce n'est pas suffisant, les objets pouvant être à cheval sur plusieurs communes (une voirie, un parc, etc... ou être administré par une autre commune qui est locataire les lieux sités sur le territoire d'une autre (par exemple une déchetterie) Le 14 avril 2013 12:14, Vincent de Chateau-Thierry v...@laposte.net Le 14/04/2013 11:14, Christian Quest a écrit : ref:xxx dans un tel cas doit servir à lier avec un unique jeu de donnée, pour moi le xxx doit contenir un identifiant unique vers le jeu de donnée et ne doit pas être générique. ref:INSEE indique bien qu'on parle du jeu de données de l'INSEE ref:FR:RATP du jeu de données de la RATP ref:mhs du jeu de donnée Mérimée etc... ref:FR:08 c'est quel jeu de données ? ref:FR:84xxx me semblerai plus approprié et oui, ça va faire plein de ref:FR:x mais ils sont nécessaires pour savoir à quel jeu de donnée on fait référence vu qu'il n'ont rien en commun les uns avec les autres ! Et doncon est revenu au point de départ de la discussion :-) Je continue de penser que ref:FR:code INSEE de la commune est une galère potentielle, tant en gestion qu'en compréhension. Quitte à considérer qu'au sein d'une commune on n'aura pas de chevauchements d'identifiants, alors je préfère largement un unique tag qui serait quasi la proposition de Tony, à savoir ref:FR:admin_level8, avec comme valeur l'identifiant externe fourni par le SIG communal. Un seul tag, c'est déjà beaucoup plus simple à intégrer (une seule colonne dans un schéma de BD par exemple) et à documenter : une page unique plutôt que x déclinaisons, une par nouveau code INSEE. Quant à l'interprétation de ce tag, ce serait : la valeur du tag est un identifiant unique délivré par l'entité de type boundary=administrative+admin___level=8 dans laquelle se situe (géographiquement parlant) l'objet ainsi taggué. J'entends ton argument. Ma proposition n'est pas robuste, et donc il en faut une autre. Je n'ai rien sous le coude, mais là où j'insiste, c'est sur le fait de ne pas arriver à un nouveau tag _par commune_. Il faut parvenir à un schéma avec des tags identiques pour toutes les communes. cf. en début de ce fil : http://lists.openstreetmap.org/pipermail/talk-fr/2013-March/056812.html vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Pourquoi FAUT-il- parvernir à ça ? Je ne vois aucune justification au fait d'avoir des tags identiques pour toutes les communes, car ce ne sont pas des éléments consitutifs d'un feature géographique. Le feature c'est plutôt porté par les autres tags. Ici on ne parle que d'un simple identifiant qui n'indique strictement rien d'autre qu'une base externe pouvant contenir des tas d'objets géographiques ou non et même pas dans OSM non plus pour la plupart, et aussi contenant des attributs supplémentaires pour les objets OSM mais des attributs qu'on ne stockera pas. Bref, si ce qui te gène c'est de ne pas pouvoir convertir tous les attributs ref;* dans des colonnes séparées d'un tableau, tu pars mal : aucune application n'a besoin de le faire, i ly a des tas d'attributs qu'on ignore totalement, mais si tu veu pouvoir les retrouver, commence d'abord par séparer les attributs qui t'intéressent dans des colonnes spécifiques de ta base, et stocke les autres dans une colonne générique refs contenant une énumération sous forme clé1=id1;clé2=id2;... là où on avait ref:clé1=id1 et ref:clé2=id2. Si on sépare malgré tout ces clés dans OSM c'est pour permettre de faire des requêtes et filtrer les données du côté du serveur, mais aussi pour limiter le risque d'effacement d'une clé par une autre incompatible. La base OSM n'est pas l'application finale utilisatrice qui prendra seulemetn ce qui l'intéresse, et n'a pas besoin non plus de tout garder puisque pour le reste elle a toujours accès à l'identifiant d'objet OSM ou peut le retrouver en faisant une recherche avec la ref:clé=* qu'elle a gardé (en ignorant les autres ref:clé2=* qu'elle n reconnait pas). Le 14 avril 2013 12:46, Vincent de Chateau-Thierry v...@laposte.net a écrit : Le 14/04/2013 12:20, Philippe Verdy a écrit : Et ce n'est pas suffisant, les objets pouvant être à cheval sur plusieurs communes (une voirie, un parc, etc... ou être administré par une autre commune qui est locataire les lieux sités sur le territoire d'une autre (par exemple une déchetterie) Le 14 avril 2013 12:14, Vincent de Chateau-Thierry v...@laposte.net Le 14/04/2013 11:14, Christian Quest a écrit : ref:xxx dans un tel cas doit servir à lier avec un unique jeu de donnée, pour moi le xxx doit contenir un identifiant unique vers le jeu de donnée et ne doit pas être générique. ref:INSEE indique bien qu'on parle du jeu de données de l'INSEE ref:FR:RATP du jeu de données de la RATP ref:mhs du jeu de donnée Mérimée etc... ref:FR:08 c'est quel jeu de données ? ref:FR:84xxx me semblerai plus approprié et oui, ça va faire plein de ref:FR:x mais ils sont nécessaires pour savoir à quel jeu de donnée on fait référence vu qu'il n'ont rien en commun les uns avec les autres ! Et doncon est revenu au point de départ de la discussion :-) Je continue de penser que ref:FR:code INSEE de la commune est une galère potentielle, tant en gestion qu'en compréhension. Quitte à considérer qu'au sein d'une commune on n'aura pas de chevauchements d'identifiants, alors je préfère largement un unique tag qui serait quasi la proposition de Tony, à savoir ref:FR:admin_level8, avec comme valeur l'identifiant externe fourni par le SIG communal. Un seul tag, c'est déjà beaucoup plus simple à intégrer (une seule colonne dans un schéma de BD par exemple) et à documenter : une page unique plutôt que x déclinaisons, une par nouveau code INSEE. Quant à l'interprétation de ce tag, ce serait : la valeur du tag est un identifiant unique délivré par l'entité de type boundary=administrative+admin_**__level=8 dans laquelle se situe (géographiquement parlant) l'objet ainsi taggué. J'entends ton argument. Ma proposition n'est pas robuste, et donc il en faut une autre. Je n'ai rien sous le coude, mais là où j'insiste, c'est sur le fait de ne pas arriver à un nouveau tag _par commune_. Il faut parvenir à un schéma avec des tags identiques pour toutes les communes. cf. en début de ce fil : http://lists.openstreetmap.**org/pipermail/talk-fr/2013-** March/056812.htmlhttp://lists.openstreetmap.org/pipermail/talk-fr/2013-March/056812.html vincent __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le dim. 14 avril 2013 à 12:14 +0200, Vincent de Chateau-Thierry a écrit : Et doncon est revenu au point de départ de la discussion :-) Oui, et tant mieux, les digressions sur la meilleure réforme possible des administrations, ce n'est pas tellement ce qui va faire avancer la cause. Je continue de penser que ref:FR:code INSEE de la commune est une galère potentielle, tant en gestion qu'en compréhension. Pourquoi ? Ça gêne qui ? Quitte à considérer qu'au sein d'une commune on n'aura pas de chevauchements d'identifiants, alors je préfère largement un unique tag qui serait quasi la proposition de Tony, à savoir ref:FR:admin_level8 Et si une voie est à la limite de deux communes ayant toutes deux versé leur SIG, ça ne marche plus. avec comme valeur l'identifiant externe fourni par le SIG communal. Un seul tag, c'est déjà beaucoup plus simple à intégrer (une seule colonne dans un schéma de BD par exemple) et à documenter : une page Qui va faire un schéma de BD contenant toutes les clés possibles ? Ça existe _en pratique_ ? ça me paraît tordu. -- ° /\Guillaume AllègreOpenStreetMap 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
Re: [OSM-talk-fr] expérimentations à Orange
Le dim. 14 avril 2013 à 11:14 +0200, Christian Quest a écrit : ref:FR:84xxx me semblerai plus approprié et oui, ça va faire plein de ref:FR:x mais ils sont nécessaires pour savoir à quel jeu de donnée on fait référence vu qu'il n'ont rien en commun les uns avec les autres ! +1 -- ° /\Guillaume AllègreOpenStreetMap 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
Re: [OSM-talk-fr] expérimentations à Orange
Le 14/04/2013 12:58, Philippe Verdy a écrit : Pourquoi FAUT-il- parvernir à ça ? Je ne vois aucune justification au fait d'avoir des tags identiques pour toutes les communes, car ce ne sont pas des éléments consitutifs d'un feature géographique. Le il faut n'est pas à prendre comme un ordre. En revanche ça me semble la cible à atteindre. Et ça n'est pas parce que ces IDs externes sont en effet, plutôt une meta-donnée qu'une donnée, qu'il faut les modéliser n'importe comment. Le feature c'est plutôt porté par les autres tags. Ici on ne parle que d'un simple identifiant qui n'indique strictement rien d'autre qu'une base externe pouvant contenir des tas d'objets géographiques ou non et même pas dans OSM non plus pour la plupart, et aussi contenant des attributs supplémentaires pour les objets OSM mais des attributs qu'on ne stockera pas. Bref, si ce qui te gène c'est de ne pas pouvoir convertir tous les attributs ref;* dans des colonnes séparées d'un tableau, tu pars mal : aucune application n'a besoin de le faire, J'adore ce genre de vérité définitive : aucune application n'a besoin de le faire. Pour affirmer ça, il faudrait connaître toutes les utilisations de la base, et le détail de chacune. C'est bien prétentieux ! Philippe, dis-toi bien que tu ne connais (et moi non plus et personne d'autre ici) pas le 1/4 du 1/3 du périmètre des applications qui s'appuient sur la base OSM. Et c'est tant mieux, au passage. Mais donc ce genre d'argument n'en est pas un. Pour revenir au sujet, je vais reformuler autrement ma proposition de ce matin. Pour combiner un nombre restreint de tags (ici 1 seul finalement) et un peu de robustesse, on pourrait renseigner ce type de tag : ref:FR:admin_level8=code INSEE de la commune source:identifiant de l'objet tel que géré par cette commune Par rapport à ce que je proposais ce matin, on garde un seul tag, mais on n'est pas contraint par une inclusion géographique. On gèrerait correctement la Maison de Victor Hugo : ref:FR:admin_level8=75056:identifiant de la maison selon la Ville de Paris vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 14 avril 2013 14:32, Vincent de Chateau-Thierry v...@laposte.net a écrit : Pour revenir au sujet, je vais reformuler autrement ma proposition de ce matin. Pour combiner un nombre restreint de tags (ici 1 seul finalement) et un peu de robustesse, on pourrait renseigner ce type de tag : ref:FR:admin_level8=code INSEE de la commune source:identifiant de l'objet tel que géré par cette commune Par rapport à ce que je proposais ce matin, on garde un seul tag, mais on n'est pas contraint par une inclusion géographique. On gèrerait correctement la Maison de Victor Hugo : ref:FR:admin_level8=75056:**identifiant de la maison selon la Ville de Paris vincent J'aime assez cette dernière proposition. En effet, on reste sur l'effet une seule colonne dans les bases de données à plat tout en permettant de filtrer pour la ou les communes qui nous intéresse. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 14/04/2013 14:21, Guillaume Allegre a écrit : Le dim. 14 avril 2013 à 12:14 +0200, Vincent de Chateau-Thierry a écrit : Et doncon est revenu au point de départ de la discussion :-) Oui, et tant mieux, les digressions sur la meilleure réforme possible des administrations, ce n'est pas tellement ce qui va faire avancer la cause. Je continue de penser que ref:FR:code INSEE de la commune est une galère potentielle, tant en gestion qu'en compréhension. Pourquoi ? Ça gêne qui ? Tout le monde à terme : contributeurs (c'est indocummentable, anti intuitif au possible) et consommateurs. Quitte à considérer qu'au sein d'une commune on n'aura pas de chevauchements d'identifiants, alors je préfère largement un unique tag qui serait quasi la proposition de Tony, à savoir ref:FR:admin_level8 Et si une voie est à la limite de deux communes ayant toutes deux versé leur SIG, ça ne marche plus. Dans le cas d'une voie communale en frontière, on suffixe ref:FR:admin_level8 avec :left et :right. Cette convention est assez répandue dans les tags. avec comme valeur l'identifiant externe fourni par le SIG communal. Un seul tag, c'est déjà beaucoup plus simple à intégrer (une seule colonne dans un schéma de BD par exemple) et à documenter : une page Qui va faire un schéma de BD contenant toutes les clés possibles ? Ça existe _en pratique_ ? ça me paraît tordu. On n'en sait _rien_ , cf. ce que je viens de répondre à Philippe. Mais justement, ne sachant pas, notre responsabilité c'est de ne pas fabriquer une usine à gaz. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 14 avril 2013 14:32, Vincent de Chateau-Thierry v...@laposte.net a écrit : Pour revenir au sujet, je vais reformuler autrement ma proposition de ce matin. Pour combiner un nombre restreint de tags (ici 1 seul finalement) et un peu de robustesse, on pourrait renseigner ce type de tag : ref:FR:admin_level8=code INSEE de la commune source:identifiant de l'objet tel que géré par cette commune Par rapport à ce que je proposais ce matin, on garde un seul tag, mais on n'est pas contraint par une inclusion géographique. On gèrerait correctement la Maison de Victor Hugo : ref:FR:admin_level8=75056:**identifiant de la maison selon la Ville de Paris Et ça ne marchera pas si 2 communes veulent identifier le même objet... comme tout les objets en limite de commune et plein de cas particuliers comme celui de la Maison de Victor Hugo. 2 jeux de données différents = 2 ref:xxx différents, je ne vois pas d'autre solution qui puisse tenir, désolé. -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/shttp://openstreetmap.fr/sotmfr2013ynthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 14/04/2013 15:25, Christian Quest a écrit : Le 14 avril 2013 14:32, Vincent de Chateau-Thierry v...@laposte.net mailto:v...@laposte.net a écrit : Pour revenir au sujet, je vais reformuler autrement ma proposition de ce matin. Pour combiner un nombre restreint de tags (ici 1 seul finalement) et un peu de robustesse, on pourrait renseigner ce type de tag : ref:FR:admin_level8=code INSEE de la commune source:identifiant de l'objet tel que géré par cette commune Par rapport à ce que je proposais ce matin, on garde un seul tag, mais on n'est pas contraint par une inclusion géographique. On gèrerait correctement la Maison de Victor Hugo : ref:FR:admin_level8=75056:__identifiant de la maison selon la Ville de Paris Et ça ne marchera pas si 2 communes veulent identifier le même objet... comme tout les objets en limite de commune et plein de cas particuliers comme celui de la Maison de Victor Hugo. 2 jeux de données différents = 2 ref:xxx différents, je ne vois pas d'autre solution qui puisse tenir, désolé. Donc mettons nous dans le cas où n communes gèrent, chacune dans son coin, un seul et même objet (ex. : la déchetterie citée par Philippe). Toutes ces communes libèrent leurs données. Mince ! Nous sommes donc confrontés à une bataille (dantesque !) de sources :-) Qu'est-ce qui, dans ce type de cas, nous empêche d'utiliser, là encore, une convention de tagguage (au même titre que :left et :right), à savoir le ';' comme séparateur de valeurs ? Je n'en suis pas fan, mais ça me semble une fois de plus largement plus gérable que le mode où chaque source provoquerait l'ajout d'un tag distinct. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
cquest wrote ref:xxx dans un tel cas doit servir à lier avec un unique jeu de donnée, pour moi le xxx doit contenir un identifiant unique vers le jeu de donnée et ne doit pas être générique. ref:INSEE indique bien qu'on parle du jeu de données de l'INSEE ref:FR:RATP du jeu de données de la RATP ref:mhs du jeu de donnée Mérimée etc... ref:FR:08 c'est quel jeu de données ? ref:FR:84xxx me semblerai plus approprié et oui, ça va faire plein de ref:FR:x mais ils sont nécessaires pour savoir à quel jeu de donnée on fait référence vu qu'il n'ont rien en commun les uns avec les autres ! si on suit cette logique, alors il faut faire ref:FR:Communes car INSEE est une institution, pas un code de classification. Si on compare avec la même chose, c'est comme si on mettait ref:84087 pour ajouter le code INSEE derrière en valeur de clé. REF:FR:admin_level_08=* voudrait dire c'est la référence en France pour les niveaux administratif 8 (les communes. Pour quoi le 08 et non le 8, parce qu'il y a 10 niveaux administratifs recensés en France. C'est pour garder le même nombre de caractères pour ce type de tags. -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5757051.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Guillaume Allegre wrote Je continue de penser que ref:FR: code INSEE de la commune est une galère potentielle, tant en gestion qu'en compréhension. Pourquoi ? Ça gêne qui ? Ceux qui utilisent les données dans des SIG classiques (il y en a encore). Il ne faut pas seulement penser informatique et web... Guillaume Allegre wrote Quitte à considérer qu'au sein d'une commune on n'aura pas de chevauchements d'identifiants, alors je préfère largement un unique tag qui serait quasi la proposition de Tony, à savoir ref:FR:admin_level8 Et si une voie est à la limite de deux communes ayant toutes deux versé leur SIG, ça ne marche plus. C'est déjà le cas pour le nom de ces voies name:left et name:right. Ou alors les séparer par des ;. De toute façon, l'identifiant unique devrait contenir le n° INSEE de la commune (comme pour les parcelles). Guillaume Allegre wrote avec comme valeur l'identifiant externe fourni par le SIG communal. Un seul tag, c'est déjà beaucoup plus simple à intégrer (une seule colonne dans un schéma de BD par exemple) et à documenter : une page Qui va faire un schéma de BD contenant toutes les clés possibles ? Ça existe _en pratique_ ? ça me paraît tordu. Des communautés de communes, d'agglo ou tout autre EPCI qui gèrent plusieurs communes, par exemple. -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5757054.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Vincent de Château-Thierry wrote Pour revenir au sujet, je vais reformuler autrement ma proposition de ce matin. Pour combiner un nombre restreint de tags (ici 1 seul finalement) et un peu de robustesse, on pourrait renseigner ce type de tag : ref:FR:admin_level8= code INSEE de la commune source : identifiant de l'objet tel que géré par cette commune Le code INSEE de la commune est presque toujours déjà présent dans l'identifiant. Chez nous, l'identifiant est du type 84087V123456. Donc, pas besoin du code INSEE de la commune source:, surtout que les : se gèrent très mal dans les Bases de données des SIG. Vincent de Château-Thierry wrote Par rapport à ce que je proposais ce matin, on garde un seul tag, mais on n'est pas contraint par une inclusion géographique. On gèrerait correctement la Maison de Victor Hugo : ref:FR:admin_level8=75056:lt;identifiant de la maison selon la Ville de Parisgt; Là, je vois pas le rapport. L'idée n'est pas de savoir qui est le propriétaire ou le gestionnaire de la voie (ça, à la rigueur, c'est le tag operator, mais dans quelle commune elle se trouve. -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5757056.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 14/04/2013 16:52, Tony Emery a écrit : Vincent de Château-Thierry wrote Pour revenir au sujet, je vais reformuler autrement ma proposition de ce matin. Pour combiner un nombre restreint de tags (ici 1 seul finalement) et un peu de robustesse, on pourrait renseigner ce type de tag : ref:FR:admin_level8= code INSEE de la commune source : identifiant de l'objet tel que géré par cette commune Le code INSEE de la commune est presque toujours déjà présent dans l'identifiant. Chez nous, l'identifiant est du type 84087V123456. Donc, pas besoin du code INSEE de la commune source:, surtout que les : se gèrent très mal dans les Bases de données des SIG. Mais on ne peut pas établir une règle en considérant que ce qui se fait à Orange se fait partout. Il faut toujours penser au pire quand tu réfléchis à un modèle, et là, le pire, c'est une commune qui dans son SIG aurait, par exemple, des IDs qui commencent à 1 et s'incrémentent. Si 2 communes font la même chose, on n'aura pas d'unicité des identifiants. Or ce scenario est gérable si le code INSEE de la commune est imposé en début de valeur, avant un séparateur, qui peut être ':' ou autre chose. Au passage, qu'un SIG gère mal ce caractère dans un nom de champ je peux le concevoir, mais dans une valeur de champ typé en caractère, ça me semble plus improbable. Vincent de Château-Thierry wrote Par rapport à ce que je proposais ce matin, on garde un seul tag, mais on n'est pas contraint par une inclusion géographique. On gèrerait correctement la Maison de Victor Hugo : ref:FR:admin_level8=75056:lt;identifiant de la maison selon la Ville de Parisgt; Là, je vois pas le rapport. L'idée n'est pas de savoir qui est le propriétaire ou le gestionnaire de la voie (ça, à la rigueur, c'est le tag operator, mais dans quelle commune elle se trouve. L'idée est de savoir quel organisme a affecté l'identifiant qu'on est en train de lire. La réponse à dans quelle commune se trouve l'objet n'a pas du tout besoin de tout ça, l'inclusion spatiale dans la limite de commune suffit. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
le ,ombre de caractères c'est ridicule, sinon au devrait écrire aussi le tag admin_level=08 et non admin_level=8; cela aurait un sens si c'était un identifiant servant de base à d'autres, mais ça n'a été modiflisé que comme une valeur strictement énumérée ayant une valeur numérique comparable sous forme d'entier, même sans le zéro (sans compter qu'à tout moment on va avoir une zone où on trouvera des valeurs non entières, pour gérer les cas de transitions lors de réformes adminsitratives dans un pays (qui entraineront des changements massifs et une perte de compatibilité avec les appilis tierces utilisant encore les anciennes entités pendant une période assez longue). Ajouter un zéro n'aidera pas dans ce cas les clés sont juste des clés, pas des valeurs ni des codes identifiants de bases externes, là il s'agit juste d'une convention strictement interne à OSM de nommage des clés et il vaut mieux être cohérent avec le schéma adopté dans OSM pour sa propre utilisation des admin_level=*. Le 14 avril 2013 16:30, Tony Emery tony.em...@yahoo.fr a écrit : cquest wrote ref:xxx dans un tel cas doit servir à lier avec un unique jeu de donnée, pour moi le xxx doit contenir un identifiant unique vers le jeu de donnée et ne doit pas être générique. ref:INSEE indique bien qu'on parle du jeu de données de l'INSEE ref:FR:RATP du jeu de données de la RATP ref:mhs du jeu de donnée Mérimée etc... ref:FR:08 c'est quel jeu de données ? ref:FR:84xxx me semblerai plus approprié et oui, ça va faire plein de ref:FR:x mais ils sont nécessaires pour savoir à quel jeu de donnée on fait référence vu qu'il n'ont rien en commun les uns avec les autres ! si on suit cette logique, alors il faut faire ref:FR:Communes car INSEE est une institution, pas un code de classification. Si on compare avec la même chose, c'est comme si on mettait ref:84087 pour ajouter le code INSEE derrière en valeur de clé. REF:FR:admin_level_08=* voudrait dire c'est la référence en France pour les niveaux administratif 8 (les communes. Pour quoi le 08 et non le 8, parce qu'il y a 10 niveaux administratifs recensés en France. C'est pour garder le même nombre de caractères pour ce type de tags. -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5757051.html Sent from the France mailing list archive at Nabble.com. ___ 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
Re: [OSM-talk-fr] expérimentations à Orange
P. N'importe quoi. Les EPCI ne peuvent pas gérer *toutes* les donénes qu'on met dans OSM. Elles sont de toute façon obligées de faire le tri dans ce qui les intéresse, et de reclasser/regrouper des éléments qui ont été codifiés séparément dans OSM (par exemple à quoi cela peut servir à une collectivité française les clés qui séparents les concepts définis au Royaume-Uni ou aux USA, et à quoi sert la nomenclature de classification officielle française à une agence américaine qui a des lois carrément incompatibles et une toute autre classification ? Personne (j'insiste) ne peut utiliser toutes les clés simultanément, d'autant plus que certaines codifications dans OSM n'ont aucun équivalent officiel ailleurs et ne sont que des compromis orientés vers une utilisation plus grand public. Même nos serveur sde rendu sont obligés tous de faire ces requalifications quand ils créents leurs propres tables de features à partir des données OSM trop riches, et de résoudre aussi des ambiguités avec des heuristiques (car on n'a pas encore de règles claires, très souvent, sur la façon de taguer *partout* de la même façon). Dès qu'on commence à parler d'une telle couche d'adaptation, toutes les clés (et aussi les valeurs) doivent d'avord être interprêtées, et ce qu'on ne comprend pas selon le but de la base finale à créer, on le met déjà de côté. Les utilisations vont aussi changer, comme nos propres recommandations et expérimentations sur bon nombre de tags. Déjà assez souvent on doit ignorer des tags devenus obsolètes car trop ambigus. N'en ajoutons pas d'autres qui dès le départ seront ambigus. Le 14 avril 2013 16:43, Tony Emery tony.em...@yahoo.fr a écrit : Guillaume Allegre wrote Je continue de penser que ref:FR: code INSEE de la commune est une galère potentielle, tant en gestion qu'en compréhension. Pourquoi ? Ça gêne qui ? Ceux qui utilisent les données dans des SIG classiques (il y en a encore). Il ne faut pas seulement penser informatique et web... Guillaume Allegre wrote Quitte à considérer qu'au sein d'une commune on n'aura pas de chevauchements d'identifiants, alors je préfère largement un unique tag qui serait quasi la proposition de Tony, à savoir ref:FR:admin_level8 Et si une voie est à la limite de deux communes ayant toutes deux versé leur SIG, ça ne marche plus. C'est déjà le cas pour le nom de ces voies name:left et name:right. Ou alors les séparer par des ;. De toute façon, l'identifiant unique devrait contenir le n° INSEE de la commune (comme pour les parcelles). Guillaume Allegre wrote avec comme valeur l'identifiant externe fourni par le SIG communal. Un seul tag, c'est déjà beaucoup plus simple à intégrer (une seule colonne dans un schéma de BD par exemple) et à documenter : une page Qui va faire un schéma de BD contenant toutes les clés possibles ? Ça existe _en pratique_ ? ça me paraît tordu. Des communautés de communes, d'agglo ou tout autre EPCI qui gèrent plusieurs communes, par exemple. -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5757054.html Sent from the France mailing list archive at Nabble.com. ___ 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
Re: [OSM-talk-fr] expérimentations à Orange
Le 11 avr. 2013 à 17:43, Tony Emery tony.em...@yahoo.fr a écrit : Une fois que j'ai dit ça, que peut-on en tirer ? 1- Que la source première de données est et restera toujours la commune (en gros toujours) ; 2- Qu'il faut s'appuyer sur elles si l'on veut constituer une base crédible et maintenue dans le temps ; 3- Que, étant données les différences de moyens des collectivités, seule un petite minorité d'entre elles sont capables de faire ce travail 4- Que pour compenser l'inégalité des moyens, il faudrait que les intercommunalités prennent le relais mais 5- Que certaines d'entre elles, notamment en milieu rural, n'ont pas plus les moyens de le faire 6- Que les collectivités locales ne peuvent pas imposer quoi que ce soit aux autres (principe constitutionnel d’interdiction de la tutelle d’une collectivité territoriale sur une autre) Sur 5 et 6, la solution est de faire des SIG à un niveau supérieur à la communauté de communes. C'est ce qui a été fait à Brest où la métropole met, par convention, son SIG à la disposition des autres EPCI du Pays de Brest (pays Voynet) 9 agents arrivent à couvrir 89 communes. Evidemment, c'est une décision politique, difficile à prendre, si les élus se méfient les uns des autres, mais, pas impossible à réaliser. Le modèle est que le SIG le plus avancé, fédère les EPCI les plus proches. Si certains d'entre vous sont en position d'attirer l'attention des élus là-dessus, ce serait une bonne chose. Christian R., contributeur super-lambda PS : Je connais une communauté d'agglo qui a un SIG, mais, la ville centre garde le sien, car, les deux têtes politiques, du même parti, sont en guerre ouverte !!??? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Christian Rogel wrote la solution est de faire des SIG à un niveau supérieur à la communauté de communes. C'est ce qui a été fait à Brest où la métropole met, par convention, son SIG à la disposition des autres EPCI du Pays de Brest (pays Voynet) 9 agents arrivent à couvrir 89 communes. Evidemment, c'est une décision politique, difficile à prendre, si les élus se méfient les uns des autres, mais, pas impossible à réaliser. Le modèle est que le SIG le plus avancé, fédère les EPCI les plus proches. Si certains d'entre vous sont en position d'attirer l'attention des élus là-dessus, ce serait une bonne chose. Effectivement, mais ce ne sera pas possible vu que la politique actuelle d'aménagement du territoire est de réduire le mille-feuilles administratif et de supprimer les syndicats et autres pays. Je pense que ça pourrait se faire soit au niveau des Conseils Généraux (mais ils leurs manque la compétence), soit, dans une volonté de solidarité, entre les interco qui ont des SIG et les autres (mais là, c'est un doux rêve). En attendant, il faut déjà avancer avec ceux qui ont déjà des référentiels et des moyens. -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5756807.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Même sans faire appel au mille-feuille administratif, il y a d'autres moyens de coopérations entre communes et autres collectivités pour certaines missions. Les associations ça existe, la France n'en manque pas ! Déjà il y a l'Association des maires de France (AMF) et je ne vois pas pourquoi les petites collectivités qui manquent de moyens ne pourraient pas utiliser une solution pérenne gérée par une telle association, avec des moyens partagés, et des relais dans toutes les régions. Evidemment se pose la question de la sécurité des SIG,et de la responsabilité des intervenants qui modifient les bases, ou les consultent, mais ce n'est pas spécifique au cadre de la collaboration et le même problème existe déjà au sein même de chaque collectivité devant gérer un SIG, la différence étant une question d'échelle si un SIG partagé devient tellement important par le nombre d'infos qui y sont enregistrées collectivement qu'il suscite ensuite des convoitises dangereuses ou tentatives de corruption des données. Le vrai problème est en fait moins technique (la sécurité ça se résoud y compris par la responsabilisation des agents et les règlementations), que celui de la formation des agents aux évolutions de ces systèmes. C'est là que les coûts peuvent exploser, à moins que les collectivités mettent en place des délégations de service public et s'en remettent alors totalement à quelqu'un d'autre pour leurs besoins (avec la crainte d'une dépendance opérationnelle, mais aussi de non maîtrise des coûts ultérieurs s'ils augmentent, et la difficulté alors de rapatrier les données pour les gérer d'une autre façon). Mais là aussi une asso comme l'AMF peut exercer son contrôle pour évaluer raisonnablement les solutions partagées mises en oeuvre (sans pour autant fédérer tout le monde dans le même système afin qu'il garde une taille raisonnable sans exploser et limiter l'exposition aux risques) et étudier les coûts (en faisant appel aussi au contrôle par la Cours des comptes qui a l'expertise dans ce domaine et la compétence nécessaire pour les fouiller en détail). Elle peut émettre des recommandations sur les meilleures pratiques et les évolutions nécessaires. Le 12 avril 2013 14:59, Tony Emery tony.em...@yahoo.fr a écrit : Christian Rogel wrote la solution est de faire des SIG à un niveau supérieur à la communauté de communes. C'est ce qui a été fait à Brest où la métropole met, par convention, son SIG à la disposition des autres EPCI du Pays de Brest (pays Voynet) 9 agents arrivent à couvrir 89 communes. Evidemment, c'est une décision politique, difficile à prendre, si les élus se méfient les uns des autres, mais, pas impossible à réaliser. Le modèle est que le SIG le plus avancé, fédère les EPCI les plus proches. Si certains d'entre vous sont en position d'attirer l'attention des élus là-dessus, ce serait une bonne chose. Effectivement, mais ce ne sera pas possible vu que la politique actuelle d'aménagement du territoire est de réduire le mille-feuilles administratif et de supprimer les syndicats et autres pays. Je pense que ça pourrait se faire soit au niveau des Conseils Généraux (mais ils leurs manque la compétence), soit, dans une volonté de solidarité, entre les interco qui ont des SIG et les autres (mais là, c'est un doux rêve). En attendant, il faut déjà avancer avec ceux qui ont déjà des référentiels et des moyens. -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5756807.html Sent from the France mailing list archive at Nabble.com. ___ 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
Re: [OSM-talk-fr] expérimentations à Orange
Le 12 avr. 2013 à 15:58, Philippe Verdy verd...@wanadoo.fr a écrit : Même sans faire appel au mille-feuille administratif, il y a d'autres moyens de coopérations entre communes et autres collectivités pour certaines missions. Les associations ça existe, la France n'en manque pas ! Déjà il y a l'Association des maires de France (AMF) et je ne vois pas pourquoi les petites collectivités qui manquent de moyens ne pourraient pas utiliser une solution pérenne gérée par une telle association, avec des moyens partagés, et des relais dans toutes les régions. Evidemment se pose la question de la sécurité des SIG,et de la responsabilité des intervenants qui modifient les bases, ou les consultent, mais ce n'est pas spécifique au cadre de la collaboration et le même problème existe déjà au sein même de chaque collectivité devant gérer un SIG, la différence étant une question d'échelle si un SIG partagé devient tellement important par le nombre d'infos qui y sont enregistrées collectivement qu'il suscite ensuite des convoitises dangereuses ou tentatives de corruption des données. Le vrai problème est en fait moins technique (la sécurité ça se résoud y compris par la responsabilisation des agents et les règlementations), que celui de la formation des agents aux évolutions de ces systèmes. C'est là que les coûts peuvent exploser, à moins que les collectivités mettent en place des délégations de service public et s'en remettent alors totalement à quelqu'un d'autre pour leurs besoins (avec la crainte d'une dépendance opérationnelle, mais aussi de non maîtrise des coûts ultérieurs s'ils augmentent, et la difficulté alors de rapatrier les données pour les gérer d'une autre façon). Mais là aussi une asso comme l'AMF peut exercer son contrôle pour évaluer raisonnablement les solutions partagées mises en oeuvre (sans pour autant fédérer tout le monde dans le même système afin qu'il garde une taille raisonnable sans exploser et limiter l'exposition aux risques) et étudier les coûts (en faisant appel aussi au contrôle par la Cours des comptes qui a l'expertise dans ce domaine et la compétence nécessaire pour les fouiller en détail). Elle peut émettre des recommandations sur les meilleures pratiques et les évolutions nécessaires. Difficile de répondre à une suite de propositions qui n'ont strictement aucun sens dans le contexte de l'administration territoriale. Des prestations SIG externalisées? Avec appels d'offres tous les 3 ans et obligation pour les fonctionnaires communaux de réapprendre une nouvelle interface? Même aux USA, paradis des missions publiques privatisées, cela doit être rare. Une association n'aurait aucune légitimité dans le domaine, seule une entente réglementaire entre collectivités pourrait être envisagée ou des conventions multi-latérales comme à Brest. Christian R., ancien utilisateur lambda d'un SIG public ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
LA légitimité concerne l'utilisation quotidienne des données effectives. L'asso est tout à fait habilitée à faire des recommandations et des études, qui n'ont aucun impact réglementaire ou légal pour autant qui sont inattaquables. Les collectivités sont ensuite responsables de leurs décisions de suivre ou pas ces recommandations. Pourtant bien des réglementations sont issues de réflexions préalables passant par des associations et des recommandations. Elles deviennent pertinente une fois que leurs membres commencent à les adopter (mais la recommandation ou l'asso qui l'a promue reste inattaquables elles-mêmes, seule les décisions de ceux qui les appliquent pouvant être l'objet de contentieux légaux). De quoi parle-t-on dans ce sujet ? De la difficulté des colectivités de s'adapter. Si on commence à parler de la possibilité qui leur est donné de déléguer leurs SIGs à d'autres entités (fussent-elles d'autres collectivités), on comence à parler de collaboration avant. L'AMF est tout à faire appropriée comme lieu d'échange et de discussions pour formuler des propositions et recommandations qui seront *ensuite* suivies d'effet par les délégations de service public faites soit entre les collectivités elles-mêmes (pas de marché public en tant que tel), soit avec des prestataires externes via des marchés publics. Mais ce sera *leur* décision, pas celle de l'AMF. Le 12 avril 2013 17:23, Christian Rogel christian.ro...@club-internet.fra écrit : Le 12 avr. 2013 à 15:58, Philippe Verdy verd...@wanadoo.fr a écrit : Même sans faire appel au mille-feuille administratif, il y a d'autres moyens de coopérations entre communes et autres collectivités pour certaines missions. Les associations ça existe, la France n'en manque pas ! Déjà il y a l'Association des maires de France (AMF) et je ne vois pas pourquoi les petites collectivités qui manquent de moyens ne pourraient pas utiliser une solution pérenne gérée par une telle association, avec des moyens partagés, et des relais dans toutes les régions. Evidemment se pose la question de la sécurité des SIG,et de la responsabilité des intervenants qui modifient les bases, ou les consultent, mais ce n'est pas spécifique au cadre de la collaboration et le même problème existe déjà au sein même de chaque collectivité devant gérer un SIG, la différence étant une question d'échelle si un SIG partagé devient tellement important par le nombre d'infos qui y sont enregistrées collectivement qu'il suscite ensuite des convoitises dangereuses ou tentatives de corruption des données. Le vrai problème est en fait moins technique (la sécurité ça se résoud y compris par la responsabilisation des agents et les règlementations), que celui de la formation des agents aux évolutions de ces systèmes. C'est là que les coûts peuvent exploser, à moins que les collectivités mettent en place des délégations de service public et s'en remettent alors totalement à quelqu'un d'autre pour leurs besoins (avec la crainte d'une dépendance opérationnelle, mais aussi de non maîtrise des coûts ultérieurs s'ils augmentent, et la difficulté alors de rapatrier les données pour les gérer d'une autre façon). Mais là aussi une asso comme l'AMF peut exercer son contrôle pour évaluer raisonnablement les solutions partagées mises en oeuvre (sans pour autant fédérer tout le monde dans le même système afin qu'il garde une taille raisonnable sans exploser et limiter l'exposition aux risques) et étudier les coûts (en faisant appel aussi au contrôle par la Cours des comptes qui a l'expertise dans ce domaine et la compétence nécessaire pour les fouiller en détail). Elle peut émettre des recommandations sur les meilleures pratiques et les évolutions nécessaires. Difficile de répondre à une suite de propositions qui n'ont strictement aucun sens dans le contexte de l'administration territoriale. Des prestations SIG externalisées? Avec appels d'offres tous les 3 ans et obligation pour les fonctionnaires communaux de réapprendre une nouvelle interface? Même aux USA, paradis des missions publiques privatisées, cela doit être rare. Une association n'aurait aucune légitimité dans le domaine, seule une entente réglementaire entre collectivités pourrait être envisagée ou des conventions multi-latérales comme à Brest. Christian R., ancien utilisateur lambda d'un SIG public ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
2013/4/5 Christian Rogel christian.ro...@club-internet.fr J'ignore ce que Pieren désigne par contributeur lambda. Cela s'oppose à contributeur non-lambda. Je vais essayer d'en donner une définition : c'est une personne de 7 à 77 ans qui veut juste ajouter une rue, une piste cyclable, un nom, une maison ou un POI mais qui ne sait pas ce que veut dire SIG, qui ne sait pas ce qu'est un code INSEE de la commune (qui est, en plus, différent du code postal), qui ne connait pas la différence entre canton et arrondissement départemental. Bref, ceux qui ne participent pas ou peu aux discussions sur cette liste, contrairement au contributeur non-lambda, qui par la force des choses ou par son métier, connait tout ce vocabulaire et les arcanes de l'administration et qui sont à peu près les seuls à être capables d'appréhender l'ensemble des données présentes dans OSM. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
2013/4/7 Tony Emery tony.em...@yahoo.fr Une autorité de l'Etat qui se chargerait de chapeauter les compétences de collectivités territoriales autonomes ?!? Oula, tu veux la révolution ??? Penchez-vous sur le sujet de la décentralisation en France et vous comprendrez que vous avez tout faut, là... Bah, je pensais au cadastre en disant ça. Ca à l'air de fonctionner à peu près correctement avec une administration centrale qui collabore avec les communes et collectivités locales (ça irait encore mieux avec plus de moyens). Mais la composante adresse n'est pas son principal souci (elles sont souvent erronées, imprécises et anonymes). Il suffirait d'en faire une obligation comme pour le parcellaire et en utilisant le même modèle de coopération pour l'actualiser. Cela ne changerait rien à l'autonomie locale mais rien n'empêche de fixer certaines normes pour pouvoir construire des bases de données à l'échelle du pays. Bien sûr, on peut préférer l'absence de standardisation, le chaos où chacun fait comme il veut dans son coin et l'absence totale de mise en commun des ressources et des données. On peut comprendre que cela fasse les affaires de quelque-uns mais cela se fait au détriment de l'intérêt général. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 11 avril 2013 11:14, Pieren pier...@gmail.com a écrit : Mais la composante adresse n'est pas son principal souci (elles sont souvent erronées, imprécises et anonymes). Il suffirait d'en faire une obligation comme pour le parcellaire et en utilisant le même modèle de coopération pour l'actualiser. Pour cela il aurait fallu que la filiale de La Poste gérant et exploitant le fichier des adresses soit transférée sous l'autorité de l'ARCEP, afin de permettre dans ce domaine là aussi une juste concurrence. Je ne comprend pas que l'ARCEP soit compétente pour gérer par exemple le plan de numérotation téléphonique national, mais pas les codes postaux, ni adresses pourtant issues du travail des collectivités territoriales publiques, alors qu'elle est sensée réguler la concurrence dans le domaine postal. La Poste devenant une société privée, n'aurait pas du conserver cet avantage issu de l'ancien monopole de service public. Je me demande pourquoi les autres concurrents de La Poste n'ont pas fait d'action judiciaire pour avoir un accès égal à celui de La Poste concernant les adresses et codes postaux, puisque La Poste a maintenant un avantage concurrentiel dans ce domaine, les autres devant collecter eux-mêmes ces fichiers depuis leurs clients, ou acheter des licences à la filiale de La Poste pour les fichiers MediaPost ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Pieren wrote Bah, je pensais au cadastre en disant ça. Ça à l'air de fonctionner à peu près correctement avec une administration centrale qui collabore avec les communes et collectivités locales (ça irait encore mieux avec plus de moyens). Mais la composante adresse n'est pas son principal souci (elles sont souvent erronées, imprécises et anonymes). Il suffirait d'en faire une obligation comme pour le parcellaire et en utilisant le même modèle de coopération pour l'actualiser. Cela ne changerait rien à l'autonomie locale mais rien n'empêche de fixer certaines normes pour pouvoir construire des bases de données à l'échelle du pays. Bien sûr, on peut préférer l'absence de standardisation, le chaos où chacun fait comme il veut dans son coin et l'absence totale de mise en commun des ressources et des données. On peut comprendre que cela fasse les affaires de quelque-uns mais cela se fait au détriment de l'intérêt général. Alors, je vais essayer de vous expliquer comment ça marche. 1- La DGFiP fait partie de la fonction publique d'état et les communes de la fonction publique territoriale, c'est comme si vous vouliez comparer Auchan avec le boulanger du coin. 2- La DGFiP ne dispose pas du filaire de voirie mais seulement d'une couche de données représentant les étiquettes du nom des voies. 3- La création, modification, suppression d'une voie ou de son nom est de la compétence de la commune (en gros) est se fait par délibération. 4- Cette délibération est ensuite transmise à la DGFiP (avec un plan papier) qui numérise tout ça et attribut un numéro de Rivoli. 5- La commune reçoit en retour chaque année une mise à jour des données cadastrales comprenant, entre autres, une table avec le nom des voies et le code rivoli (en gros aussi). 6- il peut se passer plusieurs mois voir années entre le point 4- et le point 6-. 7- l'unité principale de la DGFiP n'est pas la voie mais la parcelle... Une fois que j'ai dit ça, que peut-on en tirer ? 1- Que la source première de données est et restera toujours la commune (en gros toujours) ; 2- Qu'il faut s'appuyer sur elles si l'on veut constituer une base crédible et maintenue dans le temps ; 3- Que, étant données les différences de moyens des collectivités, seule un petite minorité d'entre elles sont capables de faire ce travail 4- Que pour compenser l'inégalité des moyens, il faudrait que les intercommunalités prennent le relais mais 5- Que certaines d'entre elles, notamment en milieu rural, n'ont pas plus les moyens de le faire 6- Que les collectivités locales ne peuvent pas imposer quoi que ce soit aux autres (principe constitutionnel d’interdiction de la tutelle d’une collectivité territoriale sur une autre) Et alors, que peut-on faire ? 1- Sensibiliser les collectivités à la démarche et faire en sorte que celles qui en ont les moyens réfléchissent soit à modèle de données commun, soit à un système permettant de passer de l'un à l'autre. 2- D'aider les autres communes à créer de la données selon le(s) modèle(s) commun et à maintenir une mise à jour Je crois qu'OpenStreetMap et sa communauté peut y jouer un rôle... -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5756669.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 11 avril 2013 17:43, Tony Emery tony.em...@yahoo.fr a écrit : Alors, je vais essayer de vous expliquer comment ça marche. 1- La DGFiP fait partie de la fonction publique d'état et les communes de la fonction publique territoriale, c'est comme si vous vouliez comparer Auchan avec le boulanger du coin. 2- La DGFiP ne dispose pas du filaire de voirie mais seulement d'une couche de données représentant les étiquettes du nom des voies. Ca dépend... les fichiers EDIGEO fournis à la DGFiP peuvent contenir le filaire de voirie en plus des étiquettes. 3- La création, modification, suppression d'une voie ou de son nom est de la compétence de la commune (en gros) est se fait par délibération. 4- Cette délibération est ensuite transmise à la DGFiP (avec un plan papier) qui numérise tout ça et attribut un numéro de Rivoli. Rivoli est devenu FANTOIR ou bien c'est différent ? 5- La commune reçoit en retour chaque année une mise à jour des données cadastrales comprenant, entre autres, une table avec le nom des voies et le code rivoli (en gros aussi). 6- il peut se passer plusieurs mois voir années entre le point 4- et le point 6-. 7- l'unité principale de la DGFiP n'est pas la voie mais la parcelle... Une fois que j'ai dit ça, que peut-on en tirer ? 1- Que la source première de données est et restera toujours la commune (en gros toujours) ; 2- Qu'il faut s'appuyer sur elles si l'on veut constituer une base crédible et maintenue dans le temps ; 3- Que, étant données les différences de moyens des collectivités, seule un petite minorité d'entre elles sont capables de faire ce travail 4- Que pour compenser l'inégalité des moyens, il faudrait que les intercommunalités prennent le relais mais 5- Que certaines d'entre elles, notamment en milieu rural, n'ont pas plus les moyens de le faire 6- Que les collectivités locales ne peuvent pas imposer quoi que ce soit aux autres (principe constitutionnel d’interdiction de la tutelle d’une collectivité territoriale sur une autre) Et alors, que peut-on faire ? 1- Sensibiliser les collectivités à la démarche et faire en sorte que celles qui en ont les moyens réfléchissent soit à modèle de données commun, soit à un système permettant de passer de l'un à l'autre. 2- D'aider les autres communes à créer de la données selon le(s) modèle(s) commun et à maintenir une mise à jour Je crois qu'OpenStreetMap et sa communauté peut y jouer un rôle... Tu as une idée de comment OSM pourrait jouer un rôle ou bien c'est plutôt un vœu ? -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/shttp://openstreetmap.fr/sotmfr2013ynthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
2013/4/11 Christian Quest cqu...@openstreetmap.fr 2- La DGFiP ne dispose pas du filaire de voirie mais seulement d'une couche de données représentant les étiquettes du nom des voies. Ca dépend... les fichiers EDIGEO fournis à la DGFiP peuvent contenir le filaire de voirie en plus des étiquettes. Oui, c'est un peu ça l'idée. Mais ça ne devrait pas forcément aller dans la même bdd que le parcellaire... Tout ce qui est dit sur les délais trop longs peut changer dès lors qu'une responsabilité est assignée et les moyens qui vont avec (c'est bien là où ça coince). L'inégalité des moyens entre communes existe aussi pour gérer le parcellaire et ce sont les collectivités aux échellons supérieurs qui prennent le relai (on voit comment ça se passe pour la numérisation). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
cquest wrote Ca dépend... les fichiers EDIGEO fournis à la DGFiP peuvent contenir le filaire de voirie en plus des étiquettes. Ça fait 6 ans que je traite les données de la DGFiP et je n'ai jamais vu le filaire de voie cquest wrote Rivoli est devenu FANTOIR ou bien c'est différent ? Oui, le fichier RIVOLI (répertoire informatisé des voies et lieux-dits) est devenu le FANTOIR (Fichier ANnuaire TOpographique Initialisé Réduit) cquest wrote Tu as une idée de comment OSM pourrait jouer un rôle ou bien c'est plutôt un vœu ? J'ai quelques pistes... et c'est vraiment un projet qui me botte ! -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5756699.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Pieren wrote Tout ce qui est dit sur les délais trop longs peut changer dès lors qu'une responsabilité est assignée et les moyens qui vont avec (c'est bien là où ça coince). Sauf que l'Etat n'a déjà plus les moyens d'assumer ses propres missions Pieren wrote L'inégalité des moyens entre communes existe aussi pour gérer le parcellaire et ce sont les collectivités aux échellons supérieurs qui prennent le relai (on voit comment ça se passe pour la numérisation). Déjà, la numérisation du parcellaire a pris presque 10 ans (et je dirais même plus), aucune des bases (IGN ou DGFiP) n'est précise et les communes ne gèrent pas les parcelles... -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5756700.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 11 avril 2013 19:45, Tony Emery tony.em...@yahoo.fr a écrit : Oui, le fichier RIVOLI (répertoire informatisé des voies et lieux-dits) est devenu le FANTOIR (Fichier ANnuaire TOpographique Initialisé Réduit) Tu ne voulais pas dire plutôt le Fichier OUblié TOpographique Inutilisé au Rebut ? ;-) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Il reste 8905 communes en raster et sur un an il y en a eu dans les de vectorisées. A ce rythme, il faudra encore 4 ans pour arriver à bout. Voir: http://munin.openstreetmap.fr/stats.db/departement/osm_commune_tous.html Le 11 avril 2013 19:49, Tony Emery tony.em...@yahoo.fr a écrit : Pieren wrote Tout ce qui est dit sur les délais trop longs peut changer dès lors qu'une responsabilité est assignée et les moyens qui vont avec (c'est bien là où ça coince). Sauf que l'Etat n'a déjà plus les moyens d'assumer ses propres missions Pieren wrote L'inégalité des moyens entre communes existe aussi pour gérer le parcellaire et ce sont les collectivités aux échellons supérieurs qui prennent le relai (on voit comment ça se passe pour la numérisation). Déjà, la numérisation du parcellaire a pris presque 10 ans (et je dirais même plus), aucune des bases (IGN ou DGFiP) n'est précise et les communes ne gèrent pas les parcelles... -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5756700.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/shttp://openstreetmap.fr/sotmfr2013ynthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 11 avril 2013 19:58, Christian Quest cqu...@openstreetmap.fr a écrit : Il reste 8905 communes en raster et sur un an il y en a eu dans les de vectorisées. A ce rythme, il faudra encore 4 ans pour arriver à bout. Et sans compter que le processus de vectorisation n'est pas financé partout avec en particulier le département de la Meuse (cf. ce message de Pieren http://lists.openstreetmap.org/pipermail/talk-fr/2012-November/051023.html) Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Si l'Etat ne peut plus financer ça auprès des collectivités territoriales rurales, sans doute un accord de coopération avec la région, voire aussi les autres régions, départements et communes et intercommunalités (via leurs associations nationales), ou encore les chambres de commerce et d'industrie, celles d'agriculture, les structures de gestion des parcs régionaux et domaines forestiers, ou les agences de bassin, ou celles chargées des coopérations en terme d'aménagement et planification des transports, pourraient aider à finaliser les budgets nécessaires. D'autres agences nationales (l'IGN par exemple participe aussi à des programmes de coopération avec des agences cartographiques étrangères), l'Union européenne (par des subventions accordées à une association de gestion de ces coopérations), ou les structures de coopération transfrontalières européennes existantes (où participent déjà des collectivités territoriales françaises) pourraient contribuer dans ces coopérations. Malgré tout avant de demander des subventions européennes, il faudrait convaincre que la France ne peut pas financer ça elle-même alors que les besoins sont beaucoup plus criants dans bien d'autres pays européens beaucoup moins bien lotis financièrement pour mener ds projets similaires (Chypre, Malte, Grèce, Portugal) alors que la France devrait aussi pouvoir les aider ne serait-ce que par des moyens techniques et équipements. Dans une structure de coopération, les modes d'action sont plus ouverts que les seules administrations publiques. Mais il se pose alors le problème de la certification des données et de l'expertise des coopérants, ce qui demande une supervision dans le cas des données à caractère légal comme le cadastre et la collecte fiscale, et non seulement estimatives pour de nombreuses statistiques, ou les zones à risque, les PLU et les schémas de transports engageant les collectivités), et celui de la confidentialité de certaines informations privées qui ne doivent pas figurer dans ces données, ainsi que dans les moyens de recours et d'accès aux données privatives en cas d'erreurs. Peut-être que le niveau de précision demandé pour la numérisation est trop élevé dès le départ, alors que les bases numérisées pourrait s'améliorer bien plus tard de façon plus progressive et moins douloureuse financièrement : un relèvement des marges d'erreurs acceptables pourraient accélérer les choses. C'est ce qui a été fait en Espagne par exemple, même si de nombreux plans cadastraux ne sont pas encore numérisés non plus (ni même simplement scannés, il y a de nombreuses zones blanches), avec une vectorisation partielle seulement de certaines frontières, souvent sans conflation complète des différents plans (d'ailleurs ces ajustements n'ont pas plus été faits en France pour raccorder correctement les communes, voire des planches cadastrales de la même commune, et là dessus l'IGN aurait du développer des solutions techniques permettant de corriger ces défauts en minimisant les erreurs, tout en gardant les seuils de précision des planches initiales dont le métrage historique a été fait sur une ancienne triangulation géodésique et jamais révisé !). Le 11 avril 2013 22:46, Romain MEHUT romain.me...@gmail.com a écrit : Le 11 avril 2013 19:58, Christian Quest cqu...@openstreetmap.fr a écrit : Il reste 8905 communes en raster et sur un an il y en a eu dans les de vectorisées. A ce rythme, il faudra encore 4 ans pour arriver à bout. Et sans compter que le processus de vectorisation n'est pas financé partout avec en particulier le département de la Meuse (cf. ce message de Pieren http://lists.openstreetmap.org/pipermail/talk-fr/2012-November/051023.html ) Romain ___ 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
Re: [OSM-talk-fr] expérimentations à Orange
Le sam. 06 avril 2013 à 15:46 -0700, Tony Emery a écrit : Je suis d'accord sur ce point. Mais je tiens, en tant que cartographe et géographe de formation à vous rappeler une chose : quel sens donne-t-on à la carte ? à quoi doit-elle servir ? S'il s'agit juste de cartographier le réel juste pour avoir des objets dans la base de données, ça sert à rien. Si on veut que cela soit utiliser, ça veut dire qu'il faut créer de la donnée pour l'usage et l'usager. OK, on sera tous d'accord là dessus, mais je ne vois pas quelle conséquence tu en tires sur le fait que les données opendata importées seront, oui ou non, fusionnées avec les données standard OSM. Comme c'est un sujet particulièrement important, que je ne veux pas voir poussé sous le tapis, je vais essayer de rédiger une synthèse de toute la discussion, avec les points consensuels et les points de désaccord. A bientôt donc... -- ° /\Guillaume AllègreOpenStreetMap 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
Re: [OSM-talk-fr] expérimentations à Orange
Pieren wrote Quand je parle de simple, c'est par rapport à la simplification administrative qui ferait qu'une seule autorité serait chargée de maintenir une base unique. Elle pourrait bien-sûr être abondée par les créateurs d'adresses (les communes) mais aussi pouvoir être corrigée et améliorée par les institutions utilisatrices (INSEE, DGFiP, police, la poste, etc). Seule la partie anonymisée serait publique et réutilisable. La partie nominative serait plus facilement entretenue si elle était couplée à une obligation légale de déclaration dominiliaire (se déclarer en mairie lors de l'installation) comme pratiquement partout ailleurs en Europe. Une autorité de l'Etat qui se chargerait de chapeauter les compétences de collectivités territoriales autonomes ?!? Oula, tu veux la révolution ??? Penchez-vous sur le sujet de la décentralisation en France et vous comprendrez que vous avez tout faut, là... Je pense qu'il faut aborder le problème d'une autre manière. Si on prend le cas de la numérisation des documents d'urbanisme, les recommandations ont été proposées (et non imposées) par le Centre National de l'Information Géographique (CNIG). A charge, pour les communes, d'appliquer ces recommandations. Il faudra sûrement en passer par là dans notre cas et proposer une normalisation suffisamment exhaustive et applicable pour s'imposer d'elle même aux collectivités... -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5756098.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Christian Rogel wrote Tony faisait le distinguo entre collectivité publique autonome et administration de l'Etat. C'est sur l'anarchie admistrative français qu'il met le doigt. En fait, je ne parle pas d'anarchie, je suggère seulement de comprendre que le service publique n'est pas une nébuleuse unique ou tous les services sont rattachés. Il faut bien distinguer la fonction publique d'Etat (les ministère, les préfectures, les impôts, l'INSEE, l'IGN, ...) et la fonction publique territoriale (les communes, les départements et les régions). Je rentre pas dans les détails car c'est plus complexe encore. Et, en gros, la fonction publique d'Etat ne peut rien imposer à la fonction publique territoriale. Voilà comment ça marche. -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5756100.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Guillaume Allegre wrote OSM ne doit pas devenir un dépôt où les institutions accepteraient de verser leurs données à condition que personne n'y touche. OSM c'est du crowdsourcing avant tout ; l'open data est un complèment, bienvenu mais pas essentiel. Il faut qu'on travaille au maximum pour intégrer l'open data dans OSM, mais si on tombe sur un conflit entre les deux, OSM laissera tomber l'open data et privilégiera toujours le crowdsourcing. Ce point est très important pour les discussions avec les collectivités, et il est non négociable, comme la licence. En un mot : aucune donnée ne doit être verrouillée dans OSM. Je suis d'accord sur ce point. Mais je tiens, en tant que cartographe et géographe de formation à vous rappeler une chose : quel sens donne-t-on à la carte ? à quoi doit-elle servir ? S'il s'agit juste de cartographier le réel juste pour avoir des objets dans la base de données, ça sert à rien. Si on veut que cela soit utiliser, ça veut dire qu'il faut créer de la donnée pour l'usage et l'usager. Concernant la remarque de Guillaume sur: Guillaume Allegre wrote Donc, exit le ref:source=, et je ne vois pas d'autre solution que le ref:FR: idbase = id Je suis d'accord pour un ref:FR:idbase=id, et même, je dirais, un ref:FR:Communal=id ou un ref:FR:niveau_administratif=id pour gérer les référentiels de plusieurs échelles administratives. -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5756101.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
On partage le même point de vue, sauf que les références provenant d'entités administratives multiples mais de même niveau (plusieurs communes ou plusieurs départements) risquent d'arriver (sans pour autant que leurs identifiants de bases de données soient compatibles entre eux. Là dessus OSM peut **aussi** devenir prescripteur d'identifiants stables permettant d'aider les collectivités à trouver des identifiants pour bases de données compatibles entre elles, si les organismes nationaux fournissant des nomenclatures (l'Insee par exemple, ou des organismes européens, ou l'ISO dans une norme internationale) ne traitent pas certains sujets. De nombreux pays par exempel n'ont pas de nomenclature stabilisée et utilisent des logiciels et bases de données fournies par d'autres pays ou par des sociétés privées ou organisations non commerciales (je pense à des tas de PVD en Afrique, Asie centrale, et archipels du Pacifique ou des Caraïbes), tout bonnement car ils n'ont pas les moyens de développer et maintenir ces logiciels et bases de données eux-mêmes. Hors ces pays, s'ils font appel à des sociétés privées (ou même de la part de fondations caritatives internationales), risquent de se retrouver dans l'incapacité de publier leurs données à cause de problèmes de licences de la part de ces tiers. OSM peut alors fournir une aide en proposant sa codification qui ne sera pas meilleure, ni pire, que les autres codifications incompatibles entre elles proposées par des tiers sous des licences restrictives et empêchant les croisements de fichiers qui leurs sont pourtant fournis. Le 7 avril 2013 00:46, Tony Emery tony.em...@yahoo.fr a écrit : Guillaume Allegre wrote OSM ne doit pas devenir un dépôt où les institutions accepteraient de verser leurs données à condition que personne n'y touche. OSM c'est du crowdsourcing avant tout ; l'open data est un complèment, bienvenu mais pas essentiel. Il faut qu'on travaille au maximum pour intégrer l'open data dans OSM, mais si on tombe sur un conflit entre les deux, OSM laissera tomber l'open data et privilégiera toujours le crowdsourcing. Ce point est très important pour les discussions avec les collectivités, et il est non négociable, comme la licence. En un mot : aucune donnée ne doit être verrouillée dans OSM. Je suis d'accord sur ce point. Mais je tiens, en tant que cartographe et géographe de formation à vous rappeler une chose : quel sens donne-t-on à la carte ? à quoi doit-elle servir ? S'il s'agit juste de cartographier le réel juste pour avoir des objets dans la base de données, ça sert à rien. Si on veut que cela soit utiliser, ça veut dire qu'il faut créer de la donnée pour l'usage et l'usager. Concernant la remarque de Guillaume sur: Guillaume Allegre wrote Donc, exit le ref:source=, et je ne vois pas d'autre solution que le ref:FR: idbase = id Je suis d'accord pour un ref:FR:idbase=id, et même, je dirais, un ref:FR:Communal=id ou un ref:FR:niveau_administratif=id pour gérer les référentiels de plusieurs échelles administratives. -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5756101.html Sent from the France mailing list archive at Nabble.com. ___ 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
Re: [OSM-talk-fr] expérimentations à Orange
Désolé pour le retard de ma réponse. Je vais essayer de vous donner quelques éléments de réflexion. Après, je suis ouvert à toutes propositions. Guillaume Allegre wrote 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. J'ai demandé à Christian, dans le cadre d'une expérimentation pour l'intégration des bureaux de vote et de la carte électorale, d'importer les données issues de notre SIG. Il s'agit du découpage officiel et utilisé par les services pour leurs missions quotidiennes. On peut comparer ce travail au découpage des zones du document d'urbanisme (PLU), des Servitudes d'Utilité Publique ou des parcelles de la DGFiP (je dis bien de la DGFiP). Par conséquent, ces traçés, même si leur précision n'est pas bonne, est règlementée. Pour info, dans un document d'urbanisme approuvé, si le dessin d'une zone à été mal fait, qu'il coupe une parcelle alors qu'il ne le devrait pas, c'est quand même ce découpage qui est appliqué. Je pense donc, même si ce n'est pas juste, qu'il faut le laisser tel quel si l'on veut que les collectivités s'investissent dans OSM. Elles ne le feront pas si les limites officielles ne correspondent pas, à cette échelle, à ce qu'elles trouvent dans OSM. Guillaume Allegre wrote 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.08722lon=4.7789zoom=17layers=M A mon avis, c'est de la sur-résolution inutile, mais ça se discute. Cela n'enlève rien au point 1 : il faut choisir quelle limite on prend (171243851 ou 197278529), voire un intermédiaire en simplifiant la limite polling_station, mais il faut quand même à terme fusionner les deux. Même réponse qu'au-dessus Guillaume Allegre wrote 3) La relation 2649371 a des attributs bizarres : - pas de nom - un CANTON=Ouest pas documenté - un ref=22 pas documenté non plus Effectivement, peut-être que le ref peut devenir le name Guillaume Allegre wrote 4) la route http://www.openstreetmap.org/browse/way/195747326 a les attributs : highway = road addr:postcode = |84100 ref:orange = 84087V99 En dehors de la typo sur le code postal avec le |, est-ce logique de mettre un code postal sur une voie ? le wiki ne donne qu'un noeud ou une surface, et j'aurais tendance à le suivre sur ce point. J'ai pris le parti d'ajouter addr:postcode = 84100 sur les voies qui se trouvent dans la commune, en attendant d'avoir un outil qui me permette de sélectionner tous les objets présents à l'intérieur d'une frontière administrative. Le fait qu'elles aient |84100 veut dire qu'elles se trouvent en partie sur le territoire (pas forcément gauche et droite) et que je dois faire attention quand je les intègre. Guillaume Allegre wrote Ensuite : ref:orange : là, je pense qu'on a un problème à régler. orange n'est pas suffisamment distinctif. Si toutes les communes du monde se mettent à utiliser le même schéma, on va multiplier les conflits. Comment régler ça ? L'objectif est de pouvoir faire un lien systématique entre la voie dans OSM et celles dans la base communale. J'ai mis, à l'époque, ref:orange parce qu'il n'y avait rien de similaire et qu'il s'agit d'une réflexion que l'on mène sur plusieurs communes du Vaucluse. S'il faut changer de clé, cela ne me pose pas de problème mais il faut savoir que cela concernera d'abord les communes et non l'INSEE. On m'avait suggéré ref:84087, mais je trouvais cela redondant car dans mon identifiant,il y a déjà le code INSEE. De plus, c'est quelque chose qui peut se diffuser sur d'autres communes et nous aurions des tags ref:84087, ref:75001, ref:13205, etc... Il faudrait plutôt un tag du type ref:FR:commune= ou dans le genre. Guillaume Allegre wrote Je ne remets pas en cause l'utilisation d'OSM comme support de données métiers issues de SIG territoriaux, bien au contraire. Mais si, comme je le suppose, Orange tend à devenir une zone d'exemple et de démonstration pour cette convergence, il serait préférable que le schéma suivi soit aussi irréprochable que possible quant à l'intégration dans les conventions standard OSM. Alors, je pense qu'il faut sérieusement se pencher sur : - le schéma d'attributs et de références qui conviendrait à tout le monde - les conventions de fusion ou juxtaposition de données, et les précisions géométriques minimales/maximales acceptables. Je suis d'accord et je veux bien y participer -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5755816.html Sent from the France mailing list archive at Nabble.com. ___
Re: [OSM-talk-fr] expérimentations à Orange
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_INSEETYPENUMERO) ? 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 Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Il me semble qu'un numéro de référence unique de la voirie doit effectivement se baser sur le code rivoli/fantoir et le code insee de la commune. Comme toujours, il faut regarder les cas particuliers... par exemple comment gérer une rue qui est la limite entre deux communes ? Ce simple cas particulier me laisse penser qu'il faudrait une référence combinée INSEE+FANTOIR et ça sera plus léger que d'avoir 2 tags. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
cquest wrote Il me semble qu'un numéro de référence unique de la voirie doit effectivement se baser sur le code rivoli/fantoir et le code insee de la commune. Comme toujours, il faut regarder les cas particuliers... par exemple comment gérer une rue qui est la limite entre deux communes ? Ce simple cas particulier me laisse penser qu'il faudrait une référence combinée INSEE+FANTOIR et ça sera plus léger que d'avoir 2 tags. Les collectivités ne pourront pas utiliser les codes fantoir de la DGFiP : - parce qu'ils sont créés par la DGFiP a posteriori, après que la commune ait transmis la délibération aux impôts, que ces derniers aient intégré ces infos dans leur base et que ces données aient été renvoyées aux communes. Il peut se passer plusieurs mois, voire plus. - il y a des doublons dans les fantoir, et des codes fantoir qui pointent sur des voies qui n'existent plus. Si les communes qui se sont penché sur le problème ont décidé de créer leur propre identifiant unique, c'est que c'était la seule solution. L'inconvénient étant que la très grande majorité des communes n'ont pas encore fait ce travail. -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5755840.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
2013/4/5 Tony Emery tony.em...@yahoo.fr 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. Donc chaque rue a trois identifiants uniques. Qui a parlé de simplification administrative ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
2013/4/5 Tony Emery tony.em...@yahoo.fr Par conséquent, ces traçés, même si leur précision n'est pas bonne, est règlementée. Pour info, dans un document d'urbanisme approuvé, si le dessin d'une zone à été mal fait, qu'il coupe une parcelle alors qu'il ne le devrait pas, c'est quand même ce découpage qui est appliqué. Je pense donc, même si ce n'est pas juste, qu'il faut le laisser tel quel si l'on veut que les collectivités s'investissent dans OSM. Ce point est capital avec OSM. C'est la violation d'un principe de base du projet : les données doivent pouvoir être améliorées par les contributeurs, sinon elles n'ont pas leur place dans la base. Aucune donnée ne doit pouvoir être bloquée dans OSM sous prétexte d'officialité, encore plus si elles sont mauvaises. Je renverrais la lecture d'un fil de discussion de référence sur ce thème (en anglais) : http://lists.openstreetmap.org/pipermail/talk/2009-March/034948.html Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Pieren wrote 2013/4/5 Tony Emery lt; tony.emery@ gt; 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. Donc chaque rue a trois identifiants uniques. Qui a parlé de simplification administrative ? Pieren Effectivement, sans parler de l'ID de la BDAdresse que je n'utilise pas, j'ai : - le RIVOLI de la DGFIP (en plus, j'ai 44 voies sur les 730 qui n'ont pas de rivoli) - l'identifiant interne géré par la mairie - l'identifiant OSM Après, on ne peut pas parler de simplification administrative puisqu'il ne s'agit pas de la même institution. Je pense que tu dois avoir la même chose à la poste, au niveau des conseil généraux, ... -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5755862.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
2013/4/5 Tony Emery tony.em...@yahoo.fr Après, on ne peut pas parler de simplification administrative puisqu'il ne s'agit pas de la même institution. Il y a aussi le serpent de mer de la base adresse unifiée. Parce que pour l'instant, chaque institution construit la sienne à grands frais (enfin, surtout aux frais des contribuables et des usagers). Mon rêve : une base adresse unifiée, publique, réutilisable librement et avec un code de voie vraiment unique adoptée par toutes les institutions. Vous avez dit trop simple ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Pieren, Je plussoie ! On parle d'opendata, mais cette base unifiée dont tu parles, en ODBL, avec une api sympa pour y accéder, ce serait l'idéal ! Le 5 avril 2013 11:54, Pieren pier...@gmail.com a écrit : 2013/4/5 Tony Emery tony.em...@yahoo.fr Après, on ne peut pas parler de simplification administrative puisqu'il ne s'agit pas de la même institution. Il y a aussi le serpent de mer de la base adresse unifiée. Parce que pour l'instant, chaque institution construit la sienne à grands frais (enfin, surtout aux frais des contribuables et des usagers). Mon rêve : une base adresse unifiée, publique, réutilisable librement et avec un code de voie vraiment unique adoptée par toutes les institutions. Vous avez dit trop simple ? Pieren ___ 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
Re: [OSM-talk-fr] expérimentations à Orange
Le 5 avril 2013 12:27, kimaidou kimai...@gmail.com a écrit : Pieren, Je plussoie ! On parle d'opendata, mais cette base unifiée dont tu parles, en ODBL, avec une api sympa pour y accéder, ce serait l'idéal ! Le 5 avril 2013 11:54, Pieren pier...@gmail.com a écrit : 2013/4/5 Tony Emery tony.em...@yahoo.fr Après, on ne peut pas parler de simplification administrative puisqu'il ne s'agit pas de la même institution. Il y a aussi le serpent de mer de la base adresse unifiée. Parce que pour l'instant, chaque institution construit la sienne à grands frais (enfin, surtout aux frais des contribuables et des usagers). Mon rêve : une base adresse unifiée, publique, réutilisable librement et avec un code de voie vraiment unique adoptée par toutes les institutions. Vous avez dit trop simple ? Je n'y crois pas du tout. Peut être est-ce bon pour l'Administration, mais il est sûr que c'est mauvais pour la géographie, et il n'est pas clair que ce soit bon pour la cartographie. Quand à savoir si c'est bon pour l'humain... Que l'Administration n'y arrive même pas, alors que ça parait si trop simple, devrait donner quelques doutes sur l'idée... mais pour les certitudes il est plus facile d'invoquer la lourdeur administrative, j'admets. Quelques éléments de doute ?... comment une adresse est-elle en rapport avec une voie ? comment se fait la synchronisation personne-adresse-voie ? et j'en passe. En informatique, si les identifiants uniques restent un outil majeur, les identifiants par rapport à un contexte, une identité, et quelques fois à un ordre, gagnent de plus en plus de terrain, c'est pas pour des prunes. XML Schéma, par exemple, les définit ainsi, contredisant (reculant, dirais-tu ? ) le système des DTD qui définissait les identifiants de façon absolue. C'est pas pour se faire plaisir, mais parce que dans un contexte hétérogène les identifiants uniques ça coince très vite. (à mais oui c'est vrai que XML c'est looouuud) OSM, je crois, est trop centré administration française. C'est pour ça qu'on croit voir sur le terrain tant de objets qui pourraient avoir un identifiant unique... et que, finalement, on ne sache même pas si une clairière est un trou ou un objet qui ferait ou non partie de la forêt. Que la collaboration avec l'administration aide à se valoriser, à travailler, à faire son mai 68 open data est une chose. Mais qu'on se mette à donner des leçons à cet administration en est une autre. Et que l'on comprenne comment est-ce que l'on peut rendre compte du terrain sur une carte, encore une autre. Pour ça les questions d'identités, non les numéros, sont The Good Way To Do May Be. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
2013/4/5 Ista Pouss ista...@gmail.com Que la collaboration avec l'administration aide à se valoriser, à travailler, à faire son mai 68 open data est une chose. Mais qu'on se mette à donner des leçons à cet administration en est une autre. Quand je parle de serpent de mer, c'est au sein même de l'administration. Un peu de lecture s'impose: http://www.afigeo.asso.fr/documentation/category/12.html?download=463%3Aafigeo-gt-adresse-rapport-2011 Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le sujet des adresses est revenu à de très nombreuses fois durant les rencontres de l'Afigéo à Bordeaux (qui se terminent ce soir). Hier, l'IGN a signé à ce sujet un partenariat avec PIGMA, la plateforme d'échange d'infos géographiques d'Aquitaine. Il y a aussi beaucoup d'infos à récupérer de la DGFiP car les adresses figurent dans le cadastre vectoriel et de ce côté, il est bien possible qu'on ai accès à court terme à diverses données vectorielles du cadastre dans leur format d'origine (donc récupération de la voirie et des adresses, voire de quelques POI ou même des parcelles ce qui permet d'affiner les landuse). -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Pieren wrote Il y a aussi le serpent de mer de la base adresse unifiée. Parce que pour l'instant, chaque institution construit la sienne à grands frais (enfin, surtout aux frais des contribuables et des usagers). Mon rêve : une base adresse unifiée, publique, réutilisable librement et avec un code de voie vraiment unique adoptée par toutes les institutions. Vous avez dit trop simple ? Je vais essayer d'être concis... Effectivement, je ne suis pas d'accord avec ça et pour plusieurs raisons : - une commune n'est pas l'administration française mais est une *collectivité locale autonome*. A moins d'accord particulier, rien de permet de croire que 2 communes puissent travailler de la même manière, qu'elles soient voisines ou, pire encore, aux quatre coins de la France. - Les communes ont des *moyens financiers et humains* très différents. Si les grandes villes et les villes moyennes ont les compétences internes pour gérer la voirie en référentiel unique, ce n'est pas forcément le cas pour les petites villes et certainement pas le cas pour les 30.000 communes de moins de 1.000 habitants (à vue de nez). - Vous me direz, il y a les intercommunalités. Ce ne sont pas des collectivités locales et n'ont aucun contrôle sur les communes de son territoire. Elles n'ont pas forcément comme compétence la gestion de la voirie et, si c'est le cas, cela ne concerne en général que la voirie dite communautaire. La compétence voirie reste donc *essentiellement une compétence communale*. Là, je ne parle que de l'aspect création d'une base unique. Il reste le problème de la maintenance de cette base unique. Et, là encore, la commune est la source unique de l'information. C'est bien pour tout cela que je parle de *référencement interne à la commune de la voirie*. Croyez-moi, le sujet est loin d'être aussi simple. Il est complexe (pas compliqué) mais c'est pour cela qu'il est intéressant... -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5755899.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
cquest wrote Il y a aussi beaucoup d'infos à récupérer de la DGFiP car les adresses figurent dans le cadastre vectoriel et de ce côté, il est bien possible qu'on ai accès à court terme à diverses données vectorielles du cadastre dans leur format d'origine (donc récupération de la voirie et des adresses, voire de quelques POI ou même des parcelles ce qui permet d'affiner les landuse). Attention, il n'existe pas de données graphiques concernant la voirie dans le cadastre de la DGFiP. Il s'agit, en fait, d'une couche d'étiquettes du nom des voies qui sont positionnées dans les espaces entre les parcelles. Au mieux, il y a une couche d'habillage qui correspond (pas toujours) aux bordures de trottoir... -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5755901.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Damned ! tu aurais des scoops avant la réunion du 9 ? Gaël, au fait, si tu as des précisions sur le lieu exact du rendez-vous, je suis preneur. Denis -Message d'origine- De : Christian Quest [mailto:cqu...@openstreetmap.fr] Envoyé : vendredi 5 avril 2013 14:52 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] expérimentations à Orange Le sujet des adresses est revenu à de très nombreuses fois durant les rencontres de l'Afigéo à Bordeaux (qui se terminent ce soir). Hier, l'IGN a signé à ce sujet un partenariat avec PIGMA, la plateforme d'échange d'infos géographiques d'Aquitaine. Il y a aussi beaucoup d'infos à récupérer de la DGFiP car les adresses figurent dans le cadastre vectoriel et de ce côté, il est bien possible qu'on ai accès à court terme à diverses données vectorielles du cadastre dans leur format d'origine (donc récupération de la voirie et des adresses, voire de quelques POI ou même des parcelles ce qui permet d'affiner les landuse). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 5 avril 2013 14:42, Pieren pier...@gmail.com a écrit : Quand je parle de serpent de mer, c'est au sein même de l'administration. Un peu de lecture s'impose: http://www.afigeo.asso.fr/documentation/category/12.html?download=463%3Aafigeo-gt-adresse-rapport-2011 Ouais enfin bon merci de ne me donner que 30 pages de lecture sur les serpents de mer dans l'administration, mais j'ai quelque mal à comprendre, à la lecture (rapide, excuse moi) de ce document, comment est-ce que l'on peut en conclure que l'adresse est un problème simple, quand bien même l'administration est mal foutue. ... et sur mon opinion que OSM est trop orienté administratif, qu'en penses-tu ? (sans me donner 30 pages de plus à lire). -- Les dérives de rue : Le papillon d’hiver (le film)http://drivrsdu.fr/le-papillon-dhiver-le-film/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 5 avril 2013 14:58, Tony Emery tony.em...@yahoo.fr a écrit : problème de la maintenance de cette base unique. Et, là encore, la commune est la source unique de l'information. C'est peut-être vrai pour les communes de taille raisonnable (disons au moins 1500 habitants), mais aujourd'hui plus aucune des plus petites communes rurales n'a les moyens ni la compétence de maintenir seule ces données. Et que pour des raisons pratiques évidentes, elles ont fait gérer leur SIG depuis longtemps par des tiers (peut-être au départ via des prestataires privés intervenant sur de nombreuses autres communes), mais aujourd'hui plus souvent par l'EPCI dont elles sont membres (même si l'EPCI peut ausssi faire appel à des prestataires externes, au moins l'EPCI dispose de son SIG et a un accès directe et on contrôle des données qui sont dedans). Il me semble que de plus en plus la source des infos et leur maintenance a été transférée aux EPCI qui disposent de plus de moyens (et de personnels) avec au passage des économies d'échelle en terme de coût. Et qu'en fin de compte il ne reste que les communes de taille suffisante, avec des budgets suffisants (en hausse constante), à encore gérer elles-mêmes leur propre SIG : ces communes seront de moins en moins nombreuses et même si elles conservent encore un SIG, une bonne partie de leur données seront toute de même transférées pour être gérées par l'EPCI (même si la commune fournit de temps en temps des données et y a un accès continu en cas de besoin). C'est à l'occasion de ces transferts vers l'EPCI que des travaux d'uniformisation sont entrepris, et qu'au passage les EPCI se concertent aussi entre eux pour évaluer les solutions choisies (les EPXI aussi veulent faire des économies d'échelle et n'ont probablement pas envie de développer des solutions totalement propriétaires incompatibles avec ce que font les autres). Au delà de ça, il y a aussi les SIG des départements et régions qui eux aussi proposent leurs solutions d'intégration. Certes il n'y a pas encore d'uniformisation au plan national (avec des agences partenaires au plan national comme l'Insee ou l'IGN, ou interrégionales comme les agences de bassin, parfois aussi des agences européennes ou des structures de coopération transfrontalières, notamment pour les transports, l'environnement et le développement touristique ou économique), mais on doit constater tout de même une convergence progressive entre les différents modèles de représentation des données entre les différents niveaux territoriaux jusqu'à l'Etat lui-même, même si certaines agences ont des besoins spécifiques supplémentaires qui sortent du cadre actuel des tentatives d'uniformisation/normalisation, faute d'avoir d'autres acteurs intéressés pour maintenir ces données spécifiques. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
2013/4/5 Ista Pouss ista...@gmail.com comment est-ce que l'on peut en conclure que l'adresse est un problème simple, quand bien même l'administration est mal foutue. Quand je parle de simple, c'est par rapport à la simplification administrative qui ferait qu'une seule autorité serait chargée de maintenir une base unique. Elle pourrait bien-sûr être abondée par les créateurs d'adresses (les communes) mais aussi pouvoir être corrigée et améliorée par les institutions utilisatrices (INSEE, DGFiP, police, la poste, etc). Seule la partie anonymisée serait publique et réutilisable. La partie nominative serait plus facilement entretenue si elle était couplée à une obligation légale de déclaration dominiliaire (se déclarer en mairie lors de l'installation) comme pratiquement partout ailleurs en Europe. ... et sur mon opinion que OSM est trop orienté administratif, qu'en penses-tu ? Je suis d'accord. Mes coups de gueule sur les références récurentes au code INSEE en témoignent. Ou les noms des cantons qui sont aussi les noms des villes et qu'on retrouve dans les résultas de recherche. Les contributeurs moyens d'OSM sont trop éloignés de ce vocabulaire. Il faut faire attention à ne pas se déconnecter du moteur du projet : le contributeur lambda. J'ai cru comprendre qu'au dernier SOTM-fr, il n'y en avait pratiquement aucun. C'est un danger qui gu (sans me donner 30 pages de plus à lire). J'ai bon ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 5 avr. 2013 à 17:36, Pieren a écrit : ... et sur mon opinion que OSM est trop orienté administratif, qu'en penses-tu ? Je suis d'accord. Mes coups de gueule sur les références récurentes au code INSEE en témoignent. Ou les noms des cantons qui sont aussi les noms des villes et qu'on retrouve dans les résultas de recherche. Les contributeurs moyens d'OSM sont trop éloignés de ce vocabulaire. Il faut faire attention à ne pas se déconnecter du moteur du projet : le contributeur lambda. J'ai cru comprendre qu'au dernier SOTM-fr, il n'y en avait pratiquement aucun. Je ne sais pas qui est trop orienté administratif, car, il me semble avoir parfois, contredit Pieren, sur des points marginaux qui tenaient à l'acceptation sans contrôle des données de l'administration, dont la réputation de cohérence et de logique est parfois usurpée. Tony faisait le distinguo entre collectivité publique autonome et administration de l'Etat. C'est sur l'anarchie admistrative français qu'il met le doigt : Les lois qui concernent l'environnement sont uniformes, malgré la diversité des climats et des écosystème, et, pourtant, t il semble admissible que les unités de base n'aient pas un minimum de référentiel commun pour des questions qui n'ont rien de politique, sinon, d'énormes efforts pour maintenir l'inertie et la désorganisation. Pour ce qui concerne, les références administratives, il est clair qu'il s'agit d'un débat qui ne concerne pas le supposé contributeur lambda. Il peut, éventuellement, être concerné par un alourdissement d ela BDD, mais, c'est tout. Ces références ou référentiels ne peuvent qu'être introduit que mécaniquement. Le lieu naturel pour trancher, sous la forme d'une recommandation qui deviendra vite une norme, est OSM- France, la liste étant un outil pour faire émerger les questions débroussailler les problèmes et indiquer les voies à suivre. J'ignore ce que Pieren désigne par contributeur lambda. Cela s'oppose à contributeur non-lambda. S'agit-il des codeurs, souvent appelés et inexactement geeks dans le langage courant? Il me semble que j'en ai rencontré quelques non-codeurs à SOTM-Fr, mais, moi qui ne code rien, j'étais content de discuter avec des gens qui me parlaient de codage, en termes généraux, bien sûr. Christian R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le ven. 05 avril 2013 à 11:34 +0200, Pieren a écrit : 2013/4/5 Tony Emery tony.em...@yahoo.fr Par conséquent, ces traçés, même si leur précision n'est pas bonne, est règlementée. Pour info, dans un document d'urbanisme approuvé, si le dessin d'une zone à été mal fait, qu'il coupe une parcelle alors qu'il ne le devrait pas, c'est quand même ce découpage qui est appliqué. Je pense donc, même si ce n'est pas juste, qu'il faut le laisser tel quel si l'on veut que les collectivités s'investissent dans OSM. Ce point est capital avec OSM. C'est la violation d'un principe de base du projet : les données doivent pouvoir être améliorées par les contributeurs, sinon elles n'ont pas leur place dans la base. Aucune donnée ne doit pouvoir être bloquée dans OSM sous prétexte d'officialité, encore plus si elles sont mauvaises. Je renverrais la lecture d'un fil de discussion de référence sur ce thème (en anglais) : http://lists.openstreetmap.org/pipermail/talk/2009-March/034948.html Je plussoie entièrement Pieren sur ce point. OSM ne doit pas devenir un dépôt où les institutions accepteraient de verser leurs données à condition que personne n'y touche. OSM c'est du crowdsourcing avant tout ; l'open data est un complèment, bienvenu mais pas essentiel. Il faut qu'on travaille au maximum pour intégrer l'open data dans OSM, mais si on tombe sur un conflit entre les deux, OSM laissera tomber l'open data et privilégiera toujours le crowdsourcing. Ce point est très important pour les discussions avec les collectivités, et il est non négociable, comme la licence. En un mot : aucune donnée ne doit être verrouillée dans OSM. -- ° /\Guillaume AllègreOpenStreetMap 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
Re: [OSM-talk-fr] expérimentations à Orange
Le jeu. 04 avril 2013 à 23:50 -0700, Tony Emery a écrit : 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. Pas la peine de partir dans les rêves de Grande Unification, je pense qu'on peut en déduire une chose : il faut que le schéma opendata utilisé accepte plusieurs identifiants provenant de plusieurs bases différentes. Donc, exit le ref:source=, et je ne vois pas d'autre solution que le ref:FR:idbase=id Je pense qu'on ne pourra pas se passer de l'identifiant DGFiP, puisque c'est déjà le référentiel pour les imports de cadastre (et qu'on peut espérer négocier une seule fois pour toute la France, et pas commune par commune). Bref, la DGFiP, c'est l'identifiant le plus utile à plus court terme. Ensuite, rien n'empêche d'ajouter un identifiant par commune participante. Et puis, dans dix ans, quand l'IGN aura vu la lumière (ou sera morte et enterrée) on pensera à mettre l'ID de la BDAdresse. -- ° /\Guillaume AllègreOpenStreetMap 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
Re: [OSM-talk-fr] expérimentations à Orange
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.08722lon=4.7789zoom=17layers=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ègreOpenStreetMap 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
Re: [OSM-talk-fr] expérimentations à Orange
- Mail original - De: kimaidou kimai...@gmail.com 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 Bonjour, Pour ce qui est d ecouter les diffs SODA fournit une infrastructure. La verification par rapport aux liens et les actions a prendre pourraient etre faites dans un plugin dedie Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Ce problème de multiplication des liens partant d'OSM vers des données externes vient en fait de l'incapacité actuelle à faire des liens pérennes pointant VERS OSM. Les ID des objets peuvent changer, les objets peuvent être découpés (par exemple une route sera tronçonnée pour l'enrichir en détails). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 01/04/2013 20:08, kimaidou a écrit : [...] +1 Je crois que c'est en effet une telle base de données externe, à l'écoute des minutes diff qui permet à la fois : * l'enregistrement de métadonnées tierces * le monitoring par un tiers de données synchrones, problème soulevé voici quelques temps déjà : identification, acceptation de modification... Il me semble que la structure de cette basse de données doit être relativement simple à concevoir. La difficulté est plus, il me semble, sur la gestion de flux, particulièrement à la création de données ou à la synchronisation de données existantes. Comment faire savoir à cette base ( va pour OSMLink, ou OSMSync ) que les nouveaux objets importés sont liés à un SIG externe et qu'elle doit enregistrer et éliminer les métadonnées avant l'intégration dans OSM ? On a peut-être déjà des éléments avec l'instance fr de l'API qui agit comme interface, il me semble. Je n'ai pas tout compris de la mécanique de Etherpad, mais il semble qu'il y ait des choses puissantes pour suivre les trois états des modifications, côté client : version utilisateur - version réseau, côté serveur : version réseau - version db. Comment, aussi, rendre ce flux compatible avec l'API officielle ? Genre : J'édite un objet sous Potlatch, ou autre éditeur, et j'ajoute le tag qui va bien pour dire que cet objet est lié à l'objet ID:* du SIG machin. Sous JOSM, c'est facile (pour certains, pas pour moi !) de faire le plugin permettant de gérer cette extension d'OSM et de se connecter au serveur de synchronisation. Je suggérai de préfixer ces tags de métadonnées par @. Ce type de convention m’apparaît d'autant plus précieux pour suivre un flux qui ne passerait pas par le serveur Sync. Le serveur le repérerait de toute façon par les minutes diff. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 2 avril 2013 09:42, Christian Quest cqu...@openstreetmap.fr a écrit : Ce problème de multiplication des liens partant d'OSM vers des données externes vient en fait de l'incapacité actuelle à faire des liens pérennes pointant VERS OSM. Les ID des objets peuvent changer, les objets peuvent être découpés (par exemple une route sera tronçonnée pour l'enrichir en détails). Autant que je puisse comprendre les choses, d'un point de vue géographique, ce n'est peut être pas très grave : il n'est pas sûr qu'il y ait quelque chose, en géographie, ou du moins ce quelque chose n'apparait que du point de vue d'une vision. Informatiquement parlant, on le définit à partir de notions d'équivalence, ou d'identité, ou de similarités, enfin des choses dans le genre. (en java, voir guava et leurs idées de hash ou de equivalence). Par contre, d'un point de vue base de données (puisqu'on raconte qu'osm est une base de données), c'est assez étrange :-) Ce qui me parait plus génant est, semble-t-il, l'absence de possibilités de synchronisation, telle qu'en parle Vincent Pottier dans son message. On peut aussi voir les choses sous la forme d'écoute ; j'ai rien vu de pareil sur les apis d'osm, et c'est surtout ça qui est génant, ou dont il faudrait discuter si je comprends pas. Cordialement. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Les id d'objets OSM peuvent changer en effet mais une chose est stable : la géolocalisation. Si nécessaire on pourrrait utiliser dans la base OSM des relations collections contenant un ID stable dans cette collection (sous forme de rôle de type id:* dans la liste de ses membres). Ce qui permettrait de stabiliser dans OSM ces relations elles-mêmes ayant un ID d'objet OSM stable, et en croisant avec l'id stable présent dans le rôle pour trouver l'objet référencé qui peut changer. Ces relations destinées à des applications externes pourraient avoir un type particulier type=collection, et même être stockées dans un espace de nommage propre à cette application externe utilisatrice, en la liant à un compte utilisateur ou un compte d'application enregistré. Ces collections pourraient s'autoorganiser entre elles. Mais en général la plupart des applications utilisent pour se lier à OSM la géolocalisation (coordonnées et niveau de zoom) et une recherche, souvent par nom (via Nominatim par exemple) s'il faut être plus précis. C'est ce que fait Wikipédia et d'une façon générale la plupart des utilisateurs. Google Maps lui non plus ne fournit pas d'ID stable mais permet de positionner des couches métiers par dessus la couche Google, sans avoir besoin de se lier directement à elle. Le but est donc moins de permettre à ses applications tierces de retrouver où se situent dans la base les objets OSM, que d'indiquer plutôt aux utilisateurs OSM comment trouver ces applications et données tierces pouvant servir de référence ou d'enrichir et mettre à jour les données OSM et de les vérifier. Afin d'avoir une idée de la pertinence et l'exactitude des données OSM. C'est alors plus précis que la seule mention de la source qui est souvent très vague, et c'est le rôle donné aux tags ref:*=*. Je reste persuadé qu'il n'y aura jamais beaucoup de ref:* pour chaque objet OSM et que la plupart du temps il n'y en aura tout au plus qu'un seul, le plus commun utilisé non seulement dans OSM mais par plein d'autres applications qui utilisent la même source d'informations (exemple : les réf. INSEE, ISO, Eurostat, les numéros de référence régionaux, nationaux ou européens des réseaux de transport). Et qu'aller vers un renforcement de la règle de nommage des tags ref:* suffira. Le 2 avril 2013 09:42, Christian Quest cqu...@openstreetmap.fr a écrit : Ce problème de multiplication des liens partant d'OSM vers des données externes vient en fait de l'incapacité actuelle à faire des liens pérennes pointant VERS OSM. Les ID des objets peuvent changer, les objets peuvent être découpés (par exemple une route sera tronçonnée pour l'enrichir en détails). ___ 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
Re: [OSM-talk-fr] expérimentations à Orange
Le lun. 01 avril 2013 à 20:08 +0200, kimaidou a écrit : Bonjour à tous On en avait déjà parlé avec Tony dès ses premières expérimentations. Pour tous ces cas là, je préférerais largement qu'une base de données externe s'occupe de gérer les liens entre identifiants. J'imagine un outil, qu'on pourrait appeler OsmLink (ou mieux), qui centraliserait l'ensemble de tous les liens entre identifiants, avec un schéma assez classique en base de donnée : Objet OSM (osm_id) --- OsmLink (osm_id, osm_type, id_table_externe, id_objet_externe ) - Table externe ( id_objet_externe) L'idée est de stocker le lien entre identifiants dans la table de lien, et ni dans OSM ni dans notre table métier. Ainsi on ne pollue ni notre table métier, ni notre table de lien, et cela permet OK pour cette idée d'une base tierce, mais dans ta description je ne comprends pas qui l'héberge. Pour moi, c'est forcément du côté du SIG, puisque la base tierce doit connaître à la fois les références SIG et les références OSM. Or OSM est publique, et le SIG métier est privé. Du coup je ne comprends pas : * de gérer autant de tables externes que souhaité : la base de donnée OsmLink serait alors un immense creuset de lien, qui serait administrée (et pourquoi pas versionnée aussi) comme la bdd OSM, avec une union des forces En tous cas, c'est une idée intéressante, et il va bien falloir aboutir à une solution si on veut accepter proprement les données OpenData qu'on nous propose. -- ° /\Guillaume AllègreOpenStreetMap 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
Re: [OSM-talk-fr] expérimentations à Orange
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.08722lon=4.7789zoom=17layers=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ègreOpenStreetMap 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
Re: [OSM-talk-fr] expérimentations à Orange
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 ? Non pas de moi. Je dirais plutôt l'inverse : que les bureaux de vote ne peuvent pas s'étendre sur plusieurs communes et devraient couvrir tout le territoire de de la commune, sans recouvrement ente eux, et sans laisser aucune frange même ces franges sont inhabitées. Les bureaux de vote sont établis sur la base des points d'adresses des électeurs inscrits (que la commune géolocalise par le point d'accès à cette adresse depuis la voirie publique indiquée dans l'adresse), ce qui compte c'est juste l'adresse enregistrée, même si leur propriété privée (éventuellement sur plusieurs parcelles disjointes) peut être couverte par plusieurs bureaux de vote : au niveau du droit électoral cela ne change rien, les étendues des propriétés privées (ou louées) ne sont pas prises en compte. En conséquence il n'est pas nécessaire d'avoir une granularité territotriale très précise et en pratique les bureaux de vote sont découpés sur les axes de rues ou entre les îlots habités, et la plupart du temps ces limites de bureaux de vote réutiliseront donc des tracés déjà existants d'objets réels (les rues) et administratives (frontières communales ou d'arrondissement de commune), mais pas toujours les frontières de quartiers au sens de l'aménagement ou de certains services publics communaux, communautaires ou d'autres collectivités territoriales ou de l'Etat (tels que l'assainissement, la collecte des ordures, la carte scolaire, les services sociaux, les commissariats de police ou gendarmeries, les espaces verts, les plans de protection de l'urbanisme, les zones de prévention des risques, etc...), mais ces tracés dans certains cas pourront tracer un grand segment tout droit coupant un parc en deux (sans autre détail concernant les limites exactes de parcelles). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Bonjour à tous On en avait déjà parlé avec Tony dès ses premières expérimentations. Pour tous ces cas là, je préférerais largement qu'une base de données externe s'occupe de gérer les liens entre identifiants. J'imagine un outil, qu'on pourrait appeler OsmLink (ou mieux), qui centraliserait l'ensemble de tous les liens entre identifiants, avec un schéma assez classique en base de donnée : Objet OSM (osm_id) --- OsmLink (osm_id, osm_type, id_table_externe, id_objet_externe ) - Table externe ( id_objet_externe) L'idée est de stocker le lien entre identifiants dans la table de lien, et ni dans OSM ni dans notre table métier. Ainsi on ne pollue ni notre table métier, ni notre table de lien, et cela permet * de gérer autant de liens qu'on veut. * de gérer les problèmes levés par Tony : on peut lier plusieurs osm_id à un objet métier et non faire comme fait actuellement Je prends l'osm_id le plus petit de la route * de gérer autant de tables externes que souhaité : la base de donnée OsmLink serait alors un immense creuset de lien, qui serait administrée (et pourquoi pas versionnée aussi) comme la bdd OSM, avec une union des forces Bien sûr il faut créer/inventer/adapter des outils pour répondre aux questions du type Que se passe-t-il si on supprime un objet d'OSM ?, Comment créer le lien, etc.. Mais je pense qu'avec ce système, c'est beaucoup plus simple de lister les liens qui sont orphelins d'un côté ou de l'autre, et de créer ou adapter des applications (OsmWatch, etc.) Bref, c'est un projet pas trop compliqué au niveau technique, il suffit de se poser les bonnes questions et de mettre un premier prototype sur Github. Je vois bien une interface graphique comme OsmFlickr, avec une carte, pour créer facilement le lien entre mon tableau métier et des objets OSM. Ce projet me tient à coeur depuis qu'on en a parlé avec Tony, mais je n'ai toujours pas trouvé le temps ou les moyens de m'y mettre... Michael ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
N'est-ce pas la même chose que les tags ref:*=* actuels ? Sauf qu'il suffirait de définiir une convention de nommage plus strict pour ces ref:*=* (et éviter l'utilisation d'autres tags ne commençant pas par ref: tels que les CLC_ID).. Même dans une table séparée (ou une base séparée, ce qui ne change pas grand chose topologiquement parlant, sauf que l'intégrité référentielle n'est plus assurée entre les identifiants OSM et la base séparée), on n'évitera pas une convention de nommage identique pour les clés (à ceci près qu'il n'y a plus besoin alors de mettre le préfixe ref: dans le nom de la clé : le problème est donc identique. Si on utilise une table séparée de celle des tags, il faut alors modifier le schéma XML des objets : c'est vaile pour les ways et relations, mais cela va surcharger beaucoup pour référencer les noeuds. L'intérêt toutefois serait de pouvoir télécharger les données OSM sans avoir besoin de charger toutes les ref:* externes en tant que tags. Cela peut se faire par un filtre de téléchargement précisant les types de clés ref:* qu'on veut voir ou mettre à jour. Mais je ne suis pas convaincu que cela apporte beaucoup de choses. Plus utile toutefois serait de pouvoir ajuoter des métadonnées suppélementaires pour certaines applications. Mais là encore c'est soluble par une convention de classification entre les tags pouvant être supporté par une convention de nommage des préfixes de clés. Mais c'est là que cela devient intéressant : les préfixes à force de se cumuler partout vont s'allonger et il faut les répéter pour tous les tags de l'application métier, là où il suffirait d'avoir un seul objet regroupant divers attributs et ayant leur propre id pour les regrouper, et les référencer depuis un objet géographique. Mais là on parle alors de développer une véritable topologie de types d'objets avec des classes et sous-classes, les objets étant alors un peu similaires aux objets javascript dans leur extensibilité et leur flexibilité (mais avec sans doute un contrôle de typage plus strict : qui voudra développer un système permettant de décrire un schéma d'objets typés sous forme de hiérarchie de classes et sous-classes et avec un contrôle des valeurs autorisées ou obligatoirement renseignées ? Et pourra-t-on créer un même objet qui référencera d'autres objets (pas seulement le sous-classement hoérarchique des types, mais aussi l'inclusion, les listes ordonnées ou ensembles non ordonnés, bornés en taille ou pas ??? Est-ce qu'on ne s'éloigne pas trop d'une base géographique ? Il me semble plus urgent de renforcer les conventions de nommage des clés de tags et leur documentation pour les listes de valeurs permises, et les outils automatiques pour des contrôles et des corrections plus aisées et plus rapides. Si le problème est la multiplication du nombre de tags par objet OSM, des filtres pour le téléchargement pourraient être développés pour éviter d'avoir à tous les charger. Cela peut se faire en ajoutant dans la base une table de description et de classification des clés de tags sous forme de collections de clés organisées de façon hiérarchique : on télécharge alors les clés d'une collection donnée, plus celles de la collection par défaut (pour compatibiité avec les clés existantes qui ne sont pas encore décrites dans une collection). Le 1 avril 2013 20:08, kimaidou kimai...@gmail.com a écrit : Bonjour à tous On en avait déjà parlé avec Tony dès ses premières expérimentations. Pour tous ces cas là, je préférerais largement qu'une base de données externe s'occupe de gérer les liens entre identifiants. J'imagine un outil, qu'on pourrait appeler OsmLink (ou mieux), qui centraliserait l'ensemble de tous les liens entre identifiants, avec un schéma assez classique en base de donnée : Objet OSM (osm_id) --- OsmLink (osm_id, osm_type, id_table_externe, id_objet_externe ) - Table externe ( id_objet_externe) L'idée est de stocker le lien entre identifiants dans la table de lien, et ni dans OSM ni dans notre table métier. Ainsi on ne pollue ni notre table métier, ni notre table de lien, et cela permet * de gérer autant de liens qu'on veut. * de gérer les problèmes levés par Tony : on peut lier plusieurs osm_id à un objet métier et non faire comme fait actuellement Je prends l'osm_id le plus petit de la route * de gérer autant de tables externes que souhaité : la base de donnée OsmLink serait alors un immense creuset de lien, qui serait administrée (et pourquoi pas versionnée aussi) comme la bdd OSM, avec une union des forces Bien sûr il faut créer/inventer/adapter des outils pour répondre aux questions du type Que se passe-t-il si on supprime un objet d'OSM ?, Comment créer le lien, etc.. Mais je pense qu'avec ce système, c'est beaucoup plus simple de lister les liens qui sont orphelins d'un côté ou de l'autre, et de créer ou adapter des applications (OsmWatch, etc.) Bref, c'est un projet pas trop compliqué au niveau technique, il suffit de se poser les
Re: [OSM-talk-fr] expérimentations à Orange
2013/3/30 Vincent de Chateau-Thierry v...@laposte.net Avec le schéma ref:FR:code insee commune on pourrait se retrouver avec autant de clés que de communes, toutes signifiant grosso-modo la même chose : cette clé a pour valeur une référence interne à la commune XXX. +1 Et quitte à me répéter, le code insee d'une commune est inconnu de la plupart des gens, et donc des contributeurs moyens. OSM ne doit pas devenir une affaire de spécialistes. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 30/03/2013 21:45, Vincent de Chateau-Thierry a écrit : Ensuite : ref:orange : là, je pense qu'on a un problème à régler. orange n'est pas suffisamment distinctif. Si toutes les communes du monde se mettent à utiliser le même schéma, on va multiplier les conflits. Comment régler ça ? Pour éviter d'avoir 36.000 tags ref:* distincts à terme (on peut rêver), je verrais plutôt un schéma générique sur 2 tags : source=* (rien de nouveau ici) ref:source=* ou source:internal_id ou toute autre formulation pour dire la même chose : mentionner l'identifiant unique utilisé par le fournisseur. Dans l'exemple du way : source=Mairie d'Orange 2012 ref:source=84087V99 Après tout, il ne s'agit pas d'un tag ref pour l'objet, que tout un chacun pourrait trouver sur le terrain, mais d'un tag ref qui n'existe que parce qu'une certaine source a été utilisée pour l'objet. vincent J'ajoute mon grain de sel... Si le tag n'est pas une référence, une clef externe, comme ref:INSEE, ref:sandre, mais une métadonnée, il me semble qu'il serait bon de le suggérer d'une façon ou d'une autre. Il me vient une idée : préfixer les métadonnées par un caractère spécifique. J'avais pensé dans un premier temps à un underscore. Mais l'usage répandu en informatique est que les variables commençant par underscore sont des membres privés d'objet, ce qui voudrait dire, dans OSM, des tags internes à OSM. Or, c'est l'inverse dans le cas présent. On veut créer une métadonnée pour une valeur externe à OSM. On peut utiliser l'arobase ? La clef serait alors @ref:* Voire même pas de mention de ref mais quelque chose du genre @INSEE:id (INSEE étant à remplacer par ce qui semblera le plus pertinent dans le reste de la discussion) Ça va faire étrange au début ! Mais si la convention s'installe, ça deviendra plus familier de voir des tags @*. Et ça permettra de repérer rapidement dans/par les éditeurs si c'est une info pertinente à éditer, modifier. Ça permettrait de repérer rapidement dans les outils d'imports d'éliminer ce genre de métadonnées avec une expression régulière ultra simple. Par ailleurs, mettre une telle info sur un objet ne simplifie pas pour autant la synchro OSM - SIG. En effet, l'absence d'objet portant l'identifiant SIG ne signifie pas pour autant que l'objet a été supprimé. L'objet peut avoir été seulement altéré sur la clef. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le dim. 31 mars 2013 à 13:16 +0200, Pieren a écrit : 2013/3/30 Vincent de Chateau-Thierry v...@laposte.net Avec le schéma ref:FR:code insee commune on pourrait se retrouver avec autant de clés que de communes, toutes signifiant grosso-modo la même chose : cette clé a pour valeur une référence interne à la commune XXX. +1 Et quitte à me répéter, le code insee d'une commune est inconnu de la plupart des gens, et donc des contributeurs moyens. OSM ne doit pas devenir une affaire de spécialistes. Je suis d'accord avec ta dernière phrase, mais ce n'est pas un argument ici. Mettre un attribut destiné à la synchro OSM-SIG est bien une affaire de spécialiste. Ça ne veut pas du tout dire que des contributeurs lambda ne pourront pas modifier l'objet, simplement, ils ne toucheront pas ce tag là. C'est tout-à-fait admissible d'avoir des attributs génériques compréhensibles de tout le monde et des attributs spécialisés sur le même objet. Et d'ailleurs c'est déjà la pratique courante : tout le monde peut ajouter un noeud natural=tree, mais il n'y a que les spécialistes qui pourront préciser le taxon=... -- ° /\Guillaume AllègreOpenStreetMap 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
Re: [OSM-talk-fr] expérimentations à Orange
Le sam. 30 mars 2013 à 23:46 +0100, Christian Quest a écrit : Si on se reposait les questions de base ? Yep. A quoi servent ces ref:xxx ? Si il s'agit de maintenir un lien avec un jeu de données externes bien précis et d'une façon unique, il faut que la clé permettent d'identifier le jeu de données sans ambiguité et donc il faut qu'elle soit unique pour chaque jeu de données et un quelque chose du genre ref:insee:x me semble adapté. Ca donne en plus un lien vers le producteur de ce jeu de données x pouvant décrire une région, un département, un EPCI, une commune, voire même une entreprise par son SIREN/SIRET. Si par contre ces références ont un caractère plus global et qu'elles sont utilisables sans être liées à un jeu de données particulier, alors là il faut utiliser une clé qui elle aussi ne soit pas liée à un jeu de données. Si on veut identifier une référence qui serait par exemple donnée de façon homogène par un niveau administratif particulier, on pourrait envisager un ref:admin_level:xx=* Faut demander à Tony ce qu'il pense en faire à long terme, mais il me semble qu'on est clairement dans le 1er cas, là : maintenir un lien avec un jeu de données externes bien précis et d'une façon unique. Vous allez voir qu'on va y arriver aux linked data ;) On peut même dire qu'on y est là, mais ça ne nous donne pas magiquement la réponse à comment les intégrer au mieux dans le taggins OSM ? -- ° /\Guillaume AllègreOpenStreetMap 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
Re: [OSM-talk-fr] expérimentations à Orange
Le code INSEE des communes est pourtant une brique de base en France, et est largement documenté... surtout il n'est pas du tout inconnu de ceux qui justement vont chercher à faire des liaisons avec les bases SIG externes (d'une ou plusieurs communes des données mais avec des définitions géographiques différentes à cause de différence de précision par exemple ou de non conflation de leur données pour ce qui devrait être une seule et même entité dans OSM). Hors si dans OSM on fait une conflation, impossible de retrouver à quoi cela correspondait dans les SIG externes. Il est très courant que les SIG pour divers services ne contiennent pas la totalité des définitions géodésiques précises (notamment pour les applications de type environnemental, comme la gestion des zones de rammasage scolaire, la collecte des ordures ménagères, les zones de protection d'espaces naturels ou de biotopes..., qui ne sont pas à 10 mètre près ni même souvent à 100 mètres près, comme peut l'être le cadastre pour la gestion foncière et fiscale ou les plans d'urbanisme ou d'équipement urbain). Le 31 mars 2013 13:16, Pieren pier...@gmail.com a écrit : 2013/3/30 Vincent de Chateau-Thierry v...@laposte.net Avec le schéma ref:FR:code insee commune on pourrait se retrouver avec autant de clés que de communes, toutes signifiant grosso-modo la même chose : cette clé a pour valeur une référence interne à la commune XXX. +1 Et quitte à me répéter, le code insee d'une commune est inconnu de la plupart des gens, et donc des contributeurs moyens. OSM ne doit pas devenir une affaire de spécialistes. Alors non je ne suis pas d'accord avec ton argument. Le but des ref est justement de fournir des identifiants non ambigus à des bases externes de référence (uniquement pour certaines données mais pas toutes) qui ont chacune leur propres identifiants pas toujours unifiés entre eux, le but de leur codification propre n'ayant pas souvent à prendre en compte tous les détails d'une autre base externe servant à gérer tout autre chose. Dès lors qu'une ref externe n'est pas unique entre les bases, on se doit de les qualifier pour qu'elles ne soient pas ambigues (en France, seules les codification du COG sont unifiées par l'INSEE pour les collectivités territoriales, pour le zonage urbain, et les statiqtiques réglementaires, mais les SIG gèrent des tas d'autres zonages non réglementés, au bon vouloir de chaque organisme et pas unifiés au plan national). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Bonsoir, Le 30/03/2013 20:37, 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. oui, fusionner la portion commune 3) La relation 2649371 a des attributs bizarres : - pas de nom - un CANTON=Ouest pas documenté - un ref=22 pas documenté non plus S'agissant de l'extension géographique d'un bureau de vote, on peut concevoir qu'il n'ait pas de nom mais juste un n° (le tag ref). 4) la route http://www.openstreetmap.org/browse/way/195747326 a les attributs : highway = road addr:postcode = |84100 ref:orange = 84087V99 En dehors de la typo sur le code postal avec le |, est-ce logique de mettre un code postal sur une voie ? le wiki ne donne qu'un noeud ou une surface, et j'aurais tendance à le suivre sur ce point. Pas sûr que ce soit une typo, ça peut être la moitié d'une modélisation sur un seul champ (dans un SIG) : code_postal à gauche | code postal à droite Pas forcément heureux là où nous sommes plus habitués à des suffixes :left et :right, et donc à deux attributs au lieu d'un. Mais la modélisation directement sur les ways est banale, quasi conventionnelle, chez les fournisseurs de BD de géocodage (IGN, TomTom co). Elle n'est pas documentée dans OSM, soit. Ça ne la rend pas invalide pour autant, et rien qu'en France, dans les quelques communes a CP multiples, ça se conçoit. Ensuite : ref:orange : là, je pense qu'on a un problème à régler. orange n'est pas suffisamment distinctif. Si toutes les communes du monde se mettent à utiliser le même schéma, on va multiplier les conflits. Comment régler ça ? Pour éviter d'avoir 36.000 tags ref:* distincts à terme (on peut rêver), je verrais plutôt un schéma générique sur 2 tags : source=* (rien de nouveau ici) ref:source=* ou source:internal_id ou toute autre formulation pour dire la même chose : mentionner l'identifiant unique utilisé par le fournisseur. Dans l'exemple du way : source=Mairie d'Orange 2012 ref:source=84087V99 Après tout, il ne s'agit pas d'un tag ref pour l'objet, que tout un chacun pourrait trouver sur le terrain, mais d'un tag ref qui n'existe que parce qu'une certaine source a été utilisée pour l'objet. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 30 mars 2013 20:37, Guillaume Allegre allegre.guilla...@free.fr a écrit : 3) La relation 2649371 a des attributs bizarres : - pas de nom - un CANTON=Ouest pas documenté - un ref=22 pas documenté non plus En effet, on a un schéma déja existant et homogène utilisant le code Insee complet du canton à 4 chiffres dans ref:INSEE=*. avec boundary=political, political_division=canton, name=Orange-Ouest, wikipedia=fr:Canton d'Orange-Ouest 4) la route http://www.openstreetmap.org/browse/way/195747326 a les attributs : highway = road addr:postcode = |84100 ref:orange = 84087V99 En dehors de la typo sur le code postal avec le |, est-ce logique de mettre un code postal sur une voie ? le wiki ne donne qu'un noeud ou une surface, et j'aurais tendance à le suivre sur ce point. Ensuite : ref:orange : là, je pense qu'on a un problème à régler. orange n'est pas suffisamment distinctif. Si toutes les communes du monde se mettent à utiliser le même schéma, on va multiplier les conflits. Comment régler ça ? Pour les références relatives à Orange, ou semble-t-il plutôt son EPCI, il serait plus utile d'indiquer ref:FR:EPCI=* (avec une abréviation de l'EPCI) ou ref:FR:code insee de la commune=* (si cela vient de la commune elle-même). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le sam. 30 mars 2013 à 21:58 +0100, Philippe Verdy a écrit : Le 30 mars 2013 20:37, Guillaume Allegre allegre.guilla...@free.fr a écrit : 3) La relation 2649371 a des attributs bizarres : - pas de nom - un CANTON=Ouest pas documenté - un ref=22 pas documenté non plus En effet, on a un schéma déja existant et homogène utilisant le code Insee complet du canton à 4 chiffres dans ref:INSEE=*. avec boundary=political, political_division=canton, name=Orange-Ouest, wikipedia=fr:Canton d'Orange-Ouest Je reconnais que mon exemple était ambigu, mais la relation n'est pas un canton, mais la limite d'un bureau de vote (numéro 22), qui appartient au Canton Ouest. La question subsidiaire : vaut-il mieux avoir un nom Limite du bureau de vote n°22 (complètement redondant) ou rien ? 4) la route http://www.openstreetmap.org/browse/way/195747326 a les attributs : highway = road addr:postcode = |84100 ref:orange = 84087V99 En dehors de la typo sur le code postal avec le |, est-ce logique de mettre un code postal sur une voie ? le wiki ne donne qu'un noeud ou une surface, et j'aurais tendance à le suivre sur ce point. Ensuite : ref:orange : là, je pense qu'on a un problème à régler. orange n'est pas suffisamment distinctif. Si toutes les communes du monde se mettent à utiliser le même schéma, on va multiplier les conflits. Comment régler ça ? Pour les références relatives à Orange, ou semble-t-il plutôt son EPCI, il serait plus utile d'indiquer ref:FR:EPCI=* (avec une abréviation de l'EPCI) ou ref:FR:code insee de la commune=* (si cela vient de la commune elle-même). Non, c'est bien la commune seule. Orange ne fait à ma connaissance toujours partie d'aucune intercommunalité, principalement en raison du bord politique du maire (ex-FN) depuis 1995. Le ref:FR:code insee de la commune= * paraît rationnel, mais un peu aride. Cela dit, pour un ref, ça peut passer. -- ° /\Guillaume AllègreOpenStreetMap 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
Re: [OSM-talk-fr] expérimentations à Orange
Le sam. 30 mars 2013 à 21:45 +0100, Vincent de Chateau-Thierry a écrit : 4) la route http://www.openstreetmap.org/browse/way/195747326 a les attributs : highway = road addr:postcode = |84100 ref:orange = 84087V99 En dehors de la typo sur le code postal avec le |, est-ce logique de mettre un code postal sur une voie ? le wiki ne donne qu'un noeud ou une surface, et j'aurais tendance à le suivre sur ce point. Pas sûr que ce soit une typo, ça peut être la moitié d'une modélisation sur un seul champ (dans un SIG) : code_postal à gauche | code postal à droite Pas forcément heureux là où nous sommes plus habitués à des suffixes :left et :right, et donc à deux attributs au lieu d'un. OK, merci, je n'y avais pas pensé. C'est vrai que le bout de route traverse la frontière Caderousse/Orange, qui est aussi une limite de code postal (84860/84100) mais elle ne la suit pas. Donc je ne sais pas si ton interprétation est la bonne. Mais la modélisation directement sur les ways est banale, quasi conventionnelle, chez les fournisseurs de BD de géocodage (IGN, TomTom co). Elle n'est pas documentée dans OSM, soit. Ça ne la rend pas invalide pour autant, et rien qu'en France, dans les quelques communes a CP multiples, ça se conçoit. OK ; ça fait sens. Mais dans ce cas, il faudrait que ce soit renseigné sur le wiki, avec les variantes :left et :right. Ensuite : ref:orange : là, je pense qu'on a un problème à régler. orange n'est pas suffisamment distinctif. Si toutes les communes du monde se mettent à utiliser le même schéma, on va multiplier les conflits. Comment régler ça ? Pour éviter d'avoir 36.000 tags ref:* distincts à terme (on peut rêver), je verrais plutôt un schéma générique sur 2 tags : source=* (rien de nouveau ici) ref:source=* ou source:internal_id ou toute autre formulation pour dire la même chose : mentionner l'identifiant unique utilisé par le fournisseur. Dans l'exemple du way : source=Mairie d'Orange 2012 ref:source=84087V99 Après tout, il ne s'agit pas d'un tag ref pour l'objet, que tout un chacun pourrait trouver sur le terrain, mais d'un tag ref qui n'existe que parce qu'une certaine source a été utilisée pour l'objet. Oui, mais cette façon de faire limite les possibilités d'édition ultérieures : - un objet pourrait avoir plusieurs ref (par exemple un ref:insee et un ref:FR:code-commune) - un objet peut avoir plusieurs sources : un SIG territorial à l'origine, puis une retouche par Bing ou par le cadastre et le source=Mairie d'Orange irait mieux sur le changeset Du coup, ref:source me semble trop fragile. Je pense que ref:FR:code insee commune comme proposé par Philippe Verdy est le plus sûr. -- ° /\Guillaume AllègreOpenStreetMap 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
Re: [OSM-talk-fr] expérimentations à Orange
Le 30/03/2013 22:35, Guillaume Allegre a écrit : Le sam. 30 mars 2013 à 21:45 +0100, Vincent de Chateau-Thierry a écrit : Ensuite : ref:orange : là, je pense qu'on a un problème à régler. orange n'est pas suffisamment distinctif. Si toutes les communes du monde se mettent à utiliser le même schéma, on va multiplier les conflits. Comment régler ça ? Pour éviter d'avoir 36.000 tags ref:* distincts à terme (on peut rêver), je verrais plutôt un schéma générique sur 2 tags : source=* (rien de nouveau ici) ref:source=* ou source:internal_id ou toute autre formulation pour dire la même chose : mentionner l'identifiant unique utilisé par le fournisseur. Dans l'exemple du way : source=Mairie d'Orange 2012 ref:source=84087V99 Après tout, il ne s'agit pas d'un tag ref pour l'objet, que tout un chacun pourrait trouver sur le terrain, mais d'un tag ref qui n'existe que parce qu'une certaine source a été utilisée pour l'objet. Oui, mais cette façon de faire limite les possibilités d'édition ultérieures : - un objet pourrait avoir plusieurs ref (par exemple un ref:insee et un ref:FR:code-commune) - un objet peut avoir plusieurs sources : un SIG territorial à l'origine, puis une retouche par Bing ou par le cadastre et le source=Mairie d'Orange irait mieux sur le changeset Du coup, ref:source me semble trop fragile. Je pense que ref:FR:code insee commune comme proposé par Philippe Verdy est le plus sûr. Avec le schéma ref:FR:code insee commune on pourrait se retrouver avec autant de clés que de communes, toutes signifiant grosso-modo la même chose : cette clé a pour valeur une référence interne à la commune XXX. À l'extrême, 36.000 communes, 36.000 clés ? Je sais bien qu'on n'en arrivera pas là, je pousse juste la logique au bout. Et côté modélisation, autant de clés distinctes qui disent toutes la même chose, je trouve que ça fait beaucoup. Et dans ce scenario catastrophe, imagine le schéma de réutilisation, dans un modèle mis à plat comme le schéma standard d'osm2pgsql : 36.000 colonnes rien que pour la source... Et c'est aussi, à sa manière, fragile. Quid de plusieurs sources issues de la même ville (on a facilement le cas sur les grandes villes) : la source des espaces verts, celle de la voirie, etc. Pour peu que les plages de valeurs se recoupent, le tag ref:FR:insee n'a plus de valeurs uniques dans la même ville, le bénéfice de tracer la source est perdu. Ma proposition sur 2 tags a pour objectif, au moins, d'éviter la multiplicité des clés signifiant toutes la même chose. Je suis d'accord sur le fait que ça ne gère pas le multi-sources. Mais en même temps, est-ce que sur ces objets on n'est pas, quasi par principe, face à du mono-source ? Des objets issus d'un SIG communal, tracés comme tels, sont potentiellement maintenus côté OSM grâce au lien avec la base source, justement. Et si besoin, rien n'empêche d'aller un cran plus fin dans le détail, en sourçant chaque clé plutôt que l'objet dans sa globalité. On a déjà des paquets de source:addr:postcode et des source:ref:INSEE, sur le même principe. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Si on se reposait les questions de base ? A quoi servent ces ref:xxx ? Si il s'agit de maintenir un lien avec un jeu de données externes bien précis et d'une façon unique, il faut que la clé permettent d'identifier le jeu de données sans ambiguité et donc il faut qu'elle soit unique pour chaque jeu de données et un quelque chose du genre ref:insee:x me semble adapté. Ca donne en plus un lien vers le producteur de ce jeu de données x pouvant décrire une région, un département, un EPCI, une commune, voire même une entreprise par son SIREN/SIRET. Si par contre ces références ont un caractère plus global et qu'elles sont utilisables sans être liées à un jeu de données particulier, alors là il faut utiliser une clé qui elle aussi ne soit pas liée à un jeu de données. Si on veut identifier une référence qui serait par exemple donnée de façon homogène par un niveau administratif particulier, on pourrait envisager un ref:admin_level:xx=* Vous allez voir qu'on va y arriver aux linked data ;) -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/shttp://openstreetmap.fr/sotmfr2013ynthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 30 mars 2013 22:26, Guillaume Allegre allegre.guilla...@free.fr a écrit : Le sam. 30 mars 2013 à 21:58 +0100, Philippe Verdy a écrit : Le 30 mars 2013 20:37, Guillaume Allegre allegre.guilla...@free.fr a écrit : 3) La relation 2649371 a des attributs bizarres : - pas de nom - un CANTON=Ouest pas documenté - un ref=22 pas documenté non plus En effet, on a un schéma déja existant et homogène utilisant le code Insee complet du canton à 4 chiffres dans ref:INSEE=*. avec boundary=political, political_division=canton, name=Orange-Ouest, wikipedia=fr:Canton d'Orange-Ouest Je reconnais que mon exemple était ambigu, mais la relation n'est pas un canton, mais la limite d'un bureau de vote (numéro 22), qui appartient au Canton Ouest. Oui mais le nom donné semble indique que le bureau 22 correspond en fait à la même chose que la fraction du canton sur le territoire de la commune. Hors un bureau de vote est très souvent beaucoup plus petit qu'un canton ou même qu'une fraction cantonale. Donc le nom donné Canton Ouest était bien ambigu. Et devait bien indiquer bureau de vote n° 22 même s'il appartient à la fraction du canton d'Orange-Ouest sur le territoire de la commune d'Orange. A l'heure actuelle, il n'y a pas de schéma défini pour les bureaux de vote, mais si un schém s'impose cela devrait rester une subdivision du canton dans un autre type de subdivision pour boundary=political. [Il me semble qu'au Royaume-Uni il y a des définitions pour les polling areas.] La question subsidiaire : vaut-il mieux avoir un nom Limite du bureau de vote n°22 (complètement redondant) ou rien ? Pas redondant, mais en tout cas ne pas faire de confusion avec les limites de cantons, et tant que la carte des bureaux de vote de la commune ou du canton n'est pas complètement établie, il est prématuré de vouloir faire une conflation des limites de ces bureaux de vote avec les frontières de communes ou de cantons. [ Il me semble qu'aucun bureau de vote, pour les élections au suffrage universel, ne peut couvrir des territoires de communes différentes ni de cantons différents, ni de circonscriptions législatives différentes, ni de circonscriptions régionales ou européennes différentes, car ce sont les communes qui ont la charge de les organiser (à défaut de moyens, c'est le préfet du département qui fournit les moyens dans la commune pour ses électeurs) ; la question ne se pose pas pour les circonscriptions sénatoriales puisque pour les sénatoriales les votes ne sont pas organisés par les communes mais par les départements, pour les électeurs élus territoriaux, ou par les régions pour les électeurs élus régionaux, par le biais su suffrage indirect qui fonctionne très différemment et n'est pas lié directement aux territoire de vie des citoyens électeurs Mais ces bureaux de vote ne sont pas des subdisivions administratives, et devraient rester dans des boundary=political avec un type différent pour political_subdivision. ]. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 30 mars 2013 23:14, Vincent de Chateau-Thierry v...@laposte.net a écrit : Le 30/03/2013 22:35, Guillaume Allegre a écrit : Le sam. 30 mars 2013 à 21:45 +0100, Vincent de Chateau-Thierry a écrit : Ensuite : ref:orange : là, je pense qu'on a un problème à régler. orange n'est pas suffisamment distinctif. Si toutes les communes du monde se mettent à utiliser le même schéma, on va multiplier les conflits. Comment régler ça ? Pour éviter d'avoir 36.000 tags ref:* distincts à terme (on peut rêver), je verrais plutôt un schéma générique sur 2 tags : source=* (rien de nouveau ici) ref:source=* ou source:internal_id ou toute autre formulation pour dire la même chose : mentionner l'identifiant unique utilisé par le fournisseur. Dans l'exemple du way : source=Mairie d'Orange 2012 ref:source=84087V99 Après tout, il ne s'agit pas d'un tag ref pour l'objet, que tout un chacun pourrait trouver sur le terrain, mais d'un tag ref qui n'existe que parce qu'une certaine source a été utilisée pour l'objet. Oui, mais cette façon de faire limite les possibilités d'édition ultérieures : - un objet pourrait avoir plusieurs ref (par exemple un ref:insee et un ref:FR:code-commune) - un objet peut avoir plusieurs sources : un SIG territorial à l'origine, puis une retouche par Bing ou par le cadastre et le source=Mairie d'Orange irait mieux sur le changeset Du coup, ref:source me semble trop fragile. Je pense que ref:FR:code insee commune comme proposé par Philippe Verdy est le plus sûr. Avec le schéma ref:FR:code insee commune on pourrait se retrouver avec autant de clés que de communes, toutes signifiant grosso-modo la même chose : cette clé a pour valeur une référence interne à la commune XXX. À l'extrême, 36.000 communes, 36.000 clés ? Je sais bien qu'on n'en arrivera pas là, je pousse juste la logique au bout. Et côté modélisation, autant de clés distinctes qui disent toutes la même chose, je trouve que ça fait beaucoup. Et dans ce scenario catastrophe, imagine le schéma de réutilisation, dans un modèle mis à plat comme le schéma standard d'osm2pgsql : 36.000 colonnes rien que pour la source... Là tu pousses à l'extrême car ces clés ne sont pas destinées à devenir des features au sens OpenGIS, mais des métadonnées à distinguer parmi celles pouvant renseigner un objet GIS. Hors on se retrouvera vite avec des clés fournies ou référencées par deux collectivités différentes, par exemples sur les voiries partagées par deux communes (ou plus). Si chacun a sa propre référence dans son SIG, on fait comment ? Même si une seule des sources a été utilisée (les autres sont d'accord sur le tracé, il n'y a pas d'ambiguité que c'est bien le même objet référenc, chaque source devrait pouvoir faire le lien avec son propre système de référence, car il n'y a pas garantie que les références utilisées par un SIG soient les mêmes que celle du SIG voisin (à moins qu'il y ait une convention commune adoptée entre les collectivités pour qu'elles utilisent la même référence interne pour faciliter les échanges entre les collectivités). Si ces collectivitées sont deux communes d'une même EPCI, elles se mettront d'accord avec le SIG de l'EPCI qui fera la lien. Mais il restera tout de même encore des liaisons à faire entre les SIG de deux EPCI différents, ou d'un EPCI et d'une commune hors EPCI. Ces communes peuent être aussi dans un autre département ou une autre région. Quand je proposais ref:FR:numéro insee = *, il était évident qu'on pouvait y mettre toute référence insee : un département à deux chiffres/lettres, une commune à 5 chiffres, mais si nécessaire on doit pouvoir être plus précis et indiquer le type de collectivité : - ref:FR:région:numéro insee = * - ref:FR:département:numéro insee = * - ref:FR:commune:numéro insee = * - ref:FR:EPCI:numéro insee = * Si au sein de la même collectivité il peut y avoir plusieurs sources utilisant des numéros de référence différents (service des espaces verts d'une commune par exemple), on peut sous-qualifier: - ref:FR:EPCI:numéro insee:esp-verts = * Note: les références nationales pour désigner les territoires entiers des collectivités elles-mêmes (ou autres subdivisions administratives voire aussi les cantons) restent: - ref:INSEE = numéro INSEE Les académies pourraient avoir leurs propre références pour les établissements qu'elles gèrent: - ref:FR:académie:Nom=* Chacun a sa clé de référence pour faire la liaison avec son SIG. Idem pour les régions militaires (mais là je pense qu'on n'a pas accès aux références internes, et que c'est géré en fait par le ministère de la défense, y compris pour les gendarmeries) Ma proposition sur 2 tags a pour objectif, au moins, d'éviter la multiplicité des clés signifiant toutes la même chose. Cela ne multiplie pas les clés. Les ref:* ne sont pas des features au sens GIS se ne sont que des métadonnées attachées en complément à un autre feature. Et les ref indiquées ne sont pas non plus nécessairement les
