Re: [OSM-talk-fr] OpenStreetMap au Tchad!
Le 18 décembre 2012 16:42, EUROSHA Tchad eurosha.tc...@gmail.com a écrit : Un coup de main sur le reste du pays (N'Djaména, Moundou, Doba...) serait particulièrement le bienvenu! Aussi si vous êtes intéressés et avez des commentaires ou des questions, n'hésitez pas à nous contacter à eurosha.tc...@gmail.com Pourrais-tu en dire un peu plus directement ici ? Par quelle technique on contribue à distance ? Y a-t-il un groupe/communauté de travail ? Son url ? (et pas seulement l'url d'un truc mondial subdivisé en 36 projets découpés en 40 entités) Faut-il être à l'aise avec l'anglais ? Merci. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Le 19 décembre 2012 01:00, Christophe Merlet red...@redfoxcenter.org a écrit : Le mardi 18 décembre 2012 à 23:53 +0100, Eric Marsden a écrit : cm == Christophe Merlet red...@redfoxcenter.org writes: cm Mais cette solution a plusieurs avantages. C'est facile à administrer à cm distance. ça ne nécessite pas de serveur puissant, juste de la RAM (en cm 9h, 18 Go de tuiles distinctes ont été demandées). L'intérêt d'un serveur distinct de celui à Londres pour les utilisateurs français me semble discutable. Depuis ma connexion Free au domicile à Toulouse, je suis à 63 ms (16 hops) de uppa-vl10-gi0-3-0-0-pau-rtr-011.noc.renater.fr, alors que je suis à 52 ms (15 hops) de me-rach.net.ic.ac.uk. J'imagine que c'est pareil pour la majorité des FAI français, qui font du peering vers Renater uniquement à Paris. Et en cas de miss la requête part quand même à Londres ... Ensuite depuis mon travail (connexion Renater) je suis à 3.8ms (7 hops) du serveur paulla, mais ça n'est pas très representatif des utilisateurs en général ... De chez moi (a Pau évidemment), en fibre optique, Londres est à 30ms, Pau est à... 40ms !! SFR m'envoie au SFINX, puis direction Lyon, et retour au point de départ via Bordeaux oo' Pire, il est censé y avoir un petit GIX local mais il ne fait pas preuve d'une grande efficacité :/ On espère voir la situation évoluer... Par contre au boulot, je suis à 0,3 ms... 2 switchs et 1 routeur ;o) Ceci dit, j'imagine que ça décharge un peu le lien vers Imperial College, ce qui doit leur être utile, donc merci et bravo à RedFox pour cela. Je pense que le serveur principal à gagné entre 10 et 20 mbs de bande passante sur plus de 100. Voir graphique en pièce jointe sur la courbe d'aujourd'hui par rapport aux jours précédents. C'est pas si mal pour commencer. Merci pour ce travail, c'est une excellente nouvelle. Ok le chemin vers Pau va être plus long mais le serveur de rendu sera moins chargé et c'est à mon avis ce qui compte le plus, partager la charge. Sinon, on dirait que de chez moi le routage n'est pas encore actif traceroute to a.tile.openstreetmap.org (193.63.75.98), 30 hops max, 60 byte packets 1 192.168.1.1 (192.168.1.1) 1.166 ms 2.835 ms 2.808 ms 2 * * * 3 153.226.70.86.rev.sfr.net (86.70.226.153) 72.387 ms 76.436 ms 76.420 ms 4 81.255.103.84.rev.sfr.net (84.103.255.81) 76.396 ms 78.996 ms 80.110 ms 5 146.133.64.86.rev.sfr.net (86.64.133.146) 85.690 ms 85.684 ms * 6 linx-gw1.ja.net (195.66.224.15) 97.748 ms 66.202 ms 54.794 ms 7 ae1.lond-sbr4.ja.net (146.97.35.181) 55.726 ms 57.377 ms 58.669 ms 8 ae12.read-sbr1.ja.net (146.97.33.141) 61.820 ms 63.552 ms 64.568 ms 9 be1.londic-rbr1.ja.net (146.97.35.150) 72.247 ms 72.251 ms 73.140 ms 10 imperial-college.ja.net (146.97.137.154) 74.123 ms 75.037 ms 75.920 ms 11 me-rach.net.ic.ac.uk (194.82.153.92) 77.125 ms 82.417 ms 82.379 ms -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Fwd: [Cartes ouvertes] Publication de l'orthophotographie Finistère 1952
Pour information. Romain -- Message transféré -- De : FILY Gaëlle gaelle.f...@brest-metropole-oceane.fr Date : 19 décembre 2012 10:09 Objet : [Cartes ouvertes] Publication de l'orthophotographie Finistère 1952 À : LISTE Cartes ouvertes cartes-ouvertes-pays-br...@listes.infini.fr, LISTE Libre li...@infini.fr, LISTE Brest en Biens Communs brest-en-biens-comm...@listes.infini.fr Bonjour ** ** « Dans la continuité du programme d'acquisition des orthophotographies anciennes, la couverture aérienne du Finistère réalisée en 1952 a été géoréférencée et est maintenant publiée. Les conditions d'utilisationhttp://geobretagne.fr/geonetwork?uuid=048622c5-b333-4c2b-94ec-40a41608dc06permettent son utilisation par flux sur tout site web, comme c'est le cas sur le visualiseur 1950-2012 http://geobretagne.fr/sviewer/dual.html. Les membres du partenariat peuvent de plus intégrer le flux à leurs SIG internes. Le programme s'achèvera en fin d'année avec la couverture des Côtes d'Armor. La Bretagne sera la première région à disposer d'une vue intégrale de son territoire à 60 ans d'écart, avec une précision métrique. Vous reconnaîtrez (ou pas) : Bénodet, le Moulin Blanc, Châteaulin et Carhaix : » *Lire la suitehttp://cms.geobretagne.fr/content/publication-de-lorthophotographie-finist%C3%A8re-1952 * * * *Accédez au visualisateurhttp://geobretagne.fr/sviewer/dual.html?x=147690y=6835611z=18, *incorporable dans son propre site. Des infos sur http://cms.geobretagne.fr/ ** ** Bonne journée * * *FILY Gaëlle* 02-98-00-84-38 ** ** Animatrice de projets TIC Direction Proximité Service Internet et Expression Multimédia ** ** http://www.wiki-brest.net [image: Description : logo-wiki_50x55] image001.gif___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] layers et cadastre injoignables...
Suite à une mise à jour malheureuse hier soir sur un de nos serveurs, layers et cadastre sont injoignable. Je pense pouvoir aller sur place remettre tout ça en fonctionnement cet après-midi. Désolé... ça m'apprendra à ne pas avoir pris le temps de configurer/tester l'IPMI/idrac sur les serveurs Dell chez Free. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Le mercredi 19 décembre 2012 à 00:26 +0100, Christian Quest a écrit : Constat proche pour moi (aussi chez free), le ping est quasiment identique (dans les 40/45ms) et même nombre de hops. Un cache de tuile chez free Bezons diviserai mon ping presque par 2 (23ms en moyenne sur osm11) ;) Le geodns pourrait-il rediriger les requêtes provenant des AS de free vers un serveur chez free ? Le GeoDNS redirige les IP par pays entier. Il ne semble pas y avoir de subdivision. De plus pour fournir un cache de tuiles à la fondation OSM, il y a quelques conditions à réunir... https://wiki.openstreetmap.org/wiki/Servers/Tile_CDN Concernant les temps d'accès, c'est un problème connu. Il y a un GIX à Pau sur lequel Axione et RENATER échangeait du trafic. Mais cela posait un petit problème... lorsqu'une université francilienne souhaitait accéder à un client citéFibre (à paris donc), il faisait un aller-retour à Pau... Les joies du routage Internet ! De plus, le routage n'est pas qu'un problème technique, c'est aussi et surtout un problème financier. Les opérateurs de transit facture la bande passante dans des rapports pouvant aller de 1 à 20 ! Donc il revient facilement moins cher d'aller faire son peering sur un GROS GIX fédérateur, voire à l'étranger que sur un nœud local. Des discussions d'il y a quelques années faisant un état des lieux... http://lafibre.info/paubc/index.php/topic,1704.0.html Pour ceux qui l'ignore, Pau est la première ville^Wagglo de France a avoir déployé son propre réseau FTTH. Il dessert plusieurs dizaines de milliers d'habitants https://fr.wikipedia.org/wiki/Pau_Broadband_Country Aujourd'hui, le plus grand FAI a destination du grand public utilisant ce réseau est SFR. Il a été rejoint cette année par Orange http://www.larepubliquedespyrenees.fr/2012/04/19/fibre-optique-premieres-offres-d-orange-avant-noel,232898.php On peut donc espérer qu'avec 4 gros opérateurs nationaux (RENATER, Axione, SFR, Orange) ils voient un intérêt financier à peerer proprement en local... Christophe, ça serait possible de rajouter ce serveur dans le munin d'OSM-FR ? On a déjà notre propre munin http://tile.paulla.asso.fr/munin-osm/ La fondation OSM intégrera ce serveur dans son propre munin http://munin.openstreetmap.org en janvier. (Il faut qu'on lui ouvre des ports supplémentaires pour ce faire) Librement, -- Christophe Merlet (RedFox) 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
Re: [OSM-talk-fr] OpenStreetMap au Tchad!
bonjour je viens de faire un tour sur la région de Goré beaucoup de travail de fait une chance : source bing avec une résolution suffisante mais beaucoup de question sur l'utilisation du sol -rivière Pendé : je suppose que sur Bing on a un aperçu en saison sèche à l'étiage. Quel est le régime hydro et quelle largeur de lit cartographier? les bancs de sables ? -occupation du sol : quelles sont les dénominations pertinentes savane, forêt, champs cultivés ? et quels tags à utiliser en conséquence ? un référentiel photo sur le blog serait assez utile pour faire le lien entre l'aspect de terrain et la photo interprétation. -sur les chemins, pistes, routes, il y a des incohérences, des chemins non raccordés, un peu trop de points sur certains chemins -habitat : serait-il pertinent de repérer tracer en zone résidentielle les villages de brousse qu'on peut repérer sur les photos ? -quelle est la réf de la route principale Google maps donne RN1 est ce que cela fait sens ? A distance depuis la France, on ne peut rien nommer, avez vous suffisament de temps, volontaires, connexion internet, pour pouvoir repasser derrière nous ? Quelle est selon vous la zone prioritaire sur laquelle se concentrer (vous sur le terrain et nous à distance) et pendant combien de temps ? bon courage Jeff Le mardi 18 décembre 2012 à 16:42 +0100, EUROSHA Tchad a écrit : Bonjour à tous, Seriez vous intéressés pour de la cartographie à distance au Tchad? Je fais partie des volontaires participant au projet pilote EUROSHA qui cherche à répondre aux questions humanitaires et à promouvoir spécifiquement le partage de l'information humanitaire dans la préparation aux crises: http://hot.openstreetmap.org/projects/eurosha_0 A ce titre, je suis déployée actuellement au Tchad avec cinq autres volontaires mais la tâche est grande dans un pays qui fait deux fois la France. Nous avons déjà cartographiés la ville de Goré et nous sommes désormais en train de travailler sur les camps de réfugiés d'Amboko, Gondjé et Dosseye. Un coup de main sur le reste du pays (N'Djaména, Moundou, Doba...) serait particulièrement le bienvenu! Aussi si vous êtes intéressés et avez des commentaires ou des questions, n'hésitez pas à nous contacter à eurosha.tc...@gmail.com Merci par avance, Aude Barraud ___ 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] OpenStreetMap au Tchad!
Le 19/12/2012 09:15, Ista Pouss a écrit : Le 18 décembre 2012 16:42, EUROSHA Tchad eurosha.tc...@gmail.com mailto:eurosha.tc...@gmail.com a écrit : Un coup de main sur le reste du pays (N'Djaména, Moundou, Doba...) serait particulièrement le bienvenu! Aussi si vous êtes intéressés et avez des commentaires ou des questions, n'hésitez pas à nous contacter à eurosha.tc...@gmail.com mailto:eurosha.tc...@gmail.com Pour info, J'ai un contact à Sarh : Une personne partie pour un an pour une projet de développement, pas très au fait d'OSM mais prête à donner un (petit) coup de main, notamment pour de la collecte d'info spécifique. Cette personne dispose d'un (mon) GPS Garmin Etex Legend avec carte OSM générée en septembre. Si nécessaire, je peux établir le lien. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
2012/12/19 Christophe Merlet red...@redfoxcenter.org: Merci et bravo pour l'effort. Mais il faut rappeler ici que ce cache n'est utile qu'à l'infrastructure globale d'OSM. Pour la France et les francophones en général, la seule solution restera de mettre en place notre propre server de tuiles avec rendu adapté (par exemple, utilisant de préférence les labels name:fr). Ca serait dommage qu'au final, on se repose uniquement sur l'infrastructure de wikipedia qui n'a pas les mêmes besoins de rendu que nous. (eux visent des cartes OSM internationalisées et exploitables pour leur encyclopédie alors que nous voulons un rendu utile aux contributeurs). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] layers et cadastre injoignables...
RDV pris pour le début d'après-midi... Le 19 décembre 2012 10:22, Christian Quest cqu...@openstreetmap.fr a écrit : Suite à une mise à jour malheureuse hier soir sur un de nos serveurs, layers et cadastre sont injoignable. Je pense pouvoir aller sur place remettre tout ça en fonctionnement cet après-midi. Désolé... ça m'apprendra à ne pas avoir pris le temps de configurer/tester l'IPMI/idrac sur les serveurs Dell chez Free. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Le mercredi 19 décembre 2012 à 11:14 +0100, Pieren a écrit : 2012/12/19 Christophe Merlet red...@redfoxcenter.org: Merci et bravo pour l'effort. Mais il faut rappeler ici que ce cache n'est utile qu'à l'infrastructure globale d'OSM. Pour la France et les francophones en général, la seule solution restera de mettre en place notre propre server de tuiles avec rendu adapté (par exemple, utilisant de préférence les labels name:fr). Ca serait dommage qu'au final, on se repose uniquement sur l'infrastructure de wikipedia qui n'a pas les mêmes besoins de rendu que nous. (eux visent des cartes OSM internationalisées et exploitables pour leur encyclopédie alors que nous voulons un rendu utile aux contributeurs). Ce rendu de tuiles existe déjà... http://tile.paulla.asso.fr/openlayers.html Il vous suffit de piocher sur http://[abc].tile.paulla.asso.fr/osm-fr/ et est aussi dispo osm-br, osm-ca, osm-eu et osm-oc. Librement, -- Christophe Merlet (RedFox) 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
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Je n'arrive pas à visualiser le résultat de mes ajouts du 27/11 (avec Nomino) de la balise name:fr pour les relations des provinces de Corée (niveau 4) http://www.openstreetmap.org/browse/changeset/14064905 http://tile.paulla.asso.fr/openlayers.html?zoom=7lat=36.02407lon=127.7179layers=B000FF même souci sur le toolserver http://toolserver.org/~osm/locale/fr.html?zoom=7lat=36.02407lon=127.7179layers=BT Une idée de ce qui peut clocher ? Et j'en profite pour saluer l'outil mis à disposition par Paulla Le 19 décembre 2012 11:25, Christophe Merlet red...@redfoxcenter.org a écrit : Le mercredi 19 décembre 2012 à 11:14 +0100, Pieren a écrit : 2012/12/19 Christophe Merlet red...@redfoxcenter.org: Merci et bravo pour l'effort. Mais il faut rappeler ici que ce cache n'est utile qu'à l'infrastructure globale d'OSM. Pour la France et les francophones en général, la seule solution restera de mettre en place notre propre server de tuiles avec rendu adapté (par exemple, utilisant de préférence les labels name:fr). Ca serait dommage qu'au final, on se repose uniquement sur l'infrastructure de wikipedia qui n'a pas les mêmes besoins de rendu que nous. (eux visent des cartes OSM internationalisées et exploitables pour leur encyclopédie alors que nous voulons un rendu utile aux contributeurs). Ce rendu de tuiles existe déjà... http://tile.paulla.asso.fr/openlayers.html Il vous suffit de piocher sur http://[abc].tile.paulla.asso.fr/osm-fr/ et est aussi dispo osm-br, osm-ca, osm-eu et osm-oc. Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus, Nadja ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Je m'auto répond : Je note à l'instant que les relations comprennent un noeud avec le rôle label, qui lui n'a pas de traduction. Je ne serais pas étonné qu'il soit à l'origine de ce souci, si la feuille de style lui donne la priorité pour le rendu ___ J'anticipe : don't feed the troll Le 19 décembre 2012 11:46, Ab_fab gamma@gmail.com a écrit : Je n'arrive pas à visualiser le résultat de mes ajouts du 27/11 (avec Nomino) de la balise name:fr pour les relations des provinces de Corée (niveau 4) http://www.openstreetmap.org/browse/changeset/14064905 http://tile.paulla.asso.fr/openlayers.html?zoom=7lat=36.02407lon=127.7179layers=B000FF même souci sur le toolserver http://toolserver.org/~osm/locale/fr.html?zoom=7lat=36.02407lon=127.7179layers=BT Une idée de ce qui peut clocher ? Et j'en profite pour saluer l'outil mis à disposition par Paulla Le 19 décembre 2012 11:25, Christophe Merlet red...@redfoxcenter.org a écrit : Le mercredi 19 décembre 2012 à 11:14 +0100, Pieren a écrit : 2012/12/19 Christophe Merlet red...@redfoxcenter.org: Merci et bravo pour l'effort. Mais il faut rappeler ici que ce cache n'est utile qu'à l'infrastructure globale d'OSM. Pour la France et les francophones en général, la seule solution restera de mettre en place notre propre server de tuiles avec rendu adapté (par exemple, utilisant de préférence les labels name:fr). Ca serait dommage qu'au final, on se repose uniquement sur l'infrastructure de wikipedia qui n'a pas les mêmes besoins de rendu que nous. (eux visent des cartes OSM internationalisées et exploitables pour leur encyclopédie alors que nous voulons un rendu utile aux contributeurs). Ce rendu de tuiles existe déjà... http://tile.paulla.asso.fr/openlayers.html Il vous suffit de piocher sur http://[abc].tile.paulla.asso.fr/osm-fr/ et est aussi dispo osm-br, osm-ca, osm-eu et osm-oc. Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus, Nadja -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus, Nadja ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Le mercredi 19 décembre 2012 à 11:46 +0100, Ab_fab a écrit : Je n'arrive pas à visualiser le résultat de mes ajouts du 27/11 (avec Nomino) de la balise name:fr pour les relations des provinces de Corée (niveau 4) http://www.openstreetmap.org/browse/changeset/14064905 http://tile.paulla.asso.fr/openlayers.html?zoom=7lat=36.02407lon=127.7179layers=B000FF même souci sur le toolserver http://toolserver.org/~osm/locale/fr.html?zoom=7lat=36.02407lon=127.7179layers=BT Une idée de ce qui peut clocher ? Je viens de regarder pour la relation Jeju http://www.openstreetmap.org/browse/relation/2398560 La traduction n'apparait pas sur la carte car cette relation utilise un noeud label qui lui n'est pas traduit http://www.openstreetmap.org/browse/node/1900155946 Or c'est ce label qui est affiché sur la carte... donc pas de traduction en français. J'imagine que c'est la même chose pour tes autres relations traduite avec Nomino. Et j'en profite pour saluer l'outil mis à disposition par Paulla Merci. Librement, -- Christophe Merlet (RedFox) 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
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Le mercredi 19 décembre 2012 à 12:02 +0100, Christophe Merlet a écrit : Le mercredi 19 décembre 2012 à 11:46 +0100, Ab_fab a écrit : Je n'arrive pas à visualiser le résultat de mes ajouts du 27/11 (avec Nomino) de la balise name:fr pour les relations des provinces de Corée (niveau 4) http://www.openstreetmap.org/browse/changeset/14064905 http://tile.paulla.asso.fr/openlayers.html?zoom=7lat=36.02407lon=127.7179layers=B000FF même souci sur le toolserver http://toolserver.org/~osm/locale/fr.html?zoom=7lat=36.02407lon=127.7179layers=BT Une idée de ce qui peut clocher ? Je viens de regarder pour la relation Jeju http://www.openstreetmap.org/browse/relation/2398560 La traduction n'apparait pas sur la carte car cette relation utilise un noeud label qui lui n'est pas traduit http://www.openstreetmap.org/browse/node/1900155946 Or c'est ce label qui est affiché sur la carte... donc pas de traduction en français. J'imagine que c'est la même chose pour tes autres relations traduite avec Nomino. En fait j'ai un doute. Je viens de greper les sources d'osm2pgsql et des feuilles de styles mapnik, à la recherche du mot label et je n'ai rien trouvé oO Donc j'ignore a quel moment le label est pris en compte... Librement, -- Christophe Merlet (RedFox) 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
Re: [OSM-talk-fr] registre parcellaire graphique, WMS et JOSM
Le 04/12/2012 06:29, Vincent de Chateau-Thierry a écrit : le Registre Parcellaire Graphique, c'est à dire les déclarations de cultures, par parcelles, dessinées par les agriculteurs sur fond photo. Pas exactement. Le registre parcellaire représente les îlots de cultures. Un îlot est constitué d'un ensemble de parcelles contigües et peut contenir plusieurs cultures. Les déclarations de cultures : les agriculteurs déclarent, le 30 avril de chaque année, les superficies des cultures, îlot par îlot. -- François ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] layers et cadastre injoignables...
On mercredi 19 décembre 2012, Christian Quest wrote: RDV pris pour le début d'après-midi... Merci à toi pour tout ce que tu fais, c'est pas franchement un truc que j'aimerais faire d'avoir à me déplacer sur des kms pour aller dépanner un serveur à titre bénévole. (Je me serais senti d'ailleurs super mal si c'est moi qui avait amené le problème d'avoir à faire déplacer quelqu'un) Si çà peut nous motiver pour nous pencher sur la question IPMI, ça ferait moins épée de damoclès -- sly, DWG member since 11/2012 Coordinateur du groupe [ga] http://wiki.openstreetmap.org/wiki/User:Sletuffe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [DWG actus] Ré-organisation des règles sur les imports et les édits en masse
Yo, Histoire de vous tenir au courant, j'ai sauté dans la fosse et commencé une ré-écriture des guidelines. Je m'excuse par avance, mais tout est en anglais, et nécessite une bonne connaissance de l'existent, de ce que fait le DWG et on en est même pas à les discuter, juste à les expliciter : http://wiki.openstreetmap.org/wiki/Draft/Edit_Policy Le débat est en cours sur la liste imports@ car j'ai pensé que c'était la liste la plus adaptée car la plupart des imports sont des edits automatiques pour lesquels je cherche à unifier les pratiques recommandées et obligatoires -- sly, DWG member since 11/2012 Coordinateur du groupe [ga] http://wiki.openstreetmap.org/wiki/User:Sletuffe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] layers et cadastre injoignables...
Le mercredi 19 décembre 2012 à 12:44 +0100, sly (sylvain letuffe) a écrit : On mercredi 19 décembre 2012, Christian Quest wrote: RDV pris pour le début d'après-midi... Merci à toi pour tout ce que tu fais, c'est pas franchement un truc que j'aimerais faire d'avoir à me déplacer sur des kms pour aller dépanner un serveur à titre bénévole. (Je me serais senti d'ailleurs super mal si c'est moi qui avait amené le problème d'avoir à faire déplacer quelqu'un) Si çà peut nous motiver pour nous pencher sur la question IPMI, ça ferait moins épée de damoclès Pour configurer l'IPMI SOL sur ubuntu 12.04 LTS dans /etc/default/grub : GRUB_TIMEOUT=5 GRUB_CMDLINE_LINUX=console=tty0 console=ttyS0,115200n81r GRUB_TERMINAL=console serial GRUB_SERIAL_COMMAND=serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1 Créer un getty sur ttyS0 /etc/init/ttyS0.conf # ttyS0 - getty # # This service maintains a getty on ttyS0 from the point the system is # started until it is shut down again. start on stopped rc or RUNLEVEL=[2345] stop on runlevel [!2345] respawn exec /sbin/getty -8 -h -L 115200 ttyS0 linux Dans le BIOS de la machine, vérifier que la redirection de console est activé sur le bon COM et à la bonne vitesse. Et bien sur que l'adresse IP de la BMC est accessible... Librement, -- Christophe Merlet (RedFox) 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
Re: [OSM-talk-fr] [forum-osm-fr] No man’s land secteur Brest
Le 22/11/2012 19:09, fo...@letuffe.org a écrit : En parcourant la carte de France, mon regard s’est arrêté sur une zone qui a tendance à attirer l’œil, c’est ici: [url]http://www.openstreetmap.org/?lat=48.33366394042969lon=-4.401741027832031zoom=12[/url] Que s’est il passé, ils ont asséché la rade de Brest ??!! :lol: Si on diminue le niveau de zoom, la baie de Douarnenez s'assèche également et la zone comprise entre Porspoder et Le Conquet s'enfonce dans l'océan. http://www.openstreetmap.org/?lat=48.33366394042969lon=-4.401741027832031zoom=9 -- François ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Voila c'est annoncé pour le Québec sur talk-ca. Un gros merci au père Noël et à Christophe. Pierre De : Christophe Merlet red...@redfoxcenter.org À : talk-fr@openstreetmap.org Envoyé le : Mercredi 19 décembre 2012 5h25 Objet : Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server Le mercredi 19 décembre 2012 à 11:14 +0100, Pieren a écrit : 2012/12/19 Christophe Merlet red...@redfoxcenter.org: Merci et bravo pour l'effort. Mais il faut rappeler ici que ce cache n'est utile qu'à l'infrastructure globale d'OSM. Pour la France et les francophones en général, la seule solution restera de mettre en place notre propre server de tuiles avec rendu adapté (par exemple, utilisant de préférence les labels name:fr). Ca serait dommage qu'au final, on se repose uniquement sur l'infrastructure de wikipedia qui n'a pas les mêmes besoins de rendu que nous. (eux visent des cartes OSM internationalisées et exploitables pour leur encyclopédie alors que nous voulons un rendu utile aux contributeurs). Ce rendu de tuiles existe déjà... http://tile.paulla.asso.fr/openlayers.html Il vous suffit de piocher sur http://[abc].tile.paulla.asso.fr/osm-fr/ et est aussi dispo osm-br, osm-ca, osm-eu et osm-oc. Librement, -- Christophe Merlet (RedFox) ___ 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] Label et rendu linguistique
osm2pgsql traite les noeuds avant les relations Le noeud a le rôle label dans la relation, mais c'est avant tout un noeud de type place Ici pour Jeju http://www.openstreetmap.org/browse/node/1900155946 où apparaît la description place = state Les noms traduits renseignés dans description de la relation n'apparaissent pas sur le rendu, tout simplement parce que la place est déjà prise par le nom inscrit sur le noeud place ? Je les sentais pas trop, ces noeuds avec un rôle label. Maintenant j'ai une bonne raison ... Le 19 décembre 2012 12:16, Christophe Merlet red...@redfoxcenter.org a écrit : Le mercredi 19 décembre 2012 à 12:02 +0100, Christophe Merlet a écrit : Le mercredi 19 décembre 2012 à 11:46 +0100, Ab_fab a écrit : Je n'arrive pas à visualiser le résultat de mes ajouts du 27/11 (avec Nomino) de la balise name:fr pour les relations des provinces de Corée (niveau 4) http://www.openstreetmap.org/browse/changeset/14064905 http://tile.paulla.asso.fr/openlayers.html?zoom=7lat=36.02407lon=127.7179layers=B000FF même souci sur le toolserver http://toolserver.org/~osm/locale/fr.html?zoom=7lat=36.02407lon=127.7179layers=BT Une idée de ce qui peut clocher ? Je viens de regarder pour la relation Jeju http://www.openstreetmap.org/browse/relation/2398560 La traduction n'apparait pas sur la carte car cette relation utilise un noeud label qui lui n'est pas traduit http://www.openstreetmap.org/browse/node/1900155946 Or c'est ce label qui est affiché sur la carte... donc pas de traduction en français. J'imagine que c'est la même chose pour tes autres relations traduite avec Nomino. En fait j'ai un doute. Je viens de greper les sources d'osm2pgsql et des feuilles de styles mapnik, à la recherche du mot label et je n'ai rien trouvé oO Donc j'ignore a quel moment le label est pris en compte... Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus, Nadja ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] layers et cadastre injoignables...
Le 19 décembre 2012 12:44, sly (sylvain letuffe) li...@letuffe.org a écrit : On mercredi 19 décembre 2012, Christian Quest wrote: RDV pris pour le début d'après-midi... Merci à toi pour tout ce que tu fais, c'est pas franchement un truc que j'aimerais faire d'avoir à me déplacer sur des kms pour aller dépanner un serveur à titre bénévole. (Je me serais senti d'ailleurs super mal si c'est moi qui avait amené le problème d'avoir à faire déplacer quelqu'un) Bah... ça m'a permis de faire mon inauguration perso du tram T2 entre La Défense et Pont de Bezons... donc de prendre un paquet de photos pour mapper aux alentours ;) Une pierre deux coup ! Si çà peut nous motiver pour nous pencher sur la question IPMI, ça ferait moins épée de damoclès J'ai configuré l'idrac (adresse IP et password) sur osm11 (que j'ai rebooté dans la foulée après un apt-get update/upgrade) et osm12. Il n'y a plus qu'à configurer les ports ethernet qui sont croisés entre les 2 machines (port N°4) pour accéder à l'autre machine... Je viens de remettre osm105 en route, donc layers et cadastre sont de retour. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Libération couche occupation du sol et Ortho-Photos aériennes de la réserve naturelle des Hauts plateaux du Vercors
Bonjour à toutes et à tous Le Parc naturel régional du Vercors vient de mettre sous licence ouverte la couche d'occupation du sol de 2005 dont je vous avais parlé en 2011 (je sais, ça date un peu), ainsi que les Ortho photos (résolution 1m) sur le secteur de la réserve naturelle des Hauts plateaux du Vercors. Ces données sont accompagnées de leurs métadonnées au format géosource xml. la page de téléchargement est ici : http://www.parc-du-vercors.fr/fr_FR/comprendre-et-partager-1110/telechargements-3115.html en espérant que ces données puisse vous intéresser bien cordialement Yann Buthion Chargé de mission SIG pour le Parc du Vercors ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Label et rendu linguistique
Le 19 décembre 2012 15:25, Ab_fab gamma@gmail.com a écrit : osm2pgsql traite les noeuds avant les relations Le noeud a le rôle label dans la relation, mais c'est avant tout un noeud de type place Ici pour Jeju http://www.openstreetmap.org/browse/node/1900155946 où apparaît la description place = state Les noms traduits renseignés dans description de la relation n'apparaissent pas sur le rendu, tout simplement parce que la place est déjà prise par le nom inscrit sur le noeud place ? Je les sentais pas trop, ces noeuds avec un rôle label. Maintenant j'ai une bonne raison ... Je trouve plutôt que ces place=state n'ont pas lieu d'exister lorsqu'une relation décrit l'emprise de ce niveau administratif et indique par un node label où mettre le nom sur le rendu. Par contre, il faudrait peut être rajouter un place=state sur les relations elles même car si on retire ce place=state le rendu mapnik n'indique plus les noms de nos régions françaises... je sais c'est limite tagguer pour le rendu, ou plutôt pour contourner les bugs du rendu ;) Voir aussi les impacts côté nominatim... car là aussi c'est pas forcément très cohérent. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Libération couche occupation du sol et Ortho-Photos aériennes de la réserve naturelle des Hauts plateaux du Vercors
Bonne nouvelle ! A rajouter sur wms.openstreetmap.fr ? Vincent ou JCG sur le coup ? Le 19 décembre 2012 15:59, y_buthion yann.buth...@pnr-vercors.fr a écrit : Bonjour à toutes et à tous Le Parc naturel régional du Vercors vient de mettre sous licence ouverte la couche d'occupation du sol de 2005 dont je vous avais parlé en 2011 (je sais, ça date un peu), ainsi que les Ortho photos (résolution 1m) sur le secteur de la réserve naturelle des Hauts plateaux du Vercors. Ces données sont accompagnées de leurs métadonnées au format géosource xml. la page de téléchargement est ici : http://www.parc-du-vercors.fr/fr_FR/comprendre-et-partager-1110/telechargements-3115.html en espérant que ces données puisse vous intéresser bien cordialement Yann Buthion Chargé de mission SIG pour le Parc du Vercors ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Extraire les limites administratives depuis le planet
Bonjour à tous je cherche à extraire les divisions administratives de tous les pays du monde depuis le planet OSM mais jusque là sans succès... Pour l'instant, j'ai fait quelques essais avec Osmosis (via Osmembrane et à la main) sur un fichier plus petit que le planet mondial mais sans trop de succès... Est-ce quelqu'un pourrait me dire ce qu'il y a d'incorrect là-dedans? *C:\Temp\Softs\Osmosis\bin\osmosis.bat \ --read-pbf file=C:\Temp\tmp\planet\tajikistan.osm.pbf \ --tag-filter accept-ways admin_level=* \ --used-node \ --write-xml file=C:\Temp\tmp\tests\tj_admin.osm * Osmosis 0.40.1 sous Windows 7 (désolé...) Merci d'avance et bonne fin de journée Stéphane -- Le mot progrès n'aura aucun sens tant qu'il y aura des enfants malheureux -- Albert Einstein A journey does not need reasons. Before long, it proves to be reason enough in itself. One thinks that one is going to make a journey, yet soon it is the journey that makes or unmakes you. -- Nicolas Bouvier Photos de voyages, photos de montagne: http://www.henriod.info ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Extraire les limites administratives depuis le planet
Tu n'aura pas tout malheureusement en ne gardant que les ways qui ont un tag boundary=administrative Une rivière ou un route peuvent servir de limite administrative, faire partie d'une relation boundary=administrative, mais ne pas avoir de tag boundary=* dessus. Il faut donc rajouter tout les ways faisant partie d'une relation boundary=administrative. Je ne suis pas familier des options d'osmosis, celles utilisées prennent-elles en compte ce cas de figure ? Le 19 décembre 2012 16:08, Stéphane Henriod s...@henriod.info a écrit : Bonjour à tous je cherche à extraire les divisions administratives de tous les pays du monde depuis le planet OSM mais jusque là sans succès... Pour l'instant, j'ai fait quelques essais avec Osmosis (via Osmembrane et à la main) sur un fichier plus petit que le planet mondial mais sans trop de succès... Est-ce quelqu'un pourrait me dire ce qu'il y a d'incorrect là-dedans? C:\Temp\Softs\Osmosis\bin\osmosis.bat \ --read-pbf file=C:\Temp\tmp\planet\tajikistan.osm.pbf \ --tag-filter accept-ways admin_level=* \ --used-node \ --write-xml file=C:\Temp\tmp\tests\tj_admin.osm Osmosis 0.40.1 sous Windows 7 (désolé...) Merci d'avance et bonne fin de journée Stéphane -- Le mot progrès n'aura aucun sens tant qu'il y aura des enfants malheureux -- Albert Einstein A journey does not need reasons. Before long, it proves to be reason enough in itself. One thinks that one is going to make a journey, yet soon it is the journey that makes or unmakes you. -- Nicolas Bouvier Photos de voyages, photos de montagne: http://www.henriod.info ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Extraire les limites administratives depuis le planet
Merci de ta réponse Christian! Je ne suis absolument pas certain que mon approche soit la meilleure et les raisons que tu mentionnes sont très pertinentes... Du coup, j'élargis ma question: quelle serait la meilleure approche (osmosis ou pas osmosis, c'est égal) pour extraire les limites des pays (admin_level = 2) ainsi que des 2 ou 3 principaux niveaux administratifs pour tous les pays du monde? Le but est une utilisation SIG générale. Je n'aurai pas besoin de mettre à jour régulièrement avec les diffs, je ne veux pas rendre avec Mapnik et n'ai donc pas besoin d'un schéma particulier... Tout ce qu'il me faut en sortie, c'est des polygones avec les attributs principaux (admin_level, nom) Quelqu'un aurait qqch à proposer? Merci! Stéphane PS: si il y a des fichiers déjà générés et qui sont téléchargeables quelque part, je prends aussi! -- Le mot progrès n'aura aucun sens tant qu'il y aura des enfants malheureux -- Albert Einstein A journey does not need reasons. Before long, it proves to be reason enough in itself. One thinks that one is going to make a journey, yet soon it is the journey that makes or unmakes you. -- Nicolas Bouvier Photos de voyages, photos de montagne: http://www.henriod.info 2012/12/19 Christian Quest cqu...@openstreetmap.fr Tu n'aura pas tout malheureusement en ne gardant que les ways qui ont un tag boundary=administrative Une rivière ou un route peuvent servir de limite administrative, faire partie d'une relation boundary=administrative, mais ne pas avoir de tag boundary=* dessus. Il faut donc rajouter tout les ways faisant partie d'une relation boundary=administrative. Je ne suis pas familier des options d'osmosis, celles utilisées prennent-elles en compte ce cas de figure ? Le 19 décembre 2012 16:08, Stéphane Henriod s...@henriod.info a écrit : Bonjour à tous je cherche à extraire les divisions administratives de tous les pays du monde depuis le planet OSM mais jusque là sans succès... Pour l'instant, j'ai fait quelques essais avec Osmosis (via Osmembrane et à la main) sur un fichier plus petit que le planet mondial mais sans trop de succès... Est-ce quelqu'un pourrait me dire ce qu'il y a d'incorrect là-dedans? C:\Temp\Softs\Osmosis\bin\osmosis.bat \ --read-pbf file=C:\Temp\tmp\planet\tajikistan.osm.pbf \ --tag-filter accept-ways admin_level=* \ --used-node \ --write-xml file=C:\Temp\tmp\tests\tj_admin.osm Osmosis 0.40.1 sous Windows 7 (désolé...) Merci d'avance et bonne fin de journée Stéphane -- Le mot progrès n'aura aucun sens tant qu'il y aura des enfants malheureux -- Albert Einstein A journey does not need reasons. Before long, it proves to be reason enough in itself. One thinks that one is going to make a journey, yet soon it is the journey that makes or unmakes you. -- Nicolas Bouvier Photos de voyages, photos de montagne: http://www.henriod.info ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ 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] Extraire les limites administratives depuis le planet
Bonjour, De : Christian Quest Tu n'aura pas tout malheureusement en ne gardant que les ways qui ont un tag boundary=administrative Une rivière ou un route peuvent servir de limite administrative, faire partie d'une relation boundary=administrative, mais ne pas avoir de tag boundary=* dessus. Il faut donc rajouter tout les ways faisant partie d'une relation boundary=administrative. Je ne suis pas familier des options d'osmosis, celles utilisées prennent-elles en compte ce cas de figure ? Voici une syntaxe que j'utilise pour le même type de besoin (mais restreint au niveau communal en France) : ./osmosis-0.40.1/bin/osmosis --rb file=france.osm.pbf --tf accept-relations admin_level=8 --used-way idTrackerType=BitSet --used-node idTrackerType=BitSet --wb file=france_admin_lev8.osm.pbf En gros : attaquer au niveau relation en spécifiant un critère avec --tf, et récupérer les membres ways et nodes à partir de là. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenStreetMap au Tchad!
On Tue, Dec 18, 2012 at 04:42:26PM +0100, EUROSHA Tchad wrote: Seriez vous intéressés pour de la cartographie à distance au Tchad? Par ailleurs, osmose tourne actuellement sur le Tchad. Ça peut donner des idées de contributions à certains, vu qu'il y a ~1500 erreurs, la plupart étant sur des tags un peu bizarre, des intersections de bâtiment, ou encore des ways non utilisés http://osmose.openstreetmap.fr/map/?zoom=6lat=15.28029lon=17.52661 http://osmose.openstreetmap.fr/errors/?country=chad -- Jocelyn ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Extraire les limites administratives depuis le planet
On Wed, Dec 19, 2012 at 04:15:03PM +0100, Christian Quest wrote: Il faut donc rajouter tout les ways faisant partie d'une relation boundary=administrative. Je ne suis pas familier des options d'osmosis, celles utilisées prennent-elles en compte ce cas de figure ? Ça me semble la bonne approche, et c'est possible avec Osmosis: osmosis ... \ --tf accept-relations boundary=administrative \ --used-ways \ --used-nodes \ ... Je n'ai pas testé, et je ne sais pas comment ça se comporte avec les relations de relations. Il est aussi possible que ça foire pour les frontières définies par un way fermée, sans la relation appropriée. Plus d'infos ici: http://wiki.openstreetmap.org/wiki/Osmosis/Detailed_Usage#--tag-filter_.28--tf.29 -- Jocelyn ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Extraire les limites administratives depuis le planet
Merci 1000! Ca a marché sur mon petit fichier, avec la commande suivante: C:\Temp\Softs\Osmosis\bin\osmosis.bat --read-pbf file=C:/Temp/tmp/planet/tajikistan.osm.pbf --tag-filter accept-relations boundary=administrative --used-way --used-node --write-xml file=C:/Temp/tmp/tests/tj_admin.osm Maintenant, on va tester sur le planet complet et voir si ça marche aussi bien ou pas... Bonne soirée! Stéphane -- Le mot progrès n'aura aucun sens tant qu'il y aura des enfants malheureux -- Albert Einstein A journey does not need reasons. Before long, it proves to be reason enough in itself. One thinks that one is going to make a journey, yet soon it is the journey that makes or unmakes you. -- Nicolas Bouvier Photos de voyages, photos de montagne: http://www.henriod.info 2012/12/19 Jocelyn Jaubert jocelyn.jaub...@gmail.com On Wed, Dec 19, 2012 at 04:15:03PM +0100, Christian Quest wrote: Il faut donc rajouter tout les ways faisant partie d'une relation boundary=administrative. Je ne suis pas familier des options d'osmosis, celles utilisées prennent-elles en compte ce cas de figure ? Ça me semble la bonne approche, et c'est possible avec Osmosis: osmosis ... \ --tf accept-relations boundary=administrative \ --used-ways \ --used-nodes \ ... Je n'ai pas testé, et je ne sais pas comment ça se comporte avec les relations de relations. Il est aussi possible que ça foire pour les frontières définies par un way fermée, sans la relation appropriée. Plus d'infos ici: http://wiki.openstreetmap.org/wiki/Osmosis/Detailed_Usage#--tag-filter_.28--tf.29 -- Jocelyn ___ 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] Extraire les limites administratives depuis le planet
Il faudra sûrement faire un mix des membres de relations + des way hors relation mais avec boundary=administrative + admin_level=xx et éventuellement rajouter les coastline... Ca sera nécessaire car je doute qu'il y ait une totale homogénéité sur les limites administratives sur tout le fichier planet par rapport à notre façon de faire dans notre hexagone élargi. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
On mercredi 19 décembre 2012, Christian Quest wrote: Un cache de tuile chez free Bezons diviserai mon ping presque par 2 (23ms en moyenne sur osm11) ;) Le geodns pourrait-il rediriger les requêtes provenant des AS de free vers un serveur chez free ? Je ne suis pas membre et encore moins décideur du groupe technique, donc de l'utilisation que nous devrions faire des serveurs qui y sont, mais je recommande vivement de réfléchir avant de proposer notre candidature pour monter un serveur de cache chez free. Et j'aurais plus coeur à défendre la création d'un serveur de rendu autonome pour toutes les raisons que j'ai évoqué sur dev-fr. Ce à quoi, je n'ai pas qu'une grande gueule, c'est exactement ce que je prévois de faire (moins quelques variations) -- sly, DWG member since 11/2012 Coordinateur du groupe [ga] http://wiki.openstreetmap.org/wiki/User:Sletuffe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Label et rendu linguistique
Dans ce que j'ai compris la valeur qu'on donne à place=* sert : - à guider le style d'apparence du label (taille de police, gras, italique, grandes capitales ou petites capitales, voire soulignement... pour différencier les communes des lieux dits, des zones commerciales ou quartiers, noms de parcs ou autres entités géographiques comme les îles, ou archipels, sommets de montagne ou nom de massifs) - ou a guider son apparition ou non sur la carte (selon l'échelle de rendu) car on ne peut pas tous les afficher : il faut faire des choix arbitraires basés sur limportance relative (mais avec un critère pas clair : s'agit-il de la population su lieu seul, ou de son agglomération entère, ou de son statut adminsitratif par rapport à un niveau administratif donné ?) Souvent ce n'est pas clair et pas toujours objectif (par exemple entre place=island et place=islet : on passe à la comparaison des surfaces mais on ne sait pas toujours ce qui est inclus dans la surface : seule la partie toujours émergée ou le plateau attenant avec ses rochers et plages découvertes à marée basse). La valeur de ce place=* est donc assez qualititatif et très subjectif (et trop souvent guidé en fonction du rendu attendu sur un moteur de rendu particulier)... En revanche le membre de rôle label dans une relation est non subjectif : il décrit d'abord une position adéquate dans la surface où il est approprié de placer le label pour qu'il ne puisse pas être confondu avec la désignation d'autre chose. Là où il se justifie le plus c'est pour nommer des surfaces fortement convaves, ou enserrant des enclaves, ou éclatées en pusieurs sous-zones écartées les unes des autres : le label doit se positionner dans la zone effective et le calcul d'un centroïde est faux. En théorie le membre de rôle label n'est pas nécessairement restreint à désigner un seul noeud et pourrait prendre la forme d'un chemin continu, permettant d'indiquer comment orienter un label au lieu de ne pouvoir l'afficher par défaut qu'horizontalement, et à préciser la longueur selon laquelle il devrait s'étaler (au lieu d'utiliser des caractères avec une approche normale et de restreindre arbitrairement la largeur de rendu de ce label en urilisant des sauts de ligne) : ce serait utile pour les massifs de montagne, dont les relations ont aussi des frontières floues, à condition que la feuille de style l'autorise (c'est généralement le cas pour les labels qui devraient recourir une zone très étendue de la carte affichée, avec des polices très grandes et des caractères assez gras pour rester lisibles mais semi-transparents pour ne pas cacher le reste en dessous. Les noms indiqués dans le label n'ont souvent guère d'importance : mais ils peuvent cependant être différents du nom classique utilisé pour désigner (hors du contexte de la carte elle-même) une région. En effet la carte fournit un contexte qu'il n'est pas nécessaire de rappeler, au contraire du nom utilisé pour désigner une région toute seule (ce nom doit être assez précis et descriptif, même si on a ôté de ce nom des éléments qui sont rappelés dans d'autres attributs, notamment le type générique d'objet). L'exemple typidque de simplification du nom dans un label est la suppression des prévisions qui lèvent l'ambiguité sur une homonymie simple. Pour ces raisons, les noms indiqués dans un label sont prioritaires sur ceux de la relation quand on devra choisir un nom signifiant pour un rendu cartographique (où ces noms seront aussi spatialement géolocalisés, et donc déjà différenciables sans ambiguïté par leur position). Les noms indiqués dans un label n'ont en revanche aucune utilité dans un rendu de type tableau de données (où figure ensuite un lieu vers la carte, ou bien une minicarte où les noms de zones sont remplacés par un petit numéro d'index dans chaque zone, le tableau de données référençant ensuite ce numéro, mais donnant le nom assez précis (sans homonymie) de la relation. Mais dans la plupart des cas, le label et le nom de la relation n'ont pas à être différents : si une relation a un membre label nommé, les noms données à la relation deviennent redondants, et il vaut mieux alors le mettre (avec ses traductions) dans le label. Attention : certains noms peuvent être homonymes dans une langue et pas dans une autre : il ne faudrait pas créer de nouvelles homonymies en transférant systématiquement les noms de relations vers leur label, et supposer alors que la relation est clairement (et uniquement) nommée d'après seulement son label (ce sera vrai pour un rendu cartographique, pas pour un rendu de ces noms dans un tableau de données) : on peut y copier des noms de la relation vers le label mais pas faire l'inverse du label vers la relation. Le 19 décembre 2012 15:59, Christian Quest cqu...@openstreetmap.fr a écrit : Le 19 décembre 2012 15:25, Ab_fab gamma@gmail.com a écrit : osm2pgsql traite les noeuds avant les relations Le noeud a le rôle label dans la relation, mais c'est avant tout un noeud de
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
C'est vrai que le problème de facturation concerne avant tout les applications très asymétriques en bande passante. Installer un cache Squid bien positionné dans la topologie du réseau est une solution pour réduire le déséquilibre des liens de peeering (sinon soit on paye le surplus, soit un se voit réduire drastiquement la bande passante). La Fondation Wikimedia ne diffuse pas que du contenu statique : les nombreuses pages de discussions et modifs de pages imposent que ce contenu change et n'entre plus dans les caches, même avec l'aide d'un CDN ou d'une série de serveur Squid managés par la fondation elle-même dans quelques GIX mondiaux stratégiques. Mais elle a aussi le même problème de charge sur ses moteurs de rendu MediaWiki : un cache ou un CDN ne peut pas tout résoudre, et il faut nécessairement monter aussi le nombre de serveurs de rendus et les mettre en réseau avec un système de distribution de la charge de travail (tout en veillant à ce que les serveurs de rendu puissent aussi disposer d'une bande passante suffisante et d'un bon temps de réponse pour rester synchronisés avec la base de données, la distribution de charge de travail sur la base de données elle-même étant un problème bien plus difficile (sauf si, comme actuellement, on accepte que les serveurs de rendus travaillent sur des réplications de la base avec un certain délai acceptable). Bref que l'on parle de la base de données OSM ou celle de Wikipédia, les difficultés pour monter en charge et garder la synchronisation acceptable en cas de distribution sont de même nature (la plus grosse difficulté est tout de même sur l'interface permettant de soumettre des modifications car on doit nécessairement s'appuyer sur une base maître chargée de lever les conflits et gérer le versionnement des contenus). Mais on n'est pas à la même échelle : le nombre de contributeurs actifs à Wikimédia est beaucoup plus élevé que ceux d'OSM, si on y inclut les pages de discussions, et surtout les envois massifs de photos vers Commons, qui sont eux aussi versionnés mais distribués par un système de répartition des répertoires, le goulot restant dans l'index général des fichiers et des catégories pour leur mise à jour). Heureusement les photos chargées sur Commons changent très peu, et pour ensuite les transférer vers les visiteurs les serveurs Squi ou les alliances avec les CDN ou FAI réduisent considérablement la bande passante de ces photos (mais très peu les pages de discussions et les données des profils d'utilisateurs qui nécessitent une modification des pages en cache pour y rajouter les données personnelles de profils, telles que les notifications en tête de page). Donc même pour les wikis de Wikimedia,les serveurs cache ou CDN ne sont pas suffisants pour la charge des pages HTML qui changent pour chaque visiteur et même à chaque rechargement d'une page par le même utilisateur. Le 19 décembre 2012 10:41, Christophe Merlet red...@redfoxcenter.org a écrit : Le mercredi 19 décembre 2012 à 00:26 +0100, Christian Quest a écrit : Constat proche pour moi (aussi chez free), le ping est quasiment identique (dans les 40/45ms) et même nombre de hops. Un cache de tuile chez free Bezons diviserai mon ping presque par 2 (23ms en moyenne sur osm11) ;) Le geodns pourrait-il rediriger les requêtes provenant des AS de free vers un serveur chez free ? Le GeoDNS redirige les IP par pays entier. Il ne semble pas y avoir de subdivision. De plus pour fournir un cache de tuiles à la fondation OSM, il y a quelques conditions à réunir... https://wiki.openstreetmap.org/wiki/Servers/Tile_CDN Concernant les temps d'accès, c'est un problème connu. Il y a un GIX à Pau sur lequel Axione et RENATER échangeait du trafic. Mais cela posait un petit problème... lorsqu'une université francilienne souhaitait accéder à un client citéFibre (à paris donc), il faisait un aller-retour à Pau... Les joies du routage Internet ! De plus, le routage n'est pas qu'un problème technique, c'est aussi et surtout un problème financier. Les opérateurs de transit facture la bande passante dans des rapports pouvant aller de 1 à 20 ! Donc il revient facilement moins cher d'aller faire son peering sur un GROS GIX fédérateur, voire à l'étranger que sur un nœud local. Des discussions d'il y a quelques années faisant un état des lieux... http://lafibre.info/paubc/index.php/topic,1704.0.html Pour ceux qui l'ignore, Pau est la première ville^Wagglo de France a avoir déployé son propre réseau FTTH. Il dessert plusieurs dizaines de milliers d'habitants https://fr.wikipedia.org/wiki/Pau_Broadband_Country Aujourd'hui, le plus grand FAI a destination du grand public utilisant ce réseau est SFR. Il a été rejoint cette année par Orange http://www.larepubliquedespyrenees.fr/2012/04/19/fibre-optique-premieres-offres-d-orange-avant-noel,232898.php On peut donc espérer qu'avec 4 gros opérateurs nationaux (RENATER, Axione, SFR, Orange) ils voient un intérêt financier à
Re: [OSM-talk-fr] [forum-osm-fr] No man’s land secteur Brest
C'est un bogue dans les exports de lignes de côte utilisées actuellement par Mapnik (qui contenaient un trou avant la génération de ce fichier). Ce bogue est là depuis maintenant plus d'un mois, les lignes de côtes n'ont toujours pas été remises à jour alors qu'il n'y a pas de problème dans les données de la base (il y a eu un problème pendant 2-3 jours dans ces données, avec un trou sur cette ligne de côte en rade de Brest, il a été vite corrigé, mais le fichier mondial des lignes de côtes a été généré à ce moment-là et PAS vérifié avant d'être importé sur Mapnik). Ce fichier des lignes de côtes a pourtant bien été recalculé et mis à jour en début de mois, mais il n'est pas encore chargé (peut-être parce qu'il a encore d'autres anomalies de continuité plus graves encore ailleurs dans le monde et que l'outil qui les génère ne sait pas les corriger tout seul, au moins en ajoutant des segments manquants avec une heuristique raisonnable). C'est ce fichier qui sert à dessiner le fond de la terre en blanc et la mer en bleu sur Mapnik. Tout le reste est dessiné à partir des données OSM à peu près à jour. On s'en rend compte quand on dessine de nouvelles petites îles ou quand on affine le tracé d'une ligne de côte : les frontières suivent, les limites de plages aussi, mais PAS les zones de terre vierges de tout landuse=* ou natural=* qui donc font apparaître encore un tracé erratique de la limite entre les zones blanches et bleues (pour que ces remplissages soient corrects, il faut patienter un temps démesurément long à cause de ce fichier pas mis à jour sur Mapnik) Puisque ce fichier destiné à Mapnik sert d'abord à éviter d'avoir à charger des lignes de côtes du monde entier pour savoir où remplir la mer, il serait préférable que ce ne soit pas UN SEUL fichier mais qu'il soit découpé arbitrairement sur des zones rectangulaires (par exemple tous les degrés). Je ne comprend de toute façon pas du tout l'utilité de ce fichier pour Mapnik, étant donné qu'on impose déjà (pour Mapnik justement !) une direction pour les lignes de côte (avec la terre à gauche et la mer à droite), ce qui permet de ne PAS avoir à charger les données du monde entier pour remplir correctement la mer en bleu. Uniquement avec cette règle d'orientation de la ligne de côte on peu se passer TOTALEMENT de ce fichier et utiliser directement les données OSM locales à la zone de la tuile à dessiner et seulement elles : C'est justement ce que fait Mapquest qui visiblement n'utilise pas du tout ce fichier des lignes de côtes (ou bien les remet à jour lui-même dans son cache local au fur et à mesure du chargement des données OSM nécessaires au rendu de ses tuiles et contenu parmi elles des segments de la ligne de côtes). Bref Mapnik a un bogue : - (1) du fait de la non-maintenance et non-vérification de ce fichier avant de l'utiliser, - (2) par le fait qu'il en dépend pour fonctionner alors qu'il devrait s'en passer totalement (en utilisant la direction du trait des lignes de côtes, il DOIT pouvoir fermer tout seul des tracés non fermés en mettant un trait de fermeture autour de la tuile rectangulaire, limité par le trait de côtes ouvert, et le bord de la tuile coupé par ce trait de côte en retenant le côté indiqué par l'orientation du trait, pour que le morceau de tuile coupé forme un anneau dessiné dans le sens horaire). Le 19 décembre 2012 14:09, François francois.le@free.fr a écrit : Le 22/11/2012 19:09, fo...@letuffe.org a écrit : En parcourant la carte de France, mon regard s’est arrêté sur une zone qui a tendance à attirer l’œil, c’est ici: [url]http://www.openstreetmap.**org/?lat=48.33366394042969** lon=-4.401741027832031zoom=**12[/url]http://www.openstreetmap.org/?lat=48.33366394042969lon=-4.401741027832031zoom=12[/url] Que s’est il passé, ils ont asséché la rade de Brest ??!! :lol: Si on diminue le niveau de zoom, la baie de Douarnenez s'assèche également et la zone comprise entre Porspoder et Le Conquet s'enfonce dans l'océan. http://www.openstreetmap.org/?**lat=48.33366394042969lon=-4.** 401741027832031zoom=9http://www.openstreetmap.org/?lat=48.33366394042969lon=-4.401741027832031zoom=9 -- François __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
C'est vrai que le gain n'est pas flagrant et en tout cas pas en vitesse c'est même plus long qu'avant en cas de cache-miss, j'ai déjà eu plusieurs interruptions de sessions (avec des tuiles incomplètes de taille zéro) à cause du temps de réponse du serveur de tuile principal à répondre à son serveur proxy Squid. Les problèmes commencent avec le zoom niveau 12 et on a des rafraîchissements qui ne se font quasiment plus concernant les tuiles obsolètes : il faut maintenant rafraîchir la même tuile deux fois avec quelques minutes d'écart entre chaque pour que ce soit dispo sur le Squid de Pau. Certes cela soulage certainement le serveur de Londres en bande passante, mais pas en travail à faire pour calculer les tuiles (qui du coup sont calculées et rendues disponibles pour finalement ne jamais être utilisées car la première requête a retourné l'ancienne version et remplis le cache Squid à Pau qui va donc continuer aussi à retourner cette version (le truc du /dirty ne semble plus fonctionner : oui il demande le rafraichissement mais cela ne force pas l'invalidation de tuiles du serveur de Pau (sauf si on modifie l'URL avec un paramètre GET ajouté dans lURL des tuiles tel que ?1, ?2 pour lui demander d'ignorer son cache et retourner la version du serveur de Londres ; le /dirty répété ne forcera plus non plus une nouvelle demande au serveur de rendu et le /status continue alors d'aficher l'ancien statut même si la tuile a bien été rafraichie à Londres). Il semble que la cause de tout ça vienne de Mapnik et non de l'installation du proxy-cache Qquid : au lieu de mettre une réponse au client en attente sur sa session, il préfère retourner une version ancienne déjà calculée (mais avec une durée de péremption trop longue pour cette réponse qui ne devrait être qu'instantanée et pas recachable en aval) en attendant pour terminer la session plus tôt (et cela pose des problèmes de cohérence de cache, un problème qui existe depuis assez longtemps même avant l'entrée en scène des serveurs proxy Squid). Squid ne semble pas en cause (cela marche très bien par exemple avec Wikipédia qui parvient très bien à suivre les mises à jour), mais bien le frontend de Mapnik (autrement dit le serveur WMS qui lui pilote son travail à faire). L'avantage de répondre immédiatement au client est d'économiser des sessions en attente du côté du serveur (et donc éviter la non disponibilité de nouveaux ports TCP pour d'autres sessions HTTP s'il y a du monde), mais ici le problème est la non péremption immédiate (ou la péremption trop longue) des tuiles obsolètes qui sont en attente de recalcul. A mon avis le serveur Squid pour la France, l'Espagne ou l'Italie serait mieux à Londres ou à Amsterdam, voire à Paris, plutôt qu'à Pau si on veut un temps de réponse correct, étant donné que les FAI français ont tous leur routage au départ de Paris avec un peering efficace vers Londres et Amsterdam. Même chose pour les FAI espagnols ou italiens qui feront leur peering efficace vers Pau en passant par Paris ou Amsterdam d'abord. Le peering de Paris vers Pau via le réseau RENATER n'est pas foundroyant, il n'a pas été tellement taillé pour un usage massif. La situation serait meilleure si la Fondation trouvait un partenariat avec des CDN mondiaux, comme Level3 qui a des serveurs proxy dans pratiquement tous les pays, et même dans les GIX régionaux (pour les FAI français qui ont des peerings régionaux et qui y sont directement connectés sans faire transiter tout le trafic de leurs abonnés par Paris). Le 18 décembre 2012 23:53, Eric Marsden eric.mars...@free.fr a écrit : cm == Christophe Merlet red...@redfoxcenter.org writes: cm Mais cette solution a plusieurs avantages. C'est facile à administrer à cm distance. ça ne nécessite pas de serveur puissant, juste de la RAM (en cm 9h, 18 Go de tuiles distinctes ont été demandées). L'intérêt d'un serveur distinct de celui à Londres pour les utilisateurs français me semble discutable. Depuis ma connexion Free au domicile à Toulouse, je suis à 63 ms (16 hops) de uppa-vl10-gi0-3-0-0-pau-rtr-011.noc.renater.fr, alors que je suis à 52 ms (15 hops) de me-rach.net.ic.ac.uk. J'imagine que c'est pareil pour la majorité des FAI français, qui font du peering vers Renater uniquement à Paris. Et en cas de miss la requête part quand même à Londres ... Ensuite depuis mon travail (connexion Renater) je suis à 3.8ms (7 hops) du serveur paulla, mais ça n'est pas très representatif des utilisateurs en général ... Ceci dit, j'imagine que ça décharge un peu le lien vers Imperial College, ce qui doit leur être utile, donc merci et bravo à RedFox pour cela. -- Eric Marsden ___ 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] Libération couche occupation du sol et Ortho-Photos aériennes de la réserve naturelle des Hauts plateaux du Vercors
On mercredi 19 décembre 2012, y_buthion wrote: Bonjour à toutes et à tous Bonjour, http://www.parc-du-vercors.fr/fr_FR/comprendre-et-partager-1110/telechargements-3115.html en espérant que ces données puisse vous intéresser Moi (mais je n'en doute pas, d'autres), ça pourrait en effet m'intéresser, très bonne initiative de votre part et merci ! Je ne sais pas si vous pourrez me répondre, mais la licence mentionne : Le « Réutilisateur » peut notamment s’acquitter de cette condition en indiquant un ou des liens hypertextes (URL) renvoyant vers « l’Information » et assurant une mention effective de sa paternité. Openstreetmap opte pour une solution consistant a lister les organismes desquels nous avons importé des données sur cette page : http://www.openstreetmap.org/copyright et celle-ci : http://wiki.openstreetmap.org/wiki/Attribution Et recommander à toute personne qui utilisera des données openstreetmap de faire un lien vers ces pages : http://wiki.openstreetmap.org/wiki/Legal_FAQ En outre, nous ajoutons dans des meta-données non loin des données elles-même ces informations. Cette solution vous semble-t-elle suffisante pour respecter votre attribution ? -- sly, DWG member since 11/2012 Coordinateur du groupe [ga] http://wiki.openstreetmap.org/wiki/User:Sletuffe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Le mercredi 19 décembre 2012 à 20:02 +0100, Philippe Verdy a écrit : C'est vrai que le gain n'est pas flagrant et en tout cas pas en vitesse c'est même plus long qu'avant en cas de cache-miss, j'ai déjà eu plusieurs interruptions de sessions (avec des tuiles incomplètes de taille zéro) à cause du temps de réponse du serveur de tuile principal à répondre à son serveur proxy Squid. Les problèmes commencent avec le zoom niveau 12 et on a des rafraîchissements qui ne se font quasiment plus concernant les tuiles obsolètes : il faut maintenant rafraîchir la même tuile deux fois avec quelques minutes d'écart entre chaque pour que ce soit dispo sur le Squid de Pau. Le serveur de Pau fonctionne de la même manière que celui de Londres. Il n'y a aucune différence entre les deux. Certes cela soulage certainement le serveur de Londres en bande passante, mais pas en travail à faire pour calculer les tuiles (qui du coup sont calculées et rendues disponibles pour finalement ne jamais être utilisées car la première requête a retourné l'ancienne version et remplis le cache Squid à Pau qui va donc continuer aussi à retourner cette version (le truc du /dirty ne semble plus fonctionner : oui il demande le rafraichissement mais cela ne force pas l'invalidation de tuiles du serveur de Pau (sauf si on modifie l'URL avec un paramètre GET ajouté dans lURL des tuiles tel que ?1, ?2 pour lui demander d'ignorer son cache et retourner la version du serveur de Londres ; le /dirty répété ne forcera plus non plus une nouvelle demande au serveur de rendu et le /status continue alors d'aficher l'ancien statut même si la tuile a bien été rafraichie à Londres). Le serveur GeoDNS de Londres ne calcule pas les tuiles. Pas plus que celui de Pau. Donc encore une fois tu digresses. A mon avis le serveur Squid pour la France, l'Espagne ou l'Italie serait mieux à Londres ou à Amsterdam, voire à Paris, plutôt qu'à Pau si on veut un temps de réponse correct, C'est quoi un temps de réponse correct ? Le peering de Paris vers Pau via le réseau RENATER n'est pas foundroyant, il n'a pas été tellement taillé pour un usage massif. ? oO La situation serait meilleure si la Fondation trouvait un partenariat avec des CDN mondiaux, comme Level3 qui a des serveurs proxy dans pratiquement tous les pays, et même dans les GIX régionaux (pour les FAI français qui ont des peerings régionaux et qui y sont directement connectés sans faire transiter tout le trafic de leurs abonnés par Paris). Un de tes problèmes parmi tant d'autres, c'est que tu passe tellement de temps à rédiger tes pavés, que tu ne lis pas les autres mails ! Librement, -- Christophe Merlet (RedFox) 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
Re: [OSM-talk-fr] [forum-osm-fr] No man’s land secteur Brest
Très exactement depuis la dernière génération des fichier shoreline_300 et process_p utilisés par Mapnik. Je les ai chargé il y a peu pour voir quelle tête ils avaient: ils datent du 29 Octobre et ont chacun un problème sur la pointe bretonne... Dommage que lors de la génération de ces fichiers, il n'y au pas un contrôle systématique de cohérence avant qu'il ne remplacent les précédents. Le 19 décembre 2012 20:00, Philippe Verdy verd...@wanadoo.fr a écrit : Ce bogue est là depuis maintenant plus d'un mois, les lignes de côtes n'ont toujours pas été remises à jour alors qu'il n'y a pas de problème dans les données de la base (il y a eu un problème pendant 2-3 jours dans ces données, avec un trou sur cette ligne de côte en rade de Brest, il a été vite corrigé, mais le fichier mondial des lignes de côtes a été généré à ce moment-là et PAS vérifié avant d'être importé sur Mapnik). -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Christophe Merlet a écrit à Philippe Un de tes problèmes parmi tant d'autres, c'est que tu passe tellement de temps à rédiger tes pavés, que tu ne lis pas les autres mails ! humour bref Christophe, c'est ce qui arrive quand le duo diabolique Sly et Philippe unit ses forces ! /bref humour :) Pierre ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Le 19 décembre 2012 21:00, Christophe Merlet red...@redfoxcenter.org a écrit : Le mercredi 19 décembre 2012 à 20:02 +0100, Philippe Verdy a écrit : C'est vrai que le gain n'est pas flagrant et en tout cas pas en vitesse c'est même plus long qu'avant en cas de cache-miss, j'ai déjà eu plusieurs interruptions de sessions (avec des tuiles incomplètes de taille zéro) à cause du temps de réponse du serveur de tuile principal à répondre à son serveur proxy Squid. Les problèmes commencent avec le zoom niveau 12 et on a des rafraîchissements qui ne se font quasiment plus concernant les tuiles obsolètes : il faut maintenant rafraîchir la même tuile deux fois avec quelques minutes d'écart entre chaque pour que ce soit dispo sur le Squid de Pau. Le serveur de Pau fonctionne de la même manière que celui de Londres. Il n'y a aucune différence entre les deux. Certes cela soulage certainement le serveur de Londres en bande passante, mais pas en travail à faire pour calculer les tuiles (qui du coup sont calculées et rendues disponibles pour finalement ne jamais être utilisées car la première requête a retourné l'ancienne version et remplis le cache Squid à Pau qui va donc continuer aussi à retourner cette version (le truc du /dirty ne semble plus fonctionner : oui il demande le rafraichissement mais cela ne force pas l'invalidation de tuiles du serveur de Pau (sauf si on modifie l'URL avec un paramètre GET ajouté dans lURL des tuiles tel que ?1, ?2 pour lui demander d'ignorer son cache et retourner la version du serveur de Londres ; le /dirty répété ne forcera plus non plus une nouvelle demande au serveur de rendu et le /status continue alors d'aficher l'ancien statut même si la tuile a bien été rafraichie à Londres). Le serveur GeoDNS de Londres ne calcule pas les tuiles. Pas plus que celui de Pau. Donc encore une fois tu digresses. Où ai-je parlé d'un serveur GeoDNS ? On parlait du serveur Squid jusquà présent. TU digresses. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] de l'utilisation de taginfo
Salut! cet outil taginfo http://taginfo.openstreetmap.fr/ est vraiment intéressant et bien utile! je m'en sers pour corriger certaines valeurs erronées sur la France exemple : school:FR = collegue, elementaire ou autre le lien vers josm permet de traiter tous les cas de la même erreur à la volée, idem pour les oneway improbables certains highway, cycleway, school:fr... pour les school:FR, on est passé de 96 valeurs différentes à 56, je pense qu'on peut encore bien réduire, mais c'est un début : je fais uniquement ce dont je suis sur idem sur les oneway de 16, on est autour de 10 désormais là où ça se corse c'est quand on a des valeurs doubles : genre maternelle;élémentaire que l'on taggue normalement en primaire, le lien ne donne pas la liste de cette erreur, mais le premier énoncé (donc les milliers de maternelles) idem sur les chaines de caractère vide ou les * : impossible d'en extraire la donnée pour la traiter dans josm est-ce que vous avez des solutions, pour me permettre de continuer ce travail, sans devoir mettre trop les mains dans le code? Bonne soirée Adrien http://taginfo.openstreetmap.fr/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] registre parcellaire graphique, WMS et JOSM
Le mardi 04 décembre 2012 à 17:52 +0100, Ab_fab a écrit : Message long, mais sujet intéressant, en particulier pour ta réflexion sur le regroupement des classes du RPG dans quelque chose de raisonnable pour osm. Pourrais-tu mettre ça à plat dans le wiki ? Voilà, j'ai commencé à écrire quelque chose sur le Registre Parcellaire Graphique : http://wiki.openstreetmap.org/wiki/WikiProject_France/data.gouv.fr/Occupation_du_sol Je ne sais pas trop si je dois décrire ma méthode de travail, c'est vraiment laborieux comme façon de faire... Mika ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] registre parcellaire graphique, WMS et JOSM
Le 19 décembre 2012 12:21, François francois.le@free.fr a écrit : Les déclarations de cultures : les agriculteurs déclarent, le 30 avril de chaque année, les superficies des cultures, îlot par îlot. Ils ne déclarent pas tout : sont souvent exclues les pâturages sur des terres exploitées en fermage gratuit (appartenant à des particuliers par exemple qui les laissent en pâturage plutôt que d'avoir à entretenir les terrains eux-mêmes, souvent il n'y a même aucun argent échangé, c'est un service de bon voisinage qui bénéficie au propriétaire comme à l'agriculture qui trouve des herbages). Parfois l'agriculteur va venir retourner la parcelle pour y resemer l'herbe, avec l'accord du propriétaire, afin que cela redevienne une pâture utilisable dans les mois qui suivent. On pourrait prendre ça comme un champ, il y a bien un usage agricole, mais ce n'est pas à lui de déclarer ça et le propriétaire n'est pas non plus obligé de déclarer ça puisqu'il ne tient pas une exploitation et ne reçoit aucune subvention non plus. Si on passe voir le terrain à ce moment là à vue d'œil sans connaitre les propriétaires ou fermiers du coin, on prendra ça pour un champ labouré, ou alors pour une pâture, alors que c'est juste temporaire (et en repassant plus tard on ne verra plus qu'une prairie inutilisée, voire une grande pelouse). Les propriétaires utilisent aussi le fermage gratuit parce qu'ils ont des obligations de désherber et d'entretenir leur terrain (surtout dans les régions ravagées par les incendies ou en lisière de forêt) : c'est beaucoup moins coûteux que d'envoyer des ouvriers nettoyer, d'autant que les simples brûlis nécessitent des précautions et n'est pas à la portée de n'importe qui. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Le 19/12/2012 21:17, Philippe Verdy a écrit : TU digresses. Et toi Philippe TU radotes : 2 mails à même pas 24h d'intervalle avec les 5 premiers pavés (pardon, paragraphes) identiques : http://lists.openstreetmap.org/pipermail/talk-fr/2012-December/052507.html http://lists.openstreetmap.org/pipermail/talk-fr/2012-December/052549.html À quoi ça rime ? S'il y a un intérêt dis-le, mais en moins de 20 mots. Chiche. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] de l'utilisation de taginfo
2012/12/19 adrien carpentier ad.carpent...@gmail.com: là où ça se corse c'est quand on a des valeurs doubles : genre maternelle;élémentaire que l'on taggue normalement en primaire, le lien ne donne pas la liste de cette erreur, mais le premier énoncé (donc les milliers de maternelles) Curieusement, ça marche sur le site original: http://taginfo.openstreetmap.org/tags/school%3AFR=%C3%A9l%C3%A9mentaire%3Bmaternelle Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Label et rendu linguistique
Le 19/12/2012 19:22, Philippe Verdy a écrit : Dans ce que j'ai compris la valeur qu'on donne à place=* sert : - à guider le style d'apparence du label (taille de police, gras, italique, grandes capitales ou petites capitales, voire soulignement... pour différencier les communes des lieux dits, des zones commerciales ou quartiers, noms de parcs ou autres entités géographiques comme les îles, ou archipels, sommets de montagne ou nom de massifs) - ou a guider son apparition ou non sur la carte (selon l'échelle de rendu) car on ne peut pas tous les afficher : il faut faire des choix arbitraires basés sur limportance relative (mais avec un critère pas clair : s'agit-il de la population su lieu seul, ou de son agglomération entère, ou de son statut adminsitratif par rapport à un niveau administratif donné ?) Souvent ce n'est pas clair et pas toujours objectif (par exemple entre place=island et place=islet : on passe à la comparaison des surfaces mais on ne sait pas toujours ce qui est inclus dans la surface : seule la partie toujours émergée ou le plateau attenant avec ses rochers et plages découvertes à marée basse). La valeur de ce place=* est donc assez qualititatif et très subjectif (et trop souvent guidé en fonction du rendu attendu sur un moteur de rendu particulier)... En revanche le membre de rôle label dans une relation est non subjectif : il décrit d'abord une position adéquate dans la surface où il est approprié de placer le label pour qu'il ne puisse pas être confondu avec la désignation d'autre chose. Là où il se justifie le plus c'est pour nommer des surfaces fortement convaves, ou enserrant des enclaves, ou éclatées en pusieurs sous-zones écartées les unes des autres : le label doit se positionner dans la zone effective et le calcul d'un centroïde est faux. Rien de plus subjectif que les objets label : ils sont clairement là pour la représentation de l'information, et en premier lieu pour la carte (placer le label, comme tu dis). Ce sont des objets cartographiques plus que géographiques, dont la position n'est pas déterminée par la situation géographique de ce qu'ils nomment, mais par l'anticipation d'une représentation carto. Autrement dit : je place le point label ici plutôt que là parce que j'ai en tête comment cela rendra sur une carte. Pour l'objectivité...on repassera. En théorie le membre de rôle label n'est pas nécessairement restreint à désigner un seul noeud et pourrait prendre la forme d'un chemin continu, permettant d'indiquer comment orienter un label au lieu de ne pouvoir l'afficher par défaut qu'horizontalement, et à préciser la longueur selon laquelle il devrait s'étaler (au lieu d'utiliser des caractères avec une approche normale et de restreindre arbitrairement la largeur de rendu de ce label en urilisant des sauts de ligne) : ce serait utile pour les massifs de montagne, dont les relations ont aussi des frontières floues, à condition que la feuille de style l'autorise (c'est généralement le cas pour les labels qui devraient recourir une zone très étendue de la carte affichée, avec des polices très grandes et des caractères assez gras pour rester lisibles mais semi-transparents pour ne pas cacher le reste en dessous. C'est déjà limite avec les points labels, ça devient flagrant avec des lignes label : on n'est plus dans la description du terrain mais dans la mise en forme d'une représentation, et par suite, en dehors d'OSM. Ce que tu décris a sa place sur une carte (la ligne de base d'un texte, etc.) mais pas dans la base _géographique_ OSM. Sans parler du fait qu'une telle ligne sera adaptée à une représentation à une échelle (ou plage d'échelles) donnée. On est bien là les deux pieds dans la carte. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bureau de vote
La modification du zonage est certes rare, mais beaucoup plus rare que les déplacements des lieux de scrutin. Habituellement une commune y consacre une salle communale ou une école, mais si elle est occupée à autre chose, elle trouvera un autre lieu public sans toucher au zonage, et même si le lieu n'est pas la zone définie. Les cas où le zonage vient à changer c'est quand la zone du bureau est devenue trop petite ou trop grande en nombre d'électeurs inscrits, mais tant que cela reste dans une fourchette de 1 à 2 dans toutes les zones de la commune, rien n'est touché. Mais si une seule zone devient trop grande, plusieurs autres zones voisines de la même commune peuvent être redécoupées, et les électeurs seront alors répartis sur des listes différentes et il faudra leur envoyer une nouvelle carte d'électeur mentionnant leur nouveau bureau (qui ne sera pas forcément dans leur propre zone). Il devrait toujours y avoir au moins un bureau par commune (pour les municipales), mais je me demande si pour les autres élections ce ne serait pas nécessairement le cas et s'il pourrait n'y avoir qu'une zone pour tout un canton, avec donc moins de bureaux que de communes (dans les régions très rurales avec très peu d'électeurs par commune, ces communes pouvant s'entendre pour faire voter leurs électeurs au même endroit, histoire de pouvoir assurer la durée de permanence légale — avec peut-être le bureau ouvert dans une commune le matin et dans l'autre voisine l'après-midi tout en restant ouvert toute la journée aux électeurs des deux communes). Je me demande aussi s'il y a obligation que le lieu de scrutin pour un bureau de vote de la commune soit toujours installé dans le territoire de la commune elle-même (déjà que ce lieu est très souvent hors du territoire du bureau, puisque les bureaux en zone urbaine sont très souvent regroupés par 2 ou 3 au même lieu, et dans la même salle si elle est assez grande). (dans certains pays peu équipés en salles communes en zone rurale et où les routes sont difficiles, c'est ce qui se passe : on déplace la liste d'émargement, l'urne et les assesseurs vers les électeurs, et le bureau de vote est dans un véhicule, par exemple un car). En France rien n'interdit une commune qui n'a temporairement pas de salle à disposition, de louer et faire venir un mobil-home sur un parking public, pour y installer un bureau de vote le temps des élections, et de l'enlever peu après. Elle peut aussi louer un local commercial, ou un logement inoccupé à un bailleur social, tant que l'accessibilité du public est garantie (portails ouverts, parcours fléché depuis la voie publique, affichage pré- et post-électoral réglementaire) et sécurisée (donc pas un chantier non plus). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Ils sont passés où les bâtiments???
J'utilise les fichiers shp de geofabrik pour alimenter en cartes vectorielles mon GPS Magellan Triton. Et je viens de constater qu'il n'y avait plus la couche buildings dans les fichiers fournis... Ils n'aiment pas nos zolis zimports du bati? Alors que c'était dispo dans la dernière extraction sous l'ancienne licence. Sniff Éric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Ils sont passés où les bâtiments???
Le mercredi 19 décembre 2012 23:27:19, Eric SIBERT a écrit : Alors que c'était dispo dans la dernière extraction sous l'ancienne licence. D'aucun diront que ça n'a rien à voir, voir le blog de F. Ramm à ce propos http://osm.gryph.de/2012/06/openbuildingmap/ L'article date du premier juin, le retrait effectif date d'un petit peu après les échanges colorés sur talk -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Navit sous Windows Mobile
Bonsoir, On m'a passé un smartphone HTC Touch HD T8282 qui tourne sous Windows Mobile 6.1. Je voulais utiliser Navit dessus pour faire du guidage routier sans connexion. J'ai installé le fichier .cab. Le programme démarre bien. Par contre, il ne récupère pas les coordonnées GPS alors qu'OSMTracker le fait sans problème. Une idée de comment faire? Je n'arrive pas non plus à lui faire utiliser la carte de France que j'ai téléchargé dans le même coin. Ou si vous avez d'autres proposition de navigation offline sur mon smartphone, je suis preneur. Éric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Label et rendu linguistique
Pas vraiment, fixer un label pour qu'il se place correctement SUR la zone qu'il désigne et pas aritrairement en un seul point (souvent mal placé et parfois en dehors si on n'utilise que le centroïde) donne une information fausse sur la carte. Déterminer un endroit qui couvre bien la zone est facile à faire indépendamment du type de rendu : cela ne fixe rien concernant l'obligation de placer le label uniquement à un seul point arbitraire, c'est indépendant de l'échelle de rendu. La seule alternative ce sont les labels le long de la frontière, mais là le label est encore plus flou sur ce qu'il désigne puisqu'on les affiche tous mélangés (à droite ou à gauche. La seule chose qu'on cherche à déterminer c'est une zone convexe située dans la surface et qui n'en déborde pas. Si la surface est concave, que faut-il couper pour que cela devienne convexe ? (1) Il existe bien un algo simple, déterminant un UNIQUE surface convexe MINIMALE englobant une surface concave (cette surface est la surface donnée elle-même si elle est convexe, c'est visiblement à partir de lui qu'on détermine le centroïde qui sort trop souvent des surfaces concaves, notamment des surfaces constituées de plusieurs parties exclavées — ce qui n'est acceptable que si le label qu'on centre dessus couvrira une partie essentielle de la surface qu'il désigne, ce qui ne se produit à faible niveau de zoom où on ne voit pratiquement pas que la surface est concave et s'assimile à un seul point central visible) (2) Mais il n'y a pas d'UNIQUE surface convexe MAXIMALE inscrite dans une surface concave : c'est pourtant là qu'on devrait y placer un label, qui devrait être le plus couvrant possible. On peut chercher à couper du polygone concave la plus petite aire possible (pour que la surface convexe restante ait l'aire la plus grande possible), mais dans certains cas, on aura encore le choix (si deux découpes possibles pour rendre la surface convexe ont la même aire). Si on n'a pas d'algorithme, où veux-tu placer le label, et comment le placer qu'il soit le plus représentatif possible de la zone qu'il recouvre et de celle qu'il désigne ? Le 19 décembre 2012 23:02, Vincent de Chateau-Thierry v...@laposte.net a écrit : Le 19/12/2012 19:22, Philippe Verdy a écrit : Dans ce que j'ai compris la valeur qu'on donne à place=* sert : - à guider le style d'apparence du label (taille de police, gras, italique, grandes capitales ou petites capitales, voire soulignement... pour différencier les communes des lieux dits, des zones commerciales ou quartiers, noms de parcs ou autres entités géographiques comme les îles, ou archipels, sommets de montagne ou nom de massifs) - ou a guider son apparition ou non sur la carte (selon l'échelle de rendu) car on ne peut pas tous les afficher : il faut faire des choix arbitraires basés sur limportance relative (mais avec un critère pas clair : s'agit-il de la population su lieu seul, ou de son agglomération entère, ou de son statut adminsitratif par rapport à un niveau administratif donné ?) Souvent ce n'est pas clair et pas toujours objectif (par exemple entre place=island et place=islet : on passe à la comparaison des surfaces mais on ne sait pas toujours ce qui est inclus dans la surface : seule la partie toujours émergée ou le plateau attenant avec ses rochers et plages découvertes à marée basse). La valeur de ce place=* est donc assez qualititatif et très subjectif (et trop souvent guidé en fonction du rendu attendu sur un moteur de rendu particulier)... En revanche le membre de rôle label dans une relation est non subjectif : il décrit d'abord une position adéquate dans la surface où il est approprié de placer le label pour qu'il ne puisse pas être confondu avec la désignation d'autre chose. Là où il se justifie le plus c'est pour nommer des surfaces fortement convaves, ou enserrant des enclaves, ou éclatées en pusieurs sous-zones écartées les unes des autres : le label doit se positionner dans la zone effective et le calcul d'un centroïde est faux. Rien de plus subjectif que les objets label : ils sont clairement là pour la représentation de l'information, et en premier lieu pour la carte (placer le label, comme tu dis). Ce sont des objets cartographiques plus que géographiques, dont la position n'est pas déterminée par la situation géographique de ce qu'ils nomment, mais par l'anticipation d'une représentation carto. Autrement dit : je place le point label ici plutôt que là parce que j'ai en tête comment cela rendra sur une carte. Pour l'objectivité...on repassera. En théorie le membre de rôle label n'est pas nécessairement restreint à désigner un seul noeud et pourrait prendre la forme d'un chemin continu, permettant d'indiquer comment orienter un label au lieu de ne pouvoir l'afficher par défaut qu'horizontalement, et à préciser la longueur selon laquelle il devrait s'étaler (au lieu d'utiliser des caractères avec une approche normale et de restreindre
Re: [OSM-talk-fr] Label et rendu linguistique
Le 19 décembre 2012 23:02, Vincent de Chateau-Thierry v...@laposte.net a écrit : Rien de plus subjectif que les objets label : ils sont clairement là pour la représentation de l'information, et en premier lieu pour la carte (placer le label, comme tu dis). Ce sont des objets cartographiques plus que géographiques, dont la position n'est pas déterminée par la situation géographique de ce qu'ils nomment, mais par l'anticipation d'une représentation carto. Autrement dit : je place le point label ici plutôt que là parce que j'ai en tête comment cela rendra sur une carte. Pour l'objectivité...on repassera. Je vois ça comme une aide au placement de texte, mais c'est vrai que c'est une info destinée uniquement au rendu et à utiliser ou pas en fonction... du rendu ;) Le placement de texte est un casse tête passionnant quand on veut produire une carte utile et lisible. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bureau de vote
Pour alimenter la digression... quid des communes sans liste électorale ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Ils sont passés où les bâtiments???
D'aucun diront que ça n'a rien à voir, voir le blog de F. Ramm à ce propos http://osm.gryph.de/2012/06/openbuildingmap/ Oui, je sais, les imports, c'est mal. Mais le pouvoir est immense du côté obscur du bâtiment ;-) Éric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Ils sont passés où les bâtiments???
Intéressant ce billet de blog... quand on lit entre les lignes. Moi qui dit souvent que dans OpenStreetMap la seule partie à retenir c'est Open parce qu'on se limite pas aux Street et que ça ne sert pas qu'à faire des Map. On aurait dû renommer le projet en OpenGeoData pour coller à la réalité ! (mais ESRI a une longueur d'avance) Le 19 décembre 2012 23:35, sly (sylvain letuffe) li...@letuffe.org a écrit : Le mercredi 19 décembre 2012 23:27:19, Eric SIBERT a écrit : Alors que c'était dispo dans la dernière extraction sous l'ancienne licence. D'aucun diront que ça n'a rien à voir, voir le blog de F. Ramm à ce propos http://osm.gryph.de/2012/06/openbuildingmap/ L'article date du premier juin, le retrait effectif date d'un petit peu après les échanges colorés sur talk -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Ils sont passés où les bâtiments???
There's *0 Comment* So Far Comments are closed on this post. Pourquoi F. Ramm influence ce que produit Geogabrik et ne veut pas qu'on y réponde ? Il critique le fait que les bâtiments n'aient pas de numéros alors que ce n'est pas une obligation d'une part (il se place dans le cadre de la géolocalisation des adresses, qui n'est qu'une toute petite partie de ce à quoi sert OSM et n'est PAS du tout une application cartographique : le Map dans le nom du projet disparait, cela devient juste OpenStreet). Si c'est le manque de numéros qui l'inquiète, c'est le cas partout dans le monde et l'absence des batiments sera un frein à leur introduction. J'aurais été lui j'aurais été plus critique vis à vis de CORINE (qui est un énorme import massif très eye candy, qui n'a pas la précision attendue, et qui ne sert à rien non plus en terme de géolocalisation). A force de combattre les imports, il va finir même par interdire toutes les données OpenData européennes. Et on n'aura plus de données de références où raccrocher le reste du contenu de la base, qui deviendra un bazar instable, très inégal, bourré d'erreurs d'approximations. A force de réagir comme ça, F. Ramm donne du grain à moudre pour ceux qui veulent un fork du projet. Et s'il le faut, la France prendra son indépendance et fera son propre OpenFranceMap. Et pourtant OSM vient de l'idée au départ de tenter de reproduire ce qu'il voyait en France dans les données publiques libres de l'époque pour tenter de faire cela aussi en Angleterre, sur une base permettant la réutilisation et la production de cartes libres avec plein de personnalisations et utilisations possibles (avant que cela sétende au reste du monde). F. Ramm a complètement oublié l'objectif initial du projet. Il est en train de le tuer dans ses fondations. Le 19 décembre 2012 23:35, sly (sylvain letuffe) li...@letuffe.org a écrit : Le mercredi 19 décembre 2012 23:27:19, Eric SIBERT a écrit : Alors que c'était dispo dans la dernière extraction sous l'ancienne licence. D'aucun diront que ça n'a rien à voir, voir le blog de F. Ramm à ce propos http://osm.gryph.de/2012/06/openbuildingmap/ L'article date du premier juin, le retrait effectif date d'un petit peu après les échanges colorés sur talk -- sly (sylvain letuffe) ___ 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] Ils sont passés où les bâtiments???
Donc à nous en France de faire ce que G. Ramm ne veut plus faire sur Geogabrik. Mais il va d'attirer aussi les foudres des utilisateurs britanniques qui ont fait un usage massif et démonstratif concernant Londres. Et de pas mal de pays qui ont avancé aussi sur le sujet même si cela ne couvre pas (encore) presque tout leur territoire comme en France. Tout cela va donc amener à des forks du projet OSM, pays par pays (certains se regrouperont sur des objectifs communs). C'est déjà commencé à l'Est de l'Europe. Cela risque fort d'arriver aussi au Royaume-Uni. Et Geofabrik continuera pour l'Allemagne avec OSM. (Mais je ne suis même pas sûr que les Allemands apprécieront aussi de voir leurs villes, qui commencent à avoir une carto des bâtiments dans les grandes villes, réduites à un ensemble de traits routiers). Pour des villes très denses, c'est une perte considérable si OSM (pour l'instant Geogabrik) commence à niveler sont objectif par le bas. Ce qu'on peut faire de notre côté pour éviter le fork, c'est refaire notre propre export supplémentaire des bâtiments, dans un fichier à part. mais avec la phobie de F.Ramm contre les bâtiments aussi dans la base, il va falloir en venir au développement d'OSM non plus comme une base unique mais comme un ensemble de bases représentant des couches de données différentes. Et ensuite revoir nos outils d'édition pour qu'ils sachent inscrire les données des bonnes couches dans les bonnes bases, en permettant de travailler sur plusieurs couches en même temps pour permettre les alignements corrects et permettre des collaborations comparatives, et des spécialisations thématiques des données selon ce qui intéresse chaque contributeur. On y viendra certainement, chaque couche ayant alors ses moteurs de rendus en couches transparentes superposables. Et peut-être même avec la possibilité depuis le même éditeur de contribuer à plusieurs bases ouvertes concurrentes (projets OSM, OFM, IGN, Google, Nokia...). OSM ne sera alors plus le vrac fourre-tout et ce sera sans doute un bien mieux pour tout le monde avec un projet plus facile à aborder, et permettant d'avoir des couches de référence stables, précises géométriquement, et complètes, même si dans certaines régions, faute de données suffisantes, on aura une couverture plus 'lâche avec moins de détails. Mais niveler par le bas revient à ne plus rien faire. F. Ramm visiblement semble ne plus vouloir faire confiance que dans les bases publiques et rien d'autre ailleurs (même si elles ont des tas d'erreurs ou oublis, puisqu'on ne pourra plus les mentionner dans OSM avec lui). Le 19 décembre 2012 23:52, Eric SIBERT courr...@eric.sibert.fr a écrit : D'aucun diront que ça n'a rien à voir, voir le blog de F. Ramm à ce propos http://osm.gryph.de/2012/06/**openbuildingmap/http://osm.gryph.de/2012/06/openbuildingmap/ Oui, je sais, les imports, c'est mal. Mais le pouvoir est immense du côté obscur du bâtiment ;-) Éric __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Le 19 décembre 2012 09:48, Cyrille Giquello cyrill...@gmail.com a écrit : Le 19 décembre 2012 01:00, Christophe Merlet red...@redfoxcenter.org a écrit : Le mardi 18 décembre 2012 à 23:53 +0100, Eric Marsden a écrit : cm == Christophe Merlet red...@redfoxcenter.org writes: cm Mais cette solution a plusieurs avantages. C'est facile à administrer à cm distance. ça ne nécessite pas de serveur puissant, juste de la RAM (en cm 9h, 18 Go de tuiles distinctes ont été demandées). L'intérêt d'un serveur distinct de celui à Londres pour les utilisateurs français me semble discutable. Depuis ma connexion Free au domicile à Toulouse, je suis à 63 ms (16 hops) de uppa-vl10-gi0-3-0-0-pau-rtr-011.noc.renater.fr, alors que je suis à 52 ms (15 hops) de me-rach.net.ic.ac.uk. J'imagine que c'est pareil pour la majorité des FAI français, qui font du peering vers Renater uniquement à Paris. Et en cas de miss la requête part quand même à Londres ... Ensuite depuis mon travail (connexion Renater) je suis à 3.8ms (7 hops) du serveur paulla, mais ça n'est pas très representatif des utilisateurs en général ... De chez moi (a Pau évidemment), en fibre optique, Londres est à 30ms, Pau est à... 40ms !! SFR m'envoie au SFINX, puis direction Lyon, et retour au point de départ via Bordeaux oo' Pire, il est censé y avoir un petit GIX local mais il ne fait pas preuve d'une grande efficacité :/ On espère voir la situation évoluer... Par contre au boulot, je suis à 0,3 ms... 2 switchs et 1 routeur ;o) Ceci dit, j'imagine que ça décharge un peu le lien vers Imperial College, ce qui doit leur être utile, donc merci et bravo à RedFox pour cela. Je pense que le serveur principal à gagné entre 10 et 20 mbs de bande passante sur plus de 100. Voir graphique en pièce jointe sur la courbe d'aujourd'hui par rapport aux jours précédents. C'est pas si mal pour commencer. Merci pour ce travail, c'est une excellente nouvelle. Ok le chemin vers Pau va être plus long mais le serveur de rendu sera moins chargé et c'est à mon avis ce qui compte le plus, partager la charge. Sinon, on dirait que de chez moi le routage n'est pas encore actif traceroute to a.tile.openstreetmap.org (193.63.75.98), 30 hops max, 60 byte packets 1 192.168.1.1 (192.168.1.1) 1.166 ms 2.835 ms 2.808 ms 2 * * * 3 153.226.70.86.rev.sfr.net (86.70.226.153) 72.387 ms 76.436 ms 76.420 ms 4 81.255.103.84.rev.sfr.net (84.103.255.81) 76.396 ms 78.996 ms 80.110 ms 5 146.133.64.86.rev.sfr.net (86.64.133.146) 85.690 ms 85.684 ms * 6 linx-gw1.ja.net (195.66.224.15) 97.748 ms 66.202 ms 54.794 ms 7 ae1.lond-sbr4.ja.net (146.97.35.181) 55.726 ms 57.377 ms 58.669 ms 8 ae12.read-sbr1.ja.net (146.97.33.141) 61.820 ms 63.552 ms 64.568 ms 9 be1.londic-rbr1.ja.net (146.97.35.150) 72.247 ms 72.251 ms 73.140 ms 10 imperial-college.ja.net (146.97.137.154) 74.123 ms 75.037 ms 75.920 ms 11 me-rach.net.ic.ac.uk (194.82.153.92) 77.125 ms 82.417 ms 82.379 ms Voilà, maintenant ça route bien vers Pau traceroute to b.tile.openstreetmap.org (193.55.222.229), 30 hops max, 60 byte packets 1 neufbox (192.168.1.1) 1.267 ms 1.398 ms 1.832 ms 2 * * * 3 153.226.70.86.rev.sfr.net (86.70.226.153) 46.273 ms 47.299 ms 49.233 ms 4 81.255.103.84.rev.sfr.net (84.103.255.81) 50.902 ms 52.396 ms 54.108 ms 5 146.133.64.86.rev.sfr.net (86.64.133.146) 56.113 ms 57.018 ms * 6 renater-ix1.sfinx.tm.fr (194.68.129.102) 67.690 ms 60.264 ms 63.042 ms 7 te0-3-1-0-lyon1-rtr-001.noc.renater.fr (193.51.189.126) 81.720 ms 66.789 ms 65.824 ms 8 te1-1-clermont-rtr-021.noc.renater.fr (193.51.189.170) 64.392 ms 63.986 ms 63.873 ms 9 te1-1-bordeaux-rtr-021.noc.renater.fr (193.51.189.165) 62.016 ms 61.153 ms 61.932 ms 10 po0-1-0-0-pau-rtr-011.noc.renater.fr (193.51.180.162) 65.149 ms 65.460 ms 65.965 ms 11 uppa-vl10-gi0-3-0-0-pau-rtr-011.noc.renater.fr (193.51.183.241) 63.892 ms 63.615 ms 65.481 ms -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bureau de vote
Tu parles des communes sans habitants ? S'il n'y a pas d'électeurs, il n'y a pas d'élections et pas d'élus non plus. Pas plus de bureau de vote. Ces communes sont gérées administrativement par le préfet (en collaboration avec le département et les communes voisines, avec un délégué préfectoral ad hoc dirigeant une commission exécutive, désigné mais pas élu, et qui peut être un fonctionnaire, voire un un élu d'une commune voisine bien que cette fonction ne soit pas directement dépendante de son mandat électoral : un élu local peut très bien être fonctionnaire de l'Etat, avec une activité qui déborde de sa commune d'élection. Je me demande si l'administration de ces communes peut entrer comme membre dans un EPCI (une communauté de communes par exemple), ne serait-ce que pour l'environnement et les déchets ou l'action culturelle de l'EPCI : bien que non habitées elles ne sont pas inoccupées et sans activité (elles peuvent donc avoir des entrées fiscales), ni domaine public routier ou patrimoine à entretenir (et aussi des monuments ou musées, avec du personnel) et sécuriser (donc aussi des charges) ; l'EPCI n'a lui non plus aucun élu mais que des représentants désignés par les communes, finalement une statut assez similaire à celui du délégué préfectoral gérant une commune inhabitée. Le 19 décembre 2012 23:48, Christian Quest cqu...@openstreetmap.fr a écrit : Pour alimenter la digression... quid des communes sans liste électorale ? ___ 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] api.openstreetmap.fr en panne ?
Hello, On dirait que http://api.openstreetmap.fr/api ne fonctionne plus (2012-12-20 00:34). JOSM n'arrive plus à charger des données depuis le service. Il bloque pendant longtemps sur Téléchargement des données OSM ... puis Aucune donnée n'a été trouvée dans cette zone. -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Le premier n'était pas parti selon Google, et je n'ai reçu qu'une copie, la deuxième. C'est sans doute le serveur de mail de cette liste qui a eu un raté le première fois, expliquant pourquoi Google l'a gardé, ou alors il a été mal reçu la première fois (non confirmation de la transaction) et renvoyé automatiquement le lendemain. Le 19 décembre 2012 22:39, Vincent de Chateau-Thierry v...@laposte.net a écrit : Le 19/12/2012 21:17, Philippe Verdy a écrit : TU digresses. Et toi Philippe TU radotes : 2 mails à même pas 24h d'intervalle avec les 5 premiers pavés (pardon, paragraphes) identiques : http://lists.openstreetmap.**org/pipermail/talk-fr/2012-** December/052507.htmlhttp://lists.openstreetmap.org/pipermail/talk-fr/2012-December/052507.html http://lists.openstreetmap.**org/pipermail/talk-fr/2012-** December/052549.htmlhttp://lists.openstreetmap.org/pipermail/talk-fr/2012-December/052549.html À quoi ça rime ? S'il y a un intérêt dis-le, mais en moins de 20 mots. Chiche. vincent __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Le jeudi 20 décembre 2012 à 00:43 +0100, Philippe Verdy a écrit : Le premier n'était pas parti selon Google, et je n'ai reçu qu'une copie, la deuxième. C'est sans doute le serveur de mail de cette liste qui a eu un raté le première fois, expliquant pourquoi Google l'a gardé, ou alors il a été mal reçu la première fois (non confirmation de la transaction) et renvoyé automatiquement le lendemain. T'es sûr ? C'est possible ? ya 3h tu nous disais tous le contraire.. je te cites : Je les ai lu au moment où je les ai reçus sans retard, et je sais même avant de poster s'il y a eu une réponse entre temps (Gmail m'avertit tout de suite pratiquement à la seconde : je le sais lorsque je suis en discussion au téléphone et que j'envoie un mail à la même personne, le délai pour que la personne au bout du fil ait le mail n'excède pas quelques secondes ; même chose quand c'est elle qui m'envoie un mail, et c'est pratiquement la seconde dans les deux sens, si on est tous les deux sur Gmail). Maintenant il est possible que tu ne reçoives pas les messages dans le même ordre et que des réponses des uns et des autres se croisent. Donc n'interprète pas un désordre apparent entre des messages des uns et des autres qui se succèdent en quelques minutes (selon la vitesse que met chaque FAI à livrer ses mails dans les boites aux lettres). Je t'épargnes les en-têtes de tes mails qui prouve qu'ils ont circulé en temps et en heure ! En tout cas tu nous fait bien rire, on a anticipé ta réponse ! [23:33] xx RedFox: ça serait un bug de la mailing list visant notre pauvre philippe que ça m'étonnerait pas [23:34] xx c'est toujours sur lui que ça tombe [23:34] RedFox arfff :D Librement, -- Christophe Merlet (RedFox) 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
Re: [OSM-talk-fr] api.openstreetmap.fr en panne ?
Le jeudi 20 décembre 2012 00:41:28, Cyrille Giquello a écrit : Hello, On dirait que http://api.openstreetmap.fr/api ne fonctionne plus (2012-12-20 00:34). Service à tout heure dépanage ! Voilà qui est réparé. Dommage collatéral du reboot de cette nuit -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
tracert b.tile.openstreetmap.org Détermination de l'itinéraire vers pau.tile.openstreetmap.org[193.55.222.229] avec un maximum de 30 sauts : 1 8 ms13 ms13 ms 10.33.128.1 212 ms13 ms21 ms ip-4.net-80-236-5.static.numericable.fr[80.236.5.4] 333 ms40 ms36 ms ip-190.net-80-236-0.static.numericable.fr[80.236.0.190] 434 ms30 ms31 ms ip-185.net-80-236-0.static.numericable.fr[80.236.0.185] 548 ms43 ms65 ms 172.19.130.14 652 ms45 ms51 ms renater.franceix.net [193.105.232.19] 768 ms62 ms63 ms te0-1-0-0-orleans-rtr-011.noc.renater.fr[193.51.189.146] 861 ms67 ms62 ms te0-2-0-0-poitiers-rtr-011.noc.renater.fr[193.51.189.158] 956 ms56 ms57 ms te1-3-bordeaux-rtr-021.noc.renater.fr[193.51.189.94] 1067 ms63 ms87 ms po0-1-0-0-pau-rtr-011.noc.renater.fr[193.51.180.162] 1166 ms66 ms63 ms uppa-vl10-gi0-3-0-0-pau-rtr-011.noc.renater.fr [193.51.183.241] 12 *** Délai d'attente de la demande dépassé. 1356 ms55 ms59 ms reserve1.paulla.asso.fr [193.55.222.229] Itinéraire déterminé. (Test effectué en WiFi N, au lieude l'Ethernet Gigabit que je pourrais tester aussi, mais cela rajoute moins de 2ms). Pour Numericable (fibre FTTB), ça part de Niort à Paris en 8-13 ms mais le plus gros du temps est sur les routeurs internes de Numéricable à Paris, vers le GIX parisien de Renater (pas loin de 40ms). Ensuite 8-10ms pour redescendre à Pau (en repassant par Poitiers...). Visiblement là où ça coince le plus c'est sur le peering d'interconnexion du GIX vers RENATER. Renater n'est pas en cause mais bien le FAI vers FranceIX (j'ai à peu près le même délai sur les GIX d'interconnexion internationale, mais beaucoup moins vers les autres FAI grand publics (Orange, SFR, Free) ou vers Google (total voisin de 40ms, inclus les 8-13ms de Numéricable entre Niort et son premier routeur publiquement accessible à Paris), car il perd moins de temps sur ces autres peerings mieux dimensionnés. Toi tu passe par Sfinx Lyon où SFR se connecte à Renater, et c'est encore moins bon alors que ça emprunte une route régionale transversale sans aller-retour à Paris (mais entre Sfinx et Pau ça marche bien). Ça confirme qu'il vaut mieux en France être hébergé à Paris, même si le traffic fait l'aller-retour. Les FAI sont stupides (là je parle de SFR, mon ancien opérateur, mais aussi de Numericable et les autres qui ont mis en place leur peering en étoile qui devient un goulet à Paris dès qu'on change de réseau). Le 20 décembre 2012 00:29, Cyrille Giquello cyrill...@gmail.com a écrit : Le 19 décembre 2012 09:48, Cyrille Giquello cyrill...@gmail.com a écrit : Le 19 décembre 2012 01:00, Christophe Merlet red...@redfoxcenter.org a écrit : Le mardi 18 décembre 2012 à 23:53 +0100, Eric Marsden a écrit : cm == Christophe Merlet red...@redfoxcenter.org writes: cm Mais cette solution a plusieurs avantages. C'est facile à administrer à cm distance. ça ne nécessite pas de serveur puissant, juste de la RAM (en cm 9h, 18 Go de tuiles distinctes ont été demandées). L'intérêt d'un serveur distinct de celui à Londres pour les utilisateurs français me semble discutable. Depuis ma connexion Free au domicile à Toulouse, je suis à 63 ms (16 hops) de uppa-vl10-gi0-3-0-0-pau-rtr-011.noc.renater.fr, alors que je suis à 52 ms (15 hops) de me-rach.net.ic.ac.uk. J'imagine que c'est pareil pour la majorité des FAI français, qui font du peering vers Renater uniquement à Paris. Et en cas de miss la requête part quand même à Londres ... Ensuite depuis mon travail (connexion Renater) je suis à 3.8ms (7 hops) du serveur paulla, mais ça n'est pas très representatif des utilisateurs en général ... De chez moi (a Pau évidemment), en fibre optique, Londres est à 30ms, Pau est à... 40ms !! SFR m'envoie au SFINX, puis direction Lyon, et retour au point de départ via Bordeaux oo' Pire, il est censé y avoir un petit GIX local mais il ne fait pas preuve d'une grande efficacité :/ On espère voir la situation évoluer... Par contre au boulot, je suis à 0,3 ms... 2 switchs et 1 routeur ;o) Ceci dit, j'imagine que ça décharge un peu le lien vers Imperial College, ce qui doit leur être utile, donc merci et bravo à RedFox pour cela. Je pense que le serveur principal à gagné entre 10 et 20 mbs de bande passante sur plus de 100. Voir graphique en pièce jointe sur la courbe d'aujourd'hui par rapport aux jours précédents. C'est pas si mal pour commencer. Merci pour ce travail, c'est une excellente nouvelle. Ok le chemin vers Pau va être plus long mais le serveur de rendu sera moins chargé et c'est à mon avis ce qui compte le plus, partager la charge. Sinon, on dirait que de chez moi le routage n'est pas encore actif traceroute to a.tile.openstreetmap.org (193.63.75.98), 30 hops max, 60
Re: [OSM-talk-fr] api.openstreetmap.fr en panne ?
Le 20 décembre 2012 01:01, sly (sylvain letuffe) li...@letuffe.org a écrit : Le jeudi 20 décembre 2012 00:41:28, Cyrille Giquello a écrit : Hello, On dirait que http://api.openstreetmap.fr/api ne fonctionne plus (2012-12-20 00:34). Service à tout heure dépanage ! Voilà qui est réparé. Super cool monsieur 24/24 ;-) Les données ... à rattraper ou bien à jour ? -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Bogue de Gmail alors (dans son interface web). Je n'ai qu'une seule copie reçue et je n'ai certainement fait aucun copier-coller d'un mail à l'autre. Je ne sais pas pourquoi le 1er mail est parti plus tôt mais incomplet et réexpédié complet 20h plus tard. Le 20 décembre 2012 01:00, Christophe Merlet red...@redfoxcenter.org a écrit : Le jeudi 20 décembre 2012 à 00:43 +0100, Philippe Verdy a écrit : Le premier n'était pas parti selon Google, et je n'ai reçu qu'une copie, la deuxième. C'est sans doute le serveur de mail de cette liste qui a eu un raté le première fois, expliquant pourquoi Google l'a gardé, ou alors il a été mal reçu la première fois (non confirmation de la transaction) et renvoyé automatiquement le lendemain. T'es sûr ? C'est possible ? ya 3h tu nous disais tous le contraire.. je te cites : Je les ai lu au moment où je les ai reçus sans retard, et je sais même avant de poster s'il y a eu une réponse entre temps (Gmail m'avertit tout de suite pratiquement à la seconde : je le sais lorsque je suis en discussion au téléphone et que j'envoie un mail à la même personne, le délai pour que la personne au bout du fil ait le mail n'excède pas quelques secondes ; même chose quand c'est elle qui m'envoie un mail, et c'est pratiquement la seconde dans les deux sens, si on est tous les deux sur Gmail). Maintenant il est possible que tu ne reçoives pas les messages dans le même ordre et que des réponses des uns et des autres se croisent. Donc n'interprète pas un désordre apparent entre des messages des uns et des autres qui se succèdent en quelques minutes (selon la vitesse que met chaque FAI à livrer ses mails dans les boites aux lettres). Je t'épargnes les en-têtes de tes mails qui prouve qu'ils ont circulé en temps et en heure ! En tout cas tu nous fait bien rire, on a anticipé ta réponse ! [23:33] xx RedFox: ça serait un bug de la mailing list visant notre pauvre philippe que ça m'étonnerait pas [23:34] xx c'est toujours sur lui que ça tombe [23:34] RedFox arfff :D Librement, -- Christophe Merlet (RedFox) ___ 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] api.openstreetmap.fr en panne ?
Le jeudi 20 décembre 2012 01:09:44, Cyrille Giquello a écrit : Les données ... à rattraper ou bien à jour ? En effet, j'ai oublié de préciser, c'est en retard de ~20h mais je viens de basculer l'édition (/api) en mode proxy pour éviter les surprises -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Le jeudi 20 décembre 2012 à 01:04 +0100, Philippe Verdy a écrit : tracert b.tile.openstreetmap.org Toi tu passe par Sfinx Lyon où SFR se connecte à Renater, et c'est encore moins bon alors que ça emprunte une route régionale transversale sans aller-retour à Paris (mais entre Sfinx et Pau ça marche bien). Ça confirme qu'il vaut mieux en France être hébergé à Paris, même si le traffic fait l'aller-retour. Les FAI sont stupides (là je parle de SFR, mon ancien opérateur, mais aussi de Numericable et les autres qui ont mis en place leur peering en étoile qui devient un goulet à Paris dès qu'on change de réseau). Il n'y a pas de sfinx à Lyon, il est a paris. Donc SFR ne peer pas avec Renater à lyon, donc ce que tu as écrit n'a pas de sens ! Tu as une imagination débordante. Pourquoi n'utilises tu pas ce talent pour écrire des contes pour enfant pour les endormir ? Librement, -- Christophe Merlet (RedFox) 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
Re: [OSM-talk-fr] api.openstreetmap.fr en panne ?
Le 20 décembre 2012 01:09, Cyrille Giquello cyrill...@gmail.com a écrit : Le 20 décembre 2012 01:01, sly (sylvain letuffe) li...@letuffe.org a écrit : Le jeudi 20 décembre 2012 00:41:28, Cyrille Giquello a écrit : Hello, On dirait que http://api.openstreetmap.fr/api ne fonctionne plus (2012-12-20 00:34). Service à tout heure dépanage ! Voilà qui est réparé. Super cool monsieur 24/24 ;-) Les données ... à rattraper ou bien à jour ? À voilà, c'est à jour. À force d'être servis de suite, on devient impatient ;-P -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] api.openstreetmap.fr en panne ?
Le 20 décembre 2012 01:16, sly (sylvain letuffe) li...@letuffe.org a écrit : Le jeudi 20 décembre 2012 01:09:44, Cyrille Giquello a écrit : Les données ... à rattraper ou bien à jour ? En effet, j'ai oublié de préciser, c'est en retard de ~20h mais je viens de basculer l'édition (/api) en mode proxy pour éviter les surprises Alors un reminder pour dans 20h ;-) Encore merci pour tout ce taf, formidable !! -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bureau de vote
Bon, j'ai intégré les bureaux de vote d'Orange et leur zonage de la façon suivante: - un noeud avec polling_station:ref=nn voir nn;nn;nn lorsque plusieurs bureaux sont dans le même lieu sans connaitre leur localisation exacte - une relation type=boundary + boundary=polling_station + ref = numéro du bureau, avec les ways définissant la zone avec des rôles outer/inner et un node (voire way) avec le role polling_station pour le bureau lui même. Je pense que de cette façon on peut passer du bureau à la zone et inversement et qu'avec la zone, on peut extraire les adresses figurant à l'intérieur. Très instructif de voir ce découpage électoral qui tient parfois vraiment du charcutage... et vas-y que je te met un micro pâté de maison dans le bureau d'à côté ;) http://www.openstreetmap.org/?relation=2649373 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] api.openstreetmap.fr en panne ?
Le jeudi 20 décembre 2012 01:18:38, Cyrille Giquello a écrit : Alors un reminder pour dans 20h ;-) Exact. Christian va encore me dire que je devrais automatiser ça (et il a raison) -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] api.openstreetmap.fr en panne ?
Tu devrais automatiser tout ça ;) Le 20 décembre 2012 01:35, sly (sylvain letuffe) li...@letuffe.org a écrit : Le jeudi 20 décembre 2012 01:18:38, Cyrille Giquello a écrit : Alors un reminder pour dans 20h ;-) Exact. Christian va encore me dire que je devrais automatiser ça (et il a raison) -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] api.openstreetmap.fr en panne ?
2012/12/20 Christian Quest cqu...@openstreetmap.fr: Tu devrais automatiser tout ça ;) Sly, tu as ton doudou pour te tenir compagnie !! ;-) Cyrille. Le 20 décembre 2012 01:35, sly (sylvain letuffe) li...@letuffe.org a écrit : Le jeudi 20 décembre 2012 01:18:38, Cyrille Giquello a écrit : Alors un reminder pour dans 20h ;-) Exact. Christian va encore me dire que je devrais automatiser ça (et il a raison) -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] api.openstreetmap.fr en panne ?
Non, il prépare un plan diabolique avec Philippe. Pierre De : Cyrille Giquello cyrill...@gmail.com À : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Mercredi 19 décembre 2012 19h55 Objet : Re: [OSM-talk-fr] api.openstreetmap.fr en panne ? 2012/12/20 Christian Quest cqu...@openstreetmap.fr: Tu devrais automatiser tout ça ;) Sly, tu as ton doudou pour te tenir compagnie !! ;-) Cyrille. Le 20 décembre 2012 01:35, sly (sylvain letuffe) li...@letuffe.org a écrit : Le jeudi 20 décembre 2012 01:18:38, Cyrille Giquello a écrit : Alors un reminder pour dans 20h ;-) Exact. Christian va encore me dire que je devrais automatiser ça (et il a raison) -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] api.openstreetmap.fr en panne ?
Le jeudi 20 décembre 2012 01:18:38, Cyrille Giquello a écrit : Alors un reminder pour dans 20h ;-) Ha ben, en fait non, pas dans 20h, maintenant ! Mais j'halucine comment ces machines dépottent et comment l'overpass c'est trop performant. 1h pour avaler 20h de diffs avec des osm2pgsql qui importent en parallèle ! -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
SFINX c'est déjà Renater (sur 2 POP parisiens). Mais toi (en fait SFR, aussi Free à Telehouse 2) tu transites par la branche lyonnaise de Renater, Numericable fait son peering sur un autre POP de Renater et transite par la branche vers Bordeaux et c'est un peu plus rapide. Je ne vois pas Orange se connecter à Renater via SFINX, mais Renater a un autre POP à Aubervilliers pour le peering avec Orange. Le 20 décembre 2012 01:16, Christophe Merlet red...@redfoxcenter.org a écrit : Il n'y a pas de sfinx à Lyon, il est a paris. Donc SFR ne peer pas avec Renater à lyon, donc ce que tu as écrit n'a pas de sens ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] de l'utilisation de taginfo
Le mercredi 19 décembre 2012 23:01:02, Pieren a écrit : 2012/12/19 adrien carpentier ad.carpent...@gmail.com: là où ça se corse c'est quand on a des valeurs doubles : genre maternelle;élémentaire que l'on taggue normalement en primaire, le lien ne donne pas la liste de cette erreur, mais le premier énoncé (donc les milliers de maternelles) Curieusement, ça marche sur le site original: http://taginfo.openstreetmap.org/tags/school%3AFR=%C3%A9l%C3%A9mentaire%3Bm aternelle Pieren Il doit y avoir une ancienne version qui bug avec les ; si quelqu'un a le courage de décrire le problème : http://trac.openstreetmap.fr/newticket composant autre (mettre [taginfo] dans le sujet) -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bureau de vote
Ce tracé me semble un peu bizarre entre la Rue et l'Avenue Frédéric Vidal (au Nord) : Tu y inclues dans la zone sud (avec la Rue Vidal) toute une rue (la partie nord de la Rue Mossé Baze), mais aucun des immeubles qui la borde et qui sont dans l'autre zone (avec l'Avenue Vidal). Comme s'il y a fait des électeurs comptés séparément quand ils habitent SUR la rue : je veux dire sur le trottoir (ceux qui dorment dehors sur un banc au point que ce serait leur adresse officielle sur les listes électorales ?) ou au milieu de la chaussée (c'est surement pour ne pas oublier les électeurs suicidaires!). Pourquoi la rue elle-même est à part des immeubles qui la bordent tout le long de chaque côté ? NE faudrait-il pas couper simplment la rue Baze en deux parties (à son carrefour avec la Rue Vidal) ? Est-ce à cause de l'interprétation du texte légal qui mentionne la rue Baze entière dans la même zone, en contradiction ici avec la coupure qui devrait suivre d'ouest en est le bord nord de la Rue Vidal sans s'aventurer au nord rue Baze pour la redescendre aussitôt une fois arrivée à l'Avenue Vidal ? Maintenant il n'est pas anormal de trouver des limites en zig zag selon la rue où en entre dans les immeubles d'un même pâté de maison ou bloc résidentiel : tout le bloc est à la même adresse même s'il a une face sur une autre rue. Mais une zone électorale doit représenter des ensembles contigus d'habitations, je ne vois pas en quoi la rue qui passe au milieu doit en être exclue et être dans une autre zone. De fait aussi, la partie exclavée au sud de ta zone n'est séparée de la partie principale que par la rue (chaussée et trottoirs) et il me semble que là aussi les deux côtés de la même rue forment une continuité (tout le long de l'Avenue de Courrèges des deux côtés), et donc il n'y a pas d'exclave au niveau de la zone électorale (donc pas de coupure par la rue Henri Dunant et donc tout le rond-point est aussi dans la zone et non en dehors, même si les 3 immeubles du coin nord-est de ce rond point, sont exclus avec leur terrain attenant). Donc tu as raison tout de même de t'inquiéter de ce micro-découpage sur les bordures (qui ne semble pas pertinent pour un découpage électoral si on ne trouve pas d'adresses distinctes dans les micro-zones inclues ou exclues sur un bord) Le 20 décembre 2012 01:22, Christian Quest cqu...@openstreetmap.fr a écrit : Bon, j'ai intégré les bureaux de vote d'Orange et leur zonage de la façon suivante: - un noeud avec polling_station:ref=nn voir nn;nn;nn lorsque plusieurs bureaux sont dans le même lieu sans connaitre leur localisation exacte - une relation type=boundary + boundary=polling_station + ref = numéro du bureau, avec les ways définissant la zone avec des rôles outer/inner et un node (voire way) avec le role polling_station pour le bureau lui même. Je pense que de cette façon on peut passer du bureau à la zone et inversement et qu'avec la zone, on peut extraire les adresses figurant à l'intérieur. Très instructif de voir ce découpage électoral qui tient parfois vraiment du charcutage... et vas-y que je te met un micro pâté de maison dans le bureau d'à côté ;) http://www.openstreetmap.org/?relation=2649373 ___ 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] Bureau de vote
La géométrie de zonage provient de la ville. Je n'ai rien inventé ou interpreté, juste intégré les données brutes. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bureau de vote
Ca a du évoluer avec le temps sous cette forme, avec les permis de construire et les regroupements de copropriétés, pour que toute la propriété ou copropriété se retrouve dans la même zone, en ajoutant changeant les parcelles privées de zone sans toucher aux parcelles du domaine public même si ça laisse uniquement des fragments minuscules du domaine public faire des zig-zags. Je note tout de même que les textes légaux définissant les cantons utilisent aussi la délimitation assez souvent non pas sur l'axe d'une rue, mais le long des façades en incluant toute la chaussée et ses deux trottoirs d'un seul côté pour ne pas diviser cette parcelle publique en deux moitiés. Cela ne semble pas le cas quand une rue sépare deux communes (chacune prend en charge sa moitié de la rue... tant qu'il n'y a pas déplacement du tracé de cette rue à la faveur de la construction d'un rond-point avec des échanges de parcelles, et une revente de morceaux de parcelles pour étendre une propriété attenante sur ce qui était l'ancienne voirie déplacée). Malgré tout on a des cas où une même propriété se retrouve à cheval sur deux communes voire deux pays, par fusion de parcelles, et si on doit classer dans une liste électorale ceux qui y résident, ça peut faire des décrochements aussi pour que le même résident ne se retrouve pas inscrit sur deux listes électorales limitrophes. Ce que tu pourrais regarder c'est si ces décrochements bizarres suivent la découpe des parcelles ou pas, ou dans le cas de parcelles d'un même ilot de résidence (copropriété ou propriété) si ces décrochements ne les coupent pas en les plaçant à cheval sur la limite de zone (donc comparer avec le cadastre parcellaire). Le 20 décembre 2012 03:24, Christian Quest cqu...@openstreetmap.fr a écrit : La géométrie de zonage provient de la ville. Je n'ai rien inventé ou interpreté, juste intégré les données brutes. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Navit sous Windows Mobile
Je n'utilise pas Navit et mon expérience avec WM date d'il y a qqs années. D'habitude ce genre de problème vient d'une mauvaise configuration de la 'porte' sérielle. Peut-être OSMTracker est capable de s'autoconfigurer et Navit ne l'est pas? Essaye donc chaque numéro pour le COM. Normalement il est également possible de répérer ce numéro dans le panneau de configuration. Chez moi c'était souvent COM5 ou COM7, mais les numéros peuvent également dépasser 16. Jo 2012/12/19 Eric SIBERT courr...@eric.sibert.fr Bonsoir, On m'a passé un smartphone HTC Touch HD T8282 qui tourne sous Windows Mobile 6.1. Je voulais utiliser Navit dessus pour faire du guidage routier sans connexion. J'ai installé le fichier .cab. Le programme démarre bien. Par contre, il ne récupère pas les coordonnées GPS alors qu'OSMTracker le fait sans problème. Une idée de comment faire? Je n'arrive pas non plus à lui faire utiliser la carte de France que j'ai téléchargé dans le même coin. Ou si vous avez d'autres proposition de navigation offline sur mon smartphone, je suis preneur. Éric __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Libération couche occupation du sol et Ortho-Photos aériennes de la réserve naturelle des Hauts plateaux du Vercors
Bonjour, si je comprends bien, le Parc naturel régional du Vercors apparaitra dans la liste à côté de la direction générale des impôts ? c'est bien ça ? si c'est le cas, je pense que cela devrait nous convenir (je demanderai confirmation à ma direction tout de même). L'essentiel pour nous est que cette donnée ne reste pas dans un placard. cordialement Yann Buthion Le 19/12/12 20:22, sly (sylvain letuffe) a écrit : On mercredi 19 décembre 2012, y_buthion wrote: Bonjour à toutes et à tous Bonjour, http://www.parc-du-vercors.fr/fr_FR/comprendre-et-partager-1110/telechargements-3115.html en espérant que ces données puisse vous intéresser Moi (mais je n'en doute pas, d'autres), ça pourrait en effet m'intéresser, très bonne initiative de votre part et merci ! Je ne sais pas si vous pourrez me répondre, mais la licence mentionne : Le « Réutilisateur » peut notamment s’acquitter de cette condition en indiquant un ou des liens hypertextes (URL) renvoyant vers « l’Information » et assurant une mention effective de sa paternité. Openstreetmap opte pour une solution consistant a lister les organismes desquels nous avons importé des données sur cette page : http://www.openstreetmap.org/copyright et celle-ci : http://wiki.openstreetmap.org/wiki/Attribution Et recommander à toute personne qui utilisera des données openstreetmap de faire un lien vers ces pages : http://wiki.openstreetmap.org/wiki/Legal_FAQ En outre, nous ajoutons dans des meta-données non loin des données elles-même ces informations. Cette solution vous semble-t-elle suffisante pour respecter votre attribution ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
