Le 3 février 2012 09:37, Pieren <pier...@gmail.com> a écrit : > 2012/2/3 Philippe Verdy <verd...@wanadoo.fr>: > >> Le tag place sert à autre chose: il indique l'importance relative d'un >> lieu par rapport aux autres. Il sert surtout à fixer des priorités >> d'affichage et à éliminer (par exemple dans le rendu d'une carte à >> échelle grossière) des noms en excès qu'on ne peut pas tous afficher >> en même temps sans rendre la carte totalement illisible, pour ne faire >> apparaître que les éléments importants (par exemple les chef-lieux de >> région mais pas tous ceux de départements, les capitales de pays mais >> pas les autres villes du pays, les villes de plus de 100 000 habitants >> mais pas les villes de plus de 10 000 ou les villages). > > Le tag "place" est souvent basé sur un critère de taille (population). > Mais la taille n'est pas forcément l' "importance". Le role de > "chef-lieu" est justement modélisé par le role "admin_centre" de la > relation boundary. > > Inutile de revenir ici sur les avantages du "subarea".
Inutile, parce que vous ne voulez pas en discuter ??? Surtout parce que ceux qui s'y opposent veulent absolument que cela modélise la géométrie, d'une zone, alors que ce n'est pas le but. Ou disent que cela empêche de modéliser niveau par niveau ce qui est là encore totalement faux, ou que cela rendrait le système non homogène, ce qui est faux aussi (les problèmes d'homogénéité existent déjà avec les frontières seules, et il n'y a aucun outil pour vérifier leur cohérence de toute façon, ou de faciliter les corrections et fixer les oublis). Les "subarea:*" tels que je les décrit ne servent pas à définir la géométrie des zones elles-mêmes (pluriel, car ils peuvent être de différents rôles pour des découpages de nature différente) , et n'ont pas nécessairement non plus à en faire une partition complète. Voyez les comme des métadonnées essentielles, faciles à maintenir de façon séparée, et qui facilitent énormément les recherches et la classification des données, ainsi que (ensuite seulement) les éventuels contrôles de cohérence permettant de faciliter les corrections de frontières qu'il ne s'agit pas de supprimer. Quant à la page que tu proposes, elle ne concerne que les EPCI. Le rapport avec les subarea ne serait que pour l'énumération des communes qui en sont membres, mais ce n'est même pas évoqué, ou pour le découpage des zones de service de l'EPCI (pôles de proximité par exemple), deux rôles différents. Mais le problème est bien plus général, et tous les découpages d'un type donné ne sont pas non plus nécessairement une partition complète (il peut y avoir des parties incluses qui débordent de la zone mère, et c'est le cas des EPCI dont bon nombre sont à cheval sur plusieurs départements ou régions, même si ce n'est pas le cas concernant les arrondissements dans les départements, les départements dans les régions, et les régions du pays si on admet la Corse comme une région malgré son statut particulier, un statut qui pourrait être explicité avec un tag remplaçant le statut par défaut). Pensez alors aux découpages cantonaux, et aux données de nature géo-démographique ou pour l'aménagement territorial comme les agglomérations et aires urbaines de l'Insee : il ne s'agit pas de retracer les frontières, juste d'énumérer des listes de membres pour permettre de produire ensuite des cartes dérivées (et pas seulement des cartes routières ou de navigation). Pensez aux autres découpages de nature économique, judiciaire, hospitalière/santé publique, fiscale, chambres de commerces, syndicats agricoles... Si c'est le nom du rôle "subarea:*" qui vous fait peur, on peut en changer pour "member:*", ou autre, ça peut se discuter. De même j'avais évoqué la possibilité d'un tag "partition=" dont la (ou les valeurs valeurs séparées par un point-virgule) permettent donner le nom du rôle "member:*" ou "subarea:*" ou autre qui sont sensées former une partition de la zone et dont on liste tous les membres ayant ce même rôle (avec ce tag, il devient aussi possible de naviguer entre plusieurs types de découpage, pas seulement sur une carte, mais dans des tables statistiques dont on peut ainsi produire des agrégats statistiques sur des axes différents). De même, au lieu de proposer de créer des relations séparées (ce que je trouve complètement stupide quand cela crée des objets désignant les mêmes zones à découper), on peut aussi voir ces données comme une couche séparée qui pourrait être stockée dans une base séparée, sans absolument AUCUNE définition géométrique (pas de noeuds, pas de chemins), hors des relations, qui reprendraient exactement les mêmes ID's que OSM (dans ce cas on pourrait choisir de les charger ou ne pas les charger, dans un calque de données distinct). Un peu ce que fait Nominatim (avec beaucoup de mal car il se trompe très souvent en faisant les recherches par géométrie pour tenter de renseigner sa propre base de recherche). Car on met beaucoup trop de choses dans la base OSM (des tas d'attributs difficiles à maintenir de façon cohérente et stable car les objets géométriques sont créés, dupliqués, modifiés, supprimés sans regard aux autres attributs qui devraient être conservés et non dupliqués), des données qui seraient mieux gérées dans des calques de données distincts stockés dans des bases séparées mieux adaptées aux requêtes de toutes sortes. Maintenant l'équivalent d'une base de données distincte ce sont les conventions de nommage (un préfixe commun par exemple, ce qui est déjà fait au moins partiellement sur certains types de données). Mais où le discuter le mieux que justement sur une liste de discussion faite pour ça ? _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
