Re: [OSM-talk-fr] Ouverture portail Open Data du Grand Nancy
Le 25 août 2013 13:06, Romain MEHUT romain.me...@gmail.com a écrit : Le 24 août 2013 22:37, Christian Quest cqu...@openstreetmap.fr a écrit : Bon, côté licence, c'est feu vert, mais maintenant il faut regarder la qualité de ces données et ne pas s'enthousiasmer par avance vu les expériences passées mais j'ai un bon présentiment vu la liste des jeux de données. Romain, tu as déjà regardé la qualité ? Non je n'ai pas encore eu le temps. J'ai regardé quelques points adresse par rapport à ceux que j'avais relevés sur le terrain et la position colle bien. Reste tout de même à bien placer le point sur le polygone du bâti surtout en centre ville. Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Ouverture portail Open Data du Grand Nancy
Le 25 août 2013 17:40, DH dhel...@free.fr a écrit : Merci pour cette bonne nouvelle Romain. Pour donner un exemple de la qualité de l'image : http://dhelfer.free.fr/gare%**20de%20Nancy.pnghttp://dhelfer.free.fr/gare%20de%20Nancy.png(ortho à 7,5 cm) C'est chouette! J'attends avec impatience que l'on puisse disposer d'un flux WMS pour JOSM. Du coup, il y a du boulot ; j'vais y faire un tour virtuel ce soir... Un souhait particulier pour l'attribution de source ? ©Communauté Urbaine du Grand Nancy 2012 ? Oui j'y ai pensé également car rien n'est indiqué sur le portail. Il existe une convention dans ce cas de figure? On pourrait aussi simplement choisir Grand Nancy 2012? Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Ouverture portail Open Data du Grand Nancy
Le 26 août 2013 09:57, Romain MEHUT romain.me...@gmail.com a écrit : Oui j'y ai pensé également car rien n'est indiqué sur le portail. Il existe une convention dans ce cas de figure? On pourrait aussi simplement choisir Grand Nancy 2012? Au niveau du sourcage, peut être serait-il intéressant d'être beaucoup plus précis que ça, comme j'imagine qu'il sera importé par un logiciel, et que ça prendra pas beaucoup plus de temps, que d'inclure la provenance précise dans la base grand nancy. Je veux dire, souvent qu'une donnée vient d'un table précise, et comporte à l'origine un id dans cette table. Par exemple (j'imagine) une hypothétique liste de bancs publics, sera, je suppose, dans une table de bancs publics, avec chacun un id dans cette table. En ce cas je suggèrerais de mettre Grand Nancy 2012 (si c'est ça qui est retenu) [nom de la table dans grand nancy opendata] [id du banc dans la table opendata]. À moins, bien sûr, que l'on ne décide de mettre ces infos dans des propriétés, mais je ne suis pas sûr que ce soit judicieux, car le nom de la table opendata n'est quand même pas une donnée géographique librement observable sur le terrain, à moins, bien sûr, que les gens de Nancy se soient organisés pour ça. Une telle démarche permettra plus facilement une coordination entre OSM et les données open data à l'avenir, me semble-t-il sauf erreur. Cordialement. -- Les dérives de rue : La municipalité de Saint-Étienne applaudit le théâtre emporté par le venthttp://drivrsdu.fr/la-municipalite-de-saint-etienne-applaudit-le-theatre-emporte-par-le-vent/ http://drivrsdu.fr/profession-emotion/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Ouverture portail Open Data du Grand Nancy
Bonjour, De : Ista Pouss Au niveau du sourcage, peut être serait-il intéressant d'être beaucoup plus précis que ça, comme j'imagine qu'il sera importé par un logiciel, et que ça prendra pas beaucoup plus de temps, que d'inclure la provenance précise dans la base grand nancy. Je veux dire, souvent qu'une donnée vient d'un table précise, et comporte à l'origine un id dans cette table. Par exemple (j'imagine) une hypothétique liste de bancs publics, sera, je suppose, dans une table de bancs publics, avec chacun un id dans cette table. En ce cas je suggèrerais de mettre Grand Nancy 2012 (si c'est ça qui est retenu) [nom de la table dans grand nancy opendata] [id du banc dans la table opendata]. L'usage jusque là est plutôt de renseigner un tag source générique, à l'échelle du producteur (ici : source=Grand Nancy 2012 ou approchant) et d'ajouter un tag ref, avec un espace de nommage spécifique, pour les identifiants lus dans la source, au niveau de la donnée élémentaire. Quelque chose comme : ref:GrandNancy=[id du banc dans la table opendata] 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] Ouverture portail Open Data du Grand Nancy
Le 26 août 2013 10:15, Ista Pouss ista...@gmail.com a écrit : Le 26 août 2013 09:57, Romain MEHUT romain.me...@gmail.com a écrit : Oui j'y ai pensé également car rien n'est indiqué sur le portail. Il existe une convention dans ce cas de figure? On pourrait aussi simplement choisir Grand Nancy 2012? Au niveau du sourcage, peut être serait-il intéressant d'être beaucoup plus précis que ça, comme j'imagine qu'il sera importé par un logiciel, et que ça prendra pas beaucoup plus de temps, que d'inclure la provenance précise dans la base grand nancy. Je veux dire, souvent qu'une donnée vient d'un table précise, et comporte à l'origine un id dans cette table. Par exemple (j'imagine) une hypothétique liste de bancs publics, sera, je suppose, dans une table de bancs publics, avec chacun un id dans cette table. En ce cas je suggèrerais de mettre Grand Nancy 2012 (si c'est ça qui est retenu) [nom de la table dans grand nancy opendata] [id du banc dans la table opendata]. À moins, bien sûr, que l'on ne décide de mettre ces infos dans des propriétés, mais je ne suis pas sûr que ce soit judicieux, car le nom de la table opendata n'est quand même pas une donnée géographique librement observable sur le terrain, à moins, bien sûr, que les gens de Nancy se soient organisés pour ça. Une telle démarche permettra plus facilement une coordination entre OSM et les données open data à l'avenir, me semble-t-il sauf erreur. Cordialement. Il vaut mieux être précis dans le sourçage, car un même type d'info peut se retrouver dans plusieurs dataset. Exemple: les emplacement de stationnement PMR. Ils se trouvent dans un fichier séparé, de qualité visiblement moyenne, et dans un second jeu de données qui semble plus complet, plus précis au niveau position (comparé au bâti du cadastre et à l'ortho bing), mais plus ancien (2008). Ca montre au passage une fois de plus, tout le boulot fait en doublon dans les administrations... Donc... il y a surtout du boulot de tri à faire dans toutes ces données, pour identifier les plus pertinentes, etc, etc... -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Piscines - était : Re: Circuits vélotourisme en Vaucluse
Bonjour, Le 21 août 2013 22:51, Yves Pratter yves.prat...@laposte.net a écrit : En représentant leisure/amenity=swimming_pool, sans restriction d'accès (no/private), voilà ce que ça donne : http://osm107.openstreetmap.fr/jbtopo/piscines.PNG sur le nord-est d'Orange… Y'a du travail de nettoyage. Effectivement, on se croirait en pleine mer :-D Je ne suis pas convaincu par la présence du tag sport=swimming pour indiquer l'accessibilité au public… Non, il sert à indiquer — entre-autres à OpenSeaMap — qu'on y pratique la natation. La piscine du Loft, bien que privée avait d'autres usages ;-) Pour les piscines découvertes pour villageois en vacances, ce tag ne se justifie pas toujours. Alors qu'un access=*, lui… Oui, dans tout ces exemples, il faut un access=private Je ne suis pas l'actualité des tags de très prés, ni même je ne contribue pas vraiment à leur élaboration. Par contre, en prenant un peu de recul, l'idée de mettre un tag access=private sur les piscines privées est surprenant. Pour un chemin ou une route, préciser que l'une d'entre elle est privée parait tout à fait naturel. Mais pour une piscine, ça me semble moins naturel. En effet, dans ma région (sud, soleil, toussa), les piscines privées sont légion, contrairement aux piscines publiques. Par exemple, dans mon environnement proche, il doit y avoir 50% des maisons qui ont leur piscine et pas la moindre piscine publique dans le village (qui dépasse les 3000 habitants). Du coup, ne serait-ce que d'un point de vue pratique, il me semblerait plus logique que la notion d'accès sur une piscine soit inversée : par défaut private et public seulement si précisé. Dans le même ordre d'idée, depuis l'import du bâti, c'est plein de building=yes sans autre précision et pourtant cela ne fait pas de ces bâtiments des bâtiments publics que l'on peut visiter à loisir. Du coup, est-il vraiment nécessaire de systématiquement préciser la nature d'un accès ? Qui plus est, en suivant ma logique, ce n'est pas tant l'accès à la piscine qui est privée, mais l'accès à toute la propriété. Du coup, il faudrait systématiquement représenter les lots pour y faire porter cette indication d'accès. Une autre réflexion porte sur l'utilité de préciser les piscines privées. On m'a dit un jour que les pompiers sont susceptibles d'apprécier cette information. Mais ce qui leur importe, c'est de savoir qu'il y a de l'eau, pas de savoir qu'on peut se baigner dedans. Peut-être que cette information présente un intérêt pour des personnes souhaitant faire des statistiques, ou je ne sais qu'elle étude. Peut-être aussi que cela fait un repère visuel depuis les hauteurs (le ciel ?). Bref, en conclusion, il me semble important de ne surtout pas représenter tous les leisure=swimming_pool, qui doivent servir à représenter simplement des bassins, mais plutôt sport=swimming comme précisé plus avant dans les échanges de mails. Mais bon, encore une fois, je ne suis pas très impliqué dans les décisions qui tournent autour des tags et de leurs logiques ou homogénéités. -- Guilhem BONNEFILLE -=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com -=- mailto:guilhem.bonnefi...@gmail.com -=- http://nathguil.free.fr/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Après le dessous des cartes (sur Arte), voici le dessus des cartes (sur France Inter)
C'était ce matin dans l'émission Service Public de France Inter, qu'on peut ré-écouter sur http://www.franceinter.fr/emission-service-public-gps-le-dessus-des-cartesà partir de 3'50 -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Prochaine réunion des contributeurs à OpenStreetMap de la région de Marseille le lundi 2 / 09 / 2013 // 20h00 à La Bo@te.
*Bonjour à toutes et à tous. * * Je rappel que les contributeurs d' OpenStreetMap de la région de Marseille se réunissent le lundi 2 septembre 2013, à partir de 20h00 à La Bo@te ( dates suivantes en fin de message ). * * Pour ceux qui compterais participez à la réunion et qui viennent pour la première fois, nous avons pour habitude que chacun(e) amène quelque chose à boire et/ou à grignoter. * *Pour confirmer votre présence éventuel, vous pouvez répondre à ce message, merci. - Lien du plan de l'accès à La Bo@te : http://www.openstreetmap.org/?lat=43.29213amp;lon=5.3730645amp;zoom=18amp;layers=Mamp;mlat=43.29210amp;mlon=5.37297http://www.openstreetmap.org/?lat=43.29213lon=5.3730645zoom=18layers=Mmlat=43.29210mlon=5.37297 - Lien de la page du Wiki d' Openstreetmap sur les réunions de Marseille : http://wiki.openstreetmap.org/wiki/Marseille/R%C3%A9unions_2013 - Archives de l'année 2012 : http://wiki.openstreetmap.org/wiki/Marseille/R%C3%A9unions_2012 Nota : Calendrier des réunions suivantes pour 2013, même lieu, même horaire. * * * * - lundi 7 octobre 2013. * * - lundi 4 novembre 2013. * * - lundi 2 décembre 2013. * *** À bientôt... Amicales salutations.** ** Olivier Griffet http://griffet.net/ | Contributeur OpenStreetMap = http://www.openstreetmap.org/user/olivier_griffet_83660_carnoules | | Habitant de 83660http://www.openstreetmap.org/export/embed.html?bbox=6.17628,43.29493,6.19694,43.30505layer=mapnikmarker=43.29837,6.18737- Carnoules http://carnoules.fr/ - Var | Adhérent de GULLIVAR et ToulonuX | Utilisateur de GNU/LINUX de **(X)Ubuntu 12.04 [ XFCE ] ; Lives USB ASRI.EDU.300 ; Etc... Site web de GULLIVAR : http://gullivar.org/ Site web de ToulonuX : http://toulonux.tuxfamily.org/ * ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Après le dessous des cartes (sur Arte), voici le dessus des cartes (sur France Inter)
En dehors de la phrase tout le monde peut y participer, la description du projet vers 26'30'' ne donne pas une idée très précise du projet. La dame dit même qu'il n'y a aucune uniformisation de l'information, donc je me demande bien pourquoi on se fatigue à discuter des bonnes pratiques sur cette liste de diffusion. 2013/8/26 Christian Quest cqu...@openstreetmap.fr C'était ce matin dans l'émission Service Public de France Inter, qu'on peut ré-écouter sur http://www.franceinter.fr/emission-service-public-gps-le-dessus-des-cartesà partir de 3'50 -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ 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
[OSM-talk-fr] Bâtiment non rendu
Bonjour, j'ai un bâtiment : http://www.openstreetmap.org/browse/way/32635153 qui n'est rendu ni sur Osm.org : http://www.openstreetmap.org/#map=19/45.19088/5.72839 ni sur tile.openstreetmap.fr : http://tile.openstreetmap.fr/?zoom=19lat=45.19088lon=5.72839 Quelqu'un aurait un diagnostic de ce qui se passe ? Merci ! Damouns ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâtiment non rendu
Le 26/08/2013 15:55, Damouns a écrit : Bonjour, j'ai un bâtiment : http://www.openstreetmap.org/browse/way/32635153 qui n'est rendu ni sur Osm.org : http://www.openstreetmap.org/#map=19/45.19088/5.72839 ni sur tile.openstreetmap.fr http://tile.openstreetmap.fr : http://tile.openstreetmap.fr/?zoom=19lat=45.19088lon=5.72839 Quelqu'un aurait un diagnostic de ce qui se passe ? Sue le rendu palois il apparait qu'à une époque, c'était un multipolygone creux (voir pièce jointe si elle passe sur la liste). Il a perdu son chemin intérieur. Et depuis, même sur le serveur palois, quelque soit le style, le bâtiment n'est plus rendu après recalcul. Je n'ai aucune explication, le bâtiment semble correct. A par le supprimer et le redessiner complètement, je n'ai aucune suggestion. Librement, -- Christophe Merlet (RedFox) attachment: 47051.png___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâtiment non rendu
J'ai fait une modif neutre (juste un changement de version de l'objet) et il est apparu sur le rendu osm.org Ca ressemble à une désynchro d'objet... ça arrive parfois, sûrement un bug d'osm2pgsql si un multipolygone disparait, le polygone outer n'est pas recréé ou un truc du genre. Le 26 août 2013 16:31, Christophe Merlet red...@redfoxcenter.org a écrit : Le 26/08/2013 15:55, Damouns a écrit : Bonjour, j'ai un bâtiment : http://www.openstreetmap.org/**browse/way/32635153http://www.openstreetmap.org/browse/way/32635153 qui n'est rendu ni sur Osm.org : http://www.openstreetmap.org/#**map=19/45.19088/5.72839http://www.openstreetmap.org/#map=19/45.19088/5.72839 ni sur tile.openstreetmap.fr http://tile.openstreetmap.fr : http://tile.openstreetmap.fr/?**zoom=19lat=45.19088lon=5.**72839http://tile.openstreetmap.fr/?zoom=19lat=45.19088lon=5.72839 Quelqu'un aurait un diagnostic de ce qui se passe ? Sue le rendu palois il apparait qu'à une époque, c'était un multipolygone creux (voir pièce jointe si elle passe sur la liste). Il a perdu son chemin intérieur. Et depuis, même sur le serveur palois, quelque soit le style, le bâtiment n'est plus rendu après recalcul. Je n'ai aucune explication, le bâtiment semble correct. A par le supprimer et le redessiner complètement, je n'ai aucune suggestion. Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] live.openstreetmap.fr c'est parti !
C'est normal que live.openstreetmap.fr soit toujours H.S. ? Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] live.openstreetmap.fr c'est parti !
Il tourne sur osm7... qui est HS... Le 26 août 2013 16:42, Stéphane Péneau stephane.pen...@wanadoo.fr a écrit : C'est normal que live.openstreetmap.fr soit toujours H.S. ? Stf __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Comparaison OSM/Route500
Je viens de terminer un bout de script pour générer département par département une liste des routes présentes dans OSM et dans le Route500 de l'IGN. Donc pour chaque département ça sort la liste des 'ref' et les km présents dans OSM et le Route500, le tout sous forme de fichier CSV (en attendant une interface un peu plus sexy). http://osm13.openstreetmap.fr/~cquest/routes/ Extrait du README: Les kilométrage sont calculés en projection Lambert 93 (EPSG:2154). La date de modification de chaque fichier CSV indique quand le calcul a été fait, les données OSM pouvant avoir en général tout au plus 5mn de retard de mise à jour. ATTENTION: Les tronçons sont découpés à la limite du département présente dans OSM, ceci peut créer de petites erreurs de calcul à la frontière du département. Les kilométrage du Route500 sont généralement inférieurs à ceux d'OSM pour une route complète de part la simplification géométrique du Route500. Tous les type de highway=* sont pris en compte sans distinction (cf la requête SQL). -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comparaison OSM/Route500
Merci, mais tu comptes l'utiliser comment ? Sachant qu'il y a un certain nombre de cas où il est très difficile de savoir qui a raison sur la numérotation, suite à des renumérotations et des documents pas toujours très clairs ni accessibles, le terrain et/ou route500 en retard... Il va falloir éviter les traitements trop automatiques. Quelques raster eggs : Dans le 25, on a une D89 qui fait 0km chez OSM et chez IGN : comment est-elle arrivée là ? Idem dans le 12 pour la D907B. Et on retrouve une toute petite N9 à la fois dans le 12 et le 25, chez IGN ? Art. Le 26 août 2013 19:47, Christian Quest cqu...@openstreetmap.fr a écrit : Je viens de terminer un bout de script pour générer département par département une liste des routes présentes dans OSM et dans le Route500 de l'IGN. Donc pour chaque département ça sort la liste des 'ref' et les km présents dans OSM et le Route500, le tout sous forme de fichier CSV (en attendant une interface un peu plus sexy). http://osm13.openstreetmap.fr/~cquest/routes/ Extrait du README: Les kilométrage sont calculés en projection Lambert 93 (EPSG:2154). La date de modification de chaque fichier CSV indique quand le calcul a été fait, les données OSM pouvant avoir en général tout au plus 5mn de retard de mise à jour. ATTENTION: Les tronçons sont découpés à la limite du département présente dans OSM, ceci peut créer de petites erreurs de calcul à la frontière du département. Les kilométrage du Route500 sont généralement inférieurs à ceux d'OSM pour une route complète de part la simplification géométrique du Route500. Tous les type de highway=* sont pris en compte sans distinction (cf la requête SQL). -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ 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] Comparaison OSM/Route500
Le 26 août 2013 20:52, Jean-Claude Repetto jrepe...@free.fr a écrit :
On 26/08/2013 19:45, Christian Quest wrote:
Je viens de terminer un bout de script pour générer département par
département une liste des routes présentes dans OSM et dans le Route500
de l'IGN.
Très intéressant ! Ce script sera-t-il lancé régulièrement ? Cela
permettrait de suivre l'avancée des travaux, surtout si plusieurs
contributeurs travaillent sur le même département.
Oui, je pense quotidiennement.
Pour le 06, il manque les routes métropolitaines, ce qui fausse le
résultat.
Peux-tu modifier ta requête :
HAVING SUBSTRING(ref,1,1) IN ('A','N','D')
en
HAVING SUBSTRING(ref,1,1) IN ('A','N','D','M') ?
Déjà ajouté pour le 06... même si ces routes M n'existent pas
officiellement ;)
La requête fait aussi apparaître les pistes DFCI (par exemple DFCILD 86 A
2.4), mais ce n'est pas très gênant, il suffit de ne pas en tenir compte.
Oui, j'ai vu ça. Ca vient du fait que je prends toutes les highway=* sans
distinction (cf README).
--
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comparaison OSM/Route500
Visiblement la requête tient compte des espaces - D155 différent de D 155 - et de la casse pour comparer les références de voie, ça complique le traitement des résultats avec tout un tas de faux positif. Je pense qu'il serait préférable de traiter D 155 b identique a D155B par exemple, ca évite d'avoir a traiter séparément les deux erreurs remontées. Le 26 août 2013 19:45, Christian Quest cqu...@openstreetmap.fr a écrit : Je viens de terminer un bout de script pour générer département par département une liste des routes présentes dans OSM et dans le Route500 de l'IGN. Donc pour chaque département ça sort la liste des 'ref' et les km présents dans OSM et le Route500, le tout sous forme de fichier CSV (en attendant une interface un peu plus sexy). http://osm13.openstreetmap.fr/~cquest/routes/ Extrait du README: Les kilométrage sont calculés en projection Lambert 93 (EPSG:2154). La date de modification de chaque fichier CSV indique quand le calcul a été fait, les données OSM pouvant avoir en général tout au plus 5mn de retard de mise à jour. ATTENTION: Les tronçons sont découpés à la limite du département présente dans OSM, ceci peut créer de petites erreurs de calcul à la frontière du département. Les kilométrage du Route500 sont généralement inférieurs à ceux d'OSM pour une route complète de part la simplification géométrique du Route500. Tous les type de highway=* sont pris en compte sans distinction (cf la requête SQL). -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ 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
