[OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?

[Philippe Verdy]

Plutôt que les "is_in:*=*" ou les "left/right:*=*" franchement on peut
consolider beaucoup plus facilement et avec énormément moins de données
avec le modèle ensembliste (ne vous fiez pas au nom donné "subarea" pour le
rôle, ce n'est pas du tout une notion surfacique à proprement parler car
cela ne s'appuie pas du tout et ne nécessite d'ailleurs pas du tout la
moindre donnée géométrique, on n'a besoin d'aucun chemin ni aucun noeud et
aucune coordonnée).

Essayez avec le modèle purement géométrique d'obtenir la liste des 22
régions métropolitaines ! il faut télécharger actuellement plus de 800 000
chemins et plusieurs dizaines de millions de noeuds (et ces nombres sont
sans arrêt en hausse au fur et à mesure qu'on affine les données). Et des
heures de téléchargement, des millions de requêtes envoyées au serveur (ou
bien on peut télécharger un gros fichier dump de la base et passer
plusieurs jours à monter une base locale: quel gachis de temps pour tout le
monde !) et consommer une bande passante réseau de plusieurs gigaoctets.

Alors que 22 membres en tout et pour tout (membres ensembliste) dans la
base suffisent et permet d'avoir cette liste en quelques millisecondes avec
1 seule et unique requête qui nécessite une bande passante de moins d'1 Ko,
ce qui est accessible à n'importe quel utilisateur ayant une relation
internet lente ou un matériel très limité en capacité de stockage et de
calcul !

Cela n'exclue pas de stocker aussi dans les relations les contours externes
mais c'est autre chose et ce n'est pas une nécessité non plus ; déjà on ne
le fait plus pour la France entière car on aurait beaucoup trop de chemins
membres, la frontière est déjà scindée en plusieurs parties stockées à part
et on a beucoup de mal à synchroniser les différents niveaux hiérarchiques
de façon cohérente: mais ce sont ces frontières qui ont une redondance
énormes car on doit les reporter à tous les niveaux (et on passe son temps
à chercher comment les réparer efficacement et rapidement sans erreur.

Alors oui je suis favorable à la suppression des tags "is_in" (les membres
de rôle "subarea" sont énormément plus efficaces), et des tags "left/right"
beaucoup trop redondants et limités à une seule langue arbitraire (les
chemins frontières avec leurs rôles "inner/outer" suffisent, ces rôles
pouvant même être gérés comme synonymes puisque qu'on peut le déduire de la
géométrie, si elle est correcte et complète, la distinction entre "inner"
et "outer" est une facilité qui évite de devoir le calculer par un
traitement complexe nécessitant la connaissance intégrale du détail des
géométrie, mais ces distinctions ne sont pas volumineuses et restent utiles
pour détecter des incohérences et vérifier l'intention du tracé initial;
ces rôles 'inner" et "outer" sont vérifiables automatiquement de façon
asynchorne, et permettent aux outils tiers de fonctionner aussi sans avoir
à charger le détail complet des géométries)..



Le 19 septembre 2013 16:29, Pieren <pieren3 at gmail.com> a écrit :

> 2013/9/19 Pieren <pieren3 at gmail.com>:
>
> Et si on va dans la consolidation, on peut aussi rétablir tous les
> "is_in" qui ont été injustement supprimés. Et mettre des
> "addr:country=France" sur toutes les adresses en France. Parce qu'il y
> aura toujours quelqu'un qui trouvera ça plus pratique pour lui. Et
> pis, ça consolide et on pourra mieux détecter les incohérences.
>
> Pieren
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20130919/b0505217/attachment.htm>