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

Mar 4 Mai 19:22:29 UTC 2021

Merci pour vos réponses,
Je vais tester ça

Philippe Jarry
P : 0667449387 - Twitter @phjarry - LinkedIn
<https://www.linkedin.com/in/philippe-jarry-10309437/>
www.philippejarry.fr  <http://www.philippejarry.fr>

Le mar. 4 mai 2021 à 20:05, Philippe Verdy <verdyp at gmail.com> a écrit :

> 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
> >
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>