Re: [OSM-talk-fr] Mega-bug sur les boundary administra tive dans la région de Dole
c'est moi qui ai tout cassé!!! par contre si quelqu'un peut me dire comment j'ai fait???! et aussi comment faire pour importer mes communes sans faire une oeuvre d'art au passage? pour info: j'ai fait mes limites administratives, puis j'ai essayé d'importer avec josm mais ca a planté... j'ai utilisé le script bulk_upload, il s'est arrêté sur une erreur dans une relation, j'ai corriger et relancé, ca a repris comme il faut, mais le resultat était pas au RDV!!! Le 11 mai 2009 00:12, Pieren pier...@gmail.com a écrit : 2009/5/10 Pierre Mauduit pierre.maud...@gmail.com: Re, Il faudrait clarifier la situation : c'est Frederik, Pierre Mauduit ou Etienne Chové qui s'en charge ? Frederik a codé le script en Perl, avec l'aide des quelques présents sur le canal irc, j'ai pu installer le truc et annuler un changeset ; avec le dernier mail d'Etienne, je crois que j'ai ce qu'il faut pour laisser tourner un ptit script qui revert tout ca. Conclusion : Je m'en charge ;-) Bonne nuit ! Merci ! Pourras-tu nous donner les détails du comment tu fais et avec quel script ? Pieren ___ 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] Mega-bug sur les boundary administra tive dans la région de Dole
PS: il faut enlever tout ce que j'ai fait le 10 (si c'est pas déja fait) merci, Le 11 mai 2009 10:14, wouldsmina wouldsm...@gmail.com a écrit : c'est moi qui ai tout cassé!!! par contre si quelqu'un peut me dire comment j'ai fait???! et aussi comment faire pour importer mes communes sans faire une oeuvre d'art au passage? pour info: j'ai fait mes limites administratives, puis j'ai essayé d'importer avec josm mais ca a planté... j'ai utilisé le script bulk_upload, il s'est arrêté sur une erreur dans une relation, j'ai corriger et relancé, ca a repris comme il faut, mais le resultat était pas au RDV!!! Le 11 mai 2009 00:12, Pieren pier...@gmail.com a écrit : 2009/5/10 Pierre Mauduit pierre.maud...@gmail.com: Re, Il faudrait clarifier la situation : c'est Frederik, Pierre Mauduit ou Etienne Chové qui s'en charge ? Frederik a codé le script en Perl, avec l'aide des quelques présents sur le canal irc, j'ai pu installer le truc et annuler un changeset ; avec le dernier mail d'Etienne, je crois que j'ai ce qu'il faut pour laisser tourner un ptit script qui revert tout ca. Conclusion : Je m'en charge ;-) Bonne nuit ! Merci ! Pourras-tu nous donner les détails du comment tu fais et avec quel script ? Pieren ___ 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] Mega-bug sur les boundary administra tive dans la région de Dole
2009/5/11 wouldsmina wouldsm...@gmail.com: pour info: j'ai fait mes limites administratives, puis j'ai essayé d'importer avec josm mais ca a planté... j'ai utilisé le script bulk_upload, il s'est arrêté sur une erreur dans une relation, j'ai corriger et relancé, ca a repris comme il faut, mais le resultat était pas au RDV!!! Belle oeuvre d'art au passage ;-) Il faudrait que tu nous expliques comment tu as procédé. Comment as-tu utilisé le script d'import assisté de Fred ? Est-ce que tu as vérifié que la vectorisation et la conflation était bonne avant de faire l'upload ? Est-ce que tu as travaillé sur des groupes de communes ou est-ce que tu as fait tout le département d'un coup ? Quel est la taille de ton fichier .osm ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mega-bug sur les boundary administra tive dans la région de Dole
2009/5/11 wouldsmina wouldsm...@gmail.com: PS: il faut enlever tout ce que j'ai fait le 10 (si c'est pas déja fait) merci, Apparement, un seul changeset a été supprimé pour l'instant (#1142055). Il faudra demander à Pierre Mauduit de supprimer les autres changeset du 10 mai. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mega-bug sur les boundary administra tive dans la région de Dole
Comment as-tu utilisé le script d'import assisté de Fred ? Je l'ai pas utilisé, j'ai récuperer les gpx sur sont site... Est-ce que tu as vérifié que la vectorisation et la conflation était bonne avant de faire l'upload ? Non, je vois même pas de quoi tu parle, désolé. Est-ce que tu as travaillé sur des groupes de communes ou est-ce que tu as fait tout le département d'un coup ? j'ai fait les communes de A à M soit environ 200... Quel est la taille de ton fichier .osm ? 3Mo Il faudra demander à Pierre Mauduit de supprimer les autres changeset du 10 mai. Ok je lui demande tout de suite... a+ Le 11 mai 2009 10:24, Pieren pier...@gmail.com a écrit : 2009/5/11 wouldsmina wouldsm...@gmail.com: pour info: j'ai fait mes limites administratives, puis j'ai essayé d'importer avec josm mais ca a planté... j'ai utilisé le script bulk_upload, il s'est arrêté sur une erreur dans une relation, j'ai corriger et relancé, ca a repris comme il faut, mais le resultat était pas au RDV!!! Belle oeuvre d'art au passage ;-) Il faudrait que tu nous expliques comment tu as procédé. Comment as-tu utilisé le script d'import assisté de Fred ? Est-ce que tu as vérifié que la vectorisation et la conflation était bonne avant de faire l'upload ? Est-ce que tu as travaillé sur des groupes de communes ou est-ce que tu as fait tout le département d'un coup ? Quel est la taille de ton fichier .osm ? Pieren ___ 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] import massif planté avec bulk_u pload.py
tu peux supprimer tout mes changement du 10 mais stp? merci, Le 11 mai 2009 00:11, Pierre Mauduit pierre.maud...@gmail.com a écrit : Le dimanche 10 mai 2009 à 19:02 +0200, wouldsmina a écrit : bonjour à tous, j'ai essayé d'importer les limites administratives du jura mais le script en python http://svn.openstreetmap.org/applications/utils/import/bulk_upload_06/bulk_upload.pya planté Suite au lancement du script de revert, je me suis aperçu que le gros paté avait disparu sur le serveur de Sylvain, j'ai donc arrété le massacre après le revert du changeset #1141098 ne souhaitant pas être responsable de suppressions de données valides ; s'il y a besoin tout de même de faire le revert sur les autres, faites-moi signe. Bonne nuit, -- Pierre ___ 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] Mega-bug sur les boundary administra tive dans la région de Dole
Salut, Apparement, un seul changeset a été supprimé pour l'instant (#1142055). Il faudra demander à Pierre Mauduit de supprimer les autres changeset du 10 mai. Pieren Non, il y en a eu plus que ca : http://openstreetmap.org/user/Pierre Mauduit/edits Je peux relancer le script ce soir si vous n'êtes pas trop pressés ; étant donné que le paté avait disparu, je me suis dit que cela suffisait, mais je relance sur les autres changesets ce soir. -- Pierre ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BETA: paquets debian pour données navit
Salut, j'utilise navit sur mon openmoko. Je trouve que la personalisation en fonction du pays est assez facile à faire. Tu veux dire l'ajout des données ? il faut quand même aller chercher le binaire de la zone souhaitée, le télécharger, le placer au bon endroit, éditer un fichier de conf et rebelotte à chaque fois qu'on veut des données à jour (c-a-d souvent avec OSM)... C'est assez facile mais clairement pas simple amha. Sur le forum openmoko-fr, il y a un membre qui a fait des paquets debian pour le freerunner. Tu peux te rapprocher de lui. Je sais qu'il avait eu des problèmes avec le LANG. Ce pourrait d'ailleurs être une idée de centrer la carte sur la capitale du pays LANG par défaut. Le wiki openmoko (http://wiki.openmoko.org/wiki/Navit) semble maintenant conseiller d'utiliser les paquets debian experimental , De toute façon, dés que le GPS se synchronise, il sufit de se centrer sur la loction actuelle. ... Si on utilise un GPS ! Je suis d'accord qu'il est un peu dérooutant de se retrouver par défaut au milieu de nulle-part par contre, LANG n'a pas forcément de pays par défaut, qu'on se le dise ! Mais de toutes façons, ceci est une autre histoire à voir avec les devs de navit ! La version pour PC fixe m'intéresse, car calculer des routes sur le freerunner est un peu long. Et puis cela permettra de valider que les jonctions de route sont correctes dans OSM. Bien, j'attends tes retours si tu utilise debian/ubuntu alors ! :-). Et oui carrément, c'est super utile (navit comme tous les autres logiciels de navigation) pour vérifier les jonctions ! -- Jocelyn Delalande ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BETA: paquets debian pour données navit
2009/5/11 Jocelyn Delalande jocelyn.list...@crapouillou.net Salut, j'utilise navit sur mon openmoko. Je trouve que la personalisation en fonction du pays est assez facile à faire. Tu veux dire l'ajout des données ? il faut quand même aller chercher le binaire de la zone souhaitée, le télécharger, le placer au bon endroit, éditer un fichier de conf et rebelotte à chaque fois qu'on veut des données à jour (c-a-d souvent avec OSM)... C'est assez facile mais clairement pas simple amha. Euh ça c'est uniquement la première fois, non ? Ensuite, pour chaque mise à jour un simple script wget+unzip suffit. Aussi je ne comprends pas pourquoi s'embêter à inclure les maps dans le package, autant le télécharger directement sur cloudmade, ça allège énormément le paquet et t'évite de télécharger toutes les maps cloudmade chaque semaine au cas où ça sera utilisé ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mega-bug sur les boundary administra tive dans la région de Dole
oui avec JOSM... Le 11 mai 2009 11:18, Pieren pier...@gmail.com a écrit : 2009/5/11 wouldsmina wouldsm...@gmail.com: Je l'ai pas utilisé, j'ai récuperer les gpx sur sont site... Et comment as-tu fait pour transformer les données GPX en données au format .osm ? Avec JOSM ? Pieren ___ 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] BETA: paquets debian pour donnée s navit
Julien D. a écrit: Euh ça c'est uniquement la première fois, non ? Oui, et à chaque fois que tu veux ajouter/retirer une zone. Ensuite, pour chaque mise à jour un simple script wget+unzip suffit. Mais pour M. Tout le monde, ce n'est *vraiment* pas simple... C'est un peu comme demander à un débutant sous GNU/Linux de compiler un programme. Et même pour les personnes plus expérimentées ça reste pénible (mais ce n'est que mon avis de feignasse :-). Aussi je ne comprends pas pourquoi s'embêter à inclure les maps dans le package, autant le télécharger directement sur cloudmade, ça allège énormément le paquet et t'évite de télécharger toutes les maps cloudmade chaque semaine au cas où ça sera utilisé ? Ah non, c'est différent, les maps ne sont pas dans le paquet de navit (ce qui serait en effet bête), elles sont dans des paquets à part qui ne contiennent que les données cartographiques. De base, tu installe le paquet de navit nu, sans cartes. Puis tu peux rajouter le/les paquets .deb de tel ou tel pays qui seront ensuite maintenus à jour. Jocelyn ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mega-bug sur les boundary administra tive dans la région de Dole
2009/5/11 wouldsmina wouldsm...@gmail.com: oui avec JOSM... Est-ce que tu pourrais m'envoyer ton fichier OSM (pas sur la messagerie de talk-fr mais vers mon addresse email) ? Je ne sais pas si je serais capable d'ouvrir le fichier avec JOSM mais je peux déjà regarder ce qu'il y a dedans. Quelques remarques déjà: - faire 200 communes d'un coup n'est pas recommandé, justement à cause de la quantité de données qui sont difficile à gérer, d'une part avec JOSM, et à l'upload d'autre part. Je m'en tiendrais personnellement à faire par paquets de 20 à 30 communes. - une fois les GPX convertis en données OSM avec JOSM, il faut ensuite faire un gros travail d'édition pour rendre les limites cohérentes entre-elles, découper les limites en fonction des communes voisines, tenir compte des données déjà existantes, bref un énorme boulot que certains scripts de l'outil d'import assisté fait à ta place si tu le souhaites. Mais même avec ça, il reste des corrections à faire à la main comme supprimer les erreurs de vectorisation, ou les problèmes de limites mal jointes entre-elles (souvent à l'intersection de 3 communes). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mega-bug sur les boundary administra tive dans la région de Dole
je savias pas que l'outil d'import permet d'aller plus loin que les gpx!!! j'ai tout fait à la main. par contre j'ai dit une bêtise tout a l'heure, le fichier fait 14Mo, mais je me demande si c'est pas après l'import qu'il a grossit... je met le fichier su dl.free.fr et je t'envoi le liens, merci pour ton aide... Le 11 mai 2009 12:35, Pieren pier...@gmail.com a écrit : 2009/5/11 wouldsmina wouldsm...@gmail.com: oui avec JOSM... Est-ce que tu pourrais m'envoyer ton fichier OSM (pas sur la messagerie de talk-fr mais vers mon addresse email) ? Je ne sais pas si je serais capable d'ouvrir le fichier avec JOSM mais je peux déjà regarder ce qu'il y a dedans. Quelques remarques déjà: - faire 200 communes d'un coup n'est pas recommandé, justement à cause de la quantité de données qui sont difficile à gérer, d'une part avec JOSM, et à l'upload d'autre part. Je m'en tiendrais personnellement à faire par paquets de 20 à 30 communes. - une fois les GPX convertis en données OSM avec JOSM, il faut ensuite faire un gros travail d'édition pour rendre les limites cohérentes entre-elles, découper les limites en fonction des communes voisines, tenir compte des données déjà existantes, bref un énorme boulot que certains scripts de l'outil d'import assisté fait à ta place si tu le souhaites. Mais même avec ça, il reste des corrections à faire à la main comme supprimer les erreurs de vectorisation, ou les problèmes de limites mal jointes entre-elles (souvent à l'intersection de 3 communes). Pieren ___ 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] BETA: paquets debian pour données navit
Ensuite, pour chaque mise à jour un simple script wget+unzip suffit. Mais pour M. Tout le monde, ce n'est *vraiment* pas simple... C'est un peu comme demander à un débutant sous GNU/Linux de compiler un programme. Et même pour les personnes plus expérimentées ça reste pénible (mais ce n'est que mon avis de feignasse :-). Je ne vois pas trop ce qui est complexe à lancer un script de 2 lignes ?! Mais bon si c'est intégré aux mises à jour du système c'est bien aussi : simplicité maximum. Aussi je ne comprends pas pourquoi s'embêter à inclure les maps dans le package, autant le télécharger directement sur cloudmade, ça allège énormément le paquet et t'évite de télécharger toutes les maps cloudmade chaque semaine au cas où ça sera utilisé ? Ah non, c'est différent, les maps ne sont pas dans le paquet de navit (ce qui serait en effet bête), elles sont dans des paquets à part qui ne contiennent que les données cartographiques. De base, tu installe le paquet de navit nu, sans cartes. Puis tu peux rajouter le/les paquets .deb de tel ou tel pays qui seront ensuite maintenus à jour. Non, je ne parles pas du paquet navit.deb, mais des paquets comme navit-osm-data-france_15042009_all.deb, pourquoi empaqueter les cartes et pas juste un script qui récupère les cartes sur cloudmade (ou ailleurs si tu préfères répliquer les données) ? À mon avis les .deb ont plus vocation à intégrer du logiciel, pas du data. Sinon j'ai installé navit sous Ubuntu et il a l'air de bien fonctionner mais en installant la carte navit-osm-data-france_15042009_all.deb ça n'a rien changé au fichier /etc/navit/navit.xml (pas de configuration automatique de la map?). D'ailleurs où se trouve la map installée ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BETA: paquets debian pour donnée s navit
Non, je ne parles pas du paquet navit.deb, mais des paquets comme navit-osm-data-france_15042009_all.deb, pourquoi empaqueter les cartes et pas juste un script qui récupère les cartes sur cloudmade (ou ailleurs si tu préfères répliquer les données) ? À mon avis les .deb ont plus vocation à intégrer du logiciel, pas du data. C'est un point de vue qui peut se tenir, quand à moi, je pense que les mises à jour n'ont jamais vocation à être gérées individuellements par l'user... Disons que en me plaçant dans l'optique ma grand mère veut utiliser navit, ça me paraît bien plus simple :-). De plus, dans le cas d'un serveur utilisant les données OSM (ex: slippy-map), il me semble tout aussi logique que celles-ci soit mise à jour régulièrement et automatiquement au même titre que les logiciels (ex: un paquet openstreetmap-planet). Par contre il est vrai que la fréquence d'une semaine peut ne pas être adaptée pour l'user lambda. Sinon j'ai installé navit sous Ubuntu et il a l'air de bien fonctionner mais en installant la carte navit-osm-data-france_15042009_all.deb ça n'a rien changé au fichier /etc/navit/navit.xml (pas de configuration automatique de la map?). D'ailleurs où se trouve la map installée ? La map installée se situe dans /usr/share/maps/osm/ une fraction de fichier de conf est mis dans /usr/share/maps/ Si tu regarde attentivement le navit.xml, il fait de base un include de /usr/share/maps/*.xml ; bon à savoir, même pour une approche à base de scripts ;-). Peux-tu me confirmer que la carte apparaissait bien dans navit suite à l'installation ? Merci, Jocelyn ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BETA: paquets debian pour données navit
2009/5/11 Jocelyn Delalande jocelyn.list...@crapouillou.net Non, je ne parles pas du paquet navit.deb, mais des paquets comme navit-osm-data-france_15042009_all.deb, pourquoi empaqueter les cartes et pas juste un script qui récupère les cartes sur cloudmade (ou ailleurs si tu préfères répliquer les données) ? À mon avis les .deb ont plus vocation à intégrer du logiciel, pas du data. C'est un point de vue qui peut se tenir, quand à moi, je pense que les mises à jour n'ont jamais vocation à être gérées individuellements par l'user... Disons que en me plaçant dans l'optique ma grand mère veut utiliser navit, ça me paraît bien plus simple :-). De plus, dans le cas d'un serveur utilisant les données OSM (ex: slippy-map), il me semble tout aussi logique que celles-ci soit mise à jour régulièrement et automatiquement au même titre que les logiciels (ex: un paquet openstreetmap-planet). Par contre il est vrai que la fréquence d'une semaine peut ne pas être adaptée pour l'user lambda. Je pensais à un script dans le .deb, du coup on garde la simplicité des mises à jour et la légèreté des paquets. Sinon j'ai installé navit sous Ubuntu et il a l'air de bien fonctionner mais en installant la carte navit-osm-data-france_15042009_all.deb ça n'a rien changé au fichier /etc/navit/navit.xml (pas de configuration automatique de la map?). D'ailleurs où se trouve la map installée ? La map installée se situe dans /usr/share/maps/osm/ une fraction de fichier de conf est mis dans /usr/share/maps/ Si tu regarde attentivement le navit.xml, il fait de base un include de /usr/share/maps/*.xml ; bon à savoir, même pour une approche à base de scripts ;-). Peux-tu me confirmer que la carte apparaissait bien dans navit suite à l'installation ? Merci, Eh bien je n'ai pas de répertoire /usr/share/maps ! (après install des 2 paquets énoncés) Pas de carte affichée au premier abord, mais j'y arrive après recherche de Paris (Destination-Paris-Carte). Ah oui, en fait l'url des maps est /usr/share/navit/maps. Donc finalement, carte oui, mais centrage non (es-ce le .navit/center.txt ? Il contient mg: 0x4048e 0x5f44dc). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Référents OSM sur Rennes ?
hello, quel est le but / mission de ce referent? je bricole pas mal sur OSM depuis un an principalement au nord de rennes mais de la a parler de referent... cordialement, ulrich Le 6 mai 2009 22:51, David MENTRE dmen...@linux-france.org a écrit : Bonjour, Le chargé de mission TIC à la ville de Rennes recherche les « référents open street map sur Rennes (Grumly ?) » pour la programmation des étés TIC de Bretagne. Est-ce que l'un d'entre vous pourrais me donner le contact d'un ou deux Rennais fortement impliqué dans OSM (ou s'auto-dénoncer ;-) pour que je puisse leur donner le contact précis ? Merci d'avance, Amicalement, d. -- pour Gulliver -- GPG/PGP key: A3AD7A2A David MENTRE dmen...@linux-france.org 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ 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] BETA: paquets debian pour donnée s navit
Je pensais à un script dans le .deb, du coup on garde la simplicité des mises à jour et la légèreté des paquets. Pas sûr de saisir, comment est faite la mise à jour du coup ? Peux-tu détailler le concept ? (dans mon cas, le script faisant le wget est dans le paquet source, celui qui génère tous les navit-osm-data-pays_version.deb). Marrant, en faisant quelques recherches, je n'ai rien trouvé concernant la problématique de l'empaquetage de ce genre de données (l'idée est-elle si absurde ?). Eh bien je n'ai pas de répertoire /usr/share/maps ! (après install des 2 paquets énoncés) Pas de carte affichée au premier abord, mais j'y arrive après recherche de Paris (Destination-Paris-Carte). Ah oui, en fait l'url des maps est /usr/share/navit/maps. Oops, juste une erreur de ma faute dans le mail, sorry, il s'agit bien des répertoires /usr/share/navit/maps et /usr/share/navit/maps/osm. Donc finalement, carte oui, mais centrage non (es-ce le .navit/center.txt ? Il contient mg: 0x4048e 0x5f44dc). Oui, ce n'est pas prévu pour changer quoi que ça soit au centrage. Je ne pense pas que les paquets de données installés doivent s'octroyer chacun leur tour à l'install le centrage. Ça revient aux devs de navit de centrer la map automatiquement sur une zone contenant des données (ex: la BoundingBox encadrant toutes les données activées). Jocelyn, surfeur à la frontière du hors-sujet ;-). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BETA: paquets debian pour donnée s navit
Le 11/05/2009 17:06, Jocelyn Delalande a écrit : Marrant, en faisant quelques recherches, je n'ai rien trouvé concernant la problématique de l'empaquetage de ce genre de données (l'idée est-elle si absurde ?). De mémoire, il y a quelques années ça avait été débattu en long en large et en travers a propos de données astronomiques. Des gens voulaient intégrer à Debian les données (libres), mais ça ce comptait en giga-octet donc ça ne plaisait pas à tout le monde. Le débat était sur l'intégration ou non à Debian plutôt que sur la façon de les empaqueter mais bon c'est quand même très proche. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BETA: paquets debian pour données navit
2009/5/11 Jocelyn Delalande jocelyn.list...@crapouillou.net Je pensais à un script dans le .deb, du coup on garde la simplicité des mises à jour et la légèreté des paquets. Pas sûr de saisir, comment est faite la mise à jour du coup ? Peux-tu détailler le concept ? (dans mon cas, le script faisant le wget est dans le paquet source, celui qui génère tous les navit-osm-data-pays_version.deb). Disons que le paquet navit-osm-data-pays_version.deb ne contient pas la carte pays, mais juste un lien vers cette carte. - En s'installant, le paquet télécharge la carte sur cloudmade ou ailleurs, puis l'installe dans /usr/share/navit/maps. - A chaque MAJ de carte, tu regénères ce paquet deb avec une version+1, ce qui oblige le système debian à recommencer l'étape précédente. Marrant, en faisant quelques recherches, je n'ai rien trouvé concernant la problématique de l'empaquetage de ce genre de données (l'idée est-elle si absurde ?). Étrange, j'ai vu pas mal de paquets ayant ce comportement (téléchargement de données sur internet pendant l'installation du .deb). Par exemple, le plugin sous le dépôt ubuntu a ce comportement : $sudo apt-get install flashplugin-installer Downloading... --2009-05-11 17:23:26-- http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_10.0.22.87.orig.tar.gz Résolution de proxy.univ-lemans.fr... 195.221.244.34 Connexion vers proxy.univ-lemans.fr|195.221.244.34|:3128... connecté. requête Proxy transmise, en attente de la réponse... 200 OK Longueur: 3968445 (3,8M) [application/x-gzip] Saving to: `./adobe-flashplugin_10.0.22.87.orig.tar.gz' 0K .. .. .. .. .. 1% 494K 8s 50K .. .. .. .. .. 2% 1,84M 5s 100K .. .. .. .. .. 3% 1010K 4s 150K .. .. .. .. .. 5% 1,80M 4s 200K .. .. .. .. .. 6% 119K 9s ... 3750K .. .. .. .. .. 98% 11,1M 0s 3800K .. .. .. .. .. 99% 713K 0s 3850K .. .. . 100% 1016K=15s 2009-05-11 17:23:41 (262 KB/s) - « ./adobe-flashplugin_10.0.22.87.orig.tar.gz » sauvegardé [3968445/3968445] Download done. Flash Plugin installed. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BETA: paquets debian pour données navit
Julien D. a écrit : $sudo apt-get install flashplugin-installer ça c'est parce-qu'il n'est pas libre ... on n'a pas le droit de le redistribuer donc on contourne la règle. -- Thomas Clavier http://www.tcweb.org Jabber/XMPP/MSN/Gtalk :t...@jabber.tcweb.org +33 (0)6 20 81 81 30 +33 (0)950 783 783 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] Référents OSM sur Rennes ?
2009/5/11 ulrich rousseau ulrich.rouss...@gmail.com: quel est le but / mission de ce referent? Le responsable TIC de la ville de Rennes fait parti du comité de programmation des étés TIC de Bretagne et veut inviter officiellement OSM (probablement pour un stand ou une présentation). Je n'en sais pas plus. Je te donne son contact en privé. Amicalement, d. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BETA: paquets debian pour donnée s navit
ton script pré-install peut lancer le wget par exemple et pour une mise à jour il suffit d'incrémenter le numéro de paquet sans rien changer d'autre :-) Ok, mais on perd toute l'encapsulation (l'empaquetage !) et la sécurité du paquet, chaque utilisateur dépend du coup de l'état des serveurs cloudmade, le jour où ils changent leurs urls, ça casse tout... Si les données ne sont pas trop grosse les avoir dans un paquet c'est bien (voir par exemple les data de jeux) Dans ce cas là j'ai bien peur que ça ne serve à rien ... sauf peut-être pour une personne sans le net qui n'a qu'un dépos debian sous la main. Les datas des First Person Shooters de Debian oscillent entre 50 et 300MiO, là où les datas de navits sont entre quelques centaines de KiO et 50MiO. (pour le planet, en effet, il en est serait tout autre et un système à base de diffs pourrait s'imposer). De mémoire, il y a quelques années ça avait été débattu en long en large et en travers a propos de données astronomiques. Des gens voulaient intégrer à Debian les données (libres), mais ça ce comptait en giga-octet donc ça ne plaisait pas à tout le monde. Le débat était sur l'intégration ou non à Debian plutôt que sur la façon de les empaqueter mais bon c'est quand même très proche. Ok, intéressant, malheureusement, je ne retrouve, pas de discussion de mailling-list. Je reste convaincu de l'utilité de ces packages, même si ça n'est éventuellement pas la solution idéale, c'est encore celle que je préfère, et je vais continuer mon travail dessus (également parce que ça m'apprend beaucoup sur le packaging ;-))... Cependant un tel débat est intéressant ! Jocelyn ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BETA: paquets debian pour donnée s navit
Jocelyn Delalande a écrit : Les datas des First Person Shooters de Debian oscillent entre 50 et 300MiO, là où les datas de navits sont entre quelques centaines de KiO alors faut vraiment pas se privé, en avant toute pour le paquet ... PS: je test ce soir. -- Thomas Clavier http://www.tcweb.org Jabber/XMPP/MSN/Gtalk :t...@jabber.tcweb.org +33 (0)6 20 81 81 30 +33 (0)950 783 783 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] BETA: paquets debian pour données navit
2009/5/11 Jocelyn Delalande jocelyn.list...@crapouillou.net ton script pré-install peut lancer le wget par exemple et pour une mise à jour il suffit d'incrémenter le numéro de paquet sans rien changer d'autre :-) Ok, mais on perd toute l'encapsulation (l'empaquetage !) et la sécurité du paquet, chaque utilisateur dépend du coup de l'état des serveurs cloudmade, le jour où ils changent leurs urls, ça casse tout... Si les données ne sont pas trop grosse les avoir dans un paquet c'est bien (voir par exemple les data de jeux) Dans ce cas là j'ai bien peur que ça ne serve à rien ... sauf peut-être pour une personne sans le net qui n'a qu'un dépos debian sous la main. Les datas des First Person Shooters de Debian oscillent entre 50 et 300MiO, là où les datas de navits sont entre quelques centaines de KiO et 50MiO. (pour le planet, en effet, il en est serait tout autre et un système à base de diffs pourrait s'imposer). Oui, quoique la taille des données augmentent plutôt vite. Sinon comme je l'ai déjà dis, tu peux héberger toi-même les données (miroir des fichiers navit de cloudmade) et ainsi ne plus dépendre d'eux pour les pays. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mega-bug sur les boundary administra tive dans la région de Dole
Le lundi 11 mai 2009 à 10:23 +0200, wouldsmina a écrit : PS: il faut enlever tout ce que j'ai fait le 10 (si c'est pas déja fait) merci, Pour info, j'ai relancé le revert que j'avais interrompu hier soir (ou cette nuit), afin de finir la liste fournie par Etienne ; Bonne soirée, -- Pierre ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BETA: paquets debian pour données navit
Installation de navit et de ton paquet france ok sous debian aussi. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Beta letuffe
Hello tout le monde, Ce soir je me suis aperçu que sur beta letuffe un certain nombre de communes sont rendues en gris. Qu est ce que cela signifie ? Exemple : L'Etrat, la tour en jarez, saint andre le puy http://beta.letuffe.org/?zoom=10lat=45.67853lon=4.23152layers=B0FFT Merci d avance Julien De : Pieren pier...@gmail.com À : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Jeudi, 30 Avril 2009, 12h53mn 55s Objet : Re: [OSM-talk-fr] Re : limite communales - Etat d'avancement 2009/4/30 Vincent Pottier vpott...@gmail.com: Yann Coupin a écrit : J'ai déjà corrigé un plan d'eau près de chez moi en me basant sur le cadastre (sans autotrace) mais du coup j'avais un footway (et la trace qui va avec) qui se retrouvait dans l'eau. Je n'ai pas fait la trace et je n'ai pas encore été la vérifier sur place, mais tout ça me donne envie de vous dire : faisez gaffe ! Sur ! Rien ne vaut le terrain ! D'accord mais irréaliste comme pour les forêts ou les lignes de chemin de fer. Le projet hydrographie est à discuter. Est-ce que le cadastre est la meilleure source ? Certainement pas. Le cadastre fait souvent figurer le lit majeur d'une rivière ou pour un canal, l'emprunte la plus large du canal qui n'est jamais utilisée en réalité. La source idéale reste les orthophotos mais nous n'en avons pas. L'autre source dont nous disposons sont des GPS eux-même précis à plus ou moins 5 à 10 mètres suivant les conditions (voir plus). Mais je vois mal quelqu'un longer les rives de rivières ou ruisseaux sur des centaines de kilomètres à pied. Des idées : faire participer les pêcheurs ou poser des GPS sur les plus gros poissons ou poser un tracker sur un petit bateau en bois en haut du ruisseau de montagne et le récupérer à l'embouchure du fleuve. Donc le cadastre est mieux que rien, mais il faut prendre les données hydrographiques qui y figure pour ce qu'elles sont, c.a.d une donnée accessoire et non précise (par contre, c'est une bonne source pour la toponymie). Il faut aussi faire attention à ne pas utiliser le bleu aveuglément. Souvent le cadastre fait figurer de petits ruisseaux ou même rigoles qui n'existent plus. Ou encore, les piscines en zone d'habitation qu'il vaudrait mieux éviter de tagguer en natural=water... En attendant une solution pour l'hydrographie, ça sera déjà très bien si les limites administratives qui suivent des limites physiques soient collées ensemble, quitte à avancer un peu moins vite. Il existe deux façons de le faire, expliquées ici: http://wiki.openstreetmap.org/wiki/Talk:WikiProject_France/Tracer_les_limites_administratives#Limites_administratives_utilisant_des_.C3.A9l.C3.A9ments_physiques On ne peut forcer personne à le faire mais ça serait un gros plus au niveau sérieux et qualité. J'attire aussi l'attention sur le fait que de nombreuses limites ne sont pas forcément au milieu de la route ou de la rivière. C'est d'ailleurs souvent une différence d'interprétation entre communes qui font que les limites ne collent pas. C'est alors à vous de juger si la limite doit se superposer au way symbolisant le milieu de la route ou de la rivière ou si cette limite peut rester parallèle. Pieren ___ 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] CORINE Land Cover France comme sou rce de données
Un grand merci à toi pour avoir effectué les démarches. Et yeepee ! pour le résultat obtenu. Antoine Pieren a écrit : Bonsoir, J'ai reçu aujourd'hui la réponse à ma demande d'éclaircissement sur les conditions d'utilisation de la base CORINE Land Cover France, en particulier sur les fameuses clauses qui nous posait problème. Voici une copie de la demande suivie de la réponse: Monsieur, J'ai récemment pris connaissance des conditions d'usage de la base de donnée géographique CORINE Land Cover pour la France disponible sur votre site internet www.ifen.fr . Cette source serait d'un apport inestimable au projet de base de données cartographique libre et mondiale appelé OpenStreetMap [1]. Ce projet est basé sur un principe collaboratif et ouvert à tous similaire au modèle de l'encyclopédie en ligne Wikipedia. Participant moi-même à ce projet et avec l'aide d'autres contributeurs, nous envisageons d'importer une partie des données mises à disposition par votre ministère sur votre site internet. Mais avant d'effectuer cette opération, nous souhaitons vérifier la conformité des droits d'usages des données CORINE Land Cover France avec l'utilisation qui en sera fait dans OpenStreetMap et sa licence Creative Commons CC-BY-SA 2.0 [2]. Il existe une clause dans votre Guide d'utilisation des données CORINE Land Cover France de février 2009 [3], au chapitre 10 Droits d'utilisation qui pourrait nous empêcher d'utiliser ces données dans notre projet. Cette clause précise que, je cite, La réutilisation des informations suppose que celles-ci ne soient pas altérées, que leur sens ne soit pas dénaturé et que leurs sources et la date de leur dernière mise à jour soient mentionnées de la manière suivante : Source : Union européenne – SOeS, CORINE Land Cover, 2006. Si la mention de la source est une condition facile à respecter par l'ajout automatique d'une métadonnée et que le sens de ces données ne sera pas dénaturé au moment de leur importation dans notre base de données, il nous est techniquement impossible de garantir que celles-ci ne soient pas ultérieurement modifiées ou altérées par certains contributeurs, le principe de la libre édition étant le fondement même du projet OpenStreetMap. C'est pourquoi j'aimerais obtenir de votre part un avis concernant cette clause de non-altération des données CORINE Land Cover France et si celle-ci n'empêche pas leur utilisation dans un projet collaboratif et ouvert comme l'est OpenStreetMap. En vous remerciant de vos éclairages, je vous prie d'agréer, Monsieur, l'expression de mes salutations distinguées. signature+, contributeur OpenStreetMap [1] http://www.openstreetmap.org [2] http://creativecommons.org/ licenses/by-sa/2.0/fr/ [3] http://www.ifen.fr/uploads/ media/CLC_guide_d-utilisation_ 02.pdf Et voici la réponse, reçue le 11 Mai 2009: Monsieur, La base Corine Land Cover France 2006 est disponible depuis peu sur le site www.ifen.fr en téléchargement gratuit avec une licence actualisée comme vous avez pu le constater. Cette base est européenne, chaque pays produit sa partie, le tout est ensuite fusionné pour constituer la base européenne. Chaque pays est copropriétaire avec l'Agence Européenne pour l'Environnement de la base qu'il a produite. Pour la France, la licence est ouverte, il n'y a plus de distinction applications commerciales ou non par exemple. Au niveau européen la licence n'a pas encore été finalisée mais elle devrait être en accord avec la licence française, en voici les grandes lignes évoquées lors du dernier Comité de pilotage il y a quelques semaines : Use rights : EEA is promoting the widest possible use of all data produced during the project. All core land cover data (national and European CLC 2000-2006 changes, national and European CLC2006 and related metadata, high resolution built-up areas, including degree of soil sealing, 2006 and high resolution forest areas, 2006) will be made available free of charge via the web, for non-commercial as well as commercial uses. Concernant, la phrase La réutilisation des informations suppose que celles-ci ne soient pas altérées, que leur sens ne soit pas dénaturé et que leurs sources et la date de leur dernière mise à jour soient mentionnées de la manière suivante : Source : Union européenne – SOeS, CORINE Land Cover, 2006., elle doit être comprise comme une mise en garde liée à la nature de la donnée et à sa précision : En effet cette base a une échelle d'utilisation au 1/100 000 ème, elle a été produite à partir d'images satellites d'une précision de 20 mètres, les polygones cartographiés mesurent au moins 25 hectares et la largeur minimale des objets est de 100 mètres. Donc une utilisation à une échelle trop fine peut produire des résultats incorrects, par exemple, des petites zones artificielles n'apparaissent pas dans la base tout comme des petits espaces boisés ou des cours d'eaux ou des routes pas assez larges. De
