Re: [OSM-talk-fr] version française du wiki de l'attribut "place=neighbourhood"
Bonjour, Le 23/04/2024 à 12:54, lenny.libre via Talk-fr a écrit : Bonjour ! La version FR https://wiki.openstreetmap.org/wiki/FR:Tag:place%3Dneighbourhood est beaucoup moins remplie que l'EN https://wiki.openstreetmap.org/wiki/Tag:place%3Dneighbourhood Pour les mettre en phase, je l'ai fait sur une page brouillon https://wiki.openstreetmap.org/wiki/User:Lenny/Occitanie/liO Avant de le mettre sur la bonne page du wiki, j'aimerais si possible avoir votre avis. La difficulté que je trouvais, c'est que les pages wikipedia anglaises : https://en.wikipedia.org/wiki/Neighbourhood et https://en.wikipedia.org/wiki/Quarter_(urban_subdivision) renvoie toutes les deux vers la même page française https://fr.wikipedia.org/wiki/Quartier_(ville) Oui en France, en général, il s'agit de petits lotissements et de groupes résidentiels parfois privés. À mon avis cela peut aussi concerné des petits quartiers officieux, non répertoriés officiellement par la commune pour des raisons diverses (historiques, coutume et habitude locale, ou autres). En tout cas merci pour ce travail. -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Accès très limité à BD Carthage
Le 17/04/2024 à 11:04, Christian Quest a écrit : La couche carthage était indisponible, j'ai corrigé ça hier soir. Le forum n'est pas du tout sur la même infra, donc aucun lien entre les deux. Un problème DNS ça se voit en début de connexion à un service (pour trouve l'IP du service), après ça ne doit avoir aucun impact, l'info est en cache sur ta machine. Merci Christian ! Ça marche impeccable. J'ai abusé avec mes histoires de DNS et forum.Ça n'a effectivement rien à voir. Merci aussi à Thomas. J'avais cherché ces ressources mais pas trouvé. C'est parfait. -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Accès très limité à BD Carthage
Bonjour, J'ai depuis quelques jours, un accès très limité et très lent à BD Carthage (plans et cours d'eau). J'ai ai vraiment besoin pour ajouter des plans d'eau peu visibles à OSM. (L'accès au forum est aussi assez lent chez moi). Je me demandais si cela venait de mes accès DNS ou bien si c'est dû aux serveurs OpenStreetmap.fr. J'ai vu plusieurs rapports de problèmes sur Github. Serais-ce lié ? -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Banc de sable visible seulement l'été dans un fleuve
Le 04/03/2024 à 11:34, Marc_marc via Talk-fr a écrit : Bonjour, Le 04.03.24 à 10:13, rpnpif a écrit : https://www.openstreetmap.org/#map=17/47.38079/-0.63932 Je propose que les bancs de sable de ce genre de fleuve et seulement dans ce cas ne soient pas représentées par un attribut natural=shoal seasonal=dry_season surface=sand comme élément indépendant je pense qu'il y a un problème de rendu : l'aspect intermittent de natural=shoal n'est pas rendu. Le rendu eau par intermittence te parait mieux ? ce serrait une amélioration/correction à proposer mais sous la forme : natural=river shoal=yes seasonal=dry_season (facultativement surface:dry_season=sand) sémantiquement, un banc de sable intermittent n'est pas une rivière, mais une partie de la rivière. je trouverai + logique de faire comme pour les places de parking ou les parties de bâtiments : avoir un tag qui dit que c'est une sous-partie. Quelque chose du genre (à affiner) : natural=river_part intermittent=yes seasonal=dry_season + éventuellement dry_season=water ou river ? wet_season=sand éventuellement avec le prefixe surface Oui ce serait une solution plus correcte. Où suggère t-on cela ? Sur la liste tags ? un rapport à github du rendu d'OSM ? Les deux ? -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Banc de sable visible seulement l'été dans un fleuve
Bonjour, Beaucoup de fleuves comportent des bancs de sable comme la Loire qui en a beaucoup. L'été, dans certains secteurs comme entre Orléans et Ancenis, la Loire est majoritairement une étendue de sable dans de nombreux secteurs. Alors que l'hiver, elle est pleine d'eau à ras bord et le sable est invisible. Comme les contributeurs naturellement cartographient surtout l'été pendant leurs vacances ou bien à partir de photos aériennes prises l'été par temps clair, ils ne voient que les bancs de sable ce qui ne correspond pas à la réalité de l'année. Par exemple, à Béhuard https://www.openstreetmap.org/#map=17/47.38079/-0.63932 Le problème est que sur les représentations de la carte on ne voit que les bancs de sable alors que l'élément majeur devrait être le fleuve donc l'eau visible souvent d'octobre ou novembre à avril ou mai. Quand un utilisateur va sur le terrain à partir de la carte officielle ou d'OsmAnd, il ne reconnaît pas le terrain une majeure partie de l'année. Je sais que l'on ne cartographie pas pour le rendu mais ici, il y a un problème de hiérarchie de données : l'eau prédomine sur le sable sinon ce n'est pas un fleuve et ne correspond pas à la réalité la plus fréquente. Je propose que les bancs de sable de ce genre de fleuve et seulement dans ce cas ne soient pas représentées par un attribut natural=shoal seasonal=dry_season surface=sand comme élément indépendant mais sous la forme : natural=river shoal=yes seasonal=dry_season (facultativement surface:dry_season=sand) flood_prone étant réservé aux zones avec des crues épisodiques mais pas régulières. Qu'en pensez-vous ? -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Lieux de fraîcheurs
Bonjour, Le 29/02/2024 à 22:16, Marc_marc via Talk-fr a écrit : Bonjour, Le 29.02.24 à 21:54, Sébastien Dinot a écrit : https://wiki.openstreetmap.org/wiki/FR:Key:air_conditioning le gros soucis de ce tag c'est que cela ne dit ni la température, ni le besoin du batiment. un local vitré plein sud climatisé et bien éblouissant, ce n'est pas nécessairement + "rafraichisant" qu'une veille chapelle Inversément le supermarché à 20°, c'est, de mon point de vue, à fuir quand il fait 35° sauf si vous souhaitez y rester jusqu'à 2h du mat : en sortant de là, c'est coup de bambou assuré telement que l'écart de température est important Auriez-vous connaissance de tags dédiés ? il y a aussi shade https://wiki.openstreetmap.org/wiki/Key%3Ashade mais qui a le défaut de mal juger la qualité que cela apporte : une terrase sur une place betonnée/asphalté, même ombragé, c'est beaucoup moins bien qu'une entourée d'arbre Je suis aussi d'accord avec Marc. La fraîcheur est une notion subjective sauf si elle est repérée par un panneau, de la municipalité par exemple. Sinon, je ne vois pas comment la qualifier. Les arbres ou les zones humidifiées comme les fontaines et jets d'eau peuvent aussi être considérés comme des lieux de fraîcheurs mais ils ou elles doivent être repérées sur le terrain. Cela n'empêche que si vous avez une solution, je suis aussi intéressé. Cordialement. -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise à jour de POLE EMPLOI
Le 14/02/2024 à 15:55, Bruno Remy via Talk-fr a écrit : Bonjour, Je suis d'accord avec toi Marc. A partir du moment où il y a eu une réorganisation administrative générale, toutes les agences sont devenues "FRANCE TRAVAIL" et le changement des enseignes sur les façades n'est pas impactante. Dans ce cas la dénomination officielle prime sur le repérage terrain et on peut faire un remplacement généralisé. Merci pour le lien wiki sur la modification automatisée.Je veux bien suivre cette procédure sur le plan administratif : référence aux discutions, documentation sur une page wiki, etc par contre je ne vois toujours pas comment techniquement faire ce remplacement automatisé? Oui mais il faut garder Pôle emploi dans old_name afin de faciliter la recherche sur l'ancienne dénomination au moins pour quelques années. -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Couche admin9 de layers.opesntreetmap.fr
Le 20/11/2023 à 19:23, David Crochet a écrit : Bonjour sur layers.openstreetmap.fr, la couche admin9 renvoie beaucoup de tuiles inopérantes. vous avez une idée ? Bonjour, Probablement en lien avec mon message précédent. Une panne probable d'une machine en serait la cause. Je crois que l'enquête est en cours. -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tuiles manquantes à zoom=17
Le 17/11/2023 à 19:12, Rpnpif a écrit : Le 16/11/2023 à 20:58, Marc_marc a écrit : Le 16.11.23 à 20:37, Marc_marc a écrit : d'autant + élevé que tu n'es pas authentifié et que tu ne les visualises pas depuis osm.org je vpulais dire : d'autant + sévère (donc d'aautant + basse) Oups je ne me souvenais plus que je prenais des tuiles françaises. sur openstreetmap.fr. J'ai peut-être atteint une limite. Merci Marc de cette piste, je vais creuser pour résoudre ce problème pour un site associatif. Le problème est le même sur https://leaflet-extras.github.io/leaflet-providers/preview/ où les tuiles pour zoom=17 n'apparaissent pas ni celles pour zoom>18 pour OpenStreetMap France. Bizarrement zoom=18 fonctionne sur ce site, au moins sur certaines zones. Peut-être lié aux Issues déclarés sur GitHub Osm-fr. Le serveur de tuiles aurait des difficultés. On va patienter. Merci à ceux qui sont sur le pont. Bon week-end. -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tuiles manquantes à zoom=17
Le 16/11/2023 à 20:58, Marc_marc a écrit : Le 16.11.23 à 20:37, Marc_marc a écrit : d'autant + élevé que tu n'es pas authentifié et que tu ne les visualises pas depuis osm.org je vpulais dire : d'autant + sévère (donc d'aautant + basse) Oups je ne me souvenais plus que je prenais des tuiles françaises. sur openstreetmap.fr. J'ai peut-être atteint une limite. Merci Marc de cette piste, je vais creuser pour résoudre ce problème pour un site associatif. -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tuiles manquantes à zoom=17
Le 16/11/2023 à 17:31, Jean-Claude Repetto a écrit : Le 16/11/2023 à 17:07, rpnpif a écrit : Bonjour, Je fais du développement avec Leaflet et OpenStreetmap. Les tuiles dès le niveau de zoom=17 sont déclarées manquantes (erreur 404). Je les ai demandées une dizaine de fois pour mes tests. J'ai l'impression qu'avant je pouvais accéder au zoom 19 sans problème. Savez vous s'il y a une limite au nombre de chargement des tuiles identiques d'une même zone et une même adresse IP ? Si oui elle doit être assez basse. Bonjour, Pourrais-tu donner les URLs de quelques-unes de ces dalles pour vérifier si d'autres personnes y ont accès ? Par exemple, ces tuiles ou dalles ici : https://c.tile.openstreetmap.fr/osmfr/17/65209/45793.png qui est pourtant visible sur https://www.openstreetmap.org/#map=17/47.57090/-0.88942 et ce sur une bande Ouest-Est d'environ 10 km autour. Dans d'autres secteurs de ce département, c'est la même chose. Afin d'évacuer les problème de cache navigateur et blocage d'adresse IP, je viens d'essayer avec Firefox et Chromium et deux adresse IP extérieures différentes. Il reste que c'est le même serveur extérieur portant Leaflet qui appelle les pages. Le nom de domaine serait-il pris en compte et seul le site officiel OSM serait protégé de ce problème ? Ou bien est-ce un problème général de Leaflet ? Merci de l'aide. -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Tuiles manquantes à zoom=17
Bonjour, Je fais du développement avec Leaflet et OpenStreetmap. Les tuiles dès le niveau de zoom=17 sont déclarées manquantes (erreur 404). Je les ai demandées une dizaine de fois pour mes tests. J'ai l'impression qu'avant je pouvais accéder au zoom 19 sans problème. Savez vous s'il y a une limite au nombre de chargement des tuiles identiques d'une même zone et une même adresse IP ? Si oui elle doit être assez basse. -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Absence de crédit sur le site de la Fédération Française de Généalogie
Le 25/09/2023 à 23:32, Yannick a écrit : Bonsoir, Je viens d'adresser le message suivant via leur blog où se trouve le formulaire de contact: "Bonsoir, Vous utilisez un fond de carte OSM sur la page suivante https://genefede.com/genealogis/archive. Vous omettez de créditer les contributeurs d'OSM ce qui est obligatoire pour utiliser ce système cartographique. En tant que utilisateur et contributeur d'OSM cela me choque. En tant que généalogiste je suis choqué que l'instance fédérale française ne montre pas l'exemple en citant ses sources. Vous voudrez demander à votre prestataire de faire promptement le nécessaire. Amitiés" En espérant que cela bouge rapidement mais j'ai des doutes car il y a du rififi au sein de cette instance. Amitiés Le truc marrant que je ne connaissais pas, c'est que désormais la page en question s'orne d'un avertissement « L'attribution n'est pas une option «. Super ! -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Geoportail et erreur de certificat. Planté !
Je me réponds ; c'est une maintenance lourde programmée et très mal annoncée à partir d'un serveur de secours. Le 24/09/2023 à 09:10, rpnpif a écrit : Bonjour, Un peu HS ce sujet. Mais https://www.geoportail.gouv.fr/ a une erreur de certificat Letsencrypt périmé depuis... le 30 novembre 2022 ! C'est un peu étrange pour un site aussi important. Peut-être une erreur de manipulation ? Ah bin non, c'est planté ! Ils renvoient vers Twitter avec un message du ... 5 février parlant de l'incident ! Encore bizarre. Il faut dire que Twitter-X est aussi à la ramasse. -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Geoportail et erreur de certificat. Planté !
Bonjour, Un peu HS ce sujet. Mais https://www.geoportail.gouv.fr/ a une erreur de certificat Letsencrypt périmé depuis... le 30 novembre 2022 ! C'est un peu étrange pour un site aussi important. Peut-être une erreur de manipulation ? Ah bin non, c'est planté ! Ils renvoient vers Twitter avec un message du ... 5 février parlant de l'incident ! Encore bizarre. Il faut dire que Twitter-X est aussi à la ramasse. -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] présentation
Le 25/04/2023 à 16:34, Christian Rogel a écrit : Le 25 avr. 2023 à 12:08, Bernard Lefrançois via Talk-fr a écrit : Le 24/04/2023 à 22:48, Christian Rogel a écrit : C’est comme qu’on peut voir qu’ « associated_street » ne fait « l’unanimité » qu’en France (c’est un gimmick Fr de se précipiter sur ce qui semble plus malin). L'unanimité, c'est pas un peu vite dit? Bon, c'était entre guillemet. Ironique? Oui, c’était ironique, mais, c’est pour marquer qu’on a lu des plaidoyers pour associated_street, mais pas pour la manière originelle. Dans la vraie vie, c’est iD est largement utilisé et son interface favorise la « tradition », car mettre une relation est un poil plus compliqué. On a eu ouï dire qu’une majorité de la communauté d’Allemagne (quid des Autrichiens ou des Suisses ?) préférait ne pas mettre de relation. Je rattache les numéros manquants à une relation, s’il y en a une, et je fais les nouveaux adressages à la paresseuse. Christian R. Bienvenue. Il y a aussi le troll, pardon la concurrence, natural=wood versus landuse=forest. :3 -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mapbox contribute ?
Le 13/03/2023 à 12:08, jb...@mailoo.org a écrit : Une question absurde. Serait-il possible que les éléments proviennent d’OSM avant le changement de licence ? C’est tellement périmé ou incohérent… JB. Cela n'expliquerait pas l'incohérence à mon avis. Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mapbox contribute ?
Le 13/03/2023 à 10:24, Dominique Rousseau a écrit : Le Sat, Mar 11, 2023 at 05:18:43PM +0100, deuzeffe [opensm@deuzeffe.org] a écrit: sur ce site https://www.mapbox.com/contribute il est proposé de contribuer mais il est difficile de comprendre à quelle base la contribution est faite ni de quelle base les points d'intérêts sont extraits. @mapboxteam, pourrriez vous nous expliquer d'où proviennent les données et qu'est ce qui est fait des contributions svp ? Dans ma zone de contribution, je ne reconnais pas vraiment les points d'intérêts, donc cela ne provient pas d'OpenStreetMap, je ne sais donc pas où peuvent aller mes éventuelles contributions ! Je certifie que les données ne viennent pas d'OSM : rarement vu une telle mauvaise qualité des données dans ma ZdC... Et ça ne vient pas de GG non plus, tout autant bourré d'erreurs mais pas les mêmes ^^ (il y a même des données perso. :/) +1 Le positionnement est "hasardeux" ( quelques dizaines voire centaines de metres pour certains points, la ou j'ai regarde ) et doit sortir d'un traitement automatise. Pour les points qui apparaissent, c'est a la fois "a jour" sur certains trucs relativement recents, et completement "obsolete" pour d'autres. Effectivement, c'est du grand n'importe quoi ! Pour un opérateur partenaire aussi important pour OSM, c'est inquiétant. Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] OsmAnd et la recherche d'objets.
Bonjour, Comme je vois des discussions sur Nominatim, cela me fait penser que son système de recherche n'est pas si mal. Par contre, OsmAnd, plus ou moins basé sur Nominatim, je crois, a un système de recherche assez médiocre. Le tri de ce qui est trouvé y est mal fait. Par exemple, si on cherche un village par son nom, on tombe en priorité sur des rues comportant ce nom, le village lui-même étant listé loin dans la liste. Quand on cherche autre chose, il est rare d'avoir une proposition pertinente. Il y a quelques années, j'avais vu une amélioration annoncée mais peu de choses effectives en réalité. Savez-vous pourquoi cette médiocrité ? Pourquoi OsmAnd n'arrive pas à résoudre ce problème pourtant assez bien géré dans les autres applications utilisant OSM ? Qu'est-ce qui bloque ? Le mainteneur ? La complexité du système ? Le fait qu'OsmAnd soit hors ligne ou sur Android ? -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Accessibilité d'une ville : recommandations
Bonjour, Le 08/12/2022 à 12:04, Noémie Lehuby via Talk-fr a écrit : Bonjour Daniel, Pour ta problématique de recherche, tu peux essayer avec Qwant Maps. Si je reprends ton test initial avec la carte positionnée sur la gare de Palaiseau Villebon et que je tape "mediatheque" j'obtiens les résultats suivants : J'ai donc 1 résultat sur Villebon et plusieurs sur Palaiseau. S'il n'y a pas la médiathèque que tu cherchais dans le liste, tu peux utiliser le "premier résultat" qui est en fait un bouton d'action pour lancer une recherche spécifique de bibliothèques autour de ce lieu (et pas juste de points d'intérêts qui ont un nom qui ressemble à médiathèque). Avez-vous essayé Organic Maps très simple et dont la recherche est probablement plus facile qu'avec OSMAnd ? Sinon, un rapport de bogue à OSMAnd serait bien utile. https://github.com/osmandapp/OsmAnd/issues -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Nombre de population des communes déléguées pas à jour
Bonjour, La population des communes est mise à jour par Christian, je pense. Merci à lui. Mais je viens de voir, contrairement à ce que je croyais, que l'INSEE publie aussi la population des communes déléguées à l'intérieur des communes dites nouvelles. Certaines données datent de 2008, souvent de 2013 alors que le recensement officiel est de 2019. Serait-il possible de mettre à jour en masse celles-ci comme on le fait pour les autres communes ? C'est une donnée qui me parait intéressante, entre autres pour certains rendus. Cordialement. -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Population des villes
Le 08/10/2022 à 11:38, Marc_marc a écrit : Bonjour, Le 08.10.22 à 10:52, Arnaud Champollion a écrit : il faut indiquer aussi les populations de chaque hameau ? il ne faut rien, mais si tu as une source, c'est possible de le faire La relation et le "place" ont la même population ( pourtant il y a des hameaux). donc l'un des 2 est faux Bonjour, Le mot ville est sujet à ambiguïté. Une ville peut être l'ensemble de la commune ou seulement l'agglomération. Pour moi, c'est simplement une information en double sur l'admin_centre. C'est assez fréquent. -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] dalles Lidar IGN colorisées en cartographie OSM
Le 13/09/2022 à 15:05, Pierre Beyssac a écrit : Bonjour à tous, Comme vous le savez peut-être, l'IGN a commencé à distribuer en opendata ses scans Lidar haute résolution (10 points/m²) du territoire français, et c'est superbe. ... Intéressant en effet. Sous Firefox, il signale que ce navigateur est trop peu performant pour visualiser le démonstrateur. Par contre, Chromium n'a pas cet avertissement. Pourtant sur mon système, Chromium est légèrement plus lent que Firefox qui fonctionne bien sur le démonstrateur. J'ai l'impression qu'ils confondent réseau lent et trop peu de mémoire (chez moi) avec la vitesse d'affichage du navigateur, Ou alors ces dév. de l'IGN seraient partisans ? Pourrait-on mesurer les hauteurs avec ce système afin de récupérer la valeur pour OSM ? -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] extraire les exif gps
Bonjour,
Le 13/09/2022 à 18:45, Eric SIBERT a écrit :
> Je cherche - pour linux - l'équivalent du truc windows : dnrgps.exe
> qui exporte les données gps d'une collection de photos vers un
fichier csv.
Spontanément, je regarderais avec ExifTool en lui demandant d'extraire
les champs qui vont bien.
J'aime bien aussi exiv2. ("apt install exiv2" sous Debian, Ubuntu ou
Linux Mint ou etc.).
--
Rpnpif
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment faire? forêt broadleaved & needleleaved
Le 04/09/2022 à 22:07, pepilepi...@ovh.fr a écrit : Pour moi landuse=forest c'est une propriété (publique ou privée) plantée d'arbres, entretenue et exploitée par son propriétaire alors que natural=wood c'est une zone où beaucoup d'arbres poussent en vrac sans que quiconque s'en soucie... Il y a de nombreux exploitants qui ne sont pas propriétaires. Et même certains utilisateurs qui ne sont pas exploitants comme ceux qui cueillent du bois ou se promènent dans les forêts publiques sans droits spécifiques. Plutôt que de propriété parlons plutôt d'utilisation (use en anglais d'où landuse). Pendant quelques années, des parcelles en régénération naturelle récente de l'ONF poussent en vrac puis sont « entretenues ». Pas simple de savoir au premier abord ce qui est exploité ou pas sauf si un acte officiel existe 'en mairie par exemple). Des propriétaires délaissent des bois ou forêts puis se mettent à exploiter brutalement. Donc on était bien face à des espaces exploités ce qui était invisible avant. C'est pour ça que je dis que 90 à 99% des forêts sont exploitées en France. -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment faire? forêt broadleaved & needleleaved
Le 08/09/2022 à 17:01, Marc_marc a écrit : Bonjour, Le 08.09.22 à 10:19, Rpnpif a écrit : des forêts primaires (en général en Afrique ou en Amérique du Sud par exemple) ou des forêts ou bois interdites d'exploitation (en Europe) pourquoi ne pas encoder cette nuance dans son propre tag ? cela permettrait, indépendament du choix natural=wood <> landuse=forest à qui le souhaite de connaitre cette info (parce que l'utilisateur de donnée n'a aucun moyen de séparer les 6 approches différentes si celle-ci ne s'appuient pas en plus sur un tag par sens ? par ex : non exploitée ? managed=no ou =forbiden foret vierge managed=never (encore que...) je vais essayer d'améliorer la page en question pour mettre en avant les tags existant pour sortir de "info inexploitable" Ce serait une bonne idée, mais on se heurte aux habitudes, au moindre effort (une seule clé au lieu de deux) et au double sens en français de bois (natural=wood) : petit espace boisé et cette soi-disant forêt non exploitée. On met le doigt sur la cause de la pérennité de cette situation ambiguë qui vient à la fois des pratiques des contributeurs et des traditions locales d’appellation. Autre cause aussi comme je l'écrivais, la plupart des forêts françaises sont exploitées. Toutes, dit Francis Hallé, le défenseur des arbres, qui veut en préserver quelques unes. Pas simple. -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment faire? forêt broadleaved & needleleaved
Bonjour,
Le 06/09/2022 à 07:17, David Marchal via Talk-fr a écrit :
[...]
boundary=forest, tel qu’approuvé, ne fait que désigner une emprise de
forêt, qu’elle soit exploitée ou non, boisée ou non, et accepte tout à
fait que des zones soient exploitées et d’autres non. Elle correspond,
en fait, à ce que la plupart des gens désignent par "Forêt de
Fontainebleau", par exemple : une zone essentiellement boisée avec des
limites définies. Comme une telle forêt n’est pas nécessairement
intégralement boisée ou même intégralement exploitée, je n’ai pas trouvé
mieux que découplér sa représentation des landuse=forest/natural=wood.
De plus, boundary=forest tel qu’approuvé me semble correspondre aux
besoins de Marc Mongenet.
{...]
De plus, sans prendre vraiment parti pour ou contre boundary=forest
(quoique je préférerais le tag site même s'il est rarement rendu malgré
son âge), très souvent on ne peut pas savoir si une forêt est exploitée.
une coupe tous les 20 ans de certains arbres seulement (pratique plus
écolo) avec un mélange d'essence comme le fait maintenant plus souvent
l'ONF, c'est de l'exploitation ou pas ? Cela ne se voit que
difficilement sur le terrain. Pour moi oui. donc je mets
systématiquement landuse=forest et je ne réserve natural=wood que pour
des forêts primaires (en général en Afrique ou en Amérique du Sud par
exemple) ou des forêts ou bois interdites d'exploitation (en Europe) ou
bien réputées non exploitées, ce qui est très rare en France, à mon avis.
Salutations.
--
Rpnpif
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Inscription étrange sur OrthoHR : A bad place
Le 29/08/2022 à 20:24, osm.sanspourr...@spamgourmet.com a écrit : Le 29/08/2022 à 15:42, leni - lenny.li...@orange.fr a écrit : Il s'agit d'une œuvre https://officiel-galeries-musees.fr/tradition-de-lavant-garde-au-chateau-de-montsoreau/ Aux messagers précédents j'ajoute : artwork_type <https://wiki.openstreetmap.org/wiki/FR:Key:artwork type?uselang=fr>=graffiti Exemple : https://www.openstreetmap.org/node/4081669006 Exemple d'œuvre temporaire : (bon là il faut un was:) https://www.openstreetmap.org/way/825168087 À l'époque il y avait pairie et gazon, du coup dans OSM il état physiquement visible dans certains rendus. Ici je ne sais si inscription=A bad place convient > Jean-Yvon D'accord. Merci à tous pour vos indications. Quant à mes messages vides. comme certains me l'ont confirmé, c'est probablement des HTML seuls dû à un mauvais réglage sur un de mes PC. Je pense que c'est corrigé maintenant. -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Inscription étrange sur OrthoHR : A bad place
Oups, encore une fois c'est un message vide qui est sur la liste alors que chez moi, il y a ça : Bonjour, Le château de Montsoreau a une façon étrange d'accueillir les visiteurs aériens. L'inscription "A BAD PLACE' sur la cour devant le château, vue en cartographiant avec l'OrthoHR. Visible aussi sur ESRI. https://www.geoportail.gouv.fr/carte?c=0.06273964558303674,47.21559680322292=20=ORTHOIMAGERY.ORTHOPHOTOS::GEOPORTAIL:OGC:WMTS(1)=yes <https://www.geoportail.gouv.fr/carte?c=0.06273964558303674,47.21559680322292=20=ORTHOIMAGERY.ORTHOPHOTOS::GEOPORTAIL:OGC:WMTS(1)=yes> D'où vient cette inscription ? Une farce comme sur le Tour de France ? Le photographe plaisante ? Est-ce que ça se cartographie sur OSM ? Rpnpif Bizarre ! C'est le seul destinataire qui a ce problème. Le 23/08/2022 à 15:04, Jacques Lavignotte a écrit : Très étrange en effet Le 23/08/2022 à 12:26, Rpnpif a écrit : ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Inscription étrange sur OrthoHR : A bad place
___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] JOSM - Désignation des shop=farm
Le 05/06/2022 à 20:36, Georges Dutreix via Talk-fr a écrit : ça me semble une bonne idée ;-) Le 05/06/2022 à 19:14, LeTopographeFou a écrit : Bonjour à tous, Soit la clé suivante : shop=farm JOSM en français la nomme "Primeur" là où le wiki (et je suis d'accord avec lui) parle de produits de la ferme. "Primeur", c'est en théorie shop=greengrocer (nommée "Fruits et légumes" dans JOSM). A mon avis cela a dû créer des erreurs. Aucun soucis pour que je fasse changer la traduction JOSM de shop=farm en "Produits de la ferme" ? Cordialement, Bonne idée aussi de modifier mais je verrais plutôt : Vente à la ferme, afin d'éviter la confusion avec un stand sur un marché externe ou de vente de produits fermiers dans un hypermarché (oui ça se voit). -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] JOSM version 18463 traduction du journal des modifications
Le 01/06/2022 à 19:09, leni a écrit : Le 01/06/2022 à 16:21, Rpnpif a écrit : Merci. Aaaargh, JOSM ne sait toujours pas utiliser un écran HD (140 dpi) sous Linux Debian. Les polices de caractères y sont souvent beaucoup trop petites. Pourtant un rapport de bogue avait été créé il y a longtemps. Je ne l'ai pas trouvé, pas su chercher (désolé suis w10), pourrais-tu essayer de le chercher ? https://josm.openstreetmap.de/query?status=assigned=needinfo=new=reopened=id=summary=status=type=priority=milestone=component=time=priority=1 Et faire un ticket si nécessaire ? Cette page peut-elle t'aider ? https://josm.openstreetmap.de/wiki/Fr%3AHelp/HiDPISupport L'astuce GDK_SCALE=2 donne des polices d'interface trop grande et 1.5 ne change rien chez moi. Je vais voir l'astuce de Christian. je ne savais pas qu'une feuille de style existait. Je vais creuser quand j'aurai un moment. Pas le temps aujourd'hui. Merci à vous. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] JOSM version 18463 traduction du journal des modifications
Merci. Aaaargh, JOSM ne sait toujours pas utiliser un écran HD (140 dpi) sous Linux Debian. Les polices de caractères y sont souvent beaucoup trop petites. Pourtant un rapport de bogue avait été créé il y a longtemps. Tant pis. -- Rpnpif Le 31/05/2022 à 18:40, leni a écrit : Bonjour JOSM étant passé à la version stable 18463 Voici la traduction du Journal des Modifications https://josm.openstreetmap.de/wiki/Fr%3AChangelog#stable-release-22.05 (le lien vers l’original anglais est en haut à droite) Comme je n'étais pas sûr de la traduction du #22073, j'ai laissé en gras le texte anglais Bonnes contributions sur JOSM !!! cordialement leni ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] MS BOT
Le 24/02/2022 à 20:51, osm.sanspourr...@spamgourmet.com a écrit : Je crois que le Topographe Fou a été clair : pour La/la c'est clair : *SI* c'est une partie de nom de famille c'est avec une majuscule. *SI* c'est par rapport à un lieu-dit c'est en minuscule, style Rue de la Tour d'Argent. Tant que tu le fais à la main, tu dois pouvoir trouver s'il est question d'une personne (présence d'un prénom par exemple) ou pas. Pareil pour de/De : si tu ne sais pas, tu ne changes pas. Par contre tu peux demander aux locaux (note, fixme) et regarder l'historique. Bonjour, Bien d'accord. Pour le principe général, dans le cas des noms de lieux-dits ou rues, les panneaux ne sont pas toujours une source fiable. Ils peuvent comporter des fautes. J'ai le cas près de chez moi. Il faut recouper avec des documents officiels (préfectoraux, historiques, et parfois avec des déclarations de riverains, etc.) et ne pas s'en tenir qu'au terrain (sauf si on ne connaît que ça ou qu'on n'a pas le temps d'enquêter sur un nouveau nom dans OSM). Il n'y a pas de règle générale simple à mon avis. -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le bourg d'une commune
Le 03/12/2020 à 23:49, osm.sanspourr...@spamgourmet.com a écrit : Le 03/12/2020 à 21:55, deuzeffe - opensm@deuzeffe.org a écrit : Le 03/12/2020 à 11:04, Rpnpif via Talk-fr a écrit : Bonsoir, À Nantes, on a bien le Lieu unique ;) qui devrait être un nom commun. Si tu es Nantais, tu sais bien que /Le Lieu Unique/ est bien un nom propre (name=), comme le dit ades, (avec une évocation du passé du lieu dans lequel il est installé...) Tu veux dite le lieu unique (https://www.lelieuunique.com/, https://fr.wikipedia.org/wiki/Le_Lieu_unique). Et oui ils ont mit tout en minuscules. Dans OSM 3 majuscules mais l'arrêt de bus n'a pas d'article. https://www.openstreetmap.org/search?query=le%20lieu%20unique#map=19/47.21529/-1.54560 Oui vous avez bien LU. Le 03/12/2020 à 11:04, Rpnpif via Talk-fr - talk-fr@openstreetmap.org a écrit : Mon propre nom en a subi les conséquences. C'est vrai que Rpnpif ;-). Je ne sais qui dans le Lot a eu l'idée d'appeler une commune le bourg https://fr.wikipedia.org/wiki/Le_Bourg Mais sinon les bourgs sont des dénominations génériques signifiant le centre aggloméré de la commune. Après il y a des dénominations spécifiques, au bourg de Guidel ils ont bien réussi à faire un "Villeneuve le Bourg" https://www.mapillary.com/app/?lat=47.791543=-3.4902096=17=CrtrlHno_7alPyfFePQ6yg=photo=0.2556606449554435=0.5015682081004983=2 Oui c'est une impasse ! Qui est 3 fois dans FANTOIR : lieu-dit (en double) et voie sans adresses (1 entreprise de taxi). Dans OSM il y le voisinage, pas la rue car il n'y pas de plaque de rue mais juste en direction en début d'impasse. Devrait-on ajouter un noname=yes ? Je me suis contenté de mettre la ref FANTOIR. Jean-Yvon Le « lieu unique » c'était une petite provocation ;) pour montrer que les choses ne sont pas binaires. Sinon je suis d'accord avec ce qu'écrit Christian Rogel dans le fil. -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le bourg d'une commune
Bonjour, Le 01/12/2020 à 11:36, Marc_marc a écrit : Le 01.12.20 à 11:27, Christian Rogel a écrit : Dire que bourg n’est pas un lieu-dit utilisé est une affirmation non étayée que je n'ai pas dis... bureau de poste, banque, mairie, bourg, tout cela sont des noms de lieux, mais ce sont des noms *communs* d'une *catégorie* de lieu et non des noms propres désignant un lieu précis. catégorie -> tag style amnity=townhall place=* nom propre -> name Ce n'est pas toujours un nom commun mais le véritable nom d'un simple lieu-dit ou bien de l'agglomération dans un ensemble plus vaste du nom de la commune. Les exemples existent mais je ne peux les trouver à la minute. Je pense qu'il ne faut pas être rigide dans ce domaine comme le sont certains employés de l'État civil qui plaquent leurs idées reçues sur les noms propres de personnes ou de lieux-dits à l'origine de nombreuses erreurs par rapport à la réalité. Mon propre nom en a subi les conséquences. Cela tue la créativité du simple citoyen et le dépossède de son histoire ou de l'histoire du lieu, si on veut philosopher. Certains maires se sentent même obligés de débaptiser des lieux pour aller vers un consensus de soi-disant bon sens. À Nantes, on a bien le Lieu unique ;) qui devrait être un nom commun. -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] addok et demo.addok.xyz : géocodage avec données OSM
Le 24/11/2020 à 20:37, Jean-Marc Liotier a écrit : On 11/24/20 6:22 PM, Frédéric Rodrigo wrote: Ce n'est pas aussi facile que ça pour faire une emprise mondiale. Il est nécessaire d'écrire des adaptateurs pour chaque langue ou pays pour traiter les particularités. Je découvre donc: - La phonemicization: https://github.com/addok/addok-fr/blob/master/addok_fr/utils.py - Les particularités Françaises: https://github.com/addok/addok-france/blob/master/addok_france/utils.py On comprend vite qu'il sera compliqué d'accepter une recherche sans connaître dans quel zone administrative et linguistique elle s'inscrit... La « phonemicization » ressemble à une sorte de phonétisation simplifiée, non ? Pourquoi n'avoir pas pris de bibliothèques de phonétisation qui sont beaucoup plus complètes et plus adaptables à la zone de recherche, comme celles des moteurs de recherche ? Trop lourdes ? -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] JOSM version stable 17329 : traduction du Journal des modifications
Le 24/11/2020 à 08:07, Cyrille37 OSM via Talk-fr a écrit : Bonjour et Mille mercis et bravo pour ce super logiciel que vous savez maintenir toutes ces années. +1. Dommage qu'il ne gère pas bien le HiDpi (haute résolution d'écran) sous Linux (probablement du fait des bibliothèques de Java). Mais un ticket est en cours. Donc espoir. -- Rpnpif ___ 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
Le 13/11/2020 à 10:16, Vincent de Château-Thierry a écrit : 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 Bonjour, Attention aussi, certains admin-centre ne sont pas sur le village ayant la plus grande population, donc c'est une mauvaise idée de mettre en relief l'admin-centre avec ce critère. Par ailleurs, on attend toujours l'affichage des noms des communes nouvelles qui devrait se faire avant les anciennes communes membres. -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu BANO (v2) de retour !
Merci à vous tous ! -- Rpnpif Le 11/11/2020 à 16:34, Christian Quest a écrit : Il y a sûrement des ajustements à faire, liés à la nouvelle organisation des données et aux nouvelles sources. Beaucoup de rouge nouveau semble concerner des points adresse liés à des noms de lieux-dits qu'il ne me semble pas avoir vu avant, ou au moins pas aussi souvent. Là, la base PG est en cours d'upgrade, donc un peu de patience pour que ça revienne ;) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Test tuiles vecto sur ProjetDuMois.fr
Oups non, j'avais mal vu : le défibrillateur est marqué à intégrer alors qu'il l'est déjà mais à 5 ou 10 m plus loin. -- Rpnpif Le 19/10/2020 à 11:52, Rpnpif via Talk-fr a écrit : Bonjour, Initiative intéressante d'utiliser des tuiles vectorielles. Mais je note qu'elles ne sont pas à jour : je viens de commenter par erreur un défibrillateur qui avait été supprimé et replacé plus loin. Quel est le délai de mise à jour de ces tuiles ? -- Rpnpif Le 18/10/2020 à 13:15, Florian LAINEZ a écrit : Hello, On vient de passer aux tuiles vectorielles pour le fond de carte de projetdumois.fr <http://projetdumois.fr> Est-ce que ce fond de carte vous paraît pertinent pour les /projets du mois /? Manque-t-il des éléments ? La vitesse de chargement est-elle bonne ? ... Votre avis/retour est le bienvenu sur https://github.com/vdct/ProjetDuMois/issues <https://github.com/vdct/ProjetDuMois/issues> Grâce au boulot d'Adrien Pavie et de Frédéric Rodrigo (merci les gars !), /projet du mois/ est le premier service qui bénéficie de tuiles vectorielles hébergées par l'asso. Si ça marche bien, on envisage donc d'en étendre l'usage à d'autres services. Merci par avance pour vos retour -- *Florian Lainez* @overflorian <http://twitter.com/overflorian> ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Test tuiles vecto sur ProjetDuMois.fr
Bonjour, Initiative intéressante d'utiliser des tuiles vectorielles. Mais je note qu'elles ne sont pas à jour : je viens de commenter par erreur un défibrillateur qui avait été supprimé et replacé plus loin. Quel est le délai de mise à jour de ces tuiles ? -- Rpnpif Le 18/10/2020 à 13:15, Florian LAINEZ a écrit : Hello, On vient de passer aux tuiles vectorielles pour le fond de carte de projetdumois.fr <http://projetdumois.fr> Est-ce que ce fond de carte vous paraît pertinent pour les /projets du mois /? Manque-t-il des éléments ? La vitesse de chargement est-elle bonne ? ... Votre avis/retour est le bienvenu sur https://github.com/vdct/ProjetDuMois/issues <https://github.com/vdct/ProjetDuMois/issues> Grâce au boulot d'Adrien Pavie et de Frédéric Rodrigo (merci les gars !), /projet du mois/ est le premier service qui bénéficie de tuiles vectorielles hébergées par l'asso. Si ça marche bien, on envisage donc d'en étendre l'usage à d'autres services. Merci par avance pour vos retour -- *Florian Lainez* @overflorian <http://twitter.com/overflorian> ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Erreurs 500 sur OrthoHR
Impeccable ! Merci beaucoup Christian.
Il ne me reste plus qu'à faire un ticket pour JOSM qui gère mal les
erreurs de serveurs.
--
Rpnpif
Le 13/10/2020 à 16:39, Christian Quest a écrit :
Oups, un vilain effet de bord !
C'est réparé :)
Les requêtes répétées quand il y a une erreur c'est effectivement pas
l'idéal.
Le 13/10/2020 à 16:22, Rpnpif via Talk-fr a écrit :
Le 13/10/2020 à 16:16, Rpnpif a écrit :
Bonjour,
Depuis deux jours l'OrthoHR ne marche plus sauf en définition très
pixélisée.
J'ai des milliers de :
2020-10-13 16:13:06.770 INFOS: GET
https://wms.openstreetmap.fr/tms/1.0.0/orthohr/21/1042880/732339 ->
HTTP/1.1 500 (87 ms)
sous JOSM et ça mouline avec un CPU à 117% (2 cœurs).
OrthoHR est en panne et JOSM n'aime pas du tout. Il devrait arrêter
de charger quand il y a trop d'erreurs, non ?
Voici le message d'erreur :
An error occurred: msDrawMap(): Image handling error. Failed to draw layer
named 'orthohr_2013'.
msDrawRasterLayerLow(): Unable to access file. Corrupt, empty or missing file
'/data/work/wms/orthohr/tileindex/2013/ORTHOHR_1-0_RVB-0M20_JP2-E080_LAMB93_D049_2013-01-01/49-2013-0400-6735-LA93-0M20-E080.gpkg'
for layer 'orthohr_2013'.
/data/work/wms/orthohr/tileindex/2013/ORTHOHR_1-0_RVB-0M20_JP2-E080_LAMB93_D049_2013-01-01/49-2013-0400-6735-LA93-0M20-E080.gpkg:
No such file or directory
File "/usr/local/lib/python2.7/dist-packages/TileCache/Service.py", line
258, in modPythonHandler
host )
File "/usr/local/lib/python2.7/dist-packages/TileCache/Service.py", line
210, in dispatchRequest
return self.renderTile(tile, params.has_key('FORCE'))
File "/usr/local/lib/python2.7/dist-packages/TileCache/Service.py", line
140, in renderTile
data = layer.render(tile, force=force)
File "/usr/local/lib/python2.7/dist-packages/TileCache/Layer.py", line 444,
in render
return self.renderTile(tile)
File "/usr/local/lib/python2.7/dist-packages/TileCache/Layers/MapServer.py",
line 51, in renderTile
mapImage = wms.draw()
File "/usr/lib/python2.7/dist-packages/mapscript.py", line 2619, in draw
return _mapscript.mapObj_draw(self)
--
Rpnpif
--
Ce message a été vérifié par *MailScanner*
<http://www.mailscanner.info/>
pour des virus ou des polluriels et rien de
suspect n'a été trouvé.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
--
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Erreurs 500 sur OrthoHR
Le 13/10/2020 à 16:16, Rpnpif a écrit :
Bonjour,
Depuis deux jours l'OrthoHR ne marche plus sauf en définition très
pixélisée.
J'ai des milliers de :
2020-10-13 16:13:06.770 INFOS: GET
https://wms.openstreetmap.fr/tms/1.0.0/orthohr/21/1042880/732339 ->
HTTP/1.1 500 (87 ms)
sous JOSM et ça mouline avec un CPU à 117% (2 cœurs).
OrthoHR est en panne et JOSM n'aime pas du tout. Il devrait arrêter de
charger quand il y a trop d'erreurs, non ?
Voici le message d'erreur :
An error occurred: msDrawMap(): Image handling error. Failed to draw layer
named 'orthohr_2013'.
msDrawRasterLayerLow(): Unable to access file. Corrupt, empty or missing file
'/data/work/wms/orthohr/tileindex/2013/ORTHOHR_1-0_RVB-0M20_JP2-E080_LAMB93_D049_2013-01-01/49-2013-0400-6735-LA93-0M20-E080.gpkg'
for layer 'orthohr_2013'.
/data/work/wms/orthohr/tileindex/2013/ORTHOHR_1-0_RVB-0M20_JP2-E080_LAMB93_D049_2013-01-01/49-2013-0400-6735-LA93-0M20-E080.gpkg:
No such file or directory
File "/usr/local/lib/python2.7/dist-packages/TileCache/Service.py", line 258,
in modPythonHandler
host )
File "/usr/local/lib/python2.7/dist-packages/TileCache/Service.py", line 210,
in dispatchRequest
return self.renderTile(tile, params.has_key('FORCE'))
File "/usr/local/lib/python2.7/dist-packages/TileCache/Service.py", line 140,
in renderTile
data = layer.render(tile, force=force)
File "/usr/local/lib/python2.7/dist-packages/TileCache/Layer.py", line 444,
in render
return self.renderTile(tile)
File "/usr/local/lib/python2.7/dist-packages/TileCache/Layers/MapServer.py",
line 51, in renderTile
mapImage = wms.draw()
File "/usr/lib/python2.7/dist-packages/mapscript.py", line 2619, in draw
return _mapscript.mapObj_draw(self)
--
Rpnpif
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Erreurs 500 sur OrthoHR
Bonjour, Depuis deux jours l'OrthoHR ne marche plus sauf en définition très pixélisée. J'ai des milliers de : 2020-10-13 16:13:06.770 INFOS: GET https://wms.openstreetmap.fr/tms/1.0.0/orthohr/21/1042880/732339 -> HTTP/1.1 500 (87 ms) sous JOSM et ça mouline avec un CPU à 117% (2 cœurs). OrthoHR est en panne et JOSM n'aime pas du tout. Il devrait arrêter de charger quand il y a trop d'erreurs, non ? -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] JOSM version stable 17084 : Correction des fuites de mémoire
Le 13/10/2020 à 13:36, Yves P. a écrit : Ca se règle dans les paramètres de la VM: la garbage collector ne tourne pas aussi souvent que tu le crois, on peut lui demander de tourner plus souvent. Certes, mais il met semble que ma bécane ne rebootait pas toute seule avant avec JOSM. Depuis la mise à jour, c'est pire. De plus tu peux lancer JOSM en activant la console, et tu as le moyen de lancer le garbage collector à la main pour le forcer à faire un cycle complet de finalisation et de libération. Est-ce que ça suffira ? Je pensais que les fuites de mémoire n'apparaissaient pas dans les applications JAVA à cause de la "balayette", mais non : /Java does automatic Garbage collection./ /However there can be situations where garbage collector does not collect objects because there are references to them. / Source <https://www.geeksforgeeks.org/memory-leaks-java/> Bonjour, J'ai aussi le problème de consommation de mémoire. Je ne sais pas si c'est ça qui me fait une erreur non fatale sous Debian Linux après quelques minutes de travail quand j'utilise les listes d'attributs ou les listes de leurs valeurs. Je l'ai aussi quand j'utilise la liste de l'historique des sources quand j'envoie les données. C'est pénible. J'ai fait un ticket. -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Couche d'affichage des noms de lieux-dits et frontières sur une photo satellite avec Leaflet
J'avais vu cette couche mais je n'avais pas remarqué qu'on pouvait sélectionner les « places » seuls. Merci, je vais tester. -- Rpnpif Le 12/10/2020 à 16:53, PanierAvide via Talk-fr a écrit : Bonjour, Tu peux probablement utiliser la couche "Locator overlay" qui est justement utilisée par iD, sa configuration est décrite ici (TMS) : https://raw.githubusercontent.com/osmlab/editor-layer-index/9a40770cbcc8593c5679b47cd6f5392219ae9214/sources/world/LocatorOverlay.geojson Un article qui parle du travail récent réalisé sur ce style : https://blog.mapbox.com/rebuilt-locator-overlay-for-id-editor-9606da7f18f8 Cordialement, Adrien P. Le 12/10/2020 à 16:45, Rpnpif via Talk-fr a écrit : Bonjour, J'aurais besoin de savoir quelle adresse vous me suggérez pour obtenir seulement les lieux-dits et éventuellement (et ultérieurement les routes et les frontières -- boundaries) afin de les afficher en surimpression sur une photo satellite ESRI comme le fait Id. Je sais faire un extrait d'overpass.de et l'afficher sur la photo mais j'aurais préféré avoir des mises à jour en temps quasi réel en vectoriel bien sûr si possible. Le trafic serait assez faible. Auriez-vous des idées d'adresses de données ou des exemples ? Cordialement. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Couche d'affichage des noms de lieux-dits et frontières sur une photo satellite avec Leaflet
Bonjour, J'aurais besoin de savoir quelle adresse vous me suggérez pour obtenir seulement les lieux-dits et éventuellement (et ultérieurement les routes et les frontières -- boundaries) afin de les afficher en surimpression sur une photo satellite ESRI comme le fait Id. Je sais faire un extrait d'overpass.de et l'afficher sur la photo mais j'aurais préféré avoir des mises à jour en temps quasi réel en vectoriel bien sûr si possible. Le trafic serait assez faible. Auriez-vous des idées d'adresses de données ou des exemples ? Cordialement. -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] validation : sorties nommées
Le 30/09/2020 à 14:56, thevenon.jul...@free.fr a écrit : - Mail original - De: "osm sanspourriel" À: talk-fr@openstreetmap.org Envoyé: Mercredi 30 Septembre 2020 14:11:35 Objet: Re: [OSM-talk-fr] validation : sorties nommées *Vous connaissez des routeurs qui affichent les destinations ?* Magic Earth le fait il me semble OsmAnd itou. -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] maxspeed par défaut
Le 03/09/2020 à 16:41, osm.sanspourr...@spamgourmet.com a écrit : Quel intérêt de rappeler un doublon désuet ? Sauf à rappeler que c'est doublon désuet. maxspeed:type désuet ? La page de wiki de source:maxspeed a été créée en 2009, celle de maxspeed:type en 2011. C'est vrai que source:maxspeed est le plus utilisé avec 1,6 millions de valeurs alors que maxspeed:type en a 378000 ce qui n'est pas ridicule. Je connais la discussion sur ce sujet mais pour être exhaustif, il fallait citer les deux. D'ailleurs c'est ce que fait la page en anglais du wiki sans prendre parti. Personnellement, j'ai un léger faible pour maxspeed:type car ce n'est pas véritablement une source mais plutôt une référence remplaçable par une valeur. Les applications qui utilisent la carte, n'utilisent que rarement les attributs source:* alors que la valeur FR:urban peut être remplacée par une vitesse. Cela n'a rien a voir avec source=cadastre ou autre. Mais je ne suis pas intégriste de cet attribut mais je pense qu'il faut laisser le choix vu le nombre d'utilisation. -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rond point et relations routes
Le 01/09/2020 à 19:13, Georges Dutreix via Talk-fr a écrit : Bonjour, J'ai souvent découpé des giratoires pour des lignes de bus : honte sur moi ! Promis, je ne le ferai plus ;-) Peut-être faudrait-il décrire les bonnes pratiques, pour les naïfs comme moi, dans des pages comme https://wiki.openstreetmap.org/wiki/FR:Bus ou https://wiki.openstreetmap.org/wiki/FR:Relation:route#Les_itin.C3.A9raires_de_bus_et_les_ronds-points ? Je ne maîtrise pas assez celles-ci pour m'amuser à modifier le wiki moi-même. Et il semblerait qu'il n'y ait pas consensus... Peut-on écrire par ci par là que la bonne pratique en France est de, si possible, ne pas casser les rond points en plusieurs segments ? +1 ! Tout à fait d'accord. -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] maxspeed par défaut
Bonjour, Le 03/09/2020 à 03:38, Marc Mongenet a écrit : Le mer. 2 sept. 2020 à 01:16, Yannick a écrit : L'implicite est désormais quasi impossible à deviner. Je suis donc partisan de mettre systématiquement le maxspeed=* au moins c'est clairement renseigné sans équivoque possible. Oui l'implicite est difficile à maîtriser. Mais le problème que j'ai rencontré, et je pense qu'il est répandu, c'est que les mappeurs ne connaissent pas suffisamment bien le code de la route pour expliciter correctement l'implicite! D'ailleurs, en relisant les textes réglementaires avant de poster, je me suis rendu compte que je ne suis pas tout à fait au clair moi-même. Ainsi, je pense que https://wiki.openstreetmap.org/wiki/FR:Key:maxspeed#Limitation_de_vitesse se trompe en écrivant: Et comme ce serait trop simple, je rappelle qu'il existe aussi maxspeed:type comme synonyme de source:maxspeed. Le premier est oublié sur le wiki en français. -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Renseigner un « Lieu-dit »
Bonjour, Le 16/08/2020 à 19:19, Jacques Lavignotte a écrit : Je regarde le Wiki et je vois que ça peut-être "place" ou "hamlet" si habité. Mais ceci : https://www.openstreetmap.org/way/157107477#map=15/45.1635/-0.1552 me semble très discutable... Qu'en penser ? J. Mettre le nom du lieu-dit comme nom d'une voie est très fréquent. Geoportail (IGN) le fait souvent sur ses cartes. Effet de bord : Cela facilite beaucoup l'affectation du nom du lieu-dit à la numérotation des maisons sous JOSM ou Id. Ensuite, est-ce une pratique souhaitable ? Ça se discute. L'avantage est de donner un nom à la voie ou portion de voie sous-jacente qui sinon serait souvent anonyme. Personnellement, je ne trouve pas gênant de le faire. Ce n'est pas le facteur (surtout en cette période de remplacement) qui me contredira. Ce qui n'empêche pas effectivement d'ajouter aussi des place=*. .-- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Référencer la production alimentaire locale
Le 17/07/2020 à 13:09, Vincent Bergeot a écrit : Il faut aussi avoir en tête qu'une ferme agricole ou une boutique de ferme ne vend pas forcément de la production alimentaire. Par exemple : https://www.openstreetmap.org/node/7723612275 oui tout à fait, cependant le shop=farm est centré alimentation (fraîchement récolté, donc sans doute c'est même quasi que des fruits et légumes non ?) https://wiki.openstreetmap.org/wiki/Tag:shop%3Dfarm shop=farm se caractérise avec product=* ou produce=* (je ne sais pas si c'est le plus simple d'ailleurs, il pourrait être plus simple de faire des shop=greengroccer, cheese, butcher en précisant que c'est produit sur place par exemple) à plus Je n'avais pas très bien lu le wiki mais je suis bien d'accord que shop=farm est un peu ambiguë. Je serais d'accord avec ta proposition qui lève toute ambiguïté. -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Référencer la production alimentaire locale
Bonjour, Le 16/07/2020 à 14:15, Vincent Bergeot a écrit : Merci Christian, Le 15/07/2020 à 20:34, chris-...@netcourrier.com a écrit : Bonjour. En complément : J'avais pris le temps de regarder ceci il y a 1 an, et j'ai résumé ici : https://wiki.openstreetmap.org/wiki/FR:WikiProject_CircularEconomy (paragraphe sur "produits alimentaires locaux") Il y a plusieurs sites exemples, basés sur osm : 1. Marchés, magasins et distributeurs automatiques de produits alimentaires sur le site Web Farmshops.eu : https://farmshops.eu Tags utilisés : shop=farm amenity=vending_machine and tags supplémentaires vending=milk et vending=food amenity=marketplace 2. Les marchés avec Wo ist markt : https://wo-ist-markt.de/ Et si je résume : Fermes qui font de la vente directe : shop=farm avec produce=* (ne pas utiliser product=* pour les produits peu ou pas transformés) Bio : organic=yes and organic=only ceux sont effectivement les mêmes tags. j'ajouterai le landuse=farmyard même si cela concerne surtout des producteurs agricoles n'ayant pas forcément de point de vente (shop=farm) mais ayant par exemple une activité sur des marchés et/ou éventuellement sur rendez vous. Encore merci Il faut aussi avoir en tête qu'une ferme agricole ou une boutique de ferme ne vend pas forcément de la production alimentaire. Par exemple : https://www.openstreetmap.org/node/7723612275 -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression *covid19=*
Merci de ne pas alimenter le troll ou si vous préférez la polémique stérile. Bien à vous. Rpnpif Le 10/07/2020 à 14:33, deuzeffe a écrit : Le 10/07/2020 à 13:04, Philippe Verdy a écrit : Bonjour aussi. /SNIP ta réponse... je n'ai pas été "impoli" envers qui que ce soit... Si, envers tous les lecteurs de la ML. Tu as eu parlé le la nétiquette : tu faisais référence à quoi ? Et Wikipedia n'est pas une référence sur le sujet. Et Wikipedia est une encyclopédie libre, ouverte et collaborative, s'appuyant sur le savoir d'une communauté expérimentée. Un peu comme OpenStreetMap, tu vois ? Oserais-tu dire qu'osm n'est pas une référence ? Ou son wiki pour les contributeurs ? Ma réponse était parfaitement cadrée sur le sujet... Non. Tu n'as donné aucune réponse pratique et technique pour bâtir la requête overpass demandée. Je te rappelle la question, puisque tu sembles ne pas l'avoir lue : "Quelle requête overpass pour supprimer les tags covid19 devenus inappropriés dans ma commune ?" Et ta réponse, est ? Heureusement que deux autres contributeurs ont parfaitement répondu à la question posée, même avec quelques différences. Puisque l'auteur initial souhaitait "virer" les tags qu'ils jugent maintenant "inutiles" alors que rien n'est fini, bien au contraire, ce sont jute les conditions locales d'usage L'auteur, enfin, l'autrice initiale, c'est moi (qui voulais supprimer et non pas "virer"). Étonnant, n'est-ce pas ? Et il s'agit bien de données d'usage dans un périmètre local parfaitement connu de moi-même. C'est curieux, n'est-ce pas ? qui peuvent évoluer et revenir. c'est bête de gâcher le patient travail des autres Manque de bol "les autres", dans ce cas précis, c'est moi aussi. /snip le HS. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu OSM et fusion de communes
Ma réponse dans le texte. Le 29/05/2020 à 08:15, Philippe Verdy a écrit : Ce n'est pas exact: si les noeuds représentent les place=* pour les noms locaux, les noms des relations sont visibles le long des frontières (il suffit de zoomer pour les voir). si on dézoome, le noeud va être trop petit par rapport à la relation, et la relation prend le pas, masquant le noeud représentant une relation plus petite quand on ne peut pas afficher les deux. D'abord je ne parlais que de rendu. Comme je l'écrivais, les noms des relations sont affichés en petit le long des frontières mais ne sont plus visibles nulle part à zoom 14 et moins. Comme les communes nouvelles n'ont théoriquement pas de nœud place=*, rien n'est rendu sur la carte OSM au-dessous de zoom 14. Pour les communes nouvelles, comme elles conservent la toponymie des communes membres, le nom de la commune nouvelle ne remplace pas celui des communes membres, qui conservent également leur code INSEE propre à 5 chiffres (même si ces communes ne sont plus de "plein exercice" en tant que personnes morales séparées, le code INSEE à 5 chiffres est un code géographique, pas un code sur la personne morale qui, elle, est codée avec le code SIREN). La commune nouvelle adopte simplement le code INSEE à 5 chiffres d'une de ses communes membres, celle de son chef-lieu, les "anciens" codes INSEE à 5 chiffres ne sont pas "supprimés", il restent en vigueur et même liés aux communes membres. L'association du code INSEE à 5 chiffres avc la commune nouvelle est seulement une "facilité". Tu parles de contraintes administratives, moi je parlais de terrain et d'utilisateurs (habitants, livreurs, voyageurs) qui ont besoin de connaître où se trouve la commune qui est mentionné sur leur bon de livraison ou qui est la destination de leur voyage. De plus en plus le nom de la commune nouvelle apparaît seule sur les adresses. Les noms des communes anciennes tendent à disparaître des adresses postales et des bons de livraison (les doublons sont pourchassés et progressivement éliminés par une numérotation différenciés des maisons, exemple : de 1 à 30 sur telle rue et de 40 à 60 sur une homonyme). Si on laisse en l'état, la seule solution est de faire un autre rendu, ce qui est hors de portée du pékin moyen. La recherche Nominatim fonctionne bien mais ne change rien au rendu utile pour se situer dans les derniers km. La distinction entre entités administratives de niveau différent est pertinente pour l'administration (et pour les cartographes et autres spécialistes) mais beaucoup moins pour le citoyen moyen. De plus certaines mairies seraient bien intéressées par une meilleure visibilité de leur commune pour leurs propres services, pour la cohésion de leurs habitants et pour la promotion de leur commune à l'extérieur. En résumé, le problème est l'utilisabilité et la visibilité de la carte OSM pour le terrain. Ce n'est ni un problème administratif, ni un problème de structure de la BDD d'OSM, quoique des changements mineurs pourraient aider. Va falloir forker la carte OSM ;). -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu OSM et fusion de communes
Le 28/05/2020 à 17:16, Jean-Claude Repetto a écrit : Je parlais bien de place=locality: https://wiki.openstreetmap.org/wiki/FR:Tag:place%3Dlocality qui est traduit par lieu-dit dans OSM. Euh, je lis « lieu-dit sans population » : /Locality/ désigne un lieu-dit (au sens littéral du terme) sans population. Les lieux-dits (dans le langage courant) ou hameaux peuplés doivent être tagués avec place <https://wiki.openstreetmap.org/wiki/FR:Key:place>=hamlet <https://wiki.openstreetmap.org/wiki/FR:Tag:place%3Dhamlet>. Ce qui est exact. -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu OSM et fusion de communes
Le 28/05/2020 à 15:29, Jean-Claude Repetto a écrit : Bonjour, Je réponds partiellement: Le 28/05/2020 à 14:45, Yann-Gaël LARGILLET a écrit : Je me permets d'écrire sur cette liste, merci de me dire si ce n'est pas le bon endroit. J'ai envoyé un message sur le forum, mais j'ai l'impression que ma question aura peut-être plus de chances de réponses sur cette liste ! Oui, cette liste est beaucoup plus active que le forum. "Saint-M'Hervon" a été engloutie par la commune de "Montauban-de-Bretagne". J'ai donc transformé le point en lieu-dit, est-ce ok ? Non, un lieu-dit n'a pas d'habitants. Je pense que "village" est plus approprié. Bonjour, Un lieu-dit, mot générique, peut avoir des habitants ou pas car place signifie lieu-dit (un village est aussi un lieu-dit). Sans habitant, c'est place=locality. Et bien se souvenir que il n'y a malheureusement aucun rendu pour le moment des communes nouvelles issues de la fusion sur la carte officielle https://www.openstreetmap.org/ sauf, comme dans ce cas, si la commune ne change pas de nom. Dans ce cas et autrement, on ne voit que les communes anciennes sur la carte, marquées par un point place=village ou bien place=* (autre). Alors que pour toutes les communes anciennes fusionnées ou pas, un point place=* est placé traditionnellement en plus de la frontière sous forme de relation même si la commune ancienne comprend plusieurs place=village (agglomérations de plus de 200 habitants). La raison est que les relations comportant le nom de la commune nouvelle ne sont pas malheureusement non plus rendues (sauf le long de la frontière de la commune en tout petit). La carte https://www.openstreetmap.org/ a choisi de ne pas représenter les surfaces place=* pour une raison qui m'est inconnue contrairement à l'application OsmAnd. Comme la communauté française a choisi de ne pas ajouter de point place=* pour les communes nouvelles (alors que pour les habitants de plus en plus celles-ci sont entrées dans la vie quotidienne entre autres pour des raisons postales et de transports) et bien ces communes sont invisibles sur ce rendu comme sur celui de openstreetmap.fr. Dommage. -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] osthéopathes
Le 12/03/2020 à 12:22, Arnaud Champollion a écrit : Le souci dans un premier temps ce n'est même pas l'absence d'icône, mais surtout le fait qu'il n'est pas rendu du tout, et si je comprends bien, parce qu'il n'a pas de tag amenity. Il quasi invisible. La recherche qu'on peut effectuer avec le point d'interrogation ne permet que de trouver le nom du praticien si on sait déjà où il est, et s'il est renseigné dans le "name", et qu'on sait déjà que c'est un ostéopathe. On ne trouve pas non plus en utilisant le champ de recherche. Au final il n'y a qu'une requête overpass sur healthcare:speciality=osteopathy qui permet de trouver. Certains contributeurs utilisent amenity=doctors, en effet c'est discutable du point de vue "médecin". Certains utilisent écrivent aussi name=ostéopathe, ce qui est incorrect mais paradoxalement plus efficace lors d'une recherche (on perd cependant le nom du praticien). Je suppose que c'est la même chose pour les kinés, orthophonistes ... bref tout ce qui est concerné par healthcare en dehors de clinic / hospital. Finalement on a amenity=doctors, amenity=clinic, amenity=hospital. Est-ce qu'on peut proposer un nouvel attribut, par exemple amenity=healthcare ? Comme la plupart du temps (au moins autour de chez moi et j'en ai dans ma famille), les ostéopathes sont des kinésithérapeutes qui se sont spécialisés, je mettrais healthcare=physiotherapist <https://wiki.openstreetmap.org/wiki/Tag:healthcare%3Dphysiotherapist> suivi de <https://wiki.openstreetmap.org/wiki/Tag:healthcare%3Dphysiotherapist>healthcare:speciality <https://wiki.openstreetmap.org/wiki/Key:healthcare:speciality>=osteopathy <https://wiki.openstreetmap.org/w/index.php?title=Tag:healthcare:speciality%3Dosteopathy=edit=1>. Il n'y a rien d'alternatif là-dedans en 2020. Ou alors dans tous les métiers il faudrait mettre alternatif pour les spécialités. Ne soyons pas plus intégristes que les intégristes ;). Le wiki n'impose pas d'amenity Sur le rendu, je n'ai pas d'avis. -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] #AttributionIsNotAnOption
Bonjour, Il me semble que le site des géomètres experts https://www.geofoncier.fr/ ne mentionne rien du tout alors que je reconnais bien OSM en fond de carte avec mes propres modifications et ajouts. C'est un site qui potentiellement sera très consulté. -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] quoi dire de fiable sur le coronavirus COVIDS-19 en France
Le 01/03/2020 à 10:15, osm.sanspourr...@spamgourmet.com a écrit : Sans doute plus dans une OpenEventDataBase ou une umap : ce sont des informations qui varient trop vite pour OSM. Sans oublier que les "quarantaines" entre les pays et même au sein d'un même pays peuvent varier. Et encore, le site que tu cites et les conseils aux voyageurs de http://www.diplomatie.gouv.fr/spip.php?page=backend_fcv <https://www.diplomatie.gouv.fr/spip.php?page=backend_fcv> (*) sont sans doute plus efficaces pour informer. Et on aurait eu du mal à cartographier le principal foyer hors Chine il fut en temps, avec un paquebot mobile. Jean-Yvon (*) https://www.diplomatie.gouv.fr/fr/mentions-legales/les-flux-rss-de-france-diplomatie/ /*Conseils aux voyageurs*/ // /http://www.diplomatie.gouv.fr/spip.php?page=backend_fcv <https://www.diplomatie.gouv.fr/spip.php?page=backend_fcv>// //Les dernières alertes de la rubrique Conseils aux voyageurs - avertissement sur les destinations à risque/ Bonjour, D'après les informations entendues à la radio ce midi, il semblerait qu'à terme (dans quelques semaines ou mois ?) si la « pandémie » se généralise, on s'orienterait vers une gestion identique à celle d'une forte grippe, donc sans zones de confinement ou autres restrictions, mais seulement un renforcement des capacités des hôpitaux et de la protection des personnes fragiles (EPHAD, malades, etc.). En ce moment, en même temps que la montée de l'épidémie, une certaine paranoïa gagne. Pour des raisons politiciennes hors contexte (code 49.3 ;-) ), le gouvernement joue la dramatisation comme l'ont avoué plusieurs ministres ou députés de la majorité hier et aujourd'hui. Donc une carte spécifique risque de devenir très rapidement obsolète sauf si on a des données épidémiologiques fiables en temps réel. Malheureusement ces dernières sont souvent disponibles avec retard comme pour les grippes annuelles. Notez que je ne suis en aucune façon un spécialiste du sujet. -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Structures de soins en addictologie (CSAPA, CAARUD…)
Réponse rapide. Le 12/02/2020 à 11:01, Yves P. a écrit : Bonjour, [...] *Faut-il nettoyer les données OSM ?* Une recherche (NOMINATIM) avec le terme CSAPA <https://www.openstreetmap.org/search?query=csapa> renvoi « Clinique », « Hospital », « Service social » , « Salle polyvalente ». Une recherche Overpass avec "social_facility:for"=drug_addicted en France <https://overpass-turbo.eu/s/QE2> montre que les tags amenity=social_facility et social_facility=* ne sont pas toujours présents. Je dirais plutôt proposer une règle Osmose au lieu d'une modification massive. -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nouvelles communes françaises issues de fusion et OSM
Merci d'avoir pris en compte ce problème et merci pour vos suggestions (place=municipality) qui me font réfléchir.. Le problème est assez peu différent pour les communes anciennes et non fusionnées récemment ayant plusieurs agglomérations séparées. L'admin-centre n'est pas forcément l'agglomération la plus grande mais celle où est se situe le bâtiment de la mairie et on y met un place=* (Oui, Florimond, j'ai bien compris tes griefs et exemples). J'aurais une suggestion qui va peut-être choquer : ce serait de remplacer place=village/town des anciennes communes incluses dans la fusion par des place=quarter/neighborough et de placer le nom de la nouvelle commune sur l'admin-centre en place=village/town/city comme on le fait pour Nantes, Paris, etc. toutes issues de fusions plus ou moins anciennes (oui bon la différence, c'est que ces communes ont gardé le nom de la commune principale). Parce que, à priori, les communes dites déléguées ne sont que de futurs arrondissements ou quartiers de la nouvelle. Aujourd'hui, ce sont des sortes de quartiers à statut spécial. -- Rpnpif Le 11/02/2020 à 18:03, Christian Quest a écrit : Prenons un exemple pour réfléchir: - Montholon (commune nouvelle): place=municipality + population=1500 - Aillant-sur-Tholon (commune chef-lieu): place=village + population=1000 - Volgré (commune déléguée): place=village + population=300 - Villiers-sur-Tholon (commune déléguée): place=village + population=200 Chaque noeud est admin_centre d'une relation admin_level=8 ou 9 Sur le rendu, Montholon sera placé en priorité, puis Aillant, puis Volgré, puis Villiers. Comme on aura plus le détail des populations des communes déléguées (quoique*) on peut conserver ce qu'on a de plus récent et on a le millésime en source:population De toute façon, quelqu'un qui aurait besoin des populations à jour ferait quand même bien mieux (en France) de prendre le fichier de l'INSEE ;) Place sur la relation + sur le noeud ? Bof bof bof, ça ne me semble pas cohérent car on a un doublon de place=* (qui décrit un objet, contrairement à population=* qui n'est pas un "objet" en tant que tel mais un attribut d'un objet). * avec le carroyage INSEE on pourrait très bien déduire approximativement la population d'un hameau, d'un écart, etc... ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag panneau zone vidéo surveillance ?
Le 11/02/2020 à 10:37, Jérôme Seigneuret a écrit : à chaud, j'aurais créé traffic_sign=surveillance ___ Pour moi c'est pas en lien avec le traffic A chaud ;-) tourism=information information=bord bord_type=surveillance Tu veux dire : Information=board board_type=surveillance ;) -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Nouvelles communes françaises issues de fusion et OSM
Je voudrais proposer de modifier la façon de traiter les communes nouvelles françaises dans OSM. Je considère qu'une nouvelle commune devrait être enregistrée de la même façon qu'une ancienne commune issue de fusion de plusieurs communes. La possibilité de fusion des communes en France est très ancienne, elle a plus de 50 ans. Par exemple, certaines communes sont issues d'une campagne de fusion des années 1970. Ces dernières portent souvent le nom des deux communes séparées d'un trait d'union. Dans OSM, elles ne sont pas distinguées des communes non issues de fusion (ou plutôt, celles dont on se souvient qu'elles ne sont pas issues de fusion ; si on remonte très loin, au Moyen-Âge, ces communes non issues de fusion doivent être assez rares). De façon que je considère arbitraire, les communes issues de fusion d'après 2010 (pourquoi ne pas prendre celles avant 2010 ?) , il a été décidé ici même de traiter à part les communes nouvelles en ne les enregistrant que par leur frontière et sous forme de relation avec leurs anciennes communes membres et leur admin_centre. Il a aussi été décidé de ne pas les repérer par un nœud place=* contrairement aux communes d'avant 2010 même issues de fusion (donc beaucoup comme on l'a vu). La conséquence la plus visible est que ces communes sont totalement invisibles dans le rendu officiel osm.org qui n'affiche pas le nom des zones englobées par une frontière sans place=*. Il y a pourtant d'autres limites dont le nom est affiché comme les forêts, etc. Geoportail de l'IGN affiche bien, lui, ces nouvelles communes. On répond que les nouvelles communes ne sont que des délimitations administratives qui n'ont pas vocation à être des lieux-dits. Cette opinion est contestable car c'est pourtant comme cela que l'on note les anciennes communes issues ou non de fusion. De plus dans l'esprit du législateur, les nouvelles communes issues de fusions récentes ont vocation à fonctionner comme les autres communes en intégrant complètement les anciennes qui ne deviennent que des sortes de quartiers ou arrondissements. Ces anciennes communes peuvent être des villages et parfois des petites villes (plus de 1 habitants aux abords d'une grande agglomération). Par exemple, une commune classique non issue de fusion récente comporte souvent un bourg qui est appelé Le Bourg par les habitants et est rarement repéré par ce nom dans Osm.org (alors que BANO peut le marquer). En général, la mairie décide de noter sur les panneaux d'entrées du bourg le nom de la commune. Donc la commune est aussi un lieu-dit qui devrait être noté par place=* au niveau du bourg ou de l'agglomération principale. Dans le cas d'une commune issue de fusion récente, certaines mairies n'affichent que le nom de la commune issue de fusion et pas l'ancienne. D'autres affichent le nom de l'ancienne commune avec mention du nom de la nouvelle dessous. Évidemment, quand le nom de la commune issue de la fusion est le même que celle de celui de la commune admin_centre, le problème est plus simple. Les habitants et autres partenaires des nouvelles communes récentes font de moins en moins la distinction avec le fonctionnement des communes non fusionnées récemment que ce soit pour leurs relations avec la mairie, la Poste, etc. (bien sûr après un temps d'adaptation plus ou moins facile et plus ou moins heureux). Ils ont donc de plus en plus besoin de repérer leur commune nouvelle sur une carte. En conséquence de ce que j'écris ci-dessus, ma proposition est la suivante : Traiter les nouvelles communes comme les anciennes avec une relation frontière (boundary) et un nœud place=* mis aux abords de l'admin-centre ou bien vers le centre de la commune. Garder le nœud place=* et la relation frontière (boundary) des anciennes communes comme on le fait déjà pour les place=village des lieux-dits d'agglomération de plus de 200 et de moins de 1 habitants à l'intérieur d'une commune « non fusionnée » récemment. Cette proposition permet de simplifier les contributions ainsi que les moteurs de rendus. -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de mise à jour : la population des communes
Le 10/02/2020 à 18:00, leni a écrit : Le 10/02/2020 à 12:29, Stéphane Péneau a écrit : Si je récapitule : - Vincent lance l'outil aidant la maj de la population sur les relations des communes. - Je soulève l'idée de supprimer le tag "population" des noeuds car ce n'est pas cohérent. - Christian indique qu'il l'utilise - Discussions sur les différents cas qui se présentent. Avec plusieurs propositions de supprimer "population" des noeuds. - J'indique que si c'est utilisé par le rendu FR, ça bloque un peu ce processus. Dans ma tête, j'en suis resté à l'idée qu'il fallait le conserver pour l'instant, et sur les maj que j'ai effectuées, j'ai copié la valeur de "population" sur le noeud "admin_centre". j'ai fait pareil après avoir lu le message de Christian Bonjour, Dupliquer la population sur l'admin-centre me semble une mauvaise idée surtout sur les nouvelles communes. En effet, elle a pu être mise à jour pour cette ancienne commune seulement et n'a donc pas la même valeur que la nouvelle. Je rappelle que beaucoup (la majorité ?) de nouvelles communes n'ont pas le même nom que l'ancienne et aussi que l'ancienne peut avoir deux relations admin_centre (pour elle-même et pour la nouvelle). D'ailleurs, le traitement des nouvelles communes et particulièrement leur rendu est un problème à part entière qui est très mal traité par le rendu osm.org, contrairement à Géoportail (de l'IGN) qui fait bien apparaître son nom. Je vais lancer un autre fil de discussion sur ce problème des nouvelles communes. Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de mise à jour : la population des communes
Le 05/02/2020 à 07:20, Vincent de Château-Thierry a écrit : Bonjour, Bonjour Vincent, Il semble que quelqu'un conteste tes mises à jour ou plutôt ne les as pas comprises. C'est sur : https://forum.openstreetmap.org/viewtopic.php?id=68546 Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Pépinière d'arbres fruitiers en venet directe
Bonjour, Je cherche une balise pour les pépinières d'arbres fruitiers en vente directe (c'est la saison !). Il existe bien landuse=plant_nursery pour les champs mais pour la boutique, j'ai trouvé shop=fruit_tree mais taginfo n'indique qu'une seule utilisation dans le monde. Pourtant c'est ce qui me semble le plus adapté. Dans le monde, il y a quand même plus d'une pépinière d'arbres fruitiers en vente directe quand même ! Avez-vous une idée de ce qui serait le plus adapté ? -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [SPAM] Re: SPAM, Re: Problème avec ID - besoin d'aide
Essayez la virgule qui, elle, est cumulative, à la place du point-virgule. -- Rpnpif Le 31/12/2019 à 17:15, Philippe Verdy a écrit : Voilà comment une spécif est devenue illisible et c'est à moi qu'on vient dire que supprimer les espaces non nécessaires serait illisible? Il y a trop de règles ici, le "fallback" (||) ne sert à rien et complique inutilement, la syntaxe indiquée n'étant même pas correctement spécifiée en terme d'associativité. Et je ne vois pas du tout pourquoi deux règles "Mo 08:00-12:00;Mo 14:00-18:00" sont fausses (même si ici c'est évidemment équivalent à une seule règle combinée/factorisée "Mo 08:00-12:00,14:00-18:00 en utilisant la virgule simplement comme séparateur secondaire entre deux horaires des mêmes dates, ou entre deux dates au même horaire). la présence ou pas du qualificateur final "off" ne devrait strictement rien changer à l'associativité. Et puis cette "doc" ne suit même pas tous les usages de l'outil de test que tu utilises, il y a d'autres outils mais franchement cette page de doc est très orientée selon une définition à priori non testée et qui ne fonctionne pas telle quelle et n'a en fait été suivi exactement par /personne/. "opening_hours" est conçu n'importe comment, pas pour être lisible, et plein d'ambiguités comme sa doc. chacun y a mis sa sauce sans vérifier comment les autres utilisaient ou analysaient le reste. C'est tellement plus simple (même pour un lecteur humain) de concevoir un traitement cumulatif et un traitement ordonné des règles. Ensuite on peut discuter de la façon de scinder les horaires sur plusieurs tags numérotés (c'est simpel de voir où on peut couper: partout où un point-virgule est admis, mais il faut une règle d'ordre donc une convention de nommage pour le numéro dans la clé). Pas besoin de base externe avec une URL qui ne sera jamais traitée (et qui ne sert à rien: autant utiliser website=* pour le site officiel mentionnant sur sa page d'info les horaires, et qu'on visitera alors dans un navigateur); ce ne sera jamais plusieurs dizaines de kilooctets comem pour toute une page web avec son HTML, ses styles, ses images, ses scripts, ses publicités et traqueurs web et autres formulaires. et toute la déco et l'animation voire le son et la vidéo qui vont avec ou des éléments "dangereux/malveillants", sinon intrusifs (boutons sociaux, Google Sense, vendeurs en ligne, etc) et qui vous suivent ensuite partout où vous allez sur le web et permettent à des tiers de faire du rapprochemetn de donénes massif. Qui utilise le "fallback" (||), qui ne sert à rien? On peut faire bien plus simple sans lui. Deux séparateurs de règles (un majeur ";" et un mineur "," suffisent à tout et ça ne cause aucune difficulté d'interprétation aussi bien pour un robot et c'est le maximum compréhensible par un humain). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Chambres d'agriculture, syndicats ouvriers
Bonjour, Rien ne semble convenir comme attributs pour les chambres d'agriculture et autres chambres consulaires <https://fr.wikipedia.org/wiki/Chambre_consulaire>. Que mettriez vous ? social_centre ne semble pas convenir car c'est un organisme semi-public (certains syndicats agricoles l'ont oublié ;) ). .office=government me semble trop orienté... gouvernement. De même, pour les syndicats ouvriers (CGT, CFDT, FO, CFTC, Sud, etc.) je mettrais amenity=social_centre mais j'ai trouvé de tout sur OSM. Qu'en pensez-vous ? -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Joli noms de rues
Le 18/12/2019 à 09:48, Christian Quest a écrit :
Le mer. 18 déc. 2019 à 02:11, <mailto:osm.sanspourr...@spamgourmet.com>> a écrit :
Mais j'ai une question : où figure l'obligation de nommer les rues
? Je croyais que l'obligation était d'avoir des adresses.
Il n'y a même pas d'obligation forte pour les adresses.
Il y a une obligation faible, surtout avec le chantage au déploiement
de la fibre ("pas d'adresse pas de fibre") et un peu aussi lié à
l'organisation des secours.
Mon hameau a été numéroté, il y a par contre 3 rues/routes qui
n'ont pas de nom.
De mon point de vue c'est une connerie d'attribuer des numéros dans un
hameau sans que ça fasse référence à une voie de circulation.
Pourquoi ?
Pour trouver une adresse, on commence par trouver la voie, puis on la
suit dans l'ordre des numéros. C'est un système simple et efficace.
Des numéros désordonnés sans logique linéaire dans un hameau ne sont
pas facilement trouvables vu qu'il n'y a pas d'ordre naturel ou
conventionnel.
Une numérotation désordonnée, on en a déjà une, les numéros de
parcelle, pas besoin d'une seconde ;)
On peut les "nommer" en utilisant le nom du hameau suivant (c'est
la route en direction de...). Et c'est suffisant.
Ce n'est pas un nom car les hameaux autour du hameau suivant
auront la même description.
Il suffit de prendre une carte OSM.
Oui, comme on ne trouve pas les numéros désordonnés, on a besoin d'une
carte...
Pour le déploiement de la fibre, ça n'a aucun impact, il suffit que
l'adresse soit dans une base de données, l'aspect terrain est
totalement secondaire (sauf pour l'installation, qui se fait une fois
pour toute).
Pour les secours (ou les livraisons)... si ils n'ont pas la carte, les
numéros désordonnés sont plus difficiles à localiser que ceux ordonnés
le long d'une voie.
Le choix pour les noms de rues est important lui aussi...
- avoir un "mot directeur"
- éviter les homonymies (chemin machin / impasse machin), le mot
directeur ne devrait être utilisé qu'une seule fois
- éviter les noms exotiques... car on augmente les fautes de saisies
Les mauvais choix (de nom ou de logique de numérotation) ont des
impacts pour les habitants. De plus les changements pour rectifier des
erreurs dans ce choix ont encore plus d'impacts... il ne faut donc pas
faire n'importe quoi, en premier par respect pour la population.
Bonjour,
En rural, la numérotation des maisons hors bourg est basée en Bretagne
depuis quelques années sur la distance par rapport au début de la rue :
le problème est qu'on ne sait jamais où commence la rue ou le chemin qui
peut être très long. Cela explique les grands nombres pour les numéros
comme 1039 (mètres). D'après des élus, ce serait une lubie de la Poste.
Avec la fibre optique et son « chantage » comme le dit Christian, les
numéros deviennent un véritable Sudoku ;). Les maisons isolées seront
bientôt numérotées en dizaines en Anjou mais suivant l'ancienne commune
à l'intérieur de la nouvelle commune !
Par exemple, toutes les habitations isolées auront comme adresse 30,
suivi de leur nom de lieu-dit pour l'ancienne commune Mimosa à
l'intérieure de la nouvelle Foire-en-Anjou. L'ancienne commune voisine
Lilas dans cette même nouvelle commune, aura ses numéros de maison
isolée en 20. S'il y en a deux dans le même lieu, la suivante aura 21.
Vous me suivez ?
L'avantage : distinguez des maisons ayant la même adresse à l'intérieur
de la même nouvelle commune (si si, c'est très fréquent et cela existe
même à l'intérieur des anciennes communes, j'ai des exemples à 1 km de
chez moi).
L'inconvénient : Une véritable usine à gaz... et du travail pour OSM ;).
-- Rpnpif
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Joli noms de rues
Le 18/12/2019 à 09:48, Christian Quest a écrit :
Le mer. 18 déc. 2019 à 02:11, <mailto:osm.sanspourr...@spamgourmet.com>> a écrit :
Mais j'ai une question : où figure l'obligation de nommer les rues
? Je croyais que l'obligation était d'avoir des adresses.
Il n'y a même pas d'obligation forte pour les adresses.
Il y a une obligation faible, surtout avec le chantage au déploiement
de la fibre ("pas d'adresse pas de fibre") et un peu aussi lié à
l'organisation des secours.
Mon hameau a été numéroté, il y a par contre 3 rues/routes qui
n'ont pas de nom.
De mon point de vue c'est une connerie d'attribuer des numéros dans un
hameau sans que ça fasse référence à une voie de circulation.
Pourquoi ?
Pour trouver une adresse, on commence par trouver la voie, puis on la
suit dans l'ordre des numéros. C'est un système simple et efficace.
Des numéros désordonnés sans logique linéaire dans un hameau ne sont
pas facilement trouvables vu qu'il n'y a pas d'ordre naturel ou
conventionnel.
Une numérotation désordonnée, on en a déjà une, les numéros de
parcelle, pas besoin d'une seconde ;)
On peut les "nommer" en utilisant le nom du hameau suivant (c'est
la route en direction de...). Et c'est suffisant.
Ce n'est pas un nom car les hameaux autour du hameau suivant
auront la même description.
Il suffit de prendre une carte OSM.
Oui, comme on ne trouve pas les numéros désordonnés, on a besoin d'une
carte...
Pour le déploiement de la fibre, ça n'a aucun impact, il suffit que
l'adresse soit dans une base de données, l'aspect terrain est
totalement secondaire (sauf pour l'installation, qui se fait une fois
pour toute).
Pour les secours (ou les livraisons)... si ils n'ont pas la carte, les
numéros désordonnés sont plus difficiles à localiser que ceux ordonnés
le long d'une voie.
Le choix pour les noms de rues est important lui aussi...
- avoir un "mot directeur"
- éviter les homonymies (chemin machin / impasse machin), le mot
directeur ne devrait être utilisé qu'une seule fois
- éviter les noms exotiques... car on augmente les fautes de saisies
Les mauvais choix (de nom ou de logique de numérotation) ont des
impacts pour les habitants. De plus les changements pour rectifier des
erreurs dans ce choix ont encore plus d'impacts... il ne faut donc pas
faire n'importe quoi, en premier par respect pour la population.
Bonjour,
En rural, la numérotation des maisons hors bourg est basée en Bretagne
depuis quelques années sur la distance par rapport au début de la rue :
le problème est qu'on ne sait jamais où commence la rue ou le chemin qui
peut être très long. Cela explique les grands nombres pour les numéros
comme 1039 (mètres). D'après des élus, ce serait une lubie de la Poste.
Avec la fibre optique et son « chantage » comme le dit Christian, les
numéros deviennent un véritable Sudoku ;). Les maisons isolées seront
bientôt numérotées en dizaines en Anjou mais suivant l'ancienne commune
à l'intérieur de la nouvelle commune !
Par exemple, toutes les habitations isolées auront comme adresse 30,
suivi de leur nom de lieu-dit pour l'ancienne commune Mimosa à
l'intérieur de la nouvelle Foire-en-Anjou. L'ancienne commune voisine
Lilas dans cette même nouvelle commune, aura ses numéros de maison
isolée en 20. S'il y en a deux dans le même lieu, la suivante aura 21.
Vous me suivez ?
L'avantage : distinguez des maisons ayant la même adresse (lieu-dit) à
l'intérieur de la même nouvelle commune (si si, c'est très fréquent et
cela existe même à l'intérieur des anciennes communes, j'ai des exemples
à 1 km de chez moi).
L'inconvénient : Une véritable usine à gaz... et du travail pour OSM ;).
En conclusion, je signe ce que dit Christian ; respect de la population
(cela n'a pas été le cas dans le coin de Bretagne mentionné vu les
oppositions locales face à la disparition inutiles de noms connus depuis
toujours).
--
Rpnpif
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] adresse mail rejetée
Le 10/12/2019 à 18:01, marc marc a écrit : quelqu'un a un message d'erreur d'un de ces emails rejetté ? Bonjour, Je aais par une autre adresse que OVH est inscrit à tort comme spammeur chez spamhaus. Ce qui explique que certains reçoivent des messages marqués [SPAM] et que d'autres ne les reçoivent pas car leur serveur est abonné à Spamhaus. -- Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Eglise désacralisée et cimetière
Le 25 novembre 2019, Donat ROBAUX a écrit : > Je suis également pour laisser les tag religion et denomination. Pq? > Parce qu'un temple protestant et une église catholique n'ont pas la même > architecture. Et même si on démonte les croix, il reste parfois des vitraux > ou des sculptures. > On peut également trouver des anciennes synagogues qui ne servent plus au > culte. Donc laisser les tags me parait important pour "conserver" > l'historique. De même que je passe le name en old_name. Je ne trouve pas que ce soit pertinent car au fur et à mesure du temps, ces objets parfois discrets disparaissent et on ne peut distinguer la "denomination" catholique de l'orthodoxe ou autre, etc. Il n'y a pas d'architecture nommée catholique ou même chrétienne. Je connais d'anciennes églises qui sont transformées en magasin (de vêtements par exemple). Pas un magasin catholique ! J'en connais même une transformée en étable (la crèche ? :)) ). Sinon si on suit le raisonnement de Donat, une croix présente dans une maison d'habitation permettrait de marquer le bâtiment par religion=*, ce qui serait abusif. C'est la même chose pour les cimetières municipaux soit la grande majorité des cimetières en France (hors Alsace ?). Ils sont légalement laïques et pourtant on y trouve beaucoup de croix chrétiennes. Mais aussi des tombes sans objets religieux et d'autres avec le croissant musulman ou des signes juifs. Et pourtant beaucoup de cimetières sont marqués de façon erronée religion=christian. Il serait plus pertinent de marquer une simple tombe avec une croix chrétienne par religion=christian. J'enlève systématiquement cet attribut sur les cimetières (je les laisse sur les tombes). L'exception sont les cimetières assez rares de communautés religieuses qui dérogent. Cela n'empêche pas d'avoir parfois à l'intérieur des cimetières municipaux des calvaires catholiques ou au moins chrétiens qui eux peuvent être marqués place of worship et religion=* s'ils sont encore utilisés pour le culte. Et les anciennes écoles catholiques, va t-on taguer les bâtiments religion=* ? non bien sûr. Et bien c'est le même raisonnement pour les anciennes églises. Par contre, d'accord avec les propositions avec une date de fin ou disused:, etc. En résumé, à mon avis, ne disséminons pas le tag religion=* à tout vent, seulement à bon escient, sinon tout devient religieux à tort. -- Alain Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [SPAM] Re: absence de licence sur "adresse-francaise.com": copyvio? vie privée/CNIL?
Le 27 novembre 2019, Philippe Verdy a écrit :
> En attendant on est toujours bombardé tous les jours de spammeurs et
> démarcheurs par courriel, téléphone fixe, mobile, maintenant aussi par
> courrier concernant les prétendues offres "d'isolation à 1 euro" pour tous
> (et ceci malgré la condamnation récente par la CNIL d'une de ces sociétés,
> cela continue, aujourd'hui par courier postal d'une "société" à
> Nogent-sur-Marne (avant à Melun), sous pli téléimprimé, et qui se dit
> "agence française de l'habitat" (autre nom à Neuilly-sur-Seine, mais qui
> déménage souvent, peut-être maintenant à Levallois, Gennevilliers,
> Courbevoie) avec de nouvelles variantes mineurs dans le nom ("officielle",
> "nationale", "pour l'amélioration de l'habitat", "institut", etc...)
> aujourd'hui cette société continue et utilise les mêmes données abusives.
+1 et ras-le-bol !
--
Alain Rpnpif
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nouvelle API du géocodeur et communes nouvelles
Le 2 octobre 2019, Christian Quest a écrit : > Le but de cette demo est surtout de trouver un lieu et de le montrer > ensuite sur la carte, la présentation de ce qui ressemble à une adresse est > très accessoire ;) > C'est le mix adresses + POI qui n'est pas évident, ainsi que la volumétrie > globale: > - 16.4 millions d'adresses BANO > - 4 millions de lieux-dits BANO > - 2.8 millions de POI OSM > - 68000 geonames > > BANO n'est pas totalement à jour sur les fusions de communes, c'est pour > cela que ce n'est pas forcément bien raccord. > > Pour les codes postaux infra-communaux, on peut les cartographier dans OSM > (boundary=postal_code si ma mémoire est bonne), les scripts de BANO en > tiennent compte. C'est utilisé par exemple sur 75016/75116 ou 94100/94210. > > Pour les communes nouvelles, il faut peut être revoir quelques trucs... > > Et puis... La Poste ? Elle nous casse les pieds, qu'elle continue comme ça > et le courrier se réduira encore plus vite vers le zéro. > Ses bases contiennent les anciens noms de commune et peuvent très bien y > distribuer le courrier si elle en a envie (ce qui est à se demander). Merci pour ces explications. Donc à réfléchir dans OSM sur les communes nouvelles. Et on va tenter quand j'aurai un moment de bien faire le zonage du code postal pour Angers par exemple. HS : mais pourquoi le gouvernement complique encore en ajoutant des règles électorales spécifiques aux communes nouvelles. Les fusions qui devait simplifier, compliquent plus en créant une institution à part, donc pas seulement dans OSM. -- Alain Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nouvelle API du géocodeur et communes nouvelles (code postal)
Le 2 octobre 2019, osm.sanspourr...@spamgourmet.com a écrit : > Le 02/10/2019 à 12:10, Rpnpif - rpn...@trob.eu a écrit : > > Bonjour, > > > > Merci à Christian pour la nouvelle API de consultation du géocodeur de > > http://demo.addok.xyhz/. > > Il n'y pas un h en trop que tu as oublié de fumer ? ;-) Oups oui, d'où vient ce h parasite ? http://demo.addok.xyz/ c'est mieux. > > En résumé c'était deux questions : la présentation de l'adresse et le > > zonage du code postal. > > Pour le zonage du code postal on a déjà ce qu'il faut: > > Key:postal code > <https://wiki.openstreetmap.org/wiki/Key:postal%20code?uselang=fr> > > boundary <https://wiki.openstreetmap.org/wiki/Key:boundary>=postal_code > <https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dpostal_code> on a > way or on a *relation* (a relation would also have type > <https://wiki.openstreetmap.org/wiki/Key:type>=boundary > <https://wiki.openstreetmap.org/wiki/Tag:type%3Dboundary>) > > Tu peux aussi utiliser les boundary=admin avec postal_code. > > Je dis bien postal_code, pas postcode qui est réservé aux adresses. Ah je ne connaissais pas boundary=postal_code. Merci beaucoup. Donc ce serait bien de l'utiliser avec la commune nouvelle dans l'API du géocodeur. -- Alain Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Nouvelle API du géocodeur et communes nouvelles
Bonjour, Merci à Christian pour la nouvelle API de consultation du géocodeur de http://demo.addok.xyhz/. Elle est très agréable à utiliser. Je voudrais attirer l'attention sur un problème lié aux communes nouvelles (encore un). Quand on recherche un lieu sur http://demo.addok.xyhz/ (mais c'est pareil sur Nominatim), la présentation de l'adresse est incomplète. Exemple spécifique à la France : La Poste demande que les adresses soient présentées sous la forme : La Rousserie (lieu-dit) Le Louroux-Béconnais (ancienne commune) 49370 Val-d'Erdre-Auxence (nouvelle commune) Elle tolère si le lieu-dit est unique sur la nouvelle commune (pas d’ambiguïté) : La Rousserie (lieu-dit) 49370 Val-d'Erdre-Auxence (nouvelle commune) Mais http://demo.addok.xyhz/ présente ainsi : La Rousserie (lieu-dit) 49370 Le Louroux-Béconnais (ancienne commune) Il manque l'info de la nouvelle commune. Là où ça se complique, c'est quand la nouvelle commune a plusieurs codes postaux. Par exemple Erdre-en-Anjou comporte des communes avec le code 49220 et une avec 49370. Comme ces codes sont basés en général sur les anciennes communes, on peut se baser sur cela pour le mettre devant le nom de la nouvelle pour un lieu déterminé. Par contre, il y a des communes et de nombreuses villes où le code postal est zoné par quartier ou rue ou partie de rue. Dans ce dernier cas, ne serait-il pas possible de créer des aires spécifiques pour l'attribut de code postal comme on les cantons ou autres à parir des données fournis par la Poste ? En résumé c'était deux questions : la présentation de l'adresse et le zonage du code postal. -- Alain Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] switch2OSM
Le 29 septembre 2019, osm.sanspourr...@spamgourmet.com a écrit : > En clair : un galimatias ! > > N. B. : Cassini, carte d'état major et même scan IGN des années 50 ne > donne rien, la carte actuelle IGN comporte le nom avec une autre faute. Il n'y a plus que l'enquête de terrain pour départager tout ça. -- Alain Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] switch2OSM
Le 28 septembre 2019, osm.sanspourr...@spamgourmet.com a écrit : > Joli poisson : sur la carte des Pages Jaunes (Mappy) j'ai eu la surprise > de voir : > > © Mappy <http://corporate.mappy.com/conditions-dutilisation/copyright/> > | 2018 TomTom, OpenStreetMap. > > Bien ? Oui et non car seul Mappy est muni d'un lien. > > Et le lien > https://blog.mappy.com/entreprise/conditions-dutilisations/copyright/ > > © Mappy 2018. Tous droits réservés, reproduction interdite. > > Par vraiment ODbL mais s'ils parlent des tuiles pourquoi pas. > > Et les différentes sources de données se voient attribuées les > copyrights qui vont bien. > > Toutes ? Non visiblement on peut se moquer des données communautaires et > des collectivités : > > 2. AUTRES DONNÉES GÉOGRAPHIQUES > Natural Earth > GeoNames > OpenStreetMap > IleDeFranceMobilité > Toulouse > Lorient > Lille > > Oui, aucun lien vers les copyrights et conditions d'utilisation respectifs. > > Christian, tu dis que les entreprises sont assez réactives si on les > titille sur Twitter, tu peux vérifier : https://twitter.com/Mappy Bonjour, Je ne leur en veux pas car ils utilisent tellement mal les données OpenStreetmap qu'ils n'y intègrent pas des erreurs de noms de lieux corrigées depuis plus de 5 ans dans OSM. -- Alain Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Action sur vandalisme demandée
Bonjour, Une question sur le forum ici : https://forum.openstreetmap.org/viewtopic.php?id=67452 -- Alain Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] école primaire
Le 19 septembre 2019, Dominique Rousseau a écrit : > Le Thu, Sep 19, 2019 at 10:27:58AM +0200, Christian Quest > [cqu...@openstreetmap.fr] a écrit: > [...] > > > > > > En toute logique, maternelle, élémentaire et primaire sont trois options > > > d'amenity=school. > > > > +1 > > > > Chaque pays définissant un age à partir duquel on passe de la garderie > > (optionnelle) à l'école (obligatoire), ce n'est pas à l'age que le tag > > devrait faire référence. > > > > En gros, je pense qu'à partir du moment ou c'est de l'école obligatoire on > > devrait passer en amenity=school > > En France, l'école n'est pas obligatoire, c'est l'instruction qui l'est. > Et depuis que l'âge est passé à 3 ans, l'accueil en "jardin d'enfants" > (aka kindergarten ;-)) peut faire "office de" [1] : > > https://www.service-public.fr/particuliers/vosdroits/F21370 > > > Et pour ce qui concerne les tags OSM et le wiki, je pense qu'on devrait > effectuer une modification pour établir que, pour la France, quand c'est > une « école », c'est amenity=school ; amenity=kindergarten étant utilisé > pour les établissements d'accueil pré-scolaire. > ( pour les autres pays francophones, je ne connais pas du tout leur > fonctionnement ) > > > > [1] pour le coup, c'est un autre débat que de dire si un acceuil en > crèche/garderie peut assurer l'instruction de la même facçon que le > programme d'école maternelle, et poltiquement, ça ressemble à une > tendance vers la kindergartenisation de l'école maternelle. > Tout est dit par Dominique. -- Alain Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] hebdoOSM Nº 474 2019-08-13-2019-08-19
Le 29 août 2019, theweekly@gmail.com a écrit : > Bonjour, > > Le résumé hebdomadaire n° 474 de l'actualité OpenStreetMap vient de paraître > *en français*. Un condensé à retrouver sur : > > http://www.weeklyosm.eu/fr/archives/12335/ > > Bonne lecture ! > > Saviez-vous que vous pouvez vous aussi soumettre des messages pour la note > hebdomadaire sans être membre ? Il vous suffit de vous connecter sur > https://osmbc.openstreetmap.de/login avec votre compte OSM. Pour en savoir > plus sur la rédaction d'un article, cliquez ici: > http://www.weeklyosm.eu/fr/this-news-should-be-in-weeklyosm Bonjour, ... > Le nouveau projet du trimestre britannique consiste à cartographier les > panneaux solaires sur les toits. Cela aidera à prévoir le comportement de la > grille électrique grille-pain ? Les pièges de la traduction automatique ;). electrical grid = réseau électrique. -- Alain Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Track -> Chemin rural
Le 8 août 2019, marc marc a écrit : > track à mes yeux est hors "réseau routier", c'est un chemin agricole, > forestrier, agriculture, loisir (parc). c'est typiquement le chemin que > vous ne prenez jamais en voiture malgré que la largeur le permet Que vous ne prenez presque jamais parce qu'il n'y a que rarement interdiction formelle (en France) si l'état du chemin le permet. Sinon d'accord. -- Alain Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Track -> Chemin rural
Le 8 août 2019, Jérôme Seigneuret a écrit : > Sur la page général alley c'est > pour le chemin secondaire des résidences ou voies étroites en zone > européenne pour les centre de type médiévaux... En dehors de ce cas je préfère service=driveway qui me semble plus adapté (allée en français). Alley signifie ruelle. Si je me souviens bien, il y a une alerte Osmose là-dessus. -- Alain Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Track -> Chemin rural
Le 6 août 2019, osm.sanspourr...@spamgourmet.com a écrit : > Plus sérieusement, ça doit être un réseau et en cas de doute on peut > s'appuyer sur Route 500 de l'IGN. Je ne pense jamais à Route500. Merci de la suggestion. > Tu crois réellement qu'en France un nouveau contributeur va trouver des > primary que personne n'a cartographié avant lui ? Oui, quand la route est neuve ou recalibrée. J'ai vu des bagarres d'édition sur quelques mois où une route changeait d'attribut tous les deux ou 3 mois. -- Alain Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Manque d'attribution : je suis estomaquée
Le 6 août 2019, Christian Quest a écrit : > Voilà ce que j'ai laissé... > > "Bonjour, > > Vous avez déjà été contacté par des contributeurs OpenStreetMap au sujet du > manque d'attribution visible sur votre site pour les fonds de carte > OpenStreetMap que vous utilisez. >... Il vient de répondre ;). https://twitter.com/cq94/status/1158287747381170176 -- Alain Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition - Approuvée - Armement de supports aériens
Le 3 août 2019, François Lacombe a écrit : > Salut à tous, > > Je n'avais pas pris le temps de le faire ici, voici donc le bilan du vote > de la proposition concernant les armements de supports aériens. > https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Lines_attachments > > 23 (24 maintenant) votes exprimés en sa faveur ont permis son adoption. > Merci à tous ceux qui se sont investi pour faire leurs commentaires et > voter le moment venu. > > Évidemment c'est comme à mon habitude très technique et non moins un sujet > qui démontre la force d'OSM. > Les poteaux électriques comme télécom sont actuellement essentiels à > l'installation de la fibre optique en rural comme en urbain parfois. > Leur recensement ainsi que certaines caractéristiques comme celle-ci > intéresse les acteurs de ce déploiement (qu'ils ne manqueront pas > d'utiliser en respectant la licence et la communauté), j'en ai parlé au > sotm cette année. > > N'hésitez donc pas à faire un petit tour autour de chez vous et apporter > votre pierre à l'édifice si vous en avez l'occasion > Les poteaux en question sont visibles sur le rendu standard et sur > OpenInfraMap. Ce dernier pourra certainement rendre la clé line_attachment > dans les prochaines semaines. Très bien. Juste pour l'anecdote, à mon grand étonnement, j'ai vu il y a quelques mois dans un pays voisin que je ne nommerai pas pour ne pas vexer des attaches (armements est un grand mot) avec des bouts de ficelles dans un capharnaüm sans nom sur des centaines de mètres, sous tension bien sûr ! Je n'avais jamais vu ça. Bien sûr ce type d'armement (illégal) n'est pas prévu, je suppose. -- Alain Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Track -> Chemin rural
Le 6 août 2019, emeric Prouteau a écrit : > Cartographiant énormément en milieu rural je suis d'accord sur le fait > qu'il est parfois difficile de bien définir une voie.et notamment pour > highway=service pour définir des voie déservant des fermes isolées. Pour > highway=unclassified d'un point de vue rendu on a tendance à plus > l'utiliser car il sera plus visuel qu'un highway=service par exemple. > > Je serais également partisan d'un enrichissement des définissions par des > exemples plus concret de ce que l'on peut trouver sur notre territoire. Mais il est très déconseillé de cartographier pour le rendu ;). https://wiki.openstreetmap.org/wiki/FR:Tagging_for_the_renderer Le rendu est le travail du logiciel qui exploite les données et pas du contributeur, ni d'openstreetmap.org. Si le rendu n'est pas bon sur https://www.openstreetmap.org il faut demander une amélioration sur https://github.com/mapnik/mapnik/issues On peut aussi essayer https://tile.openstreetmap.fr/. Et là les demandes d'amélioration peuvent être faites ici entre autres. Mieux on peut choisir plusieurs modèles de cartes sur https://umap.openstreetmap.fr/fr/ ou sur https://framacarte.org/fr/ -- Alain Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Track -> Chemin rural
Bonjour, Le 31 juillet 2019, Jean-Claude Repetto a écrit : > C'est l'usage du chemin, et non son état, qui détermine son type OSM: > - usage agricole ou forestier -> highway=track > - usage général -> highway=unclassified Ce qui veut dire qu'il faut vivre sur place pour le savoir. C'est un peu trop restrictif comme définition car dans ce cas la plupart des millions de chemins français ne peuvent être taggués faute de contributeurs vivant à côté ou de panneau les définissant. Je préfère marquer les chemins suivant leur état. Sans asphalte : c'est track sauf si un panneau dit le contraire. Avec asphalte : c'est highway sauf si un panneau ou une situation (un bout isolé en plein milieu d'une forêt par exemple) montre le contraire ou qu'un asphalte en très mauvais état indiquant qu'il est emprunté majoritairement pas des engins agricoles. Sinon, on ne peut plus rien faire. Par ailleurs, pour unclassified, je reviens au sens originel : une route dont on ne sait qualifier son rôle. Donc cela devrait être théoriquement une solution provisoire. Une route asphaltée qui dessert des champs est pour moi highway=service (comme en ville) ce qui est logique. highway=tertiairy : une route reliant deux hameaux (que certains et aujourd'hui le wiki -- ce qui n'était pas le cas précédemment -- confondent avec villages, les petites villes). Je sais que tout le monde n'est pas d'accord là-dessus mais le bon sens des mots devraient nous guider sinon ces définitions ne seront pas durables ou très mal appliquées, ce qui est le cas aujourd'hui. De même, on a toujours un méli-mélo entre highway=path et highway=track. Pour moi path est un sentier donc de faible largeur (moins de 2m environ). Je ne parlerai pas ici des highway=secondary et primary qui sont aussi sujet à caution tellement leurs définitions sont subjectives. En rural, chacun voulant que la « grande route » qu'il utilise pour aller au boulot soit classée primary et vice-versa l'urbain qui a l'habitude des voies rapides ou des autoroutes et autres voies larges classera tout en secondary ou même en unclassified. Je serais partisan d'une remise à plat de tout ça de façon qu'un nouveau contributeur ne s'arrache pas les cheveux pour savoir comment tagguer ce qui diminuera les corrections à faire derrière certains contributeurs. Bien sûr comme certains l'ont signalé, Id avec certaines traductions approximatives ou fluctuantes suivant les versions n'arrange rien. Ce n'est que mon avis. -- Alain Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Références nationales : RNA
Le 11 juin 2019, Christian Quest a écrit : > Je confirme plusieurs points: > - toutes les assos n'ont pas de numéros RNA (aussi appelé N° Waldec), mais > elles peuvent avoir un numéro plus ancien... mais parfois aussi on ne les > retrouve pas dans cette base de données (pas super bien gérée) > - toutes les assos ne sont pas inscrites dans la base SIRENE qui attribue > les N° SIREN (personne morale) et SIRET(établissement, donc lieu et > activité) > > Par ailleurs, les données du RNA sont loin d'être de qualité. Les adresses > en particulier sont assez problématiques, pas forcément à jour ni correctes > (le géocodage est vraiment complexe, pour ça que je ne l'ai fait qu'une > fois). > Je ne parierai pas non plus sur la qualité (fraicheur, exhaustivité) des > autres infos. > > Rien n'empêche d'ajouter un ref:FR:RNA quand tout semble coller, mais de là > à en tirer quelque chose pour lier les bases je pense que ce n'est vraiment > pas d'actualité. > > Seuls les locaux fixes, dédiés me semblent pertinent à avoir dans OSM, donc > partir des règles OSM habituelles (vérifiable sur le terrain, stable, etc). > Bien d'accord. Les exemples sont très nombreux de petites associations dont le siège social se trouve soit à la Mairie du lieu ou bien chez le président actuel ou ancien ou bien parfois chez un simple membre qui ne fait que recevoir le courrier. Mais ce n'est que très rarement le lieu de réunion ou de local constant. L'occupant du siège social ne souhaite pas forcément que son domicile soit noté comme le lieu de résidence de l'association qui n'a d'ailleurs que peu ou pas d'activité dans ce lieu. En conclusion, je ne vois pas l'intérêt d'utiliser ce fichier pour noter les associations dans OSM. On ne devrait noter que les associations avec pignon sur rue avec un local identifié et des horaires d'ouvertures au public affichées. Cela peut être dans un local de la mairie si c'est régulier. Ou bien si le local a une enseigne avec le nom de l'association. -- Alain Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] uMap donner les droits Éditeur à un utilisateur avec espace
Le 10 juin 2019, Jean-Christophe Becquet a écrit : > Le 09/06/2019 19:43, Jacques Lavignotte a écrit : > > Le 09/06/2019 à 18:27, pepilepi...@ovh.fr a écrit : > > > >> T'as essayé de mettre l'identifiant entre guillemets ? > > > > Essayer : > > > > paul\ valery > > > > paul%20valery > > Bonjour, > > Merci pour vos réponses. Ça a marché en supprimant simplement l'espace > lors de la saisie : Bonjour, J'ai le même genre de problème quand le nom d'utilisateur contient un caractère accentué : par exemple Chêne sera affiché Chne sur les pages de Umap. -- Alain Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pac man
Le 8 juin 2019, Yves P. a écrit : > Bonjour, > > Une curiosité sur laquelle je suis tombé en cartographiant un gazoduc > (merci Fanfoué ) > > https://www.openstreetmap.org/#map=15/46.3674/3.3656 > > Au zoom 15, elle n'est visible que sur la couche Humanitaire. > On devine son contour aux zoom >= 16 > > Il y en a un peu plus ici : > https://www.openstreetmap.org/#map=14/46.4648/3.3273=H > > Article wikipedia > <https://fr.wikipedia.org/wiki/Irrigation_%C3%A0_pivot_central> > > Pour le moment en Europe, Il n'y a que celles que j'ai commises. Est-ce que > vous en connaissez d'autres, notamment en France ? Bonsoir, Oh oui j'en connais d'autres (non renseignés sur OSM mais c'est une bonne idée). En fait il y en a dans la plupart des zones agricoles malheureusement, dont dans l'Ouest de la France. Malheureusement parce ce n'est pas bon pour la ressource en eau (trop d'évaporation, gaspillage, pompage d'eau potable parfois, salinisation de la terre à la longue la rendant stérile, etc.). Par contre le motif circulaire est rarement visible par ici parce qu'on cultive toute la parcelle polygonique et on n'arrose qu'une partie. J'essaierai d'en relever sur OSM. Bon congé. -- Alain Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] hebdoOSM Nº 460 2019-04-30-2019-05-06
Le 20 mai 2019, theweekly@gmail.com a écrit : > Bonjour, > > Le résumé hebdomadaire n° 460 de l'actualité OpenStreetMap vient de paraître > *en français*. Un condensé à retrouver sur : > > http://www.weeklyosm.eu/fr/archives/12067/ Voici le vrai 460 : http://weeklyosm.eu/fr/archives/12108 -- Alain Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] hebdoOSM Nº 460 2019-04-30-2019-05-06
Le 20 mai 2019, theweekly@gmail.com a écrit : > Bonjour, > > Le résumé hebdomadaire n° 460 de l'actualité OpenStreetMap vient de paraître > *en français*. Un condensé à retrouver sur : > > http://www.weeklyosm.eu/fr/archives/12067/ Encore raté ! C'est toujours le n°459. -- Alain Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] nommite sur les écoles
Le 18 mai 2019, osm.sanspourr...@spamgourmet.com a écrit : > Bonjour, > > je trouve de plus en plus de doublons de noms > amenity=Kindergarten/school et building=*. > > Exemple <https://www.openstreetmap.org/#map=17/47.87190/-3.56175>. > > Heu, bon là c'est encore pire : il y a une zone amenity=school pour 4 > écoles, des amenity=ponctuels (dont un doublon) et un amenity=school sur > un building et le wiki parle de landuse=school. > > Prenons plutôt celui-ci > <https://www.openstreetmap.org/way/36845196#map=18/47.88392/-3.8> > plus simple : en plus de la zone amenity=school, name=XXX, on a un > building= name= (en fait non c'est encore un nœud amenity mais c'est ce > qu'il a voulu faire, il a respecté le wiki). > > Du coup on se trouve avec deux fois le même nom sur la carte. > > *Qu'en pensez-vous ?* > > 1 ne mettre que building=school sur le bâti, mettre toute l'information > pertinente sur le amenity=school (qui sera confondu si toute la surface > est bâtie) > 2 laisser les doublons de nom, c'est au moteur de rendu de faire le ménage > > Comme Rom1 je suis pour le 1. Clair, non ambigu, pas de double maintenance. > > Cas particulier d'un groupe scolaire, mettons Groupe scolaire primaire > Tartempion avec un bâtiment pour des maternelles et un pour les cours > élémentaires : ajouter name=maternelle et name=élémentaire sur le bâti > ne me choquerait pas. > > Marc suggère les relations mutipolygones (j'ai plutôt tendance à > favoriser les relations site). > > Maintenant les noms en OpenData sont rarement des noms et bien plus > souvent des descriptions. > > Exemple : prenons les écoles de Plancoët. > > Ecole primaire publique de Plancoet, Ecole maternelle publique de Plancoet > Premier soucis, l'école primaire n'est pas une école primaire mais une > école élémentaire, passons (la mairie > <http://www.plancoet.fr/Etablissements-scolaires2.asp> de Plancoët est > plus au courant que l’Éducation Nationale). > > Si on prend la même règle que pour les églises on vire "de Plancöet" car > c'est le nom de la commune (par contre pour les gares on les garde et > pour les bureaux de poste on les garde plutôt). > > *Alors on garde ou pas ?* J'aurais plutôt tendance à virer (sauf si > c'est un vrai nom style École Henri Dès). > > Maintenant le statut public/privé : ça fait partie de operator:type donc > inutile ? Au début c'est ce que je pensais mais à force d'en voir dans > OSM, je laisse. Et la différence n'est pas toujours évidente : le > collège de Saint-Marc (quartier de Brest) était public, le collège > Saint-Marc privé (toujours dans le même quartier) parasitait le nom (le > premier étant le meilleur de la ville par ses résultats). Depuis le > premier est devenu de l'Iroise et le second Collège de Saint-Marc > (Estran) selon OSM et Collège Estran Saint-Marc selon l'éduc' nat'. > > *Dans ce cas vous allez virer école* (c'est dans amenity=school) *et > maternelle* (amenity=nursery). > > Poursuivons : *collège, lycée, primaire*... c'est dans school:FR(*). > > Donc on ne laisserait que les vrais noms style Henri Dès ou Collège de > l'Iroise. > > (*) Et pourquoi ne pas mettre des icônes plutôt que du texte ?sample of > HATCHING CHICK (U+1F423)sample of BABY SYMBOL (U+1F6BC)crèche/garderie > > sample of BABY CHICK (U+1F424)maternelle > > sample of GIRLS SYMBOL (U+1F6CA)sample of BOYS SYMBOL (U+1F6C9)élémentaire > > image of Unicode Character 'SCHOOL SATCHEL' (U+1F392)collège > > image of Unicode Character 'CHILDREN CROSSING' (U+1F6B8)lycée > > Je crois que le système français est un peut trop compliqué pour qu'on > arrive à s'y retrouver avec uniquement des icônes mais je veux bien > qu'on me prouve le contraire. J'ai pris des caractères Unicode. > Bonjour, Il y a des ensembles scolaires qui ont souvent un nom un peu différent de celui des établissements. Exemple : une école Machin, un lycée prof. Truc, un lycée général Jojo forment l'ensemble Sac-Truc. Ils peuvent être des entités juridiques différentes mais former le même ensemble lié (c'est souvent le cas dans le privé mais aussi parfois dans le public). J'ai des exemples. Moi, je marque tout individuellement et aussi l'ensemble. Sur les cas précis que tu cites, je n'ai pas d'avis, il faut voir sur place. C'est juste pour dire que cela dépend. Les erreurs dans la base des académies ne sont pas rares car il y a souvent un manque de rigueur dans l'enregistrement. (Je parle par expérience). Je dirais que seuls font foi les documents juridiques... quand ils sont trouvables. Les documents issus directement des établissements sont aussi pas mal... quand ils n'ont pas des appellations « commerciales ». amenity=school sur le bâti ne me choque pas
Re: [OSM-talk-fr] Malgré un premier blocage, cela continue ! L3mp1ck4 / Dupuiche / Y43l / ninamartin
Le 17 mai 2019, marc marc a écrit : > Le 16.05.19 à 17:03, Rpnpif a écrit : > > Le 16 mai 2019, Vincent Bergeot a écrit : > > > >> Le 03/05/2019 à 15:41, Stéphane Péneau a écrit : > >> peut-être que l'on va avancer sur la licence et sur les décisions à > >> prendre : > >> https://www.openstreetmap.org/changeset/45891332#map=17/47.95862/1.87889 > > > > Un peu risqué sa réponse : les demandes de permis de construire > > pourraient être refusées, même si l'intention est louable. > > chapeau Vincent pour la motivation à suivre le cas. > je rajoute sur la liste ninamartin (nouveau compte qui semble > être l'action de la même personne ou même entreprise et a subit un > blocage (déjà expiré) pour la même raison) > bonne idée que d'aborder chaque point séparément. > > pour ma part, la liste des problèmes : > 1) la source réelle des données. > J'ai un sérieux doute que les données viennent de la mairie. > vous voyez quelqu'un qui passe ses heures de bureau à aller en Mairie > chercher une copie des permis de construire pour ensuite les ajouter > dans osm ? > cela manque de transparence. > Certains projet avec des arbres qui bougent par ex donnent > l'impression que le gars travaille le rendu de l’esquisse dans osm. > donc sans doute bien en amont de la demande de permis de bâtir. > > 2) la licence, sans cela on peux rien faire (nickel d'avoir fait un > sujet dédié) > > 3) la différence entre une demande de permis (n'importe qui peux > demander, y compris plusieurs demandes sur la même chose) et un permis > obtenu. la différence entre un permis obtenu et le début des travaux > (certains promoteur demande un permis, vente le projet à l'état de > permis, voir vendent des options jusqu'à ce que le taux de vente soie > suffisant pour passer à l'étape "on va le faire", cfr la saga des VEFA). > la différence entre début des travaux et constuction (on est entrain > de casser l'ancien parking <> il y a un immeuble de 6 étapes > en construction") > la différence entre "en construction" et gros œuvre fermé. > La différence entre fin de travaux et maturité (pour la hauteur > des arbres par ex... pour lesquelles je pense que le mieux > est de ne pas renseigner d'hauteur à la plantation parce que je doute > que quelqu'un va suivre le sujet une fois les logements vendus) > De manière générale, je pense que : > - une demande de permis n’entraîne rien pour osm, trop d'incertitude. > - l'acceptation d'un permis pourrait se renseigner avec des planned: > - début des travaux landuse=constuction > - démolition/reconstruction : utiliser un prefix à la démolition pour > pouvoir garder l'historique à la reconstruction. aide aussi à comprendre > les choses quand on regarde une imagerie postérieur à la démolition. > - building=construction quand il y a un début de bâtiment (fondation > en cours au minimum) > - arbre uniquement une fois plantée, trop de promoteur qui ne plante > au final aucun arbre car à la subtilité que l'aménagement extérieur > est rarement dans le contrat de vente aux clients. mais je pourrais > comprendre un planned: du moins si cela ne reste pas en base > pour l'éternité +1 Ce serait bien de mettre tout ça dans le wiki. -- Alain Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Licence des Permis de construire, compatibilité OSM
Le 16 mai 2019, Vincent Bergeot a écrit : > Le 16/05/2019 à 18:10, Gwenaël Jouvin via Talk-fr a écrit : > > Bonjour, > > > > Je ne saurais préciser quel est le type de licence d’un tel document, je > > serais même choqué d’apprendre que de tels documents soient soumis au droit > > d’auteur. > > Pour moi, comme tout document produit et publié par une administration, > > c’est dans le domaine public ? > > je dirais (sans être juriste) que l'obtention d'un permis de construire > est produite par une administration mais le dépot d'une demande de > permis de construire, avec un plan, est plutôt fait par un architecte. > > J'aurai du préciser que le plan contenu dans une demande de permis de > construire est-il soumis à une licence ouverte. > > Les discussions sur l'usage des permis de construire concernent (à mon > avis) les plans contenus dans ces demandes. > > Je ne sais pas si c'est clair, je ne suis ni archi ni juriste :) Oui mais ils sont consultables par tout citoyen (ce qui ne répond pas à la question). Donc publiables ? Les plans doivent avoir quand même une protection (illégitime à mon sens mais c'est subjectif) pour l'architecte. -- Alain Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Malgré un premier blocage, cela continue ! L3mp1ck4 / Dupuiche / Y43l
Le 16 mai 2019, Vincent Bergeot a écrit : > Le 03/05/2019 à 15:41, Stéphane Péneau a écrit : > > Ah oui, j'avais oublié cet aspect "license" , merci de me le rappeler. > > > Oua, une réponse :) > > peut-être que l'on va avancer sur la licence et sur les décisions à > prendre : > https://www.openstreetmap.org/changeset/45891332#map=17/47.95862/1.87889 Bonjour, Un peu risqué sa réponse : les demandes de permis de construire pourraient être refusées, même si l'intention est louable. -- Alain Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
