[OSM-talk-fr] édition mécanique : nettoyage is_in:continent

Philippe Verdy verdy_p at wanadoo.fr
Jeu 9 Aou 09:04:39 UTC 2018


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.libre at 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 at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20180809/f9040a70/attachment.html>


Plus d'informations sur la liste de diffusion Talk-fr