Re: [OSM-talk-fr] Le service sur api.openstreetmap.fr s'agrandi lui aussi
2012/3/27 sly (sylvain letuffe) li...@letuffe.org: Soyons fou, et commençons à faire que cette api fr soit plus pointue que l'officielle (je changerais si ça perturbe trop ou j'en ferais une deuxième) j'envoi maintenant 3 niveaux (c'est les soldes) Il y a un très grand danger à modifier le comportement de l'API original. Ca n'est plus du proxy; ça altère le comportement des logiciels clients suivant qu'ils utiliseront l'API original ou celui-là. Au minimum, il faudrait la renommer en autre chose que api.openstreetmap.fr (xapi pour extended est déjà pris mais l'idée est là). Tant que l'API en .fr a un comportement différent ou ne change pas de nom (outre les problèmes d'autentification), je ne pourrais pas recommander son usage à un public plus large. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le service sur api.openstreetmap.fr s'agrandi lui aussi
Le mercredi 28 mars 2012 10:33:32, Pieren a écrit : 2012/3/27 sly (sylvain letuffe) li...@letuffe.org: Soyons fou, et commençons à faire que cette api fr soit plus pointue que l'officielle (je changerais si ça perturbe trop ou j'en ferais une deuxième) j'envoi maintenant 3 niveaux (c'est les soldes) Il y a un très grand danger à modifier le comportement de l'API original. Ca n'est plus du proxy; ça altère le comportement des logiciels clients suivant qu'ils utiliseront l'API original ou celui-là. La déviance est lié au sens que l'on donne à API original Selon moi, l'api 0.6 n'a qu'une documentation valable, c'est celle-ci : http://wiki.openstreetmap.org/wiki/API_0.6 Et mon proxy s'efforce de s'y référer au plus prêt possible. Seulement l'api de osm.org ne suit pas exactement cette documentation [1] non plus, il y a donc 3 choix : - en rester à la documentation - mimiquer les déviances de l'api officielle - prendre des libertés quand l'api officielle prend des libertés [1] exemple : Retrieving map data by bounding box: GET /api/0.6/map (...) * All relations that reference one of the nodes or ways included due to the above rules. (Does not apply recursively.) Alors qu'en fait, c'est récursif mais une fois, ce qui est contraire à la documentation Au minimum, il faudrait la renommer en autre chose J'adhère à cette vision. Je vais donc rester sur l'optique qu'il faut que http://api.openstreetmap.fr/api se comporte au plus près possible de http://api.openstreetmap.org/api et je vais voir si je dois changer la documentation pour qu'elle suive ce qui est. Je reviens donc sur ma modification. Je mettrais à disposition ultérieurement une version étendue comme je l'ai fais pour http://api.openstreetmap.org/ways-api Tant que l'API en .fr a un comportement différent ou ne change pas de nom (outre les problèmes d'autentification), je ne pourrais pas recommander son usage à un public plus large. Quoi qu'il en soit du comportement actuel de l'api fr, je propose de ne pas en recommander son usage à un public trop large. Le cercle des gens bien à l'aise avec JOSM, qui comprennent ce qu'est une relation, qui save ce qu'est un conflit et qui suive cette liste de manière régulière : ok. Mais pour les autres, ça me semble un peu prématuré, surtout tant que des bugs subsistent. -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le service sur api.openstreetmap.fr s'agrandi lui aussi
Le 28/03/2012 11:42, sly (sylvain letuffe) a écrit : Le mercredi 28 mars 2012 10:33:32, Pieren a écrit : 2012/3/27 sly (sylvain letuffe)li...@letuffe.org: Soyons fou, et commençons à faire que cette api fr soit plus pointue que l'officielle (je changerais si ça perturbe trop ou j'en ferais une deuxième) j'envoi maintenant 3 niveaux (c'est les soldes) Il y a un très grand danger à modifier le comportement de l'API original. Ca n'est plus du proxy; ça altère le comportement des logiciels clients suivant qu'ils utiliseront l'API original ou celui-là. La déviance est lié au sens que l'on donne à API original API (Application Programming Interface) c'est d'abord des spécifications destinées à être utilisées... par le serveur et par le client (d'après [1]). http://gnagna/api/ c'est un serveur offrant une interface plus ou moins conforme à ces spécifications. Selon moi, l'api 0.6 n'a qu'une documentation valable, c'est celle-ci : http://wiki.openstreetmap.org/wiki/API_0.6 En fait, la question est de savoir si la doc du wiki est une spécification de l'api 0.6 ou une documentation de l'interface osm.org/api/0.6 En fait, ça doit être un peu les deux... Et mon proxy s'efforce de s'y référer au plus prêt possible. Seulement l'api de osm.org ne suit pas exactement cette documentation [1] non plus, il y a donc 3 choix : - en rester à la documentation - mimiquer les déviances de l'api officielle - prendre des libertés quand l'api officielle prend des libertés [1] exemple : Retrieving map data by bounding box: GET /api/0.6/map (...) * All relations that reference one of the nodes or ways included due to the above rules. (Does not apply recursively.) Alors qu'en fait, c'est récursif mais une fois, ce qui est contraire à la documentation Au minimum, il faudrait la renommer en autre chose +1, api.fr = frapi avant d'entri :-) Peut-être que c'est la spécification qu'il faudrait enrichir, tout en s'y tenant... La spec dit pas récursif... le résultat devrait être conforme. On ajoute du vocabulaire à la requête : .../full pour avoir de la récursivité. Quoi qu'il en soit du comportement actuel de l'api fr, je propose de ne pas en recommander son usage à un public trop large. Le cercle des gens bien à l'aise avec JOSM, qui comprennent ce qu'est une relation, qui save ce qu'est un conflit et qui suive cette liste de manière régulière : ok. Et qui sont au courant de la latence de 2 mn. [1] http://en.wikipedia.org/wiki/Application_programming_interface -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le service sur api.openstreetmap.fr s'agrandi lui aussi
En fait, la question est de savoir si la doc du wiki est une spécification de l'api 0.6 ou une documentation de l'interface osm.org/api/0.6 En fait, ça doit être un peu les deux... En fait, après creusage de tête intensif et re-lecture approfondie, j'en arrive à que cette documentation est conforme à l'implémentation (ou l'invese ;-) ), et que c'est moi qui est mal compris cette phrase ou qu'elle n'est pas idéalement claire (ou les deux) J'ai donc modifié la documentation en espérant être plus clair sur ce point. Donc plus de doute, je vais développer l'api fr pour être le plus conforme possible à la documentation, et donc à l'officielle. Ce qui devrait donc être le cas actuellement, sauf bug non trouvé et moins le cas particulier qui concerne le téléchargement d'un élément supprimé qui ne se comporte pas comme souhaité +1, api.fr = frapi avant d'entri :-) J'vi faire ça. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le service sur api.openstreetmap.fr s'agrandi lui aussi
Le 28 mars 2012 14:30, Vincent Pottier vpott...@gmail.com a écrit : Et qui sont au courant de la latence de 2 mn. Pour info, les stats sur cette latence sont là: http://munin.openstreetmap.fr/osm11.free.org/osm103.openstreetmap.fr/osm_replication_lag_api.html En moyenne c'est 1mn, parfois ça monte à 2 et très rarement au delà. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le service sur api.openstreetmap.fr s'agrandi lui aussi
On dimanche 25 mars 2012, PhQ wrote: (...) avec l'api fr Relation : RD N°1 (1850206) seulement et avec l'api officiel la relation précédente ET Relation : Routes Départementales du Puy-de-Dôme (1857038). Ca ne serait pas une bogue de l'api fr par hasard ? Je ne parviens pas à reproduire le comportement que tu cites avec l'api officielle. Dans JOSM, si je fais : télécharger objet, chemin, n° : 121831733 JOSM lance ces appels (visibles en console) : GET http://api.openstreetmap.org/api/0.6/ways?ways=121831733 Le chemin 121 831 733 avec 27 nœuds a des nœuds incomplets car au moins un nœud était manquant dans les données chargées. GET http://api.openstreetmap.org/api/0.6/nodes?nodes=1362890197,425187227,425187226,1506128829,1506128831,281161202,1362890420,281161203,281161201,281161204,281161205,1362890189,281161038,1362890441,541423318,281161028,281161029,281161030,281161031,281161108,281161109,1506128832,281161116,281161117,281161118,281161043,281161119 GET http://api.openstreetmap.org/api/0.6/way/121831733/relations Et je me retrouve au final avec mon way, ses noeuds et la relation donc il est membre (la 1850206) mais pas la mega relation qui contient tout : n°1857038 Tu peux me détailler dans JOSM les opérations que tu fais pour arriver à avoir la relation 1857038 ? -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le service sur api.openstreetmap.fr s'agrandi lui aussi
Ben justement, il n'y a rien à faire pour obtenir la mega relation avec l'api officielle. C'est bien la le problème ! -- View this message in context: http://gis.19327.n5.nabble.com/Le-service-sur-api-openstreetmap-fr-s-agrandi-lui-aussi-tp5578665p5598497.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le service sur api.openstreetmap.fr s'agrandi lui aussi
Le mardi 27 mars 2012 20:03:10, PhQ a écrit : Correction, la technique qui me permet d'obtenir la super relation de JOSM, c'est de sélectionner par la carte flottante une partie du chemin en question, et la, effectivement, la super relation apparait ! ça y est, j'ai compris ! ;-) Au début j'ai cru que tu parlais du menu télécharger un objet et là, l'api fr se comporte bien comme l'api officielle (c'est à dire ça ne télécharge les relations dont le chemin est membre que si on coche la case et JOSM lance alors un nouvel appel) Donc je confirme, le cas se présente (présentait !) quand on télécharge à l'aide d'un appel de zone (appel map) où seul un niveau de relation était téléchargé, là ou l'api officielle en récupère 2 niveaux. Soyons fou, et commençons à faire que cette api fr soit plus pointue que l'officielle (je changerais si ça perturbe trop ou j'en ferais une deuxième) j'envoi maintenant 3 niveaux (c'est les soldes) Concrètement, si on télécharge un chemin de frontière entre la france et l'italie on récupère : - le chemin (off course) - la relation frontière france-italie qui le contient - la relation france métropolitaine qui la contient Mais en plus de l'api officielle - la relation france (qui contient les dom-tom et la france métropolitaine) Je pourrais aller encore plus loin, mais j'ai peur que ça finisse par être lourd, ceux qui voudront irons dans le menu fichier pour faire télécharger des relations parentes -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le service sur api.openstreetmap.fr s'agrandi lui aussi
Précision : Cette bogue s'observe en chargeant un chemin par exemple 121831733, mais pas en chargeant directement la relation. -- View this message in context: http://gis.19327.n5.nabble.com/Le-service-sur-api-openstreetmap-fr-s-agrandi-lui-aussi-tp5578665p5594429.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le service sur api.openstreetmap.fr s'agrandi lui aussi
Bonjour, c'est encore moi Quand je ne tague pas pour le rendu ( :) ), je tague pour la base de donnée. En tant que vieil utilisateur des bases multivaluées (Pick System), je ne peux m’empêcher de faire dans la relation arborescente. Donc, et par exemple, si je charge la relation représentant la D1 du Puy de Dôme à partir d'un morceau de la route, j'obtiens avec l'api fr Relation : RD N°1 (1850206) seulement et avec l'api officiel la relation précédente ET Relation : Routes Départementales du Puy-de-Dôme (1857038). Ca ne serait pas une bogue de l'api fr par hasard ? Cordialement -- View this message in context: http://gis.19327.n5.nabble.com/Le-service-sur-api-openstreetmap-fr-s-agrandi-lui-aussi-tp5578665p5593140.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le service sur api.openstreetmap.fr s'agrandi lui aussi
Bonjour. Pour discussion: j'utilise la fonction mise à jour des données de josm pour limiter les conflits d'édition concurrente, comme avec svn on fait un update avant un commit. Est-ce inutile ? 2012/3/22, sly (sylvain letuffe) li...@letuffe.org: Le jeudi 22 mars 2012 00:15:23, Vincent de Chateau-Thierry a écrit : Documenter la limitation, ça sera déjà pas mal. Et hop : http://wiki.openstreetmap.org/wiki/FR:Servers/api.openstreetmap.fr -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Envoyé avec mon mobile Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le service sur api.openstreetmap.fr s'agrandi lui aussi
On jeudi 22 mars 2012, Cyrille Giquello wrote: Bonjour. Pour discussion: j'utilise la fonction mise à jour des données de josm pour limiter les conflits d'édition concurrente, comme avec svn on fait un update avant un commit. Est-ce inutile ? Je n'ai jamais utilisé cette fonction, j'opte pour release quick, release often qui me permet d'avoir des changesets pas trop gros, correspondants à un lot de modification liées et m'évite de garder des données plusieurs heures ou jour qui finiraient par créer des conflits. Pour moi, une session mapping ressemble à ; - je télécharge - je modifie/ajoute pendant ~10 minutes max - j'upload - je re-télécharge dans le même calque que je ne supprime pas - etc. Mon dernier conflit remonte à 2009. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le service sur api.openstreetmap.fr s'agrandi lui aussi
Dans le cas d'un chargement de relation type frontière, j'obtiens par exemple ceci en pistage console : GET http://api.openstreetmap.fr/api/0.6/relation/1450201/full LÆÚlÚment 'note' trouvÚ dans le flux dÆentrÚe nÆest pas dÚfini. Abandon. LÆÚlÚment 'meta' trouvÚ dans le flux dÆentrÚe nÆest pas dÚfini. Abandon. ce qui n’empêche pas l'édition, mais bon ... Qu'est ce que c'est ? -- View this message in context: http://gis.19327.n5.nabble.com/Le-service-sur-api-openstreetmap-fr-s-agrandi-lui-aussi-tp5578665p5587012.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le service sur api.openstreetmap.fr s'agrandi lui aussi
On jeudi 22 mars 2012, PhQ wrote: LÆÚlÚment 'note' trouvÚ dans le flux dÆentrÚe nÆest pas dÚfini. Abandon. LÆÚlÚment 'meta' trouvÚ dans le flux dÆentrÚe nÆest pas dÚfini. Abandon. ce qui n’empêche pas l'édition, mais bon ... Qu'est ce que c'est ? Il n'y a pas à s'inquiéter, il s'agit de deux informations supplémentaires contenu dans le fichier envoyé par l'api-fr qui indique par une note que les données sont sous copyright et par un tag meta l'age de la base JOSM n'étant pas habitué à les reçevoir il met un message pour indiquer qu'il les a ignoré -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le service sur api.openstreetmap.fr s'agrandi lui aussi
Bonjour, De : sly (sylvain letuffe) Tant qu'a faire, autant qu'elle soit la mieux possible ;-) Les rapports de bugs sont donc les bienvenus Un comportement que je constate avec l'api (avant comme après l'extension monde) : Dans JOSM, charger un morceau de relation, puis, dans le panneau des relations, par clic-droit, demander Télécharger les membres incomplets. Apparaît alors une pop-up avec barre de défilement, intitulée Analyse des données, qui n'en finit pas, enfin, pas toujours. Un test à l'instant : j'ai laissé tourner cette analyse sur Saint-Malo : http://api.openstreetmap.fr/browse/relation/905534 et le téléchargement s'arrête avant d'avoir terminé. Dans la console, j'ai : L'élément 'html' trouvé dans le flux d'entrée n'est pas défini. Abandon. La requête : GET http://api.openstreetmap.fr/api/0.6/nodes?nodes=1123188078,1123188079,... Je viens de faire la manip 2x et je reproduis le problème. Frustrant quand on connaît la rapidité de l'api ! merci vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le service sur api.openstreetmap.fr s'agrandi lui aussi
Un comportement que je constate avec l'api (avant comme après l'extension monde) : Dans JOSM, charger un morceau de relation, puis, dans le panneau des relations, par clic-droit, demander Télécharger les membres incomplets. Sans rapport avec le bug que tu as trouvé, je conseille le menu du dessous télécharger les membres. Bien qu'on puisse penser qu'il soit préférable de ne télécharger que ceux qui manque, ça va en fait plus vite de tout demander (sauf bien sûr s'il n'en manque que 2 ou 3) Apparaît alors une pop-up avec barre de défilement, intitulée Analyse des données, qui n'en finit pas, enfin, pas toujours La requête : GET http://api.openstreetmap.fr/api/0.6/nodes?nodes=1123188078,1123188079,... ha ! je me suis fais avoir par le ... alors qu'avec la requête complète ça m'aurait tout de suite rappelé un vieux bug du tout début de l'api : Un module sécurité de php limite la taille des variables et c'est pour ça que passer la limite de 1000 caractères ça coince. Voilà donc à quoi ressemblait une requête qui foire et qui maintenant est réparée : GET http://api.openstreetmap.fr/api/0.6/nodes?nodes=341948736,341949710,341948739,33210080,341948741,341949706,341948744,341948746,341948749, 341947802,341948751,341948753,341949726,341949720,341948756,341949723,341948758,341948761,341949716,341948763,341949713,341948765, 341948767,341949742,341948770,341949253,341949249,341949739,341948772,341948779,341949735,341948776,341949733,341949256,341948781, 341949259,341949729,341948786,341949758,341948784,341948791,341949755,341948789,341949752,341948794,341949749,341948799,341949745, 341948796,341949769,341949219,341949773,341949223,341949775,341949761,341949225,341949231,341949228,341949767,341949784,341948692, 341948695,341949788,341948688,341949790,341948690,341948701,341949242,341949779,341948697,26696125,341949246,341948699,341949782, 341949802,341948710,341948707,341949189,341948704,341949191,341948719,341949194,341948717,341949799,341948715,341949197,341949796, 341948712,341949819,341948727,341949200,341949203,341949816,341948724,341949822,341948722,341949207,341949209,341948734,341949810, 341949213,341948731,341949215,341948729,341948877,341948869,341948895,341948886,341948907,341948904,341948910,341948909,341948897, 341948902,341948900,341948923,341948920,341948927,341948925,341948915,341948913,341948918,341946070,341948814,341948809,341946067, 341948811,341946065,341948804,341946077,341948806,341948801,341946075,341946072,341948829,341948824,341948826,341946062,341948821, 341946060,341948816,341948819,341948847,341946100,341948845,341946103,341948844,341946097,341948841,341948839,341948836,341948834, 341947766,341948832,341946106,341946085,341948860,341946087,341946080,341946083,341948855,341948852,341948850,341946090,341949470, 341949047,341949040,341949466,341949042,341949462,341949054,341949460,341949051,341949031,341949025,341949027,341949037,341949033, 341949015,341949501,341949503,341949012,341949010,341949498,341949492,341949021,341949019,341949485,618791735,341948997,341948994, 341949006,341949478,341949004,341949473,341949000,341946189,341948976,341946191,341948979 bug suivant ? -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le service sur api.openstreetmap.fr s'agrandi lui aussi
2012/3/20 sly (sylvain letuffe) li...@letuffe.org: Profitant du nouveau serveur OSM-fr, la couverture s'étend au monde entier, il est donc maintenant possible de s'en servir pour éditer partout sur terre, idem pour la xapi et l'overpassAPI qui vont avec. Que se passe-t-il lorsque l'API original est hors service comme cela arrive en période de maintenance ? Est-il prévu un arrêt automatique pour éviter l'accumulation de contributions hors délais raisonnables ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le service sur api.openstreetmap.fr s'agrandi lui aussi
De : sly (sylvain letuffe) Un comportement que je constate avec l'api (avant comme après l'extension monde) : Dans JOSM, charger un morceau de relation, puis, dans le panneau des relations, par clic-droit, demander Télécharger les membres incomplets. Sans rapport avec le bug que tu as trouvé, je conseille le menu du dessous télécharger les membres. Bien qu'on puisse penser qu'il soit préférable de ne télécharger que ceux qui manque, ça va en fait plus vite de tout demander (sauf bien sûr s'il n'en manque que 2 ou 3) Ok. Apparaît alors une pop-up avec barre de défilement, intitulée Analyse des données, qui n'en finit pas, enfin, pas toujours La requête : GET http://api.openstreetmap.fr/api/0.6/nodes?nodes=1123188078,1123188079,... ha ! je me suis fais avoir par le ... alors qu'avec la requête complète ça m'aurait tout de suite rappelé un vieux bug du tout début de l'api : Un module sécurité de php limite la taille des variables et c'est pour ça que passer la limite de 1000 caractères ça coince. Voilà donc à quoi ressemblait une requête qui foire et qui maintenant est réparée : (...) Impec. bug suivant ? Pas trouvé :-) Merci ! vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le service sur api.openstreetmap.fr s'agrandi lui aussi
On mercredi 21 mars 2012, Etienne Trimaille wrote: Bug suivant, le voici :) Il pleut il pleut des bugs Par exemple, ce way : http://www.openstreetmap.org/browse/way/156165673 C'est grave Docteur ? ça veut dire qu'il faudrait que j'évite de faire des trucs dangereux à 2h du matin sur la base en place. En voulant rajouter des fonctionnalités j'ai visiblement lancé un truc foireux qui a bloqué les mises à jour, la base est donc restée bloquée depuis 2h00 ce matin et je n'avais rien vu. Voilà qui est réparé, je vais me préparer un coin pour des tests de ce type. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le service sur api.openstreetmap.fr s'agrandi lui aussi
Le 21 mars 2012 14:50, sly (sylvain letuffe) li...@letuffe.org a écrit : On mercredi 21 mars 2012, Etienne Trimaille wrote: Bug suivant, le voici :) Il pleut il pleut des bugs Par exemple, ce way : http://www.openstreetmap.org/browse/way/156165673 C'est grave Docteur ? ça veut dire qu'il faudrait que j'évite de faire des trucs dangereux à 2h du matin sur la base en place. En voulant rajouter des fonctionnalités j'ai visiblement lancé un truc foireux qui a bloqué les mises à jour, la base est donc restée bloquée depuis 2h00 ce matin et je n'avais rien vu. Les données sont à nouveau synchrones depuis quelques minutes. Voilà qui est réparé, je vais me préparer un coin pour des tests de ce type. Sur le todo... repasser automatiquement en proxy en lecture si on a un décalage de plus de X minutes sur les diff... sauf si l'API UK est injoignable ;) C'est un filet de sécurité qui serait bien utile. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le service sur api.openstreetmap.fr s'agrandi lui aussi
Le 21/03/2012 15:01, Christian Quest a écrit : Le 21 mars 2012 14:50, sly (sylvain letuffe)li...@letuffe.org a écrit : Il pleut il pleut des bugs Sly, sors tes bottes et ton ciré :-) Dans JOSM, le rafraîchissement de la sélection (Ctrl+Maj+U) ne supprime pas les objets supprimés de la base. Pour reproduire : - télécharger un même objet dans 2 calques - dans l'un, supprimer l'objet et uploader - puis dans l'autre, sélectionner l'objet puis Ctrl+Maj+U = si le serveur est l'api .org, l'objet disparaît du calque, en conformité avec l'état de la base = si le serveur est l'api .fr, l'objet reste dans son état d'avant suppression Pas gravissime, mais ça peut être trompeur. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le service sur api.openstreetmap.fr s'agrandi lui aussi
Dans JOSM, le rafraîchissement de la sélection (Ctrl+Maj+U) ne supprime pas les objets supprimés de la base. ctrl+alt+u j'imagine Pour reproduire : vu et confirmé Pas gravissime, mais ça peut être trompeur. Celui là, il va être costaud. En simplifié : Pour que JOSM fasse disparaître le way (pareil pour noeud et relation) lors de cette séquence, l'api lui envoi en fait une information qui dit ce way de numéro X, de version Y, de dernière date t, a été supprimé par le contributeur c C'est en quelque sorte une trace historique de ce way, et cette information, la base que j'utilise ne l'a pas car elle est prévue pour ne garder que ce qui est. La version de l'api fr, sur cette demande se contente d'envoyer du rien et JOSM n'en déduit pas qu'il a été supprimé donc le garde à l'écran, et une tentative de l'envoyer va provoquer une erreur de version. Il n'y a donc pas de risque pour l'intégrité de la base OSM, mais c'est, comme tu dis, trompeur et le contributeur qui aurait regroupé plusieurs modifications risque de les perdre s'il ne sait pas qu'il doit changer d'adresse d'api (ou annuler sa suppression) Je pourrais faire en sorte que ces appels soient transmis à l'api officielle et tout irait bien, sauf que ça perdrait de l'intérêt car tout se remettrait à être lent pour ces appels dans le but de gérer un nombre de cas sans doute non majoritaires. Je crois que je vais maintenir le statu quo jusqu'a ce que je trouve la bidouille qui contourne le problème ou que j'explique le problème sur la documentation (qui n'existe pas encore) -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le service sur api.openstreetmap.fr s'agrandi lui aussi
Le 21/03/2012 23:56, sly (sylvain letuffe) a écrit : Dans JOSM, le rafraîchissement de la sélection (Ctrl+Maj+U) ne supprime pas les objets supprimés de la base. ctrl+alt+u j'imagine Oops oui, en effet. Celui là, il va être costaud. (...) Je crois que je vais maintenir le statu quo jusqu'a ce que je trouve la bidouille qui contourne le problème ou que j'explique le problème sur la documentation (qui n'existe pas encore) Compris. Gérer ce point comme sur l'api principale nécessiterait encore d'autres moyens. Documenter la limitation, ça sera déjà pas mal. Cette api a déjà bien des intérêts :-) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le service sur api.openstreetmap.fr s'agrandi lui aussi
Le jeudi 22 mars 2012 00:15:23, Vincent de Chateau-Thierry a écrit : Documenter la limitation, ça sera déjà pas mal. Et hop : http://wiki.openstreetmap.org/wiki/FR:Servers/api.openstreetmap.fr -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le service sur api.openstreetmap.fr s'agrandi lui aussi
Le mardi 20 mars 2012 09:47:45, Christian Quest a écrit : As-tu mis une limite plus restreinte qu'avant ? J'ai des erreurs de chargement sur des zones un peu larges que je n'avais pas avant. C'est tout configuré comme avant (sauf la couverture) et après plusieurs essais je n'ai rien remarqué d'anormal. Tu peux me donner un exemple de requête/URL qui pose problème ? -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le service sur api.openstreetmap.fr s'agrandi lui aussi
Ca m'est arrivé en chargeant la bbox de Caen sous JOSM... oui, c'est un peu lourd... Tu as mis quoi comme limite au fait ? Le 20 mars 2012 10:25, sly (sylvain letuffe) li...@letuffe.org a écrit : Le mardi 20 mars 2012 09:47:45, Christian Quest a écrit : As-tu mis une limite plus restreinte qu'avant ? J'ai des erreurs de chargement sur des zones un peu larges que je n'avais pas avant. C'est tout configuré comme avant (sauf la couverture) et après plusieurs essais je n'ai rien remarqué d'anormal. Tu peux me donner un exemple de requête/URL qui pose problème ? -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le service sur api.openstreetmap.fr s'agrandi lui aussi
Génial ! J'ai testé avec Merkaartor en téléchargant des zones de plusieurs milliers de km de coté ! C'est sûr dans l'océan y a pas de trop de risque ;-) On y trouve des choses étranges dans l'Océan, par exemple ce node crée par un membre de cette liste (je ne dénonce personne) : http://www.openstreetmap.org/browse/node/1482063079 Par contre il y a quelques requetes de l'API qui passe pas : GET /api/0.6/[node|way|relation]/#id/relations Une erreur 404 The requested URL /api/0.6/node/1482063079/relations was not found on this server. C'est pas un drame non plus, c'est déjà super pratique de pouvoir switcher son API... Francisco Selon sly (sylvain letuffe) li...@letuffe.org: Pour rappel sur ce que c'est : http://lists.openstreetmap.org/pipermail/talk-fr/2012-February/040108.html Profitant du nouveau serveur OSM-fr, la couverture s'étend au monde entier, il est donc maintenant possible de s'en servir pour éditer partout sur terre, idem pour la xapi et l'overpassAPI qui vont avec. Intéressant donc pour les DOM/TOM qui n'étaient pas accessibles avant L'adresse n'a pas jamais, mais la vitesse oui ! -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le service sur api.openstreetmap.fr s'agrandi lui aussi
Il y a une chose à laquelle il faut faire attention avec api.openstreetmap.fr Les données qu'on uploade ne sont pas disponibles immédiatement après en download, mais environ 1 à 2 minute plus tard, le temps d'intégrer le diff suivant provenant du planet. J'ai suggéré à sly d'intercepter les uploads et de les intégrer dans la copie locale dès leur acceptation sans erreur par api.openstreetmap.org Ceci éliminerai ce délais au moins sur les upload qu'on fait soit même. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le service sur api.openstreetmap.fr s'agrandi lui aussi
Par contre il y a quelques requetes de l'API qui passe pas : GET /api/0.6/[node|way|relation]/#id/relations Une erreur 404 The requested URL /api/0.6/node/1482063079/relations was not found on this server. C'est assez étrange je viens de tester cette requête et elle ne répond pas un 404. Tu peux donner plus de détails sur comment tu l'as réalisée ? De plus, ce n'est pas un bon exemple pour tester le paramètre /relations car ce point n'est membre d'aucune relation. J'ai donc testé avec celui là : http://api.openstreetmap.fr/api/0.6/node/1522668290/relations Et, ho ! bug découvert ! Les relations auquel le point appartient ne sont pas retournées. Sitôt repéré, sitôt éradiqué, les relations dont le point est membre sont désormais bien retournées quand on demande /relations C'est pas un drame non plus, c'est déjà super pratique de pouvoir switcher son API... Tant qu'a faire, autant qu'elle soit la mieux possible ;-) Les rapports de bugs sont donc les bienvenus -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
