Pas forcément les relations, les chemins et noeuds aussi (qui peuvent en être membre ou être isolés hors relation pour ne pas créer de relation à un seul membre): Disons seulement que type=* est juste un vrac parent pour tout le reste, destiné uniquement aux catégorisations principales les plus génériques. Et là on trouve des valeurs de type=* criticables comme: TMC et similaires (contrôle synchronisés des feux de signalisation par exemple, sous forme d'une collection de noeuds ou de la zone d'un carrefour ou d'une série de carrefours proches) qui pourraient être recatégorisés dans un type=* beaucoup plus générique.
Je trouve qu'on a trop de valeurs de type=* L'exploration de tagwatch montre bien l'aspect trop disparâtre de certains tags qui gagneraient à être regroupés avec une meilleure ontologie faciltitant les réutilisation quand les détails de chacun n'intéressent que peu de monde qui se satisferait d'un tag plus générique unique facilitant la collecte des données sans obliger à faire des unions de requêtes (les unions sont couteuses et délicates à maintenir car on a alors des oublis malheureux). Bref type=* pour juste la variété de boules de la pétanque c'est excessif et le tag a été pris à l'envers. Ca mérite une fusion par une petite task list pour migrer vers sport-boules;boules=petanque (il n'y a pas tant d'objets que ça, ce sera vite fait, et ensuite ça permet d'attribuer le un tag *=sport à la structure physique qui accueille ce sport : stade, place publique, salle, parc... qui eux ont besoin de leur type=* pour leur chemin-polygone ou multipolygone; sans avoir à utiliser un noeud séparé posé arbitrairement au milieu du polygone ni poser autant de noeuds que de sports pratiqués à cet endroit). De plus il est acceptable et en de donner plusieurs valeurs à boules=* (pourquoi seulement la variété de pétanque? il doit bien y avoir des endroits où on en fait indifféremment plusieurs) alors que c'est très mal venu pour type=* d'y mettre plusieurs valeurs (le tag est tellement utilisé qu'il vaut mieux éviter d'avoir à faire des recherches dessus avec des expressions régulières, et le réserver à des recherches par égalité stricte pour que ce soit le plus sélectif possible, alors que des recherches par expression régulière sur boules=* pour les cas où il y a plusieurs valeurs énumérées ne seront pas trop couteuses si on a déjà fait une sélection assez précise sur sport=boules). Les tags il faut les penser en fonction de la volumétrie estimée/attendue et de leur sélectivité pour l'efficacité et la réutilisabilité. Le 15 mai 2014 13:17, Pieren <pier...@gmail.com> a écrit : > 2014-05-15 11:04 GMT+02:00 V de Chateau-Thierry <v...@laposte.net>: > > > Le tag type=* et sa variante *:type=* est à mon avis une des pires idées > mises en oeuvre. > > Plus fourre-tout, c'est difficile. Donc je pencherais sans hésitation > pour la version > > pour l'instant la moins populaire (boules=petanque), dont j'aime bien le > principe : > > une propriété "tag=valeur" + une autre "valeur=sous-ensemble", c'est > déclinable...à > > l'infini ou presque :) > > Oui, il y a une volonté assez partagée de réserver la clé "type" aux > relations. Mais comme c'est le niveau zéro de la créativité, ça > revient régulièrement dans des propositions de nouveaux tags qu'il > faut ensuite nettoyer. D'où probablement les différences dans le wiki. > > Pieren > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
