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

[sly (sylvain letuffe)]

On mardi 24 janvier 2012, Christian Quest wrote:
> Le sujet semble sensible vu le ton de plusieurs messages...

Je le déplore d'ailleurs alors qu'on est là pour discuter, mais bon, l'humain 
aime la fight, ça doit être ça.

> Quand on travaille sur la base de données, c'est quand même plus simple de
> passer par des liens logiques entre relations pour naviguer dans les
> hiérarchies administratives, non ? 
> Les requêtes spatiales sont coûteuses en 
> calcul et c'est de pire en pire vue le nombre croissant d'objets dans les
> bases, autant s'en passer quand on peut.

Voilà qui est un la première bonne question :
- Est-ce que le programme gagne ou perd du temps

Je vais tenter d'aider de mes connaissances, mais ça reste pas facile à savoir 
tant qu'on a pas les deux formats côte à côte pour faire des tests.

Prenons un exemple, la région Ille de France, avec le modèle "logique" 
ou "surfacique" ou "relationnel" on peut répondre facilement est simplement à 
la question : quels département sont dedans. Par contre, quand je veux 
répondre à la question : quelles communes sont dedans, je dois d'abord passer 
par les départements (à moins d'inclure en subarea tous les niveaux 
administratifs supérieurs mais ça c'est juste la folie) et ça, c'est pas 
forcément simple car il faut savoir quel est le ou les niveaux entre les deux 
(admin_level=6) et ça, ça ne se devine que parce qu'on est habitué, ça n'est 
portable qu'en france, dans d'autres pays, il y aura un admin level=5 ou un 
autre tag.

Si maintenant je veux tous les bâtiments d'ille de france, c'est juste 
impossible, car il n'y a pas de relation subarea pour lier les entités 
administratives et les bâtiments. De sorte que je suis obligé d'avoir les 
deux modèles quand même, je suis donc obligé de réfléchir selon chaque besoin 
si je dois utiliser le premier ou le deuxième modèle, ça me semble pas 
jouable et pas homogène comme méthode

> Je ne vois pas trop quel problème cela pose de mélanger au sein d'une même
> relation des objets géographiques et logiques (sémantiques). 

Moi, je vois que ça fait plus de boulot pour le mappeur, et ça, je ne vois pas 
ce qui le justifie.
Si quelqu'un a "vraiment" besoin d'un modèle logique pour accélérer des 
traitements ou faire je ne sais quoi, ce qu'il y a de génial, c'est qu'il 
pourra construire sa base de donnée en partant du modèle surfacique pour 
accélérer ou pour son traitement. L'inverse n'est pas vrai.

> Les deux types d'infos sont utiles. On peut considérer que c'est redondant,
> c'est vrai, mais cette redondance permet aussi de vérifier la cohérence et
> d'assurer un contrôle de qualité.

Ça, c'est encore un autre débat, mais intéressant aussi. Je dirais quand même 
que l'informatique nous a appris que dans bien des cas, la redondance ne 
faisait que créer des problèmes, et pas en résoudre.
Et puis, d'autres bases existent déjà (le cadastre) qui permet, comme je le 
fais, de faire un peu de contrôle qualité par la comparaison. Je ne pense pas 
que ça soit utile d'avoir deux modèles dans osm dans ce seul but.
 
> Si ce mélange au sein d'une même relation est vraiment source de problème,
> devrait-on créer 2 relations, une purement logique (niveau N -> niveau N+1
> avec les sub_area et autres choses du même ordre) et une géographique pour
> avoir juste les contours ?

Selon moi, ça ne change pas grand chose. Ajouter un 
"if role différent de inner/outer then rien faire" est chiant à mettre 
partout, mais c'est quand même possible et ça coûtera moins cher au mappeur.
Mais je pense qu'avant d'en arriver là, il faut déjà se demander
subarea : pour quel usage ?

> En ayant rajouté bon nombre d'EPCI ces derniers jours, je trouve l'approche
> uniquement "frontière" trop limitée.

Voilà la deuxième bonne question :
- Est-ce que le mappeur gagne ou perd du temps

Pour les EPCI, je n'en ai pas rentré, mais j'ai bien l'impression que oui, 
c'est plus galère d'inclure les frontières que d'inclure les communes.

Et cela est à mon avis dû à une loi mathématique :
Le périmètre d'un cercle est en f(r) celui d'une surface est en f(r²)

Plus ça devient gros, et moins on aura de membre sur un modèle frontière, et 
inversement.
Donc pour les départements/commune, je pense que c'est plus simple en modèle 
frontière, pour les EPCI/communes c'est plus simple en modèle surface

Mon avis n'a pas changé, vu qu'on ne sait rien, il faut tester. Et je propose 
de sacrifier les taggeurs d'EPCI sur l'autel de la recherche et leur proposer 
d'utiliser le modèle surfacique. L'avenir nous permettra de comparer tout ce 
que ça implique (logiciel pour exporter, outil de check, facilité à rentrer, 
etc.)

J'accepte toutefois qu'on me réponde "c'est pas éthique". Car comment laisser, 
en pensant que c'est une mauvaise idée, des gens faire quelque chose qui sera 
changé par la suite et du temps perdu.

La science aussi produit ses héros


-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org