Re: [OSM-talk-fr] Hôtels équipés de prises pour voitures électriques ?

2020-01-17 Par sujet Philippe Verdy
Sans doute parce que ce sont leur parking qui sont tagués.

Aussi parce que la plupart des hôtels sont tagués comme des noeuds (parfois
sur le noeud d'adresse FANTOIR, en limite de propriété, ou de bâtiment dans
les rues urbaines). Noter qu'on ne peut pas toujours taguer le batiment
lui-même qui a plusieurs adresses et des services différents, parfois aussi
des résidences privées.

De plus si ce sont des équipements des hôtels eux-mêmes, ils sont sur des
parkings privés (en principe fermés la nuit par une barrière et un digicode
pour appeler le gardien, ou bien dans un garage où ce n'est pas forcément
visible et encore moins facile à taguer).

Nombre d'hôtels sont ajoutés dans OSM par des agences à partir des données
que leur fournissent les hôtels ou chaines d'hôtel, qui ont sans doute omis
de mentionner ça, ou bien l'agence n'a pas su taguer cet équipement (sur le
noeud/way/relation, sur le bâtiment ou le parking ou une relation indiquant
toute la dépendance hôtelière (autour de l'enceinte, incluant le batiment,
les jardins, cours, parkings et voies privées).

Si ce sont des équipements privés, non accessibles au public, je pense
qu'il vaut mieux ne pas taguer comme un "amenity=*" qui désigne plutôt les
bornes accessibles au public, pas forcément client de l'hôtel et qui a le
droit d'y stationner. Mais on a bien des amenity=parking avec
access=private ou permissive et cela n'indique pas clairement le droit
d'accès à la recharge, même pour les clients, ce n'est pas nécessairement
gratuit, même pour eux où la recharge sera comptée sur leur facture de
séjour en utilisant leur carte électronique d'accès qui ouvre aussi et
identifie la chambre louée.

Les recharges privées pour l'instant sont hors périmètre. Ne pas les mettre
dans OSM pour ne pas tenter des visiteurs indélicats qui viendrait occuper
le parking et recharger gratuitement. Il vaut mieux que ce soit l'hôtel qui
indique lui-même les conditions d'accès qui peuvent aussi être différentes
de celles du parking.


Le sam. 18 janv. 2020 à 02:10, Shohreh  a écrit :

> Bonjour,
>
> La requête suivante pour trouver tous les hôtels en France qui proposent
> une
> prise pour recharger une voiture électrique… ne renvoie rien :
>
> =
> [out:json][timeout:60];
>
> //France métrop : 1403916
> rel(1403916);
> map_to_area -> .searchArea;
>
> (
>   node[tourism=hotel][amenity=charging_station](area.searchArea);
>   way[tourism=hotel][amenity=charging_station](area.searchArea);
> );
>
> out center;
> =
>
> Je m'y prends mal ou personne n'a taggé d'hôtels avec ça ?
>
> Merci.
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>
> ___
> 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] Hôtels équipés de prises pour voitures électriques ?

2020-01-17 Par sujet Christian Quest

Les deux tags sont sûrement sur des objets séparés.

J'ai rajouté des IRVE qui étaient parfois dans des parking d'hôtels (cas 
de Tesla) et c'est à l'emplacement des places de parking dédiées que 
c'est taggué, pas sur l'hôtel lui même.


Exemple: https://tile.openstreetmap.fr/?zoom=19=49.2=-0.13114


Le 18/01/2020 à 02:09, Shohreh a écrit :

Bonjour,

La requête suivante pour trouver tous les hôtels en France qui proposent une
prise pour recharger une voiture électrique… ne renvoie rien :

=
[out:json][timeout:60];

//France métrop : 1403916
rel(1403916);
map_to_area -> .searchArea;

(
   node[tourism=hotel][amenity=charging_station](area.searchArea);
   way[tourism=hotel][amenity=charging_station](area.searchArea);
);

out center;
=

Je m'y prends mal ou personne n'a taggé d'hôtels avec ça ?

Merci.


--
Christian Quest - OpenStreetMap France


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


[OSM-talk-fr] Hôtels équipés de prises pour voitures électriques ?

2020-01-17 Par sujet Shohreh
Bonjour,

La requête suivante pour trouver tous les hôtels en France qui proposent une
prise pour recharger une voiture électrique… ne renvoie rien :

=
[out:json][timeout:60];

//France métrop : 1403916
rel(1403916);
map_to_area -> .searchArea;

(
  node[tourism=hotel][amenity=charging_station](area.searchArea);
  way[tourism=hotel][amenity=charging_station](area.searchArea);
);

out center;
=

Je m'y prends mal ou personne n'a taggé d'hôtels avec ça ?

Merci.



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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


Re: [OSM-talk-fr] Trottoir traversant

2020-01-17 Par sujet Florimond Berthoux
Le ven. 17 janv. 2020 à 10:37, marc marc  a
écrit :
>
> Je trouve que tu fais compliqué :)

En bon ingénieur j'énumère toutes les possibilités pour sélectionner la
meilleure à la fin ;)

> une route et un trottoir se croise, donc un nœud d'intersection
> "passage piéton" highway=crossing + crossing=uncontrolled probablement
> pour le niveau de sécurité + crossing_ref=no probablement
> pour le type (lié au marquage en fr be ch) + kerb=no

En fait il y a bien un kerb «A kerb (American English curb) is the edge
where a road meets a sidewalk.» https://wiki.openstreetmap.org/wiki/Key:kerb
Sauf que pour le trottoir traversant c'est la voiture qui se le prend cette
fois, puisque le piéton lui reste sur le trottoir !
Après, on pourrait interpréter le tag comme étant du point de vue du
piéton, mais ce n'est pas définit comme cela.

> si tu veux maintenant ajouter du détail pour dire en linéaire
> la longueur de ce croissement pour chaque usager :
> - pour la voiture, c'est un plateau traffic_calming=table
> sur le way voiture.
> côté voiture, je vois pas de différence entre traverser
> un plateau passage piéton avec marquage (les ""anciens"" trottoir
> traversants qui existent depuis des années) et un plateau
> passe piéton trottoir traversant).
> tout autre tag me semble donc superflu ou erroné.
> est-ce qu'il y a une différence dans la loi ?

Premier point, il y a différent type de trottoir traversant plus ou moins
cassant pour une voiture, alors qu'un plateau traversant c'est bien
réglementé (en France en tout cas).
Second point, sur un plateau traversant il y a toujours une délimitation
route/trottoir même s'ils sont censés être à niveau.
Troisième point légal, en France, une voiture qui traverse un trottoir
traversant traverse un trottoir (eh eh) et doit donc cédez le passage à
tous à l'intersection (Article 415-9
https://www.legifrance.gouv.fr/affichCodeArticle.do;jsessionid=6ED1C96581529BBCE4CD62E5C0D68704.tplgfr41s_3?idArticle=LEGIARTI23095968=LEGITEXT06074228=20200117
)

> - pour le piéton, il y a 2 incohérences dans ce que tu dis.
> la clef crossing sert a décrire le passage piéton (le nœud même
> si certain duplique l'info du passage 3 fois).
> crossing=continuous n'est donc pas une bonne idée pour décrire
> l'étendue du cheminement de voie le composant.
> par ailleurs si tu considères qu'un trottoir traversant est un trottoir,
> alors ce n'est pas un passage piéton, c'est highway=path path=sidewalk
> si c'est pas tout a fait un trottoir (peut-on s'y arrêter pour faire
> ses lacets ou discuter avec un autre pendant 5 min ? j'en doute),
> alors highway=path path=continuous_sidewalk ou qlq chose du genre.

C'est un vrai trottoir et tu peux jouer à la marelle dessus, c'est comme
une entrée charretière, après personne n'a le droit d’empêcher l'autre de
passer ;)
Oui crossing ça veut vraiment dire passage pour traverser la grosse voie
(route, chemin de fer, rivière...).

Et le mot anglais pour intersection c'est ... junction
https://wiki.openstreetmap.org/wiki/Key:junction
«This key describes how a specific junction is constituted. »
Perfect, aujourd'hui utilisé pour les différents rond-point (à priorité à
droite ou à priorité à l'anneau par exemple) donc pour définir à la fois la
forme physique et l'aspect légal.
On peut imaginer :
junction=continuous_sidewalk/continuous_cycleway

Donc je me suis essayé à modéliser ce magnifique trottoir traversant que je
connais bien https://www.openstreetmap.org/#map=19/48.87867/2.35428

Donc deux nœuds d'intersection avec
junction=continuous_sidewalk/continuous_cycleway
https://www.openstreetmap.org/node/652025857
https://www.openstreetmap.org/node/7140053012

Un bout de rue piétonne sur trottoir :
traffic_calming=continuous_sidewalk
highway=pedestrian
pedestrian=sidewalk (cette portion de segment est sur trottoir)
kerb=no
https://www.openstreetmap.org/way/25704593

Une piste cyclable :
cycleway=continuous
highway=cycleway
kerb:left=lowered
kerb:right=flush
https://www.openstreetmap.org/way/764269695

Un chemin piéton :
highway=footway
footway=continuous_sidewalk
kerb:left=lowered
kerb:right=flush
https://www.openstreetmap.org/way/764269695

Avec ça on est blindé :D

-- 
Florimond Berthoux
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Live HS - lié au lag de osm108 ? lui même lié aux modifs de nombreuses relations communales ?

2020-01-17 Par sujet Cédric Frayssinet

Merci Jocelyn pour avoir remis à temps le serveur en fonctionnement.

Ce matin, j'ai eu droit à des wouahh, tout ça (en voyant le nombre de
contributeurs en quelques dizaines de minutes), mais ils sont payés tous
ces contributeurs ?

Bref, c'est un service indispensable pour une présentation rapide sur OSM.

Cédric

Le 17/01/2020 à 13:08, Jocelyn Jaubert a écrit :
> Bonjour,
>
> On Wed, Jan 15, 2020 at 05:38:51PM +0100, Cédric Frayssinet wrote:
 Je voulais présenter le live à mes élèves aujourd'hui mais cela semble
 casser. Ce matin, c'était très lent, actuellement, il ne fonctionne
 pas.

 https://live.openstreetmap.fr/
>>> il y a du lag dans la generation des diffs dans l'infra osm-fr
>>> http://munin.openstreetmap.fr/osm12.openstreetmap.fr/osm108.openstreetmap.fr/osm_replication_lag_osmbin.html
>>> qui semble caussé par le traitement des modifs des relations communales.
> En fait, je crois que c'était plutôt causé à un souci sur la VM, qui saturait
> en mémoire. Je l'ai redémarré, et c'est reparti correctement.
>
>>> De mémoire, live utilise les diffs depuis le serveur ci-dessus.
>>> Jocelyn avait prévu un moyen de les contourner en cas de lag
>>> Je le prévient.
> live pointait déjà sur les diffs d'osm.org. J'ai quand même modifié la config 
> du serveur pour:
>   - prendre les diffs par défaut depuis osm-fr
>   - si le dernier diff est <= au précédent, alors récupérer les diffs depuis 
> osm.org
>
>
> Ça devrait corriger tout souci futur dans le cas de délai sur la génération 
> des diffs d'osm-fr.
>
>
> Merci,
> Jocelyn
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr


-- 

Sur Mastodon : @bristow...@framapiaf.org 

Promouvoir et soutenir le logiciel libre 

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


Re: [OSM-talk-fr] adresse mail rejetée - premières modifs

2020-01-17 Par sujet leni


Le 16/01/2020 à 23:48, Florian_G a écrit :

Hello,

Le 16/01/2020 à 18:49, Sébastien Dinot a écrit :

marc marc a écrit :

J'ai fait quelques modifs pour rendre la liste temporairement "plus
relax" au niveau des bounces

À la bonne heure ! Depuis décembre, je dois me faire virer de la liste
2 à 3 fois par semaine. Je réactive mon abonnement dès que je reçois le
message de notification, mais c'est pénible.

Pareil pour moi, et ça fait 2-3 mois que ça dure, à vue de nez (je n'ai
pas conservé les traces).

Et plus d'un an que je ne reçois plus les messages de Philippe Verdy (je
pensais qu'il avait quitté la liste
Je pensais aussi la même chose et après avoir été jeté x fois j'ai 
changé mon adresse (mais pénible d'avoir été obligé de le faire)

) : le dernier que j'ai reçu avec son
adresse Wanadoo date du 30/10/2018 puis 02/03/2019 et plus rien jusqu'au
08/01/2020 mais avec son adresse Gmail cette fois-ci. Et puis c'est tout.

++



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

2020-01-17 Par sujet 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-fr] Il est partout, quelle énergie (à faire parfois quand même !)

2020-01-17 Par sujet Jacques Lavignotte



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


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

2020-01-17 Par sujet Vincent Bergeot

François Lacombe a réussi à placer OpenStreetMap :)

Travail invisible, travail gratuit : à qui profitent nos activités non 
rémunérées ?


https://www.franceculture.fr/emissions/hashtag/hashtag-chronique-du-vendredi-17-janvier-2020

Cela dure 5'

Bonne écoute

--
Vincent Bergeot


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


Re: [OSM-talk-fr] Manque d'attribution, supprimer les cas résolus - wiki

2020-01-17 Par sujet Eric
Bonjour,

Je pense que c'est bien de garder les OK sur la même page pour vérif
périodique de "non rechute". Par exemple,
https://carto.cdata.cerema.fr/1/pnb_action7_ff_2019.map
qui était dans les sujets clos ne me semble toujours pas correct.

Eric [Blueberry]

Le ven. 17 janv. 2020 à 13:43, Donat ROBAUX  a écrit :

> Je suis de l'avis de Marc: restons KISS
> A la limite réservons le Githut aux cas problématiques et récalcitrants.
>
> Donat
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>
> ___
> 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] Types de prises IRVE

2020-01-17 Par sujet emeric Prouteau
Merci pour vos réponses.

J'utilise le fichier propre à la nouvelle aquitaine :
https://www.data.gouv.fr/fr/datasets/infrastructures-de-recharge-pour-vehicules-electriques-mobive-1/

Merci pour la correspondance des tags.

Pour mon process d'intégration, j'utilise FME en entrée je mets le fichier
en opendata et en sortie je fais un geojson avec les bons tags OSM d'ou ma
question :) pour le type.

Une partie des données à déjà été intégré du coup c'est plus un complément
et une MAJ.



Le ven. 17 janv. 2020 à 13:35, Noémie Lehuby via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Hello,
>
> je suis en train de bosser sur l'intégration osmose (en prévision d'un
> projet du mois) :)
>
> Voici une page de wiki avec le mapping entre l'open data et OSM :
> https://wiki.openstreetmap.org/wiki/France/data.gouv.fr/Bornes_de_Recharge_pour_V%C3%A9hicules_%C3%89lectriques
>
> Pour les prises :
>
>- EF correspond à socket:typee
>=*
>- T2 - EF veut dire qu'il y a deux prises sur le point de recharge
>(une T2 et une EF)
>
> --
> Noémie Lehuby
> Jungle Bus - http://junglebus.io
>
> Le 17/01/2020 à 13:08, PanierAvide via Talk-fr a écrit :
>
> Bonjour,
>
> IRVE = Infrastructure de recharge de véhicule électrique
>
> Cordialement,
>
> Adrien P.
>
> Le 17/01/2020 à 12:46, marc marc a écrit :
>
> Bonjour,
>
> Le 17.01.20 à 12:29, emeric Prouteau a écrit :
>
> Je souhaite intégrer les IRVE
>
> VE ok mais IRVE c'est quoi ?
> wikipedia ne connait que https://en.wikipedia.org/wiki/IRVE
>
> manquantes de Dordogne basé sur la donnée mobive disponible sur data.gouv.
>
> de combien d'objet parle-t-on ?
> ayant corrigé des horreurs de précédent import un peu partout
> cela serrait sûrement profitable de faire une conversion propre via
> osmose une fois pour toute.
>
> Le wiki : https://wiki.openstreetmap.org/wiki/Key:socket
>* CHADEMO (Ca c'est Ok)
>
> socket:chademo :)
>
>* COMBO
>
> socket:type2_combo
>
>* EF
>* T2 - EF
>
> je ne connait pas, une photo ?
> dans la base osm, il y a UN socket=EF-T3 (justement
> un import qui ne respecte pas la syntaxe courante)
>
>* T2
>
> socket:type2
>
> 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
>


-- 
*Emeric PROUTEAU*



*emeric.prout...@gmail.com Avant d'imprimer.
Pensons à l'environnement.Save paper. Do you really need to print this
e-mail?*
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Manque d'attribution, supprimer les cas résolus - wiki

2020-01-17 Par sujet Donat ROBAUX
Je suis de l'avis de Marc: restons KISS
A la limite réservons le Githut aux cas problématiques et récalcitrants.

Donat



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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


Re: [OSM-talk-fr] Types de prises IRVE

2020-01-17 Par sujet Noémie Lehuby via Talk-fr

Hello,

je suis en train de bosser sur l'intégration osmose (en prévision d'un 
projet du mois) :)


Voici une page de wiki avec le mapping entre l'open data et OSM : 
https://wiki.openstreetmap.org/wiki/France/data.gouv.fr/Bornes_de_Recharge_pour_V%C3%A9hicules_%C3%89lectriques


Pour les prises :

 * EF correspond à socket:typee
   =*
 * T2 - EF veut dire qu'il y a deux prises sur le point de recharge
   (une T2 et une EF)

--
Noémie Lehuby
Jungle Bus - http://junglebus.io

Le 17/01/2020 à 13:08, PanierAvide via Talk-fr a écrit :

Bonjour,

IRVE = Infrastructure de recharge de véhicule électrique

Cordialement,

Adrien P.

Le 17/01/2020 à 12:46, marc marc a écrit :

Bonjour,

Le 17.01.20 à 12:29, emeric Prouteau a écrit :

Je souhaite intégrer les IRVE

VE ok mais IRVE c'est quoi ?
wikipedia ne connait que https://en.wikipedia.org/wiki/IRVE

manquantes de Dordogne basé sur la donnée mobive disponible sur 
data.gouv.

de combien d'objet parle-t-on ?
ayant corrigé des horreurs de précédent import un peu partout
cela serrait sûrement profitable de faire une conversion propre via
osmose une fois pour toute.


Le wiki : https://wiki.openstreetmap.org/wiki/Key:socket
   * CHADEMO (Ca c'est Ok)

socket:chademo :)


   * COMBO

socket:type2_combo


   * EF
   * T2 - EF

je ne connait pas, une photo ?
dans la base osm, il y a UN socket=EF-T3 (justement
un import qui ne respecte pas la syntaxe courante)


   * T2

socket:type2

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] Manque d'attribution, supprimer les cas résolus - wiki

2020-01-17 Par sujet Guillaume Rischard
Tu as raison, ça serait mieux en plus d’utiliser une solution open source.

En attendant, ça a l’avantage d’exister et de marcher. Si un jour l’OSMF 
héberge par exemple son propre gitlab, on pourrait y passer.

Guillaume

> On 17 Jan 2020, at 12:17, marc marc  wrote:
> 
> le défaut étant d'être un tier (github),
> donc les contributeurs après s'être inscrit ici, sur osm, sur le wiki
> doivent s'inscrire une fois de + alors qu'il n'est deja pas motivant
> pour certain d'aller consigner leur signalement quelque part..
> 
> une interface web permettant de s'identifier avec son compte osm
> serait agréable
> 
> Le 17.01.20 à 12:04, Guillaume Rischard a écrit :
>> Bonjour,
>> 
>> Cette page wiki est difficile à suivre. Je vous propose
>> d’utiliser https://github.com/grischard/osm-lacking-attribution 
>>  qui
>> permet une gestion individuelle et systématisée au cas par cas, et est
>> activement lu et utilisé par le CA de la fondation OSM ;).
>> 
>> Guillaume
>> 
>>> On 14 Jan 2020, at 12:14, Cyrille37 OSM >> 
>>> >> 
>>> wrote:
>>> 
>>> Bonjour à tou·te·s,
>>> 
>>> il me semble qu'il serait plus "poli / respectueux" de supprimer les
>>> cas résolus: les sites qui ont corrigé les attributions sur leurs
>>> cartes. Effectivement, nous avons à priori seulement besoin de suivre
>>> l'avancement des corrections.
>>> 
>>> Si un besoin de mémoire était nécessaire, il pourrait être comblé par
>>> l'historique du wiki, ce qui me parait être un besoin vraiment "à la
>>> marge".
>>> 
>>> J'avais posé la suggestion sur la page de discussion, et à 2 nous
>>> étions d'accord pour supprimer les cas résolus :
>>> https://wiki.openstreetmap.org/wiki/FR_talk:Manque_d%27attribution_appropri%C3%A9e#Suivi_du_tableau
>>> 
>>> Voilà, la proposition est posée :-)
>>> 
>>> 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 
>> 
>> 
> 
> ___
> 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] Live HS - lié au lag de osm108 ? lui même lié aux modifs de nombreuses relations communales ?

2020-01-17 Par sujet Jocelyn Jaubert
Bonjour,

On Wed, Jan 15, 2020 at 05:38:51PM +0100, Cédric Frayssinet wrote:
> > > Je voulais présenter le live à mes élèves aujourd'hui mais cela semble
> > > casser. Ce matin, c'était très lent, actuellement, il ne fonctionne
> > > pas.
> > > 
> > > https://live.openstreetmap.fr/
> > 
> > il y a du lag dans la generation des diffs dans l'infra osm-fr
> > http://munin.openstreetmap.fr/osm12.openstreetmap.fr/osm108.openstreetmap.fr/osm_replication_lag_osmbin.html
> > qui semble caussé par le traitement des modifs des relations communales.

En fait, je crois que c'était plutôt causé à un souci sur la VM, qui saturait
en mémoire. Je l'ai redémarré, et c'est reparti correctement.

> > De mémoire, live utilise les diffs depuis le serveur ci-dessus.
> > Jocelyn avait prévu un moyen de les contourner en cas de lag
> > Je le prévient.

live pointait déjà sur les diffs d'osm.org. J'ai quand même modifié la config 
du serveur pour:
  - prendre les diffs par défaut depuis osm-fr
  - si le dernier diff est <= au précédent, alors récupérer les diffs depuis 
osm.org


Ça devrait corriger tout souci futur dans le cas de délai sur la génération des 
diffs d'osm-fr.


Merci,
Jocelyn

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


Re: [OSM-talk-fr] Types de prises IRVE

2020-01-17 Par sujet PanierAvide via Talk-fr

Bonjour,

IRVE = Infrastructure de recharge de véhicule électrique

Cordialement,

Adrien P.

Le 17/01/2020 à 12:46, marc marc a écrit :

Bonjour,

Le 17.01.20 à 12:29, emeric Prouteau a écrit :

Je souhaite intégrer les IRVE

VE ok mais IRVE c'est quoi ?
wikipedia ne connait que https://en.wikipedia.org/wiki/IRVE


manquantes de Dordogne basé sur la donnée mobive disponible sur data.gouv.

de combien d'objet parle-t-on ?
ayant corrigé des horreurs de précédent import un peu partout
cela serrait sûrement profitable de faire une conversion propre via
osmose une fois pour toute.


Le wiki : https://wiki.openstreetmap.org/wiki/Key:socket
   * CHADEMO (Ca c'est Ok)

socket:chademo :)


   * COMBO

socket:type2_combo


   * EF
   * T2 - EF

je ne connait pas, une photo ?
dans la base osm, il y a UN socket=EF-T3 (justement
un import qui ne respecte pas la syntaxe courante)


   * T2

socket:type2

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] Types de prises IRVE

2020-01-17 Par sujet marc marc
Bonjour,

Le 17.01.20 à 12:29, emeric Prouteau a écrit :
> Je souhaite intégrer les IRVE

VE ok mais IRVE c'est quoi ?
wikipedia ne connait que https://en.wikipedia.org/wiki/IRVE

> manquantes de Dordogne basé sur la donnée mobive disponible sur data.gouv.

de combien d'objet parle-t-on ?
ayant corrigé des horreurs de précédent import un peu partout
cela serrait sûrement profitable de faire une conversion propre via
osmose une fois pour toute.

> Le wiki : https://wiki.openstreetmap.org/wiki/Key:socket
>   * CHADEMO (Ca c'est Ok)

socket:chademo :)

>   * COMBO

socket:type2_combo

>   * EF
>   * T2 - EF

je ne connait pas, une photo ?
dans la base osm, il y a UN socket=EF-T3 (justement
un import qui ne respecte pas la syntaxe courante)

>   * T2

socket:type2

Cordialement,
Marc
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] suivit du cadastre (était : Proposition de mise à jour : la population des communes)

2020-01-17 Par sujet HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT GE PPE)
En fait, je suis partagé entre travail avec méthode +- scientifique et ballade 
au gré des envies (ou du hasard parfois).
Ce qui est lassant dans les contributions régulières et/ou volumineuses c'est 
la monotonie. Aussi, je change régulièrement de sujets (bâti, ferroviaire, 
adresses, occupation du sol, voirie) ou de coin (ça permet de faire du tourisme 
virtuel pour pas cher et de voir comment un territoire est décrit par d'autres 
contributeurs)

Denis, chair-tourist

-Message d'origine-
De : marc marc  
Envoyé : vendredi 17 janvier 2020 12:22
À : talk-fr@openstreetmap.org
Objet : Re: [OSM-talk-fr] suivit du cadastre (était : Proposition de mise à 
jour : la population des communes)

Le 17.01.20 à 12:13, HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT GE PPE) 
a écrit :

> mise à jour de bâti. Je suis presque tenté par la création d'un indice 
> de vieillesse (vieillure ?) des nœuds/ways d'une commune dans OSM, 
> genre la date moyenne de dernière modif des objets (éventuellement par 
> type)

ce serrait une bonne idée pour https://cadastre.damsy.net ceci dit, après avoir 
completé de nombreuses communes niveau du bati, j'en suis arrivé à la 
conclusion que c'est bien difficile de trouver un critère qui permet de dire oü 
il faut aller voir.
le moins mauvais critère que j'ai trouvé : les addresses.
nouveau lotisement = souvent nouvelle adresse.
du coup maintenant je fais systématiquement ajout des addr, ce qui conduit à 
ajout des batiments manquant ___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
---
Ce message et toutes les pièces jointes sont établis à l'intention exclusive de 
ses destinataires et sont confidentiels. L'intégrité de ce message n'étant pas 
assurée sur Internet, la SNCF ne peut être tenue responsable des altérations 
qui pourraient se produire sur son contenu. Toute publication, utilisation, 
reproduction, ou diffusion, même partielle, non autorisée préalablement par la 
SNCF, est strictement interdite. Si vous n'êtes pas le destinataire de ce 
message, merci d'en avertir immédiatement l'expéditeur et de le détruire.
---
This message and any attachments are intended solely for the addressees and are 
confidential. SNCF may not be held responsible for their contents whose 
accuracy and completeness cannot be guaranteed over the Internet. Unauthorized 
use, disclosure, distribution, copying, or any part thereof is strictly 
prohibited. If you are not the intended recipient of this message, please 
notify the sender immediately and delete it. 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


[OSM-talk-fr] Types de prises IRVE

2020-01-17 Par sujet emeric Prouteau
Bonjour,

Je souhaite intégrer les IRVE manquantes de Dordogne basé sur la donnée
mobive disponible sur data.gouv.

Concernant le type de prise je n'arrive pas à tout faire correspondre entre
les valeurs du fichier et les valeur du wiki : socket:...

Quelqu'un pourrait-il m'aider ?

Le wiki : https://wiki.openstreetmap.org/wiki/Key:socket

Les valeurs du fichier :

   - CHADEMO (Ca c'est Ok)
   - COMBO
   - EF
   - T2
   - T2 - EF

Bonne journée,


-- 
*Emeric PROUTEAU*



*emeric.prout...@gmail.com Avant d'imprimer.
Pensons à l'environnement.Save paper. Do you really need to print this
e-mail?*
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] suivit du cadastre (était : Proposition de mise à jour : la population des communes)

2020-01-17 Par sujet marc marc
Le 17.01.20 à 12:13, HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT
GE PPE) a écrit :

> mise à jour de bâti. Je suis presque tenté par la création d'un indice de 
> vieillesse (vieillure ?) des nœuds/ways d'une commune dans OSM, genre la date 
> moyenne de dernière modif des objets (éventuellement par type)

ce serrait une bonne idée pour https://cadastre.damsy.net
ceci dit, après avoir completé de nombreuses communes niveau du bati,
j'en suis arrivé à la conclusion que c'est bien difficile de trouver
un critère qui permet de dire oü il faut aller voir.
le moins mauvais critère que j'ai trouvé : les addresses.
nouveau lotisement = souvent nouvelle adresse.
du coup maintenant je fais systématiquement ajout des addr,
ce qui conduit à ajout des batiments manquant
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Manque d'attribution, supprimer les cas résolus - wiki

2020-01-17 Par sujet marc marc
le défaut étant d'être un tier (github),
donc les contributeurs après s'être inscrit ici, sur osm, sur le wiki
doivent s'inscrire une fois de + alors qu'il n'est deja pas motivant
pour certain d'aller consigner leur signalement quelque part..

une interface web permettant de s'identifier avec son compte osm
serait agréable

Le 17.01.20 à 12:04, Guillaume Rischard a écrit :
> Bonjour,
> 
> Cette page wiki est difficile à suivre. Je vous propose
> d’utiliser https://github.com/grischard/osm-lacking-attribution qui
> permet une gestion individuelle et systématisée au cas par cas, et est
> activement lu et utilisé par le CA de la fondation OSM ;).
> 
> Guillaume
> 
>> On 14 Jan 2020, at 12:14, Cyrille37 OSM > > wrote:
>>
>> Bonjour à tou·te·s,
>>
>> il me semble qu'il serait plus "poli / respectueux" de supprimer les
>> cas résolus: les sites qui ont corrigé les attributions sur leurs
>> cartes. Effectivement, nous avons à priori seulement besoin de suivre
>> l'avancement des corrections.
>>
>> Si un besoin de mémoire était nécessaire, il pourrait être comblé par
>> l'historique du wiki, ce qui me parait être un besoin vraiment "à la
>> marge".
>>
>> J'avais posé la suggestion sur la page de discussion, et à 2 nous
>> étions d'accord pour supprimer les cas résolus :
>> https://wiki.openstreetmap.org/wiki/FR_talk:Manque_d%27attribution_appropri%C3%A9e#Suivi_du_tableau
>>
>> Voilà, la proposition est posée :-)
>>
>> 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
> 

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


Re: [OSM-talk-fr] Proposition de mise à jour : la population des communes

2020-01-17 Par sujet HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT GE PPE)
J'en profite pour ma part, pour vérifier le bon l'ordonnancement des tronçons 
(avec plusieurs corrections à la clé), ajouter quelques name:gsw au passage (et 
virer les name:als). Pas compris, la logique de traduction des noms des 
communes (en malais, par ex)
Je refais les limites de commune plus quand je fais de la mise à jour de bâti. 
Je suis presque tenté par la création d'un indice de vieillesse (vieillure ?) 
des nœuds/ways d'une commune dans OSM, genre la date moyenne de dernière modif 
des objets (éventuellement par type)
Les fourmis jardinent même en hiver ;-)

-Message d'origine-
De : Vincent de Château-Thierry  
Envoyé : vendredi 17 janvier 2020 11:54
À : Discussions sur OSM en français 
Objet : Re: [OSM-talk-fr] Proposition de mise à jour : la population des 
communes


> De: "Donat ROBAUX" 
> 
> Pour info, la barre des 25% de communes à jour a été dépassée ce 
> matin!
> C'est une réelle satisfaction de voire la barre augmentée, mais 
> clairement c'est pas très passionnant à faire en manuel.

Oui & oui. De mon côté je traite les communes à un petit rythme, et en en 
profitant vraiment pour jardiner au passage, en voyant notamment sur quoi le 
validateur JOSM grogne. Hier par exemple j'ai eu droit à un "angle du chemin 
trop aigü" ou quelque chose d'approchant. Je ne connaissais pas ce message, au 
passage :) Et s'en est suivi du re-traçage de limite admin qui était imbriquée 
dans du tracé de rue pas joli joli... 

La mise à jour de population est vraiment un prétexte à venir jeter un oeil en 
des coins où on ne serait pas allé sinon. Statistiquement il y a quasi toujours 
prétexte à corriger 2-3 trucs en passant.

vincent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
---
Ce message et toutes les pièces jointes sont établis à l'intention exclusive de 
ses destinataires et sont confidentiels. L'intégrité de ce message n'étant pas 
assurée sur Internet, la SNCF ne peut être tenue responsable des altérations 
qui pourraient se produire sur son contenu. Toute publication, utilisation, 
reproduction, ou diffusion, même partielle, non autorisée préalablement par la 
SNCF, est strictement interdite. Si vous n'êtes pas le destinataire de ce 
message, merci d'en avertir immédiatement l'expéditeur et de le détruire.
---
This message and any attachments are intended solely for the addressees and are 
confidential. SNCF may not be held responsible for their contents whose 
accuracy and completeness cannot be guaranteed over the Internet. Unauthorized 
use, disclosure, distribution, copying, or any part thereof is strictly 
prohibited. If you are not the intended recipient of this message, please 
notify the sender immediately and delete it. 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Manque d'attribution, supprimer les cas résolus - wiki

2020-01-17 Par sujet Guillaume Rischard
Bonjour,

Cette page wiki est difficile à suivre. Je vous propose d’utiliser 
https://github.com/grischard/osm-lacking-attribution 
 qui permet une gestion 
individuelle et systématisée au cas par cas, et est activement lu et utilisé 
par le CA de la fondation OSM ;).

Guillaume

> On 14 Jan 2020, at 12:14, Cyrille37 OSM  wrote:
> 
> Bonjour à tou·te·s,
> 
> il me semble qu'il serait plus "poli / respectueux" de supprimer les cas 
> résolus: les sites qui ont corrigé les attributions sur leurs cartes. 
> Effectivement, nous avons à priori seulement besoin de suivre l'avancement 
> des corrections.
> 
> Si un besoin de mémoire était nécessaire, il pourrait être comblé par 
> l'historique du wiki, ce qui me parait être un besoin vraiment "à la marge".
> 
> J'avais posé la suggestion sur la page de discussion, et à 2 nous étions 
> d'accord pour supprimer les cas résolus : 
> https://wiki.openstreetmap.org/wiki/FR_talk:Manque_d%27attribution_appropri%C3%A9e#Suivi_du_tableau
> 
> Voilà, la proposition est posée :-)
> 
> 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] Proposition de mise à jour : la population des communes

2020-01-17 Par sujet Vincent de Château-Thierry

> De: "Donat ROBAUX" 
> 
> Pour info, la barre des 25% de communes à jour a été dépassée ce
> matin!
> C'est une réelle satisfaction de voire la barre augmentée, mais
> clairement c'est pas très passionnant à faire en manuel.

Oui & oui. De mon côté je traite les communes à un petit rythme, et en en 
profitant vraiment pour jardiner au passage, en voyant notamment sur quoi le 
validateur JOSM grogne. Hier par exemple j'ai eu droit à un "angle du chemin 
trop aigü" ou quelque chose d'approchant. Je ne connaissais pas ce message, au 
passage :) Et s'en est suivi du re-traçage de limite admin qui était imbriquée 
dans du tracé de rue pas joli joli... 

La mise à jour de population est vraiment un prétexte à venir jeter un oeil en 
des coins où on ne serait pas allé sinon. Statistiquement il y a quasi toujours 
prétexte à corriger 2-3 trucs en passant.

vincent

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


Re: [OSM-talk-fr] adresse mail rejetée - gouvernance et transparence

2020-01-17 Par sujet Vincent de Château-Thierry

> De: "marc marc" 
> 
> Le 17.01.20 à 10:52, Vincent de Château-Thierry a écrit :
> > Oui merci Marc. J'ai reçu ce matin un mail envoyé par
> > verd...@gmail.com comme quoi tout arrive.
> 
> oui et il n'y a eu plus aucun bounce depuis la modération/suppression
> de l'email problématique.

Cool

> derrière talk-fr-ow...@openstreetmap.org il y avait
> talkfrad...@gmail.com et nul ne sait/se souvient/n'a dit se souvenir
> de qui c'était vu l'absence de réaction aux messages depuis longtemps et 
> qu'il y
> avait des messages en attende de modération depuis 6 ans, TomH a accepté de
> m'envoyer au charbon à la place du précédent :)
> il n'y a personne au rôle modérateur, les lignes précédentes
> concernent le rôle admin qui a aussi accès à la modération.

Bon, le mystère restera entier.

> > Je suis partant pour faire partie de ce "pool".
> je t'ajoute volontiers, mais ne risques-tu pas un bounce si tu reçois
> un email problématique vu que tu es sur un fai le détectant ?
> sur des listes osm-fr oü il y a plus d'un modérateur, je vois souvent
> que la demande de modération d'email problématique subit un bounce
> pour les autres modérateurs. j'avais envisagé la création d'une boite
> email non filtré.

Non je ne penses pas, si je prends l'exemple des listes osm.fr où je suis admin 
: je reçois bien les mails envoyés à l'admin vdct disant que l'inscrit vdct 
bounce :/
 
> > aussi bien par souci de gouvernance que de "bus factor"
> 
> Pour le "bus factor", les admin osm.org peuvent tjs modifier :)
> Mais tout a fait d'accord. A savoir cependant qu'il n'y a pas de
> quorum de modération, le premier qui fait l'action valide.

Oui on est d'accord, c'est bien comme ça que ça fonctionne

> Plusieurs liste osm-fr manquent aussi de modérateur actif.

Auxquelles penses-tu ?

vincent

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


Re: [OSM-talk-fr] Proposition de mise à jour : la population des communes

2020-01-17 Par sujet Donat ROBAUX
Hello,

Pour info, la barre des 25% de communes à jour a été dépassée ce matin!
C'est une réelle satisfaction de voire la barre augmentée, mais clairement
c'est pas très passionnant à faire en manuel.

Donat



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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


Re: [OSM-talk-fr] adresse mail rejetée - gouvernance et transparence

2020-01-17 Par sujet marc marc
Bonjour,

Le 17.01.20 à 10:52, Vincent de Château-Thierry a écrit :
> Oui merci Marc. J'ai reçu ce matin un mail envoyé par verd...@gmail.com comme 
> quoi tout arrive.

oui et il n'y a eu plus aucun bounce depuis la modération/suppression
de l'email problématique.

> Pour la modération, deux questions :
> - as-tu finalement compris quelle(s) adresses étaient destinataires de 
> l'adresse générique de propriétaire/modérateur de talk-fr ? 

derrière talk-fr-ow...@openstreetmap.org il y avait
talkfrad...@gmail.com et nul ne sait/se souvient/n'a dit se souvenir
de qui c'était.
vu l'absence de réaction aux messages depuis longtemps et qu'il y avait
des messages en attende de modération depuis 6 ans, TomH a accepté de
m'envoyer au charbon à la place du précédent :)
il n'y a personne au rôle modérateur, les lignes précédentes concernent
le rôle admin qui a aussi accès à la modération.

> - qui d'autre que toi est modérateur ? Ca me semble sain que ce rôle soit 
> réparti sur plusieurs personnes,

Personne et je partage ton avis qu'il serrait sain d'être + que un.

> Je suis partant pour faire partie de ce "pool".
je t'ajoute volontiers, mais ne risques-tu pas un bounce si tu reçois
un email problématique vu que tu es sur un fai le détectant ?
sur des listes osm-fr oü il y a plus d'un modérateur, je vois souvent
que la demande de modération d'email problématique subit un bounce
pour les autres modérateurs. j'avais envisagé la création d'une boite
email non filtré.

> aussi bien par souci de gouvernance que de "bus factor"

Pour le "bus factor", les admin osm.org peuvent tjs modifier :)
Mais tout a fait d'accord. A savoir cependant qu'il n'y a pas de quorum
de modération, le premier qui fait l'action valide.
Plusieurs liste osm-fr manquent aussi de modérateur actif.
Pour la partie technique, c'est simple et cela s'apprend facilement.
Et on peux envisager un lieu de discussion s'il faut discuter de cela
sans noyer les listes concernées.

Cordialement,
Marc
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] adresse mail rejetée - premières modifs

2020-01-17 Par sujet Vincent de Château-Thierry
Bonjour,

> De: "Stéphane Péneau" 
> 
> Le 16/01/2020 à 13:46, marc marc a écrit :
> > J'ai reçu hier l'accès à l'administration de la liste.
> 
> Merci de prendre ça en charge Marc !

Oui merci Marc. J'ai reçu ce matin un mail envoyé par verd...@gmail.com comme 
quoi tout arrive.

Pour la modération, deux questions :
- as-tu finalement compris quelle(s) adresses étaient destinataires de 
l'adresse générique de propriétaire/modérateur de talk-fr ? 
- qui d'autre que toi est modérateur ? Ca me semble sain que ce rôle soit 
réparti sur plusieurs personnes, aussi bien par souci de gouvernance que de 
"bus factor". Si tu es actuellement seul sur le rôle, et si d'autres ici 
veulent se porter volontaires pour répartir la tâche, profitons-en. Je suis 
partant pour faire partie de ce "pool".

merci
vincent

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


Re: [OSM-talk-fr] Trottoir traversant

2020-01-17 Par sujet marc marc
Je trouve que tu fais compliqué :)

une route et un trottoir se croise, donc un nœud d'intersection
"passage piéton" highway=crossing + crossing=uncontrolled probablement
pour le niveau de sécurité + crossing_ref=no probablement
pour le type (lié au marquage en fr be ch) + kerb=no

si tu veux maintenant ajouter du détail pour dire en linéaire
la longueur de ce croissement pour chaque usager :
- pour la voiture, c'est un plateau traffic_calming=table
sur le way voiture.
côté voiture, je vois pas de différence entre traverser
un plateau passage piéton avec marquage (les ""anciens"" trottoir
traversants qui existent depuis des années) et un plateau
passe piéton trottoir traversant).
tout autre tag me semble donc superflu ou erroné.
est-ce qu'il y a une différence dans la loi ?
- pour le piéton, il y a 2 incohérences dans ce que tu dis.
la clef crossing sert a décrire le passage piéton (le nœud même
si certain duplique l'info du passage 3 fois).
crossing=continuous n'est donc pas une bonne idée pour décrire
l'étendue du cheminement de voie le composant.
par ailleurs si tu considères qu'un trottoir traversant est un trottoir,
alors ce n'est pas un passage piéton, c'est highway=path path=sidewalk
si c'est pas tout a fait un trottoir (peut-on s'y arrêter pour faire
ses lacets ou discuter avec un autre pendant 5 min ? j'en doute),
alors highway=path path=continuous_sidewalk ou qlq chose du genre.

Le 17.01.20 à 10:03, Florimond Berthoux a écrit :
> Bonjour,
> 
> J’aimerai ajouter un possibilité, aujourd’hui les segments
> d’intersections vélo ou piéton peuvent être taggué avec
> path/cycleway/footway=crossing.
> https://wiki.openstreetmap.org/wiki/Tag:footway%3Dcrossing
> 
> On pourrait alors continuer et ajouter crossing=continuous (nouvelle clé).
> https://wiki.openstreetmap.org/wiki/Key:crossing
> 
> Ça me parait pas mauvais, après dans le principe ça me gène que ça soit
> la piste qui porte le crossing alors que l’idée c’est que c’est la
> voiture qui traverse la piste ;)
> Peut-être le plus simple serait d’ajouter sur le nœud d’intersection
> crossing=continuous_sidewalk, mais il faudrait alors préciser
> crossing:cycleway=continuous.
> Comme ça un router à l’info pour les trois modes de déplacement.
> 
> Mais crossing est une clé mal foutu avec des valeurs possible
> orthogonales :/
> 
> La clé kerb pourrait être aussi intéressante
> https://wiki.openstreetmap.org/wiki/Key:kerb
> 
> (l’enfer est pavé de tags ’:)
> 
> 
> Le dim. 12 janv. 2020 à 18:56, Florimond Berthoux
> mailto:florimond.berth...@gmail.com>> a
> écrit :
> 
> Salut,
> 
> Moi, mais il en existe trop peu par chez moi pour avoir essayer de
> trouver un schéma de tags.
> Mais on peut réfléchir à plusieurs :
> 
> En anglais on parle de continous sidewalk
> https://www.youtube.com/watch?v=9OfBpQgLXUc
> Pour ce qui est des trottoirs évidemment.
> 
> Je pense qu'on peut distinguer deux notions comme montré dans la
> vidéo, le côté trottoir traversant et le côté ralentisseur.
> Pour le côté ralentisseur on pourrait le tagguer simplement comme un
> traffic_calming=continuous_sidewalk
> 
> Pour le côté trottoir : sur le highway parallèle du trottoir
> traversant un tag sidewalk:right:continuous=yes
> Si le highway piéton est séparé on pourrait imaginer sur la portion
> du trottoir traversant :
> highway=footway
> footway=sidewalk
> sidewalk=continuous
> 
> Et on pourrait faire de même pour la piste cyclable
> cycleway:right=track
> cycleway:right:continuous=yes
> ou
> highway=cycleway
> cycleway=continuous ?
> 
> 
> 
> Le dim. 12 janv. 2020 à 17:25, Axel Listes  > a écrit :
> >
> > Bonjour,
> >
> > Suite à la rénovation d'un faubourg, j'ai vu que le trottoir ainsi que
> > la piste cyclable qui le longe sont agencés d'une façon que je n'avais
> > jamais vu dans le secteur.
> >
> > Dans certains carrefours avec des rues résidentielles, les rues en
> > question "s'interrompent" au croisement. Les véhicules peuvent
> circuler
> > sur une sorte de plateau, sauf que le plateau est intégré au
> trottoir du
> > Faubourg.
> >
> > Je sais que c'est courant aux Pays-bas, existant également sur
> Strasbourg.
> >
> > Est-ce que l'un ou l'une d'entre vous s'est déjà posé la question de
> > comment représenter cela sur OSM ?
> >
> > https://fr.wikipedia.org/wiki/Trottoir_traversant
> > http://velobuc.free.fr/trottoirtraversant.html
> >
> > Bien cordialement.
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org 
> > https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> 
> -- 
> Florimond Berthoux
> 
> 
> 
> -- 
> Florimond Berthoux
> 
> 

Re: [OSM-talk-fr] Trottoir traversant

2020-01-17 Par sujet Florimond Berthoux
Bonjour,

J’aimerai ajouter un possibilité, aujourd’hui les segments d’intersections
vélo ou piéton peuvent être taggué avec path/cycleway/footway=crossing.
https://wiki.openstreetmap.org/wiki/Tag:footway%3Dcrossing

On pourrait alors continuer et ajouter crossing=continuous (nouvelle clé).
https://wiki.openstreetmap.org/wiki/Key:crossing

Ça me parait pas mauvais, après dans le principe ça me gène que ça soit la
piste qui porte le crossing alors que l’idée c’est que c’est la voiture qui
traverse la piste ;)
Peut-être le plus simple serait d’ajouter sur le nœud d’intersection
crossing=continuous_sidewalk, mais il faudrait alors préciser
crossing:cycleway=continuous.
Comme ça un router à l’info pour les trois modes de déplacement.

Mais crossing est une clé mal foutu avec des valeurs possible orthogonales
:/

La clé kerb pourrait être aussi intéressante
https://wiki.openstreetmap.org/wiki/Key:kerb

(l’enfer est pavé de tags ’:)


Le dim. 12 janv. 2020 à 18:56, Florimond Berthoux <
florimond.berth...@gmail.com> a écrit :

> Salut,
>
> Moi, mais il en existe trop peu par chez moi pour avoir essayer de trouver
> un schéma de tags.
> Mais on peut réfléchir à plusieurs :
>
> En anglais on parle de continous sidewalk
> https://www.youtube.com/watch?v=9OfBpQgLXUc
> Pour ce qui est des trottoirs évidemment.
>
> Je pense qu'on peut distinguer deux notions comme montré dans la vidéo, le
> côté trottoir traversant et le côté ralentisseur.
> Pour le côté ralentisseur on pourrait le tagguer simplement comme un
> traffic_calming=continuous_sidewalk
>
> Pour le côté trottoir : sur le highway parallèle du trottoir traversant un
> tag sidewalk:right:continuous=yes
> Si le highway piéton est séparé on pourrait imaginer sur la portion du
> trottoir traversant :
> highway=footway
> footway=sidewalk
> sidewalk=continuous
>
> Et on pourrait faire de même pour la piste cyclable
> cycleway:right=track
> cycleway:right:continuous=yes
> ou
> highway=cycleway
> cycleway=continuous ?
>
> 
>
> Le dim. 12 janv. 2020 à 17:25, Axel Listes  a écrit :
> >
> > Bonjour,
> >
> > Suite à la rénovation d'un faubourg, j'ai vu que le trottoir ainsi que
> > la piste cyclable qui le longe sont agencés d'une façon que je n'avais
> > jamais vu dans le secteur.
> >
> > Dans certains carrefours avec des rues résidentielles, les rues en
> > question "s'interrompent" au croisement. Les véhicules peuvent circuler
> > sur une sorte de plateau, sauf que le plateau est intégré au trottoir du
> > Faubourg.
> >
> > Je sais que c'est courant aux Pays-bas, existant également sur
> Strasbourg.
> >
> > Est-ce que l'un ou l'une d'entre vous s'est déjà posé la question de
> > comment représenter cela sur OSM ?
> >
> > https://fr.wikipedia.org/wiki/Trottoir_traversant
> > http://velobuc.free.fr/trottoirtraversant.html
> >
> > Bien cordialement.
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> --
> Florimond Berthoux
>


-- 
Florimond Berthoux
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Proposition de mise à jour : la population des communes

2020-01-17 Par sujet Philippe Verdy
Le plus simple c'est de modifier les deux en même temps (seulement pour les
noeuds admin_centre des communes au niveau 8, ou 9 pour les communes
déléguées ou arrondissements) ou sinon virer la population du noeud.

Pur les grosses communes divisées en IRIS, y compris à Paris avec ses
arrondissements groupant des quartiers, sous-quartiers et IRIS ; le noeud
Paris ne devrait avoir aucune population d'arrondissement mais ce n'est pas
clair si cela désigne la population départementale/municipale, ou celle de
la préfecture de Paris avec la petite couronne, ou le Grand Paris, de toute
façon ce n'est pas un IRIS Insee et c'est une totalisation partielle en
retirant les double-compte : on ne peut pas déduire cette population par
une simple somme arithmétique, la source est différente, les critères
d'inclusion dans une commune ou une autre sont un peu différent, et ce
n'est pas la somme des populations communales mais celle établie ensuite
par l'Insee qui a retiré les double-compte (notamment la population légale
par département, publiée par le décret de janvier 2020).

L'insee passe un temps fou à détecter les double-comptes mais certaines
communes exigent et obtiennent un droit à tenir compte de certaines
populations (dont les étudiants ou les touristes qu'elle héberge de façon
non permanente ou rapatrier chez elles les personnes à charge de personnes
situées dans d'autres communes, la population hospitalisée, celle
temporairement en prison n'importe où au moment du recensement mais ayant
encore un "domicile" officiel qu'elle ne peuvent pas occuper, tous ceux en
service extérieur commandé pour les armées, et la capacité d'accueil
moyenne dans les casernes en France à qui les communes ou communautés
doivent aussi rendre certains services, et certains autres résidents
quasi-permanents à l'étranger qui ont un droit de retour ou de rapatriement
permanent et immédiat en France à leur domicile déclaré.

Pour les communes non subdivisées en IRIS, donc de moins de 5000 habitants
(donc des noeuds de type place=town, village, voire hamlet dans quelques
cas) le noeud chef-lieu devrait afficher une population égale à celle de sa
relation de niveau 8 ou 9.

Moi je suis convaincu que la population au niveau du noeud n'est pas liée à
celle de la relation, le noeud ayant plus la signification associée à la
classification OSM (place=city/town/village/etc.) mais c'est significatif
si cela désigne l'agglomération. Mais dans les agglos multicommunales la
population de l'agglo ne marche plus.

De même des communes rurales et certaines communes urbaines récentes sont
créées pour grouper des villages formant des agglo différentes; ce n'est
pas clair si le noeud admin_centre devrait être la population totale de la
commune incluant ces villages périphériques dans des agglos séparées, ou la
population de l'agglo centre contenant le noeud (et parfois le noeud
communal n'est même pas fixé dans une des agglos mais entre elles, c'est le
cas pour les communes nouvelles à moins qu'on ait choisi le chef-lieu de la
commune déléguée membre, mais il y a encore des exceptions avec les
communes insulaires).

Bref Osmose peut dire ce qu'il veut. La population du noeud est difficile
voire impossible à vérifier par un moyen automatique, elle n'est pas
réellement sourçable elle donne jutse un indicateur estimé. Ce qui compte
c'est la population des relations qu'Osmose peut alors vérifier de façon
limitée (pas question de faire des cumuls à cause des double-compte, mais
la somme des membres devrait être supérieure ou égale à celle du contenant;
il vaut mieux sourcer séparément la population de chaque relation
contenante, et laisser à part celle des membres à gérer séparément)


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

> Bonjour,
>
> Osmose râle sur mes récentes modifs d'hier soir (selon le mode op
> indiqué par Vincent )  :
>
>   Attribut “population” inconsistant entre la relation et son membre
> “admin_centre”
> Population du rôle “admin_centre” (309) supérieure à celle de la
> relation (305)
> relation 146525
>
> Qu'ai-je fait de mal ?
>
> Merci de me guider vers les corrections
>
> J.
>
>
>
> Le 14/01/2020 à 12:02, Vincent de Château-Thierry a écrit :
> > Bonjour,
> > Après l'échauffement avec la mise à jour des cantons il y a quelques
> jours, je vous propose un nouveau chantier, d'une autre ampleur mais à
> peine plus long.
> >
> > L'INSEE vient en effet de publier les chiffres de population légale par
> commune pour 2017 [1]. C'est l'occasion de mettre à jour le tag population
> de nos 35000 relations communales. Ca peut effrayer au premier abord car ça
> signifie écrire 35000 fois un chiffre relevé sur un listing, sans se
> tromper... pas sûr d'avoir envie. J'ai donc essayé de nous économiser, en
> proposant une interface de saisie que j'espère efficace.
> >
> > En allant ici :
> http://dev.cadastre.openstreetmap.fr/fantoir/maj_population_2017.html
> vous visualisez la liste des départements, et pour chacun le % de communes
>