[OSM-talk-fr] Aide Requête overpass pour EPCI France entière

Mar 4 Mai 18:03:29 UTC 2021

attention aux priorités entre "or", "and" et "in". En cas de doute utiliser
les parenthèses.
Je pense que là la restriction :  in "France Métropolitaine"
ne s'applique et se combine qu'avec : local_authority:FR=CC et pas avec les
autres valeurs, ce qui empêche de faire l'union des clauses "or", et peut
donc générer une requête moins efficace.

Je pense que l'idéal c'est:
(local_authority:FR"=* in "France Métropolitaine")
suivi ensuite des restrictions sur les valeurs de local_authority qui
restent si on ne veut que les métropoles, CA ou CC, et pas les autres types
d'EPCI métropolitains (ni ceux des outre-mers) grace à la première
restriction qui réduit considérablement le champ des recherches dans 90% du
monde cartographié dans OSM pour la France seulement (quasiment toutes les
longitudes depuis l'ouest en Polynésie française à l'Est à
Wallis-et-Futuna, et le plus gros des latitudes au nord (le reste dans la
zone arctique étant de toute façon nécessairement moins dense) et tout
l'hémisphère sud avec la Terre Adélie, même si on n'y trouve aucun EPCI).
Déjà avec juste les EPCI:FR=* on restreint beaucoup les recherches sans
faire de couteux calculs de géométrie, et ensuite "in France
Métropolitaine" filtre très bien même avec un polygone grossier sans avoir
à détailler la géométrie; il reste ensuite quelques centaines d'objets au
pire mais le filtrage final sur CA,métropole ou CC élimine les EPCI sans
fiscalité propre   (pays, SCOT, syndicats mixte, ICU, SIVOM et diverses
autres coopérations intercommunales pour gérer certaines ressources en
commun: transport scolaire, eaux, déchets, santé, éducation, culture, parcs
naturels, zones portuaires et très grosses infrastructures, zones de
prévention ou gestion des risques naturels ou industriels, intérêts
économiques et touristiques à intérêt régional, voire transfrontalier avec
des collectivités étrangères ...) et les ceux qui restent ignorés (villes
nouvelles incluses dans des métropoles, et communautés urbaines: sont-elles
toutes maintenant des "métropoles" ou incluses dans une?)

On doit comprendre que ces requêtes fonctionnent en faisant autant que
possible des fusions d'ensembles par une union, chaque sous-ensemble
nécessitant une première requête la plus sélective possible avant de la
restreinndre sur des cas peu contraignants. Cela génére pour chaque
sous-ensemble une table d'objets qu'il faut ensuite aller parcourir un par
un pour en filtrer une minorité, mais si on inverse, on obient une grosse
table qu'il faut parcourir ligne par ligne pour en éliminer beaucoup. Si
deux requêtes à combiner ont une sélectivité similaire, il vaut mieux les
faire séparément en créant ensuite une table temporaire triée sur une clé
commune comme l'ID et le type de l'objet, afin de faire le filtrage en
parcourant les deux tables en parallèle pour trouver les lignes communes.

Enfin faire les "or" est là aussi un parcours de tous ses membres triés
eux aussi sur une clé commune (idéalement l'ID et le type d'objet), pour
créer la table de fusion en les lisant en parallèle. Cependant c'est
couteux si pour faire les premières requêtes avant fusion il a fallu lire
d'autres données détaillées (c'est le cas des géométries, qu'ont ne peut
optimiser ne passe 1 qu'avec une simple "bounding box", à condition que les
objets indexent tous leurs bounding box sans avoir à lire toute la
géométrie dans le détail; le calcul final de géométrie nécessite plus de
calcul dans le curseur final qui parcours les lignes trouvées en passe 2
dans la table de fusion temporaire).

Si on fait des requêtes sans géométrie, l'OverpassQL s'en sort très bien,
car ça manipule peu de données: c'est le cas des requêtes portant juste sur
les types de tags, leurs valeurs si elles sont très sélectives et
simplement indexables sur leurs préfixes, ou sur les types d'objets (mais
les types d'objets sont trop peu sélectifs dans OSM, et ne devraient être
utilisés qu'à la fin); les requêtes sur un ID d'objet précis ou sur un nom
d'objet très peu courant voire unique sont très sélectives et devraient
être placées en premiers critères,  mais pas si les valeurs sont juste des
intervalles très larges ou des préfixes courts (et attention aux
conversions de casse, les bases n'indexent pas avec une collation correcte,
juste avec un tri binaire.

Malheureusement OverpassQL ne propose pas d'afficher un plan d'exécution
avec un tableau des sélectivités et volumétries estimées pour les tables et
index temporaires à créer puis restreindre et fusionner, puisqu'il n'estime
pas du tout les sélectivités sur les index qu'il gère (et il ne connait
rien des index de l;a base de donnée primaire d'OSM.org dont il n'a
localement qu'une vue partielle; et la base primaire n'offre pas d'API
permettant d'estimer facilement la sélectivité des critères pour créer un
plan d'optimisation optimal ou du moins à peu près correct, sans avoir à
télécharger la totalité des données concernées, là où un simple "COUNT(*)"
serait suffisant à ces estimations).

Mais il y a moyen de faire autrement: utiliser un autre moteur permettant
de gérer des "tables externes" et sinon gérant un cache local pour ses
estimations (de tels moteurs existent, comme ceux de Microsoft ou Oracle,
mais PostgreSQL avec les bonnes options peut aussi gérer ça, mieux qu'un
simple MariaDB). Un tel moteur peut être installé juste sur le même hôte ou
le même réseau local que le client requêteur (pour que les transferts de
données avec le client soient les plus réactifs possibles avec une bonne
bande passante disponible). Il y a d'autres solutions encore avec des
moteurs "noSQL" (ceux utilisés pour le BigData et ne nécessitant pas
l'intégrité stricte des données et une synchronisation forte entre les
serveurs et les clients, très utiles notamment pour les analyses
statistiques qui admettent des marges raisonnables d'erreur ou
d'approximation, car plus on veut réduire ces erreurs et garantir
l'intégrité stricte des modèles, et plus c'est coûteux en ressources et
long à synchroniser; mais OSM ne gère pas un livre de compte et admet des
marges d'erreurs partout dans ses données qui ne cessent de s'affiner sans
que tous les clients ait besoin de cette précision)

Le mar. 4 mai 2021 à 18:32, Marc_marc <marc_marc at mailo.com> a écrit :

> Bonjour,
>
> > Le 4 mai 2021 à 17:38, Jarry Philippe <ph.jarry at gmail.com> a écrit :
> >
> > local_authority:FR=metropole or local_authority:FR=CU or
> > local_authority:FR=CA or local_authority:FR=CC in "France Métropolitaine"
>
> si tu as besoin de toutes les valeurs, "local_authority:FR"=* est plus
> efficace
> par ailleurs tu n'as besoin que des relations ce qui se dit avec "and
> type:relation" avant le "in"
>
> mais la requête n'abouti pas.
> soit il y a un soucis overpass, soit quelqu'a mis des subarea inutiles
> mais qui vont te faire récupérer toutes les communes puis peut-être tous
> les quartiers (et peut-être pire).
> la mauvaise nouvelle c'est que je ne connais pas de moyen de corriger cela
> dans overpass (il récupérait trop de données que pour filtrer).
> tu peux vérifier l'hypothèse en supprimant le critère "in France
> métropolitaine) et en partant d'un zoom serré que tu agrandi ensuite. quand
> cela devient lent, regarde la donnée reçue à la recherche de subarea
>
> Cordialement,
> Marc
>
>
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>