Re: [OSM-talk-fr] cartes personnelles et routes
Bonjour, De : Muselaar Merci pour l'info, mais à ce moment, il s'agirait d'une trace genre gpx ? Sinon, quel genre de fichier on peut insérer, et quel logiciel pourrait les créer ? Tu peux générer des traces au format gpx directement depuis JOSM (clic-droit sur un calque puis Enregistrer sous ou Exporter) ou sinon depuis notamment http://map.project-osrm.org/ où tu peux d'abord composer un itinéraire puis en obtenir la trace en gpx. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Valeur trop grande
De : Francescu GAROBY Je viens d'atteindre la limite maximale autorisée pour une valeur de tag : 255 caractères En l'occurrence, il s'agit des horaires d'une bibliothèque municipale : opening_hours=Tu 14:00-19:00; We 09:00-12:00,14:00-18:00; Th-Fr 14:00-19:00; Sa 09:00- 12:00,14:00-18:00; SH Tu 14:00-18:00; We 09:00-12:00,14:00-18:00; Th-Fr 14:00-18:00; Sa 09:00-12:00,14:00-18:00; PH Tu 14:00-18:00; We 09:00-12:00,14:00-18:00; Th-Fr 14:00- 18:00; Sa 09:00-12:00,14:00-17:00 Vu sur Taginfo, mais a priori pas documenté comme tel, le tag opening_hours:PH. Ça permet de splitter sur 3 tags : opening_hours, opening_hours:PH et opening_hours:SH. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Revoir l'extraction des adresses du cadastre (était [import lieux-dits (avec fixme)])
De : Christian Quest vdct travaille aussi sur le sujet des lieux-dits côté BANO. Vérifiez que vous ne faite pas les choses en double et avec un résultat différent. Un peu d'harmonie dans ce monde de données brutes ;) Le 2 août 2014 15:13, Tyndare a écrit : Je fais une proposition de nouveau format pour le fichier des noms de lieux-dits générés depuis le cadastre, voir un exemple ici: http://dl.free.fr/bOdG4FdS9 Les différences par rapport à avant: - fichier zip à part - tag place= laissé vide - plus de fixme - fichiers nommés lieux-dits*.osm au lieu de QUARTIERS*.osm - LISEZ-MOI.txt - nouveau fichier limites_lieux-dits_-_NE_PAS_ENVOYER_SUR_OSM.osm qui contient juste des limites (un multipolygon par lieu-dit), je pense que c'est utile pour évaluer le nombre de maisons et donc remplir le tag place correctement (enfin pour ceux qui arrivent à comprendre le tag place...) J'attends vos commentaires avant de potentiellement rendre ça dispo sur cadastre.openstreetmap.fr Sur les lieux-dits, il y a de quoi faire pour 2 :) De mon côté je n'ai rien fait de concurrent, juste avancé (mais pas encore terminé) sur le sujet des suffixes de noms de voies qui parfois forment un hameau. J'aurai plus de temps après mi-août pour terminer. Pour la proposition de Tyndare, je trouve que ça va tout à fait dans le bon sens. J'ai 2 remarques : - je me demande si, dès lors qu'on veut éviter que certaines données soient envoyées, on ne gagnerait pas à directement en faire un layer raster, plutôt qu'un format .osm toujours sujet à boulettes ? Ceci pour les emprises des lieux-dits. - concernant les fichiers ponctuels de lieux-dits, j'enlèverais carrément le tag place plutôt que vide car JOSM le prend comme tel, et on a donc le risque de remplir la base avec une valeur 'vide' malheureuse. Sachant que un point avec juste un name=* sans autre tag n'a aucune chance d'être utilisé ni représenté sur les rendus, ça donne une motivation pour explicitement en rajouter un. vincent ps. gazette Bano : les rapprochements OSM-cadastre dépassent 621K voies et les adresses dans OSM culminent à 2.19M, ça avance ! http://munin.openstreetmap.fr/bano-day.html ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Revoir l'extraction des adresses du cadastre (était [import lieux-dits (avec fixme)])
De : Tyndare Le 2 août 2014 16:15, V de Chateau-Thierry a écrit : - je me demande si, dès lors qu'on veut éviter que certaines données soient envoyées, on ne gagnerait pas à directement en faire un layer raster, plutôt qu'un format .osm toujours sujet à boulettes ? Ceci pour les emprises des lieux-dits. Je suis d'accord mais je te laisse t'occuper de ça car je n'ai aucune idée de comment faire des raster. Ça marche. Je vais collecter les parcelles du cadastre vectoriel France, via Bano, et je suis sûr que Christian se fera un plaisir de crayonner ça avec les bonnes couleurs pur qu'on ait un rendu donnant les limites des noms de parcelles, et les noms bien lisibles. On aura au passage une visu des limites de communes, et donc parfois des divergences de tracé entre cadastres mitoyens... J’espère quand même que personne n'osera envoyer sciemment un fichier nommé NE PAS ENVOYER et qui en plus affiche une fenêtre d'avertissement dans JOSM si on essaye quand même de le faire. C'est vrai que ça fait beaucoup :) - concernant les fichiers ponctuels de lieux-dits, j'enlèverais carrément le tag place plutôt que vide car JOSM le prend comme tel, et on a donc le risque de remplir la base avec une valeur 'vide' malheureuse. Sachant que un point avec juste un name=* sans autre tag n'a aucune chance d'être utilisé ni représenté sur les rendus, ça donne une motivation pour explicitement en rajouter un. Là pas d'accord. En laissant place= JOSM affiche un avertissement de validation au moment de l'envoie des données Clé 'place' non valide - Attributs avec des valeurs vides Alors que sans le tag place JOSM ne bronche pas. Je trouve que ça limite grandement le risque d'oublier de préciser une valeur. Mouais. Un avertissement, ça s'ignore... Sur le principe, ça me chiffonne que la manière la plus simple (comprendre : la plus en aveugle) d'envoyer de la donnée soit avec une donnée bancale. Un name seul, ok, c'est pauvre, mais un tag vide, ben... par définition, ça n'a pas de valeur. M'enfin. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Présentation et propositions
Bonjour bienvenue, Le 31/07/2014 13:59, dHuy Pierre a écrit : Je comptais simplement produire un .osm avec mon script, traiter 300 entrées à la main est relativement rapide avec josm :) Le Jeudi 31 juillet 2014 13h49, Pieren a écrit : 2014-07-31 13:31 GMT+02:00 dHuy Pierre : Je souhaiterais proposer l'intégration des données de Paris Open Data sur la ville de Paris pour le wifi ( OpenData ). Je propose à cet effet l'utilisation d'un petit script et l'utilisation du tag source:ParisData (opendata.paris.fr). Salut et bienvenue sur la liste. Pour un import sur une ville grande comme Paris, il faut prendre certaines précautions et le tag source est probablement le dernier de tes soucis (qu'il faudrait d'ailleurs mettre d'avantage sur le changeset que sur chaque élément). Ton premier pas - celui de contacter la communauté - est déjà un très bon point. D'autres pourront dire ici s'ils sont déjà dans ce processus ou pas concernant ces données. Il faudrait aussi voir si rien n'est dit dans le wiki concernant cette source et ce groupe de données. Sinon, ton script devra de toute façon tenir compte de l'existant et ne pas créer de doublons. Par exemple, les mairies, les bibliothèques et les parcs sont pratiquement tous déjà dans OSM et il serait inutile de créer des noeuds juste pour ça alors qu'il suffirait d'ajouter tes tags de wifi sur les éléments existants (donc je doute que le script soit si petit). Il faudrait aussi nous préciser quels données vont vers quels tags avant l'import pour éviter les surprises. Au cas où : pour passer en revue tes 300 points, le plugin ToDoList de JOSM est très pratique : http://wiki.openstreetmap.org/wiki/JOSM/Plugins/TODO_list Sur l'avancement du chantier wifi, je n'en ai pas idée, mais tu dois pouvoir te faire un avis en récupérant via Overpass tous les objets de Paris et alentours avec les tags à base de http://wiki.openstreetmap.org/wiki/Key:internet_access et en regardant l'ancienneté de saisie et la variété de contributeurs, ça devrait te donner un état des initiatives, et une base pour le rapprochement de tes objets. Rien à voir mais s'il t'arrive d'être parisien (géographiquement parlant) alors il ne faut pas hésiter à venir discuter autour d'un verre le dernier vendredi de chaque mois vers 19h. Les adresses varient (se rencarder ici au cas où) mais c'est toujours assez central. Et début septembre (le 8) on fêtera les 10 ans d'OSM au NUMA (rue du Caire, Paris 2e), en soirée. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Revoir l'extraction des adresses du cadastre (était [import lieux-dits (avec fixme)])
Bonsoir, Le 28/07/2014 15:15, Tyndare a écrit : L'extraction des des points place=neighbourhood depuis le cadastre à été mentionnée dès le début sur la liste dev-fr https://lists.openstreetmap.org/pipermail/dev-fr/2014-January/001986.html et est aussi décrite sur le wiki de l'outil: http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi- automatique_des_adresses Mais si ça pose problème, pas de soucis je le désactiverais ce soir en attendant qu'on arrive a générer des données moins erronées. Malgré les précautions prises (wiki, fixme=*), il faut bien admettre que les données n'ont pas été intégrées, mais juste importées. La bascule de place=neighbourhood en place=locality ne change pas fondamentalement le problème, à savoir que chaque node mériterait une évaluation en propre pour choisir une valeur de tag place adaptée. Je suis donc aussi d'avis de désactiver cette mise à dispo de la couche des nodes place via l'outil d'extraction d'adresses. Si ce fil permet de réfléchir à une meilleure heuristique pour la détermination algorithmique des valeurs du tag place, on y gagnera, au passage. Overpass renvoie 56883 nodes avec le même fixme=à vérifier Un tel volume ne rime à rien avec ce tag. Je suis d'avis de supprimer ces points, car je prends le pari qu'ils ne seront pas revus un par un avant une éternité. Si pas d'opposition, je peux me charger de cette suppression dans la semaine. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Couche Bano
Bonjour, De : Stéphane Péneau Qu'en est-il de l'état de la couche Bano ? J'ai des trucs bizarres, avec des rues corrigées il y a pas mal de temps, dont la concordance n'est toujours par faite, et d'autres plus récentes qui ont bien été mises à jour. Tu n'as pas la berlue :) Il y a environ 3 semaines, la base, réplique d'OSM, qui alimente BANO, a dû être ré- importée. Mais il y a eu pas mal d'embûches au cours du process. Une màj de BANO a eu lieu une fois cette base réimportée... jusqu'au moment où il a été détecté que la base était incomplète (il manquait une semaine de mises à jour fin juin/début juillet). Tout ça est réparé depuis hier soir, et j'ai relancé une mise à jour des rapprochements avec le cadastre ce matin. Ça va tourner toute la journée, et le graphe qui témoigne des évolutions est ici : http://munin.openstreetmap.fr/osm12.free.org/osm104.openstreetmap.fr/bano_rapproche.html L'impact sur le rendu BANO est normalement une disparition de rouge au profit du bleu. À vos caches :) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Relation route et giratoire
De : Pieren De toute façon, comme la plupart des giratoires sont mis en entier dans OSM, les logiciels de routage sont obligés de calculer les sections entrée-sortie eux-même (avec ou sans relation route). D'accord avec ça. Ceux qui font ces découpages ne le font donc que pour avoir un meilleur rendu à l'écran de leur itinéraire. Pas forcément, ou pas uniquement. Il y a déjà une part de logique : si mon bus n'emprunte pas telle portion de voie, pourquoi l'inclure dans le trajet ? Il y a aussi le besoin de vérifier ce qu'on fait en cours d'édition : un outil comme l'éditeur de relations de JOSM indique visuellement la continuité ou la rupture entre 2 ways successifs. C'est bien utile pour constater la connexité, que ce soit pour la fermeture d'un mutlipolygon ou la continuité d'une route. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Relation route et giratoire
Bonjour, PS : N'oubliez pas que dans les modèles routables, les RP sont généralement réduit à un noeud. Les RP n'ont d’intérêt que pour le rendu alors il est bien inutile de les découper. (et ça rend sa maintenance bien difficile). Oh que non. C'était vrai au XXè siècle, ça :) Aujourd'hui dans les BD du commerce, d'une échelle de saisie comparable à OSM (Here, TomTom, Google) les rond-points sont décrits en détaillant chaque entrée, chaque sortie, et toutes les portions qui forment la partie circulaire sont découpées à chaque intersection. Donc dire (plus haut dans ce fil) : Les logiciels de navigation le font déjà très bien c'est oublier qu'ils s'appuient sur un graphe où chaque croisement de plus de 2 ways occasionne un découpage. Un rond-point basique à 4 entrées sera composé de 8 ways. Je suis d'accord qu'un enjeu est de garder la marche d'entrée la plus basse possible pour la contribution. Mais pousser le curseur à l'extrême opposé en supposant que les logiciels consommateurs sauront se dépatouiller seuls, ça n'est pas forcément non plus nous rendre service pour la démocratisation de l'usage d'OSM. vincent (découpeur de rond-points sauf quand le bus fait un tour complet...) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Relation route et giratoire
De : Francescu GAROBY La question est alors : vaut-il mieux un rond-point complet (en 1 seule way), que les logiciels de navigation découperont en autant de ways qu'il y a d'E/S sur ledit rond- point, ou vaut-il mieux prémâcher le travail, au risque de créer des erreurs comme celle signalée par Sylvain ? Les erreurs sur les rond-points ne sont pas cantonnées à un mauvais découpage : http://osmose.openstreetmap.fr/fr/map/#zoom=9lat=47.674lon=0.666layer=Mapnikoverlays= FFFTitem=1050%2C2010%2C4020level=1%2C2%2C3tags=fixable=bbox=-0.57025 90942382811%2C43.172133836120246%2C-0.1517486572265625%2C43.37211393444652 Donc oui bien sûr, en découpant les rond-point il y a un risque de provoquer des erreurs. Mais c'est tellement vrai pour à peu près tout dans OSM que je n'en ferai pas un argument spécifiquement sur notre sujet. Perso, je pense qu'il est plus facile, pour un logiciel, de découper quelque chose de fermé selon des points bien précis, que de souder des ways qui se touchent, car il pourrait ne pas souder les bons morceaux (les ronds-points n'ont pas toujours de belles formes circulaires). Face à un rond-point découpé, quel besoin justifierait comme tu le dis de recoller les morceaux ? Je ne dis pas qu'il n'y en a pas, mais pour les besoins les plus triviaux (carto, calcul d'itinéraire) ça ne se justifie pas. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pourquoi je quitte OSM
Bonjour, De : Pieren Je ne crois pas que ce soit une bonne idée. Le tag name doit avoir la même signification s'il est sur un node ou une relation. En plus, ça casse la cohérence et le lien qu'on crée avec le admin_centre. Il est fort possible que certains outils QA vérifient ça dans le futur et signalent ça comme une erreur (si ça n'est pas déjà le cas). Qu'est ce que tu appelles cohérence ici ? Le nom porté par un node place=* par ailleurs admin_centre n'a aucune obligation d'être identique à celui de la relation qui le référence. (Et il y a un paquet de cas en base aujourd'hui) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Parcs départementaux du 92
Bonjour, Vu passer cette annonce d'il y a quelques semaines : http://opendata.hauts-de-seine.net/actualites/actualite/plans-topographiques-des-parcs- et-jardins-des-hauts-de-seine J'ai regardé rapidement un des jeux de données. C'est du DXF (que sait ouvrir QGis) en Lambert CC zone 8. Le niveau de détail géométrique est sympathique, avec la délimitation notamment de chaque carré de pelouse. On trouve du ponctuel, du linéaire, du surfacique. Bref, il y a peut -être matière à enrichir notre description des grands espaces verts des Hauts-de-Seine. Le détail de la nomenclature utilisée : http://applis.hauts-de-seine.net/v3fichiers/openData/CG92-NOMENCLATURE_TOPO_v2.0.pdf vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pourquoi je quitte OSM
De : JB Après avoir laissé poser quelques heures, je repars du message initial, parce que je me rends compte que « le terrain prime » n'est pas si clair, si affirmatif, si définitif chez plusieurs/beaucoup de personnes. Dont certains que je considère des anciens, des sages, d'OSM. Et ça me pose vraiment question. Pourtant, cette méthode semblait faire des émules chez des politiques, je repense à la personne de Dammarie-les-Lys qui expliquait au SOTM-FR que la mairie avait repris des arrêtés pour faire correspondre les noms « officiels » aux panneaux de rue quand les deux ne correspondaient pas. Et voilà que maintenant, on nous explique, que non, il va falloir aller voir sur les sites des mairies, sur le cadastre, sur les délibérations, sur les usages, faire un sondage, des ratios, et décider quel est le nom « juste » ? La vérifiabilité, elle va passer comment, là ? Le nom du village, mon bon contributeur, c'est pas celui que tu utilises ? Va contribuer ailleurs, si on t'embête. Tiens, la méthode n'est pas la même dans les zones de conflits territoriaux, puisque là, c'est l'usage local qui prime. Il va falloir déclarer Vers-sur-Selle zone en conflit. Un peu dépité, alors que la simplicité du « terrain » me plaisait beaucoup, à moi aussi. Tu pars du postulat que le terrain est homogène. Alors qu'il lui arrive, ça a été encore rappelé ce matin, d'être contradictoire. La même rue avec des variantes d'orthographe selon les plaques, le hameau avec à chaque extrémité un panneau d'entrée, mais là encore autant de variantes d'écriture que de versions. Pas si simple, justement ! Sur ce fil, il y a aussi l'idée que des sources éloignées du terrain (le COG, l'INSEE) primeraient sur le local. Or il a été plusieurs formes rappelé qu'il y a dans OSM la place pour plusieurs interprétations : on a name, mais aussi loc_name et official_name. Côté communes, on a les relations, et les nodes place. Je suis tout à fait d'accord avec la proposition d'Eric pour distinguer un nom par défaut officiel dans les relations admin, et un nom par défaut plus terrain sur les nodes place. Si on reste sur un débat un peu manichéen entre terrain et administrations centrales (en très résumé et avec beaucoup de guillemets) on loupe un truc je pense. Sans oublier que les usages potentiels de la base ne sont, par définition, pas limités. Donc évitons de trancher entre tout l'un et tout l'autre, organisons plutôt une base riche des deux, il y la place pour. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pourquoi je quitte OSM
Bonjour, De : Emmanuel Aubert Et maintenant, grâce à un certain BANO, il retrouve ses rues d'il y à 50 ans. Bon, comme je suppose que c'est encore le reste qui prime, je m'en vais. Si tu peux dire à quelle(s) rue(s) tu fais référence, ça permettra peut-être de lever un lièvre sur comment Bano s'y prend pour collecter les adresses. Plus généralement si la discussion permet de remotiver un contributeur plutôt que de le faire fuir, on y aura gagné :) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] changement global de tags
Bonjour, De : david.croc...@online.fr Sous JOSM, charger les données de la zones concerné Dans les attributs, bouton rechercher puis addr:city=Chatillon addr:postcode=92320. Valider Au dessus, sélectionner la clé addr:city puis modifier la valeur de même pour l'autre clé. Tu peux aussi cibler les objets concernés via taginfo : http://taginfo.openstreetmap.fr/tags/addr%3Acity=Chatillon puis les charger dans JOSM. Mais on peut aussi se demander si addr:city, addr:postcode et addr:country répétés sur des points d'adresses est bien nécessaire... vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : voies anormalement longues
De : mga_geo Merci de cette réponse rapide. Effectivement je ne vois pas comment automatiser le traitement de ces erreurs du cadastre. Est-il possible de créer une note (ou autre élément) pour indiquer à BANO ces erreurs du cadastre ? Pour l'instant il n'existe pas de circuit de remontées d'erreurs de ce type, qui leur donne une chance d'être traitées sur la durée. C'était tout l'objet du banocamp de samedi que de commencer à décrire le parcours de l'adresse, des producteurs, via bano, jusqu'aux consommateurs _et_ avec un retour des derniers vers les premiers, pour à force d'itérations fiabiliser l'information. La réflexion n'en est qu'à ses débuts. Typiquement, dans un cas comme tu en montres aujourd'hui d'adresses qui, bien que proposées par le cadastre, n'existent vraisemblablement pas, l'hypothèse de corriger dans OSM ne fonctionne pas. Corriger un positionnement géo ou une orthographe, c'est simple, corriger l'existence même d'un point, en le supprimant, nécessite une gestion en propre, qui reste à imaginer. D'ici là il restera du rouge ou du bleu sur le rendu bano, sans point vert à proposer à la place, pour ces adresses superflues. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO et fichiers adresses
Bonjour Moyroud Nicolas ;) De : Nicolas Moyroud Dans la collection des anomalies remontées par BANO, je suis aussi tombé sur un cas intéressant dans le village de Murviel-lès-Béziers. Toutes les rues nommées d'après une personne ont les noms et prénoms inversés dans le cadastre. Du coup BANO remonte tout en rouge. http://www.openstreetmap.org/#map=17/43.43924/3.14312 Mais ça va être un peu difficile à gérer ce genre de cas non ? Les joies du cadastre ! Si le phénomène est limité à une commune, le mieux reste de le gérer manuellement, par exemple en intégrant les adresses. Je peux faire quelques comptages (ce soir) pour voir si le cas se reproduit ailleurs, au moins pour les noms les plus courants (Clemenceau Georges par ex.). dct vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Autolib', service d'autopartage ou location ?
De : Dominique Rousseau Autolib' c'est le Vélam^H^Hib de la bagnole, et c'est à mon sens un service de location en libre service ; donc car_rental Je suis aussi de cet avis, quand le service est à but lucratif. À la lecture de cette page : http://fr.wikipedia.org/wiki/Autopartage_en_France je ne vois pas de différence entre location et autopartage commercial. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO et Numérotation des lieux-dits
Bonjour, De : Jérôme Amagat ça n'a pas grand chose a voir avec les adresses je suis daccord :) Ne pas hésiter à ouvrir un fil dédié. Il me semble par contre que pour qu'une place soit reconnu pour bano il faut que le nom se trouve avec un tag hightway donc ça marche pas sur le nœud d'intersection au milieu de la place ou pour le nom du parking. Il y a 2 tickets convergents sur le sujet : https://github.com/osm-fr/bano/issues/14 https://github.com/osm-fr/bano/issues/21 Ce qu'il faut en retenir, c'est qu'à terme le ref:FR:FANTOIR sera considéré quel que soit le type d'objet, tant d'un point de vue géométrique que sémantique, dès lors qu'un tag name=* lui est associé. Donc une fois de plus, ne pas faire en fonction de Bano, c'est à Bano de s'adapter. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO et Numérotation des lieux-dits
Bonjour, De : Ab_fab Pour la liaison avec la base BANO, je ne saurais pas répondre. Concernant les nœuds adresse, je dirais que c'est plutôt OK. La nuance étant que je n'aurais pas mis le tag name = nom_du_lieu-dit sur chaque nœud. http://www.openstreetmap.org/node/1028765846 Cela n'apporte rien par rapport à la balise addr:hamlet = nom_du_lieu-dit qui est elle aussi dans la description du nœud. Côté Bano, le sujet 'lieux-dits' est bien identifié mais pas encore traité. Il y a dans les données que nous récupérons du Cadastre une information de nommage, qui doit permettre de reconstituer l'emprise (toute théorique) d'un lieu-dit, sous la forme d'un ensemble de parcelles. L'idée ensuite est de rapprocher le nom de ces emprises des noms des nodes place=* inclus (quand ils existent) ou a minima de proposer le nom issu du cadastre comme élément d'adresse, et de le positionner au mieux par rapport aux zones bâties présentes dans les parcelles. Un rapprochement avec le Fantoir est aussi à faire dans ces cas. Pour la numérotation dans les lieux-dits, ça donne des adresses de quelle forme ? Numéro et nom du lieu-dit sur la même ligne, puis CP et nom de commune ? vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [FANTOIR] deux entrées pour une voie : rue ou chemin
Bonjour, De : René-Luc Dhont Le plus simple est d'avoir une seule relation et de concaténer les codes FANTOIR avec un ; ça marche ? je pensais qu'il ne fallait pas faire comme ça ? Je ne suis pas pour non plus. Laisser en rouge des zones indécises, où un passage terrain est quasi inévitable, me semble plus efficace. Que sur le rendu restent en rouge certaines voies, ça n'a rien de scandaleux. De mon côté en saisissant des adresses depuis ma chaise, je mets de plus en plus de 'notes' directement sur osm.org pour les endroits où une revue de terrain s'impose. Un prétexte à prendre son vélo, qui s'en plaindra ? :) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Code Fantoir
Bonjour, De : JB C'est valide, ça, comme code Fantoir, avec un A au milieu ? 10387A063Y-10,10,Vergers des Noels,1,Troyes,CAD,48.292142,4.103530 Ça a un sens particulier ? Apparemment oui, ça signifie : Ensemble immobilier Tiré de cette doc : http://collectivites- locales.gouv.fr/files/files/gestion_locale_dgfip/national/FANTOIR_Descriptif.pdf vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Couche BANO HS ?
Bonjour bjr, De : Nicolas Dumoulin Le jeudi 12 juin 2014 14:27:22 Christian Quest a écrit : renderd semble chauffer un peu trop... relancé et avec mise à jour progressive du rendu BANO avec les rapprochements de ces derniers jours. Et avec le rapprochement des attributs ref:Fantoir sur la relation, youhou ! Nouvelle itération cette nuit (elle doit être en train de se terminer) pour commencer à gérer les Grande Rue Grande Rue et autres Rond Point Rond Point. Si la mécanique est là, la liste des cas gérés [1] est pour l'instant en deçà de ce qu'on trouve dans les données. On observe déjà un gain néanmoins [2]. N'hésitez pas à noter les cas que vous rencontrez, par exemple dans le fil de ce ticket : https://github.com/osm-fr/bano/issues/15 Il manque au moins des Gpl Grand Place, aperçus hier dans Fantoir. merci merci vincent vincent [1] : https://github.com/osm-fr/bano/blob/master/abrev_type_voie.txt [2] : http://munin.openstreetmap.fr/osm12.free.org/osm104.openstreetmap.fr/bano_rapproche.html ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Couche BANO HS ?
De : Hamlet j'ai un problème, à Villeneuve-d'Ascq [0] Pas de ref:FANTOIR a priori, et pas de rapprochement à cause du voie communale. J'ai mis ref:FR:FANTOIR=no comme indiqué dans le wiki. [1] Je vous laisse vois comment gérer ce genre d'exception. Vu. Ça rentrera dans ce ticket : https://github.com/osm-fr/bano/issues/13 vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bano - nouveaux rapprochements ?
Bonjour, De : JB Est-ce que le mise à jour des tuiles Bano est toujours en cours ? J'ai beau rafraichir depuis hier après-midi, ça n'évolue pas beaucoup (alors que les fichiers csv à disposition semblent bons). Elle a eu lieu dans la nuit de lundi à mardi. De ce que j'avais vu, les soucis que tu avais pointés y étaient pris en compte ? Actuellement une nouvelle itération a lieu, suite à l'ajout de 96 communes passées en cadastre vectoriel depuis mi-mai, et qui n'avaient pas encore été intégrées. Un point plusieurs fois remonté depuis ce week-end, mais pas encore géré, concerne les voies toujours en rouge car nommées différemment entre le cadastre et OSM, et pour lesquelles le code Fantoir est dans la relation associatedStreet. Si tu constates, même après un /dirty, des anomalies, merci de les faire remonter, ici ou sur github. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Découpage des futures régions...
Bonjour, De : Yves Hmm... je ne peux m'empêcher de penser que l'on s'éloigne d'éléments strictement vérifiables en mappant des regions hypothétiques. Mais bon, 14 relations c'est accessoire si ça ne devient pas une habitude, et que personne ne casse de relation en collant aux débats à venir ... Comme l'impression qu'on a eu exactement le même débat il y a quelques mois : https://lists.openstreetmap.org/pipermail/talk-fr/2013-February/055632.html et suivants. Pour moi il y a confusion ici entre deux casquettes d'OSM : - OSM la base, où on devrait se limiter à du vérifiable (ce qui peut inclure certains projets si le terrain témoigne de leur avancement) - OSM le diffuseur de données, notamment ici : http://www.data.gouv.fr/fr/organization/openstreetmap qui a déjà pris le parti de diffuser des données pas uniquement issues de la base OSM. Ça a été le cas avec le contour des EPCIs avant qu'ils soient intégrés dans la base en début d'année. Les fichiers proposés étaient un mix des géométries d'OSM et des attributs de l'INSEE, pas passés par la case base OSM. C'est aussi le cas avec BANO bien sûr. Et à mon sens ça devrait être le cas avec ce projet de redécoupage des régions : une donnée qui intéresse du monde, qui peut être dérivée des données de _la base_ OSM, mais qui n'est pas strictement une donnée légitime dans la base en l'état. Vue la présence grandissante d'OSM-Fr dans le petit monde géomatique (pas plus tard qu'aujourd'hui Christian et Gaël sont aux Rencontres de l'Afigéo), je pense qu'il faut être clair sur le rôle de diffuseur de données qui se dessine petit à petit pour l'association, et l'assumer. Diffuser à ce titre les données actuelles du projet de redécoupage me semble tout à fait cohérent, mais c'est différent d'un stockage des mêmes infos dans la base OSM. vincent ps. et j'ai même pas parlé de umap pour une fois :) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu BANO : Actualisation
Bonjour, De : Art Penteur Et si j'interprète bien le rythme de progression qu'on peut voir sur GitHub, et si rien ne bloque la machine d'ici-là, on peut prévoir que les données BANO du département 85 seront remises à jour d'ici 8 à 10 heures. Après, il faudra sans doute attendre environ une semaine Ça peut semble long quand on piaffe après avoir fait une correction, mais je trouve le rythme très correct vu l'énorme travail que ça représente, et l'on peut remercier l'équipe BANO, qui a produit un magnifique outil de QC/QA des voies OSM de France. Ne pas vendre la peau de l'ours trop tôt... mais on devrait changer d'échelle de temps pour la prochaine mise à jour. En effet, on sollicite pour l'instant l'Overpass pour rafraîchir les données OSM injectées dans BANO. Le chantier du week-end est de débrancher ce flux au profit de l'accès à une base de données voisine de la base BANO, et mise à jour en continu. Un objectif (que j'espère réaliste) serait de descendre sous les 24h France entière, afin de chaque jour pouvoir rafraîchir chaque commune. Autre dimension des mises à jour : la prise en compte des communes nouvellement vectorielles du cadastre. Depuis le début de BANO début mai, plusieurs dizaines de communes sont passées d'image à vecteur. Il va falloir là aussi se placer en mode de mise à jour continue. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu BANO
Bonjour, De : Jean-Marc Liotier On 22/05/2014 08:28, Christian Quest wrote: Nous allons devoir traiter ça en exception... Ca n'est certes pas moi qui ait l'écriture du code sur ma TODO, mais j'ai comme un hérissement de poils à l'idée d'introduire des cas d'exception de ce genre, que les générations futures devront maintenir - si elles s'en rappellent... Le traitement de cette exception ne devrait-il pas plutôt consister en la généralisation des ref:FR:FANTOIR sur cette commune ? D'accord avec toi Jean-Marc, il faut juste être conscients du phénomène suivant : - on a la rue à (anciennement) Caudéran - on a une autre rue xxx ailleurs dans Bordeaux Pour l'instant, et sans gérer d'exception, on va rattacher les 2 entités au même code Fantoir qui correspond à la rue xxx à Bordeaux. C'est a posteriori qu'il faudra détecter 2 choses : - un code Fantoir absent d'OSM, et qui correspond à la rue xxx de Caudéran - une relation associatedStreet avec des membres 'street' déconnectés et très éloignés les uns des autres et corriger unitairement. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu BANO
Bonjour, De : Christian Quest Merci pour les retours et surtout les avoir mis noir sur blancs. J'ai constaté à peu près la même chose de mon côté. Comme toute source, c'est une aide et pas une référence absolue ! Il faut qu'on vérifie pour les codes FANTOIR, il y en a qui correspondent à des voies temporairement nommées ou des voies qui n'existent plus et on a une info à ce sujet qu'on n'exploite pas encore. Les voies qui n'existent pus (= avec un code d'annulation dans FANTOIR) sont exclues des tentatives de rapprochement. Pour les abréviations, il manque effectivement quelques traitements qui empêchent les rapprochements. Il manque quelques traitement qui permettraient :) des rapprochements, en étant moins stricts sur la correspondance des voies, notamment sur le type de voie. C'est un sujet identifié mais pas encore traité. Pour les types de voie redondants dans le nom, je l'ai remarqué sur Grande Rue Gde Rue, ça aussi il faut qu'on améliore. Aujourd'hui on traite des bizarreries comme GR GRANDE RUE ou PCH PETIT CHEMIN mais pas Grande Rue Gde Rue. Toutes les remontées sont les bienvenues afin de compléter cette liste : https://github.com/osm-fr/bano/blob/master/abrev_type_voie.txt On termine la collecte initiale (pour avoir une vue d'ensemble), et on va pouvoir se focaliser sur ces améliorations. Notamment la prise en compte du code Fantoir présent dans les données OSM, qui doit être prioritaire sur toute tentative de retrouver un code dans la source Fantoir. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Projet BANO : bonne manière de taguer
De : Pieren Il faut faire très attention avant de se lancer dans un import à partir de cette base BANO en odbl. La discussion sur la liste en anglais a soulevé un problème sur la licence non négligeable (même si ça reste très théorique) : en cas de changement éventuel de licence dans le futur, il se pourrait que nous soyons obligés de supprimer les adresses venant de BANO. Alors qu'on pourrait conserver celles venant directement du cadastre. Il serait donc plus prudent pour l'instant d'utiliser cet outil pour identifier les manquements mais de prendre ensuite les données directement depuis le cadastre. J'ai suivi cette discussion sur talk@ et sa tournure m'a franchement étonné. Il ne me serait jamais venu à l'idée d'utiliser BANO comme source d'import vers OSM, pour moi le lien est fondamentalement dans l'autre sens : OSM alimente BANO. Le cercle vertueux est ensuite : BANO est utilisée, des problèmes ou lacunes dans son contenu sont détectés, ils sont corrigés dans OSM, et le prochain rafraîchissement de BANO profite de ces corrections. Et ainsi de suite. Il y a des bénéfices connexes, comme la représentation carto des adresses initiée par Christian, et qui contribue, via JOSM, à cibler les zones à qualifier (aka le dégommage des points rouges). Mais pour ce qui est d'importer des adresses, je renvois aux fichiers disponibles à : http://cadastre.openstreetmap.fr/?type=adresses qui ne sont d'ailleurs pas à importer mais à intégrer :) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Projet BANO : bonne manière de taguer
De : Tyndare J'aurais voulu éviter d'embrouiller encore plus le débat, mais je ne suis pas d'accord pour écarter totalement l'interpolation comme mode de cartographie des adresses. C'est vrai que les données extraites du cadastre nous incitent pas à l'utiliser, mais ce mode pourrait avoir un grand avantage: il permettrait de modéliser une fois pour toute une bonne approximation de toutes les nouvelles adresses qui pourront être créées dans le futur dans une rue donnée, en particulier pour les rues ayant adopté la numérotation métrique (j'ai l'impression que c'est quasi systématique pour les nouvelles numérotations). Il y a de nombreuses communes en France avec une très faible densité de population, et dans certaines aucun contributeur local ne s'est manifesté au bout de 10 ans de projet. Dans son dernier post de blog Christian donne le chiffre de 200.000 nouvelles adresses chaque année en France [1], je ne vois pas pour l’instant comment OSM pourrait suivre ce rythme de manière à la fois réactive et homogène sur tout le territoire. Peut-être que BANO y arrivera en intégrant des données brutes issues de fournisseurs institutionnels ou autre, mais pour OSM comment on fait pour les zones sans contributeur local actif ? Comme on n'arrive pas à se mettre d'accord sur où positionner les point adresses, est-ce que l'on ne pourrait pas considérer l'interpolation comme une approximation durable et évolutive, potentiellement affinée par des points adresses additionnels ? Le seul truc qui m'embête c'est que j'ai l'impression d'après le Wiki [2] que l'utilisation de l'interpolation suppose que toutes les adresses interpolées aient une existence alors que cela ne serait pas du tout le cas avec une numérotation métrique. J'ai réagi à la question d'Arnaud car il pointait une zone où on est capable de proposer des fichiers d'adresses unitaires à intégrer. Je trouve vraiment dommage dans ce cas là de prendre le temps de modéliser une interpolation : c'est qualitativement moins riche et à peine moins fastidieux. Après, que les interpolations restent nécessaires, c'est possible. Mais je vois vraiment ça comme une solution de repli, pas quelque chose à promouvoir en premier lieu. Tu soulèves le problème de l'absence de contributions sur une zone, et c'est un des moteurs pour l'initiative BANO actuelle : comme on n'a pas la masse critique de contributions nécessaires pour proposer dans un délai raisonnable toutes les adresses par extraction d'OSM, on construit une alternative qui se veut complémentaire d'OSM et vertueuse vis-à-vis du projet. Là où je veux en venir, c'est qu'à un endroit où personne n'a contribué en 10 ans, au moins aucun 'local', je pense que le débat n'en est pas à : interpolation ou adresses unitaires. On part (hélas) d'un peu plus loin. Et ensuite, quitte à consacrer du temps de contribution sur les adresses, autant le faire sur les adresses unitaires, au moins là où le cadastre est vectoriel. L'interpolation est peut-être notre plan B à activer sur les communes en cadastre raster. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] boules=petanque vs. type=petanque
Bonjour, De : Jean-Marc Liotier D'après http://wiki.openstreetmap.org/wiki/Tag:sport%3Dboules un terrain (leisure=pitch) de pétanque est: sport=boules boules=petanque (375 noeuds, 75 ways - http://overpass-turbo.eu/s/3op) Mais d'après http://wiki.openstreetmap.org/wiki/FR:Key:sport c'est: sport=boules type=petanque (607noeuds, 111 ways - http://overpass-turbo.eu/s/3oo) Bon... Des avis sur une future harmonisation du pointage ou du tirage de l'étiquetage bouliste ? Le tag type=* et sa variante *:type=* est à mon avis une des pires idées mises en oeuvre. Plus fourre-tout, c'est difficile. Donc je pencherais sans hésitation pour la version pour l'instant la moins populaire (boules=petanque), dont j'aime bien le principe : une propriété tag=valeur + une autre valeur=sous-ensemble, c'est déclinable...à l'infini ou presque :) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Adresses : Problème des noms de rue identiques dans des communes associées
Bonjour, De : Christian Quest Le 12 mai 2014 10:36, Pieren a écrit : Ces 2 adresses sont dans la commune de St Maur des Fossés (code INSEE 94068), mais on n'indique jamais St Maur sur un courier qui va à La Varenne (ou par erreur)... certaines personnes pensent même que c'est une commune à part entière. Concernant le tag place, il ne doit pas y avoir de problème puisque le cas d'un polygone avec plusieurs places est fréquent. Par contre, pour le code postal, je reviens sur ma proposition de faire comme les allemands (qui ont les mêmes problèmes que nous): déplacer touts les codes postaux dans leur propre relation/polygone de type boundary=postal_code: http://wiki.openstreetmap.org/wiki/DE:Konsolidierung_der_PLZ- Relationen_in_Deutschland_2013 http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dpostal_code De mémoire c'est ce que j'ai fait pour mon cas local particulier. Le généraliser à tout les codes postaux alors qu'on a l'info modéliser autrement en France, ça me semble bien lourd et surtout l'impact sur des utilisateurs actuels n'est pas négligeable. J'éviterai. Pourquoi éviter ? Propager ce modèle aurait surtout des avantages, je trouve : - cohérent avec celui de nos voisins - compatible avec notre granularité de codes postaux, qui navigue entre multi-communal et infra-communal - cerise sur le gâteau : ça peut se faire en douceur, sans impact sur les modèles actuels (essentiellement le addr:postcode sur les relations admins), en procédant par ajout de ces nouvelles zones, sans suppression du tag addr:postcode sur les relations admins. Quitte ensuite, et ce sera souhaitable, à communiquer sur l'obsolescence du modèle actuel et inciter les consommateurs à basculer sur le nouveau. Bon après, ça s'appuie sur le tag postal_code au lieu de addr:postcode, ce qui je trouve est une mauvaise idée (2 tags pour la même notion), mais bon... vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] tag amenity:police
Bonjour, De : Mides concernant le tag amenity:police, et ayant besoin de référencer un poste de police municipale, je ne trouve pas une possibilité de distinction pouvant être faite entre : gendarmerie nationale, police nationale et police municipale. Pourriez vous me confirmer que cette possibilité n'est pas offerte, le wiki sur ce sujet n'étant pas des plus explicites. Taginfo mentionne un timide police:FR (17 occurrences) avec comme valeur 'police_municipale' ...juste une fois. Mais il faut bien commencer :) http://taginfo.openstreetmap.org/keys/police%3AFR#values vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] tag amenity:police
De : Mides J'aime bien le terme Operator pour une boite de télécommunication mais ça me fait tout drôle s'il faut marquer : Operator:Gendarmerie Nationale. Remarque, pour les speed_camera ça pourrait le faire plus facilement ;-) Pour ce qui est du tag police:FR... effectivement il faut un début à tout, mais c'est quand même timide. Le but de ma question était de voir comment je pouvais m'y prendre pour effectuer une requête API, sur ce tag Police, avec un résultat souhaité par famille :-) Stats, pourcentages, occupation géographique, etc. Une fois récupérés les objets taggués en amenity=police, c'est surtout le tag name qui pourra te renseigner sur les spécificités d'un poste de police : http://taginfo.openstreetmap.org/search?q=police+municipale#values http://taginfo.openstreetmap.org/search?q=gendarmerie+nationale#values http://taginfo.openstreetmap.org/search?q=police+nationale#values en l'état de la base. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Share alike ou le partage à l'identique
Bonjour, De : THEVENON Julien Il me semble qu une partie de la discussion a eu lieu sur Talk non ? Par contre le principcal argument developpe etait plutot si il n y avait pas de Share Alike alors des gens comme Google reutilsieraient nos donnees et donneraient une bien meilleure visibilite a OSM Merci Pieren de pas avoir fait si court que ça :) Concernant l'hypothèse de suppression, est-ce que le raisonnement suivant est valide : - à j, OSM supprime la clause SA - à j+1, n'importe quel éditeur de BD géographiques fermées récupère tout le contenu qui l'intéresse dans OSM pour enrichir sa propre base Et au delà de j+1, chacun de ces éditeurs, fort de son saut qualitatif ponctuel grâce à OSM, continue sa petite vie sans reverser quoi que ce soit à OSM et sans plus jamais se servir dedans, s'épargnant les casse-têtes de consolidation dans le temps. - à j+1 aussi, la valeur singulière d'OSM s'effondre vu que chacun de ses concurrents dispose de son contenu propre ET du contenu OSM en plus. Fin du projet... C'est très raccourci, je sais. Mais pour le dire de façon claire et partisane : je suis archi-contre la suppression du SA car je ne vois pas le projet y survivre. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Imagerie mondiale DigitalGloble disponible pour OSM
Bonjour, De : Bruno Cortial Mapbox grants You a license to tracing imagery to produce derivative vector datasets for non-commercial purposes, including tracing in OpenStreetMap. Producing derivative vector datasets from imagery for commercial purposes requires buying a Mapbox Commercial Satellite license. Je dessine à partir de l'imagerie fournie par MapBox - je verse le résultat dans OSM -- j'utilise OSM sur la même emprise pour constituer un produit que je vends Au final, j'ai bien utilisé la source d'imagerie de MapBox, via un passage dans OSM, pour un usage à caractère commercial. J'ai une vision tordue de la chose, ou bien il y a comme une contradiction dans les droits qu'ils allouent ? vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Imagerie mondiale DigitalGloble disponible pour OSM
De : THEVENON Julien Ils font peut etre une exception pour OSM. C est pareil avec l imagerie Bing non ? Oui, mais c'est la formulation même de l'exception que je trouve bancale : ...for non-commercial purposes, including tracing in OpenStreetMap M'enfin... vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Service de pré-intégration d'adresses
De : Pierre Knobel J'ai une question à propos de l'outil : j'ai trouvé une commune qui a un mélange de numérotation normale et de numérotation métrique : Wintzenbach. L'outil me donne une rue Schongauer avec un numéro, mais quand je regarde sur le cadastre que j'ai dans JOSM je ne trouve pas cette rue. En vérifiant sur Google Maps, je trouve bien la rue à l'endroit où l'outil m'a placé le numéro. Du coup je m'interroge : est-ce que l'outil utilise bien la même source du cadastre que le plugin JOSM ? Est-ce que c'est possible que certaines infos dans le fichier PDF du cadastre soient présentes mais ne soient pas visible dans JOSM ? Ca expliquerait peut-être beaucoup de problèmes de numéros manquants sur des portions de rues. Oui la source est la même, en revanche la stratégie requise par le plugin, à savoir appeler par tuiles de taille fixe, induit un biais d'affichage. C'est un constat fréquent sur les noms de rue, qui plus est s'ils sont longs : ne sont affichés dans JOSM que les caractères du nom inclus dans la tuile où figure le premier mot, qui a le point d'accroche du texte avec lui. Pour les portions du texte situées sur d'autres pavés, le point d'accroche n'étant pas dans le même pavé, le texte n'est pas affiché. Il manque la logique de meta-tuiles de Mapnik ici :( Dans ces cas-là, pour vérifier qu'un nom, invisible dans JOSM, existe bien au cadastre, il faut se replier sur un affichage directement sur http://www.cadastre.gouv.fr/ car l'affichage carto n'y rencontre pas le même biais. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] SOTMFR: programme de samedi en ligne + quelques précisions
Bonjour, De : Romain MEHUT On envoie une invitation à la FFRP pour écouter Benjamin JEAN? ;) Pour particulièrement cette session, une restitution sera la bienvenue. Scribes welcome :) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] natural=cloud
Bonjour, De : Pierre-Yves Berrard Génial ! On l'attendait avec impatience. Et ça valait le coup d'attendre ;-) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] API OSM et BBOX
Bonjour, De : Mides Bonjour, je cherche un peu d'aide quant à savoir comment inclure des paramètres bbox dans un requête. API J'utilise la syntaxe suivante, http://oapi-fr.openstreetmap.fr/xapi/? node[amenity=hospital]bbox[-0.818714,42.725465,2.323375,43.829215], mais apparemment les données bbox ne sont pas prisent en compte et tout le territoire est sélectionné. Si des fois quelqu’un passe par là. Tu dois légèrement modifier ta syntaxe : pas de '', et 'bbox' à l'intérieur des []. de: node[amenity=hospital]bbox[-0.818714,42.725465,2.323375,43.829215] à : node[amenity=hospital][bbox=-0.818714,42.725465,2.323375,43.829215] cf.:http://wiki.openstreetmap.org/wiki/Xapi#BBox_Predicates vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] JOSM : impossible d'envoyer les modifications
Bonjour, De : Gaël Simon L'envoi est très long, bloque sur la fameuse relation, puis se ferme au boit d'un moment. Je vois ce matin qu'une partie de mes modifications a été prise en compte avec 43 objets modifiés sur 86 demandés. Si je renvoie mes modifs, je suppose qu'il y aura des doublons et même encore ce blocage sur la relation ? Comment puis je terminer mon import sans risque ? Tu peux essayer d'envoyer les éléments non encore envoyés, à l'exception de la relation : - dans le panneau de recherche, tu tapes comme critère 'modified' : ça devrait te sortir la relation et les ~40 éléments non encore envoyés - tu sélectionnes quelques-unes des modifs parmi celles identifiées, puis tu demandes leur envoi via le menu 'Fichier Envoyer la sélection' - tu itères si besoin, en contournant la relation... vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rectificatif sur les nouveaux cantons
De : Vincent de Château-Thierry J'ai placé le message d'erreur dans ce ticket : http://trac.openstreetmap.fr/ticket/527 Un souci d'accès à la base Postgres. À peine posté, déjà corrigé. Merci Jocelyn ! Concrètement, comcommaker fonctionne à nouveau (testé à l'instant). vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Périmètre 2014 des EPCIs : à vos Mapcrafts, prêts...
Bonjour, De : Romain MEHUT A noter la mise en ligne de la nouvelle version de Banatic https://www.banatic.interieur.gouv.fr/V5/accueil/index.php qui (sauf erreur) ne propose pas les contours des EPCI. Oui, mis à jour, mais pas sur le point de la licence. On peut toujours lire ici [1]: Les informations mises en ligne sur le site www.banatic.interieur.gouv.fr sont publiques et ne sont couvertes par aucun droit d’auteur (art. L. 122-5 du Code de la propriété intellectuelle) ; elles peuvent être reproduites librement, sous trois conditions : - gratuité de la diffusion ; - le respect de l’intégrité de l’information reproduite (aucune modification, ni altération d'aucune sorte) ; - la citation explicite de la source du producteur : DGCL – Banatic et la mention selon laquelle les droits de reproduction sont réservés et strictement limités. Toute utilisation à des fins commerciales ou publicitaires est interdite. Un peu anachronique... vincent [1] : https://www.banatic.interieur.gouv.fr/V5/mentions-legales/mentions-legales.php#4 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Atelier OSM aux rencontres Decryptageo
Bonjour, De : Nicolas Moyroud Hé bien ce serait avec grand plaisir (d'autant que je serai présent sur Paris le week-end précédent pour le SOTM-FR) mais n'ayant pas obtenu l'accord de mon organisme pour participer aux rencontres décryptagéo, ce serait à mes frais. Et à 335€ le tarif d'entrée faut pas pousser... Si tu parles de l'entrée aux Rencontres Decryptageo, elle est libre pour l'accès général aux stands. Et a fortiori en tant qu'exposant, si tu viens animer le stand OSM et contribuer aux ateliers. Après il y a l'accès aux conférences, qui lui est payant (il me semble). vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Atelier OSM aux rencontres Decryptageo
De : Nicolas Moyroud Ce qu'il y a c'est qu'il faudra que je pose 3 jours de congés donc j'aimerai bien en profiter pour assister à quelques conférences. Si il y a moyen d'obtenir un tarif réduit par OSM France ça m'intéresse beaucoup ! Il y aura un accès aux conférences _sans frais_ pour les encadrants de l'atelier OSM. J'en ai eu confirmation. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] pompage du tracé du tram à Dijon
Bonjour, De : Dlareg Google map reprend le tracé du tram sur Dijon, si j'en suis sûr c'est que c'est moi qui est rentré cette portion de rails et que le défaut d'écartement des rails (cf lien) est le même sur Google map : http://tools.geofabrik.de/mc/? lon=5.04553lat=47.32619zoom=18num=4mt0=mapnikmt1=google-mapmt2=bing-mapmt3=mapnik- german Il y a d'autre endroit ou c'est visible. Il y a aussi des endroits où les deux sources sont clairement différentes : http://tools.geofabrik.de/mc/?lon=5.051lat=47.328zoom=18num=2mt0=mapnikmt1=google- map (à l'intérieur de la place) Plus les deux versions sont fidèles au terrain, plus elles ont des chances de se ressembler, sans pour autant que l'une dérive de l'autre. Il faudrait pouvoir indiquer un élément côté OSM notoirement exagéré / décalé / faux, et pointer sur Google la même erreur, pour étayer. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nokia recrute sur OSM pour son projet HERE
De : Steve Grosbois Bonjour à tous, J'ai été surpris en recevant ceci ce matin sur ma messagerie OSM : On est surement plusieurs à l'avoir reçu... Here est la partie Maps de Nokia. C'est de l'humour Finlandais ? Reçu à l'instant (mot pour mot). Du coup je suis allé voir ici : http://here.com/services/terms Je serais bien curieux de savoir ce que représente une communauté HERE [] autour des contributeurs OSM... vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Périmètre 2014 des EPCIs : à vos Mapcrafts, prêts...
Bonjour, De : Vincent Meurisse Merci pour ces délicieux gâteaux. Le premier est déjà fini. Vu :) Malheureusement, de nombreuses modifications que j'ai du faire sont en fait des changements qui dataient de 2013, 2012 voire même 2011. Initiative à refaire tous les ans pour garder des donnés à jour. À noter que pour deux ECPI (sur les 20 que j'ai regardé), le nom était incorrect dans OSM. Si une âme charitable se sens de faire une analyse… Pour les périmètres erronés, voire manquant, en effet beaucoup d'EPCIs n'avaient pas bougé depuis un tracé initial vers 2011. L'absence de limites communales n'incitait pas non plus à se ruer sur le sujet. Ça n'est plus le cas, on est maintenant en phase de maintenance, au moins annuelle via le fichier INSEE des appartenances de communes aux EPCIs. Il restera quelques mouvements en 2015, ça devrait être plus calme ensuite. À noter qu'au rang de nos valeurs ajoutées, il faudra pointer le changement de périmètre du Grand Lyon, qui va intervenir au 1er juin 2014 avec l'arrivée de Quincieux. À nous d'être à l'heure et de le faire savoir :) À l'instant sur les 3 Mapcrafts restants, il n'y a plus que 89 EPCIs à vérifier... http://mapcraft.nanodesu.ru/pie/374 http://mapcraft.nanodesu.ru/pie/375 http://mapcraft.nanodesu.ru/pie/376 vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Compatibilité CC-By-Sa et OBDL
Bonjour, De : Jean-Marc Gailis La carte OSM est sous licene Odbl, la mention CC-BY-SA est erronée, c'est l'ancienne licence d'OSM. Ce qui est sous OdBL, ce sont les données. Le rendu carto peut être en CC, comme c'est le cas sur osm.org = http://www.openstreetmap.org/copyright vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Service de pré-intégration d'adresses
Bonjour, Suite aux travaux qu'a initié Tyndare, présentés ici [1] se met en place un service dédié à la thématique 'Adresse', qui vous rappellera le service d'accès aux bâtiments vectoriels du cadastre. L'idée est de mettre à disposition l'information relative aux adresses, telle que fournie dans le cadastre, mais mise en forme afin d'en faciliter l'intégration dans OSM. On parle bien d'intégration et non d'import. Concrètement, via l'interface disponible ici : http://cadastre.openstreetmap.fr/adresses/ vous pouvez générer un jeu de données qui, pour une commune, appréhende toutes les adresses (numéro de voie + nom de voie) et les présente à raison d'un fichier par voie. Cette granularité de présentation nous a semblé la plus propice à une intégration. La modélisation de l'information d'adresse ne fait pas consensus. On peut recourir au schéma de relation associatedStreet ou au tag addr:street. On peut placer l'information sur un bâtiment, sur un bord de bâtiment, sur un bord de propriété près de la voie. Bref, différents styles, qui expliquent que les fichiers mis à disposition pour une commune sont multiples. Une page vise à clarifier l'offre de contenu : http://wiki.osm.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_adresses Techniquement le service est tout jeune, n'hésitez pas à signaler les problèmes rencontrés sur Trac : http://trac.openstreetmap.fr/newticket?component=export%20cadastreowner=vdct Concernant les différentes manières de positionner l'information d'adresse relativement à la voirie et aux bâtiments, le débat est loin d'être clôt, n'hésitez pas à l'engager ici même. merci pour vos retours Tyndare vincent [1] : https://lists.openstreetmap.org/pipermail/talk-fr/2014-January/065794.html ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Service de pré-intégration d'adresses
De : Tetsuo Shima J'ai une erreur tout a la fin au moment ou les fichiers sont produit, ainsi les liens des fichier produit sont innacessible. Tu as bien des fichiers disponibles ici : http://cadastre.openstreetmap.fr/data/057/ L'erreur ne concerne qu'un des 4 styles de fichiers, le style 'mixte'. Un ticket est ouvert à ce sujet : http://trac.openstreetmap.fr/ticket/497 vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Déterminer le système de projection de données
Bonjour, Avec le volume grandissant de sources de données brassées par ici, du fait de l'opendata, ce site, annoncé surGeorezo, pourra intéresser du monde :http://dogeo.fr/_apps/projection/ Le principe : disposer simplement des coordonnées d'un point, formulées dans une longue liste de systèmes de projections. Çapeut par moments aider à déterminer dans quelle projection sont fournies des données, quand les metadonnées manquentet qu'il faut mener son enquête. vincent___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] bureaux de poste
Bonjour, De : Olivier Delaune Après récupération des données de Mantilly, je me suis aperçu qu'il ne s'agissait aps de l'ancien bureau de Poste mais du relai poste qui est situé dans l'épicerrie (depuis la fermeture du « vrai » bureau de poste). Du coup, ça a quand même le tag « amenity:post_office » ? Tu viens de mettre le doigt sur un bug :) Dans le cas d'un relais de poste chez un commerçant, on avait convenu de typer en combinant 2 tags : amenity=post_office post_office:type=post_partner Initialement dans les données de la Poste ce type était décrit : Relais poste commercant (sans cédille). Mon test s'appuyait dessus. La cédille est apparue dans les mises à jour des données de la Poste, mais je n'avais pas suivi ce point. C'est réparé à l'instant dans l'outil, pour les points intégrés à l'avenir. Pour le relais de Mantilly, tu peux rajouter le tag manuellement. merci vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Problème accès tms orthophotographie seveur OSM-FR
Bonjour, De : Romain MEHUT Bon en tout cas, les tuiles ne s'affichent pas ex: http://wms.openstreetmap.fr/tous- tms-fr?zoom=16lat=48.64784lon=6.15221layers=TB0 Pour par exemple cette tuile : http://wms.openstreetmap.fr/tms/1.0.0/tous_fr/17/67779/45209 j'ai une erreur http500 avec ce message : An error occurred: msDrawMap(): Image handling error. Failed to draw layer named 'nancy_2012'. msDrawRasterLayerLow(): Unable to access file. Corrupt, empty or missing file '/data/work/wms/nancy/CUGN_2012_LBT1.ecw' for layer 'nancy_2012' vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment tagguer un haras?
Bonjour, De : David Crochet Le 05/02/2014 13:21, THEVENON Julien a écrit : J ai trouve animal=horse_walker pour l une des installations, j utilise leisure=pitch sport=horse_racing pour la piste d entrainement mais je ne sais pas quoi mettre sur le polygone definissant l emprise du haras landuse=farmyard ? En anglais ça semble se dire stud farm : http://en.wikipedia.org/wiki/Stud_farm Il y a un (petit) paquet de valeurs contenant ce terme dans la base, mais surtout dans un tag name : http://taginfo.openstreetmap.org/search?q=stud_farm#values L'occasion d'inaugurer landuse=studfarm ? vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Placer le siège sociale d'une entreprise
Bonjour, De : Francescu GAROBY Je voulais placer le siège social de l'entreprise Biocoop, mais je réalise que je ne sais pas trop comment taguer ça. En effet, il ne s'agit pas d'un magasin Biocoop (comme ici ou là), mais bien du siège, donc uniquement constitué de bureaux administratifs. Du coup, vous tagueriez ça comment vous ? Il y a 9000+ office=company d'après Taginfo http://wiki.openstreetmap.org/wiki/Tag%3Aoffice%3Dcompany Sinon on trouve aussi 300 office=Headquarters (avec un 'H'), pas documenté mais dont on peut deviner l'intention. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] tracer les voies de circulation ?
Bonjour, De : Pieren 014/1/20 hamster : - les petits bouts de voies dans les zebras pour tourner a gauche sont dessines inutile Sauf que ça reste à mon avis la manière la plus simple et intuitive de matérialiser qu'une file est dédiée au tourner-à-gauche, séparée du reste par des zebras. Les ways en question sont taggués en '*_link', je trouve ça tout à fait correct. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] tracer les voies de circulation ?
De : Christophe Merlet A : Discussions sur OSM en français Copie à : Objet : Re: [OSM-talk-fr] tracer les voies de circulation ? Le 20/01/2014 13:36, JB a écrit : Et ce qui me dérange un peu : En venant du nord-ouest, pour tourner à gauche, il va falloir : - Aller sur la voie du milieu, - tourner à gauche sur l'autre sens de la voie rapide, - tourner à droite sur le tertiary. À mon sens, il faudrait au moins rassembler en un point unique celui de la voie du milieu et celui du tertiary. Idem dans l'autre sens. Et bien sur, bien vu pour l'impossibilité d'aller du tertiary au secondary en face ! Je rajoute le lien OSRM http://osrm.at/6aI Cliquez sur Inverser pour voir dans l'autre sens Ça démontre bien l'absurdité de ce type de représentation qui se veut ultra réaliste :/ Je trouve que tu mélanges (abusivement) 2 problèmes pour pouvoir argumenter. On a d'un côté un problème (que je n'avais pas vu lors de mon précédent message) de logique de circulation, bien soulevé par Frédéric : des portions connectées sur le terrain sont séparées dans le dessin, donc routage problématique. Là dessus pas vraiment de débat, et vrai besoin de corriger. Mais le point initial (que tu englobes au passage alors qu'il est indépendant) était de dessiner de façon séparée ou non les files dédiées à une manœuvre (ici un tourner à gauche). Sur ce point je reste convaincu du bien fondé de l'intention sur la zone donnée en exemple. Je peux indiquer un endroit dont je me suis occupé et qui reprend les mêmes principes : http://www.openstreetmap.org/#map=19/43.71224/2.20666 (note : mes dernières modifs sur le type des highways sont issues de la discussion en cours) Les problèmes de connexité et de logique de circulation n'ont pas besoin de ce niveau de détail pour apparaître. Il y a juste à se balader sur cette vue pour s'en rendre compte : http://keepright.ipax.at/report_map.php? zoom=7lat=46.81663lon=2.96712layers=B0Tch=0%2C50%2C191%2C192%2C193%2C194%2C195%2C196% 2C197%2C198show_ign=1show_tmpign=1 vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] admin_centre et nom de commune
Bonjour, De : JB Une note relevée ici : www.openstreetmap.org/note/101498 « Depuis le 1er janvier 2014 : fusion des communes de Saint germain sur l'Arbresle et Nuelles, donnant naissance à la commune de Saint-Germain-Nuelles (69208) » La nouvelle commune a bien été crée début janvier avec l'admin_level 8, les anciennes sont passées à l'admin_level 10, et l'admin centre utilisée sur la nouvelle commune est Saint-Germain sur L'arbresle, sans modification de son nom, d'où un nom différent de la relation et de l'admin_centre. Aux amateurs de limites administratives et sans forcément vouloir avoir plus de 100 réponses, cela vous semble-t-il cohérent ? Oui. (= j'aurais fait de même) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] admin_centre et nom de commune
De : Jérôme Amagat C'est les communes qui ont fusionnées et ont changées de nom, et non les villes de Saint-Germain sur L'arbresle et Nuelles. C'est pas parce que le plus souvent c'est le même que le nom de la commune et la ville où il y a la mairie doit avoir le même nom. Oui, la commune en tant qu'entité administrative. Ce que tu appelles ville relève plutôt ici du bourg, au sens d'une zone, même modeste, mais avec une relative continuité de bâti et surtout un nom au moins consacré par l'usage et qui figure sur les panneaux d'entrée de la zone bâtie. Lui ne change pas dans le cas présent. La conséquence est qu'on ne change pas le nom du node taggué en place=village correspondant. À la rigueur, s'il est suivi sur les panneaux, entre parenthèses, d'une mention commune de xxx, ce texte-ci peut changer (sur le terrain) mais c'est tout. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] le nouveau modèle économique de l'IGN... en avant première
Bonjour, De : HELFER Denis +6.000.000 !!! De ce que je comprends cette somme correspondrait à 15% de la masse salariale : il va manquer 5 à 6 millions d’euros pour payer le personnel. Car il faut bien savoir que l’IGN est un établissement public administratif – pas industriel et commercial – dont la dotation de l’Etat qu’il reçoit ne couvre pas la masse salariale (seulement 85 %). Belle mise en perspective, indirectement et toutes proportions gardées, de la valeur potentielle du travail des fourmis... vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] EPCI
De : Jérôme Amagat Je me demandais si les Communautés de communes qui cessent d'exister à cause de fusion ou démembrement, est-ce qu'il faut les supprimées d'OSM ou pas? En fait j'en ai déjà supprimé :) C'est aussi comme ça que je procède, depuis le 1er janvier. La donnée EPCI est en grand chantier en ce moment. C'est, pour l'instant, une compilation de territoires à jour et dotés d'une référence INSEE (SIREN), de territoires obsolètes car fusionnés ou étendus depuis qu'ils ont été définis dans OSM, et de territoires nouvellement crées mais pour l'instant dépourvus de SIREN. Il faudra encore quelques semaines (mois ?) pour que tout ça se stabilise. Une première étape, même sans tous les SIREN (pour ça, on dépend du timing de publication de l'INSEE), serait d'avoir une bonne définition des territoires avant les élections municipales de mars, où les délégués communautaires seront aussi élus. Avoir un fond de carte à proposer pourrait intéresser, notamment, les medias. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] EPCI
De : Francescu GAROBY Ce tableau ne peut-il pas être obtenu via Wikipedia ? Le nom de l'EPCI apparait déjà dans le cartouche Infobox de chaque commune et la page dudit EPCI contient le code INSEE. C'est vrai quand c'est à jour. Et là-dessus, pour faire des allers-retours entre OSM et WP depuis 1 mois sur le sujet des EPCIs, je fais le constat d'une grosse hétérogénéité selon les articles. Avoir déjà un état de l'appartenance d'une commune à un EPCI, du strict point de vue OSM, serait bien. (Au passage il doit y avoir par ci par là des communes comprises dans 2 EPCIs à la fois faute de mise à jour synchronisée...). vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] EPCI
De : Francescu GAROBY Et depuis le site de l'INSEE ? Y a pas moyen d'extraire ça facilement ? Si, mais... seulement à partir du jour où l'INSEE publie la liste des communes et des EPCIs :-) Pour les EPCIs apparus au 1er janvier, rien encore de diffusé de leur côté. Sauf changement ça se passera par ici : http://insee.fr/fr/methodes/default.asp?page=zonages/intercommunalite.htm et/ou sur data.gouv.fr, mais si c'est comme les années passées ça ne vient qu'au bout de quelques semaines, pas le 2 janvier à 08:00 :-) Lundi dernier je leur ai posé la question de la date de diffusion mais pas encore de réponse. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Bonjour, De : Pieren Il y a de nombreuses relations qui n'ont qu'une partie de la rue (sans parler des rues sans adresses). Ca veut dire que tous les segments de rues qui ne sont pas dans la relation n'auront pas de code fantoir ! Soit vous forcez tout le monde à mettre tous les segments de la rue dans la relation (ce qui serait en quelque sorte une redéfinition de la relation qui n'était pas faite pour ça à l'origine), soit vous laissez le code sur les ways. Je croyais que le code fantoir était lié aux voies, pas aux adresses. Et là, on mélange un peu les serviettes et les torchons. Mettre tous les segments dans la relation apporterait un intérêt à cette construction un peu informe qu'est la relation associatedStreet. Avec une incitation claire à intégrer tous les ways, on gagnerait en homogénéité, et on pourrait envisager des usages de façon plus fiable, sans avoir à se demander où est le morceau de rue inclus dans la relation, ni quelle proportion de la géométrie complète de la rue il couvre. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] WMS ortho du CRAIG disponible en CC45/CC46
Bonjour, De : Landry Breuil je crois que c'était une demande de christian pour pouvoir faire du calage de cadastre sur de l'ortho dans JOSM (je me souviens plus bien), mais j'ai ajouté les projections EPSG:3945 EPSG:3946 dans les projections possibles pour le flux wms.craig.fr/osm. Caler, ou tout simplement superposer et pouvoir basculer de l'ortho au cadastre sans jongler avec les projections ou configurer un proxy. Bref, merci. ps: l'ortho 2013 arrive d'ici le printemps 25cm sur les départements, 10cm sur les 6 agglos :) Alors vivement le printemps :-) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] WMS ortho du CRAIG disponible en CC45/CC46
De : Ista Pouss
Heu ahem l'occasion pour moi de vous demander humblement s'il n'existe pas
qqpart un
tutoriel style 'l'horto pour les archi nuls
Tu as ça (mais en anglais) :
http://josm.openstreetmap.de/wiki/Help/Preferences/Imagery
avec une version française, mais qui n'est pas une traduction.
Dans le cas du CRAIG, pour configurer l'accès à un calque en particulier dans
JOSM, tu
vas dans les préférences (F12) puis WMS/TMS, puis tu demandes à ajouter un
calque
('+WMS' à droite) et dans la zone en haut 'URL du service', tu tapes ça :
http://wms.craig.fr/osm?service=wmsrequest=getcapabilities
Ensuite tu fais ton marché.
vincent
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import addr:housenumber depuis le cadastre
Bonjour, De : Tyndare J'ai essayé d'installer sur un serveur web temporaire les scriptes dont j'avais parlé ici https://lists.openstreetmap.org/pipermail/dev-fr/2013-October/001747.html Cela permet de les lancer sans installation compliquée: http://37.187.60.59/cadastre-housenumber/ Ce n'est pas extensivement testé donc à utiliser avec prudence... La grosse limitation reste toujours que le programme ne récupère que le numéro depuis le cadastre, et pas le nom de rue associée. Je ne me sent pas vraiment capable d'aller bien plus loin dans l'automatisation ou dans l'intégration web, mais si certains sont motivés, le code est ici: https://www.gitorious.org/cadastre-housenumber/cadastre-housenumber Merci pour cette mise à dispo sous forme de service, où en 3 clics et quelques instants on récupère un fichier prêt à l'intégration. Je ne suis pas allé plus loin que la génération du fichier et l'ouverture brute dans JOSM mais ces étapes sont passées avec succès, à l'instant. Par comparaison avec l'outil Adresses du plugin Cadastre-fr, l'existence des adresses sous forme de fichiers pourrait faciliter une répartition, sur une même ville, de l'intégration entre plusieurs contributeurs, par ventilation avant mise à dispo des adresses dans des fichiers par quartier, carroyage ou autre. Est-ce que ça donnerait un levier pour lancer un chantier d'intégration un peu massif ? Dans le même temps, les mêmes fichiers sont, pour certains, un prétexte à import brut. Espérons que non mais il ne faut pas nier la possibilité. taginfo.fr recense 1.500.000 addr:housenumber en ce début d'année. Combien en décembre ? vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Membre qui mappe n'importe quoi
De : Philippe Verdy Au moins il a le mérite de mettre des noms clairement imaginaires (en espagnol). Il se veut peut-être aménageur et recense ses projets ou désirs de pistes et remontées lors de ses ballades ? Ou bien recense-t-il de projets de pistes dont il a entendu une rumeur mais qui n'ont jamais abouti ? Le 3 janvier 2014 15:10, remont...@free.fr a écrit : Je viens d'apprendre de la part d'un autre contributeur l'existence d'un membre qui mappe strictement n'importe quoi : jusqu'à des stations inexistantes. Celui-ci ne mappe plus depuis 1 mois, mais il est important de le signaler : http://www.openstreetmap.org/user/skiguru Pour info (ou rappel), il existe une liste dédiée à ce type d'info. Voir : http://wiki.openstreetmap.org/wiki/FR:Groupe_d%27accompagnement vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Problème cadastre ?
Bonjour, De : Ralf Treinen est-ce seulement moi qui n'arrive plus à télécharger en josm les feuilles du cadastre ? Quand j'essaye un cadastre grab, josm affiche brièvement une grille superposée sur la fenêtre d'édition, qui disparaît après quelque sécondes. Il y a une couche josm pour la feuille cadastre de la commune mais elle est vide. Je viens d'essayer sur Paris et le cadastre s'affiche bien. À vérifier de ton côté : - est-ce que la projection est bien celle adaptée à ta commune ? - est-ce que tu es cadré (dans JOSM) sur la commune dont tu demandes les tuiles ? Au cas où, il faudrait que tu indiques de quelle commune il s'agit. vincent (et la santé, surtout :-) ) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Ombrage et relief...
Bonjour, De : Frédéric Rodrigo Salut, Moi je trouve que les routes ont l'air de flotter au dessus du fond de carte. Il faudrait peut être les ombrer aussi. D'accord avec ça. Je trouve le relief très arrondi, balloné. C'est pas un peu plus escarpé dans le coin ? Quoi qu'il en soit j'aime bien le principe. Et finalement sans ImageMagick :-) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu QA: ajout croisement FANTOIR et visu noname
De : Otourly Wiki De plus on peut aussi considérer le fait que si la rue est coupée par un rond point alors le rond-point s'il n'est pas nommé différemment porte de fait le nom de la rue principale ainsi coupée. Et lorsque les rues qui convergent en un rond-point sont de classification égale, donc toutes autant principales, on choisit quoi ? Casse-tête en perspective... La convention actuelle (pas de nom hérité d'un des axes entrants) a le mérite de la simplicité. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Metadonnées sur celles d'OSM et comment informer les autres contributeurs ?
Bonjour, De : Pieren Cette discussion revient régulièrement sur toutes les listes. La dernière en date, c'est un américain qui se plaignait de devoir supprimer à répétition une portion de route qui n'existe plus dans la réalité mais qui est systématiquement rajoutée par d'autres parce qu'elle est visible sur l'imagerie aérienne Bing. Comment dire aux autres cette portion de route n'existe plus ? Ici, ce genre de problème est plus fréquent avec les bâtiments qui sont encore dans le cadastre mais plus dans la réalité. La seule solution actuellement supportée par tous les outils : c'est mettre un way virtuel avec une note : cet objet n'existe plus depuis 1/1/2013, par exemple. Je pense que la seule solution qui marche est de rajouter ces informations, même générales, directement sur tous les objets concernés. Quitte à mettre source=attention, bâti décalé+cadastre DGFiP 2013 sur tous les building d'une commune. C'est brutal mais c'est le seul moyen d'avoir une chance d'être lu. Malheureusement, certains éditeurs ont tendance à les cacher sous le tapis. Par exemple, iD affiche bien les tags note mais pas les fixme. Ou JOSM qui considère qu'un élément avec uniquement un tag note est un élément sans tags et l'affiche comme tel à l'écran. Cette méthode a aussi l'avantage de s'adresser à ceux qui s'intéressent à ces éléments, parce qu'ils les ont examinés individuellement. Par contre, ajouter de gros polygones pour dire c'est le bazar dans toute cette zone ou cette zone est converte par une imagerie aérienne détaillée depuis xxx, c'est une très mauvaise idée parce que ça gêne les contributeurs qui s'en foutent et que ça ne correspond à rien sur le terrain. Mettrre ces polygones dans une base séparée ? Pourquoi pas. Mais on a déjà un outil qui s'appelle les notes et qui fait à peu près la même chose. Peut-être que la solution passerait par l'extension de cet outil sous forme de polygones alors qu'actuellement, on ne peut définir des notes que sur des points. L'idée de propager sur les objets de la base les notes en tous genres sur les sources pas à jour, décalées, etc, ne me dit rien de bien. Je penche vraiment pour une séparation entre les objets de la base OSM et ceux qui doivent porter les infos de qualification des sources. En disant séparation, ça peut néanmoins être un voisinage proche, comme les traces GPS sont proches des données à tel point qu'elles sont téléchargeables par un outil commun (JOSM), à une case à cocher près. Je ne vois pas de blocage de principe à stocker ces infos ailleurs. On a déjà plein d'exemples d'informations stockées en dehors de la base et qui pour autant interagissent avec elle. Par exemple : - pour des stats sur les tags, le reflex est pour (quasi ?) tout le monde d'aller sur taginfo.org. C'est suffisamment pertinent et consensuel pour que tout le monde converge vers le même service, pourtant externe. - pour les emprises d'imagerie dispo, JOSM interagit avec des metadonnées pour proposer, sur une emprise donnée, l'ajout de couches WMS. Là encore, on accède à des infos hors de la base mais qui savent interagir avec les outils. Je pense vraiment qu'on ne doit pas bloquer sur ce stockage externe. À mon avis, ça ne peut pas être la cause de l'échec d'un service. Les questions sont plutôt sur l'intégration de ce service avec les outils : comment renseigner simplement une information sur les sources ? Comment y accéder tout aussi simplement ? Je réitère l'idée de s'appuyer sur uMap pour s'entraîner à collecter ces métadonnées. Les fortunes du cadastre sont un bon motif (mais pas le seul) pour amorcer une visu, si quelqu'un se sent de commencer. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Metadonnées sur celles d'OSM et comment informer les autres contributeurs ?
De : Nicolas Dumoulin Le jeudi 12 décembre 2013 12:28:06 Stéphane Péneau a écrit : Ok, pourquoi pas uMap, mais comment on visualise ces données dans Josm ? De mon point de vue, si on a pas un accès direct à ces infos dans l'éditeur, on perd la majeure partie de l'intérêt de l'outil. Ce serait effectivement une fonctionnalité du tonnerre de pouvoir importer des données depuis umap sur un calque ! @Stéphane : l'intérêt à cours terme avec uMap, c'est que c'est un outil qui offre les fonctionnalités de saisie de points _et_ surfaces, la capacité de les décrire avec du texte, la capacité ensuite de partager ça via une URL. Je trouve que ça fait un bon début pour au moins collecter les infos sans passer par les Notes ni saisir directement dans la base. Le moyen terme, c'est comme dit par Nicolas, une capacité d'interaction entre les outils d'édition et les infos stockées, ici, dans le backend de uMap. On n'y en pas encore, on ne sait pas quelle forme ça prendra(it), mais pour réfléchir et argumenter, avoir de la vraie matière, sous forme justement des metadonnées de sources, ça me semble un bon début. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rencontre parisienne du 27 décembre
Bonjour, De : Nicolas Moyroud A Montpellier nous avons avancé notre rencontre du dernier mercredi du mois au 18 pour raison de (gavage) vacances de Noël. Mais bon c'est vrai que le 25 ça aurait été vraiment très mal placé... Trop conservateurs les Montpellierains! ;- Le 27/12 à Paris, ça permet à ceusses de passage dans la capitale pour cause de vacances de se joindre aux locaux. Faut voir le verre (de bière) à moitié plein ;-) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Tracé des limites communales terminé
Bonjour, Tout est dans le titre :-) Avec la Somme, terminée aujourd'hui, nous venons de boucler le tracé des limites de _toutes_ les communes françaises (à l'exception des 17 de Mayotte, non répertoriées sur le site du Cadastre pour l'instant). C'est un chantier de presque 6 ans qui s'achève, depuis Paris ( http://www.openstreetmap.org/relation/7444 ) le 15 mars 2008, jusque Contoire ( http://www.openstreetmap.org/relation/3359872 ), aujourd'hui : un nom qui sonne bien à l'idée de trinquer pour arroser ça. On n'en serait pas là, bien évidemment, sans l'autorisation donnée par la DGFiP pour que le Cadastre serve comme fond de plan pour OSM. On n'en serait pas là non plus sans les outils qui ont fleuri à la même époque : le plugin Cadastre-fr porté par Pieren, et qui aura servi jusqu'au bout, ainsi que les outils de vectorisation initiés par Frédéric. On n'en serait pas là, pour l'époque récente, sans Mapcraft, qui a donné le boost final pour accélérer le tracé des derniers 10%. Et, last but not least, rien de tout ça n'aurait été possible sans le temps consacré par 279 contributeurs, au fil des années, pour créér ces fameuses relations administratives. Vous les trouverez ici (les contributeurs, et les relations) : http://vimeo.com/user22882814/osmfrenchboundaries La suite ? Les sujets ne manquent pas : un peu de maintenance au fil des relations cassées, un peu d'harmonisation de tags, le complément des couches soeurs (arrondissements, cantons, EPCIs), un peu de contrôle qualité dans la foulée de ce que Christian a initié. Mais surtout, la couche des communes devient diffusable à l'échelle France, ce qui en fait un bon prétexte à discussion avec de potentiels utilisateurs. Bref, bravo à (nous) tous, et à suivre ;-) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales terminé
De : Nicolas Moyroud Super nouvelle ! Délai du 12 décembre plus que largement tenu en plus :-) En plus de mapcraft, merci aussi à toi Vincent pour la coordination de ce travail depuis plusieurs mois. Elle est géniale ta vidéo. Tu as utilisé quel outil pour faire l'animation des contributions ? Merci pour le merci :-). Ça a été un plaisir partagé, le fameux Mapcraft ayant montré toute sa pertinence pour notre besoin. J'ai vu depuis qu'il avait pas mal servi aussi pour le chantier Mairies du NPC, peut-être qu'on pourrait étendre l'idée aux autres régions ? Pour l'animation, c'est un mélange de : - php pour récupérer les infos sur la v1 de chaque relation (en connaissant à l'avance le n° de chacune suite à un import France) - SQL pour mélanger ça, via le code INSEE, aux contours du GeoFLA - Mapnik pour faire une carte par jour à partir de ces données et un logiciel pas libre du tout pour assembler le tout (Windows Movie Maker). Je peux mettre à dispo les différents bouts de scripts, ainsi que les fichiers XML des versions 1 des relations, si certains veulent s'en servir. C'est une matière à stats assez riche :). vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales terminé
De : Pieren La vidéo ne distingue pas les communes vectorisées et celles en raster. Les contributeurs qui ce sont tapés le raster méritent dix fois plus de félicitations ;-) Pour le distingo, il faudrait pouvoir connaître la date charnière entre raster et vecteur, pour chaque commune, du point de vue de la DGFiP. Si quelqu'un a l'info, ce serait simple à combiner. Mais trouver cette info, par contre... pas gagné je pense. Attention toutefois : j'ai encore corrigé la semaine dernière la vieille limite au sud de Paris qui se trompait en se collant sur une route alors que la limite du cadastre s'en éloignait pas mal. Je sais aussi que pas mal de limites ont été triturées pour faire raccord avec leurs voisines. Prochaine étape : harmoniser les tags (admin_centre, postcode, population) et les limites en coastline (si c'est pas déjà fait). Oui, les corrections sont permanentes, même si à un petit rythme. Les outils comme layers sont un gage pour être réactifs... mais en ce moment ça toussote un peu. Pour l'harmonisation, ça mériterait une discussion ici (pas forcément fleuve). vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales terminé
De : Pieren 2013/12/4 Christian Quest : J'en compte 36660 (sauf erreur) avec un tag ref:INSEE et admin_level=8 Donc 21 de moins que le COG... Dans ce document du COG, il y a 36682 communes listées (au 1er janvier 2013): http://www.insee.fr/fr/methodes/nomenclatures/cog/telechargement/2013/txt/comsimp2013.zip Mais dedans, il y a Mayotte qui compte 17 communes (qui ne sont pas dans OSM d'après ce que j'ai compris). Sans Mayotte, on tombe à 36665. Il en manque 5 ! Pas forcément... Si on prend par exemple Le Dévoluy, commune créée au 01/01/2013 par la fusion de 4 communes : la commune est introuvable via le moteur de recherche du COG : http://insee.fr/fr/methodes/nomenclatures/zonages/default.asp Côté OSM on a Le Dévoluy, et pas de trace des 4 communes sous forme de relation administrative avec admin_level=8. Donc on ne compte pas la même chose que le COG, notre référence n'est pas le 01/01/2013 mais plutôt le 04/12/2013... Ceci dit ça pose une vraie question pour qui voudrait coupler nos données avec un référentiel externe, type INSEE. On peut se réjouir d'être à jour, mais dans le même temps ça nous met en déphasage avec d'autres référentiels. Argh. Et de mon côté j'en trouve 36649, allez comprendre. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Re: utilisation carte prefecture de police
Bonjour, Message du 02/12/13 09:25 De : didier2...@free.fr j'ai envoyé un email pour l'attribution, chufiché maintenant ;) Je vois aussi qu'ils ont attribué Montigny-les-Cormeilles à la Seine-Saint-Denis, en plein Val d'Oise. Ah là là ;-) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Découverte de OSM avec un groupe d'élève en classe de première
De : Philippe Verdy Je ne le ferais pas : le prof n'a pas à savoir ensuite ce que font les élèves hors du cours s'il contribuent ensuite sur des intérêts personnels (imaginons qu'un élève cartographie des établissements LGBT-friendly, ou des assos et partis politiques, ou les lieux de ses vacances ou ses amis, ou les établissements médicaux où il se rend), cette part de vie privée ne le regarde pas et le meilleur moyen c'est de couper les ponts. Argument qui s'entendrait si les contributions n'étaient pas publiques. Tu sembles oublier que les modifications de tous sont consultables par tous, que ce soit par les pages de www.osm.org ou par la quantité d'outils qui permettent d'analyser une zone : les WhoDidIt, ITO co. Bref, la contribution secrète est un leurre, avec l'API actuelle. Donc les élèves devront utiliser leur compte perso par la suite, si ça les intéresse. En plus si les élèves continuent avec le compte créé pour le cours, le prof ou son école garderait une responsabilité s'ils font n'importe quoi avec et on devrait sanctionner l'école pour manque de contrôle ou vigilance et je ne pense pas que le prof doive se charger de ça après, on ne le contactera donc plus au sujet de ces usages futurs. on devrait sanctionner l'école : qui a le pouvoir de sanctionner ? Si tu penses à autre chose qu'un blocage de compte ça mériterait que tu donnes plus de détails. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Serveur OSM en lecture seule ce soir (maintenance)
Bonjour Désolé si c'est un doublon, mais il ne me semble pas avoir vu passer l'info ici. Il n'y aura pas d'édition possible dans la base ce soir de 18:30 à 23:00 (17:30 à 22:00 GMT) pour cause de maintenance système. Message d'annonce ici : https://lists.openstreetmap.org/pipermail/talk/2013-November/068631.html vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Serveur OSM en lecture seule ce soir (maintenance)
De : Pieren 2013/11/27 Nicolas Moyroud : Ah la vache ! Ça tombe pile poil au moment de notre réunion du groupe local montpelliérain et j'avais prévu de proposer une séance de saisie. Pas cool. Si j'avais su avant on aurait pu décaler notre réunion, mais là c'est un peu tard... Bon du coup il va falloir s'occuper autrement. :-\ Si vous voulez, je peux vous envoyer une liste de pages wiki à mettre à jour ou à traduire ;-) Et si ça vous suffit pas y'a encore quelques planches cadastrales picardes à caler :- ) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu QA
Bonjour, De : Dominique Rousseau Le Sun, Nov 24, 2013 at 12:17:32PM +0100, Christian Quest [cqu...@openstreetmap.fr] a écrit: La pastille est entourée de vert lorsque le cadastre vectoriel de la commune est disponible. Du coup, je constate (mais y'aurai eu d'autres moyens ;) que la grosse partie qui manquait de cadastre vectorisé dans la Somme semble est disponible ! Pas tout à fait, il reste pas mal de communes non vectorisées autour de Peronne et Roye : http://tile.openstreetmap.fr/?zoom=10lat=49.76389lon=2.77629layers=B000TF Globalement, le département est coupé en 2 : 398 communes vectorisées, 384 toujours en raster. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales normandes terminé
De : Christian Quest Le 21 novembre 2013 01:16, Vincent Pottier a écrit : Petit exemple : Le nœud : http://www.openstreetmap.org/browse/node/365172724 est indiqué comme ayant un écart de 56m http://tile.openstreetmap.fr/?zoom=18lat=47.22638lon=5.95226layers=B000FFFTF Les cadastres des trois communes sont cohérents à moins d'un mètre sur ce point. Et OSM les suit. C'est donc IGN qui est fautif, il me semble. Non l'IGN n'est pas fautif dans ce cas. Il faut bien se rappeler ce qu'on compare. Côté IGN, on utilise ici une base pour laquelle les spécifications indiquent [1] : l'exactitude planimétrique, mesurée pour un échantillon minimal de 100 points situés entre deux nœuds, répartis de façon aléatoire, est chiffrée par une erreur moyenne quadratique inférieure [2] à 200 mètres. Donc déduire des écarts entre des points OSM et les mêmes points dans Route500 que l'un a bon et l'autre faux, c'est comme comparer un landuse brut Corine et le même dessiné au mètre près via une ortho précise. On a un tel écart dans la précision géométrique attendue de part et d'autre que la comparaison n'a pas de valeur. Chacun est juste tant qu'on l'utilise à des échelles adaptées à son cahier des charges. L'échelle de Route500, c'est le 1/250.000, autant dire rien de comparable avec une planche du cadastre ou une imagerie bing. Donc la mesure des écarts entre OSM et Route500 est à prendre comme... une oeuvre d'art :-). Je le répète, sans accès à la BD Topo, on ne produira pas de comparaison honnête. Et surtout, évitons le piège de conclure que nous somme meilleurs avec ce type de comparaison (vers Route500 ou GeoFLA). C'est vraiment donner des verges pour se faire battre. vincent [1] : http://professionnels.ign.fr/sites/default/files/DC_ROUTE500_1-1.pdf [2] : http://georezo.net/wiki/main/dico/eqm ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Tracé des limites communales normandes terminé
Bonjour, Voilà donc 2 départements, et 2 régions de plus à notre compteur, avec la fin à l'instant du tracé des limites de l'Eure et de l'Orne. Merci à la brochette de 12 contributeurs qui sont passé donner un coup de main. Ce chantier nous a fait passer la barre des 99% de communes tracées, eh oui...:-) Avant la dernière ligne droite, on entamme le dernier virage, avec 2 des 3 départements incomplets : la Saône-et-Loire et l'Yonne, presque voisines, et qui comptent, en tout, 145 limites manquantes. Ça se passe par ici : http://mapcraft.nanodesu.ru/pie/330# et c'est, comme toujours, ouvert à tous. Et si on garde le rythme... tout ça sera terminé en 2013. À nous de jouer ! Merci à vous, vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales normandes terminé
Le mardi 19 novembre 2013 12:34:51 Christian Quest a écrit : Je vais vous mettre un coup de pression en plus... si ça pouvait être terminé avant le 12 décembre, ça pourrait faire du bruit... Sur le principe c'est faisable... mais sera d'autant plus faisable que l'on sera nombreux à s'y coller. (Ceci est un appel :-) ) Et comme dit, ça permettra de marquer la fin symbolique du chantier de création, mais il restera du chemin ensuite pour les verifs en tous genres : géométrie (topologie, points triples), harmonisation d'un set de tags garanti par commune, etc. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag pour Maison des Associations de Solidarité ?
Bonjour, De : Nicolas Dumoulin Le jeudi 14 novembre 2013 13:20:40 Pieren a écrit : Suite à cette 'note': http://www.openstreetmap.org/?note=73172 je me demandais comment on taggue une Maison des Associations de Solidarité qui met à disposition 8 salles toutes en lumière du jour, dont 6 salles de sous commission et un espace événementiel entièrement équipé pour que chacune de vos manifestations soit une totale réussite.: http://www.mas-paris.fr/ J'utilise amenity=community_centre pour les centres d'animation mais je ne crois pas que ça s'applique aussi à ce genre de structure. C'est ce tag que j'utilise pour l'instant pour les salles de fêtes et autres bâtiments municipaux à destinations des associations/particuliers. Sans focaliser sur le nom, j'ai l'impression qu'on a ici avant tout un espace de locations de salles de réunions. Dans ce cas, je le rapprocherais plutôt de la petite vingtaine de amenity=convention_centre [1] qu'on trouve dans la base. vincent [1] : http://taginfo.openstreetmap.org/tags/amenity=convention_centre 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 https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rapport Trojette et réaction de l'IGN
Bonjour, De : Pieren 2013/11/7 Christian Quest : on n'a quasiment pas d'adresse pour trouver les points de départ et d'arrivée ! On doit déjà être la plus grande base adresses libre pour la France. Et puis, sans adresse au numéro près, on peut déjà faire beaucoup avec les noms de rues. Pour les grandes avenues, c'est plus délicat maiss c'est essentiellement dans les grandes villes et ces grandes villes seront les premières à toutes disposer de leurs adresses dans OSM (c'est là où il y a le plus de contributeurs). Je ne vois donc pas de problème à exploiter les données OSM pour du routage bien avant que toutes les adresses soient présentes (mais il faudra exiger d'avantage sur l'homogénéité des voies et de leur nommmage). Avant de focaliser sur les n° d'adresse, il faudrait déjà pouvoir quantifier notre couverture en noms de voies. Concrètement, en prenant comme référence la liste des voies diffusée dans les fichiers FANTOIR [1], d'un côté, et en comptant combien de couples distincts nom de voie + code insee on a dans OSM on devrait pouvoir sortir une stat éclairante, qui réponde à la question : quelle proportion des voies connues du FANTOIR sont aussi connues d'OSM ? Je n'ai franchement aucune idée du chiffre en sortie : 50%, 80%, 99% ? (Faute de base France sous le coude je ne peux pas procéder au calcul de mon côté pour l'instant) Je pense que ce chiffre, s'il est bon, pourrait rapidement nous servir dans nos communications vers l'extérieur. Et s'il est mauvais, eh bien... il nous donnera l'ampleur du challenge à venir. vincent [1] : https://lists.openstreetmap.org/pipermail/talk-fr/2013-July/061011.html et http://www.collectivites-locales.gouv.fr/mise-a-disposition-fichier-fantoir-des-voies-et- lieux-dits 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 https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Changement de nom de communes
De : Christophe Merlet Le 07/11/2013 10:58, Frédéric Rodrigo a écrit : Ça se saurait si c'était le cas. Il reste encore du travail pour les les fournis : http://layers.openstreetmap.fr/? zoom=6lat=46.4lon=2.3508layers=BT Ha zut. Je croyais avoir lu que c'était fini :/ Promis Christophe quand ce sera le cas tu en entendras parler :-)) Et faut pas hésiter à venir donner un 'tit coup de truelle, plus on est de fous...: http://mapcraft.nanodesu.ru/pie/320 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 https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Changement de nom de communes
De : Steve Grosbois D'ailleurs sur ce layer, 3 communes du 49 n'apparaissent pas en vert alors que les limites sont bien renseignées : http://www.openstreetmap.org/browse/relation/295506 http://www.openstreetmap.org/browse/relation/295984 http://www.openstreetmap.org/browse/relation/295983 Oui, même symptôme dans les Ardennes : http://layers.openstreetmap.fr/?zoom=13lat=49.60432lon=5.0157layers=BT On voit sur le fond 2u que les limites sont interrompues, ce qui n'est pas le cas sur le rendu 'default@OSM'. Je ne sais pas s'il y a un lien avec la panne des minute diffs : https://lists.openstreetmap.org/pipermail/talk-fr/2013-November/064000.html ? 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 https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Intégration des places GIC/GIG de Paris
De : Fionn Halleman 2/ les attributs : === -wheelchair=designated pour caractériser la place (plutôt que wheelchair=yes, car ce n'est pas validé par un passage terrain que la place est effectivement praticable). A noter que cette valeur du tag n'a pas d'icône, c'est dommage. -capacity:disabled=* pour le nombre de places -ref:arrêté=* pour le numéro de l'arrêté classant la place en GIC-GIG -source=préfecture de police de Paris - opendata nov 2013 -note= ce qu'il y avait dans le fichier d'origine. En général des indications sur la position de l'emplacement Juste 2 remarques * sur le ref:arrêté : il faudrait éviter les accents côté tag. Donc plutôt ref:arrete. Mais tant qu'on y est, et faute d'identifiant unique pour chaque ligne du tableau source, pourquoi ne pas se contenter du tag ref ? = ref=Arrêté 2009-00947 * sur le tag source : est-ce que tu modules selon la source avec : source=Ville de Paris - opendata 11/2013 dans certains cas ? 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 https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites communales en SHP ?
Bonjour, De : Thomas Williamson Je cherche à récupérer les limites communales du département de la Vienne (86) au format SHAPE mais je ne trouve rien sur le net... Si quelqu'un a une solution, je suis preneur ! Tu as ça ici : http://export.openstreetmap.fr/contours-administratifs/communes/ évoqué notamment sur cette page : http://openstreetmap.fr/outils (qui mériterait plus de visibilité, peut-être) 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 https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Faire une carte de communes à partir d'OSM
Bonjour, De : Adrien Caillot On 25/10/2013 10:24, Adrien Caillot wrote: J'aurais besoin de faire une carte d'une communauté d'agglo (carte toute bête : il me faut les limites de toutes les communes avec leurs noms au milieu). Je dispose d'un fichier .osm qui contient toutes les données OSM de cette agglo (j'ai tracé un rectangle autour d'elle dans JOSM et j'ai tout enregistré). Mais comment faire pour extraire juste les limites de communes ? Je n'ai pas pensé à préciser une chose importante : je cherche à obtenir une carte toute simple, certes, mais vectorielle, pour l'utiliser dans un logiciel comme QGIS. Ce n'est pas simplement une image bitmap dont j'ai besoin. Tu devrais pouvoir trouver ton bonheur ici : http://export.openstreetmap.fr/contours-administratifs/communes/ C'est du format Shapefile, donc QGIS s'y retrouvera. 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 https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Faire une carte de communes à partir d'OSM
De : Francescu GAROBY Dans le lien que tu donnes, on retrouve le même bug que j'avais signalé il y a quelques jours : certains départements (1, 2, 5) ont des noms de départements grecs. Oui j'ai vu. Mais je n'ai pas la main dessus pour corriger. Ce bug mis à part, la ressource me paraît correspondre au besoin, puisque la conversion du format OSM XML vers du SIG est déjà faite dans les fichiers proposés. 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 https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Faire une carte de communes à partir d'OSM
De : Adrien Caillot Il me reste un seul problème : La carte que j'ai obtenue a cette forme : https://www.dropbox.com/s/jqt1n31yes6vmjj/gdijon-qgis.jpeg Et je voudrais plutôt cette forme : http://commons.wikimedia.org/wiki/File:Carte_de_la_Communaut%C3%A9_d%27Agglom%C3%A9ration _dijonnaise_%28Grand_Dijon%29.svg Il y a donc un problème de projection. Je suis en WGS 84 et je pense que la projection que je recherche est Lambert 2 étendue (?). Mais j'ai tenté de la changer un peu partout (propriétés du projet, du shapefile...) et rien ne change. Savez-vous comment on fait ça dans QGIS ? C'est bien dans les propriétés du projet, mais il faut cocher (dans Préférences Propriétés du projet) la case 'Activer la projection à la volée'. Je te parle de QGis 1.8, en 2.0 je ne sais pas. 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 https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Joli bug sur suivi communes
Bonjour, De : Francescu GAROBY Bonjour, En regardant si de nouvelles communes vectorisées étaient à importer, je viens de remarquer un joli bug : la première ligne (département de l'Ain) a un nom et un id qui correspond à... (je vous laisse découvrir). Il semblerait donc qu'il y ait un problème dans le script qui génère ce fichier, car la relation pointée a certains des tags correspondant à nos départements (type=boundary, boundary=administrative, admin_level=6). J'en déduis donc que le filtre n'est pas suffisamment précis pour ne prendre que des départements français Dans les tags communs, il y a ref=01 qui alimente bien sûr la confusion. Pour filtrer sur la France, un critère supplémentaire pourrait être : la relation départementale contient un node avec 2 propriétés : - un rôle admin_centre et - un tag ref:INSEE Ça ou autre chose tant qu'on peut éviter un is_in='France' :-) 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 https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Vidéo des limites communales (était : Tracé des limites communales d'Aquitaine terminé)
De : Ab_fab Les extraits full history doivent pouvoir permettre de représenter l'évolution des *ways* boundary = administrative Mais les relations ne sont pas gérées par la base de données, donc difficile de montrer l'évolution des surfaces concernées par ce moyen. Le dernier extrait disponible de la France est en date du 5 février 2013, ainsi que d'autres plus petits. [1] http://osm.personalwerk.de/full-history-extracts/history_2013-02-05_1701/europe/ Ca permettrait, à défaut des surfaces, de montrer les limites elles-mêmes. Pourquoi pas ? Une autre approche, complémentaire, serait de prendre la géométrie du GeoFLA*, de récupérer pour chaque commune son n° de relation OSM, et par là la date de la v1 de la relation. On pourrait ensuite animer un affichage France des communes, dans leur ordre d'apparition dans la base. vincent * un comble, oui je sais :-), mais ici c'est moins la géométrie détaillée qui importe, que la chronologie... 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 https://lists.openstreetmap.org/listinfo/talk-fr
