Re: [OSM-talk-fr] Mise à jour de POLE EMPLOI
bonjour, > De: "Discussions sur OSM en français" > Envoyé: Jeudi 15 Février 2024 13:04:03 > Objet: Re: [OSM-talk-fr] Mise à jour de POLE EMPLOI > Le 14.02.24 à 15:55, Bruno Remy via Talk-fr a écrit : >> je ne vois toujours pas comment techniquement faire ce remplacement >> automatisé? > > overpass turbo pour récupérer tous les objets pole emploi > export vers josm > sélection de tous les noms pole emploi > vérifier que tu n'as pas des choses tordues (ex un arret de bus) > remplacer le nom > envoyer en n'oubliant pas les tags de changeset vers ta page wiki de > l'opération Juste pour rappeler, comme l'a fait Vincent Bergeot avant moi, que cette discussion a démarré le 16 janvier sur le forum [1], y est toujours active et mobilise pas mal d'intervenants. Pour la recherche de consensus, merci de considérer les questions soulevées là bas avant de procéder à un quelconque changement massif. merci vincent [2] : https://forum.openstreetmap.fr/t/de-pole-emploi-a-france-travail/20397 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO
Le 8 février 2024 08:05:34 GMT+01:00, Bruno Remy via Talk-fr a écrit : >.A quelle fréquence est rafraichie la BANO? Pour avoir un aperçu immédiat de tes modifs tu peux rafraichir la partie L'Hay les Roses de BANO via la page Pifometre de la commune (bouton bleu en haut à droite): https://bano.openstreetmap.fr/pifometre/index.html?insee=94038 Pour l'instant tu as 2 lignes pour Gabriel Peri, il devrait n'en rester qu'une après ta modif. Pour une prise d'effet dans les fichiers CSV c'est fait chaque nuit. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rivoli / fantoir
> De: "didier2020" > Envoyé: Samedi 27 Janvier 2024 10:36:12 > Objet: [OSM-talk-fr] rivoli / fantoir > afin de correspondre au nouveau format (lettre optionnelle a la fin) > j'ai corrigé la regle josm mapcss sur > https://josm.openstreetmap.de/wiki/Rules/FranceSpecificRules > > et ajouté des "osmoseAssertNoMatchWithContext" pour la cohérence > d'analyse pour osmose Merci (tardif) Didier pour avoir fait ces modifs ! vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO
Bonjour, > De: "Discussions sur OSM en français" > Cc: "Bruno Remy" > Envoyé: Mercredi 7 Février 2024 15:20:00 > Objet: [OSM-talk-fr] BANO > Bonjour, > En faisant du geocaching je me suis aperçu que dans la commune de > l'Hay-Les-Roses (94) il y a une erreur dans la BANO v2: sur cette commune il y > a l'Avenue Gabriel-Péri mais il n'y a plus la Rue Gabriel-Péri, qui pourtant > est sur openstreetmap et surtout est bien affichée avec les bonnes pancartes > dans la rue. > Comment signaler des erreurs dans la BANO v2? > source : https://bano.openstreetmap.fr/data/bano-94.csv L'erreur que tu vois dans BANO reflète les bizarreries qu'on a dans OSM. Si tu regardes la relation associatedStreet de cette voie [1] tu peux constater que pour les membres avec un rôle 'street' on a des "Rue Gabriel Péri" [2] et des "Avenue Gabriel-Péri" [3]. Au moment de constituer la BANO un des 2 noms est choisi, arbitrairement. Pour corriger BANO il suffit de mettre au carré OSM en uniformisant les noms des membres de la relation. A noter, un fil sur ce sujet ouvert sur le forum cette semaine [4] merci vincent [1] : https://www.openstreetmap.org/relation/9653023/history/11 [2] : https://www.openstreetmap.org/way/155422648 [3] : https://www.openstreetmap.org/way/39041589 [4] : https://forum.openstreetmap.fr/t/voie-nommee-avenue-au-lieu-de-rue-a-94-lhay-les-roses/20900/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Où consulter le rendu "fr" ?
Bonjour > De: "Arnaud Champollion" > > Existe-t-il une instance de consultation "grand public" du rendu "Fr" ? Tu as une visu du rendu Fr sur le Geoportail : https://www.geoportail.gouv.fr/carte?c=6.2472309,44.0882860001=11=OPEN_STREET_MAP::GEOPORTAIL:OGC:WMTS(1)=yes vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Une carte pour Pifomètre
Bonjour, J'ai mis en ligne il y a quelques jours une version cartographique de Pifomètre, afin d'accéder autrement à l'analyse des voies et adresses manquantes dans OSM en vue de leur intégration. J'en ai parlé sur le forum : https://forum.openstreetmap.fr/t/pifometre-a-sa-carte-pifomap/18040 et le service se consulte à : https://bano.openstreetmap.fr/pifometre/pifomap.html Pour démarrer, entrer un code INSEE de commune en haut à gauche ou bien baladez vous sur la carte jusqu'à voir le nom de la commune que vous voulez analyser, puis cliquez dessus. Vous reconnaîtrez le code couleur rouge du rendu BANO, sans lequel on ne dégommerait rien. Pour les autres couleurs, une légende (en haut à droite) vous donnera quelques billes. merci vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Données Overture Maps - export OSM normalisé
Bonjour, > De: "Cyrille37 OSM" > > Il me semble que quelques coder français (@panierAvide ? @cquest ? @vdct > ? ...) ont fait une telle proposition il y a qlqs années, un export osm > simplifié et normalisé. Il peut s'agir de ça : https://forum.openstreetmap.fr/t/publier-des-donnees-osm-augmentees/9043 vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pifométrage en Normandie....
Bonjour > De: "Christian Perrier" > À: "Discussions sur OSM en français" > Envoyé: Lundi 7 Août 2023 11:57:07 > Objet: Re: [OSM-talk-fr] Pifométrage en Normandie > Le lun. 7 août 2023 à 10:33, leni a écrit : > > > >> Je pense que celà n'est pas dû à ton incompréhension, mais que c'est un >> problème dû aux regroupements de communes : >> >> Quand je vais dans Pifomètre V3 avec le code insee que tu donnes >> "27676", j'arrive sur la commune "Venables" >> >> > Merci de ton analyse : effectivement, je soupçonnais assez fort qu'il y ait > une conséquence liée au regroupement de communes. Le fait d'arriver sur > Venables lorsqu'on donne le code INSEE de la nouvelle commune m'avait mis > la puce à l'oreille et j'imaginais assez bien que ce sac de noeuds vienne > de là. En effet il y avait 2 micmacs qui n'aidaient pas. D'abord le polygone administratif de la commune "Les Trois Lacs", qui avait un code INSEE périmé dans OSM (27058 au lieu de 27676) ce qui perdait BANO J'ai corrigé ce point via https://www.openstreetmap.org/changeset/139554469 mais ensuite restait un souci dans BANO, où la mise à jour de cette modif était débranchée et n'avait donc aucune chance d'être prise en compte. J'ai fixé ce point et la page des Trois Lacs semble avoir meilleure allure maintenant, j'y vois par exemple ta rue comme rapprochée : https://bano.openstreetmap.fr/pifometre_v3/index.html#insee=27676 Je te laisse vérifier. @deuzeffe : les modifs en questions m'ont l'air de corriger le JOSM 404 que tu rencontres aussi, à vérifier itou merci vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Visio Pifomètre
Bonjour, > De: "osm vdct" > Envoyé: Dimanche 16 Juillet 2023 12:28:38 > Je propose une visio autour de Pifomètre cette semaine. À quoi ça sert, > comment > ça marche, etc. Ce sera l'occasion de triturer ensemble tous vos cas bizarres > d'adresses. Rendez-vous demain (mardi) soir à 21h dans ce salon : https://osmvideo.cloud68.co/user/vin-wmv-quf-b8g merci vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Visio Pifomètre
Bonjour Je propose une visio autour de Pifomètre cette semaine. À quoi ça sert, comment ça marche, etc. Ce sera l'occasion de triturer ensemble tous vos cas bizarres d'adresses. Ce sera à 21h mais le jour dans la semaine n'est pas encore fixé, un sondage est ouvert dans ce but : https://forum.openstreetmap.fr/t/visio-pifometre/16154 Merci vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pifomètre v3 arrive...
Bonjour, > De: "Discussions sur OSM en français" > Cc: "Bruno Remy" > Envoyé: Mercredi 12 Juillet 2023 10:11:59 > Bonjour, > Depuis hier soir Pifomètre V3 ne répond plus. Au départ je gardais l'interface > grâce au cache mais plus aucune donnée ne se chargeait dans JOSM.Maintenant > l'URL renvoie l'erreur suivante : > 502 Bad Gateway > Quelqu'un a des infos sur l'hébergement de pifomètre? Une maintenance semble > nécessaire.. Problème évoqué aussi ici : https://forum.openstreetmap.fr/t/pifometre-plus-accessible/16091 Je constate la même chose que toi mais sans pouvoir agir avant ce soir, je n'aurai pas accès au serveur avant, désolé. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Pifomètre v3 arrive...
Bonsoir, Lors du SOTM ce WE j'ai présenté une nouvelle version de Pifomètre & de BANO, encore en développement mais avec une partie Pifomètre déjà fonctionnelle et utilisable à cette adresse : https://bano.openstreetmap.fr/pifometre_v3/ Pour plus de détails je vous renvoie à ce post https://forum.openstreetmap.fr/t/pifometre-v3-arrive/15455 qui synthétise les principales nouveautés. Questions, critiques et retours d'expérience bienvenus ici comme là-bas. merci vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [import] import partiel des adresses en France
Le 25/04/2023 à 21:10, Marc_marc a écrit : Bonjour, Le 25.04.23 à 14:46, Vincent de Château-Thierry a écrit : La certification n'est hélas en aucun cas un critère de qualité. bien noté, je pensais que c'était quand même une indication que quelqu'un avait revu ces données et que donc, en moyenne, c'était mieux des adresses certifiés que non certifiée (qui peuvent avoir des années sans revue humaine). pq on a cette info dans le pifomètre si tu estimes que cela n'a aucun impact ? Tu inverses cause et conséquence... L'info a été demandée pour Pifomètre, je l'y ai mise. Une fois disponible, elle a permis à des contributeurs de se concentrer sur les adresses certifiées, pour finalement constater que la qualité n'était pas au rendez-vous, en tout cas pas de manière constante. Dire ça c'est donc assumer qu'on n'ajoute pas de valeur à l'import la valeur ajoutée de l'import est de transformer des données opendata existante en donnée utilisable dans tous les outils osm, tout en se gardant la possibilité de détecter les données venant de l'opendata de celle ayant été améliorée dans osm Dis comme ça je n'y vois aucun intérêt, ça donne juste à OSM le rôle d'un grand réservoir dans lequel on déverse de la donnée. L'intérêt avec OSM ça n'est pas de juste faire une compilation (j'allais dire une accumulation) de données, c'est d'harmoniser toutes ces données pour constituer un jeu cohérent. Le passage d'une compilation à un jeu de données cohérent se fait par les différents ajouts de valeur que nous apportons dans nos contributions. - garantir la bonne orthographe des noms de voies (dans la BAN c'est un poème, défauts d'accents, défauts de majuscules, etc) à partir du moment oü on n'importe que les no sur des rues rapprochées, comment pourrait-il y avoir une erreur d'accent/majuscule du à l'import? c'est le rapprochement de la route qui traite cela (et raison pour laquelle c'est proposé de ne pas traiter les routes non rapprochée) Ok donc tu voudrais partir de BANO et non de la BAN - assigner à chaque adresse une position cohérente Quel est la position cohérente quand il n'y a pas de concensus ? l'un positionera à l'endroit de la plaque "officielle" l'autre en limite (parfois suposée) de propriété public/privé le 3ieme la mettre à l'entrée correspondante et surtout le 4ieme ferra un import sans en parler à personne et les mettra là oü le dit l'opendata sans aucun moyen de les retrouver, cfr le contributeur qui a importé à ce jour 1.6 millions d'adresses par 10k, brut de décoffrage, majuscule et toute erreur compris, y compris celle renseignée dans bano ou y compris des addr:street ne correspondant pas à la voie [1] Et donc parce qu'un contributeur a fait n'importe quoi, cela justifierait qu'on ne se pose pas de questions et qu'on garde tel quelle la position de chaque adresse prise dans la BAN à l'avenir ? Le fait est que certaines positions d'adresse sont totalement farfelues (certifiées ou non). - filtrer les données sources : ne pas ajouter dans OSM des numéros assignés à une autre voie et totalement erronés dans leur affectation et leur position, sans parler des 5xxx et 9xxx n'est-ce pas déjà ce que fais le pifomètre ? si oui en quoi prendre importer depuis le pifomètre provoquerait-il une moins bonne qualité que intégrer depuis le pifomètre ? Ce qui compte ici ce n'est pas l'outil (Pifomètre ne sert pas pour de l'import massif) mais le contenu, donc BANO si une rue est rapprochée, la seule chose à faire en intégration est d'éventuelement regarder si les adresses pair/impair sont de chaque côté de la rue et en ordre croissant, chose tout a fait possible aussi en chargeant une donnée depuis osm qui aurait le created_by=Import* non ? C'est réducteur, le schéma pair/impair est loin d'être le seul. Si tu t'attends à juste vérifier la parité, tu vas déchanter avec les numérotations continues, métriques, anarchiques... qui se base sur... 3 réponses j'en compte 17 dans ma boite mais 3 ou 17 n'est pas important, je ne fais que des opérations de masse consensuelles donc soit la discussion permet d'aboutir à un consensus sur un import (éventuellement encore plus) limité soit je ne le ferrai pas... et d'autres continueront à importer sous le radar avec une qualité bien moindre que ce que je pense possible avec un import ciblé... et l'impossibilité de retrouver ces objets pour celui qui souhaiterai faire des opérations supplémentaire. A te lire c'est "moi ou le chaos"... C'est moins manichéen dès qu'on considère aussi tous les contributeurs qui font de l'intégration d'adresses (et non de l'import), à leur rythme et avec le souci de bien faire. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [import] import partiel des adresses en France
Bonjour, > De: "Marc_marc" > > Suite à l'accueil favorable sur le principe, je poursuis > la discussion entamé [2] il y a quelques mois lié à la procédure > https://wiki.openstreetmap.org/wiki/FR:Import/Guidelines > je propose de diviser l'import en plusieurs tranches > et de discuter uniquement de la première tranche : > > Étendue de l'import de la première tranche > - le nom de la rue est présente dans osm, identique à celui > de la BAL ou la ref fantoir permet de lier le nom osm au nom officiel > tel que visible avec la colonne "adresse BAN avec voie rapprochée %" > sur le pifomètre [1] > - le taux de certification de 100% tel que visible avec la colonne "% > adresses certifiées BAN" sur le pifomètre [1] > - j'avais proposé "la rue dans osm ne contient aucune addr" : certains > ont suggéré de commencer avec ce critère sur l'étendue de la commune. > le pifomètre [1] renseigne en effet des communes avec 0 adresse dans osm > > A voir s'il y a beaucoup de communes avec 100% adresses certifiées + > 100% voies adressée rapprochée + pas d'adresse dans osm :) > mais c'est une première tranche > > Questions : > > - faut-il ajouter des critères de qualité ? par ex dans le passé, > ce n'était pas rare d'avoir plusieurs adresses au même endroit. > il n'y a pas eu de retour sur ce point que je propose de supprimer > sauf si quelqu'un souhaite le conserver. > J'espère que ce problème a disparu avec la certification > mais un retour est bienvenu si ce n'est pas le cas. La certification n'est hélas en aucun cas un critère de qualité. Il y a eu différents retours d'expérience là-dessus, notamment sur le canal OSM-Fr matrix/telegram et aussi sur le forum où ce post couvre le même sujet [1]. En version courte : la certification est auto-déclarative et l'aspect géométrique est loin d'être au cœur des préoccupations des communes, plus focalisées sur l'inventaire. Donc partir sur ce critère comme un filtre d'adresses fiables et sujettes à import est biaisé dès le départ : on se trompe de postulat. > - la position des addr est souvent flottante tandis que d'autres > voudraient les voir au moins en bordure du bâtiments concernées. > Il avait été proposé de sortir cette question hors de l'import > et d'importer avec la position actuelle de l'opendata Dire ça c'est donc assumer qu'on n'ajoute pas de valeur à l'import, on photocopie l'OpenData de la BAN. C'est vraiment regrettable je trouve. Parmi nos valeurs ajoutées sur le sujet des adresses par rapport à la BAN il y a : - garantir la bonne orthographe des noms de voies (dans la BAN c'est un poème, défauts d'accents, défauts de majuscules, etc) - assigner à chaque adresse une position cohérente avec notre propre graphe et nos bâtiments, donc potentiellement retoucher les coordonnées (manuellement, car non il n'y a aucune magie pour ce genre d'opération) - filtrer les données sources : ne pas ajouter dans OSM des numéros assignés à une autre voie et totalement erronés dans leur affectation et leur position, sans parler des 5xxx et 9xxx Donc je tempère l'accueil favorable dont tu parles au début, et qui se base sur... 3 réponses. Personnellement je ne suis pas favorable à un tel import, mais ça ne devrait pas étonner par ici : si j'ai conçu Pifomètre c'est justement pour ne pas encourager les imports, tout en proposant un outil pour mécaniser le travail d'intégration sans verser dans l'ingestion aveugle d'open data. On peut largement faire évoluer Pifomètre pour changer d'échelle (la commune au lieu de la rue, etc) mais en aucun cas ça ne nous dispensera de contrôler finement ce qu'on fait, en s'interdisant les uploads aveugles par un bot. Parlons *d'intégration* massive dans ce cas, ou tout autre terme non ambigu, mais tant que le sujet sera un *import* avec tes postulats actuels, je n'y souscrirai pas. merci vincent [1] : https://forum.openstreetmap.fr/t/a-quand-des-imports-automatiques-des-bal/9012 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import d'adresses à Andernos (relation associated-street)
Bonjour, > De: "Cyrille37 OSM" > J'utilise le plugin "cadastre" de JOSM qui gère très bien les relations > associated-street. > > On sélectionne l'outil dans la barre ce qui ouvre une petite fenêtre > pour paramètrer la numérotation. On clique sur un way ce qui commence > (ou réutilise) une relation associated-street, puis on clique sur les > emplacements pour créer les housenumber. > > La doc : > https://wiki.openstreetmap.org/wiki/FR:JOSM/Greffons/Cadastre-fr#Utilitaire_de_saisie_des_adresses > On 25/04/2023 11:21, Bruno Remy via Talk-fr wrote: >> Bonjour, >> Je lis que vous suggérez d'utiliser la relation associated-street.Je suis >> plus >> partisan du tag addr:street. >> Rajouter une relation à chaque noeud nécessite une opération manuelle sur >> chaque >> noeud, ce qui est laborieux quand on travaille sur un ensemble de noeuds par >> exemple à l'échelle d'une ville. Je me vois mal créer des centaines de >> relations une par une à la main... >> En manipulant les données d'un fichier JSON ou CSV on peut plus facilement >> attribuer au noeud le tag addr:street correspondant au nom de la rue présent >> dans le fichier source de BANO. >> Vous voyez ce que je veux dire? >> Je cherche une solution qui associe l'intégrité des données (donc le numéro >> et >> le nom de la rue je suis d'accord avec vous) et la simplicité de manipulation >> des données. Bienvenue Bruno Pour ajouter des adresses j'ai conçu l'outil "Pifomètre" dont un des buts est d'éviter les nombreuses opérations manuelles et clics que peut générer la saisie des adresses. Pifomètre est organisé par commune. Pour Andernos voici le lien : https://bano.openstreetmap.fr/pifometre/index.html#insee=33005=0 Pour une présentation des fonctionnalités il existe entre autres cette description : https://wiki.openstreetmap.org/wiki/Contribuer_%C3%A0_la_BANO#Interface_de_contr%C3%B4le_et_de_saisie_Fantoir/OSM et cette video de présentation : https://peertube.openstreetmap.fr/w/viNLdwLGw3AMdcUT1V8ba2 merci vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Le forum et la liste
Bonjour, - Mail transféré - > De: "Marc_marc" > À: "Discussions sur OSM en français" > Envoyé: Lundi 17 Avril 2023 12:54:43 > Objet: Re: [OSM-talk-fr] traduction de "tag" en français dans JOSM > Marc qui a voté sur le forum https://localhost, ben quoi > faut fragmenter... Je rebondis sur cette remarque (pique ?) de Marc au sujet du forum et de la fragmentation, pour donner quelques éléments factuels sur le forum https://forum.openstreetmap.fr/ En 1 année glissante (20 avril 2022 -> 20 avril 2023) le forum a vu : - la création de 4400 sujets, soit environ 12/jour - l'arrivée de 600 nouveaux inscrits (pour un total de 3000, soit 4x plus que la liste talk-fr) - la publication de 11000 posts soit environ 30/jour Sur la même période on compte 1062 messages sur cette liste, à peine 3/jour. Évidemment chacune, chacun a ses habitudes de lecture, ses préférences en termes d'ergonomie, et je ne suis pas là pour en juger. Mais poster sur le forum, en 2023, n'est pas fragmenter, au contraire : c'est aller à la rencontre du plus grand nombre, se donner le plus de chances de recevoir avis, arguments, conseils. Voilà, sans polémique, mais pour mettre un peu à jour le paysage de nos canaux de communication, notamment pour celles et ceux qui ne consultent que la liste. merci vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Hack Week-end parisien les 13 & 14 mai
Bonsoir, (presque) tout est dans le titre. Un peu de détail ici : https://forum.openstreetmap.fr/t/save-the-date-hack-week-end-les-13-14-mai-a-paris/14070 et pour la logistique c'est sur le wiki : https://wiki.openstreetmap.org/wiki/Paris_Hack_Weekend_May_2023 On vos espère nombreuses et nombreux dans un mois à Nanterre :) Christian & vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pifomètre la même route arrive différemment via FANTOIR et via la BAN
Bonjour, > De: "leni" > dans Pifomètre le rapprochement se fait bien, mais je me retrouve avec > deux lignes et les adresses sont signalées comme manquantes alors > qu'elles sont sur la voie rapprochée. Oui il y a 2 lignes distinctes car la ligne avec le nom issu de la BAN et dépourvu de code FANTOIR ne peut pas être rapproché : divergence d'orthographe avec FANTOIR et absence de code. > > Vu que FANTOIR va être supprimé, je pense qu'il vaut mieux que j'enlève > la ref:FR:FANTOIR, le rapprochement ne se fera plus, il se fera avec la > BAN qui a le bon nom Attention, le fichier FANTOIR va disparaître mais les codes qu'on appelle par facilité "codes FANTOIR" restent, ils seront maintenant diffusés via un autre fichier appelé "TOPO". Donc la présence de ces codes dans OSM n'est pas remise en cause, ils continueront de nous aider à identifier les voies manquantes comme depuis le début de BANO. Je ne vois donc pas de souci à ce que tu laisses le code dans le cas présent. Sur un autre aspect, je vois que les adresses que tu as ajoutées sont à la fois dans une relation associatedStreet et renseignées chacune avec le tag addr:street. Ca créé une redondance inutile, tu peux soit enlever le tag addr:street sur chaque point d'adresse soit supprimer la relation. merci vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Dernier FANTOIR et conséquences
Bonjour, J'ai ouvert sur le forum une discussion autour du fichier FANTOIR et de sa fin programmée, qui a pour le contenu OSM et les outils (Osmose, Pifomètre) quelques conséquences : https://forum.openstreetmap.fr/t/dernier-fantoir-et-consequences/12795 N'hésitez pas à venir contribuer à la discussion (ou à la continuer ici pour celles / ceux que le forum rebute). Merci vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] adresse - numéros en double entre Chanceaux-sur-Choisille et Notre-Dame-D'Oé (Indre-et-Loire)
Bonjour, > De: "Cyrille37 OSM" > > La Rue de Bretagne est à cheval en les communes de > Chanceaux-sur-Choisille et Notre-Dame-D'Oé et étrangement de chaque côté > de la rue on retrouve les mêmes numéros: les 2, 4 et 6. Du coup Josm > n'est pas content et il ne doit pas être le seul. > > J'ai forcé l'envoi des données malgré l'erreur de validation. > > Existe-t-il une façon de taguer correctement ce cas atypique ? Si la rue est à cheval sur les 2 communes tu devrais composer une relation associatedStreet par commune. On y trouverait à chaque fois le filaire de voie, mais pour les numéros, chaque relation n'incluerait que ceux de sa commune. Par suite, plus de souci de validation ni de modélisation. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pifometre : voie présente dans la BAN et dans OSM, dans onglet "Dans OSM et inconnu de FANTOIR"
Bonjour, Le 26/01/2023 à 18:59, leni a écrit : Si je ne me trompe pas : * l'Impasse des Prunus (https://www.openstreetmap.org/way/28236540) est dans le fichier de la BAN (https://adresse.data.gouv.fr/data/ban/adresses/latest/csv-bal/ adresses-34.csv.gz) * Elle se retrouve dans l'onglet "Dans OSM et inconnu de FANTOIR" https://bano.openstreetmap.fr/pifometre/index.html#insee=34129=6 alors que je pensais la trouver dans l'onglet https://bano.openstreetmap.fr/pifometre/index.html#insee=34129=1 avec la mention "Voie sans FANTOIR" Est-ce dû au fait que les 4 adresses sont validées mais qu'il y en a des "non validées" pour les mêmes maisons, qui semblent correspondent aux adresses anciennement rattachées (dans le cadastre) à la "rue des Prunus" ? La BAN fournit un identifiant FANTOIR pour certaines voies (pas toutes). Un des critères pour identifier les "Voie sans FANTOIR" c'est de ne pas avoir d'identifiant FANTOIR issu de la BAN. Or dans le cas de l'impasse des Prunus on a bien un identifiant fourni, qui correspond au code FANTOIR erroné que tu as supprimé. Donc cette vois passe au travers et se retrouve juste "connue d'OSM et pas de FANTOIR". Pas grand chose à faire ici côté Pifomètre, je vois que tu as créé les adresses de l'impasse dans OSM et c'est bien l'essentiel. merci vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] codes FANTOIR portés par des nodes & ways OSM et inconnus de la source FANTOIR
Bonjour, Le 24/12/2022 à 06:37, Philippe Verdy a écrit : Autoriser un ";" peut être permis sur les noeuds (par exemple les points d'adresse qui normalement seraient situés à cheval sur 2 communes, ou géométriquement dans le territoire d'une seule car la frontière ne passe pas physiquement par ce point sité un peu à côté alors que c'est le point d'accès principal vers la propriété sur l'autre commune), mais sur les ways c'est un peu un non-sens: les ways ont une orientation, et un côté ":left" et ":right" qui permettent de lever l'ambiguité Les codes multiples peuvent arriver sur un noeud comme sur un way lorsque il existe plusieurs codes FANTOIR pour un même nom (de voie, de lieu-dit) dans une commune, associables à une même entité. Cas extrême : 30 codes différents pour la "FORET DE LANVAUX COUPE N 1" à Brandivy (56022) [1] Cas plus banal : 2 codes pour le Square Jean Moulin à Cugnaux (31157) [2] Sur la France on compte plus de 22000 cas de codes multiples, pour un même nom, dans une même commune, sans qu'un des codes soit annulé. Mais dans le lot il y beaucoup de codes pour des entités bien distinctes, dans des communes issues de fusion. Si chacune avait sa "Rue de l'Eglise" ou sa "Place de la Mairie" avant fusion, on a techniquement des doublons, mais qui ne sont pas voués à se retrouver sur un même objet OSM. vincent [1] : https://bano.openstreetmap.fr/pifometre/liste_brute_fantoir.html#insee=56022 [2] : https://bano.openstreetmap.fr/pifometre/liste_brute_fantoir.html#insee=31157 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Overture Maps
Bonsoir, je reposte ici un message déjà mis sur le forum[1], au cas où. Le lancement d’Overture Maps, annoncé cette semaine, fait beaucoup parler tellement les implications côté OSM sont (possiblement) nombreuses. Je vous propose qu’on se retrouve jeudi prochain 22/12 à 21h en visio histoire d’aborder le sujet, en essayant de décanter un peu ce que chacun(e) comprend de ce qui est annoncé, et aussi en s’essayant un peu à imaginer l’avenir. C’est absolument ouvert à tout le monde, j’ai ouvert ce salon BBB pour l’occasion : https://osmvideo.cloud68.co/user/vin-rol-wgn-nex merci vincent [1] : https://forum.openstreetmap.fr/t/overture-maps-parlons-en/11616 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] codes FANTOIR portés par des nodes & ways OSM et inconnus de la source FANTOIR
Bonjour, > De: "leni" > > Dans cet onglet, j'ai corrigé les codes qui étaient uniques. > > Maintenant, je regarde les codes qui sont séparés par un ";" ce qui est > autorisé par > https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR#Cas_particuliers > > Avant de me lancer, j'ai pris un premier enregistrement ; les deux codes > existent séparément : Pour trouver si le code est inconnu de la source > Pifometre prend chaque code ou l'ensemble ? Pifomètre considère le contenu du tag ref:FR:FANTOIR comme un seul code FANTOIR, donc en effet dans le cas de codes listés avec un ';' comme séparateur ça remonte en erreur. J'ai ouvert un ticket pour améliorer ça : https://github.com/osm-fr/osm-vs-fantoir/issues/203 vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pifomètre : voie présente dans deux onglets avec/sans adresse puis sans/avec rapprochement
Bonjour Le 21/10/2022 à 18:26, leni a écrit : à Monbrun (32262) https://bano.openstreetmap.fr/pifometre/index.html#insee=32262=0 il y a des voies présentes dans FANTOIR/BAN/OSM Elles se retrouvent 2 fois dans Pifomètre (avec et sans adresses) - (sans et avec rapprochement) Par exemple : "Rue de la Régie" https://www.openstreetmap.org/way/62819082 Voies avec adresse(s) numérotée(s) xx voies FANTOIR sans rapprochement OSM 322620020D 2012-10-29 RUE DE LA REGIE rue de la régie. 12 Points Relation Anomalies Voies sans adresse(s) numérotée(s) x voies FANTOIR avec rapprochement OSM 322620020D 2012-10-29 RUE DE LA REGIE Rue de la Régie Il me semble qu'elle devrait être dans Voies avec adresse(s) numérotée(s) voies FANTOIR avec rapprochement OSM Oui elles devraient, mais ça coince à cause du caractère de fin de nom dans le nom BAN : un point ! Il y a plusieurs noms de voies de Montbrun qui se terminent par un point, et il suffit à mettre le bazar, car il empêche le rapprochement avec le nom OSM. Pour les rapprochements on traite une série de caractères parasites à nettoyer (parenthèses, deux points, slash, etc) mais le point ne faisait pas partie du lot jusque là. Il restait donc jusqu'à l'étape de comparaison BAN <> OSM, et suffisait à considérer que les 2 noms sont différents. C'est corrigé à l'instant [1] Y a-t-il une adresse spécifique pour les signalements ? ou si je trouve autre chose, je continue sur la liste ? Un endroit pratique est le repo Github du projet où tu peux ouvrir des tickets : https://github.com/osm-fr/bano/issues/new vincent [1] : https://github.com/osm-fr/bano/pull/298 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] codes FANTOIR erronés non trouvé
Bonjour, > De: "leni" > La liste est un peu remontée 212 et il me semble qu'il y a encore des > "codes FANTOIR imaginaires" mais avec des minuscules, par exemple : > > 31084b8bbb Impasse des Calaouères et du Pré Commun Les b minuscule sont une marque de reconnaissance des pseudo-fantoir. Il y a un loupé dans le processus pour qu'il en apparaisse entre hier et aujourd'hui. Va falloir y re-regarder merci pour le signalement (bis ! :) ) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] codes FANTOIR erronés non trouvé
Le 19/10/2022 à 19:16, leni a écrit : Le 19/10/2022 à 18:52, Vincent de Château-Thierry a écrit : un manque à combler (ce soir si j'ai le temps). En ce qui me concerne, il n'y a pas d'urgence, je sais que pour le moment, il ne faut pas que je les cherche. Voilà c'est rétabli, la liste a fondu mais on compte quand même 160 lignes avec de *vrais* codes faux ;) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] codes FANTOIR erronés non trouvé
Bonjour, > De: "leni" > > Dans la page "codes FANTOIR erronés" j'ai recherché : > 09140B3BBB Chemin de la Pujadeille > > J'ai recherché ce code Fantoir dans OSM et je n'ai pas su le trouver !!! Il devrait être dans une page dédiée "codes FANTOIR imaginaires" :) Il s'agit d'un pseudo code Fantoir fabriqué pour intégrer les données BAN quand justement FANTOIR manque sur les voies correspondantes. Tu vois ce code dans la page "Fantoirs erronés" tout simplement parce que je n'ai pas fini le boulot de *ne pas* propager ces codes : je l'ai fait pour Pifomètre, les listings Fantoir et le top des adresses, mais je n'ai pas vérifié pour les Fantoirs erronés. Bref, un manque à combler (ce soir si j'ai le temps). merci pour la remontée vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Voies connues de la BAN pb avec télécommande
> De: "leni" > Après avoir choisi Relation, Josm m’avertit qu'il reçoit des données, mais pas > de téléchargement des données ni d'affichage de calque : > Voici les infos : > 2022-09-27 15:07:28.980 INFOS: RemoteControl received: GET > /import?new_layer=true_name=Chemin%20de%20Lembessin=https://bano.openstreetmap.fr/pifometre/requete_numeros.py?insee=32012=32012b13bb=Relation > HTTP/1.1 2022-09-27 15:07:29.660 INFOS: GET > https://bano.openstreetmap.fr/pifometre/requete_numeros.py?insee=32012=32012b13bb=Relation > -> HTTP/1.1 200 (637 ms; 1,42 kB) 2022-09-27 15:07:29.660 INFOS: > L?élément 'body' trouvé dans le flux d?entrée n?est pas défini. Abandon. > 2022-09-27 15:11:28.827 INFOS: GET > https://api.openstreetmap.org/api/0.6/user/details (obtient le nombre > des messages non lus) -> HTTP/1.1 200 (513 ms; 751 B) La requête que tu montres n'a pas le bon nombre de paramètres, c'est le signe que ta page n'est pas à jour. Il faudrait la rafraichir avec un Ctrl+F5 > alors qu'avec point c'est ok : Oui la partie "points" n'est pas affectée par les pseudo-FANTOIR. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Voies connues de la BAN pb avec télécommande
> De: "osm vdct" > Le 25 septembre 2022 19:29:12 GMT+02:00, leni a écrit > : > >>J'ai un problème, mais est-ce dû à ma configuration ? > > Non du tout. J'ai passé pas mal de temps à reconfigurer l'onglet Pifomètre > suite > aux nouveautés dont je parlais ce matin, et j'ai tout simplement *oublié* de > gérer les conséque'ces sur les autres onglets /o\ :) C'est maintenant réglé, l'onglet "Top adresses manquantes" devrait fonctionner y compris avec le mode Relation. merci vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : rapprochements sans code FANTOIR
Bonjour, > De: "leni" > J'ai fait l'option pour le rapprochement : > - la Voie sans FANTOIR a disparu > > - la Voie FANTOIR a été rapprochée de la voie OSM par contre, elle ne > voit pas que les points adresse existent Il y avait un mic-mac toute la matinée, peut-être la cause de cet affichage. J'ai forcé le rapprochement et les adresses ne sont plus proposés. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : rapprochements sans code FANTOIR
Le 26/09/2022 à 19:32, leni a écrit : https://bano.openstreetmap.fr/pifometre/index.html#insee=32087=0 une Voie sans FANTOIR "chemin de genboy" avec deux points adresse qui correspond à la voie avec FANTOIR (onglet 2) CHEM DE JENBOY (les 2 mêmes points adresse, précédents, sont dans le cadastre et il y a un GENBOY qui traîne sur le plan cadastral) si je met dans osm "Chemin de Genboy" avec ref:FR:FANTOIR le rapprochement va se faire avec l'onglet 2, mais pas avec l'onglet 0 ? il faudra lui ajouter "voie doublon avec orthographe différente" ? Si tu combines l'orthographe de la BAN (avec un G plutôt qu'un J) et un ref:FR:FANTOIR, ça devrait tout réconcilier, le contenu OSM faisant le lien aussi bien avec FANTOIR qu'avec la BAN. Je dis ça mais je n'ai pas essayé, je te laisse la primeur :) Tu peux aussi qualifier la voie avec une erreur ou divergence d'orthographe, mais ça n'influence pas le rapprochement. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : rapprochements sans code FANTOIR
Bonjour, > De: "deuzeffe" > Question bête : si par miracle, les voies hors FANTOIR apparaissent > soudainement dans le fichier FANTOIR/TOPO à venir (on peut rêver et > croire au PN), comment va réagir pifomètre ? Un gros rhume ? (pardon) Le fichier évolue chaque trimestre (comme tu sais ;) ) et donc la situation que tu décris est bien réelle. En l'état, le vrai déclencheur de la disparition du code pseudo-FANTOIR c'est l'apparition du vrai code conjointement dans FANTOIR et la BAN. Il faudrait un peu de boulot additionnel pour que le pseudo disparaisse rien qu'avec la publication du vrai dans FANTOIR. > Les LD se reconnaissent facilement dans l'onglet 0 -> je ne les traite > pas. En revanche, si tu peux arriver à faire qq chose (si ce n'est pas > déjà en train) pour nettoyer l'onglet 6 des voies sans FANTOIR une fois > qu'elles sont rapprochées, ça serait bien... On peut déjà intégrer les adresses des lieux-dits en cliquant sur le format 'n Points' et en remplaçant le tag addr:street par un tag addr:place. Mais comme Pifomètre ne gère pas encore addr:place, les adresses en question continueront d'être proposées à l'intégration. Vraiment pas top. Ca sera géré dans BANO v3 qui est en cours de dev. Les noms dans l'onglet 6 disparaissent (normalement) au rythme où apparaissent des adresses dans OSM associées au nom de voie. >> Côté exports BANO, il y a aura à coup sûr des doublons liés à des >> divergences d'orthographe, mais je n'ai pas terminé l'analyse. Si vous >> voyez des cas de doublon dans Pifomètre, je suis preneur. > > J'ai (c'est un peu le bazar dans osm :/) ! > https://bano.openstreetmap.fr/pifometre/index.html#insee=87041=0 > - divergence d'orthographe : > -- Voie sans FANTOIR RUE ADJ GAL DESVERINES rue de l'adj général > desverines onglet 0 > -- 870410015E 2018-03-26 RUE DE L'ADJ GAL DEVERINE Rue du Général > Déverrine onglet 1 > > C'est moi où tu as "reverse"renommé les voies de la BAN dans le style > des libellés FANTOIR ? Oui les noms BAN dans leur version pseudo-FANTOIR essaient au mieux de ressembler aux noms FANTOIR. Au moment de leur chercher un nom correspondant dans OSM, le même traitement est fait pour les noms OSM. La plupart du temps, ça converge. Mais juste la plupart du temps, pas tout le temps :) Ton exemple est typique : deSverineS dans la BAN, deverine dans FANTOIR, deverRine dans OSM. Pur bazar. Le tag ref:FR:FANTOIR permet de faire le lien OSM <-> FANTOIR pour compenser ces divergences, mais on n'a aucun mécanisme pour l'équivalent entre BAN et OSM ou BAN et FANTOIR. C'est un peu la limite de l'exercice pour l'instant. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Voies connues de la BAN pb avec télécommande
Le 25 septembre 2022 19:29:12 GMT+02:00, leni a écrit : >J'ai un problème, mais est-ce dû à ma configuration ? Non du tout. J'ai passé pas mal de temps à reconfigurer l'onglet Pifomètre suite aux nouveautés dont je parlais ce matin, et j'ai tout simplement *oublié* de gérer les conséque'ces sur les autres onglets /o\ :) >Si je vais dans l'onglet "Voies connues de la BAN mais pas d'OSM, avec >beaucoup d'adresses" que je sélectionne "relation" rien ne se passe (parfois >l'icône JOSM clignote comme s'il chargeait, mais rien), mais si je vais dans >Pifomètre et que je sélectionne la relation correspondante, le calque >correspondant se charge bien dans JOSM (par contre si je choisis "points" il >se charge normalement dans les deux onglets): Tu as donné le contournement. J'essaie de mettre ça au carré ce soir ou demain. Merci vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] BANO : rapprochements sans code FANTOIR
Bonjour, Suite aux discussions ici [1] et sur Github [2] j'ai apporté une modification au fonctionnement de BANO afin de tolérer le rapprochement de voies dépourvues de code FANTOIR. C'est la situation qu'on rencontre quand des adresses figurent dans la BAN mais que la voie correspondante n'est pas présente dans FANTOIR. On a eu le cas l'année dernière avec Torsac [3] qui disposait de sa BAL, mais dont quasi aucune voie n'était référencée dans FANTOIR (et au passage, 1 an plus tard, c'est toujours le cas). Désormais quand une voie est connue de la BAN mais pas de FANTOIR, elle est intégrée à BANO avec un pseudo code FANTOIR. Le pivot technique de BANO reste donc FANTOIR, mais parfois le contenu du code FANTOIR est fabriqué pour l'occasion, et non pérenne. Les adresses correspondantes de la BAN étant prises en compte dans BANO, elles deviennent disponible pour intégration via Pifomètre (Deuzeffe, ça pourrait modifier ton tuto...), et elles sont présentes dans les exports BANO. Comme le code est factice, il n'a pas vocation à se retrouver dans OSM via le tag ref:FR:FANTOIR. Par suite, il est masqué dans Pifomètre. A la place vous verrez un texte "Voie sans FANTOIR". Exemples avec Nedde [4]. Autres conséquences dans Pifomètre : - l'intégration de ces adresses en mode Relation n'ajoute pas de ref:FR:FANTOIR - la qualification des voies ne fonctionne pas (car les codes factices ne sont pas stables, donc inutilisables pour stocker un état sur la durée). Vous aurez une pop-up d'erreur en changeant le statut des voies, et à la prochaine ouverture de Pifomètre le statut sera remis à 'Ok' - on retrouve en tant que voies avec adresses quantité de lieux-dits, tout simplement car la BAN ne fait pas le distinguo entre lieux-dits et voies. J'ai bien dans les cartons d'opérer ce distinguo (cf ce ticket [5]) mais ça sera dans un second temps Côté exports BANO, il y a aura à coup sûr des doublons liés à des divergences d'orthographe, mais je n'ai pas terminé l'analyse. Si vous voyez des cas de doublon dans Pifomètre, je suis preneur. merci pour vos retours, vincent [1] : https://lists.openstreetmap.org/pipermail/talk-fr/2022-August/105633.html [2] : https://github.com/osm-fr/bano/issues/276 [3] : https://forum.openstreetmap.fr/t/adressage-commune-torsac/7040 [4] : https://bano.openstreetmap.fr/pifometre/index.html#insee=87104=1 [5] : https://github.com/osm-fr/bano/issues/277 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Dégommer du rouge, visible ou invisible
Bonjour, > De: "deuzeffe" > > Une chtite mise à jour ici : > https://wiki.openstreetmap.org/wiki/FR:France/Base_Adresses_Nationale_Ouverte_(BANO)#Sources > avec différenciation BANO v1/BANO v2 > > C'est mieux ? Oui ! :) > D'autre part, l'ordre de priorité a plus ou moins évolué aussi puisque > exit OpenData historique et cadastre. Et donc, le nouveau est ? OSM en > premier, mais après ? OSM en 1er, puis BALs et enfin BAN hache-thé-hache vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Dégommer du rouge, visible ou invisible
Le 17/09/2022 à 21:10, deuzeffe a écrit : Je vais voir les 87XXX (et chercher les faux positifs ?) Ah ben bien volontiers oui :) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Dégommer du rouge, visible ou invisible
Le 07/09/2022 à 17:28, Vincent de Château-Thierry a écrit : Pour rappel, les buts recherchés : - proposer dans Pifomètre une intégration de rues et n° pour les communes où les voies sont absentes de FANTOIR - augmenter le contenu exporté de BANO avec les adresses de ces communes tout ça via la création de codes FANTOIR bidons dans les traitements internes à BANO et tout en évitant de coller des faux codes FANTOIR dans OSM. J'ai un peu avancé sur ce sujet, en choisissant 2 communes cobayes : Torsac (16382) et Nedde (87104). Ca donne ce type de possibilité dans Pifomètre : https://bano.openstreetmap.fr/pifometre/#insee=87104=1 Comme vous le voyez, on a à dispo chaque rue de la commune disposant d'adresses dans la BAN, avec moyen d'intégrer les adresses simplement. La nuance par rapport à une commune dont les voies sont connues de FANTOIR, c'est qu'ici les codes FANTOIR sont masqués car à ne pas mettre dans OSM, ce sont de faux codes créés dans BANO uniquement à des fins de tambouille interne. C'est pas complètement sec, notamment car le dernier onglet (voies connues d'OSM) est rempli alors qu'on devrait trouver majoritairement son contenu plutôt dans le 2e onglet. Peu importe, ça n'empêche pas de jouer avec l'intégration d'adresses, sans code FANTOIR. Si c'est satisfaisant, la suite consistera à identifier d'autres communes sujettes au même procédé. merci vincnt ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Dégommer du rouge, visible ou invisible
Bonjour, Le 17/09/2022 à 12:52, deuzeffe a écrit : Le 05/09/2022 à 23:25, Vincent de Château-Thierry a écrit : Soit on les détermine par une règle, par exemple quelles communes ont des enregistrements dans la BAN et n'ont que des lieux-dits dans FANTOIR : on en trouve quand même 1900. Cette liste est visible "quelque part sur le ternet" ? (et 1 900 sur près de 35 000 communes, c'est un pouième ; moins de 6 % il me semble) Voici la liste : https://gist.github.com/vdct/be5ff23fa87bf7550daea828b90d92f4 Je ne l'ai pas vraiment analysée, possible que ça ne nous donne pas ce qu'on attend... vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] bano fantoir
Salut Didier,
Le 17/09/2022 à 14:28, didier a écrit :
merci pour le lien wiki
la regle devient
*["ref:FR:FANTOIR"]["ref:FR:FANTOIR"!~/^(no|([1-9][0-9]|0[1-9])([0-
9]{3})([0-9]|[A-Z])([0-
9]{3})([ABCDEFGHJKLMNPRSTUVWXYZ]))$/][inside("FR")] {
throwWarning: "mauvaise référence ref:FR:FANTOIR";
group: tr("validation rules nat_ref in France");
-osmoseItemClassLevel: "9019/9019002/3";
-osmoseTags: list("ref", "highway");
-osmoseAssertNoMatchWithContext: list("way highway=residential
name=impasse ref:FR:FANTOIR=75106S581T", "inside=FR");
}
idem pour ref:FR:FANTOIR:left/right
il y aura des faux postifs dans les cas de plusiers reférence comme
ref:FR:FANTOIR=75106S581T;75107S581L
J'ai l'impression qu'il manque la possibilité de A et B en 2e position
pour la Corse ?
vincent
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Dégommer du rouge, visible ou invisible
Bonjour, > De: "deuzeffe" >> Soit on les énumère dans un fichier et on fait vivre ce fichier, en >> ajoutant au fil de l'eau les communes où on constate du vide dans >> Pifomètre et de la matière dans la BAN, et en supprimant celles pour >> lesquelles on voit apparaître du contenu "voies" dans FANTOIR. > > Question de nunuche : comment détermines-tu celles qui doivent être dans > la liste ? Pas compris :( > >> Vos avis & idées bienvenus, surtout si on essaie de trouver des règles. >> Par défaut, je peux partir sur une liste de communes (au hasard pour >> commencer, Torsac et Nedde) > > Certes, c'est parce qu'on te les as signalées... C'est donc le critère > pour les inclure dans la liste ? Je crains que ça ne soit pas gtrès > productif :((( Oui, on navigue entre - une liste totalement faite main, où on n'ajoute que les communes où quelqu'un a constaté le vide (typiquement Nedde avec ton constat). C'est trs conservateur, mais 100% fiable. - une heuristique basée sur une règle qui reste à déterminer, qui pourrait s'amorcer avec "le croisement des communes présentes dans la BAN et pour lesquelles FANTOIR ne référence que des lieux-dits". Le souci c'est que la classif en lieux-dits de FANTOIR n'est pas super fiable. C'est donc moins fiable, et plus laxiste. Finalement peut-être que les 2 approches peuvent se combiner : utiliser Nedde comme cobaye, s'en servir pour adapter Pifomètre et les exports BANO, puis essayer d'étendre à beaucoup plus de communes déterminées par une ou des règles. Pour rappel, les buts recherchés : - proposer dans Pifomètre une intégration de rues et n° pour les communes où les voies sont absentes de FANTOIR - augmenter le contenu exporté de BANO avec les adresses de ces communes tout ça via la création de codes FANTOIR bidons dans les traitements internes à BANO et tout en évitant de coller des faux codes FANTOIR dans OSM. à suivre vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Dégommer du rouge, visible ou invisible
Bonjour, > De: "Marc_marc" > > Le 05.09.22 à 23:25, Vincent de Château-Thierry a écrit : >> Soit on les détermine par une règle, par exemple quelles communes ont >> des enregistrements dans la BAN et n'ont que des lieux-dits dans FANTOIR >> : on en trouve quand même 1900. > > cela me semble le mieux, tant en raison du nombre, qu'en raison > du caractère éventuelement fluctuant > une règle au niveau de la rue n'est pas + ciblée ? > si la rue existe dans ban mais pas dans fantoir Ca me parait très fastidieux rue par rue, je doute qu'on récolte beaucoup de contenu. Je préfère envisager à la commune, avec des règles de priorité pour les vrais FANTOIR quand on se retrouve par inadvertance avec un libellé BAN correspondant en fait à un libellé FANTOIR. >> je peux partir sur une liste de communes (au hasard pour commencer, Torsac et >> Nedde) > > cela permettrait de tester le système en attendant de récolter > des retours pour la règle la plus pertinante Oui a minima. A suivre merci vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Dégommer du rouge, visible ou invisible
Bonsoir, Le 02/09/2022 à 01:21, Jérôme Amagat a écrit : (Désolé de faire 3 messages...) Pour les communes avec des voies dans la BAN mais pas dans BANO car pas de Fantoir, on peut les trouver en regardant la page des stats par commune sur un département. Par exemple pour le Cantal (15) : https://bano.openstreetmap.fr/pifometre/stats_dept.html#dept=15 Regardez la colonne "Adresse BAN sans voie rapprochées", il y a des communes avec un nombre important. (Par contre si l'on va sur les voies récentes manquantes du même département : https://bano.openstreetmap.fr/pifometre/voies_recentes_manquantes.html#dept=15 Il n'y a que 74 voies manquantes dans osm pour ce département.) Si l'on clic sur une de ces communes avec beaucoup d'adresses sans voies rapprochées, par exemple Anglards-de-Salers (c'est la communes qui en a le plus 744) : https://bano.openstreetmap.fr/pifometre/index.html#insee=15006=0 Il ne manque qu'un lotissement de 3 adresses. Le reste des adresses de la BAN que l'on ne voit pas c'est soit des adresses lié à un lieu dit soit des adresses lié à une rue sans code Fantoir. On peut télécharger les données de la commune sur le site adresse.data.gouv.fr. Pour Anglards-de-Salers la source des adresses est très majoritairement la commune. On a une centaine de noms de voie différents dont environ la moitié qui sont en fait des noms de hameaux mais même les nom de hameau ont pour la plupart leur clé d’interopérabilité qui n'est pas le code fantoir du hameau) Dans le Cantal il y a en a quelques unes de communes dans ce cas mais ça dépend beaucoup du département. On doit pouvoir mettre en place un mécanisme assez simple qui complète FANTOIR avec les noms des voies de la BAN et un identifiant (qui n'a même pas besoin d'être pérenne). Le principal souci est de bien déterminer quelles communes sont concernées. Soit on les détermine par une règle, par exemple quelles communes ont des enregistrements dans la BAN et n'ont que des lieux-dits dans FANTOIR : on en trouve quand même 1900. Soit on les énumère dans un fichier et on fait vivre ce fichier, en ajoutant au fil de l'eau les communes où on constate du vide dans Pifomètre et de la matière dans la BAN, et en supprimant celles pour lesquelles on voit apparaître du contenu "voies" dans FANTOIR. Vos avis & idées bienvenus, surtout si on essaie de trouver des règles. Par défaut, je peux partir sur une liste de communes (au hasard pour commencer, Torsac et Nedde) merci vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Dégommer du rouge, visible ou invisible
Bonjour,
Le 01/09/2022 à 16:50, deuzeffe a écrit :
Si je lis bien le wiki, dans les sources :
https://wiki.openstreetmap.org/wiki/FR:France/Base_Adresses_Nationale_Ouverte_(BANO)#Sources
on trouve celles en OD :
https://wiki.openstreetmap.org/wiki/FR:France/Base_Adresses_Nationale_Ouverte_(BANO)/OpenData
et je m'étonne de ne trouver aucune BAL.
Cette partie du Wiki date du tout début de BANO, avant qu'émergent les
BAL. C'était la foire à l'open-data, chaque entité (ville, agglo) y
allant de sa publication. Christian produisait un script par source pour
unifier tout ça.
Vu de maintenant : non, le wiki n'est pas à jour :(
D'autre part, dans les fichiers départementaux de la BANO
(https://bano.openstreetmap.fr/data/) on trouve comme source de données :
- OSM, OD, CAD : ok
- C+O, O+O ? : Commune, OD ?
C'est une codification du début de BANO, et qu'on a gardée au fil des
changements de sources (arrêt du Cadastre et des Open-data, arrivée de
BALs et BAN)
OSM = nom et numéro issus d'OSM
O+O ("Open data + OSM") = nom issu d'OSM, numéro issu d'une BAL
OD : nom et numéro issus d'une BAL
C+O ("Cadastre + OSM") = signifie désormais numéro issu de la BAN et nom
issu d'OSM
CAD ("Cadastre") = signifie désormais numéro et nom issus de la BAN
Et j'ai vraiment l'impression qu'il y a des bouts de BAL dedans.
sont-ce des BAL qui sont raccord avec FANTOIR ou des BAL "orphelines"
ie sans lien avec FANTOIR ?
Oui il y en a, issues de
https://adresse.data.gouv.fr/data/adresses-locales/latest/csv/. Celles
qu'on trouve en sortie de BANO sont forcément liées à FANTOIR, en l'état
du fonctionnement de BANO
vincent
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Dégommer du rouge, visible ou invisible
Bonsoir, Le 31/08/2022 à 12:00, Marc_marc a écrit : Le 30.08.22 à 18:54, deuzeffe a écrit : J'ai brouillonné un petit tuto pour dégommer du rouge avec ou sans Pifomètre, ici : https://wiki.openstreetmap.org/wiki/User:Deuzeffe/voies-sans-nom Merci pour ton partage de méthode Deuzeffe :) question : - comment est-ce que BANO donc pifomètre se retrouve à ne pas avoir des addr venant des BAL ? c'est parce que le code fantoir est absent ? oui Vincent il n'est pas possible de faire quelque chose pour éviter toutes ces étapes manuelles ? non, ou en tout cas pas si simplement que ça. Comme le rappelle Deuzeffe, Fantoir est le pivot de BANO (moi j'aime bien parler de "dorsale", mais on dit la même chose). Fantoir, sur le papier, est l'ensemble le plus complet de noms de voies & lieux-dits qu'on peut trouver pour la France. Ca a donc du sens de vouloir s'appuyer dessus pour comparer différents contenus articulés autour des noms de voie : les adresses de la BAL, celles d'OSM, et plus largement les noms de voie d'OSM. Fantoir étant le hub de tout ça, une commune non couverte par Fantoir pour ses voies se retrouve mécaniquement invisible dans BANO, et donc aussi dans les outils Pifomètre. On a eu le cas l'été dernier avec Torsac, en Charente [1]. C'est moche, je suis d'accord. Je n'ai pas idée de l'ampleur du phénomène, avec Nedde ça fait au moins 2. Le souci pour bricoler un mécanisme dans BANO sans codes Fantoir, c'est que ça vient casser le paradigme de base, où Fantoir est le pivot, et le code Fantoir l'identifiant unique de chaque voie, qu'on recycle dans BANO. Ca a des conséquences dans tous les recoins de BANO, donc pas évident à affronter sans introduire de régressions pour le tout venant des communes. Ce serait cependant bien plus satisfaisant de ne pas zapper ces adresses dans les exports BANO in fine, je suis d'accord. Suggestions bienvenues ! vincent [1] : https://forum.openstreetmap.fr/t/adressage-commune-torsac/7040 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] josm : ajouter un fond de carte jpg
Bonjour Hélène > De: "Hélène PETIT" > > J'ai un fond de carte fait à la main que je veux mettre dans un calque > de josm, pour comparer, je ne retrouve pas comment faire, PicLayer est ton ami ! https://josm.openstreetmap.de/wiki/Help/Plugin/PicLayer vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Une note qui fait partie d'une relation ?
Bonjour, > De: "deuzeffe" > Je viens de tomber sur ça : https://www.openstreetmap.org/way/229728801 > Je suis perplexe. Ou bien il y a une raison historique ? > Je laisse qui sait corriger, s'il y a qq chose à corriger. Un way sans aucun tag c'est possiblement déroutant pour quiconque tombe dessus. Donc j'imagine ce tag note=* au moins pour éviter le vide ? Quand on regarde le propos de la relation, alors un tag boundary=* serait pertinent sur les ways, mais je ne vois rien de bien adapté dans le wiki [1], tout juste une quinzaine de boundary=mountain_range via taginfo [2] vincent [1] : https://wiki.openstreetmap.org/wiki/Key:boundary [2] : https://taginfo.openstreetmap.org/tags/boundary=mountain_range ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] question sur un nouveau nom de rue et procédures BANO
Bonjour, > De: "Pierre Beyssac" > > Faut-il reporter telle quelle l'orthographe du panneau dans OSM ? > > Sinon, comment faire pour trouver une autre référence ? > > Peut-on vérifier dans une autre base publique servant de source pour BANO ? > J'ai regardé hier l'extraction IGN pour le Puy de Dôme mais le nom > n'y figure pas encore, pas plus que les autres noms de rues. > > Faut-il appeler la mairie ? Appeler la mairie devrait clore le débat, si tu as moyen de consulter la délibération qui a décidé du nom de la voie. Les erreurs de retranscription sur les plaques de rue font partie des blagues récurrentes, c'est vraiment la délib qui doit faire foi. Si finalement la plaque se trompe, tu peux ajouter le nom constaté sur la plaque via un tag note=* pour éviter que quelqu'un après toi veuille rétablir dans le tag name le nom erroné. Bonne enquête vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Clés pour chemin sous marée
Bonjour,
> De: "whatis moss"
> Bonjour, j'aurais besoin d'aide pour savoir quelle clés utiliser pour un
> chemin
> qui est accessible seulement lors de la basse marée. La clé tidal=yes semble
> être répandue mais d'après le wiki, cette clé serait pour les étendues d'eau
> soumises à la marée plutôt que pour les chemins accessibles lors de la basse
> marée. Après cela, il y aurait t-il aussi une clé pour indiquer à quel niveau
> de marée le chemin est accessible ? Dans mon cas j'ai un chemin accessible
> seulement lorsque la marée est inférieure à 3 mètres.
En regardant le Passage du Gois {1] je vois un "access=tidal" qui pourrait
convenir, mais qui est très peu utilisé (30 occurrences dans le monde) et pas
documenté.
Une manière un peu plus élaborée serait avec access:conditional=yes␣@␣tidal.
Voir la doc associée [2].
vincent
[1] : https://www.openstreetmap.org/way/24369838
[2] : https://wiki.openstreetmap.org/wiki/Conditional_restrictions
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [édition mécanique/de masse] post_office:type=* -> `post_office=*
Bonjour, > De: "Marc_marc" > > je propose de convertir les post_office:type=* en`post_office=* > si post_office=* existe deja avec la même valeur, post_office:type=* > serra simplement supprimé > les éventuels conflits entre l'info donnée par post_office:type=* > et post_office=* se feront hors de l'édition de masse > > l'étendue géographique est la France entière, > un changeset pour la france métropolitaine, un par domtom pour éviter > les changeset d'étendue inutilement étendu à travers des zones non > concernées. > > Avis ? Ok pour moi. Merci Marc vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bonnes pratiques pour la délimitation des landuse et autres natural ?
Bonsoir, Le 12/07/2022 à 19:15, osm.sanspourr...@spamgourmet.com a écrit : Avec cette logique, pour une rue bordée d'immeubles, il faudrait prolonger la surface des immeubles jusqu'à l'axe central de la voie... On ne le fait pas, au moins parce que notre source pour le bâti est de qualité correcte, et que souder les bâtiments aux highways serait à la fois chronophage et synonyme de dégradation de la qualité, vue la déformation manifeste qu'on ferait subir aux géométries de bâtiments. Bref, ça ne vient à l'idée de personne je pense. Non le landuse en question c'est le residential. Mon exemple ne s'appuie pas sur un landuse mais sur un building, et c'est volontaire, pour montrer ce qui me parait bancal dans l'approche, indépendamment de la nature des polygones. Le bâtiment est collé au trottoir. Le trottoir est inclus dans le dessin filaire taggué highway=*. Donc le bâtiment doit être collé au filaire highway. C'est exactement ce qui se passe pour les landuses, je ne vois pas pourquoi ce qui nous choque pour les buildings serait acceptable pour les landuses. Par analogie, la seule raison que je vois pour coller les landuses aux filaires de voies est l'absence d'une source géométrique assez précise, combiné au temps que prend le dessin de ces surfaces. Ça n'est donc (pour moi) qu'une version intermédiaire de dessin des landuse, et surtout pas une bonne pratique. La fonctionnalité de copie parallèle dispo dans JOSM [1] est un bon compromis pour dessiner du 1er coup une limite de landuse non collée au filaire mais approximant l'emprise de la chaussée. OK pour la première partie. Par contre pas pour la seconde : on fabrique de la fausse précision. En restant au landuse surfacique / route filaire (mais éventuellement avec une largeur), on ne crée pas de fausses données. Si, ne serait-ce que pour la surface du landuse, dilatée jusqu'au filaire de voie, cf ce qui disais Stéphane plus haut. C'est imparfait, OK mais entre imparfait et faux... Absolument tout ce qu'on dessine dans OSM est imparfait géométriquement, approximé. Le faux c'est autre chose : dessiner un bâtiment à la place d'un terrain de pétanque, une rivière à la place d'une autoroute, etc. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bonnes pratiques pour la délimitation des landuse et autres natural ?
Bonsoir Le 11/07/2022 à 18:47, osm.sanspourr...@spamgourmet.com a écrit : Pas trop d’accord. Le « problème » est celui soulevé par David : la route est modélisée en filaire et les landuse en surfacique. Tant qu’on fait ça, la représentation la plus logique est de faire aller les landuse jusqu’à la route. Et c'est parce que du as des landuse=railway que tu ne vas pas jusqu'au rails. Avec cette logique, pour une rue bordée d'immeubles, il faudrait prolonger la surface des immeubles jusqu'à l'axe central de la voie... On ne le fait pas, au moins parce que notre source pour le bâti est de qualité correcte, et que souder les bâtiments aux highways serait à la fois chronophage et synonyme de dégradation de la qualité, vue la déformation manifeste qu'on ferait subir aux géométries de bâtiments. Bref, ça ne vient à l'idée de personne je pense. Par analogie, la seule raison que je vois pour coller les landuses aux filaires de voies est l'absence d'une source géométrique assez précise, combiné au temps que prend le dessin de ces surfaces. Ça n'est donc (pour moi) qu'une version intermédiaire de dessin des landuse, et surtout pas une bonne pratique. La fonctionnalité de copie parallèle dispo dans JOSM [1] est un bon compromis pour dessiner du 1er coup une limite de landuse non collée au filaire mais approximant l'emprise de la chaussée. vincent [1] : https://josm.openstreetmap.de/wiki/Fr%3AHelp/Action/Parallel ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] géolocalisation des photos
Bonjour, > De: "Jacques Lavignotte" > Le 22/06/2022 à 15:23, Hélène PETIT a écrit : > >> Avec quelques autres vieux comme moi, on utilise des photos >> géolocalisées (plutôt que de prendre des notes). > > Bienvenue au club. > >> Bug : lorsque nous nous échangeons ces photos, il arrive que la >> géolocalisation soit enlevée automatiquement ; > > Très petite expérience qui consiste à transférer du SmartPhone Android > vers un partage Owncloud/Linux. EXIF ( et géoloc donc) préservés. > > > Prêt à tester à plusieurs d'autres procédés. Mes photos n'ont par défaut pas de géoloc, je les cale grâce à une trace, avec JOSM. Il m'arrive de figer la geoloc d'une photo en écrivant les coordonnées dans l'EXIF via le plugin photo_geotagging et ça marche plutôt bien pour rouvrir les photos, y compris en changeant d'ordinateur entre temps. Pas sûr que ça réponde à ta question Hélène, tu diras. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Ajout systématique de : Contact
Bonjour, Le 28/05/2022 à 17:02, Jacques Lavignotte a écrit : Le 28/05/2022 à 16:30, Marc_marc a écrit : bonjour, il y a 2 choses en une : Pour le débat contact:* vs addr:* : je trouve assez inexplicable (ou du moins difficile à argumenter) le recours à contact:* pour stocker une adresse en certaines occasions, et le recours à addr:* pour stocker la même info en d'autres occasions. Je serais plutôt favorable au recours permanent à addr:* quel que soit l'objet auquel on veut coller une adresse, en ajoutant sur chaque occurrence une qualification, pour indiquer que les tags addr: d'un objet décrivent : - l'adresse "principale" d'un lieu (au hasard, le pas de porte avec boîtes aux lettres, interphone, plaque de rue...) - l'adresse d'un commerce, quand celle-ci fait doublon avec la principale - l'adresse pour un accès de type parking automobile etc, sur le même mode que les tags entrance=* L'idée est de donner le type d'une adresse. On pourrait utiliser un tag addr:type, ou plus simplement le tag addr seul. Ca donnerait par exemple pour ce bâtiment https://www.openstreetmap.org/way/79804469 : - le noeud https://www.openstreetmap.org/node/1363472191 avec un tag additionnel addr=main - le noeud https://www.openstreetmap.org/node/2195019201 avec un tag addr=shop et ainsi de suite. Libre ensuite aux consommateurs des données de prendre toutes les occurrences d'un addr:housenumber, ou d'en piocher une quand on ne veut pas de doublon, et dans ce cas addr=main serait l'élue. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] MS BOT
Bonjour, > De: "lenny.libre" > > Je vois depuis quelques temps des mises à jour de > https://www.openstreetmap.org/user/MS%20BOT/history sur tout le > territoire en mettant comme unique commentaire "Corrections sur France " > > En a-t-il parlé quelque part ? je n'ai rien vu !!! Rien vu de récent non plus, mais sa page parle de 2022 : https://wiki.openstreetmap.org/wiki/MS_BOT Derrière ce bot c'est Marc Sibert (initiales MS). Peut-être lit-il encore cette liste, et sinon joignable via la page de discussion de MS_BOT sur le wiki. > J'ai trouvé une des corrections (il y en a peut-être d'autres) qui n'est > pas conforme à > https://wiki.openstreetmap.org/wiki/FR:Toponymes,_odonymes#Majuscules.2C_minuscules_et_trait_d.27union > "les articles ... prennent ... une minuscule à l'intérieur du nom ..." > > https://www.openstreetmap.org/way/307914880/history : "Place Quentin de > *l*a Tour" a été remplacé par "Place Quentin de *L*a Tour" Si Wikipedia ne se trompe pas, alors la correction est valide : https://fr.wikipedia.org/wiki/Quentin_de_La_Tour vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [BANO] Ajout d'adresses associatedStreet avec adresses pré-existantes
Le 20/12/2020 à 15:55, Georges Dutreix via Talk-fr a écrit : je ne connaissais pas du tout cet outil. Il est destiné à intégrer des adresses via JOSM ? Y-a-t-il une description, même très succincte, quelque part ? (je n'ai rien trouvé) Il y a de la lecture ici : https://wiki.openstreetmap.org/wiki/Contribuer_%C3%A0_la_BANO qui n'est pas à jour des dernières évolutions, dont la possibilité d'ajouter des adresses justement. Sur le principe : lorsque dans les processus BANO on détecte que des adresses existent dans la BAN et pas dans OSM, on propose leur iintégration, en effet via JOSM. Dans ce cas tu as pour chaque nom de voie "avec Adresses" (les 2 premiers onglets à gauche) deux choix en fin de ligne : soit "x points" où x correspond au nombre d'adresses pas encore connues d'OSM, soit "Relation". Un clic sur "x points" envoie dans JOSM (via la telecommande) autant de nouveaux points avec addr:housenumber et addr:street remplis Un clic sur "Relation" envoie ces mêmes points incluis dans une relation associatedStreet, nouvelle si besoin, et recyclant de précédents points isolés si besoin aussi. Dans tous les cas, l'envoi se fait vers un nouveau calque portant le nom de la voie. il convient de vérifier ces nouvelles données, déplacer les points si besoin (leur géométrie vient de la BAN), et ensuite envoyer au serveur. Si quelqu'un a le courage de mettre à jour le wiki, surtout ne pas hésiter :) merci vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] [BANO] Ajout d'adresses associatedStreet avec adresses pré-existantes
Bonjour, Juste pour signaler une évolution dans l'outil d'intégration d'adresses (colonne "Adresses à intégrer" dans https://bano.openstreetmap.fr/fantoir/). Désormais lorsqu'on choisit l'option "Relation" et qu'il existe déjà dans OSM des points d'adresse isolés pour la voie en question, l'outil cherche à incorporer ces adresses à la relation, en supprimant au passage leur tag addr:street pour qu'il ne fasse pas doublon avec le tag name de la relation. C'est en lien avec ce ticket : https://github.com/osm-fr/osm-vs-fantoir/issues/113 et je demande votre vigilance lors de l'usage de l'outil, d'où ce mail. La nouvelle version est sensée appréhender les différents types d'objets avec le rôle "house", j'ai l'impression d'avoir tout pris en compte, mais rien ne vaut un vrai test par celles et ceux qui voudront bien, loin de mes quelques tests. En cas de soucis observés, vous pouvez les remonter ici ou directement dans le ticket. merci vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Usages des cartes IGN pour contribuer à OSM [était : Évolution de l'IGN, ouverture de données
Bonsoir, Le 11/12/2020 à 17:59, deuzeffe a écrit : Le 11/12/2020 à 17:53, Vincent Bergeot a écrit : cela me fait me demander si cela pourrait être un nouvel élément de la convention entre osm-fr et l'ign, sur le même principe que ce nous avions avec la bd ortho et son usage pour contribuer à OSM. Histoire de changer une convention caduque par une autre, en somme (et ailleurs en France). Peut-on envisager l'usage, par convention, des cartes IGN pour la contribution à OSM (avec, comme le souligne Jean-Claude les vérifications adéquates) ? Avec correction des cartes IGN par leur soins avec les données OSM ? Je ne sais pas s'il y avait une contre-partie demandée à OSM-FR par l'IGN dans la défunte convention. De quelle convention caduque et/ou défunte parles-tu ? La seule convention en vigueur actuellement entre OSM-Fr et l'IGN date de juin 2019, elle a été signée au SOTM de Montpellier pour une durée de 3 ans. C'est elle qui nous permet de choisir la BD Ortho dans nos éditeurs. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Fwd: 2020 OSMF board election and proposed resolutions
Bonsoir, > De: pepilepi...@ovh.fr > > C'est normal, ça ? Oui. Dans la page en question tu peux lire : "The vote button of this test page does not work" et il faut le prendre au pied de la lettre :) J'ai trouvé ça déroutant aussi, mais j'ai pu voter normalement ensuite, sur la vraie page de vote. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] raison pour rue non rapprochée et no manquant
Bonjour, > De: "Marc_marc" > > je pose la question ici car j'imagine ne pas être le > seul à rencontrer ce cas de temps à autre > commune Bucey-lès-Gy 70104 > un exemple parmi d'autre : Rue de l'europe > > dans osm la rue et ses adresses > https://overpass-turbo.eu/s/10HL > > dans l'outil du cadastre pdf il y en a 27 adresses > http://cadastre.openstreetmap.fr/data/070/RB104-BUCEY-LES-GY-adresses-addrstreet_mix_en_facade_ou_isole.zip > > dans le rendu bano on voit bien toutes les addr, > y compris celle encore absente dans osm > > mais dans le comparateur > https://bano.openstreetmap.fr/fantoir/#insee=70104=2 > - elle est non rapprochée. quelqu'un comprend pq ? > bien sur on peux forcer en ajoutant la ref > mais même sans ref, le nom exactement identique fait > le rapprochement non ? > - elle est sans adresse, la BAN n'a pas récupéré > les addr du cadastre ? > > Vincent je te fais volontiers un ticket si c'est > un bug dans l'outil bano/fantoir Je pense que c'est un bug car en regardant le Fantoir brut de la commune [1] on constate qu'il y a 2 voies "Rue de l'Europe", l'une actuelle et non rapprochée (701040060K), l'autre annulée mais rapprochée (701040059J). Ca ne devrait pas être le cas, la 701040059J ne devrait pas être prise en compte du fait de son annulation. Marc je veux bien un ticket là-dessus, merci. vincent [1] https://bano.openstreetmap.fr/fantoir/liste_brute_fantoir.html#insee=70104 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Offrir une une carte des adresses à Theizé
Bonjour, > De: "Christian Quest" > Le 27/11/2020 à 16:04, Marc_marc a écrit : > > les adresses correcte sont dans bano et donc > > https://bano.openstreetmap.fr/fantoir/#insee=69246=0 > > devrait être valide. > > Modulo la mise à jour de FANTOIR qui n'est peut être pas encore > faite. > > Les dates les plus récentes d'ajout sont en 2015... si de nouvelles > voies ont été nommées plus récemment, on ne les a pas encore dans les > moulinette BANO très liée à FANTOIR. Le millésime FANTOIR connu de BANO est celui d'octobre 2020 suite à ce ticket [1]. Je réalise que j'ai dû oublier d'en parler ici, dont acte. Et merci à Deuzeffe pour la veille :) Pour revenir au sujet initial, je suis assez partisan de la proposition de Brice, qui ne cherche pas à sortir la carte parfaite du 1er coup mais qui donne un excellent point de départ pour discuter d'OSM avec un élu. Evidemment, plus on aura pu déduire l'emprise des voies depuis les adresses plus on sera proche de la cible, et solliciter l'élu pour affiner sera aussi un bon prétexte. vincent [1] : https://github.com/osm-fr/bano/issues/207 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import des horaires des bureaux de poste
Bonsoir, > De: "David Faure via Talk-fr" > On jeudi 26 novembre 2020 15:23:03 CET Frédéric Rodrigo wrote: > > Le 26/11/2020 à 10:09, Marc_marc a écrit : > > > >> Ça donne 1537 changesets concernant chacun entre 1 et 96 bureaux > > >> de > > >> poste. > > > > > > pq pas si t'as envie... mais un import avec des changeset n'ayant > > > parfois qu'un bureau, cela limite l'intérêt du changeset. > > > perso un changeset pour la france ou un par région, cela me > > > choque > > > pas, ces bureaux n'avaient de toute façon pas d'horaire. > > > mais peu importe ton choix à ce niveau, ce point est pour moi ok, > > > > Même avis ici aussi. > > > > 1 537 changets pour 9 730 objets. Ça fait quand même vraiment > > beaucoup de > > changesets. > > Vraiment ? Avec StreetComplete j'ai fait 764 changesets pour 2727 > objets, si > je comprends bien le "764 Modifications" affiché sur > https://www.openstreetmap.org/user/Dfaurekde > et le 2727 affiché en haut à gauche dans StreetComplete. > > L'idée c'était d'éviter les notifications intempestives, > puisqu'apparemment certains monitorent une zone bien spécifique et ne veulent > pas > recevoir de notifications intempestives liées à un changement à grande > échelle. > D'un autre côté, ça arrive super souvent, non ? > Un exemple au hasard: > https://www.openstreetmap.org/changeset/94106441 > (merci à toi zorglubu, d'intégrer + de bureaux de postes, ça va > m'aider !) Je trouve ta justification tout à fait valable et louable : ne pas engendrer des emprises de changesets gigantesques, qui polluent l'analyse des changements produits en les dispersant dans une énorme surface. > Je peux ajuster la taille de la zone max pour créer moins de > changesets. Mais ... ça change quoi au final ? Je trouve que ce sujet est vraiment accessoire, car en effet ça ne change rien au final, on aura les mêmes objets en base in fine. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] a propos de dev.osm162.openstreetmap.fr
> De: "David Crochet" > > Le 25/11/2020 à 15:08, Marc_marc a écrit : > > mais pq utiliser l'url de dev alors que c'est en prod > > soushttps://bano.openstreetmap.fr ? > > Car https://bano.openstreetmap.fr/20km_chacun.html ne répond pas > alors que https://dev.osm162.openstreetmap.fr/20km_chacun.html# oui En effet et c'est prévu comme ça. dev.osm162 et bano sont hébergés sur la même machine virtuelle mais les points communs s'arrêtent là, l'un n'est pas le site de dev de l'autre. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] a propos de dev.osm162.openstreetmap.fr
Bonjour, > De: "David Crochet" > > Firefox n'aime pas https://dev.osm162.openstreetmap.fr/ car il lui > manque quelque chose (un certificat pour faire du 's' en http ?) Merci David. J'ai ouvert ce ticket https://github.com/osm-fr/infrastructure/issues/247 sur le sujet. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Offrir une une carte des adresses à Theizé
Salut Brice, Le 22/11/2020 à 16:58, Brice a écrit : Suite à la lecture de https://blog.geo.data.gouv.fr/t%C3%A9moignage-sur-ladresse-theiz%C3%A9-en-beaujolais-382a9f566a2c je souhaite rentrer dans OSM le nécessaire pour offrir à M. Yves Kensicher la "carte des adresses" de sa commune de Theizé (69620), c'est bientôt Noël :-) J'ai aussi lu ce témoignage, il est juste top, j'encourage chacune et chacun à le lire. Je trouve ton idée excellente :) Globalement les routes sont là et nommées, il y aura certainement des améliorations à faire sur le bâti et la voirie, je m'en occuperai en même temps que vérifier les POI adresses, après l'import effectué. Ce qu'il faudrait donc c'est "juste" importer la Base Adresses Locale existante (...) Ma question est : comment procéder ? Quel outil disponible pour cela ? Mon besoin se résume à : Je ne suis pas sûr de partager ton diagnostic quand je vois la liste des noms de voies dans https://bano.openstreetmap.fr/fantoir/#insee=69246=0. Je serais donc plutôt partisan d'une revue des noms de voies de la commune, qui peut s'accompagner de l'import des adresses pour chacune en utilisant JOSM via un clic à droite de chaque ligne dans la colonne "Adresses à intégrer". La géométrie des points proposés arrive directement de la BAN, donc in fine de la BAL de la commune. Ca devrait donc être raccord avec le CSV que tu as repéré, en terme d'exaustivité et de précision géométrique. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [CA RESTE OUVERT] xxxxxxxxxxxxx de cadastre.openstreetmap.fr, sauf si...
Bonjour, > De: "Jacques Lavignotte" > > J'ai re-essayé ce service et je le trouve très efficace même si peu > intégré, et la manip un peu roots. > > Et ça juste marche, sans maintenance depuis longtemps, c'est dire. Ca ne marche plus complètement, non. L'option "Adresses" dans "Choix du type de données" ne permet plus d'obtenir les fichiers qui faisaient l'intérêt du service, à savoir l'ajout automatique de tags addr:housenumber soit sur des nodes ajoutés aux bâtiments, soit comme tag des bâtiments [1]. Les fonctionnalités restantes liées aux adresses sont reprises dans https://bano.openstreetmap.fr/fantoir/ et sont alimentées par la mise à jour hebdomadaire de la BAN. Elles correspondent aux menus "Adresses à intégrer" des 2 onglets de gauche (onglets "Voies avec adresses numérotées). Elles n'ont donc pas d'intérêt à être portées vers un nouveau cadastre.openstreetmap.fr si portage il y a. Ce portage se limitera(it) donc à permettre l'accès aux bâtiments vectoriels du Cadastre avec un peu d'avance (quelques semaines, au max 3 mois) sur les flux proposés directement dans JOSM avec le plugin Cadastre, via un onglet dans Telechargement. vincent [1] : video de présentation du service au SOTM-FR 2014 : https://peertube.openstreetmap.fr/videos/watch/9b907bdd-269f-4751-8f69-d951bd0dd369 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] osm.org Affichage ville selon zoom - Vichy vs Cusset
Bonjour, > De: "Christian Quest" > > Certes, mais ce n'est pas ce que dit le wiki (intl) et ce n'est pas > globalement la pratique, sauf en France. Séparatisme ? ;) Le wiki est un wiki :) On doit pouvoir y indiquer comment ça fonctionne en France, tout simplement. Quand je vois les combinaisons du tag population sur Taginfo [1] on a plus de 10 "admin_level=*" et plus de 10 "boundary=*". Donc c'est loin d'être franco-français. vincent [1] https://taginfo.openstreetmap.org/keys/population#combinations ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] osm.org Affichage ville selon zoom - Vichy vs Cusset
Bonsoir, Le 12/11/2020 à 22:01, Christian Quest a écrit : Le 12/11/2020 à 17:58, Jérôme Amagat a écrit : Donc pour les rendus et pour être en accord avec ce qui est fait ailleurs dans le monde, il faudrait avoir les populations sur les node place admin_centre des communes. La seule source fiable pour obtenir ces populations est, il me semble, l'insee qui sort les populations légales tous les ans, donc pourquoi pas un bot qui modifierait population=* et source:pupulation=* des relations des communes et de leurs admin_centre tous les ans lorsque l'insee sort ces chiffres. Cela permettrait d'avoir des données tout le temps à jour. Je sais que pour beaucoup les bots c'est le mal :) mais à part les personnes qui vont compter les habitants de leur village, ça va être difficile d'avoir une meilleur source. Les bots c'est mal (il parait), mais oui, c'est vers ça qu'il faudrait aller sur ce type de données, plutôt que se fader tout à la main. Nos populations sont des populations communales, je ne vois donc pas pourquoi elles devraient être portées par autre chose que l'objet qui représente pour nous la commune, à savoir la relation admin_level=8 (ou admin_level=9 pour les arrondissements municipaux). Si un client des données a besoin de modéliser autrement cette information pour son usage propre, c'est possible. En l'occurence, descendre les informations d'une relation à un point membre de la relation est trivial, au moins avec imposm3. C'est implémenté dans BANO, je peux aider si besoin. C'est peut-être le cas aussi avec les scripts lua d'osm2pgsql [1], mais je parle sans certitude, n'ayant pas testé cette option. vincent [1] : https://osm2pgsql.org/doc/manual.html#lua-library-for-flex-output (voir l'exemple "way_member_ids") ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu BANO (v2) de retour !
Le 11/11/2020 à 16:31, deuzeffe a écrit : D'ici ce soir, je te fais un ticket circonstancié :) vincent qui met ça sur sa tout doux Juste après l'intégration du nouveau Fantoir d'automne confiné ? ;) 'xactement :) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu BANO (v2) de retour !
Bonjour, Le 11 novembre 2020 15:35:23 GMT+01:00, deuzeffe a écrit : >Échantillon sur demande ;p Volontiers ! C'est toujours plus pratique pour inspecter :) Merci vincent qui met ça sur sa tout doux ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment indiquer une séparation centrale sur une rue ?
Bonsoir, Le 05/11/2020 à 23:43, Lionel Allorge a écrit : Sur la rue suivante : https://www.openstreetmap.org/way/150276616 une petite surélévation en béton empèche les voitures de doubler, comme un terre-plein central mais bien plus petit. Comment l'indiquer ? Eventuellement barrier=kerb ? Et du fait de sa présence j'aurais tendance à dessiner un way par sens de circulation plutôt qu'un seul way centré... sur le terre-plein. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] De la BAN dans BANO... enfin !
Le 01/11/2020 à 12:51, Brice a écrit : Une remarque, de la part de qqun qui ne suit le sujet que de loin, les appelations utilisées entretiennent la confusion. Oui tu as raison Débrancher le Cadastre et alimenter BANO avec la BAN à la place... Alors là si je comprends bien, mais détrompez-moi sinon, derrière le terme "BAN", ce n'est pas le "Produit gratuit issu de la BAN" qui est évoqué mais la base "Adresses", si on se réfère à https://adresse.data.gouv.fr/donnees-nationales C'est ça en effet Confusion encore dans la suite : ... La mise à jour BAN se fait sur un rythme hebdomadaire. - l'export ... l'ajout de la BAN - les outils de contrôle "Fantoir" [2] tirent parti de la BAN ... les adresses en 5000 et 9000) non reprises par la BAN aucun numéro alors que la BAN en fournit. J'utilise "BAN" par facilité, mais en effet tout le long du message je parle du produit "Adresses", lui même victime de son propre marketing quand on voit que les URLs de téléchargement correspondantes commencent par https://adresse.data.gouv.fr/data/ban/ ... "BAN" reste un acronyme fourre-tout bien pratique pour parler d'une manière générale de tous les parfums de ladite base, ce qui est en soi un souci puisque l'idée de départ était de n'avoir qu'un seul parfum, et non des silos plus ou moins assumés pour diviser selon le type de licence, la liste des fournisseurs impliqués, etc. Toujours est-il que de ces micmacs sort quand même désormais un produit dont le contenu et la licence font qu'il est intéressant pour constituer BANO, et tant mieux pour nous :) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] De la BAN dans BANO... enfin !
Hello JB Le 01/11/2020 à 09:02, JB a écrit : Un petit coup d'œil de mon coté, et je suis surpris de voir que des éléments rapprochés n'ont plus de nom FANTOIR indiqués, par exemple 89368B091R (hamlet : La Bruyère) sur http://bano.openstreetmap.fr/fantoir/#insee=89368=5. Sans garantie, il me semble que j'avais forcé ces rapprochements avec une orthographe différente entre le terrain et FANTOIR. Bingo ;) C'est un bug, alors => https://github.com/osm-fr/bano/issues/205 vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] De la BAN dans BANO... enfin !
Bonsoir, Depuis quelques jours la base Adresses[1] produite par Etalab à partir de multiples sources est intégrée dans BANO. Le produit Adresses est une émanation de l'ancienne BAN, enrichie et diffusée sous licences LO et ODbL. On y retrouve entre autres le Cadastre, ce qui justifie côté BANO de ne plus intégrer le Cadastre en tant que tel. Alimenter BANO avec la BAN, on en parle avec Christian depuis que la BAN existe, en gros. C'est donc mine de rien une étape symbolique importante, rendue possible par l'existence même de BANO. On peut être collectivement fiers d'en être là aujourd'hui, 6 ans après le début de ce graaand lobbying collaboratif libre ;) Débrancher le Cadastre et alimenter BANO avec la BAN à la place a des implications à différents niveaux. Dans le détail : - l'import de données. C'est l'étape initiale et elle est réalisée, c'est pour ça qu'on peut commencer à en parler :). La mise à jour BAN se fait sur un rythme hebdomadaire. - l'export : cette étape reste à faire. Pour l'instant l'ajout de la BAN n'est pas visible pour les consommateurs de BANO. Les fichiers exportés chaque nuit sont encore branchés sur le mix OSM+Cadastre. - les outils de contrôle "Fantoir" [2] tirent parti de la BAN depuis ce soir, d'où ce mail. Vous pourrez observer sur les communes que vous connaissez des changements pour les voies sans rapprochement. Certaines basculent côté "voies sans adresses" car leurs uniques adresses étaient des pseudo-adresses du Cadastre (les adresses en 5000 et 9000) non reprises par la BAN. D'autres font le chemin inverse et deviennent des "voies avec adresse" car le Cadastre (trop ancien ?) ne leur connaissait aucun numéro alors que la BAN en fournit. - le rendu carto. J'ai proposé une pull request [3] qui pourrait faire le job pour que le rendu soit à nouveau fonctionnel. Elle est maintenant dans les mains de Christian pour être prise en compte. Pour info, une discussion (ouverte à tous) se passe à https://github.com/osm-fr/bano/issues/204 pour documenter les process BANO. Et enfin, un merci à Jérôme "Olyon" Amagat qui s'est plongé dans BANO côté traitements et côté rendu carto, avec plein de suggestions constructives. vincent [1] : https://adresse.data.gouv.fr/donnees-nationales [2] : http://bano.openstreetmap.fr/fantoir/ [3] : https://github.com/osm-fr/bano-cartocss/pull/5 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Salon d'amincissement ?
Bonjour, Le 31/10/2020 à 17:21, Cédric Frayssinet a écrit : Comment taguez-vous ce type d'enseigne https://westnordost.de/p/21442.jpg Sans vouloir chercher trop loin, pour moi ce serait un https://wiki.openstreetmap.org/wiki/FR%3ATag%3Ashop%3Dbeauty vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] projet du mois de novembre ? Et projet du mois de décembre
Bonjour, > De: "Nelson Tayou" > > +1, je peux également dégager du temps pour le dev > > Le jeu. 29 oct. 2020 à 16:24, Frédéric Rodrigo < > fred.rodr...@gmail.com > a écrit : > > Moi aussi je suis partant pour aider à remonter CRO, mais si ça sert > principalement à la même chose qu'à l'origine. > Où est-ce que ça discute de CRO ? En plusieurs endroits et dans le désordre (Telegram, https://twitter.com/JulienDamelet/status/1321727330394525696, etc) Concrètement de quoi parle-t-on ? Je ne vois nulle part traitée la question du *besoin*, on pourrait commencer par là. Quels sont les besoins à l'aube de ce 2e confinement ? A quels besoins répondait CRO v1 ? Y a t il convergence entre les 2 ? Pour moi CRO v1 comblait un manque (la gestion des horaires adaptés) et rassurait, aussi en créant du lien entre producteurs d'infos et consommateurs de ces infos sur les horaires. Le manque était lié à la nouveauté de la situation pour tout le monde, et à la sidération qu'elle apportait. Quels sont les besoins aujourd'hui ? Les horaires ? Possible. Les lieux de test ? Possible aussi. Ou trouver du gel et des masques ? A priori non. La question du besoin auquel on cherche à répondre est réelle, et j'ai l'impression d'entendre partout "réouvrons CRO" sans se demander si c'est pertinent côté besoin. Des réponses à ça découlent d'autres questions. Si le besoin de novembre est pile le besoin de mars, alors on peut réfléchir à rouvrir CRO tel que, figé dans sa v1. C'est ce qui demanderait sur le papier le moins d'efforts, mais je doute que ce soit pertinent. Si au contraire il faut faire évoluer le site, fonctionnellement et/ou en l'ouvrant dans de nouveaux pays, alors arrive la question des ressources à y allouer, et ça n'est pas neutre. Comme évoqué par Florian plus haut, qui reprendrait le flambeau, développerait, animerait ? L'équipe de la v1 ne sera(it) pas forcément celle de la v2. à vous lire, vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] BANO : documentation
Bonjour, J'amorce dans ce ticket https://github.com/osm-fr/bano/issues/204 la rédaction d'une doc d'installation et d'utilisation de BANO. L'idée in fine est d'obtenir un document permettant à celles-ceux qui veulent d'installer et faire tourner leur propre instance. Merci à ceux que le sujet intéresse de venir participer sur ce ticket, aussi bien en testant les parties documentées, qu'en aidant à la rédaction et à la mise en forme. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Etiqueter des routes selon le nom du lieu-dit
Bonjour, > De: "Christian Rogel" > > Il me semble qu’il faut y voir une copie de ce qu’on voit dans G Maps > : > Les voies portent le nom des hameaux proches. C’est une simple > facilité. Les autres cartographes en ligne ne le font pas, Apple, par exemple. TomTom a recours au même artéfact que G Maps. Comme tu le dis, c'est une facilité, car ça rend homogènes le modèle de structuration des rues et celui des lieux-dits, ce qui pour les moteurs de recherche d'adresse (= de géocodage) simplifie les algorithmes. Ici ça n'est pas du "taggué pour le rendu" mais du "taggué pour la recherche d'adresse". En tant que consommateur des données je trouve ça très pratique. Mais en tant que contributeur je trouve ça malvenu, on "squatte" un concept (celui de nom de voie, par nature essentiellement linéaire) avec un autre concept : celui de lieu-dit, par nature surfacique même si souvent ses frontières sont floues. Je penche finalement pour une modélisation avec des nodes place=* en considérant qu'ici ce sont aux consommateurs de faire la démarche d'aller cherche ce contenu ponctuel pour le fondre dans les moteurs de recherche au côté des noms de voies et des points d'adresse. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Simplification représentation "Cédez-le-passage cycliste au feu"
Bonjour, > De: "lejun" > > Je suis également perplexe sur la nécessité, non pas d'indiquer où se > trouvent les M12 (référence du panneau à apposer là où se trouve le > feu tricolore), mais d'accompagner le mouvement du cycliste. Sur cette thématique comme sur toutes les autres, comme toujours dans OSM, il n'y a aucune obligation, chacun contribue sur ses centres d'intérêt. > OSM est une base de données visant à représenter l'environnement sur > la base de l'existence physique et la vérifiabilité, en ce sens, > indiquer où se trouve le panneau est justifié. À l'inverse, je ne pense pas > utile de cartographier explicitement la fonction du panneau par des > méthodes souvent complexes. Ce raisonnement poussé à l'extrême nous inviterait > également à créer des relations pour les feux tricolores en apposant > une condition "Ne pas passer quand le feu est rouge". En poussant ce raisonnement, on tagguerait les panneaux "sens interdit" avec un point, à leur emplacement, mais on ne renseignerait pas la fonction avec le tag oneway=* sur les ways. Ca correspondrait bien à l'existence physique, mais malheureusement ça ne permettrait pas dans un logiciel de guidage d'empêcher d'emprunter un sens interdit, car c'est sur le way, et non grâce au node "panneau", que les logiciel de routage prennent l'information pour autoriser ou interdire un parcours. C'est identique dans le cas des cedez-le-passage cycliste. La manière conventionnelle de modéliser une manoeuvre, ou plus souvent une interdiction de manoeure [1] est de constituer un parcours au moyen d'une relation. C'est en effet plus complexe qu'un simple tag sur un unique objet, mais le but recherché est le même : rendre plus intelligent un moteur de calcul d'itinéraire, en lui donnant le maximum d'infos sur le graphe qu'il explore. > En terme d'utilisation, je connais peu d'algorithmes allant jusqu'à > prendre en compte les feux de signalisation lors de la création de > l'itinéraire et je ne pense pas que ces derniers représentent une > part importante des temps de trajets. Je pense qu'un principe important dans OSM est d'accepter de ne pas savoir à l'avance qui se servira de quoi dans la base. On n'a pas (et tant mieux !) toute la connaissance de comment les données qu'on renseigne sont exploitées ici et là. Concernant le fonctionnement des moteurs de calcul d'itinéraire, j'en parle sans savoir qui utilise explicitement les relation Cedez-le-passage, mais en connaissance du fonctionnement des moteurs de calcul car je bosse dans ce domaine. vincent [1] https://wiki.openstreetmap.org/wiki/FR:Relation:restriction ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Simplification représentation "Cédez-le-passage cycliste au feu"
Bonjour, > De: "Éric Gillet" > C'est plus complexe qu'un seul tag sur un seul nœud, de là à dire > "hyper-complexe" pas sûr. Le monde est complexe, pas tout n'est > forcément cartographiable facilement. Pour moi c'est le coeur du sujet ici. On passe notre temps à modéliser le terrain pour le faire entrer dans une base de données, avec la conviction que ce qu'on fait peut servir à d'autres, et sans préjuger des usages. Dans le cas d'un cédez-le-passage cycliste, on peut se demander à quoi donc cela peut servir. Un domaine d'usage reconnu est l'aide à la mobilité, quand on veut exploiter la base OSM pour proposer un trajet, un itinéraire, voire un guidage en temps réel. Et dans ces contextes, où un algorithme va devoir interpréter les données qu'on a saisies, il faut autant que possible supprimer les ambiguïtés, afin que le robot fonctionne au mieux. Pour le guidage, mentionner une manoeuvre implique à la fois de savoir d'où on vient et où on va. Ca permet de donner des instructions comme "tournez à droite", etc. C'est là que les relations OSM sont utiles, car elles décrivent un parcours, depuis un axe (role from) vers un autre axe (role to) en passant par un certain point (role via). Ces 3 infos sont précieuses, et on n'a pas d'autre formalisme que les relations pour les renseigner. C'est plus lourd qu'un simple point, mais beaucoup moins ambigu, donc plus utile. On augmente la valeur des données en allant à ce niveau de détail, clairement. > Certains pourraient suggérer une approche hybride (panneau quand pas > d'ambiguïté, relation quand ambiguïté possible), mais ça veut dire > implémenter logiciellement (et faire comprendre aux contributeurs) > les deux manières de cartographier, ce qui me semble empirer le > problème. D'accord avec ça. Les modélisations multiples sont parfois un mal nécessaire dans OSM (exemple typique : les relations associatedStreet vs les simples nodes addr:housenumber & addr:street) mais quand on part d'une situation assez uniforme comme dans le cas des cédez-le-passage cycliste, je trouverais dommage qu'on évolue vers une modélisation multiple, hétérogène et plus complexe à consommer. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] bâtiment sans numéro de rue
Bonjour, > De: pepilepi...@ovh.fr > Le 08/09/2020 à 16:00, osm.sanspourr...@spamgourmet.com a écrit : > > j'ai un bâtiment (une mairie ) qui est dans une associatedStreet . > > Or selon la mairie et le cadastre il n'y a pas de numéro pour la > mairie qui est entre le 63 et le 65. > > Vaut-il mieux supprimer de l'associatedStreet ou déclarer un faux > positif car elle fait bien partie de la rue ? > > Jean-Yvon > > > Ou écrire au maire pour lui demander de mettre un numéro à sa mairie, > parce que ça fout le bordel dans OSM ? > > En attendant AMHA c'est un faux positif > > JP Le propos des relations associatedStreet c'est de rassembler les n° d'une rue, non ? Pour moi, en l'absence de n°, la relation est inexploitable puisqu'il lui manque ce pour quoi elle est faite. Donc de mon point de vue, si pas de numero, alors pas de relation, je supprimerais. En attendant que le courrier suggéré par JP fasse effet, bien sûr :) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Affichage d'un name suivant le rendu
> De: "Philippe Verdy" > Ben non justement, ce n'est pas "taguer" pour le rendu car les deux > méthodes sont indiquées comme valides et approuvées. Certes il y a > des bogues dans le rendu puisque suivant les cas c'est l'une ou > l'autre méthode qui est visible; mais si on voit les deux c'est > moins grave que ne rien voir du tout. Les 2 méthodes sont valides et approuvées, je suis d'accord. Mais elles sont mutuellement exclusives : si on en choisit une pour un objet du terrain, alors il ne faut pas utiliser l'autre pour le même objet. Toujours le "one feature, one element". > Et même hors du rendu (par exemple pour les recherches) cela n'a pas > de conséquence: on trouve deux objets pratiquement au même endroit. Il y a au moins une conséquence : 2 objets pour la même réalité terrain, ça fausse les statistiques. Avec un polygone "parking" incluant un point "parking" la réponse à la simple question "combien y a t-il de parkings dans la commune ?" devient compliquée, alors qu'elle devrait être simplement la somme des noeuds "parking" et des polygones "parking" si on respecte le principe du "one feature, one element". vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Affichage d'un name suivant le rendu
Bonjour, > De: "Philippe Verdy" > Ce rappel était inutile. Ce sont deux objets de nature différente > même s'ils ont le même nom mais pas la même fonction. Et ce > "doublon" n'est pas gênant: si on crée une surface délimitée par un > polygone, ce n'est pas un noeud de plus qui change la donne en terme > de volumétrie et il n'y a pas d'ambiguité réelle. Dans ton précédent mail tu dis : "un point parking trouvé dans une surface parking" donc on parle bien de 2 objets décrivant la même réalité sur le terrain. Leur nature géométrique est différente mais ce sont bien des doublons sémantiques, chose qu'on cherche à éviter, cf le lien indiqué par Christian. > Et j'avais indiqué "de façon pragmatique". On sait qu'on a des > limites et qu'elles ne vont pas se régler tout de suite. Je préfère > nettement avoir deux objets (de nature différents mais positionnés > presque au même endroit, cela n'induit personne en erreur) que de > n'en voir aucun de façon aléatoire ou ne pas le trouver si on > cherche avec les outils qu'on a actuellement (en attendant qu'ils > soient corrigés). Le fait de "voir ou pas" les objets est de la responsabilité du logiciel qui les affiche, ça n'est pas au contenu lui-même de palier les limites des chartes graphiques. Sinon ça revient à tagguer pour le rendu. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO est-il mort?
Bonjour, De: "Yves P." > au moins on peut essayer d'avoir un avancement minimum. +1 Pour essayer de répondre aux débats, remarques et suggestions : - je comprends le besoin lié à la couche carto BANO. Remettre cette fonctionnalité en route sans dégrader le service n'est hélas pas trivial car ça entraîne le besoin d'intégrer les données BAN Adresses dans BANO. Pour des raisons qui n'ont pas leur place sur cette liste je n'ai eu que peu de temps à consacrer au sujet cet été. Je vais essayer de dégager du temps dans les semaines qui viennent pour amener le développement au point où quelqu'un(e) pourra prendre le relais pour les aspects carto. - il y a sur BANO un déficit de communication récente, qui donne l'impression d'un projet à l'abandon, notamment sur le site openstreetmap.fr. Il y a principalement matière à la fois à récupérer les articles lisibles sur le Drupal de prev.openstreetmap.fr pour les amener dans le Wordpress de www.openstreetmap.fr, et à les actualiser. Sur les aspects techniques de la manip, je ne suis pas plus qualifié que quiconque. Si une personne se sent la motivation de faire ce travail, elle est la bienvenue. Là aussi la motivation et le temps dispo sont les premiers critères, les compétences ça s'acquiert :) - sur la maintenance du code qui fait tourner BANO : j'entends les suggestions de passer à des méthodes qu'on retrouve en entreprise (Scrum, Agile). Libre à ceux que ça motive d'appliquer ces méthodes, évidemment. De mon côté je les trouve excessives par rapport au but recherché (BANO n'est pas QGis, en terme de structuration de projet...[1]) et plutôt hors sujet sur un projet où je contribue sur mon *temps libre*. Je ne vais pas faire de sprints de x semaines sur mon temps libre, c'est antinomique pour moi. Mais le code est dispo est libre, donc ma position sur le sujet n'engage que moi et ne bloquera aucune initiative de ce type. - le passage à BANO v2 a été l'occasion de simplifier le code et de le rendre plus accessible pour des contributions externes. Cependant ça reste un code peu packagé, dont l'installation de 0 n'est sûrement pas aussi fluide qu'il faudrait. Une manière de gagner en résilience serait (et ça peut être lié à une initiative type Agile ci-dessus) de monter une autre instance de BANO, avec mon support mais sans que ce soit moi aux manettes. Ca serait je pense un bon test pour identifier des points de fragilité du code (ah, les tests...), et les (grandes) lacunes de documentation d'installation. Ca me semble l'axe de travail collectif le plus prometteur et efficace, là encore avis aux motivé.e.s Voilà pour des aspects concrets, et que j'espère constructifs, quant à la gouvernance du projet et à son maintien en vie Concernant non pas le fond mais la forme maintenant... On a beaucoup parlé de motivation, de bénévolat, de bienveillance dans ce fil. Je remercie encore Adrien pour son long message [2] qui pour moi résume parfaitement la situation, les fragilités de notre fonctionnement bénévole et volontaire, et les enjeux pour faire perdurer ce modèle sans nous décourager. Je tiens vraiment à ce fonctionnement, qui combine la satisfaction d'oeuvrer au profit d'un bien commun ET d'agir en société ET de s'amuser. Le bien commun c'est la base OSM bien sûr. La société c'est "notre petite société", à savoir nous toutes et tous contributeurs OSM, la "communauté des contributeurs". Je prends cette communauté comme un tout. Je lis plus haut dans ce fil l'expression d'exclusions, de parisianisme, d'élitisme. Oui certain.e.s sur cette liste se connaissent aussi dans la vraie vie. Bien sûr cela aide à fonctionner ensemble (on a commencé BANO avec Christian dans son salon, oui). Pour autant il ne faut pas que ce soit perçu comme un rejet d'autres manières de fonctionner, à distance et en asynchrone. Je dis et redis que les premiers leviers de tous nos travaux sont le temps disponible et la motivation. OSM est une société de "do-o-crates", donc si vous avez l'envie de *faire*, c'est le premier moteur. Le reste (la compétence, les affinités, les amitiés) se greffe,éventuellement, après. Notre "société" n'est pas que virtuelle. J'ai mis un point d'honneur plusieurs années de suite à organiser nos SOTM, qui sont pour moi une des plus belles concrétisation de cette "société". Aux SOTM, la présence de tou.te.s est souhaitée, et chaque année des efforts sont faits pour offrir un accès le plus humble et large possible. Le SOTM c'est une parfaite transition entre "agir en société" et "s'amuser". "Amusez-vous !", comme le rappelle la page d'accueil de JOSM. Pour moi cela implique la bienveillance. Pour moi on est toutes et tous là pour à la fois faire avancer un beau projet, et pour prendre du plaisir à le faire. Le plaisir de la balade, du terrain, de l'entraide, des liens tissés, des compteurs qui augmentent, des jalons (les 36000 limites de communes, le réseau électrique, etc). S'amuser
Re: [OSM-talk-fr] BANO est-il mort?
Le 29/08/2020 à 10:56, PanierAvide a écrit : Le point soulevé n'était pas sur le projet du mois, mais sur la nécessité d'une communication *bienveillante*. Même si les intentions sont bonnes (c'est souvent le cas), les *demandes expéditives sont usantes* : une personne bénévole n'est pas un robot sans âme soumis à bons de commandes. De la même manière qu'on ne peut pas attendre d'OSM une qualité irréprochable des données sur l'ensemble de la planète, on ne peut pas attendre une garantie de service 100% ou une actualisation des briques logicielles en sprints agiles toutes les 4 semaines. On souhaite tous faire avancer le bien commun, faisons-le dans une ambiance bienveillante et accueillante. À quoi ça sert de défendre un modèle d'ouverture sur les logiciels et données si c'est pour communiquer comme le N+1 d'une multinationale qui n'a aucun respect pour son équipe. Une communication bienveillante ne veut pas dire qu'on ne peut pas améliorer la disponibilité ou la rapidité de mise à jour des logiciels, mais dans ce cas il faut : - Soit *mettre la main à la pâte* (on n'est jamais mieux servi que par soi-même) et travailler à plusieurs sur les outils critiques (assurer une continuité de maintenance) - Soit trouver un *budget* (donc émettre un _vrai_ bon de commande) pour que les personnes qui maintiennent actuellement les services y consacrent du temps salarié. Et si on a ni le temps ni l'argent, *revoir ses priorités* ou comprendre qu'une personne bénévole ait des priorités différentes (travail, famille, besoin de s'aérer...). Même si c'est dommage que tel service soit indisponible, ça arrive, c'est la vie. On est tous bénévoles dans ce projet, n'infligeons pas à autrui ce que l'on n'aimerait pas qu'on nous fasse. Le sujet de l'accueil des nouveaux est récurrent, n'oublions pas que si la communauté doit se renouveler, c'est aussi à cause de*la fatigue des personnes présentes de longue date*. Alors évitons de leur rajouter une couche de fatigue inutile. Quand je remonte un problème, soit j'ai la capacité d'aider donc j'aide, soit je n'ai pas la capacité et dans ce cas le problème est remonté en mode "*bouteille à la mer*". Un guide de bonnes pratiques : - Commencer par du *positif* : merci pour cet outil/base/... qui est d'un grand service. Les français sont les champions du monde pour râler, mais très peu iront vous remercier d'un service utile. - *Détailler* le problème : je rencontre tel problème, dans tel contexte technique, à telle adresse... Plus la demande est détaillée, plus le problème sera simple à identifier - *Proposer* une ou des solutions si on peut les envisager, ne pas hésiter à illustrer avec maquettes, captures d'écran... - Et enfin *remercier* pour le temps qui pourra être consacré à cette demande, tout en n'attendant pas une réponse immédiate ni une résolution rapide. Du point de vue extérieur, ça semble idiot de faire des ronds de jambe. Pourtant à l'usage ça réduit largement la charge mentale des personnes qui maintiennent ces services. Chacun a suffisamment de stress dans sa vie pour ne pas vouloir s'en rajouter avec des projets bénévoles. Donc évitons de *dégoûter* à tout jamais les personnes suffisamment motivées pour consacrer du temps au bien commun en communiquant avec elles comme à des sous-traitants pour lesquels on aurait aucun respect. C'était une des tendances lors des présentations du Sotm monde en ligne : la vraie valeur d'OSM n'est pas dans ses données, mais dans sa *communauté*. En résumé, ne disons pas à Vincent "/BANO est mort, c'est con quand même/", mais disons lui "/Merci pour avoir contribué toutes ces années à BANO et merci pour ton engagement régulier. Si nous pouvons t'aider, nous le ferons volontiers. Si nous ne pouvons pas, sache que ce service nous est bien utile dans notre contribution, et que nous serons contents de pouvoir le retrouver le moment venu./". Cordialement, Adrien P. Rien à ajouter à part un *grand* merci à toi Adrien vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO est-il mort?
Bonjour, Le 29/08/2020 à 10:15, Christian Quest a écrit : Le 28/08/2020 à 21:45, Philippe Verdy a écrit : Le ton de tes messages sur ce sujet est particulièrement peu bienveillant. J'ai hésité à répondre. A part critiquer à tout va, que proposes-tu de concret (et réaliste, parce que repasser la bébé à la fondation il fallait oser) pour améliorer la visibilité de BANO, sa documentation, sa qualité ? Merci Christian pour ces réponses et compléments factuels. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO est-il mort?
> De: "Philippe Verdy" > > Il n'y a pas que la carte des points rouges; les pages de suivi par > commune et des rues à intégrer ne fonctionnent pas non plus: c'était > le plus utile. Comme déjà dit, ces pages sont mentionnées ici : https://bano.openstreetmap.fr/ au paragraphe "Outils spécifiques pour BANO" > Je sais que la panne qui a eu lieu était majeure, mais aucune annonce > réelle dessus, aucune indication si ça va être réparé ou pas, et > aucun délai indicatif. Ceux qui s'en occupaient ont visiblemetn > d'autres "priorités" avec des "projets du mois" qui oublient les > projets de fond d'OSM, où les adresses sont une base essentielle > correspondant à des besoins permanents (également demandés et > soutenus par la fondation OSM comme un objectif principal, sur > lequel on peut ensuite fonder énormément de chose que Nominatim, > autre élément clé, ne fournit pas puisque lui s'intéresse aux noms > d'objets et n'a pas d'outils pour les adresses elles-mêmes). Le premier levier pour contribuer c'est la motivation. La mienne est entière mais compose avec mon emploi du temps (dont tu ne sais rien). Et tout ça reste bénévole. Allez, juste un peu de lecture pour finir sur des paroles sages et bienveillantes : https://github.com/vdct/ProjetDuMois/issues/22#issuecomment-678981742 vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO est-il mort?
> De: "Philippe Verdy" > Non. Le wiki est bloqué aussi, pas ouvert. Le wiki n'est pas bloqué, la preuve à l'instant : https://wiki.openstreetmap.org/w/index.php?title=FR%3AFrance%2FWikiProject_Base_Adresses_Nationale_Ouverte_%28BANO%29=revision=2026922=2026914 > Même les exports BANO dans EtaLab sont vieux. Et les pages et outils > de suivi, et les pages des logiciels opensource (GitHub et autres): > tout est vieux et date de 2016. Le code du projet est sur cette branche, qui elle est active : https://github.com/osm-fr/bano/tree/packaging Pour répondre à la question d'Adrien : une fois les données Adresses d'Etalab ajoutées comme source dans BANO, si une personne veut en profiter pour mettre à jour le rendu carto (mélange de requêtes en base de données et de travail sur le style carto avec Kosmtik) ce sera volontiers. Christian a mis au point la v1 de ce style, on ne part donc pas de rien. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO est-il mort?
Bonjour, > De: "Philippe Verdy" > > Pratiquement plus aucun lien concernant BANO ne fonctionne, plus un > seul outil, plus aucune base de suivi, plus aucun rendu. Tu ne donne aucune URL dans ton mail, or c'est bien pratique quand on parle de service, d'indiquer son URL. Ca évite les interprétations. Je vais répondre à ce que je peux, avec le risque de répondre à côté de la plaque, puisque je vais devoir interpréter. Tant pis. > Je sais qu'il y a eu un bogue, mais là ça dure. Que faire en > attendant ? On peut encore utiliser la couche cadastre pour > compléter les numéros de rue manquants dans OSM et voir un rendu > dans les couches OSM classiques (uniquement en fort niveau de zoom) > mais il n'y a plus de suivi sur l'avancement et sur ce qu'on a pu > oublier. Je suppose que tu parle du rendu carto de BANO, les points colorés et les zones rouges à dégommer. Si c'est ça, en effet c'est en panne. La raison : la v1 a été coupée (elle n'était plus mise à jour) et le v2 n'est pas encore développée. Elle a besoin du contenu du produit Adresses [1] qui est pour l'instant absent de BANO, c'est le prochain sujet pour moi [2] > Voir la page "officielle" de BANO assi sur openstreemap.fr , hormis > les articles de présentation et anciennes interviews sur d'autres > sites, plus rien ne fonctionne ou les liens ne sont pas remis à > jour. Si les services ont été migrés il faudrait revoir ces pages de > base sinon BANO sortira aussi de la vue des mainteneur de la BAN, et > les réutilisateurs se tourneront à nouveau vers des contrats aux > licences propriétaires avec LaPoste ou l'IGN. Je ne sais pas de quelle page officielle tu parles. Comme point d'entrée au projet je vois avant tout le wiki [3] et la page d'accès aux services et aux données [4] > La seule chose qui marche ce sont les exports (anciens et peu > actualisés) de la BAN sur data.gouv.fr (EtaLab), où OSM est > totalement oublié ! Les exports de BANO sont rejoués chaque nuit et publiés sous http://bano.openstreetmap.fr/data/ Le wiki n'est pas forcément à jour, mais c'est un wiki, chacun.e peut y mentionner ces infos. > BANO est-il mort ? Mort, jamais. Morte, un jour peut-être. Le B de BANO c'est pour "base" donc féminin :) Blague à part le projet est toujours là, les exports sont publiés, les services autres que le fond de carte sont disponibles (voir la rubrique "Outils spécifiques pour BANO" sur https://bano.openstreetmap.fr/) et début août le Fantoir de juillet a été intégré (merci à deuzeffe pour la veille). Le développement n'est pas bien actif depuis le début de l'été, j'en conviens. Je n'ai pas un temps disponible régulier sur le projet, ça ne veut pas dire que le projet ne vit plus, heureusement. J'espère que ça répond un peu à tes remarques. merci vincent [1] : https://adresse.data.gouv.fr/data/ban/adresses/ [2] : https://github.com/osm-fr/bano/issues/199 [3] : https://wiki.openstreetmap.org/wiki/FR:France/WikiProject_Base_Adresses_Nationale_Ouverte_(BANO) [4] : https://bano.openstreetmap.fr/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : erreur claire d'adrresse
Bonjour, > De: "osm sanspourriel" > > Pour ce point c'est assez facile (vdct ou Christian Quest me > corrigeront > si besoin). > > La BANO tient compte des données OSM donc tu corriges dans OSM. Oui BANO privilégie les données OSM donc pour améliorer BANO en effet, le plus simple et à portée de nous tou.te.s c'est de saisir ce qu'on estime être la bonne version, directement dans OSM. Concernant la màj FANTOIR, BANO est à jour de Fantoir Avril 2020, dernier millésime dispo à https://www.data.gouv.fr/fr/datasets/fichier-fantoir-des-voies-et-lieux-dits/. Pour le sujet de l'inclusion de la BAN dans BANO c'est prévu mais pas encore réalisé. Ce sera aussi le pré-requis à la remise en marche du rendu carto BANO, ça remplacera les données Cadastre et ancienne BAN. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO Josm imagerie
Bonjour,
> De: "Cyrille37 OSM"
>
> Dans Josm le tms de BANO est défini ainsi :
> tms[12,20]:https://{switch:a,b,c}.layers.openstreetmap.fr/bano/{zoom}/{x}/{y}.png
>
> Et il retourne "Erreur, Pas de tuiles à ce niveau de zoom" quelque
> soit le zoom.
Oui, on est au milieu du gué, les tuiles BANO v1 n'existent plus, et les tuiles
BANO v2 pas encore.
La balle est dans mon camp (avec Christian pas loin, merci) mais mon temps ces
jours-ci est difficile à trouver.
merci pour votre patience
vincent
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise à jour BANO
Bonsoir, > De: "Jérôme Amagat" > > Je pense que bano v2 ne gère pas toutes les communes nouvelles vu que > le nom de la commune indiquée par bano est Saint-Jean-sur-Couesnon > qui n'existe plus alors que la commune nouvelle "Rives-du-Couesnon" > créée en 2019 a le même code insee, Saint-Marc-sur-Couesnon est > aussi toujours present > https://bano.openstreetmap.fr/fantoir/index.html#insee=35293=3 Un postulat de base pour BANO était qu'on ne rencontrait qu'une seule occurrence de chaque nom de voie sur le terrain, pour une commune donnée. Pas de bol avec les fusions, qui provoquent le casse-tête (pour tout le monde, pas juste pour BANO) d'homonymies infra-communales, avec x rues de l'Eglise, y place de la Mairie, etc. Je n'ai pas d'idée immédiatement de correctif pour gérer ça proprement, car ça casse un des fondamentaux de BANO. De là à dire qu'il faudrait tout casser pour bien gérer les homonymies, il y a peu. Pour répondre à Pierre-Yves : dispatcher le code Fantoir sur les ways ne changera (hélas) rien au problème. On peut imaginer casser le paradigme de BANO, en donnant l'ascendant au code FANTOIR sur le nom. Ca résoudra les homonymies, pas sûr que ça ne casse pas autre chose... On peut continuer d'en discuter ici, n'hésitez pas à détailler les problèmes directement sur le repo aussi : https://github.com/osm-fr/bano/issues merci vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO ça n'existe plus ?
Bonjour, > De: "Christian Quest" > > La bascule BANOv1/v2 ne s'est pas suffisamment coordonnée pour éviter > ce "trou" et cela s'ajoute à des service installés depuis des années, > qui sont souvent trop stables et donc on laisse la maintenance un peu > trop en friche ;) > > > Le feuille de style qui l'alimente est ici: > https://github.com/osm-fr/bano-cartocss > > Les requêtes SQL sont à revoir pour s'adapter à BANOv2, ce que vdct > comptais faire... Désolé Jacques pour la chronologie. Je confirme que c'est sur (le haut de) ma pile de choses à faire. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] cadastre.openstreetmap.fr ???
Bonjour Hélène, > De: "Hélène PETIT" > > http://cadastre.openstreetmap.fr/ > > me donne une 403 forbidden. > C'est normal ? Pas forcément, mais tu peux accéder à une partie des ressources via https://bano.openstreetmap.fr/ vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Facebook achète Mapillary !
Bonjour, > De: "Jacques Lavignotte" > > Le 19/06/2020 à 16:15, PanierAvide a écrit : > > > De quoi a-t'on besoin pour voir un tel mécanisme émerger ? > > De promouvoir des projets communautaires ? Ce sujet a besoin du même carburant que tous les autres sujets : avant le temps humain de tou.te.s, avant l'infra, il faut quelqu'un.e qui *porte* le projet/sujet. On peut identifier tous les besoins de la terre, se plaindre qu'ils ne soient pas couverts, on ne changera pas l'élément déclencheur : une personne, quelle qu'elle soit, qui se sent la motivation d'animer le sujet, de "recruter" si besoin les bonnes personnes, et de pousser le projet de l'avant. Il n'y a aucune magie derrière Osmose, Pic4Review, une cartopartie ou un SOTM. Il y juste un/une/des gens qui portent le sujet. Et ce n'est pas une question de compétences, ou de présence au CA d'OSM-FR, ni même d'adhésion à l'asso OSM-FR. C'est avant tout une question d'envie. Donc pour être clair : si quelqu'un.e a *envie* qu'un démonstrateur "proxy Mapillary/OSC" voit le jour, qu'il/elle n'hésite pas à se lancer, à le faire savoir, voire à donner à d'autres l'envie de monter dans le même bateau. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] type de rivière pour la bièvre
Bonjour, > De: "Francois Gouget" > > On Tue, 9 Jun 2020, Brice wrote: > [...] > > Concernant la partie la plus en aval, la Bièvre entre dans le > > réseau des > > égouts de Paris. J'ai récemment dessiné cette partie aval en > > choisissant > > au mieux des tronçons d’égouts (pipeline) pour avoir la continuité > > jusqu'à la Seine. Un sujet connexe, toujours sur la Bièvre ou ce qu'il en reste : il existe dans le XIIIè et le Vè des repères au sol, sous forme de plaque avec un texte indiquant que la Bièvre passait par là avant. Quelques photos d'exemples ici : http://parismamanetmoi.com/2012/09/04/sur-les-traces-de-lancien-lit-de-la-bievre-dans-paris/ J'en avais fait le recensement (j'en ai une cinquantaine en stock), mais à peine commencé leur saisie dans OSM [1] et [2] car j'avais des doutes sur la bonne manière de les tagguer. vincent [1] : https://www.openstreetmap.org/node/484011 [2] : https://www.openstreetmap.org/node/484008 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import de points d'eau incendie en Saône-et-Loire
> De: "GarenKreiz" > > J'ai la même question pour la liste de l'Ille et Vilaine. Lors de mes > sorties de confinement, j'ai pu vérifier la qualité générale des > données (une seule bouche à incendie positionnée à quelques mètres > de l'autre côté d'une allée) et m'interroge sur l'étape suivante. > Etant donné que ces équipements ne sont censé être utilisés que par > des professionnels qui a priori bénéficient déjà de cette liste, à > quel usages correspondrait leur intégration dans OSM? En voilà une bonne question. On pourrait aussi l'appliquer à d'autres gestionnaires de réseau. Quel intérêt de placer dans OSM les armoires de rue ? Les pylones ? etc. En pratique, pour l'usage immédiat, c'est vrai qu'à part les professionnels qui utilisent ces équipements on ne voit pas bien qui ça peut intéresser. Je vois au moins un autre public possible : celles-ceux qui souhaiteraient reconstituer le "paysage" en un endroit donné, le plus fidèlement possible, par exemple pour une scène de jeu video. Dans ce cas, tout ce qui est susceptible de raffiner l'information est bon à prendre : arbre, mais aussi sa hauteur, son espèce, trottoir, mais aussi sa largeur, buulding, mais aussi le type de façade et de toiture, etc etc. C'est infini ? Oui. Les bornes incendie en font partie ? Oui. Comme les pylônes, les armoires de rue, et le reste. Donc ne pas se censurer :) Pour revenir à l'usage par les professionnels : avoir un jeu de données dans OSM, qui ne soit pas juste une photocopie d'un jeu Open Data, mais qui soit maintenu, amélioré au fil du temps, par les pros eux-mêmes mais aussi par n'importe quel contributeur, est un très bon exemple à montrer aux pros en question pour leur illustrer tout l'intérêt d'OSM. Pour parler des bornes à incendie (c'est un peu mon dada) : j'en ai au fil du temps observé un bon paquet avec des anomalies, soit par rapport aux jeux de données OD (exhaustivité, qualité du positionnement), soit par rapport au terrain (doublons d'identifiant sur une même commune...). On a donc matière à améliorer les données OD, qu'il ne faut surtout pas prendre pour la vérité absolue. J'avais audité le fichier OD des bornes incendies d'un département de banlieue parisienne il y a quelques années : les bornes avaient beau être relevées par les pompiers eux-même, c'était truffé d'erreurs de positionnement assez sévères. Là où je veux en venir : en montrant aux pros qu'on peut améliorer leurs propres données, on peut par extension les convaincre de l'intérêt de la foule (nous) pour consolider un jeu de données géographiques. Les pompiers s'intéressent énormément aux adresses. Si au travers d'une mise en qualité des bornes on les convainc de l'intérêt "tout court d'OSM, au point qu'ils renseignent dans OSM l'émergence de nouvelles rues et adresses, alors on aura gagné des contributeurs de grande valeur. Rien que pour ça ça vaut le coup. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suspicion d'usage massif d'une source non autorisée
Bonjour, > De: "blef" > > Je ne veux pas être parano ni accusateur, mais j'ai l'impression que > notre contributeur passe son temps à se promener sur Google Maps et > à recopier scrupuleusement son contenu sur OSM. > J'aimerais avoir votre avis là-dessus. Tes observations sont étayées, et tu as contacté le contributeur. Attends de voir s'il réagit à ce message, que tu peux peut-être doublonner par un message direct (via la messagerie OSM) hors changeset. Si tu constates qu'il recommence à contribuer sans avoir répondu, alors ça peut valoir le coup de signaler le cas au DWG [1] pour un blocage temporaire, qui lui imposera de lire les messages avant de recommencer à contribuer. Ce sera l'occasion de voir s'il en tient compte. vincent [1] : https://wiki.openstreetmap.org/wiki/Data_working_group ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] import cadastre d'une petite zone
Bonsoir-nuit > De: "Jérôme Amagat" > > Je n'y connais pas grand chose mais je ne pense pas que la débauche > d’énergie soit dans ce sens, dans le premier cas c'est juste un > téléchargement dans l'autre il faut récupérer les données dans les > pdf. > Moi je préfères la méthode via le plugin josm, par contre aujourd'hui > ça ne marche pas :( > Il faut prendre l'habitude de sélectionner une zone très petite pour > ne télécharger qu"une planche et faire attention de ne pas > télécharger dans la planche avec les données osm... La mise à jour > trimestriel, ne m'a que très rarement posé un problème. Sur > cadastre.openstreetmap.fr c'est très long pour avoir une commune en > entier maintenant que les pdf sont plus petit. La méthode sur cadastre.openstreetmap.fr à base de scrapping des PDFs a eu son heure de gloire (et son efficacité) jusqu'au jour où la DGFiP a modifié le paramétrage de la fonction d'impression PDF à laquelle on accédait, pour en effet diviser par 100 la surface imprimable d'un seul tenant. Dans le cadre de BANO on maintenait à jour un cache des données du Cadastre en récupérant toutes les communes mises à jour au fil de leur parution. Pour continuer "comme avant" il aurait fallu compenser le facteur 100 en faisant 100x plus d'appels aux serveurs de la DGFiP... qui nous a demandé de lever le pied. C'est une des raisons de BANO v2 : le changement d'approvisionnement de la source Cadastre pour ne plus dépendre des PDFs, et ne plus solliciter les serveurs de la DGFiP. On y a perdu en actualité, le Cadastre Etalab étant mis à jour par trimestre, et en précision dans les zones téléchargeables en effet, puisqu'on fonctionne par feuilles entières. Mais on y a (je trouve) gagné en ergonomie puisqu'on peut rester dans JOSM quand on veut des données, via le plugin Cadastre actualisé par Vincent Privat. Plus besoin de sortir de JOSM, aller sur cadastre.openstreetmap.fr, chercher sa commune, sélectionner sa zone, attendre, récupérer les données, les ouvrir dans JOSM. Je rejoins Jérôme là dessus. Tout ça reste affaire de goût, je suis d'accord. En revanche, gardez à l'esprit la demande de la DGFiP. Le moins on se sert directement via les PDFs le plus on respecte leur souhait et leurs serveurs, ce qui serait élégant de notre part vus le service énorme qu'ils nous ont rendu dès 2008 (coucou DenisH) en nous autorisant à piocher dans leurs données, bien avant la vague de l'OpenData. En complément, le service sur cadastre.openstreetmap.fr n'est quasi plus maintenu. Il reste actif mais gagnerait à être coupé, tant vis-à-vis de la DGFiP que faute de mainteneurs. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Moulinette pour lire EXIF, générer GPX, et préremplir dans JOSM?
> De: "Shohreh" > > Oui, mais y a-t-il un moyen de pré-ajouter des nodes pour réduire un > peu le boulot ? Ca ne réduit pas le boulot je pense. Si tu sous-entends que c'est à JOSM de les ajouter pour toi, d'une je ne connais pas la fonction magique pour faire ça, et de deux j'espère que ton coup d'oeil pour choisir l'endroit du node shop=* a plus de valeur que le résultat d'un algorithme, dont je ne vois pas trop sur quoi il s'appuierait pour ajouter un node à un endroit pertinent. Ajouter un node, c'est juste un double-clic, je pense que chercher à l'optimiser va surtout te faire perdre du temps. Plus généralement, ajouter des infos dans OSM suite à une collecte terrain, c'est pas du travail mécanique, c'est vraiment à voir comme du jardinage : c'est manuel, subjectif, avec tes partis-pris, ton jus de cerveau, et ta mémoire des lieux visités... vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
