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