Le 15/06/2012 09:57, Christian Quest a écrit :
Il y a plein de cas de figure... il ne faut pas raisonner avec un seul.
En utilisant:
- un amenity=school qu'il soit sur un node ou un way, décrit une école
- un landuse=school décrit si besoin une surface au sol occupée par
une ou plusieurs écoles
on peut:
- utiliser un simple node pour indiquer la présence d'une école
- tracer la surface occupée par une unique école (amenity=school) avec
éventuellement des sections dedans (node avec amenity=school)
- décrire un groupe scolaire où les contours de chaque école sont
indéterminés mais le contour global est un landuse=school et chaque
école plus ou moins localisée par un node ou un way amenity=school.
De cette façon, le nombre d'amenity=school correspond bien au nombre
d'école, et les surfaces au sont peuvent toujours être décrite.
Y a-t-il d'autres cas de figure ?
Dans le cas des sections, j'aurai bien ajouté un tag pour faire
référence à l'établissement principal et établir de cette façon le
rattachement et la hiérarchie entre les deux.
Le schéma commence à me plaire. Mais...
Le landuse=school :
Ça va être relou de faire des inner dans le landuse=residential
conteneur pour éviter l'overlap de landuses.
Je trouve que c'est déjà lourd avec les landuse=cemetery, cependant,
ceux-ci ont souvent le bon goût d'être à la périphérie du residential,
ce qui permet d'éviter le multipolygon.
Les sections en amenity=school, ça me semble limite.
Pour les compteurs d'écoles, ça va poser problème.
amenity=school_section, ça ne le fait pas ? Bien-sur, c'est pour une
section, genre technique dans un lycée, pas pour une école maternelle
dans un groupe scolaire.
On aura besoin de préciser tout ça dans le wiki ! Avec, en plus nos
school:FR ... Ah ces français...
--
FrViPofm
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
