Re: [OSM-talk-fr] API OSM et BBOX

2014-04-02 Par sujet Nicolas Dumoulin 
Le mardi 1 avril 2014 16:22:22 Pieren a écrit :
> - soit un filtragre additionel sur les tags (la relation Centre est
> ici http://www.openstreetmap.org/relation/8640 et contient d'autres
> tags discrimants comme "ISO3166-2= FR-F"

Et surtout le tag ref:INSEE=24 :-)

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

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

Re: [OSM-talk-fr] API OSM et BBOX

2014-04-01 Par sujet Mides 
Vu, et l'autre relation se trouve donc ici :

http://www.openstreetmap.org/relation/2750789

Je vais donc voir comment je peux construire cette requête de façon un peu
plus sélective ou utiliser le serveur oapi-fr.openstreetmap.fr

Merci pour tous ces conseils.






Le 1 avril 2014 16:32, sly (sylvain letuffe)  a écrit :

> On mardi 1 avril 2014, Pieren wrote:
> > 2014-04-01 15:28 GMT+02:00 Mides :
> > > Les données "erronées" sont remontées lors d'un appel API concernant la
> > > région Centre : area[name="Centre"][admin_level=4].
> >
> > Héhé... on peut facilement comprendre que d'autres régions du monde
> > ont une région de niveau administratif "4" qui s'appelle aussi
> > "Centre" ;-)
>
> On dirait que c'est exactement ça :
> http://www.openstreetmap.org/relation/2746031
>
> Je ne pense donc pas que l'on puisse parler de données "erronées", au
> mieux de
> requête non conforme au souhait ;-)
>
> > 2014-04-01 15:28 GMT+02:00 Mides :
> > Par contre, comment peut on régler ce souci ?
>
> autre option, utiliser oapi-fr.openstreetmap.fr :
>
> https://wiki.openstreetmap.org/wiki/FR:Servers/api.openstreetmap.fr#Pour_la_France_seulement
>
> Qui, du fait qu'elle ne couvre que la france, ne sortira que la région
> centre
> de france.
>
> --
> sly
> qui suis-je : http://sly.letuffe.org
>
> ___
> 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] API OSM et BBOX

2014-04-01 Par sujet sly (sylvain letuffe) 
On mardi 1 avril 2014, Pieren wrote:
> 2014-04-01 15:28 GMT+02:00 Mides :
> > Les données "erronées" sont remontées lors d'un appel API concernant la
> > région Centre : area[name="Centre"][admin_level=4].
> 
> Héhé... on peut facilement comprendre que d'autres régions du monde
> ont une région de niveau administratif "4" qui s'appelle aussi
> "Centre" ;-)

On dirait que c'est exactement ça :
http://www.openstreetmap.org/relation/2746031

Je ne pense donc pas que l'on puisse parler de données "erronées", au mieux de 
requête non conforme au souhait ;-)

> 2014-04-01 15:28 GMT+02:00 Mides :
> Par contre, comment peut on régler ce souci ?

autre option, utiliser oapi-fr.openstreetmap.fr :
https://wiki.openstreetmap.org/wiki/FR:Servers/api.openstreetmap.fr#Pour_la_France_seulement

Qui, du fait qu'elle ne couvre que la france, ne sortira que la région centre 
de france.

-- 
sly
qui suis-je : http://sly.letuffe.org

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

Re: [OSM-talk-fr] API OSM et BBOX

2014-04-01 Par sujet Pieren 
2014-04-01 15:28 GMT+02:00 Mides :
> Les données "erronées" sont remontées lors d'un appel API concernant la
> région Centre : area[name="Centre"][admin_level=4].

Héhé... on peut facilement comprendre que d'autres régions du monde
ont une région de niveau administratif "4" qui s'appelle aussi
"Centre" ;-)

Je ne connais pas assez bien ce query language pour fournir une
solution directement mais ça passe:
- soit par un filtrage sur un deuxième area ou bbox (sur France uniquement)
- soit un filtragre additionel sur les tags (la relation Centre est
ici http://www.openstreetmap.org/relation/8640 et contient d'autres
tags discrimants comme "ISO3166-2= FR-F"
- soit faire la requête sur un id de relation plutôt que son tag
"name" (ici, le id est 8640)
- soit faire une demande officielle aux autorités africaines et
françaises pour exiger des noms de régions différents ;-))

Pieren

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

Re: [OSM-talk-fr] API OSM et BBOX

2014-04-01 Par sujet Mides 
Les données "erronées" sont remontées lors d'un appel API concernant la
région *Centre : *area[name="Centre"][admin_level=4].

Serveur : http://overpass-api.de/api/

Les deux zones se trouvent ici :

http://www.mides.fr/test/error/?zoom=13&lat=1386513.14434&lon=-169760.04555&layers=B0T

http://www.mides.fr/test/error/?zoom=13&lat=428355.88566&lon=1280594.50032&layers=B0T

*(Edit with josm ne fonctionne pas avec IE)*

Il n'y figure que les polygones mais il me semble qu'il doit y avoir aussi
des nodes.

Par contre, comment peut on régler ce souci ?

Michel


Le 1 avril 2014 09:03, Philippe Verdy  a écrit :

> Il y a des "régions" en Afrique aussi, dans la plupart des pays, même si
> leur dénomination légale peut changer (hormis le Sénégal qui n'a que les
> provinces au niveau 6, et le Soudan du Sud où la structure administrative
> est encore en chantier, et les petits pays comme le Swaziland, les autres
> pays ont des régions même si certaines sont brisées temporairement dans la
> base). Au moins dans les pays francophones cela s'appelle des régions aussi.
>
> Il est possible que tu aies sélectionné une bounding box qui inclue une
> partie des îles tunisiennes ou marocaines ou une partie de leurs eaux
> territoriales (bien qu'à priori les régions ne devraient pas couvrir les
> eaux territoriales définies normalement au niveau 2).
>
> Il peut y avoir des admin_level=4 parasites sur certains chemins résiduels
> (ways) en fait utilisés pour la limite internationale (relation) au niveau
> 2. Regarde les données que tu as obtenues tu pourrais corriger ces valeurs
> incorrectes de admin_level. Sinon il peut rester aussi des noeuds ou
> chemins dupliqués par erreur hors de leur zone mais gardés en référence
> dans une relation, cela se corrige aussi.
>
>
>
>
> Le 31 mars 2014 23:34, mides.map  a écrit :
>
>>  L'api marche vraiment pas mal et même sur de grande bbox, mais il y a
>> un truc que je saisis pas bien.
>>
>> A travers cette extraction, je retrouve des données en Afrique ?? Peut
>> être aussi un erreur de ma part.
>>
>> Pour info, à quel niveau administratif correspond la valeur/clé
>> [admin_level=4] pour l'Afrique.
>>
>> Michel.
>>
>> Mides a écrit :
>>
>> Ok, merci pour la syntaxe.
>>
>>
>> Le 31 mars 2014 15:37, Christian Quest  a écrit
>> :
>>
>>>  Le 31 mars 2014 14:49, Mides  a écrit :
>>>
  Bonjour,


  On arrive quand même à extraire au travers de l'api quelques
 informations allant au-delà d'une couverture géographique se limitant à une
 commune riche en quantité d'informations diverses, qui dans mon cas bien
 précis  se limite à la  bbox[-0.8, 42.7, 2.3, 
 43.829215].



  Par contre, il est vrai que l'on s'approche très rapidement du
 time_out si l'on étant la zone, et cela est beaucoup plus flagrant
 concernant les ways.


  Alors,  comment peut-on faire si l'on souhaite raisonner au niveau du
 territoire ? Je parle au travers de l'utilisation de l'api.


  Reste ensuite,  pour ma requête, c'est-à-dire l'extraction des
 données tag amenity :hospital, à voir comment cela peut être exploitable.


  Certaines zones sont taguées soit en node ou en way, sachant que l'on
 peut travailler au niveau du centroïd pour les polygones le problème se
 règle facilement,  mais malheureusement on trouve aussi les deux
 possibilités, node et way,  pour le même objet, voire des polygones à
 l'intérieur d'autres polygones.


  Par exemple ici : http://www.mides.fr/test/hospital

 *(Rouge centroïd, mauve node)*


  Toujours est-il, je vous remercie tous deux pour l'aide.


  Michel

>>>
>>>  Avec une requête overpass, tu peux préciser le timeout et tu peux
>>> aussi préciser une zone particulière définie par une relation boundary=*
>>> dans OSM.
>>>
>>>  Exemple:
>>>
>>>  [timeout:1800];
>>> area[name="Midi-Pyrénées"][admin_level=4]->.zone;
>>> node(area.zone)[amenity=hospital];
>>> out meta;
>>> way(area.zone)[amenity=hospital];out meta;
>>> >;out meta;
>>>
>>>
>>>  --
>>> Christian Quest - OpenStreetMap France
>>> Conférence "State Of The Map" France du 4 au 6 avril à 
>>> Paris
>>>
>>> ___
>>> 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
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-

Re: [OSM-talk-fr] API OSM et BBOX

2014-04-01 Par sujet Mides 
On retrouve ces données sur deux zones bien précises, mais comme j'ai
segmenté l'extraction au niveau des
area[name="Midi-Pyrénées"][admin_level=4],  je ne sais pas à quel moment
ces valeurs ont été intégrées. Je regarderai cela à l'occasion.


http://www.mides.fr/test/hospital/


Le 1 avril 2014 09:03, Philippe Verdy  a écrit :

> Il y a des "régions" en Afrique aussi, dans la plupart des pays, même si
> leur dénomination légale peut changer (hormis le Sénégal qui n'a que les
> provinces au niveau 6, et le Soudan du Sud où la structure administrative
> est encore en chantier, et les petits pays comme le Swaziland, les autres
> pays ont des régions même si certaines sont brisées temporairement dans la
> base). Au moins dans les pays francophones cela s'appelle des régions aussi.
>
> Il est possible que tu aies sélectionné une bounding box qui inclue une
> partie des îles tunisiennes ou marocaines ou une partie de leurs eaux
> territoriales (bien qu'à priori les régions ne devraient pas couvrir les
> eaux territoriales définies normalement au niveau 2).
>
> Il peut y avoir des admin_level=4 parasites sur certains chemins résiduels
> (ways) en fait utilisés pour la limite internationale (relation) au niveau
> 2. Regarde les données que tu as obtenues tu pourrais corriger ces valeurs
> incorrectes de admin_level. Sinon il peut rester aussi des noeuds ou
> chemins dupliqués par erreur hors de leur zone mais gardés en référence
> dans une relation, cela se corrige aussi.
>
>
>
>
> Le 31 mars 2014 23:34, mides.map  a écrit :
>
>>  L'api marche vraiment pas mal et même sur de grande bbox, mais il y a
>> un truc que je saisis pas bien.
>>
>> A travers cette extraction, je retrouve des données en Afrique ?? Peut
>> être aussi un erreur de ma part.
>>
>> Pour info, à quel niveau administratif correspond la valeur/clé
>> [admin_level=4] pour l'Afrique.
>>
>> Michel.
>>
>> Mides a écrit :
>>
>> Ok, merci pour la syntaxe.
>>
>>
>> Le 31 mars 2014 15:37, Christian Quest  a écrit
>> :
>>
>>>  Le 31 mars 2014 14:49, Mides  a écrit :
>>>
  Bonjour,


  On arrive quand même à extraire au travers de l'api quelques
 informations allant au-delà d'une couverture géographique se limitant à une
 commune riche en quantité d'informations diverses, qui dans mon cas bien
 précis  se limite à la  bbox[-0.8, 42.7, 2.3, 
 43.829215].



  Par contre, il est vrai que l'on s'approche très rapidement du
 time_out si l'on étant la zone, et cela est beaucoup plus flagrant
 concernant les ways.


  Alors,  comment peut-on faire si l'on souhaite raisonner au niveau du
 territoire ? Je parle au travers de l'utilisation de l'api.


  Reste ensuite,  pour ma requête, c'est-à-dire l'extraction des
 données tag amenity :hospital, à voir comment cela peut être exploitable.


  Certaines zones sont taguées soit en node ou en way, sachant que l'on
 peut travailler au niveau du centroïd pour les polygones le problème se
 règle facilement,  mais malheureusement on trouve aussi les deux
 possibilités, node et way,  pour le même objet, voire des polygones à
 l'intérieur d'autres polygones.


  Par exemple ici : http://www.mides.fr/test/hospital

 *(Rouge centroïd, mauve node)*


  Toujours est-il, je vous remercie tous deux pour l'aide.


  Michel

>>>
>>>  Avec une requête overpass, tu peux préciser le timeout et tu peux
>>> aussi préciser une zone particulière définie par une relation boundary=*
>>> dans OSM.
>>>
>>>  Exemple:
>>>
>>>  [timeout:1800];
>>> area[name="Midi-Pyrénées"][admin_level=4]->.zone;
>>> node(area.zone)[amenity=hospital];
>>> out meta;
>>> way(area.zone)[amenity=hospital];out meta;
>>> >;out meta;
>>>
>>>
>>>  --
>>> Christian Quest - OpenStreetMap France
>>> Conférence "State Of The Map" France du 4 au 6 avril à 
>>> Paris
>>>
>>> ___
>>> 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
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] API OSM et BBOX

2014-04-01 Par sujet Philippe Verdy 
Il y a des "régions" en Afrique aussi, dans la plupart des pays, même si
leur dénomination légale peut changer (hormis le Sénégal qui n'a que les
provinces au niveau 6, et le Soudan du Sud où la structure administrative
est encore en chantier, et les petits pays comme le Swaziland, les autres
pays ont des régions même si certaines sont brisées temporairement dans la
base). Au moins dans les pays francophones cela s'appelle des régions aussi.

Il est possible que tu aies sélectionné une bounding box qui inclue une
partie des îles tunisiennes ou marocaines ou une partie de leurs eaux
territoriales (bien qu'à priori les régions ne devraient pas couvrir les
eaux territoriales définies normalement au niveau 2).

Il peut y avoir des admin_level=4 parasites sur certains chemins résiduels
(ways) en fait utilisés pour la limite internationale (relation) au niveau
2. Regarde les données que tu as obtenues tu pourrais corriger ces valeurs
incorrectes de admin_level. Sinon il peut rester aussi des noeuds ou
chemins dupliqués par erreur hors de leur zone mais gardés en référence
dans une relation, cela se corrige aussi.




Le 31 mars 2014 23:34, mides.map  a écrit :

>  L'api marche vraiment pas mal et même sur de grande bbox, mais il y a un
> truc que je saisis pas bien.
>
> A travers cette extraction, je retrouve des données en Afrique ?? Peut
> être aussi un erreur de ma part.
>
> Pour info, à quel niveau administratif correspond la valeur/clé
> [admin_level=4] pour l'Afrique.
>
> Michel.
>
> Mides a écrit :
>
> Ok, merci pour la syntaxe.
>
>
> Le 31 mars 2014 15:37, Christian Quest  a écrit :
>
>>  Le 31 mars 2014 14:49, Mides  a écrit :
>>
>>>  Bonjour,
>>>
>>>
>>>  On arrive quand même à extraire au travers de l'api quelques
>>> informations allant au-delà d'une couverture géographique se limitant à une
>>> commune riche en quantité d'informations diverses, qui dans mon cas bien
>>> précis  se limite à la  bbox[-0.8, 42.7, 2.3, 
>>> 43.829215].
>>>
>>>
>>>
>>>  Par contre, il est vrai que l'on s'approche très rapidement du
>>> time_out si l'on étant la zone, et cela est beaucoup plus flagrant
>>> concernant les ways.
>>>
>>>
>>>  Alors,  comment peut-on faire si l'on souhaite raisonner au niveau du
>>> territoire ? Je parle au travers de l'utilisation de l'api.
>>>
>>>
>>>  Reste ensuite,  pour ma requête, c'est-à-dire l'extraction des données
>>> tag amenity :hospital, à voir comment cela peut être exploitable.
>>>
>>>
>>>  Certaines zones sont taguées soit en node ou en way, sachant que l'on
>>> peut travailler au niveau du centroïd pour les polygones le problème se
>>> règle facilement,  mais malheureusement on trouve aussi les deux
>>> possibilités, node et way,  pour le même objet, voire des polygones à
>>> l'intérieur d'autres polygones.
>>>
>>>
>>>  Par exemple ici : http://www.mides.fr/test/hospital
>>>
>>> *(Rouge centroïd, mauve node)*
>>>
>>>
>>>  Toujours est-il, je vous remercie tous deux pour l'aide.
>>>
>>>
>>>  Michel
>>>
>>
>>  Avec une requête overpass, tu peux préciser le timeout et tu peux aussi
>> préciser une zone particulière définie par une relation boundary=* dans OSM.
>>
>>  Exemple:
>>
>>  [timeout:1800];
>> area[name="Midi-Pyrénées"][admin_level=4]->.zone;
>> node(area.zone)[amenity=hospital];
>> out meta;
>> way(area.zone)[amenity=hospital];out meta;
>> >;out meta;
>>
>>
>>  --
>> Christian Quest - OpenStreetMap France
>> Conférence "State Of The Map" France du 4 au 6 avril à 
>> Paris
>>
>> ___
>> 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] API OSM et BBOX

2014-03-31 Par sujet mides.map 




L'api marche vraiment pas mal et même sur de grande bbox, mais il y a
un truc que je saisis pas bien.

A travers cette extraction, je retrouve des données en Afrique ?? Peut
être aussi un erreur de ma part. 

Pour info, à quel niveau administratif correspond la valeur/clé
[admin_level=4] pour l'Afrique.

Michel. 

Mides a écrit :

  Ok, merci pour la syntaxe. 
  
  
  Le 31 mars 2014 15:37, Christian Quest 
a écrit :
  


Le 31 mars 2014 14:49, Mides 
a écrit :

  
  Bonjour, 
  
  
  On arrive quand même à extraire au travers
de l’api quelques
informations allant au-delà d’une couverture géographique se limitant à
une
commune riche en quantité d’informations diverses, qui dans mon cas
bien précis  se limite à la  bbox[-0.8,
42.7, 2.3, 43.829215].
  
  
  
  Par contre, il est vrai que l’on s’approche
très rapidement
du time_out si l’on étant la zone, et cela est beaucoup plus flagrant
concernant
les ways. 
  
  
  Alors,  comment peut-on
faire si l’on souhaite raisonner au niveau du territoire ? Je parle au
travers de l’utilisation de l’api. 
  
  
  Reste ensuite,  pour
ma requête, c'est-à-dire l’extraction des données tag
amenity :hospital, à
voir comment cela peut être exploitable.
  
  
  Certaines zones sont taguées soit en node ou
en way, sachant
que l’on peut travailler au niveau du centroïd pour les polygones le
problème se
règle facilement,  mais malheureusement
on trouve aussi les deux possibilités, node et way,  pour le même
objet, voire des polygones à l’intérieur
d’autres polygones.  
  
  
  
  Par exemple ici : http://www.mides.fr/test/hospital
  (Rouge centroïd, mauve node)
  
  
  Toujours est-il, je vous remercie tous deux
pour l’aide. 
  
  
  Michel
  



Avec une requête overpass, tu peux préciser le timeout et tu
peux aussi préciser une zone particulière définie par une relation
boundary=* dans OSM.


Exemple:



[timeout:1800];
area[name="Midi-Pyrénées"][admin_level=4]->.zone;
node(area.zone)[amenity=hospital];
out meta;
way(area.zone)[amenity=hospital];out meta;
>;out meta;








-- 
Christian Quest - OpenStreetMap France
Conférence "State Of The Map" France du 4 au 6 avril à
Paris




___
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] API OSM et BBOX

2014-03-31 Par sujet Mides 
Ok, merci pour la syntaxe.


Le 31 mars 2014 15:37, Christian Quest  a écrit :

> Le 31 mars 2014 14:49, Mides  a écrit :
>
>> Bonjour,
>>
>>
>> On arrive quand même à extraire au travers de l'api quelques informations
>> allant au-delà d'une couverture géographique se limitant à une commune
>> riche en quantité d'informations diverses, qui dans mon cas bien précis  se
>> limite à la  bbox[-0.8, 42.7, 2.3, 
>> 43.829215].
>>
>>
>>
>> Par contre, il est vrai que l'on s'approche très rapidement du time_out
>> si l'on étant la zone, et cela est beaucoup plus flagrant concernant les
>> ways.
>>
>>
>> Alors,  comment peut-on faire si l'on souhaite raisonner au niveau du
>> territoire ? Je parle au travers de l'utilisation de l'api.
>>
>>
>> Reste ensuite,  pour ma requête, c'est-à-dire l'extraction des données
>> tag amenity :hospital, à voir comment cela peut être exploitable.
>>
>>
>> Certaines zones sont taguées soit en node ou en way, sachant que l'on
>> peut travailler au niveau du centroïd pour les polygones le problème se
>> règle facilement,  mais malheureusement on trouve aussi les deux
>> possibilités, node et way,  pour le même objet, voire des polygones à
>> l'intérieur d'autres polygones.
>>
>>
>> Par exemple ici : http://www.mides.fr/test/hospital
>>
>> *(Rouge centroïd, mauve node)*
>>
>>
>>  Toujours est-il, je vous remercie tous deux pour l'aide.
>>
>>
>> Michel
>>
>
> Avec une requête overpass, tu peux préciser le timeout et tu peux aussi
> préciser une zone particulière définie par une relation boundary=* dans OSM.
>
> Exemple:
>
> [timeout:1800];
> area[name="Midi-Pyrénées"][admin_level=4]->.zone;
> node(area.zone)[amenity=hospital];
> out meta;
> way(area.zone)[amenity=hospital];out meta;
> >;out meta;
>
>
> --
> Christian Quest - OpenStreetMap France
> Conférence "State Of The Map" France du 4 au 6 avril à 
> Paris
>
> ___
> 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] API OSM et BBOX

2014-03-31 Par sujet Christian Quest 
Le 31 mars 2014 14:49, Mides  a écrit :

> Bonjour,
>
>
> On arrive quand même à extraire au travers de l'api quelques informations
> allant au-delà d'une couverture géographique se limitant à une commune
> riche en quantité d'informations diverses, qui dans mon cas bien précis  se
> limite à la  bbox[-0.8, 42.7, 2.3, 
> 43.829215].
>
>
>
> Par contre, il est vrai que l'on s'approche très rapidement du time_out si
> l'on étant la zone, et cela est beaucoup plus flagrant concernant les ways.
>
>
> Alors,  comment peut-on faire si l'on souhaite raisonner au niveau du
> territoire ? Je parle au travers de l'utilisation de l'api.
>
>
> Reste ensuite,  pour ma requête, c'est-à-dire l'extraction des données tag
> amenity :hospital, à voir comment cela peut être exploitable.
>
>
> Certaines zones sont taguées soit en node ou en way, sachant que l'on peut
> travailler au niveau du centroïd pour les polygones le problème se règle
> facilement,  mais malheureusement on trouve aussi les deux possibilités,
> node et way,  pour le même objet, voire des polygones à l'intérieur
> d'autres polygones.
>
>
> Par exemple ici : http://www.mides.fr/test/hospital
>
> *(Rouge centroïd, mauve node)*
>
>
>  Toujours est-il, je vous remercie tous deux pour l'aide.
>
>
> Michel
>

Avec une requête overpass, tu peux préciser le timeout et tu peux aussi
préciser une zone particulière définie par une relation boundary=* dans OSM.

Exemple:

[timeout:1800];
area[name="Midi-Pyrénées"][admin_level=4]->.zone;
node(area.zone)[amenity=hospital];
out meta;
way(area.zone)[amenity=hospital];out meta;
>;out meta;


-- 
Christian Quest - OpenStreetMap France
Conférence "State Of The Map" France du 4 au 6 avril à
Paris
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] API OSM et BBOX

2014-03-31 Par sujet Mides 
Bonjour,


On arrive quand même à extraire au travers de l'api quelques informations
allant au-delà d'une couverture géographique se limitant à une commune
riche en quantité d'informations diverses, qui dans mon cas bien précis  se
limite à la  bbox[-0.8, 42.7, 2.3,
43.829215].



Par contre, il est vrai que l'on s'approche très rapidement du time_out si
l'on étant la zone, et cela est beaucoup plus flagrant concernant les ways.


Alors,  comment peut-on faire si l'on souhaite raisonner au niveau du
territoire ? Je parle au travers de l'utilisation de l'api.


Reste ensuite,  pour ma requête, c'est-à-dire l'extraction des données tag
amenity :hospital, à voir comment cela peut être exploitable.


Certaines zones sont taguées soit en node ou en way, sachant que l'on peut
travailler au niveau du centroïd pour les polygones le problème se règle
facilement,  mais malheureusement on trouve aussi les deux possibilités,
node et way,  pour le même objet, voire des polygones à l'intérieur
d'autres polygones.


Par exemple ici : http://www.mides.fr/test/hospital

*(Rouge centroïd, mauve node)*


 Toujours est-il, je vous remercie tous deux pour l'aide.


Michel


Le 31 mars 2014 12:29, Philippe Verdy  a écrit :

> Attention, pour de nombreuses requêtes, la bbox ralentit souvent
> considérablement la requête sur le serveur si celle-ci est trop grande (au
> point qu'alors le serveur va finir par un timeout au bout de 2 minutes).
>
> Si ta bbox couvre toute la France, il y a de très fortes chances que ta
> requête se termine par un timeout. En gros la combinaison bbox+critères sur
> les tags échoue presque toujours dans une bbox couvrant beaucoup plus
> qu'une commune très dense comme Paris ou toute une région et le résultat
> est encore incertain à l'échelle d'un département (hors Paris ou zone
> similaire à densité élevée d'informations).
>
> C'est encore plus vrai si au lieu de sélectionner des noueds ou des
> chemins (qui sont indexés géographiquement) tu cherches des relations (là
> ce sera très coûteux, car apparement les relations ne sont pas indexées
> géographiquement avec une bbox de leurs objets membres, ou bien cet index
> est très peu sélectif à cause des nombreux recouvrements de bbox)
>
> Dans tous mes essais avec un bbox, j'ai eu soit des timeout, soit des
> temps de requête excessivement longs même pour ne retourner que quelques
> objets à la fin. Alors qu'on a un résultat très rapide en supprimant tout
> bonnement la bbox et ne gardant que les critères de tags.
>
> En gros pour les bbox, il faut se limiter à une taille correspondant plus
> ou moins à la limite de taille acceptée par le serveur dans un
> téléchargement de zone rectangulaire dans JOSM. Selon les endroits cela
> peut aller à seulement quelques kilomètres de large, mais même pour
> chercher des ilots dans l'océan (avec peu de détails) on voit des temps
> d'exécution très longs si on précise à la fois une bbox et les critères de
> tags (alors qu'on a un résultat rapide avec seulement la bbox) au delà de
> quelques centaines de miles.
>
> Il semble que le serveur systématiquement va chercher à lister tous les
> noeuds dans la base dans la bbox puis chercher à les associer aux objets,
> mais il ne sait pas effectuer une fusion. Le serveur ne sait visiblement
> pas automatiquement évaluer la sélectivité statistique d'une bbox, il va
> systématiquement construire un très gros index temporaire puis évaluer les
> autres critères en faisant un "full scan" de ce gros index avec les autres
> critères.
>
> Il semble en plus que si le serveur décide de créer un temporaire pour les
> objets dans la bbox, la taille de cet index est très importante (on atteint
> vite les millions de noeuds, qui ne tiennent pas en mémoire et déclenchent
> de couteux accès physiques au disques qui ralentissent tout), et l'index ne
> semble pas indexé correctement pour faire une sélection avec les tags
> demandés, mais il procède par fusion par un table scan pour créer le second
> index correspondant à la sélection à retourner. L'extension géographique
> apparemment n'inclue dans le premier index aucun des tags permettant une
> fusion efficace.
>
> Si les autres critères sont suffisants, on peut souvent se passer
> totalement de la bbox, quitte à faire un tri filtrage final coté client.
> On peut cependant réécrire la requête en deux parties, la première
> sélectionnant les objets par critère (tags) et en la chainant ensuite par
> une seconde requête sur la bbox.
>
> C'est aussi un bonne raison pour laquelle on doit parfois garder certains
> tags sélectifs sur les objets membres pour ne pas avoir à les chercher dans
> une relation.
>
> Bref évaluer le nombre moyen de noeuds dans la bbox (dommage que l'API ne
> permette pas apparemment de le retourner smplement à partir de l'index
> géographique des noeuds) et le nombre d'objets correspondant aux crières
> sans

Re: [OSM-talk-fr] API OSM et BBOX

2014-03-31 Par sujet Philippe Verdy 
Attention, pour de nombreuses requêtes, la bbox ralentit souvent
considérablement la requête sur le serveur si celle-ci est trop grande (au
point qu'alors le serveur va finir par un timeout au bout de 2 minutes).

Si ta bbox couvre toute la France, il y a de très fortes chances que ta
requête se termine par un timeout. En gros la combinaison bbox+critères sur
les tags échoue presque toujours dans une bbox couvrant beaucoup plus
qu'une commune très dense comme Paris ou toute une région et le résultat
est encore incertain à l'échelle d'un département (hors Paris ou zone
similaire à densité élevée d'informations).

C'est encore plus vrai si au lieu de sélectionner des noueds ou des chemins
(qui sont indexés géographiquement) tu cherches des relations (là ce sera
très coûteux, car apparement les relations ne sont pas indexées
géographiquement avec une bbox de leurs objets membres, ou bien cet index
est très peu sélectif à cause des nombreux recouvrements de bbox)

Dans tous mes essais avec un bbox, j'ai eu soit des timeout, soit des temps
de requête excessivement longs même pour ne retourner que quelques objets à
la fin. Alors qu'on a un résultat très rapide en supprimant tout bonnement
la bbox et ne gardant que les critères de tags.

En gros pour les bbox, il faut se limiter à une taille correspondant plus
ou moins à la limite de taille acceptée par le serveur dans un
téléchargement de zone rectangulaire dans JOSM. Selon les endroits cela
peut aller à seulement quelques kilomètres de large, mais même pour
chercher des ilots dans l'océan (avec peu de détails) on voit des temps
d'exécution très longs si on précise à la fois une bbox et les critères de
tags (alors qu'on a un résultat rapide avec seulement la bbox) au delà de
quelques centaines de miles.

Il semble que le serveur systématiquement va chercher à lister tous les
noeuds dans la base dans la bbox puis chercher à les associer aux objets,
mais il ne sait pas effectuer une fusion. Le serveur ne sait visiblement
pas automatiquement évaluer la sélectivité statistique d'une bbox, il va
systématiquement construire un très gros index temporaire puis évaluer les
autres critères en faisant un "full scan" de ce gros index avec les autres
critères.

Il semble en plus que si le serveur décide de créer un temporaire pour les
objets dans la bbox, la taille de cet index est très importante (on atteint
vite les millions de noeuds, qui ne tiennent pas en mémoire et déclenchent
de couteux accès physiques au disques qui ralentissent tout), et l'index ne
semble pas indexé correctement pour faire une sélection avec les tags
demandés, mais il procède par fusion par un table scan pour créer le second
index correspondant à la sélection à retourner. L'extension géographique
apparemment n'inclue dans le premier index aucun des tags permettant une
fusion efficace.

Si les autres critères sont suffisants, on peut souvent se passer
totalement de la bbox, quitte à faire un tri filtrage final coté client.
On peut cependant réécrire la requête en deux parties, la première
sélectionnant les objets par critère (tags) et en la chainant ensuite par
une seconde requête sur la bbox.

C'est aussi un bonne raison pour laquelle on doit parfois garder certains
tags sélectifs sur les objets membres pour ne pas avoir à les chercher dans
une relation.

Bref évaluer le nombre moyen de noeuds dans la bbox (dommage que l'API ne
permette pas apparemment de le retourner smplement à partir de l'index
géographique des noeuds) et le nombre d'objets correspondant aux crières
sans la bbox.

Le serveur d'API devrait être amélioré de ce côté là dans son optimiseur
statistique de requêtes de façon à calculer un plan d'exécution adéquat.
Pour l'instant il suppose dans son plan d'exécution que la bbox est assez
sélective pour ne pas retourner de grosses quantités de noeuds dans l'index
géographique.

Un exemple de requête qui échoue: sélectionner la liste des collectivités
territoriales d'un niveau donné en France métropolitaine avec une bbox et
boundary=administrative et admin_level=4 à 8.

On a intérêt alors à rechercher la liste des id's en parcourant la France à
partir d'un point et recherchant les ways connectés puis des relations
dépendantes avec une récursion pour faire le tour et trouver les autres
zones adjascentes une fois qu'on a trouvé un id pour trouver les autres.
Dans ce cas aucune utilisation de bbox il suffit de partie d'un noeud ou
d'un chemin de frontière connu. Mais l'API ne sait pas faire seule ce genre
de parcours, on peut le faire avec du code ou manuellement en préchargeant
une petite zone sélectionnée sur la carte (en choisissant un lieu sur la
frontière où il ne semble pas y avoir trop d'objets adjacents.

Sinon, si on veut vraiment faire ce genre de requête il faudra monter sa
propre base de données avec une limite plus permissive de ressources
temps/mémoire.stockage par requête (ce que font les serveurs spécailisés
comem Nominatim, ou Osmose dans leurs propres bases où ils construise

Re: [OSM-talk-fr] API OSM et BBOX

2014-03-31 Par sujet V de Chateau-Thierry 
Bonjour,

> De : "Mides"
>
> Bonjour, je cherche un peu d'aide quant à savoir comment inclure des 
> paramètres bbox
> dans un requête. API
> J'utilise la syntaxe suivante, http://oapi-fr.openstreetmap.fr/xapi/?
> node[amenity=hospital]&bbox[-0.818714,42.725465,2.323375,43.829215], mais 
> apparemment
> les données bbox ne sont pas prisent en compte et tout le territoire est 
> sélectionné. 
> Si des fois quelqu’un passe par là. 

Tu dois légèrement modifier ta syntaxe : pas de '&', et 'bbox' à l'intérieur 
des [].
de:
node[amenity=hospital]&bbox[-0.818714,42.725465,2.323375,43.829215]
à :
node[amenity=hospital][bbox=-0.818714,42.725465,2.323375,43.829215]
cf.:http://wiki.openstreetmap.org/wiki/Xapi#BBox_Predicates

vincent

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

[OSM-talk-fr] API OSM et BBOX

2014-03-31 Par sujet Mides 
Bonjour, je cherche un peu d'aide quant à savoir comment inclure des
paramètres bbox dans un requête. API

J'utilise la syntaxe suivante,
http://oapi-fr.openstreetmap.fr/xapi/?node[amenity=hospital]&bbox[-0.818714,42.725465,2.323375,43.829215],
mais apparemment les données bbox ne sont pas prisent en compte et tout le
territoire est sélectionné.

Si des fois quelqu'un passe par là.

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