Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête

2014-05-14 Par sujet Mides 
Ce problème est donc résolu avec l'Overpass Turbo, un grand merci à tous
ceux qui ont pris sur le temps pour m'aider tout au long de la journée.

Bonne fin de soirée.

Michel


Le 14 mai 2014 22:56, Roland Olbricht  a écrit :

> > area [name="France"][admin_level="2"]->.zone;
> > (
> >node(area.zone)
> >["name"="Conseil Général"];
> > );
> > out meta;
> >
> > //--
> >
> > area [name="France"][admin_level="2"]->.zone;
> > (
> >node(area.zone)
> >["name"~"^Conseil Général$"];
> > );
> > out meta;
>
> Un area ne contiens que leur id comme données dans Overpass internalement.
> C'est garanti qu'elle est toujours de petite taille.
>
> Puis, les deux requêtes sont optimisées très different:
>
> Pour le premier, Overpass va d'abord ramasser tous les ids de nodes qui
> ont un tag "name"="Conseil Général". C'est parce que même pour les bbox
> petites c'est aussi vite de charger tous les ids que de chercher un bbox
> entier.
>
> Pour le deuxième, Overpass va aboutir avec l'area (ou egalement un bbox)
> parce que il pense que le critère spatial et plus specifiquement que un
> liste de les ids potentiellement très longue (pense à un requête comme
> "name"~"." ou "highway"~".", Overpass ne peut pas analyser des regvs).
>
> Il n'y a aucune analyse ni de la nombre de résultats poentiels un de la
> taille d'un area ou bbox. C'est simplement la difference entre un requête
> par égalité contre un requête par regv.
>
> Pour forcer filtrer par regv d'abord, on peut ce formuler par deux
> instructions:
>
> area [name="France"][admin_level="2"]->.zone;
> (
>node["name"~"^Conseil Général$"];
>node._(area.zone);
> );
> out meta;
>
> Ca va toujour s'il n'y a pas trop des résultats - moins d'un mille des
> résultats.
>
> Roland
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête

2014-05-14 Par sujet Mides 
Ok vu,  c'est le niveau de parenthèse qui nous a joué un mauvais tour. :-)

C'est un peut mieux de la sorte, avec le node["name"~"^Conseil Général$"];
qui devient très certainement "prioritaire" sur le area. (*D'ailleurs j'ai
mis des parenthèses qui ne servent à rien dans ce cas là*)

/*--
area [name="France"][admin_level="2"]->.zone;
*(*
   node["name"~"^Police$"];

*)*;
   node._(area.zone);
/*added by auto repair*/
(._;>;);
/*end of auto repair*/

out meta;


Michel


Le 14 mai 2014 22:56, Roland Olbricht  a écrit :

> > area [name="France"][admin_level="2"]->.zone;
> > (
> >node(area.zone)
> >["name"="Conseil Général"];
> > );
> > out meta;
> >
> > //--
> >
> > area [name="France"][admin_level="2"]->.zone;
> > (
> >node(area.zone)
> >["name"~"^Conseil Général$"];
> > );
> > out meta;
>
> Un area ne contiens que leur id comme données dans Overpass internalement.
> C'est garanti qu'elle est toujours de petite taille.
>
> Puis, les deux requêtes sont optimisées très different:
>
> Pour le premier, Overpass va d'abord ramasser tous les ids de nodes qui
> ont un tag "name"="Conseil Général". C'est parce que même pour les bbox
> petites c'est aussi vite de charger tous les ids que de chercher un bbox
> entier.
>
> Pour le deuxième, Overpass va aboutir avec l'area (ou egalement un bbox)
> parce que il pense que le critère spatial et plus specifiquement que un
> liste de les ids potentiellement très longue (pense à un requête comme
> "name"~"." ou "highway"~".", Overpass ne peut pas analyser des regvs).
>
> Il n'y a aucune analyse ni de la nombre de résultats poentiels un de la
> taille d'un area ou bbox. C'est simplement la difference entre un requête
> par égalité contre un requête par regv.
>
> Pour forcer filtrer par regv d'abord, on peut ce formuler par deux
> instructions:
>
> area [name="France"][admin_level="2"]->.zone;
> (
>node["name"~"^Conseil Général$"];
>node._(area.zone);
> );
> out meta;
>
> Ca va toujour s'il n'y a pas trop des résultats - moins d'un mille des
> résultats.
>
> Roland
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête

2014-05-14 Par sujet Mides 
Oups, par contre un petit souci, le tag name est "Conseil Général" et l'on
peut concevoir que l'on ne trouve ces deux termes associés qu'en France.

Si je mets le terme "Police", sensé être utilisé en dehors des pays
francophones, il me renvoie un résultat sur le monde entier. On dirait
qu'il ne tient pas compte du filtre :  area [name="France"][admin_level="2
"]->.zone;

http://overpass-turbo.eu/s/3o1


Michel




Le 14 mai 2014 23:09, Mides  a écrit :

> area [name="France"][admin_level="2"]->.zone;
> (
>node["name"~"^Conseil Général$"];
>node._(area.zone);
> );
> out meta;
>
> /--
>
> Cela fonctionne effectivement et avec un temps de réponse assez
> surprenant.
>
> J'ai bien vu l'ajout de : node._(area.zone), me reste maintenant à
> essayer de comprendre comment cela fonctionne et sont rôle dans la requête.
> (regv)
>
> Toujours est il, merci pour ce conseil.
>
> Michel
>
>
> Le 14 mai 2014 22:56, Roland Olbricht  a écrit :
>
>> > area [name="France"][admin_level="2"]->.zone;
>> > (
>> >node(area.zone)
>> >["name"="Conseil Général"];
>> > );
>> > out meta;
>> >
>> > //--
>> >
>> > area [name="France"][admin_level="2"]->.zone;
>> > (
>> >node(area.zone)
>> >["name"~"^Conseil Général$"];
>> > );
>> > out meta;
>>
>> Un area ne contiens que leur id comme données dans Overpass
>> internalement. C'est garanti qu'elle est toujours de petite taille.
>>
>> Puis, les deux requêtes sont optimisées très different:
>>
>> Pour le premier, Overpass va d'abord ramasser tous les ids de nodes qui
>> ont un tag "name"="Conseil Général". C'est parce que même pour les bbox
>> petites c'est aussi vite de charger tous les ids que de chercher un bbox
>> entier.
>>
>> Pour le deuxième, Overpass va aboutir avec l'area (ou egalement un bbox)
>> parce que il pense que le critère spatial et plus specifiquement que un
>> liste de les ids potentiellement très longue (pense à un requête comme
>> "name"~"." ou "highway"~".", Overpass ne peut pas analyser des regvs).
>>
>> Il n'y a aucune analyse ni de la nombre de résultats poentiels un de la
>> taille d'un area ou bbox. C'est simplement la difference entre un requête
>> par égalité contre un requête par regv.
>>
>> Pour forcer filtrer par regv d'abord, on peut ce formuler par deux
>> instructions:
>>
>> area [name="France"][admin_level="2"]->.zone;
>> (
>>node["name"~"^Conseil Général$"];
>>node._(area.zone);
>> );
>> out meta;
>>
>> Ca va toujour s'il n'y a pas trop des résultats - moins d'un mille des
>> résultats.
>>
>> Roland
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête

2014-05-14 Par sujet Mides 
area [name="France"][admin_level="2"]->.zone;
(
   node["name"~"^Conseil Général$"];
   node._(area.zone);
);
out meta;

/--

Cela fonctionne effectivement et avec un temps de réponse assez surprenant.

J'ai bien vu l'ajout de : node._(area.zone), me reste maintenant à essayer
de comprendre comment cela fonctionne et sont rôle dans la requête. (regv)

Toujours est il, merci pour ce conseil.

Michel


Le 14 mai 2014 22:56, Roland Olbricht  a écrit :

> > area [name="France"][admin_level="2"]->.zone;
> > (
> >node(area.zone)
> >["name"="Conseil Général"];
> > );
> > out meta;
> >
> > //--
> >
> > area [name="France"][admin_level="2"]->.zone;
> > (
> >node(area.zone)
> >["name"~"^Conseil Général$"];
> > );
> > out meta;
>
> Un area ne contiens que leur id comme données dans Overpass internalement.
> C'est garanti qu'elle est toujours de petite taille.
>
> Puis, les deux requêtes sont optimisées très different:
>
> Pour le premier, Overpass va d'abord ramasser tous les ids de nodes qui
> ont un tag "name"="Conseil Général". C'est parce que même pour les bbox
> petites c'est aussi vite de charger tous les ids que de chercher un bbox
> entier.
>
> Pour le deuxième, Overpass va aboutir avec l'area (ou egalement un bbox)
> parce que il pense que le critère spatial et plus specifiquement que un
> liste de les ids potentiellement très longue (pense à un requête comme
> "name"~"." ou "highway"~".", Overpass ne peut pas analyser des regvs).
>
> Il n'y a aucune analyse ni de la nombre de résultats poentiels un de la
> taille d'un area ou bbox. C'est simplement la difference entre un requête
> par égalité contre un requête par regv.
>
> Pour forcer filtrer par regv d'abord, on peut ce formuler par deux
> instructions:
>
> area [name="France"][admin_level="2"]->.zone;
> (
>node["name"~"^Conseil Général$"];
>node._(area.zone);
> );
> out meta;
>
> Ca va toujour s'il n'y a pas trop des résultats - moins d'un mille des
> résultats.
>
> Roland
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête

2014-05-14 Par sujet Roland Olbricht 

> area [name="France"][admin_level="2"]->.zone;
> (
>node(area.zone)
>["name"="Conseil Général"];
> );
> out meta;
>
> //--
>
> area [name="France"][admin_level="2"]->.zone;
> (
>node(area.zone)
>["name"~"^Conseil Général$"];
> );
> out meta;

Un area ne contiens que leur id comme données dans Overpass 
internalement. C'est garanti qu'elle est toujours de petite taille.


Puis, les deux requêtes sont optimisées très different:

Pour le premier, Overpass va d'abord ramasser tous les ids de nodes qui 
ont un tag "name"="Conseil Général". C'est parce que même pour les bbox 
petites c'est aussi vite de charger tous les ids que de chercher un bbox 
entier.


Pour le deuxième, Overpass va aboutir avec l'area (ou egalement un bbox) 
parce que il pense que le critère spatial et plus specifiquement que un 
liste de les ids potentiellement très longue (pense à un requête comme 
"name"~"." ou "highway"~".", Overpass ne peut pas analyser des regvs).


Il n'y a aucune analyse ni de la nombre de résultats poentiels un de la 
taille d'un area ou bbox. C'est simplement la difference entre un 
requête par égalité contre un requête par regv.


Pour forcer filtrer par regv d'abord, on peut ce formuler par deux 
instructions:


area [name="France"][admin_level="2"]->.zone;
(
   node["name"~"^Conseil Général$"];
   node._(area.zone);
);
out meta;

Ca va toujour s'il n'y a pas trop des résultats - moins d'un mille des 
résultats.


Roland

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête

2014-05-14 Par sujet Christian Quest 
Le 14 mai 2014 16:40, Mides  a écrit :

> Tout à fait dans le mesure où c'est la France qui m'intéresse, mais où
> trouve t-on cet outil ou se serveur. J'ai bien essayé de changer l'adresse
> sur overpass turbo eu ", mais aucun résultat.
>
>

https://openstreetmap.fr/outils "Accéder aux données"



-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête

2014-05-14 Par sujet Mides 
Effectivement sacrée optimisation des requêtes.

donc, si je lance cette requête sur une zone bien définie qui concerne la
France et DOM/TOM,  on peut effectivement supposer qu'il y a une
"surcharge" des données au niveau AREA

---
area [name="France"][admin_level="2"]->.zone;
(
  node(area.zone)
  ["name"~"^Conseil Général$"];
);
out meta;
--

Maintenant, si je lance la même requête mais sur le monde entier, sans
AREA, ça passe.  Il y a quelque chose qui m'échappe.

  node ["name"~"^Conseil Général$"];
 out meta;

Michel


Le 14 mai 2014 15:35, Christian Quest  a écrit :

> Tu pourrais aussi taper sur l'overpass-FR... ça éviterai le recourt à
> l'area ;)
>
>
> Le 14 mai 2014 14:29, Mides  a écrit :
>
>> A dire vrai, je vais avoir quelques difficultés à optimiser quoique ce
>> soit. J'utilise cette syntaxe, area [name="France"][admin_level="
>> 2"]->.zone; donc je comprends  le fonctionnement mais je ne trouve pas
>> de doc concernant le area, du moins ici :
>> http://wiki.openstreetmap.org/wiki/Overpass_API/Language_Guide
>>
>> D'ailleurs si tu as un point de chute doc, je suis preneur.
>>
>> Michel
>>
>>
>> Le 14 mai 2014 14:02, Marc SIBERT  a écrit :
>>
>> Visiblement le regv prend toutes les données, mais pas le v "normal" et
>>> ça produit un dépassement de capacité.
>>> Sûrement une question d'optimisation de la requête. As-tu essayé de
>>> croiser les filtres ?
>>>
>>> A voir aussi : [maxsize:1073741824]
>>>
>>> (je parle de la requête en version xml).
>>>
>>>
>>> Le 14 mai 2014 13:49, Mides  a écrit :
>>>
 Peut être effectivement que ce n'est pas conçu pour cela mais partant
 donc du principe que c'est le area qui pose problème, en englobant une zone
 trop important, je serai curieux de savoir pourquoi avec ces deux requêtes,
 une fonctionne très bien alors que l’autre lève une erreur.

 L’approche est certes différente mais le area reste  identique pour les
 deux et  le résultat renvoyé est normalement le même.

 area [name="France"][admin_level="2"]->.zone;
 (
   node(area.zone)
   ["name"="Conseil Général"];
 );
 out meta;

 //--

 area [name="France"][admin_level="2"]->.zone;
 (
   node(area.zone)
   ["name"~"^Conseil Général$"];
 );
 out meta;


 Pour info, ce problème est très récent.

 Michel


 Le 14 mai 2014 10:48, Christian Quest  a
 écrit :

 overpass n'est tout simplement pas conçu pour faire des requêtes sur
> des zones aussi grandes.
>
>
> Le 14 mai 2014 10:36, Mides  a écrit :
>
>> Je pensais que l'on pouvait travailler sur une emprise du style
>> inside_polygon. (admin_level = "2") sans pour cela remonter toutes les
>> données existantes dans ce polygone.
>>
>> Je peux biaiser le problème en définissant une bbox mais ce n'est pas
>> le top non plus (résultats en UK)
>>
>> node["name"~"^Police"](42.33194,-4.79556,51.07167,8.230);
>>
>>
>> Michel
>>
>>
>> Le 14 mai 2014 09:55, Christian Quest  a
>> écrit :
>>
>>>  Le 14 mai 2014 09:04, Mides  a écrit :
>>>
 J'ai un peu de mal à appréhender cette API,  comme par exemple
 cette syntaxe :

 area [name="France"][admin_level="2"]->.zone;

 je pensais qu'à ce niveau là, je ne remontais pas une quantité
 phénoménale de données mais juste le polygone d'emprise.


>>>
>>> Ça dépend ce que tu veux dire par "remonter". Si par là tu entends
>>> que tu va recevoir une grosse quantité de données, effectivement ce 
>>> n'est
>>> pas le cas (exemple de Monaco).
>>>
>>> En fait, l'overpass va commencer par sélectionner tout les noeuds
>>> dans l'area... et "remonter" ça en RAM, sauf que là, sur la France
>>> entière... ça dépasse les 512Mo qui sont sa limite et c'est pour ça que 
>>> tu
>>> as une erreur.
>>>
>>> Ca n'a rien à voir avec ce qui sera transféré au final.
>>>
>>>
>>> --
>>> Christian Quest - OpenStreetMap France
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>

 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr

>>>

Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête

2014-05-14 Par sujet Mides 
Tout à fait dans le mesure où c'est la France qui m’intéresse, mais où
trouve t-on cet outil ou se serveur. J'ai bien essayé de changer l'adresse
sur overpass turbo eu ", mais aucun résultat.

Michel


Le 14 mai 2014 15:35, Christian Quest  a écrit :

> Tu pourrais aussi taper sur l'overpass-FR... ça éviterai le recourt à
> l'area ;)
>
>
> Le 14 mai 2014 14:29, Mides  a écrit :
>
>> A dire vrai, je vais avoir quelques difficultés à optimiser quoique ce
>> soit. J'utilise cette syntaxe, area [name="France"][admin_level="
>> 2"]->.zone; donc je comprends  le fonctionnement mais je ne trouve pas
>> de doc concernant le area, du moins ici :
>> http://wiki.openstreetmap.org/wiki/Overpass_API/Language_Guide
>>
>> D'ailleurs si tu as un point de chute doc, je suis preneur.
>>
>> Michel
>>
>>
>> Le 14 mai 2014 14:02, Marc SIBERT  a écrit :
>>
>> Visiblement le regv prend toutes les données, mais pas le v "normal" et
>>> ça produit un dépassement de capacité.
>>> Sûrement une question d'optimisation de la requête. As-tu essayé de
>>> croiser les filtres ?
>>>
>>> A voir aussi : [maxsize:1073741824]
>>>
>>> (je parle de la requête en version xml).
>>>
>>>
>>> Le 14 mai 2014 13:49, Mides  a écrit :
>>>
 Peut être effectivement que ce n'est pas conçu pour cela mais partant
 donc du principe que c'est le area qui pose problème, en englobant une zone
 trop important, je serai curieux de savoir pourquoi avec ces deux requêtes,
 une fonctionne très bien alors que l’autre lève une erreur.

 L’approche est certes différente mais le area reste  identique pour les
 deux et  le résultat renvoyé est normalement le même.

 area [name="France"][admin_level="2"]->.zone;
 (
   node(area.zone)
   ["name"="Conseil Général"];
 );
 out meta;

 //--

 area [name="France"][admin_level="2"]->.zone;
 (
   node(area.zone)
   ["name"~"^Conseil Général$"];
 );
 out meta;


 Pour info, ce problème est très récent.

 Michel


 Le 14 mai 2014 10:48, Christian Quest  a
 écrit :

 overpass n'est tout simplement pas conçu pour faire des requêtes sur
> des zones aussi grandes.
>
>
> Le 14 mai 2014 10:36, Mides  a écrit :
>
>> Je pensais que l'on pouvait travailler sur une emprise du style
>> inside_polygon. (admin_level = "2") sans pour cela remonter toutes les
>> données existantes dans ce polygone.
>>
>> Je peux biaiser le problème en définissant une bbox mais ce n'est pas
>> le top non plus (résultats en UK)
>>
>> node["name"~"^Police"](42.33194,-4.79556,51.07167,8.230);
>>
>>
>> Michel
>>
>>
>> Le 14 mai 2014 09:55, Christian Quest  a
>> écrit :
>>
>>>  Le 14 mai 2014 09:04, Mides  a écrit :
>>>
 J'ai un peu de mal à appréhender cette API,  comme par exemple
 cette syntaxe :

 area [name="France"][admin_level="2"]->.zone;

 je pensais qu'à ce niveau là, je ne remontais pas une quantité
 phénoménale de données mais juste le polygone d'emprise.


>>>
>>> Ça dépend ce que tu veux dire par "remonter". Si par là tu entends
>>> que tu va recevoir une grosse quantité de données, effectivement ce 
>>> n'est
>>> pas le cas (exemple de Monaco).
>>>
>>> En fait, l'overpass va commencer par sélectionner tout les noeuds
>>> dans l'area... et "remonter" ça en RAM, sauf que là, sur la France
>>> entière... ça dépasse les 512Mo qui sont sa limite et c'est pour ça que 
>>> tu
>>> as une erreur.
>>>
>>> Ca n'a rien à voir avec ce qui sera transféré au final.
>>>
>>>
>>> --
>>> Christian Quest - OpenStreetMap France
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>

 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr


>>>
>>>
>>> --
>>> Marc Sibert
>>> m...@sibert.fr
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.open

Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête

2014-05-14 Par sujet Christian Quest 
Tu pourrais aussi taper sur l'overpass-FR... ça éviterai le recourt à
l'area ;)


Le 14 mai 2014 14:29, Mides  a écrit :

> A dire vrai, je vais avoir quelques difficultés à optimiser quoique ce
> soit. J'utilise cette syntaxe, area [name="France"][admin_level="
> 2"]->.zone; donc je comprends  le fonctionnement mais je ne trouve pas de
> doc concernant le area, du moins ici :
> http://wiki.openstreetmap.org/wiki/Overpass_API/Language_Guide
>
> D'ailleurs si tu as un point de chute doc, je suis preneur.
>
> Michel
>
>
> Le 14 mai 2014 14:02, Marc SIBERT  a écrit :
>
> Visiblement le regv prend toutes les données, mais pas le v "normal" et ça
>> produit un dépassement de capacité.
>> Sûrement une question d'optimisation de la requête. As-tu essayé de
>> croiser les filtres ?
>>
>> A voir aussi : [maxsize:1073741824]
>>
>> (je parle de la requête en version xml).
>>
>>
>> Le 14 mai 2014 13:49, Mides  a écrit :
>>
>>> Peut être effectivement que ce n'est pas conçu pour cela mais partant
>>> donc du principe que c'est le area qui pose problème, en englobant une zone
>>> trop important, je serai curieux de savoir pourquoi avec ces deux requêtes,
>>> une fonctionne très bien alors que l'autre lève une erreur.
>>>
>>> L'approche est certes différente mais le area reste  identique pour les
>>> deux et  le résultat renvoyé est normalement le même.
>>>
>>> area [name="France"][admin_level="2"]->.zone;
>>> (
>>>   node(area.zone)
>>>   ["name"="Conseil Général"];
>>> );
>>> out meta;
>>>
>>> //--
>>>
>>> area [name="France"][admin_level="2"]->.zone;
>>> (
>>>   node(area.zone)
>>>   ["name"~"^Conseil Général$"];
>>> );
>>> out meta;
>>>
>>>
>>> Pour info, ce problème est très récent.
>>>
>>> Michel
>>>
>>>
>>> Le 14 mai 2014 10:48, Christian Quest  a écrit
>>> :
>>>
>>> overpass n'est tout simplement pas conçu pour faire des requêtes sur des
 zones aussi grandes.


 Le 14 mai 2014 10:36, Mides  a écrit :

> Je pensais que l'on pouvait travailler sur une emprise du style
> inside_polygon. (admin_level = "2") sans pour cela remonter toutes les
> données existantes dans ce polygone.
>
> Je peux biaiser le problème en définissant une bbox mais ce n'est pas
> le top non plus (résultats en UK)
>
> node["name"~"^Police"](42.33194,-4.79556,51.07167,8.230);
>
>
> Michel
>
>
> Le 14 mai 2014 09:55, Christian Quest  a
> écrit :
>
>>  Le 14 mai 2014 09:04, Mides  a écrit :
>>
>>> J'ai un peu de mal à appréhender cette API,  comme par exemple cette
>>> syntaxe :
>>>
>>> area [name="France"][admin_level="2"]->.zone;
>>>
>>> je pensais qu'à ce niveau là, je ne remontais pas une quantité
>>> phénoménale de données mais juste le polygone d'emprise.
>>>
>>>
>>
>> Ça dépend ce que tu veux dire par "remonter". Si par là tu entends
>> que tu va recevoir une grosse quantité de données, effectivement ce n'est
>> pas le cas (exemple de Monaco).
>>
>> En fait, l'overpass va commencer par sélectionner tout les noeuds
>> dans l'area... et "remonter" ça en RAM, sauf que là, sur la France
>> entière... ça dépasse les 512Mo qui sont sa limite et c'est pour ça que 
>> tu
>> as une erreur.
>>
>> Ca n'a rien à voir avec ce qui sera transféré au final.
>>
>>
>> --
>> Christian Quest - OpenStreetMap France
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


 --
 Christian Quest - OpenStreetMap France

 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr


>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>>
>> --
>> Marc Sibert
>> m...@sibert.fr
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête

2014-05-14 Par sujet Mides 
A dire vrai, je vais avoir quelques difficultés à optimiser quoique ce
soit. J'utilise cette syntaxe, area [name="France"][admin_level="
2"]->.zone; donc je comprends  le fonctionnement mais je ne trouve pas de
doc concernant le area, du moins ici :
http://wiki.openstreetmap.org/wiki/Overpass_API/Language_Guide

D'ailleurs si tu as un point de chute doc, je suis preneur.

Michel


Le 14 mai 2014 14:02, Marc SIBERT  a écrit :

> Visiblement le regv prend toutes les données, mais pas le v "normal" et ça
> produit un dépassement de capacité.
> Sûrement une question d'optimisation de la requête. As-tu essayé de
> croiser les filtres ?
>
> A voir aussi : [maxsize:1073741824]
>
> (je parle de la requête en version xml).
>
>
> Le 14 mai 2014 13:49, Mides  a écrit :
>
>> Peut être effectivement que ce n'est pas conçu pour cela mais partant
>> donc du principe que c'est le area qui pose problème, en englobant une zone
>> trop important, je serai curieux de savoir pourquoi avec ces deux requêtes,
>> une fonctionne très bien alors que l’autre lève une erreur.
>>
>> L’approche est certes différente mais le area reste  identique pour les
>> deux et  le résultat renvoyé est normalement le même.
>>
>> area [name="France"][admin_level="2"]->.zone;
>> (
>>   node(area.zone)
>>   ["name"="Conseil Général"];
>> );
>> out meta;
>>
>> //--
>>
>> area [name="France"][admin_level="2"]->.zone;
>> (
>>   node(area.zone)
>>   ["name"~"^Conseil Général$"];
>> );
>> out meta;
>>
>>
>> Pour info, ce problème est très récent.
>>
>> Michel
>>
>>
>> Le 14 mai 2014 10:48, Christian Quest  a écrit :
>>
>> overpass n'est tout simplement pas conçu pour faire des requêtes sur des
>>> zones aussi grandes.
>>>
>>>
>>> Le 14 mai 2014 10:36, Mides  a écrit :
>>>
 Je pensais que l'on pouvait travailler sur une emprise du style
 inside_polygon. (admin_level = "2") sans pour cela remonter toutes les
 données existantes dans ce polygone.

 Je peux biaiser le problème en définissant une bbox mais ce n'est pas
 le top non plus (résultats en UK)

 node["name"~"^Police"](42.33194,-4.79556,51.07167,8.230);


 Michel


 Le 14 mai 2014 09:55, Christian Quest  a
 écrit :

>  Le 14 mai 2014 09:04, Mides  a écrit :
>
>> J'ai un peu de mal à appréhender cette API,  comme par exemple cette
>> syntaxe :
>>
>> area [name="France"][admin_level="2"]->.zone;
>>
>> je pensais qu'à ce niveau là, je ne remontais pas une quantité
>> phénoménale de données mais juste le polygone d'emprise.
>>
>>
>
> Ça dépend ce que tu veux dire par "remonter". Si par là tu entends que
> tu va recevoir une grosse quantité de données, effectivement ce n'est pas
> le cas (exemple de Monaco).
>
> En fait, l'overpass va commencer par sélectionner tout les noeuds dans
> l'area... et "remonter" ça en RAM, sauf que là, sur la France entière... 
> ça
> dépasse les 512Mo qui sont sa limite et c'est pour ça que tu as une 
> erreur.
>
> Ca n'a rien à voir avec ce qui sera transféré au final.
>
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>

 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr


>>>
>>>
>>> --
>>> Christian Quest - OpenStreetMap France
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> Marc Sibert
> m...@sibert.fr
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête

2014-05-14 Par sujet Marc SIBERT 
Visiblement le regv prend toutes les données, mais pas le v "normal" et ça
produit un dépassement de capacité.
Sûrement une question d'optimisation de la requête. As-tu essayé de croiser
les filtres ?

A voir aussi : [maxsize:1073741824]

(je parle de la requête en version xml).


Le 14 mai 2014 13:49, Mides  a écrit :

> Peut être effectivement que ce n'est pas conçu pour cela mais partant donc
> du principe que c'est le area qui pose problème, en englobant une zone trop
> important, je serai curieux de savoir pourquoi avec ces deux requêtes, une
> fonctionne très bien alors que l'autre lève une erreur.
>
> L'approche est certes différente mais le area reste  identique pour les
> deux et  le résultat renvoyé est normalement le même.
>
> area [name="France"][admin_level="2"]->.zone;
> (
>   node(area.zone)
>   ["name"="Conseil Général"];
> );
> out meta;
>
> //--
>
> area [name="France"][admin_level="2"]->.zone;
> (
>   node(area.zone)
>   ["name"~"^Conseil Général$"];
> );
> out meta;
>
>
> Pour info, ce problème est très récent.
>
> Michel
>
>
> Le 14 mai 2014 10:48, Christian Quest  a écrit :
>
> overpass n'est tout simplement pas conçu pour faire des requêtes sur des
>> zones aussi grandes.
>>
>>
>> Le 14 mai 2014 10:36, Mides  a écrit :
>>
>>> Je pensais que l'on pouvait travailler sur une emprise du style
>>> inside_polygon. (admin_level = "2") sans pour cela remonter toutes les
>>> données existantes dans ce polygone.
>>>
>>> Je peux biaiser le problème en définissant une bbox mais ce n'est pas le
>>> top non plus (résultats en UK)
>>>
>>> node["name"~"^Police"](42.33194,-4.79556,51.07167,8.230);
>>>
>>>
>>> Michel
>>>
>>>
>>> Le 14 mai 2014 09:55, Christian Quest  a écrit
>>> :
>>>
  Le 14 mai 2014 09:04, Mides  a écrit :

> J'ai un peu de mal à appréhender cette API,  comme par exemple cette
> syntaxe :
>
> area [name="France"][admin_level="2"]->.zone;
>
> je pensais qu'à ce niveau là, je ne remontais pas une quantité
> phénoménale de données mais juste le polygone d'emprise.
>
>

 Ça dépend ce que tu veux dire par "remonter". Si par là tu entends que
 tu va recevoir une grosse quantité de données, effectivement ce n'est pas
 le cas (exemple de Monaco).

 En fait, l'overpass va commencer par sélectionner tout les noeuds dans
 l'area... et "remonter" ça en RAM, sauf que là, sur la France entière... ça
 dépasse les 512Mo qui sont sa limite et c'est pour ça que tu as une erreur.

 Ca n'a rien à voir avec ce qui sera transféré au final.


 --
 Christian Quest - OpenStreetMap France

 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr


>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>>
>> --
>> Christian Quest - OpenStreetMap France
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Marc Sibert
m...@sibert.fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête

2014-05-14 Par sujet Mides 
Peut être effectivement que ce n'est pas conçu pour cela mais partant donc
du principe que c'est le area qui pose problème, en englobant une zone trop
important, je serai curieux de savoir pourquoi avec ces deux requêtes, une
fonctionne très bien alors que l’autre lève une erreur.

L’approche est certes différente mais le area reste  identique pour les
deux et  le résultat renvoyé est normalement le même.

area [name="France"][admin_level="2"]->.zone;
(
  node(area.zone)
  ["name"="Conseil Général"];
);
out meta;

//--

area [name="France"][admin_level="2"]->.zone;
(
  node(area.zone)
  ["name"~"^Conseil Général$"];
);
out meta;


Pour info, ce problème est très récent.

Michel


Le 14 mai 2014 10:48, Christian Quest  a écrit :

> overpass n'est tout simplement pas conçu pour faire des requêtes sur des
> zones aussi grandes.
>
>
> Le 14 mai 2014 10:36, Mides  a écrit :
>
>> Je pensais que l'on pouvait travailler sur une emprise du style
>> inside_polygon. (admin_level = "2") sans pour cela remonter toutes les
>> données existantes dans ce polygone.
>>
>> Je peux biaiser le problème en définissant une bbox mais ce n'est pas le
>> top non plus (résultats en UK)
>>
>> node["name"~"^Police"](42.33194,-4.79556,51.07167,8.230);
>>
>>
>> Michel
>>
>>
>> Le 14 mai 2014 09:55, Christian Quest  a écrit :
>>
>>>  Le 14 mai 2014 09:04, Mides  a écrit :
>>>
 J'ai un peu de mal à appréhender cette API,  comme par exemple cette
 syntaxe :

 area [name="France"][admin_level="2"]->.zone;

 je pensais qu'à ce niveau là, je ne remontais pas une quantité
 phénoménale de données mais juste le polygone d'emprise.


>>>
>>> Ça dépend ce que tu veux dire par "remonter". Si par là tu entends que
>>> tu va recevoir une grosse quantité de données, effectivement ce n'est pas
>>> le cas (exemple de Monaco).
>>>
>>> En fait, l'overpass va commencer par sélectionner tout les noeuds dans
>>> l'area... et "remonter" ça en RAM, sauf que là, sur la France entière... ça
>>> dépasse les 512Mo qui sont sa limite et c'est pour ça que tu as une erreur.
>>>
>>> Ca n'a rien à voir avec ce qui sera transféré au final.
>>>
>>>
>>> --
>>> Christian Quest - OpenStreetMap France
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête

2014-05-14 Par sujet Christian Quest 
overpass n'est tout simplement pas conçu pour faire des requêtes sur des
zones aussi grandes.


Le 14 mai 2014 10:36, Mides  a écrit :

> Je pensais que l'on pouvait travailler sur une emprise du style
> inside_polygon. (admin_level = "2") sans pour cela remonter toutes les
> données existantes dans ce polygone.
>
> Je peux biaiser le problème en définissant une bbox mais ce n'est pas le
> top non plus (résultats en UK)
>
> node["name"~"^Police"](42.33194,-4.79556,51.07167,8.230);
>
>
> Michel
>
>
> Le 14 mai 2014 09:55, Christian Quest  a écrit :
>
>>  Le 14 mai 2014 09:04, Mides  a écrit :
>>
>>> J'ai un peu de mal à appréhender cette API,  comme par exemple cette
>>> syntaxe :
>>>
>>> area [name="France"][admin_level="2"]->.zone;
>>>
>>> je pensais qu'à ce niveau là, je ne remontais pas une quantité
>>> phénoménale de données mais juste le polygone d'emprise.
>>>
>>>
>>
>> Ça dépend ce que tu veux dire par "remonter". Si par là tu entends que tu
>> va recevoir une grosse quantité de données, effectivement ce n'est pas le
>> cas (exemple de Monaco).
>>
>> En fait, l'overpass va commencer par sélectionner tout les noeuds dans
>> l'area... et "remonter" ça en RAM, sauf que là, sur la France entière... ça
>> dépasse les 512Mo qui sont sa limite et c'est pour ça que tu as une erreur.
>>
>> Ca n'a rien à voir avec ce qui sera transféré au final.
>>
>>
>> --
>> Christian Quest - OpenStreetMap France
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête

2014-05-14 Par sujet Mides 
Je pensais que l'on pouvait travailler sur une emprise du style
inside_polygon. (admin_level = "2") sans pour cela remonter toutes les
données existantes dans ce polygone.

Je peux biaiser le problème en définissant une bbox mais ce n'est pas le
top non plus (résultats en UK)

node["name"~"^Police"](42.33194,-4.79556,51.07167,8.230);


Michel


Le 14 mai 2014 09:55, Christian Quest  a écrit :

> Le 14 mai 2014 09:04, Mides  a écrit :
>
>> J'ai un peu de mal à appréhender cette API,  comme par exemple cette
>> syntaxe :
>>
>> area [name="France"][admin_level="2"]->.zone;
>>
>> je pensais qu'à ce niveau là, je ne remontais pas une quantité
>> phénoménale de données mais juste le polygone d'emprise.
>>
>>
>
> Ça dépend ce que tu veux dire par "remonter". Si par là tu entends que tu
> va recevoir une grosse quantité de données, effectivement ce n'est pas le
> cas (exemple de Monaco).
>
> En fait, l'overpass va commencer par sélectionner tout les noeuds dans
> l'area... et "remonter" ça en RAM, sauf que là, sur la France entière... ça
> dépasse les 512Mo qui sont sa limite et c'est pour ça que tu as une erreur.
>
> Ca n'a rien à voir avec ce qui sera transféré au final.
>
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête

2014-05-14 Par sujet Christian Quest 
Le 14 mai 2014 09:04, Mides  a écrit :

> J'ai un peu de mal à appréhender cette API,  comme par exemple cette
> syntaxe :
>
> area [name="France"][admin_level="2"]->.zone;
>
> je pensais qu'à ce niveau là, je ne remontais pas une quantité phénoménale
> de données mais juste le polygone d'emprise.
>
>

Ça dépend ce que tu veux dire par "remonter". Si par là tu entends que tu
va recevoir une grosse quantité de données, effectivement ce n'est pas le
cas (exemple de Monaco).

En fait, l'overpass va commencer par sélectionner tout les noeuds dans
l'area... et "remonter" ça en RAM, sauf que là, sur la France entière... ça
dépasse les 512Mo qui sont sa limite et c'est pour ça que tu as une erreur.

Ca n'a rien à voir avec ce qui sera transféré au final.


-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête

2014-05-14 Par sujet Christophe Merlet 
Le 14/05/2014 09:04, Mides a écrit :
> J'ai un peu de mal à appréhender cette API,  comme par exemple cette
> syntaxe : 
> 
> area [name="France"][admin_level="2"]->.zone;
> 
> je pensais qu'à ce niveau là, je ne remontais pas une quantité
> phénoménale de données mais juste le polygone d'emprise. 

La France administrative de niveau 2 correspond à la France
métropolitaine + DOM/TOM et autres territoires.
Autant dire que si le polygone d'emprise est un simple rectangle, il
couvre quasiment la terre entière ! et mieux vaut donc s'en passer.

Si tu ne veut que la France métropolitaine, fait bien attention a ne
prendre qu'elle :
http://nominatim.openstreetmap.org/details.php?place_id=98156803
http://www.openstreetmap.org/relation/1403916
name = France métropolitaine
admin_level = 3

> Quant à area je ne trouve pas spécialement de doc ici,  et je suis
> preneur si plus d'infos :
>  http://wiki.openstreetmap.org/wiki/Overpass_API/Language_Guide
> 
> Sinon, effectivement si je priorise la requête : 
> 
> node["name"~"^Toulouse"](area.zone);   
> 
> mais comment lui dire ensuite d'appliquer un filtre area
> 
> Michel
> 
> 
> Le 14 mai 2014 04:46, Philippe Verdy  > a écrit :
> 
> Je pense plutôt que c'est le premier filtre de la seconde requête
> (node(zone)à qui n'est pas assez sélectif. La "zone" (le polygone de
> la France adminstrative de niveaus 2) est gigantesque et contient
> des millions de noeuds.
> 
> La première requête (vers la variable "zone" est relativelent
> sélective car elle recherche des polygones ayant deux attributs très
> sélectifs (name=France déjà, affiné par admin_level=2 pour les
> homonymes peu nombreux): à priori zone ne contient qu'un polygone
> (assez complexe malgré tout avec quelques milliers de sommets
> essentiellement sur les frontières terrestres, car en mer les
> limites des eaux territoriales ne sont pas très compliquées, mais
> son on choisissait la limite côtière alors là ce sont près de 200
> 000 noeuds, peut-etre plus maintenant avec les cotes de plus en plus
> affinées et les ilots).
> 
> Il vaut mieux faire des requêtes en commençant par le filtre le plus
> sélectif; celui sur le name élimine quasiment tout, et ne crée donc
> pas une table temporaire énorme, le filtre sur la zone France est à
> appliquer après sur ce qui reste (s'il reste quelquechose).
> 
> Overpass n'a toujours pas d'optimiseur statistique des plans
> d'exécutions qu'il crée en interne (il ne sait pas évaluer la
> sélectivité des requêtes: même s'il y a des index primaires
> utilisables, ça peut être encore inefficace si la sélectivité de la
> requête est faible, et c'est pire si cela doit passer par des index
> secondaires n'incluant pas d'autres données nécessaires sur des
> éléments non sélectifs) et en stockant des tonne de données temporaires.
> 
> Assez vite il tombe sur les limites de quota (en volume, ou encore
> plus en nombre d'I/O qui sollicite beaucoup les disques avec des
> caches peu efficaces, et en fin de compte aboutissant à dépasser le
> quota de temps d'exécution mais avec cette requête-là on doit tomber
> sur tous ces quotas en même temps, mais impossible ici de dire
> lequel tombe en premier).
> 
> De fait on doit penser à une optimisation manuelle de ses requêtes
> en évaluant soi-même quelles quantités de données sont séletionnées
> à chaqué étape.
> 
> Donc ici il suffit d'inverser les deux requêtes : filtrer d'abord
> sur les noeuds ayant ce nom puis sélectionner les points restants
> dans la zone retenue. La solution sera inversée si la zone est assez
> petite (ne dépasse pas la limite raisonnable de taille d'une zone
> restangulaire de téléchargement de JOSM par exemple ; toute la
> France c'est beaucoup trop gros si on n'a pas déjà effectué une
> première sélection très sélective).
> 
> 
> Le 13 mai 2014 21:46, Christian Quest  > a écrit :
> 
> Je pense que c'est la premier area qui cause un dépassement côté
> serveur... et pas que le serveur t'a envoyé 513MB de data ;)
> Sur une plus petite zone (Monaco) ça répond bien qu'il n'a rien
> trouvé.
> 
> 
> Le 13 mai 2014 20:55, Mides  > a écrit :
> 
> Bonsoir, 
> 
> À cette requête, pour test, sensée trouver toutes les tags
> name débutants par cette chaine, "trzetgsqgdfgqsdaze " cette
> réponse m’est retournée, et pourtant je ne pense pas qu’il y
> ait beaucoup de tags name où l'on trouve ce mot. 
> 
> Assez étonnant comme résultat.
> 
> _Requête :_
> _
> _
> area [name="France"][admin_level="2"]->.zone;
> (
>   node(area.zone)
>   ["name"~"^trzetgsqgdfgqsdaze "];
>

Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête

2014-05-14 Par sujet Mides 
J'ai un peu de mal à appréhender cette API,  comme par exemple cette
syntaxe :

area [name="France"][admin_level="2"]->.zone;

je pensais qu'à ce niveau là, je ne remontais pas une quantité phénoménale
de données mais juste le polygone d'emprise.

Quant à area je ne trouve pas spécialement de doc ici,  et je suis preneur
si plus d'infos :
http://wiki.openstreetmap.org/wiki/Overpass_API/Language_Guide

Sinon, effectivement si je priorise la requête :

node["name"~"^Toulouse"](area.zone);

mais comment lui dire ensuite d'appliquer un filtre area

Michel


Le 14 mai 2014 04:46, Philippe Verdy  a écrit :

> Je pense plutôt que c'est le premier filtre de la seconde requête
> (node(zone)à qui n'est pas assez sélectif. La "zone" (le polygone de la
> France adminstrative de niveaus 2) est gigantesque et contient des millions
> de noeuds.
>
> La première requête (vers la variable "zone" est relativelent sélective
> car elle recherche des polygones ayant deux attributs très sélectifs
> (name=France déjà, affiné par admin_level=2 pour les homonymes peu
> nombreux): à priori zone ne contient qu'un polygone (assez complexe malgré
> tout avec quelques milliers de sommets essentiellement sur les frontières
> terrestres, car en mer les limites des eaux territoriales ne sont pas très
> compliquées, mais son on choisissait la limite côtière alors là ce sont
> près de 200 000 noeuds, peut-etre plus maintenant avec les cotes de plus en
> plus affinées et les ilots).
>
> Il vaut mieux faire des requêtes en commençant par le filtre le plus
> sélectif; celui sur le name élimine quasiment tout, et ne crée donc pas une
> table temporaire énorme, le filtre sur la zone France est à appliquer après
> sur ce qui reste (s'il reste quelquechose).
>
> Overpass n'a toujours pas d'optimiseur statistique des plans d'exécutions
> qu'il crée en interne (il ne sait pas évaluer la sélectivité des requêtes:
> même s'il y a des index primaires utilisables, ça peut être encore
> inefficace si la sélectivité de la requête est faible, et c'est pire si
> cela doit passer par des index secondaires n'incluant pas d'autres données
> nécessaires sur des éléments non sélectifs) et en stockant des tonne de
> données temporaires.
>
> Assez vite il tombe sur les limites de quota (en volume, ou encore plus en
> nombre d'I/O qui sollicite beaucoup les disques avec des caches peu
> efficaces, et en fin de compte aboutissant à dépasser le quota de temps
> d'exécution mais avec cette requête-là on doit tomber sur tous ces quotas
> en même temps, mais impossible ici de dire lequel tombe en premier).
>
> De fait on doit penser à une optimisation manuelle de ses requêtes en
> évaluant soi-même quelles quantités de données sont séletionnées à chaqué
> étape.
>
> Donc ici il suffit d'inverser les deux requêtes : filtrer d'abord sur les
> noeuds ayant ce nom puis sélectionner les points restants dans la zone
> retenue. La solution sera inversée si la zone est assez petite (ne dépasse
> pas la limite raisonnable de taille d'une zone restangulaire de
> téléchargement de JOSM par exemple ; toute la France c'est beaucoup trop
> gros si on n'a pas déjà effectué une première sélection très sélective).
>
>
> Le 13 mai 2014 21:46, Christian Quest  a écrit :
>
>> Je pense que c'est la premier area qui cause un dépassement côté
>> serveur... et pas que le serveur t'a envoyé 513MB de data ;)
>> Sur une plus petite zone (Monaco) ça répond bien qu'il n'a rien trouvé.
>>
>>
>> Le 13 mai 2014 20:55, Mides  a écrit :
>>
>>>  Bonsoir,
>>>
>>> À cette requête, pour test, sensée trouver toutes les tags name
>>> débutants par cette chaine, "trzetgsqgdfgqsdaze " cette réponse m’est
>>> retournée, et pourtant je ne pense pas qu’il y ait beaucoup de tags name où
>>> l'on trouve ce mot.
>>>
>>> Assez étonnant comme résultat.
>>>
>>> *Requête :*
>>>
>>> area [name="France"][admin_level="2"]->.zone;
>>> (
>>>   node(area.zone)
>>>   ["name"~"^trzetgsqgdfgqsdaze "];
>>> );
>>> out skel;
>>>
>>> *Réponse : *
>>>
>>> Une erreur est survenue lors de l'exécution de la requête overpass !
>>> Voici ce que l'API overpass a retourné :
>>> runtime error: Query run out of memory in "query" at line 4 using about
>>> 513 MB of RAM.
>>>
>>> Michel
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>>
>> --
>> Christian Quest - OpenStreetMap France
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête

2014-05-13 Par sujet Philippe Verdy 
Je pense plutôt que c'est le premier filtre de la seconde requête
(node(zone)à qui n'est pas assez sélectif. La "zone" (le polygone de la
France adminstrative de niveaus 2) est gigantesque et contient des millions
de noeuds.

La première requête (vers la variable "zone" est relativelent sélective car
elle recherche des polygones ayant deux attributs très sélectifs
(name=France déjà, affiné par admin_level=2 pour les homonymes peu
nombreux): à priori zone ne contient qu'un polygone (assez complexe malgré
tout avec quelques milliers de sommets essentiellement sur les frontières
terrestres, car en mer les limites des eaux territoriales ne sont pas très
compliquées, mais son on choisissait la limite côtière alors là ce sont
près de 200 000 noeuds, peut-etre plus maintenant avec les cotes de plus en
plus affinées et les ilots).

Il vaut mieux faire des requêtes en commençant par le filtre le plus
sélectif; celui sur le name élimine quasiment tout, et ne crée donc pas une
table temporaire énorme, le filtre sur la zone France est à appliquer après
sur ce qui reste (s'il reste quelquechose).

Overpass n'a toujours pas d'optimiseur statistique des plans d'exécutions
qu'il crée en interne (il ne sait pas évaluer la sélectivité des requêtes:
même s'il y a des index primaires utilisables, ça peut être encore
inefficace si la sélectivité de la requête est faible, et c'est pire si
cela doit passer par des index secondaires n'incluant pas d'autres données
nécessaires sur des éléments non sélectifs) et en stockant des tonne de
données temporaires.

Assez vite il tombe sur les limites de quota (en volume, ou encore plus en
nombre d'I/O qui sollicite beaucoup les disques avec des caches peu
efficaces, et en fin de compte aboutissant à dépasser le quota de temps
d'exécution mais avec cette requête-là on doit tomber sur tous ces quotas
en même temps, mais impossible ici de dire lequel tombe en premier).

De fait on doit penser à une optimisation manuelle de ses requêtes en
évaluant soi-même quelles quantités de données sont séletionnées à chaqué
étape.

Donc ici il suffit d'inverser les deux requêtes : filtrer d'abord sur les
noeuds ayant ce nom puis sélectionner les points restants dans la zone
retenue. La solution sera inversée si la zone est assez petite (ne dépasse
pas la limite raisonnable de taille d'une zone restangulaire de
téléchargement de JOSM par exemple ; toute la France c'est beaucoup trop
gros si on n'a pas déjà effectué une première sélection très sélective).


Le 13 mai 2014 21:46, Christian Quest  a écrit :

> Je pense que c'est la premier area qui cause un dépassement côté
> serveur... et pas que le serveur t'a envoyé 513MB de data ;)
> Sur une plus petite zone (Monaco) ça répond bien qu'il n'a rien trouvé.
>
>
> Le 13 mai 2014 20:55, Mides  a écrit :
>
>>  Bonsoir,
>>
>> À cette requête, pour test, sensée trouver toutes les tags name débutants
>> par cette chaine, "trzetgsqgdfgqsdaze " cette réponse m’est retournée, et
>> pourtant je ne pense pas qu’il y ait beaucoup de tags name où l'on trouve
>> ce mot.
>>
>> Assez étonnant comme résultat.
>>
>> *Requête :*
>>
>> area [name="France"][admin_level="2"]->.zone;
>> (
>>   node(area.zone)
>>   ["name"~"^trzetgsqgdfgqsdaze "];
>> );
>> out skel;
>>
>> *Réponse : *
>>
>> Une erreur est survenue lors de l'exécution de la requête overpass !
>> Voici ce que l'API overpass a retourné :
>> runtime error: Query run out of memory in "query" at line 4 using about
>> 513 MB of RAM.
>>
>> Michel
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête

2014-05-13 Par sujet Christian Quest 
Je pense que c'est la premier area qui cause un dépassement côté serveur...
et pas que le serveur t'a envoyé 513MB de data ;)
Sur une plus petite zone (Monaco) ça répond bien qu'il n'a rien trouvé.


Le 13 mai 2014 20:55, Mides  a écrit :

> Bonsoir,
>
> À cette requête, pour test, sensée trouver toutes les tags name débutants
> par cette chaine, "trzetgsqgdfgqsdaze " cette réponse m'est retournée, et
> pourtant je ne pense pas qu'il y ait beaucoup de tags name où l'on trouve
> ce mot.
>
> Assez étonnant comme résultat.
>
> *Requête :*
>
> area [name="France"][admin_level="2"]->.zone;
> (
>   node(area.zone)
>   ["name"~"^trzetgsqgdfgqsdaze "];
> );
> out skel;
>
> *Réponse : *
>
> Une erreur est survenue lors de l'exécution de la requête overpass ! Voici
> ce que l'API overpass a retourné :
> runtime error: Query run out of memory in "query" at line 4 using about
> 513 MB of RAM.
>
> Michel
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr