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

Pieren pieren3 at gmail.com
Mar 24 Jan 14:19:23 UTC 2012


2012/1/24 sly (sylvain letuffe) <liste at letuffe.org>:
>
> hé ho, elle est où ta diplomatie légendaire ?
>

Je me suis énervé parce que j'ai vu un historique d'édition où de
nombreuses relations boundary étaient modifiées sans concertation, ni
examen des conséquences. Heureusement que Nominatim n'est plus mis à
jour depuis des mois...

Je ne vais pas revenir sur tous les points parce qu'il y en a trop. Je
voudrais juste donner quelques infos:
- les boundary_segments ne sont supportés par aucun logiciel, à part
ceux de Sly/Etienne Chové, donc uniquement franco-français. C'est
tellement vrai que nous avons maintenant deux relations identiques
pour le pays puisque les étrangers ne comprennaient pas pourquoi la
France était le seul pays sans polygon boundary dans leur bdd.
Résultat, au lieu d'avoir alléger les données de frontières, on les a
encore plus alourdies (d'où ma reflexion sur "c'était déjà le bordel
avant")
- les "subarea" sont une réinvention du fameux tag "is_in". C'est
juste pour éviter de faire des requêtes sql (et accessoirement à
apprendre à les faire). Ce rôle est uniquement documenté dans le wiki
du boundary administrative et pas dans celui du multipolygone. Il faut
savoir que la plupart des logiciels traitent les relations boundary
comme pour les multipolygones. Il y a donc une différence entre la doc
et les logiciels qui traitent les données OSM. Mais de toute façon,
les relations de relations ne sont pas supportées car elles posent des
problèmes techniques pas simples à résoudre lorsqu'on traite les
données en flux (ça oubligerait à faire deux passes ou de stocker les
relations en cache). Je comprends la facilité que cela amène pour
naviguer dans les relations. Je ne trouve pas utile de faire ce type
de construction pyramidale maintenue à la main si on peut le faire par
logiciel. Je n'approuve pas mais je n'empêcherais pas non plus ceux
qui veulent en faire, sauf que:
- mélanger dans la même relation "boundary" les contours extérieurs et
la somme des surfaces est un non-sens. Créez votre relation de type
"area" si ça vous chante pour mettre des subareas et laissez les
membres boundaries pour la relation "boundary". Il ne faut pas
mélanger des concepts différents sous le même nom. Les deux concepts
sont équivalents comme le dit Sly mais on a choisit il y a longtemps
d'opter pour les limites comme nos voisins à l'étranger et je ne vois
pas pourquoi, brutalement, on devrait passer d'un modèle à un autre ou
pire, cumuler les deux dans la même relation.
- certains militent pour la suppression du membre "admin_centre" de la
relation boundary/multipolygon car ils trouvent que ça n'en fait pas
partie. Ils veulent séparer la modélisation "géométrie" et
"administratif"
(http://lists.openstreetmap.org/pipermail/dev/2012-January/024229.html),
chose que je désapprouve. Mais c'est juste pour dire à quel point il
faut éviter de rendre ces relations un peu fourre-tout.
- osm2pqsql pour nominatim (gazetteer) et mapnik ignore les rôles. La
géométrie est reconstituée à partir de tous les ways membres de la
relation (voir build_geometry.cpp). C'est pourquoi actuellement, par
exemple, un building enrôlé comme admin_centre dans le relation sera
considéré comme un inner/enclave (et poser problème de géolocalisation
pour ce qui s'y trouve)
(http://lists.openstreetmap.org/pipermail/dev/2012-January/024226.html).
Ca n'est pas une raison pour ne pas mettre les rôles mais c'est aussi
juste pour dire que les relations ne doivent pas contenir trop de
choses différentes parce que cela rend l'interprétation des données de
plus en plus difficile pour les logiciels comme pour les humains.
- pour le modèle des relations de relations (boundary_segments), si
cela diminue le nombre de relations attachées à un way, cela augmente
aussi le nombre de relations (n+1) et rend aussi l'interprétation des
données plus difficile (on ne voit plus d'un coup d'oeil de quelles
relations fait partie un way). Donc là aussi, je n'ai rien contre leur
emploi mais en étant pragmatique, c.a.d que lorsqu'on n'a pas le
choix.

Pieren




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