Re: [OSM-talk] The end of waterway map

[François Lacombe]

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

[François Lacombe]

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

[François Lacombe]

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

[François Lacombe]

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 ?

[François Lacombe]

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

[François Lacombe]

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

[François Lacombe]

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

[François Lacombe]

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

[François Lacombe]

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

[François Lacombe]

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

[François Lacombe]

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

[François Lacombe]

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

[François Lacombe]

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

[François Lacombe]

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)

[François Lacombe]

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

[François Lacombe]

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

Re: [OSM-talk-fr] [édition de masse] convertir le tag déprécié diaper par le tag approuvé changing_table

[François Lacombe]

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

[François Lacombe]

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] Proposition - Vote - Les pompes

[François Lacombe]

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

Re: [OSM-talk-fr] Proposition - Vote - Les pompes

[François Lacombe]

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

[François Lacombe]

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

[François Lacombe]

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

[François Lacombe]

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

[François Lacombe]

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

[François Lacombe]

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

[François Lacombe]

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 ?

[François Lacombe]

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 
>> ___
>> 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

[François Lacombe]

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

[François Lacombe]

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

[François Lacombe]

Bonsoir à tous

Le dim. 6 sept. 2020 à 23:08, Philippe Verdy  a écrit :

> Merci pour ce lien. Dommage qu'il faille télécharger un gros fichier ZIP
> national et aucun outil de recherche (la carte affichée sur la page n'est
> qu'un fond générique, elle n'en fait aucun rendu, et il n'y a pas d'ouil de
> sélection sur cette page même si elle prétend le contraire).
>

Le découpage départemental a été demandé par plusieurs personnes et est
dans les tuyaux.
Il y a la plateforme opendata qui permet d'afficher les données sur le mode
carte d'opendatasoft
https://data.enedis.fr/explore/?sort=modified=Infrastructures


> Sinon il semble que ce jeu ne soit pas complet: je note des tas de bouts
> de lignes aériennes (20kV: pas les grand pylones mais des poteaux avec 1 à
> 3 câbles) visibles sur l'imagerie mais absentes du jeu publié  (et même on
> voit leur interconnexion avec la partie publiée, et sans poste de
> transformation aux noeuds de répartition, même s'il y a éventuellement
> juste des coupe-circuits, impossibles à voir). Et je ne parle pas su réseau
> de distribution BT (220-400 V, mono ou triphasé) ni de la partie enterrée
> (qui ne semble à peu près complète qu'en milieu urbain dense).
>

Attention, ces tronçons de ligne ont surement été déposés ou Enedis n'est
pas exploitant sur la commune. Le jeu de données est normalement à jour du
1er semestre 2020
Si la ligne est sur la vue aérienne mais pas dans le jeu de données, il
faut aller vérifier sur place


> Il semble que ces données oublient les lignes qui desservent des clients
> éloignés isolés et pas gros consommateurs (par exemple vers une seule
> ferme, une résidence un hameau avec 2 ou 3 maisons) ou des lignes de
> dérivation ajoutées juste pour le maillage et permettant de contourner des
> pannes ou coupure sur une ligne (ces lignes ne sont pas toujours sous
> tension, pour éviter des problèmes de pertes importante par déphasage en
> fonction des longueurs de parcours, elles peuvent s'activer juste par
> télécommande quand un autre circuit est coupé), ni les lignes qui
> permettent de "booster" la puissance disponible (pour certaines entreprises
> dans une petite zone artisanale, quand le réseau urbain attenant n'a pas la
> capacité suffisante, ou pour franchir certains obstacles naturels (un bois,
> une rivière).
>

Je veux bien regarder un exemple de ce genre de cas si possible


> Bref on a des lignes HT (~20kV) déjà dans OSM (classées somme lignes
> "mineures"), assez facilement observables (dans l'imagerie, niveau de zoom
> minimum de 16 dans les champs cultivés, parfois il faut plus dans les zones
> forestières ou à fort relief ou végétation irrégulière, dans les
> forêts voir les poteaux n'est pas évident car on ne repère pas leur ombre
> même si on s'attend à les trouver au bord d'un chemin d'exploitation ou
> d'une route forestière ou qu'il doit en exister pour relier les habitats ou
> entreprises isolées), qui ne sont pas dans ce fichier. OSM s'emble à
> peut près au point seulement pour les grandes artères en très haute tension
> (sur gros pylones).
>

L'import des réseaux moyenne et basse tensions prendra des années, c'est
vrai. Ce qui laisse de bonnes séances de carto, survey et vérifications
pour tout le monde !
Sans compter que nous collectons aujourd'hui plus de données sur le terrain
sur les réseaux aériens qu'il n'y a dans l'opendata.


Le lun. 7 sept. 2020 à 00:54, Philippe Verdy  a écrit :

> Et contrairement à Enedis, je n'ai pas trouvé d'OpenData concernant
> "Seolis" (le réseau des Deux-Sèvres: Enedis est y présent aussi mais
> seulement pour certaines communes denses où les deux réseaux se recouvrent
> et ou s'interconnectent partiellement), il semble que Seolis délègue ses
> données à "Geredis" qui lui non plus ne semble pas avoir de données
> ouvertes (selon le service ScanR du ministère de la recherche, des
> références en tant qu'organisation mais presque tout est vide hormis
> quelques rapports de thèses ou des analyses financières et quelques
> statistiques).
>

Et pourtant Gérédis est le 1er gestionnaire de réseau à avoir ouvert ses
données après Enedis fin 2019.
https://www.geredis.fr/Cartographie-et-reseaux


>
> Sinon j'ai trouvé l'agence ORE:
>
> https://opendata.agenceore.fr/explore/dataset/distributeurs-denergie-par-commune/information/
> Mais ça référence juste des organisations, pas les réseaux et il y a très
> peu de détails (on a plus d'infos dans les RCS ou services info-greffe): ce
> n'est en fin de compte qu'un annuaire.
>

C'est un travail déjà énorme.
Le recensement des sociétés parmi plus de 640 concessions a pris un certain
temps, d'autant que les plus petits acteurs n'ont pas les moyens de
participer à la même hauteur que les gros.
Cela vaudrait le coup de l'intégrer dans Osmose pour vérifier le 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 

Re: [OSM-talk-fr] La gestion des poteaux

[François Lacombe]

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

[François Lacombe]

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

[François Lacombe]

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

[François Lacombe]

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  a
>annoncé
> 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

[François Lacombe]

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 
> support=pedestal photo
> 
> 1642 
> cover=roof + support=pole photo
> 
> 748 
> support=pole + cover !~ ".*" photo
> 
> 551 
> cover=roof + support !~ ".*"
> 279 
> support=ground photo
>  74
> 
> cover=roof + support=stile photo
> 
> 31 
> cover=roof + support=pedestal
> 5  borne surmontée d'une balise aérienne
> cover=cone photo
> 
> 0 
> cover=fin photo
>  0
> 
>
> Il me semble que j'ai passé en revue tous les cas du wiki 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

[François Lacombe]

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 ?

[François Lacombe]

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

[François Lacombe]

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

[François Lacombe]

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 !

[François Lacombe]

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://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

[François Lacombe]

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

[François Lacombe]

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

[OSM-talk-fr] CNIG : Proposition de géo-standard Grace THD

[François Lacombe]

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

[François Lacombe]

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

[François Lacombe]

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

[François Lacombe]

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
=* 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

[François Lacombe]

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,
> > => a ignorer
> > - cumul : distance cumulée depuis le début de la route
> > => a ignorer ou inventer
> >
> > - route: A0004 (a modifier pour faire correspondre a A 4)
> > => ref
> > - pr : 1 pour une meme route, il peut y avoir le meme pr dans chaque
> > département
> > => distance
> >
> > - pour ces 3 données
> >   + depPr : le département gestionnaire (pas le département ou se situe
> > le plo)
> >   + concessionPr : C pour concédé a un concessionnaire, N pour non
> > concédé
> >   + cote : 

Re: [OSM-talk-fr] DCbrain rend publique une partie de son code en open source

[François Lacombe]

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

[François Lacombe]

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

[François Lacombe]

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

[François Lacombe]

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
> 
>  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 
> , BMPM
> 
> , SSLIA
> 
>  ?
> 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

[François Lacombe]

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

[François Lacombe]

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]

[François Lacombe]

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

[François Lacombe]

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

[François Lacombe]

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

[François Lacombe]

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

[François Lacombe]

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
> 
> .
>
> Les pages wikipedia Robert Keller
> , Laurent Matheron
>  et 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
> ,
> de même que la photo dans openplaques.org
> .
>
> Pages wikipedia
>
>- Paris
>   - Rue de l'Ingénieur-Robert-Keller
>   
>   - Piscine Keller 
>   - Tour Keller 
>   - plaque commémorative
>   
> 
>- Rennes
>   - Category:Centre Pierre-Guillou
>   .
>   Façade du centre visible sur GSV
>   
> ,
>   et plaque sur la vue 3D
>   
> 
>
> Objets OSM
>
>- Paris
>   - Rue de l'Ingénieur Robert Keller (Relation 541733
>   
>   )
>   - 6, Rue de l'Ingénieur Robert Keller (Nœud 682420370
>   )
>   - Tour Keller (Chemin 115878685
>   )
>   - Piscine Keller (Chemin 115878661
>   )
>- Noisy-le-Grand
>   - Rue du Réseau Robert Keller (Chemin 300360502
>   )
>- Dunkerque
>   - Rue Pierre Guillou (Relation 4160543
>   
>   )
>   - Allée Pierre Guillou (Chemin 310637211
>   )
>   et Aire Pierre Guillou (Chemin 310637210
>   
>   )
>- Saint-Brévin-les-Pins
>   - Avenue Pierre Guillou (Chemin 537798149
>   
>   )
>- Rennes
>   - Centre Pierre Guillou (Tout ou partie ? du chemin 80941896
>   )
>   - Plaque commémorative : Pierre Guillou(Nœud 7505930664
>   )
>- Plonévez-Porzay
>   - Square Pierre Guillou (Chemin 109304851
>   
>   )
>- Troyes
>   - Rue Robert Keller (Chemin 68247930
>   )
>- Lyon
>   - plaque commémorative est apposée une plaque dans l'enceinte du
>   centre Lyon-Sévigné de Orange, situé dans le 3e arrondissement de Lyon
>   - Centre d'amplification des LSGD de Lyon-Tassin a été nommé Centre
>   Laurent-Matheron
>   - centre Lyon-Sévigné est rebaptisé Lyon-Sévigné-Matheron
>- Le Petit-Quevilly
>   - Le nouveau bureau de poste porte son nom de Robert Keller. Une
>   plaque y est apposée.
>   - Cachan
>   - Un lycée professionnel porte le nom de Robert 

Re: [OSM-talk-fr] Ça reste ouvert bientôt intégré sur le site de la ville de Lyon

[François Lacombe]

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
>  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
> .
>
> 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 prouve une nouvelle fois la vitalité et la pertinence d'OSM
> pour répondre à la crise sanitaire actuelle, et de faire avancer ensemble
> la communauté, les collectivités et les petites entreprises autour d'OSM.
>
> Dans les semaines à venir nous continuerons de nous impliquer pour faire
> 

[OSM-talk-fr] Schémas de nommages locaux et cas de ref:FR:RTE_nom

[François Lacombe]

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

[François Lacombe]

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

[François Lacombe]

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

[François Lacombe]

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

[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

Re: [OSM-talk] Fwd: Re[2]: Tag:manhole=telecom

[François Lacombe]

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

[François Lacombe]

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] [Edition mécanique] ref:FR:CORRIDOR -> ref:EU:EVSE

[François Lacombe]

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

[François Lacombe]

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
> 
> 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] Ajout de brand:wikidata sur les enseignes

[François Lacombe]

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] Ajout de brand:wikidata sur les enseignes

[François Lacombe]

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
.

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] Ajout de brand:wikidata sur les enseignes

[François Lacombe]

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] Processus de validation de tag

[François Lacombe]

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

[François Lacombe]

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

[François Lacombe]

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

[François Lacombe]

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

[François Lacombe]

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
> ,
> 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] Proposed new status for tags in the wiki: "import" for undiscussed tags that were only used by an import

[François Lacombe]

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
>
>  
>
> archaic
>
> passe
>
> stale
>
>
>
> 
> ___
> 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é

[François Lacombe]

Bonjour Jacques,

Tout ce qui comporte
ref:FR:ARCEP

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 ?

[François Lacombe]

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

[François Lacombe]

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)

[François Lacombe]

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

[François Lacombe]

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
> ,
> MapRoulette , Mapillary,
> Pic4Review , NotesReview
> ,
> 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
> 
> .
>
> 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

Re: [OSM-talk-fr] Remplacer ref:ERDF:gdo par ref:FR:Enedis / ref:FR:gdo

[François Lacombe]

Bonsoir Quentin,

Attention, à ma connaissance sur les réseaux GRDF, seuls les postes de
distribution publics ont un code GDO affichés.
Les valeurs qui commencent par GI ne sont pas des codes GDO

Cela n'empêche pas de les décrire avec
pipeline=substation
substation=delivery
operator=GRDF
ref=GIxx

La documentation est encore très partielle sur le sujet j'en conviens

Bonne soirée

François

Le lun. 17 févr. 2020 à 11:16, Quentin Salles 
a écrit :

> Bonjour François,
>
> Merci pour cet ajout. Je retrouve les cas que j'ai rencontré dans ma
> commune, notamment les postes de distribution privé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

Re: [OSM-talk-fr] Nettoyage Enedis / GRDF

[François Lacombe]

Bonsoir Quentin,

Merci pour les informations, tel qu'expliqué ici ces modifs devraient être
ok.

N'hésitez pas à faire de même chez vous pour se séparer de operator=ERDF
Je m'aperçois que j'en ai encore un peu à faire dans les Alpes

Bonne soirée

François

Le lun. 17 févr. 2020 à 13:17, Quentin Salles 
a écrit :

> Bonjour,
> J'ai effectué la modification des clés ERDF et ENEDIS sur toute la région
> Occitanie. N'étant pas sur de ma contribution, voici ce que j'ai fait :
> - Les postes de transformation basculent vers Enedis après vérification
> sur le site de l'agence ORE
> - Les câbles électriques en surface sont divisés en 2 parties :
> -- Les "minor_line" ont comme opérateur Enedis
> -- Les autres (voltage=63000) ont comme opérateur RTE.
> J'espère ne pas m'être trompé sur mes contributions.
>
> Je n'ai pas réalisé de bascule EDF vers Enedis vu que je ne suis pas assez
> calé pour réaliser ces modifications.
>
> Bonne journée
>
> Quentin
> ___
> 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] Nettoyage Enedis / GRDF

[François Lacombe]

Bonjour Adrien et merci pour ton action :)

N'hésitez pas à le faire dans votre région également, on sera plusieurs à
être disponibles en cas d'indéterminations

Bon dimanche

François

Le ven. 14 févr. 2020 à 09:21, PanierAvide  a
écrit :

> Bonjour François,
>
> Merci pour ce travail de documentation et d'animation de communauté ! Je
> viens de faire la bascule en Bretagne des operator=ERDF/EDF vers
> operator=Enedis sur le réseau de distribution. Je n'ai pas modifié les
> operator=EDF sur tout ce qui est production d'énergie (centrales
> électriques).
>
> Cordialement,
>
> Adrien P.
>
> Le 14/02/2020 à 00:29, François Lacombe a écrit :
>
> Salut à tous,
>
> Il devenait nécessaire de créer une page wiki pour Enedis et GRDF, nos
> opérateurs de distribution préférés pour documenter les pratiques les
> concernant.
> https://wiki.openstreetmap.org/wiki/FR:Tag:operator%3DGRDF
>
> En particulier Enedis qui mérite un bon nettoyage puisque qu'il y a encore
> ~2500 operator=ERDF et quelques operator=EDF qui traînent (on a dépassé les
> 100 000 pour Enedis)
>
> Un résumé des différentes valeurs est visible ici
> https://wiki.openstreetmap.org/wiki/FR:Tag:operator%3DEnedis
>
> Si certains objets concernés se trouvent dans votre zone de prédilection,
> cela sera utile de mettre la bonne valeur pour operator
> Il est possible de vérifier si Enedis est bien le gestionnaire du réseau
> sur la commune ici
> https://dataviz.agenceore.fr/distributeurs-energie-france/
>
> Au passage, compléter les postes, *poteaux* et autres ouvrages avec
> ref:FR:gdo et name est apprécié
> https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:gdo
>
> A disposition en cas de questions sur le sujet
>
> Bonne soirée
>
> François
>
> ___
> 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

[OSM-talk-fr] Nettoyage Enedis / GRDF

[François Lacombe]

Salut à tous,

Il devenait nécessaire de créer une page wiki pour Enedis et GRDF, nos
opérateurs de distribution préférés pour documenter les pratiques les
concernant.
https://wiki.openstreetmap.org/wiki/FR:Tag:operator%3DGRDF

En particulier Enedis qui mérite un bon nettoyage puisque qu'il y a encore
~2500 operator=ERDF et quelques operator=EDF qui traînent (on a dépassé les
100 000 pour Enedis)

Un résumé des différentes valeurs est visible ici
https://wiki.openstreetmap.org/wiki/FR:Tag:operator%3DEnedis

Si certains objets concernés se trouvent dans votre zone de prédilection,
cela sera utile de mettre la bonne valeur pour operator
Il est possible de vérifier si Enedis est bien le gestionnaire du réseau
sur la commune ici
https://dataviz.agenceore.fr/distributeurs-energie-france/

Au passage, compléter les postes, *poteaux* et autres ouvrages avec
ref:FR:gdo et name est apprécié
https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:gdo

A disposition en cas de questions sur le sujet

Bonne soirée

François
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Remplacer ref:ERDF:gdo par ref:FR:Enedis / ref:FR:gdo

[François Lacombe]

Bonsoir à tous

Le mar. 7 janv. 2020 à 16:04, Quentin Salles  a
écrit :

> Bonjour,
>
> Pouvez-vous me confirmer que l'usage de la clé "ref:FR:gdo" est bien actif
> ?
> En faisant une requête Overpass, je n'ai vu qu'une seule utilisation sur
> toute la France.
>
> De plus, je suis novice sur le sujet, mais je pense qu'il serait
> intéressant de parler d'autres cas (notamment le gaz) sur cette page. Qu'en
> pensez-vous ?
>

Suite à la remarque de Quentin ci-dessus, la page est désormais mixte
électricité/gaz, avec des cas d'usages décris pour les deux domaines
https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:gdo#Ouvrages_gaziers

Même si la documentation pour le gaz est moins étoffée que pour l'élec, les
postes gaz comme ceux-ci ont bien leur place dans OSM en tant qu'armoires
de rue
https://wiki.openstreetmap.org/wiki/File:French_gas_delivery_point.jpg

Bonne soirée

François
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] ref et ref:FR

[François Lacombe]

Bonjour

Des arguments sont toujours attendus pour faire autrement.

3 points :
* Qui sommes-nous pour affirmer que le nom de la ref ne collisionnera pas
ailleurs ?

* Le namespace permet de spécialiser la ref, d'y associer une documentation
complète et de séparer les concepts.
En ce qui me concerne, toutes les ref crées selon ce motif sont documentées
et vous serez bien inspirés non seulement de proposer cette documentation
sur une clé unique et aussi d'aller les valider dans les éditeurs

* Dans des cas de multi-ref (plus souvent le cas qu'on ne le pense), on
distingue clairement les différents concepts en jeu.
Avoir ref=* + ref:autre n'est pas acceptable à plusieurs titres : on
perdrait l'info de ce qui est effectivement lu sur le terrain (qui peut
contenir plusieurs champs)
Exemple : https://www.openstreetmap.org/relation/6668144

J'ai reporté ces arguments sur le wiki
https://wiki.openstreetmap.org/wiki/Talk:France/Liste_des_r%C3%A9f%C3%A9rences_nationales#Arguments_pour.2Fcontre_le_recours_aux_namespaces_locaux

Qu'il y ait des références mal définies, c'est vrai et du temps est
nécessaire pour les reformuler
De là à parler de dogme, c'est pas le cas n'est-ce pas ?

Bonne journée

François

Le mer. 12 févr. 2020 à 00:34, marc marc  a
écrit :

> on ets en plein dogme, cfr Réseau Arc en ciel de bus en france
>
> Le 12.02.20 à 00:21, François Lacombe a écrit :
> > En corollaire à ces propositions, je pensais suggérer à l'international
> > de ne laisser sur la page ref que les références mondiales
> > J'ai déjà supprimé le peu de ref:FR qui s'y trouvaient, en laissant
> > évidemment les liens vers la page française des références nationales.
> >
> > Cela permettra de clarifier les choses entre mondial/national et
> > d'inciter les pays à créer leurs propres page et namespace
> >
> > Penser qu'il y a aussi un niveau continental, avec quelques entrées en
> > Europe par exemple
> > https://wiki.openstreetmap.org/wiki/FR:Key:ref:EU:EVSE
> > https://wiki.openstreetmap.org/wiki/Key:ref:EU:ENTSOE_EIC
> >
> > Bonne soirée
> >
> > François
> >
> > Le mar. 11 févr. 2020 à 23:47, François Lacombe
> > mailto:fl.infosrese...@gmail.com>> a écrit :
> >
> > Bonsoir à vous
> >
> > +1 avec vous, bonne idée de séparer le tableau, pourquoi pas par
> > thèmes, comme nous le faisons pour les Map Features ?
> > Sur le caractère national/local, pourquoi pas ajouter une colonne
> > dans les tables pour le préciser ?
> >
> > Globalement, tout ce qui favorise l'adoption de ref:FR:* est bon à
> > prendre.
> >
> > François
> >
> > Le mar. 11 févr. 2020 à 18:57, deuzeffe  > <mailto:opensm@deuzeffe.org>> a écrit :
> >
> > Hello,
> >
> > Le 11/02/2020 à 18:25, leni a écrit :
> > > Bonjour
> > >
> > > En attendant que nous trouvions une meilleure solution pour
> > certaines
> > > ref:FR:*** , je pense qu'il serait bien de partager le tableau
> > de la
> > > page
> > >
> >
> https://wiki.openstreetmap.org/wiki/France/Liste_des_r%C3%A9f%C3%A9rences_nationales
> >
> > > (1) en deux parties :
> > > - une première partie avec les références qui s'appliquent sur
> > > l'ensemble du territoire (ref:FR:ARCEP=* ; ...) en y ajoutant
> > celles que
> > > j'ai trouvées dans le wiki (2)
> > > - une partie pour les autres (ref:FR:CRTA=*en Aquitaine ;
> > > ref:FR:BSPP:=* ; ref:FR:RATP=*) en y ajoutant celles que
> j'ai
> > > trouvées dans le wiki (3)
> > > - Faut-il y ajouter ref:FR:TransGironde et ref:FR:CUB qui sont
> > dans osm
> > > et que je n'ai pas trouvées dans le wiki ?
> > >
> > > Qu'en pensez-vous ?
> >
> > Sur le partage, que du bien. Et peut-être "l'ordonner" voire le
> > découper
> > par thème ?
> > Il me semble que j'en avais déjà parlé, sans grand succès...
> >
> > --
> > deuzeffe - qui n'a pas oublié la page transport à toiletter.
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org <mailto: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] ref et ref:FR

[François Lacombe]

En corollaire à ces propositions, je pensais suggérer à l'international de
ne laisser sur la page ref que les références mondiales
J'ai déjà supprimé le peu de ref:FR qui s'y trouvaient, en laissant
évidemment les liens vers la page française des références nationales.

Cela permettra de clarifier les choses entre mondial/national et d'inciter
les pays à créer leurs propres page et namespace

Penser qu'il y a aussi un niveau continental, avec quelques entrées en
Europe par exemple
https://wiki.openstreetmap.org/wiki/FR:Key:ref:EU:EVSE
https://wiki.openstreetmap.org/wiki/Key:ref:EU:ENTSOE_EIC

Bonne soirée

François

Le mar. 11 févr. 2020 à 23:47, François Lacombe 
a écrit :

> Bonsoir à vous
>
> +1 avec vous, bonne idée de séparer le tableau, pourquoi pas par thèmes,
> comme nous le faisons pour les Map Features ?
> Sur le caractère national/local, pourquoi pas ajouter une colonne dans les
> tables pour le préciser ?
>
> Globalement, tout ce qui favorise l'adoption de ref:FR:* est bon à prendre.
>
> François
>
> Le mar. 11 févr. 2020 à 18:57, deuzeffe  a
> écrit :
>
>> Hello,
>>
>> Le 11/02/2020 à 18:25, leni a écrit :
>> > Bonjour
>> >
>> > En attendant que nous trouvions une meilleure solution pour certaines
>> > ref:FR:*** , je pense qu'il serait bien de partager le tableau de la
>> > page
>> >
>> https://wiki.openstreetmap.org/wiki/France/Liste_des_r%C3%A9f%C3%A9rences_nationales
>> > (1) en deux parties :
>> > - une première partie avec les références qui s'appliquent sur
>> > l'ensemble du territoire (ref:FR:ARCEP=* ; ...) en y ajoutant celles
>> que
>> > j'ai trouvées dans le wiki (2)
>> > - une partie pour les autres (ref:FR:CRTA=*en Aquitaine ;
>> > ref:FR:BSPP:=* ; ref:FR:RATP=*) en y ajoutant celles que j'ai
>> > trouvées dans le wiki (3)
>> > - Faut-il y ajouter ref:FR:TransGironde et ref:FR:CUB qui sont dans osm
>> > et que je n'ai pas trouvées dans le wiki ?
>> >
>> > Qu'en pensez-vous ?
>>
>> Sur le partage, que du bien. Et peut-être "l'ordonner" voire le découper
>> par thème ?
>> Il me semble que j'en avais déjà parlé, sans grand succès...
>>
>> --
>> deuzeffe - qui n'a pas oublié la page transport à toiletter.
>>
>> ___
>> 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] Acknowledgement for the wiki documentation

[François Lacombe]

Hi Daniel,

Thank you for your message, very encouraging to provide high quality of
documentation
Even if it consumes high amount of time sometimes

Translations are important also, great to see people involved in this :)

All the best

François

Le sam. 8 févr. 2020 à 22:22, Daniel Capilla  a écrit :

> Hi,
>
> I've been working on the translation of the wiki into Spanish for a long
> time, both creating new translations and updating the translations that
> become obsolete. In all this time I have been able to check the
> evolution of some pages of documentation in English, the way in which
> they have expanded in content over time and clarifying cases of use of
> tags that could be confusing initially.
>
> I have sent this message to the mailing list just to thank all users and
> contributors who help documenting the use of tags, projects, mappers'
> guides and other documentation pages on the OSM Wiki. It is an important
> work, a much appreciated and very valuable effort.
>
> Thanks to all of you!
>
> Greetings from Spain.
>
> Regards,
>
> Daniel
>
>
> ___
> 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] ref et ref:FR

[François Lacombe]

Bonsoir à vous

+1 avec vous, bonne idée de séparer le tableau, pourquoi pas par thèmes,
comme nous le faisons pour les Map Features ?
Sur le caractère national/local, pourquoi pas ajouter une colonne dans les
tables pour le préciser ?

Globalement, tout ce qui favorise l'adoption de ref:FR:* est bon à prendre.

François

Le mar. 11 févr. 2020 à 18:57, deuzeffe  a écrit :

> Hello,
>
> Le 11/02/2020 à 18:25, leni a écrit :
> > Bonjour
> >
> > En attendant que nous trouvions une meilleure solution pour certaines
> > ref:FR:*** , je pense qu'il serait bien de partager le tableau de la
> > page
> >
> https://wiki.openstreetmap.org/wiki/France/Liste_des_r%C3%A9f%C3%A9rences_nationales
> > (1) en deux parties :
> > - une première partie avec les références qui s'appliquent sur
> > l'ensemble du territoire (ref:FR:ARCEP=* ; ...) en y ajoutant celles que
> > j'ai trouvées dans le wiki (2)
> > - une partie pour les autres (ref:FR:CRTA=*en Aquitaine ;
> > ref:FR:BSPP:=* ; ref:FR:RATP=*) en y ajoutant celles que j'ai
> > trouvées dans le wiki (3)
> > - Faut-il y ajouter ref:FR:TransGironde et ref:FR:CUB qui sont dans osm
> > et que je n'ai pas trouvées dans le wiki ?
> >
> > Qu'en pensez-vous ?
>
> Sur le partage, que du bien. Et peut-être "l'ordonner" voire le découper
> par thème ?
> Il me semble que j'en avais déjà parlé, sans grand succès...
>
> --
> deuzeffe - qui n'a pas oublié la page transport à toiletter.
>
> ___
> 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] Fwd: [OSM-dev] OpenStreetMap Carto release v4.25.0

[François Lacombe]

Le dim. 2 févr. 2020 à 18:41, pepilepi...@ovh.fr  a
écrit :

> Le 02/02/2020 à 14:50, Stéphane Péneau a écrit :
>
> Ça m'a tout cassé mes jolies haies  :-(((
>
> https://www.openstreetmap.org/#map=19/47.09460/-1.35571
>
> Natural=scrub est-il incompatible ici ? (si tu veux retrouver tes jolies
> haies...)
>

C'est plutôt pour la broussaille basse, les haies peuvent être composées
d'arbres à part entière.
Et le rendu vert kaki reflète peu la broussaille qu'on trouve ici je trouve

Le dim. 2 févr. 2020 à 19:34,  a écrit :

> Sauf que Stéphane a bien mis area=yes.
>
> https://www.openstreetmap.org/way/458961507
>
> Stéphane, je crois que tu vas pouvoir ouvrir un ticket sur le sujet.
>
Le parti pris est bien de ne plus supporter area=yes sur barrier=hedge
(sans me prononcer si c'est bien ou mal)
https://github.com/gravitystorm/openstreetmap-carto/pull/3844

Bonne soirée

François
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Remplacer ref:ERDF:gdo par ref:FR:Enedis / ref:FR:gdo

[François Lacombe]

Bonjour à tous,

La migration a été faite hier soir, pour les nœuds et chemins uniquement
sur un peu plus de 2800 objets.
Il reste 2 relations et 2 occurrences dérivées de ref:ERDF:gdo à traiter
dans les prochaines heures.
Merci de ne plus utiliser ref:ERDF:gdo et de vous reporter exclusivement
sur ref:FR:gdo à partir de maintenant.
N'hésitez pas à compléter les objets visibles autour de chez vous,
compléter ce tag a de la valeur pour lier ces points avec d'autres jeux de
données.

Pas de problèmes à signaler
C'est une bonne expérience à faire pour s'apercevoir des cas d'usage de la
clé et de prendre les meilleures mesures pour mieux guider les
contributeurs.
Cela a aussi été l'occasion de reprendre plusieurs objets, convertir des
nœuds en bâtiments et vice versa.
La qualité globale des données a augmenté normalement, il faut continuer :)

Il va donc s'agir maintenant d'étendre l'utilisation de ref:FR:gdo au
installations de distribution de gaz.
La documentation va finir d'être mise à jour et des tickets créés vers les
éditeurs pour améliorer le contrôle qualité.

Bonne fin d'après-midi

François

Le sam. 7 déc. 2019 à 15:57, François Lacombe  a
écrit :

> Salut à tous,
>
> La motivation de Stéphane sur ref:INSEE m'a motivé pour proposer un autre
> changement sur une clé de référence.
> Il sera pour ma part moins important en volume concerné. Il porterait sur
> le remplacement automatique de ref:ERDF:gdo en ref:FR:Enedis ou ref:FR:gdo
> sur 2700 objets.
> https://wiki.openstreetmap.org/wiki/FR:Key:ref:ERDF:gdo
>
> La justification est de deux ordres :
> - ERDF n'existe plus
> - La référence est propre à la France et ne comporte pas FR. Je trouve que
> ce serait une bonne chose
> => ref:FR:Enedis pourrait convenir
>
> Nous utilisons ref:ERDF:gdo pour documenter les réseaux électriques mais
> le Guide Des Ouvrages est partagé avec les gaziers de GRDF.
> Ainsi ref:FR:gdo permettrait aussi de documenter les affleurant gaziers
>
> N'hésitez pas à donner votre avis sur cette proposition, en tenant compte
> de la volumétrie d'usage :
> https://taginfo.openstreetmap.org/keys/?key=ref%3AERDF%3Agdo
>
> Ce peut aussi être l'occasion de nettoyer un peu les données, parce que
> beaucoup de ces refs sont aussi dans ref=* et pas dans ref:ERDF:gdo
> actuellement.
>
> 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] Opportunité de promouvoir OSM : Démonstration T'dat'hack les 31/01 et 01/02

[François Lacombe]

Bonsoir Brice

L'événement est bien maintenu et aura lieu de vendredi midi à samedi midi
Malheureusement les équipes ont été constituées il y a 15 jours et les
accréditations déjà envoyées.

C'est dommage de ne pas avoir pu nous entendre avant la semaine dernière
pour que tu y participes.
Peux-tu te libérer vendredi à partir de 13h ou uniquement le soir ?

François

Le mar. 28 janv. 2020 à 22:14, Brice  a écrit :

> Le 18/12/2019 à 23:11, François Lacombe a écrit :
> > L'Association des Villes et Collectivités Câblées (AVICCA) organise sur
> deux jours, les 31/01 et 01/02, un hackathon un
> > peu particulier à La Paillasse à Paris à destination de ses membres.
> > http://www.avicca.org/actualite/tdathack-territoires-data-et-telecoms
> > http://www.avicca.org/content/tdathack
> (...)
> > Il n'est pas nécessaire d'être familier avec ce domaine de contribution
> pour venir assister les participants. La
> > connaissance et la culture autour d'OSM est ce qui est le plus recherché
> et nous avons ici une belle tribune il me semble.
>
> Bonsoir François,
>
> Cette manifestation est-elle bien maintenue ?
> Je pense pouvoir passer vendredi soir, est-ce le bon moment pour apporter
> un peu de savoir-faire concernant OSM ?
> D'autres contributeurs OSM seront-ils présents ?
>
> Brice Mallet aka Britzz
>
> ___
> 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 NRO : blocage d'un contributeur à envisager ?

[François Lacombe]

Le dim. 26 janv. 2020 à 22:19, deuzeffe  a écrit :

>
> Cépabien ^^
> (dit celle qui ne taggue pas les name pour les points de distribution -
> j'ai bon ? - en building pour ne pas qu'ils soient rendus :P)
>

Les sous-répartiteurs cuivre et certaines armoires fibre peuvent aussi
avoir des noms d'usage.

Pour que tout le monde comprenne, on ne tague pas en building lorsque c'est
une armoire parce que man_made=street_cabinet et building=* sont
strictement incompatibles.
Aucun technicien ne peut physiquement rentrer dans une armoire, un bâtiment
si.
Les sous-répartitions comme les nœuds de raccordement peuvent
indépendamment être en bâtiment ou en armoire, mais jamais les deux en même
temps, même si on dessine l'armoire comme un polygone.
Si le rendu veut les matérialiser aux zooms les plus forts, il utilisera
man_made=street_cabinet.

Voir les 1ere lignes de
https://wiki.openstreetmap.org/wiki/FR:Tag:man_made%3Dstreet_cabinet


> Peut être que quand les bases des opé seront en OD, on y verra plus clair
> ^^
>

En ce moment c'est précisément pour inciter les opérateurs à ouvrir leurs
données que nous ajoutons tous ces objets
Les comparaisons avec les référentiels internes montrent des différences
sensibles, parfois de plusieurs km, c'est un fait.
Ainsi la contribution peut les aider à corriger tout ça.

François
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Ajout de NRO : blocage d'un contributeur à envisager ?

[François Lacombe]

Salut à tous,

Eric est l'un des contributeurs les plus actifs sur les réseaux télécoms en
France
Je vais essayer de comprendre ce qu'il a essayer de faire. Nous échangeons
souvent sur Twitter, il n'est pour moi pas question de bloquer un
utilisateur comme lui.

Le sam. 25 janv. 2020 à 21:08, Romain MEHUT  a
écrit :

> Donc ce contributeur ajoute en grand nombre des "NRO". 1ère chose que je
> lui ai fait remarquer est qu'il n'y a pas lieu que ces objets aient un tag
> name.
>

Tous les noeuds de raccordement cuivre ont un nom d'usage, bien souvent le
nom du quartier desservi ou la ville concernée.
Par ailleurs, name=NRO c'est taguer pour le rendu certes. J'ai moi aussi
cette mauvaise habitude.


> 2ème chose, il a ajouté des NRO alors que préexistaient des objets
> man_made=telephone_office et telecom=central_office et ces tags sont
> aujourd'hui dépréciés cf.
> https://wiki.openstreetmap.org/wiki/Tag:telecom%3Dexchange Il
> conviendrait donc de reprendre les tags des objets existants plutôt qu'en
> ajouter des nouveaux.
>

Comme la doc le précise :
https://wiki.openstreetmap.org/wiki/FR:Tag:telecom%3Dexchange#Cas_de_multiples_noeuds_dans_le_m.C3.AAme_b.C3.A2timent
Lorsqu'il y a plusieurs medium desservis dans le même batiment, les noeuds
sont séparés.
Il a simplement créé le NRO sur un noeud dédié parce qu'il reste un NRA
cuivre dans le bâtiment.
Normalement il devrait y avoir deux noeuds mais il explique ne pas avoir
voulu toucher le polygone pour l'instant.

Le cuivre et la fibre vont cohabiter encore pour quelques années. Lorsque
le NRA cuivre disparaîtra, on supprimera le nœud dans toucher au NRO fibre.


> Et malgré mes remarques, il a continué à contribuer sans en tenir compte
> ex : https://www.openstreetmap.org/node/7156119118.
>

Ce site semble bien être mixte, sa contribution est la bonne.

Je sais que le sujet est technique et déroutant, mais il semble que les
pratiques soient bien adaptées ici.
Il faut en tenir compte.

Le sam. 25 janv. 2020 à 23:42, deuzeffe  a écrit :

>
> Va falloir faire une sacré ménage :(
>

Oui c'est bien ce qui se manifeste ici
https://wiki.openstreetmap.org/wiki/FR:Tag:telecom%3Dexchange#Possibles_erreurs

Mais le dernier modèle voté en 2018 est vraiment beaucoup mieux que le
précédent et ce ménage vaut le coup.

Bonne soirée

François
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Proposition - RFC - Organisation des lignes aériennes (consécutive à line_attachment)

[François Lacombe]

Salut à tous,

Nouvelle année, nouvelles propositions. Voici celle que je souhaite pousser
en premier.
Elle est formulée dans le cadre du nettoyage de tower:type et d sa
suppression complète des supports électriques.
Expliqué il y a quelques temps dans mon journal :
https://www.openstreetmap.org/user/InfosReseaux/diary/391058

Elle concerne la topologie et l'organisation des lignes aériennes
(électriques mais pas que).
https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Lines_management

La RFC a déjà commencé depuis quelques temps sur la ML internationale, je
viens de finir de traduire en français.
La clé est déjà utilisée à quelques endroits par d'autres utilisateurs.

Il me manque des photos libres de situations comme celle-ci :
https://wiki.openstreetmap.org/wiki/File:Power_line_chart_pole_loop.png
pour compléter les exemples
Si quelqu'un a quelque chose qui ressemble autour de chez lui, je suis
preneur.

Par ailleurs n’hésitez pas à essayer de transcrire ce que vous verriez sur
le terrain avec les valeurs proposées pour s'assurer que tout fonctionne
bien
Auquel cas on pourra compléter les exemples si nécessaire.
Certaines valeurs marchent même pour les remontées mécaniques si vous allez
au ski (tout comme line_attachment=pulley)

Merci par avance pour vos commentaires et bon weekend

François
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Il est partout, quelle énergie (à faire parfois quand même !)

[François Lacombe]

Bonjour et merci Vincent,

On a eu un bon échange avec la journaliste. Et le propos dans l'émission a
plutôt bien traduit tout ca donc c'est super.

Je sais que le profit n'est pas ce qui nous anime ici, et que la
rétribution prend bien d'autres formes que la rentabilité financière.
Par contre c'est un indicateur intéressant que de savoir quelle quantité
d'énergie des institutions est économisée par les contributions sur OSM.
Le chiffre donné par Gabriel Attal sur les bénévoles des restos du cœur
donne déjà une idée (bien que sûrement imparfait)

On verra si à l'avenir des progrès sont fait pour l'évaluer.

François

Le ven. 17 janv. 2020 à 16:17, Jacques Lavignotte 
a écrit :

>
>
> Le 17/01/2020 à 15:27, Vincent Bergeot a écrit :
>
> > François Lacombe a réussi à placer OpenStreetMap :)
>
> Oui ! En live ce matin.
>
> Bravo !
>
> Vraie question que la valorisation du bénévolat...
>
> J.
>
> --
> GnuPg : 156520BBC8F5B1E3 Because privacy matters.
> On mangera ? (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] Deleting template parameters copied to data items

[François Lacombe]

Hi Frederik

Le ven. 17 janv. 2020 à 16:05, Frederik Ramm  a écrit :

> Over the years, a couple of people have time and time again suggested
> that we get down and make a nice, curated, text-based catalogue of tags
> maintained by a team, potentially on a git-like system where pull
> requests can be submitted by everyone, but maintainers have to approve
> them.
>
> I was always on the fence about this, because it would install a
> maintainer team with more powers than the average user. But in the face
> of a wiki that is more and more moving into a direction where you need
> to have a degree in Wikidata to even participate, and where anything you
> contribute will be mowed over three times by this bot and that bot in
> order to fit into some structure that someone else has devised with
> practically zero community oversight, I think I'll prefer the git-based
> human-readable "tag atlas".
>

Could you please elaborate a bit more on why by human for human is the only
thing that exists in our landscape?
Don't we have tools that actually rely on that documentation to work and we
should take care of this as well?

In a really practical approach, I'm fed up to maintain sync in dozen of
translated pages containing the exact same template with the exact same
information.
DataItems would keep anyone able to document the tag as we do now instead
of a centralised git system with pull requests.
It's ok to say that as any brand new thing it will require further
development to be perfect. IMHO my contributions are more usable and
efficient on items than on many-same-wikitemplates.

OSM semantics and tagging model are also a thing and delivering it in a
structured database could make it usable at a really larger scale than now.
It's more about organizing knowledge than human readable documentation.
Time is short to make both in separates repositories.

Best regards

François
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Remplacer ref:ERDF:gdo par ref:FR:Enedis / ref:FR:gdo

[François Lacombe]

Il n'y a pas eu de nouvel échanges dans ce fil

Il me semble donc que je peux procéder à la migration ?
En tout cas passer de ref:ERDF:gdo à ref n'est pas possible sans perdre
l'information sur ce qui est effectivement présent sur le terrain (ref=P 57
vs ref:ERDF:gdo=19132P0057)
Sauf erreur je crois qu'une réponse a été apportée sur tous les points
levés.

Si vous avez une nouvelle objection levez la main assez vite s'il vous plaît

Bonne soirée

François

Le mer. 8 janv. 2020 à 13:33, François Lacombe 
a écrit :

> Bonjour Marc,
>
> Je suis d'accord avec Yves ici
> Ce n'est pas parce qu'un objet ne porte qu'une référence, qu'on ne peut
> pas associer des règles de validation ou de formatage particulières sur
> celle-ci.
> Plus que les tags de l'objet et le contexte d'utilisation de ref=*, il
> faut une clé dédiée à laquelle on associe une doc complète et des règles
> dans les éditeurs.
>
> Même si certaines fois l'exploitant est repris dans le nom de la ref
> (ref:FR:Orange par exemple), ce n'est pas le but de déterminer l'exploitant
> avec la ref;
> Nous n'avons pas le droit de reprendre systématiquement le nom du
> référentiel à cause de la propriété intellectuelle, donc on utilise la
> marque à la place qui correspond au nom de l'exploitant.
>
> Je serai bien embêté si il fallait exprimer sur la même page les règles
> pour ref:FR:gdo et ref:FR:FINESS. Ce n'est pas du tout la même chose, ce
> serait éminemment plus complexe à valider aussi.
>
> Voir aussi les objets qui portent plusieurs ref : ref:FR:ARCEP +
> ref:FR:Orange (avoir ref + ref:FR:Orange n'a pas plus de sens que
> ref:FR:ARCEP + ref)
>
> On utilise enfin les namespaces parce que ces règles, concepts et
> référentiels sont spécifiques à la France et peuvent collisionner ailleurs
> dans le monde.
>
> Le mar. 7 janv. 2020 à 16:20, marc marc  a
> écrit :
>
>> Bonjour,
>>
>> Le 07.01.20 à 16:01, Quentin Salles a écrit :
>> > Pouvez-vous me confirmer que l'usage de la clé "ref:FR:gdo" est bien
>> actif ?
>>
>> Nous n'avions pas terminé la discussion sur la migration.
>> Je te conseille d'utiliser l'ancienne clef en attendant, puisque
>> c'est elle qui est la façon de faire actuellement.
>>
>
> Je n'ai pas fait la migration, pour l'ancienne clé reste valable.
> Y a-t-il d'autres points à discuter ?
>
>
>> je vais faire une comparaison avec les routes :
>> en lisant une référence sur le panneau d'une route, cette référence
>> se retranscrit dans la clef ref=numéro et ceci indépendamment de
>> l'opérateur ou du pays.
>>
>
> Parce qu'on traduit avant tout ce qu'on lit sur le terrain sans chercher à
> la rapprocher d'un référentiel quelconque.
>
>
>> on n'utilise pas non plus d'espace de nom du genre ref:FR:auteur
>> pour préciser qui serrait l'auteur de la ref.
>> on n'utilise pas non plus de mot dans la clef pour donner le sens de
>> cette référence ou le terme légal que celui-ci aurait dans la loi.
>>
>
> Et on pourrait, mais le domaine routier n'est pas le meilleur pour
> produire des référentiel, je ne connais pas le nom de la base de données
> qui attribue les numéros de routes.
>
>
>> A l'inverse, dans le domaine énergétique (et des transports), au fil
>> du temps, on utilise des espaces de nom pour la clef ref en France,
>> sans que je perçoive ni le besoin ni même l'intérêt.
>>
>> Au final l'utilisateur qui lit une ref quelque part, ne peux pas
>> l'ajouter dans osm sans devoir chercher dans le wiki quel est la règle
>> particulière qui régit cet objet dans ce pays.
>>
>
> C'est nécessaire parce qu'on a besoin de formater cette valeur par rapport
> à ce qui est lu sur le terrain : infos incohérentes, valeurs partiellement
> effacées, techniciens fatigués...
>
>
>> cela nuit à mon avis grandement à l'encodage simple et même à
>> l'utilisation (essayez donc de connaître le nombre de power=substation
>> au niveau mondial qui ont une ref, vous devez écrire une règle qui dit
>> que cela peux être ref ou ref:* chose que de nombreux outil tel que
>> tainfo ou overpass ne permettent pas ou pas facilement)
>>
>> > Est-il possible de remonter l'information
>> > via l'Open data. Si oui, est-il permis d'ajouter ces informations non
>> > visibles sur le terrain ?
>>
>> bien sur, osmose ne propose rien sur le sujet ?
>> https://osmose.openstreetmap.fr/fr/map/
>
>
> Pas encore mais la migration va être l'occasion d'ajouter de la validation
> dans JOSM et Osmose quand j'aurais le temps de m'en occuper.
> * substation=minor_distribution + operator=Enedis + ref=* => Alerte, il
> manque ref:FR:gdo
> * operator!=Enedis;GRDF + ref:FR:gdo => Alerte, ce n'est pas possible
>
> Et ainsi de suite
>
> François
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr