>> Je pencherai donc plutôt pour >> * un site amenity=school + name=Lycée NNN >> * et des membres POIs (points ou bâtiment quand on peut) >> amenity=school_section > > > +1
Boonjour, C'est ce que j'avais fait naturellement au début, mais on m'a expliqué qu'il fallait réserver les relations "site" pour les site éclaté géographiquement. Sauf que parallement on explique aussi que les site permette d'établir une hierachie permettant de ne pas surcharger les cartes quand ce n'est pas nécessaire, en affichant juste l'info du site, sans ses membres individuels. Pourquoi évacuer d'un revers de la main la surface taggée amenity=school globale, avec nodes amenity=school dedans. En pratique amenity school ca veux dire ici il y a une école, pas forcément qu'elle est "unique" ceux qui veulent compter les écoles, et qui compte juste les amenity sans vérifier quelle sont imbriquer ... tant pis. D'autant plus que la surface amenity=school englobante, ne possède qu'un tag name a priori, sans détail de la section etc. En gros je trouve que c'est plutot une bonne solution, assez simple, et logique. Le probleme des compteur d'école doivent se résoudre autrement en vérifiant l'imbrication, mais a priori c'est pas le probleme du cartographe. C'est compliqué de vérifier qu'un node n'est pas englobé dans une surface, sans tag spécifique expliquant la "hiérarchie"? Cordialement _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
