On pourrait ajouter "is_in:country" qui ne devrait plus servir à rien maintenant qu'on a les frontières des pays (et qu'il a été décidé de délimiter les zones contestées ou revendiquées par plusieurs pays dans des relations séparées hors des revendications de chaque pays, avec un tag spécifique). La plupart des "is_in" était pour palier le manque provisoire de relations de délimitation des frontières en indiquant cela sur des noeuds. Il reste encore des "is_in:region=*" ou similaire pour des entités infra-nationales non encore délimitées, notamment pas mal au niveau des municipalités ou subdivisions nationales de 2e niveau (la plupart des délimitations de premier niveau sont déjà dans la base, et notamment les "is_in:state=*" pour les pays fédérés sont maintenant aussi inutiles.
Personnellement je considère les "is_in" un peu comme des "notes" informatives à traiter comme des éléments "à faire". Ce ne sont pas réellement des données exploitables (et encore moins le "is_in=*" qui accepte une liste, que les "is_in:type=*" qui peuvent encore avoir une utilité). Pour l'Europe et l'Amérique du Nord au moins, la quasi totalité des "is_in=*" ou "is_in:type=*" est maintenant inutile puisque les relations nécessaires sont là. De plus les tags "is_in[:type]=*" sont dépréciés plutôt en faveur des membres de rôle "subarea" dans les relations :je sais certains n'aiment pas les subarea, mais les requêtes spatiales sont lourdes et pas forcément appropriées pour trouver les subdivisions correctes dans les cas connus où la structure hiérarchique des niveaux n'est pas aussi stricte qu'on le pense, et les "subarea" lèvent ces ambiguités et ont un coût négligeable puisque c'est un seul membre ajouté par relation dans la relation parente appropriée et n'implique aucun ajoute de relation supplémentaire, et sont simples à gérer et vérifier de façon exhaustive et permettent aussi de relever les cas de revendications territoriales multiples/contestées, telles que les revendications chinoises contre celles de ses voisins, et cela permet d'adapter les rendus carto selon les pays demandeurs et peut permettre de lever des conflits d'édition en donnant la place à chaque point de vue). Bien souvent en plus on peut aussi utiliser les subarea pour créer et référencer des relations incomplètes, dans lesquelles les membres n'auraient encore que des noeuds (un "admin_centre", parfois 2 ou 3 pour certaines entités comme l'Afrique du Sud qui a 3 capitales, et éventuellement et encore d'autres pour les villes non encore tracées): ces relations incomplètes sont faciles à trouver et on peut aussi y mettre un tag "note" ou "fixme" pour bien indiquer ce qui reste à y faire pour les délimiter ou ajouter des notes sur les difficultés ou contestations de revendications. Il est simple de créer une liste exhaustive de relations même incomplètes et continuer ensuite : au lieu des "is_in" dispersés, on centralise l'info les sur la relation parente (même incomplète) avec ses membres "subarea". Les requêtes à la base de données sont largement simplifiées et beaucoup plus rapide (avec beaucoup moins de données à scanner), et le modèle des subarea est très résistant aux cas des relations brisées (dont certains ways membre ont été scindés), et facilitent la réparation. Certains ont cru à tord que les "subarea" étaient un conflit entre "modèle de surface" et "modèle de frontière", ce n'est pas le cas car cela a toujours été les deux en même temps: les subarea c'est autre chose et traduit seulement la reconnaissance d'une sous-entité territoriale/administrative comme partie d'une entité territoriale maître (voire plusieurs en cas de conflit de revendications): les "subarea" gèrent très bien ces conflits et sont très résistants. Il sont très peu coûteux, solides et efficaces, très faciles à gérer et donnent un excellent rapport de complétude. Cela se construit très vite avec peu de modifications à la base; même dans les éditeurs il devient facile de naviguer entre niveaux. Et ils sont une méthode bien plus efficace pour construire sans erreur (ou beaucoup moins d'erreurs) les frontières ou pour ensuite les modifier (réformes adminstratives) sans oubli : on sait facilement où en en est, on évite aussi des doublons d'objets. Les membres de rôle "subarea" ne sont pas non plus limités aux seuls frontières administratives; on a dans la base d'autres objets comme les limites fiscales, judiciaires, postales, militaires... En France aussi on a les "local_authority" assez compliqués pour les EPCI (il n'y a pas que les seuls ECPI à fiscalité propre, et même on a des cas où des ECPI ont leurs propres subdivisions comme les métropoles de Paris ou Nantes), et qui bougent régulièrement: il est là aussi facile de mettre dans la relation de l'EPCI la listes des communes membres: la construction et vérification des frontières en est facilité pour ensuite y mettre ou maintenir les ways membres en rôle "outer"/"inner". Certaines entités ont plusieurs types de découpages en parallèle qui là encore ne suivent pas le modèle hiérarchique (déjà bogué, car pas absolument vrai partout... et notamment pas lors des périodes transitoires de réformes administratives où deux découpages peuvent coexister pendant des mois voire même plusieurs années, et souvent nécessaires pour assurer la continuité statistique par exemple : tout n'est pas simplement "historique" et à effacer) des "boundary=administrative"+"admin_level=*": c'est un cas où les rôle "subarea" peuvent être qualifiés en cas de besoin par "subarea:type" pour distinguer chaque type de découpage (garder "subarea" uniquement pour le découpage "boundary=administrative"+"admin_level=*", qualifier les autres découpages concurrents). Là encore il n'y a rien à ajouter aux relations membres, les données sont claires et non ambiguës, et on facilite la réutilisation des données en rpenant en compte la complexité des situations et les nombreuses exceptions (que ne peut peut pas gérer une simple recherche géométrique qui ne sait pas faire le tri et mélange tout dans ses résultats et en oublie!). Le 8 août 2018 à 18:28, lenny.libre <lenny.li...@orange.fr> a écrit : > > > Le 08/08/2018 à 01:40, marc marc a écrit : > >> Bonsoir, >> >> une discussion a lieu ces derniers jours à propos des continents. >> ceux-ci, hormis l’antarctique, sont pour le moment représenté par un >> nœud car l'étendue de ceux-ci sont imprécis et parfois conflictuel >> (parle-t-on d’Europe donc d'un continent politique ? si oui quel est >> sa limite vers l'est ou de plaque tectonique et donc d’Eurasie ?) >> bref le débat est en cours... et j'ai pas la prétention d'apporter >> quelques choses à celui-ci tant les positions sont éloignées. >> >> par contre, pour contourner ce manque d'étendue géographique, >> il existe le tag is_in:continent. >> cela permet de renseigner qu'un pays ou une partie de celui-ci >> est dans tel continent >> cependant ce tag pour une raison inconnue se retrouve un peu n'importe >> où, il y a par exemple environ 350x ce tag en France continentale >> alors qu'il est suffisant d'en avoir un seul sur la relation. >> > +1 > Il me semble aussi que sa présence sur la relation > https://www.openstreetmap.org/relation/1403916 est suffisante > Leni > > >> Mon message a donc pour but d'informer mon intention de procéder >> un nettoyage en France continentale et donc de discuter de celui-ci >> avant de le faire comme il se doit :) >> >> PS: c'est quasi toute la variété des is_in qui faudrait nettoyer. >> Mais pour d'autre tag, ce serra moins trivial, alors je préfère >> y aller par petite étape rapide à discuter et à faire. >> >> Cordialement, >> Marc >> _______________________________________________ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
