Re: [OSM-talk-fr] Fwd: [OpenStreetMap] Imports
Le sujet de l'*intégration* du cadastre revient sur le tapis :-) Personnellement je suis en phase de mis a jour du bati du cadastre et je me demande de plus en plus en plus si l'on ne devrais pas faire évoluer notre méthode d'intégration du format commune au format planche cadastral. En intégrant une planche à la fois cela permet de sourcer précisément la date de mis a jour du cadastre sur les batiment (Il faudra juste choisir entre la date de mis à jour en CDIF ou la date de mis à jour sur www.cadastre.gouv.fr, personnellement j'opterais plus pour la 1er). De plus les uploads seraient moins volumineux et donc passeraient en dessous des radars du DWG :-) L'utilisation du sript bati-fusion de jecor pour générer les fichiers à importer peut permettre aux débutant de bien se rendre compte qu'il y a de la férification à faire sur ces fichiers. En plus sa méthode basé sur les rectangles englobants permet lors d'une deuxième passe du script de repérer de nombreux batiments découpé celon les limites de parcelles (tout du moins les nombreuses paires de triangles formant un unique bâtiment triangulaire). Simon Le 25/11/2013 22:15, Pieren a écrit : 2013/11/25 Sylvain Perrinel sylvain.perri...@gmail.com: Oui moi une fois sur deux, j'oublie de changer de compte :( Alors bon pour retrouver la liste de mes imports, ça va être chaud :P Tu gardes ton compte d'origine et tu changes juste ton pseudo dans les préférences le temps de ton import. Quand ça sera terminé, attend une semaine et revient à ton pseudo d'origine. De toute façon, cette histoire de compte séparé, une majorité est contre et c'est facile à contourner (malheuresement, la minorité contrôle le DWG). Pieren ___ 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] Création d'un projet réseau ferré
Le 26 novembre 2013 00:44, Copro Grammes coprogram...@yahoo.fr a écrit : Certes, nous pouvons paraître diverger, mais je tiens à préciser que je ne suis partisan d'aucun schéma particulier, ou conception d'OSM. Jusqu'à maintenant, j'ai juste essayé de comprendre au mieux ce qui avait été fait par d'autres, et ce qui est présenté sur le wiki, sans le remettre en cause. Entre autres, j'ai essayé de comprendre et d'appliquer le schéma public_transport, croyant qu'il faisait consensus. Effectivement, tu me fais prendre conscience qu'il ne décrit pas directement le terrain, mais en est une interprétation. On peut d'ailleurs dire la même chose des relations route=bus/train, non ? Je ne tiens pas à défendre l'idée que public_transport=platform désigne le lieu d'attente des voyageurs, je me suis contenté de tirer ça de la description du schéma sur le wiki ( http://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dplatform , http://wiki.openstreetmap.org/wiki/FR:Key:public_transport ), et du fait que des arrêts de bus portent cette balise (sans qu'il n'y ait physiquement de quai !). A mon avis c'est une erreur d'interprétation du wiki et/ou de traduction de celui-ci. Par lieu d'attente je pense qu'il faut comprendre non pas une salle d'attente, mais le lieu où on doit attendre juste avant de monter dans un transport en commun. Donc pour un arrêt de bus ça peut être l'abri, le poteau, mais pas sur la route (donc la différence avec le stop_position), comme pour le train où c'est le quai et non un noeud sur la voie. Pour monter dans le train, je n'attend pas au milieu du hall de la gare, ni sur la voie, mais bien sur le quai (sinon, je rate mon train ou me transforme en accident voyageur). Dans certains cas il n'y a pas de zone bien claire correspondante, et bien dans ce cas on ne le renseigne pas dans OSM plutôt que de vouloir à tout prix renseigner un truc de plus (faux en l'occurrence). Plus les gares sont complexes, plus ça devient aléatoire d'indiquer un stop_position par exemple. Du coup à Nancy il y en a une demi-douzaine. A la gare de Lyon, il faut en mettre un à chaque buttoir ? Le schéma public_transport convient assez bien aux itinéraires de bus ou tram très stables (arrêt et attente du bus/tram toujours au même endroit), mais pas trop bien au train pour ces raisons (affectation train/quai très changeante). Pour le métro c'est encore différent, il est souvent impossible de différencier les différents quais et voies, vu que tout est souterrain et difficile à positionner. Par simplification on n'a mis qu'un noeud railway=station commun pour avoir la notion de correspondances. Vouloir y appliquer le schéma public_transport dans le détail me semble souvent inadapté et dernièrement des modifs faites sur Paris ont fait disparaitre bon nombre de stations de métro par incompréhension de ce schéma alambiqué (et surtout suppression des tags classiques). Un contributeur avait aussi commencé (et pas terminé) à dédoubler les voies du métro (alors qu'on ne sait pas exactement où elles passent) pour faire la migration vers public_transport. Cette migration ici n'apportait rien d'autre que de la complexité. Maintenant que je pense avoir clairement montré que n'étais pas un partisan du schéma public_transport, que j'avais juste essayé de le comprendre et de l'utiliser, j'apporte quand même un avis personnel : Si l'on considère légitime de définir dans OSM des relations route=bus/train/..., il me paraît intéressant d'ajouter à ces relations des objets avec le rôle platform, plutôt que de se contenter des objets avec le rôle stop. Et je trouvais cohérent de leur ajouter la balise public_transport=platform. Oui, c'est intéressant de les ajouter quand ils sont stables, non ambigus, basé sur le terrain. Le seul point où je ne t'ai pas compris, c'est quand tu parles de fluctuations ? Quelles sont les différentes interprétations qu'il y aurait ? Fluctuations dans les interprétations des contributeurs de ce schéma public_transport. Plus un modèle est complexe, plus il y a des risques d'interprétations différentes et donc de fluctuations dans les données que les logiciels sont bien incapable de prendre en compte. Un modèle simple laissera moins de place à ces fluctuations et sera au final plus facile à exploiter. C'est pour ça que je ne suis pas un chaud partisan de public_transport même si je comprends son utilité. Je me méfie des schéma qu'on ne comprends pas à leur première lecture. Cordialement, Zigeuner PS En plus, j'ai oublié operator=SNCF à Nancy ; j'ai vraiment fait n'importe quoi !! PPS J'en profite, même si ce n'est pas le lieu : ce serait possible d'avoir le beau logo SNCF aussi sur les railway=halt ? (laissons pour plus tard le débat sur l'utilisation de halt/station...) J'aimerai les différencier, car une halte n'offre aucun service, il n'y a pas d'agents, c'est juste un endroit où s'arrêtent des trains et où éventuellement il y a un distributeur de
Re: [OSM-talk-fr] Fwd: [OpenStreetMap] Imports
Peut-on déterminer les limites de planches dans les données PDF servant au script d'extraction ? Si oui, ça serait très utile quand le calage est fluctuant d'une planche à l'autre. Si l'idée est de passer sous le radar, ça ne me semble pas du tout une priorité sauf pour jouer avec le DWG. Oui, c'est casse pied de changer de compte et il m'arrive souvent d'oublier de rebasculer. Il faut qu'on se penche sérieusement sur bati-fusion car les données du cadastre commencent pas endroit à ne plus être très fraiches et un usage facilité de ce dernier comme on l'a fait pour le script d'extraction permettrait de plus facilement mettre à jour le bâti. Le 26 novembre 2013 09:48, RÉAU Simon msr...@gmail.com a écrit : Le sujet de l'*intégration* du cadastre revient sur le tapis :-) Personnellement je suis en phase de mis a jour du bati du cadastre et je me demande de plus en plus en plus si l'on ne devrais pas faire évoluer notre méthode d'intégration du format commune au format planche cadastral. En intégrant une planche à la fois cela permet de sourcer précisément la date de mis a jour du cadastre sur les batiment (Il faudra juste choisir entre la date de mis à jour en CDIF ou la date de mis à jour sur www.cadastre.gouv.fr, personnellement j'opterais plus pour la 1er). De plus les uploads seraient moins volumineux et donc passeraient en dessous des radars du DWG :-) L'utilisation du sript bati-fusion de jecor pour générer les fichiers à importer peut permettre aux débutant de bien se rendre compte qu'il y a de la férification à faire sur ces fichiers. En plus sa méthode basé sur les rectangles englobants permet lors d'une deuxième passe du script de repérer de nombreux batiments découpé celon les limites de parcelles (tout du moins les nombreuses paires de triangles formant un unique bâtiment triangulaire). -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Fwd: [OpenStreetMap] Imports
2013/11/26 Christian Quest cqu...@openstreetmap.fr: Oui, c'est casse pied de changer de compte et il m'arrive souvent d'oublier de rebasculer. Pour rappel, le but d'un compte séparé est de mieux identifier et séparer les contributions habituelles d'une source externe. Parce que la plupart du temps, la source est indicative sur le commentaire du groupe de modifications (changeset) mais qu'elle est parfois absente (c'est toujours fait manuellement sauf si l'import se fait par script), on peut alors plus facilement passer par un compte séparé. Mais comme nous mettons la source sur chaque élément dans l'import cadastral, cette démarche n'a aucun intérêt. Malheureusement, le bon sens ne fait partie des règles du DWG. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Fwd: [OpenStreetMap] Imports
Le 26/11/2013 11:55, Christian Quest a écrit : Peut-on déterminer les limites de planches dans les données PDF servant au script d'extraction ? Visuellement oui, techniquement c'est hors de mes compétences (mais nos supers développeurs font toujours des miracles :-) Si oui, ça serait très utile quand le calage est fluctuant d'une planche à l'autre. Entre autre, je vois surtout un moyen de simplifier les mis a jour. Le cadastre est mis a jour planche par planche et il me semble moins laborieux de faire toutes les vérification de mis a jour sur une seul planche que sur une commune complète. En plus Il devient simple d'indiquer la date de mise a jour exacte de la planche cadastral dans le tag source. Si l'idée est de passer sous le radar, ça ne me semble pas du tout une priorité sauf pour jouer avec le DWG. Oui, c'est casse pied de changer de compte et il m'arrive souvent d'oublier de rebasculer. Personnellement je n'ai toujours pas de compte séparé et pas de mail du DWG non plus. Par contre je vois la un moyen de leur montrer que nous améliorons continuellement la qualité de nos intégration du bâti et que cela ressemble de moins en moins à un import brutal de données dans la base (et donc que le compte séparé est de moins en moins utile). Il faut qu'on se penche sérieusement sur bati-fusion car les données du cadastre commencent pas endroit à ne plus être très fraiches et un usage facilité de ce dernier comme on l'a fait pour le script d'extraction permettrait de plus facilement mettre à jour le bâti. Je suis en contact avec jecor et le script évolue. Je vois bien d'ici quelque temps les fichiers issues de bati-fusion remplacer les fichiers sur cadastre.openstreetmap.fr Pour le tester actuellement bati-fusion impose encore plus de travail de vérification que les fichier issu de cadastre.openstreetmap.fr sauf sur un import initial n'ayant aucun bâti, dans ce cas le travail est le même. Le 26 novembre 2013 09:48, RÉAU Simon msr...@gmail.com mailto:msr...@gmail.com a écrit : Le sujet de l'*intégration* du cadastre revient sur le tapis :-) Personnellement je suis en phase de mis a jour du bati du cadastre et je me demande de plus en plus en plus si l'on ne devrais pas faire évoluer notre méthode d'intégration du format commune au format planche cadastral. En intégrant une planche à la fois cela permet de sourcer précisément la date de mis a jour du cadastre sur les batiment (Il faudra juste choisir entre la date de mis à jour en CDIF ou la date de mis à jour sur www.cadastre.gouv.fr http://www.cadastre.gouv.fr, personnellement j'opterais plus pour la 1er). De plus les uploads seraient moins volumineux et donc passeraient en dessous des radars du DWG :-) L'utilisation du sript bati-fusion de jecor pour générer les fichiers à importer peut permettre aux débutant de bien se rendre compte qu'il y a de la férification à faire sur ces fichiers. En plus sa méthode basé sur les rectangles englobants permet lors d'une deuxième passe du script de repérer de nombreux batiments découpé celon les limites de parcelles (tout du moins les nombreuses paires de triangles formant un unique bâtiment triangulaire). -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ 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] Création d'un projet réseau ferré
Le 26 novembre 2013 11:46, Christian Quest cqu...@openstreetmap.fr a écrit : J'aimerai les différencier, car une halte n'offre aucun service, il n'y a pas d'agents, c'est juste un endroit où s'arrêtent des trains et où éventuellement il y a un distributeur de billet qui fonctionne. Il y a aussi un bouton pour demander l'arrêt du train suivant, qui sinon ne s'arrête pas aux haltes optionnelles (il y a le même bouton alors aussi dans la rame), mais il faut avoir appuyé à temps car le train ne peut pas freiner brutalement pour s'arrêter. Cela n'est possible que sur les voies secondaires à faible vitesse ayant assez de marges de temps disponible pour effectuer ces arrêts, ou bien si la halte se fait sur une voie parallèle, et où les haltes sont également protégées par des feux de signalisation pour les trains qui arriveraient derrière et qui doivent patienter le redémarrage du train arrêté à la halte. Exemple de tel arrêt équipé, à la halte du CHR Pontchaillou au Nord de Rennes (sinon les arrêts standards sont à la gare principale en centre ville-sud de Rennes et à Betton, la halte est située sur une voie secondaire contournant Rennes par l'ouest et le nord-ouest, sur la ligne secondaire Rennes-Saint-Malo, elle n'est empruntée que par des TER et de rares trains de frêt qui ne peuvent pas circuler aux heures de service de ces haltes TER, faute de pouvoir s'arrêter convenablement pour patienter, car il n'y a pas de voie parallèle pour passer à côté d'une rame arrétée à la halte). Depuis l'arrivée du métro rennais juste à côté (stations Anatole France ou Pontchaillou) pour rejoindre la gare centrale, il était question de supprimer cette halte pour ne pas gêner le trafic de fret et booster un peu la ligne régionale vers Saint-Malo, voire y faire rouler des quelques rames de TGV venus de Paris et pas seulement des petits TER, à certaines périodes de l'année où il y a de la demande et où le changement par TER n'a pas assez de capacité (je ne sais pas trop si cette très ancienne halte de Pontchaillou que j'a toujours connu existe encore, elle est bien dans OSM mais est-elle encore utilisable quand le métro est plus pratique et plus régulier et qu'il y a tellement rejoingnant le métro depuis Saint-Grégoire ou Betton ?). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Fwd: [OpenStreetMap] Imports
J'ai donc créé un 2ème compte. je vais essayer de pas trop me tromper de compte (mais me connaissant je suis persuadé que ça arrivera!). Merci Le 26 novembre 2013 13:15, RÉAU Simon msr...@gmail.com a écrit : Le 26/11/2013 11:55, Christian Quest a écrit : Peut-on déterminer les limites de planches dans les données PDF servant au script d'extraction ? Visuellement oui, techniquement c'est hors de mes compétences (mais nos supers développeurs font toujours des miracles :-) Si oui, ça serait très utile quand le calage est fluctuant d'une planche à l'autre. Entre autre, je vois surtout un moyen de simplifier les mis a jour. Le cadastre est mis a jour planche par planche et il me semble moins laborieux de faire toutes les vérification de mis a jour sur une seul planche que sur une commune complète. En plus Il devient simple d'indiquer la date de mise a jour exacte de la planche cadastral dans le tag source. Si l'idée est de passer sous le radar, ça ne me semble pas du tout une priorité sauf pour jouer avec le DWG. Oui, c'est casse pied de changer de compte et il m'arrive souvent d'oublier de rebasculer. Personnellement je n'ai toujours pas de compte séparé et pas de mail du DWG non plus. Par contre je vois la un moyen de leur montrer que nous améliorons continuellement la qualité de nos intégration du bâti et que cela ressemble de moins en moins à un import brutal de données dans la base (et donc que le compte séparé est de moins en moins utile). Il faut qu'on se penche sérieusement sur bati-fusion car les données du cadastre commencent pas endroit à ne plus être très fraiches et un usage facilité de ce dernier comme on l'a fait pour le script d'extraction permettrait de plus facilement mettre à jour le bâti. Je suis en contact avec jecor et le script évolue. Je vois bien d'ici quelque temps les fichiers issues de bati-fusion remplacer les fichiers sur cadastre.openstreetmap.fr Pour le tester actuellement bati-fusion impose encore plus de travail de vérification que les fichier issu de cadastre.openstreetmap.fr sauf sur un import initial n'ayant aucun bâti, dans ce cas le travail est le même. Le 26 novembre 2013 09:48, RÉAU Simon msr...@gmail.com a écrit : Le sujet de l'*intégration* du cadastre revient sur le tapis :-) Personnellement je suis en phase de mis a jour du bati du cadastre et je me demande de plus en plus en plus si l'on ne devrais pas faire évoluer notre méthode d'intégration du format commune au format planche cadastral. En intégrant une planche à la fois cela permet de sourcer précisément la date de mis a jour du cadastre sur les batiment (Il faudra juste choisir entre la date de mis à jour en CDIF ou la date de mis à jour sur www.cadastre.gouv.fr, personnellement j'opterais plus pour la 1er). De plus les uploads seraient moins volumineux et donc passeraient en dessous des radars du DWG :-) L'utilisation du sript bati-fusion de jecor pour générer les fichiers à importer peut permettre aux débutant de bien se rendre compte qu'il y a de la férification à faire sur ces fichiers. En plus sa méthode basé sur les rectangles englobants permet lors d'une deuxième passe du script de repérer de nombreux batiments découpé celon les limites de parcelles (tout du moins les nombreuses paires de triangles formant un unique bâtiment triangulaire). -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing listTalk-fr@openstreetmap.orghttps://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] OSM au journal de France2, hier soir.
Bien vu, Mais il s'agit de la Lyonnaise des Eaux qui utilise les capteurs. Il serait intéressant de leur demander une communication sur leur usage : si c'est à l'échelle nationale... Pieren wrote Les plus vigilants auront reconnu not' carte utilisée par la mairie (service des eaux?) d'Anglet. C'est en replay, ici: http://www.francetvinfo.fr/replay-jt/france-2/20-heures/jt-20-heures-lundi-4-novembre-2013_446080.html Bon allez, comme ça ne saute pas aux yeux, je vous aide. C'est dans le reportage qui commence à ~9mn La zone qu'on voit sur l'écran à 11'55'' correspond à ça: http://www.openstreetmap.org/#map=15/43.5012/-1.5254 Comme quoi, ce qu'on considérait encore comme extraordinaire il y a quelques années, passe peu à peu dans les moeurs et normal. Et c'est tant mieux. Pieren ___ Talk-fr mailing list Talk-fr@ https://lists.openstreetmap.org/listinfo/talk-fr - Cordialement, ZIMMY Jean-Louis ZIMMERMANN Développeur territorial (ville d'Orange,FR84) Mandataire OSM-France sur le Grand-Sud-est -- View this message in context: http://gis.19327.n5.nabble.com/OSM-au-journal-de-France2-hier-soir-tp5784127p5787368.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] Tracé des limites communales bourguignonnes terminé
Bonsoir, Il aura fallu une semaine et quelques heures pour terminer, à l'instant, le tracé des limites des 145 dernières communes de l'Yonne et de la Saône-et-Loire. Merci aux 8 contributeurs qui ont participé cette fois-ci. Et nous voilà donc dans la dernière ligne droite : un saut en Picardie pour compléter le tracé de 181 communes de la Somme, ce qui bouclera le département, la région, le pays :-) Comme toujours, toute contribution est la bienvenue, alors n'hésitez pas à passer par ici : http://mapcraft.nanodesu.ru/pie/333# Merci vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Compte-rendu Capitole du Libre
Bonsoir, Voici un compte-rendu des actions en lien avec l'édition 2013 de Capitole du Libre qui s'est déroulée ce week-end à Toulouse. * Samedi 23/11 = Stand OSM Animé par Cyrille Giquello, Léo Serre et moi-même. Le stand a connu une belle fréquentation même si les conférences ont drainé l'essentiel du public. Je ne sais pas si c'est OSM qui gagne en renommée ou si cela s'explique par le taux de libristes au mètre carré ce week-end - sans doute un peu des deux - mais c'est bien la première fois que je vois autant de personnes me dire qu'elles connaissent déjà OSM même si elles n'ont qu'une vague idée de son mode de fonctionnement. Certaines personnes sont venues avec des questions très précises sur l'outillage disponible et je suis resté un peu sec. Heureusement, Cyrille et Léo étaient là. :) Merci donc à Cyrille et Léo pour leur précieux coup de main. La carte R25 du Parc des Volcans d'Auvergne réalisée par JB et imprimée au format A1 a eu un franc succès. Elle démontre bien qu'avec des données libres, tout ou presque est permis, y compris une carte de randonnée personnalisée. Merci beaucoup JB ! Vivement que TileMill sache faire de jolis exports PDF de grande taille. Nous pourrons alors nous passer de Maperitive. = Conférences Plusieurs conférences en lien avec l'open data, la cartographie et OSM ont été proposées au public : * Alternatives libres à GoogleMaps - Mathieu Leplatre http://2013.capitoledulibre.org/programme/conferences-internet-libre.html#scrczz * L'Open Data toulousain - Sandrine Mathon http://2013.capitoledulibre.org/programme/conferences-grand-public.html#scrddf * Découvrir la carte mondiale libre OpenStreetMap - Cyrille Giquello http://2013.capitoledulibre.org/programme/conferences-grand-public.html#scrcmr * Une seconde conférence de Cyrille Giquello il me semble mais je ne l'ai pas retrouvée dans le programme indiqué sur le site web Tenant le stand OSM, je n'ai pu assister à aucune de ces conférences (ni à d'autres qui m'auraient vivement intéressé). Je laisse Cyrille ou les personnes qui y ont assisté les commenter. J'ai par contre eu l'occasion de visiter le stand de Makina Corpus (sponsor de l'événement) et de découvrir quelques belles réalisations : * Geotrek, http://geotrek.fr/ * MooodWalkR, http://makina-corpus.com/blog/metier/moodwalkr-behind-the-scenes * Dimanche 24/11 = Ateliers (ni stand, ni conférence ce jour-là comme c'est la coutume à CdL) * Contribuer à OpenStreetMap - Sébastien Dinot http://2013.capitoledulibre.org/programme/ateliers.html#scrfzq Atelier de trois heures sur l'utilisation de JOSM. Une vingtaine de participants (j'en aurais eu plus si un robot mal configuré n'avait pas clos les inscriptions dès samedi matin et indiqué que l'atelier était complet) dont 3 seulement avaient déjà un compte OSM. Afin de conserver sa fluidité à l'atelier, j'avais demandé un coup de main à quelques mappeurs. Christophe Triquet (orhygine), Laurent Combe, Vincent Privat (don-vip) et Gérard Escande se sont dévoués. Ils n'ont pas été de trop car comme je m'y attendais, nous avons eu notre lot de bizarreries et de problèmes spécifiques. Merci donc à eux quatre, ils ont contribué au succès de l'atelier et à la satisfaction exprimée par les participants à la sortie. * Utiliser les données d'OpenStreetMap - Cyrille Giquello http://2013.capitoledulibre.org/programme/ateliers.html#scrdby Atelier d'une heure trente sur TileMill et l'API Overpass. Les deux sujets étaient fort intéressants mais Cyrille a joué de malchance : - Déjà médiocre le matin, la qualité du réseau s'est effondrée l'après-midi (7 minutes montre en main pour accéder au portail captif) et je n'ai pu avoir accès à Internet que 35 minutes après le démarrage de l'atelier. Je n'étais pas le seul dans ce cas, plusieurs participants ont éteint leur PC et suivi l'atelier en spectateur. - Pour éviter la surcharge, le site overpass-turbo.eu rejette les requêtes concurrentes en provenance de la même adresse IP. Or, j'ai compté 26 participants et chacun tentait sa chance. Résultat des courses, une seule de mes requêtes a abouti et, pas de bol, c'était pour me dire qu'aucune donnée du type que j'avais demandé n'existait dans la zone sélectionnée. :( J'ai donc été un peu agacé (pas par Cyrille mais par le cumul des tuiles). Ceci étant, je suis quand même content d'être venu car j'ai pu découvrir deux outils auxquels je ne m'étais pas encore frotté et, le hasard fait bien les choses, l'API overpass s'est déjà révélée utile depuis !
