Re: [OSM-talk-fr] Vérification des tags wikipedia et nettoyage ?

2019-11-27 Par sujet Topographe Fou 
Bonjour,

Tout à fait d'accord avec Yves : c'est même la raison d'être de wikidata, pas 
de remplacer wikipedia mais d'être une porte d'entrée vers les sites wikipedia, 
wikivoyages, wikinews... en plus d'être une base de données puissante, peu 
importe la langue et avec une promesse de maintenance réduite (tant qu'un 
Qx reste valide). De même que de pouvoir s'interfacer avec d'autres bdd qui 
utiliseraient cette clé publique comme osm. Ayant moi-même développé des 
moulinettes alliant wikipedia, wikidata et osm je vois bien la différence entre 
les deux clés. Et à ceux qui comme moi contribuent à Wikidata la mine 
d'information est énorme.

Donc je pense qu'il faut encourager l'usage de cette clé, de manière consciente 
(je saisie le Q) comme de manière sympathique (petit moteur de recherche 
wikidata à condition que ce soit simple de vérifier si un item correspond bien 
à ce que l'on veut, car il y a bcp d'homonymes).

Ceci étant dit il y a en effet fort à faire je pense niveau validation de tags 
wikipedia.

Et pourquoi pas lancer un maproulette pour les erreurs détectées ? D'expérience 
c'est plus lent mais permet de détecter et corriger d'autres erreurs sur le 
même objet / à proximité. Effet de bord tirant la qualité vers le haut.


LeTopographeFou


  Message original  


De: yves.prat...@gmail.com
Envoyé: 28 novembre 2019 12:29 AM
À: talk-fr@openstreetmap.org
Répondre à: talk-fr@openstreetmap.org
Objet: Re: [OSM-talk-fr] Vérification des tags wikipedia et nettoyage ?



>> Si car ça lie directement l’objet OSM aux propriétés wikidata
>
> ils sont déjà lié, ex le plugin josm wikidata propose d'ajouter le wikidata à 
> partir de l'url wikipedia
>
Je n’étais pas assez précis : on a toutes les infos en 1 clic avec wikidata. Et 
en 2 avec wikipedia
Je suis persuadé qu’à terme il n’y aura plus que le tag wikidata.

>> Quel est l’intérêt de consommer de l’énergie à stocker et à maintenir des 
>> données redondantes ?
>
> aucun, mais rien que toi et moi on n'est pas d'accord du quel des 2 
> supprimer. alors on peux philosopher, mais sans aboutir.
D’autres peuvent apporter leur point de vue. Et tout le monde évolue (pendant 
longtemps, je ne voyais pas l’intérêt de wikidata)

> La seule piste d'amélioration possible à court terme c'est de proposer aux 
> outils qui ne le font pas encore de gérer les 2 tags
> (= fonctionner de la même manière en présence de n'importe lequel des 2)
Ça me semble un bon compromis.

La carte des objets historiques fait ça en partie.
Elle utilise https://tools.wmflabs.org/hub pour obtenir des photos à partir de 
wikipedia ou wikidata et vice-versa.

> en passant quelqu'un avait proposé un script d'intégration
> osm-wikidata (par ex ajout de name:xx). a ma connaissance
> aucun rendu ne l'a mis en place (ce serrait pratique sur les
> rendus spécialisé sur une langue précise).
> yaka mais il manque de bras :)
Je verrais bien ça pour OpenStreetMap.org… pour afficher le nom de l’élément 
wikidata et la page wikipedia dans la langue préférée de l’utilisateur…
On pourra ainsi virer le tag wikipedia 

—
Yves




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

Re: [OSM-talk-fr] Un peu de BANO v2

2019-11-27 Par sujet Vincent de Château-Thierry 

Bonjour,

Le 27/11/2019 à 12:23, marc marc a écrit :


https://github.com/osm-fr/infrastructure/issues/133


@Rainer : Toreilles est de retour, le contenu a été corrigé par Jocelyn 
hier soir (merci à lui), j'ai pu ré-importer une base où le souci 
n'existe plus.


@Jocelyn : je te laisse commiter en lien avec le ticket ci-dessus et je 
fermerai les tickets BANO ensuite


merci
vincent

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

Re: [OSM-talk-fr] Vérification des tags wikipedia et nettoyage ?

2019-11-27 Par sujet Jérôme Amagat 
>
>
>- 2669  contenant des _ à la place
>des espaces
>
> le validateur de JOSM corrige cette erreur, les _ à la place d'espace.
L'erreur est indiqué par le validateur et "réparer" remplace les _ par des
espaces.

Moi aussi je me suis fais plusieurs fois taper sur les doigts parce que
j'envoyais des données sur plusieurs continent en même temps :) , ça plaît
pas à certains qui, avec je sais plus quel outils, suivent les changset sur
leur zones et donc un changset mondial, ça bip chez tout le monde :). Mais
je pense pas qu'il y ai besoin de couper par pays, par "région" qui peut
englober plusieurs pays ça suffit.
Dans JOSM, je sélectionne un grand rectangle :) ou mieux (comme ça, ça
sélectionne les relations) une recherche "(new or modified)  inview" en ce
plaçant correctement, ne pas oublier les ( ) la dernière fois que j'ai été
interpelé, je suis allé trop vite et les ai oublié donc dans la sélection
il y avait des élements dans le monde entier :(  et après fichier -> envoyé
la sélection.
Par contre, le gros problème c'est pour les éléments supprimés, il faut pas
en avoir sinon on se retrouve avec à la fin et pas moyen de les
sélectionner :(

Pour les expression régulière et leur stockage, il est possible de les
placer dans l'espèce de wikidata du wiki d'osm, les éléments OpenStreetMap
Wiki, avec la propriété "Expression régulière pour valider la valeur" P13 (
https://wiki.openstreetmap.org/wiki/Property:P13)
Je l'ai fais il y a quelque temps ici :
https://wiki.openstreetmap.org/wiki/Item:Q1273
pour wikidata , c'est ici : https://wiki.openstreetmap.org/wiki/Item:Q827
et wikipedia là : https://wiki.openstreetmap.org/wiki/Item:Q828

Par contre, 2 remarques, l'expression régulière doit être tel que il sera
ajouté "^(" avant et ")$" après, je comprends pas pourquoi cette
restriction. Et je sais pas comment on fait une recherche dans ce wikidata
OSM, le seul moyen d'y accéder c'est par les pages "normales" et sur la
colonne de gauche "élément OpenStreetMap Wiki"
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Vérification des tags wikipedia et nettoyage ?

2019-11-27 Par sujet Yves P. 

>> Si car ça lie directement l’objet OSM aux propriétés wikidata
> 
> ils sont déjà lié, ex le plugin josm wikidata propose d'ajouter le wikidata à 
> partir de l'url wikipedia
> 
Je n’étais pas assez précis : on a toutes les infos en 1 clic avec wikidata. Et 
en 2 avec wikipedia
Je suis persuadé qu’à terme il n’y aura plus que le tag wikidata.

>> Quel est l’intérêt de consommer de l’énergie à stocker et à maintenir des 
>> données redondantes ?
> 
> aucun, mais rien que toi et moi on n'est pas d'accord du quel des 2 
> supprimer. alors on peux philosopher, mais sans aboutir.
D’autres peuvent apporter leur point de vue. Et tout le monde évolue (pendant 
longtemps, je ne voyais pas l’intérêt de wikidata)

> La seule piste d'amélioration possible à court terme c'est de proposer aux 
> outils qui ne le font pas encore de gérer les 2 tags
> (= fonctionner de la même manière en présence de n'importe lequel des 2)
Ça me semble un bon compromis.

La carte des objets historiques fait ça en partie.
Elle utilise https://tools.wmflabs.org/hub pour obtenir des photos à partir de 
wikipedia ou wikidata et vice-versa.

> en passant quelqu'un avait proposé un script d'intégration
> osm-wikidata (par ex ajout de name:xx). a ma connaissance
> aucun rendu ne l'a mis en place (ce serrait pratique sur les
> rendus spécialisé sur une langue précise).
> yaka mais il manque de bras :)
Je verrais bien ça pour OpenStreetMap.org… pour afficher le nom de l’élément 
wikidata et la page wikipedia dans la langue préférée de l’utilisateur…
On pourra ainsi virer le tag wikipedia 

—
Yves




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

Re: [OSM-talk-fr] Vérification des tags wikipedia et nettoyage ?

2019-11-27 Par sujet marc marc 
Le 27.11.19 à 17:57, Yves P. a écrit :
>> mais rajouter un wikidata à qlq chose qui a un wikipedia, 
>> cela ne sert pas à grand chose.
> Si car ça lie directement l’objet OSM aux propriétés wikidata

ils sont déjà lié, ex le plugin josm wikidata propose
d'ajouter le wikidata à partir de l'url wikipedia

>>> ça fait beaucoup de données inutiles ?
>> tout a fait.
> Quel est l’intérêt de consommer de l’énergie à stocker et à maintenir des 
> données redondantes ?

aucun, mais rien que toi et moi on n'est pas d'accord du quel
des 2 supprimer. alors on peux philosopher, mais sans aboutir.
La seule piste d'amélioration possible à court terme c'est de proposer
aux outils qui ne le font pas encore de gérer les 2 tags (= fonctionner
de la même manière en présence de n'importe lequel des 2)

en passant quelqu'un avait proposé un script d'intégration
osm-wikidata (par ex ajout de name:xx). a ma connaissance
aucun rendu ne l'a mis en place (ce serrait pratique sur les
rendus spécialisé sur une langue précise).
yaka mais il manque de bras :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] absence de licence sur "adresse-francaise.com": copyvio? vie privée/CNIL?

2019-11-27 Par sujet marc marc 
Le 27.11.19 à 20:02, Yves P. a écrit :
> @Christian
>> Blacklister leur referer est la seule chose à faire.
> 
> Est-ce que ça veut dire que les serveurs OSM peuvent bloquer 
> la fourniture de tuiles pour ce site ?

techniquement oui n'importe quel serveur web peux filtrer le refere
(l'url du site qui inclu l'image)

pratiquement, discussion en cours, TomH n'est pas chaud,
principalement pour des questions de rôles (il estime que c'est
pas aux sysadmin de décider qui doit être bloqué...ca se tient...
ce point pourrait être résolu en soumettant l'idée/responsabilité
au LWG)
et des raisons de perf (qui serrait à évaluer si le LWG le décidait)

> Ou de le mettre dans une liste noire des navigateurs, des DNS ?

techniquement oui, en pratique c'est hautement improbable,
suffit de voir le cacophonie pour la lutte contre les botnets
actif dans des domaines + grave.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Restriction d'accès saisonnière pour les cyclistes sur des routes de montagne

2019-11-27 Par sujet marc marc 
Le 27.11.19 à 21:58, Jean-Christophe Becquet a écrit :
> Le 27/11/2019 17:41, Jean-Christophe Becquet a écrit :
> Le access:conditional=no @
> s'accompagne forcément d'un access=yes ?

la page wiki rappelle que c'est la valeur implicite
https://wiki.openstreetmap.org/wiki/Conditional_restrictions#Default_restrictions
donc pas obligatoire, même si ce ne serrait pas bien
grave de l'ajouter
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Restriction d'accès saisonnière pour les cyclistes sur des routes de montagne

2019-11-27 Par sujet osm . sanspourriel 
Oui car on peut imaginer d'autres valeurs telles que destination, customers...

Jean-Yvon


> Gesendet: Mittwoch, 27. November 2019 um 21:58 Uhr
> Von: "Jean-Christophe Becquet - j...@apitux.com" 
> 
> An: talk-fr@openstreetmap.org
> Betreff: Re: [OSM-talk-fr] Restriction d'accès saisonnière pour les cyclistes 
> sur des routes de montagne
>
> Le 27/11/2019 17:41, Jean-Christophe Becquet a écrit :
> > Sur les tronçons fermés l'hiver à tous les véhicules :
> > 
> > access=yes
> > access:conditional=no @ (Nov Fr[-1]-Apr Fr[-1])
> 
> J'aurais besoin d'une confirmation :
> 
> Le access:conditional=no @
> 
> s'accompagne forcément d'un access=yes ?
> 
> Merci
> 
> JC
> -- 
> Pourquoi le libre ne concerne pas que les informaticiens
> http://www.apitux.org/index.php?2006/07/09/97-pourquoi-le-libre-ne-concerne-pas-que-les-informaticiens
> 
> ==APITUX : le choix du logiciel libre==
> 
> APITUX - Jean-Christophe Becquet
> 2 chemin du Tivoli - 04000 Digne-les-Bains
> 06 25 86 07 92 - j...@apitux.com - http://www.apitux.com
> SIRET : 452 887 441 00031 - APE : 6202A
> 
> ===
> 
> ___
> 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] Vérification des tags wikipedia et nettoyage ?

2019-11-27 Par sujet Philippe Verdy 
Le mer. 27 nov. 2019 à 19:55, Yves P.  a écrit :

>
> En principe, je dis bien en principe, ces infos doivent permettre de
> contacter l'agence.
>
> Donc ici exit les contact:*
> 
>
> On va virer aussi les numéros de téléphone 
>
> *Valeur* *Quantité*
> +33 1 58 34 44 10 781
>
> Devinette : à qui appartient ce n° français ?
> Réponse (surligner) Autolib' (Paris)
>
Autolib/Vélib Métropole (Grand Paris)
https://autolibmetropole.fr/autolib-metropole/qui-sommes-nous/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Restriction d'accès saisonnière pour les cyclistes sur des routes de montagne

2019-11-27 Par sujet Jean-Christophe Becquet 
Le 27/11/2019 17:41, Jean-Christophe Becquet a écrit :
> Sur les tronçons fermés l'hiver à tous les véhicules :
> 
> access=yes
> access:conditional=no @ (Nov Fr[-1]-Apr Fr[-1])

J'aurais besoin d'une confirmation :

Le access:conditional=no @

s'accompagne forcément d'un access=yes ?

Merci

JC
-- 
Pourquoi le libre ne concerne pas que les informaticiens
http://www.apitux.org/index.php?2006/07/09/97-pourquoi-le-libre-ne-concerne-pas-que-les-informaticiens

==APITUX : le choix du logiciel libre==

APITUX - Jean-Christophe Becquet
2 chemin du Tivoli - 04000 Digne-les-Bains
06 25 86 07 92 - j...@apitux.com - http://www.apitux.com
SIRET : 452 887 441 00031 - APE : 6202A

===

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

Re: [OSM-talk-fr] Eglise désacralisée et cimetière

2019-11-27 Par sujet Rpnpif via Talk-fr 
Le 25 novembre 2019, Donat ROBAUX a écrit :

> Je suis également pour laisser les tag religion et denomination. Pq?
> Parce qu'un temple protestant et une église catholique n'ont pas la même
> architecture. Et même si on démonte les croix, il reste parfois des vitraux
> ou des sculptures.
> On peut également trouver des anciennes synagogues qui ne servent plus au
> culte. Donc laisser les tags me parait important pour "conserver"
> l'historique. De même que je passe le name en old_name.

Je ne trouve pas que ce soit pertinent car au fur et à mesure du
temps, ces objets parfois discrets disparaissent et on ne peut
distinguer la "denomination" catholique de l'orthodoxe ou autre, etc.
Il n'y a pas d'architecture nommée catholique ou même chrétienne.
Je connais d'anciennes églises qui sont transformées en magasin (de
vêtements par exemple). Pas un magasin catholique ! J'en connais même
une transformée en étable (la crèche ? :)) ).
Sinon si on suit le raisonnement de Donat, une croix présente dans une
maison d'habitation permettrait de marquer le bâtiment par religion=*,
ce qui serait abusif.

C'est la même chose pour les cimetières municipaux soit la
grande majorité des cimetières en France (hors Alsace ?). Ils sont
légalement laïques et pourtant on y trouve beaucoup de croix
chrétiennes. Mais aussi des tombes sans objets religieux et d'autres
avec le croissant musulman ou des signes juifs.
Et pourtant beaucoup de cimetières sont marqués de façon erronée
religion=christian. Il serait plus pertinent de marquer une simple
tombe avec une croix chrétienne par religion=christian. J'enlève
systématiquement cet attribut sur les cimetières (je les laisse sur les
tombes).
L'exception sont les cimetières assez rares de communautés religieuses
qui dérogent.

Cela n'empêche pas d'avoir parfois à l'intérieur des cimetières
municipaux des calvaires catholiques ou au moins chrétiens qui eux
peuvent être marqués place of worship et religion=* s'ils sont encore
utilisés pour le culte.

Et les anciennes écoles catholiques, va t-on taguer les bâtiments
religion=* ? non bien sûr. Et bien c'est le même raisonnement pour les
anciennes églises.

Par contre, d'accord avec les propositions avec une date de fin ou
disused:, etc.

En résumé, à mon avis, ne disséminons pas le tag religion=* à tout vent,
seulement à bon escient, sinon tout devient religieux à tort.

-- 
Alain Rpnpif

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

Re: [OSM-talk-fr] absence de licence sur "adresse-francaise.com": copyvio? vie privée/CNIL?

2019-11-27 Par sujet Yves P. 
@Christian
> Blacklister leur referer est la seule chose à faire.

Est-ce que ça veut dire que les serveurs OSM peuvent bloquer la fourniture de 
tuiles pour ce site ?
Ou de le mettre dans une liste noire des navigateurs, des DNS ?

—
Yves

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

Re: [OSM-talk-fr] Vérification des tags wikipedia et nettoyage ?

2019-11-27 Par sujet Yves P. 

> En principe, je dis bien en principe, ces infos doivent permettre de 
> contacter l'agence.
> Donc ici exit les contact:* 
> 
> 
On va virer aussi les numéros de téléphone 

Valeur  Quantité
+41 31 3213111  3152
+7 800 550  3078
+7 800 2009002  1581
+7 800 505  1578
+7 495 787;+7 800 3330303   1498
+7 495 539-54-541018
+7 800 3330201  985
+7 800 2005888  821
+33 1 58 34 44 10   781
+7 495 5005550  754
+375 44 780 723
+380 44 494 0101711

Devinette : à qui appartient ce n° français ?
Réponse (surligner) Autolib' (Paris)

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

Re: [OSM-talk-fr] absence de licence sur "adresse-francaise.com": copyvio? vie privée/CNIL?

2019-11-27 Par sujet Philippe Verdy 
La protection contre le transfert ici concerne juste le statut que tu
indiques.

Il y a d'autres statuts qui indiquent bien un problème reconnu par le
registrar (même si ce n'est pas encore remonté au registre primaire qui
sinon aurait mis un statut "server*" au lient de "client*").

Rien que le fait que le **renouvellement** soit interdit (par le registrar)
vient du registrar et non du client qui doit donc répondre aux demandes du
registrar et sinon ne pourra rien modifier (donc pas non plus transférer ou
modifier dans les données DNS). Sinon le client ne peut pas bloquer le
renouvellement lui-même... sauf s'il a initié un transfert (qui dont ne
pourrait pas être bloqué en même temps); ce blocage de renouvellement n'est
pas disponible dans l'interface du client, et la plupart des registrars
n'offrent aux client que le blocage contre les transferts (mais pas celui
des modifications puisque c'est une obligation permanente pour tout
titulaire de domaine .com, comme l'exige l'ICANN et comme les registrars
doivent en notifier ses clients pour qu'ils viennent corriger ou revalider
au moins une fois par an.)

Là le statut ne peut venir que justement du fait que le client ne s'est pas
acquitté de ses obligations (bref le domaine doit venir d'un prête-nom et a
disparu dans la nature pour justement ne plus répondre à une requête
légale; il est probable que le site a même été payé avec de l'argent
escroqué d'un tiers et que l'identité enregistrée de ce client était
usurpée).

Il y a encore une autre indication comme Registrant Organization: borislav
block" qui n'est pas une organisation mais plutôt un indicateur. Ce n'est
pas comme ça qu'apparaissent les noms de domaines dont les registrants sont
anonymisés avec un id unique (chez le registrar lui-même qui connait les
détails de son client mais le masque sans le WHOIS).

Chez Gandi par exemple l'anonymisation utilisait des id's uniques par
registrant ou par contact technique mais cela vient de changer avec un
identifiant anonyme par domaine pour éviter les rapprochements publics
entre registrants ayant des domaines multiples chez le même registrar;
cependant le registrar peut faire les rapprochements. Gandi n'autorise que
le changement du statut "clientTransfer" les autres statuts "client*" sont
uniquement controlés par le registrar, pas par le client final.

Chez Wild West Domains, en revanche, je ne pense pas que ce soit comme ça,
mais on peut noter que l'ID enregistré ne vient pas diurectement de chez
lui mais de Verisign: il est possible alors que ces autrers statuts
viennent de VeriSign (mais cela n'est toujours pas du client s'il est
encore chez VeriSign à qui il a ouvert un compte de délégation pour gérer
une série d'enregistrements de domaines chez divers registrars): Wild West
Domains ne fait pas confiance directement au client mais autorise la
délégation à VeriSign qui donc a été protégée à VeriSign qui est lui-même
registrar aussi et signataire des contrats ICANN. Là ça passe par les
règles régissant les relations entre registrars.

Ce type de configuration montre que le vrai détenteur possède de nombreux
autres domaines s'il fait appel à ce type de délégation par un autre tiers
pour gérer des enregistrements de domaines chez différents registrars (les
prix des registrars ne sont pas les même selon les racines utilisées, les
périodes promotionnelles de chacun d'eux et les dates anniversaires).

Ceci dit c'est plutôt bon signe car ce site abusif peut avoir un grand
nombre de sites liés entre eux en remontant chez VeriSign, qui pourrait
alors les bloquer/parquer tous en même temps chez tous les registrars de ce
client (qui cependant possède probablement déjà d'autres comptes de gestion
pour des domaines "en réserve" mais pas encore activés, ce que font tous
les escrocs du net, difficile à arrêter tant qu'on n'a pas réussi et
repérer d'où venant l'argent ou identifié les fichiers de cartes bancaires
détournés et repéré les transactions d'échange sur le "marché noir" du net
souvent en bitcoins mais parfois on peut pister le bitcoin au moment où il
se convertit en monnaie réelle sur un compte normal (souvent un vendeur
légal qui s'est fait payer en bitcoins, mais qui pourra collaborer pour
faire connaitre l'identité du dernier détenteur de bitcoin à qui a été
rendu le service ou la vente légale).

J'ai déjà vu sur mon compte une trace d'une recette de quelques fractions
de bitcoin, vite repéré et annulé automatiquement par ma banque masi il n'y
a eu aucun impact sur mon compte hormi deux écritures contre-balancées en
une seconde, ensuite invisibles dans le journal quelques jours après (je
n'ai rien eu à faire, la banque m'a contacté et proposé un changement de
numéro de compte, et il n'y a eu aucune transaction sur mes cartes
bancaires). Le fait est que pour payer les enregistrements de noms de
domaines, les escrocs tentent d'utiliser des prête-noms temporaires et
disparaissent aussitôt, ils conservent ces domaines cependant pour la durée
maximale prévue par

Re: [OSM-talk-fr] [SPAM] Re: absence de licence sur "adresse-francaise.com": copyvio? vie privée/CNIL?

2019-11-27 Par sujet Rpnpif via Talk-fr 
Le 27 novembre 2019, Philippe Verdy a écrit :

> En attendant on est toujours bombardé tous les jours de spammeurs et
> démarcheurs par courriel, téléphone fixe, mobile, maintenant aussi par
> courrier concernant les prétendues offres "d'isolation à 1 euro" pour tous
> (et ceci malgré la condamnation récente par la CNIL d'une de ces sociétés,
> cela continue, aujourd'hui par courier postal d'une "société" à
> Nogent-sur-Marne (avant à Melun), sous pli téléimprimé, et qui se dit
> "agence française de l'habitat" (autre nom à Neuilly-sur-Seine, mais qui
> déménage souvent, peut-être maintenant à Levallois, Gennevilliers,
> Courbevoie) avec de nouvelles variantes mineurs dans le nom ("officielle",
> "nationale", "pour l'amélioration de l'habitat", "institut", etc...)
> aujourd'hui cette société continue et utilise les mêmes données abusives.

+1 et ras-le-bol !

-- 
Alain Rpnpif

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

Re: [OSM-talk-fr] Vérification des tags wikipedia et nettoyage ?

2019-11-27 Par sujet Yves P. 
> Je ne veux rien imposer, je me demande de l’intérêt d’avoir des tags « 
> dupliqués », surtout en grande quantité (décroissance c’est un sujet pour 
> certains en ce moment ).
> Au passage c’est des  brand:* pour MacDo et compagnie. Un wikidata (cf. 
> discussion plus bas) pour afficher le bon wikipédia, le logo 
> internationalisé… c’est suffisant.
Un autre exemple : https://www.openstreetmap.org/node/6699737528

brand  
100%Banco
brand:wikidata 
  
Q517093 
brand:wikipedia 

es:Banco de Venezuela
contact:facebook 
  
https://es-la.facebook.com/100x100banco/ 

contact:instagram 

https://www.instagram.com/100x100banco/?hl=es-la 

contact:twitter 

https://twitter.com/100x100banco?lang=es 

Peut-on mettre les contacts une fois pour toutes dans wikidata ?

Si non, ne peut-on pas mettre uniquement les identifiants dans contacts:* plus 
qu’une longue URL ?
Note: c’est le cas pour twitter, instagram, pas facebook.

Mais en pratique, seuls les URL ont des liens dans OSM, Overpass… donc les 
contributeurs mettent des URL 拾

contact:facebook51 591
facebook18 085
website:facebook116

Voici uniquement la première page de taginfo :
contact:facebook

contact:instagram   
https://www.facebook.com/ruspost2784
https://instagram.com/sberbank  1135
https://www.facebook.com/pyaterochka1674
https://www.instagram.com/sberbank/ 742
https://www.facebook.com/sberbank   1657
https://www.instagram.com/mol.magyarorszag/ 444
https://www.facebook.com/vtbgroup   716 
https://www.instagram.com/ruspostofficial   440
https://www.facebook.com/krasnoe.beloe  566 
https://www.instagram.com/krasnoebeloe  342
https://www.facebook.com/mol.magyarorszag/  444 
http://instagram.com/perekrestok325
https://www.facebook.com/perekrestok426 
https://www.instagram.com/izbenka_vkusvill  240
https://www.facebook.com/bankdruzey 418 
https://www.instagram.com/mcdonalds_rus/229
https://www.facebook.com/mcdonaldsrussia300 
https://www.instagram.com/bankvtb   204
https://www.facebook.com/izbenka294 
https://www.instagram.com/sberbank  198
https://www.facebook.com/mts269 
https://www.instagram.com/orteka_rus/   197
https://www.facebook.com/orteka.rus 198 
https://instagram.com/krasnoebeloe  156

9746

4652
Il y a 31222 clé contact:facebook avec une URL et 15395 pour la clé facebook 拾

> Quel est l’intérêt de consommer de l’énergie à stocker et à maintenir des 
> données redondantes ?
J’ai oublié la bande passante pour télécharger ça 

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

Re: [OSM-talk-fr] Vérification des tags wikipedia et nettoyage ?

2019-11-27 Par sujet Yves P. 
> les CLEFS et les VALEURS sont 2 choses qu'il faut séparer :
> 
> corriger les VALEURS erronées : je suis 100% pour.
C’est l’objet de ces méls

> mais choisir quel CLEF le monde entier doit ou pas utiliser,
> ce n'est pas le bon endroit
Je ne veux rien imposer, je me demande de l’intérêt d’avoir des tags « 
dupliqués », surtout en grande quantité (décroissance c’est un sujet pour 
certains en ce moment ).
Au passage c’est des  brand:* pour MacDo et compagnie. Un wikidata (cf. 
discussion plus bas) pour afficher le bon wikipédia, le logo internationalisé… 
c’est suffisant.

> et je doute même que tu arrives
> à un accord unanime nécessaire aux éditions de masse
L’idée n’est pas forcément de faire une édition de masse, mais de réfléchir à 
nos pratiques, à l’intérêt final, au coût que ça à sur la maintenance…

> 2 exemples :
> 
> 1) les tags _1 _2 _3 : je suis totalement contre, c'est une décision
> controversée d'iD de créer un 2ieme tag avec _1 lors que l'utilisateur
> veux rajouter une 2ieme fois le même tag.
Zut, iD fait encore ça (je pensais que c’était une ancienne pratique)

> lors que les 2 tags ont la même info (comme l'exemple que tu as donné
> avec wikipedia=valeurnormale + wikipedia_1=url), c'est automatisable.
oui

> mais lorsque ce n'est pas le cas, c'est impossible d’automatiser.
Si c’est ce que font les règles dans JOSM : elles demandent à l’humain derrière 
le clavier de gérer 
Ou alors elles sont plus subtiles, ce que semble faire le greffon wikipedia de 
JOSM.
Du style, j’ai wikipedia:fr=* et pas de wikipedia=*, je change le tag en 
wikipedia=fr:*
J’ai wikipedia_1=fr:* wikipedia_2=de:* …, si je peux, je change les tags en 
wikipedia=fr:* wikipedia:de=* …
C’est ce que je fais manuellement. C’est l contributeur local qui décidera de 
ce qui est approprié.

> faire une édition de masse mondiale qui les vire va être à juste titre
> contestée s'il n'y a pas une discussion mondiale avant sur la ml talk.
Ok, quand on arrivera à un consensus francophone, je laisserai les spécialistes 
s’en occuper 
(Ou alors je prendrais le temps de suivre cette liste. La notre est déjà très 
énergivore )

> 2) wikidata <> wikipedia : la logique osm est d'avoir des tags lisible
> pour les humains, par conséquent s'il ne doit y en avoir qu'un, c'est
> wikipedia.
Pour le moment .

Sur le tableau que j’ai fait passé, on voit que iD et JOSM (avec le greffon 
wikipedia) affichent en clair et dans ta langue, le nom de l’élément wikidata.
iD permet même une saisie à la volée.

Il ne manque que l’affichage dans OSM et overpass… pour régler la question.
Je pense que c’est juste un bout de javascript à rajouter pour faire ça.

 (Note: Le tableau semble bloqué pour une question de taille)

> indpendament de cela, certains ont eu besoin d'un tag wikidata pour lier
> différente base de donnée entre elle au lieu d'innoncer osm avec plein
> de ref:a ref:b
Zut, c’est ce que je fais 
La question est subtile, on en avait déjà discuté dans le passé :
Avoir des identifiants dans OSM permet une certaine indépendance vis à vis de 
wikimedia, et des choses impossible à faire avec nos outils actuels.
Je cherche tous les phares avec un identifiant de la NGA n’est pas possible en 
l’état avec overpass.

> mais rajouter un wikidata à qlq chose qui a un wikipedia, cela ne sert
> pas à grand chose.
Si car ça lie directement l’objet OSM aux propriétés wikidata (les wikis, les 
propriétés non géographiques qui ne sont pas dans OSM…)
A terme, il n’y aura plus de wikipedia:*=*  (cf. supra)

> et supprimer le wikipedia à un élément qui a un
> wikidata, c'est illogique (il ne reste plus qu'un chiffre
> au lieu d'avoir un tag lisible pour les humains)
Idem.

> 
>> ça fait beaucoup de données inutiles ?
> 
> tout a fait.
Quel est l’intérêt de consommer de l’énergie à stocker et à maintenir des 
données redondantes ?
Je parle d’huile de coude (sujet à la tendinite en ce moment à force de cliquer 
), mais il est aussi possible de voir les centrales à charbon  et à uranium 
☢️ au bout de la fibre optique 

> Vespucci a par exemple décider de ne plus ajouter les
> wikidata venant du nsi, il ajoute uniquement les wikipedia
C’est une solution que peu choisir la(es) communauté(s), en tout cas ça me 
parait important d’y penser.

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

Re: [OSM-talk-fr] Restriction d'accès saisonnière pour les cyclistes sur des routes de montagne

2019-11-27 Par sujet Jean-Christophe Becquet 
Le 27/11/2019 13:31, marc marc a écrit :
> tu veux dire access=yes/no + access:conditional=yes/no @ (...) ? :)

Oui pardon, je me suis un peu emmêlé.

Sur les tronçons fermés l'hiver à tous les véhicules :

access=yes
access:conditional=no @ (Nov Fr[-1]-Apr Fr[-1])


Sur les relations des parcours jalonnés pour monter au col :

seasonal=yes


JC
-- 
HÉRuDi : l'Histoire Étonnante des Rues de Digne
Nouveau rendez-vous mardi 17 décembre
18h à la médiathèque François Mitterand
https://www.mediatheque-digne.fr/cms/articleview/id_profil/11/id/145

==APITUX : le choix du logiciel libre==

APITUX - Jean-Christophe Becquet
2 chemin du Tivoli - 04000 Digne-les-Bains
06 25 86 07 92 - j...@apitux.com - http://www.apitux.com
SIRET : 452 887 441 00031 - APE : 6202A

===

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

Re: [OSM-talk-fr] absence de licence sur "adresse-francaise.com": copyvio? vie privée/CNIL?

2019-11-27 Par sujet marc marc 
Le 27.11.19 à 16:06, Philippe Verdy a écrit :
> En attendant ce domaine est en litige ouvert à l'ICANN :
> *Domain Status: clientTransferProhibited

ce n'est pas la marque d'un litige, c'est l'info que le transfert
d'un domaine serra rejeté au lieu de provoquer une demande de clef.
j'ai cela sur tous mes domaines oü c'est possible (moins de spam et
tentative de hijack)
PS: l'explication est dispo en cliquant sur le lien.

personne d'entre nous n'est juriste bénévole ni admin osm.org,
donc redire qu'ils sont dans l'illégalité volotnaire n'aura
aucune conséquence.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Vérification des tags wikipedia et nettoyage ?

2019-11-27 Par sujet marc marc 
Le 27.11.19 à 15:16, Yves P. a écrit :
> Mais est-ce pertinent de saisir des brand:wikipedia alors que la
> combinaison brand=* et brand:wikidata=* est peut-être suffisante ?

les CLEFS et les VALEURS sont 2 choses qu'il faut séparer :

corriger les VALEURS erronées : je suis 100% pour.
mais choisir quel CLEF le monde entier doit ou pas utiliser,
ce n'est pas le bon endroit et je doute même que tu arrives
à un accord unanime nécessaire aux éditions de masse

2 exemples :

1) les tags _1 _2 _3 : je suis totalement contre, c'est une décision
controversée d'iD de créer un 2ieme tag avec _1 lors que l'utilisateur
veux rajouter une 2ieme fois le même tag.
lors que les 2 tags ont la même info (comme l'exemple que tu as donné
avec wikipedia=valeurnormale + wikipedia_1=url), c'est automatisable.
mais lorsque ce n'est pas le cas, c'est impossible d'automatiser.
faire une édition de masse mondiale qui les vire va être à juste titre
contestée s'il n'y a pas une discussion mondiale avant sur la ml talk.

2) wikidata <> wikipedia : la logique osm est d'avoir des tags lisible
pour les humains, par conséquent s'il ne doit y en avoir qu'un, c'est
wikipedia.
indpendament de cela, certains ont eu besoin d'un tag wikidata pour lier
différente base de donnée entre elle au lieu d'innoncer osm avec plein
de ref:a ref:b
mais rajouter un wikidata à qlq chose qui a un wikipedia, cela ne sert
pas à grand chose. et supprimer le wikipedia à un élément qui a un
wikidata, c'est illogique (il ne reste plus qu'un chiffre
au lieu d'avoir un tag lisible pour les humains)

> ça fait beaucoup de données inutiles ?

tout a fait. Vespucci a par exemple décider de ne plus ajouter les
wikidata venant du nsi, il ajoute uniquement les wikipedia
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] wikipedia=URL d'un autre wiki — Re: Vérification des tags wikipedia et nettoyage ?

2019-11-27 Par sujet Yves P. 
Bonjour,

> pour éviter l'indigestion, je pense que tu devrais cibler : un cas à la fois
wikipedia=ru:http://kraeved.vp43.ru/wiki/Поминальный крест охотников и рыболовов

C’est un site mediawiki certes, mais le tag wikipedia=ru:Поминальный крест 
охотников и рыболовов ne permettra pas de retrouver l’article.
Je remplace par url=http://kraeved.vp43.ru/wiki/Поминальный крест охотников и 
рыболовов (ce n’est pas le site web officiel)

—
Yves

112  avec regex « wiki » 

Valeurs extraites avec cat wikipedia.json | jq --raw-output 
'[.data[].value|match(".*[:./]wiki.*";"i").string]|unique|.[]' 
>wikipedia.wiki-value.txt

FR:Wikipedia.org/wiki/Passamaïnty
cs:Wikimedia Česká republika
de:Wikimedia Deutschland
de:Wikingborg, Haus Parchmann
de:Wikinger-Museum Haithabu
de:Wikingturm
de:Wikipedia:Kontor Hamburg
de:Wikipedia:Lokal K
de:Wikipedia:WikiMUC
de:http://wiki.openstreetmap.org/wiki/Bremen/Kulturdenkm%C3%A4ler
de:https://wuerzburgwiki.de/wiki/Schlossmühle_(Rimpar)
en:Wikimedia Foundation
en:Wikimedia UK
en:http://wikimapia.org/3196659/Greyfield-Inn
en:http://wikimapia.org/street/19091017/Awan-Street
en:http://wikimapia.org/street/436870/Lane-4
en:http://wikimapia.org/street/613731/N5-Peshawar-Road
en:http://wikimapia.org/street/656873/N5-The-Mall-Road
en:http://wikimapia.org/street/671645/N38-Kallar-Syedan-Road
en:https://wikivisually.com/wiki/Polonezk%C3%B6y
en:https://www.wikivillage.in/village/haryana/jind/safidon/singhana
en:https://www.wikiwand.com/en/Bishop%27s_Stortford_High_School
en:https://www.wikiwand.com/en/Rio_Tuba
es:http://wikimapia.org/4338407/es/La-Asegurada
fr:Wikimédia France
fr:Wikipedia.org/wiki/Dzaoudzi
fr:Wikipedia.org/wiki/Dzaoudzi#Labattoir
fr:Wikipedia.org/wiki/Mtsapéré
fr:Wikipermanence
fr:Wikipédia:WikiPermanence/Montpellier
https://commons.m.wikimedia.org/wiki/Special:MobileDiff/346336451
https://pl.m.wikipedpl:Parafia_św._Klemensa_w_Lgocie_Wielkiej
https://regiowiki.pnp.de/wiki/Abrahamhof (Neuburg)
https://wikimapia.org/27999399/Negeri-Lima-Uli-Nau-Hena-Helu
hu:Wikipédia:Wikimédia Magyarország
my:https://incubator.m.wikimedia.org/wiki/Wp/mnw/%E1%80%9E%E1%80%AC%E1%80%B6%E1%80%9C%E1%80%BE%E1%80%B1%E1%80%9D%E1%80%BA%E1%81%8A_%E1%80%80%E1%80%BD%E1%80%AC%E1%80%94%E1%80%BA
nl:https://www.wikiwand.com/nl/Donatuskerk_(Leermens)
nl:https://www.wikiwand.com/nl/Leermens
pl:Wikielec (powiat braniewski)
pl:Wikielec (powiat iławski)
pl:http://wikimapia.org/2030816/pl/%C5%9Awi%C4%99ta-G%C3%B3ra
ru:http://kraeved.vp43.ru/wiki/%D0%98%D1%81%D1%82%D0%BE%D1%87%D0%BD%D0%B8%D0%BA_%D0%91%D0%B8%D0%B7%D0%B5%D0%BA
ru:http://kraeved.vp43.ru/wiki/%D0%9F%D0%BE%D0%BC%D0%B8%D0%BD%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%B9_%D0%BA%D1%80%D0%B5%D1%81%D1%82_%D0%BE%D1%85%D0%BE%D1%82%D0%BD%D0%B8%D0%BA%D0%BE%D0%B2_%D0%B8_%D1%80%D1%8B%D0%B1%D0%BE%D0%BB%D0%BE%D0%B2%D0%BE%D0%B2
ru:http://wikimapia.org/#lang=ru=42.854874=41.812913=16=w=/39620049/ru/%D0%92%D0%BE%D0%B4%D0%BE%D0%BF%D0%B0%D0%B4-%D0%97%D0%BE%D0%BB%D0%BE%D1%82%D0%BE%D0%BD%D0%BE%D1%81%D0%B5%D1%86-=42.854742%2C%2041.805551
sv:Wikimedia Sverige
uk:wiki/Липняжка
uk:wiki/Федоро-Шулічине
vi:https://www.wikiwand.com/vi/Ch%E1%BB%A3_B%C3%A0_Chi%E1%BB%83u
vi:https://www.wikiwand.com/vi/Th%E1%BA%A3o_C%E1%BA%A7m_Vi%C3%AAn_S%C3%A0i_G%C3%B2n

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

Re: [OSM-talk-fr] absence de licence sur "adresse-francaise.com": copyvio? vie privée/CNIL?

2019-11-27 Par sujet Philippe Verdy 
En attendant ce domaine est en litige ouvert à l'ICANN :

Domain Name: adresse-francaise.com
Registry Domain ID: 1968123926_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.wildwestdomains.com
Registrar URL: http://www.wildwestdomains.com
Updated Date: 2019-10-07T13:37:09Z
Creation Date: 2015-10-13T00:22:12Z
Registrar Registration Expiration Date: 2021-10-13T00:22:12Z
Registrar: Wild West Domains, LLC
Registrar IANA ID: 440
Registrar Abuse Contact Email: ab...@wildwestdomains.com
Registrar Abuse Contact Phone: +1.4806242505
Reseller: Mad Dog Domains
*Domain Status: clientTransferProhibited
http://www.icann.org/epp#clientTransferProhibited
*



*Domain Status: clientUpdateProhibited
http://www.icann.org/epp#clientUpdateProhibited
Domain Status:
clientRenewProhibited http://www.icann.org/epp#clientRenewProhibited
Domain Status:
clientDeleteProhibited http://www.icann.org/epp#clientDeleteProhibited
*Registrant Organization:
borislav block
Registrant State/Province: moscow
Registrant Country: RU
Registrant Email: Select Contact Domain Holder link at
https://www.secureserver.net/whois?plid=1387=adresse-francaise.com
Admin Email: Select Contact Domain Holder link at
https://www.secureserver.net/whois?plid=1387=adresse-francaise.com
Tech Email: Select Contact Domain Holder link at
https://www.secureserver.net/whois?plid=1387=adresse-francaise.com
Name Server: NS25.DOMAINCONTROL.COM
Name Server: NS26.DOMAINCONTROL.COM
DNSSEC: unsigned
URL of the ICANN WHOIS Data Problem Reporting System:
http://wdprs.internic.net/
>>> Last update of WHOIS database: 2019-11-27T14:00:00Z <<<

Mais il fonctionne toujours malgré cela. Son propriétaire russe ("borislav
block", Moscou, RU, sans doute un pseudonyme ou un "alias" utilisé pour
repérer un groupe d'adresses abusives à bloquer ensemble et suivre
conjointement) a tenté de le remettre en vente sur "Mad Doc Domain" mais la
revente est interdite car le client ne peut ni modifier, ni modifier, ni
renouveler son inscription, ni le transférer à un nouveau "prête-nom".

Je ne comprend pas pourquoi le registrar américain WildWestdomains (qui
l'héberge maintenant après son acquisition initiale chez Verisign) ne met
pas ce domaine en parking pour désactiver complètement le site et
l'empêcher de fonctionner (au moins toutes les pages affichant les données
personnelles, obsolètes ou pas).

En attendant le registrant ne peut plus rien changer sur son domaine et ne
peut pas le renouveler sans avoir à contacter d'abord directement le
registrar et répondre aux questions et vérifications demandées. S'il ne le
fait pas, son domaine non renouvelé sera alors mis hors service puis libéré
au bout du "délai de grace" (où le renouvellement pourrait avoir lieu mais
en payant bien plus cher).

En attendant on est toujours bombardé tous les jours de spammeurs et
démarcheurs par courriel, téléphone fixe, mobile, maintenant aussi par
courrier concernant les prétendues offres "d'isolation à 1 euro" pour tous
(et ceci malgré la condamnation récente par la CNIL d'une de ces sociétés,
cela continue, aujourd'hui par courier postal d'une "société" à
Nogent-sur-Marne (avant à Melun), sous pli téléimprimé, et qui se dit
"agence française de l'habitat" (autre nom à Neuilly-sur-Seine, mais qui
déménage souvent, peut-être maintenant à Levallois, Gennevilliers,
Courbevoie) avec de nouvelles variantes mineurs dans le nom ("officielle",
"nationale", "pour l'amélioration de l'habitat", "institut", etc...)
aujourd'hui cette société continue et utilise les mêmes données abusives.

Et ses courriers demandent de les contacter à un numéro surtaxé très cher
(3 euros par minute l'appel plus 3 euros par minute): je crois bien que
tout ce qui est vendu c'est non pas l'isolation, mais les appels surtaxés
(et tant qu'à faire, ces surtaxes devraient être remboursées
automatiquement par les opérateurs s'il y a eu condamnation, à charge pour
les opérateurs alors de porter plainte et se porter partie civile, et
inscrire les titulaires abuseurs sur leurs listes noires à qui on ne doit
pas vendre le moindre service téléphonique tant qu'ils ne se seront pas
acquittés des sommes à rembourser aux opérateurs et les frais de poursuite
engagés par les opérateurs ou leurs assureurs).

Demander ça à chacune des nombreuses victimes de ces démarcheurs est
infaisable avec la lourdeur, la lenteur et les couts de la justice en
France, incapable de toute façon de répondre avant des mois. La loi devrait
favoriser la reprise de ces litiges de façon simplifiée par une obligation
donnée aux opérateurs de prendre ça en charge, de la même façon que la loi
oblige les banques à prendre en charge et rembourser ceux qui se sont fait
escroquer leurs comptes ou cartes bancaires mais ensuite la loi devrait
aussi les obliger ces banques alors à déposer plainte au lieu de

[OSM-talk-fr] Généralisation — Re: Vérification des tags wikipedia et nettoyage ?

2019-11-27 Par sujet Yves P. 
>> Tu veux généraliser, ce n'est pas une mauvaise idée, tu proposes une base 
>> réutilisable par les différents éditeurs ?
>> 
Centraliser des regex, des extraits de code… pour les développeurs éviterait de 
réinventer la roue, et d’améliorer globalement OSM.

Où mettre ces infos : dans le wiki, GitHub, un GitLab, Trac… ?

Il y a aussi Wikidata. Cf. méls précédents.

—
Yves

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

Re: [OSM-talk-fr] Vérification des tags wikipedia et nettoyage ?

2019-11-27 Par sujet Yves P. 
@Stéphane
> J'ai croisé des cas semblables récemment, avec des transformation d'un tag 
> brand:wikipedia=fr:Système U
> 
> Je ne suis pas certains que ça soit très pertinent comme modif.
> 
Il n’y en que 2  : 1 en Espagne, l’autre au 
Portugal.
La page web anglaise existe bien (pas les pages en espagnol et en portugais).

Mais est-ce pertinent de saisir des brand:wikipedia alors que la combinaison 
brand=* et brand:wikidata=* est peut-être suffisante ?
Pour le moment, OSM n’affiche pas le nom en clair pour les wikidata.
Il faut donc cliquer sur le lien pour en savoir plus. Mais est-ce vraiment un 
problème ?

—
Yves

PS: pour tous les brand=*, brand:wikidata=*, brand:wikipedia=*, 
brand:wikipedia:en=*… redondant, ça fait beaucoup de données inutiles ?
environ 756000 brand=*, 475000 brand:wikidata et brand:wikipedia (cf. 
https://taginfo.openstreetmap.org/search?q=brand)

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

Re: [OSM-talk-fr] absence de licence sur "adresse-francaise.com": copyvio? vie privée/CNIL?

2019-11-27 Par sujet Philippe Verdy 
En attendant, ils violent la vie privée et publient même en ligne des
extraits de données nominatives (pas forcément à jour, mais impossibles à
corriger donc là encore en infraction) : faites une recherche par
département>ville>rue et voyez ce qu'ils affichent (on n'a pas tout pour
faire une recherche immédiate, mais assez tout de même pour avoir accès à
des recherches localisées). Et ils revendent ces fichiers.

Reste donc à prévenir la CNIL et y déposer plainte si vous voyez vos noms
et numéros listés illégalement (on voit même en ligne les inscriptions en
liste noire et rouge!). En espérant ensuite que le nombre de plaintes les
concernant conduira à la fermeture de ce "service", et la saisie légale et
le parquage du nom de domaine après notification du registrar selon la
procédure de l'ICANN (comme cela se fait pour les sites d'escroqueries et
de groupes terroristes). Au passage, la saisine des registrars devraient
aussi les conduire à lister les divers noms de domaine qu'ils utilisent et
controlent, car il doit y en avoir d'autres sous diverses appellations dnas
diverses langues et d'autres même déjà réservés mais pas encore utilisés.
Et les registrars devraient avoir une liste de détenteurs à blacklister ou
surveiller précisément pour conrtoler l'usage qui est fait des noms de
domaine et notifier les divers services gérant et surveillant la sécurité
et le respect des droits. Et si un des sites est condamné, ils seront prêt
à révéler la source de facturation, les comptes bancaires et numéros de
cartes utilisés, les email utilisés pour suivre le renouvellement des
domaines et leur hébergement.

Ca les empêchera pas de réouvrir, mais ils devront chercher des noms de
domaine moins "vendeurs" que "adresses-francaises" et d'afficher des logos
officiels des sources qu'ils ne respectent pas.

En attendant leur nom générique crée la confusion, en prétendant avoir un
support officiel et des sources fiables (ce qui n'est pas du tout le cas).


Le mer. 27 nov. 2019 à 09:37, Christian Quest  a
écrit :

> Ne perdez pas votre temps avec adresses-francaises.com !
>
> C'est un site totalement hors des clous, signalé maintes fois à la CNIL,
> géré par des russes avec un pied au canada... bref, un truc insaisissable.
>
> Alors la licence d'OSM... croyez bien qu'ils s'en fichent !
> Blacklister leur referer est la seule chose à faire.
>
>
> Le mer. 27 nov. 2019 à 08:52, Topographe Fou 
> a écrit :
>
>> Bonjour Philippe,
>>
>> Pour license OSM : tu peux les contacter en utilisant par exemple la
>> procédure du wiki
>> https://wiki.openstreetmap.org/wiki/FR:Lacking_proper_attribution
>>
>> Pour la CNIL : n'hésite pas à leur faire un signalement sur leur site.
>>
>> Cordialement,
>>
>> LeTopographeFou
>> *De:* verd...@wanadoo.fr
>> *Envoyé:* 26 novembre 2019 11:31 PM
>> *À:* talk-fr@openstreetmap.org
>> *Répondre à:* verd...@wanadoo.fr; talk-fr@openstreetmap.org
>> *Objet:* [OSM-talk-fr] absence de licence sur "adresse-francaise.com":
>> copyvio? vie privée/CNIL?
>>
>> Cartes et données OSM sans licence sur "adresse-francaise.com"
>>
>> https://adresse-francaise.com/street.php?i=751015825
>>
>> (pas plus de mention des licences pour les données DGFiP, Cadastre, BAN,
>> La Poste, et Annuaire universel).
>>
>> C'est clairement du copyvio, mais il y a d'autres problèmes aussi
>> dangereux!
>>
>> Site utilisé pour la revente de fichiers nominatif de prospection
>> commerciale (fichiers en grande partie abusifs, ils indiquent l'oppoition à
>> la prospection commerciale, mais ces fichiers sont utilisés quand même et
>> sans engagement légal supplémentaire concernant les restrictions
>> d'utilisation et sans vérification des autorisations par la CNIL)
>>
>> 
>>
>> Note: la CNIL vient d'épingler une société de prospection (pour
>> "l'isolation à 1 euro", une grosse arnaque) à un demi-million d'euros
>> d'amende, mais cette société continue ses harcèlements téléphoniques via
>> une panoplie de centres d'appels tiers et "d'autoentrepreneurs", mais aussi
>> via des appels passant par des relais téléphoniques hors Union Européenne,
>> dont les appels entrant en France sont transmise tels quels, même avec un
>> numéro d'appelant falsifié/détourné, et non masqués car invérifiables quand
>> l'appel issu de France a transité par un relais hors UE, notamment en Inde,
>> au Pakistan, en Azerbaidjan ou en Russie, via des opérateurs et
>> fournisseurs légalement installés dans ces pays et qui authentifient les
>> appels partant de chez eux mais pas ceux venant d'autres pays; il faut
>> savoir que les numéros d'appelants même français sont facilement falsifiés,
>> tous les opérateurs ne le vérifiant pas, et notamment pas pour les
>> interconnexions internationales avec les opérateurs et réseaux hors UE).
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> --
> Christian Quest - OpenStreetMap France
>

Re: [OSM-talk-fr] Vérification des tags wikipedia et nettoyage ?

2019-11-27 Par sujet Yves P. 
@marc
>> Comment repérer les valeurs et/ou les clés erronées ?
> 
> cela dépend de ce que tu veux en faire.
> pour une édition de masse, le mieux est probablement de télécharger un
> extrait France, de filtrer pour ne garder que les objets avec une clef
> wikipedia et de tavailler dessus
Il n’y a pas forcément de grande quantité (quoi que avec toutes les sous clés)…
Mais un peu partout sur le globe… C’est très lourd à téléverser sur le serveur 
pays par pays.

Le plus simple serait d’avoir la bonne requête overpass et les corrections 
faites dans JOSM ou ses greffons.
Pour la requête, tout n’est pas faisable (cf. #146 
 faite il y a 5 ans déjà).
Pour rechercher les clés de la même façon avec taginfo, même problème (cf. #271 
)

> pour améliorer la qualité des futures données, il est utile de faire les 
> tickets/PR dans les éditeurs et osmose
Vous pouvez étayer les tickets existants 
Pour osmose, je sais qu’il fait des contrôle et des corrections. Pouvez-vous 
regarder de plus près ?

>> Faut-il les nettoyer ?
> 
> si cela te motive de proposer, n'hésites pas
Il y a des requêtes dans ma réponse à Jean-Yvon. L’intérêt de le faire à la 
main est de comprendre comment un contributeur arrive à faire ça.
Ça permettra de proposer des tickets et des correctifs plus adaptés et 
efficaces.

>> Si oui, comment ?
>>  * contrôles et corrections automatiques dans l’éditeur
> 
> à mon avis les 3
> - un contrôle à la source est toujours mieux que de corriger après.
Oui et comme le précise Jean-Yvon, ça évitera que ça se reproduise.

> pour éviter l'indigestion, je pense que tu devrais cibler
> un cas à la fois : par exemple les valeurs génériques
> ou les typo qu'il est possible parfois de corriger
> automatiquement à partir du wikidata
> ou n'importe quel autre cas qui te branche pour commencer :)
J’ai essayé de ne montrer que quelques exemples pour monter l’ampleur du bazar. 
Il y en a probablement pleins d’autres.
Je les ai mis en post-scriptum, j’aurais du rajouter un TL/DR 


J’ai aussi fait un tableau « synthétique » des contrôle des les éditeurs (mais 
le mél ne passe pas).

>> wikipedia=fr:Phare
> 
> introuvable même en utilisant overpass pour remonter au 1er janvier
> tu as un exemple ?
c’était un exemple avec un mot au pif.
ici, modification faite volontairement avec iD : 
https://www.openstreetmap.org/node/331257382/history

Il y en avait 260 le 15 novembre : https://overpass-turbo.eu/s/OvN

> a noter un cas fréquent en France : la mise du tag sur tous les rails d'une 
> relation train
> 
Je suis tombé sur celle-là : https://www.openstreetmap.org/relation/6051577
rien sur la relation, tout sur les chemins : donc à nettoyer

Mais ça ne se cantonne pas à la France : 
https://taginfo.openstreetmap.org/keys/wikipedia?filter=ways#values
Si tu regardes les valeurs qui ont 3 ou plus de chemins, ça fait 1 clés 
wikipedia !
La ligne Shinkansen Tōkaidō  
fait 514 km. Elle a 2239 membres sous OSM !!
Tous? les segments semblent avoir tous les tags dupliqués : 
https://www.openstreetmap.org/way/609446768

> heu... ben du coup on discute de quoi ?
De comment éviter que ça revienne.
Nettoyer c’est bien, mais le faire façon tonneau des Danaïdes 
, c’est un vrai châtiment. 

> je pensais que tu voulais discuter s'il fallait ou pas
> faire des opérations de masse
Aussi, car il y a tous? les pays, et tous les sous tags wikipedias 

>>  * subject:wikipedia:en
> 
> qu'est-ce qui n'est pas juste ?
C’est peut-être redondant avec subject:wikipedia=ru:*. subject:wikidata=Qxxx 
est peut-être largement suffisant et produit moins de maintenance.
Aucun des outils suivant n’affiche de lien (OpenStreetMap, overpass-turbo, iD, 
JOSM)
Quand a subject:wikidata, il ne manque que pour iD.

> 
>> Tags d'éléments « supprimés » Faut-il les supprimer ?
> cela n'a pas grand intérêt
De les garder, c’est bien ça ?

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

Re: [OSM-talk-fr] Attribution OSM sur https://www.windy.com/ (copyvio?)

2019-11-27 Par sujet Philippe Verdy 
Houlà ! Il faut vraiment avoir de bons yeux pour la voir tellement c'est
petit et si mal contrasté (quasiment illisible, on prend ça pour une des
textures remplissant les fonds et avc les animations on ne voit pas du
tout. Ce texte devrait être détouré/ombré pour assurer un contraste
minimum. Et les fonds de carte utilisés devraient être dans l'écran donnant
seulement les sources de données météo. L'écran de sélection des couches
(menu à droite) et l'écran "à propos" (menu à gauche) devraient lister les
sources et avoir une page concernant les attributions et mentions légales,
les infos de contact du site... Ce qui est d'autant plus nécessaire que
c'est un projet collaboratif faisant appel aux dons du public, et donc
devant être clair sur la destination des fonds
Pour moi c'est tellement peu clair (y compris sur l'usage des dons et la
coordination) que cela me pousse justement à ne PAS donner, ça n'inspire
pas confiance malgré les bonnes volontés affichées, le projet semble fait
un peu trop "à l'arrache" sans se préoccuper des questions de droit.
Maintenant avec les centaines de milliers d'euros collectés, ils ne sont
plus à l'abri de poursuites judiciaires pour aller prélever une bonne
partie de ces dons, et pousser ensuite ce site vers une voie commerciale.
LEs objectifs du site ne sont pas clairement affichés non plus (va-t-il
devenir un fournisseur commercial financé initialement par des dons).
Le minimum pour remercier les gens de leurs dons seraient justement de
mentionner et crédits corrects, et notamment ceux qui font le travail
d'alimentation des données, ou le calcul des modèles, créent les algos,
testent le fonctionnalités, signalent les anomalies, améliore les schémas
de données, les protocoles, les rendus, et tous les logiciels libres et
données libres que ce type de site doivent utiliser.

Le mer. 27 nov. 2019 à 11:07, Erwan Salomon  a écrit :

> salut,
>
> j’avoue j’avais jamais fait attention, pourtant je la reconnais et je
> l’utilise régulièrement
> mais …
>
> chez moi je vois bien l’attribution OSM : (c) OSM & contributors
> elle est clivable et même à la page :
> https://www.openstreetmap.org/copyright
> sous la légende de vitesse de vent, tout en bas à droite
> en blanc sur le fond de carte, pas le plus lisible, mais ça correspond au
> design générale des texte de leur carte
> pour les données météos, elle sont nommées (AROME, GFS …) mais sans lien
> vers leurs sources en effet
>
> glyo
>
> Le 26 nov. 2019 à 23:30, Philippe Verdy  a écrit :
>
> Très jolie carte, cependant aucune attribution visible des sources
> utilisés (aussi bien pour les données météo ou incendies, que pour les
> fonds de carte... OSM)
>
> ___
> 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] Attribution OSM sur https://www.windy.com/ (copyvio?)

2019-11-27 Par sujet Vincent Bergeot 

Le 27/11/2019 à 14:15, Philippe Verdy a écrit :

je cale complètement concernant OSM que je ne trouve toujours pas.


quasiment cachée, tout en bas à droite de l'écran, sous l'échelle des vents

à plus

--
Vincent Bergeot

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

Re: [OSM-talk-fr] Vérification des tags wikipedia et nettoyage ?

2019-11-27 Par sujet Stéphane Péneau 

Le 27/11/2019 à 13:53, Yves P. a écrit :


wikipedia=gl:https://upload.wikimedia.org/wikipedia/commons/6/6a/Plano_de_Moaña.png 
(*version 1* du noeud 6703264890 
)
Le préfixe GL (galégo) provient d’une contribution récente sous iD par 
un « débutant » (94 contributions depuis 1 an).
Sous iD, si on colle une URL dans le formulaire wikipedia, la langue 
est saisie par défaut (le contributeur parle le galicien).




J'ai croisé des cas semblables récemment, avec des transformation d'un tag

brand:wikipedia=fr:Système U

en

brand:wikipedia=en:Système U


Je ne suis pas certains que ça soit très pertinent comme modif.

Stf

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

Re: [OSM-talk-fr] Attribution OSM sur https://www.windy.com/ (copyvio?)

2019-11-27 Par sujet Philippe Verdy 
Franchement je cherche et j'ai du mal à les voir ces attributions, et je
cale complètement concernant OSM que je ne trouve toujours pas.
Même si c'est quelquepart, ce n'est pas normal qu'il faille chercher
autant: rien non plus dans le menu latéral et la page "à propos".
Il me semble que le minimum serait d'avoir une mention claire "attributions
et sources" cliquable ouvrant un panneau d'information avec le détail des
sources et licences (et pas seulement OSM).

Il y a bien une icone en forme de montre "A propos de ces données" mais le
panneau que ça ouvre décrit les sources de données météo, mais sans lien
pour la plupart, et rien concernant les fonds de carte. Et rien concernant
les droits et licences associées. Ces attributions ne sont conformes pour
aucune des sources, rien n'est clair.

Leur forum de support en ligne n'a rien répondu à ce sujet depuis des
semaines, ou il fait la sourde oreille.


Le mer. 27 nov. 2019 à 11:07, Erwan Salomon  a écrit :

> salut,
>
> j’avoue j’avais jamais fait attention, pourtant je la reconnais et je
> l’utilise régulièrement
> mais …
>
> chez moi je vois bien l’attribution OSM : (c) OSM & contributors
> elle est clivable et même à la page :
> https://www.openstreetmap.org/copyright
> sous la légende de vitesse de vent, tout en bas à droite
> en blanc sur le fond de carte, pas le plus lisible, mais ça correspond au
> design générale des texte de leur carte
> pour les données météos, elle sont nommées (AROME, GFS …) mais sans lien
> vers leurs sources en effet
>
> glyo
>
> Le 26 nov. 2019 à 23:30, Philippe Verdy  a écrit :
>
> Très jolie carte, cependant aucune attribution visible des sources
> utilisés (aussi bien pour les données météo ou incendies, que pour les
> fonds de carte... OSM)
>
> ___
> 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] Vérification des tags wikipedia et nettoyage ?

2019-11-27 Par sujet Yves P. 
@Jean-Yvon
> Philippe, la réponse d'Yves est bonne car il ne parlait "que" des tags 
> wikipedia.
> 
Je confirme. Le sujet est déjà assez vaste et chiant comme ça 
> Tu veux généraliser, ce n'est pas une mauvaise idée, tu proposes une base 
> réutilisable par les différents éditeurs ?
> 
J’ai fait un ticket (cf. infra) suggérant que le code du greffon wikipedia 
utilise déjà l’API wikimedia pour avoir une liste à jour.
Par défaut, le « contrôleur » (validator) de JOSM ne teste pas tout (en ne pas 
pas tout tester).
Le greffon wikipedia va plus loin, mais les 2 ne testent pas tous les cas, ils 
sont en partie redondant et parfois donnent des résultats différent.

Du coup, ça complique le travail de maintenance des données 

J’ai creusé un peu plus ce matin.

wikipedia=gl:https://upload.wikimedia.org/wikipedia/commons/6/6a/Plano_de_Moaña.png
 (version 1 du noeud 6703264890 
)
Le préfixe GL (galégo) provient d’une contribution récente sous iD par un « 
débutant » (94 contributions depuis 1 an).
Sous iD, si on colle une URL dans le formulaire wikipedia, la langue est saisie 
par défaut (le contributeur parle le galicien).

iD ne fait pas de contrôle sur le contenu du champ wikipedia… encore moins de 
transformation en File:Plano_de_Moaña.png

Le contrôleur par défaut de JOSM détecte un problème, mais ne le corrige pas. 
Le greffon ne voit rien.

> Le 26/11/2019 à 22:53, Yves P. - yves.prat...@gmail.com 
>  a écrit :
> 
>> Faut-il les nettoyer ?
>> gros travail…
>> la clé wikidata permet de gérer les libellés en plusieurs langues, les 
>> synonymes, les relations entre objets, les identifiants externes…
> Oui si possible
Pour la clé wikipedia, il ne reste «  que » :
61  URL
15  fichiers wikimedia commons
1  préfixe tronqué (e: au lieu de en:)
1  préfixe wiki:
1  préfixe language:
478  objets ans préfixe (au minimum)
78  encodées (contenant %XX)
2669  contenant des _ à la place des espaces
? combien avec des pages redirigées ou inexistantes ?

Et il y a toutes les autres sous clés wikipedia à vérifier 浪

>> Il y a en avait beaucoup, c’est presque tout nettoyé. Est-ce que ça 
>> reviendra avec l’arrivée de contributeurs débutants ?
> Oui
> 
Je pense aussi.
Nous devons donc analyser ces erreurs pour fait des contrôles plus adaptés dans 
iD, JOSM… (et ou corriger des bugs).

>> Tags d'éléments « supprimés »
>> Faut-il les supprimer ?
> Ça dépend des cas. Globalement ça ne mange pas de pain et si des gens ont 
> jugé utile de les ajouter.
> 
Il y a peut-être l’historique pour ça.
Mettre old_name et was:amernity=xxx et peut être suffisant ?

Je ne savais pas encore récemment, mais il est possible de faire des requêtes 
overpass dans le passé. 
> former_operator:wikipedia
> former:operator:wikipedia
> Je ne vois pas trop l'utilité et il faudrait a minima passer à un préfixe de 
> cycle de vie (was: ?)
> 
Pour moi, à virer comme plus haut.
L’idée de mettre ca-nexiste-plus:amenity=* est plutôt bonne (c’est une forme de 
cycle de vie), mais au final ça « pollue »  la base.
Autant le garder pour le nom et l’objet principal, autant le virer pour les 
tags *:wikipedia:*

> old_name:wikipedia
> old_wikipedia
> old_wikipedia:zh
> old:wikipedia
> J'ai du mal à comprendre. Si on a un ancien nom, dans l'article Wikipédia 
> actuel il y sera fait référence et la page Wikipédia correspondante sera 
> citée.
> 
Du coup, pas d’intérêt à garder ça ?
> not:brand:wikipedia
> 
> Ça c'est utile pour éviter que des cartographes en fauteuil ne disent que le 
> restaurant McDonald est une franchise McDonald alors qu'il a juste le malheur 
> de partager son nom.
> 
ok pour garder not:brand=*
voir not:band:wikidata=* (overpass et le site web d’osm affichent les liens)
ça ne fait que 5  cas
> Virer/corriger les valeurs incorrectes me semble plus utile. Par exemple en 
> transformant ta revue des manques de vérification en tickets JOSM/iD…
> 
2 ici pour JOSM : 
https://josm.openstreetmap.de/ticket/18360
https://josm.openstreetmap.de/ticket/18256#comment:8 (c’est pas l’objet 
principal du ticket)

En fait il y a une multitude de chose à faire, ou à revoir. Il faut peut-être 
prendre du recul sur la façon de saisir et/ou de contrôler les données ?
Les validateurs de JOSM sont très bruyants, avec parfois des messages « 
ésotériques ».
Ils ne proposent pas toujours de nettoyage automatique.

Par exemple, saisir une article wikipedia, un élément wikidata ou une photo 
wikimedia commons… est peut-être plus facile pour les contributeurs en faisant 
un simple copier/coller de l’URL.

Si c’est vraiment le cas, il faut nettoyer ça à la saisie, ou simplifier le 
processus

Re: [OSM-talk-fr] Restriction d'accès saisonnière pour les cyclistes sur des routes de montagne

2019-11-27 Par sujet marc marc 
Le 27.11.19 à 12:42, Jean-Christophe Becquet a écrit :
> access=no @ (Nov Fr[-1]-Apr Fr[-1])

tu veux dire access=yes/no + access:conditional=yes/no @ (...) ? :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Vérification des tags wikipedia et nettoyage ?

2019-11-27 Par sujet marc marc 
Bonjour,

Le 26.11.19 à 22:53, Yves P. a écrit :
> Comment repérer les valeurs et/ou les clés erronées ?

cela dépend de ce que tu veux en faire.
pour une édition de masse, le mieux est probablement de télécharger un
extrait France, de filtrer pour ne garder que les objets avec une clef
wikipedia et de tavailler dessus

pour améliorer la qualité des futures données, il est utile
de faire les tickets/PR dans les éditeurs et osmose

> Faut-il les nettoyer ?

si cela te motive de proposer, n'hésites pas

> Si oui, comment ?
>   * contrôles et corrections automatiques dans l’éditeur

à mon avis les 3
- un contrôle à la source est toujours mieux que de corriger après.
- vu l'ampleur que tu décris, une/des éditions en France
semble le plus approprié
- après, proposer le correctif mondial et/ou le correctif dans les éditeurs

> PS: Quelques exemples :

pour éviter l'indigestion, je pense que tu devrais cibler
un cas à la fois : par exemple les valeurs génériques
ou les typo qu'il est possible parfois de corriger
automatiquement à partir du wikidata
ou n'importe quel autre cas qui te branche pour commencer :)

> wikipedia=fr:Phare

introuvable même en utilisant overpass pour remonter au 1er janvier
tu as un exemple ?

a noter un cas fréquent en France : la mise du tag sur tous les rails
d'une relation train
https://taginfo.openstreetmap.fr/keys/wikipedia#values

> c’est presque tout nettoyé

heu... ben du coup on discute de quoi ?
je pensais que tu voulais discuter s'il fallait ou pas
faire des opérations de masse

> Suffixes de langue inappropriés :
>   * subject:wikipedia:en

qu'est-ce qui n'est pas juste ?

> Tags d'éléments « supprimés »
>   * abandoned:wikipedia
> Faut-il les supprimer ?

cela n'a pas grand intérêt

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

Re: [OSM-talk-fr] Restriction d'accès saisonnière pour les cyclistes sur des routes de montagne

2019-11-27 Par sujet Jean-Christophe Becquet 
Le 26/11/2019 11:59, Jean-Christophe Becquet a écrit :
> Je dois renseigner une restriction d'accès saisonnière pour les
> cyclistes sur des routes de montagne.
> 
> L'interdiction est formulée ainsi : du dernier vendredi de novembre au
> dernier vendredi d'avril.

Bonjour,

Après vérification des arrêtés du Conseil départemental, les
interdictions hivernales s'appliquent en fait à tous les véhicules et
pas seulement aux vélos.

Donc la bonne combinaison de tags pour ces tronçons serait plus simplement :

seasonal=yes
access=no @ (Nov Fr[-1]-Apr Fr[-1])

Et l'interdiction à tous les véhicules s'appliquera de fait pour les
vélos.


Pour les interdictions spécifiques aux vélos mais qui sont permanentes,
je mets juste :
bicycle=no


Bonne journée

JCB
-- 
Film : Internet ou la révolution du partage
samedi 30 novembre à Chorges
http://www.moisdudoc.com/spip.php?rubrique90=39

==APITUX : le choix du logiciel libre==

APITUX - Jean-Christophe Becquet
2 chemin du Tivoli - 04000 Digne-les-Bains
06 25 86 07 92 - j...@apitux.com - http://www.apitux.com
SIRET : 452 887 441 00031 - APE : 6202A

===

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

Re: [OSM-talk-fr] Un peu de BANO v2

2019-11-27 Par sujet marc marc 
Bonjour,

Le 27.11.19 à 09:23, Vincent de Château-Thierry a écrit :
> Le 27/11/2019 à 07:08, rainerU a écrit :
>>
>> Il s'agit de la commune de Torreilles, code INSEE 66212.
> 
> Le problème vient de l'absence du contour de commune (polygone
> admin_level=8) dans mon extrait de données OSM issu de
> http://download.openstreetmap.fr/extracts/merge/

dans ce cas, cela mérite un ticket infra :)
https://github.com/osm-fr/infrastructure/issues/133
on pourrait compter le nombre de relation ref:INSEE osm<>extrait
pour se faire une idée de l'ampleur du problème

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

Re: [OSM-talk-fr] Attribution OSM sur https://www.windy.com/ (copyvio?)

2019-11-27 Par sujet Erwan Salomon 
oups mal lu ton message Yves
en effet y’a la source des météos avec la montre
AROME c’est Météo France, d’où la source donnée MF : 
http://www.meteofrance.fr/prevoir-le-temps/la-prevision-du-temps/le-modele-a-maille-fine-arome
 


glyo 

> Le 27 nov. 2019 à 00:30, Yves P.  a écrit :
> 
>> Très jolie carte, 
> Elle est démente cette version. Il y a les prévisions météo… des webcam…
> 
>> cependant aucune attribution visible des sources utilisés (aussi bien pour 
>> les données météo ou incendies, que pour les fonds de carte... OSM)
> Les tuiles viennent de Mapy…
> Les données c’est bien OSM : je reconnais des sentiers de randonnées que j’ai 
> cartographiés
> 
> https://windytiles.mapy.cz/turist-en/12-2116-1438
> 
> Pour les sites de parapentes : paraglidingearth.com
> 
> Les webcams :https://fr.webcams.travel/api/
> 
> Pour les météos, il faut cliquer sur la montre en bas à droite :
> https://www.ecmwf.int
> https://www.dwd.de/DE/Home/home_node.html
> https://www.meteoblue.com
> AROME ?
> 
> Satellite: https://www.eumetsat.int/website/home/index.html
> Radar : http://www.meteofrance.com
> Feux : coppernicus
> Aéroports google et wikipedia ?, METAR, NOTAM ?
> 
> 
> —
> Yves
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] Attribution OSM sur https://www.windy.com/ (copyvio?)

2019-11-27 Par sujet Erwan Salomon 
salut,

j’avoue j’avais jamais fait attention, pourtant je la reconnais et je l’utilise 
régulièrement
mais …

chez moi je vois bien l’attribution OSM : (c) OSM & contributors
elle est clivable et même à la page : https://www.openstreetmap.org/copyright 

sous la légende de vitesse de vent, tout en bas à droite
en blanc sur le fond de carte, pas le plus lisible, mais ça correspond au 
design générale des texte de leur carte
pour les données météos, elle sont nommées (AROME, GFS …) mais sans lien vers 
leurs sources en effet

glyo

> Le 26 nov. 2019 à 23:30, Philippe Verdy  a écrit :
> 
> Très jolie carte, cependant aucune attribution visible des sources utilisés 
> (aussi bien pour les données météo ou incendies, que pour les fonds de 
> carte... OSM) 
>  
> ___
> 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] Vérification des tags wikipedia et nettoyage ?

2019-11-27 Par sujet osm . sanspourriel 

Philippe, la réponse d'Yves est bonne car il ne parlait "que" des tags
wikipedia.

Tu veux généraliser, ce n'est pas une mauvaise idée, tu proposes une
base réutilisable par les différents éditeurs ?


Le 26/11/2019 à 22:53, Yves P. - yves.prat...@gmail.com a écrit :

Faut-il les nettoyer ?

  * gros travail…
  * la clé wikidata permet de gérer les libellés en plusieurs langues,
les synonymes, les relations entre objets, les identifiants externes…


Oui si possible

Il y a en avait beaucoup, c’est presque tout nettoyé. Est-ce que ça
reviendra avec l’arrivée de contributeurs débutants ?


Oui


Tags d'éléments « supprimés »

  * abandoned:brand:wikipedia
  * abandoned:wikipedia
  * demolished:brand:wikipedia
  * demolished:wikipedia
  * former_operator:wikipedia
  * former:operator:wikipedia
  * not:brand:wikipedia
  * old_brand:wikipedia
  * old_name:wikipedia
  * old_wikipedia
  * old_wikipedia:zh
  * old:wikipedia
  * razed:wikipedia
  * was:brand:wikipedia
  * was:operator:wikipedia
  * was:wikipedia


Faut-il les supprimer ?


Ça dépend des cas. Globalement ça ne mange pas de pain et si des gens
ont jugé utile de les ajouter.

 * former_operator:wikipedia
 * former:operator:wikipedia

Je ne vois pas trop l'utilité et il faudrait a minima passer à un
préfixe de cycle de vie (was: ?)

 * old_name:wikipedia
 * old_wikipedia
 * old_wikipedia:zh
 * old:wikipedia

J'ai du mal à comprendre. Si on a un ancien nom, dans l'article
Wikipédia actuel il y sera fait référence et la page Wikipédia
correspondante sera citée.

not:brand:wikipedia

Ça c'est utile pour éviter que des cartographes en fauteuil ne disent
que le restaurant McDonald est une franchise McDonald alors qu'il a
juste le malheur de partager son nom.

Virer/corriger les valeurs incorrectes me semble plus utile. Par exemple
en transformant ta revue des manques de vérification en tickets JOSM/iD...

Jean-Yvon

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

Re: [OSM-talk-fr] absence de licence sur "adresse-francaise.com": copyvio? vie privée/CNIL?

2019-11-27 Par sujet Christian Quest 
Ne perdez pas votre temps avec adresses-francaises.com !

C'est un site totalement hors des clous, signalé maintes fois à la CNIL,
géré par des russes avec un pied au canada... bref, un truc insaisissable.

Alors la licence d'OSM... croyez bien qu'ils s'en fichent !
Blacklister leur referer est la seule chose à faire.


Le mer. 27 nov. 2019 à 08:52, Topographe Fou  a
écrit :

> Bonjour Philippe,
>
> Pour license OSM : tu peux les contacter en utilisant par exemple la
> procédure du wiki
> https://wiki.openstreetmap.org/wiki/FR:Lacking_proper_attribution
>
> Pour la CNIL : n'hésite pas à leur faire un signalement sur leur site.
>
> Cordialement,
>
> LeTopographeFou
> *De:* verd...@wanadoo.fr
> *Envoyé:* 26 novembre 2019 11:31 PM
> *À:* talk-fr@openstreetmap.org
> *Répondre à:* verd...@wanadoo.fr; talk-fr@openstreetmap.org
> *Objet:* [OSM-talk-fr] absence de licence sur "adresse-francaise.com":
> copyvio? vie privée/CNIL?
>
> Cartes et données OSM sans licence sur "adresse-francaise.com"
>
> https://adresse-francaise.com/street.php?i=751015825
>
> (pas plus de mention des licences pour les données DGFiP, Cadastre, BAN,
> La Poste, et Annuaire universel).
>
> C'est clairement du copyvio, mais il y a d'autres problèmes aussi
> dangereux!
>
> Site utilisé pour la revente de fichiers nominatif de prospection
> commerciale (fichiers en grande partie abusifs, ils indiquent l'oppoition à
> la prospection commerciale, mais ces fichiers sont utilisés quand même et
> sans engagement légal supplémentaire concernant les restrictions
> d'utilisation et sans vérification des autorisations par la CNIL)
>
> 
>
> Note: la CNIL vient d'épingler une société de prospection (pour
> "l'isolation à 1 euro", une grosse arnaque) à un demi-million d'euros
> d'amende, mais cette société continue ses harcèlements téléphoniques via
> une panoplie de centres d'appels tiers et "d'autoentrepreneurs", mais aussi
> via des appels passant par des relais téléphoniques hors Union Européenne,
> dont les appels entrant en France sont transmise tels quels, même avec un
> numéro d'appelant falsifié/détourné, et non masqués car invérifiables quand
> l'appel issu de France a transité par un relais hors UE, notamment en Inde,
> au Pakistan, en Azerbaidjan ou en Russie, via des opérateurs et
> fournisseurs légalement installés dans ces pays et qui authentifient les
> appels partant de chez eux mais pas ceux venant d'autres pays; il faut
> savoir que les numéros d'appelants même français sont facilement falsifiés,
> tous les opérateurs ne le vérifiant pas, et notamment pas pour les
> interconnexions internationales avec les opérateurs et réseaux hors UE).
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [OSM-talk-fr] Un peu de BANO v2

2019-11-27 Par sujet Vincent de Château-Thierry 

Bonjour,

Le 27/11/2019 à 07:08, rainerU a écrit :


Il s'agit de la commune de Torreilles, code INSEE 66212.

http://dev.cadastre.openstreetmap.fr/fantoir/index.html#insee=66212


En effet. Le problème vient de l'absence du contour de commune (polygone 
admin_level=8) dans mon extrait de données OSM issu de 
http://download.openstreetmap.fr/extracts/merge/
J'ai le même problème avec les communes voisines de Claira et 
Villelongue et avec quelques autres communes en France.
On a avec Jocelyn échangé sur le souci dans la source pbf, mais sans 
tordre le cou au problème jusque là. Je réfléchis à un patch par ailleurs.

J'ai ouvert 2 tickets suite à ta remontée :
https://github.com/osm-fr/osm-vs-fantoir/issues/65
et plus généralement pour compiler les cas :
https://github.com/osm-fr/bano/issues/159

à suivre,
vincent

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