[OSM-talk-fr] Retours FOSDEM
Salut, Quelques retours du FOSDEM pour ma part. Je laisserai les autres participants au stand compléter. Je n’étais présent que le dimanche et je note : — Le stand est un stand OpenStreetMap-FR. Pour la prochaine édition, il faudra impérativement motiver la fondation et nos amis allemands — Nous n’avions aucune doc à distribuer, aucun poster à afficher et pas le moindre goodies à vendre. Tout juste Gaël avait pensé à ramener un grand écran et un gadget technologique, appât à geek :-) — Les standistes ne sont pas des programmeurs : nous avons été régulièrement séchés par les questions très techniques et terre à terre des visiteurs. N’oublions pas que le FOSDEM est orienté dév … savoir présenter OSM fait une belle jambe à tous ces geeks qui connaissent déjà très bien le projet — Nous avons eu l’occasion d’échanger sur l’éventualité d’une association belge pour OSM Au demeurant et malgré le stand pas très attractif, nous avons eu beaucoup de visiteurs et notre présence à Bruxelles aura encore été intéressante. Philippe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Retours FOSDEM
Je suis en plein dans les goodies pour SOTM-FR... donc ça on va bientôt avoir :) Le 4 février 2013 10:16, Philippe Pary phili...@cleo-carto.com a écrit : Salut, Quelques retours du FOSDEM pour ma part. Je laisserai les autres participants au stand compléter. Je n’étais présent que le dimanche et je note : — Le stand est un stand OpenStreetMap-FR. Pour la prochaine édition, il faudra impérativement motiver la fondation et nos amis allemands — Nous n’avions aucune doc à distribuer, aucun poster à afficher et pas le moindre goodies à vendre. Tout juste Gaël avait pensé à ramener un grand écran et un gadget technologique, appât à geek :-) — Les standistes ne sont pas des programmeurs : nous avons été régulièrement séchés par les questions très techniques et terre à terre des visiteurs. N’oublions pas que le FOSDEM est orienté dév … savoir présenter OSM fait une belle jambe à tous ces geeks qui connaissent déjà très bien le projet — Nous avons eu l’occasion d’échanger sur l’éventualité d’une association belge pour OSM Au demeurant et malgré le stand pas très attractif, nous avons eu beaucoup de visiteurs et notre présence à Bruxelles aura encore été intéressante. Philippe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] repère de crues - zone inondables
Le 3 févr. 2013 à 21:12, DH a écrit : Le 03/02/2013 13:11, Philippe Verdy a écrit : Le 3 février 2013 12:41, ades_...@orange.fr ades_...@orange.fr a écrit : je ne vais pas défendre les Pays de la Loire, mais dans ce cas je crois que c'est l'Etat, serveur carmen (équipement, écologie, je ne sais plus comment ça s'appelle maintenant). Pour la licence, j'espérais que ça éclairerait ;-). Reste à appeler une Dréal, à moins qu'un lecteur de la liste soit dans la maison, et qu'il puisse avoir la réponse plus facilement. Je pense que ce sont des données libres puisque simplement collectées auprès des communes (obligation réglementaire) et que pour certains bassins de crue il est même fait appel à la collaboration du public (la Seine je crois). Penser que... cela ne fait pas une licence claire. Rien ne vaut une licence en bonne et due forme. Qui ne s'oppose pas non pus à l'application de la loi ou d'une décision judiciaire : si tel était le cas, on pourra encore supprimer certaines données et appliquer la loi ou la décision judiciaire, et OSM dispose publiquement de tels recours. Tu dis à la fois que cela n'est pas un licence libre mais que Bigre ! C'est quoi ce jargon incompréhensible ?. L'administration française n'est pas tenue de fournir les données sous une licence OL/LO (même si c'est plus confortable pour tous les réutilisateurs), mais est tenue à respecter la Loi française (et d'en faire un rappel -comme l'a fait en son temps la Direction Générale des Finances Publiques pour nous signifier clairement que nous avions à faire face à de l'information publique légalement réutilisable-). Comprendre la convention d'Aarhus, la directive européenne INSPIRE, la politique et la stratégie de l'État français n'est pas une tâche simple, mais nous ne sommes pas les seuls à investir ce maquis juridique. L'Open Data jette un trouble dans un monde où l'eau claire distillée par les sources officielles ne gênait personne. Les temps ont changé et il faut accepter que tous les acteurs se donnent le temps de s'adapter à cette nouvelle donne. Pour en revenir aux données environnementales, la seule tache qui pourrait empêcher une pleine réutilisation est le fait que les données produites l'aient été à partir de données IGN sans que ces services de l'État bénéficient alors de la licence étendue permettant de s'approprier (au sens droit d'auteur et droits voisins) les données dérivées. On entre ici dans le dur de la stratégie de l'État vis à vis de lui-même ou de ses émanations (s'agissant plus particulièrement de la partie de la mission de service public de l'IGN (Référentiel à Grande Échelle -RGE) théoriquement entièrement subventionné. En résumé, utiliser des données DREAL, aucun doute sur la légalité. Télécharger des données DREAL, nécessité de verrouiller la clause IGN. Denis, ex-voisin de la maison ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr +1 J'ai passé un coup de fil une DREAL il m'a été confirmé que ces données sont production exclusive des services de l'Etat. La localisation des repères, après indication par les communes ou les collectivités locales ont vu leur repérage vérifié puis cartographiés par les services de l'Etat, il n'y a pas d'intervention IGN. Confirmation écrite pourrait être demandée. Il faut précisé que la mise à dispo de données environnementales est en cours d'évoluer vers une mise à dispo nationale (wms et téléchargement des .shp ou mif .mid)sans doute, d'ici 1 an. Pour les repères de crue, ils s'orientent vers un système proche de celui mis en place sur la Seine, avec demande de contributions du public. Pour info, le statut légal des repères de crue est le même que celui des bornes géodésiques.. La première question est plutôt celle de savoir si il y a un intérêt d'intégrer ces infos dans le projet OSM. Quels sont les avis ? S'il se dégage une réponse positive comment ça marche dans osm ? Pour les tags il pourrait s'agir de : manMade=flood_marker name=# flood_max_hight=#,## m (hauteur au dessus du sol au droit du repère) Flood_max_year= (année plus haute crue connue) flood_max_date=dd/mm/ (date si présente) flod_years=;; (autres crues repéres) source=# ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] RAPPEL: AG le 23 février à Lyon et candidatures...
Petit message de rappel concernant l'AG d'OpenStreetMap France qui se tiendra à Lyon le 23 février et surtout: - le délais pour les candidatures au conseil d'administration qui doivent être envoyées à c...@listes.openstreetmap.fr au plus tard le vendredi 8 février (soit ce vendredi). - tout le CA est renouvelé, donc les membres actuels du CA qui veulent rempiler doivent aussi envoyer leur candidature. Les candidatures reçues jusqu'à maintenant sont (j'en profite pour rajouter la mienne) : - Tony Emery - Jean-Louis Zimmermann - Cyrille Giquello - Philippe Pary - Louis-Julien de la Bouëre - Christian Quest -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [osm-fr CA] RAPPEL: AG le 23 février à Lyon et candidatures...
Je me suis également déjà porté candidat. Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [osm-fr CA] RAPPEL: AG le 23 février à Lyon et candidatures...
Oups, je t'ai oublié dans la liste (pourtant bien noté)... couché trop tard ! Le 4 février 2013 11:07, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : Je me suis également déjà porté candidat. Frédéric. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] data.shom.fr
Pas vu passer l'annonce ici, alors je relaie. Peut-être intéressant pour un trait de côte officiel ? Art. Le portail données publiques du SHOM est accessible au public depuis le 28 janvier 2013. Il permet à tous les usagers (services de l’État, collectivités territoriales, entreprises, citoyens…) de rechercher, de visualiser et d'accéder aux données de référence du SHOM, décrivant l’environnement physique maritime, côtier et océanique, et son évolution. Cette plate-forme de diffusion de données géographiques est conformes aux exigences de la directive Inspire. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] data.shom.fr
Pour avoir également un tracé de toute la cablasse maritime. Il faut néanmoins un accès nominatif pour avoir accès aux données attributaires donc impossible de savoir si ce sont des câbles électriques, télégraphiques ou optiques. Le 4 février 2013 13:50, Art Penteur art.pent...@gmail.com a écrit : Pas vu passer l'annonce ici, alors je relaie. Peut-être intéressant pour un trait de côte officiel ? Art. Le portail données publiques du SHOM est accessible au public depuis le 28 janvier 2013. Il permet à tous les usagers (services de l’État, collectivités territoriales, entreprises, citoyens…) de rechercher, de visualiser et d'accéder aux données de référence du SHOM, décrivant l’environnement physique maritime, côtier et océanique, et son évolution. Cette plate-forme de diffusion de données géographiques est conformes aux exigences de la directive Inspire. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] data.shom.fr
Bonjour, De : François Lacombe Pour avoir également un tracé de toute la cablasse maritime. Il faut néanmoins un accès nominatif pour avoir accès aux données attributaires donc impossible de savoir si ce sont des câbles électriques, télégraphiques ou optiques. Le 4 février 2013 13:50, Art Penteur a écrit : Pas vu passer l'annonce ici, alors je relaie. Peut-être intéressant pour un trait de côte officiel ? Art. Le portail données publiques du SHOM est accessible au public depuis le 28 janvier 2013. Il permet à tous les usagers (services de l’État, collectivités territoriales, entreprises, citoyens…) de rechercher, de visualiser et d'accéder aux données de référence du SHOM, décrivant l’environnement physique maritime, côtier et océanique, et son évolution. Cette plate-forme de diffusion de données géographiques est conformes aux exigences de la directive Inspire. Les aspects de licence sont moyennement accesibles. Il en ressort que tout ce qui est disponible sur ce site n'est pas sous une seule licence. J'ai trouvé ça : http://www.shom.fr/les-services-en-ligne/portail-datashomfr/ où la liste des couches opendata est bien courte. Et sur le trait de côte, la licence bloque, j'ai l'impression : Le fichier Trait de Côte Histolitt est librement réutilisable dans des bases de données ou services intégrés dans les conditions suivantes : - mention explicite de la source des données TCH par la mention © IGN-SHOM 2007 lors de leur visualisation, - indication claire à l'utilisateur des limites d'usage de cette donnée. - représentation sur site internet accompagnée obligatoirement des logos de l'IGN et du SHOM, munis d'un lien vers les url www.ign.fr et www.shom.fr Tout autre mode de réutilisation, en particulier dans le cadre de services commerciaux, doit être l'objet de la délivrance d'une licence particulière par l'IGN ou le SHOM. 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] repère de crues - zone inondables
Bonjour, le 04/02/2013 10:59, ades_...@orange.fr a écrit: La première question est plutôt celle de savoir si il y a un intérêt d'intégrer ces infos dans le projet OSM. Quels sont les avis ? S'il se dégage une réponse positive comment ça marche dans osm ? Ces infos sont utiles et intéressantes pour le citoyen lambda : - intérêt historique - intérêt environnemental (un cours d'eau, ça vit et ça déborde !) - intérêt foncier, etc. C'est à mon sens plus intéressant qu'un nom de magasin mais bon... Quant aux zones inondables, je ne comprends pas qu'on soit si dubitatif sur l'intérêt d'intégrer ces vastes polygones. C'est quand même une information pertinente voire vitale pour les citoyens qui souhaitent vivre dans telle ou telle région, non ? Samy ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Activations humanitaires, Groupe HOT
Bonjour Merci pour ce post, Effectivement c'est intéressant pour voir du pays. Apres une discussion avec Jean Guilhem la semaine dernière , j’ai trouvé sont idées géniales de demander au diaspora de cartographier leur pays. Ex du Mali avec la communauté malienne de Montreuil. Et pourquoi pas organiser des Mapping Party dans ces communautés , si il y a des Mappers à côté qui peuvent tisser des liens avec ces associations . Ce serait surement un bon échange et qui sait, ils pourraient mettre les points d’eau en plein désert. A moins que ce soit secret comme en haute Savoie avec les coins aux champignons. Bon mapping a tous fred M ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Arbres du cadastre vert du CG92 [was: Ouverture de la plateforme Open Data des Hauts-de-Seine]
On 28/01/2013 15:12, Jean-Marc Liotier wrote: Les arbres du Cadastre Vert (http://opendata.hauts-de-seine.net/jeu-de-donnees/cadastre-vert-les-arbres) à croiser éventuellement avec les arbres d'alignement (http://opendata.hauts-de-seine.net/jeu-de-donnees/arbres-dalignement-sur-la-voirie-departementale) et les arbres remarquables (http://opendata.hauts-de-seine.net/jeu-de-donnees/arbres-remarquables-du-territoire-des-hauts-de-seine-hors-proprietes-privees). J'ai posé à http://opendata.hauts-de-seine.net/jeu-de-donnees/cadastre-vert-les-arbres#comment-1053 la question du dédoublonnage de ces jeux de données : Chaque arbre a un identifiant unique, mais c'est IDELEMENT_ pour le Cadastre Vert, ID_ARBRE pour les arbres d'alignement et MATRICULE pour les arbres remarquables... Pourriez-vous s'il vous plait indiquer s'il est possible de croiser ces sources de données ? OpenDataHautsDeSeine m'a gentiment répondu et l'élément clé de sa réponse est : chaque arbre est dans un seul jeu de données. Nous pouvons donc sans crainte de doublonnage considérer chacun de ces jeux de données comme une source d'importation entièrement indépendante. Prochaine tâche : pour chacun de ces jeux de données, créer une page de wiki et y déterminer dans quels étiquettes de natural=tree fourrer les données de chacun des champs offerts par le CG92. Si quelqu'un le fait avant moi, ce serait pratique s'il le signale ici... Y-a-t-il d'autres expériences d'importation de ce type de données ? Une recherche de cadastre vert et openstreetmap ne donne pas grand chose... C'est une première ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Activations humanitaires, Groupe HOT
Fred, c'est effectivement une idée excellente. La connaissance du pays, c'est un élément essentiel de ces activations humanitaires et souvent nos cartes manquent de descriptions une fois que nous avons terminé de cartographier à distance. Les expatriés peuvent jouer un rôle très utile à cet égard. Ils ont aussi une connaissance du pays qui peut nous éclairer lors de nos interventions. Il serait intéressant si vous organisez de tels carto-parties, de pouvoir échanger par Skype par exemple et ainsi montrer la dimension internationale du groupe humanitaire HOT. Pierre De : Fred Moine frmo...@gmail.com À : talk-fr@openstreetmap.org Envoyé le : Lundi 4 février 2013 8h22 Objet : Re: [OSM-talk-fr] Activations humanitaires, Groupe HOT Bonjour Merci pour ce post, Effectivement c'est intéressant pour voir du pays. Apres une discussion avec Jean Guilhem la semaine dernière , j’ai trouvé sont idées géniales de demander au diaspora de cartographier leur pays. Ex du Mali avec la communauté malienne de Montreuil. Et pourquoi pas organiser des Mapping Party dans ces communautés , si il y a des Mappers à côté qui peuvent tisser des liens avec ces associations . Ce serait surement un bon échange et qui sait, ils pourraient mettre les points d’eau en plein désert. A moins que ce soit secret comme en haute Savoie avec les coins aux champignons. Bon mapping a tous fred M ___ 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] data.shom.fr
C'est pourtant en contradiction directe avec ce qui est écrit dans le gros tableau des jeux de données: *Couches* *Réutilisation* MNT littoral Litto3D®http://www.shom.fr/les-produits/bases-de-donnees-numeriques/bathymetrie/litto3d/ opendata Références altimétriques maritimeshttp://www.shom.fr/les-produits/bases-de-donnees-numeriques/maree-et-courant/references-altimetriques/ opendata Trait de côte Histolitt®http://www.shom.fr/les-services-en-ligne/donnees-en-telechargement/trait-de-cote/ opendata La réutilisation des données des produits numériques *opendata est gratuite pour tous les usages, y compris commerciaux* selon les termes de la licence ouverte version 1.0 publiée par la mission Etalab : www.etalab.gouv.fr. Peut-être s'agit-il d'une ancienne licence et le site web n'a pas été mis à jour ? ça mérite de les contacter pour éclaircissement. Le 4 février 2013 14:08, Vincent de Chateau-Thierry v...@laposte.net a écrit : Bonjour, De : François Lacombe Pour avoir également un tracé de toute la cablasse maritime. Il faut néanmoins un accès nominatif pour avoir accès aux données attributaires donc impossible de savoir si ce sont des câbles électriques, télégraphiques ou optiques. Le 4 février 2013 13:50, Art Penteur a écrit : Pas vu passer l'annonce ici, alors je relaie. Peut-être intéressant pour un trait de côte officiel ? Art. Le portail données publiques du SHOM est accessible au public depuis le 28 janvier 2013. Il permet à tous les usagers (services de l’État, collectivités territoriales, entreprises, citoyens…) de rechercher, de visualiser et d'accéder aux données de référence du SHOM, décrivant l’environnement physique maritime, côtier et océanique, et son évolution. Cette plate-forme de diffusion de données géographiques est conformes aux exigences de la directive Inspire. Les aspects de licence sont moyennement accesibles. Il en ressort que tout ce qui est disponible sur ce site n'est pas sous une seule licence. J'ai trouvé ça : http://www.shom.fr/les-services-en-ligne/portail-datashomfr/ où la liste des couches opendata est bien courte. Et sur le trait de côte, la licence bloque, j'ai l'impression : Le fichier Trait de Côte Histolitt est librement réutilisable dans des bases de données ou services intégrés dans les conditions suivantes : - mention explicite de la source des données TCH par la mention © IGN-SHOM 2007 lors de leur visualisation, - indication claire à l'utilisateur des limites d'usage de cette donnée. - représentation sur site internet accompagnée obligatoirement des logos de l'IGN et du SHOM, munis d'un lien vers les url www.ign.fr et www.shom.fr Tout autre mode de réutilisation, en particulier dans le cadre de services commerciaux, doit être l'objet de la délivrance d'une licence particulière par l'IGN ou le SHOM. 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] repère de crues - zone inondables
2013/2/4 Samy Mezani samy.mez...@wanadoo.fr: Quant aux zones inondables, je ne comprends pas qu'on soit si dubitatif sur l'intérêt d'intégrer ces vastes polygones. C'est quand même une information pertinente voire vitale pour les citoyens qui souhaitent vivre dans telle ou telle région, non ? Les zones inondées sont déterminées à partir de modèles 3D (ou de relevés photos sur des événements marquants). De plus, leur ampleur est très variable suivant l'intensité des crus. Ce qui gêne donc le plus, c'est la difficulté de représenter du 3D dans le système 2D d'OSM (on a déjà beaucoup de mal avec les marées ou même les lits mineurs/majeurs des rivières), l'impossibilité de pouvoir les vérifier et aussi le caractère transitoire de ces événements. Des questions qu'on se pose régulièrement sur d'autres sujets du même type. (l'exposition aux risques en général, comme l'exposition aux pollutions de l'air, sonores, électromagnétiques, chimiques, radioactives, etc). Par contre, il y a en général aucune réticence à mettre des objets physiques (antennes, usines, zones de stockages, marqueurs de crus) qui sont plus permanents et vérifiables. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Activations humanitaires, Groupe HOT
On 04/02/2013 14:22, Fred Moine wrote: Apres une discussion avec Jean Guilhem la semaine dernière , j’ai trouvé sont idées géniales de demander au diaspora de cartographier leur pays. Ex du Mali avec la communauté malienne de Montreuil. Et pourquoi pas organiser des Mapping Party dans ces communautés , si il y a des Mappers à côté qui peuvent tisser des liens avec ces associations. J'ai essayé anecdotiquement avec des Sénégalais et des Burkinabés, mais j'ai rencontré des obstacles qui, quoiqu'analogues à ceux rencontrés avec des utilisateurs Français, n'en sont pas moins nettement renforcés: - L'interprétation de sources orbitales nous semble aujourd'hui innée parce que nous la pratiquons régulièrement, mais elle est encore impénétrable pour beaucoup d'utilisateurs. Pour leur soutirer l'information il faut les faire parler en leur décrivant l'image. - La représentation cartographique est également une abstraction peu accessible à ceux qui n'ont pas l'occasion de la pratiquer régulièrement : spontanément l'utilisateur décrira un chemin du genre et sur la grande route goudronnée je tourne à gauche avant le carrefour de l'aéroport qu'il faudra projeter pour lui sur la carte. La vision globale offerte par la cartographie en générale et l'imagerie orbitale en particulier est donc souvent un choc pour celui qui n'a toujours eu que sa vision subjective au niveau du sol, représentée mentalement sous forme d'itinéraires ignorant le contexte. Tout ça n'a rien de spécifiquement Africain comme en témoigne la popularité de la navigation pas à pas dans les routeurs portatifs, mais le problème est souligné et c'est encore une mise en perspective du luxe d'information dans lequel nous baignons aujourd'hui et dont il faut tenir compte pour approcher ces utilisateurs vivant dans des environnements où l'accès à l'information est souvent moins pervasif que celui auquel nous sommes habitués. Si je devais produire un support de formation spécifique, je l'introduirait avec des triptyques mettant côté à côté : - Vue subjective au niveau du sol - Vue d'orbite - Carte La démarche n'a rien de fondamentalement différent de ce que je fais pour présenter OSM à mes parents, mais elle nécessite d'autant plus de pédagogie élémentaire pour commencer que les utilisateurs viennent d'un environnement pauvre en information écrite et cartographique. Ensuite arrive le problème de la translittération de toponymes rarement manipulés sous forme écrite... Préparez-vous à régulièrement utiliser alt_name J'imagine que les intervenants locaux HOT en général et d'Eurosha en particulier auront beaucoup à dire autour de ces sujets et avec un nombre d'expériences nettement plus représentatif que mes anecdotes. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] data.shom.fr
2013/2/4 Vincent Privat vincent.pri...@gmail.com Peut-être s'agit-il d'une ancienne licence et le site web n'a pas été mis à jour ? ça mérite de les contacter pour éclaircissement. Je penche aussi pour cette explicaation. Sinon, il n'y aurait aucun changement et l'annonce n'aurait aucun sens. Voir aussi le tableau couches de données disponibles ici: http://www.shom.fr/les-services-en-ligne/portail-datashomfr/ Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] repère de crues - zone inondables
Le 4 févr. 2013 à 15:09, Pieren a écrit : 2013/2/4 Samy Mezani samy.mez...@wanadoo.fr: Quant aux zones inondables, je ne comprends pas qu'on soit si dubitatif sur l'intérêt d'intégrer ces vastes polygones. C'est quand même une information pertinente voire vitale pour les citoyens qui souhaitent vivre dans telle ou telle région, non ? Les zones inondées sont déterminées à partir de modèles 3D (ou de relevés photos sur des événements marquants). De plus, leur ampleur est très variable suivant l'intensité des crus. Ce qui gêne donc le plus, c'est la difficulté de représenter du 3D dans le système 2D d'OSM (on a déjà beaucoup de mal avec les marées ou même les lits mineurs/majeurs des rivières), l'impossibilité de pouvoir les vérifier et aussi le caractère transitoire de ces événements. Des questions qu'on se pose régulièrement sur d'autres sujets du même type. (l'exposition aux risques en général, comme l'exposition aux pollutions de l'air, sonores, électromagnétiques, chimiques, radioactives, etc). +1 Il s'agit de constructions, ou même d'interprétations, à partir de données physiques ça doit effectivement échapper à la capacité de modélisation d'OSM. ;-) Ces zones de crues (mais c'est effectivement pareil pour les risques industriels, les risques d'avalanche ou d'éboulement…) sont par ailleurs l'objet de Plan de prévention des risques d'où découlent des données réglementaires. Je vois mal comment on pourrait dans OSM, pourrait intégrer toutes ces données en garantissant leur pertinence. OSM permet à tous de modifier les informations portées sur la carte. En plus ces informations sont facilement dispo sur les serveurs des services de l'Etat (un peu long à trouver pour l'instant, il y a de multiples serveurs, mais ça semble s'arranger), je ne suis pas sûr que le projet d'OSM soit de faire le porter à connaissance de l'Etat. Par contre, il y a en général aucune réticence à mettre des objets physiques (antennes, usines, zones de stockages, marqueurs de crus) qui sont plus permanents et vérifiables. je ne connais pas trop bien le fonctionnement d'OSM pour ce faire, il faudrait créer de nouveaux tags, informer sur le but etc. . Comment ça se passe pratiquement ? Je veux bien faire de l'import sur un ou deux départements (encore qu'avec josm ça ne va pas forcement être si simple que ça), mais ensuite ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Retours FOSDEM
Le samedi c'était Gaël et moi qui ont tenu le stand. C'est vrai, c'était fort minimaliste. L'année dernière on avait au moins une carte format poster qui venait de Geofabrik pour décorer un petit peu. Pour moi, le plus important, c'est que nous étions là pour repondre aux questions. Et des questions il y en avait. Pour moi c'était donc assez bien réussi. Mais il y a certainement de quoi améliorer. Le samedi prochain j'ai organisé un rencontre OSM à Lier (en Flandre, alentours d'Anvers). La première semaine de juillet il y a le RMLL qui sera organisé à Bruxelles cette année. Les organisateurs aimeraient que nous organisons une cartopartie au jour du grand public. Moi, je pense que nous pourrons également faire aux moins 2 présentations. 1 pour présenter le projet en général et une pour les sujets plus avancés. En outre il serait intéressant d'avoir 3-5 machines au stand pour que les gens puissent faire une expérience directe. Et on peut même organiser un atelier pratique avec des démos. Et le matériel 'goodies' bien sûr! De préférence avec openstreetmap.org. Les RMLL à Bruxelles seront bien plus internationales et multilingues que les autres, il me semble. J'achèterai directement un T shirt, une 'veste' pour la pluie, une veste haute visibilité moi même! :-) Jo 2013/2/4 Christian Quest cqu...@openstreetmap.fr Je suis en plein dans les goodies pour SOTM-FR... donc ça on va bientôt avoir :) Le 4 février 2013 10:16, Philippe Pary phili...@cleo-carto.com a écrit : Salut, Quelques retours du FOSDEM pour ma part. Je laisserai les autres participants au stand compléter. Je n’étais présent que le dimanche et je note : — Le stand est un stand OpenStreetMap-FR. Pour la prochaine édition, il faudra impérativement motiver la fondation et nos amis allemands — Nous n’avions aucune doc à distribuer, aucun poster à afficher et pas le moindre goodies à vendre. Tout juste Gaël avait pensé à ramener un grand écran et un gadget technologique, appât à geek :-) — Les standistes ne sont pas des programmeurs : nous avons été régulièrement séchés par les questions très techniques et terre à terre des visiteurs. N’oublions pas que le FOSDEM est orienté dév … savoir présenter OSM fait une belle jambe à tous ces geeks qui connaissent déjà très bien le projet — Nous avons eu l’occasion d’échanger sur l’éventualité d’une association belge pour OSM Au demeurant et malgré le stand pas très attractif, nous avons eu beaucoup de visiteurs et notre présence à Bruxelles aura encore été intéressante. Philippe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest ___ 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] Activations humanitaires, Groupe HOT
Le 04/02/2013 15:11, Jean-Marc Liotier a écrit : J'ai essayé anecdotiquement avec des Sénégalais et des Burkinabés, mais j'ai rencontré des obstacles qui, quoiqu'analogues à ceux rencontrés avec des utilisateurs Français, n'en sont pas moins nettement renforcés: - L'interprétation de sources orbitales nous semble aujourd'hui innée parce que nous la pratiquons régulièrement, mais elle est encore impénétrable pour beaucoup d'utilisateurs. Pour leur soutirer l'information il faut les faire parler en leur décrivant l'image. - La représentation cartographique est également une abstraction peu accessible à ceux qui n'ont pas l'occasion de la pratiquer régulièrement : spontanément l'utilisateur décrira un chemin du genre et sur la grande route goudronnée je tourne à gauche avant le carrefour de l'aéroport qu'il faudra projeter pour lui sur la carte. Tout à fait ! Aussi, cartographier l'Afrique, c'est bien. Mais fournir des cartes à l'Afrique, c'est pas mal du tout ! Il y a une jeune de Besançon qui est partie pour Sarh (Tchad) pour un an. Je lui ai fourni (outre un GPS Garmin avec carte OSM) tout un jeu de tirages walking-paper de sa zone pour noter ce qu'elle peut avec les gens du coin. Il y a deux jeunes de Besançon qui ont le projet d’aller à Douroula (Burkina) cet été. Ils y sont déjà allé une fois et ont rapporté de la donnée. Dans le projet, ils font imprimer une carte de Douroula sur bâche pour le collège là-bas, l'idée est de faire payer le tirage par Besançon, jumelé avec Douroula. Les jeunes apprendront à lire une carte s'il en ont une de leur coin ! Même le préfet n'a pas de carte de son département ! Il est intéressé par OpenStreetMap, solution à pas cher. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Arbres du cadastre vert du CG92 [was: Ouverture de la plateforme Open Data des Hauts-de-Seine]
On 04/02/2013 14:29, Jean-Marc Liotier wrote: Prochaine tâche : pour chacun de ces jeux de données, créer une page de wiki et y déterminer dans quels étiquettes de natural=tree fourrer les données de chacun des champs offerts par le CG92. Voilà pour la création de la page : http://wiki.openstreetmap.org/wiki/WikiProject_France/Open_Data_Hauts-de-Seine_Arbres Une proposition de correspondance des champs avec les étiquettes de natural=tree est donc la prochaîne tâche sur ma liste. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Orthophotoplans de Toulouse
Bravo pour cet énorme boulot Jean-Guilhem !
Le 3 février 2013 22:40, Guilhem Bonnefille
guilhem.bonnefi...@gmail.coma écrit :
Génial.
Les utilisateurs de Viking peuvent aussi en profiter en rajoutant les
lignes suivantes dans ~/.viking/maps.xml :
object class=VikSlippyMapSource
property name=labelOrthophotoplans Toulouse 2011/property
property name=hostnamewms.openstreetmap.fr/property
property name=url/tms/1.0.0/toulouse_ortho2011/%d/%d/%d.png/property
property name=id510/property
/object
object class=VikSlippyMapSource
property name=labelOrthophotoplans Toulouse 2007/property
property name=hostnamewms.openstreetmap.fr/property
property name=url/tms/1.0.0/toulouse_ortho2007/%d/%d/%d.png/property
property name=id511/property
/object
Je suis toutefois surpris que le format des fichiers soit en .png pour
des photos.
Le 2 février 2013 12:28, Jean-Guilhem Cailton j...@arkemie.com a écrit :
Bonjour,
Les orthophotoplans de Toulouse, réalisés à partir de prises de vue
aériennes de juillet 2011 et 2007, avec une taille de pixel de 12,5 cm,
et libérés par Toulouse Métropole, sont disponibles en TMS sur
wms.openstreetmap.fr.
Vous pouvez les visualiser dans votre navigateur à partir de :
http://wms.openstreetmap.fr/toulouse
(qui inclut aussi quelques cartes OSM, dont le rendu en occitan de
PauLLA).
Ces images sont intégrées dans les fournisseurs d'imagerie de JOSM,
accessibles dans l'onglet WMS-TMS des préférences (mettez la liste à
jour, et activez-les pour les faire apparaître dans votre menu imagerie).
Vous pouvez aussi ajouter à la main ces URL TMS pour JOSM :
tms[22]:
http://wms.openstreetmap.fr/tms/1.0.0/toulouse_ortho2011/{zoom}/{x}/{y}
tms[22http://wms.openstreetmap.fr/tms/1.0.0/toulouse_ortho2011/%7Bzoom%7D/%7Bx%7D/%7By%7Dtms%5B22
]:http://wms.openstreetmap.fr/tms/1.0.0/toulouse_ortho2007/{zoom}/{x}/{y}
Pour Potlatch2, ajoutez ces URL dans les arrières-plans :
http://wms.openstreetmap.fr/tms/1.0.0/toulouse_ortho2011/$z/$x/$y
http://wms.openstreetmap.fr/tms/1.0.0/toulouse_ortho2007/$z/$x/$y
Voyez https://wiki.openstreetmap.org/wiki/Toulouse/ToulouseMetropoleData
pour la source à citer.
Bien cordialement,
Jean-Guilhem
--
gpg 0x5939EAE2
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
--
Guilhem BONNEFILLE
-=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com
-=- mailto:guilhem.bonnefi...@gmail.com
-=- http://nathguil.free.fr/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Orthophotoplans de Toulouse
Le 03/02/2013 22:40, Guilhem Bonnefille a écrit : Je suis toutefois surpris que le format des fichiers soit en .png pour des photos. Bonjour, C'est bien sûr le format jpeg qui est utilisé. Il traînait effectivement des .png superflus et trompeurs dans le fichier toulouse.html, à cause d'un copier-coller trop rapide, mais TileCache envoie de toute façon les tuiles en jpeg, comme il est configuré pour le faire. En png, les tuiles seraient effectivement beaucoup plus grosses. Merci pour les utilisateurs de Viking. Cordialement, Jean-Guilhem -- gpg 0x5939EAE2 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Activations humanitaires, Groupe HOT
Le 4 février 2013 15:11, Jean-Marc Liotier j...@liotier.org a écrit : J'ai essayé anecdotiquement avec des Sénégalais et des Burkinabés, mais j'ai rencontré des obstacles qui, quoiqu'analogues à ceux rencontrés avec des utilisateurs Français, n'en sont pas moins nettement renforcés: - L'interprétation de sources orbitales nous semble aujourd'hui innée parce que nous la pratiquons régulièrement, mais elle est encore impénétrable pour beaucoup d'utilisateurs. Pour leur soutirer l'information il faut les faire parler en leur décrivant l'image. - La représentation cartographique est également une abstraction peu accessible à ceux qui n'ont pas l'occasion de la pratiquer régulièrement : spontanément l'utilisateur décrira un chemin du genre et sur la grande route goudronnée je tourne à gauche avant le carrefour de l'aéroport qu'il faudra projeter pour lui sur la carte. Pour les africains je n'en sais rien, mais pour les français j'ai remarqué depuis belle lurette que la lecture cartographique présentait de réelles difficultés pour un grand nombre de personnes. On est plutôt en situation d'illettrisme cartographique, avec des gens qui essaient de faire semblant de savoir lire. Et la situation ne risque pas de s'améliorer puisque les passionnés de cartographie actuels s'imaginent que la cartographie n'est qu'une base de données ! C'est la poutre et la paille, quoi. La seule façon que j'ai trouvée de résoudre ce problème (celui de l'illétrisme cartographique) est celui que tu prends : demander aux gens de décrire ce qu'ils voient, et d'expliquer comment voir, et comment je fais. Je l'ai fait en bateau de croisière, ou sur les routes en bagnole, ou sur des chemins de rando. Mais, en plus, il y a souvent un problème de concrétisation : les gens estiment que la description cartographique n'est pas concrète. Par contre, une photo, un GPS (par GPS il s'agit des trucs dans les bagnoles), etc, sont, disent-ils, des choses concrètes. En gros la description cartographique est une perte de temps, selon eux... Je n'ai encore jamais trouvé de solution à ce problème. Et quand à ceux qui croient que la carte est un simple rendu de base de données, encore jamais trouvé de solution non plus. Je vous tiens au courant :-) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Problème de localisation de Rennes
Le dimanche 03 février 2013 21:43:46, Vincent de Chateau-Thierry a écrit : Pour reformuler Je préfère en base un tag name avec strictement le nom, et pas un nom aménagé qui viserait à désambiguïser par lui-même. On a d'autres moyens que le tag name pour éviter les confusions, et la combinaison de tags est un levier à actionner +1 Oui, ne pas ajouter dans le nom arrondissement de/commune de/département de l'/... peut sembler un peu plus délicat au final pour faire du joli français et ajoute des ambiguïtés dans les logiciels imparfaits, mais ça me semble aussi la solution la plus flexible à terme pour vraiment utiliser osm comme une base de donnée. Charge à nous de trouver un endroit pour stocker la correspondance admin_level - version française avec des mots Quelque chose dans cette idée là : http://wiki.openstreetmap.org/wiki/Relations/Proposed/Defaults (ou une autre relation similaire dont le but serait la conservation de méta données) Idée en vrac de prototype de tags : admin_level_name:8:fr=commune admin_level_name:6:fr=département admin_level_name:X:fr=Arrondissement -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Activations humanitaires, Groupe HOT
Fred, Des humanitaires au Mali, des personnes à Bamako ou expatriés avec souvent peu de connaissances OSM sont susceptibles de collaborer. Je suis prêt à faire le pari qu'il y aura des personnes qui pourront se retrouver sur une carte. Il faut éviter que les usagers se perdent dans le dédale de la classification OSM. Dans le cadre de tels projets, nous focusons sur un petit nombre d'objets tels que infrastructures et services publics. Voici le type de données à géolocaliser : Rue, route inter-cité, piste Pont Port Service de ferry Station de bus Ville/Village Hopital Clinique médicale École Mosquée / Église Points d'eau etc. Quelqu'un parmi vous a-t-il des propositions concrètes pour adapter rapidement un outil de collecte de données qui se connecte à OSM? Il faudrait simplifier au maximum l'information à fournir par l'usager. Cet outil présenterait une grille semblable à ce qui est décrit ci-haut, puis l'usager complèterait en ajoutant la description. Pierre De : Fred Moine frmo...@gmail.com À : talk-fr@openstreetmap.org Envoyé le : Lundi 4 février 2013 8h22 Objet : Re: [OSM-talk-fr] Activations humanitaires, Groupe HOT Bonjour Merci pour ce post, Effectivement c'est intéressant pour voir du pays. Apres une discussion avec Jean Guilhem la semaine dernière , j’ai trouvé sont idées géniales de demander au diaspora de cartographier leur pays. Ex du Mali avec la communauté malienne de Montreuil. Et pourquoi pas organiser des Mapping Party dans ces communautés , si il y a des Mappers à côté qui peuvent tisser des liens avec ces associations . Ce serait surement un bon échange et qui sait, ils pourraient mettre les points d’eau en plein désert. A moins que ce soit secret comme en haute Savoie avec les coins aux champignons. Bon mapping a tous fred M ___ 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] Problème de localisation de Rennes
Il y aurait bien une solution : supprimer le niveau 7 en en faisant non plus un niveau administratif (ce qu'il est pourtant bel et bien !) mais un découpage politique (le fourre-tout où on let ce qui n à rien de plitique mais électoral ou pour des découpages adminstratifs secondaires). Mais si on ne garde en boundary=administrative QUE les structures administratives ayant des conseils élus et pas les structures de l'Etat alors il faudrait un autre type pour le decoupage exécutif de l État. Et on y mettrait alors les arrondissements les cantons et les pays mais pas les EPCI qui émanent non pas d'une répartion hiérarchique des structures de l'État ni de transferts successifs de compétence d'un niveau à l'autre, mais des décisions de coopération entre les communes issues de ce découpage. Dans ce cas on aurait un nouveau type boundary=executive avec executive_level=arrondissement ou canton. Malgré tout je reste persuadé que l'essentiel de cette discussion n'a aucun sens car cela revient à demander à corriger OSM pour un problème de rendu (dans Nominatim), surtout quand il affiche de lui-même, sans que ce soit nulle part dans la base, une correspondance comme 7=county qui n'a de sens qu'au Royaume-Uni au départ (mais a été repris aux USA). La correspondance entre les niveaux n'a rien à voir avec ce qu'affiche Nominatim qui se trompe (par ses insuffisances d'analyse), et ce n'est pas un problème d'OSM lui-même. Certes on peut régler le problème de Nominatim avec des métadonnées pour la France, mais à condition : - 1° que ces métadonnées correspondent effectivement à ce qui est documenté sur le wiki pour chaque pays - 2° que Nominatim utilise ces métadonnées, ce qui n'est pas gagné non plus ! Le 3 février 2013 12:16, Mickaël Guéret m.gue...@free.fr a écrit : Le samedi 02 février 2013 à 23:02 +0100, Vincent de Chateau-Thierry a écrit : En bref : tout ça concerne le moteur qui exploite les données (Nominatim) et pas la donnée elle-même. Ne faisons pas assumer à la donnée ce qui relève du logiciel. Bon, ok, tu as gagné, je laisse tomber (pour cette manche ;-))... Mais il faut quand même laisser un ticket sur trac.openstreetmap.org du coup... Je veux bien m'en charger mais mon anglais est...usé..., enfin, voilà... Si je résume, Nominatim devrait : - Compléter le nom des relations de limites administratives de niveau 7 en Arrondissement de %name% dans le contexte français. - de même, il faudrait compléter le nom des relations de limites politiques de type canton par Canton de %name% - Ne pas retourner ce niveau (7) dans le résultat détaillé. ex : [1] , countyArrondissement de Rennes/county), en France on attendrait plutôt countyIlle-et-Vilaine/county, soit le niveau 6. - Et pour être encore plus précis (je ne sais pas ce que cela implique ??) : department au lieu de county et pendant qu'on y est region à la place de state, pour mieux coller au contexte français... ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Arbres du cadastre vert du CG92 [was: Ouverture de la plateforme Open Data des Hauts-de-Seine]
Bonsoir, Pourrais-tu raccrocher la page à celle-ci http://wiki.openstreetmap.org/wiki/FR:Potential_Datasources/France ? Romain Le 4 février 2013 17:09, Jean-Marc Liotier j...@liotier.org a écrit : On 04/02/2013 14:29, Jean-Marc Liotier wrote: Prochaine tâche : pour chacun de ces jeux de données, créer une page de wiki et y déterminer dans quels étiquettes de natural=tree fourrer les données de chacun des champs offerts par le CG92. Voilà pour la création de la page : http://wiki.openstreetmap.org/wiki/WikiProject_France/Open_Data_Hauts-de-Seine_Arbres Une proposition de correspondance des champs avec les étiquettes de natural=tree est donc la prochaîne tâche sur ma liste. ___ 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] Arbres du cadastre vert du CG92 [was: Ouverture de la plateforme Open Data des Hauts-de-Seine]
On 02/04/2013 09:33 PM, Romain MEHUT wrote: Pourrais-tu raccrocher la page à celle-ci http://wiki.openstreetmap.org/wiki/FR:Potential_Datasources/France ? Fait - http://wiki.openstreetmap.org/w/index.php?title=FR%3APotential_Datasources%2FFrancediff=863493oldid=846293 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Activations humanitaires, Groupe HOT
On 02/04/2013 09:16 PM, Pierre Béland wrote: Il faut éviter que les usagers se perdent dans le dédale de la classification OSM. Dans le cadre de tels projets, nous focusons sur un petit nombre d'objets tels que infrastructures et services publics. Voici le type de données à géolocaliser : [..] Quelqu'un parmi vous a-t-il des propositions concrètes pour adapter rapidement un outil de collecte de données qui se connecte à OSM? Il faudrait simplifier au maximum l'information à fournir par l'usager. Cet outil présenterait une grille semblable à ce qui est décrit ci-haut, puis l'usager complèterait en ajoutant la description. Tout dépend de la population visée, et donc du niveau technologique choisi : - Papier et crayon, saisie sur un poste connecté (même pas d'imprimante pour des papiers de marche[1] ni d'appareil photo pour les saisir) - Papier et crayon, saisie sur un poste connecté (type papiers de marche) - Papiers de marche + récepteur GPS simple pour enregistrer des positions précises et des traces - Android à 50$ non connecté avec une application simple pour le relevé de POI - Android milieu de gamme connecté avec une application collectant et uploadant les POI Le meilleur rapport coût/efficacité se situe probablement au niveau d'un poste central entouré d'utilisateurs de papiers de marche et de récepteurs GPS simples... Mais je doute qu'il y ait une unique bonne réponse. Sur l'Android non connecté, on peut imaginer de customiser OSMtracker avec un jeu de types de POI au goût local. Vue l'évolution de la pénétration d'Android en Afrique (300 000 Android à 50$ vendus au Kenya - http://techcrunch.com/2012/12/10/50-android-smartphones-are-disrupting-africa-much-faster-than-you-think-says-wikipedias-jimmy-wales) ce ne sera bientôt plus une solution aussi luxueuse qu'elle peut paraître actuellement. Avec les méthodes centrées sur les papiers de marche, l'axe de progrès est à mon avis d'ordre méthodologique : - Pour une opération de longue durée, organiser la collecte en phases s'appuyant les unes sur les autres. Chaque phase ferait l'objet d'une fiche à emporter avec les papiers de marche. - Spécialiser les collecteurs en fonction de moyens de collecte (collecte motorisée de traces GPS, collecte semi-motorisée de POI à grande échelle, porte-à-porte de collecte détaillée). Chaque tournée ferait l'objet d'une fiche à emporter avec les papiers de marche. - Organiser des collectes périodiques par thèmes pour maximiser l'apprentissage mutuel dans chaque thématique. Chaque thème ferait l'objet d'une fiche à emporter avec les papiers de marche. Les habitués des ateliers cartographiques[2] (je suis essentiellement un cartographe de bureau) en savent certainement beaucoup plus que moi à ce sujet. Mais il me semble bien que c'est dans la méthodologie et l'accompagnement qu'il faut chercher plutôt que dans les outils. [1] Walking papers en langue Angloise. [2] Mapping parties dans la langue de Richard Weait ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Vider le cache des tuiles Bing Mapnik
Bonsoir, Sous Windows, JOSM stocke dans un répertoire de cache les tuiles Bing Mapnik. Je cherche un moyen de supprimer régulièrement ces fichiers. Auriez-vous une idée? Windows est à la ramasse pour supprimer près de 6 .png Merci. Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] A propos de la couche voirie/cadastre de layers.openstreetmap.fr
Le vendredi 01 février 2013 09:41:37, Stéphane Péneau a écrit : Bonjour Sly, Ce bug a été corrigé ou pas ? Celui que tu avais signalé en octobre ? Non, pas corrigé, et je ne compte pas le corriger. Toujours la même réponse donc : http://lists.openstreetmap.org/pipermail/talk-fr/2012-October/050404.html En un mot : ça va* se réparer tout seul dimanche prochain. * ou disons : devrait Plus globalement, toutes les communes des pays de la loire sont vectorisées depuis longtemps (à l'exception de 2 en Mayenne), et pourtant, il y a pas mal de blanc. Le calcul a lieu tous les dimanche matin à 3h00. Si dimanche matin prochain, que personne n'a touché la commune entre le moment du calcul et le moment ou tu regardes et qu'elle est toujours en blanc... alors tu as trouvé un bug et j'aurais besoin de l'id de la relation pour tenter d'y voir plus clair Les deux que tu m'as cité : Aigrefeuille sur Maine : a été retouché aujourd'hui Remouillé : bien en bleu -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] [2ème round] Proposition(s) pour un petit coup de balais dans les tags access/oneway
Re, Suite aux avis exprimés sur : http://lists.openstreetmap.org/pipermail/talk-fr/2013-January/053869.html Je propose une version allégée pour mon premier coup de balais : * Retrait des tags fixme=name uniquement lorsqu'il n'y a pas de nom à l'objet (pas de changement si l'objet à les deux tags name=xx + fixme=name car on considère que le sens est ambiguë) Le 2ème reste inchangé : * Retrait des fixme=set better denotation sur tous les arbres -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vider le cache des tuiles Bing Mapnik
Il y a des utilitaires divers de nettoyage automatique de Windows, tu peux les paramétrer pour qu'ils allent faire le ménage plus souvent en ajoutant ce dossier. Sinon le dossier peut rester dans le dossier temporaire de l'utilisateur. Mais je suis d'accord sur le fait que le cache de JOSM est mal fichu : si le nettoyage prend autant de temps c'est parce que TOUS les fichiers sont dans le même dossier et que leur suppression un par un oblige Windows à sans arrêt retrier les index. Solution pour accélérer ça : déplacer ce dossier non pas sur un volume NTFS (où les dossiers sont maintennus triés) mais sur un volume FAT. Et là la suppression dans un même dossier contenant des milliers de fichiers va beaucoup plus vite, même si FAT a tendance à se fragmenter énormément. Le cache de JOSM n'est en plus pas conforme à HTTP (il ne tient pas compte des dates de péremption, ni même d'un comptage de volume maximum, et JOSM n'a aucun thread nettoyeur pour virer les fichiers obsolètes ou en excès par rapport au colume maximum indiqué, sans compter aussi que le nombre de fichier est doublé car il stocke un fichier pour la tyuile et un autre fichier pour n'y mettre que les ETag de transaction HTTP, dont la conservation est pourtant totalement inutile dès que la transaction est terminée). Ce cache (en fait c'est le module JTiles) n'a aucune structure comparable à ce que réalisent tout bon navigateur web pour faire des purges efficaces. Le 4 février 2013 22:44, Romain MEHUT romain.me...@gmail.com a écrit : Bonsoir, Sous Windows, JOSM stocke dans un répertoire de cache les tuiles Bing Mapnik. Je cherche un moyen de supprimer régulièrement ces fichiers. Auriez-vous une idée? Windows est à la ramasse pour supprimer près de 6 .png ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vider le cache des tuiles Bing Mapnik
Le 04/02/2013 23:21, Philippe Verdy a écrit : Il y a des utilitaires divers de nettoyage automatique de Windows, tu peux les paramétrer pour qu'ils allent faire le ménage plus souvent en ajoutant ce dossier. Sinon le dossier peut rester dans le dossier temporaire de l'utilisateur. Mais je suis d'accord sur le fait que le cache de JOSM est mal fichu : si le nettoyage prend autant de temps c'est parce que TOUS les fichiers sont dans le même dossier et que leur suppression un par un oblige Windows à sans arrêt retrier les index. Solution pour accélérer ça : déplacer ce dossier non pas sur un volume NTFS (où les dossiers sont maintennus triés) mais sur un volume FAT. Et là la suppression dans un même dossier contenant des milliers de fichiers va beaucoup plus vite, même si FAT a tendance à se fragmenter énormément. Le cache de JOSM n'est en plus pas conforme à HTTP (il ne tient pas compte des dates de péremption, ni même d'un comptage de volume maximum, et JOSM n'a aucun thread nettoyeur pour virer les fichiers obsolètes ou en excès par rapport au colume maximum indiqué, sans compter aussi que le nombre de fichier est doublé car il stocke un fichier pour la tyuile et un autre fichier pour n'y mettre que les ETag de transaction HTTP, dont la conservation est pourtant totalement inutile dès que la transaction est terminée). Ce cache (en fait c'est le module JTiles) n'a aucune structure comparable à ce que réalisent tout bon navigateur web pour faire des purges efficaces. Le 4 février 2013 22:44, Romain MEHUT romain.me...@gmail.com a écrit : Bonsoir, Sous Windows, JOSM stocke dans un répertoire de cache les tuiles Bing Mapnik. Je cherche un moyen de supprimer régulièrement ces fichiers. Auriez-vous une idée? Windows est à la ramasse pour supprimer près de 6 .png En version rustique, tu peux arriver à tes fins avec une fenêtre DOS et 3 lignes de commande : cd c:\users\login\appdata\local\temp\JMapViewerTiles_login del Bing Aerial Maps\*.png del Bing Aerial Maps\*.tags En fonction du nombre de fichiers ça peut être long (20 bonnes minutes à l'instant pour 18 pngs, misère !) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vider le cache des tuiles Bing Mapnik
Autre solution : si tu as assez de mémoire, crée un RAM disk de bonne capacité, qui sera recréé à chaque redémarrage (jamais suavegardé). Les RAMdisk sont le plus souvent en FAT32. Alloue une lettre de lecteur pour lui. Si jamais il est plein, reformatte le plutôt que d'essayer de le vider : le formatage rapide est quasi instantané contrairement à la suppression des fichiers. Note que si le volume de stockage est plein, le cache de JOSM ne sait pas faire du ménage pour faire de la place, il retourne une exception et le chargement de la tuile échoue Autre démonstration de la stupidité de ce cache de JOSM. Au début je ne m'étais pas aperçu qu'il se remplissait autant, et il a crû au point de stocker des centaines de milliers de fichiers, au point de devenir PLUS LENT même à accéder que de faire une requête en ligne au serveur via ma conexion câble à 100 méga. Bref ce cache devient nuisible et ne sert plus à rien ! Le 4 février 2013 23:21, Philippe Verdy verd...@wanadoo.fr a écrit : Il y a des utilitaires divers de nettoyage automatique de Windows, tu peux les paramétrer pour qu'ils allent faire le ménage plus souvent en ajoutant ce dossier. Sinon le dossier peut rester dans le dossier temporaire de l'utilisateur. Mais je suis d'accord sur le fait que le cache de JOSM est mal fichu : si le nettoyage prend autant de temps c'est parce que TOUS les fichiers sont dans le même dossier et que leur suppression un par un oblige Windows à sans arrêt retrier les index. Solution pour accélérer ça : déplacer ce dossier non pas sur un volume NTFS (où les dossiers sont maintennus triés) mais sur un volume FAT. Et là la suppression dans un même dossier contenant des milliers de fichiers va beaucoup plus vite, même si FAT a tendance à se fragmenter énormément. Le cache de JOSM n'est en plus pas conforme à HTTP (il ne tient pas compte des dates de péremption, ni même d'un comptage de volume maximum, et JOSM n'a aucun thread nettoyeur pour virer les fichiers obsolètes ou en excès par rapport au colume maximum indiqué, sans compter aussi que le nombre de fichier est doublé car il stocke un fichier pour la tyuile et un autre fichier pour n'y mettre que les ETag de transaction HTTP, dont la conservation est pourtant totalement inutile dès que la transaction est terminée). Ce cache (en fait c'est le module JTiles) n'a aucune structure comparable à ce que réalisent tout bon navigateur web pour faire des purges efficaces. Le 4 février 2013 22:44, Romain MEHUT romain.me...@gmail.com a écrit : Bonsoir, Sous Windows, JOSM stocke dans un répertoire de cache les tuiles Bing Mapnik. Je cherche un moyen de supprimer régulièrement ces fichiers. Auriez-vous une idée? Windows est à la ramasse pour supprimer près de 6 .png ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [2ème round] Proposition(s) pour un petit coup de balais dans les tags access/oneway
Le 04/02/2013 23:14, sly (sylvain letuffe) a écrit : Re, Suite aux avis exprimés sur : http://lists.openstreetmap.org/pipermail/talk-fr/2013-January/053869.html Je propose une version allégée pour mon premier coup de balais : * Retrait des tags fixme=name uniquement lorsqu'il n'y a pas de nom à l'objet (pas de changement si l'objet à les deux tags name=xx + fixme=name car on considère que le sens est ambiguë) Le 2ème reste inchangé : * Retrait des fixme=set better denotation sur tous les arbres Ok pour moi. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vider le cache des tuiles Bing Mapnik
Merci mais je connaissais déjà la solution (et cela n'est guère plus rapide de supprimer via une commande DOS DELTREE ou RD /S qu'avec l'explorateur Windows). Mais si tu suggères une ligne de commande c'est mieux avec RD/S ou DELTREE en une seule ligne ! Justement ce sont ces 20 minutes qui sont inacceptables ! Et devoir vider totalement le cache est contre-productif : un cache devrait être persistant de sorte qu'on n'ait JAMAIS besoin de le vider manuellement, et faire économiser des ressources au serveur. Le 4 février 2013 23:29, Vincent de Chateau-Thierry v...@laposte.net a écrit : En version rustique, tu peux arriver à tes fins avec une fenêtre DOS et 3 lignes de commande : cd c:\users\login\appdata\local\temp\JMapViewerTiles_login del Bing Aerial Maps\*.png del Bing Aerial Maps\*.tags En fonction du nombre de fichiers ça peut être long (20 bonnes minutes à l'instant pour 18 pngs, misère !) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vider le cache des tuiles Bing Mapnik
Autre solution avec Advanced System Care, tu peux aussi lui demander de nettoyer tous les fichiers plus vieux qu'une semaine dans le dossier temporaire. C'est une bonne solution qui est automatisée et permet de garder un volume raisonnable au cache, sans jamais le vider totalement ; il a un automatisme pour faire une purge programmée tous les jours. Le 4 février 2013 23:37, Philippe Verdy verd...@wanadoo.fr a écrit : Merci mais je connaissais déjà la solution (et cela n'est guère plus rapide de supprimer via une commande DOS DELTREE ou RD /S qu'avec l'explorateur Windows). Mais si tu suggères une ligne de commande c'est mieux avec RD/S ou DELTREE en une seule ligne ! Justement ce sont ces 20 minutes qui sont inacceptables ! Et devoir vider totalement le cache est contre-productif : un cache devrait être persistant de sorte qu'on n'ait JAMAIS besoin de le vider manuellement, et faire économiser des ressources au serveur. Le 4 février 2013 23:29, Vincent de Chateau-Thierry v...@laposte.net a écrit : En version rustique, tu peux arriver à tes fins avec une fenêtre DOS et 3 lignes de commande : cd c:\users\login\appdata\local\temp\JMapViewerTiles_login del Bing Aerial Maps\*.png del Bing Aerial Maps\*.tags En fonction du nombre de fichiers ça peut être long (20 bonnes minutes à l'instant pour 18 pngs, misère !) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vider le cache des tuiles Bing Mapnik
Le 04/02/2013 23:37, Philippe Verdy a écrit : Merci mais je connaissais déjà la solution C'est bien à ton mail que je répondais, mais c'était surtout une réponse à la question de Romain. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Arbres du cadastre vert du CG92 [was: Ouverture de la plateforme Open Data des Hauts-de-Seine]
On 02/04/2013 05:09 PM, Jean-Marc Liotier wrote: On 04/02/2013 14:29, Jean-Marc Liotier wrote: Prochaine tâche : pour chacun de ces jeux de données, créer une page de wiki et y déterminer dans quels étiquettes de natural=tree fourrer les données de chacun des champs offerts par le CG92. Voilà une première passe d'analyse : http://wiki.openstreetmap.org/wiki/WikiProject_France/Open_Data_Hauts-de-Seine_Arbres Commentaires et amendements sont les bienvenus. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [2ème round] Proposition(s) pour un petit coup de balais dans les tags access/oneway
2013/2/4 sly (sylvain letuffe) li...@letuffe.org: * Retrait des tags fixme=name uniquement lorsqu'il n'y a pas de nom à l'objet (pas de changement si l'objet à les deux tags name=xx + fixme=name car on considère que le sens est ambiguë) Ne pas oublier toutes les conjugaisons du tag name (loc_name, name:lg. etc) http://wiki.openstreetmap.org/wiki/Name Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vider le cache des tuiles Bing Mapnik
Il me semblait avoir vu qu'on pouvait indiquer à Windows de ne PAS maintenir le tri de l'index d'un répertoire particulier (comme il le fait par défaut), en y mettant un attribut particulier (dans ce cas, l'index devient une simple liste à parcourir du début à la fin). Pour des répertoires qui ont de très nombreux fichiers mis à jour très souvent, ce tri est plus coûteux qu'utile. Mais je ne retrouve plus l'API sur MSDN. Malgré tout, si un dossier n'est pas trié, il se pose le problème du temps de parcours en entier du répertoire avant d'y créer une nouvelle entrée (sinon il y aurait création d'un doublon), ou pour y retrouver rapidement un fichier par son nom (c'est ce que fait JTiles puisque'il n'organise pas du tout ce dossier où il stocke dans un unique dossier pour chaque fournisseur TMS toutes les tuiles de tous les niveaux de zoom et de n'importe quelle valeur de x et y). Comme JTiles est incapable de faire le ménage (il doit y avoir eu du code pour ça, mais visiblement il ne marche plus ou n'est plus activé), la seule façon de faire cela efficacement serait que JTiles divise son cache en sous-dossiers de sorte qu'il n'y ait jamais plus d'environ 2000 fichiers par sous-dossier. Comment faire ? Déjà il pourrait créer un niveau de dossier pour le niveau de zoom. Supposons la limite à entrées par dossier : le niveau de zoom 5 tient en entier dedans pour toute la planète (je suppose que les tags s'il y en a sont comptés à part, ils peuvent être aussi stockés à part dans un unique fichier index tags), et les niveaux 0 à 4 tiennent aussi dans cette limite. Pour le niveau 6 il faudra 4 sous-dossiers, mais le nombre de sous-dossiers va être multiplié par 4 à chaque niveau de zoom suivant. On tient jusqu'au niveau de zoom 10. Après il faudra augmenter la hiérarchie avec un autre niveau de sous-dossier jusqu'au niveau de zoom 15. Mais à la longue on a alors plein de niveaux de sous-dossiers, plus ou moins pleins, et toujours rien pour faire le ménage. La solution est alors de stocker toujours 2048 entrées par dossier mais stocker tous les dossiers à plat en nombre fini (par exemple 256 sous-dossiers (ce qui fera tout de même 512 000 fichiers, on a de la marge pour un cache confortable !). Pour savoir dans quel sous-dossier stocker ou trouver un fichier, un simple hachage de son nom suffit ! A la suite de quoi tous les dossiers ont une taille raisonnable, ils sont maintenus très rapidement, on peut les lister de façon répétée de façon exhaustive pour y faire le ménage. Le cache peut alors se nettoyer tout seul pour respecter les contraintes de taille totale ou purger les fichiers obsolètes (les fichiers tags sont remplacés par un fichier index unique stockant les métadonnées HTTP, pas seulement les ETag, mais aussi les dates d'obsolescence si nécessaire, bien qu(on puisse aussi décider de rendre tous les fichiers obsolètes une semaine après leur création, à moins qu'on les touche pour les garder en faisant des requêtes HEAD au serveur) Note: sous NTFS un dossier de 2048 entrées prend 512Ko d'index dans la MFT, non compris les attributs longs ou les données de fichiers courts comme les Etags justement qui sont aussi stockés directement dans la même entrée de la MFT sans espace externe supplémentaire). S'y ajoute pour ce dossier un index de tri (sous-forme de B-arbre) qui prend en gros 128Ko (et permet des accès directs rapides à un fichier par son nom). Les suppressions ou ajouts dans un tel dossier ne demandent que peu d'I/O et pas trop d'opération en mémoire. En revanche pour un dossier de plus de 6 entrées (fois 2 avec les fichiers Etag), cela commence à swapper énormément en mémoire et sollicite beaucoup trop les caches disques, à cause des opérations de maintenance du B-arbre (pour maintenir ses critères d'équilibre). Le 4 février 2013 23:45, Vincent de Chateau-Thierry v...@laposte.net a écrit : Le 04/02/2013 23:37, Philippe Verdy a écrit : Merci mais je connaissais déjà la solution C'est bien à ton mail que je répondais, mais c'était surtout une réponse à la question de Romain. vincent ___ 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] [2ème round] Proposition(s) pour un petit coup de balais dans les tags access/oneway
Le 4 février 2013 23:35, Vincent de Chateau-Thierry v...@laposte.net a écrit : Le 04/02/2013 23:14, sly (sylvain letuffe) a écrit : Je propose une version allégée pour mon premier coup de balais Ok pour moi. ok pour moi aussi ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Orthophotoplans de Toulouse
Bonsoir Jean-Guilhem, Jean-Guilhem Cailton a écrit : Les orthophotoplans de Toulouse, réalisés à partir de prises de vue aériennes de juillet 2011 et 2007, avec une taille de pixel de 12,5 cm, et libérés par Toulouse Métropole, sont disponibles en TMS sur wms.openstreetmap.fr. Existe-t-il un « howto » ? :) J'avais effectué quelques essais de mon côté avec GDAL (gdalbuildvrt + gdal2tiles.py) mais : - j'obtenais au final 2,5 millions d'images pour 139 Go de données alors que les 416 tuiles initialement fournies par la ville de Toulouse représentaient 6,5 Go de données ; - la manipulation entraînait une dégradation légère mais perceptible de l'image ; - le traitement nécessitait 65 heures de calcul sur mon PC, les outils n'étant pas multithreadés et ne sachant pas tirer partie des 4 cœurs disponibles. La curiosité technique me pique donc : quels outils as-tu utilisés ? Sont-ils complexes ? As-tu fait des choix particuliers qui expliquent le faible dégradation de qualité de l'image finale par rapport à l'image initiale ? Sébastien -- Sébastien Dinot, sebastien.di...@free.fr http://sebastien.dinot.free.fr/ Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Orthophotoplans de Toulouse
Il me semble que vu les résultats et l'explosion de taille sur le serveur de tuiles pour produire les différents niveaux de zoom, il serait judicieux d'une part de convertir les JPEG en une seule image PNG géante par un prétraitement minimaliste conservant toute la résolution et les couleurs, puis convertir ce PNG en un fichier unique à codage progressif permettant au serveur de répondre directement à une requête de tuile). Même si on a 6,5Go de données avec les tuiles iniales en JPEG, leur conversion en une seule image PNG ne devrait pas dépasser les 50 Go. Ensuite pour produire les images aux autres niveaux de zoom (en divisant par 2, puis 4, puis 8 chaque dimension), cela peut se faire en quelques heures et toutes ces images ensemble ne représentera pas plus de 50 Go non plus. Donc un total voisin de 100 Go au lieu des 139Go obtenus, tout en conservant toute la précision et la colorimétrie. Avec un codage progressif dans une seule image, pour pourrait réduire le volume d'un tiers environ, soit de l'ordre de 65 Go (et très probablement beaucoup moins car plus on zoome et plus la redondance devient importante et le codage différentiel devient performant). Si le serveur de tuile utilise ce seule fichier unique à codage progressif, le nombre d'accès I/O pour une tuile ne sera jamais supérieur au niveau de zoom, tout en profitant d'un cache en mémoire élevé et efficace pour les premiers niveaux. Aure intérêt : on sollicite beaucoup moins les systèmes de fichiers et l'OS. Faire 16 I/O pour récupérer une tuile à servuir au nieavu 16, sachant que les premiers niveaux sont presque toujours en cache (et qu'il y a ensuite une grande chance que des tuiles voisines soient aussi demandées, de sorte qu'on augmente le nombre de hits sur les tuiles différentielles de pas mal de niveaux supplémentaires), permettrait d'avoir un serveur de tuile à la fois très performant, et très stable. Des solutions existent déjà (et servent justement pour afficher sur le web des photos à très haute résolution et de grande taille en pixels). On en a une démo sur Wikimedia Commons, qui sait même servir une unique image JPEG sans codage progressif à la volée pour un affichage tuilé à la demande, le code Javascript ou le code Flash côté client pouvant s'occuper lui-même de faire la recomposition des niveaux progressifs, ou s'il ne le supporte pas, utilisant une autre requête du serveur pour qu'il renvoie les tuiles fusionnant les niveaux progressifs différentiels). C'est très rapide, très efficace, et cela permet à tout le monde de pouvoir regarder même sur un navigateur avec peu de mémoire des photos très grandes et en très haute résolution (en utilisant le chargement progressif, à partir du niveau de zoom le plus bas dans une zone d'afichage de tailel réduite tenant dans la fenêtre disponible). Une telle solution n'est-elle pas possible pour les serveurs de tuiles TMS et pour optimiser leur stockage local (notamment pour optimiser le système de fichiers utilisé) et réduire aussi les temps I/O en maximisant l'utilisation de son cache mémoire, donc aussi pour pouvoir servir plus de requêtes vers plus de monde ? Le 5 février 2013 01:47, Sébastien Dinot sebastien.di...@free.fr a écrit : Bonsoir Jean-Guilhem, Jean-Guilhem Cailton a écrit : Les orthophotoplans de Toulouse, réalisés à partir de prises de vue aériennes de juillet 2011 et 2007, avec une taille de pixel de 12,5 cm, et libérés par Toulouse Métropole, sont disponibles en TMS sur wms.openstreetmap.fr. Existe-t-il un « howto » ? :) J'avais effectué quelques essais de mon côté avec GDAL (gdalbuildvrt + gdal2tiles.py) mais : - j'obtenais au final 2,5 millions d'images pour 139 Go de données alors que les 416 tuiles initialement fournies par la ville de Toulouse représentaient 6,5 Go de données ; - la manipulation entraînait une dégradation légère mais perceptible de l'image ; - le traitement nécessitait 65 heures de calcul sur mon PC, les outils n'étant pas multithreadés et ne sachant pas tirer partie des 4 cœurs disponibles. La curiosité technique me pique donc : quels outils as-tu utilisés ? Sont-ils complexes ? As-tu fait des choix particuliers qui expliquent le faible dégradation de qualité de l'image finale par rapport à l'image initiale ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vider le cache des tuiles Bing Mapnik
Merci pour ces réponses très détaillées ;) Et bientôt je me poserai sans doute aussi la question pour Linux. Romain Le 5 février 2013 00:28, Philippe Verdy verd...@wanadoo.fr a écrit : Il me semblait avoir vu qu'on pouvait indiquer à Windows de ne PAS maintenir le tri de l'index d'un répertoire particulier (comme il le fait par défaut), en y mettant un attribut particulier (dans ce cas, l'index devient une simple liste à parcourir du début à la fin). Pour des répertoires qui ont de très nombreux fichiers mis à jour très souvent, ce tri est plus coûteux qu'utile. Mais je ne retrouve plus l'API sur MSDN. Malgré tout, si un dossier n'est pas trié, il se pose le problème du temps de parcours en entier du répertoire avant d'y créer une nouvelle entrée (sinon il y aurait création d'un doublon), ou pour y retrouver rapidement un fichier par son nom (c'est ce que fait JTiles puisque'il n'organise pas du tout ce dossier où il stocke dans un unique dossier pour chaque fournisseur TMS toutes les tuiles de tous les niveaux de zoom et de n'importe quelle valeur de x et y). Comme JTiles est incapable de faire le ménage (il doit y avoir eu du code pour ça, mais visiblement il ne marche plus ou n'est plus activé), la seule façon de faire cela efficacement serait que JTiles divise son cache en sous-dossiers de sorte qu'il n'y ait jamais plus d'environ 2000 fichiers par sous-dossier. Comment faire ? Déjà il pourrait créer un niveau de dossier pour le niveau de zoom. Supposons la limite à entrées par dossier : le niveau de zoom 5 tient en entier dedans pour toute la planète (je suppose que les tags s'il y en a sont comptés à part, ils peuvent être aussi stockés à part dans un unique fichier index tags), et les niveaux 0 à 4 tiennent aussi dans cette limite. Pour le niveau 6 il faudra 4 sous-dossiers, mais le nombre de sous-dossiers va être multiplié par 4 à chaque niveau de zoom suivant. On tient jusqu'au niveau de zoom 10. Après il faudra augmenter la hiérarchie avec un autre niveau de sous-dossier jusqu'au niveau de zoom 15. Mais à la longue on a alors plein de niveaux de sous-dossiers, plus ou moins pleins, et toujours rien pour faire le ménage. La solution est alors de stocker toujours 2048 entrées par dossier mais stocker tous les dossiers à plat en nombre fini (par exemple 256 sous-dossiers (ce qui fera tout de même 512 000 fichiers, on a de la marge pour un cache confortable !). Pour savoir dans quel sous-dossier stocker ou trouver un fichier, un simple hachage de son nom suffit ! A la suite de quoi tous les dossiers ont une taille raisonnable, ils sont maintenus très rapidement, on peut les lister de façon répétée de façon exhaustive pour y faire le ménage. Le cache peut alors se nettoyer tout seul pour respecter les contraintes de taille totale ou purger les fichiers obsolètes (les fichiers tags sont remplacés par un fichier index unique stockant les métadonnées HTTP, pas seulement les ETag, mais aussi les dates d'obsolescence si nécessaire, bien qu(on puisse aussi décider de rendre tous les fichiers obsolètes une semaine après leur création, à moins qu'on les touche pour les garder en faisant des requêtes HEAD au serveur) Note: sous NTFS un dossier de 2048 entrées prend 512Ko d'index dans la MFT, non compris les attributs longs ou les données de fichiers courts comme les Etags justement qui sont aussi stockés directement dans la même entrée de la MFT sans espace externe supplémentaire). S'y ajoute pour ce dossier un index de tri (sous-forme de B-arbre) qui prend en gros 128Ko (et permet des accès directs rapides à un fichier par son nom). Les suppressions ou ajouts dans un tel dossier ne demandent que peu d'I/O et pas trop d'opération en mémoire. En revanche pour un dossier de plus de 6 entrées (fois 2 avec les fichiers Etag), cela commence à swapper énormément en mémoire et sollicite beaucoup trop les caches disques, à cause des opérations de maintenance du B-arbre (pour maintenir ses critères d'équilibre). Le 4 février 2013 23:45, Vincent de Chateau-Thierry v...@laposte.net a écrit : Le 04/02/2013 23:37, Philippe Verdy a écrit : Merci mais je connaissais déjà la solution C'est bien à ton mail que je répondais, mais c'était surtout une réponse à la question de Romain. vincent ___ 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Des images, des images, des images
Bonjour, Entre autre million de projets inutiles, je m'intéresse à comprendre comment les images s'utilisent en conjonction avec OSM, particulièrement les photos. C'est à dire comment à partir d'une carte on peut voir aussi des photos/images de ce qu'on voit sur la carte, et vice versa. Je suis parti de http://wiki.openstreetmap.org/wiki/Photo_Mapping#Websites.2Fprojects_about_geolocating_photoset j'ai été un peu déçu par le résultat de mon analyse : j'ai l'impression que le seul site de géolocalisation viable est.. Flickr. C'est le seul que j'ai vu en français, et même si son ergonomie est très loin d'être parfaite, au moins il fonctionne. MAIS c'est pas un site de la communauté du libre ? MAIS il présente les cartes, non pas sur OSM, mais sur un obscur plan truc Nokia ? Sur OSM soit même, je n'ai trouvé aucun rendu de photos géolocalisées. Sur Wikimedia, par contre, il existe un système qui est pas mal, et en français. Si, par exemple, je prends la photo image du jour d'aujourd'hui, soit http://commons.wikimedia.org/wiki/File:Taagepera_m%C3%B5isa_peahoone2.jpgje peux voir Voir cet endroit et d’autres images sur : Google Maps / Earth - OpenStreetMap..Je clique sur OSM, et j'arrive à http://toolserver.org/~kolossos/openlayers/commons-on-osm.php?zoom=16lat=57.993408110738lon=25.665869596601et j'y vois la position de la photo, avec d'autres en plus... BIEN. Malheureusement ça mouline un max et l'affichage des tuiles arrive quand il en a envie. Et en plus ce service n'est absolument pas cité dans le wiki d'OSM ? (ou j'ai pas trouvé). Je suis étonné de cette situation. Il me semble que les images sont un élément essentiel du processus de cartographie. Ça permet de vérifier, et de comprendre les choix du cartographe, et de se faire une idée du terrain sous un autre angle. Par exemple tous les carnets de cartopartie pourraient être enregistrés, etc. Bref, y a-t-il qqchose que j'ai pas vu et/ou pas compris dans ma recherche ? Y a-t-il un site en français utilisable et utilisé ? Etc ? Merci. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Des images, des images, des images
Et openstreetview ? http://openstreetview.org/ Le 5 février 2013 08:22, Ista Pouss ista...@gmail.com a écrit : Bonjour, Entre autre million de projets inutiles, je m'intéresse à comprendre comment les images s'utilisent en conjonction avec OSM, particulièrement les photos. C'est à dire comment à partir d'une carte on peut voir aussi des photos/images de ce qu'on voit sur la carte, et vice versa. Je suis parti de http://wiki.openstreetmap.org/wiki/Photo_Mapping#Websites.2Fprojects_about_geolocating_photoset j'ai été un peu déçu par le résultat de mon analyse : j'ai l'impression que le seul site de géolocalisation viable est.. Flickr. C'est le seul que j'ai vu en français, et même si son ergonomie est très loin d'être parfaite, au moins il fonctionne. MAIS c'est pas un site de la communauté du libre ? MAIS il présente les cartes, non pas sur OSM, mais sur un obscur plan truc Nokia ? Sur OSM soit même, je n'ai trouvé aucun rendu de photos géolocalisées. Sur Wikimedia, par contre, il existe un système qui est pas mal, et en français. Si, par exemple, je prends la photo image du jour d'aujourd'hui, soit http://commons.wikimedia.org/wiki/File:Taagepera_m%C3%B5isa_peahoone2.jpgje peux voir Voir cet endroit et d’autres images sur : Google Maps / Earth - OpenStreetMap..Je clique sur OSM, et j'arrive à http://toolserver.org/~kolossos/openlayers/commons-on-osm.php?zoom=16lat=57.993408110738lon=25.665869596601et j'y vois la position de la photo, avec d'autres en plus... BIEN. Malheureusement ça mouline un max et l'affichage des tuiles arrive quand il en a envie. Et en plus ce service n'est absolument pas cité dans le wiki d'OSM ? (ou j'ai pas trouvé). Je suis étonné de cette situation. Il me semble que les images sont un élément essentiel du processus de cartographie. Ça permet de vérifier, et de comprendre les choix du cartographe, et de se faire une idée du terrain sous un autre angle. Par exemple tous les carnets de cartopartie pourraient être enregistrés, etc. Bref, y a-t-il qqchose que j'ai pas vu et/ou pas compris dans ma recherche ? Y a-t-il un site en français utilisable et utilisé ? Etc ? Merci. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Des images, des images, des images
Le 5 février 2013 08:37, Christian Quest cqu...@openstreetmap.fr a écrit : Et openstreetview ? http://openstreetview.org/ Je ne sais pas chez toi, mais chez moi ce site est en anglais, et je ne vois rien qui le fasse passer en français. Pour moi (je voudrais proposer cette démarche à d'autres, pas forcément à l'aise avec l'anglais) c'est stoppant. Et si je clique sur une des photos, rien ne se passe. Et si je clique sur le rendu osmarender je vois un beau rectangle rose à la place de la carte ? En gros, je n'ai pas l'impression que ce site fonctionne. Cordialement. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
