Le jeudi 24 mai 2012 à 18:59 +0200, Gilles Bassière a écrit : > Le jeudi 24 mai 2012 à 09:36 -0500, Balaitous a écrit : > > Merci pour vos réponse. > > > > Donc si je comprend bien en dehors du myltipolygon, pas d'héritage des > > tags. (Je ne sais pas si c'est officiel pour le multipolygon, mais quand > > je l'utilise je ne tag pas les ways correspondantes, et ça a l'air de > > marcher). > > Je pense que c'est l'éditeur ou le rendu qui t'induit en erreur. Si tu > prend un bâtiment avec un cour intérieure par exemple, il y aura deux > chemins membres d'une relation de type multipolygon. Le seul objet OSM > qui représente le bâtiment est la relation. Les deux chemin *ne sont > pas* des bâtiments. Ils peuvent éventuellement porter des tags propres > pour représenter un *autre* objet. > > > En fait, le point de départ de ma réflexion, c'est qu'après avoir > > contribué un peu à l'édition, j'aimerais bien avoir une carte papier! > > Et je compte dans les mois qui viennent essayer de faire une telle > > carte, échelle visé 1:25000 et 1:100000. > > L'exploitation envisagée de la base de données ne doit en aucun cas > commander la manière dont on l'édite. Autrement dit : on ne taggue pas > pour le rendu (ou pour quoi que ce soit d'autre).
Entièrement d'accord. Le point de départ est effectivement l'élaboration d'une carte, mais les questions sont plus générales. La question que je me suis posé est quand deux way highway=* sont parallèles (pas évident à détecter, mais c'est possible algorithmiquement) s'agit-il des deux chaussées d'une même route ou non ? Cette information n'est pas spécifique à un rendu particulier, c'est une question d'échelle de représentation (et pas uniquement graphique) de l'information. Les relations existent, mais il y a un gros travail de standardisation à faire. Sur le wiki, je voie que des propositions de 2008 restent aujourd'hui des propositions! et le nombre de relation officiellement reconnues ne dépasse pas 6! Assez limité pour décrire de l'information de grande échelle. Pour les routes street ? associatedstreet ? collected way ? > > Si par exemple tu veux faire une carte du bâti, tu pourras avoir 2 > tables après import de la base : une table du bâti polygone (way) et une > table du bâti multipolygone (relation). C'est *après l'import* que tu > devras faire un post-traitement pour mettre ça au propre dans une seule > table. Pareil pour fusionner les tronçons de routes qui n'aurait pas été > groupé dans une relation (ST_LineMerge est ton ami). > > > Le système existant est très orienté navigation routière. > > Dans OSM, il y a aussi de l'occupation des sols, des chemins de > randonnées, des POI, des balises de navigation maritime, des ... Il n’empêche que la représentation des routes est très orienté voie de circulation. > > Les outils de modélisation OSM sont simples et souples et c'est pour ça > que la base est aussi riche :) > > > Effectivement les besoins ne sont pas les mêmes en rase campagne, où la > > règle un trait = une route fonctionne assez bien, et tant qu'une route > > n'est pas trop segmenté, la gestion manuelle de la cohérence fonctionne > > assez bien. En ville ou sur les grands axes routiers par contre la > > segmentation est beaucoup plus forte, et question simplicité d'édition, > > le système actuel n'est pas satisfaisant, rajouter une modifier une ref > > ou un nom sur une route partagée en 10 ou 2 segments à de quoi > > décourager plus d'un utilisateur! > > Rien ne t'empêche de créer une relation pour cette voie et ainsi > factoriser les tags. Je ne l'ai jamais vu mais ça n'est ni impossible ni > interdit. Le problème est que la factorisation des tags n'est pas reconnue (exception du multipolygon), il me semble que la plupart des moteurs de rendu fonctionnent au niveau trait. > > > Le principe d'un projet tel qu'OSM est de fonctionner par petites > > évolutions avec compatibilité ascendante. Le principe d'héritage des > > tags me parait entrer dans cette catégorie. > > Au niveau de l'édition cela peut se gérer assez facilement si un peu > > comme ce qui est fait pour les relations, lors de la sélection d'un > > élément JOSM affiche les groupes dont il fait partie, et si JOSM propose > > lors du découpage d'un segment de regrouper les tags existant en créant > > un nouveau groupe. > > L’existence de la relation type=route montre qu'il y a un besoin, mais > > son utilité est bien faible sans l'héritage des tags. > > En fait, je pense qu'on ne se comprends pas bien. J'entends "héritage" > au sens de la modélisation objet qui implique l'existence de classes. > Dit simplement l'héritage correspond à une relation "est-un" entre deux > concepts : la classe Écureuil hérite de Mammifère qui hérite de Animal > car un écureuil *est un* mammifère et un mammifère *est un* animal. Effectivement c'est bien de cette notion de factorisation des tags dont je veux parler. Et je constate que c'est une question que d'autres se posent puisque j'ai découvert une proposition de relation genre "collected tag". > Dans ce que tu décris, je ne vois pas de relation "est un" ni de > classes. Je vois seulement de la factorisation de tags. C'est bien de ça > que tu veux parler ? Si oui, alors les relations te permettent déjà de > faire ça. Les possibilité d'amélioration se situent alors : > - D'une part au niveau des éditeurs, comme tu le suggères, qui > pourraient proposer de créer une relation quand plusieurs objets OSM > sont manifestement des parties d'un même objet physique. Libre à toi de > proposer un patch implémentant ceci. > - D'autre part au niveau des contributeurs qu'il faudra convaincre ou > rassurer. En effet, beaucoup sont réticents à utiliser les relations > (les nouveaux et les occasionnels en particulier). J'espère que tu ne > manque ni de courage ni de pédagogie pour cette tâche :p > > Si j'interprète mal ce que tu appelles héritage, peux-tu donner des cas > d'utilisation pour clarifier ? > > Désolé pour la longueur de la réponse et merci d'avoir lu jusqu'ici ! > > Cordialement _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
