[OSM-talk-fr] zoom sur carte
Bonjour Pourquoi sur la carte OSM quand je fais un zoom arrière toutes les modifications que j'ai envoyées ne sont plus visibles ??? alors que sur un niveau de zoom plus fort, tout apparait !! Ça fait bizarre il n'y a que ma zone qui disparait... Merci pour la réponse ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] zoom sur carte
Salut ! C'est juste que les tuiles correspondant à tous les niveaux de zoom ne sont pas régénérées en meme temps donc tes modifs peuvent effectivement etre visible ou pas selon le niveau de zoom affiché. Ce n'est qu'une question de temps, tes modifs seront très prochainement visibles dans tous les niveaux de zoom Le 28 juin 2012 08:08, Deloizy delo...@laposte.net a écrit : Bonjour Pourquoi sur la carte OSM quand je fais un zoom arrière toutes les modifications que j'ai envoyées ne sont plus visibles ??? alors que sur un niveau de zoom plus fort, tout apparait !! Ça fait bizarre il n'y a que ma zone qui disparait... Merci pour la réponse __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] zoom sur carte
Le 28/06/2012 08:08, Deloizy a écrit : Bonjour Pourquoi sur la carte OSM quand je fais un zoom arrière toutes les modifications que j'ai envoyées ne sont plus visibles ??? alors que sur un niveau de zoom plus fort, tout apparait !! Ça fait bizarre il n'y a que ma zone qui disparait... Merci pour la réponse ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr Bonjour, Rien de grave, juste une question de rafraichissement de caches, soit dans ton navigateur, soit au niveau du serveur de tuiles qui prend des temps différents pour mettre à jour les tuiles des différents niveau de zoom (en même temps, il ne peut pas tout faire simultanément) N’hésites pas à rafraichire le cache du navigateur (shift - mise à jour de la page sur firefox). Il existe aussi une procédure permettant de forcer le recalcul d'une tuile côté serveur, mais c'est rarement nécessaire. http://c.tile.openstreetmap.org/18/133039/90247.png/status (donne l'état de la tuile) http://c.tile.openstreetmap.org/18/133039/90247.png/dirty (force le refresh) A+ -- Marc Sibert mailto:m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Article sur la qualité d'OpenStreetMap dans XYZ
Bonjour, Comme indiqué ici http://www.agrotic.org/blog/?p=2722 L'article est issue d'un travail de fin d'étude. Le dossier complet de 71 pages est disponible ici : http://opheliepetit.fr/pdf/Dossierqualiteopenstreetmap.pdf René-Luc 3Liz (ancien AgroTic) Le 27/06/2012 23:44, Romain MEHUT a écrit : Bonsoir Ophélie, Des nouvelles quant à la possibilité d'avoir accès à cet article? Romain Le 23 juin 2012 14:53, Ophélie PETIT ophelie.petit.cheval...@gmail.com mailto:ophelie.petit.cheval...@gmail.com a écrit : Bonjour à tous! Ça faisait un moment que je l'avais annoncé, l'article sur la qualité d'OpenStreetMap vient de sortir dans la revue XYZ! http://www.aftopo.org/FR/xyz-4.html Je vais demander à XYZ la semaine prochaine pour savoir si je peux le diffuser. A bientôt. -- Ophélie PETIT ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Article sur la qualité d'OpenStreetMap dans XYZ
Le samedi 23 juin 2012 14:53:23 Ophélie PETIT a écrit : Bonjour à tous! Ça faisait un moment que je l'avais annoncé, l'article sur la qualité d'OpenStreetMap vient de sortir dans la revue XYZ! http://www.aftopo.org/FR/xyz-4.html Je vais demander à XYZ la semaine prochaine pour savoir si je peux le diffuser. Bonjour, Je suis en train de le parcourir (après l'avoir reçu dans ma BAL au boulot !), et la couverture du sujet est intéressante. Page 12, l'actualisation des données est évoquée. C'est vrai que ce serait pas mal, d'avoir un outil qui indique les zones non mise à jour depuis longtemps (à quantifier). Idéalement, je verrais bien un moyen de faire un touch sur les données pour dire qu'on les a vues et vérifiées sur le terrain ou une source récente en précisant la date. Mais bon, yaka ^^ Les méthodes utilisées pour faire les comparaisons sont intéressante, et permette d'expliciter ce que les contributeurs peuvent « intuiter ». Merci pour votre travail et votre rapport. -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Réseau routier du Cantal : c'est fait
Bonjour, Bon, voilà, j'en avais déjà parlé ici, j'ai passé quelques temps à me ballader sur les orthophotos du Cantal (merci le CRAIG). L'objectif était d'obtenir les distances routières entre toutes les communes du Cantal (le département), ce qui impliquait donc d'avoir les données routières et d'en avoir des bonnes. Au final, j'ai passé 2 semaines à temps plein à saisir les données manquantes et à corriger les erreurs. J'ai utilisé OSRM pour calculer les distances, et un peu de script python pour détecter des abérrations, et beaucoup d'inspection visuelle des données avec OpenLayers. Presque tout est expliqué ici (en anglais) : http://motive.cemagref.fr/people/nicolas.dumoulin/distances-osrm Pour ceux que ça intéresse, le même travail peut être reproduit dans les 3 autres département d'Auvergne. En effet, sans l'imagerie du CRAIG, je n'aurai pas pu mener ce projet à terme. De mon côté, je fais une pause sur l'utilisation de la souris, j'ai le bras droit en compote. -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réseau routier du Cantal : c'est fait
Un grand bravo pour ce travail accompli ! -- View this message in context: http://gis.19327.n5.nabble.com/Reseau-routier-du-Cantal-c-est-fait-tp5714385p5714388.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] Réseau routier du Cantal : c'est fait
Salut Nicolas, a fait plaisir de voir que l'Irstea ralisent des choses qui peuvent tre utiles OSM ! Quand je vois a je me dis que je devrais venir travailler avec toi Clermont-Ferrand. ;-) En tout cas excellent travail et merci beaucoup pour la description dtaille de la mthode. Tu dis que sans les images du CRAIG tu n'aurai pas pu faire le travail. Je n'ai pas bien saisi quelle a t ton utilisation de ces images ? Pour ajouter les routes manquantes dans OSM ? La rsolution des images Bing n'est pas suffisante pour a dans le Cantal ? a+ Nicolas Moyroud ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] CRAIG et bing en auvergne
Le 28/06/2012 09:44, Nicolas Dumoulin a écrit : Pour ceux que ça intéresse, le même travail peut être reproduit dans les 3 autres département d'Auvergne. En effet, sans l'imagerie du CRAIG, je n'aurai pas pu mener ce projet à terme. De mon côté, je fais une pause sur l'utilisation de la souris, j'ai le bras droit en compote. il y a une grosse partie de l'auvergne ou les photos bing ont ete mise a jour recamment, resultat bing est plus recent et meilleur que CRAIG (moins d'ombres portees, photos faites en septembre avec l'herbe verte et non pas jaunie) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réseau routier du Cantal : c'est fait
2012/6/28 partir-en-vtt ad...@partir-en-vtt.com: Un grand bravo pour ce travail accompli ! Ouais bravo, mais... we have used the commercial map only for identifying the lack of data in OpenStreetMap by data comparison Hummm, hummm, je tousse... On va pas relancer un débat légal ici mais utiliser une carte commerciale pour identifier des vides dans OSM, c'est amha aussi une forme de travail dérivé de cette carte commerciale (ce qui est protégé dans une carte, ça n'est pas le reflet de la réalité - qui n'est pas de la création - mais le travail de collecte et d'attribution). Donc comparer c'est bien profiter de ce travail de collecte, exhaustive dans le cas de l'IGN. On peut bien-sûr faire ce travail de comparaison pour une étude statistique (comme celle citée récemment d'Ophélie) mais pas pour que cela déclenche des contributions spécifiques dans OSM. Même si je reconnais que c'est limite et que probablement l'IGN ne poursuivra pas pour cet usage. Et d'ailleurs, si c'est fait à titre individuel et que la contribution elle-même est faite à partir d'une autre source, il est impossible de savoir que l'absence de route a été détectée sur une carte IGN. Ce qu'il faut, c'est éviter de le faire systématiquement (comme pour StreetView) ou juste ne pas le dire publiquement ;-) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réseau routier du Cantal : c'est fait
Le jeudi 28 juin 2012 10:25:55 Nicolas Moyroud a écrit : Salut Nicolas, Ça fait plaisir de voir que l'Irstea réalisent des choses qui peuvent être utiles à OSM ! Disons qu'on avait besoin de ces données, et que l'autre solution étaient estimée à plusieurs dizaines de milliers d'euros (vente assurée par un fonctionnaire d'un autre EPST :-/). Donc, je n'ai pas eu à trop argumenter ;-) Tu dis que sans les images du CRAIG tu n'aurai pas pu faire le travail. Je n'ai pas bien saisi quelle a été ton utilisation de ces images ? Pour ajouter les routes manquantes dans OSM ? La résolution des images Bing n'est pas suffisante pour ça dans le Cantal ? Non. La résolution de Bing est hétérogène, et dans certaines zones, on devine à peine les routes et encore moins leur largeur. En effet, pour le routage, il me fallait classifier un minimum les routes. J'ai donc choisi entre unclassified et tertiary (le reste était déjà saisi, à quelques rares exceptions) en fonction de la topologie et de la largeur de la route. De plus, dans certaines zones boisées, j'avais vraiment besoin d'une bonne résolution pour voir la route à travers les arbres (tout un art). Il y a quelques rares occasion ou j'ai dégotté bing qui avait une bonne résolution pour justement augmenter ma précision dans les portions boisées. Car, tant qu'à faire, j'ai essayé de ne pas dépasser les 5m d'erreur (distance de Hausdorff d'après le rapport d'Ophélie ;-) ). -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réseau routier du Cantal : c'est fait
Le jeudi 28 juin 2012 10:35:20 Pieren a écrit : Hummm, hummm, je tousse... On va pas relancer un débat légal ici mais utiliser une carte commerciale pour identifier des vides dans OSM, c'est amha aussi une forme de travail dérivé de cette carte commerciale Oui, ma conscience a été pas mal questionnée sur ce point. Mais au final, utiliser une carte pour repérer un endroit, puis y aller (à pied ou avec des vues aériennes) pour vérifier, ça me paraît correct. Je dis bien « vérifier », car au passage, j'ai pu remarquer des erreurs sur la carte IGN. -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] CRAIG et bing en auvergne
Le jeudi 28 juin 2012 10:29:30 hamster a écrit : Le 28/06/2012 09:44, Nicolas Dumoulin a écrit : Pour ceux que ça intéresse, le même travail peut être reproduit dans les 3 autres département d'Auvergne. En effet, sans l'imagerie du CRAIG, je n'aurai pas pu mener ce projet à terme. De mon côté, je fais une pause sur l'utilisation de la souris, j'ai le bras droit en compote. il y a une grosse partie de l'auvergne ou les photos bing ont ete mise a jour recamment, resultat bing est plus recent et meilleur que CRAIG (moins d'ombres portees, photos faites en septembre avec l'herbe verte et non pas jaunie) Certes, après l'annonce, je suis allé faire un petit tour. Mais, ça n'est toujours pas homogène. Donc, oui dans certaines zones bing peut être meilleure (attention au calage tout de même ! surtout dans un département avec du relief), mais pas partout. Et moi ce dont j'avais besoin, c'est ce « partout ». -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réseau routier du Cantal : c'est fait
Nicolas si je peux me permettre une autre question... Je ne suis pas sr d'avoir parfaitement compris l'usage que vous avez fait du GEOFLA de l'IGN concernant les "departure/arrival instructions needed for the computing the routes". Que contient plus prcisment le fichier "Cantal-routingInput.csv" ? De ce que j'ai compris vous utilisez les enveloppes des communes issues du GEOFLA pour dterminer les points de dpart et d'arrive des itinraires. Donc vos distances sont calcules partir des frontires des communes. J'ai bon ? Du coup, pourquoi n'avez-vous pas utilis directement les limites de communes issues d'OSM ? a+ Nicolas Moyroud ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réseau routier du Cantal : c'est fait
bravo nicolas ! Le 28 juin 2012 10:48, Nicolas Moyroud nmoyr...@free.fr a écrit : ** Nicolas si je peux me permettre une autre question... Je ne suis pas sûr d'avoir parfaitement compris l'usage que vous avez fait du GEOFLA de l'IGN concernant les departure/arrival instructions needed for the computing the routes. Que contient plus précisément le fichier Cantal-routingInput.csv ? De ce que j'ai compris vous utilisez les enveloppes des communes issues du GEOFLA pour déterminer les points de départ et d'arrivée des itinéraires. Donc vos distances sont calculées à partir des frontières des communes. J'ai bon ? Du coup, pourquoi n'avez-vous pas utilisé directement les limites de communes issues d'OSM ? a+ Nicolas Moyroud ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- *Florian Lainez* http://twitter.com/overflorian http://www.nouslesgeeks.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réseau routier du Cantal : c'est fait
Le jeudi 28 juin 2012 10:48:25 Nicolas Moyroud a écrit : Que contient plus précisément le fichier Cantal-routingInput.csv ? De ce que j'ai compris vous utilisez les enveloppes des communes issues du GEOFLA pour déterminer les points de départ et d'arrivée des itinéraires. Donc vos distances sont calculées à partir des frontières des communes. J'ai bon ? Non. Dans le fichier GeoFLA, il y a aussi les coordonnées du chef-lieu de commune. Donc le fichier en question contient la liste des trajets à calculer, avec pour chaque ligne, les coordonnées du point de départ et d'arrivée. Le chef-lieu est plus représentatif du centre des zone résidentielles d'une commune que le centroïdes de la limite administrative. Si tu as d'autres questions, on pourrait passer sur dev-fr Du coup, pourquoi n'avez-vous pas utilisé directement les limites de communes issues d'OSM ? Même si j'avais voulu, elles n'y sont pas pour toutes les communes ! -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réseau routier du Cantal : c'est fait
C'est une approche très intéressante. Lors de nos réunions parisiennes (pendant le hackathon Transilien), j'avais soumis l'idée d'une analyse osmose qui repérerait les manques au niveau du réseau routier en utilisant OSRM et en partant du principe (imparfait, c'est vrai) que chaque commune devrait avoir une route pour aller à ses voisines. Une autre idée venue en discutant avec David d'OpenTripPlanner était de récupérer les problèmes de routage signalés par son générateur de graphe pour signaler les ruptures dans osmose. Combler les trous est vraiment très utile mais encore faut-il les repérer ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Meilleur méthode pour créer une carte thématique
Bonjour, ça serait plutôt une petite zone (quelques communes). De l'affichage avec interaction sur le nom de l'élément, c'est à dire le nom qui s'affiche dans une petite fenêtre lorsque l'on clique dessus. Et faire au plus simple aussi (dans un premier temps) -- View this message in context: http://gis.19327.n5.nabble.com/Meilleur-methode-pour-creer-une-carte-thematique-tp5714351p5714429.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] Meilleur méthode pour créer une carte thématique
Bonjour, Une solution simple pourrait être d'utiliser OpenLayers [1] ou Leaflet [2] pour la partie carto et XAPI [3]pour les données OSM. Par exemple voir : http://geotribu.net/node/363 Arnaud 2012/6/28 SylvainH nbelsylv...@aol.com Bonjour, ça serait plutôt une petite zone (quelques communes). De l'affichage avec interaction sur le nom de l'élément, c'est à dire le nom qui s'affiche dans une petite fenêtre lorsque l'on clique dessus. Et faire au plus simple aussi (dans un premier temps) -- View this message in context: http://gis.19327.n5.nabble.com/Meilleur-methode-pour-creer-une-carte-thematique-tp5714351p5714429.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 -- Arnaud Van De Casteele Mines Paris Tech - CRC Sophia-Antipolis 0698 24 25 29 SIG - WebMapping - Spatial Ontology - GeoCollaboration Web Site http://perso.crc.mines-paristech.fr/~arnaud.van_de_casteele/ http://geotribu.net/ http://www.i2c.eu/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Meilleur méthode pour créer une carte thématique
Merci pour ce didactitiel. -- View this message in context: http://gis.19327.n5.nabble.com/Meilleur-methode-pour-creer-une-carte-thematique-tp5714351p5714451.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] url des repères géodésiques
Le 22 juin 2012 05:43, Nicolas Croiset (Campus Grenoble 90,8) nicolas.croi...@brume.org a écrit : On 21/06/2012 12:31, Eric Sibert wrote: À mon avis, c'est un tag genre ref:FR:IGN_geodesie avec uniquement l'identifiant qu'il faudrait mettre. C'est aux outils (tag2link...) de le convertir en url C'est une piste intéressante. ce qui donnerait, pour l'exemple présent : ref:FR:IGN_geodesie=7403003 Il y a déjà un tag ref. Il suffirait de le transformer et de supprimer toutes les url. Par contre, je ne sais pas trop comment procéder en pratique pour faire le remplacement sur toute la France. Si vous avez des suggestions... Bonjour, c'est effectivement une bonne idée. Concernant les points géodésique toujours et l'erreur Osmose Repère géodésique hors de sa commune, je tombe sur un cas intéressant car le point géodésique est un noeud de la frontière, à mon avis dans ce cas l'erreur ne devrait pas apparaitre. Salut, Je pense que le point ne devrait pas faire partie de la frontière, peut-être superposé au même endroit, mais pas dans le way. C. cf : http://osmose.openstreetmap.fr/map/?zoom=16lat=45.579591lon=3.105603item=6070 Qu'en pensez-vous ? A+ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] circonscriptions legislatives : trouver les limites
Le 21 juin 2012 22:20, Nabil Servais nabil.serv...@gmail.com a écrit : Salut, 2012/6/21 Marc SIBERT m...@sibert.fr: Le 19 juin 2012 23:39, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : Bonjour, Une version des limites de circonscriptions législatives a été construite parallèlement à la notre par toxicode. Ils ont mis leur construction à disposition hier : http://www.toxicode.fr/circonscriptions Le csv contient du kml. Il a été reconsolidé là : https://github.com/Icephale/constituency-fr-NG/blob/master/circos/circos.kml Il pour la constitution des circonscriptions dans OSM il reste encore du travail. Une nombre important de Journaux Officiels ont été identifié. http://wiki.openstreetmap.org/wiki/FR:Circonscription_l%C3%A9gislative Frédéric. Bonjour, Ce serait très instructif de faire un comparatif entre ces contours et ceux extraits d'OSM. Comme devoir de vacances, je vous propose : OpenLayers / Leaflet / etc. C'est en cours de développement. Pour l'instant j'ai seulement intégré les données du répo de Benjamin, une nouvelle version devrait arrivé dans les jours qui viennent avec les données de toxicode, un moteur de recherche fonctionnelle. Je suis même prêt à fournir un moyen pour faciliter l'intégration dans osm. http://maps.calculating-god.com/ Salut, Pourrais-tu indiquer, sur ton site[1], plus précisément: - les fichiers utilisés pour ton rendu ? Sur le github[2] il y en a beaucoup. - la licence du site[1] ? Peut-on réutiliser des choses. Merci ! [1] http://maps.calculating-god.com/ [2] https://github.com/Icephale/constituency-fr-NG Cyrille. Extraction des relations circonscriptions législatives d'OSM avec L'overpass api au format OSM dans un layer Production d'un second layer à partir du KML Les markers qui permettent d'ouvrir JOSM sur zone avec les deux éléments (OSM KML) circonscrits Je ramasse les sites web fin juillet ! Mes 0 € A+ -- Marc Sibert m...@sibert.fr -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Etat du cadastre vectorisé ou en voie de l'être
Bonjour, Vu sur le forum georezo, GeoBretagne publie un état des lieux de la numérisation du cadastre ([1]) en collaboration avec la DGFiP (mai 2012). Le document etat_numerisation_pcivecteur_et_convention_mai2012.pdf est particulièrement intéressant puisqu'il montre les communes déjà vectorisées et celles qui sont conventionnées (c.a.d dont la vectorisation est financée mais pas encore réalisée). Et il reste les blancs, c.a.d les communes qu'il ne faut pas trop être pressé de voir au format vecteur... Pieren [1] http://www.geobretagne.fr/web/guest/cadastre?p_p_id=ctcms_WAR_ctcmsportlet_INSTANCE_e4FSp_p_lifecycle=1p_p_state=normalp_p_mode=viewp_p_col_id=column-4p_p_col_count=1renderUid=35cmsAction=fullViewrecordUid=541 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Etat du cadastre vectorisé ou en voie de l'être
Merci Pieren pour cette info. Mes voisins meusiens sont très mal lotis mais ça on le savait déjà! Néanmoins, quelqu'un sait si une convention de vectorisation peut se faire à l'échelle d'une commune? Romain Le 28 juin 2012 15:00, Pieren pier...@gmail.com a écrit : Bonjour, Vu sur le forum georezo, GeoBretagne publie un état des lieux de la numérisation du cadastre ([1]) en collaboration avec la DGFiP (mai 2012). Le document etat_numerisation_pcivecteur_et_convention_mai2012.pdf est particulièrement intéressant puisqu'il montre les communes déjà vectorisées et celles qui sont conventionnées (c.a.d dont la vectorisation est financée mais pas encore réalisée). Et il reste les blancs, c.a.d les communes qu'il ne faut pas trop être pressé de voir au format vecteur... Pieren [1] http://www.geobretagne.fr/web/guest/cadastre?p_p_id=ctcms_WAR_ctcmsportlet_INSTANCE_e4FSp_p_lifecycle=1p_p_state=normalp_p_mode=viewp_p_col_id=column-4p_p_col_count=1renderUid=35cmsAction=fullViewrecordUid=541 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Article sur la qualité d'OpenStreetMap dans XYZ
Il existe un outil de calcul de température de villes cree par martin van exel. Son outil s'appelle osmquality metrics sur github et son login est mvexel On Jun 28, 2012 8:34 AM, Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net wrote: Le samedi 23 juin 2012 14:53:23 Ophélie PETIT a écrit : Bonjour à tous! Ça faisait un moment que je l'avais annoncé, l'article sur la qualité d'OpenStreetMap vient de sortir dans la revue XYZ! http://www.aftopo.org/FR/xyz-4.html Je vais demander à XYZ la semaine prochaine pour savoir si je peux le diffuser. Bonjour, Je suis en train de le parcourir (après l'avoir reçu dans ma BAL au boulot !), et la couverture du sujet est intéressante. Page 12, l'actualisation des données est évoquée. C'est vrai que ce serait pas mal, d'avoir un outil qui indique les zones non mise à jour depuis longtemps (à quantifier). Idéalement, je verrais bien un moyen de faire un touch sur les données pour dire qu'on les a vues et vérifiées sur le terrain ou une source récente en précisant la date. Mais bon, yaka ^^ Les méthodes utilisées pour faire les comparaisons sont intéressante, et permette d'expliciter ce que les contributeurs peuvent « intuiter ». Merci pour votre travail et votre rapport. -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] zoom sur carte
Le 28 juin 2012 08:37, Marc Sibert m...@sibert.fr a écrit : N’hésites pas à rafraichire le cache du navigateur (shift - mise à jour de la page sur firefox). Il existe aussi une procédure permettant de forcer le recalcul d'une tuile côté serveur, mais c'est rarement nécessaire. http://c.tile.openstreetmap.org/18/133039/90247.png/status (donne l'état de la tuile) http://c.tile.openstreetmap.org/18/133039/90247.png/dirty (force le refresh) Dommage qu'on n'ait pas la même chose (au moins la sous-page /status) sur les autres serveurs de tuiles hors ceux ici de Mapnik. De même le framework OpenLayers ne tient pas compte de l'état du cache web affiche de façon indéfinie des images obsolètes récupérées d'anciennes versions stockées dans le cache, même lorsque le navigateur a chargé une nouvelle version des tuiles. (On s'en rend compte en faisant un click droit pour ouvrir une tuile dans un nouvel onglet, pour ensuite l'y rafraîchir avec F5, mais quand on revient à la page OpenLayers, on a beau bouger la page ou même la recharger, c'est encore l'ancienne version qui s'affiche et non celle remise à jour pourtant séparément dans le cache du navigateur ! Le seul moyen d'afficher une nouvelle version est de vider complètement le cache du navigateur (en fermant d'abord la page) ce qui est carrément contreproductif quand on veut voir l'effet d'une modification (par exemple juste après une correction). Au moins on n'a pas ce problème de rafraîchissement avec les autres frameworks. Mais OpenLayers est une collection de scripts particulièrement complexes qui génère du code Javascript effectuant apparemment ses requêtes HTTP lui-même sans passer par les fonctions de chargement web du navigateur, et gérant d'une façon étrange le stockage dans le cache (ou qui ne tient pas compte des dates d'obsolescence): il génère alors un cache local absolument énorme contenant des tonnes de tuiles obsolètes qui ne sont même pas purgées. D'ailleurs ce problème de croissance incontrôlée du cache local de tuiles existe aussi dans JOSM qui fait croitre de façon démesurée le cache avec des tuiles qui ne sont ensuite plus jamais purgées (on se retrouve alors avec un répertoire cache contenant vite dans un seul dossier des dizaines de milliers de fichiers (à ne surtout pas stocker dans un volume FAT, NTFS est très hautement conseillé sinon ça rame de plus en plus ! Mais même avec NTFS on constate que finalement le cache devient vite plus lent au moindre accès que simplement redemander les tuiles au serveur). Je veux bien qu'il y ait une politique pour les tuiles, seulement un serveur de tuiles indique une date d'obsolescence raisonnable, et le protocole HTTP pourrait être respecté quand une tuile est rafraichie, afin que le client en tienne compte ! Si la solution c'est de vider le cache du navigateur à chaque fois, pour restaurer les performances et éviter d'encombrer indéfiniment un volume disque, ces logiciels clients doivent être mis à jour (c'est la principale cause actuellement des plantage de JOSM, qui rapidement ne parvient même plus à lire en entier les fichiers de son cache local de tuiles, tellement il y stocke de fichiers, même en version 64 bits avec une taille de VM imposante, par exemple 8 Go). Enfin les logiciels qui gèrent des caches de tuiles devraient éviter de stocker des dizaines de milliers de fichiers dans un même dossier du système de fichiers. Si les fichiers ont des noms bien définissables, on doit pouvoir calculer une clé de hachage simple mais prédistible de ces noms permettant de les répartir en par exemple un maximum de 256 dossiers de 256 sous-dossiers maximum (ou toute division suffisante adaptée au niveau de zoom de ces tuiles selon le serveur), afin d'accélérer considérablement l'accès et la maintenance de leurs contenus, comme aussi accélérer considérablement le nettoyage (surtout sur les volumes FAT ou NFS ou UFS qui n'ont pas d'index d'accès direct, les fichiers étant trouvés dans un dossier en le parcourant depuis le début, ou le dossier étant maintenu trié et demandant de plus en plus de maintenance au fur et à mesure que le nombre de leurs entrées croit). Si on devait aller plus loin, même les métadonnées pour les tuiles devraient non pas être dans des fichiers texte séparés pour chaque tuile mais dans un index de base de données locale (sur un volume NTFS, ces métadonnées peuvent être stockées dans des streams sans entrée supplémentaire dans les dossiers, ces streams étant eux aussi autoindexables en B-arbres paginables avec un accès direct très rapide aussi bien en lecture qu'en mise à jour, sinon on peut aussi utilise un fichier de base de données unique dans le dossier des images; si cette base de données est corrompue ou plus à jour, il peut être reconstruit en ignorant et purgeant automatiquement aussi les images du dossier sans métadonnées; la base de données doit uniquement contenir les champs d'entête MIME pertinents pour la gestion du cache HTTP et émis par le serveur,
