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

Répondre à