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

[Emilie Laffray]

2012/1/24 verdy_p <verdy_p at wanadoo.fr>

> > Pour verdy_p : hélas sur tes exemples sur nominatim, je peux te dire ce
> qui
> va se passer : Plus rien ne pourra plus être indiqué comme étant dans
> l'ille
> et vilaine puisque nominatim utilise osm2pgsql qui ne supporte pas cette
> construction.
>
> Ne parlons pas de Nominatim, il a ses bogues et même avant d'avoir fait ce
> test de frontière pour l'Ille-et-Vilaine, cela fait longtemps qu'il classe
> toutes les communes d'Ille-et-Vilaine dans les Pays de la Loire (recherchez
> Rennes, j'ai eu beau modifier un peu la position du nœud, il a pris la
> nouvelle position, mais pas tenu compte de la relation parente qui est bien
> en Ille-et-Vilaine, et l'Ille-et-Vilaine en Bretagne...).
>
> Ce bogue de Nominatim ne vient pas du modèle utilisé dans la base OSM est
> propre à ses propres mises à jour (il en omet plein et stocke des tonnes de
> données anciennes en doublon avec les données récentes, et ne conserve que
> les anciennes alors qu'elles ne sont plus dans la base OSM principale).
>
> Regardez le Trac de Nominatim, il y a des tonnes de cas semblables, car il
> utilise une recherche géométrique très approximative, apparemment basée sur
> la distance d'un lieu aux centroïdes des régions les plus proches, pour
> tenter de résoudre ses propres anomalies de doublons (dont les doublons
> avec
> des données qui n'existent plus dans la base OSM et qu'il aurait du
> supprimer depuis longtemps de sa propre base).
>
> Et de fait, le centroïde de l'Ille-et-Vilaine (vers Betton, pas loin de
> Rennes) est plus proche du centroïde des Pays de la Loire (pas loin de
> Nord-sur-Erdre) que de celui de la Bretagne (à mi-chemin entre Carhaix et
> Ploermel)... Ces anomalies de Nominatim sont très fréquents pour les lieux
> et zones les plus excentrés d'une zone mère, souvent les zones
> frontalières...
>
>
Brève réponse pour Nominatim puisque je connais Brian. Par définition,
Nominatim utilisera un polygone quand il existe. Sinon cela utilisera un
mécanisme de weighed Voronoi qui est sur de donner des choses
approximatives. Le plus gros problème est que Nominatim doit gérer des
normes différentes dans tous les pays. C'est un peu une grosse catastrophe
vu la variété des données. Cela prend pas moins de 9 jours pour faire un
import de base de planet.osm et ces chiffres datent d'il y a près d'un an
maintenant. Je ne suis pas sure que ça soit en rajoutant de nouvelles
manières de tagguer que l'on va réparer les données et les résultats dans
Nominatim. C'est le problème de tout geocodeur: il faut avoir une
compréhension des données sous-jacentes pour pouvoir faire quelque chose
d'utile et qui fonctionne. On parle de la France en terme de complexité
mais il y a bien pire que la France, il y a le Royaume Uni.
Personnellement, après 2 ans de travail sur les limites administratives
anglaises, je suis toujours a me demander comment tout fonctionne.
De plus, Nominatim a toujours eus du mal a lire les frontières de la France
a la base vu le format utilisé. De plus, Nominatim utilise osm2pgsql pour
créer ses données. Autrement dit, si ça ne passe pas dans osm2pgsql, on
peut toujours se tamponner pour avoir quelque chose.
Quelques mots sur l'utilisation du subarea. Je considère l'utilisation du
sub area dans une relation comme une aberration totale telle qu'elle est
faite pour l'Espagne et la Pologne car ça mélange des données sémantiques
et géographiques ce qui est vraiment quelque chose d'horrible. La encore,
ça n'est que relativement récemment que osm2pgsql a été modifié pour
ignorer les subarea car ça faisait tout planté justement lié a ce mélange
hideux de sémantique et de géographique. Oui pour améliorer les choses, non
pour faire des immondices.
Quant a Nominatim, Brian travaille sur une version 2 de Nominatim qui
devrait permettre de nettoyer le code et d'améliorer les performances mais
la encore patch welcome pour ceux qui peuvent.

Emilie Laffray

Emilie Laffray
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20120124/fead9d66/attachment.htm>