Re: [OSM-talk-fr] OverPass et rue sans éclairage en ville
Bonjour,
J'ai fait quelques essais supplémentaires et mes requêtes sont toujours en
erreur ou bien les commandes utilisée ne sont pas les bonnes.
Est-ce qu'une personne aurait une piste de recherche en m'indiquant le nom des
commandes à utiliser ?
Le July 3, 2020 1:13:19 PM UTC, Percherie OnDaNet
a écrit :
>Bonjour,
>
>
>Je suis en train de regarder comment extraire les voies sans éclairage
>en ville et les voies principale hors aglo. Je part de la requête
>suivante :
>
>[out:json][timeout:250];
>(
> way["highway"][!"lit"]({{bbox}})(if: length() > 30);
>);
>// print results
>out body;
>>;
>out skel qt;
>
>Comment ajouter une zone englobante ayant les tags suivant :
>landuse=residential|retail|commercial|industrial
>
>En dehors de ces zones, je compte exclure les tag suivant :
>highway=track|path|road
--
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise à jour BANO
Bonsoir, > De: "Jérôme Amagat" > > Je pense que bano v2 ne gère pas toutes les communes nouvelles vu que > le nom de la commune indiquée par bano est Saint-Jean-sur-Couesnon > qui n'existe plus alors que la commune nouvelle "Rives-du-Couesnon" > créée en 2019 a le même code insee, Saint-Marc-sur-Couesnon est > aussi toujours present > https://bano.openstreetmap.fr/fantoir/index.html#insee=35293=3 Un postulat de base pour BANO était qu'on ne rencontrait qu'une seule occurrence de chaque nom de voie sur le terrain, pour une commune donnée. Pas de bol avec les fusions, qui provoquent le casse-tête (pour tout le monde, pas juste pour BANO) d'homonymies infra-communales, avec x rues de l'Eglise, y place de la Mairie, etc. Je n'ai pas d'idée immédiatement de correctif pour gérer ça proprement, car ça casse un des fondamentaux de BANO. De là à dire qu'il faudrait tout casser pour bien gérer les homonymies, il y a peu. Pour répondre à Pierre-Yves : dispatcher le code Fantoir sur les ways ne changera (hélas) rien au problème. On peut imaginer casser le paradigme de BANO, en donnant l'ascendant au code FANTOIR sur le nom. Ca résoudra les homonymies, pas sûr que ça ne casse pas autre chose... On peut continuer d'en discuter ici, n'hésitez pas à détailler les problèmes directement sur le repo aussi : https://github.com/osm-fr/bano/issues merci vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Message de service :: Travaux sur l'infra 6/7 après-midi.
Le 06/07/2020 à 12:22, Jacques Lavignotte a écrit : Cet après-midi, intervention pour upgrade matériel sur nos serveurs osm12 et osm13 chez Free. Quelques coupures sont à prévoir. Liste des serveurs/services : https://wiki.openstreetmap.org/wiki/FR:Serveurs_OpenStreetMap_France Pour vous tenir au courant, voici ce qui a été fait ces derniers temps sur notre infra: - mi-juin, nous avons fait un upgrade logiciel de nos 4 serveurs OVH (le serveur de rendu FR + le cluster de 3 serveurs). Il s'agissait de passer à la version 6 de Proxmox, la distrib linux que nous utilisons et qui nous permet de gérer la virtualisation des différents services. - hier, j'ai procédé à l'upgrade hardware du côté de la fondation free 4 nouveaux SSD de 2To chacun ont été installés pour étendre la capacité et accélérer les accès disque. Ces serveurs, don de la fondation free en 2012, voient ainsi leur espérance de vie rallonger de quelques années. Les données OSM ne font qu'augmenter en volume et en détail et le trafic a largement augmenter lui aussi en 8 ans, d'où le besoin de toujours plus d'espace de stockage rapide ! Pour mémoire, ces serveurs n'avaient aucun SSD à l'origine, nous avons dû en ajouter au fur et à mesure des années alors que la charge montait (et continue de monter). La RAM a aussi été augmentée (64+64Go devenus 160+96Go) et un 4ème serveur (récupéré gratuitement il y a quelques mois) a aussi été installé temporairement pour faciliter les mises à jour des 3 autres déjà présents. Depuis hier, migration des données sur les nouveaux SSD, un peu de nettoyage et quelques upgrades sotfware pour osm13 qui assure à nouveau un service normal pour le rendu humanitaire, les rendus Route500, Carthage, QA et les rendus "layers". Il y a eu quelques coupures sur cadastre.openstreetmap.fr et download.openstreetmap.Fr qui ont été résolus ce matin. Aventures à suivre... car il y a d'autres épisodes prévus ;) -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise à jour BANO
pour l'exemple je me suis trompé de rue de la mairie. celle indiqué est bien rapproché mais pas celle la https://www.openstreetmap.org/relation/11263768 name=Rue de la Mairie ref:FR:FANTOIR=352820032V non rapproché https://bano.openstreetmap.fr/fantoir/#insee=35282=2 Je pense que bano v2 ne gère pas toutes les communes nouvelles vu que le nom de la commune indiquée par bano est Saint-Jean-sur-Couesnon qui n'existe plus alors que la commune nouvelle "Rives-du-Couesnon" créée en 2019 a le même code insee, Saint-Marc-sur-Couesnon est aussi toujours present https://bano.openstreetmap.fr/fantoir/index.html#insee=35293=3 Le mar. 7 juil. 2020 à 19:46, Jérôme Amagat a écrit : > Je ne sais pas si le problème vient de là mais il y a un souci de > rapprochement avec bano v2. > des codes fantoir qui sont sur des relations associatedStreet sont indiqué > comme non rapproché sur la page > https://bano.openstreetmap.fr/fantoir/#insee=35282=2 > exemple name=Rue de la Mairie ref:FR:FANTOIR=352820045J > https://www.openstreetmap.org/relation/11261731 > la relation a été crée le 1/07 et le rapprochement est indiqué comme fait > le 4/07 https://bano.openstreetmap.fr/fantoir/#insee=35282=2 > > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas
Non je pense que addr:* est encore adapté quand la rue la plus proche n'est pas la bonne mais il faut indiquer une adresse du point lui-même (son adresse d'accès pour s'y rendre). Alors que contact:* c'est pour des adresses de contact (par courrier, mais PAS pour y aller physiquement: cette adresse peut-être partout **ailleurs** dans le monde) et ne sont utiles que justement ce n'est pas l'adresse physique du lieu pour s'y rendre. Ces adresses dans "contact:*" ne doivent RIEN géolocaliser du tout (on y trouve des adresses "virtuelles", notamment des CEDEX spéciaux et boites postales/poste restantes, des services externalisés chez un tiers) Aucune "addr:*" ne devrait contenir un CEDEX ou boite postale en poste restante: si c'est le cas, il FAUT mettre l'adresse dans CONTACT (au moins le code postal et le nom du CEDEX, le code de distribution spéciale sans adresse géographique) Le mer. 1 juil. 2020 à 18:56, Yves P. a écrit : > Si il n'y a pas de addr:xxx déjà présent, il faudrait l'ajouter à sa place > et pas comme un effet de bord de tel ou tel import de POI. > > Ou prendre le temps de créer le point adresse et ne pas rajouter de > contact:* > > Je vois l'intérêt de contact:* quand l'adresse postale est différente du > n° de rue le plus proche. > > __ > Yves > > ___ > 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] Mise à jour BANO
Je ne sais pas si le problème vient de là mais il y a un souci de rapprochement avec bano v2. des codes fantoir qui sont sur des relations associatedStreet sont indiqué comme non rapproché sur la page https://bano.openstreetmap.fr/fantoir/#insee=35282=2 exemple name=Rue de la Mairie ref:FR:FANTOIR=352820045J https://www.openstreetmap.org/relation/11261731 la relation a été crée le 1/07 et le rapprochement est indiqué comme fait le 4/07 https://bano.openstreetmap.fr/fantoir/#insee=35282=2 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise à jour BANO
Bonjour, Constatant que la dernière version du FANTOIR intégrait désormais les communes nouvelles de 2019 et que la BANO v2 était désormais disponible dans http://bano.openstreetmap.fr/data/, j'ai donc testé le 30 juin ce que ça donnait dans mon secteur. Ça m'a permis de repérer un souci lié aux voies homonymes dans une même commune nouvelle. J'ai focalisé mon attention sur Rives-du-Couesnon (code INSEE 35282). Mon extraction BANO précédente des voies de ce qui était alors quatre communes distinctes pour le FANTOIR s'était passée sans souci. J'ai donc eu la désagréable surprise de constater que seules les voies de Saint-Jean-sur-Couesnon (code 35282) étaient reprises dans BANO v2 et aucune des autres ex-communes. J'ai donc refait une passe sur OSM pour forcer les nouveaux codes FANTOIR dans les relations AssociatedStreet de la commune (cf. https://www.openstreetmap.org/relation/6600634, par exemple). Je m'attendais donc à ce que l'extraction de BANO faite après cette opération me fasse ressortir tous les points adresses de la commune. Hélas, non... Il faut dire que Rives-du-Couesnon présente l'intérêt d'avoir dans chacun de ses quatres bourgs historiques des voies nommées, avec une remarquable originalité, "Rue de la Mairie" ou "Rue de l'Église". Et c'est là que le bât blesse... Bien que la rue de la Mairie de Saint-Marc ait un code (352820032V) différent de celui de la rue de la Mairie de Saint-Jean (352820007T), le code retenu pour chaque adresse de Rives-du-Couesnon située dans une des rues de la Mairie est celui de la rue de la Mairie de Vendel (352820045J)... Et les points ayant le même numéro sont tout bonnement ignorés pour ne garder qu'un seul "2 rue de la Mairie". Étant donné que, sur le terrain, chacune de ces rues a gardé sa plaque "Rue de la Mairie", il ne me semble pas opportun de renommer les rues dans OSM pour les faire correspondre aux appellations du FANTOIR (Rue de la Mairie St Marc, Rue de la Mairie Vendel ou Rue de la Mairie St Jean). Pour que le fichier BANO soit correct, y-a-t-il moyen , via http://bano.openstreetmap.fr/fantoir/, de forcer le rapprochement entre une relation AssociatedStreet et son code correspondant ? (Je n'ai pas vu comment faire) Ou bien faut-il que chaque highway concernée ait une valeur "ref:FR:FANTOIR", ce qui n'est pas recommandé vu que ledit code s'applique à une relation ? Merci pour vos éclairages. Pierre-Yves Le mar. 3 mars 2020 à 22:44, Vincent de Château-Thierry a écrit : > > Le 03/03/2020 à 19:39, Pierre-Yves Mevel via Talk-fr a écrit : > > Merci Vincent pour cette réponse. > > > > Donc, ça finira bien par revenir. Je ne me sens pas les compétences pour > > aller tripatouiller sur Github, mais si je peux être utile à quoi que ce > > soit, n'hésite pas à me faire signe. > > Si tu es partant pour beta-tester les fichiers d'Ille-et-Vilaine en v2 > dès leur dispo, moi ça me va :) > > vincent > > ___ > 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] Tag pour les services d'un établissement, quand ils sont adaptés aux fauteuils roulants
Bonjour, Réponse uniquement sur la forme ;) >> Je prends un exemple "simple" : la place de stationnement. >> Que veux dire wheelchair=yes ou même wheelchair=designated ? > wheelchair=designated pour une place pmr n'est pas sensé être utilisé, […] Je ne parlais pas trop du détails des tags (il doit y avoir au moins 3 manières différentes de taguer une place PMR) (MP) > yes : tout ce que tu dis mais une place limite côté largeur. > designated : la largeur etc... tout est conforme à la norme. (Violaine) > wheelchair désigne l'accessibilité du lieu, donc il peut y avoir une place > dédiée aux PMR qui ne soit pas ou plus accessible (par exemple une place pas > aux normes mais bien peinte en bleu, ou bien où les racines d'un arbre voisin > a rendu la surface impraticable, …) La réalité est assez proche de la réponse de Violaine. C'est une place peinte en bleu ;D Je m'explique : Une personne qui a un véhicule adapté avec une rampe longue, un "ascenseur", ou un "simple" fauteuil passager qui sort en tournant du véhicule… Avec le dispositif sur le côté, derrière… En étant seul et conduisant son véhicule, ou forcément avec un accompagnant valide… Toutes ce combinaisons, font qu'on ne peut pas répondre à la question facilement. Par contre des tags qui indiquent précisément la largeur et la longueur de la place permettront aux occupants du véhicule de savoir si elle est utilisable. Dans ce cas, pas besoin de les inventer, il suffit de mapper ça avec un polygone. Et inciter les logiciels à calculer les dimensions ;) Un autre exemple réel : Des toilettes indiquées comme adaptées dans une aire de service d'autoroute. Elles l'étaient réellement :) … sauf qu'elles servaient de stockage de cartons :( La ce n'est pas directement un problème de tag, mais plutôt de vérification ou de mise à jour des informations. Un cas souvent rencontré : le seuil d'accès de l'entrée d'un établissement. Suivant la pente, la hauteur du seuil, du handicap, du "fauteuil"… l'accès ne pose pas de problème :) ou est complètement impossible. Je me souviens que ce qu'attendaient les PMR n'étaient pas des tags pour qualifier ça (car il y a toujours des cas particuliers qui ne rentrent pas dans les cases)… mais une photo pour se rendre compte par elle même de la situation. A+ __ Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
