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

[marc marc]

a noter qu'il y a aussi la clef charging_station=*
https://taginfo.openstreetmap.fr/keys/charging_station
permettant de renseigner qu'un poi a une station de recharge
lorsqu'on ignore exactement où il se trouve

au final cela fait quelques choses du genre :

area[name="Cabourg"];
nwr[amenity=charging_station]->.borne;
(
nwr(around.borne:100)[tourism=hotel];
nwr[tourism=hotel][charging_station][charging_station!=no];
);
(._;>;);
out meta;


Le 18.01.20 à 10:40, Vincent Bergeot a écrit :
> Le 18/01/2020 à 02:09, Shohreh a écrit :
>> trouver tous les hôtels en France qui proposent une
>> prise pour recharger une voiture électrique
> 
> area[name="Cabourg"];
>   node(area)[tourism=hotel]->.hotels;
>   (
>     way(around.hotels:100)[amenity=charging_station];
>     node(around.hotels:100)[amenity=charging_station];
>   );
>   (._;>;);
>   out meta;
___
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 ?

[marc marc]

Le 18.01.20 à 12:25, Shohreh a écrit :
> distinguant les prises en accès privé/public ?

access=private/customers/yes (l'absence de la clef signifiant yes)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[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)

[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

[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] adresse mail rejetée - gouvernance et transparence

[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] Trottoir traversant

[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] adresse mail rejetée - email problématique modéré jusqu'à résolution

[marc marc]

Le 16.01.20 à 22:45, Philippe Verdy a écrit :
> je n'ai RIEN bricolé du tout

tu continues d'envoyer des email "from verd...@wanadoo.fr",
via serveur gmail et cela vient de produire 41 bounce.
cet email redirigé est TON choix, ce n'est pas parce que gmail
le permet que les autres fai doivent accepter un comportement
courant dans l'usurpation d'identité et le spam, d'autant
que tu as (tu le dis toi-même) ton email gmail qui va bien.

Par conséquent ton email est modéré jusqu'à résolution du problème.
si un email verd...@wanadoo.fr arrive via gmail, il serra supprimé.
si un email disant "c'est la faute des autres si tu utilises
ton email wanadoo dans gmail" arrive, il serra supprimé.
si c'est un email non bricolé, je le validerai.
Tu dois cependant t'attendre à des délais de validation,
je ne vais pas passer ma vie derrière mon écran pour valider
un hypothétique message valide à la minute alors que cela fait
des semaines que la demande a été faite calmement et patiemment.
En moyenne je m'attends cependant à les valider dans la journée.

J'en suis navré d'en arriver là mais ta mauvaise foi te perdra.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [DAE] fonctionnement de la base de données nationale des,défibrillateurs automatisés externes

[marc marc]

Merci.
Quelqu'un a eu une réaction à nos ràactions sur le format ?

Le 16.01.20 à 13:51, Laurent Magréault a écrit :
> Bonjour,
> 
> Ci-dessous, les dates des 3 "webdémos" pour en savoir plus sur la base
> nationale des DAE.
> 
> ___)```)___
> 
> Laurent Magréault
> 
>      Courriel original 
>     Objet: Base nationale des DAE - faire suivre
>     Date: 15/01/2020 18:16
>     De: ATLASANTE mailto:atlasa...@ars.sante.fr>>
>     À:
> 
> 
>     Bonjour,
> 
>      
> 
>     Ce message s’adresse aux collectivités locales ou opérateurs privés
> propriétaires de défibrillateurs, aux membres des plateformes régionales
> d’échanges de données, aux mainteneurs de défibrillateurs, aux
> professionnels du secours, aux gestionnaires des applications citoyennes
> qui assurent le service aujourd’hui.
> 
>      
> 
>     La base de données nationale de collecte des défibrillateurs
> automatisés externes ouvrira prochainement afin de permettre aux
> exploitants de déclarer leur DAE en ligne, conformément à la Loi du 28
> juin 2018.
> 
>     Afin de comprendre et voir comment cela va se mettre en place nous
> vous proposons 3 web démos d’une durée d’une heure. L’inauguration
> officielle aura lieu mi-février, mais nous ouvrirons le service avant
> pour permettre les déclarations des premiers DAE.
> 
>      
> 
>     La Direction Générale de la Santé (DGS) a mandaté les équipes
> d’Atlasanté pour assurer les aspects techniques de ce recueil et du
> partage de la donnée.
> 
>     Atlasanté est le Système d’Information Géographique mutualisé des
> ARS et du ministère de la santé.
> 
>      
> 
>     Le projet n’a pas vocation à remplacer les applications citoyennes
> existantes. Elles assurent un rôle indispensable d’animation de
> communautés de secouristes. La base nationale permettra à toutes les
> applications qui le souhaiteront de disposer des mêmes données via des
> API gratuites. Les données publiques de ce projet seront également
> disponibles en Open Data.
> 
>      
> 
>      
> 
>     3 webdémos  en janvier
> 
>     le 21 à 10h55            le 24 à 13h25            le 27 à 13h55
> 
>      
> 
>     1h pour découvrir le projet et poser vos questions
> 
>      
> 
>     ·         Audio : 01 70 75 07 40
> 
>     ·         Ecran :
> https://ars-auvergne-rhonealpes.anywhereconference.com/
> 
>     Web login
>    
> 
>     Code PIN Participant
> 
>     418836232
>    
> 
>     92796633
>    
> 
>      
> 
>     Pour le confort de tous, nous vous demanderons de couper vos micros
> et poser vos questions au fur et à mesure par écrit via l’outil de
> dialogue. Vos questions seront ensuite regroupées et posées à l’orateur.
> 
>     La démo dure environ 30mn, le reste du temps sera dédié aux réponses
> à vos questions.
> 
>      
> 
>      
> 
>     Cordialement,
> 
>      
> 
>     Xavier VITRY
> 
>     SCN SIM ARS
> 
>    
> https://www.atlasante.fr/media/site/gen/atlasante/logo-atla-sant-l...@2x.png
> 
>     cid:image001.png@01D5C49D.064A2650  
> 
>     Ministère des Solidarités et de la Santé
>     Ministère du Travail
> 
>     Ministère de l’Éducation nationale
> 
>     Ministère des Sports
> 
>     04 27 86 57 30
> 
>     07 78 63 92 32
> 
>     xavier.vi...@ars.sante.fr 
> 
>      
> 
> 
>     Les ministères sociaux agissent pour un développement durable.
> 
>     Préservons l'environnement : n'imprimons que si nécessaire !
> 
> Le mer. 11 déc. 2019 à 10:51, Cyrille37 OSM via Talk-fr
> mailto:talk-fr@openstreetmap.org>> a écrit :
> 
> Revue de publication officielle:
> 
> Arrêté du 29 octobre 2019 relatif au fonctionnement de la base de
> données nationale des défibrillateurs automatisés externes (DAE)
> https://www.legifrance.gouv.fr/jo_pdf.do?id=JORFTEXT39363959
> 
> Cet arrêté précise les modalités d'exploitation (alimentation, gestion,
> communication) de la base de données nationale des défibrillateurs
> automatisés externes.
> https://www.legifrance.gouv.fr/eli/arrete/2019/10/29/SSAP1932161A/jo/texte
> 
> 
> 
> ___
> 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] adresse mail rejetée - premières modifs

[marc marc]

Bonjour,

J'ai reçu hier l'accès à l'administration de la liste.
l'email de Philippe [1] a provoqué à lui tout seul des bounces sur 16
email différents ainsi que 10 désinscriptions sur plusieurs domaines
différents.

J'ai réactivé manuellement les 15 personnes qui ont subi à ce moment
là et dans le passé une désinscription pour "bounce excessif".
J'ai fait quelques modifs pour rendre la liste temporairement "plus
relax" au niveau des bounces, temporairement parce que cette fonction
est nécessaire dans une liste normale pour détecter les adresses mortes
avant que le serveur d'en face ne s'en irrite (comportement normal
dans le domaine spam<>antispam).

Philippe il t'a déjà été demandé à de nombreuses reprises de cessez
d'envoyer ces emails bricolés rejetés par la moitié des fai français.
Merci d'en tenir compte MAINTENANT, le taux de nuisance n'est pas
acceptable. dire que c'est la faute du monde entier sauf toi
n'est pas une solution.

[1]
https://lists.openstreetmap.org/pipermail/talk-fr/2020-January/096313.html

Cordialement,
Marc
___
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

[marc marc]

Hello,

Le but est de pouvoir répondre différemment à celui qui commet
une erreur <> l'entreprise bricole la prod sous la pression
mais perd l'info à chaque maj parce que pas remonté comme il faut.

ceci dit je suis tout a fait d'accord pour un droit à l'oubli.
mais pas avec un délai "instantané".
Il y des infos à ce sujet dans une loi ou une jurisprudence ?
Sinon au pif 1 an me semble bien, si c'est déplacé sur une page annexe.

Pour l'histoire de "c'est pas les mêmes gars", je ne suis pas d'accord.
on ne vise pas l'humain qui était affecté à la tâche,
on vise le site. la fréquence de changement des gars qui s'en occupent,
cela peux se comprendre comme "raison" mais cela ne nous regardent pas
et cela ne doit sûrement pas être accepté comme excuse pour justifier
un problème récurent, si cela se produit.

Cordialement,
Marc

Le 15.01.20 à 18:11, Cyrille37 OSM a écrit :
> Hello
> 
> Marc, à quoi servirait d'avoir l'histoire ? Une fois le site mit en
> conformité, l'affaire est terminée. Si un jour le même site pose à
> nouveau problème c'est une autre "histoire", non ?
> 
> À mon avis un site qui se retrouve à nouveau en défaut d'attribution un
> an après, n'est pas le même site: c'est une nouvelle version, une
> nouvelle équipe, ou un nouveau je ne sais quoi.
> 
> Je fais un peu le parallèle avec le "droit à l'oubli", qui existe même
> en justice, qui selon la gravité oublie les fautes, de façon que si tu
> refais une faute après un certain délai on ne te reprochera pas les
> fautes précédentes puisqu'elles sont oubliées.
> 
> Dit encore autrement, je n'aime pas conserver des infos qui me
> permettrai d'accumuler des reproches pour le prochain désaccord. ;-)
> 
> Cyrille.
> 
> Le 14/01/2020 à 13:26, marc marc a écrit :
>> Le 14.01.20 à 12:14, Cyrille37 OSM a écrit :
>>> il me semble qu'il serait plus "poli / respectueux"
>>> de supprimer les cas résolus
>> Il ne faut en effet pas les garder comme "à problème"
>>
>> Mais les effacer pose le soucis de l'historique, càd le manque
>> de possibilité de recherche :
>> regarde le dernier site ajouté, c'est "ajout site".
>> si celui-ci est supprimé avec comme résumé "suppression site",
>> tu n'as aucun moyen de retrouver son existence hormis regardant chaque
>> modif.
>>
>> Je verrais bien une page d'archive, un peu comme cela se fait avec les
>> pages de proposition. le contenu passé est caché derrière un clic.
>> je me demande même si cela ne disparait pas aussi du moteur de recherche
>> (à vérifier). mais cela permet au moins de se rendre sur la page
>> d'archive, avoir la date de l'incident, la date de résolution. bref
>> savoir si besoin au lieu de réécrire l'histoire.
>> ___
>> 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 ?

[marc marc]

Le 15.01.20 à 16:28, Cédric Frayssinet a écrit :
> 
> Bonjour à tous et notamment aux techs :)

j'ai ajouté la ml tech :)

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

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.
tu veux encore présenter aujourd'hui ? si oui j’irai voir sur le serveur
si Jocelyn n'est pas dispo
___
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

[marc marc]

Le 14.01.20 à 21:54, DH a écrit :

> La population 2017 ne peut pas être connue méthodologiquement avant 2020.

ce n'est pas parce que la méthode insee date de l'époque "que par
papier" que d'autres ne font pas mieux (je connais une commune qui
a publié le jour même le passage au millier supérieur).
oui oui p_v c'est impossible mais elle l'a fait.

> J'ai simplement la crainte que l'utilisateur lamba, sans chercher
> à comprendre le pourquoi du comment, assume source:date=2020 <=>
> population 2020 ce qui est bien évidemment faux.
> Une note méthodologique ? sur le wiki ?

ta crainte est tout a fait justifiée,
l'utilisateur lambda change le tag population sans autre :(

solution : se limiter à source=insee et sur le changeset uniquement :)
ainsi c'est clair que si t'as changé la valeur de la population en 2010
avec source=insee, c'est que t'as utilisé l'info de l'insee la + à jour
dispo à cette date et peu importe que l'insee ai mis 1 jour ou une
décénie a publier.
C'est ce qu'on fait quand on met source=imagery imagery_used=BDOrtho :
on a utilisé l'imagerie la + récente sans se prendre la tête
manuellement à aller chercher la date de l'image qu'on voit (mais qui
serrait très pratique a récupérer automatiquement, mais ca c'est un
autre sujet).
après je suis pas contre si quelqu'un met sur le changeset de mis
source=insee
population:date=2017
source:date=2020
mais sur les objets, comme dit avant, de toute façon le contributeur
lamba changera la valeur de l'un sans changer l'autre, c'est peine
perdue et erroné de se fier aux source=* sur les objets.

> note  : autant la commune est légitime comme source sur la toponymie,
> autant sur la population c'est l'INSEE la source légitime et légale.

je ne comprend pas en quoi la commune n'est pas légitime vu que
ce sont les infos de la commune que d'autres vont récupérer.
c'est un peu comme dire qu'on ne devrait pas modifier un bâtiment
dans osm tant que le cadastre n'a pas fait la maj légale.
Je partage à 100% l'idée d'uniformiser tous le pays avec la source légal
dispo en opendata. mais si quelqu'un a une source de meilleur qualité
et tout aussi ouverte, ne nous gênons pas à faire mieux que le légal.   

Cordialement,
Marc
___
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

[marc marc]

oui et non.
oui il y a bien 2 dates (récolte des données <> publication).
non il ne me semble pas qu'il y ai 2 dates valide pour la source
au sens osm.

Quand je met une info dans osm et que j'ai le choix entre 2 sources,
je vais prendre celle qui a les infos les + fraîche, cad celle dont
la réalité "sur place" a une date la + fraîche.
il me semble donc que la date de publication a peu d'intérêt pour osm,
c'est la date "sur place" qui importe, ici 2017 en l’occurrence

concrètement il y a des contributeurs (comme moi) qui mettent parfois à
jour la population de la commune avec une source + fraîche (la commune
elle-même). ils vont mettre source:date=2019 et se faire écraser par une
valeur publiée en 2020 mais + veille.

Le 14.01.20 à 15:29, HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT
GE PPE) a écrit :
> Bonjour,
> 
> Pour comprendre que les deux informations sont exactes, un peu de lecture : 
> https://www.insee.fr/fr/information/2383265 
> 2017 = année médiane des enquêtes
> 2020 = année de diffusion des données
> 
> Denis
> 
> -Message d'origine-
> De : Stéphane Péneau  
> Envoyé : mardi 14 janvier 2020 15:10
> À : talk-fr@openstreetmap.org
> Objet : Re: [OSM-talk-fr] Proposition de mise à jour : la population des 
> communes
> 
> Le 14/01/2020 à 14:59, leni a écrit :
>>
>>
>> De plus, le "source:population=INSEE 2020" n’apporte-t-il pas une 
>> confusion puisque la base INSEE est 2017 mais la mise à jour en 2020 ?
>>
> J'avoue que je ne serais pas contre un peu d'uniformisation, parce que 
> dernièrement je me mélangeais les pinceaux, entre osm et wikipedia.
> 
> Stf
> 
> ___
> 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
> 

___
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

[marc marc]

Le 14.01.20 à 14:33, david.croc...@free.fr a écrit :
> Et pourquoi ne pas attendre que les données soient dans WikiData pour ensuite 
> les récupéré automatiquement

ou voir qui le fait et faire les 2 en même temps (parce que passer
par wikipedia a le défaut de masquer la réelle source/licence)
___
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

[marc marc]

non il y a 4 cas :
1) population village=commune avec 1 seul lieu habité : c'est correct
mais n'apporte pas de précision à l'info communale.
2) population village=commune avec +  d'un lieu habité : incorrect
3) quand la population village > commune : incorrect
4) quand la population village < commune : en automatique c'est
difficile de vérifier vu l'absence de source. donc à priori ne pas toucher.

Le 14.01.20 à 14:18, osm.sanspourr...@spamgourmet.com a écrit :
> En résumé on a deux cas, dans un cas on supprime et dans l'autre cas on 
> supprime aussi.
> Je propose de simplifier : on supprime sans regarder^^ et on documente le 
> wiki : la population ne peut pas porter sur des nœuds.
> 
> Jean-Yvon
> 
>> Gesendet: Dienstag, 14. Januar 2020 um 13:45 Uhr
>> Von: "Vincent de Château-Thierry"
>> An: "Discussions sur OSM en français" 
>> Betreff: Re: [OSM-talk-fr]  Proposition de mise à jour : la population des 
>> communes
>>
>>
>>> De: "marc marc" 
>>>
>>> quand les 2 population=* sont égales et que la commune n'a qu'un seul
>>> lieu habité, alors on peux mettre à jour les 2 avec la meme valeur.
>>
>> Ou plutôt supprimer la population du node, car elle fait doublon, elle 
>> n'apporte aucune précision.
>>
>>> quand les 2 population=* sont égales et que la commune a + d'un lieu
>>> habité, alors il y a confusion commune<>village et l'info est à
>>> supprimer
>>
>> D'accord avec ça
>>
>> vincent
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 

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

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

[marc marc]

Le 14.01.20 à 13:29, Vincent de Château-Thierry a écrit :
> comment savoir si cette population concerne toute la commune, ou seulement la 
> partie figurée par le node place=* ?

quand les 2 population=* sont égales et que la commune n'a qu'un seul
lieu habité, alors on peux mettre à jour les 2 avec la meme valeur.

quand les 2 population=* sont égales et que la commune a + d'un lieu
habité, alors il y a confusion commune<>village et l'info est à supprimer
___
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

[marc marc]

Le 14.01.20 à 12:02, Vincent de Château-Thierry a écrit :
> Merci pour vos retours 

pour édition mécanique <> vérif humaine, je suis mitigé.
j'étais aussi entrain d'argumenté pour la modif mécanique (surtout
que cela pourra être réutilisé à chaque maj de la source).
Pas convaincu de l'intérêt d'un clic humain pour mettre à jour chaque
objet. mais c'est à celui qui propose de choisir ce qu'il propose,
donc je respecterai cela.
je participerai néanmoins en aller voir sur osmose si des admin_center
et relation cassées manquent de bras :)

ce serrait le moment d'en profiter pour abandonner le tag
source:population sur l'objet et le mettre sur le changeset vu que le
tag source sur l'objet ne dit en rien que l'info vient ACTUELLE vient
de cette source là, ce n'est pas rare que quelqu'un modifie ensuite la
valeur en question (le tag population dans notre cas) sans mettre à jour
le tag sur l'objet (puisque la bonne façon de faire est la source sur le
changeset). donc faut quand même regarder l'historique si on veux
connaitre la source réelle de la dernipre modif. donc autant éviter
de continuer avec ce suposé facilité qui n'a pas la garantie nécessaire.

pour la population d'un village <> celui de la commune, perso j'ai
abandonné, quand il y a conflit, bcp de modif sont fait sans renseigner
la source. donc impossible de trancher si c'est une confusion entre
commune et village ou si c'est un problème de date différente
___
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

[marc marc]

Le 14.01.20 à 12:14, Cyrille37 OSM a écrit :
> il me semble qu'il serait plus "poli / respectueux" 
> de supprimer les cas résolus
Il ne faut en effet pas les garder comme "à problème"

Mais les effacer pose le soucis de l'historique, càd le manque
de possibilité de recherche :
regarde le dernier site ajouté, c'est "ajout site".
si celui-ci est supprimé avec comme résumé "suppression site",
tu n'as aucun moyen de retrouver son existence hormis regardant chaque
modif.

Je verrais bien une page d'archive, un peu comme cela se fait avec les
pages de proposition. le contenu passé est caché derrière un clic.
je me demande même si cela ne disparait pas aussi du moteur de recherche
(à vérifier). mais cela permet au moins de se rendre sur la page
d'archive, avoir la date de l'incident, la date de résolution. bref
savoir si besoin au lieu de réécrire l'histoire.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] école primaire

[marc marc]

Le 13/01/2020 à 19:49, deuzeffe a écrit :
>>> établir que, pour la France, quand c'est
>>> une « école », c'est amenity=school ; amenity=kindergarten étant utilisé
>>> pour les établissements d'accueil pré-scolaire.
>>> ( pour les autres pays francophones, je ne connais pas du tout leur
>>> fonctionnement )
>>
>> Une décision a-t-elle été prise ? 

ton idée m'a l'air bien.
tu fais une courte comparaison avant/après pour ceux qui ne sont pas
dans le bain ? :)

Le 14.01.20 à 07:23, Arnaud Champollion a écrit :
> Et y a school:FR=maternelle pour le préciser.

je trouve ce tag historique compréhensible à titre temporaire
lors de la création du monde ou presque.
mais pitié, la proposition d'éducation 2.0 a assez d'idée
pour internationaliser les tags que pour ne plus devoir pousser
en avant des :FR
sinon on fait quoi ensuite ? shop:FR=magasin de vêtement
pour tous les shop=clothes ?
il y a vraiment de l'abus de namespace dans la communauté fr.
essayons de garder/uniformiser des tags mondiaux au lieu de rustines
différentes selon chaque pays.

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

Re: [OSM-talk-fr] Supermarché drive only

[marc marc]

Le 06/01/2020 à 22:23, Cédric Frayssinet a écrit :
> Avez-vous déjà tagué ce genre de magasin :
> https://westnordost.de/p/7258.jpg

si c'était un drive only
shop=supermarket
drive_through=only

mais à voir la photo, ce n'est pas le cas,
tu sorts de ton véhicule et tu vas dans le magasin,
comme n'importe quel autre magasin sauf que t'as passé
ta commande avant au lieu de sur place.
je n'ai pas connaissance de tag disant que le magasin
a la possibilité de commander en ligne.
si tu le trouve, suffit de mettre =only
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Padza [Mayotte]

[marc marc]

Le 11.01.20 à 07:36, Waxy via Talk-fr a écrit :
> https://fr.wikipedia.org/wiki/Padza
> natural=bare_rock

cela me semble bien.

> surface=ground

bof, wikipedia a dit que c'est de la roche et non de la terre


> natural=stone

c'est pour un rocher individuel

> natural=sand (parfois avec surface=ground)

celai pourrait décrire que la zone rocheuse est devenue du sable.
mais à mon avis il faudra choisir entre les 2
selon l'état : soit c'est encore un rocher, soit c'est du sable

> Les name=Padza sont à enlever

ou à migrer en description

> clé geological=outcrop

ca pourrait être un bon complément pour décrire le comment
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] OSMOSE et Opendata

[marc marc]

Bonjour,

Le 10.01.20 à 12:44, emeric Prouteau a écrit :
> acceder à de la donnée opendata et la valider via osmose

http://osmose.openstreetmap.fr/fr/map/#item=8xxx=1%2C2%2C3
c'est la rubrique "à cartographier" à gauche

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

Re: [OSM-talk-fr] Intégration supports radio ANFR : différences mast/tower

[marc marc]

Le 09.01.20 à 22:04, François Lacombe a écrit :
> pour les pylônes auto-stables, l'échelle est à l'intérieur du treillis
> le plus souvent donc c'est plutôt man_made=tower

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

Re: [OSM-talk-fr] Chemin de fer "disused"

[marc marc]

Bonjour,

Le 09.01.20 à 07:32, Arnaud Champollion a écrit :
> Pour une ligne de chemin de fer désaffectée (mais dont l'infrastructure
> est encore en place), j'ai passé tous les tronçons "railway=rail" en
> "railway=disused" :
> 
> "Portion de voie ferrée désaffectée mais dont l'infrastructure est
> encore en place."

exact. même si le mot désaffecté est mal choisit :
la valeur pour le rail ne dépend pas s'il est utilisé ou pas (cette info
est donnée par une relation passager/fret ou non) mais par son état :
utilisable ou besoin d'un peu de boulot pour être utilisé à nouveau


> Ces tronçons appartiennent à une relation qui décrit l'ancienne ligne.
> --> Est-ce que cette relation
> https://www.openstreetmap.org/relation/3321823  :
> 
> - doit être aussi qualifiée de "railway=disused"  ? 
> sachant qu'a priori on n'utilise pas railway=rail sur les lignes :
> https://wiki.openstreetmap.org/wiki/FR:Tag:route%3Drailway

non, une ligne n'est pas un rail, donc pas de railway=*

> - doit utiliser le préfixe disused:route=railway ?

c'est une possibilité. mais il faudra quand même une route=*
qui décrit ce que c'est aujourdh'ui sinon l'utilisation des données
et les outil qa vont signaler que le type de route est inconnu
le mieux pour cela est route=historic

> - ne doit plus exister ?

c'est une possibilité lorsqu'il n'existe plus de ligne sur le terrain
mais ici la ligne est toujours présente même si son état va lentement
se dégrader, alors je n'effacerais pas (encore) la relation

> --> Quid de l'attribut "name" des tronçons et de la relation ?

les rails ne devrait ne jamais avoir de nom (sauf s'il existe quelques
parts un rail ayant un nom, style rail d'inoguration ou d'un sponsort)
la ligne peux garder son name=* même si à mes yeux ce n'est pas un name
mais un from+ to=* mais hélas la discussion à ce sujet sur tagging
a bien avancé mais n'a pas totalement abouti (trop d'utilisation
en font usage + sérieux d'outil à adapter)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Intégration supports radio ANFR : différences mast/tower

[marc marc]

Le 09.01.20 à 01:39, François Lacombe a écrit :
> Je n'ai pas beaucoup participé aux discussions

de mémoire, sur tagging, la différence avait surtout été mis
sur comment on y monte : mat par dehors, polygone par dedans.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] 1ere mondiale (enfin je crois) : le réseau de transport électrique français est routable

[marc marc]

Le 07.01.20 à 08:41, Christian Quest a écrit :
> je ne suis pas sur le transfo de

l'étendue de distribution d'un transfo est-elle connue ?
ou pour le dire autrement, peux-t-on avoir l'info inverse :
tel transfo alimente tel rue + tel rue + tel rue ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] adresse mail rejetée - expéditeur wanadoo.fr via gmail pour destintaire free gmail laposte et autres

[marc marc]

Le 08.01.20 à 01:28, Philippe Verdy a écrit :
> Pour ceux auxquels je réponds
je redis :
même les NOUVEAUX messages que TU écris, TOUS sont en @wanadoo
comme par exemple ton email avec le sujet communes-communautés.

Je réitère ma demande de cesser d'envoyer à la liste
TOUT emails expéditeur @wanadoo.fr via les serveurs email de gmail.

Même si gmail le permet, gmail free laposte et d'autres serveurs
sont irrité par cette technique courante de spam, ce qui provoque
des nuissances collectives importantes.

> Le mar. 7 janv. 2020 à 21:56, marc marc a écrit :
> 
> Philippe ce n'est pas le cas, tous tes emails
> sont en verd...@wanadoo.fr , ci dessous
> les entêtes de celui auquel je répond.
> 
> j'ai aussi mis en dessous le nouveau thread
> que tu as créés aujourd'hui.
> 
> Je te sugère de désabonner l'email wanadoo
> pour ne garder que l'abo en gmail.com <http://gmail.com>
> ansi le problème cessera de lui-même.
> 
> Philippe Verdy a écrit :
>> Pour les nouveaux messages à la liste, 
>> j'envoie maintenant avec mon adresse Gmail
> 
>  Message transféré 
> Sujet :         [OSM-talk-fr] communes-communautés
> Date :  Tue, 7 Jan 2020 19:08:33 +0100
> De :    Philippe Verdy mailto:verd...@wanadoo.fr>>

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

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

[marc marc]

Le 08.01.20 à 08:53, ades a écrit :
> 
> je ne compte plus les messages de « bounced" depuis 1 ou 2 mois, je n’en 
> n’avais jamais avant… et mon adresse mail est tout ce qu’il y a de plus 
> simple, 'at orange', sans aucune redirection…

je sais que le sujet est complexe, mais il est important de comprendre
qu'il y a 2 groupes qui coexiste pour provoquer le problème :
- un groupe d'email d'expéditeur donc la config email n'est pas
classique (par exemple écrire avec une email wanadoo.fr comme expéditeur
en utilisant un compte gmail)
- un groupe d'email de destintaire donc la config email est "stricte"

quand l'email d'un expéditeur en question arrive à un des destinataire
en question, le serveur de celui-ci la rejette (message 550 spam detecte
dans le cas de free.fr)
quand le gestionnaire de la liste recoint trop de rejet, il désinscrit
le(s) destintaire(s) en question, quand bien même c'est pas leur faute
si l'expéditeur "pas classique" continue
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] la voie verte fantôme

[marc marc]

> Le 8 janv. 2020 à 08:57, Arnaud Champollion 
>  a écrit :
> 
> Est-il envisageable de supprimer purement et simplement ces chemins ?

Si cela ne correspond à rien et que le contributeur fautif ne corrige pas, il 
faut évidement le supprimer.
Si le contributeur recommence, signale le au DWG
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[marc marc]

Le 08.01.20 à 00:04, Christian Quest a écrit :
> Certes, mais ceci devrait arriver sur toutes les ML... or il n'y a que
> sur talk-fr que je suis (et pas tout seul) régulièrement désabonné pour
> cause bounce.

le premier cas (nombreux email @yahoo.fr émis depuis les serveurs gmail)
n'est apparement pas si courant :)
et/ou les autres listes ont la protection dmnarc activitée
comme la liste tech par ex
___
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

[marc marc]

Le 07.01.20 à 16:54, Philippe Verdy a écrit :
> pour les routes (sur la voie publique) on n'a pas besoin de clé car il
> n'y a à priori qu'un opérateur public attitré localement

il y a le national, le départemental, le communal, les concessions
d'autoroute et dans d'autres pays, il y a encore d'autres cas.
ce n'est donc pas cela la raison, la raison est franco-française :
on a en france qlq passionés des espaces de noms au point qu'on
en rajoute encore et encore parce que "d'autres l'ont fait".

si on veux distinguer les opérateurs ou les réseaux,
il y a les clefs qu'il faut pour.
quand je map un power=substation hors de France,
je n'ai pas besoin de wiki et pas besoin d'altérer le résultat
de mon éditeur, je met la ref dans ref et c'est terminé.

Le 07.01.20 à 17:05, Yves P. a écrit :
> si on ne connait pas la ref:* à mettre, on peut mettre ref

bien évidemenmt. mais elle serra invisible pour ceux qui ciblent
les ref:FR:xxx

Le 07.01.20 à 17:05, Yves P. a écrit :
> Les intérêts sont :
>
>   * de lier l’objet OSM à un objet dans une base de donnée externe.

c'est tout autant lié avec ref

>   * pour un objet qui a plusieurs références, de les différencier.

hors France, il y a aussi des objets multi-référence (dont les routes)
cela ne les empeches pas d'avoir comme règle de base d'utiliser ref
et de préciser la clef quand il y a besoin et non comme règle de base

>   * pour une machine (voir un humain), de savoir à quoi ça correspond.
> Référence de l’opérateur, de la commune… ?

on fait pareil avec name ? remplacer par défaut name=truc
par name:lenomdelentitiéquiadefinitlenom=truc ?
c'est compréhensible de vouloir être précis mais c'est nuisible d'en
faire un règle de clef par défaut.

je pense qu'il n'est pas du rôle d'osm de devoir
connaitre qui a définit la ref lisible sur plaque comme prérequis
pour l'ajouter correctement dans osm.
j'en reviens avec l'analogie des routes, on utilise ref pour la
référence principale sans se soucier si la ref a été définie
par la commune ou par le niveau national.
Et uniquement quand il y a plusieurs ref, on fait une règle
pour les autres ref. idem pour les noms, idem pour tout.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[marc marc]

Philippe ce n'est pas le cas, tous tes emails
sont en verd...@wanadoo.fr, ci dessous les entêtes
de celui auquel je répond.

j'ai aussi mis en dessous le nouveau thread
que tu as créés aujourd'hui.

Je te sugère de désabonner l'email wanadoo
pour ne garder que l'abo en gmail.com
ansi le problème cessera de lui-même.

 Message transféré 
Sujet : Re: [OSM-talk-fr] adresse mail rejetée
Date :  Tue, 7 Jan 2020 18:17:58 +0100
De :Philippe Verdy 


Pour les nouveaux messages à la liste, j'envoie maintenant
avec mon adresse Gmail


 Message transféré 
Sujet : [OSM-talk-fr] communes-communautés
Date :  Tue, 7 Jan 2020 19:08:33 +0100
De :Philippe Verdy 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[marc marc]

Bonjour,

J'ai discuté avec TomH ce midi. Le soucis semble être double :

- certains email sont protégé par spf et/ou dmarc,
une technologique qui permet de préciser qui a le droit d'envoyer
un email avec tel domaine ou tel serveur/ip.
les listes de diffusion cassent cette protection (pour le destinataire,
l'email n’apparaît plus comme venant de l'expéditeur d'origine mais
comme venant d'un serveur sans rapport avec le domaine initial).
Certains domaines de destination sont stricts sur ce critère,
ce qui provoque un bounce et une fois atteint x bounce, le serveur de
liste désinscrit ce destinataire.
une modification a été faite à ce sujet pour modifier ces emails et
mettre talk-fr comme expéditeur à la place (cfr mon email de 16h05
comme exemple).
cependant mon email suivant n'a pas été masqué, donc p'tre qu'il
reste un problème.

- certains domaines de destination ne semble pas aimer les emails
redirigé. en effet ils reçoivent par exemple un email @wanadoo.fr
avec l'ip d'un serveur qui n'est pas celui de wanadoo mais gmail.
ils peuvent considérer cela comme de l'usurpation classique des spam.
dans les logs, le serveur free.fr répond par exemple "550 spam detected"
Pour résoudre cela, soit il faut demander à free.fr d'être moins strict
(quasi aucune chance d'aboutir) soit les utilisateurs inscrits via un
domaine mais qui transmettent cet email à un autre hébergeur devrait
cesser ce le faire et s'inscrire directement avec cet autre hébergeur.
les différents cas trouvé par TomH pour talk-fr concerne tous Philippe
Verdy mais il n'a pas faire une analyse complète, donc si d'autres sont
dans le cas, n'hésitez pas à signaler/migrer :)

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

Re: [OSM-talk-fr] Comment libeller une fontaine d'eau en pierre (qui n'est pas un monument) ?

[marc marc]

pour ceux craintif à propos de l'aspect légal,
c'est justement l'intérêt du tag drinking_water:legal
il fait la différence entre "tout le monde la boit" et "qlq a
fait l'analyse et/ou a posé un panneau qui le dit"

il y a une erreur dans ton raisonnement ci-dessous :
une belle fontaine en pierre et potable est amenity=fountain
et drinking_water=yes

Le 07.01.20 à 16:20, European Water Project a écrit :
> Merci Marc
> 
> Pour les fontaines qui sont indiquées "non potable", nous ne pouvons
> qu'inciter les personnes de ne pas libeller la fontaine comme autre
> chose que "amenty=fountain et drinking_water=no". Nous ne pouvons pas
> assurer de la qualité de l'eau sans que les testes (qui ne sont pas
> couteux) soit faites par les autoritées compétentes et je ne prendrai
> pas cette responsabilité. 
> 
> Et dans ce cas,  il y a une incoherence entre une belle fontaine en
> pierre dans un village français qui sera juste "amenity=drinking_water"
> is l'eau est potable, et "amenity=fountain" et "drinking_water=no" si la
> fontaine n'est pas potable. 
> 
> bien cordialement,
> 
> Stuart 
> 
> On Tue, 7 Jan 2020 at 16:05, marc marc via Talk-fr
> mailto:talk-fr@openstreetmap.org>> wrote:
> 
> Bonjour,
> 
> il y a 2 points différents dans ta question
> 
> 1) à quoi ressemble l'objet ?
> la différence entre amenity=drinking_water <> amenity=fountain
> concerne l'apparence.
> un simple robinet d’où coule de l'eau avec une plaque d'égout en
> dessous, ce n'est pas une fontaine.
> un objet artistique, avec parfois plusieurs jets ou sculpté a des chance
> d'être une fontaine.
> évidement le problème est entre les 2 (ex un objet en pierre sculpté
> avec un simple jet d'eau). mais je suis d'accord avec Stefan : à priori
> quand il y a un doute, c'est un amenity=drinking_water
> il ne serrait d'ailleurs pas trop grave de mettre amenity=drinking_water
> sur une fontaine, osm se fait de manière incrémentielle, une fois la
> localisation précise connue, et qui plus est grâce aux photos que vous
> voulez récolter, il serrait facile d'améliorer la description de l'objet
> dans osm si nécessaire
> 
> 2) potable ou non potable ? légalement ou en pratique ?
> tant un point d'eau qu'une fontaine peux fournir de l'eau potable
> ou non ou potable sans garantie légale
> Pour ma part, je m'en tiens à la page wiki
> https://wiki.openstreetmap.org/wiki/Key%3Adrinking_water
> s'il y a un panneau potable ou si c'est manifestement fait pour se
> désaltérer (cas du mobilier urbain avec un robinet ou bouton poussoir)
> amenity=drinking_water ou drinking_water:legal=yes sur une fontaine
> s'il y a un panneau non potable drinking_water:legal=no
> s'il me semble raisonnable de boire l'eau drinking_water=yes
> s'il me semble déraisonnable de boire l'eau drinking_water=no
> 
> Cordialement,
> Marc
> 
> Le 07.01.20 à 15:45, European Water Project a écrit :
> > Bonjour, 
> >
> > Nous avons les instructions maintenant en 6 langues pour comment
> ajouter
> > une fontaine en OpenStreetMap et une photo d'une fontaine en Wikimedia
> > Commons. Nous avons eu beaucoup d'aide pour completer cette tache
> d'OSM
> > Suisse et d'OSM Espagne.
> >
> >
> 
> https://meta.wikimedia.org/wiki/Wikimedia_CH/Project/European_Water_Project/fr
>    
> >
> > Stefan Keller d'OSM Suisse nous conseil de mettre comme tag pour la
> > grande majorité de fontaines que  "amenity=drinking_water" et de
> ne pas
> > mettre 2) "amenity=fountain et drinking_water=yes".  Vous etes plutôt
> > d'accord ? Malheureusement en France, la grande majorité de
> fontaines en
> > pierre avec de l'eau 100% potable sont libellée "non potable" par peur
> > du procès des maires (et ils ont raisons, tant que la legislation ne
> > change). Dans ce cas, faut-il mettre "amenity=fountain et
> > drinking_water=no".  Et si un jour la legislation change pour ces
> > fontaines, on mettra que "amenity=drinking_water" ?
> >
> > Bien cordialement,
> >
> > Stuart 
> >
> >
> >
> > On Fri, 27 Dec 2019 at 14:13, European Water Project
> >  <mailto:europeanwaterproj...@gmail.com>
> <mailto:europeanwaterproj...@gmail.com
> <mailto:europeanwaterproj...@gmail.com>>>
> > wrote:
> >
> >     Bonjour, 
> >
>

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

[marc marc]

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.

Pour ma part, je me posais la question de ce que je considère comme
une surutilisation non nécessaire des espaces de nom (l’enchaînement
de clef: pour préciser une clef)
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.
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.

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

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

Re: [OSM-talk-fr] Comment libeller une fontaine d'eau en pierre (qui n'est pas un monument) ?

[marc marc via Talk-fr]

Bonjour,

il y a 2 points différents dans ta question

1) à quoi ressemble l'objet ?
la différence entre amenity=drinking_water <> amenity=fountain
concerne l'apparence.
un simple robinet d’où coule de l'eau avec une plaque d'égout en
dessous, ce n'est pas une fontaine.
un objet artistique, avec parfois plusieurs jets ou sculpté a des chance
d'être une fontaine.
évidement le problème est entre les 2 (ex un objet en pierre sculpté
avec un simple jet d'eau). mais je suis d'accord avec Stefan : à priori
quand il y a un doute, c'est un amenity=drinking_water
il ne serrait d'ailleurs pas trop grave de mettre amenity=drinking_water
sur une fontaine, osm se fait de manière incrémentielle, une fois la
localisation précise connue, et qui plus est grâce aux photos que vous
voulez récolter, il serrait facile d'améliorer la description de l'objet
dans osm si nécessaire

2) potable ou non potable ? légalement ou en pratique ?
tant un point d'eau qu'une fontaine peux fournir de l'eau potable
ou non ou potable sans garantie légale
Pour ma part, je m'en tiens à la page wiki
https://wiki.openstreetmap.org/wiki/Key%3Adrinking_water
s'il y a un panneau potable ou si c'est manifestement fait pour se
désaltérer (cas du mobilier urbain avec un robinet ou bouton poussoir)
amenity=drinking_water ou drinking_water:legal=yes sur une fontaine
s'il y a un panneau non potable drinking_water:legal=no
s'il me semble raisonnable de boire l'eau drinking_water=yes
s'il me semble déraisonnable de boire l'eau drinking_water=no

Cordialement,
Marc

Le 07.01.20 à 15:45, European Water Project a écrit :
> Bonjour, 
> 
> Nous avons les instructions maintenant en 6 langues pour comment ajouter
> une fontaine en OpenStreetMap et une photo d'une fontaine en Wikimedia
> Commons. Nous avons eu beaucoup d'aide pour completer cette tache d'OSM
> Suisse et d'OSM Espagne.
> 
> https://meta.wikimedia.org/wiki/Wikimedia_CH/Project/European_Water_Project/fr
>    
> 
> Stefan Keller d'OSM Suisse nous conseil de mettre comme tag pour la
> grande majorité de fontaines que  "amenity=drinking_water" et de ne pas
> mettre 2) "amenity=fountain et drinking_water=yes".  Vous etes plutôt
> d'accord ? Malheureusement en France, la grande majorité de fontaines en
> pierre avec de l'eau 100% potable sont libellée "non potable" par peur
> du procès des maires (et ils ont raisons, tant que la legislation ne
> change). Dans ce cas, faut-il mettre "amenity=fountain et
> drinking_water=no".  Et si un jour la legislation change pour ces
> fontaines, on mettra que "amenity=drinking_water" ?
> 
> Bien cordialement,
> 
> Stuart 
> 
> 
> 
> On Fri, 27 Dec 2019 at 14:13, European Water Project
> mailto:europeanwaterproj...@gmail.com>>
> wrote:
> 
> Bonjour, 
> 
>  
> 
> Je serai reconnaissant si vous pouvez nous donner vos commentaires
> sur les instructions en français de comment ajouter une fontaine
> d’eau potable dans OpenStreetMap et une photo d’une photo dans
> Wikimedia Commons.
> 
>  
> 
> Nous présentons le projet et l'application pour la première fois le
> 8 janvier devant 860 lycéens de 48 pays - dont la moitie francophone. 
> 
>  
> 
> 
> https://meta.wikimedia.org/wiki/Wikimedia_CH/Project/European_Water_Project/fr
>   
> 
>  
> 
> Bien cordialement,
> 
>  
> 
> Stuart Rapoport
> 
> 
> 
> ___
> 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] Mentions légales

[marc marc]

Le 07/01/2020 à 09:43, Xavier BIZOT a écrit :

> Comment faire lorsque la mention OSM
> n'est pas présente sur la carte

https://wiki.openstreetmap.org/wiki/FR:Manque_d%27attribution_appropri%C3%A9e
est-ce ceci que tu cherches ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

[marc marc]

@Martin
> You mentioned the cities in Morocco
> https://www.openstreetmap.org/node/288704798
> The only difference is that the Baltic Sea involves a couple more languages.

no the main difference is :
Morocco local rules about name <> one mapper rule about the world
talking and (trying to) building a new global rule is fine.
having a global rule per contributor only produce edit wars.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

[marc marc]

Le 06.01.20 à 16:35, Martin Koppenhoefer a écrit :
> in OpenStreetMap we’re trying to represent the current state of things

I agree with that.

> English using it in international context as a fallback.

yes as a fallback, not as a rule "international -> name=name:en"
but if a lake is in a multi-lingual area, if a country has several
official languages, if a sea is bordered by countries which together
have a very small number of names (2 or 3 in the case of the Baltic Sea)
or even a name with a large majority, if a continent has a majority
language, there is no obligation to use English as a fallback:

if the local community around the lake decides to have a name other
than English, if a country have a multilingual name, if the community
of the countries around the Baltic Sea decides to use the most used
name or a combination of the 3 most common, if a local majority of
a continent decide to use Portuguese/Spanish or any other language that
better represents the name as used there, I see no reason for this not
to happen.
but this must be done in a transparent way, (a message on the forum with
announcements in the national lists?) and then documented on the
multilingual names page, and not a mecanical edit because a contributor
wants such a language.

Once the language of the name tag is modified, I see no reason why
the wikipedia language could not be modified in the same language
as the name if that wikipedia page exists and is not a stub.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

[marc marc]

Le 06.01.20 à 01:28, Tomek a écrit :
> W dniu 20-01-06 o 00:24, marc marc pisze:
>> are you planning a mechanical edit ?
> NE, mi volas redakti ĉiun punkton aparte.

editing one by one, doesn't solve the the mechanical issue,
mechanical isn't about the size of the changeset,
it's about the "select objects by a query (for ex all sea in this area)
without a review/local knowledge.

> W dniu 20-01-06 o 00:24, marc marc pisze:
>> A more pragmatic solution would be to propose that each of these objects
>> have a name either in the most common language of that place, or in the
>> languages of that place or in a neutral language for example an
>> artificial language such as Esperanto.
> La problemo estas, ke ne eblas difini lingvon de ekzemple Balta Maro

really ? reading wikipedia for 2 min, I have a less chaotic vision
https://en.wikipedia.org/wiki/en:Baltic%20Sea?uselang=fr#Etymology
the current name is used extensively, including by a neighboring Baltic
country.
the article gives 2 other names used by 2 other neighboring countries.
the name tag of a multilingual zone must not contain 9 versions.

previous revert does not state on your arguments, it was done because
you are doing mass editions without following the rules that have been
written to avoid edit wars when 2 people have a different opinion.
it's sad to see that you've started again a few days ago.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] absence de BAN dans BANO

[marc marc]

Le 31.12.19 à 15:51, Christian Quest a écrit :
> la BAN sera dispo "avant la fin de l'année" sous Licence Ouverte, donc
> compatible avec l'ODbL d'OSM et de BANO.

je n'ai pourtant pas encore commencé le réveillon.
mais depuis quand l'obligation d'attribution de la LO est compatible
avec l'absence d'attribution des sources contribuant à osm ?
si j'affiche la carte d'un changeset provenant d'une source LO,
il y a pas d'attribution "donnée venant de cette source LO"
c'est pour cela qu'il me semblait qu'on devait se farcir
des demandes d'exeption pour que la source accepte de renoncer
à l'attribution et se contente d'être mentionné dans les sources
contribuant à osm

Je suis en tout cas ravi si la BANOv2 ou v3 (surtout ses outils
à la contribution osm) incluera la BAN en dernier resort.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] absence de BAN dans BANO

[marc marc]

Bonjour,

Quelle est la raison pour ne pas intégrer la BAN Odbl dans BANO ?
Dans certaines commune, BANO est pauvre, par ex Ceyzérieu 01073
Bano ne contient même pas l'adresse de la mairie
et de nombreuses voies "sans adresse" dans BANO
ont des adresses dans la BAN.
ex Rue de Bourbouillon

il parait qu'elle ne serra plus publiée à partir de demain :(
p'tre que Christian en ferra un archivage :)

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

Re: [OSM-talk-fr] heure d'ouverture dépassant 255 caractères

[marc marc]

Le 31.12.19 à 00:37, Philippe Verdy a écrit :
> Mais que penser de ma proposition de rendre tous les espaces facultatifs

postée ici, elle n'a aucune chance d'être par les dev des différentes
applications.
postée sur tagging, dans une version digeste, elle aura sans doute du
soutient et des détracteurs. pas sur que cela suffise vu que d'autres
idées moins problématique n'ont pas abouti à être adpètées.

moi je suis d'avis : si la valeur souhaité d'une clef est indigeste pour
un humain (parce que c'est cela la logique des clef/valeur d'osm),
alors c'est pas une bonne valeur (=faut faire autrement)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Plusieurs relations pour la même rue...

[marc marc]

Le 30.12.19 à 22:16, deuzeffe a écrit :
>> Chemin : Rue des Libellules (72456629)
> 
> Ce n'est pas une rue, mais une voie privée : elle fait partie intégrante
> de la parcelle 450. Classique dans les lotissements arrangés façon
> Tétris. À débaptiser et passer en highway=service ? 

oui

> Voire à supprimer ?

non car un jour un autre contributeur la recréera :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] SPAM, Tag PMU ?

[marc marc]

Le 30.12.19 à 12:13, Cyrille37 OSM a écrit :
> C'est dommage que https://wiki.openstreetmap.org/wiki/Key:vending soit
> réservée pour les "vending_machine".

c'est pour cela qu'il a été créé.
mais il y a déjéà 1 objets avant vending=* sans amenity=vending_machine
il s'utilise par exemple fréquement pour shop=farm
mais ceci dit, cela ne résoud qu'à moitié le problème.
tu peux lister le détail quand il y a quelques produits,
mais c'est un sous-tag, il faut donc un tag principal adapté.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tag pour bar + restaurant ?

[marc marc]

Bonjour,

Le 30.12.19 à 11:43, pepilepi...@ovh.fr a écrit :
> un bar, un café qui propose AUSSI des repas

>   * amenity=bar;restaurant ?

malheureusement quasi aucun outil (rendu, recherche dans une appli gps)
ne gère 2 valeurs dans un tag principal :(

>   * amenity=bar + restaurant=yes ?

cela convient bien si l'un est une activité annexe de l'autre

>   * un noeud amenity=bar + un noeud amenity=restaurant dans le même
> bâtiment ?

cela convient bien si les 2 activités sont "principales"

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

Re: [OSM-talk-fr] heure d'ouverture dépassant 255 caractères

[marc marc]

quand c'est trop tordu ou trop long, on peux aussi se limiter à
opening_hours:url
ok les très rare outils affichant que le poi est "ouvert en ce moment"
ne le feront plus, mais vu qu'en plus la majorité des outils n'arrivent
pas à lire l'ensemble des specs, au moins l'humain qui veux savoir
trouvera une version humainement plus lisible
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] OSMOSE : Intégration de support radio pas encore en service

[marc marc]

Bonsoir,

Le 29.12.19 à 20:10, Yves P. a écrit :
> En intégrant un support d’antenne avec Osmose, j’ai constaté qu’il
> n’était pas visible dans Cartoradio.
> C’est en fait un émetteur pas encore en service. (Dans Cartoradio, il
> faut sélectionner "Toutes les stations » pour le voir)
> 
> http://osmose.openstreetmap.fr/fr/error/b7782955-a9e0-6479-0ffb-b7517a681c8b
> https://www.cartoradio.fr/index.html#/cartographie/lonlat/-61.0337639/16.3242967
> 
> Faut-il l’intégrer, et donc le proposer dans Osmose ?
> Il me semble que les projets ne sont parfois pas réalisés ?

tu maps un support d'antenne ou un émetteur ?
les 2 ne sont pas nécessairement réalisé en même temps

Mais pour ce support, selon cartoradio, il est :
- utilisé pour téléphonie orange+tnt+autre faisceau orange
- "toutes" rajoute free (qui n'est pas ou plus ou pas encore utilisé)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Limite de 255 caractères dans OSM

[marc marc]

Le 28.12.19 à 17:28, Yves P. a écrit :
> 
>> le fait que cela va casser une partie des outils utilisant l'api actuelle
> Ils sont répertoriés ?

je n'ai jamais vu (ni cherché) ce genre de liste.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Limite de 255 caractères dans OSM — Re: Problème avec ID - besoin d'aide

[marc marc]

Le 28.12.19 à 17:17, Yves P. a écrit :
> En savez-vous plus sur ce qui coince exactement ?

le fait que cela va casser une partie des outils utilisant l'api actuelle
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import bâti cadastre dans JOSM

[marc marc]

Le 28.12.19 à 11:38, rainerU a écrit :
> j'ai constaté que les données dans les fichiers générés sur
> cadastre.openstreetmap.fr étaient plus à jour que les données Etalab.
> Par exemple ici:
> 
> https://www.openstreetmap.org/#map=19/42.62719/2.76934
> 
> Est-ce un bug ou y a-t-il une vrai différence de mise mise à jour ?


Etalab via plugin josm : maj trimestrielle
pdf via cadastre.openstreetmap.fr : maj en continu
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] SPAM, Re: Banque de France

[marc marc]

Le 27.12.19 à 22:46, David Crochet a écrit :
> Bonjour
> 
> Le 27/12/2019 à 21:41, Arnaud Champollion a écrit :
>> En tout cas, je ne vois effectivement pas comment je peux ouvrir un
>> compte à la Banque de France, encore moins y obtenir un chéquier, et
>> ne connais personne dans mon entourage pour qui c'est le cas.
> 
> 
> Recevant des chèque pour le compte d'une association, j'y retrouve bien
> des chèque émis au nom de la Banque de France, avec une belle écriture
> calligraphique vert  sur fond vert clair

je suis bien surpris.
l'iban de ces asso dit quoi ?

> La banque de France ouvre un compte avec un attestation de refus
> d'ouverture de compte puisque l'ouverture d'un compte est un droit
> (article L312-1 du code monétaire et financier)

mais le site de la banque de France elle-même dit qu'elle désignera
une banque pour faire respecter ce droit.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] outil https://cadastre.openstreetmap.fr patché à gogo

[marc marc]

Bonsoir,

3 [1] barbus [2] ont passé la soirée sur irc pour patcher l'outil,
il devrait refonctionner comme il faut.
Si quelque chose bug encore, remontez l'info :)

[1] Merci Gautier et Vincent \o/
[2] même pas vrai. mais c'est l'expression consacrée :)

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

Re: [OSM-talk-fr] SPAM, Re: Banque de France

[marc marc]

Le 27.12.19 à 21:41, Arnaud Champollion a écrit :
> building=public ?

cette valeur est à mon avis un non sens.
public=* décrit le style. c'est quoi un style "batiment hébergeant un
service public" ?
mettons le building=* comme pour tout batiment, indépendament de l'usage
(qui est renseigné par un autre tag)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import bâti cadastre dans JOSM

[marc marc]

Le 27.12.19 à 15:22, Eric SIBERT a écrit :
> Heu... et sinon, j'ai un autre problème. J'arrive sur une zone. Je
> constate que le bâti dans OSM est mal calé (par rapport au GPS, aux
> orthophotos...). Je vois aussi que le cadastre actuel est mieux calé. Je
> voudrais ré-importer mais en conservant les tags des anciens bâtiments.
> Une méthode facile proposée?

https://cadastre.damsy.net te prémache un conflate dans josm qui te
permet de conserver les id et les tags existant dans osm

Tu peux bien évidement aussi charger le tout "à la main" comme
d'habitude et exécuter le script de config de https://cadastre.damsy.net

tu peux aussi le faire "à la main", avec l'option "remplacer la
géométrie" disponible dans le menu lorsque tu installes UtilsPlugin2

la dernière solution si c'est juste un décalage est de sélectionner tout
le batiment et de déplacer (à la souris) la sélection pour l'aligner par
exemple sur l'imagerie.

dans tous les cas, on finit souvent par avoir à ajuster aussi les routes
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Banque de France

[marc marc]

Le 27.12.19 à 14:26, Philippe Verdy a écrit :
> Le ven. 27 déc. 2019 à 13:49, marc marca écrit :
>> si on peux y ouvrir un compte, c'est bien un amenity=bank (j'en doute)
> Pas de raison d'en douter:
> https://particuliers.banque-france.fr/

au contraire, la page droit au compte confirme que
https://particuliers.banque-france.fr/page-sommaire/droit-au-compte
"désignation <...> par la Banque de France d'un établissement bancaire
qui devra <...> vous ouvrir un compte"
La BnF est l'organe régulateur, ce n'est pas une amenity=bank.
ce n'est pas chez elle que tu as ton compte.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import bâti cadastre dans JOSM

[marc marc]

Le 27.12.19 à 14:09, Philippe Verdy a écrit :
> réimporter le cadastre ? Pour quoi faire ?

Pour ajouter dans osm les nouveau batiments et ceux ayant été fortement
modifié (hangar agricole devenu un immeuble de logement, annexe doublant
parfois la surface du bati)
l'outil en question permet de les détecter, à l'échelle d'une commune,
en un temps record, ce qui n'est pas du luxe à vérifier tout les 10 ans.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Banque de France

[marc marc]

Bonjour,

si on peux y ouvrir un compte, c'est bien un amenity=bank (j'en doute)

la banque centrale est bien une institution institutionnelle :)
le terme government est sans doute mal choisit mais d'après le wiki,
cela convient à l'exécutif, législatif et judiciaire.
donc j'utiliserais office=government comme en Belgique
https://www.openstreetmap.org/node/1348588611

Cordialement,
Marc

Le 26.12.19 à 21:06, Arnaud Champollion a écrit :
> Bonjour,
> 
> La Banque de France doit-elle être qualifiée "bank" sur OSM ?
> 
> Selon les villes, je vois, soit rien, soit amenity=bank, soit
> office=governement, ou encore landuse=commercial
> 
> Sur Wikipédia on peut lire : La Banque de France est une institution
> indépendante, membre de l'Eurosystème
>  (ainsi que du Système
> européen de banques centrales
> )
> depuis le 1^er  janvier
>  1999
> .
> 
> Merci
> 
> Arnaud
> 
> 
> ___
> 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] Import bâti cadastre dans JOSM

[marc marc]

Bonjour Vincent,

ton email est parfaitement juste, sauf qu'il parle de la technique
sous-jacente et pas une seconde de l'expérience utilisateur.
je t'invite à tester https://cadastre.damsy.net
pour par exemple mettre à jour une commune dont le cadastre date de 2008
et faire donc une maj des bâtiments nouveaux et modifié entre temps.
Ensuite je t'invite à utiliser tous sauf ce site pour faire la même
chose avec le cadastre vectoriel disponible via le plugin josm.
l'expérience utilisateur est en défaveur des outils cadastre vectoriel.

alors oui, évidement qu'à terme, l'utilisation des pdf cessera.
mais en attendant, au moins un des outils qui l'utilise est un des
plus abouti.
jeter cela en disant "yaka faire tout à la main avec le cadastre
vectoriel parce que c'est plus moderne" n'est pas très plaisant comme
réponse. surtout que Gautier a écrit les patchs pour corriger ce qui
doit l'être.

Pour ma part, l'intégration du cadastre à la main, c'est sans moi.
Je ne vois aucune raison valable de demander au contributeur
de passer 2x fois plus de temps que nécessaire alors qu'il
existe des outils qui utilisent mieux le cerveau humain et le temps
si précieux qui l'accompagne.
Et il reste aussi, à chaque fois que je met à jour une commune,
tant de "import cadastre à la main" à retoucher niveau qualité.

Cordialement,
Marc

Le 26.12.19 à 21:10, Vincent de Château-Thierry a écrit :
> Bonjour,
> 
> Le 26/12/2019 à 19:41, marc marc a écrit :
>> la grande différence c'est l'expérience de l'utilisateur.
> 
> Oui parlons-en de l'expérience utilisateur :)
> 
> Le sujet ici c'est de savoir si on doit maintenir une page (l'actuelle
> cadastre.openstreetmap.fr) qui s'appuie sur un processus d'accès au
> Cadastre (le recours aux PDFs d'impression de cadastre.gouv.fr) qui
> certes nous a sauvé la mise pendant des années, mais a avec le temps été
> rendu plus gourmand en ressources et est devenu obsolète avec
> l'apparition du cadastre redifusé par Etalab.
> 
> Entre le moment (juin 2010 [1]) où on a eu accès à ces PDFs et
> maintenant, un changement de configuration du site cadastre.gouv.fr à
> réduit d'un facteur 100 la surface terrain imprimable en PDF. Donc on a
> du augmenter d'un facteur 100 les appels aux serveurs du site pour
> obtenir la même couverture terrain en PDF. Ca c'est pour les ressources.
> 
> Pour l'obsolescence : les travaux côté Etalab sur la donnée cadastrale
> permettent maintenant un accès vectoriel au cadastre grandement facilité
> comme l'a rappelé Ades. C'est vrai pour les couches hors adresses ici :
> https://cadastre.data.gouv.fr/
> et pour les adresses là :
> https://adresse.data.gouv.fr/
> 
> Là dessus, le plugin Cadastre-fr a bénéficié d'une 2è vie (merci à
> Vincent Privat :) ) pour intégrer l'accès à ces couches directement
> depuis l'interface de chargement de JOSM.
> 
> On a donc au final directement dans le contexte d'intégration un accès
> aux données, sans passer par un site intermédiaire
> (cadastre.openstreetmap.fr) et en s'alignant sur de meilleures pratiques
> d'accès à la donnée, sans scraping. Je ne vois pas avec tout ça comment
> l'expérience utilisateur, plus intégrée, moins clickodrome, s'en
> trouverait altérée. De mon point de vue le "reste à faire" consisterait
> surtout à remplacer le contenu de la page d'accueil de
> cadastre.openstreetmap.fr par un lien vers le wiki expliquant la
> nouvelle manière d'accéder dans JOSM aux mêmes données.
> 
> vincent
> 
> [1] :
> https://lists.openstreetmap.org/pipermail/talk-fr/2010-June/022871.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] Import bâti cadastre dans JOSM

[marc marc]

la grande différence c'est l'expérience de l'utilisateur.
croire qu'un utilisateur de cadastre.openstreetmap.fr
va aller sur un site gouv.fr pour trouver ce qu'il a besoin
pour ensuite l'utiliser dans josm avec un plugin... c'est oublier que
c'est pas le niveau de la majorité des contributeurs.
à mon avis l'avenir c'est quelque chose genre https://cadastre.damsy.net
branché sur le cadastre vectoriel et bano v2
et encore, il reste pas mal d'idée (genre avoir la conflation qui se
fait sur le serveur, avoir une meilleur sélection de "ici il faut
intervenir", avoir une info de "ici batiment manquant") et idéalement
une intégration osmose (parce qu'il est plus pratique d'avoir un seul
outil qui te connecte à tous les autres plutôt
que d'avoir à parcourir une 10aine pour chaque catégorie)

Le 26.12.19 à 19:05, ades a écrit :
> Comprends pas trop ;-)
> C’est quoi l’intérêt du cadastre en ligne (si j’ai à peu près compris) avec 
> JOSM quand on peut importer le cadastre (à jour tous les trimestres, en shp, 
> en edigeo ou geojsom -là je suis moins sur pour ce format) à partir d’etalab 
> ? Et l’importer sans pb, par couches (bati, hydro, parcelle etc. dans Josm)
> Au moins on peut travailler calmement et en local ;-) (sans bouffer de la 
> bande passante et de l’énergie sur le net), on fait facilement une conflation 
> dans Josm, ou on peut aussi utiliser n’importe soft sig pour préparer les 
> données…
> 
> 
>> Le 26 déc. 2019 à 18:00, marc marc  a écrit :
>>
>> Bonjour,
>>
>> Le 26.12.19 à 15:52, Eric SIBERT a écrit :
>>> https://lists.openstreetmap.org/pipermail/talk-fr/2019-July/093691.html
>>>
>>> En allant sur cadastre.openstreetmap.fr, en non sécurié, en sécurisé
>>> simple, en sécurisé en cliquant sur le cadenas vert pour dire que ce
>>> n'est pas grave si tout n'est pas sécurisé, la fenêtre pour sélectionner
>>> la zone à exporter reste vide.
>>
>> avant il suffisait d'utiliser le site en http (parce qu'en https il y a
>> un mixed content)
>> mais il semble qu'un autre soucis existe : cadastre.gouv.fr ne fournit
>> plus de donnée en http
>> les 2 ensemble font que c'est devenu inutilisable
>> j'ai lancé un appel à maintenance sur ce dépot car je n'ai pas accés
>> pour merger.
>> si cela ne réagit pas, je ferrai les modifs à la main sur le serveur.
>>
>>
>>> Directement dans JOSM, je vais dans Télécharger puis l'onglet
>>> "Téléchargement depuis le Cadastre". Je sélectionne la zone et ça
>>> télécharge. Je me retrouve avec des couches edigo-xxx.tar.bz2 avec deux
>>> petits triangles oranges d'avertissement. Quand je fusionne avec le
>>> calque principal, les triangles sont transmis au calque principal. Je ne
>>> peux alors pas renvoyer les données vers OSM.
>>>
>>> Comment j'importe un morceau de bâti du cadastre???
>>
>> il ne faut pas merger tout le calque mais sélectionner les batiments
>> manquant et merger la sélection
>>
>> 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] Import bâti cadastre dans JOSM

[marc marc]

Bonjour,

Le 26.12.19 à 15:52, Eric SIBERT a écrit :
> https://lists.openstreetmap.org/pipermail/talk-fr/2019-July/093691.html
> 
> En allant sur cadastre.openstreetmap.fr, en non sécurié, en sécurisé
> simple, en sécurisé en cliquant sur le cadenas vert pour dire que ce
> n'est pas grave si tout n'est pas sécurisé, la fenêtre pour sélectionner
> la zone à exporter reste vide.

avant il suffisait d'utiliser le site en http (parce qu'en https il y a
un mixed content)
mais il semble qu'un autre soucis existe : cadastre.gouv.fr ne fournit
plus de donnée en http
les 2 ensemble font que c'est devenu inutilisable
j'ai lancé un appel à maintenance sur ce dépot car je n'ai pas accés
pour merger.
si cela ne réagit pas, je ferrai les modifs à la main sur le serveur.


> Directement dans JOSM, je vais dans Télécharger puis l'onglet
> "Téléchargement depuis le Cadastre". Je sélectionne la zone et ça
> télécharge. Je me retrouve avec des couches edigo-xxx.tar.bz2 avec deux
> petits triangles oranges d'avertissement. Quand je fusionne avec le
> calque principal, les triangles sont transmis au calque principal. Je ne
> peux alors pas renvoyer les données vers OSM.
> 
> Comment j'importe un morceau de bâti du cadastre???

il ne faut pas merger tout le calque mais sélectionner les batiments
manquant et merger la sélection

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

Re: [OSM-talk-fr] Orthos: mise à jour 2018 sur de nombreux départements

[marc marc]

Le 24.12.19 à 15:32, Philippe Verdy a écrit :
> est-ce qu'OSM France propose une couche composite rassemblant les
> dernières meilleures ortho en date sur une couche simple

oui, christian l'a détaillé 3 email avant :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] osmose rétabli

[marc marc]

c'est rétablit.

Le 23.12.19 à 16:01, Marc M. a écrit :
> Bonjour,
> 
> osmose est ko.
> info de freed :
> une grosse migration
> ça devait être sans coupure mais ça a coupé quand même
> ça va prendre plusieurs jours :/
> 
> on regarde ce qu'on peux faire pour rétablir au + vite
> 
> Cordialement,
> Marc
> 

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

[OSM-talk-fr] osmose ko

[marc marc]

Bonjour,

osmose est ko.
info de freed :
une grosse migration
ça devait être sans coupure mais ça a coupé quand même
ça va prendre plusieurs jours :/

on regarde ce qu'on peux faire pour rétablir au + vite

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

Re: [OSM-talk-fr] Chambres d'agriculture, syndicats ouvriers

[marc marc]

Bonjour,

Le 23.12.19 à 12:18, Alain Rpnpif a écrit :
> chambres d'agriculture et autres chambres consulaires
> .
> 
> Que mettriez vous ?

office=government me semble convenir puisque c'est un établisement
de droit public.
sinon tu as aussi la valeur administration

> De même, pour les syndicats ouvriers (CGT, CFDT, FO, CFTC, Sud, etc.) je
> mettrais amenity=social_centre mais j'ai trouvé de tout sur OSM.

suppose être office=association
il y a aussi des office=union et labor_union

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

Re: [OSM-talk-fr] clairière dans une forêt

[marc marc]

> Le 22 déc. 2019 à 20:23, Arnaud Champollion 
>  a écrit :
> 
> il faut d'abord faire le trou dans la forêt avec un multipolygone puis 
> qualifier le chemin du trou (polygone intérieur) ?

Le MP est la bonne solution
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Osmose : Erreur sur remplacement clés "ref" sur réseaux de transports en commun

[marc marc]

Le 21.12.19 à 22:29, deuzeffe a écrit :
> Ce qui m'amène à une question de béotienne (éternelle) mais plus
> générale : doit-on (ou jusqu'où doit-on) préciser/affiner les ref:FR
> pour les réseaux de transport ?

je pense que cela n'apporte que des désavantages :
- l'exemple du réseau arc en ciel montre que croire qu'une ref:FR est
unique est une erreur.
donc si on voulait une clef unique, il faudrait aller encore plus loin
ref:pays:region voir commune
- tout utilisateur voulant ajouter une ref doit trouver un exemple bien
tagé à proximité ou trouver la page wiki ad-hoc.
- cela implique aussi automatiquement qu'il y aura des ref dans des
mauvaises clefs, donc un travail conséquent de maintenance à faire.
- niveau utilisation des données, cibler les arrêts d'une route d'un
operateur est aussi facile que cibler ref:FR:...
- à côté de cela, pour une route, la ref se met dans ref, tant à
Marseille ou à Genève.

pour les arrêts multi-opérateurs, une règle simple pourrait s'inspirer
des routes :
- la ref du réseau local du lieu -> ref=*
- la ref du réseau régional reg_ref=*
il ne resterait alors que des exeptions, quand un arrêt se trouve en
bordure de 2 réseaux locaux.
pour ceux là, ref:=* avec  valant exactement la
même chose que la clef operator=* de la relation route simplifierait
bien des choses.

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

Re: [OSM-talk-fr] Nommage/Numérotation hameaux (Était : Re: Joli noms de rues)

[marc marc]

Le 21.12.19 à 13:58, deuzeffe a écrit :
> Le 18/12/2019 à 22:54, marc marc a écrit :
> 
>>> je n'arrive pas à décider quelle est la moins mauvaise méthode.
>>
>> Addr:place :-) remplace addr:street ou associatedStreet lorsque le nom
>> ne vient pas d'une rue
> 
> Je rêve ou tu me proposes une 3e méthode !?

c'est pas une propositioon, addr:street <> associatedStreet <>
addr:place sont les 3 méthodes qui existent.
ce que je proposais c'est d'utiliser l'une d'elle avant
ou au lieu d'envisager d'en rajouter une 4ieme :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Nommage/Numérotation hameaux (Était : Re: Joli noms de rues)

[marc marc]

Bonjour,

> Le 21 déc. 2019 à 09:49, lenny.libre  a écrit :
> 
> si le lieu-dit existe en plus du village et qu'il est utilisé dans les 
> adresses, il devrait exister dans osm, même s'il parait faire doublon.
> 
> Quand  pensez-vous ?

Si le lieu-dit existe et est utilisé pour les adresses, il me semble normal de 
l'avoir dans osm.
La vrai question est de savoir si le bourg est la même chose que le village 
(dans ce cas un sel place avec name+alt_name est préférable) ou si ce ne sont 
pas exactement la même chose (je connais un village où le bourg désigné l'hyper 
centre, les habitations plus éloignées ont d'autres lieu-dit)

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

Re: [OSM-talk-fr] Requête overpass turbo - boulangeries à plus de 50 mètres d'un arrêt de bus

[marc marc]

alors il faut faire une soustraction :
(
toutes les boulangeries de la commune;
-
les boulangeries bien déservies renseignée par la requête ci dessous;
);

https://wiki.openstreetmap.org/wiki/FR:Overpass_API/Overpass_QL#Difference
l'erreur la plus courante est d'oublier le ; après chacun des 2 blocs.
je te laisse essayer ? si tu bloques, je m'y colles :)


Le 20.12.19 à 17:37, Thomas Ruchin a écrit :
> Merci c'est génial.
> Mais je veux identifier les boulangeries mal desservies. Donc celles à
> plus de 50 mètres (pas celles à moins de 50 mètres).
> 
> Le ven. 20 déc. 2019 à 17:13, marc marc  <mailto:marc_marc_...@hotmail.com>> a écrit :
> 
> Le 20.12.19 à 16:57, Thomas Ruchin a écrit :
> > Dans ma commune, je veux identifier les boulangeries (way, nodes,
> > relations) qui sont à plus de 50 mètres d'un arrêt de bus.
> 
> simplifie toi la vie :-)
> - pas besoin de nomer un jeux de donnée si tu ne l'utilises qu'une fois
> - utilise nwr pour avoir en une fois les objets de type
> node+way+relation
> 
> https://overpass-turbo.eu/s/P9e
> [out:xml];
> area[name="Montrouge"];
> nwr[highway=bus_stop](area);
> nwr(around:50)[shop=bakery];
> out meta;>;out meta;
> ___
> 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

Re: [OSM-talk-fr] Requête overpass turbo - boulangeries à plus de 50 mètres d'un arrêt de bus

[marc marc]

n'aurais-tu pas entre temps forcé dans tes paramètres d'utiliser un
autre serveur overpass api ? le serveur osm-fr par ex ne supporte pas
encore nwr (honte à moi, je ne l'ai pas encore fait la maj)

Le 20.12.19 à 17:22, Cyrille37 OSM a écrit :
> Merci Marc, encore une excellente contribution :-)
> 
> Et paf, je tombe sur un bug: la version overpass ne doit pas être la
> même sur HTTP que HTTPS pour overpass-turbo.eu. La requête fonctionne
> bien sur le https, mais la syntaxe échoue sur http à cause du "nwr".
> 
> Error: line 3: parse error: Unknown type "nwr"
> Error: line 3: static error: For the attribute "type" of the element
> "query" the only allowed values are "node", "way", "relation" or "area".
> 
> Cyrille37.
> 
> Le 20/12/2019 à 17:13, marc marc a écrit :
>> Le 20.12.19 à 16:57, Thomas Ruchin a écrit :
>>> Dans ma commune, je veux identifier les boulangeries (way, nodes,
>>> relations) qui sont à plus de 50 mètres d'un arrêt de bus.
>> simplifie toi la vie :-)
>> - pas besoin de nomer un jeux de donnée si tu ne l'utilises qu'une fois
>> - utilise nwr pour avoir en une fois les objets de type node+way+relation
>>
>> https://overpass-turbo.eu/s/P9e
>> [out:xml];
>> area[name="Montrouge"];
>> nwr[highway=bus_stop](area);
>> nwr(around:50)[shop=bakery];
>> out meta;>;out meta;
>> ___
>> 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] Requête overpass turbo - boulangeries à plus de 50 mètres d'un arrêt de bus

[marc marc]

Le 20.12.19 à 16:57, Thomas Ruchin a écrit :
> Dans ma commune, je veux identifier les boulangeries (way, nodes,
> relations) qui sont à plus de 50 mètres d'un arrêt de bus.

simplifie toi la vie :-)
- pas besoin de nomer un jeux de donnée si tu ne l'utilises qu'une fois
- utilise nwr pour avoir en une fois les objets de type node+way+relation

https://overpass-turbo.eu/s/P9e
[out:xml];
area[name="Montrouge"];
nwr[highway=bus_stop](area);
nwr(around:50)[shop=bakery];
out meta;>;out meta;
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[marc marc]

Le 20.12.19 à 16:51, Francois Gouget a écrit :
> On Mon, 16 Dec 2019, marc marc wrote:
> 
>>
>>> ce serait vraiment bien si
>>
>> Je redis parce que cela a visiblement été noyé dans la masse :
>> Il semblent n'yavoir aucun sysadmin osm.org
>> Donc leur parler ici revient à parler dans le vide (sauf à aider au 
>> diagnostic, qui lui nécessité le message de bounce).
>> Solution : soit aller voir les logs d'un serveur email perso soit 
>> signaler le soucis aux admin osm.org
> 
> 1. Je n'ai pas accès aux logs de Free.

c'est pour cela que j'en appellais à ceux qui sont abonné
via leur propre serveur :)

> 2. Je ne sais pas comment contacter les administrateurs osm.org.

https://wiki.openstreetmap.org/wiki/System_administrators
propose operati...@osmfoundation.org

> 3. Manifestement, en plus de ne pas y avoir d'administrateur sur cette 
>liste, il n'y a pas non plus qui que ce soit qui soit motivé pour 
>faire le relai ou au moins indiquer où signaler le problème.

c'est cela le soucis :) ceux qui ont le soucis n'ont pas envie de
frapper à la bonne porte et attendent que quelqu'un le fasse :)

> Anglais, Français ?

j'ignore qui s'occupe du serveur mail,
mais si tu maîtrises l'anglais, c'est préférable.


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

Re: [OSM-talk-fr] Nettoyage des clés FANTOIR et SANDRE

[marc marc]

Le 20.12.19 à 13:39, Yves P. a écrit :
> Il y a 122 clés old_ref:sandre qui ne doivent pas plus servir

est-ce que cela ne concernerait pas les déclassement pro-pollution ?
si oui cela pourrait être utile pour les asso concernées.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Nouvelles données ouvertes sur les réseaux électriques

[marc marc]

Bonjour François,

bravo pour ce travail de titan !

Le 19.12.19 à 15:20, François Lacombe a écrit :
> L'effort devrait se poursuivre en 2020 avec l'établissement d'un
> standard (j'espère)

tu veux parler des données contenu dans les base exportée ?
oserions nous rêver d’attributs inspiré d'osm lorsque ceux-ci sont
matures/bien choisit ? :)

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

Re: [OSM-talk-fr] Nommage des bâtiments scolaires / universitaires complexes

[marc marc]

Le 19.12.19 à 15:31, Arnaud Champollion a écrit :
> https://wiki.openstreetmap.org/wiki/FR:Tag:amenity%3Dschool#Sp.C3.A9cialisations
> Mais je n'ai pas compris l'histoire de la balise de troisième niveau.

cela a été ajouté il y a plus de 9 ans, sans aucune proposition de tag.
faudrait aller voir si la proposition education 2.0 en parle
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Nommage/Numérotation hameaux

[marc marc]

Le 19.12.19 à 22:43, Christian Rogel a écrit :
>> Le 19 déc. 2019 à 15:15, marc marc a écrit :
>> ce n'est en rien plus simple d'avoir un associatedStreet
>> version Christian R., supporté que par lui-même.
>> cela rendrait juste les données utilisables par tous sauf l'humain.

> La nécessité d’utiliser place pour une adresse serait liée au fait d’utiliser 
> des relations ?

non, c'est lié à :
addr:street est lié au highway=* du même nom
addr:place est lié au place=* du même nom
il n'y a aucune relation dans la base osm pour ces 2 tags, le lien se
fait avec "cet objet est sémantiquement lié à cet objet"

> pour moi, il n’y a que des noms de voie
alors pour toi, met un name sur le(s) highway=* du place
et utilise addr:street pour les addresses.
cela ne correspond pas à la réalité du terrain
mais cela serra au moins cohérent avec ton dogme et cela fonctionnera
parfaitement dans les différents outils et éditeurs.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu transport routier...

[marc marc]

Bonjour,

Le 19.12.19 à 17:31, laurent-38 a écrit :
> Voici une question « tagging » : lorsque la limitation est associée au
> panneau d’entrée en agglomération (genre interdit aux +3.5T sauf desserte),
> est-il suffisant de rajouter la limitation en question sur les segments en
> entrée d’agglomération, ou faut-il la mettre sur toutes les voies
> (principales) de l’agglomération ?

le mettre sur toutes les highway d'entrée, fonctionnera :)
mais jusqu'à ce qu'une nouvelle entrée fasse son apparition

c'est le même probblème que pour la vitesse agglomération par défaut :
pour le moment il faut la mettre sur tous les highway.

l'idéal est de créer une relation type=default pour la définir sur toute
l'agglomération mais aucun routage n'est connu pour l'utiliser,
en partie parce qu'il manque sans doute qlq détails pour la faire voter
(dont une simplification d'une série de ces relations, surtout au niveau
hierarchie)

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

Re: [OSM-talk-fr] Nommage/Numérotation hameaux

[marc marc]

Bonjour,

Le 19.12.19 à 13:44, Christian Rogel a écrit :
>> Le 18 déc. 2019 à 22:54, marc marc a écrit :
>> Addr:place :-) remplace addr:street ou associatedStreet lorsque le nom ne 
>> vient pas d'une rue.
> 
> Cela n’est pas très clair. Une rue = un nom de voie formé obligatoirement 
> d’un générique et d’un spécifique ?

non, il faut comprendre "rôle street" au sens osm cad un way avec un tag
highway=primary/secondary/tertiary/residential/living_street/service
que le nom ai un générique/spécifique ou autre n'est pas un critère
pour l'associatedStreet

> Le plus simple est de voir tout nom donné comme officiel, venant ou non d’un 
> nom de lieu que comme il a été voulu, un nom de voie.

ce n'est en rien plus simple d'avoir un associatedStreet
version Christian R., supporté que par lui-même.
cela rendrait juste les données utilisables par tous sauf l'humain.

Si on voulait progresser sur le sujet, il faudrait à mon avis commencer
par améliorer l'associatedStreet actuel dans les éditeurs, avant
d'envisager une proposition hypothétiquement acceptée regroupant
associatedStreet Street et les addr:place

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

Re: [OSM-talk-fr] Fwd: [osm-grenoble] Projet Europeen de l'Eau/European Water Project - Introduction

[marc marc]

Bonjour,

Le 19.12.19 à 11:33, European Water Project a écrit :
> Je viens de m'inscrire sur cette liste de distribution, donc je n'ai pas
> pu répondre à l'email précèdent sur le sujet.   

bienvenue !
les archives te permettent de lire ce qui s'est dit précédemment.
https://lists.openstreetmap.org/pipermail/talk-fr/2019-December/095604.html
tu peux facilement répondre (mais sans citation automatique) en cliquant
sur la 2ieme ligne de l'archive, celle contenant l'email de l'expéditeur
(il contient aussi l'id du message pour ceux qui ont un client qui
l'utilise).

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

Re: [OSM-talk-fr] Noms de rue, osmose et bano V2

[marc marc]

> Le 19 déc. 2019 à 12:03, Vincent Bergeot  a écrit :
> 
> je me demande si ces outils qualités se parlent et surtout comment ils se 
> parlent ?

Ils se parlent mais la version bano v2 n'est pas encore déployée/utilisée 
partout. D'où une partie des différences entre les outils.
Ils se parle via bdd (pour le rendu) et https (pour la remontée osmose)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Idée folle : changer building=service en building=utility lorsqu'applicable

[marc marc]

Le 19 déc. 2019 à 10:05, Yves P.  a écrit :

>> Je ne saisis pas comment tu veux d'écrire "une fois pour toute" quelque 
>> chose qui varie selon les cas (armoire de rue, bâtiment dit de service, 
>> poteau, pièce technique).
>> Pourrais-tu donner 2 exemples Switch dans une armoire de rue et dans une 
>> pièce multi-équipements) ?
> Je ne parlais pas de tous les tags, mais par exemple des man_made=*
> 
> Tu peux décrire (une fois pour toute) que power=switch n’est possible que 
> pour street_cabinet=power ou power=pole…

Tu peux très bien d'écrire qu'un Switch n'est possible qu'en combinaison avec X 
autres tags (encore qu'en l'occurrence il peux aussi être dans une pièce Tage 
séparément donc aucun tag sur l'objet). Mais cela n'empêche que j'aimerai bien 
que tu donnes les tags des 2 exemples, il faudra bien un tag pour dire que ce 
Switch la est par exemple dans une armoire alors que tel autre non
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Idée folle : changer building=service en building=utility lorsqu'applicable

[marc marc]

Le 19 déc. 2019 à 09:11, Yves P. a écrit :


C'est elle qui décrit s'il y a une armoire. Elle est utile à ceux que l'info 
intéresse :-)
Tu as effectivement raison :-)

Mais doit-on rajouter ça à chaque objet OSM ?
Ça peut-être décrit une fois pour toute dans une base sémantique.

Je ne saisis pas comment tu veux d'écrire "une fois pour toute" quelque chose 
qui varie selon les cas (armoire de rue, bâtiment dit de service, poteau, pièce 
technique).
Pourrais-tu donner 2 exemples Switch dans une armoire de rue et dans une pièce 
multi-équipements) ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Idée folle : changer building=service en building=utility lorsqu'applicable

[marc marc]

Le 19 déc. 2019 à 08:55, Yves P. a écrit :

  *   man_made=street_cabinet
  *   street_cabinet=power

la première clé ne sert à rien

C'est elle qui décrit s'il y a une armoire. Elle est utile à ceux que l'info 
intéresse :-)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Nommage des bâtiments scolaires / universitaires complexes

[marc marc]

Le 19.12.19 à 00:38, Philippe Verdy a écrit :
> 
> 
> Le mer. 18 déc. 2019 à 17:13, marc marc a écrit :
> 
> idem pour les crèches (amenity=kindergarden)
> 
> Tu fais comment quand le même établissement est à la fois une crèche,
> une maternelle (selon l'heure de la journée), un centre de loisirs: un
> établissement avec le même directeur ayant plusieurs activités ?

comme pour n'importe quel poi multi-activité,
il faut savoir s'il y a une activité principale et des petites choses
annexes -> tag principal et qlq tags=yes
ou s'il y a plusiers activités principales dans un même lieu ->
plusieurs objets
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Nommage/Numérotation hameaux (Était : Re: Joli noms de rues)

[marc marc]

> Le 18 déc. 2019 à 22:48, deuzeffe  a écrit :
> 
> je n'arrive pas à décider quelle est la moins mauvaise méthode.

Addr:place :-) remplace addr:street ou associatedStreet lorsque le nom ne vient 
pas d'une rue
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Idée folle : changer building=service en building=utility lorsqu'applicable

[marc marc]

Bonjour François,

Le 18.12.19 à 00:28, François Lacombe a écrit :
> Avec building=service, on se sais pas de quel service il peut s'agir.
> Un garagiste c'est aussi un service finalement (on me l'a déjà sorti
> plein de fois).

il y a une erreur de signification : building=service décrit l'apparence
"batiment dit de service", elle ne décrit pas qu'un service y a lieu,
d'autres tags décrivent si quelques choses y a lieu (power, amenity, ..)

> Il est réellement intéressant de pouvoir construire des chaînes comme ce
> que je montrais dans le mail du dessus.
> Si le consommateur est intéressé pour trouver tout le bâti impliqué dans
> les utilités, il ne connaît peut-etre pas les valeurs plus spécifiques
> comme power=substation et il peut en oublier.

c'est peut-être un vrai problème mais changer de valeur building=* est
une fausse solution

de la même manière qu'il est impossible de trouver tous les bâtiments
résidentiel avec la clef building=* (parce qu'il peux y avoir un
bâtiment ayant l'apparence d'une église (building=church) reconverti
en résidentiel (building:use=residentiel),
il est tout aussi impossible de trouver tous les bâtiments impliqué dans
les utilités avec la clef building=* et ceci indépendamment de la valeur
building=service <> building=utility
un poste de transformation peux très bien se trouver dans un bâtiment
dit de service, un bâtiment ayant l'apparence d'un garage, voir une
pièce dans un centre commercial, ou une partie d'une pièce multi-fonction)
chacun de ces cas aura un tag building/room différent.

si tu veux regrouper toute les utilités sous une même clef,
la clef utility=* convient bien, sans qu'il soie nécessaire d'ouvrir
la proposition quasi impossible à faire voter de changer
building=service pour chainer les clefs/valeurs.

si tu veux vraiement lier, building:use=utility et room=utility

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

Re: [OSM-talk-fr] SPAM, Re: SPAM, Re: SPAM, Re: Nommage des bâtiments scolaires / universitaires complexes

[marc marc]

Le 18.12.19 à 08:46, Vincent Bergeot a écrit :
>> Une école = une direction d'école = une entité = un amenity=school
> c'est la définition administrative, pas forcément celle que l'on peut
> voir sur le terrain. Que cela soit l'intention administrative, ok mais
> pour beaucoup de cas je pense qu'il y a encore écrit école maternelle
> (même si c'est une école primaire :) )

si on veux renseigné ce qui est écrit sur l'entrée , il y a
la clef inscription=*
https://wiki.openstreetmap.org/wiki/FR:Key:inscription

mais je partage l'avis initial qu'il ne faut pas créer 2 amenity=school
pour le groupe scolaire et un de ses membres.
soit on considère que le groupe scolaire est amenity=school, soit ses
membres, mais pas les 2 (pas de amenity=school dans amenity=school,
un objet ne peux pas être le tout et une partie)

> et peut-être que le problème est ailleurs alors car la requête sur
> amenity=school renvoie aussi les crêches, le conservatoire de musique,
> l'appase, l'école d'infirmiers, l'iut

le problème est ailleurs :)
celui qui tag un école d'infirmière post-bac en amenity=school
se trompe :)
idem pour les crèches (amenity=kindergarden)
et sans doute aussi pour les autres
voir à ce sujet la propal éducation 2.0 qui bient que rejettée
a des points interessant
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet Europeen de l'Eau/European Water Project - Introduction

[marc marc]

Le 18.12.19 à 13:38, Romain MEHUT a écrit :
> marc marc wrote
>> source : données livres, cartes libres, utilisateurs
>> c'est versé dans osm ou ils ont réinventé la roue ?
> 
> Voir cet échange via Twitter :
> https://twitter.com/Hoali_org/status/1164078027472613377

pour mémoire, il s'y dit :
Les données sont un mix de données ouvertes dont @openstreetmap, mais
aussi des bases de données de cyclistes et de livreurs à vélo et de la
contribution des usagers. Les données générée seront repartagés sur
@openstreetmap.

cquest a réclamé l'attribution manquante.
pas de trace de la base obdl sous odbl vu la fusion de bdd
pas souvenir d'avoir entendu parler d'un import de leur part
si quelqu'un a envie de les relancer sur Twitter :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet Europeen de l'Eau/European Water Project - Introduction

[marc marc]

Bonjour,

Le 18.12.19 à 09:20, Romain MEHUT a écrit :
> A toutes fins utiles, il existe déjà une initiative bretonne avec les mêmes
> objectifs mais limités à la France :
> https://www.ouest-france.fr/societe/hoali-l-appli-de-saint-brieuc-qui-vous-dit-ou-remplir-votre-gourde-6501876

source : données livres, cartes libres, utilisateurs
c'est versé dans osm ou ils ont réinventé la roue ?

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

[marc marc]

> ce serait vraiment bien si

Je redis parce que cela a visiblement été noyé dans la masse :
Il semblent n'yavoir aucun sysadmin osm.org
Donc leur parler ici revient à parler dans le vide (sauf à aider au diagnostic, 
qui lui nécessité le message de bounce).
Solution : soit aller voir les logs d'un serveur email perso soit signaler le 
soucis aux admin osm.org
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Nommage des bâtiments scolaires / universitaires complexes

[marc marc]

Un bâtiment -> 1 building=*
Des caractéristiques différentes -> building:part=*

> Le 15 déc. 2019 à 20:20, Cyrille37 OSM  a écrit :
> 
>> Le 15/12/2019 à 17:32, Arnaud Champollion a écrit :
>>> Le 15/12/2019 à 17:24, Brice a écrit :
>>> Si un des bâtiments l'a il me semble cohérent, oui, de le mettre sur tous 
>> 
>> OK, et du coup serait-il cohérent de fusionner les bâtiments dès lors ceux 
>> ceux-ci constituent le même corps architectural ?
> 
> Par forcément. Un même bâtiment peut être constitué de plusieurs "morceaux" 
> de hauteurs différentes, et/ou de toiture différentes, ...
> 
> 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] Remplacer ref:ERDF:gdo par ref:FR:Enedis / ref:FR:gdo

[marc marc]

Y a t il des objets ayant plus d'une ref ? Et si oui est-ce à ce point fréquent 
au point d'en faire la règle de base ?

Café l'autre sujet où je me pose la question de l'inutilité de l'utilisation de 
namespace pour ref quand cela ne fait que dupliquer le tag operator

Le 15 déc. 2019 à 20:13, François Lacombe 
mailto:fl.infosrese...@gmail.com>> a écrit :

Salut à tous,

Je retiens donc ref:FR:gdo pour la nouvelle clé.
Une notice du changement est disponible ici
https://wiki.openstreetmap.org/wiki/FR_talk:Key:ref:ERDF:gdo#Remplacement_par_ref:FR:gdo

Comme vous pouvez le voir, il y a pas mal de choses à vérifier. Ce sera fait 
d'un seul coup, grâce à JOSM qui permet d'explorer facilement les objets de 
chaque couche.

Il y a aussi une chapitre sur la reprise de la valeur de certains clés comme 
ref ou name
Ceci peut par contre être fait au fil de l'eau, à votre convenance ou affinité 
avec telle ou telle région.

Si il n'y a pas d'objections sur les opérations à réaliser, ceci sera fait 
d'ici fin décembre et ref:ERDF:gdo migrée sur le wiki vers une nouvelle page

Bonne fin de weekend

François

Le lun. 9 déc. 2019 à 09:32, Yves P. 
mailto:yves.prat...@gmail.com>> a écrit :
@François
> Ainsi ref:FR:gdo permettrait aussi de documenter les affleurant gaziers
Plutôt celui-ci car effectivement il est utilisé sur les coffrets de gaz qui 
alimentent un client…
Et comme ça, il n’y a plus de problème quand ERDF ou Enedis changeront encore 
de nom 

@Donat
> Une solution serait d'inventer une ref:operator:wikidata:Q=***
ref:Q c’est plus simple. Ou plutôt ref:Pxxx ou Pxxx
On va faire une PR pour qu’OSM affiche automatiquement le nom de la propriété 
dans la langue du contributeur, avec le lien automatique…

En gros, on transfère tous les objets OSM dans le wikidata (d’OSM)

—
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
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Nommage des bâtiments scolaires / universitaires complexes

[marc marc]

C'est une erreur.
Name décrit le nom et pas l'usage.
Le bâtiment ne s'appellent pas maternelle, il ne faut pas rager pour le rendu 
en renseignant un faux nom pour voir s'afficher l'usage

> Le 15 déc. 2019 à 10:33, Arnaud Champollion 
>  a écrit :
> 
> on détaille les différents bâtiments selon leur usage courant.
> 
> C'est ce que j'ai fait par exemple sur cette école :
> 
> https://www.openstreetmap.org/#map=19/44.08944/6.24771
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Nommage des bâtiments scolaires / universitaires complexes

[marc marc]

2 noeuds amenity pour chacune des entités 
1 bâtiment sans nom s'il n'a pas de nom
1 landuse si tu veux décrire l'ensemble de la surface utilisée (bâtiment + cour 
+ ...)

> Le 15 déc. 2019 à 10:33, Arnaud Champollion 
>  a écrit :
> 
> comment faire lorsque plusieurs entités partagent un même bâtiment ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Osmose : Erreur sur remplacement clés "ref" sur réseaux de transports en commun

[marc marc]

Bonjour,

Je me demande le sens de cet ultra spécialisation de la clef ref qu'on ne 
trouve pas dans d'autres clés.
Avoir une clef ref avec un namespace devrait être utile quand il y a plusieurs 
ref (arrêt multi opérateur) mais quand il y a qu'une, cette habitude est un non 
sens.
C'est un peu comme on remplaçait les name par name:FR:lacommune pour préciser 
que la commune à donné le name puis opening_hours:lecommerce pour dire que ce 
sont les heures selon le commerce et ainsi de suite.
Je pense qu'on a perdu de vue là non duplication des données au profit d'une 
utilisation fainéante des données.
PS je ne vise pas ce cas en particulier, je parle d'une manière générale de la 
sur utilisation parfois inutile des espaces de nom.

Cordialement,
Marc

Le 13 déc. 2019 à 11:00, Quentin Salles 
mailto:quentin.salle...@gmail.com>> a écrit :

Bonjour,

Je vous informe avoir modifié la page 
https://wiki.openstreetmap.org/wiki/Toulouse/Transports_en_commun
afin de prendre en compte le "ref:FR:Tisséo".

Cordialement

Quentin SALLES

Le mer. 11 déc. 2019 à 18:55, lenny.libre 
mailto:lenny.li...@orange.fr>> a écrit :

En ce qui concerne le réseau Arc-en-Ciel, quand nous avons choisi le nom de 
l'attribut je l'ai ajouté avec son explication dans le wiki, pour ma part, je 
n'ai rien fait d'autre ; quelqu'un a dû le lire pour mettre la règle dans 
osmose car je ne reçois pas le message que nous recevons pour Tisséo.

Je te conseille de le modifier et de le signaler quand la modif sera faite, en 
réponse à ton message

Leni

Le 10/12/2019 à 15:02, Quentin Salles a écrit :
Bonjour Frédéric,

Si dans le Wiki OSM de "Toulouse/Transports en commun", je mets à jour la 
règle, alors ce sera pris en charge par Osmose ?
Quelle est la procédure pour prendre en compte ce changement ?



Le mar. 10 déc. 2019 à 14:53, Frédéric Rodrigo 
mailto:fred.rodr...@gmail.com>> a écrit :
Le principe des règles, c'est de corrigé les données, pas les règles.
La règle est valide et basé sur le wiki OSM.



Le 10/12/2019 à 14:48, Quentin Salles a écrit :
> Bonjour,
>
> Après avoir demandé à la mail-list de Toulouse, j'ai récemment
> entrepris de mettre à jour et de remplacer la clé "ref" par
> "ref:FR:Tisséo" sur les arrêts de bus toulousains. Aujourd'hui, Osmose
> signale tous les arrêts de bus ayant un mauvais suffixe d'attribut sur
> la clé "ref:FR:Tisséo". Est-il possible de corriger cette règle dans
> le code d'Osmose ?
>
> Cordialement.
>
> Quentin SALLES
>
> ___
> 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] Appel à l'aide à propos d'une série de premières contributions assez catastrophiques

[marc marc]

> Le 12 déc. 2019 à 16:13, FR via Talk-fr  a écrit :
> 
> Est-ce qu’il est possible avec iD de remonter dans l’historique

Il y a un lien en bas à gauche vers osm.org pour afficher l'historique.
Mais iD comme Josm sans plugin reverter ne permet à ma connaissance pas 
d'annuler la supression.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[marc marc]

quelqu'un a un message d'erreur d'un de ces emails rejetté ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] SNT, éducation nationale / Nombre maximum d'appareils connectés à un compte

[marc marc]

Le 05.12.19 à 06:43, Vincent Bergeot a écrit :
> Le 04/12/2019 à 15:58, marc marc a écrit :
>>> Le 4 déc. 2019 à 13:57, Vincent Bergeot
>>> Savez vous si il y a un maximum d'appareils connectables à un compte
>>> unique OSM ?
>> Aucune limite connue mais en cas de vandalisme tu ne saurai jamais 
>> qui c'est.
>> Un compte ÉcoleAbcClasse1N1 a20 me semble bien préférable
> 
> ok pour la crainte du vandalisme, mais demander à créer 10 comptes par
> classe pour chaque classe de seconde de lycée cela me semble :
> 
> 1- difficile pour les profs (blabla+compte1@ac- ... et cela 10 fois cela
> va demander une formation à part entière avant même de commencer

je suis dépité (pour la génération en cours de formation) que l'usage
des emails en 2019 nécessiterait une formation à part entière pour le prof.
> Donc l'idée "défendue" et mise dans la lettre aux DANE (délégation
> académique aux numériques éducatifs de France) c'est d'avoir un compte
> classe pour le temps du cours, avec profil précisant #snt, le lycée, la
> classe éventuellement, avec changement de mot de passe à l'issue de la
> séance. Si il y a du vandalisme à ce moment là, ok mais cela fait
> néanmoins l'objet d'un changeset, c'est plus "facile" à détecter.

un login par classe voir par prof est un compromis acceptable si le prof
a bien conscience qu'il "perd" la possibilité de retrouver l'auteur à
posteriori.

pour ma part, le plus important, c'est que la contribution à osm
en classe ne soie pas une cour de récréation.
est-ce que le prof jette un oueil voir corrige l'exercice pratique ?
les 10aines de réaction que j'ai écrit sont quasi toute restées lettre
morte. certaines d'entre elle étaient pourtant due à des contributions
immédiatement détectable comme fantaisiste.
Aucune idée non plus si mes remarques sont remontées aux personnes
intéressées..
Mais si la communauté n'a pas moyen de savoir si elle est bénévole
forcée et ignorée pour l'éducation nationale, cela donne envie d'un
revert pur/simple sans explication détaillée.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr