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