Merci pour ces réponses qui me permettent d'y voir un peu plus clair. Le vendredi 25 mai 2012 à 14:39 +0200, sly (sylvain letuffe) a écrit : > 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 Côté wiki il ne me parait pas à jour. Par quel processus une relation passe du stade de proposé à officiel ? Sur la base des statistiques d'utilisation ? Quand j'aurais plus de temps, j'irais faire un tour de ce côté là aussi. > 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. Pour le projet qui m'intéresse, je compte pourtant m’appuyer sur les relations quand elles existent, et faire de l'empirique ailleurs (2 ways avec un certain nombres d'attribut communs = 1 route) (2 ways // avec même catégorie de route = probablement 1 route a chaussée séparée) Pour ma part hier j'ai ajouté 2 ou 3 routes, dès qu'elles sont coupées en 2 je les encapsules dans une "street", et je ne met plus le nom dans tous les tronçons. Aux éditeurs de se débrouiller comme cela m'a été dit dans certaines réponses. > 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. Effectivement, quand les gens aurons fait l'expérience de modifier 10 ou 20 tag pour ajouter UNE ref sur UNE rue, il trouverons plus d’intérêt aux relations. > > 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. Absolument d'accord, mais il faudrait proposer à ceux qui veulent aller dans ce sens des outils adéquats : qu'une "street" incorporant des way non taggées highway=, name=, ... soit admis. Je pense que je vais en laisser trainer quelques une dans la base (avec un tag comment expliquant le pourquoi) > > 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é > > _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
