[OSM-talk-fr] SOTM à Brest : inscriptions et covoiturage
Bonjour, Comme vous le savez, notre State Of The Map se déroule dans maintenant 3 semaines, du 29 au 31 mai, à Brest. Le programme est en cours d'élaboration, des détails dans la semaine à venir. Il est encore temps de proposer des interventions, toujours à s...@openstreetmap.fr . Pour que chacun puisse organiser son déplacement, la page https://framacalc.org/Covoiturage%20SOTM-FR-2015 propose de mettre en relation ceux qui viendront en voiture, et leurs possibles passagers. Point important, n'hésitez pas à confirmer votre venue en vous inscrivant, dès que possible, par ici : https://www.eventbrite.fr/e/billets-state-of-the-map-france-2015-brest-16641745910 ce qui aidera l'organisation à se mettre en place. Merci de faire circuler ces infos, notamment du côté des listes locales... ...et à bientôt à Brest ! vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Caméra embarquée avec position et direction
Bonjour, De: Jean-Claude Repetto jrepe...@free.fr Le 24/04/2015 11:58, Eric Sibert a écrit : Garmin vient de sortir une caméra embarquée avec GPS mais aussi accéléromètres et gyroscopes pour enregistrer la direction de prise de vue: https://buy.garmin.com/fr-FR/FR/en-action/cameras/virb-x/prod164723.html Ça pourrait être bien pratique pour les relevés de terrain. Il faudra encore les outils adaptés en aval genre plugin pour josm. Les outils sont déjà là : si tu utilises le mode rafale, qui prend des photos plutôt qu'une vidéo, les images sont normalement directement comprises dans JOSM. La vidéo dans JOSM, il me semble que c'est toujours pas au point, et quand bien même, la définition des images ne serait pas aussi bonne qu'avec des clichés. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Caméra embarquée avec position et direction
De: Nicolas Moyroud nmoyr...@free.fr On sent là une certaine expérience de la chose ! ;-) Héhé ^^ Après on parle là de méthodes efficaces mais gourmandes en stockage, et génératrices de beaucoup de bruit : pour un cliché utile, combien qui ne disent rien ? C'est une balance à trouver, selon sa vitesse de déplacement et ce qu'on cherche à capturer. C'est parfait pour les PEI ;) Se pose aussi la question (qu'on n'aborde jamais trop ici) de la discrétion du procédé, et des réactions qu'il peut provoquer des passants, promeneurs et riverains. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import d'hydrants sur le département du Tarn
De: Marc SIBERT m...@sibert.fr Je veux bien participer à cette opération de qualification. Les beaux jours reviennent et c'est une belle occasion de faire du vélo dans ma nouvelle ville de Sainte Geneviève des Bois. Bien d'accord sur la méthode :) Dans le cas des PEI, c'est très adapté si on cherche les poteaux incendie. Pour les bouches, comme à Paris intra muros, c'est plus une activité de piéton. @Yann : tu soulèves _le_ problème, à savoir la capacité à faire, tant les ressources et le temps manquent. Dès que tu as un peu de matière à contrôler, on peut s'organiser une journée de terrain, en mode brigade cycliste sur le 91. La saison est propice, yapluka. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import d'hydrants sur le département du Tarn
Bonjour, Le 21/04/2015 19:19, Yann Kacenelen a écrit : Salut à tous, (...) Merci pour votre lecture. N'hésitez pas à me contacter pour la qualif des données PEI du 91 ;) Est-ce que tu vois envisageable de présenter ta méthode de révision des implantations de PEI à tes collègues du Tarn ? Mon petit inventaire pouvant illustrer le sujet à leur niveau : http://umap.openstreetmap.fr/fr/map/points-eau-incendie-osm-vs-opendata-dans-le-tarn_36908#12/43.7101/2.1863 (j'ai enlevé hydrants du titre :) ) Reste après le sujet bien réel de la capacité à faire, vu le nombre de points à balayer. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import d'hydrants sur le département du Tarn
De: David Crochet david.croc...@free.fr Le 20/04/2015 12:21, Nicolas Moyroud a écrit : Des avis ? +1 aussi pour la correction participative générale. De mon côté, c'est sans hésiter +1 pour _l'intégration_ participative, donc la solution Osmose. Si on est face à un jeu de données qui nécessite qu'on colle à l'import un tag fixme sur chaque objet, alors il y a un souci, non ? vincent ps. d'accord avec JB dont je vois la réponse entre temps. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import d'hydrants sur le département du Tarn
Bonjour, De: Nicolas Moyroud nmoyr...@free.fr Pour moi les bornes sont avant tout un patrimoine des services de l'eau / syndicats des eaux / Veolia... Donc les numéros visibles sur le terrain font partie d'un référentiel de ces services. Ainsi, ref=* ne devrait présenter que le numéro visible sur le terrain, pour éviter toute ambiguïté. Pour la vingtaine de cas que j'ai contrôlé sur les photos terrains le numéro des données était celui indiqué sur la borne. C'est vrai qu'il n'y a pas moyen d'être sûr pour tout le département. Attendons de voir avec les photos de Vincent. Mais après rien n'empêche de ne faire l'import que sur le tag ref:FR:SDIS et de faire la copie au cas par cas sur le tag ref. Je n'ai pas ressorti mes photos, mais je suis sûr que quasi aucune ne permet de lire un n° (j'avais pas ça dans mon cahier des charges à l'époque :) ). Cependant j'ai regardé ceux que je connais, et sur les 185 j'en sors quand même 70 où il y a à redire sur la localisation. J'ai mis ici http://umap.openstreetmap.fr/fr/map/hydrants-osm-vs-opendata-dans-le-tarn_36908 ces PEI et ceux issus du jeu OpenData, dans un rayon de 200m autour de chacun. On a du mauvais côté de rue : http://umap.openstreetmap.fr/fr/map/hydrants-osm-vs-opendata-dans-le-tarn_36908#19/43.70154/2.13673 http://umap.openstreetmap.fr/fr/map/hydrants-osm-vs-opendata-dans-le-tarn_36908#18/43.65471/2.17015 http://umap.openstreetmap.fr/fr/map/hydrants-osm-vs-opendata-dans-le-tarn_36908#20/43.61048/2.23977 http://umap.openstreetmap.fr/fr/map/hydrants-osm-vs-opendata-dans-le-tarn_36908#19/43.62271/2.27107 de la distance : http://umap.openstreetmap.fr/fr/map/hydrants-osm-vs-opendata-dans-le-tarn_36908#18/43.62408/2.23123 http://umap.openstreetmap.fr/fr/map/hydrants-osm-vs-opendata-dans-le-tarn_36908#17/43.66684/2.29395 http://umap.openstreetmap.fr/fr/map/hydrants-osm-vs-opendata-dans-le-tarn_36908#18/43.76471/2.11509 du positionnement relatif par rapport à un bâtiment : http://umap.openstreetmap.fr/fr/map/hydrants-osm-vs-opendata-dans-le-tarn_36908#19/43.60479/2.23887 http://umap.openstreetmap.fr/fr/map/hydrants-osm-vs-opendata-dans-le-tarn_36908#18/43.63255/2.22646 http://umap.openstreetmap.fr/fr/map/hydrants-osm-vs-opendata-dans-le-tarn_36908#18/43.63245/2.26997 etc. On a à côté de ça une bonne masse de positionnements très convergents. Cet inventaire rappelle juste que le processus de collecte est en partie basé, j'imagine, sur de la mémoire visuelle plus que sur de la photo (géolocalisée ou pas). Dans la majorité des cas, ça n'empêche pas un usage opérationnel par les pompiers, en revanche pour de l'import dans OSM ça reste mitigé, si on considère que ça rentre dans la catégorie micro-mapping. Pour plus de facilité, il peut être tenté de créer un référentiel parallèle à celui de l'opérateur de la borne, en ajoutant au numéro visible sur le terrain le code INSEE de la commune Ceci serait fait dans le Morbihan ou le Finistère. Donc une borne incendie peut avoir deux références distinctes et celle du jeu de données du Tarn semble devoir aller dans un ref:FR:SDIS. On pourrait même envisager trois références distinctes : celle du SDIS, celle du service des eaux et celle du terrain. Dans le cas de Nîmes les ref du service des eaux et du SDIS ne semblent pas être les mêmes. Stocker la référence vue sur place dans ref (sans lui ajouter de code INSEE s'il ne figure pas sur le PEI), et l'identifiant fourni par la source SDIS dans un ref:FR:SDIS me va bien aussi. On accumule les infos, ce qui permet par la suite de tester leur (possible) cohérence. Et si on obtient un identifiant de la part du gestionnaire de réseau d'eau, on pourra lui attribuer sa propre clé aussi, le moment venu. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import d'hydrants sur le département du Tarn
Bonjour, Le 19/04/2015 16:24, François Lacombe a écrit : +1 aussi pour indiquer les ref du SDIS dans une clé séparée pour conserver ce qui est visible sur le terrain. Suivant ce que la communauté en pense, est-ce réellement utile d'indiquer le département du SDIS dans la ref ? Vu que les territoire de SDIS ne se recouvrent pas, ref:FR:SDIS pourrait être suffisant (même si chaque SDIS n'utilise pas le même formalisme). On retrouve le département dans la source=SDIS81 indiquée à juste titre. Je suis d'accord avec ça : la source pour indiquer le SDIS de provenance, et un tag ref (ref:SDIS, voire... tout simplement ref ?) avec la référence. Le 19 avril 2015 15:23, Nicolas Moyroud nmoyr...@free.fr mailto:nmoyr...@free.fr a écrit : En fouillant un peu sur data.gouv, je suis tombé sur ça : https://www.data.gouv.fr/fr/datasets/hydrants-du-tarn/ A priori ça semble être le seul SDIS qui a mis à disposition ces données sous licence ouverte. Dans les jeux de données il y a 5497 poteaux incendies (emergency=fire_hydrant + fire_hydrant:type=pillar) et 193 bouches souterraines (emergency=fire_hydrant + fire_hydrant:type=underground). D'après overpassAPI sur ce département il y a actuellement un total de 210 fire_hydrant (poteaux + bouches). En comptant à l'instant, je plaide coupable pour 185 de ces hydrants. Ce qui veut dire que j'ai des photos pour chaque. Si tu n'est pas à la minute, je veux bien regarder ce que ça donne sur ceux-là, essentiellemnt sur Castres, et un peu en montant vers Albi. Les données sont essentiellement collectées sur le terrain par les sapeurs-pompiers du département lors des contrôles annuels et lors de leurs déplacements ou missions qu'ils sont amenés à effectuer sur le terrain. Les services des eaux contribuent aussi pour une large part à l'enrichissement de cette base départementale. La mise à jour de la base se fait à partir de relevés gps fournis par les acteurs de terrain ou de *saisies basées sur l'orthophotoplan de l'IGN*. Sans aller jusqu'à une précision géométrique absolue, il faut au moins s'assurer du positionnement relatif : bon côté de voie, bon embranchement à un carrefour. Vous en pensez quoi ? Au delà de l'aspect juridique est-ce que vous pensez que c'est une bonne idée de réaliser cet import ? Ça donnerait un boost à nos stats : on n'attend pas encore 25000 hydrants sur la France, on a une grosse marge de progression. Et on a tout à gagner à un circuit vertueux avec nos amis des SDIS, sur les hydrants mais pas que. Pour les infos complémentaires je pense extraire les valeurs de pression et diamètre pour renseigner les tags fire_hydrant:diameter et fire_hydrant:pressure (http://wiki.openstreetmap.org/wiki/Tag:emergency%3Dfire_hydrant). Une lecture sur le sujet, avec une proposition de correspondance des tags : https://lists.openstreetmap.org/pipermail/talk-fr/2015-February/075118.html vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [BANO] problème sur une adresse
Bonjour, Le 17/04/2015 18:02, Patrick Proy a écrit : J'ai une rue hermitage avec une seule adresse en plein milieu d'une rue ermitage : http://layers.openstreetmap.fr/?zoom=18lat=43.44025lon=5.69009layers=0B000TT Du coup, la rue hermitage apparait en rouge sur BANO. Il s'agit vraisemblablement d'une erreur, mais est-ce que j'ajoute ref:fr:FANTOIR:id hermitage en tag sur la rue ermitage ? est-ce que celà ne va pas empêcher le rapprochement avec nom ? Note : le cadastre indique seulement ermitage Si tu ajoute l'un des 2 codes Fantoir, tu vas figer le rapprochement, indépendamment des divergences d'orthographe, mais ça ne changera rien au fait que côté cadastre, une partie des adresses ne pourra être rapprochée, vu que le cadastre n'est pas homogène. Donc le rouge restera. Tu peux plutôt indiquer l'erreur en allant ici : http://cadastre.openstreetmap.fr/fantoir/#insee=13110 et en mentionnant pour la rue non rapprochée (celle avec un h): voie doublon avec orthographe différente, ce qui désormais est reflété dans le rendu BANO avec une couleur ad'hoc. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Fixmaville
Bonjour, De: Bruno pa...@free.fr Le 16/04/2015 10:07, Vincent Bergeot a écrit : sur le site fixmaville, lorsque l'on va sur la carte pour signaler ou suggérer http://www.fixmaville.fr/signaler_fmv/ il me semble bien voir une carte osm mais pas d'attributions. Connaissiez vous ce site ? Oui c'est bien des données OSM avec un rendu que je ne connaissais pas et qui est intéressant, mais pas d' attribution visible même en parcourant les différentes pages du site. Le service est proposé par dataforpeople.fr et on retrouve OSM ici : http://www.dataforpeople.fr/blog/biz/ne-pas-utiliser-google-maps/ Signalé vers eux à l'instant : https://twitter.com/_vdct/status/588633340388868096 vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Article de 20 minutes - La France a enfin son fichier unique d'adresses postales
Bonsoir, Le 15/04/2015 23:37, George Kaplan a écrit : Je viens de voir la nouvelle dans les flux RSS du site de d'osm-fr. J'ai lu avec attention et des questions me viennent sur cette annonce : Je vois que sur http://bano.openstreetmap.fr/ , le dossier /data n'a pas été mis à jour aujourd'hui alors qu'un nouveau nommé /BAN_odbl a fait son apparition, contenant des données datées de ce jour. Est-ce que ça veut dire que le dossier /BAN_odbl est maintenant l'emplacement des fichiers BANO ? Non, c'est juste un concours de circonstances, cf. mon message de ce matin sur les outils de màj quotidiens de BANO (de minuit à ~05:00 chaque matin) qui sont momentanément en mode manuel (et à l'heure qu'il est ils tournent). Christian gère cette partie, et, disons, il a été comme occupé par le lancement de la BAN ces derniers temps ;) Est-ce que le terme BANO est maintenant obsolète et remplacé par BAN Odbl ? Non. BANO s'appuie massivement sur OSM comme source, la BAN ODbL pas du tout. La convergence des licences permet à partir de maintenant d'imaginer la construction d'une base sous ODbL tirant le meilleur parti des 2 bases. Christian a la main sur tes autres points. La page Contribuer ne mentionne pas la possibilité de corriger une erreur en ajoutant l'adresse dans OSM, est-ce que cette absence est volontaire ? Les outils de géocodage disponibles sur http://adresse.data.gouv.fr/ utilisent-ils la BAN ou son sous-ensemble Odbl ? Je voulais aussi consulter la licence gratuite de repartage mais son URL ( https://adresse.data.gouv.fr/static/BAN_Licence_de_repartage.pdf ) renvoie une erreur 404. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Problème cadastre.openstreetmap.fr
Bonjour, De: Nicolas Moyroud nmoyr...@free.fr Super merci Vincent, je vais pouvoir reprendre une activité ajout de bâtiments normale. ;-) Bien ;) Le 14/04/2015 22:34, Vincent de Château-Thierry a écrit : Un redémarrage plus tard, ça semble rentré dans l'ordre. Cependant, le redémarrage n'a pas tout redémarré : concrètement la mise à jour nocturne en automatique est désactivée, donc si vous voulez actualiser les données sur une commune, passez par http://cadastre.openstreetmap.fr/fantoir/ . vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rencontre parisienne d'avril le 24
Bonjour, Le 13/04/2015 19:32, Christian Quest a écrit : Possible si Jean peut nous mettre à disposition la salle de RDC de la Maison des Associations... Jean ? Merci à Jean qui entre temps nous a bloqué une salle à la MDA :) C'est au 23 rue Greneta, Paris 02 : http://www.openstreetmap.org/node/691721185 vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rencontre parisienne d'avril le 24
Le 14/04/2015 11:25, JB a écrit : Faudra vraiment que j'arrive à me caler un passage par Paris un week-end de rencontre… Ce sera pas avril… qui sait pour mai… Si je passe, en tous cas, présent pour Maperitive et R25 (et même avec tous les défauts du logiciel !). Pour la rencontre parisienne de mai, ça pourrait bien être... à Brest du vendredi 29 au dimanche 31 : SOTM-Fr. À ce propos l'organisation se précise et https://wiki.openstreetmap.org/wiki/FR:State_of_the_Map_France_2015 donne quelques éléments (dont une amorce de section co-voiturage). L'ouverture des inscriptions est imminente. Pour toute question ou proposition de contribution, une seule adresse : s...@openstreetmap.fr vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Problème cadastre.openstreetmap.fr
Le 14/04/2015 18:34, Christian Quest a écrit : Dès que j'ai terminé les préparatifs du lancement de la BAN (c'est demain à 18h), je regarde osm104... Le 14/04/2015 15:41, Olivier Patrice Griffet a écrit : *Bonjour Nicolas et à tous. * *C'est sûrement lié à ça : http://listes.openstreetmap.fr/wws/arc/tech/2015-04/msg00020.html Le 14 avril 2015 15:31, Nicolas Moyroud nmoyr...@free.fr mailto:nmoyr...@free.fr a écrit : Pas de réponse du côté du serveur cadastre.openstreetmap.fr http://cadastre.openstreetmap.fr Un redémarrage plus tard, ça semble rentré dans l'ordre. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Rencontre parisienne d'avril le 24
Bonsoir à tous, à vos tablettes, la prochaine rencontre parisienne sera exceptionnellement avancée au vendredi 24 avril. Le lieu reste à préciser, et sera annoncé ici. Sur le principe, prévoyez Paris centre à partir de 19:00. vincent ( Christian pas loin) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : suivi des rapprochements, par département
(2è tentative d'envoi de ce mail, désolé si ça fait doublon) -- Bonsoir, Le 10/04/2015 15:47, jean navarro a écrit : Bonjour j'ai un peu du souci avec les différents sites de suivi du projet bano. Plus pratiquement je ne comprends pas pourquoi ces deux pages ne donnent pas les mêmes valeurs pour la commune d'Ambérieu en bugey par exemple 1) http://cadastre.openstreetmap.fr/fantoir/stats_dept.html#dept=01 2) http://cadastre.openstreetmap.fr/fantoir/#insee=01004 Merci Jean d'avoir mis le doigt sur 2 points d'un coup La page de stats départementales comptait, pour la colonne Toutes voies rapprochées, toutes les valeurs différentes de codes Fantoir trouvées dans les données OSM d'une commune. Sauf que la valeur '' (Fantoir vide) était comptée comme les autres, ce qui ajoutait 1 au comptage dans chaque commune où au moins une voie n'a pas de rapprochement Fantoir. = le comptage ignore maintenant les voies sans code Fantoir. Pour ambérieu, on passe de 173 à 172 voies rapprochées. Il arrive par ailleurs que parmi les rapprochements, figurent des associations à des codes Fantoir de lieux-dits. Il y en a 1 sur Ambérieu*, mais qui n'apparaît nulle part dans http://cadastre.openstreetmap.fr/fantoir/#insee=01004, car : - il est pourvu d'adresses, et la colonne voies FANTOIR avec rapprochement OSM _avec adresses_ ne compte pas les lieux-dits. - la colonne voies FANTOIR avec rapprochement OSM _sans adresses_ ne liste que les Fantoir dépourvus d'adresses. Tout ça était volontaire à l'origine car je voulais consacrer des onglets supplémentaires au cas des rapprochements sur lieux-dits. Mais ça traîne Pour revenir au comptage, on a donc maintenant : - sur la page d'Ambérieu, 140+31 = 171 voies rapprochées - sur la page des stats, 172 voies rapprochées, dont 1 sur un lieu-dit. Donc 171 sur des voies, ça colle enfin. vincent *pas sûr d'ailleurs qu'il soit ok : il existe un code Fantoir propre pour le Chemin de la Combette... ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : suivi des rapprochements, par département
Bonsoir, Le 10/04/2015 15:47, jean navarro a écrit : Bonjour j'ai un peu du souci avec les différents sites de suivi du projet bano. Plus pratiquement je ne comprends pas pourquoi ces deux pages ne donnent pas les mêmes valeurs pour la commune d'Ambérieu en bugey par exemple 1) http://cadastre.openstreetmap.fr/fantoir/stats_dept.html#dept=01 2) http://cadastre.openstreetmap.fr/fantoir/#insee=01004 Merci Jean d'avoir mis le doigt sur 2 points d'un coup :) La page de stats départementales comptait, pour la colonne Toutes voies rapprochées, toutes les valeurs différentes de codes Fantoir trouvées dans les données OSM d'une commune. Sauf que la valeur '' (Fantoir vide) était comptée comme les autres, ce qui ajoutait 1 au comptage dans chaque commune où au moins une voie n'a pas de rapprochement Fantoir. = le comptage ignore maintenant les voies sans code Fantoir. Pour ambérieu, on passe de 173 à 172 voies rapprochées. Il arrive par ailleurs que parmi les rapprochements, figurent des associations à des codes Fantoir de lieux-dits. Il y en a 1 sur Ambérieu*, mais qui n'apparaît nulle part dans http://cadastre.openstreetmap.fr/fantoir/#insee=01004, car : - il est pourvu d'adresses, et la colonne voies FANTOIR avec rapprochement OSM _avec adresses_ ne compte pas les lieux-dits. - la colonne voies FANTOIR avec rapprochement OSM _sans adresses_ ne liste que les Fantoir dépourvus d'adresses. Tout ça était volontaire à l'origine car je voulais consacrer des onglets supplémentaires au cas des rapprochements sur lieux-dits. Mais ça traîne :( Pour revenir au comptage, on a donc maintenant : - sur la page d'Ambérieu, 140+31 = 171 voies rapprochées - sur la page des stats, 172 voies rapprochées, dont 1 sur un lieu-dit. Donc 171 sur des voies, ça colle enfin. vincent *pas sûr d'ailleurs qu'il soit ok : il existe un code Fantoir propre pour le Chemin de la Combette... ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : Ref Fantoir sur nom d'immeuble
Bonsoir, Le 08/04/2015 15:59, Christian Quest a écrit : Rajouter le ref:FR:FANTOIR sur l'objet concerné (ici un immeuble, mais ça peut être une résidence comprenant plusieurs immeuble) permet de géolocaliser ces objets. Exemple: cherchez Tour Tourmalet sur https://adresse.data.gouv.fr/map/ J'ai rajouté le ref:FR:FANTOIR sur le bâtiment et du coup BANO peut le localiser: http://www.openstreetmap.org/way/70474811 Le 08/04/2015 12:38, Stéphane Péneau a écrit : Le 08/04/2015 12:24, Pierre Knobel a écrit : Je trouve que la limitation actuelle aux objets de type highway=* + name=* pour les rapprochements OSM/FANTOIR est trop restrictive (peut-être centrée sur une problématique de calcul d'itinéraire ?). On pourrait imaginer rapprocher aussi les building=*, les leisure=park... etc S'il y a une lettre après le code Insee de la commune, c'est que ce code Fantoir ne s'applique pas à une voie. Le plus souvent il s'agit d'un hameau, mais on rencontre aussi le cas des lotissements, ou comme ici, d'une résidence ou d'un batiment. Dans notre contexte le FANTOIR est en premier lieu un inventaire de noms, qui nous permet de confronter notre propre stock de noms (de rues, de hameaux, de parkings, places, mais pourquoi pas aussi immeubles, parcs, etc.). La comparaison nous donne une vision de notre propre avancement, et les différents outils (le rendu carto, les listes de rapprochements) sont orientés dans ce sens. Donc oui, à l'échelle d'un immeuble, pouvoir l'identifier comme existant dans OSM, via son lien retrouvé dans FANTOIR, est intéressant, je pense. Maintenant, en l'état, retrouver un immeuble et le rapprocher signifie qu'on aura explicitement tagué un ref:FR:FANTOIR dessus, car les immeubles n'ont pas le privilège des highways=*, landuse=residential,amenity=parking, qui sont les seuls types d'objets où la présence du tag name suffit à les porter candidats au rapprochement. L'essentiel du code correspondant est là [1]. Je n'ai pas de souci à ouvrir cette liste à d'autres couples clé-valeur, tant qu'on ne se sert pas dans les shop=* ou bien les highway=bus_stop : un arrêt de bus portera facilement le nom d'une rue, mais ce qui nous intéresse via Fantoir, c'est de vérifier qu'on a bien la rue dans OSM, et pas juste un arrêt de bus homonyme. = Vos suggestions de clés-valeurs manifestement manquantes sont les bienvenues. Mais on a aussi la situation inverse, où OSM est fournisseur de géométrie pour le FANTOIR. C'est explicite dès qu'un tag ref:FR:FANTOIR est utilisé, et implicite quand, sans ce tag, on parvient à procéder aux rapprochements. OSM est aussi potentiel fournisseur de retours-qualité, par la qualification voie par voie des écarts constatés, sur les types de voies, les divergences d'orthographe, etc. On a donc les ingrédients d'un lien double, où FANTOIR et OSM sont chacun fournisseur de l'autre, et ça peut avoir quelques vertus. Donc pour répondre à Simon, il n'y a évidemment aucune obligation à tagguer les immeubles avec un Fantoir, mais si tu as de l'énergie (et du temps !) pour, je suis serein sur le fait que ça aura un usage. Et en tout cas, ne pas le faire ne doit pas amener à qualifier ces codes FANTOIR en erreurs. vincent [1] : https://github.com/osm-fr/bano/blob/master/sql/highway_insee.sql ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Adresse et hameau
Le 08/04/2015 18:32, Julien Noblet a écrit : Bonjour, Je suis en train de renseigner quelques n° de maisons sur des hameaux. J'aime beaucoup l'utilisation de relations type associatedStreet que je préfère à l'utilisation de addr:street. A votre avis, comment faire pour un hameau/résidence/autre... ? * Un nouveau type associatedPlace ? * Me cantonner à addr:place ? A-ton des nouvelles pour une intégration dans la BANO? Tu fais bien de réveiller le sujet. Côté BANO ça n'a pas encore dépassé le stade de l'intégration des lieux-dits du Cadastre, et uniquement à des fins d'affichage sur les tuiles carto. Il faut évidemment aller plus loin, mais je vais être franc, une des raisons du peu d'activité depuis septembre pour les intégrer, c'est que je n'ai pas pris le temps de comprendre les différents modèles d'adressage qui ont déjà été discutés ici. Sans parler de consensus, s'il existe des ressources (wiki ou fil ici-même) qui permettent de dresser le paysage, ou si certains veulent bien (à nouveau) dire comment ils procèdent, d'avance merci. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : suivi des rapprochements, par département
Bonsoir, Le 06/04/2015 13:31, didier2020 a écrit : (((c-a)^2)/c) + (((b-c)^2)/c) + (((d-b)^2)/d) stp vincent, merci de corriger ... :$ Voilà, c'est cette formule là qui est visible désormais. vincent ps. ça manque de racines carrées et de logarithme, non ? ;) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : suivi des rapprochements, par département
Le 05/04/2015 19:49, didier2020 a écrit : ((a/c)*(c-a)) + ((b/c)*(c-b)) + ((b/d)* (d-b)) qui qualifie mieux la notion déficitaire que le simple ecart relatif (plus le chiffre est gros, plus y a de boulot) Ajouté (je te laisse voir le nom de la colonne ;) ). Garder à l'esprit que le comptage qui inclut les lieux-dits donne parfois des chiffres artificiellement gonflés, tant il peut y avoir un décalage entre les lieux-dits vécus, pratiqués, constatés, et ceux inventoriés sur le cadastre. Toute tambouille qui s'appuie sur ce chiffre héritera du biais. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : suivi des rapprochements, par département
Bonjour, Le 05/04/2015 09:53, rainerU a écrit : Merci, c'est très utile ce tableau. Serait-il possible de différencier les communes vectoriels et raster ? Merci pour la suggestion, je viens de l'ajouter en 1ère colonne : http://cadastre.openstreetmap.fr/fantoir/stats_dept.html#dept=66 vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] code FANTOIR avec nom de rue et de résidence
Bonsoir, Le 04/04/2015 18:10, Jérôme Seigneuret a écrit : ARFFF Je mettrai ça en erreur Fantoir car normalement c'est la rue qui doit faire foi et là tu as la rue plus autre type d'info Erreur la plus cohérente: Voie incorporée à une autre. Ton problème est un peu chiant car les trois Fantoir déservent le même nom de rue qui n'exista pas tous seul... (Sauf pour certaines dont tu as Rue + Résidence Pour la rue de la Fosse aux Loups, on a 4 Fantoir : 1 par résidence + 1 pour la rue seule. N'en jetez plus. Les codes semblent bien s'appliquer aux voies et pas aux résidences, dixit la doc Fantoir [1]. On peut imaginer affecter chacun des 3 codes des résidences à 3 portions de la voie Rue de la Fosse au Loups qui partent de là : https://www.openstreetmap.org/node/3436827988 mais ça laisse sur le carreau le Fantoir de la voie seule. Pour lui je n'ai aucune idée, sachant qu'en plus aucune parcelle du cadastre n'est rattachée à cette voie : le 027890079Z est dans les voies sans adresses. En regardant la rue Hirson, c'est un peu différent : http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#18/49.8374866646/3.91359296038 On a encore une voie par résidence et une voie pour la rue seule, mais il semble plus simple d'affecter un Fantoir à chacune, même si elles portent toutes le même nom Rue d'Hirson dans OSM. Le Fantoir de la rue seule irait sur https://www.openstreetmap.org/way/336628661, et les autres sur les voies de service devant chaque immeuble. Dans tous les cas, avoir plusieurs codes Fantoir avec le même nom de voie OSM va laisser, pour l'instant, du rouge sur le calque Bano, car la gestion de Fantoirs multiples pour un seul nom n'est pas encore branchée. Du coup je rajoute ces exemples dans le ticket : https://github.com/osm-fr/bano/issues/71 vincent [1] : http://www.collectivites-locales.gouv.fr/files/files/gestion_locale_dgfip/national/FANTOIR_Descriptif.pdf ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] BANO : suivi des rapprochements, par département
Bonsoir, Dans la série des outils autour de BANO, je vous propose une nouvelle page, qui donne pour un département quelques chiffres commune par commune : - le nombre de voies avec adresses, rapprochées - le nombre de voies rapprochées (qu'elles aient des adresses ou pas) - le nombre de voies recensées au FANTOIR, hors lieux-dits - le nombre de voies _et_ lieux-dits recensés au FANTOIR et des calculs de pourcentages combinant ces 4 effectifs. La prise en compte des lieux-dits permet de s'adapter au cas où des rapprochements de voies OSM sont faits sur des FANTOIRs de lieux-dits. Ça sera pertinent dans certaines communes seulement. L'outil est ici : http://cadastre.openstreetmap.fr/fantoir/stats_dept.html Ces tableaux généralisent un outil qui a émergé pour accompagner le travail en cours sur l'Isère [1]. L'idée était de voir, à l'échelle d'un département, où se situaient les communes les plus déficitaires dans OSM en voies nommées, donc celles sur lesquelles on pourrait mettre la priorité en terme de contribution. Questions retours bienvenus, vincent [1] : https://lists.openstreetmap.org/pipermail/talk-fr/2015-March/075627.html ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] code FANTOIR avec nom de rue et de résidence
Le 04/04/2015 22:13, didier2020 a écrit : ok merci pour la réponse . question en + : les highway=service ne sont pas rapprochés ? Tous les objets linéaires ou surfaciques avec les tags highway et name sont automatiquement candidats au rapprochement. Si tu constates que ça ne rapproche pas, y'a un souci... le dire :) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de schéma de tags pour améliorer la cartographie des arbres
Chalut, Le 01/04/2015 00:02, Frédéric Rodrigo a écrit : On commence donc par décrire le tronc, longueur, direction et l'inclinaison : - tree:trunk:length=* (en m par défaut, mais d'autres unités restent bien sûr possible, c'est important) Puis les branches ou la suite du tronc : - tree:trunk:trunk:length=* Et pour chaque branche : - tree:trunk:branch[X]:length=* On va enfin pouvoir décrire les soles pleureu(ses|rs) :D Mais il manque les racines, dans ton schéma. Je propose des indices négatifs, à l'image des layers : root[-2]:root[-1]:tree:trunk:... Comme ça on peut creuser. Voire trouver de l'eau. L'avantage de cette façon de faire est de pouvoir rester concis, un seul nœud suffit, pas besoin de cartographier les branches avec des ways. Certains vont penser que ce n'est que pour le rendu, mais on peut faire bien plus de choses avec, par exemple du calcul d'itinéraires ou d’ensoleillement par ombre porté sur le feuillage en fonction de l'espèce de l'arbre. Pour le calcul d'itinéraire, cette approche permet enfin de parcourir les arêtes. Il était temps, je vote pour. J'espère que des moteurs 3D comme F4 pourront rapidement prendre en compte cette approche, le résultat sera quand même beaucoup plus réaliste. Je suis ouvert à vos remarques avant de faire une proposition en bon et due forme sur le wiki puis sur la liste tagging. Sur le wiki ? Aqua bon. Note, il faudra maintenant aller mapper avec des boussoles, des niveaux et des compas ; mais nos chers smartphones font déjà tout ça ! Frédéric. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pause des mises à jour BANO
Bonjour, Le 30/03/2015 21:14, Jérôme Amagat a écrit : C'est reparti? Oui, les mises à jour OSM sontà jour : http://munin.openstreetmap.fr/osm12.free.org/osm105.openstreetmap.fr/osm_replication_lag_osm2pgsql.html et BANO a été mis à jour dans la journée. Et le tms du cadastre ne fonctionne plus. c'est normal? C'était lié aux changeents récents sur les serveurs. Fred vient de faire le nécessaire pour que ça refonctionne. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] attribution homengo.com
Bonjour, De: dHuy Pierre dh...@yahoo.fr Un lien vers une page l'utilisant? Le Jeudi 26 mars 2015 8h52, Ab_fab gamma@gmail.com a écrit : Non, c'est bien un rendu basé sur OSM Le 25 mars 2015 23:32, dHuy Pierre dh...@yahoo.fr a écrit : En même temps, ils utilisent googlemaps... (à première vue, je n'ai pas visité tout le site) Le Mercredi 25 mars 2015 22h32, djo_man djo_...@laposte.net a écrit : Homengo n'ont à priori pas d'attribution sur la carte... Pour voir la carte : https://homengo.com/s/vente/porte-saint-martin_district-32359/? Les tuiles sont servies par Mapbox, comme celle-ci : https://b.tiles.mapbox.com/v3/homengo.map-k5p53d21/11/1037/704.png Il n'y a rien sur la carte en effet, il y a une page de sources qui n'a sûrement pas la même visibilité : https://homengo.com/immobilier/sources/ vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Pause des mises à jour BANO
Bonjour, Les mises à jour BANO des deux dernières nuits n'ont pas eu lieu, mais pour une bonne raison : la base monde qui nous sert de référence est en cours de ré-import sur un SSD flambant neuf issu de la campagne de dons de fin 2014, et que Christian a pu installer en début de semaine. Le suivi du ré-import se fait ici : http://munin.openstreetmap.fr/osm12.free.org/osm105.openstreetmap.fr/postgres_size_ALL.html Les effets sur BANO : le rendu de tuiles reflète les données OSM de lundi dernier, idem du côté des comparaisons FANTOIR, pour lesquelles la mise à jour par commune ne fonctionne pas. Reprise des opérations d'ici fin de semaine si tout se déroule bien. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rencontre à Paris vendredi 27 mars
Salut revenant :) De: Florian LAINEZ winner...@free.fr Hello Paris, Le rdv du dernier vendredi du mois tient toujours tous les mois ? J'ai rien vu passer pour ce vendredi, je me demande si c'est prévu. Dans ce cas vous vous retrouvez où d'habitude ? ++ PS [Spoiler] : je suis de retour sur Paris et content de retrouver tous les parigos ! Depuis le mois dernier on a décalé au dernier _jeudi_. Pas de lieu fixé pour cette fois-ci, mais ça va se préciser dans la journée. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
Le 23/03/2015 21:27, Vincent Frison a écrit : Mon programme ne rajoute pas ou ne découpe de bâtiment, il rajoute juste des tags sur des bâtiments déjà existants dans OSM. Si un bâtiment a plusieurs étages il y aura à coup sûr plusieurs bâtiments dans la base d'OpenDataParis (ODP) car effectivement cette dernière possède un découpage extrêmement précis des bâtiments (plus de 300 000 volumes bâtis !!), bien plus que le découpage des bâtiments d'OSM. Imaginons un bâtiment de 8 étages collé à un autre de 5 étages. Si il y a déjà un découpage en 2 bâtiments dans OSM, ça va coller nickel. Sinon ça sera une simplification : si OSM n'a qu'a seul bâtiment pour représenter ces 2 immeubles alors il faudra choisir, 5 ou 8 étages. Mais comme je regarde les surfaces et ça sera le bâtiment d'ODP qui aura la surface la plus proche du bâtiment d'OSM qui sera pris en compte. C'est donc une simplification et dans l'idéal il faudrait découper le bâtiment d'OSM en 2 bâtiments mais c'est pas ce que fait mon programme. N'hésitez pas à regarder le résultat sur la zone de test entre Bastille et Nation pour vérifier des cas concrets. En enregistrant le résultat de tes programmes, non en base OSM, mais dans des fichiers au format .osm, mis ensuite à disposition, tu rendrais possible plusieurs aspects : - le contrôle a priori, chacun ayant le loisir d'inspecter un fichier _avant_ que ses modifs ne soient en base - la répartition du travail : on peut imaginer un lotissement par pâté de maisons, feuille cadastrale, ou autre segmentation, ce qui ouvre la possibilité d'un travail coordonné comme ça existe déjà sur d'autres sujets - la mise en évidence de divergences entre les bâtis attendus et ceux trouvés dans OSM, comme dans ton exemple ci-dessus. Rien n'oblige à appliquer des tags en cherchant un critère d'affectation à tout prix. Devant une ambiguïté, on peut imaginer un signalement directement dans les fichiers mis à disposition, sous forme de tag fixme par exemple. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rencontre à Paris jeudi 26 mars
Le 23/03/2015 12:02, althio a écrit : Si vous voulez encore une louche d'Open pour le jeudi 26 : N'en jetez plus :) Pour la rencontre parisienne de jeudi, ce sera finalement chez Papa, 153 rue Montmartre : http://www.openstreetmap.org/node/2695378308 Rdv à partir de 19:00, les premiers arrivés prennent une table au 1er étage... À jeudi, vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Erreurs Osmose Fantoir place=
Bonsoir, Le 10/03/2015 18:11, Cavok a écrit : J'ai bien peur que l'erreur pourrait venir d'Osmose qui pour les Fantoirs de B à W n'accepte que locality, hamlet or isolated_dwelling. Pensez vous qu'Osmose soit trop restrictif dans ces choix, ou en effet le tag place=neighbourhood n'est toujours pas adapté. Je pense qu'Osmose devrait tolérer d'autres valeurs en effet, y compris des valeurs de highway, car il arrive aussi que ce qui est présenté par Fantoir comme un nom de lieu-dit, se retrouve sur le terrain comme nom de voie. La prise en compte au pied de la lettre des classifications Fantoir est trop restrictive. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Codes Fantoir erronés
Bonjour, De: Vincent de Château-Thierry osm.v...@free.fr J'ai placé sur cette page : http://cadastre.openstreetmap.fr/fantoir/fantoir_errone.html un listing des codes Fantoir connus seulement d'OSM, car absents du fichier Fantoir. Il s'agit donc d'anomalies, souvent dûes à des fautes de frappe lors de la saisie en base. Vous reconnaîtrez sur la page les liens présents sur http://cadastre.openstreetmap.fr/fantoir/ afin de permettre l'édition des objets concernés, l'objectif étant de réduire à 0 le nombre de lignes de cette page. Merci à Ano59 qui a donné ce week-end un grand coup de balai dans les ~70 erreurs qui restaient listées sur cette page. À noter que depuis la mise à jour BANO d'hier matin, nous utilisons un millésime 2015 du FANTOIR. Si vous avez souvenir de voies créées en cours d'année dernière il peut être intéressant de voir si elles sont maintenant rapprochées. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : 2 questions
Bonjour, Le 08/03/2015 18:08, Pierre-Yves Berrard a écrit : * Le nombre de voies manquantes sur le rendu diffère du nombre sur la page cadastre.opentstreetmap.fr http://cadastre.opentstreetmap.fr, car le premier intègre les lieux-dits. Ne pourrait-on pas assurer une cohérence ? Oui il faudrait ! Le rendu et la page de récap par commune ont émergé chacune de leur côté. Il faudrait harmoniser en effet (poke Christian :) ) * Sur la page de récap communale, pourquoi les Données OSM en date ne s'actualisent pas quand on force la mise à jour ? C'est identifié... mais pas encore traité : https://github.com/osm-fr/bano/issues/75 vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment tagger une place composite ?
Le 04/03/2015 20:49, Stéphane Péneau a écrit : Les landuses sont des area, donc pas besoin d'ajouter ce tag. Pour ma part, landuse=plaza name= ref:FR:FANTOIR= et c'était ok pour Bano. Normalement, pas besoin de highway. En effet, la présence d'un tag highway _ou_ d'un tag ref:FR:FANTOIR suffit (avec un tag name bien sûr) et ce, que ce soit sur un point, une ligne ou un polygone. Il y a quelques rares exceptions en cas d'absence de tag highway, ce sont, pour des surfaces, la présence d'un tag landuse=residential, ou celle d'amenity=parking. Pas de souci pour allonger la liste, au cas par cas. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Adresses non trouvées par BANO
Salut Nicolas, De: Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net Je viens de trouver des adresses qui ne sont pas trouvées par BANO, mais qui sont visible sur le cadastre. Il s'agit de la Rue du Grand Champ à Beaumont : http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#18/45.75255/3.08527 Une piste d'amélioration :-) Côté http://cadastre.openstreetmap.fr/fantoir/#insee=63032 la rue est bien rapprochée, mais dans la catégorie sans adresses. Côté cadastre il n'y a qu'une seule parcelle affectée à cette rue, et elle n'a pas de numero d'adresse, donc ça colle. Le n°8 affiché en plein milieu est le numero de parcelle (feuille BT01, parcelle n°8). Donc sauf à saisir des adresses dans OSM, affectées à cette rue, je ne vois pas grand chose à faire ? vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Quai Gallieni ou Quai du Général Gallieni ?
Bonjour, De: Pieren pier...@gmail.com 2015-03-02 10:39 GMT+01:00 Jean-Marc Liotier j...@liotier.org: Ou sinon, si vous pouvez m'éclairer sur la manière de répondre à ce problème... Perso, je pense que les tags alt_name ou short_name ne devraient être utilisés que si on trouve des versions alternatives ou courtes sur le terrain (panneau) ou dans la documentation officielle. Pour les raccourcis de langage (comme rue de Gaulle), il faudrait plutôt chercher à améliorer les logiciels de recherche de nom au lieu d'envisager de tagguer toutes les façon possibles et imaginables de citer le nom d'une rue. D'accord avec ça. Pour illustrer en reprenant le titre du fil, il existe à Boulogne (92) une rue Gallieni [1] qui traverse la ville d'est en ouest, et il ne me viendrait pas à l'idée de surcharger ses tags avec des noms alternatifs, avec Général, Maréchal ou que sais-je. Ici, c'est une rue Gallieni tout court sur le terrain [2]. Chaque commune est autonome pour dénommer ses voies, donc l'idée de forme canonique d'un nom de rue est à prendre avec des pincettes (voire à oublier). Qu'un moteur de recherche organise des correspondances, libre à lui, mais de son côté, pas dans la donnée, où à mon sens on ne doit pas aller plus loin que le support d'un nom officiel (type Fantoir / Cadastre) et d'un nom d'usage (si le terrain diffère). vincent [1] : http://www.openstreetmap.org/relation/2841858 [2] : https://goo.gl/maps/J6ytJ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Coexistence du tag ref:FR:commune et ref:FR:FANTOIR [était CR rencontre DMI de Grenoble]
De: Pieren pier...@gmail.com 2015-02-26 21:31 GMT+01:00 DH dhel...@free.fr: N'est-ce pas là le fond du problème ? Faire un référentiel géographique mutualisé multi-domaines (on balaie large de l'occupation du sol, aux services publics en passant par l'adresse sans oublier les PEI et les limites en tous genres) sans tenir compte des nécessaires connexions avec les réutilisateurs/producteurs. Ces primary key sont nécessaires tant qu'une solution plus durable (uuid géographisée déjà évoquée sur cette liste) n'émerge et fasse consensus. Pour revenir au code ref:FR:commune sur les voies, limité à Orange et son interco pour l'instant, personne ne répond à une de mes questions : si on laisse se propager plusieurs codes uniques pour chaque voie, qui pourra dire stop à la prolifération de ces refs externes ? Et pourquoi vouloir dire stop ? Je te trouve bien pessimiste. Si ces refs sont le témoignage d'un besoin, et d'une réutilisation d'OSM dans un système géré au jour le jour, ça préfigure plutôt d'une maintenance qui, indirectement, a toutes les chances de profiter au contenu OSM en retour. Une voie accidentellement supprimée dans OSM, c'est une alerte potentiel dans le SIG du consommateur, et en retour une correction apportée dans OSM pour remette d'aplomb le référentiel. Ceux qui sont abonnés à la liste import savent à quel point le principe même de ref externe pour le croisement de données est mal accepté, voir refusé au moment des imports. Même le code fantoir doit encore justifier de sa légitimité à l'extérieur de la France. À l'inverse, envisager que le contenu OSM est autonome et peut se passer de clés et autres mécanismes pour interagir avec un contenu externe, c'est largement prétentieux en l'état de la base (je ne dis pas ça pour toi mais ceux qui tiennent ce discours). Et c'est oublier que l'intérêt premier d'OSM est d'être utilisé... Au moment de sa création, on nous a expliqué en long et en large que le cadastre n'étant pas suffisament fiable avec les dénominations, le code FANTOIR servirait à croiser les données OSM avec le cadastre avec succès dans tous les cas. Pour moi le code FANTOIR, et la problématique des rapprochements qui suscite beaucoup de questions et de contributions, est avant tout un outil pour mesurer l'avancement de notre couverture en voies nommées _dans OSM_, au niveau France. C'était ma première motivation pour faire http://cadastre.openstreetmap.fr/fantoir/ : permettre d'y voir clair surle reste à faire, par commune. Mais si maintenant, chacun vient avec son propre code interne, c'est plus difficile à admettre, surtout lorsqu'on sait que l'utilisateur a aussi le code fantoir en local, donc que le croisement automatique reste possible moyennant un petit effort au départ dans la mise en place des outils. Tony a expliqué le souci il me semble : le FANTOIR est long à émerger, localement, et le besoin d'un ID unique pour chaque voie arrive bien avant la publication d'un code FANTOIR. Donc non, l'utilisateur n'a pas _immédiatement_ le code fantoir en local. Ça simplifierait voire annulerait cette discussion, sinon. Denis, tu dis que le fantoir ne vient qu'en deuxième rang. Mais du point de vue d'OSM, il n'y a pas de rang ni de priorité dans les consommateurs de nos données. Il peut y avoir des producteurs de code ref mais nous n'avons pas à connaitre leur hiérarchie, ni leur priorité. A la limite, moi, je n'ai rien contre la généralisation des codes ref:FR:commune mais alors on supprime les codes FANTOIR. Ça rejoint le point ci-dessus sur le nombre de ref distinctes. Je préfère poser la question autrement : si des consommateurs de données veulent s'appuyer sur FANTOIR, et que d'autres préfèrent un ref:FR:commune, pourquoi trancher ? Ce cumul de 2 ref, peut-être demain de 5 ou 10, serait plutôt pour moi un excellent signe : celui que des acteurs qui n'ont rien à voir entre eux, ont tous besoin de consommer nos données, et vont donc avoir un intérêt (une motivation) pour surveiller et maintenir ces données. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modélisation des points d'eau incendie - Projet d'import des données du SDIS de l'Essonne
De: Jérôme Seigneuret jseigneuret-...@yahoo.fr - la géométrie Attention en cas de points proches (test à faire sur un tampon sachant que les bornes d’incendie sont au maximum à une distante de x mètres) donc traitement différencier suivant le type de colonne. Ne pas supprimer le point mais le mettre à jour et ne pas supprimer la source initiale) La proximité géométrique ne peut pas être un critère. Tu trouves en urbain des hydrants littéralement côte à côte, à quelques cm l'un de l'autre [1], et à l'inverse tu peux longer une route sur plusieurs km sans croiser aucun hydrant, faute par exemple de bâtiment ou d'installation motivant une implantation. En cas de modification il faut soit valider soit annuler. C'est le principe de modération suite à modification (mais en externe à OSM). Cela peut être géré par les opérateurs qui fournissent de l'information via des requêtes d'import et de comparaison de version de référentiel. Permet aussi les ajouts externe renseignés par d'autres contributeurs. PS: pour rappel il n'y a pas réellement de système de modération dans OSM sauf vérifier que ses propres ajouts n'ont pas fait l'objet d'une révision par un autre contributeur. C'est le cas des points de géodésie qui ne doivent pas être modifié mais qui pourraient l'être par mégarde. Il y a un batch de restauration il me semble. Une différence de taille avec les repères géodésiques, c'est le caractère référentiel de leur position géographique. Par définition, les repères ne peuvent bouger. Côté hydrants, s'agissant de relevés terrain par les contributeurs, ou de relevés via les SDIS, le positionnement n'a rien de parfait. Ça ne me semble ni réaliste (vu le caractère imparfait des sources) ni souhaitable sur le principe, de brancher sur ce contenu des bots de surveillance afin de reverter toute modification. En tous cas OsmHydrant est pratique pour détecter les zones ou les colonnes sont pas encore renseignées. Pour l'instant, la détection est assez facile :) http://taginfo.openstreetmap.fr/tags/emergency=fire_hydrant dit qu'en France on a 21000 PEI. Un lien donné récemment par François rappelle qu'un hydrant doit avoir un rayon d'action de 200m. L'INSEE [2] estime à 12 km2 la superficie urbaine en France. Mélangez tout ça et vous obtenez un besoin théorique d'hydrants d'environ 95 PEI. On ne serait donc pour l'instant qu'à 2% de couverture... y'a de la marge. vincent [1] : http://www.osmhydrant.org/en/#zoom=18lat=48.846715lon=2.316513 [2] : http://www.insee.fr/fr/themes/document.asp?reg_id=0ref_id=ip1364%C2 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Serveur proxy de tuiles du cadastre avec mode joker
Bonjour, De: Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net En fait, je vais expliciter un peu ma question :-) : 1. L'emprise contient-elle les ROM ? Tu as les mêmes communes que celles accessibles sur http://www.cadastre.gouv.fr/ donc ici celles de Guyane, Guadeloupe, Martinique et Réunion, mais pas Mayotte. 2. Est-ce que la précision de la limite de l'emprise à une importance ? 2.1 Cela évite-t-il d'envoyer des requêtes sur des zones non couvertes ? Est- ce une charge supplémentaire tolérable pour ce gentil WMS et son gentil proxy TMS de renvoyer un peu de blanc sur les bords ? 2.3 Doit-on (peut-on) exclure les communes non vectorisées ? Je pense qu'on peux faire une emprise par excès, géométriquement simplifiée, sans coller aux limites de communes. En essayant à l'instant le WMS sur une commune raster, il y a bien un appel au service, mais pas de réponse ni plantage, donc c'est transparent à tous les sens du terme. Ça évite de plus de se lancer dans une maintenance au fil de l'apparition des communes vectorisées. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modélisation des points d'eau incendie - Projet d'import des données du SDIS de l'Essonne
De: MASSIOT Dominique dominique.mass...@sdis29.fr De mon point de vue, le fait de ne pas partager les informations de débit/pression empêcherait des exploitations éventuelles de la données. Le simple positionnement des points d'eau incendie me paraît assez limité en potentiel de ré-exploitation ultérieure. Alors que la mise à disposition des données de débit/pression ouvrirait des potentialités d'exploitation : C'est un point positif en effet, car il vise à faciliter la réutilisation, sachant que le nombre d'attributs en question est limité à quelques uns. J'insiste sur ce point pour différencier de, par exemple, la publication des résultats du recensement par sexe et tranche d'âge, commune par commune. On passe là dans un volume d'informations ingérable à notre niveau, donc qui nécessite de ne publier dans OSM qu'une clé (le code INSEE par exemple) et de diffuser ailleurs les données détaillées. Retour aux hydrants : je serais néanmoins partisan, en complément, comme l'a suggéré Pierre, d'une publication régulière en lecture seule sur un portail comme data.gouv.fr afin de permettre des vérifications et croisements, voire l'identification de différentiels qui permettraient des mises à jour dans OSM, par ajout des nouveaux PEI par ex. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment tagger une place composite ?
De: Pieren pier...@gmail.com Aujourd'hui, je pencherais plutôt pour un nouveau tag, du genre highway=plaza ou place=plaza (avec un ou deux 'z' au choix), à mettre sur un polygone fermé ou un multipolygon. Ca reflète mieux le caractère mixte des usages. Et surtout, on reste dans une logique de highway ou de place=* pour nommer un lieu, ce qui est beaucoup plus cohérent qu'un landuse pour les toponymes/odonymes déjà présents dans OSM. Je tique sur le tag place, dont l'usage est quand même dans une écrasante majorité associé à un point. Mais aucun souci de mon point de vue à remplacer landuse par highway au niveau du tag, on reste dans la thématique voirie. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] FME, OpenStreetMap et Veremap
De: Tony Emery tony.em...@yahoo.fr L'idée est de récupérer les données OSM via un batch de requêtes et l'importer les données dans une base de données PostGIS via le logiciel FME. Quelqu'un a-t-il déjà tester d'importer des données OpenStreetMap avec FME pour alimenter une base de données PostGIS ? Pas moi, mais si tu veux mettre à jour ta base PostGIS au fil des mises à jour OSM, il existe une chaîne logicielle taillée pour, à base d'osm2pgsql et d'osmosis. C'est (partiellement) expliqué ici : https://switch2osm.org/fr/servir-des-tuiles/construire-un-serveur-de-tuiles-depuis-des-paquets/ Le temps gagné à ne pas réinventer la roue sera en partie consommé à choisir dans le schéma des 3 tables points/lignes/polygones importées par osm2pgsql quels objets et quels attributs viendront alimenter tes tables métier. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rapprochement auto FANTOIR pour les lotissements
Le 25/02/2015 23:19, Jérôme Seigneuret a écrit :
Bonjour,
Je voudrais savoir s'il est possible de rapprocher les lotissements avec
une méthode automatique.
Je parle d'avoir une validation ici :
http://cadastre.openstreetmap.fr/fantoir/#insee=
landuse=residential + name=Lotissement * {type=way}
La combinaison landuse=residential + name est reconnue depuis quelques
jours, cf.https://github.com/osm-fr/bano/issues/86
Ça a été très peu testé, du coup si tu as des cas qui ne marchent pas,
ça m'intéresse.
place=neighbourhood+ name=Lotissement * {type=node,way,relation}
leisure=park+name=*
De même pour les différentes regroupement parcellaires :
- Clos *
- Cité *
- Cours *
- Centre horticole * et autre Centre
- Domaine *
- Esplanade *
- Espace *
- HLM * (sur le bati si une seule barre ? ou relation ou noeud)
- Parc *
- Place *
- Plan *
- Square *
- Résidence * (sur le bati si une seule barre ? ou relation ou noeud)
- ZAC *
- ZI *
...
Je pense que ce rapprochement s'apparente à celui des lieudit.
Les candidats au rapprochement ne sont pas sélectionnés en fonction du
contenu du tag name. Il faudrait plutôt exprimer les souhaits sous forme
de clés-valeurs, comme pour leisure=park.
D'une manière générale, tickets appréciés ici :
https://github.com/osm-fr/bano/issues/new
vincent
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment tagger une place composite ?
Bonjour, De: Pieren pier...@gmail.com 2015-02-25 7:33 GMT+01:00 Stéphane Péneau stephane.pen...@wanadoo.fr: Je confirme qu'en attendant de trouver mieux j'utilise landuse=plaza On peut en conclure que ce tag est une impasse ^^ Ou en conclure que ce tag est bien utile tant que rien de plus convaincant n'est proposé. vincent (mode verre à moitié plein) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rencontre parisienne ce jeudi
Le 24/02/2015 22:04, Jean-Baptiste Holcroft a écrit : je serai là également ! À l'intérieur de ce batiment il y aura une salle particulière ? Non, on sera dans la salle de réunion du rez-de-chaussée. Et grignotage dans le quartier ensuite, bien sûr ;) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : Orléans et environs en rouge
Bonjour, De: djoman djo_...@laposte.net Mais ce matin BANO est toujours rouge. Retard ou autre chose ? Ça peut être du côté de ton cache, car je ne vois rien d'anormal pour Orléans ici : http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#12/47.9017/1.9072 ni là : http://cadastre.openstreetmap.fr/fantoir/#insee=45234 Pour info les tuiles du rendu BANO sont invalidées / regénérées chaque nuit au moment de la mise à jour quotidienne de la base. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : Orléans et environs en rouge
De: Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net Ben, pas moi. J'entends les deux points de vue (+ le 3 ème que j'ai expérimenté mais que je n'essaierai pas plus de défendre), et aucun des deux n'est satisfaisant (sans parler de parfait). Oui, rien d'idéal, je suis d'accord. Pour reprendre ton exemple de rues séparées en deux (sans parler des voies), je trouve les deux propositions bancales. Là, je préfère tracer une nouvelle polyligne sur le terre-plein centrale pour la limite, c'est parfait :-). Je parlais d'une rue dont les propriétés changent sur la longueur. Pour une rue à plusieurs chaussées, d'accord avec ce que tu décris, et dont parlais aussi Philippe : il y a un tracé en propre pour la limite, à mi-largeur de l'ensemble. Même chose lorsque une limite croise un rond-point. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Rencontre parisienne ce jeudi
La fin du mois approche, Si vous êtes parisien(ne)s ce jeudi soir, vous êtes les bienvenus à partir de 19:00 à la Maison des Associations du IIè arrondissement, 23, rue Greneta. = http://www.openstreetmap.org/node/691721185 À jeudi, vincent ( Christian) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : Orléans et environs en rouge
Bonjour, De: Pierre-Yves Berrard pierre.yves.berr...@gmail.com Grosse tache rouge détectée à Orléans et communes limitrophes. http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#12/47.9171/1.9144 Je suspecte un problème sur les limites communales, qui empêche l'appariement sur l'ensemble du territoire des communes. Cohérent (façon de parler) avec ça : http://suivi.openstreetmap.fr/communes/suivi.txt Je viens de reprendre dans la même liste Enghien (95) mais pas le temps de voir le reste maintenant. Le chantier des nouveaux cantons s'est fait au sprint je crois ;) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : Reconnaissance des voies
Bonsoir, Le 20/02/2015 06:28, « Ano59 » a écrit : Le 20/02/2015 05:46, Philippe Verdy a écrit : Et on l'a vu, les name:left et name:right ne suffisent pas pour les noeuds d'adresse Je ne sais pas si on se comprend bien en fait. Ma demande / proposition, c'était que BANO reconnaisse les name:right et name:left sur un way avec un tag highway=* au même titre qu'il reconnaît les name tout court. Probablement une mauvaise compréhension de mes propos, donc. Car effectivement je vois pas l'intérêt d'ajouter name, name:left ou name:right sur un noeud d'adresse. Ou bien si c'était bien ce qui avait été compris, c'est moi qui ne percute pas. Pas de souci, c'était très clair. Philippe parle de name:left et name:right pour des points, ce qui d'un point de vue géométrique est fortiche. C'est quoi le côté droit ou gauche d'un point ??? Le point de côté, je connais. Le côté d'un point, non. Le 19/02/2015 23:04, Vincent de Château-Thierry a écrit : Pour t'économiser il y a l'outil de génération d'adresses : http://cadastre.openstreetmap.fr/?type=adresses Merci, je l'utilise déjà toutefois. ;-) C'est juste un peu lourd à dégainer quand d'ordinaire je passe en coup de vent sur une commune après l'autre en ajoutant des tags name=* à tout va. D'accord là-dessus, le service n'est pas réactif à la seconde, plutôt à la minute, donc pas adapté à de la contribution en passant. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : Reconnaissance des voies
Bonjour, Le 19/02/2015 00:39, « Ano59 » a écrit : Déjà première suggestion : serait-il possible que BANO reconnaisse les voies OSM portant un tag name:left ou name:right ? En mappant certaines rues entre deux villes, je me suis rendu compte que le cas arrivait souvent (la rue a deux noms différents selon la ville). Ces voies ne sont pas reconnues dans BANO : au mieux seule la portion avec un seule nom est reconnue, si elle existe. En effet pour l'instant ce cas n'est pas géré, mais une autre modélisation est prise en compte dans ces situations : l'existence d'une relation associatedStreet par côté de voie, avec comme tags de la relation, un name et un ref:FR:FANTOIR. Dans une moindre mesure, lié au cas précédent, j'ignore si BANO reconnaît correctement des références FANTOIR multiples sur une même rue, telles que ref:FR:FANTOIR=RefX;RefY. J'ai l'impression que non, je peux me tromper. Non, pas de valeurs multiples pour le tag Fantoir. Et comme c'est une modélisation controversée, autant l'éviter quand d'autres solutions existent, comme celle ci-dessus : une associatedStreet par Fantoir. Ensuite davantage une question : pourquoi parfois certaines voies dont on indique bien la référence FANTOIR ne sont toujours pas reconnues après MAJ ? Malheureusement je n'ai pas d'exemple sous la main, j'en fournirai si j'en retrouve. Il n'y a pas de cas général pour cs anomalies, le meux est de pouvoir les indiquer au moyen d'un lieu vers la carte ou vers un objet OSM. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : Reconnaissance des voies
Le 19/02/2015 22:39, « Ano59 » a écrit : En créant 2 relations associatedStreet distincte les scripts BANO retrouveront leurs petits. C'est un peu dommage dans la mesure où créer à la main les relations associatedStreet et ajouter chaque adresse est très chronophage par rapport à un ajout name:left et name:right... Pour t'économiser il y a l'outil de génération d'adresses : http://cadastre.openstreetmap.fr/?type=adresses Bon cela dit merci, ça m'aide pour mes propres modifs. Du coup la rue en question est incluse dans deux relations associatedStreet ? Oui En fait aux débuts de BANO, j'ajoutais pas mal de relations associatedStreet et quand la référence FANTOIR devait être indiquée, je la plaçais dans ladite relation. Seulement ce n'était jamais reconnu, quand je m'en suis aperçu j'ai dû mettre la référence FANTOIR directement sur la rue. Etait-ce normal à l'époque, et est-ce que ça a vraiment changé maintenant ? Sur ce point là non. Le code Fantoir est géré sur les relations depuis le tout début de BANO. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] calcul d'itinéraires sur osm.org
Bonjour, De: Pieren pier...@gmail.com Il n'y a pas encore eu d'annonce officielle Si, ici : https://blog.openstreetmap.org/2015/02/16/routing-on-openstreetmap-org/ vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Article - La Voix du Nord
De: Romain MEHUT romain.me...@gmail.com Ce qui est rigolo c'est que les journalistes ne savent pas comment s'y prendre pour remonter à la source du tracé. L'article évoque une prise de contact avec OSM. Mais contact at openstreetmap.fr n'a rien reçu. Est-ce qu'au moins par ici quelqu'un a été sollicité en direct ? vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cantons
Bonjour, De: Francescu GAROBY f.gar...@gmail.com Je relance ce sujet : les élections sont dans 1 mois et demi, les candidats commencent à être connus (localement) et à se déclarer, les médias commencent à parler de l'élection, ... Bref, les anciens cantons n'ont plus vraiment de raison d'être (personne ne va pas s'intéresser à leur découpe ou à en tracer de nouveaux, maintenant), il serait peut-être bon de commencer à faire la bascule. Je propose que lorsque quelqu'un fait la bascule, il la fasse en même temps pour les 2 types de cantons : les anciens (avec l'ajout du préfixe disused:* et du tag end_date=2015-03, comme évoqué précédemment) et les nouveaux (avec le retrait du préfixe planned:*). Et ce serait bien que cela soit fait pour tout un département à la fois (les nouveaux cantons ne suivant pas les frontières des anciens, il risquerait sinon d'y avoir superposition d'anciens pas encore désactivés et de nouveaux cantons fraîchement activés, et les 2 seront considérés comme les cantons officiels par les moteurs de rendu) Cette façon de faire vous convient-elle ? Oui pour moi, sur l'ensemble. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Article - La Voix du Nord
De: DH dhel...@free.fr Quelqu'un a pris contact avec l'auteur initial du tracé (Jacques Lys) pour lui demander ses sources ? Peut-être nous écoute-t-il sur cette liste ? Oui, ce matin, par messagerie OSM. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712
Bonsoir, Le 11/02/2015 16:28, Philippe Verdy a écrit : Mais en fin de compte puisque ton identifiant utilise un numéro Insee de commune française qui en est à la source, - pourquoi pas ref:FR:x = Vnn, où x est le code commune à 5 chiffres ? - ou bien ref:FR:x=Vnnn, où x est le code SIREN de l'entité qui l'a défini, - ou bien ref:FR-dd:CCXXX = * où CCXXX est l'abréviation en lettres de l'EPCI et dd est le numéro de département de sa commune siège (donc ref;FR-87:CCPRO = * pour ta communauté de communes, puisque FR-dd est un code ISO 3166 valide comme l'est aussi FR). Au moins avec ref:FR=* on sait que c'est discuté en France, et documenté en français (pas sûr pour autant que nos amis belges ou canadiens nous ait suivi adns le détail, Allez, soyons fous : un des schemas ci-dessus emporte l'adhésion, et est massivement propagé. On se retrouve avec, disons, une centaine de collectivités qui l'adoptent. Résultat, une centaine de tags ref:FR:identifiant de la collectivité distincts, stockant chacun des valeurs pour la même notion : un identifiant unique. Et maintenant, un consommateur de données OSM veut appréhender ces données à l'échelle de la France, en exploitant ces identifiants, par exemple pour les afficher sur une carte. Donc une centaine de colonnes distinctes dans une BD, rien que pour récupérer toutes les valeurs des différents émetteurs. Des colonnes vides à 99% évidemment, puisque chacune n'est utilisée que sur un tout petit périmètre géographique. Tout ça fait une donnée très pénible à exploiter, car explosée artificiellement dans différents tags (osm) ou colonnes (de BD relationnelle). Vous voulez faire des stats ? Accrochez-vous... En bref : je suis contre les noms de tags à composante géographique à une maille aussi fine qu'une collectivité territoriale. Pour moi on ne devrait pas descendre en dessous du pays dans les espaces de nom, donc ref:FR ici. Et, ça a été rappelé par Fred, un simple tag local_ref permettrait souvent de s'en sortir. KISS*, comme disait l'autre. vincent * http://fr.wikipedia.org/wiki/Principe_KISS ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le cadastre vectoriel est accessible en WMS
Bonsoir, Le 10/02/2015 21:42, Pierre a écrit : Bon ben j'ai plus qu'à simplifier drastiquement Qadastre2OSM ? :) Il était temps, plus de lecture de pages web, de hack pour lire un fichier PDF… le rêve ! Tss tss tss. Pas touche à Qadastre ! ;) Pour pas mal l'utiliser depuis une semaine, le WMS est vraiment pratique en fond de plan, ça zoome/dézoome et charge correctement, bref, c'est très bien, mais ça reste du pixel ! Donc Qadastre a encore de beaux jours devant lui, et la lecture de PDFs aussi. Et comme on ne te croise pas souvent par ici, c'est l'occasion de te remercier pour cet outil, qui en a permis d'autres : l'extraction d'adresses, et BANO dans la foulée. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rencontre parisienne OSM au Numa le 30 janvier 2015
Bonjour, De: althio althio.fo...@gmail.com Autre sujet de discussion : les itinéraires vélos et le dénivelé. Ce n'est pas le rendu évoqué (par échelle de couleur directement sur l'itinéraire) mais voici une autre présentation : https://www.mapbox.com/blog/dc-bikeshare-revisited/ Je suis tombé là-dessus : http://hillmapper.com/ (sur fond Google) qui n'offre pas de calcul d'itinéraire mais renseigne dans la même idée, autour de soi. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712
Le 05/02/2015 18:04, Tony Emery a écrit : Voici mon premier mail, dites-moi en quoi il est agressif : Bonjour Philippe, (...) tu ajoute les tags admin_level et boundary sur le tronçon alors que c'est en doublon avec le fait que ce tronçon fait partie d'une relation de type boundary Il faut que tu corriges absolument ces erreurs sur l'ensemble de ton groupe de modification car nous ne pouvons plus réutiliser ces données par la suite. Ajouter les tags admin_level et boundary sur un tronçon, highway ou pas, n'a rien d'une erreur dès lors que ce way est membre d'une relation boundary=administrative. Et si au passage ça permet de rappeler, en cours d'édition, qu'on manipule une route (ou une rivière, etc.) *qui est aussi une limite*, ça me semble un garde-fou pas inutile. Il faut se rappeler que Potlatch 2 et iD sont muets quand on efface un membre de relation. JOSM en revanche, prévient, ce qui devrait limiter la casse. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712
Bonjour, De: Philippe Verdy verd...@wanadoo.fr Visiblement il utilise OSM comme si c'était un SIG privé. Je doute que ça soit son intention. Mais Tony pousse l'utilisation d'OSM dans ses retranchements, en couplant les données OSM et ses référentiels métier,au sein de sa collectivité. Je l'ai alerté sur les relations cassées, j'en ai aussi réparé quelques unes depuis 24h. Pour ce qui est de tags tels que ref:FR:commune, si ça répond à son besoin, alors pourquoi pas. Mais il y a une limite à l'exercice : si ça n'est pas documenté, alors d'autres contributeurs n'auront pas de moyen de comprendre de quoi il retourne et ça n'aidera pas à la maintenance de ces tags, ni des objets qui les portent. Donc si Tony et lui seul en a l'usage, à lui avant tout de s'en donner les moyens en documentant ce qu'il fait de manière accessible aux contributeurs. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : non rapprochement highway avec code FANTOIR
De: Stéphane Péneau stephane.pen...@wanadoo.fr Je vois. Donc dans le cas d'une rue séparant 2 communes, avoir 2 relation associatedstreet avec sur le tag name Rue truc - Machin sur Seine, et Rue truc - Bidule sur yvette n'est pas une bonne idée ? Malgré l'aide que ça apporte pour les repérer dans la liste des relations ? Ou alors on efface la relation et on revient au schémas addr:housenumber + addr:street sur les noeuds adresse :-) Oops, mes excuses, en re-regardant le code je vois que ma mémoire a un peu rêvé. Dans le cas des relations associatedStreet, on ne va _pas_ chercher le nom des highways en 2e choix, ni en 1er, on prend le tag name de la relation, point. Ça mériterait d'être assoupli au vu de la discussion présente, en même temps jusque là ça n'a pas heurté grand monde, mais c'est peu étonnant vu le % de présence du tag name dans les relations associatedStreet (+99% en France). vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : non rapprochement highway avec code FANTOIR
Le 02/02/2015 20:20, lenny.libre a écrit : Le 01/02/2015 21:12, Philippe Verdy a écrit : Note: le noms des deux relations (name=*) devrait être suffixé pour éviter l'homonymie. J’ai fait une recherche et je n'ai pas trouvé de description sur la manière de faire (séparation entre radical et suffixe et le suffixe lui-même - name, code insee ... - ). Est-ce : name = Avenue des Chênes:Bordeaux pour l'une et name = Avenue des Chênes:Mérignac pour l'autre ? On peut toujours indiquer le nom **non suffixé** de la rue dans le tag addr:street=* de la relation. Si on en est là, autant laisser comme name=* de la relation le nom de terrain (sans nom de ville accolé) et ajouter à titre indicatif un tag addr:city à la relation, ou une note disant la même chose. Quand il existe (ce qui n'est en rien obligatoire), le tag name des relations associatedStreet sert dans BANO. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Base de données pour le développement
Bonsoir et bienvenue, Le 02/02/2015 23:12, Vincent Frison a écrit : La base de données concerne environ 40 000 immeubles répartie sur toute la France mais de toute façon je comptais bien lancer un nouveau sujet pour détailler et demander des conseils techniques voir légaux. Pour l'instant mon problème est juste sur la base de données de test... Ou bien demander des conseils légaux voire techniques ;) Tu as des infos sur la licence associée aux données de la base PSS ? C'est, comme pour tout apport de données d'une base externe, la première question à voir, sachant qu'elle peut à elle toute seule bloquer la suite. Je vois que ce fil : http://www.pss-archi.eu/forum/viewtopic.php?id=33791 n'a pas déchaîné les foules, et comme turman (toi ?) je n'ai rien trouvé sur le statut de cette base. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : non rapprochement highway avec code FANTOIR
Bonjour, Le 03/02/2015 02:25, Philippe Verdy a écrit : Le rapprochement BANO n'utilise-t-il pas de préférence le tag addr:street:* (plutot que name=*) quand il est présent ? Du tout, non. Sur les entités associatedStreet, on a très souvent un tag name, et, d'après taginfo.fr, jamais de tag addr:street : http://taginfo.openstreetmap.fr/tags/type=associatedStreet#combinations Il y a 2 cas pour un objet portant le tag addr:housenumber, - rechercher un tag addr: street sur le même objet, - ou bien l'inclusion de l'objet à une relation associatedStreet. Deux sous-possibilités pour les objets des relations : soit la relation a un tag name, et on le prend, soit elle n'en a pas et on va chercher le tag name des membres de la relation ayant le rôle 'street'. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rencontre parisienne OSM au Numa le 30 janvier 2015
Bonjour, De: Vincent de Château-Thierry v...@laposte.net Autre questionnement hier, suite à une récente cartopartie au Père-Lachaise : comment décrire, mieux qu'avec un simple tag name, les subdivisions des cimetières ? Comme ici : http://www.openstreetmap.org/way/177232497 Je tombe sur cette proposition en cours, avec déjà un peu d'usage (~2300 ways) : http://wiki.openstreetmap.org/wiki/Proposed_features/Cemetery_sector vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] 149 nouvelles communes au format vectoriel au cadastre ?
Le 01/02/2015 15:25, Yves Pratter a écrit : Alzeihmer a frappé: où se trouve la liste des communes ajoutées ? Didier2020 en a donné l'essentiel au début de ce fil : https://lists.openstreetmap.org/pipermail/talk-fr/2015-January/074732.html Sinon un moyen au jour le jour : https://twitter.com/CadInfos Pour simplifier l'accès complet, il y aura bientôt sur github la liste des 36000 communes avec leur format et la date de constat d'apparition de leur dernière version : soit une bascule raster/vecteur, soit une mise à jour du vecteur. Sans cette notion de date, la liste est déjà visible ici : https://github.com/osm-fr/bano-data/blob/master/cadastre_type.txt vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] 149 nouvelles communes au format vectoriel au cadastre ?
Bonjour, Le 28/01/2015 21:31, Vincent de Château-Thierry a écrit : Le 28/01/2015 20:54, didier2020 a écrit une liste longue comme le bras : 02 02104 BOUFFIGNEREUX (...) 91 91630 VAL-SAINT-GERMAIN (LE) Eh bé :) J'arrive au même chiffre que toi. Ça fait du monde ! On verra demain si ça se voit ici : http://munin.openstreetmap.fr/osm12.free.org/osm104.openstreetmap.fr/bano_rapproche.html Ça ne s'est finalement pas vu le lendemain. En effet, cette grosse livraison de contenu a mis en évidence pour nous un changement dans la manière de composer les plans côté Cadastre : le dessin des limites de parcelles a été modifié, ainsi que la police de caractères utilisée pour tous les textes, notamment ceux qui nous intéressent en premier lieu : numéros d'adresses. La description de la forme des caractères étant au coeur de la mécanique de récupération des infos pour BANO, le 29/1 au matin, rien parmi les nouvelles communes n'avait été intégré, le robot BANO ne reconnaissait rien parmi les nouveautés. Il a fallu que Tyndare (merci à lui), auteur de cette partie de code stratégique, remette les mains dedans, pour adapter les algorithmes à ces changements. C'était chose faite hier, en premier lieu au bénéfice de l'outil d'extraction d'adresses : http://cadastre.openstreetmap.fr/?type=adresses Les modifications ont été transmises au code BANO, et les 168 communes apparues en vectoriel depuis le début de semaine ont été intégrées cette nuit, apportant un peu plus de 2000 rapprochements et 2 adresses. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] 149 nouvelles communes au format vectoriel au cadastre ?
Le 01/02/2015 15:51, Yves Pratter a écrit : C’est micro qui a frappé : j’ai recherché 168 communes dans les entêtes de méls, pas 149 :D Arf ;) 149 c'était pour la seule journée du 28/01. 168 c'est sur l'ensemble de la semaine. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Le cadastre vectoriel est accessible en WMS
Bonjour,
Jusqu'à présent pour visualiser le cadastre vectoriel, il fallait
utiliser le plugin Cadastre-Fr. Depuis quelques jours, une alternative
apparaît, à l'initiative de la DGFiP. En effet, elle vient de rendre
public son service WMS : le cadastre accessible en tuiles, directement
par le producteur.
La documentation est ici :
https://www.cadastre.gouv.fr/scpc/aide.do#
= rubrique Votre service WMS
et pour vos réglages JOSM, voici un exemple de ligne à déclarer (F12
rubrique 'TMS/WMS') :
wms:http://inspire.cadastre.gouv.fr/scpc/*code
INSEE*.wms?service=WMSrequest=GetMapVERSION=1.3CRS={proj}WIDTH={width}HEIGHT={height}BBOX={bbox}LAYERS=BU.Building,AMORCES_CAD,CP.CadastralParcel,HYDRO,BORNE_REPERE,DETAIL_TOPO,LIEUDIT,VOiE_COMMUNICATIONSTYLES=FORMAT=image/png
Il faut adapter 2 éléments de la requête :
- la chaîne '*code INSEE*' est à remplacer par les 5 caractères du
code de la commune qui vous intéresse.
- la liste des thèmes affichés (après 'LAYERS=') : cette liste est
modulable selon ce qui vous intéresse.
Par rapport au plugin Cadastre-Fr, du mieux et du moins bon : le mieux,
c'est que l'affichage est directement possible en projection Mercator,
donc on gagne en confort d'utilisation. Le moins bon, c'est que ça ne
gère que les communes en vectoriel, là où le plugin sait tout afficher,
y compris le raster sans géoréférencement.
À vos tests et à vous lire
vincent
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rencontre parisienne OSM au Numa le 30 janvier 2015
Bonjour, Le 31/01/2015 12:15, Shohreh a écrit : Merci pour la rencontre hier soir. La prochaine sera un _jeudi_ : le 26/02 ;) Et puisqu'on parlait des bornes incendie, un sujet connexe… The One-Man Beautification Plan: A security guard from Queens explains why he’s repainting New York’s forgotten emergency call boxes. www.slate.com/articles/podcasts/gist/2015/01/the_gist_fdny_call_box_beautification_with_john_colgan_and_a_new_lobstar.html On a aussi (entre autres) évoqué les références portées sur les églises : http://wiki.openstreetmap.org/wiki/Key%3Aref%3AFR%3ACEF vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rencontre parisienne OSM au Numa le 30 janvier 2015
Le 31/01/2015 17:30, Vincent Pottier a écrit : Le 31/01/2015 15:28, Vincent de Château-Thierry a écrit : On a aussi (entre autres) évoqué les références portées sur les églises : http://wiki.openstreetmap.org/wiki/Key%3Aref%3AFR%3ACEF Et il s'est dit quoi ? On a parlé de toi ;) C'était en évoquant l'identification et le référencement des églises, notamment parmi les bâtiments importés depuis le cadastre, car Donat passe du temps sur le sujet. Mais je vois sur le wiki que ces références ne sont plus accessibles ? Autre questionnement hier, suite à une récente cartopartie au Père-Lachaise : comment décrire, mieux qu'avec un simple tag name, les subdivisions des cimetières ? Comme ici : http://www.openstreetmap.org/way/177232497 vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : non rapprochement highway avec code FANTOIR
Le 31/01/2015 20:43, lenny.libre a écrit : Le 31/01/2015 19:49, Stéphane Péneau a écrit : Elle n'est pas rapprochée car cette avenue est située dans les limites communales de Mérignac. A aucun moment elle ne passe dans Bordeaux. Il y a seulement quelques maisons qui semblent en faire parti. Je ne crois pas qu'il y ait de solution toute prête pour ce genre de situation, mais Vincent pourra certainement en dire plus. Bien vu, en effet, je l'ai vraiment raté !!! Le rapprochement se fait avec la même voie à Mérignac Je n'ai pas trouvé de statuts FANTOIR qui corresponde : Adresses hors périmètre est le plus proche, mais c'est toute la rue qui est hors périmètre ... Il y a bien un bout de code qui permet de récupérer des voies en dehors d'une commune pour tenter un rapprochement. Mais comme on est hors commune, pour ne pas prendre n'importe quoi, il faut un code Fantoir rattaché à la commune. Le cas que tu indiques est pile dedans, donc ça devrait marcher. Sauf que non. Bordeaux est une commune où certains noms sont suffixés. Et jusque là, pour les communes avec des noms suffixés, je zappe cette étape de recherche des voies en dehors de la commune. Pourquoi ? Pas idée ! Ça doit être la flemme :) Bref, ça ne marchera pas ce soir, mais pour ne pas oublier j'ai créé un ticket : https://github.com/osm-fr/bano/issues/88 vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : non rapprochement highway avec code FANTOIR
Le 31/01/2015 23:28, Philippe Verdy a écrit : Raison de plus pour ne pas séparer le chemin d'une rue et celui d'une frontière administrative alors que c'est dévidence la même; la rue étant partagée par deux communes, chacune utilisant son code FANTOIR et éventuellement son propre nom et sa propre numérotation des adresses (et son éventuel code de voie communal dans son SIG; si ce n'est pas le FANTOIR et le rapprochement complet n'est pas fait ou difficile car pas complètement équivalent pour certaines sections distinguées dans un des codes mais pas dans l'autre). La séparation physique (en séparant les nœuds) s'impose seulement si la frontière s'écarte de la voirie et va séparer des parcelles d'une seule commune. Dans le cas présent la frontière entre Bordeaux et Mérignac ne passe pas par l'axe de l'Avenue des Chênes, mais traverse bien des parcelles. La limite dans OSM est raccord avec celle visible directement sur le cadastre : http://www.openstreetmap.org/way/186045436#map=18/44.84906/-0.63297 donc la question du partage des chemins entre rue et frontière n'est pas à poser ici. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Communes sans voies nommées : 'B'
De: JB jb...@mailoo.org Oups, j'ai dû très mal m'exprimer. Bazoches les Bray ne fait pas partie du gâteau en B, alors qu'il me semble qu'il devrait. C'est pas un grand malheur, mais je suis curieux… Pierre-Yves a trouvé l'explication et le coupable. Évidemment un cas comme ça mériterait largement sa place dans l'inventaire. On ferra un gâteau de rattrapage avec les cas limites :) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] 149 nouvelles communes au format vectoriel au cadastre ?
Le 28/01/2015 20:54, didier2020 a écrit une liste longue comme le bras : 02 02104 BOUFFIGNEREUX (...) 91 91630 VAL-SAINT-GERMAIN (LE) Eh bé :) J'arrive au même chiffre que toi. Ça fait du monde ! On verra demain si ça se voit ici : http://munin.openstreetmap.fr/osm12.free.org/osm104.openstreetmap.fr/bano_rapproche.html vincent ps. dans ta liste il manquait la 149e ligne : Saint-Victor-de-Malcap (30) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment afficher les noms de lieux en français sur toute la planète ?
Bonjour, De: Ab_fab gamma@gmail.com Pierre a répondu à ta question. Pour aller un peu plus loin, voila un outil qui vise à faciliter l'ajout des noms de lieu en français (*) partout dans le monde. http://nomino.openstreetmap.fr/ Il y a aussi cette carte qui met en oeuvre le concept : http://mlm.jochentopf.com/?zoom=10lat=0lon=0layers=B0Tlang=fr (mais à l'instant je n'obtiens pas de tuiles). vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nouvelles communes vectorielles (était Osmose)
De: Jean-Baptiste Holcroft jb.holcr...@gmail.com Le 27 janvier 2015 12:12, Pierre-Yves Berrard pierre.yves.berr...@gmail.com a écrit : Euh, rectification. Le 27 janvier 2015 12:04, Pierre-Yves Berrard pierre.yves.berr...@gmail.com a écrit : Une grosse fournée vient d'arriver : environ 2500 communes nouvellement vectorisées (si mes calculs sont bons). C'est beaucoup plus modeste hélas, mais le réveil des communes nouvellement vectorisées a bien eu lieu hier [1] pour 2015. Et en page 20 de ce doc : http://circulaires.legifrance.gouv.fr/pdf/2015/01/cir_39087.pdf une liste (à droite) des communes pour lesquelles on n'a pas fini d'attendre le passage en vectoriel... vincent [1] : https://twitter.com/CadInfos/status/559945058271502336 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Codes Fantoir erronés
De: Frédéric Rodrigo fred.rodr...@gmail.com Pas tout a fait. Les codes FANTOIR ne sont rendu public via le FANTOIR annuellement, mais les communes le reçoivent avant et peuvent le diffuser. Oui il ne faut pas l'exclure. Mais le sondage que j'ai pu faire sur les ~150 codes remontés jusque là montre une majorité de cas où la différence entre un code connu de Fantoir et le code connu d'OSM est sur 1 caractère : un 8 compris comme un 3 ou le contraire, etc. Donc plutôt sur des codes pas forcément tous neufs, et entrés à la main en relisant le calque BANO, par ex. Après, si on ne parvient pas à tout corriger, avec le Fantoir actuel (millésime 2014), ça n'est pas un souci. Ça donnera l'étendue des codes dont tu parles, plus récents. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Codes Fantoir erronés
Bonjour, je relaie ici une annonce faite sur le forum [1]. J'ai placé sur cette page : http://cadastre.openstreetmap.fr/fantoir/fantoir_errone.html un listing des codes Fantoir connus seulement d'OSM, car absents du fichier Fantoir. Il s'agit donc d'anomalies, souvent dûes à des fautes de frappe lors de la saisie en base. Vous reconnaîtrez sur la page les liens présents sur http://cadastre.openstreetmap.fr/fantoir/ afin de permettre l'édition des objets concernés, l'objectif étant de réduire à 0 le nombre de lignes de cette page. À noter : la page est un peu longue à charger car l'établissement du listing se fait dynamiquement à l'ouverture, en interrogeant les données BANO et Fantoir France, ce qui fait un peu de monde. Merci à vous, vincent [1] : http://forum.openstreetmap.fr/viewtopic.php?f=2t=1187start=140#p7426 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Codes Fantoir erronés
Le 26/01/2015 18:23, Philippe Verdy a écrit : pour tester le rapport; j'ai juste essayé sur une correction sur une seule voie avant de voir si le rapport se mettait à jour. Il n'y a pas de mise à jour directe depuis la page en question. Pour qu'elle se rafraîchisse, il faut mettre à jour BANO pour la commune où tu as fait des modifs. C'est possible depuis les liens de droite intitulés Fantoir-OSM code INSEE. Et sans mise à jour par ce biais, il y a de toute façon une mise à jour BANO complète chaque nuit, donc en revenant le lendemain, on doit voir l'impact de ses éditions : normalement, les lignes qu'on a éditées ont disparu. Cette iste ne semble pas longue avec 149 codes détectés encore (148 en tenant compte de ma modif invisible; ou moins s'il y en a d'autres). Bref ça peut être fait très rapidement; mais j'attends de voir. Oui, ça peut être très rapide de vider cette liste. L'intérêt sur la durée est de surveiller de temps en temps si de nouvelles lignes apparaissent. Question: ce rapport tient-il compte des codes FANTOIR formés du code commune, suivi de et de la lettre rivoli, utilisé par endroit pour prolonger voiries privées (essentiellement des voies de service dqns des entreprises ou centres commerciaux) où l'accès public reste toléré et n'est pas réellement fermé par des portails ? Ce rapport prend comme données de référence celles disponibles ici : http://www.collectivites-locales.gouv.fr/mise-a-disposition-fichier-fantoir-des-voies-et-lieux-dits qui sont consultables par commune, intégralement, ici : http://cadastre.openstreetmap.fr/fantoir/liste_brute_fantoir.html Est-ce que ce rapport considère en erreur les codes écrits simplement en minuscules (il ne semble pas que la casse soit réellement signifiante pour la lettre du code rivoli ou les départements de Corse). Oui, tu peux voir dans la liste des codes avec une lettre en minuscule. Enfin tient-il compte des segments de voies qui ont 2 codes FANTOIR distincts quand la rue sert de frontière séparant deux communes Oui vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose
Le 26/01/2015 21:06, Jérôme Amagat a écrit : Le 26 janvier 2015 20:38, Jérôme Amagat jerome.ama...@gmail.com mailto:jerome.ama...@gmail.com a écrit : Sur le rendu BANO, il a été ajouté les lieux dits, certains s'appelle hameaux machin, et semble bien placé. Pourquoi ne pas sortir leur position avec leur nom et permettre de l’intégrer dans osmose avec place=hamlet. C'est prévu. Il reste pour cela à déterminer une proposition de valeur pour le tag place, en fonction de la quantité de bâtiments inclus dans les parcelles rattachées au nom du lieu-dit. Ça ne sera qu'une proposition, à ré-évaluer au cas par cas, mais le but est autant que possible de ne pas proposer n'importe quoi. Il y aura aussi ajout, quand c'est possible, du code Fantoir du lieu-dit, histoire de permettre comme pour les voies un inventaire de ce que contient OSM. Ici: https://github.com/osm-fr/bano-data/blob/master/cadastre_type.txt le fichier n'est plus mis à jour depuis un mois : normal, pas normal ou c'est juste qu'au cadastre ils sont encore en vacances? Depuis le 20/12/14, les scripts BANO tournent bien chaque nuit, mais n'ont plus détecté de nouvelles communes vectorielles, en effet. Donc le fichier https://github.com/osm-fr/bano-data/blob/master/cadastre_type.txt ne bouge pas, tout comme le fil Twitter https://twitter.com/CadInfos qui diffuse les nouvelles communes vectorielles au jour le jour... quand il y a de la matière. Wait see :) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Communes sans voies nommées : 'B'
Bonjour,
le chantier Mapcraft de nommage de rues pour les communes muettes
commençant par T - Z [1] touche à sa fin, avec plus de 90% des communes
prises en charge. À noter, la Corse est un peu délaissée et concentre la
moitié du reste à faire.
Retour en quelques chiffres sur les deux premiers chantiers de la série
('A' et 'T-Z') :
on recense 3687 voies nouvellement nommées, dont 3234 avec rapprochement
Fantoir. Elles permettent d'alimenter BANO en n° d'adresse à hauteur de
25000 nouveaux points, rien que ça.
Pour continuer sur cette belle lancée, je vous propose un nouveau
gâteau, avec les 231 communes sans nom de voies et commençant par 'B'.
Ça se passe par ici :
http://mapcraft.nanodesu.ru/pie/468 et vous êtes tou(te)s bienvenu(e)s.
et toujours le wiki :
http://wiki.openstreetmap.org/wiki/WikiProject_France/WikiProject_Base_Adresses_Nationale_Ouverte_(BANO)/MapCraft_:_communes_sans_aucune_rue_nomm%C3%A9e
vincent
[1] :
https://lists.openstreetmap.org/pipermail/talk-fr/2014-December/074215.html
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Tagging] Deprecation of associatedStreet-relations
De: Jo winfi...@gmail.com Puis ils on toutes sortes de raisons, mais cela revient toujours à un support pauvre dans certains éditeurs, pour maintenir ces relations... aucune iD lequel ça pourrait être. :) 2015-01-23 11:40 GMT+01:00 Philippe Verdy verd...@wanadoo.fr : Mais je voterais plutôt contre la migration des relations vers les noeuds (oui ça foutra le bordel dans les rapprochements de la BANO Non Philippe, j'insiste, BANO n'est pas impactée. Faire un vote pour déprécier des tags sans même discuter des migrations à faire et de leur impact est assez stupide. D'accord là dessus. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Tagging] Deprecation of associatedStreet-relations
De: Philippe Verdy verd...@wanadoo.fr Pour l'instant non, mais on verra ce que ça donnera si des contributeurs se mettent à virer toutes les relations et insistent pour ne taguer que les noeuds et les voies. On a déjà de nombreuses erreurs liées à cette séparation; le rapprochement BANO se fait déjà mal et les relations ont chaque fois résolu les problèmes d'ambiguité comme des points d'adresses rapporochés sur la mauvaise rue (et pallié aussi à de nombreux oublis quand les relations n'étaient pas là pour référencer les noeuds isolés un peu trop loin de la voie). Le rapprochement des données OSM dans BANO exploite soit l'appartenance à une relation associatedStreet, soit le couple de tags addr: street et addr:housenumber. Il n'y a _aucune_ prise en compte de la géométrie pour les rapprochements, le critère d'éloignement de la voie n'est pas pris en compte. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Tagging] Deprecation of associatedStreet-relations
Bonjour, Le 23/01/2015 05:17, Philippe Verdy a écrit : Autre difficulté c'est le rapprochement pour BANO avec les codes fantoir; dans le cas des segments de rues qui en ont deux car la rue sépare deux communes et chaque coté utilise sont code FANTOIR. Non, pas de souci ici. BANO gère l'affectation des codes Fantoir uniques sur les nodes, ways, ways fermés, et relations associatedStreet (tag ref:FR:FANTOIR) et des codes latéraux sur les ways (ref:FR:FANTOIR:left et ref:FR:FANTOIR:right). Ce vote s'l aboutit risque de mettre à mal l'important travail de rapprochement qui a lieu pour la BANO et ses équivalents dans divers pays. Ce vote s'il aboutit ne changera rien pour BANO, qui gère les 2 schémas d'adressage : par relation associatedStreet ou par tag addr: street. Et ça tous ceux qui ont voté pour approuver le chagement n'ont pas vraiment compris car les enjeux ne sont pas expliqués, et parce qu'aucune solution claire de remplacement n'a été expliquée; ni même discutée; avant de passer directement au vote expéditif ! Oui, ça a été présenté comme un sondage mais l'absence de contexte, et surtout la confusion sur ce qui devrait remplacer les relations associatedStreet (la relation Street ? le schema simple addr: street ?) fait qu'on ne sait pas pour quoi on vote. Pas top. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Offre de stage
Bonjour, Vue ce matin, une (chouette) offre de stage où OSM est une partie du sujet : http://georezo.net/forum/viewtopic.php?pid=262994#p262994 vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Zonages statistiques Ilots et IRIS
Bonjour, L'APUR libère des données qui sont parfois évoquées ici, souvent pour regretter leur caractère non libre, car s'appuyant sur des géométries de l'IGN. Il s'agit des les limites statistiques infracommunales Îlots et IRIS : http://www.apur.org/article/donnees-disponibles-open-data Les données Îlot ne sont pas (au moins en diffusion INSEE) promises à grand avenir : http://www.insee.fr/fr/methodes/default.asp?page=definitions/ilot.htm donc les intégrer dans OSM se discute. Proposer en revanche un fond IRIS [1] national et libre aurait de l'allure, et des consommateurs. Les données de l'APUR sont un matériau pertinent, sur Paris et petite couronne, pour alimenter cette démarche. Il faudrait à cette occasion établir un schéma de tags, à base de boundary=census ou boundary=statistical, non documentés pour l'instant. vincent [1] : http://www.insee.fr/fr/methodes/default.asp?page=definitions/iris.htm ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
Le 20/01/2015 18:22, Marc SIBERT a écrit : Ça va quand même être difficile de faire ça sans rien ajouter dans OSM. Certaines limites n'existent simplement pas dans la zone où je regarde (ma commune). J'ai précisément une limite qui semble être la voie ferrée et comme les rails sont multiples, je serais tenté de placer une limite boundary filaire pour clore ma surface constituée jusque là de boundary=admin et de highway. Mais la question vaut d'être posée ! Dans OSM, ou pas ? En effet, quel peut être l'intérêt d'un zonage (un de plus !) directement dans OSM ? Petit préambule : il existe un produit, commercialisé par l'IGN, qui détaille les contours d'IRIS avec une précision géométrique semblable à celle qu'on manipule dans OSM. Je vous laisse voir les tarifs de 2012 p10 de ce doc : http://professionnels.ign.fr/sites/default/files/Bar%C3%A8me%20des%20licences%20d%27utilisation%20des%20produits%202012.pdf Un autre produit est proposé par ESRI France : http://esrifrance.fr/iso_album/DP_FranceIRIS_V1.1.pdf Ces mentions pour indiquer que le contenu IRIS est suffisamment utilisé pour disposer d'un marché. Je parlais volontairement de consommateurs au début de ce fil. À partir de là, proposer des contours IRIS issus d'OSM, c'est potentiellement répondre à un besoin. La problématique ici n'est pas différente des autres thématiques de la base, comme par exemple les limites communales : https://www.data.gouv.fr/fr/datasets/decoupage-administratif-communal-francais-issu-d-openstreetmap/ Par nature, les limites d'IRIS s'appuient sur des éléments physiques : cours d'eau, axes de voirie, voies ferrées. Proposer une couche intégrée dans OSM, c'est offrir un jeu de données cohérent, en terme de géométrie. Si les IRIS sont libérés prochainement, ça facilitera le travail d'intégration, mais ne changera pas la plus-value de cohérence géométrique liée à une intégration dans OSM. À l'inverse, oui bien sûr, ça constitue une couche de relations supplémentaire, qui plus est en milieu urbain, dense en informations. On n'échappera pas à de la casse de relations de temps en temps. C'est le lot (quotidien) pour les limites communales. Mais, comme pour ces dernières, s'il y a un besoin, et des consommateurs, il y aura toujours de la motivation pour assurer la maintenance, j'en suis convaincu. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagguer les Départements français et admin_level=6
De: Philippe Verdy verd...@wanadoo.fr Franchement je préfère qu'ont ne touche pas les admin_level et qu'on les garde simples comme ils sont même s'ils assimilent plusieurs choses. Ajouter un tag pour distinguer les statuts sera plus simple à gérer (comme pour les EPCI). Sly je te rejoins sur le principe, en considérant qu'on ne devrait pas tagguer de la même manière des notions distinctes. C'est potentiellement inexploitable, source de confusion aussi bien pour le contributeur que pour le consommateur. Mais... je crains qu'on aie un peu de mal à tagguer vraiment différemment aussi bien Lyon que la Nouvelle-Calédonie. Donc je verrais bien le maintien des tags actuels (boundary et admin_level) sans changer leurs valeurs, mais à la condition qu'on ajoute, comme le suggère Philippe, un tag qui raffine le sens, afin de pouvoir les distinguer, autrement que par leur ID de relation ou par la valeur de leur tag name. Je n'ai pas cherché bien loin, mais il existe par exemple le tag 'administrative', joyeux fourre-tout pour l'instant : http://taginfo.openstreetmap.org/keys/administrative#values qu'on pourrait utiliser, par exemple pour Lyon : boundary=administrative admin_level=6 administrative=metropole et en NC : boundary=administrative admin_level=6 administrative=province Je donne ça comme exemple, pas pour dire que ça doit être ce tag ni cette valeur, le fond de la question étant de pouvoir manipuler ces données sans confusion possible. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comportement JOSM
De: JB jb...@mailoo.org Quand je suis en mode ajout, et que je crée un nœud, l'écran se déplace pour placer ce nouveau nœud au milieu de l'écran de travail… C'est pas que ce soit une mauvaise idée en soi, mais le léger retard au début du déplacement pourrit complètement la vitesse de travail. Du coup, si quelqu'un connait le raccourci ou la méthode pour désactiver, ce serait chouette, Ça ressemble à Affichage suivi de la vue : Ctrl+Shift+F vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] geocodage à l'adresse ?
Bonjour, De: Laurent CELATI lcel...@cci-paris-idf.fr J'ai de gros fichiers excels listant des sites d'entreprises. Des champs sont dediés à l'adresse (voie, communes). Je travaille sur des departements franciliens (77/93/95). Je dois geocoder ces fichiers (avec qgis probablement). On m'a conseillé d'utiliser comme reference, comme BD pour le reseau de voies, la donnée OSM. Pourriez vous me dire où je peux récupérer cette donnée OSM s'il vous plait? Il existe une BD qui s'appuie sur les données filaires d'OSM, et les données de numéros d'adresse issues d'OSM et d'autres sources (Cadastre essentiellement, mais aussi OpenData de collectivités) et dont le propos est justement de permettre de géocoder : BANO. Les fichiers de listes d'adresses (n°, nom de voie, commune, code postal x, y) sont disponibles par département ici : http://bano.openstreetmap.fr/data/ Pour QGis, elles existent en format shapefile. Je ne sais pas ce qu'attend QGis comme structuration de données pour le géocodage. Ça serait intéressant d'avoir, à l'occasion, un retour sur ce point. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] geocodage à l'adresse ?
De: Greg ewala...@gmail.com Il est possible d'avoir un aperçu de la couverture de BANO avec cette carte : http://layers.openstreetmap.fr/?zoom=6lat=47.35651lon=2.25398layers=BFT 2015-01-14 13:10 GMT+01:00 image93 lcel...@cci-paris-idf.fr : Je vous remercie beaucoup pour votre message. Celà semble etre intéressant.Meme si j'imagine que la BD n'est probablement pas complète? Il doit manquer des voies, je vais regarder dans mon secteur. 1/ On m'avait parlé également de l'outil OSM Nominatim, mais j'avoue ne pas trop avoir compris comment se servir de l'outil. S'agit il d'un outil web ou d'une base de donnée? Je ne sais pas trop si il peut m'etre utile dans mon cas precis. Nominatim est un service web basé sur les données OSM. Le géocodage de listes d'adresses y est techniquement possible, par paquet de 100 adresses chez MapQuest. Voir http://developer.mapquest.com/fr/web/products/open/geocoding-service et http://open.mapquestapi.com/geocoding/#batch . 2/ En tout cas je compte justement tester et comparer le geocodage avec mapinfo, qgis et postgis. Si vous etes intéressé, je pourrai vous faire un petit retour, notamment sur les requirements sur la structure de données. Volontiers. Avec QGis, j'ai l'impression que le plugin MMQGIS [1] pourrait fonctionner avec les données BANO, en indiquant que les numéros début et fin, droite et gauche, sont un seul numéro. Mais je n'ai pas testé plus. vincent [1] : http://michaelminn.com/linux/mmqgis/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] DKIM Re: Tagguer des magasins ayant une démarche écologique
Le 13/01/2015 15:00, Francescu GAROBY a écrit : Ils font du lavage à l'eau, (...) n'utilise pas de produits agressifs et toxiques (...) et leurs produits sont biodégradables. Eh bien en voilà du _vrai_ greenwashing :) = [] ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Qualification des divergences OSM = Fantoir
Bonjour à tous, et bonne année 2015 L'outil de qualification des divergences entre libellés Fantoir et libellés OSM [1] a un peu plus d'1 mois maintenant. Il a déjà permis de noter des remontées sur plus de 1200 voies, réparties sur 330 communes. Merci à chacun pour le temps consacré à consigner ces observations. Mis en carte, ça donne ceci (données de ce matin): http://umap.openstreetmap.fr/fr/map/localisation-des-divergences-osm-fantoir_25369#6/46.627/2.461 Cette masse d'informations va occasionner des retours d'infos vers la DGFiP, émettrice du Cadastre et du registre Fantoir. La forme de ces retours, et leur périodicité, restent à élaborer. vincent [1] : http://cadastre.openstreetmap.fr/fantoir/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Orne - communes nouvelles
De: Pieren pier...@gmail.com Le niveau 9 pour les arrondissements, c'est assez ancien. On ne peut pas changer les admin_level comme ça, d'un claquement de doigts. Il y a probablement des applications, des gens qui utilisent ces données avec ces tags régulièrement. En effet, fin 2010, pendant cette discussion : https://lists.openstreetmap.org/pipermail/talk-fr/2010-September/026880.html qui justement a mis le doigt sur une application qui utilisait ce découpage. L'idée de compatibilité, de non-régression est bien à prendre en compte quand on commence à toucher à des données structurantes, comme typiquement un découpage administratif, dont l'usage est multiple. La distinction entre arrondissements et communes associées n'est pas un gadget pour les pointilleux. C'est un minimum de pouvoir extraire ces deux types de limites administratives par des requêtes simples, de type overpass-api, sans avoir à filtrer ensuite les résultats en cherchant des id ou des name particuliers. Oui, se baser sur des IDs (non stables) ou un nom, côté fiabilité, c'est un peu le pire. Ajouter des tags décrivant des catégories d'objets, des typologies, là ok. Reste à trouver lesquels, en gardant l'idée qu'une application existante devrait, idéalement, ne pas être impactée. Je dis ça comme un principe à privilégier, pas comme une obligation. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Qualification des divergences OSM = Fantoir
De: David Crochet david.croc...@free.fr Hum, je trouve un défaut au système difficile à rattraper : D'office, le rapprochement est positionné à OK. Donc le OK veut dire 2 choses maintenant : - Soit cela n'a pas été vérifié et donc on ne sait pas si c'est correct - Soit cela été vérifié et on sait si c'est correct. est-il possible de pouvoir faire à un moment ou un autre la différence ? Le statut 'Ok' est exclu des chiffres que je donnais ce matin et donc de la carte associée. C'est le statut par défaut, il n'existe pas (= n'est pas stocké), pour une rue donnée, tant qu'on n'a pas explicitement changé la valeur de liste déroulante, d'abord vers autre chose que 'Ok', puis changé d'avis et remis à 'Ok'. Je n'ai pas les chiffres sous les yeux mais ça concerne très peu de rues. On pourrait reformuler 'Ok' en 'Ok - statut par défaut' pour clarifier. Pour ce qui est 'Vérifié', de 2 choses l'une : - soit il est vérifié que les noms des deux sources correspondent, et dans ce cas ce sont les routines de rapprochement qui vérifient de fait la correspondance, - soit les 2 noms ne correspondent pas, et ce qu'on a pu vérifier sur le terrain, c'est la divergence. Et dans ce cas, il vaut mieux choisir dans la liste une des catégories de divergence. À moins de dupliquer toutes les entrées liées à des anomalies, pour avoir pour chacune : 'vérifié depuis ma chaise' et 'vérifié sur le terrain'. Mais faut-il en arriver là ? Vos avis bienvenus. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
