[OSM-talk-fr] Re : Re : Re : Import Corine - Status
De : Etienne Chové ch...@crans.org Ça monte... http://osmose.openstreetmap.fr/map/cgi-bin/clc.py On dirait que l import est bloque depuis une petite heure Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Re : Re : Import Corine - Status
THEVENON Julien a écrit : *De :* Etienne Chové ch...@crans.org ** Ça monte... http://osmose.openstreetmap.fr/map/cgi-bin/clc.py On dirait que l import est bloque depuis une petite heure Julien Ouais, 05:40:33 GMT d'après osm.org/user/CLCF06/edits Je ne sais pas s'il y a une hot line ;-) J'imagine (et j'espère pour lui) que Pieren ne passe pas sa vie devant la courbe. -- Vincent alias FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Tag] Comment representer une statue ?
THEVENON Julien a écrit : Bonjour tout le monde, Quel(s) tag doit on utiliser pour une statue ? Je suppose que c est quelque chose du genre historic=statue mais je n ai rien vu de tel sur le wiki. A moins que l on puisse utiliser memorial ? Dans mon cas il s agit d une statue de la vierge dressee en memoire d un pretre. Merci d avance Julien Les tags disponibles : tourism=artwork + name=* + artwork_type=painting|mosaic|sculpture|mural... + artist_name=* + date=* historic=memorial -- Vincent alias FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Re : Re : Import Corine - Status
2009/9/29 Vincent Pottier vpott...@gmail.com: THEVENON Julien a écrit : J'imagine (et j'espère pour lui) que Pieren ne passe pas sa vie devant la courbe. Hélas non... ;-) Le script s'est arrété suite à une erreur 'connection refused'. Je redémarre et j'en profite pour mettre la liste des incidents et les changesets concernés sur le wiki comme ça, on pourra toujours revenir dessus en cas de problème: http://wiki.openstreetmap.org/wiki/WikiProject_France/Corine_Land_Cover#Historique_de_l.27import Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Re : [Tag] Comment representer une statue ?
De : Vincent Pottier vpott...@gmail.com THEVENON Julien a écrit : Bonjour tout le monde, Quel(s) tag doit on utiliser pour une statue ? Je suppose que c est quelque chose du genre historic=statue mais je n ai rien vu de tel sur le wiki. A moins que l on puisse utiliser memorial ? Dans mon cas il s agit d une statue de la vierge dressee en memoire d un pretre. Les tags disponibles : tourism=artwork + name=* + artwork_type=painting|mosaic|sculpture|mural... + artist_name=* + date=* historic=memorial Cool ! Merci Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Re : Import Corine - Status
Le Tue, Sep 29, 2009 at 12:43:13AM +0200, Jean-Christophe Haessig [jean-christophe.haes...@dianosis.org] a écrit: Le lundi 28 septembre 2009 à 23:46 +0200, Pieren a écrit : Salut, puis les forêts, etc... pour finir avec les lacs et rivières. Oups, j???avais zappé que les surfaces d???eau étaient aussi concernées. J???ai taggué quelques petits lacs (quelques dizaines de mètres d???envergure), est-ce que c???est gênant ? De mémoire, je crois que les plus petits objets que CLC connait, c'est 5 ha Donc, a priori, tes (f)lacs de qq dizaines de metres ne devraient pas géner :) Au pire, tu feras un tour, plus tard, quand les polygones non importés seront mis à dispo, pour voir si il n'y avait pas qq choses dans Corine qui serait rentré en conflit avec. -- Dominique Rousseau d...@lee-loo.net - 06 82 43 12 27 Si cinquante millions de gens disent une sottise, ça n'en reste pas moins une sottise. -- Anatole France ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Re : Re : Re : Re : Import Corine - Status
De : Vincent Pottier vpott...@gmail.com THEVENON Julien a écrit : On dirait que l import est bloque depuis une petite heure Ouais, 05:40:33 GMT d'après osm.org/user/CLCF06/edits Je ne sais pas s'il y a une hot line ;-) J'imagine (et j'espère pour lui) que Pieren ne passe pas sa vie devant la courbe. Apparemment quelqu un s en est apercu l import a repris il y a 10 minutes :-) Et pour Pieren je sais pas mais j avoue que je passe souvent devant la courbe ( ca me fascine !!! ) Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [ANNONCE] MapOSMatic : gén ération automatique de plans de ville à partir des données OpenStreetMap
Pour les diffs, c'est peut-être pas la meilleure solution si vous décidez de mettre à jour une seule fois par jour toute la France. Pour cela, un téléchargement du dernier osm.bz de chez geofabrik et un import de novo dans la bdd via osm2pgsql est plus rapide. Nous le faisons pour osmtransport , et pour la France, cela prend environ 20 minutes avec un serveur normal. (4go Ram) Sinon pendant que j'y suis : Ce serait top de faire des cartes à fond blanc pour économiser de l'encre (je parle de la couleur de remplissage entre les rues). Le style Mapnik n'est pas très adapté à l'impression je trouve. Je sais qu'un demande a été faite pour pouvoir ajouter des styles via upload de fichiers xml, mais en attendant ce serait bon pour l'environnement de mettre de la couleur (et du gris) que lorsqu'il y en a besoin :). Kimaidou Le 28 septembre 2009 20:42, Vincent Pottier vpott...@gmail.com a écrit : David MENTRE a écrit : Bonjour Jean-François, Jean-Francois Nifenecker jean-francois.nifenec...@laposte.net writes: je rencontre un souci : lorsque je demande un rendu pour une localité déjà rendue, le rendu antérieur est directement proposé, sans possibilité de re-rendre. C'est gênant, d'autant que les données sous-jacentes peuvent avoir beaucoup changé (ex : Cenon) ;-) Oui, initialement on avait mis ça en place pour limiter la charge sur le serveur. Maintenant, il faudrait un système qui re-régénère la carte au bout d'un certain temps. Oui, ce serait bien? Ça a changé ici ! http://osm.org/go/erms5edf8-- Et obtnir ça : http://maposmatic.org/rendered//003099_2009-09-28_20-23_LeMontSaintMichel.png C'est un peu dommage. De plus, je trouve que, d'une manière générale les données utilisées ne sont pas très fraîches (Walking papers a le même problème). C'est moi, ou bien ? Initialement il n'y avait pas d'import régulier. David (Decotigny) et Thomas regardent ça mais galèrent pas mal : il nous faut actuellement 9h pour importer 24h de diff : pas top ! On si prend peut-être mal, mais bon on apprend un peu sur le tas. En tout cas, jusqu'à ce qu'on dise le contraire, les données ne sont pas à jour. Peut-être que Sly a un tuyau. Il faudra bien que la communauté francophone se paye un bon serveur pour héberger ce genre de service avec un mise à jour temps réel. Merci quand même pour ce bel outil. -- Vincent alias FrViPofm ___ 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] [ANNONCE] MapOSMatic : génér ation automatique de plans de ville à partir des donn ées OpenStreetMap
Bonjour, Le Tue, 29 Sep 2009 09:58:18 +0200, kimaidou kimai...@gmail.com a écrit : Pour les diffs, c'est peut-être pas la meilleure solution si vous décidez de mettre à jour une seule fois par jour toute la France. Nous avions évidemment pensé, mais plutôt que de mettre en place ce mécanisme pour la France, nous souhaitons plutôt passer à l'échelle mondiale pour que MapOSMatic supporte d'autres pays. Et autant pour la France seule un import complet régulier est envisageable, autant pour la planète, c'est plus difficile (4-5 jours pour l'importation complète sur notre serveur). Sinon pendant que j'y suis : Ce serait top de faire des cartes à fond blanc pour économiser de l'encre (je parle de la couleur de remplissage entre les rues). Le style Mapnik n'est pas très adapté à l'impression je trouve. Je sais qu'un demande a été faite pour pouvoir ajouter des styles via upload de fichiers xml, mais en attendant ce serait bon pour l'environnement de mettre de la couleur (et du gris) que lorsqu'il y en a besoin :). Excellente idée. Tu peux nous proposer une feuille de style Mapnik correspondante ? Bonne journée, Thomas -- Thomas Petazzoni http://thomas.enix.org Promouvoir et défendre le Logiciel Libre http://www.april.org Logiciels Libres à Toulouse http://www.toulibre.org signature.asc Description: PGP signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Re : Import Corine - Status
2009/9/29 Dominique Rousseau d...@lee-loo.net: De mémoire, je crois que les plus petits objets que CLC connait, c'est 5 ha Donc, a priori, tes (f)lacs de qq dizaines de metres ne devraient pas géner :) Au pire, tu feras un tour, plus tard, quand les polygones non importés seront mis à dispo, pour voir si il n'y avait pas qq choses dans Corine qui serait rentré en conflit avec. Tout dépend de la date de création et de leur taille effectivement : si ça a été créé avant jeudi soir dernier, alors ils ont pu entrer en conflit avec des polygones de CLC s'ils représentent plus de 2% de superposition et ont peut-être empêcher l'import automatique de ces polygones. Il faudra donc repasser à la fin de l'import avec osmose pour consolider le coin à la main. Pour les surfaces créés à partir de vendredi matin, il y a un risque qu'un polygone CLC se créer par dessus, donc ton étang ou lac risque de disparaître au rendu mais les données sont encore là. Il faudra juste modifier les polygones CLC pour tenir compte de ces étendues d'eau (soit en redécoupant, soit en créant une relation multipolygone). Mais surtout, il faut attendre que l'import soit terminé avant de modifier des polygones CLC ! En effet, de nombreux nodes sont réutilisés par plusieurs polygones CLCF et si vous en supprimez un, cela bloquera l'import lorsqu'on arrivera à la création des polygones voisins. L'import n'est pas un long fleuve tranquille... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] [ANNONCE] Blog de MapOSMatic
Bonjour, Le Thu, 10 Sep 2009 10:11:47 +0200, David MENTRE dmen...@linux-france.org a écrit : Un rendu de plan peut être demandé en ligne : http://maposmatic.org/ Depuis l'annonce de ce service, nous avons mis en place un blog sur http://news.maposmatic.org pour tenir au courant les personnes intéressées des nouveautés et problèmes que nous rencontrons. Le dernier article fait notamment le point sur le problème d'avoir une base de données de la planète entière mise à jour de façon régulière. Contributions et idées bienvenues sur le sujet, nous sommes un peu secs et ça nous empêche d'implémenter le support pour d'autres pays. Bonne journée, Thomas -- Thomas Petazzoni http://thomas.enix.org Promouvoir et défendre le Logiciel Libre http://www.april.org Logiciels Libres à Toulouse http://www.toulibre.org signature.asc Description: PGP signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Re : Re : Re : Import Corine - Status
Apparemment quelqu un s en est apercu l import a repris il y a 10 minutes :-) Et pour Pieren je sais pas mais j avoue que je passe souvent devant la courbe ( ca me fascine !!! ) Gosh :) A noter que ce sont les landuses qui prendront le plus de temps a etre importes :) Aussi, vis a vis, des petits lacs que quelqu'un a nomme. Si ces lacs sont pris dans un polygone Corine, le polygone Corine ne sera pas importe du fait de la méthode de double overlap que Sylvain a mis au point. Car un petit lac sera recouvert a 100% et donc invalidera le polygone Corine. Ce n'est pas bien grave. Il est toujours possible de réimporter manuellement le polygone :) Emilie LAffray signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : [Tag] Comment representer une statue ?
2009/9/29 THEVENON Julien Les tags disponibles : tourism=artwork + name=* + artwork_type=painting|mosaic|sculpture|mural... + artist_name=* + date=* historic=memorial Plutôt historic=statue que memorial si ça n'est pas un mémorial. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Re : Re : Re : Import Corine - Status
On mardi 29 septembre 2009, Emilie Laffray wrote: sont pris dans un polygone Corine, le polygone Corine ne sera pas importe du fait de la méthode de double overlap que Sylvain a mis au point. Que TU as mise au point. Car un petit lac sera recouvert a 100% et donc invalidera le polygone Corine. Je pense que ce qu'il a voulu dire, c'est qu'il a ajouté des lacs après la phase de calcul des superpositions. Je pense que ce n'est pas bien grave, surtout pour lac. Personne n'aura idée de supposer qu'un lac est sous une forêt ! Mais pour bien faire, si un polygone de type forêt, ou champ englobe les lacs, il faudrait les ajouter en rôle inner d'un multipolygon afin de bien préciser qu'il s'agit d'un trou dans la forêt/prairie/vignoble/... -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [ANNONCE] Blog de MapOSMatic
On mardi 29 septembre 2009, Thomas Petazzoni wrote: Bonjour, Le dernier article fait notamment le point sur le problème d'avoir une base de données de la planète entière mise à jour de façon régulière. Contributions et idées bienvenues sur le sujet, nous sommes un peu secs et ça nous empêche d'implémenter le support pour d'autres pays. Salut, Si mes devinettes sont bonnes, vous utilisez un serveur kimsuffi chez ovh, et à en voir vos résultats je dirais http://www.kimsufi.com/ le premier ? Bref, avec ça, je dirais que ça va être vraiment chaud de gérer osm worldwide (que ce soit l'import initial ou les diffs). Concernant l'optimisation d'osm2pgsql, je ne pense pas que cette voie soit bien terrible, certes ça profiterait à tout le monde, mais je doute que ce soit codé avec les pieds, donc je doute qu'il y est beaucoup à gagner. Idées en vrac (alternatives ou cumulables) : - se rabattre sur l'europe plutôt que la terre (j'utilise des hour diff qui prennent environ 5/8 minutes, mais mon serveur est plus costaud ) - ne pas tout importer (laisser de coté certains poi/way/polygone de moindre importance) - changer de serveur, et impérativement booster les accès disques qui sont ~90% résponsables du temps d'import (Penser au RAID 0, disques SSD, ou autres) PS1: deux serveurs est une mauvaise idée si vous pensez faire une base postgres d'un coté, et les imports diff de l'autre, vous serez limiter par le réseau, et c'est bien pire que les disques PS2: pas besoin de diff pour l'europe, vous utilisez ceux de la terre, et vous appliquez une bbox PS3:au fait, tant que l'import d'un diff est inférieur à 24h, où est le problème ? -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import Corine - Status
2009/9/29 Vincent Pottier vpott...@gmail.com Emilie Laffray a écrit : Bonjour, le but de cet email est de tenir au courant tout le monde sur le statuts de l'import Corine. Il y a de nombreuses étapes dans l'import et il est important que tout le monde sache a peu près ou l'on en est. Parallèlement, et accessoirement, ça commence à causer pour orchard (je suppose que Pieren a fait le mail qui va bien ;-). proposition : http://wiki.openstreetmap.org/wiki/Proposed_features/orchard discussion : http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/orchard À vous la parole. Bonjour micro, plus serieusement, j'ai corrige quelques fautes l'autre jour. Oui ca a du marcher puisque lulu-ann a participe :P Je ne vois pas quoi dire honnetement car je suis fondamentalement d'accord avec la proposition. Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import Corine - Status
2009/9/29 Emilie Laffray emilie.laff...@gmail.com: Est-ce que orchard est déjà rendu avec mapnik ? Il semblerait que oui si on lit ça: http://www.openstreetmap.org/user/wilpin/diary/8100 Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import Corine - Status
2009/9/29 Pieren pier...@gmail.com 2009/9/29 Emilie Laffray emilie.laff...@gmail.com: Est-ce que orchard est déjà rendu avec mapnik ? Il semblerait que oui si on lit ça: http://www.openstreetmap.org/user/wilpin/diary/8100 Oui en effet, j'ai regarde la carte. Landuse=orchard est rendu comme une ferme actuellement :) Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import Corine - Status
Pieren a écrit : 2009/9/29 Emilie Laffray emilie.laff...@gmail.com: Est-ce que orchard est déjà rendu avec mapnik ? Il semblerait que oui si on lit ça: http://www.openstreetmap.org/user/wilpin/diary/8100 Pieren Je ne crois pas. J'avais rentré une petite parcelle en orchard http://www.openstreetmap.org/?lat=47.217705lon=6.050527zoom=18layers=B000FTTT Rien n'apparaissait. (Je l'ai passé en landuse2, je viens de rétablir) Il n'y a qu'a suivre ça http://www.openstreetmap.org/browse/way/40026557 -- Vincent alias FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [ANNONCE] MapOSMatic : gén ération automatique de plans de ville à partir des données OpenStreetMap
Le problème avec le style Mapnik, c'est que les routes sont presques blanches par défault (#FEFEFE) alors qu'autour c'est du gris ( #F1EEE8) Donc si je fais un remplacement à la va vite du gris par du blanc pur ( #FF), on ne verra presque plus les routes :( Il faut que je fasse des tests en local, donc ca risque de prendre du temps... Mais je serai heureux d'apporter cette contribution à votre projet :D kimaidou Excellente idée. Tu peux nous proposer une feuille de style Mapnik correspondante ? Bonne journée, Thomas -- Thomas Petazzoni http://thomas.enix.org Promouvoir et défendre le Logiciel Libre http://www.april.org Logiciels Libres à Toulouse http://www.toulibre.org ___ 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] Import Corine - Status
Bonjour, Blocage au 2001e changeset ? (15h43) 2001 serait-il un nombre non compatible avec ce projet ? ;-) Amicalement _ Inédit ! Des Emoticônes Déjantées! Installez les dans votre Messenger ! http://www.ilovemessenger.fr/Emoticones/EmoticonesDejantees.aspx___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Re : Re : Re : Re : Re : Import Corine - Status
De : Emilie Laffray emilie.laff...@gmail.com Apparemment quelqu un s en est apercu l import a repris il y a 10 minutes :-) Et pour Pieren je sais pas mais j avoue que je passe souvent devant la courbe ( ca me fascine !!! ) Gosh :) A noter que ce sont les landuses qui prendront le plus de temps a etre importes :) Aussi, vis a vis, des petits lacs que quelqu'un a nomme. Si ces lacs sont pris dans un polygone Corine, le polygone Corine ne sera pas importe du fait de la méthode de double overlap que Sylvain a mis au point. Car un petit lac sera recouvert a 100% et donc invalidera le polygone Corine. Ce n'est pas bien grave. Il est toujours possible de réimporter manuellement le polygone :) L'import semble de nouveau bloque, je sais pas si c est une coincidence mais le dernier changeset etait exactement le 2000 eme ( on frole les 10%) Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] TopoSM
Bonjour, Pour ceux qui ne connaissent pas, voici un rendu avec relief du Massachusetts et du Colorado que je trouve très réussi: http://toposm.com/ma/ http://toposm.com/co/ Emmanuel. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Re : Import Corine - Status
De : Fabien Giraud ab_f...@hotmail.com Bonjour, Blocage au 2001e changeset ? (15h43) 2001 serait-il un nombre non compatible avec ce projet ? ;-) Amicalement C est reparti ! l ange gardien de Corine est super reactif :-) Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import Corine - Status
2009/9/29 Fabien Giraud ab_f...@hotmail.com: Bonjour, Blocage au 2001e changeset ? (15h43) 2001 serait-il un nombre non compatible avec ce projet ? ;-) Amicalement Encore une erreur http 500 venant du serveur. Il faut s'attendre à ce que l'import s'arrête de temps à autre, c'est normal et déjà signalé sur d'autres imports. Je ne souhaite pas faire de redémarrage automatique parce que je veux voir la cause de l'arrêt (le premier arrêt était dû à un problème dans notre fichier corine par exemple) et parce que je contrôle ensuite que la reprise se passe bien. Je jette un oeil aussi souvent que possible mais ne me demandez pas de dormir sur une chaise électrique pour m'empêcher de dormir la nuit ;-) Notez qu'on pourrait faire les 3x8 avec Sly et Emilie ;-) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] TopoSM
On mardi 29 septembre 2009, Emmanuel Pacaud wrote: Bonjour, Pour ceux qui ne connaissent pas, voici un rendu avec relief du Massachusetts et du Colorado que je trouve très réussi: http://toposm.com/ma/ http://toposm.com/co/ C'est en effet super chouette, mais pour chez nous ça va pas le faire : - il utilise des modèles de terrain hyper précis, mais uniquement dispo aux US - l'hydrographie a été elle aussi récupérée ailleurs Sinon le reste du rendu est plus sobre en effet que ce qu'on est habitué à voir sur osm.org avec des couleurs flashi http://wiki.openstreetmap.org/wiki/TopOSM -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Import Corine - Status
2009/9/29 THEVENON Julien julien_theve...@yahoo.fr C est reparti ! l ange gardien de Corine est super reactif :-) Faudra qu'on fasse un paquet cadeau a Pieren un de ces jours :) J'avoue que c'est impressionnant de voir la France se remplir petit a petit. Globalement, ça fonctionne vraiment très bien. Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import Corine - Status
On mardi 29 septembre 2009, Pieren wrote: Notez qu'on pourrait faire les 3x8 avec Sly et Emilie ;-) Heu, moi je préfère dormir la nuit si ça ne gêne personne ;-) Sinon, plutôt que de contrôler à la main régulièrement, je te conseil de lancer ta commande avec : $ python bulk_upload truc bidule ; echo prouf | mail -s planté again t...@email Bon, les fanas de l'import corine étant pendu à l'outil de progression, la liste va presque aussi vite, mais voilà juste une idée -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import Corine - Status
2009/9/29 Pieren pier...@gmail.com Je ne souhaite pas faire de redémarrage automatique parce que je veux voir la cause de l'arrêt (le premier arrêt était dû à un problème dans notre fichier corine par exemple) et parce que je contrôle ensuite que la reprise se passe bien. +1 Je jette un oeil aussi souvent que possible mais ne me demandez pas de dormir sur une chaise électrique pour m'empêcher de dormir la nuit ;-) Non pas une chaise électrique. Juste un mécanisme ou des que tu reçois un sms sur ton téléphone, ça envoie une impulsion électrique te réveillant. Bon tout compte fait, ne faisons pas un mécanisme comme ça, mes patrons pourraient ensuite l'adapter sur nos serveurs et être réveillée en plein milieu de la nuit brutalement même quand on est d'astreinte, ce n'est pas le top ;) Notez qu'on pourrait faire les 3x8 avec Sly et Emilie ;-) Euh oui, enfin j'accepte les tickets restaurants :P Mais oui pourquoi pas pour aider a relancer ça de temps en temps :) Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Re : Re : Import Corine - Status
De : Emilie Laffray emilie.laff...@gmail.com Faudra qu'on fasse un paquet cadeau a Pieren un de ces jours :) J'avoue que c'est impressionnant de voir la France se remplir petit a petit. Globalement, ça fonctionne vraiment très bien. C est clur ! tiens un truc qui aurait pu etre fun ( et chouette a montrer au SOTM 2010 ) c est une video montrant la progression de l import, comme cela a ete fait pour les communes si je me rappelle bien. Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Re : Import Corine - Status
De : Emilie Laffray emilie.laff...@gmail.com Je ne souhaite pas faire de redémarrage automatique parce que je veux voir la cause de l'arrêt (le premier arrêt était dû à un problème dans notre fichier corine par exemple) et parce que je contrôle ensuite que la reprise se passe bien. +1 mieux vaut un tout petit peu plus lentement mais surement Je jette un oeil aussi souvent que possible mais ne me demandez pas de dormir sur une chaise électrique pour m'empêcher de dormir la nuit ;-) En meme temps pour l instant il n y a pas eu tant d arrets que ca et ils se sont passes en journee donc croisons les doigts pour la suite Notez qu'on pourrait faire les 3x8 avec Sly et Emilie ;-) Fais gaffe tu risques d etre pris au mot lol !! hier j ai suivi jusqu a 3 heures et rien a signaler heureusement Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Re : Import Corine - Status
2009/9/29 THEVENON Julien julien_theve...@yahoo.fr *De :* Emilie Laffray emilie.laff...@gmail.com * * Faudra qu'on fasse un paquet cadeau a Pieren un de ces jours :) J'avoue que c'est impressionnant de voir la France se remplir petit a petit. Globalement, ça fonctionne vraiment très bien. C est clur ! tiens un truc qui aurait pu etre fun ( et chouette a montrer au SOTM 2010 ) c est une video montrant la progression de l import, comme cela a ete fait pour les communes si je me rappelle bien. On peut toujours faire la vidéo après coup. On a toujours l'histoire de l'import via l'utilisateur que l'on a crée pour l'occasion. Il faudrait juste voir comment on représente cela. Si on produit un historique de polygones avec un timestamp, ça devient facile d'essayer de faire une animation. Le plus dur est de montrer les zones qui se remplissent. Il faudrait voir pour un mecanisme a la ITO. Parlant de ITO a mon avis, la France va etre brillante les prochains rendus ;) Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [ANNONCE] Blog de MapOSMatic
Salut Sylvain, Le 29 septembre 2009 10:54, sly (sylvain letuffe) sylv...@letuffe.org a écrit : Si mes devinettes sont bonnes, vous utilisez un serveur kimsuffi chez ovh, et à en voir vos résultats je dirais http://www.kimsufi.com/ le premier ? Oui, Kimsufi XL de l'année dernière (3e modèle de l'ancienne gamme). Bref, avec ça, je dirais que ça va être vraiment chaud de gérer osm worldwide (que ce soit l'import initial ou les diffs). Pas cool ! :-( Idées en vrac (alternatives ou cumulables) : - se rabattre sur l'europe plutôt que la terre (j'utilise des hour diff qui prennent environ 5/8 minutes, mais mon serveur est plus costaud ) C'est le plan B. :-) - ne pas tout importer (laisser de coté certains poi/way/polygone de moindre importance) C'est une piste. Il faudrait qu'on détermine ce qui est utile pour Mapnik ou pas. Et est-ce qu'on y gagnerait vraiment ? - changer de serveur, et impérativement booster les accès disques qui sont ~90% résponsables du temps d'import (Penser au RAID 0, disques SSD, ou autres) Oui, apparemment, dixit mes condisciples, le CPU n'est pas très haut et ce sont les I/O qui galèrent. Donc, pour aller plus vite, il nous faudrait un serveur plus cher avec des disques qui poussent. :-( PS1: deux serveurs est une mauvaise idée si vous pensez faire une base postgres d'un coté, et les imports diff de l'autre, vous serez limiter par le réseau, et c'est bien pire que les disques En local chez OVH, on peut espérer avoir la patate, non ? Déjà, saturer du 100Mb/s au niveau applicatif... Mais perso, je ne suis pas fan des deux serveurs non plus. PS2: pas besoin de diff pour l'europe, vous utilisez ceux de la terre, et vous appliquez une bbox Ok. Pour la Bbox, il y en a de bien connues ? On prend le shapefile de l'Europe sur geofabrik ? PS3:au fait, tant que l'import d'un diff est inférieur à 24h, où est le problème ? Ben pour l'instant ça prend 9h et pendant ce temps la machine est inutilisable. Merci pour tes commentaires, Amicalement, d. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [ANNONCE] MapOSMatic : gén ération automatique de plans de ville à partir des données OpenStreetMap
En un mot: Bravo! Et en deux mots Bravo et Merci! Je trouve le rendu vraiment chouette. Comment fonctionne le mode de selection? Je n'arrive pas a faire un rendu de ma commune (Saint Sulpice La Foret 35 (il y en a plusieurs en france) J'obtiens Aucune limite administrative disponible pour cette ville. Essayez en corrigeant la casse (majuscule sur la première lettre) Et si je renseigne Saint Sulpice j'obtiens un rendu pour saint sulpice sur tarn qui ne m'interesse que très moyennement Cordialement, ulrich Le 10 septembre 2009 10:11, David MENTRE dmen...@linux-france.org a écrit : == Version courte == Nous avons le plaisir d'annoncer la sortie de MapOSMatic, un ensemble d'outils pour générer des plans de ville à partir de données OpenStreetMap. MapOSMatic se charge de créer une grille sur le plan, un index des rues avec des références à cette grille et une bordure grisée de la ville si ses limites administratives sont connues. Actuellement nous ne pouvons générer que les plans de villes en France métropolitaine mais nous l'étendrons à d'autres régions du monde. MapOSMatic est un Logiciel Libre, sous license AGPLv3. Un rendu de plan peut être demandé en ligne : http://maposmatic.org/ Exemple de plan généré : - plan : http://maposmatic.org/smedia/chavagne.png http://maposmatic.org/smedia/chavagne.pdf - index des rues : http://maposmatic.org/smedia/chavagne_index.png http://maposmatic.org/smedia/chavagne_index.pdf ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [ANNONCE] Blog de MapOSMatic
2009/9/29 David MENTRE dmen...@linux-france.org - changer de serveur, et impérativement booster les accès disques qui sont ~90% résponsables du temps d'import (Penser au RAID 0, disques SSD, ou autres) Oui, apparemment, dixit mes condisciples, le CPU n'est pas très haut et ce sont les I/O qui galèrent. Donc, pour aller plus vite, il nous faudrait un serveur plus cher avec des disques qui poussent. :-( Oui, c'est en effet le problème. Actuellement, je suis en train de voir a mon bureau pour reconfigurer nos serveurs pour augmenter l'IO de nos serveurs ainsi que la RAM. Pour l'utilisation que nous en faisons, le facteur limitant est l'accès disque. Pour l'extension de nos serveurs, les CPU ne seront pas aussi pousses mais la mémoire sera très fortement montée afin de permettre un cache plus efficace en mémoire (je fais du reverse geocoding, donc une bonne utilisation du cache mémoire augmente les performances sérieusement). La base de donnée sera sûrement montée sur un SAN avec de l'accès fibre optique. Question bête: lisez vous les fichiers directement en bz2 ou ont ils été décompressés? PS2: pas besoin de diff pour l'europe, vous utilisez ceux de la terre, et vous appliquez une bbox Ok. Pour la Bbox, il y en a de bien connues ? On prend le shapefile de l'Europe sur geofabrik ? Oui, enfin il vaut mieux prendre leur fichier .poly et faire la bbox soit même. Prendre le shapefile oblige a faire une conversion supplémentaire mais je pense que tu faisais référence plutôt au fichier osm. PS3:au fait, tant que l'import d'un diff est inférieur à 24h, où est le problème ? Ben pour l'instant ça prend 9h et pendant ce temps la machine est inutilisable. Hum et bien entendu on doit utiliser la fonction slim pour avoir accès aux diffs. Avez vous essayer de monter la valeur du cache mémoire? Je sais que sur mon portable ça a grandement amélioré les performances en passant de 800Mo a 1600Mo de mémoire vive. Ce n'était que sur la France mais ça peut être intéressant de voir cela. Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [ANNONCE] MapOSMatic : gén ération automatique de plans de ville à partir des données OpenStreetMap
Salut, Le 29 septembre 2009 16:41, ulrich rousseau ulrich.rouss...@gmail.com a écrit : En un mot: Bravo! Et en deux mots Bravo et Merci! Merci ! Je trouve le rendu vraiment chouette. C'est le rendu par défaut de Mapnik, on n'a rien touché ! :-) Comment fonctionne le mode de selection? Je n'arrive pas a faire un rendu de ma commune (Saint Sulpice La Foret 35 (il y en a plusieurs en france) J'obtiens Aucune limite administrative disponible pour cette ville. Essayez en corrigeant la casse (majuscule sur la première lettre) Et si je renseigne Saint Sulpice j'obtiens un rendu pour saint sulpice sur tarn qui ne m'interesse que très moyennement Il faut que tu utilises la slippy map (option Zone géographique) : - toutes les communes n'ont pas encore de limite administrative ; - en cas de doublons (commune avec le même nom), on prend toujours la première. Oui, je sais, c'est un bug. ;-) Amicalement, d. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [ANNONCE] Blog de MapOSMatic
On mardi 29 septembre 2009, David MENTRE wrote: Salut Sylvain, re, Oui, Kimsufi XL de l'année dernière (3e modèle de l'ancienne gamme). Ben, y'a déjà moyen de gagner en changeant de gamme - ne pas tout importer (laisser de coté certains poi/way/polygone de moindre importance) C'est une piste. Il faudrait qu'on détermine ce qui est utile pour Mapnik ou pas. Et est-ce qu'on y gagnerait vraiment ? J'en sais franchement rien car moi, je n'ai fais qu'ajouter des trucs à importer, et oui, ça me prend plus de temps (bien que je n'ai pas de chiffres à fournir) Donc, pour aller plus vite, il nous faudrait un serveur plus cher avec des disques qui poussent. :-( Les disques classiques, ça pousse toujours a peu prêt pareil (p'tet 30% qui se ballade) ce qu'il faut surtout c'est du RAID 0 ! (ou avec du fric, des SSD, j'ai vu une nouvelle offre chez OVH avec deux SSD de 80Go qu'on peut mettre en RAID0, ça, ça doit pousser au cul ) En local chez OVH, on peut espérer avoir la patate, non ? P'tit bonheur la chance... si c'est pas le même datacenter. Sur mon serveur et celui de pieren, on a des interfaces gigabit, ben ça sature à 100Mbit/s Déjà, saturer du 100Mb/s au niveau applicatif... Je n'en suis pas si sûr. Sachant que le process d'import initial et diff est limité par... les i/o, ça revient à dire que le goulot d'étrangement c'est les disques. Or, sur mon serveur le raid0 peut fournir du 180Mo/s en linéaire, si je convertis bien ça fait du 1.4Gb/s, tu vois tout de suite le problème du rapport 0.1 / 1.4 ! Quelques tests à l'instant avec iostat semblent indiquer que durant l'import d'un diff, le traffic lecture des disques semble de l'ordre de 3Mo/s (en écriture c'est que dalle car finalement il n'y a pas temps que ça à écrire dans un diff) ce qui indiquerait que la congestion vient non seulement des disques, mais en fait de leur temps d'accès. Ajouter par dessus ça une couche réseau ne peux qu'aggraver le phénomène. Bien qu'on puisse penser que ce soit faible devant les autres délais, mais pour quel gain finalement ? Ok. Pour la Bbox, il y en a de bien connues ? On prend le shapefile de l'Europe sur geofabrik ? Moi je fais ça avec l'europe de géofabrik et --bbox -27,31,50,72 (c'est taillé à la hâche, mais ça me va) PS3:au fait, tant que l'import d'un diff est inférieur à 24h, où est le problème ? Ben pour l'instant ça prend 9h et pendant ce temps la machine est inutilisable. Beuh ? ça c'est anormal. osm2pgsql utilise du transactionnel, durant tous ses petits calculs, la base reste accessible normalement (bien qu'un peu ralenti) donc vous avez surtout un problème à ce niveau. Une connexion à la main avec psql ça dit quoi ? -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [ANNONCE] Blog de MapOSMatic
On mardi 29 septembre 2009, Emilie Laffray wrote: 2009/9/29 David MENTRE dmen...@linux-france.org Oui, c'est en effet le problème. Actuellement, je suis en train de voir a mon bureau pour reconfigurer nos serveurs pour augmenter l'IO de nos serveurs ainsi que la RAM. Je serais très curieux de voir des benchs comparatifs entre une solution plus de RAM et une solution plus de disques (histoire de savoir où investir :-) ) Mais aussi, selon la taille du fichier osm. Je me doute bien que si toute la base postgis tient en RAM ça doit dépoter sévère. Question bête: lisez vous les fichiers directement en bz2 ou ont ils été décompressés? Moi bz2 toujours, c'est plus simple et... sisi, plus rapide ;-) Mon serveur a du cpu à revendre durant les imports, par contre, pas les io... -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Re : Import Corine - Status
Oh oui oui, il nous faudrait une vidéo comme celle de ITO 'a year of edits' =) J'aimerais vraiment savoir comment on fait un truc aussi zouli =) 2009/9/29 Emilie Laffray emilie.laff...@gmail.com 2009/9/29 THEVENON Julien julien_theve...@yahoo.fr *De :* Emilie Laffray emilie.laff...@gmail.com * * Faudra qu'on fasse un paquet cadeau a Pieren un de ces jours :) J'avoue que c'est impressionnant de voir la France se remplir petit a petit. Globalement, ça fonctionne vraiment très bien. C est clur ! tiens un truc qui aurait pu etre fun ( et chouette a montrer au SOTM 2010 ) c est une video montrant la progression de l import, comme cela a ete fait pour les communes si je me rappelle bien. On peut toujours faire la vidéo après coup. On a toujours l'histoire de l'import via l'utilisateur que l'on a crée pour l'occasion. Il faudrait juste voir comment on représente cela. Si on produit un historique de polygones avec un timestamp, ça devient facile d'essayer de faire une animation. Le plus dur est de montrer les zones qui se remplissent. Il faudrait voir pour un mecanisme a la ITO. Parlant de ITO a mon avis, la France va etre brillante les prochains rendus ;) Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Mon weblog - http://www.tenshu.fr/ Je soutiens le Logiciel Libre, j'adhère à l'APRIL ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [ANNONCE] Blog de MapOSMatic
2009/9/29 sly (sylvain letuffe) sylv...@letuffe.org Je serais très curieux de voir des benchs comparatifs entre une solution plus de RAM et une solution plus de disques (histoire de savoir où investir :-) ) Je ne peux pas vraiment fournir de benchs car on ne fait que de la lecture seule. Le load test tool que j'ai écrit il y a quelques temps montre que je n'arrive pas a maxer les serveurs postgresql a partir de ma machine :) Au final, ce que l'on voit, ce sont les temps de latence provenant du serveur. Il faut que je prenne le temps un jour de faire un beau test Jmeter afin de bien mettre en valeur l'augmentation de performances que l'on a eus. Il n'y a qu'un import tous les 2 mois. L'import et toutes les étapes prennent environ une semaine du fait du preprocess. Mais aussi, selon la taille du fichier osm. Je me doute bien que si toute la base postgis tient en RAM ça doit dépoter sévère. Oui mais pas forcement, ça dépend aussi de la géométrie que tu utilises et la manière dont tu utilises tes fonctions. Disons qu'une géométrie LINESTRING se cache très bien et pour l'utilisation que j'en fais c'est absolument génial. Les polygones sont aussi très efficaces a cacher surtout si tu as beaucoup de mémoire. Par contre, le problème et le point noir ce sont les points. C'est de loin le plus lent sur les requêtes que je fais (un ordre de magnitude plus lent). Je travaille sur le monde entier. Il y a bien sur des moyens de biaiser pour augmenter les performances selon ce que tu recherches. Les partitions tables sont une de ces solutions. Question bête: lisez vous les fichiers directement en bz2 ou ont ils été décompressés? Moi bz2 toujours, c'est plus simple et... sisi, plus rapide ;-) Mon serveur a du cpu à revendre durant les imports, par contre, pas les io... En effet, c'est mieux d'utiliser bz2. C'est beaucoup plus rapide et ça réduit sérieusement les IO. En moyenne, le ratio de compression est d'environ 20. Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [ANNONCE] Blog de MapOSMatic
On Tuesday 29 September 2009 16:24:38 David MENTRE wrote: Oui, apparemment, dixit mes condisciples, le CPU n'est pas très haut et ce sont les I/O qui galèrent. Un moyen simple de gagner en I/O sous linux (si ce n'est pas déjà fait) : noatime: pas de mise à jour de l'heure d'accès lors des lectures. Le gain peut être énorme. data=writeback: pas de journal. On peut gagner un peu en perf par contre on perd en sécurité. À faire sur une partition dédié à la base de donnés. -- Vincent Meurisse ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] convertir image cadastre en géotif f
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pour informations : Pour informations voici les données : br.png est l'image cadastre issue de la commande : ./cadastre_client.py 729...@172756 735...@177400 3200 BROUZET LES QUISSAC 30 br.png br.png.aux.xml est automatiquement généré par la commande précédente br.tiff est la conversion que j'ai essayée avec : gdal_translate br.png br.tif (en supposant que le fichier br.png.aux.xml est automatiquement pris en compte) GPSDATA-20081003.gpx est une trace gps avec implantation de points lumineux issue de mes relevés. Si on importe le .gpx et le .tif cela ne colle pas du tout. Les fichiers sont là : http://people.ubuntu.com/~vetsel-patrice/qgis/ kagou a écrit : Bonsoir, j'ai utilisé l'archive cadastre_tools sur le wiki d'OSML afin de récupérer un .png d'une commune. Associée à cette image il y a un fichier .aux.xml qui semble être un fichier d'informations permettant de référencer le .png. Mon problème est que je n'arrive pas à importer une couche raster avec ces 2 fichiers sous QGis 1.3 Je pense (mais je peux me tromper) qu'une conversion en Géotiff pourrait être la solution (le Géotiff semblant pas mal supporté par les divers logiciels, enfin je crois...). Mon problème comment faire ? (je m'en sorts pas avec gdal_translate) Merci ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr - -- Patrice Vetsel ubu...@kagou.fr Aka/Alias Kagou https://launchpad.net/people/vetsel-patrice gpg key: 0x15c094db -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrCL/YACgkQAGLykBXAlNvSJgCfb2alZiNyoKu+FmzU52QQkaaW OkAAnjOXYFhrii0b0Qff10Y5SQJvHfq9 =vK5n -END PGP SIGNATURE- ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Statistiques sur les changesets created_by=* et JOSM
Pour les fans de statistiques, TomH a fourni à Ævar Arnfjörð Bjarmason une liste des tags created_by les plus utilisés dans les changesets (et presque supérieurs à 1000): 813222 = JOSM, 730972 = Potlatch, 96066 = Merkaartor, 40213 = bulk_upload.py, 34625 = upload.py, 17443 = KMLManager, 7995 = FreieTonne, 4620 = osmtools, 3779 = OTHERS, 1271 = mat's little ruby script, 898= osm2go, Si on regarde la langue sélectionnée dans JOSM : 357350 = de, 165641 = en, 57463 = fr, 40643 = en_GB, 30081 = ru, 23435 = it, 11881 = fi, 11470 = es, 8578 = cs, 6582 = nl, 6029 = sv, 5619 = pl, 5357 = ja, 2939 = da, 2062 = sk, 911= nb, 892= bg, 514= tr, 502= et, 499= is, 305= sl, 284= pt, 255= ro, 133= he, 102= gl, 72 = el, 36 = zh, On voit que la France n'est pas si mal placée. 1. select count(*),v from changeset_tags where k='created_by' group by v order by count desc; 2. http://u.nix.is/~avar/created_by.txt 3. http://u.nix.is/~avar/created_by.pl Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Statistiques sur les changesets created_by=* et JOSM
On Tue, 2009-09-29 at 19:31 +0200, Pieren wrote: On voit que la France n'est pas si mal placée. Ne veux-tu pas plutôt dire la francophonie? :) Pierre-Luc Un néocartographe du Québec signature.asc Description: This is a digitally signed message part ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Re : Import Corine - Status
De : Pieren pier...@gmail.com Encore une erreur http 500 venant du serveur. Il faut s'attendre à ce que l'import s'arrête de temps à autre, c'est normal et déjà signalé sur d'autres imports. Je ne souhaite pas faire de redémarrage automatique parce que je veux voir la cause de l'arrêt (le premier arrêt était dû à un problème dans notre fichier corine par exemple) et parce que je contrôle ensuite que la reprise se passe bien. Je jette un oeil aussi souvent que possible mais ne me demandez pas de dormir sur une chaise électrique pour m'empêcher de dormir la nuit ;-) Notez qu'on pourrait faire les 3x8 avec Sly et Emilie ;-) On dirait qu il y a un autre arret. le change 2681146 reste marque en cours de modification alors qu il parait complet. En meme temps la page sur le script de suivi d import http://osmose.openstreetmap.fr/map/cgi-bin/clc.py ne repondait plus non plus ( Intenal server error ) Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Import Corine - Status
THEVENON Julien wrote: On dirait qu il y a un autre arret. le change 2681146 reste marque en cours de modification alors qu il parait complet. En meme temps la page sur le script de suivi d import http://osmose.openstreetmap.fr/map/cgi-bin/clc.py ne repondait plus non plus ( Intenal server error ) L'arrêt a été remarqué et c'est reparti. Il semblerait que le script de Étienne soit sensible aux erreurs 500 du site. Emilie Laffray signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Statistiques sur les donnees Corine
Bonsoir, je compte produire quelques statistiques une fois que Corine sera importée. Pour le moment, je compte produire principalement une statistique car elle me tient a cœur: - Nombre et noms des polygones landuse residentials qui n'ont pas de villes proches d'elles. Le but de la manœuvre est bien entendu d'essayer de nommer tous les landuse residentials pour avoir une liste complète de tous les villages ou villes de plus de 25ha. Si vous avez d'autres idées de statistiques, n'hésitez pas a me demander. Parmi les choses aussi auxquelles je réfléchis depuis quelques temps, il y a une sorte de baromètre pour savoir si une zone de France est bien définie ou pas. Ce n'est pas quelque chose de simple a faire. J'en suis bien consciente. L'algorithme que je vais proposer est une idée de base. Je la soumets a tout le monde pour voir si les gens trouvent un défaut a mon raisonnement ou pas. La première étape est d'importer tous les polygones de départements, et de communes (je parle de communes et non pas de villes, c'est important). Les communes sont celles que Sylvain génère avec une grande précision sur son site. Une fois que j'ai toutes les communes importées, je compte entrer dans la base de donnée la population de cette commune. L'étape suivante est de calculer le nombre de highways dans une commune et de le comparer a un nombre idéal. Ce nombre idéal serait base sur la population, la surface de la commune. Ce chiffre sera bien évidemment déduit de manière heuristique a partir de quelques villes a peu près complètes. Je suis consciente que la densité varie et que les structures des villes changent selon les régions et l'age de la ville (j'ai encore des restes d'urbanisme). Il est évident que des villes qui s'étendent sur une rue principalement auront tendance a être marquées alors que ça ne devrait pas être le cas, etc... etc Après, il suffit juste de créer un simple calcul pour savoir quelle zone manque de highway ou pas. L'explication est simplistique pour le moment. Mais l'algorithme de base tiendrait compte de la taille du landuse residential de la ville (je peux facilement découper un landuse qui s'étend sur plusieurs villes via la base de donnée). J'ai une idée bien plus précise pour calculer tout ça, mais je veux juste soumettre l'idée de base. Toutes les idées sont bien sures (C) :P Emilie Laffray signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Statistiques sur les donnees Corine
Emilie Laffray a écrit : Parmi les choses aussi auxquelles je réfléchis depuis quelques temps, il y a une sorte de baromètre pour savoir si une zone de France est bien définie ou pas. Ce n'est pas quelque chose de simple a faire. J'en suis bien consciente. L'algorithme que je vais proposer est une idée de base. Je la soumets a tout le monde pour voir si les gens trouvent un défaut a mon raisonnement ou pas. En avant pour la tambouille ;o) La première étape est d'importer tous les polygones de départements, et de communes (je parle de communes et non pas de villes, c'est important). Les communes sont celles que Sylvain génère avec une grande précision sur son site. Une fois que j'ai toutes les communes importées, je compte entrer dans la base de donnée la population de cette commune. L'étape suivante est de calculer le nombre de highways dans une commune et de le comparer a un nombre idéal. Ce nombre idéal serait base sur la population, la surface de la commune. Ce chiffre sera bien évidemment déduit de manière heuristique a partir de quelques villes a peu près complètes. Je suis consciente que la densité varie et que les structures des villes changent selon les régions et l'age de la ville (j'ai encore des restes d'urbanisme). Il est évident que des villes qui s'étendent sur une rue principalement auront tendance a être marquées alors que ça ne devrait pas être le cas, etc... etc Quelques propositions d'ingrédients : - plutôt que le nombre de ways, considérer la longueur cumulée des ways, ce qui rend moins dépendant des styles de saisie, qui peuvent varier d'un mapper à l'autre, - pondérer le nombre idéal en fonction de la longueur x l'importance (primary, secondary, unclassified...) du réseau existant. Je pars du postulat que le réseau principal est à peu près là partout (Nationales et Départementales), même si les contre-exemples ne manqueront pas, - exclure du calcul le réseau autoroutier, qui bien souvent traversera une commune sans la desservir Après, il suffit juste de créer un simple calcul pour savoir quelle zone manque de highway ou pas. Et tout ça combiné à la population (comment vas-tu l'obtenir ?) et la surface landuse=residential, pour une belle formule qui vaut ce qu'elle vaut comme tu l'évoques, mais qui permettrait à coup sûr de faire ressortir des disparités. Je sais déjà de quelle couleur ressortirait mon patelin ;o(( A suivre, et bonne soirée, vincent (vdct) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Statistiques sur les donnees Corine
Vincent de Chateau-Thierry wrote: Quelques propositions d'ingrédients : - plutôt que le nombre de ways, considérer la longueur cumulée des ways, ce qui rend moins dépendant des styles de saisie, qui peuvent varier d'un mapper à l'autre, Je te rassure, c'est ce que j'avais en tête. La raison principale pour ne pas l'avoir mentionne était d'éviter de compliquer encore plus la proposition :) - pondérer le nombre idéal en fonction de la longueur x l'importance (primary, secondary, unclassified...) du réseau existant. Je pars du postulat que le réseau principal est à peu près là partout (Nationales et Départementales), même si les contre-exemples ne manqueront pas, Hum, je n'avais pas vu ça sous cet angle. Je pensais faire quelque chose de très générique initialement pour justement éviter des complications. Je ne suis pas sure qu'on gagne a complexifier le modèle des le début. Il faut déjà voir les résultats qu'on obtient avec un algorithme simple. - exclure du calcul le réseau autoroutier, qui bien souvent traversera une commune sans la desservir Ça, c'est une très bonne idée. Je pense même qu'exclure la surface du réseau autoroutier de la surface globale peut être intéressant. De la même façon, je pense qu'on peut étendre cela aux routes de type trunks. Ca devrait fournir une bien meilleure approximation. Et tout ça combiné à la population (comment vas-tu l'obtenir ?) Source INSEE. J'avais pose la question il y a maintenant quelques mois parce que l'idée me trottait déjà dans la tête :) Mais bon il y avait Corine et certaines taches a mon travail a finir avant de jouer avec d'autres choses. et la surface landuse=residential, pour une belle formule qui vaut ce qu'elle vaut comme tu l'évoques, mais qui permettrait à coup sûr de faire ressortir des disparités. Je sais déjà de quelle couleur ressortirait mon patelin ;o(( Je pense qu'avec Corine on aura une bonne idée de base des landuse residential bientôt :) L'autre partie de l'histoire sur les landuse residential, je suis en train de bidouiller un truc. Peut être que ça marchera. Peut être pas :) Trop tot pour annoncer quoique ce soit. Je sais que la mentalité est plutot de publier souvent, mais j'avoue que je n'aime pas publier avant que le projet soit utilisable. Enfin bon, ne vous inquiétez pas si vous voyez débarquer d'autres brain dumps dans les semaines qui suivent. En tout cas, merci beaucoup pour les commentaires constructifs. Emilie Laffray signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Statistiques sur les donnees Corine
Vincent Pottier wrote: Merci pour ton commentaire fort utile :) Emilie Laffray signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] [Import] panne sur changeset 2682185
[Import] panne sur changeset 2682185 (en cours de modification) ... Le précédent (2682177) à 21:32:04:GMT ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Statistiques sur les donnees Corine
Bonsoir, Je suis nouveau sur la talk-fr donc je me présente : Bastien Jacquet, 24ans, Fontainebleau/Paris/Palaiseau cyclo-randonneur à mes heures et bien décidé à contribuer à Openstreetmap. Je pense que ton idée est géniale peut-etre peut-on meme restreindre aux highways en zone Corine résidentielles. Cela nous donnerait le nombre d'habitant par metre linéaire de trotoire (il y a un facteur 2 qui traîne ...), et cela doit être assez revélateur. Peut etre faudra-il rajouter des astuces du style plus la population est grande = plus il y a de chance qu'il y ait des immeubles donc 1hab/m est bizarre en campagne mais pas forcément en agglomération dense Bastien Jacquet ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Statistiques sur les donnees Corine
Emilie Laffray a écrit : Vincent de Chateau-Thierry wrote: - pondérer le nombre idéal en fonction de la longueur x l'importance (primary, secondary, unclassified...) du réseau existant. Je pars du postulat que le réseau principal est à peu près là partout (Nationales et Départementales), même si les contre-exemples ne manqueront pas, Hum, je n'avais pas vu ça sous cet angle. Je pensais faire quelque chose de très générique initialement pour justement éviter des complications. Je ne suis pas sure qu'on gagne a complexifier le modèle des le début. Il faut déjà voir les résultats qu'on obtient avec un algorithme simple. Pour le dire autrement, l'idée est que la présence d'un réseau type RN ou RD entraîne forcément (guillemets de rigueur) la présence d'un réseau de desserte qui vient se brancher dessus, d'où pour des communes pour l'instant uniquement couvertes par un axe important / de transit [1], le besoin de les faire ressortir dans les stats comme manquant sûrement de réseau local. ...et bonne soirée vincent [1] par ex. Soullans (85) http://osm.org/go/eqzIfIEk-- ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Statistiques sur les donnees Corine
Bastien Jacquet wrote: Bonsoir, Je suis nouveau sur la talk-fr donc je me présente : Bastien Jacquet, 24ans, Fontainebleau/Paris/Palaiseau cyclo-randonneur à mes heures et bien décidé à contribuer à Openstreetmap. Je pense que ton idée est géniale peut-etre peut-on meme restreindre aux highways en zone Corine résidentielles. Cela nous donnerait le nombre d'habitant par metre linéaire de trotoire (il y a un facteur 2 qui traîne ...), et cela doit être assez revélateur. Peut etre faudra-il rajouter des astuces du style plus la population est grande = plus il y a de chance qu'il y ait des immeubles donc 1hab/m est bizarre en campagne mais pas forcément en agglomération dense J'ai une approche légèrement différente: Tu as la réponse implicite, car on a la population et la surface. On a donc une densité de base. De plus, l'algorithme est basé sur une commune. Je pars du postulat qu'une ville avec une population très importante aura tout sa surface pleine. Il y a donc un moment ou le nombre de routes/rue n'augmente plus proportionnellement avec la densité de population. J'avais fait quelques études il y a quelques temps et il y a clairement une sorte d'asymptote a partir d'une certaine densité. Le problème c'est vraiment les moyennes villes, car il faut trouver cette densité ou d'un seul coup le nombre de rues n'augmente plus. En plus, après si on veut vraiment être puriste, il faut tenir compte du relief qui a des effets très amusants sur la densité, et sur la surface. L'idée du nombre d'habitant par mètre linéaire de trottoir est toutefois une alternative intéressante. Je pense que l'on pourra calculer ça après coup une fois que l'on aura des villes complètes. En fait, plus j'y pense plus je me rends compte que la valeur a laquelle je pense est en fait le nombre d'habitant par mètre linéaire de trottoir corrige par une courbe de distribution de la densité (ou du moins une mesure de ce genre). Merci beaucoup pour ton apport sur le sujet. Emilie Laffray signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Statistiques sur les donnees Corine
Le Tue 29 Sep 2009 à 22:48 +0100, Emilie Laffray a ecrit : Vincent de Chateau-Thierry wrote: - pondérer le nombre idéal en fonction de la longueur x l'importance (primary, secondary, unclassified...) du réseau existant. Je pars du postulat que le réseau principal est à peu près là partout (Nationales et Départementales), même si les contre-exemples ne manqueront pas, Hum, je n'avais pas vu ça sous cet angle. Je pensais faire quelque chose de très générique initialement pour justement éviter des complications. Je ne suis pas sure qu'on gagne a complexifier le modèle des le début. Il faut déjà voir les résultats qu'on obtient avec un algorithme simple. Je suis assez d'accord avec VdCT. Un pronostic au doigt mouillé : si tu effectues ton calcul 2 fois, la première avec uniquement les routes primary et la 2e avec uniquement les tertiary, tu risques d'avoir un classement des scores assez différents. En gros, un coin peut très bien être bien couvert en primary, si ça a été fait par un touriste qui passait par là, alors que pour couvrir en tertiary, il faut souvent un autotochtone ;-) Ça généralise la suggestion suivante (exclure les autoroutes) : - exclure du calcul le réseau autoroutier, qui bien souvent traversera une commune sans la desservir Une autre idée, plus basique : prendre en compte la proportion des routes qui ont un nom (pour les rues) ou une ref. Ça permet de différencier les saisies détaillées des autres. Bon, ça fait beacoup de pistes pour ton indicateur... j'espère que tu arriveras à en sortir quelque chose d'intéressant. -- ° /\Guillaume AllègreMembre de l'April /~~\/\ allegre.guilla...@free.fr Promouvoir et défendre le logiciel libre / /~~\tél. 04.76.63.26.99 http://www.april.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Statistiques sur les donnees Corine
Vincent de Chateau-Thierry wrote: Pour le dire autrement, l'idée est que la présence d'un réseau type RN ou RD entraîne forcément (guillemets de rigueur) la présence d'un réseau de desserte qui vient se brancher dessus, d'où pour des communes pour l'instant uniquement couvertes par un axe important / de transit [1], le besoin de les faire ressortir dans les stats comme manquant sûrement de réseau local. Hum, je ne suis toujours pas convaincue. J'ai l'exemple un peu inverse de ma ville natale, ou l'axe principale est la rue ou mes parents habitent. C'est une départementale assez grosse qui mène a une desserte de l'agglomération Orleanaise, mais on ne peut pas se servir de sa surface pour faire ressortir cela dans les statistiques. La desserte pour l'agglomération Orleanaise est elle classée en trunk. Je pense que ton argument fonctionne plus sur les petites villes. ...et bonne soirée vincent [1] par ex. Soullans (85) http://osm.org/go/eqzIfIEk-- Je ne suis pas sure de voir grand chose sur ton exemple. Il y a trop peu de chose et c'est un axe secondaire. Ceux ci ont tendance a avoir pas mal de maisons dessus. Emilie Laffray signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Statistiques sur les donnees Corine
Guillaume Allegre wrote: Je suis assez d'accord avec VdCT. Un pronostic au doigt mouillé : si tu effectues ton calcul 2 fois, la première avec uniquement les routes primary et la 2e avec uniquement les tertiary, tu risques d'avoir un classement des scores assez différents. En gros, un coin peut très bien être bien couvert en primary, si ça a été fait par un touriste qui passait par là, alors que pour couvrir en tertiary, il faut souvent un autotochtone ;-) Oui, mais l'idée est d'avoir un indice global initial. Je comptais prendre toutes les routes sauf autoroute et trunks selon sa suggestion. Je ne cherche pas a obtenir un ratio en séparant primaire, secondaire etc... C'est d'autant plus dangereux a mes yeux que leurs définitions en milieu urbain changent un peu par rapport au milieu rural. Je réalise maintenant que l'idée de base qui trottait dans ma tête doit être séparée en deux concepts: - Au niveau de la commune, c'est a dire toutes les rues/routes. Le cote urbain / rural est corrige en partie par la densité de population. - Au niveau du landuse, c'est a dire des routes en milieu forcement urbain. Une autre idée, plus basique : prendre en compte la proportion des routes qui ont un nom (pour les rues) ou une ref. Ça permet de différencier les saisies détaillées des autres. Je pense que ça sera un autre ratio. Il faut bien séparer toutes les idées et les mettre dans des containers différents. Je pense qu'a trop vouloir couvrir tout, on arrive a un nombre qui ne veut rien dire, d'où ma clarification plus haut. Toutefois, tu as raison de penser que c'est base sur la même chose. Il faudra juste changer le calcul de la distance pour avoir une valeur différente. Bon, ça fait beacoup de pistes pour ton indicateur... j'espère que tu arriveras à en sortir quelque chose d'intéressant. La mailing list sera la première informée si j'obtiens quelque chose d'intéressant ;) Emilie Laffray signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Ligne de crete
Le Tue 22 Sep 2009 à 22:58 +0200, Guillaume Allegre a ecrit : Je pense serieusement faire une proposition pour deux nouveaux tags, natural=ridge, et son pendant natural=thalweg. Ce serait ma premiere proposition, aussi je suis preneur de tous les avis, a la fois sur le fond et sur la formulation. Par contre, j'ai cherché sur le wiki, et je n'ai pas trouvé de procédure explicite pour une proposition (RFC). Je suppose pourtant que ça existe. Alors si quelqu'un peut me diriger vers une référence, il est le bienvenu. Merci d'avance. -- ° /\Guillaume AllègreMembre de l'April /~~\/\ allegre.guilla...@free.fr Promouvoir et défendre le logiciel libre / /~~\tél. 04.76.63.26.99 http://www.april.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Re : [Import] panne sur changeset 2682185
De : Vincent Pottier vpott...@gmail.com [Import] panne sur changeset 2682185 (en cours de modification) ... Le précédent (2682177) à 21:32:04:GMT ça a deja ete relance apparemment ;-) c est moi ou le site d OSM a du mal ce soir ? Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Statistiques sur les donnees Corine
Vincent de Chateau-Thierry a écrit : Emilie Laffray a écrit : Parmi les choses aussi auxquelles je réfléchis depuis quelques temps, il y a une sorte de baromètre pour savoir si une zone de France est bien définie ou pas. Ce n'est pas quelque chose de simple a faire. J'en suis bien consciente. L'algorithme que je vais proposer est une idée de base. Je la soumets a tout le monde pour voir si les gens trouvent un défaut a mon raisonnement ou pas. En avant pour la tambouille ;o) Où l'on voit qu'une base qui approche l'exhaustivité suscite l'imagination ;-) Quelques propositions d'ingrédients : - plutôt que le nombre de ways, considérer la longueur cumulée des ways, ce qui rend moins dépendant des styles de saisie, qui peuvent varier d'un mapper à l'autre, +1 j'ai coupé beaucoup de rues pour les trajets de bus, les bandes cyclables. Ce nombre idéal serait base sur la population, la surface de la commune. Peut-être qu'un ratio surface residential/surface commune ou nombre de residential/commune permettrait d'apprécier la dispersion de l'habitat donc le besoin en highway. Un village-clairière n'a pas les mêmes besoins qu'un groupe de hameaux bressans. Il y a même peut-être la population à faire intervenir pour deviner l'habitat dispersé (hors 25 ha). Peut-être qu'une typologie, ou un coefficient de dispersion de l'habitat... n personnes ont besoin de n*(n-1)/2 chemins + 1 unclassified pour le reste du monde n hameaux ont besoin de n*(n-1)/2 unclassified (ou residential) + 1 residential pour le reste du monde n villages ont besoin de n*(n-1)/2 tertiary + 1 secondary... n bourgs... ... Un habitat dispersé aura un residential faible par unité de population (25 ha). Il aura besoin de nombreux unclassified. Un habitat éclaté aura un nombre important de landuse=residential. Il aura besoin nombreux tertiary. Un habitat groupé aura 1 residential important. il aura besoin de nombreus highway=residential Ceci dit je n'ai jamais étudié l'urbanisme (peut-être un peu le ruralisme ;-) ni même les équations barbares ou les séries de Fourier, donc je n'ai aucune idée de la pertinence de mon propos. Si toutefois ça peut donner à penser (comme disait un de mes profs). Mais j'apprécie un beau graphe bien signifiant. A suivre, et bonne soirée, vincent (vdct) La première phase, c'est peut-être de calculer simplement les communes (et les residentials Corine) sans highway. Je suis sur qu'il y en a un paquet ! -- Vincent alias FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Re : Ligne de crete
De : Guillaume Allegre allegre.guilla...@free.fr Le Tue 22 Sep 2009 à 22:58 +0200, Guillaume Allegre a ecrit : Je pense serieusement faire une proposition pour deux nouveaux tags, natural=ridge, et son pendant natural=thalweg. Ce serait ma premiere proposition, aussi je suis preneur de tous les avis, a la fois sur le fond et sur la formulation. Par contre, j'ai cherché sur le wiki, et je n'ai pas trouvé de procédure explicite pour une proposition (RFC). Je suppose pourtant que ça existe. Alors si quelqu'un peut me diriger vers une référence, il est le bienvenu. J avais pose la question il y a quelques temps par rapport a la maniere de tagguer les casinos : http://openstreetmap.fr/forum#nabble-td3239188 Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Statistiques sur les donnees Corine
Le Tue 29 Sep 2009 à 23:26 +0100, Emilie Laffray a ecrit : Guillaume Allegre wrote: Je suis assez d'accord avec VdCT. Un pronostic au doigt mouillé : si tu effectues ton calcul 2 fois, la première avec uniquement les routes primary et la 2e avec uniquement les tertiary, tu risques d'avoir un classement des scores assez différents. Oui, mais l'idée est d'avoir un indice global initial. Je comptais prendre toutes les routes sauf autoroute et trunks selon sa suggestion. Je ne cherche pas a obtenir un ratio en séparant primaire, secondaire etc... C'est d'autant plus dangereux a mes yeux que leurs définitions en milieu urbain changent un peu par rapport au milieu rural. Certes. Alors je vais présenter mon idée autrement. Si tu le veux bien, essaie quand même de faire le calcul de l'indicateur sans présupposé, selon 3 modalités (par exemple) : - tous types de routes confondus, comme tu le pensais - uniquement les primary - uniquement les tertiary Et de regarder ensuite s'il y en a un qui colle mieux avec l'idée intuitive que tu te fais de la zone, à l'oeil. Parce qu'on peut peut-être obtenir des résultats auxquels on ne pense pas a priori, et probablement différents selon le type de zone (centre ville, banlieue, zones rurales...) C'est un peu l'idée de faire apparaître les variables cachées, même si on est encore loin de la formalisation mathématique rigoureuse. Je réalise maintenant que l'idée de base qui trottait dans ma tête doit être séparée en deux concepts: - Au niveau de la commune, c'est a dire toutes les rues/routes. Le cote urbain / rural est corrige en partie par la densité de population. - Au niveau du landuse, c'est a dire des routes en milieu forcement urbain. Effectivement, c'est plus clair comme ça. Une autre idée, plus basique : prendre en compte la proportion des routes qui ont un nom (pour les rues) ou une ref. Ça permet de différencier les saisies détaillées des autres. Je pense que ça sera un autre ratio. Il faut bien séparer toutes les idées et les mettre dans des containers différents. Je pense qu'a trop vouloir couvrir tout, on arrive a un nombre qui ne veut rien dire, d'où ma clarification plus haut. 100% d'accord. -- ° /\Guillaume AllègreMembre de l'April /~~\/\ allegre.guilla...@free.fr Promouvoir et défendre le logiciel libre / /~~\tél. 04.76.63.26.99 http://www.april.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Statistiques sur les donnees Corine
Vincent Pottier a écrit : Vincent de Chateau-Thierry a écrit : Emilie Laffray a écrit : Parmi les choses aussi auxquelles je réfléchis depuis quelques temps, il y a une sorte de baromètre pour savoir si une zone de France est bien définie ou pas. Ce n'est pas quelque chose de simple a faire. J'en suis bien consciente. L'algorithme que je vais proposer est une idée de base. Je la soumets a tout le monde pour voir si les gens trouvent un défaut a mon raisonnement ou pas. En avant pour la tambouille ;o) Où l'on voit qu'une base qui approche l'exhaustivité suscite l'imagination ;-) Quelques propositions d'ingrédients : - plutôt que le nombre de ways, considérer la longueur cumulée des ways, ce qui rend moins dépendant des styles de saisie, qui peuvent varier d'un mapper à l'autre, +1 j'ai coupé beaucoup de rues pour les trajets de bus, les bandes cyclables. Ce nombre idéal serait base sur la population, la surface de la commune. Peut-être qu'un ratio surface residential/surface commune ou nombre de residential/commune permettrait d'apprécier la dispersion de l'habitat donc le besoin en highway. Un village-clairière n'a pas les mêmes besoins qu'un groupe de hameaux bressans. Il y a même peut-être la population à faire intervenir pour deviner l'habitat dispersé (hors 25 ha). Peut-être qu'une typologie, ou un coefficient de dispersion de l'habitat... n personnes ont besoin de n*(n-1)/2 chemins + 1 unclassified pour le reste du monde n hameaux ont besoin de n*(n-1)/2 unclassified (ou residential) + 1 residential pour le reste du monde n villages ont besoin de n*(n-1)/2 tertiary + 1 secondary... n bourgs... ... Un habitat dispersé aura un residential faible par unité de population (25 ha). Il aura besoin de nombreux unclassified. Un habitat éclaté aura un nombre important de landuse=residential. Il aura besoin nombreux tertiary. Un habitat groupé aura 1 residential important. il aura besoin de nombreus highway=residential Ceci dit je n'ai jamais étudié l'urbanisme (peut-être un peu le ruralisme ;-) ni même les équations barbares ou les séries de Fourier, donc je n'ai aucune idée de la pertinence de mon propos. Si toutefois ça peut donner à penser (comme disait un de mes profs). Mais j'apprécie un beau graphe bien signifiant. A suivre, et bonne soirée, vincent (vdct) La première phase, c'est peut-être de calculer simplement les communes (et les residentials Corine) sans highway. Je suis sur qu'il y en a un paquet ! Par exemple : http://osm.org/go/0BMSBxt-- Qui vient d'être importé. -- Vincent alias FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Statistiques sur les donnees Corine
Vincent Pottier wrote: Quelques propositions d'ingrédients : - plutôt que le nombre de ways, considérer la longueur cumulée des ways, ce qui rend moins dépendant des styles de saisie, qui peuvent varier d'un mapper à l'autre, +1 j'ai coupé beaucoup de rues pour les trajets de bus, les bandes cyclables. Vi, je pensais a cela. Je renvoie a un de mes mails précédents sur pourquoi ça n'a pas été cité :) Ce nombre idéal serait base sur la population, la surface de la commune. Peut-être qu'un ratio surface residential/surface commune ou nombre de residential/commune permettrait d'apprécier la dispersion de l'habitat donc le besoin en highway. Un village-clairière n'a pas les mêmes besoins qu'un groupe de hameaux bressans. Il y a même peut-être la population à faire intervenir pour deviner l'habitat dispersé (hors 25 ha). Oui population, densite, surface. Ca me parait les chiffres les plus simples que l'on puisse initialement utilisees. Peut-être qu'une typologie, ou un coefficient de dispersion de l'habitat... n personnes ont besoin de n*(n-1)/2 chemins + 1 unclassified pour le reste du monde n hameaux ont besoin de n*(n-1)/2 unclassified (ou residential) + 1 residential pour le reste du monde n villages ont besoin de n*(n-1)/2 tertiary + 1 secondary... n bourgs... ... Je ne suis pas sure qu'il existe des formules magiques de ce genre. Je prefere ne pas toucher aux classifications rues/routes en elles memes, car l'interpretation est parfois floue selon les personnes. Les tags motorways ou trunks eux pretent nettement moins a confusion et clairement n'ont generalement pas de populations directement associes (pas d'entree de maisons). Un habitat dispersé aura un residential faible par unité de population (25 ha). Il aura besoin de nombreux unclassified. Un habitat éclaté aura un nombre important de landuse=residential. Il aura besoin nombreux tertiary. Un habitat groupé aura 1 residential important. il aura besoin de nombreus highway=residential Comme je disais, je prefere ne pas me preoccuper du type de route initialement. Je prefere avoir un indice globale sur le nombre de routes/rues. Ceci dit je n'ai jamais étudié l'urbanisme (peut-être un peu le ruralisme ;-) ni même les équations barbares ou les séries de Fourier, donc je n'ai aucune idée de la pertinence de mon propos. Si toutefois ça peut donner à penser (comme disait un de mes profs). Mais j'apprécie un beau graphe bien signifiant. Bah, ca sert toujours. Si je pensais qu'il n'y avait rien a retirer de la mailing list, je n'enverrais pas ca en publique. L'idee est qu'une bonne argumentation et des refutations permet d'affiner l'idee initial, ce qui se passe deja dans ma tete. La première phase, c'est peut-être de calculer simplement les communes (et les residentials Corine) sans highway. Je suis sur qu'il y en a un paquet ! Clairement! Emilie Laffray signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Statistiques sur les donnees Corine
Guillaume Allegre wrote: Le Tue 29 Sep 2009 à 23:26 +0100, Emilie Laffray a ecrit : Guillaume Allegre wrote: Je suis assez d'accord avec VdCT. Un pronostic au doigt mouillé : si tu effectues ton calcul 2 fois, la première avec uniquement les routes primary et la 2e avec uniquement les tertiary, tu risques d'avoir un classement des scores assez différents. Oui, mais l'idée est d'avoir un indice global initial. Je comptais prendre toutes les routes sauf autoroute et trunks selon sa suggestion. Je ne cherche pas a obtenir un ratio en séparant primaire, secondaire etc... C'est d'autant plus dangereux a mes yeux que leurs définitions en milieu urbain changent un peu par rapport au milieu rural. Certes. Alors je vais présenter mon idée autrement. Si tu le veux bien, essaie quand même de faire le calcul de l'indicateur sans présupposé, selon 3 modalités (par exemple) : - tous types de routes confondus, comme tu le pensais - uniquement les primary - uniquement les tertiary Et de regarder ensuite s'il y en a un qui colle mieux avec l'idée intuitive que tu te fais de la zone, à l'oeil. Hum, pas une mauvaise idée. Je pense qu'a terme, il faudra faire travailler tout le monde afin de trouver des villes témoins. Maintenant, la séparation uniquement primary ou tertirary me gêne, car la gamme avec laquelle on travaille est clairement primary, secondary, tertiary, unclassified, residential ET track. Il faut donc voir pour faire les calculs avec des groupes. Parce qu'on peut peut-être obtenir des résultats auxquels on ne pense pas a priori, et probablement différents selon le type de zone (centre ville, banlieue, zones rurales...) C'est un peu l'idée de faire apparaître les variables cachées, même si on est encore loin de la formalisation mathématique rigoureuse. Bah apres, il faut bien voir que c'est une idee lancee en l'air. Peut etre qu'il y a deja eus des theses sur ce genre de sujets, mais on rentre clairement dans le domaine de la recherche :) Emilie Laffray signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Re : Statistiques sur les donnees Corine
De : Vincent Pottier vpott...@gmail.com La première phase, c'est peut-être de calculer simplement les communes (et les residentials Corine) sans highway. Je suis sur qu'il y en a un paquet ! +1 Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Statistiques sur les donnees Corine
Le Tue 29 Sep 2009 à 23:46 +0100, Emilie Laffray a ecrit : Certes. Alors je vais présenter mon idée autrement. Si tu le veux bien, essaie quand même de faire le calcul de l'indicateur sans présupposé, selon 3 modalités (par exemple) : - tous types de routes confondus, comme tu le pensais - uniquement les primary - uniquement les tertiary Et de regarder ensuite s'il y en a un qui colle mieux avec l'idée intuitive que tu te fais de la zone, à l'oeil. Hum, pas une mauvaise idée. Je pense qu'a terme, il faudra faire travailler tout le monde afin de trouver des villes témoins. Maintenant, la séparation uniquement primary ou tertirary me gêne, car la gamme avec laquelle on travaille est clairement primary, secondary, tertiary, unclassified, residential ET track. Il faut donc voir pour faire les calculs avec des groupes. OK, je comprends ton objection. Je parlais uniquement de primary et tertiary, pour avoir deux indicateurs assez bien distincts, ie pour éviter le biais d'évaluation de l'importance de la route par l'opérateur. (il peut éventuellement confondre une primaire avec une secondaire, ou une secondaire avec une tertiaire, mais certainement pas confondre une 1aire et une 3aire). Donc l'idée reste à affiner. Parce qu'on peut peut-être obtenir des résultats auxquels on ne pense pas a priori, et probablement différents selon le type de zone (centre ville, banlieue, zones rurales...) C'est un peu l'idée de faire apparaître les variables cachées, même si on est encore loin de la formalisation mathématique rigoureuse. Bah apres, il faut bien voir que c'est une idee lancee en l'air. Peut etre qu'il y a deja eus des theses sur ce genre de sujets, mais on rentre clairement dans le domaine de la recherche :) Oui. On peut espérer qu'un jour il y aura des travaux de recherche sur les données d'OSM, et qui n'auraient pas été envisageables sans ! Bonne nuit... -- ° /\Guillaume AllègreMembre de l'April /~~\/\ allegre.guilla...@free.fr Promouvoir et défendre le logiciel libre / /~~\tél. 04.76.63.26.99 http://www.april.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Statistiques sur les donnees Corine
Au doigt mouillé, je dirais que la formule magique n'est pas évidente à définir. Un territoire aussi vaste que la France métropolitaine n'est pas aussi politiquement homogène que des institutions communes peuvent le suggérer. Pour des raisons historiques, des collectivités (communes, départements) ont décidé de développer le réseau routier local avec beaucoup de volontarisme, c'est le cas en Bretagne, pour différentes raisons : dispersion énorme de l'habitat rural, poids politique des agriculteurs, temps clément qui favorise la longévité des routes, etc... Si on introduit un critère de population, on a à gérer les écarts énormes de densité. On peut probablement mesurer des écarts par rapport à une moyenne, mais on doit créer des segmentations artificielles et, au final, on peut arriver à des évidences du genre, y a pas beaucoup de routes là où les espaces naturels (forêts, marais, garrigues) sont importants et beaucoup plus ailleurs. ;-) Dans ce cas, comment juger de ce qui manque sans connaître les variables de la zone concernée? Autre remarque les tertiary et secondary peuvent sans doute découler de l'habitat permanent, mais les flux touristiques peuvent amener à les faire créer, alors que l'habitat permanent n'y suffirait pas. Je rappelle aussi que dans une péninsule (la Bretagne encore), la plupart des primary n'ont de justification que départementale ou intra-régionale). Ces phénomènes de bord doivent exister ailleurs sur les côtes. Christian Emilie Laffray a écrit : Je ne suis pas sure qu'il existe des formules magiques de ce genre. Je prefere ne pas toucher aux classifications rues/routes en elles memes, car l'interpretation est parfois floue selon les personnes. Les tags motorways ou trunks eux pretent nettement moins a confusion et clairement n'ont generalement pas de populations directement associes (pas d'entree de maisons). Un habitat dispersé aura un residential faible par unité de population (25 ha). Il aura besoin de nombreux unclassified. Un habitat éclaté aura un nombre important de landuse=residential. Il aura besoin nombreux tertiary. Un habitat groupé aura 1 residential important. il aura besoin de nombreus highway=residential Comme je disais, je prefere ne pas me preoccuper du type de route initialement. Je prefere avoir un indice globale sur le nombre de routes/rues. Ceci dit je n'ai jamais étudié l'urbanisme (peut-être un peu le ruralisme ;-) ni même les équations barbares ou les séries de Fourier, donc je n'ai aucune idée de la pertinence de mon propos. Si toutefois ça peut donner à penser (comme disait un de mes profs). Mais j'apprécie un beau graphe bien signifiant. Bah, ca sert toujours. Si je pensais qu'il n'y avait rien a retirer de la mailing list, je n'enverrais pas ca en publique. L'idee est qu'une bonne argumentation et des refutations permet d'affiner l'idee initial, ce qui se passe deja dans ma tete. La première phase, c'est peut-être de calculer simplement les communes (et les residentials Corine) sans highway. Je suis sur qu'il y en a un paquet ! Clairement! Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Re : Re : Import Corine - Status
Nouvel arret. Cette fois ci le dernier changeset est le 2683498 (0:59:52 GMT ) Vu l heure je pense que la relance se fera demain matin donc bonne nuit a tous Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Gonflage
Bonjour, je ne sais si cette question a déjà été posée ici... Comment étiqueter une station de gonflage comme on en trouve aux entrées d'autoroutes, par exemple ? Merci, -- Jean-Francois Nifenecker, Bordeaux ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
