Re: [OSM-talk] The end of waterway map
Hi Amanda, Thank you for this additional piece of very useful tool :) > WWM/ends excludes canals. It's ok but it includes pressurised waterways and these nodes are flagged as ends : https://www.openstreetmap.org/node/2255728449/ I'd like to include canals instead of removing pressurised waterways (which connect to upstream rivers and it could lead to other mistaken ends too). Isn't this an opportunity to check the appropriate usage of inlet/outlet values and man_made=outfall as well? https://wiki.openstreetmap.org/wiki/Key:inlet https://wiki.openstreetmap.org/wiki/Key:outlet https://wiki.openstreetmap.org/wiki/Tag:man_made%3Doutfall Best regards François Le lun. 29 janv. 2024 à 21:04, Amanda McCann a écrit : > I've added a new feature to [WaterwayMap.org: A map showing where > waterways end](https://waterwaymap.org/ends/), i.e. a map of the > ends-of-waterways . > > It shows nodes which are “the end” of a waterway, i.e. where the water > can't go anywhere else. Uniquely, it calculates the total upstream length > of waterway ways which end at a point. It uses the direction of OSM ways, > and how they are connected. This should make larger mistakes more visible. > Like the rest of WaterwayMap.org, data is updated daily, at the same time. > > It's normal for there to be ends, like when a river ends at a coastline. > This will rightly show up on WWM:Ends. When a river empties into a lake, > this will also show up, unless we've mapped a waterway through the lake. > There's [active discussion]( > https://community.openstreetmap.org/t/should-river-lines-be-mapped-through-lakes-estuaries-gulfs-and-other-large-water-bodies/104438) > on when & how to do that. > > # Merging & Splitting > > When 2+ waterways come together, the upstream value is added together. > When 2+ waterways split, the upstream value is split equally. This mostly > works well, e.g. when a river splits through a side channel, and then > rejoins. > > If you have a small stream going into a large river, and it's in the wrong > direction, then half the upstream value from the big river will go off to > the side stream. This is a mapping mistake, and this tool makes it easier > to find them. e.g. [way 962171457]( > https://www.openstreetmap.org/way/962171457/history) is mapped as flowing > *out* of the Nile, so it's taking 17,000 km of upstream away! [on > `wwm/ends`](https://waterwaymap.org/ends/#map=13.8/17.96527/33.98571). > This direction should probably be reversed. > > Conversely, [this way]( > https://www.openstreetmap.org/way/67963223#map=19/52.66517/-8.62906) is > taking half (930 km) of the Shannon [wwm/ends]( > https://waterwaymap.org/ends/#map=15.34/52.66393/-8.627153). I don't > think this should count as an “end”, but the mapping looks ok. WWM/ends > excludes canals. I'm unsure if it's possible to calculate the right value. > Perhaps more advanced tag calculations. What do yous think? > > I hope you enjoy this new map & we all improve OSM together. > > # See also > > • a short description of [how it works]( > https://waterwaymap.org/ends/help/). > • [News about WaterwayMap.org]( > https://en.osm.town/@amapanda/tagged/WaterwayMapOrg) can be found on > Mastodon/Fediverse (incl. [Atom/RSS feed]( > https://en.osm.town/@amapanda/tagged/WaterwayMapOrg.rss)): > • This code is on Github: [`amandasaurus/waterwaymap.org`]( > https://github.com/amandasaurus/waterwaymap.org). [New issue reports]( > https://github.com/amandasaurus/waterwaymap.org/issues) are welcome. > • The programme which generates it is [`osm-lump-ways`]( > https://github.com/amandasaurus/osm-lump-ways) > > -- > Amanda > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] Absence de crédit
Bonjour à tous Pensez que l'association OSM France tient une traçabilité de ces problèmes d'attribution sur son dépôt github https://github.com/osm-fr/attributions C'est plus commode pour suivre ces différents problèmes que dans un fil de mail n'est-ce pas ? Pouvez-vous aller créer les tickets correspondants s'il vous plaît ? Bon weekend François Le sam. 30 sept. 2023 à 11:35, Nicolas VIGNERON a écrit : > Bonjour, > > Côté Wikipédia, ce genre de choses arrive très souvent. > > Après un premier mail sympathique (car après tout la personne peut ne pas > savoir ou savoir et avoir oublié, c'est humain), on passe en général à un > mail faisant un rappel à la loi. > En particulier, la mention que la copie sans attribution est un délit de > contrefaçon qui peut être puni de trois ans d'emprisonnement et de 300 000 > euros d'amende (article L335-2 et suivants du Code de la propriété > intellectuelle). > Dans un grand nombre de cas, cela fait réagir (et si même cela ne fait pas > réagir, en général rien ne le fera, même pas envoyé un avocat sur place). > > Cdlt, > Nicolas > > > > Le sam. 30 sept. 2023 à 11:10, Maxime Chourré > a > écrit : > > > Bonjour, j'ai un problème similaire avec le site www.hosman.co qui > > utilise Mapbox. > > > > Je leur ai envoyé le 19 septembre le mail suivant (à cont...@hosman.co): > > = > > Bonjour, > > La carte affichée sur les annonces doit avoir un crédit vers Mapbox et > > OpenStreetMap. > > Merci de corriger ce problème d'attribution au plus vite. > > Pour plus de renseignements, consultez l'aide de Mapbox : > > https://docs.mapbox.com/help/getting-started/attribution/ > > Cordialement, > > Maxime > > = > > > > Et depuis, pas de réponse... > > Comment faire ? > > > > Maxime Chourré > > > > > > > > On 9/25/23 20:01, Yannick wrote: > > > Bonsoir, > > > > > > La Fédération Française de Généalogie utilise OSM sur son site > > > https://genefede.com > > > Je n'ai pas vu le crédit sur la carte. > > > Il faudrait réagir fermement car c'est un prestataire qui a fait le > site. > > > > > > Amitiés > > > > > > ___ > > > 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 > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Erreurs Osmose pour les transformateurs sur poteau
Bonjour et merci de l'avoir remarqué, c'est tout à fait légitime. Nous attendons la prise en compte de ce ticket sur JOSM : https://josm.openstreetmap.de/ticket/22200 pour faire disparaître ces signalements. C'est suite au vote de https://wiki.openstreetmap.org/wiki/Proposal:Substation_nodes_extension et les nœuds signalés sont bien décrits de la bonne façon Peut-être me pencherais-je sur les modifications nécessaires prochainement mais j'ai moins l'habitude de SVN que de git. Bon weekend François Le ven. 5 mai 2023 à 17:15, Frédéric Rodrigo a écrit : > Bonjour, > > C'est une règle de validation qui provient de JOSM > > https://josm.openstreetmap.de/browser/josm/trunk/resources/data/validator/combinations.mapcss > > De plus, ce n'est pas parce qu'une proposition est acceptée, que les > données sont mises à jour en conséquence. > > Frédéric. > > > Le 05/05/2023 à 15:17, Francois Gouget a écrit : > > Osmose génère plein d'erreurs pour les transformateurs sur poteaux : > > > > > https://osmose.openstreetmap.fr/fr/map/#item=9001=12=45.9717=0.7335=1%2C2%2C3 > >attribut manquant : substation sans power=substation ou > pipeline=substation > > > > Ceci parce que ces poteaux sont taggés avec : > >power = pole > >substation = minor_distribution > >transformer = main > > > > Effectivement la page power=pole indique qu'il faudrait les tagger > > différemment : > > > >https://wiki.openstreetmap.org/wiki/Tag:power%3Dpole#Design > >power = pole > >transformer = distribution > >(mais pas substation = *) > > > > > > J'ai l'impression que cela fait suite à la proposition suivante > > qui a été adoptée : > > > > > https://wiki.openstreetmap.org/wiki/Proposal:Substation_nodes_extension > > > > Y a-t-il eu un retournement de situation ou est-ce juste que tout n'a > > pas été mis à jour ? > > > > > > > ___ > 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] Vers un modèle de données amélioré pour OpenStreetMap
Merci Marc ! C'est un sujet capital sur lequel notre contribution sera sollicité. Une discussion sur le forum devrait être initiée pour traiter du sujet Bonne fin de semaine (je prends le temps pour répondre sur d'autres sujets bientôt) François Le ven. 2 sept. 2022 à 13:31, Marc_marc a écrit : > Bonjour, > > j'ai traduis le message de Tobias Knerr, > https://www.openstreetmap.org/user/marc__marc/diary/399867 > pour ceux que cela interesse. > > le plus le plus interessant à mes yeux est celui sur la création > d'un 4ieme type d'objet pour les aires au lieu des bricolages > chemin fermé ou multipolygone > > Cordialement, > Marc > > > > ___ > 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] pipeline=marker déprécié -> marker=* + subject=pipeline ?
Bonjour Marc, Le jeu. 28 juil. 2022 à 15:36, Marc_marc a écrit : > > est-ce que cela vous semble donc pertinent de remplacer > le tag pipeline=marker déprécié par : > tag marker=* pour décrire un marqueur et sa forme > subject=pipeline pour décrire que c'est relatif à un pipeline > ? > Cela me semble ok d'ajouter subject=pipeline (ou toute autre valeur pertinente) pour traduire qu'une borne indique la présence d'une canalisation. C'est plus large que pipeline=marker, nous n'avions pas de valeur pour indiquer quelqu'autre sujet que ce soit dans le passé. Avoir trouvé une pratique générique qui permette de traiter tous les sujets doit être valorisé. C'est un détail sémantique, parlons du remplacement des occurrences restantes de pipeline=marker, parce que son remplacement en tant que tel a déjà été discuté (ce qui nous amène à la discussion en cours). Bonne journée François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] equivalence subtance=* -> utility=* sur les pipeline=marker dépréciés
Bonjour Il faut clarifier quelques points. Le ven. 22 juil. 2022 à 12:26, Marc_marc a écrit : > Bonjour, > > Le 20.07.22 à 00:44, osm.sanspourr...@spamgourmet.com a écrit : > > remplacer les contenus par les types d'opérateurs > > merci François et Jean-Yvon pour le retour. > C'était justement ce que je craignais car si j'ai > bien compris, on a déprécié un tag en remplacement > d'un autre alors que les 2 tags ne renseigne pas > la même chose > C'est un remplacement et il était légitime dans le sens où le gaz, l'eau ou l'électricité ne sont pas dans la borne. La borne n'est pas un équipement des ouvrages indiqués. La géométrie doit donc être distincte et ne pas ajouter à la borne des attributs qui devraient aller sur l'ouvrage qu'elle désigne. > je vois un marqueur relatif à un pipeline gas. > on a un nouveau tag pour renseigner sa forme > on a un nouveau tag pour renseigner l'utilisateur final > du contenu du pipeline > Et un attribut pour désigner à quelle activité l'ouvrage prend part (utility=*). > mais comment est-ce qu'on renseigne : > - que c'est à propose d'un pipeline ou d'un cable électrique ? > la clef subject me semble un bon candidat > - comment est-ce qu'on renseigne le contenu du pipeline > quand le pipeline n'est pas encore dans osm (parce qu'en > première étape, il faut parfois aller sur le terrain collecter > les marqueurs) > subject:content ? cela me semble un faible gain > comparé à content=* > content=* est un synonyme de substance=*, utilisé pour les cuves et réservoirs notamment (on pourrait remplacer l'un par l'autre). Ce n'est pas bon ici, la borne ne contient rien non plus. subject=* pourrait être intéressant, peut-être l'occasion de remplacer utility=hydrant par utility=water + subject=hydrant. subject=pipeline, cable, boundary, highway... ? > par ailleurs il manque une série de valeur à utility=* > - les pipeline otan entre structure militaire ? > - un pipeline pour alimenter un aéroport civil ? > Ni la nature civile ou militaire ni la destination ne changent l'utiity concernée. operator=* suffit pour l'OTAN et pour la desserte de l'aéroport (ou de tout site industriel), voire usage=delivery (je viens d'inventer la valeur) ? Très bonne après-midi François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] equivalence subtance=* -> utility=* sur les pipeline=marker dépréciés
Bonsoir Marc, Tout dépend qui exploite et dans quel but ? substance=brine est utilisé autant dans l'industrie chimique (utility=chemical) ou bien dans le stockage de gaz naturel (utility=gas). Idem pour substance=water (même si habituellement c'est aussi utility=water, tu as aussi des conduites d'eau brute pour l'industrie chimique) Si on peut résumer, de manière simpliste, c'est : substance => une solution chimique utility => Une activité industrielle bien souvent publique. Pour l'instant cela donne satisfaction, voyons si il y a des exceptions Bonne soirée François Le mar. 19 juil. 2022 à 19:41, Marc_marc a écrit : > Bonjour, > > le déprécié pipeline=marker utilisait parfois erronément > subtance=* pour décrire ce que contenait le pipeline concerné. > cela a été remplacé par marker=* + utility=* > > la conversion est triviale pour certaines valeur, exemple : > subtance=gas/oil -> utility=gas/oil > mais pour les autres ? > les 9 valeurs existante en france métropolitaine > substance=brine > substance=brine;water > substance=ethylene > substance=fuel > substance=gas -> subtance=gas > substance=hydrogen > substance=measurement > substance=oil -> subtance=oil > substance=water > > Cordialement, > Marc > > > > ___ > 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] [édition mécanique] remplacer 300 noeud school=entrance par entrance=yes en France métropolitaine
Bonjour Marc A première vue, je trouve ça très bien ! La clé entrance est bien plus appropriée pour ça Bonne journée François Le ven. 10 juin 2022 à 10:38, Marc_marc a écrit : > Bonjour, > > sur la liste tagging, cela parle de la veille clef school=entrance > dans les faits et les logiciels, cela a été remplacé par > entrance=yes/main/... > > je propose de remplacer les 300 occurrences de school=entrance > par entrance=yes sur des noeuds en France métropolitaine > > avis ? > > PS: les 16 occurences sur des ways ne sont pas concerné par > l'opération (il vaut mieux les traiter à la main) > https://overpass-turbo.eu/s/1jbM > si je prend un exemple https://www.openstreetmap.org/way/256137216 > c'est à rempalcer par un noeud entrance=yes commun entre la voie et > l'emprise de l'école > je les traiterai à la main, si qlq souhaites le faire, je suis partageur :) > > Cordialement, > Marc > > > > ___ > 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] Enedis duplicatata de name et GDO
Bonjour Ludovic, Désolé je ne suis pas revenu ici assez rapidement et le partage des photos a expiré. Je voudrais être sûr qu'il s'agit bien d'un doublon et non d'un rappel de références comme on le voit parfois. Normalement, deux armoires distantes ne doivent pas avoir la même référence, ce n'est pas normal. Peux-tu remettre ces photos en ligne s'il te plait ? Bonne après-midi François Le mer. 18 mai 2022 à 10:02, Ludovic Hirlimann a écrit : > > On 5/16/22 15:19, Ludovic Hirlimann wrote: > > On 5/16/22 14:09, François Lacombe wrote: > > Bonjour Ludovic, > > Si cela est possible, je pense qu'avoir les photos et l'emplacement des > deux armoires peut nous aider. > > > Les photos sont là > https://drop.chapril.org/download/51ab4cf1a33f2290/#VEH9CvB4eqjKkd3iY-KUcg > > Les armoires sont dans cette zone > https://www.openstreetmap.org/#map=17/43.87341/1.23779 > > La première, celle ne portant qu'une référence, se trouve au croisement > du chemin de Cazal et du chemin de Monbéqui. l'autre se trouve juste après > les bâtiments "peyro de la sal". > > > Coucou, > > ça aide ou non , ou je fait comme Marc le propose ? > > > Ludo > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Enedis duplicatata de name et GDO
Bonjour Ludovic, Si cela est possible, je pense qu'avoir les photos et l'emplacement des deux armoires peut nous aider. Ce sont de bonnes questions en tout cas, bonne après-midi François Le lun. 16 mai 2022 à 14:02, Ludovic Hirlimann a écrit : > Bonjour/bonsoir > > > En prenant des données sur le terrain, je suis tombé sur deux petites > armoires bizarres. Bizarres, car elles se situent à une centaine de > mètres l'une de l'autre. L'une porte une ref GDO + un nom. La suivante > deux refs GDO et deux noms. L'une des deux refs et nom de la deuxième > armoire est identique à la première. > > > Je gère comment ? (si c'est po clair j'ai des photos). > > > Ludovic > ___ > 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] Bilan 2021 de la convention Enedis / OSM France
Merci pour vos encouragements ! Que ceci puisse profiter à toutes les initiatives à venir, de l'asso ou des pros. La plupart des enseignements sont à extrapoler facilement, ne concernent pas directement le sujet de fond. Le soutien à la plateforme projetdumois (par des devs) est essentiel, pensez-y autant que faire se peut. Je pense industrialiser la production du slide 8 par exemple, pour refléter le dynamisme de la communauté plus facilement. A bientôt :) François Le mer. 2 mars 2022 à 09:23, Florian LAINEZ a écrit : > Absolument génial de voir un tel engouement pour un sujet qui paraît au > premier abord très technique. > Bravo à tous ! > > Le mer. 2 mars 2022 à 08:52, Jean-Christophe Becquet a > écrit : > > > Le 01/03/2022 à 22:51, François Lacombe a écrit : > > > Ces retours positifs nous incitent à poursuivre dans cette direction > > > > Bonjour, > > > > J'ajoute un retour positif : +1 félicitations pour tout ce travail ! > > > > Bonne journée > > > > JCB > > -- > > Ressources : supports pédagogiques > > Introduction à l’opendata et L’écosystème OpenStreetMap > > > > > https://www.linkedin.com/posts/jean-christophe-becquet-b0131b210_libre-opendata-openstreetmap-activity-6900519323119497216-H6nJ > > > > Jean-Christophe Becquet - Expert conseil - APITUX > > le logiciel libre et les données ouvertes au service des territoires > > 06 25 86 07 92 - j...@apitux.com - http://www.apitux.com > > > > ___ > > Talk-fr mailing list > > Talk-fr@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk-fr > > > > > -- > > *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
[OSM-talk-fr] Bilan 2021 de la convention Enedis / OSM France
Bonjour à toutes et à tous, nous en parlons régulièrement ici ou sur d'autres canaux, le partenariat Enedis / OSM France a maintenant 1 an. https://www.openstreetmap.fr/convention-dechange-de-donnees-entre-enedis-et-openstreetmap-france/ Un premier bilan est désormais disponible pour mieux se rendre compte du chemin parcouru ces derniers mois. https://files.infos-reseaux.com/openstreetmap/cr_enedis_2021.pdf Parmi les principaux enseignements, on retiendra : * L'effet visible sur la contribution OSM, de la mise à disposition d'orthophotographies et du renforcement vertueux de l'opendata réalisés par Enedis * Une communauté dynamique, de plus de 500 personnes, qui contribue sur des sujets plutôt techniques * Des développements, adaptations d'outils et de modèles attributaires en fonction des retours d'expérience retenus * Un suivi disponible quotidiennement en ligne sur https://enedis.openstreetmap.fr * Des données disponibles librement sur plusieurs plateformes Ces retours positifs nous incitent à poursuivre dans cette direction avec l'ajout de nouveaux sujets pour l'année 2022, sur les coffrets affleurants principalement. Des cas d'usage pratiques des données produites apparaissent depuis quelques semaines, nous pourrons être amenés à communiquer plus largement sur ce point dans l'année. En vous rappelant enfin l'existence de cette vidéo pour en savoir plus https://peertube.openstreetmap.fr/w/098b46b9-d52b-46f9-b5c1-c37b82f7fd61 Bonne semaine ! François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Proposition - Vote - Classification des transformateurs électriques
Bonjour :) Une proposition assez ancienne est soumise au vote cette semaine, concernant la classification des transformateurs électriques (encore eux). https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Transformers_classification_refinement La dernière proposition sur le sujet date de 2017 et l'expérience depuis a montré que nous pouvions améliorer la clarté des valeurs de la clé transformer=* Il est proposé de remplacer plusieurs situations existantes par la valeur transformer=main, plus simple à identifier sur les vues aériennes. Les valeurs transformer=traction, transformer=auto sont supprimées Les périmètres couverts par transformer=distribution, transformer=auxiliary sont modifiés. D'autres détails sont disponibles dans le documents, avec les explications nécessaires. Tout cela est évidemment optionnel. Le vote se déroule sur la version anglaise https://wiki.openstreetmap.org/wiki/Proposed_features/Transformers_classification_refinement#Voting Bon weekend ! François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSRM-talk] OSRM with postgis+pgrouting extension
Hi everyone Le dim. 10 janv. 2021 à 18:22, Daniel Patterson via OSRM-talk < osrm-talk@openstreetmap.org> a écrit : > Why would you not just use pgRouting all by itself? Why do you want to > use OSRM as well as pgRouting - they serve a common purpose. > > To use OSRM with data in a psotgres database, you would need to export it > into an OSM compatible XML or PBF format - how you do this would depend on > how you've stored the data. > Just to mention this tool I maintain : https://github.com/DCbrainOrg/pgsql2osm intended to convert data from pgsql to osm. Data model is described on readme. It's currently a draft which would suffer some issues at world scale, but it brings value on small or medium sized datasets (I currently use it on whole metropolitan France to run OSRM on custom data). All the best François ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
[OSM-talk-fr] Proposition - Vote - Les pompes (bis)
Bonjour à tous, Un peu de temps supplémentaire a été consacré à la proposition sur les pompes et une version corrigée est disponible au vote jusqu'au 4 janvier prochain. https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Pumping_proposal Le vote se tient sur la page anglaise selon les modalités habituelles https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal A noter que malgré une classification complexe pour ces appareils, la plupart des tags proposés sont optionnels et personne ne sera jamais forcé de les utiliser contre son gré. Certaines pompes peuvent être cachées dans des zones inaccessibles et le but reste de décrire les appareils que nous pourrons atteindre sans prise de risque inutiles. En vous remerciant de prendre quelques minutes pour donner votre avis. Bon début de semaine François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Vote en cours sur la clé electricity
Bonjour à tous, Le vote d'une proposition intéressante est en cours sur le wiki. Elle concerne la description de l'approvisionnement électrique des bâtiments. Mais non c'est pas compliqué. https://wiki.openstreetmap.org/wiki/Proposed_features/electricity Il est proposé d'indiquer si le bâtiment est raccordé à un réseau électrique ou si un moyen de production locale est disponible (ou les deux). Il y est également proposé la dépréciation de power_supply utilisé jusque là presque uniquement dans les campings. Faites-vous votre propre avis quoi qu'il arrive. J'ai suivi les discussions, je peux sûrement répondre à certaines questions. Ce vote est doublement intéressant. power_supply est actuellement utilisé plus de 13 000 fois. Je serai particulièrement vigilent aux arguments apportés (ou non) contre le remplacement/dépréciation de tags considérés comme utilisés selon des seuils indéterminés. Bonne après-midi François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] nouvelle clef : avalanche_transceiver
Bonjour à tous, Suite à discussion sur le fil telegram France (merci Gustave Eiffel, Pyrog, Vinber), les tags suivants ont été proposés pour cartographier ce qui est relatif aux DVA (https://en.wikipedia.org/wiki/Avalanche_transceiver) : - training=avalanche_transceiver pour les zones d'entraînement à la manipulation des DVA (ex : https://www.chamoniarde.com/formations/parcs-dva#) - checkpoint=avalanche_transceiver pour les boîtiers permettant de tester son DVA (exempl https://www.serre-chevalier.com/en/ski-area/activities/glisse-toute-securite/avalanche-transceiver-checkpoints) Merci beaucoup et bonne journée, BaboucheVerte Sent with [ProtonMail](https://protonmail.com) Secure Email.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [édition de masse] convertir le tag déprécié diaper par le tag approuvé changing_table
Bonjour Marc Bonne idée également, je valide François Le dim. 29 nov. 2020 à 10:33, Éric Gillet a écrit : > Bonjour Marc, > > Ça me semble être une bonne idée ! > Go pour moi > > Éric > > Le 27/11/2020 à 19:58, Marc_marc a écrit : > > Bonjour, > > > > et justement puisque j'en parle dans l'autre email, > > je propose l'édition de masse suivante : > > étendue géographique : la France métropolitaine (je ferrai > > des messages auprès d'autres communautés pour les cas > > présents ailleurs) > > cible : > > - les (193) objets ayant le tag diaper déprécié en juin 2019 > > à remplacer par le tag approuvé changing_table > > - les (7) objets ayant le tag diaper et changing_table > > avec la même valeur > > > > avis/accord/objection ? > > > > Cordialement, > > Marc > > > > > > > > ___ > > 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] Proposition - Vote - Les pompes
Merc Lejun pour ce retour Il y a en effet des craintes à changer des tags existants. Il faudrait néanmoins savoir ce que ça veut dire. Certaines tentatives de tagging ont été un échec mais en appliquant les mêmes méthodes je pourrais très bien dire que ces tags existent donc on y touche pas. Le vrai problème se pose lorsque ca oblige à utiliser des termes moins clairs, juste pour préserver ce qui existe sans aucune autre raison. Dommage de passer du temps là-dessus, le vote est mis en pause le temps d'évaluer les impacts Bonne après-midi François Le mer. 25 nov. 2020 à 06:45, lejun a écrit : > Sur OSM aussi il y a une part de conservateurs qui veulent maintenir > l'usage d'un ancien attribut quitte à en mettre une couche par dessus. > Oui j'pense à vous, ceux qui travaillent sur les transports publics et > qui en êtes au moins à la 4e version officielle surajoutée. > > Bon courage pour la suite ! > > Le 24/11/2020 à 20:41, François Lacombe a écrit : > > > > Toutefois et sans être spécifique au cas précis et très technique des > > pompes, je reste en désaccord avec le maintien d'une clé prétendument > > utilisée par principe. > > Le niveau d'utilisation d'une clé est imprécis, considéré de manière > > différente suivant les personnes. > > C'est un risque pour OSM : quand tous les tags seront réputés utilisés, > > on ne changera plus rien. > > Ici est opposée l'existence de 30 000 utilisations sur 14% *seulement* > > des objets censés le recevoir. Ce n'est pas acceptable. > > La recherche de qualité, d'innovation propre à OSM mérite vraiment mieux > > à mon sens. > > -- > Lejun - Groupe Local OpenStreetMap Bourgogne-Franche-Comté > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Lot Talk-fr, Vol 172, Parution 70
@Éric OK j'ignorais, merci. Pensez-vous que ce soit intéressant à mapper ? Envoyé depuis ProtonMail mobile Message d'origine Le 25 nov. 2020 à 07:56, a écrit : > Envoyez vos messages pour la liste Talk-fr à > talk-fr@openstreetmap.org > > Pour vous (dés)abonner par le web, consultez > https://lists.openstreetmap.org/listinfo/talk-fr > > ou, par email, envoyez un message avec 'help' dans le corps ou dans le > sujet à > talk-fr-requ...@openstreetmap.org > > Vous pouvez contacter l'administrateur de la liste à l'adresse > talk-fr-ow...@openstreetmap.org > > Si vous répondez, n'oubliez pas de changer l'objet du message afin > qu'il soit plus spécifique que "Re: Contenu du digest de Talk-fr..." > > Thèmes du jour : > > 1. précision proposition nouvel attribut (François Bojarski) > 2. Re: addok et demo.addok.xyz : géocodage avec données OSM > (Jean-Marc Liotier) > 3. Re: Proposition - Vote - Les pompes (François Lacombe) > 4. Re: précision proposition nouvel attribut (Eric SIBERT) > 5. Re: Proposition - Vote - Les pompes (lejun) > 6. Re: addok et demo.addok.xyz : géocodage avec données OSM > (Cyrille37 OSM) > > -- > > Message: 1 > Date: Tue, 24 Nov 2020 19:16:44 + > From: François Bojarski > To: "talk-fr@openstreetmap.org" > Subject: [OSM-talk-fr] précision proposition nouvel attribut > Message-ID: > > > Content-Type: text/plain; charset="utf-8" > > Bonjour > Je confirme ce que dis le topographe fou, le but est de cartographier les > endroits où l'on peut tester son dva. > Rappel rapide sur les dva que j'aurais du faire avant. En ski de rando ou > free ride, on a tous sur soi un dva qui émet en permanence. Si une personne > de ton groupe est prise dans une avalanche, tu mets ton dva en mode > réception, et en captant le signal de la personne ensevelie, tu peux la > retrouver. Dans la plupart des stations (en tout cas celles où le hors piste > est répandu), il y a des boîtiers qui sont comme des dva en mode réception, > qui permettent de te confirmer que ton dva émet bien et est donc utilisable. > Ce sont ces boitiers que je souhaiterais cartographier. > Cartographier des zones où le dva est nécessaire n'aurait selon moi aucun > sens : il n'est obligatoire nulle part (à ma connaissance), mais utile > partout. De même cartographier la possibilité d'en vendre / acheter ne me > paraît pas intéressante, l'écrasante majorité des magasins de skis en vendent. > (L'équivalent des balises MOB seraient, en sortie de rade, s'il y avait des > boîtiers pour tester si ta MOB fonctionnait, ce qui n'existe pas àmha). > Je prends note, en effet dva_check est un peu trop franco-français :). > Peut-être avalanche_beacon_check est trop long ? > > Merci à tous > > Sent with [ProtonMail](https://protonmail.com) Secure Email. > -- section suivante -- > Une pièce jointe HTML a été nettoyée... > URL: > <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20201124/bcf70066/attachment-0001.htm> > > -- > > Message: 2 > Date: Tue, 24 Nov 2020 20:37:49 +0100 > From: Jean-Marc Liotier > To: Discussions sur OSM en français > Subject: Re: [OSM-talk-fr] addok et demo.addok.xyz : géocodage avec > données OSM > Message-ID: > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > 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... > > -- section suivante -- > Une pièce jointe HTML a été nettoyée... > URL: > <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20201124/761016fb/attachment-0001.htm> > > -- > > Message: 3 > Date: Tue, 24 Nov 2020 20:41:59 +0100 > From: François Lacombe > To: Discussions sur OSM en français > Subject: Re: [OSM-talk-fr] Proposition - Vote - Les pompes > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > Bonsoir à tous, > > Quelques nouvelles à propos de ce vote. > Difficile d'imaginer la multitude de commentaire
Re: [OSM-talk-fr] Proposition - Vote - Les pompes
Bonsoir à tous, Quelques nouvelles à propos de ce vote. Difficile d'imaginer la multitude de commentaires reçus avant de se lancer. Merci à tous ceux qui ont pris le temps de lire, commenter, expliquer jusqu'ici. Cette version ne sera probablement pas acceptée et je pense arrêter le vote pour l'instant. Il faut que je réfléchisse davantage sur le schéma proposé, pour intégrer certaines remarques. Toutefois et sans être spécifique au cas précis et très technique des pompes, je reste en désaccord avec le maintien d'une clé prétendument utilisée par principe. Le niveau d'utilisation d'une clé est imprécis, considéré de manière différente suivant les personnes. C'est un risque pour OSM : quand tous les tags seront réputés utilisés, on ne changera plus rien. Ici est opposée l'existence de 30 000 utilisations sur 14% *seulement* des objets censés le recevoir. Ce n'est pas acceptable. La recherche de qualité, d'innovation propre à OSM mérite vraiment mieux à mon sens. A suivre donc, bonne soirée François Le ven. 20 nov. 2020 à 14:17, Jacques Lavignotte a écrit : > > > Le 19/11/2020 à 20:19, François Lacombe a écrit : > > le vote sur la proposition traitant des pompes est finalement ouvert > > A voté ! > > > -- > GnuPg : 156520BBC8F5B1E3 Because privacy matters. > « Quand est-ce qu'on mange ? » AD (c) (tm) > > ___ > 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] précision proposition nouvel attribut
Bonjour Je confirme ce que dis le topographe fou, le but est de cartographier les endroits où l'on peut tester son dva. Rappel rapide sur les dva que j'aurais du faire avant. En ski de rando ou free ride, on a tous sur soi un dva qui émet en permanence. Si une personne de ton groupe est prise dans une avalanche, tu mets ton dva en mode réception, et en captant le signal de la personne ensevelie, tu peux la retrouver. Dans la plupart des stations (en tout cas celles où le hors piste est répandu), il y a des boîtiers qui sont comme des dva en mode réception, qui permettent de te confirmer que ton dva émet bien et est donc utilisable. Ce sont ces boitiers que je souhaiterais cartographier. Cartographier des zones où le dva est nécessaire n'aurait selon moi aucun sens : il n'est obligatoire nulle part (à ma connaissance), mais utile partout. De même cartographier la possibilité d'en vendre / acheter ne me paraît pas intéressante, l'écrasante majorité des magasins de skis en vendent. (L'équivalent des balises MOB seraient, en sortie de rade, s'il y avait des boîtiers pour tester si ta MOB fonctionnait, ce qui n'existe pas àmha). Je prends note, en effet dva_check est un peu trop franco-français :). Peut-être avalanche_beacon_check est trop long ? Merci à tous Sent with [ProtonMail](https://protonmail.com) Secure Email.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] proposition nouvel attribut
Bonjour à tous, Suite au recommandation de Donat, je viens prendre la température pour la proposition d'un nouveau tag pour cartographier les boîtiers test de Detecteur de Victime en Avalanche (DVA en français, avalanche beacon in english). Ce sont des petits boitiers que l'on peut trouver dans les stations aux départs de certains grands hors pistes, proche des arrivées de remontées, à côté des caisses de forfait, dans des zones dédiés de zone d'entraînement pour sortir des gens d'avalanches, etc . Ca me paraît utile, et pourrait facilement avoir un rendu, puisque dans des zones peu dense. Le tag : avalanche_beacon_check ou bien dva_check me paraitrait approprié. Il pourrait être combine avec le tag pour dire s'il est à l'intérieur ou à l'extérieur des bâtiments. Qu'en pensez-vous ? Si ma proposition n'amène pas un refus frontal, je ferai la proposition "officielle " sur le wiki. Merci ! Sent with [ProtonMail](https://protonmail.com) Secure Email.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition - Vote - Les pompes
Merci Cyrille C'est bien par la discussion qu'on arrivera à trouver la meilleure solution. J'ai bien conscience que la proposition prévoit des changements, en contrepartie de concepts plus largement définis définis qu'actuellement Bon weekend François Le ven. 20 nov. 2020 à 13:35, Cyrille37 OSM via Talk-fr < talk-fr@openstreetmap.org> a écrit : > Hello again > > Je suis aux bouts de mes arguments, les points de vue différents sont > indissociables de notre humanité :-) Je laisse donc mon vote "pour" en > confiance et en encouragement de ton implication :-D > > Cyrille37. > Le 20/11/2020 à 13:08, François Lacombe a écrit : > > Cyrille, > > Parfois, les usages établis l'ont été à des époques où nous partions d'une > feuille blanche. > S'interdire de les améliorer (donc de remplacer certaines choses parfois) > parce qu'ils existent aurait pu être opposé à OSM lorsqu'il remplace > d'autres choses. > > En l'occurrence, pump=powered a beau être simple, il ne veut > malheureusement rien dire et posera certainement des problèmes quand il > s'agira de mettre osm en correspondance avec d'autres standards. > Si il s'agit d'indiquer que la pompe n'est pas activable à la main, on > peut mettre handle=no > > Je le redis, pump=* actuel ne parle pas de pompe, uniquement de puis et de > moteurs éventuels. Pas des pompes. > > François > > Le ven. 20 nov. 2020 à 12:55, Cyrille37 OSM via Talk-fr < > talk-fr@openstreetmap.org> a écrit : > >> François >> >> Je rejoins assez "Jeisenbe" sur le fait de ne pas déprécier les valeurs >> précédentes qui correspondent à un usage établi. Pourquoi ne pas seulement >> enrichir l'existant ? >> >> Pour ma part je trouve excellent les tags pump=manual et pump=powered, >> c'est exactement de mon niveau. Ensuite s'ils peuvent être enrichis par >> d'autres tags, yes, no problemo :-) >> >> C/. >> Le 20/11/2020 à 12:25, Cyrille37 OSM a écrit : >> >> François >> >> Ceux qui sont contre disent que c'est "pump=powered" qui disparaît dans >> la proposition, ce qui enlève la permission de tagger simplement. >> >> Cyrille. >> Le 20/11/2020 à 10:37, François Lacombe a écrit : >> >> Bonjour Cyrille, >> >> Merci pour ton commentaire. >> >> Le ven. 20 nov. 2020 à 10:10, Cyrille37 OSM via Talk-fr < >> talk-fr@openstreetmap.org> a écrit : >> >>> Je suis sensible au contre argument : >>> *Any tagging scheme allowing to tag extreme detail uninteresting to >>> nearly all people must allow also tagging basic info without making >>> mandatory to specify details* >>> >> Cela tombe bien parce que je ne comprends pas cette phrase. >> Il n'y a aucun tag obligatoire (sinon évidemment le man_made, mais c'est >> une évidence), surtout pas le mechnical_driver. >> >>> Mais je n'ai pas analysé précisément la proposition pour confirmer sa >>> véracité, seulement lu les 3 oppositions qui je trouve se rejoignent sur la >>> nécessité de tagger simplement un pompe. >>> >> C'était bien le but je vous rassure, visiblement on est tous d'accord >> (mais certains se sentent quand même obligés de voter contre) >> >>> Cette proposition permet-elle de continuer à tagger très simplement une >>> pompe avec un seul tag, sans autre connaissance des détails ? >>> >> Oui, man_made=pump : c'est une pompe et suffit à lui-même, on est pas >> obligé de faire plus. >> >> Le point central de la proposition est de cesser d'utiliser "pump" pour >> parler du moteur puisque c'est le cas aujourd'hui. >> Une pompe est souvent animée par un moteur, on a donc deux appareils >> pompe + moteur, il me semble logique qu'OSM ait deux tags pour parler >> respectivement de la pompe et du moteur. >> >> Bonne fin de semaine à vous tous >> >> François >> >> ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > > ___ > Talk-fr mailing > listTalk-fr@openstreetmap.orghttps://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] Proposition - Vote - Les pompes
Cyrille, Parfois, les usages établis l'ont été à des époques où nous partions d'une feuille blanche. S'interdire de les améliorer (donc de remplacer certaines choses parfois) parce qu'ils existent aurait pu être opposé à OSM lorsqu'il remplace d'autres choses. En l'occurrence, pump=powered a beau être simple, il ne veut malheureusement rien dire et posera certainement des problèmes quand il s'agira de mettre osm en correspondance avec d'autres standards. Si il s'agit d'indiquer que la pompe n'est pas activable à la main, on peut mettre handle=no Je le redis, pump=* actuel ne parle pas de pompe, uniquement de puis et de moteurs éventuels. Pas des pompes. François Le ven. 20 nov. 2020 à 12:55, Cyrille37 OSM via Talk-fr < talk-fr@openstreetmap.org> a écrit : > François > > Je rejoins assez "Jeisenbe" sur le fait de ne pas déprécier les valeurs > précédentes qui correspondent à un usage établi. Pourquoi ne pas seulement > enrichir l'existant ? > > Pour ma part je trouve excellent les tags pump=manual et pump=powered, > c'est exactement de mon niveau. Ensuite s'ils peuvent être enrichis par > d'autres tags, yes, no problemo :-) > > C/. > Le 20/11/2020 à 12:25, Cyrille37 OSM a écrit : > > François > > Ceux qui sont contre disent que c'est "pump=powered" qui disparaît dans la > proposition, ce qui enlève la permission de tagger simplement. > > Cyrille. > Le 20/11/2020 à 10:37, François Lacombe a écrit : > > Bonjour Cyrille, > > Merci pour ton commentaire. > > Le ven. 20 nov. 2020 à 10:10, Cyrille37 OSM via Talk-fr < > talk-fr@openstreetmap.org> a écrit : > >> Je suis sensible au contre argument : >> *Any tagging scheme allowing to tag extreme detail uninteresting to >> nearly all people must allow also tagging basic info without making >> mandatory to specify details* >> > Cela tombe bien parce que je ne comprends pas cette phrase. > Il n'y a aucun tag obligatoire (sinon évidemment le man_made, mais c'est > une évidence), surtout pas le mechnical_driver. > >> Mais je n'ai pas analysé précisément la proposition pour confirmer sa >> véracité, seulement lu les 3 oppositions qui je trouve se rejoignent sur la >> nécessité de tagger simplement un pompe. >> > C'était bien le but je vous rassure, visiblement on est tous d'accord > (mais certains se sentent quand même obligés de voter contre) > >> Cette proposition permet-elle de continuer à tagger très simplement une >> pompe avec un seul tag, sans autre connaissance des détails ? >> > Oui, man_made=pump : c'est une pompe et suffit à lui-même, on est pas > obligé de faire plus. > > Le point central de la proposition est de cesser d'utiliser "pump" pour > parler du moteur puisque c'est le cas aujourd'hui. > Une pompe est souvent animée par un moteur, on a donc deux appareils pompe > + moteur, il me semble logique qu'OSM ait deux tags pour parler > respectivement de la pompe et du moteur. > > Bonne fin de semaine à vous tous > > François > > ___ > 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] Proposition - Vote - Les pompes
Cyrille, Oui c'est ce à quoi j'étais en train de répondre. Il y a plusieurs problèmes auxquels je souhaite apporter une solution durable : * pump=* est actuellement réservé aux puits et traite des moteurs au lieu de parler des pompes elles-même. * pump=powered, s'il est vu comme une manière simple de taguer, est trop vague : il y a une multitude de solutions pour motoriser une pompe. Il est en plus toujours possible d'utiliser une valeur style mechanical_driver=powered en palliatif le temps que quelqu'un donne plus de détails si nécessaire. On en parle sur les bornes à incendie, la question est la même pour les services d'urgence ici : si je sais que la pompe du puits est motorisée sans plus d'infos et que je ne viens qu'avec du gasoil, alors que c'est un moteur électrique, ca ne servira à pas grand chose. Je constate aussi que ceux qui critiquent maintenant le remplacement de pump=powered affirment aussi ne pas savoir pourquoi ces tags ont été définis à la base, ça me gêne un peu. Bon apétit François Le ven. 20 nov. 2020 à 12:28, Cyrille37 OSM via Talk-fr < talk-fr@openstreetmap.org> a écrit : > François > > Ceux qui sont contre disent que c'est "pump=powered" qui disparaît dans la > proposition, ce qui enlève la permission de tagger simplement. > > Cyrille. > Le 20/11/2020 à 10:37, François Lacombe a écrit : > > Bonjour Cyrille, > > Merci pour ton commentaire. > > Le ven. 20 nov. 2020 à 10:10, Cyrille37 OSM via Talk-fr < > talk-fr@openstreetmap.org> a écrit : > >> Je suis sensible au contre argument : >> *Any tagging scheme allowing to tag extreme detail uninteresting to >> nearly all people must allow also tagging basic info without making >> mandatory to specify details* >> > Cela tombe bien parce que je ne comprends pas cette phrase. > Il n'y a aucun tag obligatoire (sinon évidemment le man_made, mais c'est > une évidence), surtout pas le mechnical_driver. > >> Mais je n'ai pas analysé précisément la proposition pour confirmer sa >> véracité, seulement lu les 3 oppositions qui je trouve se rejoignent sur la >> nécessité de tagger simplement un pompe. >> > C'était bien le but je vous rassure, visiblement on est tous d'accord > (mais certains se sentent quand même obligés de voter contre) > >> Cette proposition permet-elle de continuer à tagger très simplement une >> pompe avec un seul tag, sans autre connaissance des détails ? >> > Oui, man_made=pump : c'est une pompe et suffit à lui-même, on est pas > obligé de faire plus. > > Le point central de la proposition est de cesser d'utiliser "pump" pour > parler du moteur puisque c'est le cas aujourd'hui. > Une pompe est souvent animée par un moteur, on a donc deux appareils pompe > + moteur, il me semble logique qu'OSM ait deux tags pour parler > respectivement de la pompe et du moteur. > > Bonne fin de semaine à vous tous > > François > > ___ > 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] Proposition - Vote - Les pompes
Bonjour Cyrille, Merci pour ton commentaire. Le ven. 20 nov. 2020 à 10:10, Cyrille37 OSM via Talk-fr < talk-fr@openstreetmap.org> a écrit : > Je suis sensible au contre argument : > *Any tagging scheme allowing to tag extreme detail uninteresting to > nearly all people must allow also tagging basic info without making > mandatory to specify details* > Cela tombe bien parce que je ne comprends pas cette phrase. Il n'y a aucun tag obligatoire (sinon évidemment le man_made, mais c'est une évidence), surtout pas le mechnical_driver. > Mais je n'ai pas analysé précisément la proposition pour confirmer sa > véracité, seulement lu les 3 oppositions qui je trouve se rejoignent sur la > nécessité de tagger simplement un pompe. > C'était bien le but je vous rassure, visiblement on est tous d'accord (mais certains se sentent quand même obligés de voter contre) > Cette proposition permet-elle de continuer à tagger très simplement une > pompe avec un seul tag, sans autre connaissance des détails ? > Oui, man_made=pump : c'est une pompe et suffit à lui-même, on est pas obligé de faire plus. Le point central de la proposition est de cesser d'utiliser "pump" pour parler du moteur puisque c'est le cas aujourd'hui. Une pompe est souvent animée par un moteur, on a donc deux appareils pompe + moteur, il me semble logique qu'OSM ait deux tags pour parler respectivement de la pompe et du moteur. Bonne fin de semaine à vous tous François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Proposition - Vote - Les pompes
Salut à tous, Suite aux annonces faites plus tôt cette année, le vote sur la proposition traitant des pompes est finalement ouvert https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal Le but est de décrire les appareils servant à relever la cote d'un liquide dans de multiples situations : accès à l'eau, industrie, agriculture, irrigation... Certaines valeurs sont proposées pour être dépréciées et ainsi permettre un formalisme plus cohérent entre le mécanisme de la pompe et les moyens de propulsion. Une version française est disponible https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Pumping_proposal Les tags ont été testés dans plusieurs situations et à plusieurs endroits sans qu'il reste de problèmes particuliers vis à vis du but poursuivi. Ce qui a par exemple permis de compléter l'usine de production d'eau potable de ma ville https://www.openstreetmap.org/node/8098817015 En vous remerciant de prendre quelques minutes pour donner votre avis avant le 3 décembre Bonne soirée François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Contributeurs autour de Charleville-Mézières
Bonsoir à tous, Ceci se destine aux contributeurs situés dans les ardennes, plus particulièrement autour de Charleville-Mézières. J'ai été contacté par le chef de projet mobilités douces d'Ardenne Métropole qui semble motivé pour interagir avec la communauté et ouvrir des données. Je n'avais pas de contact local à lui fournir, sauf erreur de ma part. Ainsi il peut être intéressant de le rencontrer là-bas, fonder un groupe local, organiser des carto-parties, des conférences, State of the Map France et finalement State of The Map Monde l'année prochaine ! N'hésitez pas à répondre ci-dessous pour une mise en relation si la démarche vous intéresse. Bonne soirée François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mission Politique publique de la donnée
Merci Cyrille de nous avoir indiqué ce site Je me suis permis d'ajouter une contribution libre https://www.mission-open-data.fr/processes/politique-publique-donnee/f/2/proposals/27 Bonne soirée François Le jeu. 15 oct. 2020 à 14:23, Cyrille37 OSM via Talk-fr < talk-fr@openstreetmap.org> a écrit : > Hello, > Petit rappel : > > La Mission Politique publique de la donnée a formulé 10 constats sur > lesquels elle vous invite à réagir, en apportant vos commentaires. Vous > avez repéré un constat supplémentaire qui ne figure dans ce rapport > d'étape ? Vous souhaitez proposer une solution pour lever les blocages > identifiés ? Rendez-vous sur la page "contributions libres" ! > > https://www.mission-open-data.fr/processes/politique-publique-donnee/f/1/ > > Cyrille37 > > > ___ > 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] rendus FR en vectoriels, on se lance ?
Hello Je ne peux que plussoyer, vive le vectoriel Je n'utilise que ça pour produire des tuiles d'overlay et il est vrai que réaliser un fond de carte complet est plus complexe que ça. Pour différent projets, ce sont soit Tegola en go ou directement St_AsMvt de postgis qui sont utilisés. Tegola fonctionne vraiment bien https://github.com/flacombe/oim-styles Côté navigateur, c'est du mapbox 100% du temps, peut-être faudrait-il une autre stack pour faire le rendu. https://github.com/flacombe/gespot A suivre François Le ven. 18 sept. 2020 à 15:42, Florimond Berthoux < florimond.berth...@gmail.com> a écrit : > Salut, > > La team de OSM-Carto y travaille de leur côté, ça serait probablement > utile de s’en inspirer, voir > https://github.com/gravitystorm/openstreetmap-carto/issues/3201 > > Perso, je préfère pour l’instant la tuile bitmap taillée main :) > > Le ven. 18 sept. 2020 à 11:41, Florian LAINEZ a > écrit : > >> Hello, >> Et si on se mettait sérieusement au boulot pour créer des rendus français >> en vectoriel ? >> On voit clairement la limite de ceux affichés sur >> https://www.openstreetmap.fr et dans nos service connexes (umap, projet >> du mois, ...). >> On pourrait commencer avec le rendu osm-fr ou bien le rendu vélo. >> >> Je sais, c'est un serpent de mer. Je sais, ce n'est pas si facile. Et je >> sais aussi que je ne serai sûrement pas d'une grande utilité pour le faire, >> mais je pense que ça serait tout de même un grand pas en avant qui >> mériterait une plus grande attention de notre part. >> #AppelABonnesVolontés >> >> -- >> >> *Florian Lainez* >> @overflorian <http://twitter.com/overflorian> >> ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > > > -- > Florimond Berthoux > ___ > 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] La proposition shadok : les pompes
Merci Gad pour tes encouragements N'hésitez pas à compléter la section des exemples ou proposer des illustrations pour les valeurs qui n'en ont pas encore. Par exemple les pompes à vis, à aubes, injecteurs et autres éjecteurs à air comprimé. Bon weekend François Le mer. 9 sept. 2020 à 05:48, Gad Jo a écrit : > Ton dossier pour la proposition est très bien construit et très clair. > > Félicitations > > Le September 8, 2020 10:12:40 PM UTC, "François Lacombe" < > fl.infosrese...@gmail.com> a écrit : >> >> Salut à tous >> >> Voici une proposition de nouveaux tags pour décrire les pompes, beaucoup >> de modèles différents, dont je vient d'achever la traduction >> https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Pumping_proposal >> >> Elle m'a occupé une partie du confinement de ce printemps et a déjà reçu >> de nombreux commentaires sur la version anglaise, ce qui permet aujourd'hui >> d'avoir un modèle assez mature. >> >> L'idée est de réutiliser ce qui a été mis en place pour décrire les puits >> à eau ou de pétrole pour l'étendre à d'autres univers comme l'industrie ou >> le médical. >> En tout cas il est proposé de considérer les pompes comme des appareils à >> part entière, quel que soit leur usage en situation. >> >> Je cherche encore des exemples ou des photos. Certains modèles sont quasi >> introuvables dans la nature et ca ne pousse pas sur les arbres. >> >> Le modèle attributaire proposé sera également présenté au groupe de >> travail de l'ASTEE qui débute la semaine prochaine pour l'élaboration d'un >> nouveau géostandard pour l'adduction d'eau potable et la gestion des eaux >> usées. J'essaierai d'y apporter un peu de culture OSM >> (le précédent GT >> https://www.astee.org/groupe-de-travail-sig-participez-a-la-consultation-externe/ >> ) >> >> Preneur de vos retours, à bientôt >> >> François >> > > -- > 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 > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] La proposition shadok : les pompes
Salut à tous Voici une proposition de nouveaux tags pour décrire les pompes, beaucoup de modèles différents, dont je vient d'achever la traduction https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Pumping_proposal Elle m'a occupé une partie du confinement de ce printemps et a déjà reçu de nombreux commentaires sur la version anglaise, ce qui permet aujourd'hui d'avoir un modèle assez mature. L'idée est de réutiliser ce qui a été mis en place pour décrire les puits à eau ou de pétrole pour l'étendre à d'autres univers comme l'industrie ou le médical. En tout cas il est proposé de considérer les pompes comme des appareils à part entière, quel que soit leur usage en situation. Je cherche encore des exemples ou des photos. Certains modèles sont quasi introuvables dans la nature et ca ne pousse pas sur les arbres. Le modèle attributaire proposé sera également présenté au groupe de travail de l'ASTEE qui débute la semaine prochaine pour l'élaboration d'un nouveau géostandard pour l'adduction d'eau potable et la gestion des eaux usées. J'essaierai d'y apporter un peu de culture OSM (le précédent GT https://www.astee.org/groupe-de-travail-sig-participez-a-la-consultation-externe/ ) Preneur de vos retours, à bientôt François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] La gestion des poteaux
tag operator=* de plusieurs objets mais j'avoue ne pas avoir l'énergie pour tout faire. > Mais la liste est intéressante pour savoir à qui on pourrait s'adresser > pour leur demander leurs données ouvertes (celles au moins que leur impose > la loi : ces données existent peut-être le papier mais pas immédiatement > accessibles en ligne ou dans un format ou une API libre et documentée; on > pourrait se retrouver là aussi avec des données brutes ou pas facilement > utilisables et aucune visualisation, ou des demandes à faire une par une > sur des points isolés). > > Je ne suis même pas certain que les obligations de données ouvertes > s'imposent à toutes les organisations concernées (notamment les très > petites, tels que les micro-producteurs, liés à un contrat privé avec un > autre fournisseur d'énergie qui leur achète tout et peut-être aussi les > finance en partie > Tous les gestionnaires de réseaux sont tenus par les mêmes obligations, pas les producteurs. Des démarches sont actuellement en cours pour disposer la cartographie de tous les réseaux de distribution prochainement https://teamopendata.org/t/les-gestionnaires-de-distribution-electrique/1018 Les ressources sont déjà conséquentes, cela prendra plusieurs mois pour que nous intégrions tout ça dans les outils A votre bon coeur pour l'utiliser :) Bonne soirée François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] La gestion des poteaux
Bonjour à vous Merci d'avoir complété ces quelques points. Concernant la présence de lignes aériennes en zone Enedis, tout est maintenant connu et publié en opendata https://www.enedis.fr/cartographie-des-reseaux-denedis Il est possible de s'en servir pour contribuer à OSM, aucune ligne HTA 20 000 volts ou BT 220 volts ne peut vous échapper dans 95% des communes en France métropolitaine. Les 5% restant arrivent bientôt. Les postes HTA/BT sont aussi disponibles mais aucun attribut ne permet de déterminer s'ils sont sur un poteau ou pas Le souterrain a commencé à être intégré à Caen et Dijon avec de bons résultats. A chaque point de connection aérien/souterrain se trouve un poteau. Donc avec ces données + vues aériennes, il est au moins possible de savoir où les poteaux sont manquants. Bonne fin de weekend François Le ven. 4 sept. 2020 à 20:45, Francois Gouget a écrit : > On Thu, 3 Sep 2020, Philippe Verdy wrote: > [...] > > > Le nombre de cables se voit sur les photos aériennes. > > > > Pas toujours il y a plein de petites lignes même si on est capable de le > > dire. Difficile de dire souvent s'il y a 3 ou 5 câbles ou plus. ou même > > s'il y en a plus d'un seul. > > On parle bien du 20kV, pas du 400V en aval des transformateurs de > distribution ? Les lignes 400V sont effectivement ingérables. Pareil pour > les lignes téléphoniques. > > > > Ca dépend beaucoup du fond (y compris la saison), > > Ils sont effectivement beaucoup plus visibles sur les fonds sombres que > les fonds clairs. C'est pas très pratique dans les vignobles, plus simple > là où il y a des prairies. Mais même si on ne voit pas le nombre de cables > à un endroit donné, on peut souvent les compter dans un autre champ un peu > plus loin. > > > Et de toute façon pas moyen de deviner les tensions transportées et le > > mode (nombre de phases ou continu à certains endroits) > > Comme dit précédemment la tension se déduit des transformateurs qu'on > trouve sur la ligne. > > > > Les transfos sont également pas faciles à voir (et pas toujours montés en > > haut des poteaux, > > Les transformateurs au sol sont au sol sont généralement en bordure des > villes. Pour eux il faut compté sur les photos de rue. > > Mais en campagne c'est huit voir neuf transformateurs sur 10 qui se > trouvent en haut du poteau. Ceux-là font une généralement une verrue bien > repérable sur l'ombre du poteau. > > https://www.openstreetmap.org/edit#map=21/45.77978/-0.09650 > > Du coup ça fait un bon faisceau d'indices : verrue sur l'ombre + ligne 3 > cables qui arrive + proche d'un transformateur manquant sur Osmose + à > coté d'un hameau => il y a un transformateur. > > > > et ce transfo est souvent caché dans la végétation > > D'accord avec toi mais en remplaçant 'souvent' par 'parfois'. La verrue > est aussi parfois moins visible quand le poteau est dans l'axe du soleil. > > > > parfois enterré sous une trappe difficile à voir (ou dans une armoire > > difficile à distinguer d'une armoire télécoms; > > Tout ça ne concerne que les villes. Et dans ce cas c'est clair qu'i faut > des photos de rue. > > > > Pour le gaz c'est plus facile car le chemin est marqué par des gros > points > > jaunes ou chapiteaux jaunes sur un poteau très visibles presque partout > et > > presque toujours en bordure de chemin ou en limite de parcelle sur une > aire > > dégagée. > > Oui. Et il y a moins de marqueurs que de poteaux électriques. Mais les > marqueurs faits pour être vus d'hélicoptère sont assez rares et quand on > n'a qu'eux je ne suis pas sûr que le tracé du pipeline soit bien précis. > Pour bien faire il faut aussi avoir les marqueurs triangulaires (pedestal) > mais ils sont très durs à repérer 'en grous il faut identifier 4 pixels un > peu clairs en losange de part et d'autre d'une route proche du tracé > supposé du pipeline). > > > > Sinon si j'ai des doutes, tant pis je ne relie pas: > > Oui. Pareil. > > > -- > Francois Gouget >___ > 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] La gestion des poteaux
Salut à tous L'été a permis d'avancer certains projets pour pas mal de monde à ce que j'ai vu, y compris les projets du mois :p Suite aux développements de ces deux derniers mois, j'ai mis à disposition aujourd'hui un rendu pour montrer tous les poteaux électriques et telecom qu'on pouvait avoir dans OSM en France. www.gespot.fr Le sujet passionne en ce moment pour le déploiement de la fibre et plusieurs exploitants sont intéressés par ce que la contribution OSM a déjà produit. Exemple : http://gespot.fr/#14.84/46.04506/6.13543 Un peu de documentation sur le sujet : https://common.infos-reseaux.com/files/telco/gespot.pdf @Zimmy : je vais essayer d'en reverser une partie dans les thématiques de GéOSM. Une proposition est en cours d'écriture pour finaliser l'approbation de man_made=utility_pole (tous les poteaux sauf électriques qui sont avec power=pole) https://wiki.openstreetmap.org/wiki/Proposed_features/Utility_poles_proposal (pas encore traduite) C'est dores et déjà utile de compléter les power=pole du réseau de distribution avec operator=Enedis (dans les communes appropriées https://dataviz.agenceore.fr/distributeurs-energie-france/) ou d'ajouter les poteaux Orange de vos environs avec man_made=utility_pole + utility=telecom + operator=Orange A suivre pour la suite des événements, bonne soirée François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Source d'une photo
Salut à tous, Je me suis rendu compte que j'ai utilisé une photo dans l'une de mes prez sur OSM sans en connaître véritablement la source. Est-ce que quelqu'un se rappelle de celle-ci, sa licence et son auteur svp ? http://www.mediation-numerique.fr/actualite_cartopartie--quand-le-numerique-donne-les-cles-de-la-cite-aux-citoyens--_48.html Son nom Cartopartie-V1Sartoux-07.jpg semble indiquer une cartopartie à Sartoux. Je n'en sais pas plus. J'aimerais avoir le droit de l'utiliser dans des slides sur l'asso (que je m'apprête à rendre dispo sur le NextCloud). Merci par avance :) François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] hebdoOSM 524 | Financement de développement pour Nominatim par la foundation OSM
Salut à tous Cela fait quelque temps que je survole le sujet de très très loin. Sans dévaloriser le travail de Richard pour Potlatch 2, je ne comprends pas pourquoi on souhaite maintenir cet éditeur basé sur Flash. Une des solutions évoquées serait de le porter sous Adobe Air, Flash ne sera plus du tout maintenu fin 2020. D'autres technos sont pourtant bien plus pérennes actuellement. Si quelqu'un à l'explication, je suis preneur. Bonne soirée François Le lun. 10 août 2020 à 15:13, Yves P. a écrit : > Bonjour, > > Lu dans l'hebdo, une nouvelle qui devrait vous intéresser : > > https://weeklyosm.eu/fr/archives/13472 > > >- Guillaume Rischard <https://www.openstreetmap.org/user/Stereo> a >annoncé ><https://lists.openstreetmap.org/pipermail/talk/2020-August/085174.html> en >direct le financement de trois projets d’infrastructure : Nominatim, >osm2pgsql et Potlatch 2 par le CA de l’OSMF. > > > Nominatim est le logiciel de géocodage qui alimente openstreetmap.org et > de nombreuses autres applications et sites Web. > Sarah souhaite travailler sur openstreetmap.org pour > >- terminer les efforts de localisation (améliorer le calcul d'adresse >pour différents pays, sortie d'adresse localisée) >- rendre le logiciel plus convivial (réduire le nombre de langages de >programmation d'au moins deux, déplacer les projets annexes dans des dépôts >séparés, réorganiser le code pour que Nominatim puisse devenir un package >Ubuntu, docs, docs, docs) > > La proposition complète se trouve sur > https://wiki.osmfoundation.org/wiki/Nominatim_project_2020-07 > > __ > 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] Edition de masse sur pipeline=marker en France
Bonsoir Yves, Merci d'avoir fait le recensement. Effectivement le sujet des bornes intéresse, et les tags proposés permettent à la fois de décrire des bornes techniques mais aussi les repères routiers, de propriété et autres. Pour ma part j'en remplace régulièrement, à la main, je n'ai pas trouver de meilleure méthode. Les anciens tags ne contenaient pas toutes les informations du modèle actuel, il faut parfois retourner sur le terrain. A noter que parfois plusieurs bornes sont positionnées les unes à côté des autres, de plusieurs types aussi (aériennes et potelet) Il faut ainsi créer autant de noeuds que nécessaire. Certaines sont parfois bien cachées https://twitter.com/InfosReseaux/status/1286969000476516352?s=20 Bonne semaine François Le jeu. 2 juil. 2020 à 15:41, Yves P. a écrit : > De mémoire ce n'est pas un simple copier/coller, il faut faire plusieurs > requêtes overpass pour cela en fonction du type de "chapeau" et de support. > > > *Tags associés à pipeline=marker* *Photo* *Nombre* *Commentaire* > support !~ ".*" et cover !~ ".*" > 7145 <https://overpass-turbo.eu/s/VGY> > support=pedestal photo > <https://wiki.openstreetmap.org/wiki/File:French_gas_pipeline_ground_marker.jpg> > 1642 <https://overpass-turbo.eu/s/VGQ> > cover=roof + support=pole photo > <https://commons.wikimedia.org/wiki/File:Bornes_et_balises_de_rep%C3%A9rage_en_France_06.jpg> > 748 <https://overpass-turbo.eu/s/VFM> > support=pole + cover !~ ".*" photo > <https://wiki.openstreetmap.org/wiki/File:Pipeline_Measuring_Point.jpg> > 551 <https://overpass-turbo.eu/s/VFW> > cover=roof + support !~ ".*" > 279 <https://overpass-turbo.eu/s/VH2> > support=ground photo > <https://wiki.openstreetmap.org/wiki/File:Pipeline_Marker_Ground.jpg> 74 > <https://overpass-turbo.eu/s/VGP> > cover=roof + support=stile photo > <https://commons.wikimedia.org/wiki/File:Bornes_et_balises_de_rep%C3%A9rage_en_France_01.jpg> > 31 <https://overpass-turbo.eu/s/VFO> > cover=roof + support=pedestal > 5 <https://overpass-turbo.eu/s/VFU> borne surmontée d'une balise aérienne > cover=cone photo > <https://wiki.openstreetmap.org/wiki/File:Pipeline_Marker_Cone_Cover_MP.jpg> > 0 <https://overpass-turbo.eu/s/VFX> > cover=fin photo > <https://wiki.openstreetmap.org/wiki/File:Pipeline_Marker_Fin_Cover.jpg> 0 > <https://overpass-turbo.eu/s/VFL> > > Il me semble que j'ai passé en revue tous les cas du wiki pipeline=marker > <https://wiki.openstreetmap.org/wiki/Tag:pipeline=marker> > > Y'a plus qu'à proposer des modifications :) > > __ > 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] ref et ref:FR
Merci à vous pour le nettoyage ! François Le mar. 21 juil. 2020 à 08:42, Topographe Fou a écrit : > Bonjour, > > Suis pour supprimer la colonne, il y a bien souvent dans les autres déjà > des liens vers les annuaires officiels en ligne qui vont bien. > > Merci pour le toilettage. > > LeTopographeFou > *De:* lenny.li...@orange.fr > *Envoyé:* 20 juillet 2020 7:26 PM > *À:* talk-fr@openstreetmap.org > *Répondre à:* talk-fr@openstreetmap.org > *Objet:* Re: [OSM-talk-fr] ref et ref:FR > > > Le 20/07/2020 à 00:39, Yves P. a écrit : > > Je propose de supprimer la colonne Tag2Link, ce greffon n'étant plus utilisé. > > le greffon n'est plus nécessaire, car il a été intégré dans JOSM ( > https://josm.openstreetmap.de/wiki/Fr%3AHelp/Action/Tag2Link) n'en > connaissant pas l'utilisation je n'ai pas d'avis, vous me confirmez que la > colonne n'est plus nécessaire ? > > leni > > > __ > Yves > > > > > ___ > Talk-fr mailing > listTalk-fr@openstreetmap.orghttps://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] sur-spécification ?
Bonsoir Jean-Yvon, J'ai constaté la même chose à certains endroits. Est-ce seulement interdit par le code de la route ? Sinon sur une chaussée à voie unique, dès lorsque le terre plein se termine, il doit être possible de faire demi-tour si les conditions de sécurité sont réunies. Si la chaussée est à voies séparées en sortie de rond-point, la question ne se pose pas François Le mer. 22 juil. 2020 à 00:13, a écrit : > Je vois des interdiction de faire demi-tour sur une départementale en > sortie de rond-point : > > https://www.openstreetmap.org/relation/11332801#map=19/47.78898/-3.47998 > > Stricto sensu ce n'est pas faux mais est-ce que ça a le moindre intérêt ? > > Jean-Yvon > > > > ___ > 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] Le député Éric Bothorel investi d’une mission sur la politique de la donnée et des codes sources
Le ven. 10 juil. 2020 à 09:45, Christian Quest a écrit : > > > Je n'ai pas encore pu trouver une copie de la lettre de mission, pour > savoir exactement de quoi il retourne... > > Je trouve par exemple étonnant qu'on parle d'ouverture "opportune", > alors que c'est la règle par défaut. > C'est bien un point à discuter. Laure de la Raudière peut aussi être intéressée. Vu l'ambiance actuelle il est possible que cette mission puisse être là pour freiner le mouvement. C'est en ce sens que je parlais de vaccin. Bonne journée François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] FTTH Références à fignoler
Bonsoir à vous C'est surement un NRO SFR Oui SFR a la technologie pour mettre ses NRO en armoire. G2R est en tout cas le référentiel infrastructure de SFR. ref:FR:SFR est déjà utilisé pour le FTTH avec des références différentes. Je serais presque d'avis d'utiliser ref:FR:G2R ou ref:FR:SFR_G2R (moins fan de la deuxième) Donc man_made=street_cabinet utility=telecom telecom=exchange telecom:medium=fibre ref:FR:SFR=PTI1 ref:FR:G2R=861604 Qu'en pensez-vous ? François Le lun. 29 juin 2020 à 17:40, Éric Gillet a écrit : > Le 28/06/2020 à 14:55, Jacques Lavignotte a écrit : > > Je l'ai posée au bon endroit : > > > > https://www.openstreetmap.org/node/7660605456 > > > > Aidez-moi à compléter les et les > > > > Merci, Jacques > > > Je connais pas ce domaine spécifiquement, mais je pense qu'il vaut mieux > ne pas mettre les références plutôt que mettre des placeholders qui vont > masquer le manque d'infos. Au minimum il faudrait mettre un tag fixme à > mon avis. > > > ___ > 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] Facebook achète Mapillary !
Bonjour, Le 19/06/2020 à 19:27, François Magimel a écrit : > Pour la gestion de projet, on peut déjà commencer par une page sur le wiki > OSM pour définir les besoins, l'existant, la partie technique et peut-être > des tâches (comme ça, il y en a pour tous les goûts ;)) ? En fait, un pad serait plus adapté dans un premier temps pour recenser les besoins, l'existant et le reste : https://annuel2.framapad.org/p/osm_photo_alternatives-9hcx. Et une fois qu'il aura bien avancé, on pourra en faire une page wiki. À voir si on le fait en français (plus accessible pour nous) ou en anglais (plus accessible pour l'intégration des autres communautés). François / Linkid signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Facebook achète Mapillary !
Hello, Pour le stockage « partagé » d'images, on peut aussi regarder comment s'en sort Pixelfed, basé sur activitypub (fédération, toussa). Pour la gestion de projet, on peut déjà commencer par une page sur le wiki OSM pour définir les besoins, l'existant, la partie technique et peut-être des tâches (comme ça, il y en a pour tous les goûts ;)) ? Bon courage, François Le 19/06/2020 à 17:57, Arnaud Champollion a écrit : > Le 19/06/2020 à 17:53, Christian Quest a écrit : >> >> L'essentiel quand même dans tout ça est la conservation du stock de photos, >> car même si elles sont disponibles sous une licence libre, elles dépendent >> de l'hébergement fait par Mapillary (et donc gratuit pour nous, mais pas >> pour eux) et celui-ci peut très bien être coupé, réduit, changer de >> politique, etc... >> >> L'urgence pour moi est donc dans l'immédiat le "takeout" ;) > > > C'est à dire ? > > Il faudrait aspirer en masse les images pour ne pas les perdre ? > > Comment faire ? > > Je regrette de n'avoir pas conservé de copies de mes (maigres) uploads à > Mapillary. > > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Facebook achète Mapillary !
Salut à tous Le ven. 19 juin 2020 à 11:42, Yves P. a écrit : > Coté Faceebook, pour moi il y deux choses intéressantes dans Mapillary : > la contribution à OSM (et c'est bon pour tout le monde) et l'IA de classe > mondiale qu'a développé Mapillary. > > +1 > > Les photos sont protégées par une licence CC BY-SA 4.0 > <https://creativecommons.org/licenses/by-sa/4.0/> : > https://www.mapillary.com/legal > Elles n'appartiennent ni à Mapillary, ni à Facebook. > Pour que ce soit clair : une licence ne définit pas la propriété d'un matériel, uniquement les conditions d'utilisations (ou de modification, de partage...) Dans le droit français (et dans certains autres), la propriété d'une oeuvre de l'esprit est inaliénable. C'est néanmoins qu'un grand principe : vous pouvez céder les droits d'usage et ainsi ne plus toucher de revenus d'une oeuvre que vous avez produite et dont vous gardez à vie la propriété. Ici l'enjeu est double : que Facebook continue d'utiliser CC BY-SA 4.0 ce qui conditionne directement que l'utilisateur producteur soit crédité, mais aussi continue d'alimenter OSM en données tout aussi libres. Changer de licence du contenu peut être plus ou moins facile selon la raison sociale de l'entreprise qui s'y emploie. Sur OSM, ce serait à l'issue d'un vote... c'est pas le cas partout. Bonne après-midi François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] NRO avec ref ARCEP sans connection_point
Bonjour Jacques, Le mer. 17 juin 2020 à 11:24, Jacques Lavignotte a écrit : > Au passage, j'ai été surpris de voir qu'Osmose jette ref:FR:Orange pour > le cuivre et exige ref:FR:PTT. > Osmose semble se caler sur ce que le wiki dit, et je confirme. ref:FR:Orange correspond aux références "PTx", uniquement pour la fibre. ref:FR:PTT est destiné pour les réseaux cuivre sous un format et des règles d'application différentes. C'est telecom:medium et operator qui détermine ce qui est attendu. Bonne journée François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] NRO avec ref ARCEP sans connection_point
Bonjour Deuzeffe, Le mar. 16 juin 2020 à 00:09, deuzeffe a écrit : > Bonsoir, > > Soit un NRO dans un zouli shelter. > > Si je lis bien le wiki, les tags minimum sont : > - telecom=exchange > - telecom:medium=fibre > Ce sont les tags fonctionnels du domaine. Il faudra aussi building=service utility=telecom (de plus en plus utilisé) building:prefabricated=yes si c'est un shelter préfabriqué. > Pour la ref, j'ai eu la mauvaise idée de mettre un ref:FR:ARCEP et donc > Osmose me signale que ref:FR:ARCEP sans telecom=connection_point, ce > n'est pas réglo. Ok. > > Q1 : j'ai raté quoi ? Que la ref, c'est pas ARCEP ? > Well, cela me fait prendre conscience d'une formulation trompeuse En FTTH il y a deux concepts différents : les points de mutualisation (PM) d'une part et les noeuds techniques (sous répartition, NRO...) d'autre part. Le 1er est un rôle réglementaire, le 2nd est un rôle technique. Un point de mutualisation peut se trouver indépendamment sur une sous-répartition, un NRO, un boitier dans une chambre... et ref:FR:ARCEP concerne les points de mutualisation. J'ai mis à jour la page https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:ARCEP pour mieux l'expliquer et retirer la contrainte sur telecom=connection_point Le dégroupage ADSL qu'on connaît depuis plus longtemps est aussi un cas de mutualisation qui prend place dans les noeuds de raccordement, pas au sous-répartiteur. > Le NRA sis juste à côté est dit raccordé au PM NA__ Je suppose > que c'est lui (le PM) qui doit porter la ref ARCEP ? > Le NRO donc ? NRA est pour le cuivre. Oui c'est le PM qui porte la ref ARCEP, comme expliqué plus clairement, le PM peut être le NRO ou le SRO selon l'architecture adoptée. > Q2 subsidiaire : est-il dans le NRO (un node en plus dans le polygone du > NRO) ou qq part ailleurs pas loin (va falloir arpenter...) ? > Sans plus de précisions sur l'emplacement on ne peut pas conclure. Il peut être dans le NRO (rare) ou juste à côté (une armoire collée au shelter) ou plus loin. Il existe aussi des sous-répartiteurs en shelters. Je m'excuse pour ceux qui ont défini des architectures aussi complexes. Le mer. 17 juin 2020 à 00:05, Francois Gouget a écrit : > > À ce propos, est-ce que telecom=exchange serait approprié pour les > nombreux phone=substation sur Niort ? A ce que j'ai vu ici : https://www.mapillary.com/map/im/DJUMK_hsKRHsetacyumPsw https://www.openstreetmap.org/way/41197531 C'est une sous-répartition cuivre au 1er plan et une armoire d'amplification du réseau câblé ensuite. phone=sub_station n'est pas adapté. Ce n'est pas non plus un bâtiment, mais il est possible de décrire l'armoire comme un polygone si on a des images assez précises. A cet endroit il faut deux noeuds différents, un pour l'armoire cuivre et l'autre pour l'armoire coaxiale. Voir https://wiki.openstreetmap.org/wiki/FR:Tag:telecom%3Dconnection_point pour les deux. A bientôt François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] et si c'était Nöel ? liste de souhait et d'intérêt des outils existant
Merci pour le résumé et le pad ! J'y ai mis mon petit avis du coup... François Le 13/06/2020 à 15:47, Marc M. a écrit : Bonjour, Merci pour vos retours. Voici la compilation chronologique des 8 personnes ayant répondu avec utilisation et/ou besoin/souhait. un doubble étonnement : le nombre limité à 8 et le peux de retour sur les outils existant, à croire qu'on peux fermer la moitié :) - avoir un éditeur web consensuel utilisable (le fameux id-consensuel grâce aux patchs de fred) - accompagner les petites structures pour un switch2osm, ce qui implique d'avoir un doc Leaflet en français par ex sur http://www.openstreetmap.fr/fonds-de-carte/ - soutenir les rendus existant (par ex fr) ou à grandir (cyclosm) parce qu'une donnée qui se voit mal est une donnée un peu gâchée. - diminuer la marche à l'entrée pour les contributeurs : -- faciliter/accompagner lorsque quelqu'un veux faire une amélioration sur un outil majeur, écrire p'tre une doc, identifier les problèmes. -- avoir des serveurs de test pour cela (par exemple tester une modif de rendu à plusieurs, ce n'est pas facile. faut installer un docker, le rendre accessible à l'extérieur, installer le style, etc) -- faciliter le correspondance besoin<>aidant en aidant par exemple la communauté à bâtir une page listant les besoins, afin que ceux qui le souhaitent puisse y piocher sans devoir "parcourir le web". -- soutenir les communautés locales à grandir voir à se créer dans les endroits qui en sont dépourvu. -- aider à l'ajout d'opendata dans osm, non seulement osmose, mais aussi en discutant d'un possible groupe de travail import/intégration ciblé (certaines infos ont un "match" facile entre osm-opendata qui rend inutile de demander un clic par objet). cfr aussi le osmmybiz version opendata-fr - un outil qui envoie un mail de présentation d'OSM dès que l'on tagge email=moncoiff...@orange.fr. Avec un lien vers un soutien financier - maquette de présentation/communication osm auprès des POI - éditeur axé poi osmmybiz + horaire, un wizard/éditeur d'ajout de POI tout public, notamment pour les commerces. - retour du rendu BANO - une instance française de https://nrenner.github.io/achavi/ ? - communiquer autour de http://geosm.openstreetmap.fr - URL de chaque point de vente d'une enseigne https://lists.openstreetmap.org/pipermail/talk-fr/2020-May/099075.html - du Docker sur l'infra OSM-FR (suposé possible avec proxmox 6 à court terme) - du switch2osm qui parle de tuiles vecto - une version d'Osmose dédié à l'OpenData - un canal de discussion pour remplacer twitter "Mapillary team fr" - pouvoir suivre des objets osm en particulier, et être alerté (mail, flux rss, autre) en cas de modification. - interface ‘carte cyclable’ rafraichie tous les jours, comme l’est l’excellent cyclOSM - completer le docker osm-carto switch2osm afin d'avoir la brique "récupérer le style" - CyclOSM - BD Ortho IGN - UMap j'en ai fait un pad pour rajouter facilement d'étentuel avis à venir https://annuel2.framapad.org/p/osm-retour-communaute-9h8d Cordialement, Marc ___ 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] CNIG : Proposition de géo-standard Grace THD
Bonsoir, L'information a peut-être été donnée ici, le CNIG a ouvert un appel à commentaire à propos de la standardisation d'une nouvelle version du modèle Grace THD. http://cnig.gouv.fr/?page_id=17477 http://cnig.gouv.fr/?page_id=23937 Ce modèle de donnée permet un échange d'informations géographiques entre acteurs du déploiement des nouveaux réseaux en fibre optique, dont certains sont des collectivités. Je souhaitais vous donner quelque clés de lecture sur cette phase de la standardisation. Certains objets OSM sont transcriptibles dans la version 2.0.1 du modèle https://wiki.openstreetmap.org/wiki/FR:Tag:telecom%3Dexchange#Correspondance_GraceTHD Un standard fourni normalement un cadre aux développeurs et professionnels pour produire des données comparables et de qualité. La proposition en question laisse de nombreux champs "libres pour l'implémentation", c'est à dire que chacun pourra faire ce qu'il veut. C'est contraire à l'esprit de standard. La gestion de l'adresse n'est pas cohérente entre les différentes classes. Les adresses sont considérées pour les terminaisons des réseaux, pas pour les sites techniques. Enfin, les choix de modélisation ne sont pas suffisamment expliqués dans la notice, ce qui a normalement peu de chance de convaincre le lecteur. Cela rend la discussion sur des sujets purs télécom vaine avant même d'avoir commencé si on est pas capable de comprendre les raisons des choix de modélisation. Il faut penser au précédent que cela pourrait créer en cas de standardisation, sur les pratiques mêmes d'écriture d'un standard. Le planning incroyablement serré me laisse vraiment perplexe. Pensez-y si vous avez l'intention de répondre. Bon début de semaine François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Intégration du bornage du réseau routier national
Bonjour Jérôme Le dim. 7 juin 2020 à 20:28, Jérôme Amagat a écrit : > > >> Si, c'est écrit : à côté de la voie >> https://wiki.openstreetmap.org/wiki/FR:Key:marker#Comment_contribuer >> >> là tu parle du tag marker=* pas de highway=milestone > C'est la même chose, marker=* donne l'apparence physique de la borne. J'ai mis à jour la version anglaise https://wiki.openstreetmap.org/wiki/Tag:highway%3Dmilestone > On ne roule pas sur les feux de signalisation et pourtant c'est conseillé > de placer highway=traffic_signals sur un node du way de la route voir à > l'intersection des ways des routes. pareil pour les panneaux stop et cédez > le passage. > Le problème c'est indique t on la borne ou ce qu'elle représente : c'est > lorsqu'on est sur la route à côté de la borne que l'on est au point > kilométrique. Pareil pour les feux et panneaux (pour les feux et panneaux, > on a le problème de la direction mais pas là). Pour les route, on > "schématise" pas mal dans osm, pas de surfacique, 1 way par chaussée et pas > par voie ... autant continuer. > un node à côté de la route, ça veut aussi dire que l'info est beaucoup > plus difficile à réutiliser (sauf à l'afficher sur une carte). > Ici le jeu de donnée c'est beaucoup d'autoroutes où il me semble le pk est > indiqué des 2 cotés des 2 chaussées donc 3 ou 4 bornes a ajouter, 2 si sur > le way, 1 par chaussée. > La question essentielle est bien de savoir si on cartographie l'effet de l'objet ou l'objet lui-même. Dans le cas des feux et des balises, c'est plutôt l'effet. Pour les limitations de vitesse, ce sont les deux : on place le panneau à l'endroit exact et complétons maspeed sur le linéair concerné. Dans le cas des bornes, je suis en faveur d'indiquer l'emplacement exact, il n'y a pas d'effet sur le linéaire à matérialiser. > > Pas de ref dans le fichier. le code plo indiqué dans le 1er message peut > être déduit des différentes colonne du fichier, mais n'est pas présent. > Donc, pas de ref=* François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Intégration du bornage du réseau routier national
Le dim. 7 juin 2020 à 15:15, François Lacombe a écrit : > Bonjour à tous, > > Le dim. 7 juin 2020 à 11:02, Frédéric Rodrigo a > écrit : > >> >> Le wiki de dit pas si la borne doit être sur ou a coté du la voie. >> > > Si, c'est écrit : à côté de la voie > https://wiki.openstreetmap.org/wiki/FR:Key:marker#Comment_contribuer > > Ajouter les bornes comme noeuds de la route est une mauvaise idée : vous > ne roulez pas sur la borne quand vous y circulez. > Idem pour la signalisation. > Je nuance mon propos : ajouter le noeud sur la voie ne correspondrait qu'aux situations où le point kilométrique est peint au sol, sur la voie. highway=milestone marker=ground color=* distance=* Ce serait également le cas pour des canalisations en surface si la borne est directement installée dessus. François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Intégration du bornage du réseau routier national
Bonjour à tous, Le dim. 7 juin 2020 à 11:02, Frédéric Rodrigo a écrit : > Le 04/06/2020 à 17:09, Marc M. a écrit : > > Le 04.06.20 à 17:02, didier2020 a écrit : > >> dans le référentiel, la bretelle est définie par 2 plo, non visible > >> sur le terrain > >> - la référence métier est sur un way > > séparer l'intégration en 2 : > > - les bornes réelles d'un côté > > - les ref de route non indiquée sur le terrain... > > sans doute qlq chose pour unsigned_ref. > > très pratique pour éviter qu'un guidage te propose > > de suivre une ref que tu ne vois pas. > > Je pense qu'il faut déjà se concentrer sur les bornes physiques. > > > > Un borne est portée une route qui a une référence. > > Le wiki de dit pas si la borne doit être sur ou a coté du la voie. > Si, c'est écrit : à côté de la voie https://wiki.openstreetmap.org/wiki/FR:Key:marker#Comment_contribuer Ajouter les bornes comme noeuds de la route est une mauvaise idée : vous ne roulez pas sur la borne quand vous y circulez. Idem pour la signalisation. > La borne a ensuite une référence unique par route, composé du > département, numéro d'ordre de la borne, coté de chaussée [...]) > > http://dtrf.setra.fr/pdf/pj/Dtrf/0005/Dtrf-0005792/DT5792.pdf page 12 > > Mais cette référence de borne n'inclut pas la référence de la route > (c'eût aurait été trop facile). > > Nationalement il y a donc des doublons de référence de bornes. Ils font > donc les deux références pour l'identifier. > C'est le cas de certains objets, dont plusieurs déjà traités par Osmose : les pylônes RTE par exemple. C'est le cas aussi de la plupart des lampadaires, de beaucoup de bornes à incendie, des bornes GRTgaz. Les numéros sont donnés à la ligne, à la commune ou à l'EPCI, on ne peut pas les identifier nationalement. La conflation doit se faire dans chaque périmètre ce qui ajoute une difficulté en plus oui > > Soit on considère que par jointure/proximité avec la voie qui la porte > on retrouve cette référence, soit on cherche à rajouter la ref de la > route quand même sur la borne (mais dans quel tag ?), ou tout mettre > dans le même tag par concaténation. > ref=* doit contenir la référence de la borne telle que vue sur le terrain ou à défaut dans le fichier. M'est avis qu'il faut sortir de ref:*=* l'identification de la route sur la borne pour ne pas confondre. Un truc du style highway_name=* ou apparenté. Le dim. 7 juin 2020 à 11:33, didier2020 a écrit : > > Les versions Française et Anglaise ne sont pas aprouvée... > > la proposition était simple : ref est le nom de la route > https://wiki.openstreetmap.org/wiki/Proposed_features/Milestones Bon point de souligner que les discussion n'est pas allée au bout. Je n'ai pas la même interprétation de "ref <https://wiki.openstreetmap.org/wiki/Key:ref>=* is optional, only to be used if the milestone actually has a reference number written on it." En France, je ne connais aucune borne kilométrique qui ait une référence sur le terrain. Bon dimanche à vous François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Intégration du bornage du réseau routier national
Bonjour, C'est un très bon sujet. Je ne peux pas prendre le temps de l'envisager dans la globalité pour l'instant, voici quelques éléments que je souhaitais apporter. highway=milestone peut être utilement complété par marker=* Idéalement marker=stone ou marker=plate voire marker=post lorsque c'est opportun. https://wiki.openstreetmap.org/wiki/Tag:marker%3Dstone https://wiki.openstreetmap.org/wiki/Tag%3Amarker%3Dplate https://wiki.openstreetmap.org/wiki/Key:marker C'est ce qui permet de détermine l'apparence physique de la borne (highway=milestone étant son rôle fonctionnel). Merci d'en tenir compte dans vos réflexions. Bonne après-midi François Le jeu. 4 juin 2020 à 16:38, Frédéric Rodrigo a écrit : > Je résume. > La question porte sur l'usage du tag ref pour un highway=milestone. > Certains utilisent la ref de voie (A 63), d'autres la distance. Il y a > en plus une référence "métier" non inscrite sur les bornes. > https://wiki.openstreetmap.org/wiki/Tag:highway%3Dmilestone > > Mon avis perso. La ref de la voie ne peut pas être la ref de la borne > car ça ne rend pas cette référencée unique dans son contexte > d'utilisation, c'est à dire la voie. > > > Le 04/06/2020 à 16:04, didier a écrit : > > Bonjour, > > > > Afin qu'osmose puis permettre d'intégrer des données du réseau routier > > national, > > F.Rodrigo m'a demandé de voir l'utilisation des tags pour > > highway=milestone > > > > Préambule : > > Le céréma gère le référentiel du réseau routier national (RRN), qui est > > a l'origine une base de donnée patrimoniale : > > - Une route et sa représentation géométrique (Polyline) : A0001, N0001 > > etc... > > - Une route pour les bretelles d'entrée, sortie, échange ou giratoire > > : 60A900130DC, 78A901310 etc... > > - Des "points localisants" (plo) qui sont associés a une route > >+ chaque plo a une distance cumulée par rapport au début de la route > > (l'ecart entre deux plo est appelé inter-pr) > > les 2 types de localisants qui sont "interressant" sont > >+ SC pour section courante (plo 93PR1D pr 1, 60PR30GC pr 30) > >+ DB pour début bretelle (plo DB1 pr 1, plo DB2 pr 2) > >+ FB pour fin bretelle (plo FB1 pr 1, plo FB2 pr 2) > > > > ces 2 tables sont le référentiel rrn et sont suffisantes pour décrire > > le réseau routier et ses différentes caractéristiques et ceci sans > > coordonnées. > > exemple: sur la route A0001, 100 metres après le plo 93PR1D et jusqu'a > > 10 metres après le plo 93PR2D, le nombre de voie est de 5, la vitesse > > de 90 km/h > > > > Différents export de cette base sont disponible sur data.gouv.fr mis a > > disposition par le Ministère de la Transition écologique et solidaire > > entre autre : > > https://www.data.gouv.fr/fr/datasets/bornage-du-reseau-routier-national/ > > > https://www.data.gouv.fr/fr/datasets/gestionnaires-du-reseau-routier-national/ > > > > La question pour l'intégration dans Openstreetmap est sur l'utilisation > > des tags, lesquels utiliser ?: > > A) Pour les routes, il n'y a pas de données précise mis a disposition > > sur data.gouv.fr. > > ref est utilisé sur les way et dans les relations routes mais avec un > > espace entre la lettre et les chiffres > > Il n'y a pas de donnée a intégrer > > > > B) Pas retenu pour une intégration avec osmose : > > Pour les plo de type DB ou FB, cela correspont a des entrées, sorties, > > giratoires ou bretelles d'interconnexion => type:way et > > highway=motorway_link, trunk_link, primary_link... > > cela correspond : > > > https://www.data.gouv.fr/fr/datasets/gestionnaires-du-reseau-routier-national/ > > (les données de bretelle et de bornage sont mélangées) > > la référence ne sera pratiquement jamais visible sur le terrain. > > je propose > > nat_ref = 60A900130DC_1 > > car cela correspond a ce qu'utilise bison-futé pour la géolocalisation > > de ses données événementielles > > > > C) Pour les plo de type SC, cela correspont au bornage routier => > > type:node et highway=milestone > > les données sont disponibles : > > https://www.data.gouv.fr/fr/datasets/bornage-du-reseau-routier-national > > (les données de bretelle et de bornage sont mélangées) > > (pour info, les données intégrables commencent après la ligne 13454) > > > > dans le wiki, les tags highway=milestone sont distance et ref > > > > je propose cette correspondance pour des attributs du csv > > - x coordonnées lon epsg:2154 > > - y coordonnées lat epsg:2154 > > - z toujours a 0, a ignorer > > > > - abs : toujours a 0,
Re: [OSM-talk-fr] DCbrain rend publique une partie de son code en open source
Philippe, je crois que tu ne comprends pas. Le mar. 26 mai 2020 à 17:24, Philippe Verdy a écrit : > Justement j'ai proposé un patch, pas juste exposé les problèmes. C'est > nécessaire pour éviter que ce code maintenant publié soit utilisé tel quel > sans correction au risque d'importer des géométries farfelues, car un tel > script peut servir à faire des imports en masse sans trop regarder... > Proposer un patch de cette façon en l'assortissant de phrases buttoir n'apporte rien et surtout décourage d'autres de publier leur contribution, si c'est pour avoir à faire à ce genre de discours. Personne n'a parlé d'import dans OSM. Les cas d'usage proposés étaient d'utiliser certains logiciels, en particulier osrm, avec des données qui ne viennent pas d'OSM. Mon utilisation est certainement trop limitée pour avoir vu le problème des antipodes. Que le code soit perfectible, certes. On ne va quand même pas attendre qu'il soit parfait pour le publier? Tu ne semble pas avoir compris pourquoi les layers avaient été introduits ici. Quand on combine plusieurs jeux de données, des nœuds peuvent se trouver au même endroit sans devoir être fusionnés. +1 avec Adrien et Jérôme, j'ai tout simplement pas envie de regarder la suite. François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] DCbrain rend publique une partie de son code en open source
Bonjour Philippe, Le mar. 26 mai 2020 à 06:52, Philippe Verdy a écrit : > Ce code source n'apporte strictement rien. > Merci à toi. Bonne journée François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Candidature au CA OSM France
Bonjour à tous, Dans la droite ligne des communications de Donat et Tony, je présente ma candidature pour continuer de porter la parole d'OSM France au CA de l'association. On se retrouve bientôt pour la rétrospective de cette année avant l'AG du 13/06 prochain. Bonne fin de weekend François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import de points d'eau incendie en Saône-et-Loire
Bonsoir Yves, Le ven. 22 mai 2020 à 22:12, Yves P. a écrit : > > Le 20 mai 2020 à 08:31, Jérôme Seigneuret a > écrit : > > Je ne sais pas si on peut adjoindre dans alias dans ID via Transifex. Cela > permettrait d'avoir des terminologies différentes pour les mêmes couple de > clés/ valeurs en résultat… > > Oui. Cf. message sur "les bons termes" > > Il faudrait aussi harmoniser les termes/traductions dans JOSM. > Et revoir le wiki Correspondance avec le modèle PEI de l'Afigeo > <https://wiki.openstreetmap.org/wiki/FR:Tag:emergency=fire_hydrant#Correspondance_avec_le_mod.C3.A8le_PEI_de_l.27Afigeo> > car > une BI (bouche) est appelée "borne". > (Le PI (poteau) est appelé "poteau" ouf.) > Il est fort dommage que le document de l'Afigéo ne soit plus en ligne (Google Drive...). C'était le seul endroit où il était matérialisé. Ils devraient se payer un wiki http://www.afigeo.asso.fr/1786 J'ai normalement repris leur terminologie. Une bouche à incendie ne correspond qu'à un PEI enterré il me semble. Une borne semble être un abus de langage. L'AFNOR, quant à elle, qualifie tout de poteaux : https://www.boutique.afnor.org/norme/nf-en-14384/poteaux-d-incendie/article/694754/fa101025 Le modèle de l'Afigéo se base en partie dessus. Le ven. 22 mai 2020 à 23:51, Yves P. a écrit : > > Voici ce qui est existe dans la bas OSM : > https://taginfo.openstreetmap.org/search?q=sdis > (j'avais mis ref:SDIS39 pour le Jura pour tenter de rester homogène avec > l'existant) > Je serais d'avis de passer progressivement à ref:FR:* comme le reste. > > A priori il n'y a pas de bornes chez le voisin, donc quel intérêt de > préciser le sdis ? > > Pouvoir pointer directement sur le jeu de données du service correspondant. > On pourrait y arriver avec operator, sauf si on met Véolia, Commune XYZ… > Attention, le SDIS agrège des infos de différents exploitants. Ce n'est pas parce que le SDIS publie le jeu de données que les références sont attribuées par le SDIS. Elles sont souvent déterminées par l'exploitant, c'est à dire le service de l'eau qui exploite la zone. Le SDIS n'est qu'utilisateur, il n'attribue pas de références (ou les siennes, différentes de la responsabilité de l'exploitant du réseau d'eau). > Petit gag, il n'y a pas que des SDIS en France ;) > BSPP <https://fr.wikipedia.org/wiki/Brigade_de_sapeurs-pompiers_de_Paris> > , BMPM > <https://fr.wikipedia.org/wiki/Bataillon_de_marins-pompiers_de_Marseille> > , SSLIA > <https://fr.wikipedia.org/wiki/Service_de_sauvetage_et_de_lutte_contre_l'incendie_des_a%C3%A9ronefs> > ? > Comment sont référencés les PEI de Paris et de Marseille ? > Comme les autres : les services de l'eau compétents, à savoir Eau de Paris et Eaux de Marseille attribuent des références et réalisent les essais de PEI en coopération avec le SDIS. https://twitter.com/InfosReseaux/status/1061630374328131585?s=20 > Existe-t-il des PEI dans les aérodromes ? > Sont-ils référencés par le SDIS local ou par le SSLIA ? > Ni l'un ni l'autre : par le service de l'eau local si ils sont alimentés par le réseau public. D'autres dispositifs peuvent être exploités par le SSLIA. > Sinon si ce sont les numéros affichés sur les bornes, ref suffit > (visiblement non). > > *ref* c'est ce que le contributeur OSM voit sur la borne. > *ref:sdis*… c'est ce qui est utilisé dans le SIG et le fichier OD du SDIS. > Comme d'habitude, ref c'est le terrain, ref:*:* c'est le métier. > Il faudrait regarder dans les fichiers OD si les identifiants commencent > tous par les n° INSEE de la commune ? > https://www.data.gouv.fr/fr/search/?q=hydrant > https://www.data.gouv.fr/fr/search/?q=PEI > Une récente réglementation dont je n'ai pas la référence impose le référencement et la signalisation des PEI, mais ne donne pas de format de codification à ma connaissance. > > > > "operator": "VEOLIA", > "operator": "Veolia", > > C'est la commune ou un sous traitant qui installe, maintient les PEI et > effectue les mesures de débits/pressions. > Ce sont les "SDIS" qui les utilisent. > Il y a un "peu de tout" dans operator : https://overpass-turbo.eu/s/Uhd > operator=* ne devrait contenir que l'exploitant du réseau d'eau potable qui alimente le PEI dans le cas de water_source=main. A bientôt François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Feature proposal - Lines management - Vote
Bonsoir à tous, Les discussions sur la seconde proposition de qualification des poteaux/pylônes se sont achevées récemment et le vote a pu démarrer ce soir. https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Lines_management Cette proposition concerne cette fois-ci des topologies particulières des lignes électriques, lors qu'elles divergent, se croisent, passent en souterrain à proximité d'un support. Si elle est acceptée, un gros nettoyage de tower:type/pole:type pourra avoir lieu et certaines situations difficilement descriptibles pourront être représentées plus facilement. Plusieurs discussions intéressantes ont eu lieu et on a pu s'apercevoir comme d'habitude que tout n'était pas si simple, malgré un sujet très technique. Les valeurs proposées ont été éprouvées sur les réseaux électriques, la terminologie est toutefois neutre et peut être utilisée ailleurs si des situations similaires se présentent. Ne vous inquiétez pas des 12 000 objets à modifier suite à ces changements. Il reste en France plus de 28 millions de poteaux à cartographier, je ne sais pas combien dans le monde. Merci par avance de prendre le temps donner votre avis sur la version anglaise, bon week-end à tous https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_management François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import de points d'eau incendie en Saône-et-Loire
Salut à tous, J'ai vu que la doc anglaise avait été mentionnée en début de discussion, avez-vous vu la version française avec la correspondance avec le modèle de l'Afigeo ? https://wiki.openstreetmap.org/wiki/FR:Tag:emergency%3Dfire_hydrant#Correspondance_avec_le_mod.C3.A8le_PEI_de_l.27Afigeo Il y a un standard d'échange qui a été défini, justement pour éviter de devoir en discuter à chaque fois. Je pense qu'il y a peut-être d'autres points, mais ne passez pas à côté Bonne journée François Le mer. 20 mai 2020 à 08:32, Jérôme Seigneuret a écrit : > Je ne sais pas si on peut adjoindre dans alias dans ID via Transifex. Cela > permettrait d'avoir des terminologies différentes pour les mêmes couple de > clés/ valeurs en résultat... > > Le mer. 20 mai 2020 à 06:38, Antonin Delpeuch (lists) < > li...@antonin.delpeuch.eu> a écrit : > >> On 19/05/2020 23:37, Yves P. wrote: >> >> Mon habitude de dire "pilier" vient probablement du fait que c'est le >> >> terme utilisé par iD en version française (pour traduire la valeur >> >> "pillar") - ça vaudrait le coup d'être corrigé. Si tu sais comment >> >> résoudre ça (et probablement d'autres problèmes de terminologie) >> >> n'hésite pas ! >> > Il faut utiliser Transifex >> > : https://www.transifex.com/openstreetmap/id-editor/ >> > >> > Pour plus d'infos : >> > >> https://github.com/openstreetmap/iD/blob/develop/CONTRIBUTING.md#translating >> >> Super! Je te laisse t'en occuper ? Personellement je n'ai pas de >> préférence particulière sur les termes à utiliser. >> >> Antonin >> >> ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > > > -- > Cordialement, > Jérôme Seigneuret > ___ > 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] "Les bons termes" [était Re: Import de points d'eau incendie en Saône-et-Loire]
Bonjour Vincent, Parfaitement d'accord avec cette distinction. Elle rappelle des discussions que nous avons régulièrement en présentant OSM à des entreprises ou des pros. Je compléterais en ajoutant que certains langages métier ont, comme tous langages, leurs biais, leur existence en silo et ne font pas cas d'autres activités voisines. La communauté est riche d'une diversité qui permet aux néophytes, aux pros, aux bénévoles de converger sur une même plateforme. Le pro la semaine est bénévole le weekend (ou l'inverse). Pour avoir eu à faire plusieurs correspondances entre des modèles métier et OSM, le langage métier n'est pas celui qui permet d'adresser le maximum de situation avec une formulation claire. Regardez certaines classes INSPIRE pour vous apercevoir que cette sémantique n'est pas la plus utilisable. Les discussions qui ont eu lieu sur les bornes à incendie, pour établir le modèle d'échange officiel, a aussi montré que certains pros (pas vous qui me lisez, les autres) prenaient parfois des mots pour d'autres ou ne maîtrisaient pas correctement les définitions de mots galvaudés. Il y aussi des différences de perception entre les services, entre les localités. Ce n'est pas un tort, cela n’empêche absolument pas aux métiers de fonctionner au quotidien dans leur silo. OSM n'a pas à en souffrir néanmoins pour proposer quelque chose de plus large. D'expérience, les tags qui marchent le mieux sont ceux pour lesquels les définitions sont claires, les cas d'usages bornés et le consensus partagé, qu'ils soient métier ou non. Bonne après-midi François Le mer. 20 mai 2020 à 08:54, Vincent Bergeot a écrit : > Bonjour, > > Le 19/05/2020 à 22:16, Yves P. a écrit : > > Préalable : utiliser les bons termes :) > > Les "professionnels" parlent de PEI (point d'eau incendie), qui sont ; > >- des poteaux (le commun des mortels appel ça des bornes, toi des >piliers par anglicisme ?, parfois même des bouches > - ils sortent du sol. >- des bouches > - elles sont enterrées dans le sol. >- des points d’eau naturels >- des points d’eau artificiels >- … > > je suis favorable à utiliser "les bons termes", mais cela ne signifie pas > que ceux sont les termes des "professionnels". Le langage pro est comme > tout langage, avec ses spécificités, pas forcément accessible aux non pro. > Et OSM n'est pas professionnel *ou* non professionnel *ou* ... mais est > plutôt professionnel *et* non professionnel *et* ... > > Donc OSM a son propre langage. Il me semble dont que si il doit y avoir > "de bons termes", cela doit être ceux que nous construisons en commun (qui > prendra sans doute des choses chez les pros, dans le langage commun, chez > les non pros, dans les traductions d'iD, ...). > > Bonne journée > > -- > Vincent Bergeot > > ___ > 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] Suspicion d'usage massif d'une source non autorisée
Salut à tous, J'ai eu récemment à faire à un contributeur de bonne foi qui a indiqué se servir de StreetView sans avoir connaissance des conditions restrictives qui ne le permettent pas. Évidemment peu de monde a conscience de ces restrictions. Dans un fonctionnement un peu automatique, ses contributions auraient du être annulées. Je lui ai proposé de conserver les contributions qu'il avait faite tout en commençant à prendre systématiquement en photo les objets qu'il ajoutait. Ajoutées à Wikimedia Commons, il est ensuite possible de sourcer chaque objet en y ajoutant la photo. Je reconnais que cela est borderline, mais au final on aura gagné un contributeur moins démotivé que si les contributions avaient été annulées et des objets mieux d'écrit puisque systématiquement pris en photos. Le tout est d'avoir une bonne communication pour trouver une solution adaptée à chaque situation. Bonne journée François Le mar. 19 mai 2020 à 15:46, Yves P. a écrit : > > Tes observations sont étayées, et tu as contacté le contributeur. > Attends de voir s'il réagit à ce message, que tu peux peut-être doublonner > par un message direct (via la messagerie OSM) hors changeset. > > Tu peux aussi "éduquer" le contributeur avant de sortir le char d'assaut :D > Et l'inciter à utiliser à d'autres sources, OD, terrain :) > > Outre le problème de licences, GSV n'est qu'une source parmi d'autres, > elle aussi truffée d'erreurs. Il faut donc les croiser et en cas de doutes, > privilégier le terrain. > Le plus souvent, les photos StreetView ne sont plus à jour. Un poteau > incendie sur GSV avait traversé la route :D > Parfois même, les photos ne correspondent pas à l'endroit. > > Quand aux POI sur GM, ils sont localisé automatiquement et pas au bon > endroit, ou plus à jour. > > > Si tu constates qu'il recommence à contribuer sans avoir répondu, alors > ça peut valoir le coup de signaler le cas au DWG [1] pour un blocage > temporaire, qui lui imposera de lire les messages avant de recommencer à > contribuer. Ce sera l'occasion de voir s'il en tient compte. > > __ > 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] Quality and the Openstreetmap value chain
Hi Jean-Marc, Long time no see! Le mer. 13 mai 2020 à 17:08, Jean-Marc Liotier a écrit : > On 5/12/20 3:50 PM, Colin Smale wrote: > > The role I expect of the data consumers is to articulate how they would > like to view the data (including what attributes they are expecting), and > not to dictate how that data is stored/represented internally. Cartography, > geography, statistics etc are very different skills to data modelling and > database design. > > Indeed, technical implementations take functional requirements into > account but have many other inputs and a different class of actors. > Consumers, tell us what you want - not how to do it ! Same as any software > project... > As a data consumer, telling you what I want directly often relates to how tagging is built as I consume raw osm data without filters or transformation done by any API (and that's fortunate). "Same as any software project" Corporate software projects can be designed to preserve silos and inefficiency due to any so-called-valid excuse of dysfunctional middle management (rude, but... change my mind) OSM is a good opportunity to change practices and show some solutions that would be really hard to provide at company scale. So, respectably no, not like any software project please. All the best François ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] DCbrain rend publique une partie de son code en open source
Salut, Merci pour le relais. J'ai eu l'occasion de tremper dans cette sombre affaire. Le convertisseur est utilisé pour alimenter OSRM, mais c'est surtout le réciproque de osm2pgsql. Il produit un fichier xml osm à partir d'une base postgis. Cela ayant pour avantage de bénéficier de la force de postgis et de données tierces pour utiliser des logiciels qui n'acceptent que du xml en entrée. La valeur ajoutée résident dans le code SQL de création de la topologie avec les bonnes connections plus que dans l'écriture du XML qui devrait être revue prochainement. A dispo pour plus d'explications François Le mer. 13 mai 2020 à 16:25, a écrit : > DCbrain rend public un convertisseur de données, sur son compte Github. Il > s'agit d'un convertisseur de données géographiques postgresql en format > openstreetmap > Apparemment c est en rapport avec OSRM > > Source: > https://www.programmez.com/actualites/dcbrain-rend-publique-une-partie-de-son-code-en-open-source-30553 > > Julien > > ___ > 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] Robert Keller, Laurent Matheron et Pierre Guillou : Hitler sur table d'écoute
Bonjour Yves Il y a aussi un central téléphonique qui porte le nom de Robert Keller, correspondant au bureau de poste dans le 15eme arrondissement Parisien https://www.openstreetmap.org/node/2062421762#map=19/48.84801/2.28139 (Il manque ref ptt dessus 75115RKE) Est ce qu'on sait où se trouve la plaque commémorative à Lyon Sevigné? J'y ai passé 3 mois il y a quelques années, peut etre l'ai je en photo Bonne nuit ! François Le lun. 11 mai 2020 à 11:16, Yves P. a écrit : > Bonjour, > > Un documentaire très intéressant sur le "piratage" de liaison télécom > entre Paris et Berlin est disponible en replay sur France 5 > <https://www.france.tv/documentaires/histoire/720801-hitler-sur-table-d-ecoute.html> > . > > Les pages wikipedia Robert Keller > <https://fr.wikipedia.org/wiki/Robert_Keller>, Laurent Matheron > <https://fr.wikipedia.org/wiki/Laurent_Matheron> et Pierre Guillou > <https://fr.wikipedia.org/wiki/Pierre_Guillou> rendent hommage à ces > résistants. > > Malheureusement, il n'y a que très peu de liens entre les objets OSM et > les objets wikipedia/wikidata. > > Est-ce que les contributeurs locaux et/ou les amateurs d'histoire peuvent > compléter ? > > Pour ma part, j'ai rajouté la plaque en hommage à Pierre Guillou à Rennes > :) > __ > Yves > > PS: > Ajout OpenPlaques et lien avec la photo, ajout de l'inscription dans > Commons et ajout OSM. > Elle sera visible dans quelques heures sur historic.place > <https://gk.historic.place/historische_objekte/l/fr/index.html?zoom=19=48.11067=-1.65521=HaHbHcSaHe?select=n7505930664>, > de même que la photo dans openplaques.org > <http://openplaques.org/plaques/53568>. > > Pages wikipedia > >- Paris > - Rue de l'Ingénieur-Robert-Keller > <https://fr.wikipedia.org/wiki/Rue_de_l'Ing%C3%A9nieur-Robert-Keller> > - Piscine Keller <https://fr.wikipedia.org/wiki/Piscine_Keller> > - Tour Keller <https://fr.wikipedia.org/wiki/Tour_Keller> > - plaque commémorative > > <https://commons.wikimedia.org/wiki/File:Plaque_Comm%C3%A9morative_en_l'honneur_de_l'Ing%C3%A9nieur_des_PTT_Robert_Keller_&_ses_compagnons_R%C3%A9sistants.jpg> >- Rennes > - Category:Centre Pierre-Guillou > <https://commons.wikimedia.org/wiki/Category:Centre_Pierre-Guillou>. > Façade du centre visible sur GSV > > <https://www.google.com/maps/@48.1103606,-1.6555346,3a,60y,34.45h,84.56t/data=!3m6!1e1!3m4!1s4FX1X89980l7CdbRxXLyrQ!2e0!7i16384!8i8192>, > et plaque sur la vue 3D > > <https://www.google.com/maps/place/48%C2%B006'37.9%22N+1%C2%B039'18.5%22W/@48.1105329,-1.6544823,68a,35y,270h,45.03t/data=!3m1!1e3!4m5!3m4!1s0x0:0x0!8m2!3d48.11053!4d-1.65515> > > Objets OSM > >- Paris > - Rue de l'Ingénieur Robert Keller (Relation 541733 > <https://www.openstreetmap.org/relation/541733#map=18/48.84775/2.28264> > ) > - 6, Rue de l'Ingénieur Robert Keller (Nœud 682420370 > <https://www.openstreetmap.org/node/682420370>) > - Tour Keller (Chemin 115878685 > <https://www.openstreetmap.org/way/115878685>) > - Piscine Keller (Chemin 115878661 > <https://www.openstreetmap.org/way/115878661>) >- Noisy-le-Grand > - Rue du Réseau Robert Keller (Chemin 300360502 > <https://www.openstreetmap.org/way/300360502#map=15/48.8517/2.5754>) >- Dunkerque > - Rue Pierre Guillou (Relation 4160543 > <https://www.openstreetmap.org/relation/4160543#map=14/51.0243/2.3918> > ) > - Allée Pierre Guillou (Chemin 310637211 > <https://www.openstreetmap.org/way/310637211#map=14/51.0200/2.3827>) > et Aire Pierre Guillou (Chemin 310637210 > <https://www.openstreetmap.org/way/310637210#map=17/51.01937/2.38624> > ) >- Saint-Brévin-les-Pins > - Avenue Pierre Guillou (Chemin 537798149 > <https://www.openstreetmap.org/way/537798149#map=13/47.2572/-2.1607> > ) >- Rennes > - Centre Pierre Guillou (Tout ou partie ? du chemin 80941896 > <https://www.openstreetmap.org/way/80941896>) > - Plaque commémorative : Pierre Guillou(Nœud 7505930664 > <https://www.openstreetmap.org/node/7505930664>) >- Plonévez-Porzay > - Square Pierre Guillou (Chemin 109304851 > <https://www.openstreetmap.org/way/109304851#map=19/48.12423/-4.21947> > ) >- Troyes > - Rue Robert Keller (Chemin 68247930 > <https://www.openstreetmap.org/way/68247930#map=16/48.3243/4.1102>) >- Lyon > - plaque commémorative est apposée une plaque dans l'encein
Re: [OSM-talk-fr] Ça reste ouvert bientôt intégré sur le site de la ville de Lyon
Magnifique boulot effectué depuis toutes ces semaines Bravo à toute l'équipe ! Et la réponse positive des collectivités complète significativement le tableau Bonne soirée François Le mer. 6 mai 2020 à 19:43, Florian LAINEZ a écrit : > Bonjour à tous, > Suite aux précédents emails de l'équipe de "Ça reste ouvert", voici un > nouveau point d'étape. > > Le projet a en effet beaucoup grandi depuis le début du confinement. > D'un outil développé en urgence pour lequel rien n'était calé, nous avons > tous ensemble réussi à faire d'OSM la base de données incontournable pour > connaître les lieux ouverts durant le confinement. C'est déjà en soi un > succès ! > > *En France, notre mobilisation collective a permis d'indiquer sur la carte > à ce jour 117 498 lieux*, et dans le Monde entier, ce sont même plus de > 301 281 lieux ! > En réponse aux demandes des communautés OSM locales, nous avons ouvert le > service dans de nouveaux pays. Celles-ci n'ont pas eu besoin d'installer > une instance dédiée : nous avons permis la traduction, affiché les POIs > adaptés à la situation dans leur pays, développé une appli mobile > accessible sur les stores dans leurs pays, produit des visuels adaptés ... > c'est un gros chantier que nous avons entrepris avec enthousiasme. > Sont couverts à ce jour : France métropolitaine, outre-mer & Monaco ( > caresteouvert.fr), Allemagne, Suisse & Autriche (bleibtoffen.de), Espagne > (dont Catalogne (esobert.osmcatala.cat) et Galice) & Andorre > sigueabierto.es, Finlande (ollaanauki.fi), République Démocratique du > Congo (ezosala.org) et Philippines. De nouvelles ouvertures sont à > prévoir, les infos sont tenues à jour sur la page > https://blog.caresteouvert.fr/international-coverage > > *Du coté de la presse, ce sont des dizaines d'articles qui ont mis en > avant la communauté OpenStreeetMap*. Nombre d'entre nous sommes allés au > contact de la presse pour exposer nos initiatives locales de cartographie > des lieux ouverts durant le confinement et expliquer les avantages > d'OpenStreetMap et de l'open data pour faire face à la crise. > Nous (essayons) de tenir à jour une revue de presse qui liste les articles > qui mentionnent le projet : https://blog.caresteouvert.fr/presse > (n'hésitez pas à nous faire part d'éventuels manquements) > Nous avons également la chance de compter parmi nos bénévoles un excellent > graphiste qui nous a aidé à faire ce dossier de presse : > https://blog.caresteouvert.fr/dossier-presse (vous pouvez largement > diffuser cette URL à la presse) > > Le déclencheur du projet fut la promotion de notre cartographie bénévole > de la ville par la mairie de Montrouge. Cette reconnaissance initiale nous > a poussé à élargir le périmètre à la France (puis au delà). > Depuis lors, le maire de Bordeaux lui-même nous a mentionné dans un tweet > <https://twitter.com/nflorian33/status/1246046916523315200> et *de > nombreuses collectivités locales ont trouvé avec "Ça reste ouvert" une > solution efficace de communication *auprès de leurs habitants. > Nous avons très tôt écrit un guide dédié pour accompagner spécifiquement > ces acteurs > <https://blog.caresteouvert.fr/un-outil-de-communication-des-mairies/>. > > Nous passons maintenant un nouveau cap : impressionnée par la qualité du > travail collectif déjà réalisé sur la ville de Lyon,* la mairie nous a > proposé d'intégrer la carte directement sur leur site.* C'est encore une > belle étape de franchie et nous sommes heureux de vous en faire part avant > la mise en place effective qui aura lieux dès lundi. > Concrètement la ville intégrera la carte "Ça reste ouvert" dans le site > http://lyon.fr et notre équipe développera quelques fonctionnalités > spécifiques pour promouvoir la réouverture des restaurateurs locaux. > > Cette première prestation permettra tout d'abord de couvrir les frais déjà > avancés pour le projet. Nous proposerons également à nos partenaires > techniques qui nous ont soutenu gracieusement jusqu'à présent de participer > financièrement à leur infrastructure technique (cela inclus entre autres > l'association OpenStreetMap France). > Ensuite, une petite gratification d'environ 200€ sera dédiée aux membres > les plus impliqués de l'équipe, qui ont consacré plusieurs centaines > d'heures ces dernières semaines pour construire, documenter, communiquer, > contribuer sur OSM et sur "Ça reste ouvert". Enfin, nous n'oublions pas la > communauté OSM en France et à l'étranger, sans qui le projet n'aurait pas > eu un tel impact et n'aurait pas été un si beau succès. Nous prévoyons de > la remercier sous une forme concrète, qui vous sera présentée prochainement > (n'hésitez pas à nous soumettre vos idées !). > > Ce partenariat
[OSM-talk-fr] Schémas de nommages locaux et cas de ref:FR:RTE_nom
Bonjour à tous, Nous en avons déjà discuté ici, les schémas de références et nommage locaux est un sujet qui me tient à cœur. Il existe un cas un peu particulier avec RTE qui exploite le réseau de transport d'électricité puisque 2 clés sont disponibles avec des cas d'usage différents : ref:FR:RTE (le "codnat") et ref:FR:RTE_nom (le nommage officiel en plus du codnat). https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:RTE_nom Récemment je me suis aperçu qu'un contributeur avait eu la bonne idée d'utiliser name:FR:RTE. Cela me semble être une bonne idée selon les points suivants : * ref:FR:RTE_nom fait passer un nom comme une ref, c'est plutôt un nom avec des règles particulières, en plus d'une ref. * ref:FR:RTE_nom n'est pas affiché sur le terrain il me semble et les valeurs répondent à des règles précises * name:FR:RTE permet de recevoir ces règles particulières et autorise l'emploi d'une valeur en minuscules pour name=*, notamment utilisé pour le rendu. Je réfléchi pour remplacer ref:FR:RTE_nom par name:FR:RTE Quels pourraient être les arguments contre ? Merci par avance, bonne soirée François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] plusieurs structures dans un même bâtiment
Bonjour, Voici ce que nous avons retenus pour les infras télécoms. Deux ou plusieurs noeuds de service peuvent se trouver dans le même bâtiment, ainsi il faudra ajouter autant de noeuds OSM dans le polygone du bâtiment avec chacun des attributs appropriés https://wiki.openstreetmap.org/wiki/FR:Tag:telecom%3Dexchange#Cas_de_multiples_noeuds_dans_le_m.C3.AAme_b.C3.A2timent My 2 cts François Le sam. 25 avr. 2020 à 23:45, Georges Dutreix via Talk-fr < talk-fr@openstreetmap.org> a écrit : > Les ref:FR:FINESS servent aussi au contrôle qualité. > J'avais commencé un balayage pour entrer les n° finess manquant sur des > EHPAD, maintenant Osmose me signale les EHPAD carrément inexistants dans > OSM. > Ça marche vraiment bien :-) > > > Le 25/04/2020 à 23:21, Christian Rogel a écrit : > > Les ref. FINESS ? S’il y en a 2, on les met tous les 2. De toute façon, ça > sert à faire des stats, pas à dire aux gens ce qu’il s’y passe. > > > ___ > 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] New diary: 10 years of French power transmission network mapping
You're welcome Christine :) I'll try to setup some viz tool which use network topology. This is kind of occupation during current lockdown ;) Such tool would be interesting to investigate quality issues beside warnings from osmose as well in a few months All the best François Le lun. 20 avr. 2020 à 00:40, Christine Karch a écrit : > Chapeau and thank you for that interesting work and the documentation! > > Am 20.04.20 um 00:25 schrieb François Lacombe: > > Hi all, > > > > This link to look back at 10 years of mapping of French power > > transmission network > > https://www.openstreetmap.org/user/InfosReseaux/diary/392777 > > > > OSM demonstrates a large potential to improve official opendata and > > bring valuable data back to operators. > > Official opendata brings real situations inspiring our tagging model. > > This article was originally posted in French on OSM France website last > > week. > > Find dedicated render on OpenInfraMap : > > https://openinframap.org/#5.64/46.723/2.944 > > > > Hope to see this continuing in coming years. Thank you all to make this > > possible :) > > > > > > Best regards > > > > François > > > > ___ > > talk mailing list > > talk@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk > > > > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Fwd: Re[2]: Tag:manhole=telecom
Given problem is you argue with pictures showing what is under the cap. On the tag page picture - and on the ground - we can't say what is under and if a man can't get down a ladder into a room. I think all this stuff would require a formal proposal to discuss about vocabulary and have opinions of several people. We need standard definitions more than legal actually. All the best Le lun. 20 avr. 2020 à 01:02, <80hnhtv4a...@bk.ru> a écrit : > I am trying to say the tag page is wrong, > https://wiki.openstreetmap.org/wiki/Tag:manhole=telecom > the picture is a fiber optics splice enclosure not a manhole > > https://www.multicominc.com/product/pencell-pem-2436-24x36x24-buried-cable-enclosure/ > https://www.thefoa.org/tech/ref/install/Microtrenching/Pages/25.html > https://www.thefoa.org/tech/ref/appln/Prefab-underground.jpg > > this is a fiber splice manhole, > > https://www.jensenprecast.com/AT-T-Northern-California-a840/Telecom-Utility-Structures/Manholes-p14890/AT-T-4-x4-x4-fiber-optic-Intercept-Manhole-Page-1-of-2-d2315.pdf > > can we change the picture or put both on the same page with the legal > industry names. > https://www.lexico.com/en/definition/manhole > ( a man goes into the hole) [manhole] > > > > Sunday, April 19, 2020 5:02 PM -05:00 from François Lacombe < > fl.infosrese...@gmail.com>: > To me, manhole applies in the two situations. > We should make a distinction between the "cap" visible from the surface > and the facility underground. > Same shape of "cap" (I call it the manhole actually) can hide really > different kind of stuff underground you won't be able to define without > removing the cap. > In OSM, most mappers will only be able to describe what is visible on > surface. So this distinction would really be valuable. > When I look for "cable manhole" in google, I see both pavement and road > manholes. > Then I found this : > https://www.archiexpo.com/prod/dakota-group/product-150519-1693688.html > The body below surface, buried underground would be called a "cable room". > All the best > François > > Le dim. 19 avr. 2020 à 23:14, 80hnhtv4agou--- via talk < > talk@openstreetmap.org > > a écrit : > > this is an enclosure just put in the ground, level 3 fiber. > > https://s3-eu-west-1.amazonaws.com/mapillary.private.images/4KIBU1qe2CfjtcKtPHegeg/uploaded.jpg?AWSAccessKeyId=AKIAR47SN3BMII5SHG7V=1587328637=8%2FzNiW16zbU9FjWy0JD17cNwIns%3D > https://www.thefoa.org/tech/ref/install/Microtrenching/Pages/25.html > > this is a manhole, ameritech, a t & t. > > https://s3-eu-west-1.amazonaws.com/mapillary.private.images/dSk9MhzCx0L0AAFzD-WqYQ/uploaded.jpg?AWSAccessKeyId=AKIAR47SN3BMII5SHG7V=1587329086=o%2F0CqAKQC1ltl0F2vCqXVIecRP4%3D > > > https://www.jensenprecast.com/AT-T-Northern-California-a840/Telecom-Utility-Structures/Manholes-p14890/AT-T-4-x4-x4-fiber-optic-Intercept-Manhole-Page-1-of-2-d2315.pdf > > > Sunday, April 19, 2020 3:06 PM -05:00 from Tom Pfeifer < > t.pfei...@computer.org>: > Dear 80hnhtv4agou, > As OpenStreetMap is a worldwide project, we have to agree on a tagging > scheme for an object that > is worldwide comprehensible. > We prefer to use the same tag for the same kind of thing. > Thus we prefer not to introduce synonyms or regional variations. > To make a feature be found more easily, "related terms" can be added in > the wiki. > In the particular case, some friendly colleague has already added ‹buried > cable enclosure› > to the manhole=telecom wiki page. > Kind regards > Tom > > On 19.04.2020 17:20, 80hnhtv4agou--- via talk wrote: > > https://wiki.openstreetmap.org/wiki/Tag:manhole=telecom > > in the united states this is not what it is called, so it was hard for > me to find to use. > > can the name be changed. > > > https://www.multicominc.com/product/pencell-pem-2436-24x36x24-buried-cable-enclosure/ > > to what it is ? > ___ > > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] New diary: 10 years of French power transmission network mapping
Hi all, This link to look back at 10 years of mapping of French power transmission network https://www.openstreetmap.org/user/InfosReseaux/diary/392777 OSM demonstrates a large potential to improve official opendata and bring valuable data back to operators. Official opendata brings real situations inspiring our tagging model. This article was originally posted in French on OSM France website last week. Find dedicated render on OpenInfraMap : https://openinframap.org/#5.64/46.723/2.944 Hope to see this continuing in coming years. Thank you all to make this possible :) Best regards François ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Fwd: Re[2]: Tag:manhole=telecom
To me, manhole applies in the two situations. We should make a distinction between the "cap" visible from the surface and the facility underground. Same shape of "cap" (I call it the manhole actually) can hide really different kind of stuff underground you won't be able to define without removing the cap. In OSM, most mappers will only be able to describe what is visible on surface. So this distinction would really be valuable. When I look for "cable manhole" in google, I see both pavement and road manholes. Then I found this : https://www.archiexpo.com/prod/dakota-group/product-150519-1693688.html The body below surface, buried underground would be called a "cable room". All the best François Le dim. 19 avr. 2020 à 23:14, 80hnhtv4agou--- via talk < talk@openstreetmap.org> a écrit : > this is an enclosure just put in the ground, level 3 fiber. > > https://s3-eu-west-1.amazonaws.com/mapillary.private.images/4KIBU1qe2CfjtcKtPHegeg/uploaded.jpg?AWSAccessKeyId=AKIAR47SN3BMII5SHG7V=1587328637=8%2FzNiW16zbU9FjWy0JD17cNwIns%3D > https://www.thefoa.org/tech/ref/install/Microtrenching/Pages/25.html > > this is a manhole, ameritech, a t & t. > > https://s3-eu-west-1.amazonaws.com/mapillary.private.images/dSk9MhzCx0L0AAFzD-WqYQ/uploaded.jpg?AWSAccessKeyId=AKIAR47SN3BMII5SHG7V=1587329086=o%2F0CqAKQC1ltl0F2vCqXVIecRP4%3D > > > https://www.jensenprecast.com/AT-T-Northern-California-a840/Telecom-Utility-Structures/Manholes-p14890/AT-T-4-x4-x4-fiber-optic-Intercept-Manhole-Page-1-of-2-d2315.pdf > > > Sunday, April 19, 2020 3:06 PM -05:00 from Tom Pfeifer < > t.pfei...@computer.org>: > > Dear 80hnhtv4agou, > > As OpenStreetMap is a worldwide project, we have to agree on a tagging > scheme for an object that > is worldwide comprehensible. > > We prefer to use the same tag for the same kind of thing. > > Thus we prefer not to introduce synonyms or regional variations. > > To make a feature be found more easily, "related terms" can be added in > the wiki. > > In the particular case, some friendly colleague has already added ‹buried > cable enclosure› > to the manhole=telecom wiki page. > > Kind regards > Tom > > On 19.04.2020 17:20, 80hnhtv4agou--- via talk wrote: > > https://wiki.openstreetmap.org/wiki/Tag:manhole=telecom > > > > in the united states this is not what it is called, so it was hard for > me to find to use. > > > > can the name be changed. > > > > > https://www.multicominc.com/product/pencell-pem-2436-24x36x24-buried-cable-enclosure/ > > > > to what it is ? > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > > > > > > > > -- > > > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tag:manhole=telecom
Hi To me there are two separate concepts : * The enclosure : the underground chamber hosting several equipment including cable splices * The manhole : The way technicians get into the enclosure. For smaller ones, the manhole has the same dimension than enclosure but there are bigger ones where human can get into. Then, what do you want to map? All the best François Le dim. 19 avr. 2020 à 17:23, 80hnhtv4agou--- via talk < talk@openstreetmap.org> a écrit : > https://wiki.openstreetmap.org/wiki/Tag:manhole=telecom > > in the united states this is not what it is called, so it was hard for me > to find to use. > > can the name be changed. > > > https://www.multicominc.com/product/pencell-pem-2436-24x36x24-buried-cable-enclosure/ > > to what it is ? > > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] [ca reste ouvert] Services publics ouverts sans accès pour le public
Je me suis posé la question récemment. A mon avis ça dépend surtout de ce qu'on entend par "openings hours" : s'agit-il d'ouverture physique ou des heures travaillées, ou des créneaux de standard téléphonique ? Si on considère que l'on doit ne cartographier que ce qui est vérifiable sur le terrain, je pense qu'il vaut mieux ne renseigner que les horaires d'ouvertures des _lieux accessibles physiquement à __tout public_ (mais rajouter les contacts tél, mél, site web). F Le 19/04/2020 à 11:00, Vincent Bergeot a écrit : Le 19/04/2020 à 09:53, Yves P. a écrit : J'ai donc commencé à décliner quelques casaccess:covid19=no pour les services publics, avec les opening_hours:covid19=open, same XXX. Est-ce que cela vous semble "cohérent" ? si oui je mets à jour le wiki en conséquence. Si non je sis curieux de votre retour ! C'est cohérent avec le point de vue des partisans de ce tag, mais pas convaincant. La discussion sur la manière de décrire ces cas ne me semble pas close ;) ok, je n'avais pas suivi entièrement l'autre discussion. alors dans un premier temps, ma question est surtout : il existe de nombreux cas (commerces, banques, ...) qui ont des horaires spécifiques durant le confinement (donc opening_hours:covid19 *n'est pas* off) mais dont l'accès ne se fait pas sur le lieu car celui ci est fermé sauf éventuellement après "Rendez-vous, commande, ..." (donc si j'ai tout suivi, access:covid19=no, private, restricted *encore à préciser*). Est-ce qu'il vous semble cohérent d'ajouter la questions des services aux publics tels que les mairies et offices de tourisme, qui sont pour la plupart dans la même situation (horaires spécifiques durant le confinement / services rendus par téléphone et mail mais lieu souvent inaccessible physiquement) ? à plus -- Vincent Bergeot ___ 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] Les horaires adaptés sur Qwant Maps
Merci pour les précisions ! F Le 10 avril 2020 08:21:51 GMT+02:00, PanierAvide a écrit : >Bonjour, > >Ça reste ouvert n'est pas qu'un canal de contribution, on réalise >également un travail d'augmentation/agrégation au-delà d'OSM. Un >exemple : > >https://www.openstreetmap.org/node/6597224025 : pas d'infos covid19 > >https://www.qwant.com/maps/place/osm:node:6597224025@Carrefour_Market_G%C3%A9vez%C3%A9#map=18.25/48.2203417/-1.7854300 > >: même objet avec des infos covid19 > >Ces infos ne viennent pas d'OSM, mais de la liste des enseignes et leur > >état d'ouverture ici : https://github.com/PanierAvide/Covid_enseignes > >Sur laquelle on réalise une jointure par identifiant wikidata ou nom de > >marque. On rajoute donc des informations supplémentaires à >OpenStreetMap. Les données de sortie sont en ODbL, source OpenStreetMap > >+ Ça reste ouvert. À noter que Qwant précise quelques lignes plus bas >que les données viennent d'OSM, on a donc bien la double mention. Après > >de notre côté on a pas la main sur la façon dont l'équipe de Qwant >présente les infos. > >Cordialement, > >Adrien P. > >Le 09/04/2020 à 23:09, François Boucault a écrit : >> >> Bonjour à tous, >> >> Simplement pour vous signaler que Qwant maps affiche les horaires >> adaptés durant le confinement (exemple >> ><https://www.qwant.com/maps/place/osm:node:255851907@Super_U#map=16.61/42.9229055/1.8362474>), > >> un bel exemple d'intégration selon moi. >> >> Petit détail : il est écrit "Source : caresteouvert.fr", mais en fait > >> la source reste OSM, non ? Le site caresteouvert n'est pas la source, > >> mais simplement un canal de contribution... >> >> Il serait moins faux, et plus engageant, d'écrire, par exemple : >> "Aidez à renseigner les horaires d'ouvertures durant le confinement : > >> caresteouvert.fr". >> >> Comme ça l'initiative est tout de même citée, et le visiteur >comprends >> qu'il s'agit d'un site web pour le moins "dynamique" (et non une >> source rigide établie par une administration). >> >> Bien à vous, >> >> François >> >> >> ___ >> 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] Les horaires adaptés sur Qwant Maps
Bonjour à tous, Simplement pour vous signaler que Qwant maps affiche les horaires adaptés durant le confinement (exemple <https://www.qwant.com/maps/place/osm:node:255851907@Super_U#map=16.61/42.9229055/1.8362474>), un bel exemple d'intégration selon moi. Petit détail : il est écrit "Source : caresteouvert.fr", mais en fait la source reste OSM, non ? Le site caresteouvert n'est pas la source, mais simplement un canal de contribution... Il serait moins faux, et plus engageant, d'écrire, par exemple : "Aidez à renseigner les horaires d'ouvertures durant le confinement : caresteouvert.fr". Comme ça l'initiative est tout de même citée, et le visiteur comprends qu'il s'agit d'un site web pour le moins "dynamique" (et non une source rigide établie par une administration). Bien à vous, François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Edition mécanique] ref:FR:CORRIDOR -> ref:EU:EVSE
Bonsoir Marc Aucune objection, excellente idée ! François Le mer. 1 avr. 2020 à 11:49, Marc M. a écrit : > Bonjour, > > un contributeur a dans le passé utilisé le tag ref:FR:CORRIDOR > pour renseigner la référence européenne des bornes du réseau corridor > le nouveau tag "adopté" étant ref:EU:EVSE, je propose de les modifier > en masse > > Avis ? Objection ? > > Cordialement, > Marc > > ___ > 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] Ajout de brand:wikidata sur les enseignes
Bonsoir Yves Le sam. 28 mars 2020 à 09:46, Yves P. a écrit : > iD affiche le libellé automatiquement > D'accord, bonne démarche Incomplète à mon sens : sans l'éditeur tu ne peux plus lire les données OSM, attention ça ne convaincra pas tout le monde. > > Le parti pris d'OSM est d'avoir des valeurs lisibles par l'homme il me > semble? > Et puis la question qui se pose est d'avoir deux fois la même information > sur les objets. > > non en ne mettant pas le tag brand mais uniquement brand:wikidata ;) > Je pense que ce n'est pas si simple qu'en faisant une liaison directe avec Wikidata pour les raisons que je donne la dessous. > > Peux-tu me citer un exemple d'homonyme s'il te plait? > > Je me souvenais de « Mac Donald » et « McDonald’s » : > https://wiki.openstreetmap.org/wiki/What%27s_the_problem_with_mechanical_edits%3F#Potential_for_bad_judgement > <https://wiki.openstreetmap.org/wiki/What's_the_problem_with_mechanical_edits?#Potential_for_bad_judgement> > Il s’avère qu’il ne s’agit pas du tag brand mais name… > … on pourrait imaginer qu’il existe réellement la marque « Mac > Donald »mais effectivement l’orthographe est différente :) > Oui je pense ainsi qu'on aura très peu de problèmes de ce genre. La réglementation sur les marques et la propriétés intellectuelle nous facilitant bien la tâche sur ce sujet précis. > Non parce que wikidata ne va pas te dire sur quelle géométrie peut-être > utilisé le tag, ou à quelles règles de validation il va répondre. > Les DataItem c'est la description sémantique propre à OSM. > > Je comprends, mais j’ai l’impression qu’on mélange 2 choses. > > Dire que la clé *brand* ne se met que sur les > *amenity=shop, tourism=hotel* ou *amenity=fuel* par exemple est une chose. > Dire que la clé *brand* n’a que certaines valeurs « autorisées » en est > une autre, car lister toutes les marques reviendrait à dupliquer wikidata ? > > Certes, on pourrait dire que *brand=Esso* ne se met qu’avec *amenity=fuel* > . > Il y a environ 100 propriétés différentes de gestion de la sémantique dans les DataItems Il ne s'agit pas que de donner les combinaisons, mais aussi les règles de validation, d'édition, d'illustration, de description et j'en passe. Oui à chaque fois que j'ai eu à identifier une entreprise, j'ai du définir une "valeur OSM", je n'ai pour autant pas dupliqué les forces de wikidata. Chose que je me garderais bien d'ailleurs de déléguer en dehors de OSM. Wikidata aurait raison de nous refuser l'ajout de propriétés strictement dédiées à OSM. A l'inverse ce serait très généreux de leur part d'accépter d'en intégrer *certaines* On aura toujours besoin d'un système pour décrire des choses qui concernent OSM seulement, donc toujours besoin de définir une valeur lisible, l'identifiant wikidata n'étant qu'une propriété de plus sur le dataitem. > ça rajoute une surcouche de complexité. Et il faut que le projet se fasse connaître, fasse l’ « unanimité »… De quoi part-on aujourd'hui pour gérer nos tags ? Un wiki traduit en 126 langues avec une synchronisation bien compliquée à gérer entre les spécificités locales et l'ascendance de l'anglais pertinente dans certains cas. On peut aussi se dire que ce sera plus simple avec de la structure. OSM a ajouté de la complexité par rapport aux cartes IGN papier. On est plus heureux aujourd'hui je crois :) Bonne soirée François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Les horaires "hors confinement"
> Oui l'interface est problématique. > Déjà tu ne récupères pas les horaires existants, donc risque d'écraser > les deux données. > > "Je ne sais pas" => préciser que ça laisse les horaires existants (je > suppose que ça ne les supprime pas). > > Je n'ai pas osé aller jusqu'à la fin. > > Mais on dit jour par jour si c'est ouvert (covid) puis éventuellement > non covid. > > Si tu mets une fois par erreur "même" tu vas potentiellement écraser les > horaires non covid par des horaires incomplets. > > Si on met les heures et non seulement les jours, YoHours est beaucoup > plus rapide à utiliser. > > Je préfère voir la chaîne et pouvoir utiliser YoHours pour les modifier. > > Un lien vers iD/JOSM serait pertinent. J'ai oublié de préciser que cette option n'est affiché que lorsqu'il n'y a pas d'horaires "normaux". Est ce que cela change tes impressions ? Clairement, sur mon PC, je préfère rentrer directement les horaires au format OSM, mais je ne dois pas être normal. Noté l'idée de iD/JOSM. François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Les horaires "hors confinement" [était : Re: [Ça reste ouvert][Pharmacies][URPS]]
> > Merci de cette suggestion. Nous sommes en train de travailler a un > > nouveau formulaire de contribution qui permettre de directement saisir > > les horaires d'ouverture de confinement et, si les horaires "normaux" > > ne sont pas remplis, de dire que ce sont les mêmes. > > euh, je pense qu'il est préférable d'éviter d'écrire dans opening_hours (si > vide) des horaires de opening_hours:covid19. > > Cela va introduire une donnée fausse ! > > Si il n'y a pas d'opening_hours : > > * soient ceux sont les horaires hors-confinement qui sont ajoutés > * soient il n'y a pas d'horaires ajoutés > > > J'ai conscience que ce n'est pas tout a fait la même chose que ce que > > tu suggère, mais cela pourrait augmenter le nombre d'opening_hours. > > Si on ajoute des opening_hours faux cela n'a pas d'intérêt je pense, cela > demandera de revérifier tous les opening_hours qui étaient vide avant qu'un > opening_hours:covid19 ait été ajouté et de vérifier cet opening_hours Merci de ce retour. Tu a vu l'interface ? C'est une option une fois qu'ils ont saisi les horaires de confinement. Si tu pense que ce n'est pas assez clair ou trop dangereux, on supprime. François > > à plus > > > > > > > > François > > > > On Mon, Mar 30, 2020 at 03:45:07PM +0200, Georges Dutreix via Talk-fr wrote: > > > Justement, le côté très positif est qu'on voit arriver énormément de > > > contributions #covid19 #caresteouvert, motivées par la participation à > > > l'info "confinement". > > > Ma suggestion est d'inciter ces contributeurs occasionnels à fournir aussi > > > les infos d'ouvertures habituelles, de contect, etc, en ajoutant un > > > message > > > sur le site https://www.caresteouvert.fr/ > > > > > > > > > > > > Le 30/03/2020 à 12:17, PanierAvide a écrit : > > > > En plus, les contributions portent sur des sujets qu'on a du mal à > > > > suivre/maintenir côté contributeurs réguliers OSM : > > > > > > > > - commerces fermés définitivement de longue date > > > > - horaires d'ouvertures de confinement qui sont les mêmes > > > > qu'habituellement > > > > - infos de contact / site web / téléphone > > > > > > > > Si on voyait un peu le positif plutôt que de regretter l'utopie, pour > > > > avancer de manière constructive ? :-) > > > ___ > > > 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 > > > -- > Vincent Bergeot > > ___ > 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] [Ça reste ouvert][Pharmacies][URPS]
Bonjour Georges, Merci de cette suggestion. Nous sommes en train de travailler a un nouveau formulaire de contribution qui permettre de directement saisir les horaires d'ouverture de confinement et, si les horaires "normaux" ne sont pas remplis, de dire que ce sont les mêmes. J'ai conscience que ce n'est pas tout a fait la même chose que ce que tu suggère, mais cela pourrait augmenter le nombre d'opening_hours. François On Mon, Mar 30, 2020 at 03:45:07PM +0200, Georges Dutreix via Talk-fr wrote: > Justement, le côté très positif est qu'on voit arriver énormément de > contributions #covid19 #caresteouvert, motivées par la participation à > l'info "confinement". > Ma suggestion est d'inciter ces contributeurs occasionnels à fournir aussi > les infos d'ouvertures habituelles, de contect, etc, en ajoutant un message > sur le site https://www.caresteouvert.fr/ > > > > Le 30/03/2020 à 12:17, PanierAvide a écrit : > > En plus, les contributions portent sur des sujets qu'on a du mal à > > suivre/maintenir côté contributeurs réguliers OSM : > > > > - commerces fermés définitivement de longue date > > - horaires d'ouvertures de confinement qui sont les mêmes > > qu'habituellement > > - infos de contact / site web / téléphone > > > > Si on voyait un peu le positif plutôt que de regretter l'utopie, pour > > avancer de manière constructive ? :-) > > ___ > 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] CaResteOuvert.fr - on fait le point
Bonjour, La prise en compte des modifications dans OSM vers la carte est en place. Il y a un lag de réplication en ce moment, mais en temps normal c'est max 1 heure. On va monitorer ça pour savoir si on peut réduire ce délai. François On Thu, Mar 26, 2020 at 10:07:07PM +0100, Florian LAINEZ wrote: > Bonjour à tous, > Beaucoup de discussions se sont échangées ces jours-ci en lien avec le > projet http://caresteouvert.fr et il nous semble qu'il est temps de faire > le point. > Je vais détailler mon propos, dont le résumé en une phrase est : *MERCI* > pour vos très nombreuses contributions afin de répondre à la crise > sanitaire #Covid19; nous sommes fiers de faire partie de cette communauté > qui sait se mobiliser lorsqu'il y en a besoin; nous sommes sincèrement > désolés pour l'avalanche de notes ces derniers temps qui est dû à des choix > techniques du site Internet justifiés par l'urgence; nous sollicitons > humblement votre aide pour traiter ces notes au plus vite; nous promettons > que ce flot continue de notes ne durera pas longtemps; continuons à > contribuer ensemble et à se coordonner sur la page > https://wiki.openstreetmap.org/wiki/France/Covid-19 > > -- > Au début du confinement, François de Metz et moi-même > avons cartographié les lieux restés ouverts dans notre commune et avons > créé une visualisation sur le site http://osmontrouge.fr > Notre initiative a été partagée par la mairie de Montrouge, à la suite de > quoi nous avons reçu une avalanche d'emails de citoyens désireux de nous > préciser les conditions d'ouverte des différents lieux de la ville. > > Constatant le succès de ce premier site et face à l'urgence liée à la crise > sanitaire, il nous a semblé évident de mettre nos compétences au service de > la communauté. > Avec Adrien Pavie qui nous a rejoint, nous avons > mis entre parenthèse nos projets professionnels respectifs pour nous > concentrer à 100% sur le projet : développer en urgence la carte > collaborative des lieux ouverts durant le confinement. > > Nous proposons un site mobile/desktop à la couverture Nationale (incluant > les territoires d'outre-mer) dont l’objectif principal est de contribuer à > limiter les sorties hors domicile de la population et ainsi retarder la > propagation du virus Covid19. Informer au mieux la population des lieux > ouverts autour de leur lieu de confinement nous paraît une manière > pertinente de répondre à la situation. Un citoyen mieux informé peut être > amené à réduire le nombre mais aussi la distance et le temps de sorties > extra-domicile. > > Le résultat c'est "Ça reste ouvert". Le site http://caresteouvert.fr est un > outil simple, *utilisable par un humain*, pour partager des informations > vraiment utiles durant cette crise. > Cette carte collaborative permet à chacun de partager simplement les lieux > ouverts ou fermés dans toute la France, mais aussi les horaires d'ouverture > spécifiques au confinement. > Les données affichées proviennent toutes d'OpenStreetMap : le fond de carte > et les lieux cliquables sur la carte. Nous utilisons en particulier 2 > nouveaux tags créés pour l'occasion : opening_hours:covid19 > <https://wiki.openstreetmap.org/wiki/FR:Key:opening_hours:covid19>=* et son > petit frère note:covid19=* > > L'outil a été développé en urgence : ces derniers jours ont été extrêmement > intense pour notre équipe. Vous avez d'ailleurs été très nombreux à nous > proposer une aide spontanément; Merci à Vincent de Château Thierry pour son > aide technique, Vincent Bergeot pour les tests utilisateur ... et à tous > les autres. Désolé de ne pas pouvoir citer tout le monde mais MERCI de > répondre présent pour répondre à ce challenge collectif. Cette réalisation > est un vrai travail de groupe : l'hébergeur Scalingo nous a mis à dispo des > serveurs gracieusement, les amis de Jawg Maps ont aussi fournit leur infra > technique gracieusement, un graphiste bénévole nous a fait un logo ... mais > surtout de nombreux contributeurs OpenStreetMap ont contribué à créer les > données. > En moins de 24h nous sommes passé de 200 à 500 occurrences pour le tag > opening_hours:covid19 > <https://wiki.openstreetmap.org/wiki/FR:Key:opening_hours:covid19>=* (cf. > taginfo > <https://taginfo.openstreetmap.org/keys/?key=opening_hours%3Acovid19>). > > Le projet a eu une audience démesurée bien trop rapidement : de nombreux > articles de presse ont été écrits dont celui sur BFM TV : > https://www.bfmtv.com/tech/coronavirus-comment-savoir-quels-commerces-restent-ouverts-1882596.html > Le site a tenu la charge après la publication d'un article de BFM TV. C'est > déjà un exploit en soi ! (bravo les devs) > La conséquence a été un afflux massif de contributions vers un outil > bricolé e
Re: [OSM-talk-fr] Ajout de brand:wikidata sur les enseignes
Le jeu. 26 mars 2020 à 18:10, Yves P. a écrit : > > Je suggère de ne taguer les objets OSM qu'avec brand=* > Le problème, c’est qu’il y a des homonymes… > C’est pour ça qu’il existe wikidata ;) > Oui mais les identifiants wikidata ne sont pas lisibles. Le parti pris d'OSM est d'avoir des valeurs lisibles par l'homme il me semble? Et puis la question qui se pose est d'avoir deux fois la même information sur les objets. Peux-tu me citer un exemple d'homonyme s'il te plait? > > Et dans le DataItem relatif à une marque donné > brand=Harley-Davidson -> https://wiki.openstreetmap.org/wiki/Item:Q5371 > > Ok, mais ça revient à recréer wikidata ? > Non parce que wikidata ne va pas te dire sur quelle géométrie peut-être utilisé le tag, ou à quelles règles de validation il va répondre. Les DataItem c'est la description sémantique propre à OSM. > > Sinon on ne va faire que ça et cette liaison va être modifiée en > permanence en plus d'être difficile à maintenir partout. > +1 > > > Cela donne un cas d'usage positif supplémentaire aux dataitems > OK. Mais en pratique, on fait comment dans iD, JOSM et n’importe quel > outil OSM pour passer d’un tag à un DataItem ? > Tu n'aurais pas à le faire justement si tout se passe dans le DataItem. Les éditeurs vont toutefois intégrer progressivement cette base de données qui rencontre une certaine réticence jusque là J'avoue ne pas comprendre pourquoi. Bonne soirée François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Ça reste ouvert : on a besoin de vous !
Bonjour Martin, Merci pour les encouragements ! > Cela peut être une belle porte d'entrée sur OSM, peut-être en mettant une > partie des informations visible sur la page "à propos" dès la page d'accueil > ? (une pop up à la première connexion ?) > > > Dans le même ordre d'idée, y aurait-il quelque chose à faire autour de la > correction d'informations erronées/manquantes hors Covid ? (j'ai fait > quelques corrections sur Chambéry ce matin et il y a pas mal de commerces > pas à jour ou sans horaires pré-covid - honte à nous :-D - ça pourrait être > l'occasion de les repérer en ajoutant un format de notes sur les corrections > de nom et d'horaires normaux, en les affichant) C'est un sujet en réflexion, mais pour le moment le plan est de permettre la contribution directement sur le site pour le tag opening_hours:covid19. > Enfin, je pense qu'il y a plein d'idées que vous pourriez rajouter : p. ex. > le calculateur de distance d'1km (vu que l'outil déjà partagé ici avait > plein de traqueurs malvenus), voire un outil calculant certaines > infrastructures les plus proches si >1km (pourrait servir de justificatif, > "je n'ai pas de pharmacie plus proche, la preuve" !), l'idée qui vient > d'être émise sur les centres de santé, etc. etc. Ça dépasse largement mes > compétences techniques par contre, je ne pourrais pas vous aider ;-) On va certainement rajouter le cercle de 1km. Pour le reste c'est vrai qu'on est parti sur un format carte classique, mais on pourrais lister seulement les commerces autour d'un point. François > > Encore bravo en tout cas ! > > Martin > > > On 26/03/2020 13:00, talk-fr-requ...@openstreetmap.org wrote: > > Subject: > > Re: [OSM-talk-fr] Ça reste ouvert : on a besoin de vous ! > > From: > > François de Metz > > Date: > > 26/03/2020, 12:59 > > > > To: > > Discussions sur OSM en français > > > > > > Bonjour, > > > > Merci à toute les personnes qui contribuent et ferment les notes. > > > > La mise à jour automatique des données OpenStreetMap n'est pas encore > > effective, donc ne vous étonnez pas que vos contributions ne soient > > pas encore affichées. Cela arrive très vite. > > > > François > ___ > 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] Ajout de brand:wikidata sur les enseignes
Bonjour Yves, Le jeu. 26 mars 2020 à 13:29, Yves P. a écrit : > Data_items c’est bien le wikidata interne à OSM pour décrire les tags ? > Il ne sert pas à décrire les données ?? > C'est bien ça. brand y est par exemple décrit https://wiki.openstreetmap.org/wiki/Item:Q98 On y apprend que brand=* correspond au concept wikidata Q431289 <https://www.wikidata.org/wiki/Q431289>. Il ne concerne que les tags, aucune donnée OSM n'y est décrite. > Si je comprends bien, tu suggères de gérer *brand:wikidata* avec les data > items ? > Ou seulement de ne mettre que ce tag et plus *brand*, ni *brand:wikipedia* (et > de continuer de gérer les noms avec wikidata) ? > Je suggère de ne taguer les objets OSM qu'avec brand=* Et dans le DataItem relatif à une marque donné, d'y faire un lien unique avec le concept Wikidata correspondant à la marque. Idem por operator=* en fait. Sinon on ne va faire que ça et cette liaison va être modifiée en permanence en plus d'être difficile à maintenir partout. Cela donne un cas d'usage positif supplémentaire aux dataitems Bonne après midi, François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Ça reste ouvert : on a besoin de vous !
Bonjour, Merci à toute les personnes qui contribuent et ferment les notes. La mise à jour automatique des données OpenStreetMap n'est pas encore effective, donc ne vous étonnez pas que vos contributions ne soient pas encore affichées. Cela arrive très vite. François On Wed, Mar 25, 2020 at 07:44:53PM +0100, PanierAvide wrote: > Bonjour à tous, > > Suite aux échanges divers sur l'épidémie de Covid-19 et comment OSM pouvait > proposer une information de qualité sur le sujet, nous avons enfin publié > "Ça reste ouvert", la carte des lieux ouverts pendant le confinement : > caresteouvert.fr > > La carte propose aux visiteurs d'ajouter des infos dans leur commune : cela > créé une note automatiquement dans OSM, avec les informations nécessaires. > Ces notes sont à passer en revue pour intégrer les tags sur les lieux > concernés. En particulier : > > - opening_hours:covid19 : horaires d'ouvertures pendant le confinement (ou > off si fermé) > - note:covid19 : si des infos supplémentaires sont données (livraison à > domicile, mesures sanitaires...) > > Pour vous aider à passer en revue les notes, il y a l'outil NotesReview : > > https://ent8r.github.io/NotesReview/?query=%23caresteouvert=1=2020-03-23=6%2F47.3691%2F1.0107 > > Et la page de coordination du projet est ici : > https://wiki.openstreetmap.org/wiki/France/Covid-19 > > Nous comptons sur la communauté pour intégrer ces infos et faire d'OSM la > base de données de référence pendant le confinement (et même après) ! > > Cordialement, > > -- > Adrien P. > > > ___ > 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] Ajout de brand:wikidata sur les enseignes
Bonjour Noémie, Je sais que c'est un sujet depuis un moment, je vois aussi des operator:wikidata fleurir un peu partout et l'effort pour les ajouter est conséquent. Mais va-t-on devoir doubler tous les tags à chaque fois qu'une référence à un nom propre est fait sur OSM? N'est-ce pas un problème qui devrait être traité via nos propres Data Item, mettant en correspondance la valeur choisie entre nous, qui reste lisible tant par l'humain que la machine, et la valeur wikidata? https://wiki.openstreetmap.org/wiki/Data_items Parce que là on créé des version 2, 3, 4 pour n'apporter aucune information supplémentaire My 2 cts François Le jeu. 26 mars 2020 à 10:08, Noémie Lehuby via Talk-fr < talk-fr@openstreetmap.org> a écrit : > Hello, > > Pour avancer sur l'ajout de tags brand et brand:wikidata sur les > enseignes, je vous propose ce petit challenge Maproulette : > https://maproulette.org/browse/challenges/13011 > > Il traite uniquement des banques, pour commencer. > > ID est un éditeur particulièrement efficace pour ce genre de tâche car > il arrive à deviner les bons tags à ajouter dans pas mal de cas ;) > > -- > Noémie Lehuby > > Le 26/03/2020 à 09:26, Yves P. a écrit : > > Une contribution intéressante est également de rajouter le tag > > brand:wikidata sur les boutiques qui n'en ont pas. > > ___ > 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] Ça reste ouvert : on a besoin de vous !
Bonjour à tous, Une contribution intéressante est également de rajouter le tag brand:wikidata sur les boutiques qui n'en ont pas. Cela facilite la fusion avec https://github.com/PanierAvide/Covid_enseignes. François On Wed, Mar 25, 2020 at 07:44:53PM +0100, PanierAvide wrote: > Bonjour à tous, > > Suite aux échanges divers sur l'épidémie de Covid-19 et comment OSM pouvait > proposer une information de qualité sur le sujet, nous avons enfin publié > "Ça reste ouvert", la carte des lieux ouverts pendant le confinement : > caresteouvert.fr > > La carte propose aux visiteurs d'ajouter des infos dans leur commune : cela > créé une note automatiquement dans OSM, avec les informations nécessaires. > Ces notes sont à passer en revue pour intégrer les tags sur les lieux > concernés. En particulier : > > - opening_hours:covid19 : horaires d'ouvertures pendant le confinement (ou > off si fermé) > - note:covid19 : si des infos supplémentaires sont données (livraison à > domicile, mesures sanitaires...) > > Pour vous aider à passer en revue les notes, il y a l'outil NotesReview : > > https://ent8r.github.io/NotesReview/?query=%23caresteouvert=1=2020-03-23=6%2F47.3691%2F1.0107 > > Et la page de coordination du projet est ici : > https://wiki.openstreetmap.org/wiki/France/Covid-19 > > Nous comptons sur la communauté pour intégrer ces infos et faire d'OSM la > base de données de référence pendant le confinement (et même après) ! > > Cordialement, > > -- > Adrien P. > > > ___ > 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] Processus de validation de tag
Merci Stuart pour le témoignage et bonjour à tous Au sujet des échanges parfois conséquents qui peuvent se tenir, voici le dernier cas en date pour moi, en cours en ce moment même J'attends d'avoir trouvé une solution à cette dizaine de points avant de communiquer plus largement sur le sujet des shadocks. https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Pumping_proposal Ça fait beaucoup de questions, d'arguments opposés, consolidés, etc... Si on ne peut pas poser ces discussions au moment d'une proposition, l'énergie nécessaire pour faire la pub de ces tags petit à petit sera encore plus conséquente de mon point de vue. Quitte parfois à devoir essuyer un peu de mauvaise foi en effet, particulièrement sur les usages existants : https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Pumping_proposal#Clarify_use_with_man_made.3Dwater_well On a déjà abouti à plusieurs modifications utiles sur ce qui était initialement proposé, c'est tant mieux. Bon dimanche François Le sam. 21 mars 2020 à 23:08, European Water Project < europeanwaterproj...@gmail.com> a écrit : > On Sat, Mar 21, 2020, 21:22 wrote: > >> Si l'objet ne porte que sur le site de réfugié, quel intérêt de l'espace >> de nommage ? >> > >>>>> un site de réfugié peut être un campement, un bâtiment, un village, > etc ! Le même node/way pourrait avoir un tag amenity ou tag place qui > décrit plus l'aspect physique. Dans ce cas peut-être un namespace de > refugee_site pour décrire l'aspect plutôt d'organisationel et humaine > pourrait avoir un sens. > >> >> > Le 21/03/2020 à 17:24, European Water Project - >> europeanwaterproj...@gmail.com a écrit : >> >> Bonjour, >> >> Désolé pour les fautes de français. >> >> Je viens de passer l’expérience moi même de faire voter un nouveau tag .. >> , et même si certaines personnes sont un peu cassantes et d'autres ne me >> semblaient pas être 100% sincères, je suis pleinement satisfait avec la >> finalité. Je voulais juste partager mon expérience de néophyte. >> >> Les premières propositions étaient rejetés, mais avec le recul pour des >> très bonnes raisons, et finalement les tags qui ont passés à la fin étaient >> proposés par quelqu'un d'autre. J'ai du arrêter le vote au milieu et >> "améliorer" ma proposition et recommencer une fois. Mais il me semble que >> le but doit être d'avoir des tags pour des données qui ont le mérite d’être >> dans la base de donnée d'OSM qui sont KISS mais aussi qui sont cohérent >> avec tout écosystème d'OSM (que je continue a découvrir). >> >> Je viens de lire la proposition pour la première fois .. (Je pense que >> nous avons tous un peu plus de temps en ce moment). >> >> Est-ce que vous avez réfléchi à l'idée de créer un namespace pour >> refugee_site ? Je ne trouve pas très KISS d'utiliser le tag >> place=refugee_site .. >> >> refugee_site = yes, formal, informal >> refugee_site:for = IDP, refugee_strict >> refugee_site:operator = UNHCR/Red Cross/ >> refugee_site:duration = permanent, temporary >> refugee_site:population = 500,000 >> . >> . >> etc. >> >> Bien cordialement, >> >> Stuart >> >> >> >> >> >> >> >> >> On Fri, 20 Mar 2020 at 23:39, François Lacombe >> wrote: >> >>> Le ven. 20 mars 2020 à 12:15, Florimond Berthoux < >>> florimond.berth...@gmail.com> a écrit : >>> >>>> Bonjour, >>>> >>>> Un autre point de vue des proposals (d'un néophyte): >>>> C'est 20 personnes (souvent les mêmes) sur une mailling list anglophone. >>>> Contre plus d'un million de contributeur et bien plus d'utilisateurs. >>>> >>>> Discuter du bon tag c'est bien, perdre son énergie pour faire passer un >>>> tag dans une moulinette administrative qui n'aura au final aucune force >>>> contraignante bof. >>>> >>> >>> Le sens n'est pas celui-là. >>> La proposition est l'occasion de poser les choses, expliquer et débattre >>> pour mettre toutes les chances de son côté que le tag soit utilisé. >>> Ce n'est pas un cerfa à remplir. >>> >>> >>>> Ma vision est plus doocratie : >>>> 1. réfléchir et chercher le bon tag >>>> 2. tagguer >>>> 3. discuter si pas sûr >>>> 4. changer si nécessaire >>>> 5. documenter sur le wiki >>>> un an plus tard >>>> 6. regarder si le tag à été réutiliser >>>> >>>> Et si tu veux que le tag soit plus utiliser tu peux essayer d'en faire >>>
Re: [OSM-talk-fr] Le trafic moyen c'est bien
Bonjour Phyks, Le sam. 21 mars 2020 à 13:13, Phyks a écrit : > >> Par contre ce qui m'intéresse et qui change peu dans le temps c'est le > >> trafic moyen. > >> Le trafic moyen est une grandeur physique mesurable et constant dans le > >> temps. > >> > > D'après ce qui est écrit au dessus je ne comprends pas ce point. > > Des événements imprévus et irrésistibles peuvent venir modifier le > trafic, > > comment la moyenne pourrait être constante ? > > De la même façon qu'en météo, nous avons des moyennes saisonnières. Il y > a potentiellement des écartements par rapport à ces valeurs, mais elles > représentent néanmoins une certaine grandeur constante dans le temps. > S'agit-il des moyennes ou des normales saisonnières ? Le climat est réputé variable sur le temps long (sauf en ce moment), pas le trafic Pour le routier, une grandeur qui me semblerait d’intérêt serait le trafic prévu, qui lui est normalement public puisque partie du cahier des charges du maître d'ouvrage. Dans nos pays, les normes routières prévoient certains équipements en fonction du trafic, de la vitesse, etc... François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Processus de validation de tag
Le ven. 20 mars 2020 à 12:15, Florimond Berthoux < florimond.berth...@gmail.com> a écrit : > Bonjour, > > Un autre point de vue des proposals (d'un néophyte): > C'est 20 personnes (souvent les mêmes) sur une mailling list anglophone. > Contre plus d'un million de contributeur et bien plus d'utilisateurs. > > Discuter du bon tag c'est bien, perdre son énergie pour faire passer un > tag dans une moulinette administrative qui n'aura au final aucune force > contraignante bof. > Le sens n'est pas celui-là. La proposition est l'occasion de poser les choses, expliquer et débattre pour mettre toutes les chances de son côté que le tag soit utilisé. Ce n'est pas un cerfa à remplir. > Ma vision est plus doocratie : > 1. réfléchir et chercher le bon tag > 2. tagguer > 3. discuter si pas sûr > 4. changer si nécessaire > 5. documenter sur le wiki > un an plus tard > 6. regarder si le tag à été réutiliser > > Et si tu veux que le tag soit plus utiliser tu peux essayer d'en faire la > pub. > OSM est un formidable endroit pour expérimenter et il ne faut surtout jamais perdre ce côté là, si différenciant par rapport à tout ce qui peut exister à côté. Il y a néanmoins un besoin de structuration pour progresser vers une plateforme plus mature. Il en coûte beaucoup d'énergie pour rétablir de la cohérence quand une approche de fond n'a pas été menée au bout dès le départ Exemple, 2 ans de boulot : https://www.openstreetmap.org/user/InfosReseaux/diary/391058 Le ven. 20 mars 2020 à 14:25, Florimond Berthoux < florimond.berth...@gmail.com> a écrit : > > Je ne dis pas qu'il ne faut pas écouter l'avis des gens, et que le système > de proposition est inutile. > Je dis juste que ce n'est que l'avis de quelques personnes, culturellement > orientées (la discussion sur name=* est un bon exemple), certes informés > sur le fonctionnement d'OSM. > Je rejoint Marc sur l'avis qu'il a donné. Il n'appartient alors qu'à ceux qui pensent avoir quelque chose à apporter d'y contribuer pour nuancer cet aspect culturel. > Je ne reproche pas aux gens de s'investir, par contre je reprocherais à > quelqu'un de s'investir sur un sujet qu'il n'utilise pas et de bloquer > l'innovation (conservatisme). > Et il y a un effet pouvoir bureaucratique qui me dérange et me dérangerait > beaucoup s'il était obligatoire. > On ne peut pas dire que le fonctionnement d'OSM soit bureaucratique comparé à d'autres communautés. L'intérêt que je trouve aux propositions et du peu de discussions qui s'en dégage est qu'on s'assure de la cohérence de ce qui est envisagé avec l'existant ou à d'autres ontologies qui ont fait leur preuves. C'est une tâche complexe à assumer seul, le côté collectif et la sensibilité de chacun aide beaucoup. Le voir comme quelque chose d'utile évite de se poser la question de l'obligation. Avec le recul je suis satisfait d'avoir pu corriger certaines erreurs ou biais de perception et proposé des tags cohérents. OSM deviens de plus en plus mature. Lancer un tag en l'air a de plus en de plus de chances d'être en contradiction avec une pratique établie (sans démonstration à la hauteur, l'établi gagne par principe). Le changement est une bonne chose mais il faut mettre l'énergie de le faire complètement, ce que finalement peu de personnes font. Quand nous pourrons nous retrouver à nouveaux tout ensemble, il faudra que nous parlions de la valeur de notre sémantique et du poids que ça peut avoir bien au delà d'OSM. François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le trafic moyen c'est bien
Bonsoir Florimond, Le ven. 20 mars 2020 à 15:52, Florimond Berthoux < florimond.berth...@gmail.com> a écrit : > Par contre ce qui m'intéresse et qui change peu dans le temps c'est le > trafic moyen. > Le trafic moyen est une grandeur physique mesurable et constant dans le > temps. > D'après ce qui est écrit au dessus je ne comprends pas ce point. Des événements imprévus et irrésistibles peuvent venir modifier le trafic, comment la moyenne pourrait être constante ? > - Mais c'est imprécis ! > Parce qu'il y a un tag dans OSM qui est précis ? > Oui, certains tags ont une définition précise et un verbe emprunt de normes établies. > Toute mesure est imprécise, quelle précision d'un width entre un laser, un > mètre à ruban, une vue satellite ? Quelle précision pour le tag surface ? > OSM est une modélisation simplifiée du monde qui comporte par construction > des imprécisions, l'important est de savoir si cette imprécision est > raisonnable pour l'utilisation que l'on veut en faire. > La question du trafic moyen ne touche pas autant à la précision de la mesure mais de sa variabilité dans le temps comme dit plus haut. Une mesure spatiale, bien qu'imprécise, est vérifiable à tout instant. > Pour quoi faire ? > Je suis cycliste, je maintiens une carte vélo (CyclOSM), et je suis membre > actif de Paris en Selle (asso vélo du grand Paris) qui a notamment édité un > guide d'aménagement cyclable qui précise qu'une rue avec moins de 200 > véhicules (motorisés) par heure de pointe est cyclable sans aménagement. > Cette notion a directement été recopié des Pays-Bas et de leur guide. > Donc l'idée est d'utiliser le trafic moyen pour savoir si une route est > plus ou moins cyclable ou non, utilisable pour un routeur ou une carte vélo. > Le trafic moyen pourrait être aussi utilisé pour savoir si le futur appart > de vos rêve sera bruyant ou non. > Je suis d'accord sur ce point. Toutefois il va falloir trouver de très bons arguments, parce que les fondations d'OSM posent des orientations fortes pour la maintenabilité et la cohérence. Qu'une donnée soit utile pour un cas d'usage, il en existe plein. Ça ne garanti pas que ce soit maintenable ici en particulier. Il me semble par exemple difficilement maintenable d'ajouter le débit moyen des rivières. C'est une question qui a soulevé beaucoup de débats pour qualifier des cours d'eau intermittent ou non. Sans garanties de passage à l'échelle et de maintenabilité, je suis pas très chaud. Ce n'est que mon avis. Bonne soirée François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Processus de validation de tag
Bonsoir Martin, La démarche entreprise est seine, quelques commentaires ci-dessous pour vous encourager tous à persévérer. Bien que complexe, semé d'embuches et à géométrie variable, le principe des propositions/votes permet de trouver un certain concensus. A noter que la participation sur le vote a été bonne, il n'y a semble-t-il pas eu de problème de communication sur la tenue de celui-ci. Le jeu. 19 mars 2020 à 15:06, Martin Noblecourt a écrit : > Bonjour à tous, > > Peu d’entre vous l’auront sans doute remarqué mais CartONG portait depuis > plusieurs semaine (en lien avec HOT et les organisations humanitaires > concernées) un proposal de tag autour des camps de réfugiés > <https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Refugee_Site_Location>, > afin de standardiser des tags utilisés jusqu’à présent de façon incohérente > et désorganisée. Ce proposal a fait l’objet de nombreux commentaires suivi > de réponses & révisions de notre part pour essayer de l’améliorer du mieux > possible. > Merci à vous Pour ma part je serais aussi de l'avis de Marc, place=* correspond à un lieu commun. amenity=* me semble être plus approprié. Nous sommes logiquement déçus par cette situation : beaucoup de > contributeurs se plaignent à raison du manque de considération des > organisations, notamment humanitaires, pour les règles communautaires, mais > pourquoi ne pas accueillir avec bienveillance les (rares) organisations qui > essaient de jouer le jeu, plutôt que bloquer un vote sans faire de > contre-propositions ? Le fait que si peu de proposals de tags soient > validés (moins d’1/3, le reste étant essentiellement abandonné plus que > rejeté) – ce qui conduit à un effet totalement contre-productif où chacun > fait ce qu’il veut puisqu’on ne peut rien officialiser – pose question. > Principalement parce que ceux qui formules les critiques sur l'approches de certaines ONG ne sont pas ceux qui jugent les propositions ensuite (enfin j'espère). Disons que la justification des oppositions est un sujet qui revient souvent sur la table, il est au moins nécessaire de justifier son opposition à une proposition. Quant à formuler une contre-proposition, ca ne saurait être obligatoire : on peut savoir être contre sans pour autant trouver de solution au problème posé. On est souvent seul face à cela. > CartONG va relancer dans les prochaines semaines le proposal en tentant de > le bonifier (grâce aux plusieurs contributeurs qui ont, eux, fait des > remarques constructives), nous serons donc preneurs de l’appui de toute > personne connaissant bien le processus de vote pour nous aider à faire > encore mieux. > C'est la bonne démarche. Il n'y a pas d'autres solutions. A noter que je me suis aussi cassé les dents sur certaines propositions avec des remarques plus ou moins honnêtes. Avec le recul, on se dit que le vote est parti trop tôt et que les choses n'ont pas été assez expliquées. Certaines propositions mettent des années avant d'être matures (la discussion s'arrête puis reprend, etc...) > Par ailleurs, nous nous sommes dit qu’il serait utile de lancer une > discussion sur le sujet (au prochain SOTM ?), notamment sur comment > clarifier le processus et mieux le documenter. > Ok pour mieux documenter les choses. Mais pas trop : c'est pas marrant si on te prévient de surveiller les forums locaux pour voir si ils ne préparent pas un raid 10h avant la fin du vote ;) En revanche, ceux qui ont essayé de changer les choses jusque là n'y sont pas parvenus : on aurait atteint la perfection ? > A très vite et bon courage pour le confinement ! > Merci, à toi aussi François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Carte de France des lieux ouverts durant le confinement ?
Bonjour, > - qlq soucis de tag > Police: nwr["amenity"="townhall"](area.searchArea); > Pharmacie: nwr["amenity"="townhall"](area.searchArea); > ou alors la mairie de Montourge est très spéciale :) Effectivement, je me suis planté lors de la copie de la requête, il s'agit bien sur de: nwr["amenity"="pharmacy"](area.searchArea); > - des choix arbitraire : > nwr["amenity"="doctors"]["operator:type"="public"](area.searchArea); > je ne suis pas convaincu que tous les amenity=docteurs d'opérateur > public soie ouvert et tous les autres fermés. C'est clair, c'était précisé ;). Cela permet de cibler LE centre de santé municipale de Montrouge. > - niveau technique : > une carte avec que ces points serraient trop vide et nécessite de > doubler les tuiles rendues actuellements (et cela produit déjà > hélas bcp de tuiles "pas à temps que pour être affichées" > une umap comme semble être votre carte me semble le mieux Ce n'est pas umap, mais c'est effectivement l'idée. François > > et on fait quoi pour l'inévitable cas du poi dans la caétogie ouvert > mais qui est fermé ou inversement ? > > Cordialement, > MArc > > Le 18.03.20 à 20:02, Florian LAINEZ a écrit : > > J'ai appris via Datactivist que la liste détaillée des lieux ouverts est > > dispo sur la page https://www.gouvernement.fr/info-coronavirus > > > > j'ai lu, j'ai vu que nous avions oublié d'indiquer sur notre carte à > > Montrouge au moins tous ces lieux : > > shop=bicycle > > shop=frozen_food > > shop=mobile_phone > > shop=doityourself > > shop=stationery > > shop=optician > > amenity=car_rental > > amenity=bank > > office=employment_agency > > shop=alcohol > > > > pour le reste de la france, il faut refaire une passe (et rajouter > > hôtels, garagistes ...), il y du boulot pour transcrire tout ça en une > > requête overpass on s'y colle ? > > > > Le mer. 18 mars 2020 à 18:49, Florian LAINEZ > <mailto:winner...@free.fr>> a écrit : > > > > Hello, > > > > François et moi-même avons créé la carte des lieux ouverts durant le > > confinement à Montrouge : > > > > https://osmontrouge.fr/covid19=townhall=police=pharmacy=centre_sante=food=bakery=fuels_station=funerals@48.815861,2.315304,14.87 > > > > Est-ce que l'on n'essayerai pas de faire pareil à l'échelle du pays > > ? Umap ? Ou mieux, un rendu ad-hoc sur covid19.openstreetmap.fr > > <http://covid19.openstreetmap.fr> ? > > Les requêtes que nous avons utilisé sont surement à revoir pour être > > applicable à l'ensemble du territoire. Les voici : > > > > Mairie: > > nwr["amenity"="townhall"](area.searchArea); > > > > Police: > > nwr["amenity"="townhall"](area.searchArea); > > > > Pharmacie: > > nwr["amenity"="townhall"](area.searchArea); > > > > Centre de soin (très spécifique à Montrouge): > > nwr["amenity"="doctors"]["operator:type"="public"](area.searchArea); > > > > Magasin d'alimentation: > > nwr["amenity"="marketplace"](area.searchArea); > > nwr["shop"="supermarket"](area.searchArea); > > nwr["shop"="greengrocer"][!"indoor"](area.searchArea); > > nwr["shop"="butcher"][!"indoor"](area.searchArea); > > nwr["shop"="seafood"][!"indoor"](area.searchArea); > > nwr["shop"="cheese"][!"indoor"](area.searchArea); > > nwr["shop"="convenience"](area.searchArea); > > > > Boulangerie: > > nwr["shop"="bakery"][!"indoor"](area.searchArea); > > > > Station d'essence: > > nwr["amenity"="fuel"](area.searchArea); > > > > Service funéraire: > > nwr["shop"="funeral_directors"](area.searchArea); > > > > -- > > > > *Florian Lainez* > > > > @overflorian <http://twitter.com/overflorian> > > > > > > > > -- > > > > *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] Proposed new status for tags in the wiki: "import" for undiscussed tags that were only used by an import
Hi all My 2cts : "in use" status and statuslink to the import proposal would be enough, right? Point is to determine where does the tag come from, and it's done by statuslink, not status which reflect the current state of use. All the best François Le mar. 17 mars 2020 à 10:55, Warin <61sundow...@gmail.com> a écrit : > On 17/3/20 8:22 pm, Marc M. wrote: > > Hello Joseph, > > it may give the impression that this is the way it should be done. > I agree to identify these "Noise" or poor quality tags, but with a > keyword to show that it's a problem. e.g. status=bad, disputed, error, ... > it would be necessary to find a word that is not as strong as error, > but which nevertheless clearly indicates that this is not an example to > follow. > > > > Agree with both. > > Possible values? > > obsolete > > abandoned > > discarded > > <https://www.collinsdictionary.com/dictionary/english-thesaurus/forsaken> > > archaic > > passe > > stale > > > > <https://www.collinsdictionary.com/dictionary/english-thesaurus/forsaken> > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] TELECOM :: Avis demandé
Bonjour Jacques, Tout ce qui comporte ref:FR:ARCEP <https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:ARCEP?uselang=fr> FI-86070-0002 est un point de mutualisation fibre. Il est possible d'ajouter utility=telecom si tu le souhaites (à moyen terme street_cabinet=telecom pourrait être remplacé). Bonne journée François Le jeu. 12 mars 2020 à 17:32, Jacques Lavignotte a écrit : > > Bonjour, > > pas du tout certain que : > > https://www.openstreetmap.org/node/7289040768 > > soir un PM du FTTH. > > https://framapic.org/gallery#YjUsykpdZqD4/SHkecVziGGEz.jpg > > Over. > > J. > > ps : merci. > > -- > GnuPg : 156520BBC8F5B1E3 Because privacy matters. > « Quand est-ce qu'on mange ? » AD (c) (tm) > > ___ > 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] Détection de bâti manquant à partir de la Carte des déploiements fibre ?
Salut à tous +1 avec Yves, c'est un très bon cas d'usage Le mer. 11 mars 2020 à 14:39, Frédéric Rodrigo a écrit : > Oui c'est tout à fait un job pour Osmose ça. On pourra l'activer le 1er > avril, ça fera sont petit effet. > Oui, à double titre : https://www.arcep.fr/actualites/agenda-et-evenements/detail/n/conference-annuelle-territoires-connectes-cartes-sur-table.html > Cette base sert d'ailleurs de source à la BAN. > Je n'en suis pas sûr, quelle est ta source ? Orange me dit le contraire ici : https://www.youtube.com/watch?v=-WfW5EO3zmU=53s Bonne journée François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Point de vue intéressant concernant les licences
Salut à tous, Il existe une communauté de contributeurs autour de la modélisation des infrastructures d'énergie que je suis depuis quelques mois : OpenMod initiative. Cette communauté manipule beaucoup de modèles scientifiques, données publiques et contributions privées et se pose bien plus que nous des questions sur les différentes licences et attributions. Robbie Morisson a effectué un bon travail de classification et une discussion récente dresse une vision peu glorieuse du travail d'attribution pourtant nécessaire. OSM est cité. https://groups.google.com/forum/#!topic/openmod-initiative/-1OHyVjaQwg Il est possible de traduire l'échange en français pour les intéressés. J'ai tické quand j'ai vu que Creative Commons était préfér à ODbL pour les jeux de données, en me rappelant des discussions qui s'étaient tenues lors du changement de licence d'OSM. Preneur de vos réactions si vous en avez Bonne soirée François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Les actionneurs (portes automatiques, barrières, plots routiers, vannes)
Hello Relativement à ce vieux mail, j'ai commencé à renseigner quelques bornes amovibles https://www.openstreetmap.org/node/7216029508 Preneur de retours si quelqu'un a aussi tenté des choses Il y a des portes sympa à décrire aussi : https://wiki.openstreetmap.org/wiki/FR:Tag:actuator%3Dmanual François Le mar. 16 juil. 2019 à 00:02, François Lacombe a écrit : > Salut à tous, > > J'ai récemment un peu avancé dans la traduction de la doc de la clé > actuator=*, permettant d'indiquer la nature de l'actionneur mécanique > mettant différents systèmes en mouvement. > https://wiki.openstreetmap.org/wiki/FR:Key:actuator > > Cela va de la porte automatique, aux plots routiers amovibles en passant > par les vannes (but initial de cet clé). > La liste des valeurs possibles initiale est disponible sur la proposition > votée en début d'année > > https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Pipeline_valves_proposal#Actionneurs > > Ce serait pas mal d'initier l'usage de la clé sur les dispositifs routiers > de régulation de la circulation (barrières, plots, portails) et sur les > portes automatiques, cela peut servir pour l'accessibilité. > Seules les valeurs electric_motor, pneumatic_cylinder et > hydraulic_cylinder devraient être utiles pour cela (on va laisser solenoid > et thermostatic pour plus tard). > https://wiki.openstreetmap.org/wiki/FR:Tag:actuator%3Delectric_motor > https://wiki.openstreetmap.org/wiki/FR:Tag:actuator%3Dhydraulic_cylinder > https://wiki.openstreetmap.org/wiki/FR:Tag:actuator%3Dpneumatic_cylinder > > Dans le cas de dispositifs manuels, la clé handle pourrait également servir > https://wiki.openstreetmap.org/wiki/FR:Key:handle > > La liste des valeurs est aussi disponible sur la proposition (les valeurs > n'étant pas toutes utilisées vu de taginfo, la liste ne les donne pas > toutes) > > https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Pipeline_valves_proposal#Commande_manuelle > > Preneur de vos remarques pour ces cas d'usages, y compris indiquant des > clés existantes plus particulières ou des cas non documentés. > > Bonne soirée > > François > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Projet du mois de mars - #balanceTaBorne
Hello Merci Noémie pour la préparation ! Cela a été l'occasion de se poser quelques question sur les tags existant et d'apporter quelques corrections mineures. Les données issues de ce projet seront d'autant de bonne qualité que nous nous rendrons sur le terrain à mon avis (quitte à utiliser Osmose pour guider ses déplacements) Je mettrai un tweet sur le sujet demain matin Bonne fin de weekend François Le dim. 1 mars 2020 à 10:33, Noémie Lehuby via Talk-fr < talk-fr@openstreetmap.org> a écrit : > Bonjour, > > Plus de 28 000 points de recharge pour véhicules électriques de recharge > existent en France. > Votre mission, si vous l’acceptez, est de cartographier toutes les bornes > servant de support à ces points de recharge. > > Nous en avons déjà repéré environ 4 000, félicitations. Mais le compte n’y > est pas ! > > Vous l’aurez compris, il va s’agir d’une mission de terrain : ouvrons > l’œil et n’en manquons aucune ! > > Et comme pour chaque mission, nous pouvons nous appuyer sur ces précieux > outils : MapContrib > <https://www.mapcontrib.xyz/t/d21a0a-Bornes_de_recharge_de_vehicules_electriques>, > MapRoulette <https://maproulette.org/browse/challenges/12463>, Mapillary, > Pic4Review <https://pic4review.pavie.info/#/mission/921>, NotesReview > <https://ent8r.github.io/NotesReview/expert/?query=%23balancetaborne=100=2020-01-15>, > etc. > > Le mot-dièse de cette mission est #balanceTaBorne. Pensez à l’indiquer > dans vos changesets, vos notes OSM et vos communications sur les réseaux > sociaux. > > Les détails plus précis de cette mission sont à retrouver sur la page de > wiki > <https://wiki.openstreetmap.org/wiki/FR:Project_of_the_month/bornes_vehicules_electriques> > . > > Bonne chance ! > > -- > Noémie Lehuby > Jungle Bus - http://junglebus.io > > ___ > 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
