2012/1/24 sly (sylvain letuffe) <[email protected]>: > > hé ho, elle est où ta diplomatie légendaire ? >
Je me suis énervé parce que j'ai vu un historique d'édition où de nombreuses relations boundary étaient modifiées sans concertation, ni examen des conséquences. Heureusement que Nominatim n'est plus mis à jour depuis des mois... Je ne vais pas revenir sur tous les points parce qu'il y en a trop. Je voudrais juste donner quelques infos: - les boundary_segments ne sont supportés par aucun logiciel, à part ceux de Sly/Etienne Chové, donc uniquement franco-français. C'est tellement vrai que nous avons maintenant deux relations identiques pour le pays puisque les étrangers ne comprennaient pas pourquoi la France était le seul pays sans polygon boundary dans leur bdd. Résultat, au lieu d'avoir alléger les données de frontières, on les a encore plus alourdies (d'où ma reflexion sur "c'était déjà le bordel avant") - les "subarea" sont une réinvention du fameux tag "is_in". C'est juste pour éviter de faire des requêtes sql (et accessoirement à apprendre à les faire). Ce rôle est uniquement documenté dans le wiki du boundary administrative et pas dans celui du multipolygone. Il faut savoir que la plupart des logiciels traitent les relations boundary comme pour les multipolygones. Il y a donc une différence entre la doc et les logiciels qui traitent les données OSM. Mais de toute façon, les relations de relations ne sont pas supportées car elles posent des problèmes techniques pas simples à résoudre lorsqu'on traite les données en flux (ça oubligerait à faire deux passes ou de stocker les relations en cache). Je comprends la facilité que cela amène pour naviguer dans les relations. Je ne trouve pas utile de faire ce type de construction pyramidale maintenue à la main si on peut le faire par logiciel. Je n'approuve pas mais je n'empêcherais pas non plus ceux qui veulent en faire, sauf que: - mélanger dans la même relation "boundary" les contours extérieurs et la somme des surfaces est un non-sens. Créez votre relation de type "area" si ça vous chante pour mettre des subareas et laissez les membres boundaries pour la relation "boundary". Il ne faut pas mélanger des concepts différents sous le même nom. Les deux concepts sont équivalents comme le dit Sly mais on a choisit il y a longtemps d'opter pour les limites comme nos voisins à l'étranger et je ne vois pas pourquoi, brutalement, on devrait passer d'un modèle à un autre ou pire, cumuler les deux dans la même relation. - certains militent pour la suppression du membre "admin_centre" de la relation boundary/multipolygon car ils trouvent que ça n'en fait pas partie. Ils veulent séparer la modélisation "géométrie" et "administratif" (http://lists.openstreetmap.org/pipermail/dev/2012-January/024229.html), chose que je désapprouve. Mais c'est juste pour dire à quel point il faut éviter de rendre ces relations un peu fourre-tout. - osm2pqsql pour nominatim (gazetteer) et mapnik ignore les rôles. La géométrie est reconstituée à partir de tous les ways membres de la relation (voir build_geometry.cpp). C'est pourquoi actuellement, par exemple, un building enrôlé comme admin_centre dans le relation sera considéré comme un inner/enclave (et poser problème de géolocalisation pour ce qui s'y trouve) (http://lists.openstreetmap.org/pipermail/dev/2012-January/024226.html). Ca n'est pas une raison pour ne pas mettre les rôles mais c'est aussi juste pour dire que les relations ne doivent pas contenir trop de choses différentes parce que cela rend l'interprétation des données de plus en plus difficile pour les logiciels comme pour les humains. - pour le modèle des relations de relations (boundary_segments), si cela diminue le nombre de relations attachées à un way, cela augmente aussi le nombre de relations (n+1) et rend aussi l'interprétation des données plus difficile (on ne voit plus d'un coup d'oeil de quelles relations fait partie un way). Donc là aussi, je n'ai rien contre leur emploi mais en étant pragmatique, c.a.d que lorsqu'on n'a pas le choix. Pieren _______________________________________________ Talk-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-fr
