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:xxxxx 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 donc....on 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<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<http://lists.openstreetmap.org/listinfo/talk-fr> >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
