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

[Philippe Verdy]

Le 26 janvier 2012 10:57, Pieren <pieren3 at gmail.com> a écrit :
> 2012/1/26 Philippe Verdy <verdy_p at wanadoo.fr>:
>
>> il peut alors de façon paliative
>> (uniquement paliative) utiliser l'autre axe vertical (surfaces,
>> "subareas").
>
> Dans tes arguments, tu parts toujours du principe que la relation
> "boundary" est parfois incomplète, ce qui induit ensuite Nominatim en
> erreur. Mais la même chose peut arriver dans le modèle surfacique. La
> relation peut manquer un subarea, une commune ou un département. Ou en
> avoir en trop. On ne peut jamais garantir l'intégrité des données. Et
> si un modèle diffère de l'autre (par exemple, une île qui serait dans
> l'un mais pas dans l'autre), il est impossible de savoir
> automatiquement qui a raison et qui a tord. Il faudra donc toujours
> passer par un contrôle manuel en cas de problème.
> Tu peux écrire des mails de 25 pages, tu n'as toujours pas démontré en
> quoi le modèle "subarea" n'est pas équivalent au modèle "boundary"
> actuel pour définir un multipolygone. Au contraire, comme d'autres
> l'ont déjà dit, le modèle surfacique ne marche que lorsque l'ensemble
> des subarea est défini.

C'est faux ! On peut très bien créer une nouvelle relation de
frontières avec un membre subarea ajouté à la zone plus grande, sans
avoir pour l'instant l'ensemble de ses frontières, mais par exemple
juste un admin_center. On la crée rapidement, avec les autres
métadonnées, on ajoute un fixme pour les frontières manquantes (ou
approximatives à redessiner avec une source cadastrale).

Cela ne remplace PAS le tracé des frontières. Et jamais je n'ai
défendu cette position.

> Hors, de nombreuses régions en France n'ont
> pas encore toutes leurs limites communales.

Justement c'est le cas en Mayenne, où il manquait aussi les 3
arrondissements que je suis en train d'ajouter SANS supprimer aucune
frontière. Les frontières restent là, je n'ai rien changé là-dessus.

C'est pour cela que le
> modèle "boundary" a toujours été préféré dans OSM jusqu'à aujourd'hui.

> Si tu ne peux pas vivre sans relations de type surfacique et
> pyramidal, soit, mais pas dans la même relation de type "boundary". Si
> tu penses que les deux peuvent se compléter, rien ne t'empêche de
> sélectionner l'une ou l'autre en fonction de l'attribut "type=*" (les
> tags "name" et "admin_level" pouvant être identiques).

Pas dans la même relation ? Tout l'intérêt est perdu car cela revient
à dédoubler toutes les relations filles, sans permettre de mettre un
seul lien avec l'autre relation par frontières, alors qu'il suffit
d'ajouter dans la relation mère UN SEUL membre par relation contenue
dans une autre.

Le volume de données  est négligeable au regard des données des
frontières: pas de relation en double portant les mêmes noms, les
mêmes références INSEE, NUTS ou autre, aucun besoin de modifier les
frontières ou de les doublonner. Ta solution serait pire car alors il
y aurait ambuiguité sur la relation à mettre à jour par des outils de
recherche externe, si on trouve deux relations avec le même type, les
mêmes tags (de référence) et les mêmes admin_level ! Alors que cela
désigne strictement le même objet... Où est le modèle relationnel dans
tout ça ???