[OSM-talk-fr] Outil d'importation des établissements scolaires

[Vincent Pottier]

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