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

[osm.sanspourriel at spamgourmet.com]

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 
<http://wiki.openstreetmap.org/wiki/Overpass_API/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.emery at 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20160623/16b7c76b/attachment.htm>