[OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

[Philippe Verdy]

Le 25 janvier 2012 10:19, Pieren <pieren3 at gmail.com> a écrit :
> 2012/1/25 Philippe Verdy <verdy_p at wanadoo.fr>:
>> Je sais parfaitement pourquoi l'Ille-et-Vilaine n'est pas classée en
>> Bretagne par Nominatim: la requête spaciale échoue, car
>> l'Ille-et-Vilaine n'est pas entièrement incluse dans la Bretagne (ce
>> sont les îles oubliées...).
>
> Dans ce cas, il suffit d'ajouter les îles manquantes dans la relation
> et attendre que nominatim se remette à jour. Avec des subarea, on
> aurait aussi ce genre de problème. Si une relation est incomplète, on
> ne peut pas espérer que les logiciels ne fassent pas d'erreurs.




Non, avec les subareas, ce problème disparaitrait complètement: elles
sont simples à définir, très stables, indépendantes de la précision
des tracés ou de leur complétude, ne grossiront pas même si on
améliore la précision, elles soulagent énormément les requêtes. Et une
fois complètes (ce qui est facile à faire en peu de temps), elles
permettront de regénérer entièrement toutes les frontières de niveaux
supérieur, par récursion, afin que les cartes dessinées se mettent à
jour. Elles seront très utiles pout finalement aboutir à une cohérence
complète: plutôt que de perdre du temps à corriger les frontières
oubliées ou à la remettre en ordre pour les fermer et vérifier
qu'elles sont bien fermées, on ne travaille plus que sur les
frontières des zones les plus petites, ces zones (définies comme
relations de type boundary) qu'ont inclue ensuite comme relations
membres d'une zone plus grande avec un rôle "subarea".




La frontière de la zone de niveau supérieur, une fois que toutes les
subareas ont été incluses pour former une partition complète, peut
être regénérée automatiquement, et les boundary segments peuvent être
définis aussi automatiquement (plus tard) pour les frontières communes
des sous-zones. L'automatisation évitera toutes ces erreurs car on
commet nettement moins d'erreurs en travaillant au niveau le plus fin
de la carte: plus besoin de corriger les frontières des zones de
niveau supérieur, cela se fera par un bot, qui pourra le faire si une
zone contient des subareas, et si la zone mère est marquée comme
listant exhaustivement ses sous-zones (par exemple un attribut de la
relation "partitions"="subarea" indique que les membres de type
"subarea" forment une partition, et que donc ses frontières peuvent
être déduites, mises à jour automatiquement, des frontières de ses
sous-zones de rôle "subarea".




Rien donc n'est à changer aux outils qui dessinent les tuiles: ils
peuvent continuer à ignorer les membres de rôle subarea (ou tout autre
rôle si on désire faire plusieurs partitions différentes d'une zone,
ou faire des sous-zones formant une partition incomplète, ce rôle
restant alors non listé dans l'attribut "partitions"="subarea").




Je ne dis pas qu'il faut remplacer les frontières (boundaries, voire
boundary_segments) par des subareas, mais que les deux peuvent
énormément faciliter le travail: on travaille localement sur la carte,
qui se remet alors à jour de façon automatisable sur les zones de
niveau supérieur. Au final, on charge moins le serveur car la plupart
des éditions successives se fera au niveau local, ce qui affectera
beaucoup moins de tuiles, et demandera aux cartographes moins de
travail pour fouiller la carte, localiser les chemins et noeuds
puisqu'on peut naviguer facilement de façon récursive.




Et avec moins d'erreurs (grace au travail des bots), on pourra en in
corriger ce que Nominatim n'arrive pas à calculer correctement. Les
bots qui importent aussi des métadonnées n'auront plus besoin de
charger sans arrêt les noeuds et chemins: ils auront juste à parcourir
les relations, ce qui sera bien plus facile, plus rapide, plus
efficace, et produira des données de bien meilleure qualité que la
seule recherche géométrique qui est trop lourde.




Tu saisis l'intérêt ?