On jeudi 24 mai 2012, Balaitous wrote: > Bonjour, Bonjour,
> Pour mon premier message, je voudrais poser une question que je me pose > depuis un moment. > Est-ce que les tags d'une relation sont héréditaires ? > En d'autre terme lorsque je mets un tag dans une relation celui-ci > est-il transmis aux enfants de la relation (lorsque ceux-ci ne > redéfinissent pas le tag en question) ? Il n'y a pas "une" mais plusieurs réponses à ta question, principalement car l'éco-système OSM (la base, les utilisations, les éditeurs, le wiki) sont très souples et disons, un peu anarchique parfois et pas toujours cohérent et pas imposé par quoi que ce soit. (Je ne commenterais pas les défauts et avantages) Donc la réponse à ta question va dépendre de quelle partie de cet éco-système elle concerne. Dans la base OSM (celle qu'on édite avec JOSM/potlatch/...) il n'y a pas de notion d'hérédité, une relation a ses tags, un way les siens, un noeud les sien, et rien n'est recopié nulle part de manière automatique. Exemple, si tu places le tag landuse=forest sur une relation multipolygon, ce tag ne se retrouvera pas sur les ways membres de la relation. L'hérédité, si elle existe quelque part, sera dans la manière d'utiliser les données OSM, c'est à dire les logiciels de rendu, l'impression d'une carte, ... Et ça, c'est laissé complètement libre à celui qui veut se servir des données OSM, et donc au logiciel qu'il va utiliser pour s'occuper de la conversion du format .osm vers un format exploitable pour son besoin. Le logiciel osm2pgsql par exemple qui est célèbre car étant utilisé par la majorité des rendus sous forme de carte des données OSM (dont le rendu proposé en page d'accueil du site www.osm.org) dispose de quelque traitement de l'hérédité au niveau de certaines relations seulement (type=route, type=boundary et type=multipolygon) et pour certains tags seulement défini dans par liste blanche ou noire Il n'y a rien de systématique donc, et tout est fait au cas par cas, selon le besoin et le logiciel utilisé. Et enfin, il y a le wiki, qui va décrire l'utilisation de relation, et pour lesquelles il va (ou non) explicitement indiquer que toute utilisation de cette relation "devrait" considérer l'hérédité. Mais le wiki n'est qu'une description, la décision finale revenant à l'utilisation qui sera faite des dites relations et qui dépendra, certes de la description faite du wiki, mais aussi de la manière réél et majoritaire dont les contributeurs OSM auront rentré dans la base de donnée Exemple, si 1% seulement des routes nationales de france disposent d'une relation avec nom+ref alors que tout le reste c'est de la réplication des tags sur chacun des composants, alors je suppose que quelqu'un souhaitant faire un rendu des routes nationales de france va simplement laisser tomber l'hérédité car ça ne gérera que trop peu de cas. A l'inverse, si ce chiffre passe à 99% ça va commencer à intéresser du monde, et les choses évoluerons. Tout ça est donc un salmigondi s'entre-influençant fait de la manière d'éditer, du nombre d'utilisation qui en est faite, de documentation wiki qui en parle et du support plus au moins aisé/influencé par les éditeurs OSM. Une sorte de progression anarchique par essai/erreur qui entraîne sans doute de la perte de temps, de création d'algorithme plus compliqué mais aussi de plus de flexibilité. Mon pronostic c'est qu'on devrait ré-avancer vers la normalisation (factorisation des tags par les relations) et la multiplication des relations dans l'avenir car le découpage des routes, des cours d'eau, des frontières de manière quasi-arbitraire (restriction de vitesse, pont, tunnel, chevauchement) augmenterons et avec eux la difficulté d'éditer, donc un besoin grandissant d'outil pour les gérer. > Plus généralement, depuis quelques temps que je m'intéresse à OSM, je > trouve un manque de séparation des aspects géométriques (point, > ligne, ...) et sémantiques. Cela risque de poser d'importants problèmes > de cohérence pour le nommage des routes, de plus en plus fragmentées. Beaucoup en sont conscient, et des solutions arrivent petit à petit qui tente de garder la compatibilité (les relations sont l'exemple le plus typique) sinon les réflexions depuis quelques années pour gérer d'une manière unique et cohérente les surface : http://wiki.openstreetmap.org/wiki/The_Future_of_Areas Mais il est devenu presque impensable de dire : bon, on casse tout et on repart de zéro avec les géométries d'un coté, la sémantique de l'autre. > En gros, généraliser les relations, faire du multipolygon un élément > géométrique à part entière. J'en suis partisan, d'autres voudraient l'abandonner et le substituer par un nouvel objet "area" au même niveau que "way", "node" et "relation" qui reprendrait grosso modo l'idée du multipolygon mais imposerait des contraintes d'intégrité -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
