Re: [OSM-talk-fr] Requête overpass turbo - boulangeries à plus de 50 mètres d'un arrêt de bus

[Thomas Ruchin]

Au cas où ce serait utile à d'autres, voici le code dans over-pass (cette
fois-ci, j'ai pris les supérettes et supermarchés) :










*[out:xml];area[name="Montrouge"];nwr[highway=bus_stop](area)->.a;
(nwr["shop"~"supermarket|convenience"](area); -
nwr(around.a:50)["shop"~"supermarket|convenience"];);out meta;>;out
meta;out meta;>;out meta;*



Thomas

Le ven. 20 déc. 2019 à 17:42, marc marc  a
écrit :

> alors il faut faire une soustraction :
> (
> toutes les boulangeries de la commune;
> -
> les boulangeries bien déservies renseignée par la requête ci dessous;
> );
>
> https://wiki.openstreetmap.org/wiki/FR:Overpass_API/Overpass_QL#Difference
> l'erreur la plus courante est d'oublier le ; après chacun des 2 blocs.
> je te laisse essayer ? si tu bloques, je m'y colles :)
>
>
> Le 20.12.19 à 17:37, Thomas Ruchin a écrit :
> > Merci c'est génial.
> > Mais je veux identifier les boulangeries mal desservies. Donc celles à
> > plus de 50 mètres (pas celles à moins de 50 mètres).
> >
> > Le ven. 20 déc. 2019 à 17:13, marc marc  > > a écrit :
> >
> > Le 20.12.19 à 16:57, Thomas Ruchin a écrit :
> > > Dans ma commune, je veux identifier les boulangeries (way, nodes,
> > > relations) qui sont à plus de 50 mètres d'un arrêt de bus.
> >
> > simplifie toi la vie :-)
> > - pas besoin de nomer un jeux de donnée si tu ne l'utilises qu'une
> fois
> > - utilise nwr pour avoir en une fois les objets de type
> > node+way+relation
> >
> > https://overpass-turbo.eu/s/P9e
> > [out:xml];
> > area[name="Montrouge"];
> > nwr[highway=bus_stop](area);
> > nwr(around:50)[shop=bakery];
> > out meta;>;out meta;
> > ___
> > 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] Requête overpass turbo - boulangeries à plus de 50 mètres d'un arrêt de bus

[marc marc]

alors il faut faire une soustraction :
(
toutes les boulangeries de la commune;
-
les boulangeries bien déservies renseignée par la requête ci dessous;
);

https://wiki.openstreetmap.org/wiki/FR:Overpass_API/Overpass_QL#Difference
l'erreur la plus courante est d'oublier le ; après chacun des 2 blocs.
je te laisse essayer ? si tu bloques, je m'y colles :)


Le 20.12.19 à 17:37, Thomas Ruchin a écrit :
> Merci c'est génial.
> Mais je veux identifier les boulangeries mal desservies. Donc celles à
> plus de 50 mètres (pas celles à moins de 50 mètres).
> 
> Le ven. 20 déc. 2019 à 17:13, marc marc  > a écrit :
> 
> Le 20.12.19 à 16:57, Thomas Ruchin a écrit :
> > Dans ma commune, je veux identifier les boulangeries (way, nodes,
> > relations) qui sont à plus de 50 mètres d'un arrêt de bus.
> 
> simplifie toi la vie :-)
> - pas besoin de nomer un jeux de donnée si tu ne l'utilises qu'une fois
> - utilise nwr pour avoir en une fois les objets de type
> node+way+relation
> 
> https://overpass-turbo.eu/s/P9e
> [out:xml];
> area[name="Montrouge"];
> nwr[highway=bus_stop](area);
> nwr(around:50)[shop=bakery];
> out meta;>;out meta;
> ___
> 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] Requête overpass turbo - boulangeries à plus de 50 mètres d'un arrêt de bus

[Thomas Ruchin]

Merci c'est génial.
Mais je veux identifier les boulangeries mal desservies. Donc celles à plus
de 50 mètres (pas celles à moins de 50 mètres).

Le ven. 20 déc. 2019 à 17:13, marc marc  a
écrit :

> Le 20.12.19 à 16:57, Thomas Ruchin a écrit :
> > Dans ma commune, je veux identifier les boulangeries (way, nodes,
> > relations) qui sont à plus de 50 mètres d'un arrêt de bus.
>
> simplifie toi la vie :-)
> - pas besoin de nomer un jeux de donnée si tu ne l'utilises qu'une fois
> - utilise nwr pour avoir en une fois les objets de type node+way+relation
>
> https://overpass-turbo.eu/s/P9e
> [out:xml];
> area[name="Montrouge"];
> nwr[highway=bus_stop](area);
> nwr(around:50)[shop=bakery];
> out meta;>;out meta;
> ___
> 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] Requête overpass turbo - boulangeries à plus de 50 mètres d'un arrêt de bus

[marc marc]

n'aurais-tu pas entre temps forcé dans tes paramètres d'utiliser un
autre serveur overpass api ? le serveur osm-fr par ex ne supporte pas
encore nwr (honte à moi, je ne l'ai pas encore fait la maj)

Le 20.12.19 à 17:22, Cyrille37 OSM a écrit :
> Merci Marc, encore une excellente contribution :-)
> 
> Et paf, je tombe sur un bug: la version overpass ne doit pas être la
> même sur HTTP que HTTPS pour overpass-turbo.eu. La requête fonctionne
> bien sur le https, mais la syntaxe échoue sur http à cause du "nwr".
> 
> Error: line 3: parse error: Unknown type "nwr"
> Error: line 3: static error: For the attribute "type" of the element
> "query" the only allowed values are "node", "way", "relation" or "area".
> 
> Cyrille37.
> 
> Le 20/12/2019 à 17:13, marc marc a écrit :
>> Le 20.12.19 à 16:57, Thomas Ruchin a écrit :
>>> Dans ma commune, je veux identifier les boulangeries (way, nodes,
>>> relations) qui sont à plus de 50 mètres d'un arrêt de bus.
>> simplifie toi la vie :-)
>> - pas besoin de nomer un jeux de donnée si tu ne l'utilises qu'une fois
>> - utilise nwr pour avoir en une fois les objets de type node+way+relation
>>
>> https://overpass-turbo.eu/s/P9e
>> [out:xml];
>> area[name="Montrouge"];
>> nwr[highway=bus_stop](area);
>> nwr(around:50)[shop=bakery];
>> out meta;>;out meta;
>> ___
>> 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] Requête overpass turbo - boulangeries à plus de 50 mètres d'un arrêt de bus

[Cyrille37 OSM]

Merci Marc, encore une excellente contribution :-)

Et paf, je tombe sur un bug: la version overpass ne doit pas être la 
même sur HTTP que HTTPS pour overpass-turbo.eu. La requête fonctionne 
bien sur le https, mais la syntaxe échoue sur http à cause du "nwr".


Error: line 3: parse error: Unknown type "nwr"
Error: line 3: static error: For the attribute "type" of the element 
"query" the only allowed values are "node", "way", "relation" or "area".


Cyrille37.

Le 20/12/2019 à 17:13, marc marc a écrit :

Le 20.12.19 à 16:57, Thomas Ruchin a écrit :

Dans ma commune, je veux identifier les boulangeries (way, nodes,
relations) qui sont à plus de 50 mètres d'un arrêt de bus.

simplifie toi la vie :-)
- pas besoin de nomer un jeux de donnée si tu ne l'utilises qu'une fois
- utilise nwr pour avoir en une fois les objets de type node+way+relation

https://overpass-turbo.eu/s/P9e
[out:xml];
area[name="Montrouge"];
nwr[highway=bus_stop](area);
nwr(around:50)[shop=bakery];
out meta;>;out meta;
___
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] Requête overpass turbo - boulangeries à plus de 50 mètres d'un arrêt de bus

[marc marc]

Le 20.12.19 à 16:57, Thomas Ruchin a écrit :
> Dans ma commune, je veux identifier les boulangeries (way, nodes,
> relations) qui sont à plus de 50 mètres d'un arrêt de bus.

simplifie toi la vie :-)
- pas besoin de nomer un jeux de donnée si tu ne l'utilises qu'une fois
- utilise nwr pour avoir en une fois les objets de type node+way+relation

https://overpass-turbo.eu/s/P9e
[out:xml];
area[name="Montrouge"];
nwr[highway=bus_stop](area);
nwr(around:50)[shop=bakery];
out meta;>;out meta;
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Requête overpass turbo - boulangeries à plus de 50 mètres d'un arrêt de bus

[Thomas Ruchin]

Bonjour,

J'ai une petite requête que je ne parviens pas à construire.
Dans ma commune, je veux identifier les boulangeries (way, nodes,
relations) qui sont à plus de 50 mètres d'un arrêt de bus.

J'ai bien vu comment trouver les arrêts de bus à moins de 50 mètres d'une
boulangerie, mais pas l'inverse.

Merci pour votre aide.
Thomas

  area[name="Montrouge"];
  node(area)[highway=bus_stop]->.bus_stops;
  (
way(around.bus_stops:50)[shop=bakery];
node(around.bus_stops:50)[shop=bakery];
  );
  (._;>;);
  out meta;
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Requête Overpass ou mapCSS : comment tester key1=key2 ?

[Yves P.]

> Comment sélectionner les objets OSM ayant la même valeur dupliquée dans 2 
> clés différentes ?
> Je n’arrive pas à faire ça avec mapCSS, et pas mieux avec Overpass.
> 
Une petite pause s’impose : je viens de trouver pour mapCSS :

*[tag(image)=tag(picture)]

Je suis quand même preneur pour Overpass.

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

[OSM-talk-fr] Requête Overpass ou mapCSS : comment tester key1=key2 ?

[Yves P.]

Bonjour,

Comment sélectionner les objets OSM ayant la même valeur dupliquée dans 2 clés 
différentes ?
Je n’arrive pas à faire ça avec mapCSS, et pas mieux avec Overpass.

—
Yves

PS:  requêtes faites dans JOSM


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

Re: [OSM-talk-fr] Requête overpass [était : Fond de carte avec frontières de pays]

[Yves P.]

>> 
>> Sélectionner uniquement les objets (modifiés) qui se trouvent dans un pays 
>> donné.
> Les objets modifiés dernièrement, depuis une certaine date ?
> 
> 
Ceux que j’ai corrigé moi-même et que je dois envoyer sur le serveur.

J’utilise :
« inview -modified » pour voir ceux qui me restent à corriger
« inview (new or modified) » pour sélectionner ceux que je dois envoyer.

inview car au préalable, je zoom sur le « pays » qui m’intéresse.

>> Comme je ne sais pas faire facilement et rapidement la requête dans JOSM, je 
>> détermine visuellement le pays.
> moi je ne sais pas faire facilement mais quand j'en ai trouvé une je la garde 
> précieusement vu le temps que cela fait gagner !
> 
Ce n’est pas une requête que je réutilise régulièrement (du moins pour le 
moment).
Mais je les retrouve dans l’historique de l’assistant requête de JOSM.

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

[OSM-talk-fr] Requête overpass [était : Fond de carte avec frontières de pays]

[Vincent Bergeot]

Le 27/10/2019 à 09:54, Yves P. a écrit :


—
Yves Pratter




Une requête overpass turbo permet de faire ça, mais ça n’est pas 
possible dans JOSM (du moins à ma connaissance).

je ne comprends pas ce que cela veut dire ?

Permet de faire ça, c'est quoi ?


Sélectionner uniquement les objets (modifiés) qui se trouvent dans un 
pays donné.



Les objets modifiés dernièrement, depuis une certaine date ?


Comme je ne sais pas faire facilement et rapidement la requête dans 
JOSM, je détermine visuellement le pays.


moi je ne sais pas faire facilement mais quand j'en ai trouvé une je la 
garde précieusement vu le temps que cela fait gagner !








—
Yves


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



--
Vincent Bergeot

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

Re: [OSM-talk-fr] Requête Overpass

[Eric SIBERT via Talk-fr]

Le 12/08/2019 à 22:17, osm.sanspourr...@spamgourmet.com a écrit :
J'ai commencé à regarder avec la diff d'Overpass Comme ton problème ce 
sont les modifs hgv:conditional ajoutées il y a environ un an je propose 
ceci : http://overpass-turbo.eu/s/Lt Y 
, 2 622 chemins.


Imparfait, mais tu dois voir ce qui t'intéresse.


Oui, ça permet déjà de voir l'ampleur des dégâts... dégâts qui sont 
moins étendus que ce que je pensais. Surtout des autoroutes et quelques 
routes principalement en Rhône-Alpes, un peu en Île-de-France.


Je vais traiter département par département.

Merci

Eric

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

Re: [OSM-talk-fr] Requête Overpass

[osm . sanspourriel]

J'ai commencé à regarder avec la diff d'Overpass Comme ton problème ce
sont les modifs hgv:conditional ajoutées il y a environ un an je propose
ceci : http://overpass-turbo.eu/s/Lt Y
, 2 622 chemins.

Imparfait, mais tu dois voir ce qui t'intéresse.

Tu peux raffiner par utilisateur (user:Ilona_S), mais dans ce cas tu
dois prendre pour date de fin une date très proche de la fin de ses
modifications afin d'éviter de louper des chemins modifiés après son
passage.

Exemple , 928 chemins.

Ou plus généreusement en filtrant moins 
1 373. À mon avis là tu n'as que des faux positifs en plus.

J'ai fait deux tests, deux fois je suis tombé sur des modifications
postérieures à la sienne, donc un filtre sur le dernier
utilisateur=Ilona_S sur la base actuelle n'a sans doute pas grand sens.

Du coup je me suis dit qu'OSMCha pouvait être intéressant.

https://osmcha.mapbox.com/changesets/62482398?aoi=a77357a3-aec6-4e10-940f-605d171b9e72

Pouvait car ici il retourne 2 683 changesets (et oui elle n'a pas poussé
ses modifs par autoroute mais par tronçon OSM).

Tu me diras entre 2 683 modifications et 928 chemins il vaut mieux la
requête Overpass qui peut-être passée à JOSM.

Tu peux aussi voir dans http://overpass-turbo.eu/ les autoroutes qu'elle
a modifié et charger ces autoroutes dans OSM (si elles comportent encore
une telle restriction).

Il y aura peut-être quelqu'un•e avec une meilleure idée (ou une en plus).

Jean-Yvon


Le 12/08/2019 à 21:07, Eric SIBERT via Talk-fr -
talk-fr@openstreetmap.org a écrit :

J'ouvre un nouveau fil de discussion suite à mon message précédent.

Comment je récupère toutes les routes de France où le contributeur
Ilona_S a mis les interdictions temporaires de circulation de
poids-lourds d'après la doc Bison-Futé de 2018?

Exemple:
https://www.openstreetmap.org/changeset/61926986#map=14/45.2417/5.8544

L'objectif étant de nettoyer, toute méthode (simple ;-) ) pour
récupérer et nettoyer les voies correspondantes est la bienvenue. Ce
n'est pas restreint à overpass/josm.

Eric

___
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

[OSM-talk-fr] Requête Overpass

[Eric SIBERT via Talk-fr]

J'ouvre un nouveau fil de discussion suite à mon message précédent.

Comment je récupère toutes les routes de France où le contributeur 
Ilona_S a mis les interdictions temporaires de circulation de 
poids-lourds d'après la doc Bison-Futé de 2018?


Exemple:
https://www.openstreetmap.org/changeset/61926986#map=14/45.2417/5.8544

L'objectif étant de nettoyer, toute méthode (simple ;-) ) pour récupérer 
et nettoyer les voies correspondantes est la bienvenue. Ce n'est pas 
restreint à overpass/josm.


Eric

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

Re: [OSM-talk-fr] Requête overpass pour récupérer les ponts au dessus d'une voie ferrée

[osm . sanspourriel]

Herrare humanum est. Fred a bien viré une connerie.

Dans le temps il y a eu un objet OSM à cet endroit car la balise existe,
l'article Wikipedia aussi.

Car contre ce que Fred a viré c'est bien une erreur.

Jean-Yvon

Le 18/05/2019 à 17:50, Jean-Yvon Landrac a écrit :


Et Fred vient par erreur de supprimer ce nœud.

 Null Island existe bien c'est une bouée météorologique nommée d'après
une île fictive créée par Natural Earth.

Jean-Yvon

Le 18/05/2019 à 17:25, Florian_G - forums+...@floriang.eu a écrit :

Hello,

Le 18/05/2019 à 10:13,osm.sanspourr...@spamgourmet.com  a écrit :

Le 17/05/2019 à 23:40, DH -dhel...@free.fr  a écrit :


Non, juste dans la méconnue catégorie des Fortunes

https://wiki.openstreetmap.org/wiki/FR:Fortunes

Denis

C'est ainsi qu'on voit un de nos administrateurs qui n'est pourtant pas manchot 
placer le pôle sud en (0, 0).

Jean-Yvon


Pour m'amuser, je suis allé voir (via iD, hein !) à ces coordonnées : il y a 
des traces GPS publiques, un nœud avec juste un nom, et des notes…

https://www.openstreetmap.org/node/6477793527#map=15/0.0005/-0.0005=NDG

Il y en a qui s'amusent bien. ^_^

++

___
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] Requête overpass pour récupérer les ponts au dessus d'une voie ferrée

[osm . sanspourriel]

Et Fred vient par erreur de supprimer ce nœud.

 Null Island existe bien c'est une bouée météorologique nommée d'après
une île fictive créée par Natural Earth.

Jean-Yvon

Le 18/05/2019 à 17:25, Florian_G - forums+...@floriang.eu a écrit :

Hello,

Le 18/05/2019 à 10:13, osm.sanspourr...@spamgourmet.com a écrit :

Le 17/05/2019 à 23:40, DH - dhel...@free.fr a écrit :


Non, juste dans la méconnue catégorie des Fortunes

https://wiki.openstreetmap.org/wiki/FR:Fortunes

Denis

C'est ainsi qu'on voit un de nos administrateurs qui n'est pourtant pas manchot 
placer le pôle sud en (0, 0).

Jean-Yvon


Pour m'amuser, je suis allé voir (via iD, hein !) à ces coordonnées : il y a 
des traces GPS publiques, un nœud avec juste un nom, et des notes…

https://www.openstreetmap.org/node/6477793527#map=15/0.0005/-0.0005=NDG

Il y en a qui s'amusent bien. ^_^

++

___
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] Requête overpass pour récupérer les ponts au dessus d'une voie ferrée

[Florian_G]

Hello,

Le 18/05/2019 à 10:13, osm.sanspourr...@spamgourmet.com a écrit :
>
> Le 17/05/2019 à 23:40, DH - dhel...@free.fr a écrit :
>
>> Non, juste dans la méconnue catégorie des Fortunes
>>
>> https://wiki.openstreetmap.org/wiki/FR:Fortunes
>>
>> Denis 
>
> C'est ainsi qu'on voit un de nos administrateurs qui n'est pourtant pas 
> manchot placer le pôle sud en (0, 0).
>
> Jean-Yvon
>
Pour m'amuser, je suis allé voir (via iD, hein !) à ces coordonnées : il y a 
des traces GPS publiques, un nœud avec juste un nom, et des notes…

https://www.openstreetmap.org/node/6477793527#map=15/0.0005/-0.0005=NDG

Il y en a qui s'amusent bien. ^_^

++

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

Re: [OSM-talk-fr] Requête overpass pour récupérer les ponts au dessus d'une voie ferrée

[osm . sanspourriel]

Le 17/05/2019 à 23:40, DH - dhel...@free.fr a écrit :


Non, juste dans la méconnue catégorie des Fortunes

https://wiki.openstreetmap.org/wiki/FR:Fortunes

Denis


C'est ainsi qu'on voit un de nos administrateurs qui n'est pourtant pas
manchot placer le pôle sud en (0, 0).

Jean-Yvon

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

Re: [OSM-talk-fr] Requête overpass pour récupérer les ponts au dessus d'une voie ferrée

[DH]

Le 17/05/2019 à 22:17, Gwenaël Jouvin via Talk-fr a écrit :

Pour savoir si le pont est lézardé, ajouter
[disused:bridge]


je suis déjà loin…



Non, juste dans la méconnue catégorie des Fortunes

https://wiki.openstreetmap.org/wiki/FR:Fortunes

Denis



---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: [OSM-talk-fr] Requête overpass pour récupérer les ponts au dessus d'une voie ferrée

[mga_geo via Talk-fr]

Merci Marc
Nickel le (around:0) !



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk-fr] Requête overpass pour récupérer les ponts au dessus d'une voie ferrée

[marc marc]

Le 17.05.19 à 22:17, Gwenaël Jouvin via Talk-fr a écrit :
> Pour savoir si le pont est lézardé, ajouter
> [disused:bridge]

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

Re: [OSM-talk-fr] Requête overpass pour récupérer les ponts au dessus d'une voie ferrée

[osm . sanspourriel]

Et Flamanville c'est un peu loin car sinon tu as aussi des centrales
neuves et lézardées ^^

Le 17/05/2019 à 22:17, Gwenaël Jouvin via Talk-fr -
talk-fr@openstreetmap.org a écrit :

Pour savoir si le pont est lézardé, ajouter
[disused:bridge]


je suis déjà loin…

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

Re: [OSM-talk-fr] Requête overpass pour récupérer les ponts au dessus d'une voie ferrée

[Gwenaël Jouvin via Talk-fr]

Pour savoir si le pont est lézardé, ajouter
[disused:bridge]


je suis déjà loin…


Le 17/05/2019 à 22:10, marc marc a écrit :
> Le 17.05.19 à 21:47, mga_geo via Talk-fr a écrit :
>> - extraction des voies ferrées (railway)
>> - extraction des ponts (highway + bridge=yes)
>> puis intersection géométrique entre ces deux extractions.
> 
> tu peux imposer le critère que l'un doit être proche de l'autre
> https://wiki.openstreetmap.org/wiki/FR:Overpass_API/Overpass_QL#Autour_de_.28around:.29
> avec 0 c'est suposé être ceux qui se croise (selon le wiki :
> uniquement aux points de l'objet mais en testant, il trouve
> bien ceux qui se croise sans noeud commun)
> 
> cela donne
> [out:xml][timeout:25];
> {{geocodeArea:Rennes}}->.searchArea;
> way[railway](area.searchArea);
> way(around:0)[highway][bridge][bridge!=no];
> out geom meta;
> 
> a noter qu'il y a aussi plein de valeur différente de bridge=yes
> j'ai donc utilisé [bridge][bridge!=no]
> 
> par contre pour savoir si un lézard l'emprunte, je te laisse faire :)
> ___
> 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] Requête overpass pour récupérer les ponts au dessus d'une voie ferrée

[osm . sanspourriel]

- récupérer le réseau ferroviaire

- ajouter les bridge=* (pas que yes !) touchant ce réseau.

La différence c'est que je ne chercherais que les bridges croisant le
réseau et non tous les ponts du secteur.

Il y a des exemples overpass faisant ça.

Jean-Yvon

Le 17/05/2019 à 21:47, mga_geo via Talk-fr - talk-fr@openstreetmap.org a
écrit :

Bonsoir à tous,
Le réseau de voies ferrées est probablement utilisé comme corridor
écologique par les lézards. Nous voudrions vérifier cette hypothèse sur
Rennes et pour cela je recherche les ponts et les passages à niveau.
Je ne sais pas extraire les ponts routiers qui passent au-dessus d'une voie
ferrée.
La solution que j'envisage est :
- extraction des voies ferrées (railway)
- extraction des ponts (highway + bridge=yes)
puis intersection géométrique entre ces deux extractions.
Existe-t-il d'autres solutions ?
Marc





--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

___
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] Requête overpass pour récupérer les ponts au dessus d'une voie ferrée

[marc marc]

Le 17.05.19 à 21:47, mga_geo via Talk-fr a écrit :
> - extraction des voies ferrées (railway)
> - extraction des ponts (highway + bridge=yes)
> puis intersection géométrique entre ces deux extractions.

tu peux imposer le critère que l'un doit être proche de l'autre
https://wiki.openstreetmap.org/wiki/FR:Overpass_API/Overpass_QL#Autour_de_.28around:.29
avec 0 c'est suposé être ceux qui se croise (selon le wiki :
uniquement aux points de l'objet mais en testant, il trouve
bien ceux qui se croise sans noeud commun)

cela donne
[out:xml][timeout:25];
{{geocodeArea:Rennes}}->.searchArea;
way[railway](area.searchArea);
way(around:0)[highway][bridge][bridge!=no];
out geom meta;

a noter qu'il y a aussi plein de valeur différente de bridge=yes
j'ai donc utilisé [bridge][bridge!=no]

par contre pour savoir si un lézard l'emprunte, je te laisse faire :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Requête overpass pour récupérer les ponts au dessus d'une voie ferrée

[mga_geo via Talk-fr]

Bonsoir à tous,
Le réseau de voies ferrées est probablement utilisé comme corridor
écologique par les lézards. Nous voudrions vérifier cette hypothèse sur
Rennes et pour cela je recherche les ponts et les passages à niveau.
Je ne sais pas extraire les ponts routiers qui passent au-dessus d'une voie
ferrée.
La solution que j'envisage est :
- extraction des voies ferrées (railway)
- extraction des ponts (highway + bridge=yes)
puis intersection géométrique entre ces deux extractions.
Existe-t-il d'autres solutions ?
Marc





--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk-fr] Requête overpass

[marc marc]

Le plus simple serrait d'afficher la carte osm à l'endroit d'un bout de 
rail manquant dans ton résultat, clic droit, interroger les objets (ou 
télécharger une petite zone avec josm).
Ainsi tu peux voir comment est tagé le rail qui te manque.

Sans l'avoir fait, je pense que cibler uniquement les "way" est trop 
limité, tu devrais au moins inclure aussi les relations qui ont les 
mêmes tags.

Le 04. 12. 17 à 16:15, PIERRE Sylvain a écrit :
> Merci pour les différentes pistes.
> 
> Cela marche plutôt bien dans l'ensemble, j'ai juste un souci avec les 
> données allemandes:
> 
> Alors que pour tous les autres pays européens je retrouve bien les voies 
> principales, la même requête overpass revoie des données complétement 
> éparpillées.
> 
> La requête:
> 
> https://www.overpass-api.de/api/interpreter?data=[out:xml];area[name=Deutschland];(way[railway][usage=main](area););out
>  
> body;>;out skel qt;
> 
> Une petite idée?
> 
> SP
> 
> -Message d'origine-
> De : HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT GE APPUI 
> PERFORMANCE) [mailto:denis.hel...@reseau.sncf.fr]
> Envoyé : vendredi 1 décembre 2017 16:00
> À : Discussions sur OSM en français
> Objet : Re: [OSM-talk-fr] Requête overpass
> 
> Tu peux également compléter avec la clé importance=national 
> (http://taginfo.openstreetmap.fr/tags/importance=national#map).
> 
> Remarque : il manque dans cette classe, à mon sens, le corridor alsacien 
> qui sert également de support au corridor européen Luxembourg-Bâle Ne 
> pas oublier non plus, les relations ferroviaires soit infra 
> (http://www.openstreetmap.org/relation/4745266) soit exploitation 
> (http://www.openstreetmap.org/relation/5847389)
> 
> Hope this helps,
> 
> Denis
> 
> -Message d'origine-
> 
> De : marc marc [mailto:marc_marc_...@hotmail.com]
> 
> Envoyé : vendredi 1 décembre 2017 15:34
> 
> À : talk-fr@openstreetmap.org <mailto:talk-fr@openstreetmap.org>
> 
> Objet : Re: [OSM-talk-fr] Requête overpass
> 
> Bonjour et bienvenue
> 
> Le 01. 12. 17 à 15:13, PIERRE Sylvain a écrit :
> 
>  > identifier avec
> 
>  > l’API overpass les voies de chemin de fer qui apparaissent sur le
> 
>  > serveur OpenRailWayMap sous les intitulés de légende « Ligne
> 
>  > principales » et « Lignes à grande vitesses ».
> 
>  >
> 
>  > J’ai bien conscience que OpenRailwayMap utilise ses propres tags, mais
> 
>  > existe-y-il une correspondance avec ceux de OSM sur ces critères ?
> 
> le point de départ est là http://wiki.openstreetmap.org/wiki/OpenRailwayMap
> 
> d’où on va sur
> 
> http://wiki.openstreetmap.org/wiki/OpenRailwayMap/Tagging#Tracks
> 
> où ils parlent de highspeed=yes
> 
> à l'arrache une première version :
> 
> https://overpass-turbo.eu/s/tsA
> 
> Pour les lignes principales, celle sans highspeed=yes :) J'ai pas vu 
> pour les lignes secondaires (mais je n'ai fais qu'un rapide
> 
> survol)
> 
>  > Et puis allez, on est vendredi, je tente ma chance ;-)
> 
> et c'est bientôt Noël :-)
> 
>  > requête overpass pour sortir les autoroutes et les routes nationales
> 
> http://wiki.openstreetmap.org/wiki/FR:Key:highway
> 
> autoroute tu verras que c'est facile : motorway Pour n'avoir que les 
> nationales, c'est un peu + compliqué.
> 
> il va falloir faire une combinaison de la fonction trunk+primary et de 
> la ref~N
> 
>  > sur plusieurs pays européens ?
> 
> Je laisse ce point pour le suivant :-)
> 
> Cordialement,
> 
> Marc
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Requête overpass

[PIERRE Sylvain]

Merci pour les différentes pistes.

Cela marche plutôt bien dans l'ensemble, j'ai juste un souci avec les données 
allemandes:

Alors que pour tous les autres pays européens je retrouve bien les voies 
principales, la même requête overpass revoie des données complétement 
éparpillées.

La requête:

https://www.overpass-api.de/api/interpreter?data=[out:xml];area[name=Deutschland];(way[railway][usage=main](area););out
 body;>;out skel qt;

[cid:image001.png@01D36D1B.1A3DF910]



Une petite idée?



SP



-Message d'origine-
De : HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT GE APPUI PERFORMANCE) 
[mailto:denis.hel...@reseau.sncf.fr]
Envoyé : vendredi 1 décembre 2017 16:00
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Requête overpass



Tu peux également compléter avec la clé importance=national 
(http://taginfo.openstreetmap.fr/tags/importance=national#map).

Remarque : il manque dans cette classe, à mon sens, le corridor alsacien qui 
sert également de support au corridor européen Luxembourg-Bâle Ne pas oublier 
non plus, les relations ferroviaires soit infra 
(http://www.openstreetmap.org/relation/4745266) soit exploitation 
(http://www.openstreetmap.org/relation/5847389)

Hope this helps,

Denis



-Message d'origine-

De : marc marc [mailto:marc_marc_...@hotmail.com]

Envoyé : vendredi 1 décembre 2017 15:34

À : talk-fr@openstreetmap.org<mailto:talk-fr@openstreetmap.org>

Objet : Re: [OSM-talk-fr] Requête overpass



Bonjour et bienvenue



Le 01. 12. 17 à 15:13, PIERRE Sylvain a écrit :

> identifier avec

> l’API overpass les voies de chemin de fer qui apparaissent sur le

> serveur OpenRailWayMap sous les intitulés de légende « Ligne

> principales » et « Lignes à grande vitesses ».

>

> J’ai bien conscience que OpenRailwayMap utilise ses propres tags, mais

> existe-y-il une correspondance avec ceux de OSM sur ces critères ?



le point de départ est là http://wiki.openstreetmap.org/wiki/OpenRailwayMap

d’où on va sur

http://wiki.openstreetmap.org/wiki/OpenRailwayMap/Tagging#Tracks

où ils parlent de highspeed=yes

à l'arrache une première version :

https://overpass-turbo.eu/s/tsA

Pour les lignes principales, celle sans highspeed=yes :) J'ai pas vu pour les 
lignes secondaires (mais je n'ai fais qu'un rapide

survol)



> Et puis allez, on est vendredi, je tente ma chance ;-)



et c'est bientôt Noël :-)



> requête overpass pour sortir les autoroutes et les routes nationales



http://wiki.openstreetmap.org/wiki/FR:Key:highway

autoroute tu verras que c'est facile : motorway Pour n'avoir que les 
nationales, c'est un peu + compliqué.

il va falloir faire une combinaison de la fonction trunk+primary et de la ref~N



> sur plusieurs pays européens ?



Je laisse ce point pour le suivant :-)



Cordialement,

Marc

___

Talk-fr mailing list

Talk-fr@openstreetmap.org<mailto:Talk-fr@openstreetmap.org>

https://lists.openstreetmap.org/listinfo/talk-fr

---

Ce message et toutes les pièces jointes sont établis à l'intention exclusive de 
ses destinataires et sont confidentiels. L'intégrité de ce message n'étant pas 
assurée sur Internet, la SNCF ne peut être tenue responsable des altérations 
qui pourraient se produire sur son contenu. Toute publication, utilisation, 
reproduction, ou diffusion, même partielle, non autorisée préalablement par la 
SNCF, est strictement interdite. Si vous n'êtes pas le destinataire de ce 
message, merci d'en avertir immédiatement l'expéditeur et de le détruire.

---

This message and any attachments are intended solely for the addressees and are 
confidential. SNCF may not be held responsible for their contents whose 
accuracy and completeness cannot be guaranteed over the Internet. Unauthorized 
use, disclosure, distribution, copying, or any part thereof is strictly 
prohibited. If you are not the intended recipient of this message, please 
notify the sender immediately and delete it.

___

Talk-fr mailing list

Talk-fr@openstreetmap.org<mailto: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] Requête overpass

[HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT GE APPUI PERFORMANCE)]

Tu peux également compléter avec la clé importance=national 
(http://taginfo.openstreetmap.fr/tags/importance=national#map).
Remarque : il manque dans cette classe, à mon sens, le corridor alsacien qui 
sert également de support au corridor européen Luxembourg-Bâle
Ne pas oublier non plus, les relations ferroviaires soit infra 
(http://www.openstreetmap.org/relation/4745266) soit exploitation 
(http://www.openstreetmap.org/relation/5847389)
Hope this helps,
Denis

-Message d'origine-
De : marc marc [mailto:marc_marc_...@hotmail.com] 
Envoyé : vendredi 1 décembre 2017 15:34
À : talk-fr@openstreetmap.org
Objet : Re: [OSM-talk-fr] Requête overpass

Bonjour et bienvenue

Le 01. 12. 17 à 15:13, PIERRE Sylvain a écrit :
> identifier avec
> l’API overpass les voies de chemin de fer qui apparaissent sur le 
> serveur OpenRailWayMap sous les intitulés de légende « Ligne 
> principales » et « Lignes à grande vitesses ».
> 
> J’ai bien conscience que OpenRailwayMap utilise ses propres tags, mais 
> existe-y-il une correspondance avec ceux de OSM sur ces critères ?

le point de départ est là http://wiki.openstreetmap.org/wiki/OpenRailwayMap
d’où on va sur
http://wiki.openstreetmap.org/wiki/OpenRailwayMap/Tagging#Tracks
où ils parlent de highspeed=yes
à l'arrache une première version :
https://overpass-turbo.eu/s/tsA
Pour les lignes principales, celle sans highspeed=yes :) J'ai pas vu pour les 
lignes secondaires (mais je n'ai fais qu'un rapide
survol)

> Et puis allez, on est vendredi, je tente ma chance ;-)

et c'est bientôt Noël :-)

> requête overpass pour sortir les autoroutes et les routes nationales

http://wiki.openstreetmap.org/wiki/FR:Key:highway
autoroute tu verras que c'est facile : motorway Pour n'avoir que les 
nationales, c'est un peu + compliqué.
il va falloir faire une combinaison de la fonction trunk+primary et de la ref~N

 > sur plusieurs pays européens ?

Je laisse ce point pour le suivant :-)

Cordialement,
Marc
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
---
Ce message et toutes les pièces jointes sont établis à l'intention exclusive de 
ses destinataires et sont confidentiels. L'intégrité de ce message n'étant pas 
assurée sur Internet, la SNCF ne peut être tenue responsable des altérations 
qui pourraient se produire sur son contenu. Toute publication, utilisation, 
reproduction, ou diffusion, même partielle, non autorisée préalablement par la 
SNCF, est strictement interdite. Si vous n'êtes pas le destinataire de ce 
message, merci d'en avertir immédiatement l'expéditeur et de le détruire.
---
This message and any attachments are intended solely for the addressees and are 
confidential. SNCF may not be held responsible for their contents whose 
accuracy and completeness cannot be guaranteed over the Internet. Unauthorized 
use, disclosure, distribution, copying, or any part thereof is strictly 
prohibited. If you are not the intended recipient of this message, please 
notify the sender immediately and delete it. 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Requête overpass

[marc marc]

Bonjour et bienvenue

Le 01. 12. 17 à 15:13, PIERRE Sylvain a écrit :
> identifier avec 
> l’API overpass les voies de chemin de fer qui apparaissent sur le 
> serveur OpenRailWayMap sous les intitulés de légende « Ligne 
> principales » et « Lignes à grande vitesses ».
> 
> J’ai bien conscience que OpenRailwayMap utilise ses propres tags, mais 
> existe-y-il une correspondance avec ceux de OSM sur ces critères ?

le point de départ est là http://wiki.openstreetmap.org/wiki/OpenRailwayMap
d’où on va sur 
http://wiki.openstreetmap.org/wiki/OpenRailwayMap/Tagging#Tracks
où ils parlent de highspeed=yes
à l'arrache une première version :
https://overpass-turbo.eu/s/tsA
Pour les lignes principales, celle sans highspeed=yes :)
J'ai pas vu pour les lignes secondaires (mais je n'ai fais qu'un rapide 
survol)

> Et puis allez, on est vendredi, je tente ma chance ;-) 

et c'est bientôt Noël :-)

> requête overpass pour sortir les autoroutes 
> et les routes nationales 

http://wiki.openstreetmap.org/wiki/FR:Key:highway
autoroute tu verras que c'est facile : motorway
Pour n'avoir que les nationales, c'est un peu + compliqué.
il va falloir faire une combinaison de la fonction trunk+primary
et de la ref~N

 > sur plusieurs pays européens ?

Je laisse ce point pour le suivant :-)

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

[OSM-talk-fr] Requête overpass

[PIERRE Sylvain]

Bonjour,

Je débute dans l’univers OSM. Je souhaiterais pouvoir identifier avec l’API 
overpass les voies de chemin de fer qui apparaissent sur le serveur 
OpenRailWayMap sous les intitulés de légende « Ligne principales » et « Lignes 
à grande vitesses ».
J’ai bien conscience que OpenRailwayMap utilise ses propres tags, mais 
existe-y-il une correspondance avec ceux de OSM sur ces critères ?
Et puis allez, on est vendredi, je tente ma chance ;-) : quelle serait la 
requête overpass pour sortir les autoroutes et les routes nationales sur 
plusieurs pays européens ?
D’avance merci


→  Sylvain PIERRE
 Chef de projet système d’information
 Direction des Systèmes d’Information
 Service Projets et Applications Numériques
   Conseil Départemental du Bas-Rhin

[cid:image003.jpg@01D36AB6.EB45F920]

 Hôtel du Département
 1 place du Quartier Blanc 67964 Strasbourg Cedex 9
 Tél : 03 88 76 68 88 - mobile :
 Mobile : 06 30 96 31 76
 Email : sylvain.pie...@bas-rhin.fr
 www.bas-rhin.fr


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

Re: [OSM-talk-fr] requête Overpass API : recherche de communes avec leur n° INSEE

[Samy Mezani]

Merci Jérôme,

Effectivement je crois que je suis dans une impasse. Je vais faire avec 
avec plusieurs requêtes Overpass tant pis, et je croiserai les infos a 
posteriori.


Merci pour l'aide

Samy


Le 15/11/2017 à 02:40, Jérôme Amagat a écrit :



Le 14 novembre 2017 à 19:11, Samy Mezani > a écrit :


Je touche au but mais je n'arrive pas à indiquer les coordonnées
géographiques des admin_centre.

Pour l'instant ça marche avec ça :

[out:csv(_row;false)][timeout:100];

make out _row = "insee,commune,bourg"; out;

area[name="Bourgogne"]["disused:admin_level"=4]->.bourgogne;

rel(area.bourgogne)[boundary=administrative]["admin_level"=8]->.communes;

foreach.communes->.commune(
   node(r.commune:"admin_centre")->.bourg;
   make out _row =
     commune.u(t["ref:INSEE"]) + "," +
     commune.u(t["name"]) + "," +
     bourg.u(t["name"])
     ;
   out geom;
);

Si j'ajoute par exemple la latitude avec ' bourg.u(t[::lat])' dans
mon "make out", j'obtiens une erreur.

J'ai l'impression que le problème c'est que ça : t[ ] c'est pour obtenir 
la valeur pour un tag, le problème c'est que la latitude n'est pas un 
tag. il y a un truc pour récupérer l'id "id()" et le type "type()" mais 
rien pour les coordonnées il me semble 
(https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#Element-Dependent_Operators).


Je ne vois que la solution donnée plus tôt : sur une ligne les données 
de la relation puis celles de l'admin centre.


(Et attention peut être que certaine relation de commune n'ont pas 
d’élément admin_centre)





___
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] requête Overpass API : recherche de communes avec leur n° INSEE

[Samy Mezani]

L'intérêt est d'apprendre les requêtes Overpass pour répondre à des 
besoins spécifiques, et surtout de ne télécharger que ce dont j'ai besoin.


Merci pour le lien, mais télécharger les contours communaux de la France 
ne m'intéresse pas, car ça je sais déjà faire avec les requêtes Overpass 
(suite d'ailleurs à l'aide apportée sur cette liste).


En l'occurence je ne voulais que les admin_centre des communes avec 
leurs coordonnées et leur n° INSEE.



Le 15/11/2017 à 07:54, Christian Quest a écrit :
Quel est l'intérêt de reconstituer (péniblement) ces données alors 
qu'elles sont disponibles en opendata ?


http://professionnels.ign.fr/adminexpress

Les noeuds admin_centre en sont pas toujours présents. J'ai peur que le 
résultat soit incomplet.


Admin Express est mis à jour chaque mois par l'IGN et est sous licence 
ouverte.



Le 15 novembre 2017 à 02:40, Jérôme Amagat > a écrit :




Le 14 novembre 2017 à 19:11, Samy Mezani > a écrit :

Je touche au but mais je n'arrive pas à indiquer les coordonnées
géographiques des admin_centre.

Pour l'instant ça marche avec ça :

[out:csv(_row;false)][timeout:100];

make out _row = "insee,commune,bourg"; out;

area[name="Bourgogne"]["disused:admin_level"=4]->.bourgogne;


rel(area.bourgogne)[boundary=administrative]["admin_level"=8]->.communes;

foreach.communes->.commune(
   node(r.commune:"admin_centre")->.bourg;
   make out _row =
     commune.u(t["ref:INSEE"]) + "," +
     commune.u(t["name"]) + "," +
     bourg.u(t["name"])
     ;
   out geom;
);

Si j'ajoute par exemple la latitude avec ' bourg.u(t[::lat])'
dans mon "make out", j'obtiens une erreur.

J'ai l'impression que le problème c'est que ça : t[ ] c'est pour
obtenir la valeur pour un tag, le problème c'est que la latitude
n'est pas un tag. il y a un truc pour récupérer l'id "id()" et le
type "type()" mais rien pour les coordonnées il me semble

(https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#Element-Dependent_Operators

).

Je ne vois que la solution donnée plus tôt : sur une ligne les
données de la relation puis celles de l'admin centre.

(Et attention peut être que certaine relation de commune n'ont pas
d’élément admin_centre)



___
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] requête Overpass API : recherche de communes avec leur n° INSEE

[Nicolas Moyroud]

Euh et sinon si on restait sur les données OSM y'a pas plutôt ça :

http://www.data.gouv.fr/fr/datasets/decoupage-administratif-communal-francais-issu-d-openstreetmap/

Et ensuite tu travailles avec un logiciel SIG comme QGIS pour découper 
sur le territoire qui t'intéresse...


Nicolas



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

Re: [OSM-talk-fr] requête Overpass API : recherche de communes avec leur n° INSEE

[Christian Quest]

Quel est l'intérêt de reconstituer (péniblement) ces données alors qu'elles
sont disponibles en opendata ?

http://professionnels.ign.fr/adminexpress

Les noeuds admin_centre en sont pas toujours présents. J'ai peur que le
résultat soit incomplet.

Admin Express est mis à jour chaque mois par l'IGN et est sous licence
ouverte.


Le 15 novembre 2017 à 02:40, Jérôme Amagat  a
écrit :

>
>
> Le 14 novembre 2017 à 19:11, Samy Mezani  a écrit
> :
>
>> Je touche au but mais je n'arrive pas à indiquer les coordonnées
>> géographiques des admin_centre.
>>
>> Pour l'instant ça marche avec ça :
>>
>> [out:csv(_row;false)][timeout:100];
>>
>> make out _row = "insee,commune,bourg"; out;
>>
>> area[name="Bourgogne"]["disused:admin_level"=4]->.bourgogne;
>>
>> rel(area.bourgogne)[boundary=administrative]["admin_level"=8]->.communes;
>>
>> foreach.communes->.commune(
>>   node(r.commune:"admin_centre")->.bourg;
>>   make out _row =
>> commune.u(t["ref:INSEE"]) + "," +
>> commune.u(t["name"]) + "," +
>> bourg.u(t["name"])
>> ;
>>   out geom;
>> );
>>
>> Si j'ajoute par exemple la latitude avec ' bourg.u(t[::lat])' dans mon
>> "make out", j'obtiens une erreur.
>>
>> J'ai l'impression que le problème c'est que ça : t[ ] c'est pour obtenir
> la valeur pour un tag, le problème c'est que la latitude n'est pas un tag.
> il y a un truc pour récupérer l'id "id()" et le type "type()" mais rien
> pour les coordonnées il me semble (https://wiki.openstreetmap.
> org/wiki/Overpass_API/Overpass_QL#Element-Dependent_Operators).
>
> Je ne vois que la solution donnée plus tôt : sur une ligne les données de
> la relation puis celles de l'admin centre.
>
> (Et attention peut être que certaine relation de commune n'ont pas
> d’élément admin_centre)
>
>
>
> ___
> 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] requête Overpass API : recherche de communes avec leur n° INSEE

[Jérôme Amagat]

Le 14 novembre 2017 à 19:11, Samy Mezani  a écrit :

> Je touche au but mais je n'arrive pas à indiquer les coordonnées
> géographiques des admin_centre.
>
> Pour l'instant ça marche avec ça :
>
> [out:csv(_row;false)][timeout:100];
>
> make out _row = "insee,commune,bourg"; out;
>
> area[name="Bourgogne"]["disused:admin_level"=4]->.bourgogne;
>
> rel(area.bourgogne)[boundary=administrative]["admin_level"=8]->.communes;
>
> foreach.communes->.commune(
>   node(r.commune:"admin_centre")->.bourg;
>   make out _row =
> commune.u(t["ref:INSEE"]) + "," +
> commune.u(t["name"]) + "," +
> bourg.u(t["name"])
> ;
>   out geom;
> );
>
> Si j'ajoute par exemple la latitude avec ' bourg.u(t[::lat])' dans mon
> "make out", j'obtiens une erreur.
>
> J'ai l'impression que le problème c'est que ça : t[ ] c'est pour obtenir
la valeur pour un tag, le problème c'est que la latitude n'est pas un tag.
il y a un truc pour récupérer l'id "id()" et le type "type()" mais rien
pour les coordonnées il me semble (
https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#Element-Dependent_Operators
).

Je ne vois que la solution donnée plus tôt : sur une ligne les données de
la relation puis celles de l'admin centre.

(Et attention peut être que certaine relation de commune n'ont pas
d’élément admin_centre)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] requête Overpass API : recherche de communes avec leur n° INSEE

[Samy Mezani]

Je touche au but mais je n'arrive pas à indiquer les coordonnées 
géographiques des admin_centre.


Pour l'instant ça marche avec ça :

[out:csv(_row;false)][timeout:100];

make out _row = "insee,commune,bourg"; out;

area[name="Bourgogne"]["disused:admin_level"=4]->.bourgogne;

rel(area.bourgogne)[boundary=administrative]["admin_level"=8]->.communes;

foreach.communes->.commune(
  node(r.commune:"admin_centre")->.bourg;
  make out _row =
commune.u(t["ref:INSEE"]) + "," +
commune.u(t["name"]) + "," +
bourg.u(t["name"])
;
  out geom;
);

Si j'ajoute par exemple la latitude avec ' bourg.u(t[::lat])' dans mon 
"make out", j'obtiens une erreur.


Comment faire ?

Merci

Samy



Le 14/11/2017 à 17:20, Samy Mezani a écrit :

Merci Adrien,

Ça me met sur une bonne piste.

Je vais essayer de formatter avec make out _row que j'ai vu à 
https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_API_by_Example#Wiki_table_generator_.28since_0.7.54.29 



Mais bon, faut déjà comprendre. ;-)

Merci

Samy

Le 14/11/2017 à 17:01, PanierAvide a écrit :

Bonjour,

Après quelques recherches, j'ai pas trouvé mieux que ça :

|[out:csv("ref:INSEE","name",::lat,::lon)][timeout:100];||
||area[name="Bourgogne"]["disused:admin_level"=4]->.bourgogne;||
||rel(area.bourgogne)[boundary=administrative]["admin_level"=8];||
||foreach(||
||  out;||
||  node(r:"admin_centre");||
||  out;||
||);|

On récupère les limites communales, et pour chacune on affiche les 
infos de la relation, puis sur la ligne suivante les infos du noeud 
admin_centre. J'ai pas vu de moyen de mélanger la sortie d'un noeud et 
de sa relation. Avec une bonne expression régulière derrière, on doit 
pouvoir fusionner les lignes deux à deux, et arriver au résultat 
escompté.


Cordialement,

Adrien.


Le 14/11/2017 à 14:49, Samy Mezani a écrit :

Bonjour,

Je cherche à faire une requête Overpass API pour rechercher les 
communes d'un territoire avec leur "ref:INSEE" et les coordonnées 
géographiques de leur "admin_centre"


Je suis contraint de rechercher les relations avec "admin_level"=8, 
et non les nodes avec ce tag, car j'ai remarqué que nombre d' 
"admin_centre" communaux n'ont plus de "ref:INSEE" ou ont parfois des 
"ref:FR:INSEE"


Comment faire pour retourner à la fois les admin_centre avec leurs 
coordonnées, et le "ref:INSEE" et le name de leur relation parente ?


Pour l'instant j'ai ça, mais ::lat et ::lon sont les centroïdes des 
communes :


[out:csv("ref:INSEE","name",::lat,::lon)][timeout:100];

area[name="Bourgogne"]["disused:admin_level"=4]->.bourgogne;

rel(area.bourgogne)[boundary=administrative]["admin_level"=8];

out ;

Avec ça j'ai bien les coordonnées des "admin_centre" mais je n'ai pas 
le "name" des communes ni toujours le "ref:INSEE" :


[out:csv("ref:INSEE","name",::lat,::lon)][timeout:100];

area[name="Bourgogne"]["disused:admin_level"=4]->.bourgogne;

rel(area.bourgogne)[boundary=administrative]["admin_level"=8]->.communes; 



node(r.communes:"admin_centre");

out ;


Merci

Samy

___
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] requête Overpass API : recherche de communes avec leur n° INSEE

[Philippe Verdy]

Les ref:FR:SIREN devraient être sur toutes les relations des collectivités
territoriales (communes, départements, régions, EPCI à fiscalité propre ou
non, et autres syndicats mixtes associant des collectivités publiques à des
entités privées). Si ce n'est pas le cas, c'est à importer (je suggère une
analyse Osmose pour voir ceux qui manquent). On a des SIREN pour la plupart
des EPCI à fiscalité propre, mais pas pour toutes les communes ni les
syndicats mixtes, et on devrait les avoir dans les données ouvertes par
l'INSEE et dans le SIRENE maintenant ouvert.

Ce SIREN, concernant les communes, contient normalement le code INSEE du
siège de cette commune (ce code INSEE n'est cependant pas associée toujours
à la commune entière, ce peut être en fait celui d'une commune déléguée ou
associée et est normalement le code INSEE à utiliser pour désigner
informellement la commune entière). Mais il y a certainement des exceptions
(qui sait comment l'INSEE a initialement attribué le code SIREN avant
l'entrée en vigueur de la commune nouvelle ou si celle-ci n'a pas ensuite
décidé de déplacer son siège sans pour autant changer d'identité légale).
On connait certaines collectivités qui ont leur siège HORS de leur propre
territoire.

Toutes les collectivités sont tenues de rendre public ce code dans la
totalité de leurs annonces légales, publicités, contrats, factures, appels
d'offre, et sur la notice légale d'information de leur site web ou journal
diffusé dans les boites à lettre: c'est leur "signature" en tant que
personne morale, non ambiguë comme peut être leur nom (souvent abrégé,
simplifié, dérivé en logogrammes soumis à droits d'auteur réservés ou
droits des marques, traduit ou translittéré plus ou moins formellement et
parfois complètement remplacé par une marque déposée destinée à protéger
aussi un nom de domaine pour un site web ou contre une appropriation par
une entité commerciale tierce ou par un émetteur privé de label
d'appellation ou d'origine...)


Le 14 novembre 2017 à 16:56, Samy Mezani  a écrit :

> Merci pour ta réponse, mais les ref:FR:SIREN sont encore moins utilisés
> sur les admin_centre que les ref:INSEE, donc ça ne me convient pas trop.
>
>
> Le 14/11/2017 à 15:31, Philippe Verdy a écrit :
>
>> La recherche pourrait se faire par les ref:FR:SIREN aussi (les mairies
>> des communes de plein droit ont un préfixe dédié, cependant les communes
>>
> [...]
>
>
>> Le 14 novembre 2017 à 14:49, Samy Mezani  samy.mez...@wanadoo.fr>> a écrit :
>>
>> Bonjour,
>>
>> Je cherche à faire une requête Overpass API pour rechercher les
>> communes d'un territoire avec leur "ref:INSEE" et les coordonnées
>> géographiques de leur "admin_centre"
>>
>> Je suis contraint de rechercher les relations avec "admin_level"=8,
>> et non les nodes avec ce tag, car j'ai remarqué que nombre d'
>> "admin_centre" communaux n'ont plus de "ref:INSEE" ou ont parfois
>> des "ref:FR:INSEE"
>>
>> Comment faire pour retourner à la fois les admin_centre avec leurs
>> coordonnées, et le "ref:INSEE" et le name de leur relation parente ?
>>
>> Pour l'instant j'ai ça, mais ::lat et ::lon sont les centroïdes des
>> communes :
>>
>>  [out:csv("ref:INSEE","name",::lat,::lon)][timeout:100];
>>
>>  area[name="Bourgogne"]["disused:admin_level"=4]->.bourgogne;
>>
>>  rel(area.bourgogne)[boundary=administrative]["admin_level"=8
>> ];
>>
>>  out ;
>>
>> Avec ça j'ai bien les coordonnées des "admin_centre" mais je n'ai
>> pas le "name" des communes ni toujours le "ref:INSEE" :
>>
>>  [out:csv("ref:INSEE","name",::lat,::lon)][timeout:100];
>>
>>  area[name="Bourgogne"]["disused:admin_level"=4]->.bourgogne;
>>
>> rel(area.bourgogne)[boundary=a
>> dministrative]["admin_level"=8]->.communes;
>>
>>  node(r.communes:"admin_centre");
>>
>>  out ;
>>
>>
>> Merci
>>
>> Samy
>>
>
> ___
> 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] requête Overpass API : recherche de communes avec leur n° INSEE

[Samy Mezani]

Merci Adrien,

Ça me met sur une bonne piste.

Je vais essayer de formatter avec make out _row que j'ai vu à 
https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_API_by_Example#Wiki_table_generator_.28since_0.7.54.29


Mais bon, faut déjà comprendre. ;-)

Merci

Samy

Le 14/11/2017 à 17:01, PanierAvide a écrit :

Bonjour,

Après quelques recherches, j'ai pas trouvé mieux que ça :

|[out:csv("ref:INSEE","name",::lat,::lon)][timeout:100];||
||area[name="Bourgogne"]["disused:admin_level"=4]->.bourgogne;||
||rel(area.bourgogne)[boundary=administrative]["admin_level"=8];||
||foreach(||
||  out;||
||  node(r:"admin_centre");||
||  out;||
||);|

On récupère les limites communales, et pour chacune on affiche les infos 
de la relation, puis sur la ligne suivante les infos du noeud 
admin_centre. J'ai pas vu de moyen de mélanger la sortie d'un noeud et 
de sa relation. Avec une bonne expression régulière derrière, on doit 
pouvoir fusionner les lignes deux à deux, et arriver au résultat escompté.


Cordialement,

Adrien.


Le 14/11/2017 à 14:49, Samy Mezani a écrit :

Bonjour,

Je cherche à faire une requête Overpass API pour rechercher les 
communes d'un territoire avec leur "ref:INSEE" et les coordonnées 
géographiques de leur "admin_centre"


Je suis contraint de rechercher les relations avec "admin_level"=8, et 
non les nodes avec ce tag, car j'ai remarqué que nombre d' 
"admin_centre" communaux n'ont plus de "ref:INSEE" ou ont parfois des 
"ref:FR:INSEE"


Comment faire pour retourner à la fois les admin_centre avec leurs 
coordonnées, et le "ref:INSEE" et le name de leur relation parente ?


Pour l'instant j'ai ça, mais ::lat et ::lon sont les centroïdes des 
communes :


[out:csv("ref:INSEE","name",::lat,::lon)][timeout:100];

area[name="Bourgogne"]["disused:admin_level"=4]->.bourgogne;

rel(area.bourgogne)[boundary=administrative]["admin_level"=8];

out ;

Avec ça j'ai bien les coordonnées des "admin_centre" mais je n'ai pas 
le "name" des communes ni toujours le "ref:INSEE" :


[out:csv("ref:INSEE","name",::lat,::lon)][timeout:100];

area[name="Bourgogne"]["disused:admin_level"=4]->.bourgogne;

rel(area.bourgogne)[boundary=administrative]["admin_level"=8]->.communes; 



node(r.communes:"admin_centre");

out ;


Merci

Samy

___
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] requête Overpass API : recherche de communes avec leur n° INSEE

[PanierAvide]

Bonjour,

Après quelques recherches, j'ai pas trouvé mieux que ça :

|[out:csv("ref:INSEE","name",::lat,::lon)][timeout:100];||
||area[name="Bourgogne"]["disused:admin_level"=4]->.bourgogne;||
||rel(area.bourgogne)[boundary=administrative]["admin_level"=8];||
||foreach(||
||  out;||
||  node(r:"admin_centre");||
||  out;||
||);|

On récupère les limites communales, et pour chacune on affiche les infos 
de la relation, puis sur la ligne suivante les infos du noeud 
admin_centre. J'ai pas vu de moyen de mélanger la sortie d'un noeud et 
de sa relation. Avec une bonne expression régulière derrière, on doit 
pouvoir fusionner les lignes deux à deux, et arriver au résultat escompté.


Cordialement,

Adrien.


Le 14/11/2017 à 14:49, Samy Mezani a écrit :

Bonjour,

Je cherche à faire une requête Overpass API pour rechercher les 
communes d'un territoire avec leur "ref:INSEE" et les coordonnées 
géographiques de leur "admin_centre"


Je suis contraint de rechercher les relations avec "admin_level"=8, et 
non les nodes avec ce tag, car j'ai remarqué que nombre d' 
"admin_centre" communaux n'ont plus de "ref:INSEE" ou ont parfois des 
"ref:FR:INSEE"


Comment faire pour retourner à la fois les admin_centre avec leurs 
coordonnées, et le "ref:INSEE" et le name de leur relation parente ?


Pour l'instant j'ai ça, mais ::lat et ::lon sont les centroïdes des 
communes :


[out:csv("ref:INSEE","name",::lat,::lon)][timeout:100];

area[name="Bourgogne"]["disused:admin_level"=4]->.bourgogne;

rel(area.bourgogne)[boundary=administrative]["admin_level"=8];

out ;

Avec ça j'ai bien les coordonnées des "admin_centre" mais je n'ai pas 
le "name" des communes ni toujours le "ref:INSEE" :


[out:csv("ref:INSEE","name",::lat,::lon)][timeout:100];

area[name="Bourgogne"]["disused:admin_level"=4]->.bourgogne;

rel(area.bourgogne)[boundary=administrative]["admin_level"=8]->.communes; 



node(r.communes:"admin_centre");

out ;


Merci

Samy

___
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] requête Overpass API : recherche de communes avec leur n° INSEE

[Samy Mezani]

Merci pour ta réponse, mais les ref:FR:SIREN sont encore moins utilisés 
sur les admin_centre que les ref:INSEE, donc ça ne me convient pas trop.



Le 14/11/2017 à 15:31, Philippe Verdy a écrit :
La recherche pourrait se faire par les ref:FR:SIREN aussi (les mairies 
des communes de plein droit ont un préfixe dédié, cependant les communes 

[...]


Le 14 novembre 2017 à 14:49, Samy Mezani > a écrit :


Bonjour,

Je cherche à faire une requête Overpass API pour rechercher les
communes d'un territoire avec leur "ref:INSEE" et les coordonnées
géographiques de leur "admin_centre"

Je suis contraint de rechercher les relations avec "admin_level"=8,
et non les nodes avec ce tag, car j'ai remarqué que nombre d'
"admin_centre" communaux n'ont plus de "ref:INSEE" ou ont parfois
des "ref:FR:INSEE"

Comment faire pour retourner à la fois les admin_centre avec leurs
coordonnées, et le "ref:INSEE" et le name de leur relation parente ?

Pour l'instant j'ai ça, mais ::lat et ::lon sont les centroïdes des
communes :

         [out:csv("ref:INSEE","name",::lat,::lon)][timeout:100];

         area[name="Bourgogne"]["disused:admin_level"=4]->.bourgogne;

         rel(area.bourgogne)[boundary=administrative]["admin_level"=8];

         out ;

Avec ça j'ai bien les coordonnées des "admin_centre" mais je n'ai
pas le "name" des communes ni toujours le "ref:INSEE" :

         [out:csv("ref:INSEE","name",::lat,::lon)][timeout:100];

         area[name="Bourgogne"]["disused:admin_level"=4]->.bourgogne;


rel(area.bourgogne)[boundary=administrative]["admin_level"=8]->.communes;


         node(r.communes:"admin_centre");

         out ;


Merci

Samy


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

Re: [OSM-talk-fr] requête Overpass API : recherche de communes avec leur n° INSEE

[Philippe Verdy]

note: tu peux utiliser "end_date=*" pour détecter les communes qui
"n'existe plus" (vérifie la valeur de la date au normalement au format ISO
8601 "-MM-DD" pour celle dont la fin de plein exercice est annoncée, ou
parfois seulement "" pour les très anciennes communes d'avant 1973 dont
on a du mal à retrouver la date de fin exacte car les arrêtés ne sont pas
toujours en ligne), cette date n'est pas exactement la fin complète de leur
existence légale qui vient bien plus tard mais correspond à celle où une
nouvelle entité est sensée commencer à fonctionner et commencer à en
reprendre les activités (si une commune succède à une autre la première
peut déjà exister depuis longtemps avant, ce n'est pas nécessairement une
création).

Le 14 novembre 2017 à 14:49, Samy Mezani  a écrit :

> Bonjour,
>
> Je cherche à faire une requête Overpass API pour rechercher les communes
> d'un territoire avec leur "ref:INSEE" et les coordonnées géographiques de
> leur "admin_centre"
>
> Je suis contraint de rechercher les relations avec "admin_level"=8, et non
> les nodes avec ce tag, car j'ai remarqué que nombre d' "admin_centre"
> communaux n'ont plus de "ref:INSEE" ou ont parfois des "ref:FR:INSEE"
>
> Comment faire pour retourner à la fois les admin_centre avec leurs
> coordonnées, et le "ref:INSEE" et le name de leur relation parente ?
>
> Pour l'instant j'ai ça, mais ::lat et ::lon sont les centroïdes des
> communes :
>
> [out:csv("ref:INSEE","name",::lat,::lon)][timeout:100];
>
> area[name="Bourgogne"]["disused:admin_level"=4]->.bourgogne;
>
> rel(area.bourgogne)[boundary=administrative]["admin_level"=8];
>
> out ;
>
> Avec ça j'ai bien les coordonnées des "admin_centre" mais je n'ai pas le
> "name" des communes ni toujours le "ref:INSEE" :
>
> [out:csv("ref:INSEE","name",::lat,::lon)][timeout:100];
>
> area[name="Bourgogne"]["disused:admin_level"=4]->.bourgogne;
>
> rel(area.bourgogne)[boundary=administrative]["admin_level"=8
> ]->.communes;
>
> node(r.communes:"admin_centre");
>
> out ;
>
>
> Merci
>
> Samy
>
> ___
> 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] requête Overpass API : recherche de communes avec leur n° INSEE

[Philippe Verdy]

La recherche pourrait se faire par les ref:FR:SIREN aussi (les mairies des
communes de plein droit ont un préfixe dédié, cependant les communes
déléguées dans les communes nouvelles, ou les communes associées dans une
commune en fusion-association ont aussi leur propre SIREN, et les communes
récemment fusionnées ont encore un SIREN valide pendant l'année qui suit,
le temps de présenter les bilans et clore les comptes et engagements, mais
parfois ça dure plusieurs années avant que l'ancienne entité légale soit
dissoute et ensuite éliminée du répertoire des sociétés, l'INSEE devant
aussi assurer la continuité statistique par au moins une année de
transition permettant les comparaisons, comme l'impose les textes de lois,
et le SIREN perdure tant qu'il existe un recours administratif non résolu
contre les conditions d'une fusion ou défusion de communes et que les
délais légaux de recours devant une cour administrative ne sont pas
dépassés.

En pratique le SIREN des communes persiste pendant au moins 5 ans après le
démarrage de la nouvelle commune, qui en revanche a un SIREN dès le début,
attribué avant même son entrée en vigueur qui doit être annoncée au moins 2
mois avant, le temps d'enregistrer la nouvelle entité à créer (car sinon
elle n'aurait aucun droit d'exercer, le SIREN étant obligatoire pour toute
personne morale qui doit disposer d'une personnalité juridique, absolument
obligatoire pour n'importe quelle décision administrative ou réglementaire
que la personne morale pourrait prendre et aussi pour pouvoir tenir des
comptes ou réclamer la moindre fiscalité ou se prévaloir de créances de
dettes ou de la propriété d'un domaine public ou de la capacité à employer
du personnel. Cette coexistence fait que pendant un certain temps un même
territoire peut être couvert par plusieurs personnes morales coexistantes,
même si l'une n'est plus en état légal de décider par elle-même: dès le
jour de la publication de l'arrêté préfectoral ou de la décision de justice
applicable après les délais d'appel, l'INSEE procède à l'enregistrement des
communes à créer, mais l'INSEE ne supprime que bien plus tard après
publication et certification des comptes de clôture reprenant la liste des
engagements financiers et sociaux et des actifs et dettes sont la
responsabilité doit être transférée soit à la nouvelle commune soit à une
autre collectivité, soit à l'Etat).

Le 14 novembre 2017 à 14:49, Samy Mezani  a écrit :

> Bonjour,
>
> Je cherche à faire une requête Overpass API pour rechercher les communes
> d'un territoire avec leur "ref:INSEE" et les coordonnées géographiques de
> leur "admin_centre"
>
> Je suis contraint de rechercher les relations avec "admin_level"=8, et non
> les nodes avec ce tag, car j'ai remarqué que nombre d' "admin_centre"
> communaux n'ont plus de "ref:INSEE" ou ont parfois des "ref:FR:INSEE"
>
> Comment faire pour retourner à la fois les admin_centre avec leurs
> coordonnées, et le "ref:INSEE" et le name de leur relation parente ?
>
> Pour l'instant j'ai ça, mais ::lat et ::lon sont les centroïdes des
> communes :
>
> [out:csv("ref:INSEE","name",::lat,::lon)][timeout:100];
>
> area[name="Bourgogne"]["disused:admin_level"=4]->.bourgogne;
>
> rel(area.bourgogne)[boundary=administrative]["admin_level"=8];
>
> out ;
>
> Avec ça j'ai bien les coordonnées des "admin_centre" mais je n'ai pas le
> "name" des communes ni toujours le "ref:INSEE" :
>
> [out:csv("ref:INSEE","name",::lat,::lon)][timeout:100];
>
> area[name="Bourgogne"]["disused:admin_level"=4]->.bourgogne;
>
> rel(area.bourgogne)[boundary=administrative]["admin_level"=8
> ]->.communes;
>
> node(r.communes:"admin_centre");
>
> out ;
>
>
> Merci
>
> Samy
>
> ___
> 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

[OSM-talk-fr] requête Overpass API : recherche de communes avec leur n° INSEE

[Samy Mezani]

Bonjour,

Je cherche à faire une requête Overpass API pour rechercher les communes 
d'un territoire avec leur "ref:INSEE" et les coordonnées géographiques 
de leur "admin_centre"


Je suis contraint de rechercher les relations avec "admin_level"=8, et 
non les nodes avec ce tag, car j'ai remarqué que nombre d' 
"admin_centre" communaux n'ont plus de "ref:INSEE" ou ont parfois des 
"ref:FR:INSEE"


Comment faire pour retourner à la fois les admin_centre avec leurs 
coordonnées, et le "ref:INSEE" et le name de leur relation parente ?


Pour l'instant j'ai ça, mais ::lat et ::lon sont les centroïdes des 
communes :


[out:csv("ref:INSEE","name",::lat,::lon)][timeout:100];

area[name="Bourgogne"]["disused:admin_level"=4]->.bourgogne;

rel(area.bourgogne)[boundary=administrative]["admin_level"=8];

out ;

Avec ça j'ai bien les coordonnées des "admin_centre" mais je n'ai pas le 
"name" des communes ni toujours le "ref:INSEE" :


[out:csv("ref:INSEE","name",::lat,::lon)][timeout:100];

area[name="Bourgogne"]["disused:admin_level"=4]->.bourgogne;


rel(area.bourgogne)[boundary=administrative]["admin_level"=8]->.communes;

node(r.communes:"admin_centre");

out ;


Merci

Samy

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

Re: [OSM-talk-fr] requête Overpass en ligne de commande

[Samy Mezani]

Le 11/09/2017 à 16:51, sly (sylvain letuffe) a écrit :

mais le seul soucis qui semble  (semble car je
ne suis pas expert Qgis) rester ce sont les 2 communes au Sud Est qui
appartiennent à la région voisine, qui sont donc des enclaves appartenant à
la région d'a coté et qui devrait alors être des "trous" de la ex-région
bourgogne mais qui ne semble pas être traité comme des trous.


Là pour le coup, ça ne m'a pas choqué puisque ces 2 enclaves touchent 
bien la relation Bourgogne.


Le polygone généré pour la Bourgogne par ogr2ogr est bien le 
multipolygone "outer".
Je me suis débarrassé des 2 enclavec avec -sql select * from 
multipolygons where name = 'Bourgogne'


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

Re: [OSM-talk-fr] requête Overpass en ligne de commande

[sly (sylvain letuffe)]

Samy Mezani wrote
> Je teste en ce moment même avec ogr2ogr (qui me renvoie des erreurs de 
> segmentation sur Debian...)

Par curiosité, j'ai voulu essayer et ça à l'air de presque quasiment le
faire avec ogr2ogr :
http://sly.letuffe.org/echange/old-bourgogne.zip

Sur une debian 8
$ ogr2ogr --version
GDAL 1.10.1, released 2013/08/26

$ ogr2ogr -overwrite -f "ESRI Shapefile" test.shp test.osm -sql 'select *
from multipolygons'

ça s'ouvre nikel avec Qgis, mais le seul soucis qui semble  (semble car je
ne suis pas expert Qgis) rester ce sont les 2 communes au Sud Est qui
appartiennent à la région voisine, qui sont donc des enclaves appartenant à
la région d'a coté et qui devrait alors être des "trous" de la ex-région
bourgogne mais qui ne semble pas être traité comme des trous.
Peut-être une "non fonctionnalité" de ce driver ogr2ogr qui ne gère pas les
role inner
https://wiki.openstreetmap.org/wiki/Relation:multipolygon#One_outer_and_one_inner_ring






-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk-fr] requête Overpass en ligne de commande

[Samy Mezani]

J'enfonce certainement des portes ouvertes, mais voici enfin la manip 
qui a fonctionné :


wget -O bourgogne.osm 
'http://overpass-api.de/api/interpreter?data=rel[name="Bourgogne"]["disused:admin_level"=4];(._;>);out 
geom;


ogr2ogr -a_srs "EPSG:4326" -t_srs "EPSG:2154" -f PostgreSQL 
PG:"host= dbname=" -lco schema= -nln bourgogne_region_old 
-nlt multipolygon -sql "select name from multipolygons where 
name='Bourgogne'" bourgogne.osm


J'ai bien mon multipolygone dans ma base PostGIS. Nickel. Si ça peut servir…

Merci pour votre aide.

Samy

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

Re: [OSM-talk-fr] requête Overpass en ligne de commande

[Samy Mezani]

Le 11/09/2017 à 15:24, sly (sylvain letuffe) a écrit :
[...]

A mon avis, le problème qui fait que tu n'obtiens pas les réponses que tu
attends tient dans l'expression de ton besoin.
Je pense comprendre (je peux me tromper) que ce que tu veux c'est un
multipolygone au sens GIS (postgis, shapefile) du terme alors que les
réponses qui t'ont été données expliquent comment avoir un multipolygone au
sens OSM du terme :


Effectivement, mes termes sont ambigus mais tu as bien compris mon 
besoin : un multipolygone au sens SIG.



Car la requête que tu as faite sur l'overpass te donne, selon la
terminologie OSM, le multipolygone de l'ancienne-Bourgogne et tous les
éléments qu'il faut pour en construire un (multi-)polygone (au sens GIS du
terme)


Ah OK, c'est plus clair.


Ce que tu cherches (peut-être) maintenant c'est un convertisseur, et
overpass ne fait pas ça.

osm2pgsql sait le faire pour importer dans postgres/postGIS
ogr2ogr semble le faire aussi :


Je teste en ce moment même avec ogr2ogr (qui me renvoie des erreurs de 
segmentation sur Debian...)


Le 11/09/2017 à 15:44, Jo a écrit :

Mais à mon avis les plugins openstreetmap en QGIS te seront plus utiles pour 
arriver à des fichiers .SHP. J'ignore si c'est possible de les invoquer à 
partir de  la ligne de commande. Peut-être avec un script Python?


J'aurais pu en effet me servir de codes Python comme QuickOSM ou autre, 
mais je voulais plutôt dégrossir le problème avec Overpass.


Merci en tous cas, je vais essayer de voir ogr2ogr ou osm2pgsql.

Samy

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

Re: [OSM-talk-fr] requête Overpass en ligne de commande

[Jo]

https://wiki.openstreetmap.org/wiki/Osmosis

peut filtrer tes données OSM en ligne de commande

Mais à mon avis les plugins openstreetmap en QGIS te seront plus utiles
pour arriver à des fichiers .SHP. J'ignore si c'est possible de les
invoquer à partir de  la ligne de commande. Peut-être avec un script Python?

Jo

2017-09-11 15:24 GMT+02:00 sly (sylvain letuffe) :

> Samy Mezani wrote
> > Je veux simplement obtenir le multipolygone de son ancien contour.
>
> A mon avis, le problème qui fait que tu n'obtiens pas les réponses que tu
> attends tient dans l'expression de ton besoin.
> Je pense comprendre (je peux me tromper) que ce que tu veux c'est un
> multipolygone au sens GIS (postgis, shapefile) du terme alors que les
> réponses qui t'ont été données expliquent comment avoir un multipolygone au
> sens OSM du terme :
> https://wiki.openstreetmap.org/wiki/Relation:multipolygon
> (c'est à dire un objet de type"relation")
>
> Car la requête que tu as faite sur l'overpass te donne, selon la
> terminologie OSM, le multipolygone de l'ancienne-Bourgogne et tous les
> éléments qu'il faut pour en construire un (multi-)polygone (au sens GIS du
> terme)
> (Pour s'en convaincre, ajoute out meta; et ouvre le avec josm, tu verra que
> tu as bien le contour)
>
> Ce que tu cherches (peut-être) maintenant c'est un convertisseur, et
> overpass ne fait pas ça.
>
> osm2pgsql sait le faire pour importer dans postgres/postGIS
> ogr2ogr semble le faire aussi :
> http://www.gdal.org/drv_osm.html
>
> Mais ça nous aider, tu veux quel format à la fin pour le traiter dans ta
> chaîne "en ligne de commande" ?
>
>
>
> -
> --
> sly, contact direct : sylvain /a\ letuffe o r g
> http://wiki.openstreetmap.org/wiki/User:Sletuffe
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>
> ___
> 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] requête Overpass en ligne de commande

[sly (sylvain letuffe)]

Samy Mezani wrote
> Je veux simplement obtenir le multipolygone de son ancien contour.

A mon avis, le problème qui fait que tu n'obtiens pas les réponses que tu
attends tient dans l'expression de ton besoin.
Je pense comprendre (je peux me tromper) que ce que tu veux c'est un
multipolygone au sens GIS (postgis, shapefile) du terme alors que les
réponses qui t'ont été données expliquent comment avoir un multipolygone au
sens OSM du terme :
https://wiki.openstreetmap.org/wiki/Relation:multipolygon
(c'est à dire un objet de type"relation")

Car la requête que tu as faite sur l'overpass te donne, selon la
terminologie OSM, le multipolygone de l'ancienne-Bourgogne et tous les
éléments qu'il faut pour en construire un (multi-)polygone (au sens GIS du
terme)
(Pour s'en convaincre, ajoute out meta; et ouvre le avec josm, tu verra que
tu as bien le contour)

Ce que tu cherches (peut-être) maintenant c'est un convertisseur, et
overpass ne fait pas ça.

osm2pgsql sait le faire pour importer dans postgres/postGIS
ogr2ogr semble le faire aussi :
http://www.gdal.org/drv_osm.html

Mais ça nous aider, tu veux quel format à la fin pour le traiter dans ta
chaîne "en ligne de commande" ?



-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk-fr] requête Overpass en ligne de commande

[marc marc]

Le 11. 09. 17 à 14:21, Samy Mezani a écrit :
> Donc , pour résumer, comment n'obtenir que les *ways* membres 
> de la relation et surtout leur géométrie ? 
> (pour importer dans PostGIs, ou visionner dans QGis)
la géométrie d'un way implique d'avoir les nœuds.
"out geom" te donne lat/lon des nœuds sans leur id/tag.
Je ne connais pas PostGIs et donc aucune idée si le format lui convient.

>> Le 11 septembre 2017 à 13:04, marc marc  a écrit :
>> wget -O -
>> 
>> 'http://overpass-api.de/api/interpreter?data=rel[name=Bourgogne]["disused:admin_level"=4];out;'
>>  
>> | egrep '(
>> bourgogne.osm
Le 11/09/2017 à 13:53, Philippe Verdy a écrit :
> pas un fichier OSM valide, ni valide en XML
> Bref il vaut mieux utiliser un vrai filtre XML basé 
> sur le DOM après parsing.
un nom de ce genre de filtre utilisable en ligne de commande ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] requête Overpass en ligne de commande

[Samy Mezani]

Donc , pour résumer, comment n'obtenir que les *ways* membres de la 
relation et surtout leur géométrie ? (pour importer dans PostGIs, ou 
visionner dans QGis)


Mon but est de comprendre ces requêtes pour en faire d'autres sur des 
données plus fréquemment mises à jour.


Là je veux juste obtenir un multipolygone de l'ancienne Bourgogne, comme 
je le fais par exemple avec QuickOSM dans QGis, mais là uniquement en 
ligne de commande.


Merci

Samy

Le 11/09/2017 à 13:53, Philippe Verdy a écrit :



Le 11 septembre 2017 à 13:04, marc marc > a écrit :


Mais en ligne de commande si :

1) récupérer le minimum contenant les infos souhaitées :
wget -O bourgogne.osm
'http://overpass-api.de/api/interpreter?data=rel[name=Bourgogne][

"disused:admin_level"=4];out;'

2) filtrer pour ne garder que la relation, les chemins et le nom
cat bourgogne.osm | egrep '(http://overpass-api.de/api/interpreter?data=rel[name=Bourgogne][

"disused:admin_level"=4];out;'
| egrep '(
bourgogne.osm


Atention ce egrep supprime trop de choses, tu n'obtiendra pas un fichier 
OSM valide, ni valide en XML
- pour la vadlité XML il faut ajouter les balises de fermeture et 
ajouter un objet racine englobant le tout (et faire attention aux 
attributs des tags qui peuvent être sur des lignes séparées et il 
manquera alors des ">" pour terminer les tags d'ouverture)

- mais pour OSM cet objet racine doit en plus suivre le schéma OSM).

Bref ce que tu obtiens c'est juste un objet plus ou moins indenté mais 
pas sûr d'avoir tous les attributs.


De plus rien n'interdit à Overpass de renvoyer du XML compacté (sans 
aucun saut de ligne ni indentation).


Bref il vaut mieux utiliser un vrai filtre XML basé sur le DOM après 
parsing.


Noter aussi que XML/OSM n'est pas le seul format de sortie possible pour 
Overpass. XML est un peu "verbeux" avec ses tags de fermeture. D'autres 
formats possibles sont CSV, Turtle, ... Overpass permet de construire 
son format de sortie adhoc (utilisant la syntaxe de formatage pour le 
CSV). On a des exemples sur le wiki.



___
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] requête Overpass en ligne de commande

[Philippe Verdy]

Le 11 septembre 2017 à 13:04, marc marc  a écrit
:

> Mais en ligne de commande si :
>
> 1) récupérer le minimum contenant les infos souhaitées :
> wget -O bourgogne.osm
> 'http://overpass-api.de/api/interpreter?data=rel[name=Bourgogne][
> "disused:admin_level"=4];out;'
>
> 2) filtrer pour ne garder que la relation, les chemins et le nom
> cat bourgogne.osm | egrep '( k="name")'
>
> On peux bien sur combiner les 2 :
> wget -O -
> 'http://overpass-api.de/api/interpreter?data=rel[name=Bourgogne][
> "disused:admin_level"=4];out;'
> | egrep '( bourgogne.osm
>

Atention ce egrep supprime trop de choses, tu n'obtiendra pas un fichier
OSM valide, ni valide en XML
- pour la vadlité XML il faut ajouter les balises de fermeture et ajouter
un objet racine englobant le tout (et faire attention aux attributs des
tags qui peuvent être sur des lignes séparées et il manquera alors des ">"
pour terminer les tags d'ouverture)
- mais pour OSM cet objet racine doit en plus suivre le schéma OSM).

Bref ce que tu obtiens c'est juste un objet plus ou moins indenté mais pas
sûr d'avoir tous les attributs.

De plus rien n'interdit à Overpass de renvoyer du XML compacté (sans aucun
saut de ligne ni indentation).

Bref il vaut mieux utiliser un vrai filtre XML basé sur le DOM après
parsing.

Noter aussi que XML/OSM n'est pas le seul format de sortie possible pour
Overpass. XML est un peu "verbeux" avec ses tags de fermeture. D'autres
formats possibles sont CSV, Turtle, ... Overpass permet de construire son
format de sortie adhoc (utilisant la syntaxe de formatage pour le CSV). On
a des exemples sur le wiki.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] requête Overpass en ligne de commande

[marc marc]

Mais en ligne de commande si :

1) récupérer le minimum contenant les infos souhaitées :
wget -O bourgogne.osm 
'http://overpass-api.de/api/interpreter?data=rel[name=Bourgogne]["disused:admin_level"=4];out;'

2) filtrer pour ne garder que la relation, les chemins et le nom
cat bourgogne.osm | egrep '(http://overpass-api.de/api/interpreter?data=rel[name=Bourgogne]["disused:admin_level"=4];out;'
 
| egrep '( bourgogne.osm


Le 11. 09. 17 à 12:55, Philippe Verdy a écrit :
> Dans Overpass tu ne peux pas choisir entre avoir un seul tag ("name=*") 
> ou tous les tags d'un objet. Tu peux en revanche obtenir la liste des 
> objets sans leur géométrie ("out;" au lieu de "out geom;")
> Regarde les paramètres possibles pour "out;" selon le niveau de 
> verbosité attendu, si tu ne veux pas la longue liste des noeuds de tous 
> les ways membres.
> 
> Le 11 septembre 2017 à 12:46, Samy Mezani  > a écrit :
> 
> En fait, je souhaite bien tous les descendants de la relation, mais
> pas les nœuds, et si possible obtenir un seul objet de type
> multipolygone.
> 
> Les données ne m'intéressent pas dans ce cas précis, si ce n'est le
> taq name.
> 
> Merci
> 
> Samy
> 
> 
> Le 11/09/2017 à 12:35, Christian Quest a écrit :
> 
> Si tu ne veux que la relation décrivant le multipolygone (et pas
> les way ni les noeuds permettant d'avoir la géométrie complète),
> retire le ">;"
> 
> Tu aura les tags de la relation, la liste des membres, mais rien
> d'autre.
> 
> 
> Le 11/09/2017 à 12:03, Samy Mezani a écrit :
> 
> Bonjour,
> 
> Je tente de faire une requête en ligne de commande pour
> obtenir un fichier osm de l'ancienne région Bourgogne.
> 
> Je veux simplement obtenir le multipolygone de son ancien
> contour.
> 
> Avec ça, j'obtiens tous les objets (nœuds) de la relation :
> 
> wget -O bourgogne.osm
> 
> "http://overpass-api.de/api/interpreter?data=(rel[name=Bourgogne][\
> 
> "disused:admin_level\"=4]);(._;>;);out
> geom;"
> 
> 
> Comment faire pour filtrer ma requête et n'obtenir que le
> multipolygone ? Je me perds dans la doc…
> 
> Merci pour vos conseils
> 
> Samy
> 
> ___
> 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] requête Overpass en ligne de commande

[Philippe Verdy]

Dans Overpass tu ne peux pas choisir entre avoir un seul tag ("name=*") ou
tous les tags d'un objet. Tu peux en revanche obtenir la liste des objets
sans leur géométrie ("out;" au lieu de "out geom;")
Regarde les paramètres possibles pour "out;" selon le niveau de verbosité
attendu, si tu ne veux pas la longue liste des noeuds de tous les ways
membres.

Le 11 septembre 2017 à 12:46, Samy Mezani  a écrit :

> En fait, je souhaite bien tous les descendants de la relation, mais pas
> les nœuds, et si possible obtenir un seul objet de type multipolygone.
>
> Les données ne m'intéressent pas dans ce cas précis, si ce n'est le taq
> name.
>
> Merci
>
> Samy
>
>
> Le 11/09/2017 à 12:35, Christian Quest a écrit :
>
>> Si tu ne veux que la relation décrivant le multipolygone (et pas les way
>> ni les noeuds permettant d'avoir la géométrie complète), retire le ">;"
>>
>> Tu aura les tags de la relation, la liste des membres, mais rien d'autre.
>>
>>
>> Le 11/09/2017 à 12:03, Samy Mezani a écrit :
>>
>>> Bonjour,
>>>
>>> Je tente de faire une requête en ligne de commande pour obtenir un
>>> fichier osm de l'ancienne région Bourgogne.
>>>
>>> Je veux simplement obtenir le multipolygone de son ancien contour.
>>>
>>> Avec ça, j'obtiens tous les objets (nœuds) de la relation :
>>>
>>> wget -O bourgogne.osm "http://overpass-api.de/api/in
>>> terpreter?data=(rel[name=Bourgogne][\"disused:admin_level\"=4]);(._;>;);out
>>> geom;"
>>>
>>>
>>> Comment faire pour filtrer ma requête et n'obtenir que le multipolygone
>>> ? Je me perds dans la doc…
>>>
>>> Merci pour vos conseils
>>>
>>> Samy
>>>
>>> ___
>>> 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] requête Overpass en ligne de commande

[Samy Mezani]

En fait, je souhaite bien tous les descendants de la relation, mais pas 
les nœuds, et si possible obtenir un seul objet de type multipolygone.


Les données ne m'intéressent pas dans ce cas précis, si ce n'est le taq 
name.


Merci

Samy

Le 11/09/2017 à 12:35, Christian Quest a écrit :
Si tu ne veux que la relation décrivant le multipolygone (et pas les way 
ni les noeuds permettant d'avoir la géométrie complète), retire le ">;"


Tu aura les tags de la relation, la liste des membres, mais rien d'autre.


Le 11/09/2017 à 12:03, Samy Mezani a écrit :

Bonjour,

Je tente de faire une requête en ligne de commande pour obtenir un 
fichier osm de l'ancienne région Bourgogne.


Je veux simplement obtenir le multipolygone de son ancien contour.

Avec ça, j'obtiens tous les objets (nœuds) de la relation :

wget -O bourgogne.osm 
"http://overpass-api.de/api/interpreter?data=(rel[name=Bourgogne][\"disused:admin_level\"=4]);(._;>;);out 
geom;"



Comment faire pour filtrer ma requête et n'obtenir que le 
multipolygone ? Je me perds dans la doc…


Merci pour vos conseils

Samy

___
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] requête Overpass en ligne de commande

[Christian Quest]

Si tu ne veux que la relation décrivant le multipolygone (et pas les way 
ni les noeuds permettant d'avoir la géométrie complète), retire le ">;"


Tu aura les tags de la relation, la liste des membres, mais rien d'autre.


Le 11/09/2017 à 12:03, Samy Mezani a écrit :

Bonjour,

Je tente de faire une requête en ligne de commande pour obtenir un 
fichier osm de l'ancienne région Bourgogne.


Je veux simplement obtenir le multipolygone de son ancien contour.

Avec ça, j'obtiens tous les objets (nœuds) de la relation :

wget -O bourgogne.osm 
"http://overpass-api.de/api/interpreter?data=(rel[name=Bourgogne][\"disused:admin_level\"=4]);(._;>;);out 
geom;"



Comment faire pour filtrer ma requête et n'obtenir que le 
multipolygone ? Je me perds dans la doc…


Merci pour vos conseils

Samy

___
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] requête Overpass en ligne de commande

[Philippe Verdy]

Déjà tu peux enlever l'union avec la récursion descendante "(._;>;);" si tu
ne veux que la relation multipolygone, et pas ses descendants; mais ensuite
"out geom;" ne te servira bas beaucoup puisqu'il n'y a pas de géométrie
dans un multipolygone mais juste ses descendants; je suppose que tu veux
ses tags et un "out;" simple suffit". Tu peux choisir une option plus
économique pour "out;" si tu ne veux que le type d'objet et l'id (suffisant
pour charger l'objet seul dans JOSM).
JOSM malgré tout chargera lui-même tous les tags, et la liste complète
des membres
(mais à l'état "incomplet" : tu peux ensuite charger les membres
descendants sélectivement ou bien tous)

Le 11 septembre 2017 à 12:03, Samy Mezani  a écrit :

> Bonjour,
>
> Je tente de faire une requête en ligne de commande pour obtenir un fichier
> osm de l'ancienne région Bourgogne.
>
> Je veux simplement obtenir le multipolygone de son ancien contour.
>
> Avec ça, j'obtiens tous les objets (nœuds) de la relation :
>
> wget -O bourgogne.osm "http://overpass-api.de/api/in
> terpreter?data=(rel[name=Bourgogne][\"disused:admin_level\"=4]);(._;>;);out
> geom;"
>
>
> Comment faire pour filtrer ma requête et n'obtenir que le multipolygone ?
> Je me perds dans la doc…
>
> Merci pour vos conseils
>
> Samy
>
> ___
> 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

[OSM-talk-fr] requête Overpass en ligne de commande

[Samy Mezani]

Bonjour,

Je tente de faire une requête en ligne de commande pour obtenir un 
fichier osm de l'ancienne région Bourgogne.


Je veux simplement obtenir le multipolygone de son ancien contour.

Avec ça, j'obtiens tous les objets (nœuds) de la relation :

wget -O bourgogne.osm 
"http://overpass-api.de/api/interpreter?data=(rel[name=Bourgogne][\"disused:admin_level\"=4]);(._;>;);out 
geom;"



Comment faire pour filtrer ma requête et n'obtenir que le multipolygone 
? Je me perds dans la doc…


Merci pour vos conseils

Samy

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

Re: [OSM-talk-fr] Requête overpass api & python

[Tony Emery]

Jérôme Amagat wrote
> a la place mieux vaux :
> (._; >;);
> out meta;
> cela te donne les même éléments.
> et normalement c'est trier, ça veux pas dire que c'est trier comme tu le
> souhaites.

Effectivement, j'ai remplacé par ce bout de script et cela fonctionne bien
mieux.

Pour les curieux, voici une partie de mon script. Si vous avez des
remarques, je suis ouvert à toute suggestion.

# Import des modules time
import time
import datetime
# Définition des dates et heures de début de processus
DateDuProcess = time.strftime('%d%m%Y',time.localtime())
HeureDuProcess = time.strftime('%H:%M:%S',time.localtime())
heure,minute=0,0
tempsdep = time.clock()
tempsInstr = time.clock()
# Définition du chemin du fichier des logs
logfilePath = r"\\Vdom2\sig\_ARCGIS\log_" + DateDuProcess + ".txt"

# Fonction d'insertion des messages dans le fichier des logs
def insertMessageLogFile(inPathLogFile, message):
logFile = open(inPathLogFile, "a")
logFile.write("\n"+message)
logFile.close()
print(message)

# Fonction de calcule des heures, minutes, secondes
def decoupe(tempsEcoule):
heure = int(tempsEcoule) /3600
tempsEcoule %= 3600
minute = int(tempsEcoule)/60
tempsEcoule%=60
tempsEcoule = (heure+"H "+minute+"m "+tempsEcoule+"s")

insertMessageLogFile(logfilePath, '*'*20)
msgLog = ('1.0 Lancement du script de chargement du fichier osm dans la GDB
le {0} à {1}').format(DateDuProcess,HeureDuProcess)
insertMessageLogFile(logfilePath, msgLog)

# Import des modules
msgLog = ('1.1 Import des modules')
insertMessageLogFile(logfilePath, msgLog)
import arcpy
import os, sys
import urllib2, urllib, re
arcpy.ImportToolbox("C:/Program Files
(x86)/ArcGIS/Desktop10.3/ArcToolbox/Toolboxes/OpenStreetMap Toolbox.tbx",
"osmtools")
tempsEcoule = str(round((time.clock() - tempsInstr),3))
msgLog = ('1.1 Modules importés : {0}s').format(tempsEcoule)
insertMessageLogFile(logfilePath, msgLog)
tempsInstr = time.clock()

# Création des variables
msgLog = ('1.2 Création des variables')
insertMessageLogFile(logfilePath, msgLog)
inFolder = r"\\Vdom2\sig\_PROJETS\_CCPRO_OSM\OSMFiles\Automatique"
inGDB = r"\\Vdom2\sig\_GDB\OSM_CCPRO.gdb"
inFieldLong = "lastmodif"
inFieldDate = "osmtimestamp"
urlxapi = 'http://overpass-api.de/api/interpreter?'
bbox = "(43.98,4.70,44.27,4.99)"
timeout = 65

tempsEcoule = str(round((time.clock() - tempsInstr),6))
msgLog = ('1.2 Variables créées : {0}s').format(tempsEcoule)
insertMessageLogFile(logfilePath, msgLog)
tempsInstr = time.clock()

# Compte du nombre de fichiers planet à importer
arcpy.env.workspace = inFolder
fileCount = 0
fileDone = 1
for osm in arcpy.ListFiles("*.osm"):
fileCount += 1
msgLog = ('1.3 Nombre de fichiers planet à importer :
{0}').format(fileCount)
insertMessageLogFile(logfilePath, msgLog)

# Etape 1 - import des données
msgLog = ('2.1 Les données vont être importées depuis {0} vers
{1}').format(inFolder,inGDB)
insertMessageLogFile(logfilePath, msgLog)
# Boucle sur tous les fichiers osm du dossier
\\Vdom2\sig\_PROJETS\_CCPRO_OSM\OSMFiles\Automatique
for osm in arcpy.ListFiles("*.osm"):
try:
msgLog = ('2.1.1 Fichier planet traité {0}, {1}/{2}').format(osm,
fileDone, fileCount)
insertMessageLogFile(logfilePath, msgLog)
taille = round(os.path.getsize(inFolder + os.sep + osm) / 1024)
tempsBoucle = time.clock()
msgLog = ('2.1.2 Définition du Prédicat de {0}, {1} kO').format(osm,
taille)
insertMessageLogFile(logfilePath, msgLog)
# requête particulière : parking
if osm == 'parking.osm':
requete = '["amenity"="parking"]'
# requête particulière : buildingpart
elif osm == 'buildingpart.osm':
requete = '["building:part"]'
# requête particulière : housenumber
elif osm == 'housenumber.osm':
requete = '["addr:housenumber"]'
# requête particulière : associatedStreet
elif osm == 'associatedStreet.osm':
requete = '["type"="associatedStreet"]'
# requête particulière : PublicTransport
elif osm == 'public_transport.osm':
requete = '["route"="bus"]'
else:
requete = ('["' + osm[:-4] + '"]')

msgLog = ('2.1.3 Création de l\'URL de la requête :
{0}').format(requete)
insertMessageLogFile(logfilePath, msgLog)
# exécution de la requête XAPI
query
='[out:xml][timeout:{0}];(node{1}{2};way{1}{2};relation{1}{2};);(._;>;);out
meta;'.format(timeout,requete, bbox)
query = query.encode('utf8')
query_string = urllib.urlencode({'data': query})

msgLog = ('2.1.4 Lancement de la requête : {0}').format(requete)
insertMessageLogFile(logfilePath, msgLog)
try:
data = urllib2.urlopen(url=urlxapi, data=query_string).read()
except urllib2.HTTPError as e:
if e.code == 400:
print 'Bad request overpass'
# exit()
continue

# overpass timeout
 

Re: [OSM-talk-fr] Requête overpass api & python

[osm . sanspourriel]

Petit correctif : il fallait évidemment lire .ways et non .way.

http://overpass-turbo.eu/s/gXp


Le 23/06/2016 à 23:03, osm.sanspourr...@spamgourmet.com a écrit :




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

Re: [OSM-talk-fr] Requête overpass api & python

[osm . sanspourriel]

Le 24/06/2016 à 00:00, Philippe Verdy - verd...@wanadoo.fr a écrit :
Le 23 juin 2016 à 23:03, > a écrit :


Certes comme dit Philippe, ce n'est pas forcément encore bon, pour
les relations mais par exemple tu pourras ajouter des filtres pour
sortir les associatedStreet avant ou après si ce n'est pas
exactement ce que tu cherches.

Comme dit pas Philippe, moins tu mets de contraintes côté serveur,
mieux c'est.

Je l'ai dit aussi...
Un s au lieu d'un r (j'ai voulu écrire "Comme dit pa*r* Philippe" comme 
le contexte permettait de toute évidence de corriger) et bla, bla, bla...


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

Re: [OSM-talk-fr] Requête overpass api & python

[Philippe Verdy]

Le 24 juin 2016 à 00:45, Jérôme Amagat  a écrit :

>
> a la place mieux vaux :
> (._; >;);
> out meta;
> cela te donne les même éléments.
> et normalement c'est trier, ça veux pas dire que c'est trier comme tu le
> souhaites.
>

Non ceci n'est pas "trié", c'est juste une "union", qui sera
(éventuellement) sortie dans un ordre quelconque, ou pas sortie du tout
(qui dépend de la façon dont sont indexés les éléments d'une union : en
pratique l'index assure uniquemetn l'unicité des éléments sur le critère
(type d'objet, id) mais l'ordre peut être aléatoire (notammment si l'index
de l'union est une table de hachage, bien plus rapide à calculer et
beaucoup moins couteux qu'une table triée sur ces mêmes éléments, même si
ce tri est fait sur un index en B-arbre qui préserve un critère de tri).

S'il y a un tri, il n'est que dans la commande "out" elle-même (sur son
propre jeu de données, mais pas sur les autres commandes "out" de la
requête, dont les résultats sont juste juxtaposés dans l'ordre des "out"
sans vérifier même si des données sont déjà sorties dans un "out" précédent.

L'ordre final "out meta" ne précise aucun tri particulier (et le seul tri
supporté en fait est le tri géographique en quadtiles (out meta qt)... qui
ne trie en fait que les noeuds et ne garantie rien du tout sur les ways et
relations qui n'ont pas toujours une bounding box déterminée si ces
éléments composites ne sont pas "complets" dans le jeu de données
retourné!).

Actuellement aucun tri topologique n'est supporté par Overpass, c'est au
client de le réaliser s'il en a besoin pour n'avoir que des références à
des objets définis en amont mais aucune vers des objets définis en aval.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Requête overpass api & python

[Jérôme Amagat]

si tu met çà :

out meta;
>;
out meta;
ça fait 2 sorties donc sûr que tu n'aura pas ce que tu veux pareil "qt"
comme ça a été dit c'est un tri géographique.
(c'est possible aussi comme il y a 2 sorties que tu es 2 fois le même
élément. j'ai deja eu le cas et je comprenait pas d’où ça venait)


a la place mieux vaux :
(._; >;);
out meta;
cela te donne les même éléments.
et normalement c'est trier, ça veux pas dire que c'est trier comme tu le
souhaites.



pour un tri après coup, je sait que osmosis peut trier les éléments d'un
fichier osm avec --sort
http://wiki.openstreetmap.org/wiki/Osmosis
exemple :
osmosis --read-xml file="data.osm" --sort type="TypeThenId" --write-xml
file="data-sorted.osm"
pareil ça trie mais je sais pas si c'est ce que tu veux comme tri.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Requête overpass api & python

[Philippe Verdy]

Le 23 juin 2016 à 23:03,  a écrit :

> Certes comme dit Philippe, ce n'est pas forcément encore bon, pour les
> relations mais par exemple tu pourras ajouter des filtres pour sortir les
> associatedStreet avant ou après si ce n'est pas exactement ce que tu
> cherches.
>
> Comme dit pas Philippe, moins tu mets de contraintes côté serveur, mieux
> c'est.
>
Je l'ai dit aussi... En expliquant que le tri avait un cout sur le serveur
et en disant que si au final ce sont les même données et que cela ne change
rien au volume final, autant faire ce tri côté client... et donc soulanger
le serveur d'espaces temporaires supplémentaires.

J'avais abordé les quadtiles aussi, qui ont aussi un coût (bien qu'il soit
faible si la base a déjà trié ses objets par quadtiles: en sortant les
objets trouvés dans la base au fil de l'eau, ils seront déjà dans cet
ordre, pas besoin de retrier en fait).

Le tri des quadtiles cependant ne concerne que les noeuds (les chemins et
relations peuvent facilement déborder des tas de quadtiles, au pire on peut
les indexer en quadtile sur leur bounding-box: possible facilement pour les
ways, beaucoup moins pour les relations qui dans certains cas (souvent
pathogènes) sont cycliques, mais ces cycles de références mutuelles
existent dans la base qui ne les interdit pas: les bounding box des
relations ne sont pas toujours définies et la cloture récursive des
références est très coûteuse à calculer, elle peut parfois ramener des
références sur des milleirs de relations, des dizaines de milliers de
chemins et des millions de noeuds

En revanche le tri topologique a un coût raisonnable (mineur). Le tri par
ID en revanche est assez stupide et ne sert à rien (il ne sert à rien pour
trier les noeuds, à rien pour trier les ways, et ne résoud pas l'ordre des
dépendances pour trier les relations contrairement au tri topologique.

Cependant un tri topologique strict n'est pas toujours possible sur les
relations à références cycliques (exemple: relation A membre de la relation
B, relation B membre de la relation A). Ce cas est rare dans la base mais
cela a été l'objet d'une correction dans JOSM pour éviter des récursions
infinies durant le rendu (en évitant de parcourir à nouveau une relation
mère d'une fois si une des sous-relations la référence en dessous) !
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Requête overpass api & python

[osm . sanspourriel]

Certains t'expliquent que si tu vois des majuscules, c'est qu'il faut 
que tu changes de lunettes.

Certains t'expliquent que si tu veux trier, c'est que tu te trompes.

C'est dommage car leurs raisons, souvent bonnes, sont parasitées par la 
volonté d'avoir raison quitte à falsifier la réalité pour retomber sur 
leurs pieds.


Je préfère t'expliquer comment obtenir un résultat, pas forcément 
correspondant à tes besoins mais t'aidant à répondre à ton besoin.


Je vois que tu a mis :

out meta asc;
>;out meta qt;

Donc tu tries les objets highway dans l'ordre des ID puis les 
descendants par quadtile.


C'est sans doute ton problème. Il vaut mieux sortir les nœuds, puis les 
chemins puis les relations.


Certes comme dit Philippe, ce n'est pas forcément encore bon, pour les 
relations mais par exemple tu pourras ajouter des filtres pour sortir 
les associatedStreet avant ou après si ce n'est pas exactement ce que tu 
cherches.


Comme dit pas Philippe, moins tu mets de contraintes côté serveur, mieux 
c'est.

Par exemple :

out meta;

(tri par défaut par id croissant)

plutôt que :

out meta qt;
(tri géographique par quadtile).

Si l'emprise est raisonnable, ça va bien côté client.

Ne récupères que ce qui te sera utile, ici tu récupères 40 Mo de données.

Tu peux regrouper les objet par type pour éviter les doublons.

Je ne sais ce qui est moins coûteux : l'opérateur union () ou le renvoi 
de trop de données.


Avec la requête brute j'obtiens 40 Mo (pas d'union, out meta après 
chaque instruction (lignes 13, 15, 17, 23 et 26)), avec l'union 30 Mo.


Peut-être que seuls certains nœuds t'intéressent.
Il est possible aussi que 
Overpass_API_by_Example#QA_on_Streets.2C_Addresses_and_House_Numbers 



soit proche de ton bonheur !

http://overpass-turbo.eu/s/gXi

[out:json][timeout:65];
// zone réduite pour les tests
//(43.98,4.70,44.27,4.99)
// zone complète
//(43.98,4.70,43.99,4.79)
node["highway"](43.98,4.70,44.27,4.99)->.nodes;
// les chemins
way["highway"](43.98,4.70,44.27,4.99)->.ways;
// les relations
relation["highway"](43.98,4.70,44.27,4.99)->.relations;
// d'abord les noeuds
(
  .nodes;
// les noeuds des voies
  node(w.ways);
// les noeuds des relations
  node(r.relations);
);
 out meta;

// les chemins
(
  .way;
  // les chemins des relations
  // attention de pas de récursivité, des relations peuvent manquer, je 
ne vois pas trop quoi mais vérifie

  way(r.relations);
);
 out meta;
// requête initiale
/*http://overpass-api.de/api/interpreter?[out:xml][timeout:65];(node["highway"](43.98,4.70,44.27,4.99);way["highway"](43.98,4.70,44.27,4.99);relation["highway"](43.98,4.70,44.27,4.99););out
meta asc;>;out meta qt;*/


Le 22/06/2016 à 08:48, Tony Emery - tony.em...@yahoo.fr a écrit :

Je déterre un peu le sujet car il y a un petit truc dans le script que j'ai
réalisé qui me chiffonne.

Quand la requête est lancée (par exemple, pour importer les voies), le
fichier Planet généré contient bien les objets demandé mais il ne sont pas
forcément classés (ou alors, je ne sais pas avec quelle ordre de tri).

Le fait d'ouvrir le fichier avec JOSM et d'enregistrer à nouveau le fichier
fait que les données sont triées. Cela veut dire que JOSM lit le fichier et
remet de l'ordre dans tout ça.

Or, FME ne sait pas faire ça et, du coup, n'arrive pas a interpréter le
fichier Planet brut.

Du coup, je me demandais s'il n'y avait pas une option a indiquer dans la
requête pour trier les objets (d'abord les nodes, puis les ways et enfin les
relations) ?



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Requete-overpass-api-python-tp5863030p5876134.html
Sent from the France mailing list archive at Nabble.com.

___
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] Requête overpass api & python

[Tony Emery]

Du coup, je devrais plutôt mettre ça à la place ?

(
  ._;
  >;
);
out meta;





-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Requete-overpass-api-python-tp5863030p5876180.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Requête overpass api & python

[Etienne Trimaille]

Overpass donne des résultats ordonnés par défaut, sauf quand on lui donne
plusieurs sorties (out,print), du coup ils les exécutent dans l'ordre de ta
requête overpass.
Je ne connais plus la syntaxe OQL, mais en XML, il faut :
 
  
  
 
 
Un seul print (out en OQL) est suffisant. Dans ta requête, tu en as deux,
ce qui est inutile (seulement utile pour overpass turbo).
Essaye ta requête dans QuickOSM, tu dois obtenir l'avertissement que ton
fichier n'est pas ordonné. Puis supprime le "out" de trop en t'assurant que
tu récupères bien les objets enfants (jusqu'à aux nœuds)

2016-06-22 9:19 GMT+02:00 Tony Emery :

> Ma requête doit ressembler à ça :
> #
> http://overpass-api.de/api/interpreter?[out:xml][timeout:65];(node[
> "highway"](43.98,4.70,44.27,4.99);way["highway"](43.98,4.70,44.27,4.99);relation["highway"](43.98,4.70,44.27,4.99););out
> meta asc;>;out meta qt;
>
> Et quand j'ajoute les paramètre, dans mon script Python, ça donne ça :
> query
> ='[out:xml][timeout:{0}];(node{1}{2};way{1}{2};relation{1}{2};);out meta
> asc;>;out meta qt;'.format(timeout,requete, bbox)
> query = query.encode('utf8')
> query_string = urllib.urlencode({'data': query})
>
> msgLog = ('2.1.4 Lancement de la requête : {0}').format(requete)
> insertMessageLogFile(logfilePath, msgLog)
> try:
> data = urllib2.urlopen(url=urlxapi, data=query_string).read()
> except urllib2.HTTPError as e:
> if e.code == 400:
> print 'Bad request overpass'
> # exit()
> continue
>
>
>
> -
> Tony EMERY
> Administrateur OpenStreetMap.fr
> Mandataire Grand Sud-Est
> Géomaticien & chef de projets
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Requete-overpass-api-python-tp5863030p5876139.html
> Sent from the France mailing list archive at Nabble.com.
>
> ___
> 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] Requête overpass api & python

[Philippe Verdy]

A priori les requêtes Overpass n'ont pas besoin de trier les objets.
Cependant le chargement de données dans un schéma destiné à les lier entre
elles peut nécessiter que les objets dépendants (les noueds d'un way, ou
les membres d'une relation) soient déclarés avant l'objet qui en dépent (le
way ou la relation) sinon ils ne trouvent pas les objets liés et l'objet
dépendant ne peut pas être créé.

Les ids d'objets ne sont pas indispensables partout car on n'a pas
nécessairemetn besoin des objets liés à un objet parent, juste de l'objet
parent lui-même et ses tags. Overpass ne trie pas car le tri a un coût en
mémoire (et certaines requêtes volumineuses ne pourraient pas alors
fonctionner, le serveur ne pouvant allouer la mémoire ou l'espace de
stockage temporaire nécessaire).

L'idée est que si un tri est nécessaire, c'est plutôt au client de le faire
lui-même plutôt que le serveur (qui sert à plein de monde et ne peut pas
allouer beaucoup de mémoire pour un seul utilisateur).

Sinon si un tri est nécessaire, lister tous les noeuds, puis tous les ways
puis tous les membres peut ne pas suffire (les relations peuvent aussi
avoir des relations dépendantes dans leurs membres). Si un tri devait être
fait, ce devrait être un tri "topologique": pas besoin de tri global (les
objets en général n'ont pas d'ordre, surtout pas selon leur id qui a une
valeur arbitraire), mais plutôt envoyer les objets au fil de l'eau, mais si
un objet n'est pas complet (ses membres ne sont pas encore sortis, alors le
mettre en attente d'un autre objet, sortir tout le reste et dès qu'un des
objets de ce reste est sorti qui était marqué comme en attente, sortir
l'objet qui était en attente). A la fin tous les objets en attente
devraient être sortis. Cette approche demandera beaucoup moins de mémoire.

Noter aussi qu'Overpass permet de sélectionner des objets sans faire aucune
récursion sur ses membres. Bref Overpass ne peut pas non plus imposer un
tri topologique, d'autant plus que ses requêtes sont ordonnées et qu'il
peut manipuler et sortir plusieurs "result sets" séparés (rien n'indique
que ces "result sets" multiples sont liés entre eux, et Overpass pourra
même sortir un même objet plusieurs fois (dans des résult sets séparés:
Overpass n'impose pas de calculer l'union des "result sets" dans un nouveau
"result set" unique).

Ceci dit, quand Overpass sort un "result set", autant que possible celui-ci
devrait être sorti dans un ordre topologique (qui n'est pas nécessairement
un tri complet non plus: les objets retournés peuvent être mélangés, mais
il s'assurera que si un objet est lié à un autre dans le même result set,
les objets dépendant liés seront sortis avant les objets liants). Dans un
tri topologique si deux objets A et B ne sont pas liés entre eux (aucun ne
dépend de l'autre), on peut les sortir dans un ordre quelconque (donc A,B
ou B,A, peu importe, un moteur les sortira autant que possible au fil de
l'eau selon sa représentation interne qui lui évite d'avoir à revenir
dessus plus tard et lui évite chaque fois que possible de gérer un espace
temporaire de mise en attente).

Ne pas imposer de tri dans Overpass permet justement des optimisations pour
la représentation interne des result sets, et pour accélérer notamment le
calcul des unions et intersections: plutôt que de faire des fusions par
tri, il utilisera des tables de hachage qui sont beaucoup plus rapides.
Hors les tables de hachage mélangent les objets indexés dans un ordre quasi
aléatoire (c'est une nécessité même de la fonctio nde hachage pour qu'elle
soit la plus efficace possible, avec le moins possible de "collisions" sur
une clé de hachage et une bonne distribution).

Overpass peut aussi trier les objets dans un ordre facilitant le traitement
2D, par exemple avec le tri "quadtile", si on le lui demande: ce tri
facilite, du côté client la division d'une tâche de traitement en
permettant de créer des taches pour des zones rectangulaires avec toutes
les données locales proches dans le jeu de données. Cependant là encore ce
n'est qu'un des critères de tri possible (et cela n'exclue pas en plus de
faire un tri topologique, sanchant que dans un seul "quadtile" il peut y
avoir des données dépendantes qui sont dans un ou plusieurs autres
"quadtiles" voisins): les quadtiles ne trient en fait que les noeuds, les
chemins et relations qui seraient liés à ces noeuds seront sortis après.

Mais d'une façon générale, oui les noeuds peuvent toujours être sortis en
premier (dans un ordre quelconque) car il ne sont liés à rien, puis tous
les chemins dans un ordre quelconque car ils ne sont liés qu'à des noeuds
(et aucun autre chemin), le cas se complique avec les relations à la fin
(qui ont des relations entre elles). Cependant mettre tous les noeuds avant
les chmins et relations n'est pa non plus efficace côté client qui ne peut
par exemple pas commencer à traiter les chemins utilisant les premiers
noeuds avant que la totalité des noeuds soient sortis.

Un tri topologique complet 

Re: [OSM-talk-fr] Requête overpass api & python

[Tony Emery]

Ma requête doit ressembler à ça :
#
http://overpass-api.de/api/interpreter?[out:xml][timeout:65];(node["highway"](43.98,4.70,44.27,4.99);way["highway"](43.98,4.70,44.27,4.99);relation["highway"](43.98,4.70,44.27,4.99););out
meta asc;>;out meta qt;

Et quand j'ajoute les paramètre, dans mon script Python, ça donne ça :
query
='[out:xml][timeout:{0}];(node{1}{2};way{1}{2};relation{1}{2};);out meta
asc;>;out meta qt;'.format(timeout,requete, bbox)
query = query.encode('utf8')
query_string = urllib.urlencode({'data': query})

msgLog = ('2.1.4 Lancement de la requête : {0}').format(requete)
insertMessageLogFile(logfilePath, msgLog)
try:
data = urllib2.urlopen(url=urlxapi, data=query_string).read()
except urllib2.HTTPError as e:
if e.code == 400:
print 'Bad request overpass'
# exit()
continue



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Requete-overpass-api-python-tp5863030p5876139.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Requête overpass api & python

[Etienne Trimaille]

Cela vient de ta requête overpass.
Il y a le même problème dans QuickOSM, il faut que les objets soient dans
le bon ordre.
Avec l'assistant par défaut d'Overpass Turbo, on peut obtenir l'ordre
inverse.  Est-ce que l'on peut voir la requête ?

Le 22 juin 2016 à 08:48, Tony Emery  a écrit :

> Je déterre un peu le sujet car il y a un petit truc dans le script que j'ai
> réalisé qui me chiffonne.
>
> Quand la requête est lancée (par exemple, pour importer les voies), le
> fichier Planet généré contient bien les objets demandé mais il ne sont pas
> forcément classés (ou alors, je ne sais pas avec quelle ordre de tri).
>
> Le fait d'ouvrir le fichier avec JOSM et d'enregistrer à nouveau le fichier
> fait que les données sont triées. Cela veut dire que JOSM lit le fichier et
> remet de l'ordre dans tout ça.
>
> Or, FME ne sait pas faire ça et, du coup, n'arrive pas a interpréter le
> fichier Planet brut.
>
> Du coup, je me demandais s'il n'y avait pas une option a indiquer dans la
> requête pour trier les objets (d'abord les nodes, puis les ways et enfin
> les
> relations) ?
>
>
>
> -
> Tony EMERY
> Administrateur OpenStreetMap.fr
> Mandataire Grand Sud-Est
> Géomaticien & chef de projets
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Requete-overpass-api-python-tp5863030p5876134.html
> Sent from the France mailing list archive at Nabble.com.
>
> ___
> 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] Requête overpass api & python

[Tony Emery]

Je déterre un peu le sujet car il y a un petit truc dans le script que j'ai
réalisé qui me chiffonne.

Quand la requête est lancée (par exemple, pour importer les voies), le
fichier Planet généré contient bien les objets demandé mais il ne sont pas
forcément classés (ou alors, je ne sais pas avec quelle ordre de tri).

Le fait d'ouvrir le fichier avec JOSM et d'enregistrer à nouveau le fichier
fait que les données sont triées. Cela veut dire que JOSM lit le fichier et
remet de l'ordre dans tout ça.

Or, FME ne sait pas faire ça et, du coup, n'arrive pas a interpréter le
fichier Planet brut.

Du coup, je me demandais s'il n'y avait pas une option a indiquer dans la
requête pour trier les objets (d'abord les nodes, puis les ways et enfin les
relations) ?



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Requete-overpass-api-python-tp5863030p5876134.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Requête overpass api & python

[Tony Emery]

Du coup, j'ai pas mal avancé sur mon script python.
En prérequis, j'ai :
- un dossier qui contient 19 fichiers planet nommés en fonction du tag
principal (highway.osm, landuse.osm, barrier.osm,...)
- une géodatabase contenant des jeux de classe d'entités (une par fichier
planet)

En gros, voici ce que fait le script :
- il télécharge les données OSM via une requête overpass dans chaque fichier
planet
- il importe chaque fichier planet dans le jeu de classe d'entités
correpondant de la gdb
- il extrait tous les tags de chaque classe d'entités
- il ajoute 2 champs de coordonnées pour les couches de point
- il ajoute un champ pour calculer le temps écoulé entre la date de la
dernière modification de chaque objet et la date de l'import des données
- il récupère les tags dans les tables des relations




-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Requete-overpass-api-python-tp5863030p5866598.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Requête overpass api & python

[Philippe Verdy]

les parenthèses c'est pour créer une union de plusieurs ensembles d'objets
et donc éliminer les doublons éventuellement retournés entre les deux
requêtes. cela permet aussi de fournir les données de l'union avec un tri
cohérent.
Sinon les deux out meta retournent les deux ensembles sans les comparer,
c'est plus rapide sur le serveur, et ça lui demande moins de mémoire
temporaire. C'est au client ensuite et non au serveur d'éliminer les
doublons éventuels, et de trier les deux ensembles.

Le 29 décembre 2015 à 16:58, Etienne Trimaille 
a écrit :

> Tu peux remplacer :
> out meta;
> >;
> out meta;
> par
> (
>   ._;
>   >;
> );
> out meta;
>
> Faut pas me demander comment l'écrire. C'est du chinois pour moi :)
> Mais je sais que c'est comme ca qu'il faut supprimer les deux out.
> Entre les parenthèses, c'est pour ajouter les récursivités vers les nœuds.
>
> Le 29 décembre 2015 à 10:25, Tony Emery  a écrit :
>
>> Etienne Trimaille wrote
>> > Exactement comme pour le format, c'est dans la requête overpass qu'il
>> faut
>> > spécifier cela et non pas dans le script python ;-)
>> > Il faut mettre un out meta; au lieu de out body;
>>
>> Petite question supplémentaire, pourquoi doit-on écrire 2 fois "out meta"
>> :
>> );
>> out meta;
>> >;
>> out meta;
>>
>> A priori, le premier concerne les objets qui sont retournés mais je ne
>> vois
>> pas à quoi sert celui qui se trouve après >;
>>
>>
>>
>> -
>> Tony EMERY
>> Administrateur OpenStreetMap.fr
>> Mandataire Grand Sud-Est
>> Géomaticien & chef de projets
>> --
>> View this message in context:
>> http://gis.19327.n5.nabble.com/Requete-overpass-api-python-tp5863030p5863364.html
>> Sent from the France mailing list archive at Nabble.com.
>>
>> ___
>> 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] Requête overpass api & python

[Etienne Trimaille]

Tu peux remplacer :
out meta;
>;
out meta;
par
(
  ._;
  >;
);
out meta;

Faut pas me demander comment l'écrire. C'est du chinois pour moi :)
Mais je sais que c'est comme ca qu'il faut supprimer les deux out.
Entre les parenthèses, c'est pour ajouter les récursivités vers les nœuds.

Le 29 décembre 2015 à 10:25, Tony Emery  a écrit :

> Etienne Trimaille wrote
> > Exactement comme pour le format, c'est dans la requête overpass qu'il
> faut
> > spécifier cela et non pas dans le script python ;-)
> > Il faut mettre un out meta; au lieu de out body;
>
> Petite question supplémentaire, pourquoi doit-on écrire 2 fois "out meta" :
> );
> out meta;
> >;
> out meta;
>
> A priori, le premier concerne les objets qui sont retournés mais je ne vois
> pas à quoi sert celui qui se trouve après >;
>
>
>
> -
> Tony EMERY
> Administrateur OpenStreetMap.fr
> Mandataire Grand Sud-Est
> Géomaticien & chef de projets
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Requete-overpass-api-python-tp5863030p5863364.html
> Sent from the France mailing list archive at Nabble.com.
>
> ___
> 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] Requête overpass api & python

[Tony Emery]

Etienne Trimaille wrote
> Exactement comme pour le format, c'est dans la requête overpass qu'il faut
> spécifier cela et non pas dans le script python ;-)
> Il faut mettre un out meta; au lieu de out body;

Petite question supplémentaire, pourquoi doit-on écrire 2 fois "out meta" : 
);
out meta;
>;
out meta;

A priori, le premier concerne les objets qui sont retournés mais je ne vois
pas à quoi sert celui qui se trouve après >;



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Requete-overpass-api-python-tp5863030p5863364.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Requête overpass api & python

[Jo]

d'abord pour les données résultant de la requête, puis >; veut dire que tu
veux tous les objets dépendants (les noeuds pour les ways, p.e.), puis tu
veux les données meta pour ceux-là aussi.

Polyglot

2015-12-29 10:25 GMT+01:00 Tony Emery :

> Etienne Trimaille wrote
> > Exactement comme pour le format, c'est dans la requête overpass qu'il
> faut
> > spécifier cela et non pas dans le script python ;-)
> > Il faut mettre un out meta; au lieu de out body;
>
> Petite question supplémentaire, pourquoi doit-on écrire 2 fois "out meta" :
> );
> out meta;
> >;
> out meta;
>
> A priori, le premier concerne les objets qui sont retournés mais je ne vois
> pas à quoi sert celui qui se trouve après >;
>
>
>
> -
> Tony EMERY
> Administrateur OpenStreetMap.fr
> Mandataire Grand Sud-Est
> Géomaticien & chef de projets
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Requete-overpass-api-python-tp5863030p5863364.html
> Sent from the France mailing list archive at Nabble.com.
>
> ___
> 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] Requête overpass api & python

[Tony Emery]

Du coup, quel différence existe-t-il entre le GET et me POST et où doit-on
paramétrer tout ça ?

Pour l'erreur HTTP 419, normalement, mes requêtes se lancent les unes après
les autres et après d'autres traitements effectués dans les données. Il y a
peu de chances pour que 2 requêtes se lancent en même temps.




-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Requete-overpass-api-python-tp5863030p5863088.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Requête overpass api & python

[Etienne Trimaille]

Le 23 décembre 2015 à 09:51, François Lacombe  a
écrit :

> On dirait plutôt du GET, et l'overpass-tubro a l'air d'envoyer du POST
> à chaque fois.
> Si on peut le taper en GET, c'est d'autant mieux.
>

Oui, le script utilise du GET.
Le script n'utilise pas l'overpass-turbo, mais l'overpass api.


> Par ailleurs, attention à l'erreur HTTP 419 indiquant qu'une requête
> est déjà en cours d’exécution pour la même IP.
> C'est important si on veut en lancer plusieurs.
>

Ah merci pour l'indice. Je vais le rajouter dans mes scripts :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Requête overpass api & python

[François Lacombe]

Non je voulais bien dire en GET, dans un esprit de respect du protocole http.

En théorie, GET est plus approprié, puisqu'on cherche à obtenir des
données du serveur plus qu'à en envoyer.
POST est réservé à la création de contenu sur le serveur, c'est pas le
cas ici, on fait une requête dans l'espoir d'obtenir un résultat.

Sauf qu'on se heurte aux limites du protocole que je n'ai pas vu tout
de suite et POST est le seul outil à pouvoir nous sortir de là.
Si la requête est trop longue, on aura beau respecter la norme, le
serveur ne comprendra pas le message.

A+
François Lacombe

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux


Le 23 décembre 2015 à 11:49, Etienne Trimaille
 a écrit :
> Le 23 décembre 2015 à 09:51, François Lacombe  a
> écrit :
>>
>> Si on peut le taper en GET, c'est d'autant mieux.
>
>
> C'est pour ça que je ne comprenais pas ce message :)
> Tu voulais dire en POST !
>
> Merci pour les infos. Je vais vérifier mon code.
>
> ___
> 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] Requête overpass api & python

[Etienne Trimaille]

Exactement comme pour le format, c'est dans la requête overpass qu'il faut
spécifier cela et non pas dans le script python ;-)
Il faut mettre un out meta; au lieu de out body;

Le 23 décembre 2015 à 16:16, Tony Emery  a écrit :

> Alors, dans le script que propose Etienne, les métadonnées des objets ne
> remontent pas (par exemple, version="7" timestamp="2014-10-14T10:45:02Z"
> changeset="26069043" uid="675449" user="jseigneuret">).
>
> Il y a une option à ajouter dans le script ou l'erreur est-elle plus grave
> ?
>
>
>
> -
> Tony EMERY
> Administrateur OpenStreetMap.fr
> Mandataire Grand Sud-Est
> Géomaticien & chef de projets
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Requete-overpass-api-python-tp5863030p5863120.html
> Sent from the France mailing list archive at Nabble.com.
>
> ___
> 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] Requête overpass api & python

[Tony Emery]

J'ai trouvé.
Il faut mettre :
;
out meta;
>;
out meta;

 à la place de 
;
out body;
>;
out skel qt;



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Requete-overpass-api-python-tp5863030p5863124.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Requête overpass api & python

[Tony Emery]

Alors, dans le script que propose Etienne, les métadonnées des objets ne
remontent pas (par exemple, version="7" timestamp="2014-10-14T10:45:02Z"
changeset="26069043" uid="675449" user="jseigneuret">).

Il y a une option à ajouter dans le script ou l'erreur est-elle plus grave ?



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Requete-overpass-api-python-tp5863030p5863120.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Requête overpass api & python

[François Lacombe]

Le 23 décembre 2015 à 11:18, Etienne Trimaille
 a écrit :
> Oui, le script utilise du GET.
> Le script n'utilise pas l'overpass-turbo, mais l'overpass api.

C'est bien une spécification de l'overpass-API, l'overpass turbo ne
peut que s'y conformer.
Et pour cause : utiliser GET force à passer la requête dans l'URL dont
la longueur est limité à 4096 caractères. Il faut donc bien prendre
garde à ce que la requête oAPI ne soit pas trop longue.
D'ou le post, où la requête oAPI est transmise dans le corps HTTP et
peut avoir la longueur qu'on veut.

>
> Ah merci pour l'indice. Je vais le rajouter dans mes scripts :)
Si les heures de galères peuvent en aider d'autres c'est avec plaisir ;)

Le 23 décembre 2015 à 10:52, Tony Emery  a écrit :
> Du coup, quel différence existe-t-il entre le GET et me POST et où doit-on
> paramétrer tout ça ?

Bonne question, je ne fais pas de http en Python

>
> Pour l'erreur HTTP 419, normalement, mes requêtes se lancent les unes après
> les autres et après d'autres traitements effectués dans les données. Il y a
> peu de chances pour que 2 requêtes se lancent en même temps.
Idem de mon côté, mais elle apparait quand même de temps à autre, même
si les requêtes sont envoyées les unes après les autres.
Il faut la gérer quand même sinon on ne sera pas au courant que la
requête à retourné une exception.

A+


François

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

Re: [OSM-talk-fr] Requête overpass api & python

[Etienne Trimaille]

Le 23 décembre 2015 à 09:51, François Lacombe  a
écrit :

> Si on peut le taper en GET, c'est d'autant mieux.
>

C'est pour ça que je ne comprenais pas ce message :)
Tu voulais dire en POST !

Merci pour les infos. Je vais vérifier mon code.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Requête overpass api & python

[François Lacombe]

Bonjour à vous,

Dans le script qu'Etienne a adapté, s'agit-il d'une requête http POST ou GET ?
On dirait plutôt du GET, et l'overpass-tubro a l'air d'envoyer du POST
à chaque fois.
Si on peut le taper en GET, c'est d'autant mieux.

Par ailleurs, attention à l'erreur HTTP 419 indiquant qu'une requête
est déjà en cours d’exécution pour la même IP.
C'est important si on veut en lancer plusieurs.

A+
François Lacombe

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux


Le 23 décembre 2015 à 08:52, Etienne Trimaille
 a écrit :
> Ton problème, c'est le format de sortie de ta requête overpass. Change
> "json" en "xml" ;-)
>
> Pour la requête sur plusieurs lignes, bien sur tu peux changer. C'était
> juste pour plus de lisibilité.
>
> Le 23 décembre 2015 à 08:42, Tony Emery  a écrit :
>>
>> Etienne Trimaille wrote
>> > J'ai plusieurs script python qui utilise l'api overpass, QuickOSM par
>> > exemple.
>> > J'ai adapté ton code rapidement :
>> > https://gist.github.com/Gustry/378058e2984faeddac47
>>
>> A priori, ton script fonctionne plutôt bien mais il doit y avoir un
>> problème
>> à l'encodage car le fichier généré est du type :
>>
>> {
>>   "version": 0.6,
>>   "generator": "Overpass API",
>>   "osm3s": {
>> "timestamp_osm_base": "2015-12-23T07:23:02Z",
>> "copyright": "The data included in this document is from
>> www.openstreetmap.org. The data is made available under ODbL."
>>   },
>>   "elements": [
>>
>> {
>>   "type": "node",
>>   "id": 25178536,
>>   "lat": 44.0034820,
>>   "lon": 4.7046202,
>>   "tags": {
>> "addr:postcode": "30120",
>> "address": "A 9 - direction Orange/Nîmes, Aire de Tavel Nord",
>> "amenity": "fuel",
>> "fuel:diesel": "yes",
>> "fuel:e10": "yes",
>> "fuel:lpg": "yes",
>> "fuel:octane_98": "yes",
>> "is_in": "A-9",
>> "name": "Station Esso",
>> "opening_hours": "24/7",
>> "operator": "Esso",
>> "source": "stations.gpl.online.fr;source = Ministère de l'Economie, de
>> l'Industrie et du Numérique - 15/09/2014"
>>   }
>> },
>>
>> Alors que moi j'ai besoin plutôt de :
>>
>> 
>> 
>> The data included in this document is from www.openstreetmap.org.
>> The
>> data is made available under ODbL.
>> 
>>
>>   > timestamp="2014-10-14T10:45:02Z" changeset="26069043" uid="675449"
>> user="jseigneuret">
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>   
>>
>>
>>
>> -
>> Tony EMERY
>> Administrateur OpenStreetMap.fr
>> Mandataire Grand Sud-Est
>> Géomaticien & chef de projets
>> --
>> View this message in context:
>> http://gis.19327.n5.nabble.com/Requete-overpass-api-python-tp5863030p5863079.html
>> Sent from the France mailing list archive at Nabble.com.
>>
>> ___
>> 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] Requête overpass api & python

[Tony Emery]

Etienne Trimaille wrote
> J'ai plusieurs script python qui utilise l'api overpass, QuickOSM par
> exemple.
> J'ai adapté ton code rapidement :
> https://gist.github.com/Gustry/378058e2984faeddac47

Merci, c'est exactement ça. Je vais tester tout ça...

Je suppose qu'on peut mettre la partie query=... sur la même ligne ?
Parce qu'en fait, j'ai une boucle qui va lancer autant de requête en
fonction des fichiers xml présents dans un dossier.



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Requete-overpass-api-python-tp5863030p5863047.html
Sent from the France mailing list archive at Nabble.com.

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

[OSM-talk-fr] Requête overpass api & python

[Tony Emery]

Bonjour à tous,

J'ai créé un script python qui me permet, entre autre, de télécharger les
données OSM en local sur mon poste. Je lance ce script en tâche planifiée 2
fois par jour.

Je pense que http://api.openstreetmap.fr/xapi? ne répond plus car les
requêtes que je lance sur ce site me renvoie des tables vides depuis 4
jours.

Du coup, j'essaye de m'adapter en tapant directement dans l'API overpass.

L'un d'entre vous a-t-il déjà essayé de faire passer une requête overpass en
utilisant un script python ?

J'ai essayé un truc du genre :
import os, sys
import urllib2

http =
'http://overpass-api.de/api/interpreter?data=[out:json][timeout:25];(node["highway"](43.98,4.70,44.27,4.99);way["highway"](43.98,4.70,44.27,4.99);relation["highway"](43.98,4.70,44.27,4.99););out
body;>;out skel qt;'

open(r"C:\Scripts\osm\highway.osm",'w').write(urllib2.urlopen(str(http)).read())

Mais, bien sûr, ça ne fonctionne pas. Pourtant, ce bout de script fonctionne
plutôt bien avec les requête XAPI.

Merci de vos réponses



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Requete-overpass-api-python-tp5863030.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Requête overpass api & python

[Nicolas Moyroud]

Salut Tony,

As-tu essayé ce module Python qui est fait tout exprès pour ça ?
http://osmapi.divshot.io/
Je te dis ça, mais je ne l'ai jamais testé. :-)

Nicolas


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

Re: [OSM-talk-fr] Requête overpass api & python

[Nicolas Moyroud]

Salut Étienne,


J'ai plusieurs script python qui utilise l'api overpass, QuickOSM par 
exemple.
J'ai adapté ton code rapidement : 
https://gist.github.com/Gustry/378058e2984faeddac47



Ah ben oui QuickOSM ça utilise l'overpassAPI, forcément ! :-D

Nicolas

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

Re: [OSM-talk-fr] Requête overpass api & python

[Etienne Trimaille]

Salut Tony,

J'ai plusieurs script python qui utilise l'api overpass, QuickOSM par
exemple.
J'ai adapté ton code rapidement :
https://gist.github.com/Gustry/378058e2984faeddac47


Le 22 décembre 2015 à 12:03, Tony Emery  a écrit :

> Bonjour à tous,
>
> J'ai créé un script python qui me permet, entre autre, de télécharger les
> données OSM en local sur mon poste. Je lance ce script en tâche planifiée 2
> fois par jour.
>
> Je pense que http://api.openstreetmap.fr/xapi? ne répond plus car les
> requêtes que je lance sur ce site me renvoie des tables vides depuis 4
> jours.
>
> Du coup, j'essaye de m'adapter en tapant directement dans l'API overpass.
>
> L'un d'entre vous a-t-il déjà essayé de faire passer une requête overpass
> en
> utilisant un script python ?
>
> J'ai essayé un truc du genre :
> import os, sys
> import urllib2
>
> http =
> 'http://overpass-api.de/api/interpreter?data=[out:json][timeout:25];(node[
> "highway"](43.98,4.70,44.27,4.99);way["highway"](43.98,4.70,44.27,4.99);relation["highway"](43.98,4.70,44.27,4.99););out
> body;>;out skel qt;'
>
>
> open(r"C:\Scripts\osm\highway.osm",'w').write(urllib2.urlopen(str(http)).read())
>
> Mais, bien sûr, ça ne fonctionne pas. Pourtant, ce bout de script
> fonctionne
> plutôt bien avec les requête XAPI.
>
> Merci de vos réponses
>
>
>
> -
> Tony EMERY
> Administrateur OpenStreetMap.fr
> Mandataire Grand Sud-Est
> Géomaticien & chef de projets
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Requete-overpass-api-python-tp5863030.html
> Sent from the France mailing list archive at Nabble.com.
>
> ___
> 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] Requête overpass api & python

[Tony Emery]

Etienne Trimaille wrote
> J'ai plusieurs script python qui utilise l'api overpass, QuickOSM par
> exemple.
> J'ai adapté ton code rapidement :
> https://gist.github.com/Gustry/378058e2984faeddac47

A priori, ton script fonctionne plutôt bien mais il doit y avoir un problème
à l'encodage car le fichier généré est du type :

{
  "version": 0.6,
  "generator": "Overpass API",
  "osm3s": {
"timestamp_osm_base": "2015-12-23T07:23:02Z",
"copyright": "The data included in this document is from
www.openstreetmap.org. The data is made available under ODbL."
  },
  "elements": [

{
  "type": "node",
  "id": 25178536,
  "lat": 44.0034820,
  "lon": 4.7046202,
  "tags": {
"addr:postcode": "30120",
"address": "A 9 - direction Orange/Nîmes, Aire de Tavel Nord",
"amenity": "fuel",
"fuel:diesel": "yes",
"fuel:e10": "yes",
"fuel:lpg": "yes",
"fuel:octane_98": "yes",
"is_in": "A-9",
"name": "Station Esso",
"opening_hours": "24/7",
"operator": "Esso",
"source": "stations.gpl.online.fr;source = Ministère de l'Economie, de
l'Industrie et du Numérique - 15/09/2014"
  }
},

Alors que moi j'ai besoin plutôt de :



The data included in this document is from www.openstreetmap.org. The
data is made available under ODbL.


  












  



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Requete-overpass-api-python-tp5863030p5863079.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Requête overpass api & python

[Etienne Trimaille]

Ton problème, c'est le format de sortie de ta requête overpass. Change
"json" en "xml" ;-)

Pour la requête sur plusieurs lignes, bien sur tu peux changer. C'était
juste pour plus de lisibilité.

Le 23 décembre 2015 à 08:42, Tony Emery  a écrit :

> Etienne Trimaille wrote
> > J'ai plusieurs script python qui utilise l'api overpass, QuickOSM par
> > exemple.
> > J'ai adapté ton code rapidement :
> > https://gist.github.com/Gustry/378058e2984faeddac47
>
> A priori, ton script fonctionne plutôt bien mais il doit y avoir un
> problème
> à l'encodage car le fichier généré est du type :
>
> {
>   "version": 0.6,
>   "generator": "Overpass API",
>   "osm3s": {
> "timestamp_osm_base": "2015-12-23T07:23:02Z",
> "copyright": "The data included in this document is from
> www.openstreetmap.org. The data is made available under ODbL."
>   },
>   "elements": [
>
> {
>   "type": "node",
>   "id": 25178536,
>   "lat": 44.0034820,
>   "lon": 4.7046202,
>   "tags": {
> "addr:postcode": "30120",
> "address": "A 9 - direction Orange/Nîmes, Aire de Tavel Nord",
> "amenity": "fuel",
> "fuel:diesel": "yes",
> "fuel:e10": "yes",
> "fuel:lpg": "yes",
> "fuel:octane_98": "yes",
> "is_in": "A-9",
> "name": "Station Esso",
> "opening_hours": "24/7",
> "operator": "Esso",
> "source": "stations.gpl.online.fr;source = Ministère de l'Economie, de
> l'Industrie et du Numérique - 15/09/2014"
>   }
> },
>
> Alors que moi j'ai besoin plutôt de :
>
> 
> 
> The data included in this document is from www.openstreetmap.org.
> The
> data is made available under ODbL.
> 
>
>timestamp="2014-10-14T10:45:02Z" changeset="26069043" uid="675449"
> user="jseigneuret">
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>   
>
>
>
> -
> Tony EMERY
> Administrateur OpenStreetMap.fr
> Mandataire Grand Sud-Est
> Géomaticien & chef de projets
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Requete-overpass-api-python-tp5863030p5863079.html
> Sent from the France mailing list archive at Nabble.com.
>
> ___
> 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] Requête Overpass API sur France entière

[Pierre-Alain Dorange]

François Lacombe
francois.laco...@telecom-bretagne.eu
wrote:

 
 Peut-être que je devrais modifier ma syntaxe : en supprimant la bounding
 box, la requête met 16 secondes à s'exécuter.
 Comme operator=RTE est uniquement français, ça ira. Néanmoins ça n'est pas
 très sûr puisque le jour où on le trouve ailleurs qu'en France ma stratégie
 tombe à l'eau.
 
 Une idée là-dessus ?

Perso j'utilise des scripts python et j'ai fait un petit filtres après
import pour ne conserver que ce qui se trouve a l'intérieur d'un
polygone que je passe en paramètre (je fait le filtrage près import, en
post-traitement).

-- 
Pierre-Alain Dorange
OSM experiences : http://www.leretourdelautruche.com/map/


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

Re: [OSM-talk-fr] Requête Overpass API sur France entière

[Roland Olbricht]

Am Mittwoch, 2. Oktober 2013, 23:36:49 schrieb Christian Quest:
 Si on indique une bbox, overpass passera en revue tout les objets dans
 cette bbox sans pouvoir tirer partie de ses index.
 Si on utilise seulement un tag, overpass utilise l'index sur ce tag pour
 trouver les objets correspondants qui si ils sont peu nombreux donneront le
 résultat très rapidement.

Je voudrais adjouter quelque détails:

Au prémier, on peut forcer overpass d'utiliser ses indexes dans l'ordre qui 
convient. Regardons encore un fois le requête: 

 way
   [power=sub_station]
   [operator=RTE]
   (41.333740, -5.140600, 51.089062, 9.559320);
 (._;;);
 out body;

Si on écrit

way
  [power=sub_station]
  [operator=RTE];
way
  ._
  (41.333740, -5.140600, 51.089062, 9.559320);
(._;;);
out body;

on enforce overpass d'amasser au premier tous les ways avec les deux tags, 
puis les filtrer pour le bbox. Les deux requêtes ont le méme résultat, mais la 
deuxieme est plus vite.

Plus compliqué, c'est plus vite à overpass-api.de depuis une heure, parce-que 
je viens de corriger un bogue qui à ralentisse tous les requêtes avec grand 
bbox, mais n'a pas changé les résultat (et pour ça a été jamais trouvé par des 
testes).

 overpass n'a pas la puissance (relative) du query planner de postgres qui
 va tenter d'exploiter le meilleur index et la meilleure méthode en fonction
 de la requête et des données (via des statistiques).

Un query planner ne serais pas un grande aide ici, parce-que il n'y a pas 
beaucoup des indexes pour choisir dans overpass. Au contraire, il faut 
seulement connâitre en avance combien des objets sont dans un bbox 
particulière. Si on connâit ça, on peut compter si suivre des objets 
individuel ou lire tous les objets au bbox et plus vite.

Il voire existe le code pour compter des résultat. Mais je prefère faire des 
testes nombreux avant d'integrer ce code, parce-que avoir toujours les 
résultats corrects est plus important que faire les requêtes plus vite. Ce 
code n'est pas encore bien testé.

On va gangner en plus si on utilise les deux indexes géographiques (de bbox et 
des le objets trouvés) en parallel. C'est une chance pour gagner vitesse dans 
des versions subséquentes. Au moment, j'implemente à overpass de stocker aussi 
l'histoire d'OSM. Ca va simplifier de retrouver des objects supprimer et 
également de suivre des changes au base des donées. Mais parce-que c'est un 
grand étape, j'ai repousse tous les autres changes.

En totale, dans quelque mois les deux requêtes seront également vite, mais au 
moment on devrait preferer le deuxième.

Roland


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

Re: [OSM-talk-fr] Requête Overpass API sur France entière

[Nicolas Dumoulin]

Le mercredi 2 octobre 2013 23:36:49 Christian Quest a écrit :
 Un tel fonctionnement permettrait à celui qui écrit la requête de
 l'optimiser en ayant une vague idée de ce qui est le plus discriminant.

+1

À un moment, j'ai pensé que Overpass fonctionnait déjà ainsi. Ce serait 
effectivement très pratique (à condition de bien lire la doc).

-- 
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] Requête Overpass API sur France entière

[Ista Pouss]

Le 2 octobre 2013 23:36, Christian Quest cqu...@openstreetmap.fr a écrit :

 Si on indique une bbox, overpass passera en revue tout les objets dans
 cette bbox sans pouvoir tirer partie de ses index.


Pourquoi ?

Quel est le problème de filtrer le résultat tirant parti d'un index par la
bounding box ? Cela dure si longtemps ?

Actuellement, on passe de résultat immédiat sans bbox à interminable avec
bbox... une telle différence est incompréhensible, à moins d'imaginer que
overpass ignore complètement l'index même s'il existe dès qu'il y a une
bbox, sauf que je ne vois pas la raison de procéder ainsi ?



 Si on utilise seulement un tag, overpass utilise l'index sur ce tag pour
 trouver les objets correspondants qui si ils sont peu nombreux donneront le
 résultat très rapidement.

 overpass n'a pas la puissance (relative) du query planner de postgres qui
 va tenter d'exploiter le meilleur index et la meilleure méthode en fonction
 de la requête et des données (via des statistiques).


Sans parler du meilleur, au moins de comprendre le fonctionnement actuel.




 Un tel fonctionnement permettrait à celui qui écrit la requête de
 l'optimiser en ayant une vague idée de ce qui est le plus discriminant.



J'espère que overpass ne va pas se mettre à fonctionner sur des requêtes de
vagues idées ou des optimisations de hacker fou ! Si les index sont
importants (j'imagine que oui évidemment), alors il est préférable de les
expliciter dans les requêtes et/ou le protocole de traitement.

Cordialement.

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

Re: [OSM-talk-fr] Requête Overpass API sur France entière

[François Lacombe]

Très bien, je prends note de toutes ces précisions.

Ainsi spécifier un timeout supérieur à la limite par défaut n'est pas
pénalisant, mais il est préférable d'effectuer une requête sans bounding
box.

Je pense qu'il est mieux d'utiliser un serveur qui ne contient que les data
France plutôt que de partir du principe qu'un tag donné n'est utilisé qu'à
un endroit précis.


Bonne soirée.

*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com


Le 2 octobre 2013 06:10, Roland Olbricht roland.olbri...@gmx.de a écrit :

  Néanmoins est-ce pertinent de charger le service avec ce genre de requête
  plutôt que de passer par un export / autre technique ?

 Je pense oui. Je ne connais pas la taille de la réponse, mais j'estime que
 elle est moins que 100 Mo.

  Mes requête pourraient être nombreuses, et exécutées régulièrement.
  Je ne voudrais pas pénaliser le reste des utilisateurs, ce qui me semble
  pourtant être le cas en augmentant la durée de timeout de la sorte.

 Par contraire, jusq'à 10 Go par jour par adresse IP sont bon. A propos
 augmenter la durée de par timeout: quand le serveur est très chargé, il
 renvoye des grandes requêtes mais encore accepte des petites requêtes.
 C-est à
 dire, si le serveur accepte une grande requête, il n'est pas trop chargé.

  Peut-être que je devrais modifier ma syntaxe : en supprimant la bounding
  box, la requête met 16 secondes à s’exécuter.

 C'est bien possible. Si un bounding box est dans la requête, le serveur
 toujours internement filtre premièrement au bounding box, puis à les tags.
 C'est bon pour les bounding box petits, mais c'est une faiblesse à improver
 pour les bounding box très grandes.

 Si tous les objects sont connu être en France, il est au moment vraiment
 mieux
 des chercher sans bounding box.

 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] Requête Overpass API sur France entière

[Stéphane Péneau]

Je viens de faire une requête très simple (elle trouve 18 POI) sur la 
france entière .


Avec bbox : au bout de 15 minutes ce n'était pas terminé
Sans bbox : résultat quasi instantané.


Stf

Le mercredi 2 octobre 2013 20:53:54, François Lacombe a écrit :

Très bien, je prends note de toutes ces précisions.

Ainsi spécifier un timeout supérieur à la limite par défaut n'est pas
pénalisant, mais il est préférable d'effectuer une requête sans
bounding box.

Je pense qu'il est mieux d'utiliser un serveur qui ne contient que les
data France plutôt que de partir du principe qu'un tag donné n'est
utilisé qu'à un endroit précis.


Bonne soirée.

*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com


Le 2 octobre 2013 06:10, Roland Olbricht roland.olbri...@gmx.de
mailto:roland.olbri...@gmx.de a écrit :

 Néanmoins est-ce pertinent de charger le service avec ce genre
de requête
 plutôt que de passer par un export / autre technique ?

Je pense oui. Je ne connais pas la taille de la réponse, mais
j'estime que
elle est moins que 100 Mo.

 Mes requête pourraient être nombreuses, et exécutées régulièrement.
 Je ne voudrais pas pénaliser le reste des utilisateurs, ce qui
me semble
 pourtant être le cas en augmentant la durée de timeout de la sorte.

Par contraire, jusq'à 10 Go par jour par adresse IP sont bon. A propos
augmenter la durée de par timeout: quand le serveur est très
chargé, il
renvoye des grandes requêtes mais encore accepte des petites
requêtes. C-est à
dire, si le serveur accepte une grande requête, il n'est pas trop
chargé.

 Peut-être que je devrais modifier ma syntaxe : en supprimant la
bounding
 box, la requête met 16 secondes à s’exécuter.

C'est bien possible. Si un bounding box est dans la requête, le
serveur
toujours internement filtre premièrement au bounding box, puis à
les tags.
C'est bon pour les bounding box petits, mais c'est une faiblesse à
improver
pour les bounding box très grandes.

Si tous les objects sont connu être en France, il est au moment
vraiment mieux
des chercher sans bounding box.

Roland


___
Talk-fr mailing list
Talk-fr@openstreetmap.org mailto: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] Requête Overpass API sur France entière

[Ista Pouss]

Le 2 octobre 2013 22:39, Stéphane Péneau stephane.pen...@wanadoo.fr a
écrit :

 Je viens de faire une requête très simple (elle trouve 18 POI) sur la
 france entière .

 Avec bbox : au bout de 15 minutes ce n'était pas terminé
 Sans bbox : résultat quasi instantané.


Mais alors, comment fait-on ensuite pour savoir quels sont les points qui
correspondent à la bbox ?

(ou question subsidiaire : pourquoi faut-il tant de temps à overpass pour
faire le tri sur la bbox ??? )
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr