Pour en revenir au problème de noeuf qui "déborde", voici un exemple:
http://www.openstreetmap.org/browse/node/1038274011 Historiquement, "Montjay" est considéré comme un hameau de Bures-sur-Yvette. En réalité, depuis les années 70, la ville nouvelle des Ulis s'est construite dans sa continuité et l'a "désenclavé". Il s'agit maintenant plutôt d'un quartier que d'un hameau. Montjay est tagué par un point (car les limites officielles ne sont pas connues), avec les tags suivants: is_in = Bures-sur-Yvette, Communauté d’Agglomération du Plateau de Saclay, Essonne, Île-de-France, France name = Montjay place = suburb Le résultat donne un polygone (calculé) assez large, qui déborde très largement sur la commune des Ulis, alors que Montjay est limité à Bures-sur-Yvette (ce que j'ai tenté de spécifier par le tag is_in, en vain). Là où le bas blesse, c'est dans le calcul des adresses par Nominatim. Par exemple, si je cherche le quartier "Champagne" des Ulis, défini par une relation précise de type boundary strictement incluse dans les frontières des Ulis, j'obtiens l'objet suivant: http://www.openstreetmap.org/browse/relation/1361065 L'objet est correct, mais l'adresse affichée par Nominatim est "Champagne, Coulée Verte, Montjay, Bures-sur-Yvette, Les Ulis, Essonne, 91440, Île-de-France, France" Le quartier "Champagne" est donc considéré comme faisant partie de Montjay, et par conséquent de Bures-sur-Yvette, du fait du débordement du polygone calculé pour Montjay. Est-ce un problème connu, me manque-t-il un tag pour bien définir Montjay? Raphaël 2011/1/7 Raphaël Pinson <raph...@gmail.com>: > Les arguments sont très intéressants :-) > > J'ai justement un problème avec le fait d'utiliser un noeud pour un > quartier lorsque le découpage administratif des communes est un peu > complexe. Un quartier localisé en périphérie de ville/village peut > déborder énormément sur les communes voisines, au point que > l'information sur la carte est entièrement erronée. Au moins avec un > type=boundary, la limite est clairement définie et un noeud avec un > role de label peut permettre de bien positionner l'information sur la > carte. > > Je suis en train d'expérimenter avec les type=boundary pour les > quartiers des Ulis (91940). En fait, comme remarqué par Pieren, les > autochtones ont tendance à utiliser plus les noms de résidences (que > je me retrouve donc à garder en landuse=residential) au sein de ces > quartiers (plutôt utilisés par les services communaux). > > Voilà un exemple de secteur+résidences/quartiers aux Ulis, tel que > j'en suis venu à le cartographier: > http://www.openstreetmap.org/browse/relation/1359866 > Les Hautes Plaines est une résidence inscrite dans ce secteur: > http://www.openstreetmap.org/browse/way/93664154 > > > > Raphaël > > > > 2011/1/7 Pieren <pier...@gmail.com>: >> 2011/1/7 Christophe Savigny <christophe.savi...@gmail.com> >>> >>> Bonjour, >>> >>> à Grenoble, j'ai crée les "secteurs" à partir d'une relation boundary de >>> niveau 10. >>> voir ici par exemple : >>> http://www.openstreetmap.org/browse/relation/1186180 >>> >> >> Christian parle de 20 quartiers sur Grenoble mais il y a 6 "secteurs" >> utilisés par la mairie. Pour moi, c'est l'exemple typique de découpage >> interne qui n'a aucune valeur dans OSM (d'ailleurs l'article wikipedia >> mentionné précise bien que les indigènes ne s'identifient pas à ces secteurs >> mais à leur quartier). >> A tout le moins, si on conserve ce genre de découpage (à mon avis, on ne >> devrait pas sinon on va se retrouvé submergé par des tas de boundaries à >> usage interne), il ne faudrait pas y appliquer les tags >> boundary=administrative; admin_level=10 mais autre chose. Sinon c'est quoi >> la prochaine étape, les bureaux de vote en admin_level=11, les cartes >> scolaires en admin_level=12, etc ? >> >> Pieren >> >> >> _______________________________________________ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-fr >> >> > _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
