Re: [OSM-talk-fr] vérification utilisationRPG et OCS_GE

[osm . sanspourriel]

L'URL d'accès des données est claire et en navigant naturellement on
passe bien par un bandeau "Licence Ouverte".

https://geoservices.ign.fr/documentation/diffusion/telechargement-donnees-*libres*.html#ocs-ge

Jean-Yvon

Le 25/06/2020 à 13:21, ades - ades.s...@orange.fr a écrit :

lire "sous licence,  Ouverte/Open License Version 2.0" et pas
« licence ocs etc."



Le 25 juin 2020 à 12:26, ades mailto:ades.s...@orange.fr>> a écrit :


bonjour,
le RPG et l’OCS_GE sont disponibles (pas pour tous les dpt) sous
licence OCS_GE
(https://geoservices.ign.fr/documentation/diffusion/index.html)
J’en déduis, peut-être à tort ?, que l’on peut utiliser les .shp
dispos pour contribuer.
A mon sens le RPG est trop précis et a des lacunes (parcelles non
renseignées), alors que OCS_GE, plus « général » semble mieux
convenir pour OSM.
Possible ou pas, à une échelle communale je compte vérifier sur le
terrain…
___
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] vérification utilisationRPG et OCS_GE

[ades]

lire "sous licence,  Ouverte/Open License Version 2.0" et pas « licence ocs 
etc."


> Le 25 juin 2020 à 12:26, ades  a écrit :
> 
> 
> bonjour,
> le RPG et l’OCS_GE sont disponibles (pas pour tous les dpt) sous licence 
> OCS_GE (https://geoservices.ign.fr/documentation/diffusion/index.html 
> )
> J’en déduis, peut-être à tort ?, que l’on peut utiliser les .shp dispos pour 
> contribuer.
> A mon sens le RPG est trop précis et a des lacunes (parcelles non 
> renseignées), alors que OCS_GE, plus « général » semble mieux convenir pour 
> OSM.
> Possible ou pas, à une échelle communale je compte vérifier sur le terrain…
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

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

[OSM-talk-fr] vérification utilisationRPG et OCS_GE

[ades]

bonjour,
le RPG et l’OCS_GE sont disponibles (pas pour tous les dpt) sous licence OCS_GE 
(https://geoservices.ign.fr/documentation/diffusion/index.html 
)
J’en déduis, peut-être à tort ?, que l’on peut utiliser les .shp dispos pour 
contribuer.
A mon sens le RPG est trop précis et a des lacunes (parcelles non renseignées), 
alors que OCS_GE, plus « général » semble mieux convenir pour OSM.
Possible ou pas, à une échelle communale je compte vérifier sur le terrain…___
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 ?

[Topographe Fou]

Je parlais de Maproulette pour corriger les tags wikipedia incohérents (tels 
que ceux signalés en début de fil) si il y en a "trop". Si il y en a "peu", 
cela peut être fait sans passer par ce service par un contributeur motivé.


LeTopographeFou


  Message original  


De: yves.prat...@gmail.com
Envoyé: 1 décembre 2019 9:20 PM
À: talk-fr@openstreetmap.org
Répondre à: talk-fr@openstreetmap.org
Objet: Re: [OSM-talk-fr] Vérification des tags wikipedia et nettoyage ?


@Topographe Fou
> De même que de pouvoir s'interfacer avec d'autres bdd qui utiliseraient cette 
> clé publique comme osm.

J’ai réussi à faire des requête SPARQL entre wikidata et OSM. En fait on peut 
faire des requête entre pleins de bases de connaissances :
Par exemple, les catalogues de grandes bibliothèques pour trouver des photos, 
vérifier des noms, trouver des articles…

> Et pourquoi pas lancer un maproulette pour les erreurs détectées ?

Avec des requêtes SPARQL, on peut non seulement vérifier que la valeur des tags 
wikidata ou wikipedia est correcte avec une expression régulière,
mais carrément, on peut vérifier que l’élément ou l’article existe bien,
que la page ne soit pas une page de redirection,
que l’élément wikidata corresponde bien à l’objet OSM (j’ai des tags 
man_made=lighthouse, la nature de l’élément wikidata doit être « phare »),
trouver la population d’une ville,
…

—
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] Vérification des tags wikipedia et nettoyage ?

[Yves P.]

@Jérôme

> L’intérêt de le mettre sur wikidata, c’est que ce dernier est plus général; 
> les expressions régulières souvent  existent déjà… Pourquoi réinventer la 
> roue ?
> 
> Il n'y a pas les expressions régulières pour les tag OSM, si?
Si. La valeur étant la même, tu peut appliquer l’expression rationnelle aussi 
au tag OSM.
On peut aussi trouver l’URL pour générer des liens à partir d’un identifiant

J’avais fait une requête SPARQL qui listait ça : https://w.wiki/D5z

> 
> Il y a un serveur SPARQL pour OSM : il permet d’interroger les données OSM 
> (et des bases de connaissances externes comme wikidata).
> Il s’appel Sophox  ?
> 
> J'ai vu ça mais j'ai jamais testé... et je comprend pas trop ce que ça 
> apporte par rapport à overpass.
J’ai donné des exemples dans ma réponse au Topographe fou.

Voici une requête SPARQL dans wikidata qui affiche sur une carte les phares qui 
sont dans OSM : https://w.wiki/D5g


Bonne soirée,

—
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 ?

[Yves P.]

@Topographe Fou
> De même que de pouvoir s'interfacer avec d'autres bdd qui utiliseraient cette 
> clé publique comme osm.

J’ai réussi à faire des requête SPARQL entre wikidata et OSM. En fait on peut 
faire des requête entre pleins de bases de connaissances :
Par exemple, les catalogues de grandes bibliothèques pour trouver des photos, 
vérifier des noms, trouver des articles…

> Et pourquoi pas lancer un maproulette pour les erreurs détectées ?

Avec des requêtes SPARQL, on peut non seulement vérifier que la valeur des tags 
wikidata ou wikipedia est correcte avec une expression régulière,
mais carrément, on peut vérifier que l’élément ou l’article existe bien,
que la page ne soit pas une page de redirection,
que l’élément wikidata corresponde bien à l’objet OSM (j’ai des tags 
man_made=lighthouse, la nature de l’élément wikidata doit être « phare »),
trouver la population d’une ville,
…

—
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 ?

[Yves P.]

Bonsoir,


@Philippe
> Je ne vois que des avantages à Wikidata... sauf […qu’il] faut aussi 
> contribuer à Wikimedia

> ensuite il faut aussi se former aux outils Wikimedia et apprendre à utiliser 
> Wikidata (ce qui est beaucoup moins simple que pour Wikipédia).
J’ai bien galèré avec la syntaxe wiki 
Pour wikidata, la saisie est « visuelle » et on s’y fait vite.

Ce qui est « compliqué », c’est de savoir comment sont organisés les éléments, 
connaitre leur propriétés…
C’est relativement facile avec les contraintes qui indiquent tout de suite 
qu’il y a un problème.

Et il « suffit » d’observer un élément connu pour savoir comment s’y prendre.

—
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 ?

[Jérôme Amagat]

Le sam. 30 nov. 2019 à 10:37, Yves P.  a écrit :

> 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.
>
> Oui, le problème comme tu l’indiques plus bas et de faire les corrections
> sans s’attirer les foudres des communautés OSM
>
> 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.
>
> Pas toujours 
> Je connais un contributeur qui utilise OSMcha  pour
> « surveiller » un territoire de métropole, et un changeset qui couvre toute
> la France va être détecté, même si il n’y a aucune modifications dans son
> territoire.
>

Oui c'est pour ça que je pense que la découpe par pays ce n'est pas le plus
intéressant, il faut découper l'envoi pour avoir une "surface" de changeset
la plus petite possible. En envoyant plusieurs changesets, si leur ensemble
recouvre une surface presque équivalente au monde entier, tout le monde
aura, avec OSMcha, un changeset pour son "territoire" donc pareil qu'avec
un changeset mondial :)

>
> 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.
>
> Je fais ça aussi. Parfois avant de faire envoyer la sélection
> CMD+ALT+MAJ+U, je dois faire machinalement un CTRL+A et j’envoi un gros
> bazar !
>
> 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 :(
>
> En fait il faut réussir à cibler ses modifications
>
> 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
>
> Je ne connaissais pas, mais j’ai peur de ne pas être le seul. 類
>
> L’intérêt de le mettre ici, c’est que ça reste sur les serveurs OSM.
>

Oui, exactement, comme ça l'info est stocké quelque part.


> Encore faut-il que les développeurs le connaissent ?
>

S'il n'y a rien sur ces éléments OSM wiki, les développeurs ne
l'utiliseront pas et ... inversement. Il faut bien commencer quelque part.


> Tient, on pourra à terme virer toute une partie du wiki 
> (comme pour les boites dans wikipedia qui sont remplies automatiquement
> par des données wikidata).
>
> L’intérêt de le mettre sur wikidata, c’est que ce dernier est plus
> général; les expressions régulières souvent  existent déjà… Pourquoi
> réinventer la roue ?
>

Il n'y a pas les expressions régulières pour les tag OSM, si?
Comme wikidata, ça permet d'avoir des infos faciles à utiliser par un
robot, facile de créé une page dans une autre langue vu que la bande de
droite se remplit toute seul, permet de lier les pages des différentes
langues.

>
>
> 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.
>
> Peux-tu donner des exemples ?
>

On peut toujours s'arranger avec ça mais pour moi le "^" et le "$" font
partie de l'expression régulière et il y a un soucis sur la page, on dit
qu'il sera ajouté "^(" avant et ")$" après, mais dans "format de l'url" il
n'y a pas les parenthèses.

>
> 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 »
>
> ça correspond dans wikipedia à Élément Wikidata.
>
> J’ai peut-être trouvé une piste 
> Il y a un serveur SPARQL pour OSM : il permet d’interroger les données OSM
> (et des bases de connaissances externes comme wikidata).
> Il s’appel Sophox  ?
>

J'ai vu ça mais j'ai jamais testé... et je comprend pas trop ce que ça
apporte par rapport à overpass.


> Je ne sais pas encore comment interroger le wikidata d’OSM que tu décris
> plus haut, par contre j’arrive bien à interroger les données OSM :
>
> Requête SPARQL des objets ayant un identifiant NGA (les feux, phares,
> bouées et 

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

[Yves P.]

> 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.
Oui, le problème comme tu l’indiques plus bas et de faire les corrections sans 
s’attirer les foudres des communautés OSM

> 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.
Pas toujours 
Je connais un contributeur qui utilise OSMcha  pour 
« surveiller » un territoire de métropole, et un changeset qui couvre toute la 
France va être détecté, même si il n’y a aucune modifications dans son 
territoire.

> 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.
Je fais ça aussi. Parfois avant de faire envoyer la sélection CMD+ALT+MAJ+U, je 
dois faire machinalement un CTRL+A et j’envoi un gros bazar !

> 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 
> :(
En fait il faut réussir à cibler ses modifications

> 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 
> Je ne connaissais pas, mais 
> j’ai peur de ne pas être le seul. 類

L’intérêt de le mettre ici, c’est que ça reste sur les serveurs OSM.
Encore faut-il que les développeurs le connaissent ?
Tient, on pourra à terme virer toute une partie du wiki 
(comme pour les boites dans wikipedia qui sont remplies automatiquement par des 
données wikidata).

L’intérêt de le mettre sur wikidata, c’est que ce dernier est plus général; les 
expressions régulières souvent  existent déjà… Pourquoi réinventer la roue ?

> 
> 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.
Peux-tu donner des exemples ?

> 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 »
ça correspond dans wikipedia à Élément Wikidata.

J’ai peut-être trouvé une piste 
Il y a un serveur SPARQL pour OSM : il permet d’interroger les données OSM (et 
des bases de connaissances externes comme wikidata).
Il s’appel Sophox  ?

Je ne sais pas encore comment interroger le wikidata d’OSM que tu décris plus 
haut, par contre j’arrive bien à interroger les données OSM :

Requête SPARQL des objets ayant un identifiant NGA (les feux, phares, bouées et 
balises maritimes) : https://tinyurl.com/susuzyf
Ici par vraiment d’intérêt par rapport à Overpass-Turbo (hormis que c’est comme 
sous wikidata, on peut présenter les « connaissances » sous pleins de formes 
tableaux, cartes,…)

L'un des intérêts est de pouvoir « croiser » ces données avec wikidata ou une 
autre base de connaissance (ontologie).
(Je n’est pas encore testé).

J’ai découvert Navigae qui permet de consulter des données issues de travaux en 
géographie. Une requête sur « Phare » renvoie des cartes et photos anciennes :
https://www.navigae.fr/map?textSearch=phare=fr 


Une autre est de pouvoir utiliser l’outil OpenRefine 
 et un service de reconciliation 
capable d’interroger n’importe quel point d’entrée SPARQL.
Je l’ai testé pour retrouvé des objets OSM à partir de données au format CSV. 
Je faisais une requête overpass pour chaque objet, mais sans pouvoir utiliser 
la réconciliation, ou du moins que sur le nom et pas sur la géométrie.

—
Yves


___
Talk-fr mailing list

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

[Philippe Verdy]

Je ne vois que des avantages à Wikidata... sauf que pour contribuer à OSM
alors les conditions d'utilisation OSM ne sont plus suffisantes, il faut
aussi contribuer à Wikimedia et accepter aussi les termes Wikimedia et y
disposer d'un autre compte. ensuite il faut aussi se former aux outils
Wikimedia et apprendre à utiliser Wikidata (ce qui est beaucoup moins
simple que pour Wikipédia).
Il faudrait que les outils OSM fassent comme Wikipédia: inclure les
"moulinettes" qui permettent de contribuer indirectement à Wikidata de
façon plus simple que par l'interface Wikidata par défaut. Il faudrait
aussi que les éditeurs OSM incluent la création ou la connexion à un compte
Wikimedia et l'acceptation de ses propres conditions d'utilisation. Ensuite
ces outils OSM n'ont pas besoin de générer toutes les données Wikidata,
juste celles qu'OSM va utiliser: il semble suffisant que cet éditeur puisse
trouver les articles Wikipédia (dans n'importe quelle langue) puis leur Id
Q Wikidata et aussitôt alors proposer de mettre ce Wikidata et se
passer de Wikipédia dan les données OSM.

Les noms par défaut et traductions peuvent être trouvées aussi dans
Wikidata et on doit pouvoir y contribuer directement avec son compte
Wikimedia (de préférence un compte SUL, mais attention car certains comptes
Wikimedia n'on pas pu être unifiés et les noms d'utilisateurs peuvent être
différents selon les wikis : l'utilisateur Wikipédia et l'utilisateur
Wikidata n'est pas toujours le même, surtou si ce sont des comptes anciens
mais toujours actifs, datant d'avant les logins unifiés, et la fusion n'a
pas toujours été possible si les comptes en conflits étaient actifs tous
les deux et aucun n'a accepté de changer son nom d'utilisateur local car
Wikimédia n'a pas voulu ni obligé personne à abandonner son nom
d'utilisateur actif au profit d'un autre, sachant que le renommage de
comptes pose des tas de difficultés, demande des ressorues importantes sur
les serveurs pour modifier des tas de pages, et que tout n'est pas toujours
trouvé à cause des modèles ou des préférences locales des utilisateurs,
dont les javascripts utilisateur dans leurs pages personelles que Wikimedia
s'interdit d'altérer au risque de créer des problèmes de sécurité sur les
PC de ces utilisateurs; enfin de tels renommages nécessitent un procvessus
complexe d'approbation et une surveillance par les admins qui doivent être
mis au courant des problèmes ultérieurs que cela peut provoquer, afin
d'éviter des usages abusifs ou de bloquer un utilisateur pour une mauvaise
raison liéé à une confusions entre utilisateurs différents pour des actions
réalisées à des dates d'avant ou après le renommage; il y a le risque que
durant la migration cela ouvre la porte à des spammeurs et toutes sortes
d'abus: le processus de renommage n'est pas sans risque en terme de
sécurité individuelle ou collective et il y a aussi des problèmes de
gestion des droits, notamment du droit d'auteur et des licences accordées
qui pourraient s'avérer invalides après; de tels renomages doivent donc
être historisés de façon fiable pour résoudre correctement tout conflit
ultérieur, et éviter qu'une nouvelle demande de vérification de droits à un
utilisateur aboutisse à la mauvaise personne qui ne répondra pas ou
répondra à mauvais escient, puis au retrait illégitime des droits et la
suppression d'anciennes modifs pourtant tout à fait valides sans avoir
avisé l'auteur initial à son nouveau compte).

Ceci dit, quand Wikidata est activé sur les éléments qu'on cherche, il
devrait servir de base et au lieu d'ajouter ou modifier des traductions
dans OSM, on pourra le faire sur Wikidata à la place et cela doit être
automatisable, même au sein des éditeurs OSM, devenus des éditeurs
OSM+Wikidata, sans même avoir ensuite à utiliser l'interface web de
Wikidata. Des bots OSM peuent aussi trouver les redondances et pourront
nettoyer OSM de ce qui n'est plus nécessaire après avoir vérifié les
redondances restantes et l'absence de conflits. Pour le reste les bots
peuvent lister les problèmes trouvés et les inscrire dans une
"maproulette", où selon le cas il faudra modifier soit les données OSM soit
celles de Wikidata par des outils d'édition plus avancés et distinctifs,
que des utilisateurs plus avancés maitrisant chaque environnement pourront
aller "nettoyer" à la main.

Note: il y a aussi du nettoyage à faire dans Wikidata, mais Wikidata a
aussi ses bots de vérification et ses longues listes de tâches à faire (les
modèles de données évoluent aussi, des éléments dont lobjet de fusion ou
scission et de désambiguisation, il y a aussi des entrées en doublon non
fusionnées automatiquement à cause de conflits internes à Wikidata). Ce
n'est pas simple non plus, et les utilisateurs avancés de Wikidata ont même
du mal à s'y retrouver car parfois les décision prises sont contradictoires
ou non coordonnées. Cela ne se rédout pas facilement et rapidement malgré
la bonne volonté de tout le monde, et parfois il y a des désaccords forts

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

[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] Vérification des tags wikipedia et nettoyage ?

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

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

[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] Vérification des tags wikipedia et nettoyage ?

[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] Vérification des tags wikipedia et nettoyage ?

[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] Vérification des tags wikipedia et nettoyage ?

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

[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] Vérification des tags wikipedia et nettoyage ?

[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

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

[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] Vérification des tags wikipedia et nettoyage ?

[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] Vérification des tags wikipedia et nettoyage ?

[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] Vérification des tags wikipedia et nettoyage ?

[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] Vérification des tags wikipedia et nettoyage ?

[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] Vérification des tags wikipedia et nettoyage ?

[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] Vérification des tags wikipedia et nettoyage ?

[Philippe Verdy]

Non, OSM a des données aussi pour bien autre chose que les liens Wikimedia,
notamment pour les libellés (name:* et variantes) qui sont en de bien plus
nombreuses langues (et écritures).

Pour les liens wikipedia, il n'y a pas besoin de la conformité BCP 47 car
oui dans ce cas ce ne sont que des étiquettes de noms de domaines.
Cependant dans les deux cas la casse n'est pas imposée, il y a juste une
casse recommandée et qu'on peut normaliser en minuscules (même si pour
BCP47 il est fait référence à des casses alternatives concernant les codes
ISO 3166-1 (à 2 lettres uniquement, éventuellement augmenté par des codes
de subdivisions de l'ISO 3166-2, avec un séparateur facultatif, donc lui
aussi ce second sous-code devrait être en capitales, mais ce cas ne
concerne pas les codes de langues régionalisés qui n'utilisent pas du tout
les codes ISO 3166-2) normalement en capitales uniquement, et les codes ISO
15924 avec l'initiale seule en capitale.

Pour OSM, tout ce qui concerne la codification des langues de base devrait
être en minuscules (mais les extensions de code peuvent varier en casse, et
on ne doit pas supprimer les séparateurs, et OSM devrait normaliser partout
les capitales requises pour les codes régions et l'initiale seulement des
codes d'écriture, sinon tout le reste en minuscules uniquement: on a des
tags dont les noms qui ont des extensions, préfixées ou suffixées avec ":"
qui dinstingue soit par pays, soit par langue; et aussi des extensions ":"
d'usage privé qui devraient être en minuscules mais d'autres en capitales
et on a le risque de collision avec des codes langue ou codes
géographiques, et c'est un peu le "bordel" dans ces extensions qui
devraient éviter tout risque de collision avec les codes langues ou
géographiques, en normalisant ces dernières de la façon recommandée par
BCP47, afin que les autres extension OSM n'utilisent aucune de ces formes;
cependant il n'y a pas de collision si les extensions OSM ne sont PAS 2 ou
3 lettres ou 3 chiffres éventuellement suivis d'un trait d'union et là on a
un peu toutes les formes; mais il y a encore certaines extensions privées
d'OSM qui entrent en collision avec les codes langues et géographiques avec
leur capitalisation normalisée : OSM initialement a émis des
recommandations n'utilisant que les minuscules mais ce n'est pas tenable et
les tags privées d'OSM ont une casse significative par défaut: on doit donc
normaliser la casse de ces codes même si ni BCP 47 ni les codes ISO, ni les
noms de domaines Wikimedia ne l'imposent, et ça traîne depuis des années et
continue à compliquer les requêtes et à poser des problèmes d'évolution
pour plus de langues ou de régions).


Le mer. 27 nov. 2019 à 00:36, Yves P.  a écrit :

>
> Concernant les préfixes de langue il n'y a pas que les tirets, mais si on
> les accepte il faudrait aussi valider la syntaxe. Visiblement ne sont
> acceptés que les codes langue en minuscules
>
> En fait c’est plus simple, on n’accepte que les codes de langues des sites
> wikipedia existants.
> cf. API wikimedia ou requêtes SPARQL : https://w.wiki/Cqb
>
> Minuscules ou majuscules, ce sont des noms de domaines, donc (pour le
> moment) ça ne change rien.
>
> —
> 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 ?

[Yves P.]

> Concernant les préfixes de langue il n'y a pas que les tirets, mais si on les 
> accepte il faudrait aussi valider la syntaxe. Visiblement ne sont acceptés 
> que les codes langue en minuscules
En fait c’est plus simple, on n’accepte que les codes de langues des sites 
wikipedia existants.
cf. API wikimedia ou requêtes SPARQL : https://w.wiki/Cqb

Minuscules ou majuscules, ce sont des noms de domaines, donc (pour le moment) 
ça ne change rien.

—
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 ?

[Philippe Verdy]

Le mar. 26 nov. 2019 à 23:28, Yves P.  a écrit :

>Notes
>
>1
https://trac.openstreetmap.org/browser/subversion/applications/editors/josm/plugins/tag2link/resources/tag2link_sources.xml#L59
>\p{Lower} dans l’expression rationnelle n’accepte pas le tiret ? Remplacer
par [a-z-] ou [a-zA-Z-]
>
>2 https://github.com/tyrasd/overpass-turbo/blob/master/js/overpass.js#L719
>[a-zA-Z] dans l’expression rationnelle n’accepte pas le tiret. Remplacer
par [a-zA-Z-]

Concernant les préfixes de langue il n'y a pas que les tirets, mais si on
les accepte il faudrait aussi valider la syntaxe. Visiblement ne sont
acceptés que les codes langue en minuscules (même accentuées ou non
latines, ce qui est incorrect). Mais aussi sans limite de longueur. De plus
après les tirets, on peut avoir un code de variante de langue (obsolète, de
3 lettres minuscules), un code d'écriture (1 majuscule et 3 minuscules), un
code région (2 lettres pour un code ISO 3166-1 ou 3 chiffres), et de code
de variante (en minuscules ou chiffres ASCII). Et tous les "subtags" sont
limités à 8 caractères et ont au moins 2 caractères (entre les tirets); les
sub
tags à 1 lettre sont spéciaux et ne devraient pas être utilisés pour
identifier les langues (les anciens codes IANA commençant par "i-" sont
obsolètes, et les codes langues "x-*" sont bannis hors des "subtags" de
variantes régionales (préférables aux codes de régions ISO 3166-1 qui ne
sont pas assez discernants), mais des propriétés de localisation.

Bref une expression régulière correcte serait

[a-z][a-z][a-z]?(-[a-z][a-z][a-z])?(-[A-Z][a-z][a-z][a-z])?(-[A-Z][A-Z]|[0-9][0-9][0-9])?(-x)?(-[a-z]{2,8}):

Si on est strict, mais on peut admettre alors aussi ces préfixes en
capitalisation différente (quitte à les normaliser ensuite automatiquement,
y compris en remplaçant les séparateurs "_" par des "-"), conformément à ce
que prévoit le standard BCP47. Ensuite chaque "subtag" peut éventuellement
être validé si on a une copie locale de la base IANA pour BCP47 (sauf cas
spécial des variantes "-x-[a-z0-9]{2,8}" qui elles sont validées par un
dictionnaire de variantes privées admises dans OSM (mais sont sujette à
remplacement automatisable ultérieurement s'il y a un code standard tel que
"be-x-tarask" reconverti en "be-tarask", avant la suppression de ces
admissions du dictionnaire quand la base OSM a été nettoyée et les
utilisateurs avertis)

Ceci dit la validation peut admettre des codes devenus depuis ambigus et
dépréciés mais qu'on ne peut pas remplacer automatiquement: c'est le cas
quand ISO a scindé un code langue en deux.

Il reste enfin des exceptions venant de Wikimedia (telles que "roa-tara"
qui devraient être plutôt une variante du sicilien "scn-tara" ou une
variante non standard de l'italien "it-x-tara")

D'autres substitutions automatiques sont possibles (exemple changer "fre"
ou "fra" en "fr", si on préfère les codes courts ISO 639-1 aux codes ISO
639-2/3).

Dans l'état, les validateurs sont peu à jour et sont encore basés sur la
vieille version de BCP 47 non basée sur RFC 4646 mais sur une version plus
ancienne. Il serait temsp de convertir tou ça car les RFC 47 a quand mêem
été mise à jour depuis plusieurs années, avant même la sortie de l'ISO
639-3 et les révisions de l'ISO 15924 pour les codes d'écritures et la
refonte du registre IANA avec des règles bien plus précises et une
politique de stabilité et une procédure établie pour les
ajouts/révisions/dépréciations, ainsi que la révision des codes à remplacer
automatiquement !

Quand à la normalisation des codes (la capitalisation) je n'ai pas d'avis
tranché, on peut très bien admettre dans OSM uniquement les formes
minuscules seulement, sans capitaliser la première lettre des codes
d'écriture ou les codes région ISO 3166-1 à deux lettres. En revanche on
doit éviter les formes ISO 3166 ou ISO15924 en chiffres, on peut les
subtituer automatiquement (et leur liste n'est pas longue, il ne doit
rester que quelques codes à 3 chiffres pour les groupes de pays par masse
continentale). Mais ce la ne devrait pas bloquer la validation des données
si un éditeur omet cette substitution automatique. car un bot peut
facilement faire la correction plus tard.
___
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 ?

[Yves P.]

Redirections gérées par les principales applications.

Contrôle
valeur
url
iD
tag2link
Openstreetmap
Overpass
wikipedia






avec préfixe de langue
fr:Œting
https://fr.wikipedia.org/wiki/Œting   
oui
oui
oui
oui
simple:Hatshepsut
https://simple.wikipedia.org/wiki/Hatshepsut 
 
oui
oui
oui
oui
nds:Seppenser Möhl
https://nds.wikipedia.org/wiki/Seppenser_Möhl 
  
oui
oui
oui
oui
es:Óscar Quiñones
https://es.wikipedia.org/wiki/Óscar_Quiñones 
   
oui
oui
oui
oui
be-tarask:Новы Двор
https://be-tarask.wikipedia.org/wiki/Новы_Двор 

 
⚠️ oui
oui
oui
non (2)
be-x-old:Серкавіцкі сельсавет
https://be-tarask.wikipedia.org/wiki/Серкавіцкі_сельсавет 


oui
oui
oui
fiu-vro:Põrmujärv
https://fiu-vro.wikipedia.org/wiki/Põrmujärv 
   
oui
oui
oui
sans préfixe
Paris
 ⚠️ pointe sur le site anglais
non
(comportement adapté )
龍潭大池
Париж
URL
https://en.wikipedia.org/wiki/Paris    

page de recherche 


⚠️ plante    
oui
oui

http://undar.edu.pe/  

oui
oui
wikipedia:*






wikipedia:fr
Île des Sœurs
https://fr.wikipedia.org/wiki/Île_des_Sœurs 
 
⚠️ non
oui
oui
oui
wikipedia:es
Alcocéber
https://es.wikipedia.org/wiki/Alcocéber 
  
oui
oui
oui
wikipedia:gag
Komrat
https://gag.wikipedia.org/wiki/Komrat    
oui
oui
oui
wikipedia:be-tarask
Межава (Аршанскі раён)
https://be-tarask.wikipedia.org/wiki/Межава_(Аршанскі_раён) 

 
non (1)
oui
oui
wikipedia:zh-yue
河北沿海高速公路
https://zh-yue.wikipedia.org/wiki/河北沿海高速公路 

 
oui
oui
wikidata






Liens multiples
Q22949674;Q22949654


⚠️ oui (3)
non
non
Notes






1
https://trac.openstreetmap.org/browser/subversion/applications/editors/josm/plugins/tag2link/resources/tag2link_sources.xml#L59
 


\p{Lower} dans l’expression rationnelle n’accepte pas le tiret ? Remplacer par 
[a-z-] ou [a-zA-Z-]
2
https://github.com/tyrasd/overpass-turbo/blob/master/js/overpass.js#L719 


[a-zA-Z] dans l’expression rationnelle n’accepte pas le tiret. Remplacer par 
[a-zA-Z-]
3
Produit un seul lien avec les 2 valeurs. Le site wikidata indique que cette 
entité n’existe pas.___
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 ?

[Yves P.]

Tableau des contrôles effectués par les éditeurs (non exhaustif)

Il y a des applications sur smartphone à rajouter éventuellement, les outils de 
contrôle qualité : osmose…

Les contrôles effectués sont probablement à compléter…

_
Yves


Contrôle
Exemple
iD
JOSM



validator
(wikipedia.mapcss 
)
greffon
Wikipedia
wikipedia
vérification du préfixe « langue »
dummy:Paris
non
incomplet
liste statique (2)
oui
utilise l’API de mediawiki (3)
vérification absence du préfixe
Paris
non
oui
oui
remplacement URL complète
https://en.wikipedia.org/wiki/Paris    
non
non
oui
remplacement caractères encodés
P%C3%B5rmuj%C3%A4rv
non
oui
non
remplacement caractères soulignés
nl:Gymnasium_Haganum
non
oui
oui (1)
vérification des redirections
fr:Manjaque redirect
non
non
oui
vérification wikipedia sans correspondance wikidata

non
non
oui
vérification article inexistant

non
non
non
vérification URL non wiki
http://undar.edu.pe/  

oui (4)
oui (5)

vérification valeurs multiples
en:Izadshahr, fa:ایزدشهر
non (6)
wikipedia:*
vérification du suffixe « langue » dans la clé
wikipedia:dummy
non
non
non
vérification des valeurs
(comme pour la clé wikipedia)

non
non
non

vérification caractères encodés
P%C3%B5rmuj%C3%A4rv
non
oui
non

remplacement caractères soulignés
Gymnasium_Haganum
non
non
non
*:wikipedia
vérification du préfixe dans la clé

non
non
non
vérification des valeurs
(comme pour la clé wikipedia)

non
non
non
wikidata
vérification élément inexistant

non

oui

vérification valeurs multiples
Q22949674;Q22949654

oui
oui (7)
wikidata
Affichage articles sur la carte

non

oui
wikipedia
wikidata
saisie interactive

oui

non
wikipedia
Notes





1
messages peu clairs :
[Wiki] Wikidata item and Wikipedia article do not match! - Wikidata item 
Q367203 is not associated with Wikipedia article nl:Gymnasium_Haganum (has no 
Q-ID) (1) 
[Wiki] Wikipedia article is a redirect - Wikipedia article 'Gymnasium_Haganum' 
redirects to 'Gymnasium Haganum' (1) 
2
https://josm.openstreetmap.de/browser/josm/trunk/data/validator/wikipedia.mapcss#L13
 

3
https://gitlab.com/JOSM/plugin/wikipedia/blob/master/src/main/java/org/wikipedia/validator/WikipediaValueFormat.java#L97
 

https://www.wikidata.org/w/api.php?action=help=sitematrix 

4
message peu clair :
attributs dépréciés - Le format du tag wikipedia est obsolète, utilisez 
'wikipedia'='langue:page de titre' à  la place (1) 
5
message clair ?
[Wiki] Unknown Wikipedia language prefix 'http'! (1) 
6
valeurs multiples non gérées. La page wikipedia inique que l’article n’existe 
pas.
7
valeurs multiples non gérées pour les vérifications (détecte une valeur 
erronée). Mais le nom de l’élément Q123 est affiché automatiquement___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Yves P.]

Bonsoir,

En regardant de plus près les clés wikipedia et leurs valeurs avec taginfo, je 
constate pas mal de bazar.

Lors de la saisie, que vérifient (ou pas) les principaux éditeurs ?
(J’ai fait un tableau comparatif. Il sera envoyé plus tard)

Pour les données existantes,

Comment repérer les valeurs et/ou les clés erronées ?
taginfo
difficile car pas de recherche par expressions rationnelles (regex)
export des valeurs + script utilisant des regex
requêtes overpass
expressions rationnelles limitées (pas de PCRE)
outils de contrôle qualité (Osmose…)
…

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…

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

—
Yves

PS: Quelques exemples :

wikipedia=fr:Phare
wikipedia_1=es:Faro
wikipedia_2=de:Leuchtturm
wikipedia_3=fa:فانوس دریایی
…

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

Préfixe de langue manquant
wikipedia=Phare
brand:wikipedia=McDonald's

Préfixe de langue incomplet (pb de copier/coller ?)
wikipedia=n:Connections Museum
operator:wikipedia=e:BDZ Deutsche Zoll- und Finanzgewerkschaft
brand:wikipedia=u:Россельхозбанк

Préfixes de langues correctes (norme ISO) mais sans site linguistique wikipédia 
correspondant

url complète et ses variantes
wikipedia=https://fr.wikipedia.org/wiki/Phare

url vers un site n’ayant rien à voir avec wikipedia
wikipedia=http://undar.edu.pe/

url avec un préfixe de langue rajouté !
wikipedia=fr:https://fr.wikipedia.org/wiki/Phare

mauvais séparateur . ; …
wikipedia=fr.Château_Mathelin

Photos wikimedia commons avec préfixe de langue
wikipedia=it:File:Alfred Nobel - Villa in Sanremo.jpg
wikipedia=fr:Canal Saint-Félix#/media/File:W1785-Nantes CanalStFelix Ecluse 
85749.JPG
wikipedia=de:Datei:Prichsenstadt BW 6.JPG
wikipedia=fr:Fichier:Bouvines Monument au morts.jpg
Valeurs multiples :
wikipedia=en:Izadshahr, fa:ایزدشهر
…

Des clés incorrectes :

Suffixes de langue inappropriés :
brand:wikipedia_1
brand:wikipedia:ar
…
subject:wikipedia:de
subject:wikipedia:en
…
artist:wikipedia:et

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 ?

…

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

Re: [OSM-talk-fr] vérification de quelques tags,

[deuzeffe]

On 10/25/18 1:08 PM, JB wrote:

Les thématiques qui me parlent : Le 24/10/2018 à 18:30, ades a écrit :
waterway:riverbanks on suit le wiki français : pas de riverbank si 
largeur moins de 12m?
Va vraiment falloir que quelqu'un aille modifier ce wiki, 


Just do it?
--
deuzeffe

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

Re: [OSM-talk-fr] vérification de quelques tags,

[JB]

Les thématiques qui me parlent : Le 24/10/2018 à 18:30, ades a écrit :

waterway:riverbanks on suit le wiki français : pas de riverbank si largeur 
moins de 12m?
Va vraiment falloir que quelqu'un aille modifier ce wiki, la question 
revient régulièrement. 12m, ça date de l'époque où on ne pouvait pas 
faire mieux faute d'outils et d'imagerie adaptée. Je ne dis pas que 50cm 
serait la bonne limite, mais on peut faire bien mieux que 12m actuellement.

landuse:forest vs natural:wood dans une zone complètement anthropisée c’est 
landuse:forest ?
Bof, tu fais un peu comme tu veux, les puristes n'arrivent pas à se 
mettre d'accord sur une définition et les autres s'en fichent un peu.


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

Re: [OSM-talk-fr] vérification de quelques tags,

[ades]

> Le 24 oct. 2018 à 20:31, marc marc  a écrit :
> 
> Le 24. 10. 18 à 18:30, ades a écrit :
>> waterway:riverbanks on suit le wiki français : pas de riverbank si largeur 
>> moins de 12m?

> 
> faudrait voir d'oü vient cette limite mais son sens est plutôt :
> "au plus étroite est la rivière, au moins on gagne par rapport
> à la représentation filaire"
> Mais tot ou tard, on y viendra à tout faire en 2d (faut juste
> que cela soi harmonieux avec l’existant)
Ok je laisse les riverbanks de moins  de 12m, ça me fait chier, mais bon…, je 
trouve que ça encombre énormément les rendus (cf un truc vu sur des marais de 
Loire-Atlantique) ceci dit c’est au moteur de rendu de faire le ménage ;-))
> 
>> highway:* sauf autoroutes, voies rapides tous les usages sont inclus ? velo, 
>> autos, piétons, bourrins, quads etc. ?
> 
> non, et le détail dépend du code la route de chaque pays
> https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions 
> 
vu merci du lien, pour la france c’est donc implicite…
>> bâtiments isolés au milieu d’un farmland ? Dans la mesure où il ne 
> s’agit pas d’exploitation agricole
> landuse c'est l'utilisation actuelle. donc landuse=residential me semble 
> adapté.
OK c’est ce que je fais
> Si on veux vraiement insister qu'il y a eu un changement d'affectation
> et non pas une erreur de tag, on peux rajouter
> was:landuse=farmyard
ou historic:farmyard ?
> 
>> préciser la pelouse, le jardin potager, la cours devant, garde t-on le 
>> ‘residencial’ ?
> 
> normalement chaque lieu ne devrait avoir qu'un landuse
> donc la pelouse d'une parcelle résidentielle devrait rester en résidentiel.
> il y a l’éternel débat entre ceux qui voudrait un landcover (pour dire 
> cette partie de la zone résidentielle est couverte d'herbe ou a quelquea 
> abres etc) et ceux pour qui landuser=grass est tellement courant qu'il 
> faut garder cette erreur pour l’éternité. du coup landcover n'est pas 
> rendu sur osm.org (ce qui n’empêche pas de l'ajouter mais démotive certains)
ça landuse et landcover j’avais remarqué, c’est un gros foutoir, maintenant 
j’essye de faire avec, avec ce que dit le wiki ;-)
> 
>> landuse: flowerbed ? peut-on utiliser ce tag ( 6 occutrences pour l’instant) 
>> ?
> 
> tu peux utiliser le tag que tu veux :) mais c'est mieux si c'est 
> compréhensible et utilisé :)
> si c'est un landuse, c'est une zone qu'on sacrifie pour lutter
> contre les inondations en aval en cas de crue ?
non, flowerbed=parterre
Pour ces zone ça va être coton à définir ;-), la ville deTours on la sacrifie 
pour éviter des inondations à Nantes ? ;-)))
> 
>> landuse:forest vs natural:wood dans une zone complètement anthropisée c’est 
>> landuse:forest ?
> 
> il y a 6 façons de voir une différence ou pas entre les 2
> https://wiki.openstreetmap.org/wiki/Forest
> la seule chose que tu peux en déduire des 2 tags c'est qu'il y a
> eu des arbres, tout le reste est variable selon le contributeur.
> c'est là qu'à nouveau un landcover permettrait de sortir de conflit
> landcover=trees + managed=yes/no
évident ;-)
> ___
> 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 de quelques tags,

[marc marc]

Le 24. 10. 18 à 18:30, ades a écrit :
> waterway:riverbanks on suit le wiki français : pas de riverbank si largeur 
> moins de 12m?

faudrait voir d'oü vient cette limite mais son sens est plutôt :
"au plus étroite est la rivière, au moins on gagne par rapport
à la représentation filaire"
Mais tot ou tard, on y viendra à tout faire en 2d (faut juste
que cela soi harmonieux avec l'existant)

> highway:* sauf autoroutes, voies rapides tous les usages sont inclus ? velo, 
> autos, piétons, bourrins, quads etc. ?

non, et le détail dépend du code la route de chaque pays
https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions
  > bâtiments isolés au milieu d’un farmland ? Dans la mesure où il ne 
s’agit pas d’exploitation agricole
landuse c'est l'utilisation actuelle. donc landuse=residential me semble 
adapté.
Si on veux vraiement insister qu'il y a eu un changement d'affectation
et non pas une erreur de tag, on peux rajouter
was:landuse=farmyard

> préciser la pelouse, le jardin potager, la cours devant, garde t-on le 
> ‘residencial’ ?

normalement chaque lieu ne devrait avoir qu'un landuse
donc la pelouse d'une parcelle résidentielle devrait rester en résidentiel.
il y a l’éternel débat entre ceux qui voudrait un landcover (pour dire 
cette partie de la zone résidentielle est couverte d'herbe ou a quelquea 
abres etc) et ceux pour qui landuser=grass est tellement courant qu'il 
faut garder cette erreur pour l’éternité. du coup landcover n'est pas 
rendu sur osm.org (ce qui n’empêche pas de l'ajouter mais démotive certains)

> landuse: flowerbed ? peut-on utiliser ce tag ( 6 occutrences pour l’instant) ?

tu peux utiliser le tag que tu veux :) mais c'est mieux si c'est 
compréhensible et utilisé :)
si c'est un landuse, c'est une zone qu'on sacrifie pour lutter
contre les inondations en aval en cas de crue ?

> landuse:forest vs natural:wood dans une zone complètement anthropisée c’est 
> landuse:forest ?

il y a 6 façons de voir une différence ou pas entre les 2
https://wiki.openstreetmap.org/wiki/Forest
la seule chose que tu peux en déduire des 2 tags c'est qu'il y a
eu des arbres, tout le reste est variable selon le contributeur.
c'est là qu'à nouveau un landcover permettrait de sortir de conflit
landcover=trees + managed=yes/no
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] vérification de quelques tags,

[ades]

waterway:riverbanks on suit le wiki français : pas de riverbank si largeur 
moins de 12m?

highway:* sauf autoroutes, voies rapides tous les usages sont inclus ? velo, 
autos, piétons, bourrins, quads etc. ?

landuse  
comment tagger le terrain d’assiette d’un bâtiment ou groupe de bâtiments 
isolés au milieu d’un farmland ? Dans la mesure où il ne s’agit pas 
d’exploitation agricole (farmyard). Pour l’instant, j’avais retenu 
‘landuse:residencial’. Doit-on remettre farmyard dans la mesure où 
historiquement il s’agissait de ça, mais y-a longtemps qu’il n’y a plus de 
paysans à ces endroits.
Si l’on est capable ensuite de préciser la pelouse, le jardin potager, la cours 
devant, garde t-on le ‘residencial’ ?
D’ailleurs à propos de cours, je n’est pas trouver de tag pour ce type d’espace.

landuse: flowerbed ? peut-on utiliser ce tag ( 6 occutrences pour l’instant) ?

landuse:forest vs natural:wood dans une zone complètement anthropisée c’est 
landuse:forest ?

La végétation dans le lit mineur d’une rivière on la représente ?

c’est tout pour l'instant
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Vérification

[Yannick]

Le 15/05/2017 à 01:06, François Lacombe a écrit :

Bonsoir

Les amis de wikipedia ont traité le sujet. Il y a les adresses associées

https://fr.m.wikipedia.org/wiki/Liste_des_fa%C3%A7ades_factices_de_Paris

A+

Francois


Bonjour,

Merci à tous les deux.
Je me disais que c'était bizarre que ce ne soit pas traité.
Il est vrai que j'ai eu du mal à travailler sur ce truc mais cela ne 
venait de chez moi, pas le bonhomme mais de la version de JOSM utilisée 
et aussi un problème de Java.


Merci d'avoir rectifié mon erreur.

Amitiés

--
Yannick VOYEAUD
Nul n'a droit au superflu tant que chacun n'a pas son nécessaire
(Camille JOUFFRAY 1841-1924, maire de Vienne)
http://www.voyeaud.org
Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/
Journées du Logiciel Libre: http://jdll.org
Généalogie en liberté avec Ancestris http://www.ancestris.org
Aidez Ancestris à aller au Havre
https://www.helloasso.com/associations/ancestris/collectes/le-havre-2017

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

Re: [OSM-talk-fr] Vérification

[François Lacombe]

Bonsoir

Les amis de wikipedia ont traité le sujet. Il y a les adresses associées

https://fr.m.wikipedia.org/wiki/Liste_des_fa%C3%A7ades_factices_de_Paris

A+

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

Re: [OSM-talk-fr] Vérification

[Vincent de Château-Thierry]

Le 15/05/2017 à 00:00, Yannick a écrit :


Vas-y fais le ménage et récupère la note si tu veux pour mettre sur le
polygone. Ne te gène surtout pas.


Hop hop : https://twitter.com/_vdct/status/863879620466225152

Bonne nuit,
vincent

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

Re: [OSM-talk-fr] Vérification

[Yannick]

Le 14/05/2017 à 22:35, Vincent de Château-Thierry a écrit :

Bonsoir,

Le 14/05/2017 à 21:58, Yannick a écrit :


J'ai un doute sur une action que je viens de faire.
Merci de bien vouloir la vérifier.
Groupe Id 493505417


Il s'agit de l'ID du way que tu as ajouté. Il vient en doublon de la
relation https://www.openstreetmap.org/relation/3173679 qui décrit déjà
cet "immeuble". Si tu as des infos à ajouter c'est sur le multipolygone
qu'il faudrait le faire.


À priori l'adresse n'était pas entrée, je l'ai faite.
J'ai signalé en note que seule la façade existe! Il n'y a pas de
logements à cette adresse. Il y a simplement une bouche d'aération pour
le RER.
Il s'agit du 145 rue Lafayette à Paris (75009)


Je suis passé devant jeudi et je confirme ;) C'est assez troublant de
distinguer les grilles d'aération et de constater que la façade est
trompeuse sur la destination du bâtiment.

vincent



Bonsoir Vincent,

Avant de partir me coucher.
Merci de confirmer ce que je pensais.
Vas-y fais le ménage et récupère la note si tu veux pour mettre sur le 
polygone. Ne te gène surtout pas.


Merci
Amitiés

--
Yannick VOYEAUD
Nul n'a droit au superflu tant que chacun n'a pas son nécessaire
(Camille JOUFFRAY 1841-1924, maire de Vienne)
http://www.voyeaud.org
Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/
Journées du Logiciel Libre: http://jdll.org
Généalogie en liberté avec Ancestris http://www.ancestris.org
Aidez Ancestris à aller au Havre
https://www.helloasso.com/associations/ancestris/collectes/le-havre-2017

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

[OSM-talk-fr] Vérification

[Yannick]

Bonsoir,

J'ai un doute sur une action que je viens de faire.
Merci de bien vouloir la vérifier.
Groupe Id 493505417

À priori l'adresse n'était pas entrée, je l'ai faite.
J'ai signalé en note que seule la façade existe! Il n'y a pas de 
logements à cette adresse. Il y a simplement une bouche d'aération pour 
le RER.

Il s'agit du 145 rue Lafayette à Paris (75009)

Merci de corriger mes éventuelles fautes.

Amitiés

--
Yannick VOYEAUD
Nul n'a droit au superflu tant que chacun n'a pas son nécessaire
(Camille JOUFFRAY 1841-1924, maire de Vienne)
http://www.voyeaud.org
Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/
Journées du Logiciel Libre: http://jdll.org
Généalogie en liberté avec Ancestris http://www.ancestris.org
Aidez Ancestris à aller au Havre
https://www.helloasso.com/associations/ancestris/collectes/le-havre-2017

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

Re: [OSM-talk-fr] Vérification Osmose: nettoyage des imports routiers, champs redondants

[Philippe Verdy]

Le 9 février 2012 06:35, Vincent de Chateau-Thierry v...@laposte.net a écrit :
 Bonjour,

 Le 09/02/2012 01:28, Philippe Verdy a écrit :

 Le 8 février 2012 20:55, Vincent de Chateau-Thierryv...@laposte.net  a
 écrit :



 Le 08/02/2012 18:30, Philippe Verdy a écrit :


 (...)


  Notes ===

 Ne vous fiez pas forcément aux données affichées dans le mode plan
 vectoriel de Google Maps : il y a de nombreuses erreurs et
 approximations sur les noms de voies,



 Se fier à des données des plans sous copyright Google ou © Bing serait en
 effet une très mauvaise idée, et ce quelle que soit leur qualité ou leurs
 approximations. L'incompatibilité de licence intervient bien avant la
 qualité.


 Là je ne parlais pas des données du plan, mais des *photos* de plein
 pied prises par les Google Cars,


 Soit. Mais dans ce cas, évite d'appeler mode plan vectoriel une photo :-)

Non je ne me suis pas trompé. Ta citation est incorrecte et mélange
les phrases hors contexte, pour leur faire dire le contraire.

J'ai parlé de deux choses séparées au moment où je disais de ne pas
utiliser le mode plan vectoriel comme source de données : car cela
n'excluait pas de consulter les photos de plein pied du mode street
view non pas pour y lire aussi un libellé ajouté par Google en
surimpression, mais pour regarder les plaques de rues ou la
signalisation qui sont sur les photos elles-mêmes.

On n'importe pas non plus ces photos (qui sont sous copyright,
concernant la prise de vue, mais pas ce qu'elles représentent qui sont
des objets dont Google n'est pas propriétaire).

On a le droit de regarder ces photos, ne serait-ce que pour contrôler
une orthographe, voire trouver un nom oublié dans OSM et qui n'est pas
forcément juste non plus dans le mode plan vectoriel de Google Maps
qui a aussi de nombreuses erreurs, malgré les photos. Google l'admet
lui-même, en mentionnant souvent adresse approximative ; car son
mode plan vectoriel (visible aussi en surimpression sur l'imagerie
aérienne et sous forme de libellés en perspective sur les photos du
mode streetview) est un gruyère avec des trous informes, bien qu'il
faut lui reconnaître une bonne qualité de sa géométrie (au moins sur
les rues qui ont été parcourues de plein pied, alors que les autres
voies dessinées sont parfois des approximations aussi depuis la vue
aérienne, avec des voies farfelues en surnombre).

Hors toi tu sembles dire que même regarder ces photos c'est pécher.
Ce n'est qu'une source intéressante de comparaison, mais on n'en
prends directement aucune données. C'est un élément utile comme le
seraient d'autres sources. Lire une plaque de rue sur une photo, qui
que soit celui qui a pris la/les photo(s) et avec pour chacun son
copyright, ne change rien au statut de l'objet de la voie publique sur
la photo, c'est le même objet dont le photographe ne s'approprie pas
la propriété simplement par son cliché.

Je note aussi que même ceux qui vont sur place enquêter, ou qui
connaissent en apparence bien un lieu, se trompent aussi sur certains
noms, et on trouve des fautes d'orthographe à foison. On en trouve
aussi parmi les données interprétées en lisant le cadastre, qui
omettent des accents, insèrent des abréviations, confondent des
homonymes, délimitent mal une rue à une extrémité, ou associent une
voie parallèle au même nom que la rue principale quand ce n'est pas le
cas (ce cas est courant aussi sur les grandes places quand les
intersections et accès forment un système complexe de voies
principales, voies de service, chemins piétons : sans regarder la
signalisation sur place, difficile de se fier à un plan général,
surtout quand on est piéton, même avec une carte OSM qui privilégie
encore trop la circulation en voiture pour simplifier le reste).

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

Re: [OSM-talk-fr] Vérification Osmose: nettoyage des imports routiers, champs redondants

[Pieren]

2012/2/9 Philippe Verdy verd...@wanadoo.fr:

 Non je ne me suis pas trompé. Ta citation est incorrecte et mélange
 les phrases hors contexte, pour leur faire dire le contraire.

Je vais donc reprendre le texte original exact:
Ne vous fiez pas forcément aux données affichées dans le mode plan
vectoriel de Google Maps : il y a de nombreuses erreurs et
approximations sur les noms de voies, non corrigées malgré la présence
de photos dans son mode Street View, et souvent Google Maps (Bing
aussi...)

Pour reprendre ton vocabulaire, il n'y a pas à se fier aux données
affichées dans le mode plan vectoriel qui contiendraient des
erreurs/approximations parce que, comme l'ont dit les autres, on n'a
pas à s'en servir.
Le fait est que dans ton message, tu passes allègrement de gmaps à
streetview alors que, comme tu l'indiques justement plus-tard, leur
utilisation pour OSM peut être différenciée.
Il y a cependant deux points que je veux corriger:
- le contenu des photos streetview ne peuvent être réutilisées de
manière automatique ou massive. Car si le contenu des photos
n'appartient pas à Google comme tu le dis, ça n'est pas le cas de leur
collection et géoréférencement. Nous en avons d'ailleurs la
confirmation écrite par Ed Parsons lui-même (so checking the odd
street names is OK.. but every street name I would suggest would
represent a bulk feed) comme cela a été mentionné à plusieurs
reprises sur cette liste.
- tu mentionnes les erreurs dans les diverses sources. Il faut aussi
mentionner les plaques de rues qui peuvent, elles aussi, parfois se
tromper (dans l'orthographe ou même dans la dénomination). C'est très
rare mais on doit pouvoir trouver quelques exemples dans les archives.
Il faut donc toujours prendre toutes nos sources avec précaution et ne
pas oublier que l'une de nos devises c'est le terrrain qui prime
s'applique en cas de doute.

Pieren

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

Re: [OSM-talk-fr] Vérification Osmose: nettoyage des imports routiers, champs redondants

[Emilie Laffray]

+1 pour Pieren
On Feb 9, 2012 12:53 PM, Pieren pier...@gmail.com wrote:

 2012/2/9 Philippe Verdy verd...@wanadoo.fr:

  Non je ne me suis pas trompé. Ta citation est incorrecte et mélange
  les phrases hors contexte, pour leur faire dire le contraire.

 Je vais donc reprendre le texte original exact:
 Ne vous fiez pas forcément aux données affichées dans le mode plan
 vectoriel de Google Maps : il y a de nombreuses erreurs et
 approximations sur les noms de voies, non corrigées malgré la présence
 de photos dans son mode Street View, et souvent Google Maps (Bing
 aussi...)

 Pour reprendre ton vocabulaire, il n'y a pas à se fier aux données
 affichées dans le mode plan vectoriel qui contiendraient des
 erreurs/approximations parce que, comme l'ont dit les autres, on n'a
 pas à s'en servir.
 Le fait est que dans ton message, tu passes allègrement de gmaps à
 streetview alors que, comme tu l'indiques justement plus-tard, leur
 utilisation pour OSM peut être différenciée.
 Il y a cependant deux points que je veux corriger:
 - le contenu des photos streetview ne peuvent être réutilisées de
 manière automatique ou massive. Car si le contenu des photos
 n'appartient pas à Google comme tu le dis, ça n'est pas le cas de leur
 collection et géoréférencement. Nous en avons d'ailleurs la
 confirmation écrite par Ed Parsons lui-même (so checking the odd
 street names is OK.. but every street name I would suggest would
 represent a bulk feed) comme cela a été mentionné à plusieurs
 reprises sur cette liste.
 - tu mentionnes les erreurs dans les diverses sources. Il faut aussi
 mentionner les plaques de rues qui peuvent, elles aussi, parfois se
 tromper (dans l'orthographe ou même dans la dénomination). C'est très
 rare mais on doit pouvoir trouver quelques exemples dans les archives.
 Il faut donc toujours prendre toutes nos sources avec précaution et ne
 pas oublier que l'une de nos devises c'est le terrrain qui prime
 s'applique en cas de doute.

 Pieren

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

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

Re: [OSM-talk-fr] Vérification Osmose: nettoyage des imports routiers, champs redondants

[Christian Rogel]

Le 9 févr. 2012 à 13:52, Pieren a écrit :

 Nous en avons d'ailleurs la
 confirmation écrite par Ed Parsons lui-même (so checking the odd
 street names is OK.. but every street name I would suggest would
 represent a bulk feed) comme cela a été mentionné à plusieurs
 reprises sur cette liste.

Paroles verbales sans portée pour un ajout discontinu. 
Il pourrait tout juste faire semblant de se fâcher, si quelque faisait un 
import massif
(bulk feed) par détection automatique des noms, le tout dans une courte 
séquence de temps.

il ne faut pas croire tout ce que racontent les gens, surtout, ceux qui ont un 
monopole à défendre.
Orange laisse entendre que Free n'est pas au top, alors qu'eux sont les purs 
croisés
du service mobile.
Les croyez-vous, les uns et les autres?


Christian

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

Re: [OSM-talk-fr] Vérification Osmose: nettoyage des imports routiers, champs redondants

[Philippe Verdy]

Le 9 février 2012 13:52, Pieren pier...@gmail.com a écrit :
 Il y a cependant deux points que je veux corriger:
 - le contenu des photos streetview ne peuvent être réutilisées de
 manière automatique ou massive. Car si le contenu des photos
 n'appartient pas à Google comme tu le dis, ça n'est pas le cas de leur
 collection et géoréférencement.

Sauf que je n'ai pas dit le contraire, je n'ai justement fait que
défendre cela, le géoréférencement et toutes autres données ajoutées
au delà des prises de vues elles-mêmes est sujet à caution, d'abord
parce qu'effectivement ces données sont propriétaires, mais aussi
entâchées d'erreurs, ce que je 'ai souligné aussi.

Malgré tout, les plaques de rue sont certainement plus fiables que
bien d'autres sources (y compris le cadastre), et en attendant bien
plus fiables que ce qu'aurait noté par erreur quelqu'un sur le
terrain, et qui a introduit ses propres erreurs, ne serait-ce que de
façon involontaire par une faute de frappe. C'est d'ailleurs ce type
d'erreurs qui justement frappe aussi les labels affichés dans Google
Maps qui précise bien adresse approximative parce que Google ne les
a pratiquement jamais vérifiées par d'autres sources et qu'il attend
qu'on les lui signale.

Si une plaque de rue ou une signalisation est erronée c'est
extrêmement rarement une erreur : ce qui peut se passer est plus
souvent qu'une plaque a été oubliée et pas changée après un changement
de nom. C'est en revanche plus fréquent sur des panneaux indicateurs
vers des destinations plus lointaines, raison de plus pour aller
regarder une dénomination sur place.

De plus je ne qualifierait pas comme erreur le fait qu'une plaque de
rue ou un panneau d'entrée d'agglomération mentionne un nom ou une
orthographe alternative. Cela veut dire que ce nom reste en usage
aussi (et même bon nombre de collectivités continuent à utiliser des
graphies voire des noms alternatifs pour se désigner elles-mêmes dans
leurs publications, alors que l'enregistrement officiel (type Insee)
utilise un autre nom ou une autre graphie et omet celle utilisée par
la collectivité.

Car l'Insee peut aussi ne pas être (encore) à jour sur la dernière
version de sa base de données. Ensuite il n'y a pas que l'Insee même
si en principe le COG fait autorité pour les autres services de l'Etat
et des collectivités. Ces incohérences momentanées surviennent, et
alors il ne reste que la publication dans le Journal Officiel
mentionnant le texte de la décision de changement ou d'attribution de
nom.

Pour les autres noms qui ne désignent pas une collectivité publique,
notamment les tonomymes locaux, l'Insee n'établit pas de réference. Il
reste alors l'IGN en second lieu. Parfois l'IGN mentionne aussi des
noms différents pour les toponymes associés à une collectivité, parce
que cela correspond à une longue tradition, ou parce que ce nom a
longtemps été officiel, et parce qu'il est toujours utilisé et encore
référencé dans des documents qui font encore foi.

Dans tous ces cas, j'ai de très forts doutes sur la capacité de ceux
qui vont sur le terrain et rapportent des données en contradiction
avec ce qu'on trouve sur des plaques de rues et panneaux indicateurs,
ou se fient seulement à leur mémoire ou connaissance pour transcrire
des noms et orthographes approximatifs. Il faut admettre qu'eux aussi
font des erreurs, et même bien plus souvent que ce qu'on trouve sur
les panneaux (que moi je ne mettrai JAMAIS en doute SAUF si on me
donne un texte réellement officiel tel qu'un arrêté publié au JORF, et
qui prévaudra sur tout ce qui figure dans n'importe quelle base de
données, fusse-t-elle de l'Insee ou de l'IGN).

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

[OSM-talk-fr] Vérification Osmose: nettoyage des imports routiers, champs redondants

[Philippe Verdy]

Je tombe souvent sur des zones où Osmose annonce (avec raison) une
grande redondance de données parmi celles qui ont été importées.
Notamment car les champs sont en fait mal choisis pour les mettre.

Exemple:

  tag k=name v=Voie communale n°7 d'Elliant à Concarneau /
  tag k=ref v=C 7 /

Ici, le champ name ne contient pas le nom de la voie, c'est en fait
une description (un nom de voie pourrait s'y ajouter si la voie
traverse par exemple un village et prend le nom d'une rue).
La partie de cette description Voie communales n°7 correspond à ce
qui a été mis dans le ref. Le reste est seulement descriptif.

Je suggère que les imports routiers fassent attention aux données
qu'ils importent, quitte à utiliser un champ description pour les
données qui ne sont pas converties correctement, afin de faciliter les
mises à jour manuelles, où à titre documentaire ou de suivi. Par
exemple la plupart des imports ajoutent des tags de suivi, propres à
la source utilisée, notamment des identifiants divers, comme ici la
source de la Communauté de communes de Concarneau - Cornouailles
(), avec des tags dont le nom commence par 4C:. Cela doit
suffire pour assurer une synchronisation ou un suivi de ce qui a été
importé (attention toutefois à utiliser des tags appropriés qui ne
risquent pas de rentrer en conflit avec des tags génériques
documentés: l'utilisation des préfixes est donc fortement recommandé,
surtout si la source est très locale et pas nationale, comme ici une
communauté de communes).

Si on en tient compte, l'exemple ci-dessus (détecté par le
vérificateur Osmose) devrait être après nettoyage:

  tag k=description v=D'Elliant à Concarneau /
  tag k=ref v=C 7 /

Reste à savoir ensuite si on garde ou non les champs description qui
restent (à mon avis ils peuvent rester, et seront utiles même pour le
suivi ou lors de l'utilisation d'une carte interactive, surtout ici où
il n'y a pas de nom clair, ou alors parce que ces noms révèlent des
lieux dits proches, qui facilitent aussi la localisation, à condition
d'avoir demandé à afficher les infos détaillées d'une voie)...

De même, des champs fréquents comme:

  tag k=name v=Voie communale n°4 /
  tag k=ref v=C 4 /

sont clairement redondants, car le nom donné n'apporte strictement
rien de plus que la référence. Dans ce cas on supprime directement le
champ name, et on ne garde que le champ ref.

Ces nettoyages peuvent se faire directement depuis l'interface en
ligne d'Osmose, avec rawedit et non JOSM, parce que c'est nettement
plus léger et rapide à faire.

Mais pour des zones étendues où il y a une grande répétition de ces
redondances, la fonction de recherche intégrée à JOSM permet de faire
des sélections multiples d'objets sur la valeur d'un champ spécifique,
pour corriger cette valeur dans tous les objets chargés qui utilisent
cette valeur redondante.

A mon avis, il vaudrait mieux faire ces nettoyages dans JOSM avant
l'importation vers la base de données, mais il peut s'agit aussi d'un
oubli. A vous de voir quel éditeur utiliser selon l'étendue des
nettoyages à faire avant vos imports de données. ou après pour
corriger les erreurs introduites après l'importation des données

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

Re: [OSM-talk-fr] Vérification Osmose: nettoyage des imports routiers, champs redondants

[Frédéric Rodrigo]

Bonjour,

Tes remarques sont légitimes. Malheureusement ces données ne
proviennent pas d'imports mais de contributions manuelle en recopiant
bêtement le cadastre.

Frédéric.

Le 8 février 2012 15:51, Philippe Verdy verd...@wanadoo.fr a écrit :
 Je tombe souvent sur des zones où Osmose annonce (avec raison) une
 grande redondance de données parmi celles qui ont été importées.
 Notamment car les champs sont en fait mal choisis pour les mettre.

 Exemple:

  tag k=name v=Voie communale n°7 d'Elliant à Concarneau /
  tag k=ref v=C 7 /

 Ici, le champ name ne contient pas le nom de la voie, c'est en fait
 une description (un nom de voie pourrait s'y ajouter si la voie
 traverse par exemple un village et prend le nom d'une rue).
 La partie de cette description Voie communales n°7 correspond à ce
 qui a été mis dans le ref. Le reste est seulement descriptif.

 Je suggère que les imports routiers fassent attention aux données
 qu'ils importent, quitte à utiliser un champ description pour les
 données qui ne sont pas converties correctement, afin de faciliter les
 mises à jour manuelles, où à titre documentaire ou de suivi. Par
 exemple la plupart des imports ajoutent des tags de suivi, propres à
 la source utilisée, notamment des identifiants divers, comme ici la
 source de la Communauté de communes de Concarneau - Cornouailles
 (), avec des tags dont le nom commence par 4C:. Cela doit
 suffire pour assurer une synchronisation ou un suivi de ce qui a été
 importé (attention toutefois à utiliser des tags appropriés qui ne
 risquent pas de rentrer en conflit avec des tags génériques
 documentés: l'utilisation des préfixes est donc fortement recommandé,
 surtout si la source est très locale et pas nationale, comme ici une
 communauté de communes).

 Si on en tient compte, l'exemple ci-dessus (détecté par le
 vérificateur Osmose) devrait être après nettoyage:

  tag k=description v=D'Elliant à Concarneau /
  tag k=ref v=C 7 /

 Reste à savoir ensuite si on garde ou non les champs description qui
 restent (à mon avis ils peuvent rester, et seront utiles même pour le
 suivi ou lors de l'utilisation d'une carte interactive, surtout ici où
 il n'y a pas de nom clair, ou alors parce que ces noms révèlent des
 lieux dits proches, qui facilitent aussi la localisation, à condition
 d'avoir demandé à afficher les infos détaillées d'une voie)...

 De même, des champs fréquents comme:

  tag k=name v=Voie communale n°4 /
  tag k=ref v=C 4 /

 sont clairement redondants, car le nom donné n'apporte strictement
 rien de plus que la référence. Dans ce cas on supprime directement le
 champ name, et on ne garde que le champ ref.

 Ces nettoyages peuvent se faire directement depuis l'interface en
 ligne d'Osmose, avec rawedit et non JOSM, parce que c'est nettement
 plus léger et rapide à faire.

 Mais pour des zones étendues où il y a une grande répétition de ces
 redondances, la fonction de recherche intégrée à JOSM permet de faire
 des sélections multiples d'objets sur la valeur d'un champ spécifique,
 pour corriger cette valeur dans tous les objets chargés qui utilisent
 cette valeur redondante.

 A mon avis, il vaudrait mieux faire ces nettoyages dans JOSM avant
 l'importation vers la base de données, mais il peut s'agit aussi d'un
 oubli. A vous de voir quel éditeur utiliser selon l'étendue des
 nettoyages à faire avant vos imports de données. ou après pour
 corriger les erreurs introduites après l'importation des données

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

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

Re: [OSM-talk-fr] Vérification Osmose: nettoyage des imports routiers, champs redondants

[Marc SIBERT]

Bonjour,

Pour faire court (si si c'est aussi possible), je plaide coupable, car j'ai
activement participé à l'import de la 4C probablement à l'origine de tes
remarques (cf. http://freeroute.fr/4c/  http://freeroute.fr/?page_id=307).

Je suis donc à ta dispo pour un petit marathon correctif dans ce sens.

A+

-- 
Marc Sibert
m...@sibert.fr

Le 8 février 2012 15:51, Philippe Verdy verd...@wanadoo.fr a écrit :

 Je tombe souvent sur des zones où Osmose annonce (avec raison) une
 grande redondance de données parmi celles qui ont été importées.
 Notamment car les champs sont en fait mal choisis pour les mettre.

 Exemple:

  tag k=name v=Voie communale n°7 d'Elliant à Concarneau /
  tag k=ref v=C 7 /

 Ici, le champ name ne contient pas le nom de la voie, c'est en fait
 une description (un nom de voie pourrait s'y ajouter si la voie
 traverse par exemple un village et prend le nom d'une rue).
 La partie de cette description Voie communales n°7 correspond à ce
 qui a été mis dans le ref. Le reste est seulement descriptif.

 Je suggère que les imports routiers fassent attention aux données
 qu'ils importent, quitte à utiliser un champ description pour les
 données qui ne sont pas converties correctement, afin de faciliter les
 mises à jour manuelles, où à titre documentaire ou de suivi. Par
 exemple la plupart des imports ajoutent des tags de suivi, propres à
 la source utilisée, notamment des identifiants divers, comme ici la
 source de la Communauté de communes de Concarneau - Cornouailles
 (), avec des tags dont le nom commence par 4C:. Cela doit
 suffire pour assurer une synchronisation ou un suivi de ce qui a été
 importé (attention toutefois à utiliser des tags appropriés qui ne
 risquent pas de rentrer en conflit avec des tags génériques
 documentés: l'utilisation des préfixes est donc fortement recommandé,
 surtout si la source est très locale et pas nationale, comme ici une
 communauté de communes).

 Si on en tient compte, l'exemple ci-dessus (détecté par le
 vérificateur Osmose) devrait être après nettoyage:

  tag k=description v=D'Elliant à Concarneau /
  tag k=ref v=C 7 /

 Reste à savoir ensuite si on garde ou non les champs description qui
 restent (à mon avis ils peuvent rester, et seront utiles même pour le
 suivi ou lors de l'utilisation d'une carte interactive, surtout ici où
 il n'y a pas de nom clair, ou alors parce que ces noms révèlent des
 lieux dits proches, qui facilitent aussi la localisation, à condition
 d'avoir demandé à afficher les infos détaillées d'une voie)...

 De même, des champs fréquents comme:

  tag k=name v=Voie communale n°4 /
  tag k=ref v=C 4 /

 sont clairement redondants, car le nom donné n'apporte strictement
 rien de plus que la référence. Dans ce cas on supprime directement le
 champ name, et on ne garde que le champ ref.

 Ces nettoyages peuvent se faire directement depuis l'interface en
 ligne d'Osmose, avec rawedit et non JOSM, parce que c'est nettement
 plus léger et rapide à faire.

 Mais pour des zones étendues où il y a une grande répétition de ces
 redondances, la fonction de recherche intégrée à JOSM permet de faire
 des sélections multiples d'objets sur la valeur d'un champ spécifique,
 pour corriger cette valeur dans tous les objets chargés qui utilisent
 cette valeur redondante.

 A mon avis, il vaudrait mieux faire ces nettoyages dans JOSM avant
 l'importation vers la base de données, mais il peut s'agit aussi d'un
 oubli. A vous de voir quel éditeur utiliser selon l'étendue des
 nettoyages à faire avant vos imports de données. ou après pour
 corriger les erreurs introduites après l'importation des données

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

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

Re: [OSM-talk-fr] Vérification Osmose: nettoyage des imports routiers, champs redondants

[Philippe Verdy]

Cela ne concerne pas que la 4C, je trouve des cas semblables partout
en France, où le champ name est mal choisi...

Encore une fois, en cas de doute sur la clé à utiliser pour les
tags, avec des données pourtant utiles au repérage, mieux vaut
importer le texte sous la clé description. L'absence de nom et/où de
référence sera ensuite rapportée par Osmose, mais on évitera de mettre
des infos qui ne sont pas des noms, et qui entreront ensuite en
conflit avec des noms de rues par exemple, afin ensuite de les relier
aux adresses.
Et sur un import massif, il n'est pas inutile de mettre un tag de
suivi pour la vérification manuelle (sur la base de diverses sources
utilisables, sur le terrain ou sur des photos lisibles sur un moteur
comme Google Maps, pour voir les plaques de rues et de lieux-dits ou
la signalisation).

 Notes ===

Ne vous fiez pas forcément aux données affichées dans le mode plan
vectoriel de Google Maps : il y a de nombreuses erreurs et
approximations sur les noms de voies, non corrigées malgré la présence
de photos dans son mode Street View, et souvent Google Maps (Bing
aussi...) inscrit le nom d'un lieu-dit comme nom d'une voie à défaut
d'autre chose. Dans ces cas là, seul le numéro de référence est
réellement pertinent.

Pour de nombreuses routes sans numéro de référence, ce n'est pas Bing
ou Google Maps qui donne ces numéros, mais presque toujours le
cadastre (car il n'y a souvent aucun panneau, cette numérotation est
gérée directement au niveau de chaque commune, et même pas toujours
affiché sur les plans municipaux diffusés par la commune ou affichés
sur des panneaux).

Ces voies non numérotées dans Bing et Google Maps sont essentiellement
les chemins ou voies communales (format C nnn), chemins vicinaux
(format CV nnn), chemins ruraux (format CR nnn), chemins
d'exploitation (format CE nnn), et chemins départementaux (format
CD nnn, trouvés uniquement en limite de département pour les petits
chemins qui en marquent la frontière), car justement on ne les voit
partiquement jamais dehors sur un panneau.

Parfois il faut se pencher (on ne verra rien sur les photos de Google
Street View) et regarder les inscriptions sur certaines bornes
cadastrales, mais bon nombre de bornes n'affichent que des numéros de
parcelle, parfois un code interne difficile à interpréter ; mais on y
voit souvent l'identité du service cadastral qui les plantées (avec un
avertissement Ne pas déplacer, afin justement de les reconnaître).

Ces bornes cadastrales n'ont pas toujours une grande durée de vie, et
sont posées par des géomètres avant le début de travaux sur des
terrains faisant l'objet de demande de permis de construire. Après
quoi le chantier est contrôlé et la commune peut autoriser leur
retrait éventuel (quand ces bornes ne font pas partie du réseau
géodésique réglementaire), le plan cadastral prenant en compte les
bâtiments ou voies construits et recettés, conformes aux permis de
construire.

Elles peuvent aussi être déplacées (pas par les propriétaires
eux-mêmes ! il faut faire une demande d'autorisation), voire
supprimées, notamment dans le cadre de remembrements de parcelles pour
une exploitation agricole, ou de construction de murs de séparation de
propriétés (hors voirie publique, car les collectivités imposent des
distances réglementaires sur les terrains privés, dans lesquelles où
rien ne peut être construit en dur, parfois même pas un arbre, mais où
des plantations légères restent possibles comme des pelouses; il
arrive aussi que des morceaux de parcelles fassent l'objet d'une
préemption par les communes, où rien ne peut être aménagé par les
propriétaires, en vue d'un élargissement futur d'une petite voirie ;
mais cette préemption peut mettre du temps à se transformer en rachat
de terrain, le temps de trouver les accords avec les propriétaires et
les budgets nécessaires pour le rachat des terrains expropriés, le
plan d'aménagement n'étant pas complètement défini).

Le 8 février 2012 16:19, Marc SIBERT m...@sibert.fr a écrit :
 Bonjour,

 Pour faire court (si si c'est aussi possible), je plaide coupable, car j'ai
 activement participé à l'import de la 4C probablement à l'origine de tes
 remarques (cf. http://freeroute.fr/4c/  http://freeroute.fr/?page_id=307).

 Je suis donc à ta dispo pour un petit marathon correctif dans ce sens.

 A+

 --
 Marc Sibert
 m...@sibert.fr

 Le 8 février 2012 15:51, Philippe Verdy verd...@wanadoo.fr a écrit :

 Je tombe souvent sur des zones où Osmose annonce (avec raison) une

 grande redondance de données parmi celles qui ont été importées.
 Notamment car les champs sont en fait mal choisis pour les mettre.

 Exemple:

  tag k=name v=Voie communale n°7 d'Elliant à Concarneau /
  tag k=ref v=C 7 /

 Ici, le champ name ne contient pas le nom de la voie, c'est en fait
 une description (un nom de voie pourrait s'y ajouter si la voie
 traverse par exemple un village et prend le nom d'une rue).
 La partie de cette description Voie communales n°7 correspond à ce
 qui a été 

Re: [OSM-talk-fr] Vérification Osmose: nettoyage des imports routiers, champs redondants

[Vincent de Chateau-Thierry]

Le 08/02/2012 18:30, Philippe Verdy a écrit :

(...)

 Notes ===

Ne vous fiez pas forcément aux données affichées dans le mode plan
vectoriel de Google Maps : il y a de nombreuses erreurs et
approximations sur les noms de voies,


Se fier à des données des plans sous copyright Google ou © Bing serait 
en effet une très mauvaise idée, et ce quelle que soit leur qualité ou 
leurs approximations. L'incompatibilité de licence intervient bien avant 
la qualité.


 non corrigées malgré la présence

de photos dans son mode Street View, et souvent Google Maps (Bing
aussi...) inscrit le nom d'un lieu-dit comme nom d'une voie à défaut
d'autre chose. Dans ces cas là, seul le numéro de référence est
réellement pertinent.

Pour de nombreuses routes sans numéro de référence, ce n'est pas Bing
ou Google Maps qui donne ces numéros, mais presque toujours le
cadastre (car il n'y a souvent aucun panneau, cette numérotation est
gérée directement au niveau de chaque commune, et même pas toujours
affiché sur les plans municipaux diffusés par la commune ou affichés
sur des panneaux).
(...)


vincent

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

Re: [OSM-talk-fr] Vérification Osmose: nettoyage des imports routiers, champs redondants

[Philippe Verdy]

Le 8 février 2012 20:55, Vincent de Chateau-Thierry v...@laposte.net a écrit :


 Le 08/02/2012 18:30, Philippe Verdy a écrit :

 (...)


  Notes ===

 Ne vous fiez pas forcément aux données affichées dans le mode plan
 vectoriel de Google Maps : il y a de nombreuses erreurs et
 approximations sur les noms de voies,


 Se fier à des données des plans sous copyright Google ou © Bing serait en
 effet une très mauvaise idée, et ce quelle que soit leur qualité ou leurs
 approximations. L'incompatibilité de licence intervient bien avant la
 qualité.

Là je ne parlais pas des données du plan, mais des *photos* de plein
pied prises par les Google Cars, qui montrent les plaques de rues.
Ce ne sont pas des approximations, au moins concernant
l'orthographe, sauf si cepuis la prise de vue un nom de rue (ou de
route) a changé. La date de prise de vue peut renseigner, par rapport
à ce qui a été cartographié depuis le cadastre. Il arrive que les
photos soient plus récentes que le plan cadastral disponible.

Regarder une photo pour lire une plaque, ce n'est pas la copier, il
n'y a pas de violation du copyright sur la photo, Google n'est pas
propriétaire des noms affichés sur les plaques de rue et la
signalisation publique, mais seulement de sa base de données dérivée
de ces photos et des clichés eux-même à l'exclusion de *tout* ce
qu'ils représentent (que les objets présentés soient eux-mêmes publics
ou privés, les éléments privés étant aussi sujets à retrait par leurs
propriétaires légitimes qui peuvent demander à flouter une façade,
l'état d'une porte ou fenêtre, un intérieur visible par une fenêtre,
un visage reconnaissable oublié, une plaque d'immatriculation, un
mobilier ou équipement extérieur hors de la voie publique; il arrive
même que Google floute les numéros de routes sur la signalisation,
quand celle-ci ne correspond plus et la plaque de signalisation n'a
pas encore été changée par l'équipement départemental ou la commune).

Et je note que ***bien souvent*** les photos de Google Street View
(prises de plein pied) sont plus récentes que celles fournies par le
CNES/Spot Image pour Bing ou Google en mode aérien, et que les données
présentes dans la base OSM sont issues d'une vectorisation depuis
l'imagerie Bing (plus ancienne) et utilisée par les Chair mappers.

Je ne dis pas qu'il faut reprendre les données de Google Street View.
En fait on n'en reprends aucune: on regarde les photos, qui souvent
aussi renseignent même sur des erreurs dans la base cartographique de
Google Maps, et qu'on peut aussi lui signaler en cliquant le lien
signaler une erreur (pour cela il faut sortir du zoom en mode
street view pour se repositionner sur la carte ou la vue satellite)
; par exemple des fautes d'orthographe, des accents manquants, des
noms obsolètes, etc... (Google demande qu'on lui fournisse une
référence fiable et datée pour qu'il accepte la correction, ou une
brève explication concernant un toponyme mal orthographié ou un accent
manquant, et permettant de localiser un autre nom auquel le toponyme
ou le nom de rue est normalement lié).

C'est aussi bien pour cela que Google Street View mentionne ses dates
de prises de vue, afin ensuite de pouvoir comparer avec d'autres
sources plus récentes qui lui seraient fournies, au cas où une photo
de plein pied ne serait elle aussi plus à jour (Google réponds à ces
signalements par Email et informe que la mise à jour de sa base peut
prendre plusieurs semaines pour apparaître sur son plan corrigé.

En attendant, on peut mettre à jour rapidement sur OSM. Et il est bon
dans ce cas-là d'ajouter une note mentionnant la source d'un éventuel
changement de nom ou de situation en contradiction avec les sources
utilisées ici (notamment l'imagerie Bing, et certaines autres sources
ouvertes non cadastrales) : par exemple un lien vers l'arrêté au
journal officiel mentionnant un changement de nom, la désaffection
d'une voie, le reclassement d'une route nationale en départementale,
une démolition de route récente... Sinon un cartographe amateur serait
tenté de remettre des données anciennes pourtant déjà corrigées et à
jour..

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

Re: [OSM-talk-fr] Vérification Osmose: nettoyage des imports routiers, champs redondants

[Vincent de Chateau-Thierry]

Bonjour,

Le 09/02/2012 01:28, Philippe Verdy a écrit :

Le 8 février 2012 20:55, Vincent de Chateau-Thierryv...@laposte.net  a écrit :



Le 08/02/2012 18:30, Philippe Verdy a écrit :


(...)


 Notes ===

Ne vous fiez pas forcément aux données affichées dans le mode plan
vectoriel de Google Maps : il y a de nombreuses erreurs et
approximations sur les noms de voies,



Se fier à des données des plans sous copyright Google ou © Bing serait en
effet une très mauvaise idée, et ce quelle que soit leur qualité ou leurs
approximations. L'incompatibilité de licence intervient bien avant la
qualité.


Là je ne parlais pas des données du plan, mais des *photos* de plein
pied prises par les Google Cars,


Soit. Mais dans ce cas, évite d'appeler mode plan vectoriel une photo :-)

vincent

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

Re: [OSM-talk-fr] Vérification import points de g éodésie

[Frédéric Rodrigo]

Le vendredi 14 mai 2010 00:30:43, Vincent Pottier a écrit :
 Le 10/05/2010 16:23, Etienne Chové a écrit :
  Bonjour,
  
  Je viens de relancer un test :
  http://geodesie.openstreetmap.fr/check/
  
  On a pas encore pris de décision sur quoi faire ? Déjà il faudrait
  alerter les utilisateurs qui font des erreurs. Pour les noeuds
  supprimés, on peut refaire un import. Il faudrait qu'il y ait une suite
  à cet import, car plus ça va aller, plus il va y avoir d'erreurs à
  corriger.
 
 Je crois qu'il faudrait ajouter un test sur le nom et sur l'existence de
 la relation.
 Je viens de voir ceci :
 http://www.openstreetmap.org/browse/relation/488567/history
 Le nom du site est passé de COLOMBE A à Colombe.
 
 Par ailleurs, des tags ont été ajoutés à certains repères :
 * amenity=place_of_worship (8 nœuds). On s'en doutait, vu qu'il y a
 36000 clocher. (Non, c'est vrai ! 36373 nœuds ayant 'clocher' dans la
 description)
 * amenity=doctors (2 nœuds) Ça c'est inquiétant, puisque les repères
 sont décrits sur un clocher.
 ** http://www.openstreetmap.org/browse/node/670633273
 ** http://www.openstreetmap.org/browse/node/670634279
 * natural=peak. (~250 nœuds) Un bon nombre de repère a déjà été
 identifié comme sommet.
 * image=* un repère a été photographié. Mais la photo sur flickr n'est
 pas géolocalisée.
 http://www.openstreetmap.org/browse/node/670055098
 * power=tower
 * tourisme=view_point
 * place=village
 ...
 Hé, 136 974 points bien référencés, ça inspire...
 Mais c'est sur, il va falloir les protéger, repérer ce qui peut être
 ajouté (peak, tower) et ce qui ne le peut pas.

Il faudrais retrouver les discutions, mais il me semble que l'on avait dit 
qu'il fallait dissocier le support du repère lui même.
Mise à part les natural=peak c'est tout à fait faisable à la main.

My 2cents
Fred

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

Re: [OSM-talk-fr] Vérification import points de g éodésie

[Vincent Pottier]

Le 14/05/2010 10:48, Frédéric Rodrigo a écrit :
 Le vendredi 14 mai 2010 00:30:43, Vincent Pottier a écrit :

 Le 10/05/2010 16:23, Etienne Chové a écrit :
  
 Bonjour,

 Je viens de relancer un test :
 http://geodesie.openstreetmap.fr/check/

 On a pas encore pris de décision sur quoi faire ? Déjà il faudrait
 alerter les utilisateurs qui font des erreurs. Pour les noeuds
 supprimés, on peut refaire un import. Il faudrait qu'il y ait une suite
 à cet import, car plus ça va aller, plus il va y avoir d'erreurs à
 corriger.

 Je crois qu'il faudrait ajouter un test sur le nom et sur l'existence de
 la relation.
 Je viens de voir ceci :
 http://www.openstreetmap.org/browse/relation/488567/history
 Le nom du site est passé de COLOMBE A à Colombe.

 Par ailleurs, des tags ont été ajoutés à certains repères :
 * amenity=place_of_worship (8 nœuds). On s'en doutait, vu qu'il y a
 36000 clocher. (Non, c'est vrai ! 36373 nœuds ayant 'clocher' dans la
 description)
 * amenity=doctors (2 nœuds) Ça c'est inquiétant, puisque les repères
 sont décrits sur un clocher.
 ** http://www.openstreetmap.org/browse/node/670633273
 ** http://www.openstreetmap.org/browse/node/670634279
 * natural=peak. (~250 nœuds) Un bon nombre de repère a déjà été
 identifié comme sommet.
 * image=* un repère a été photographié. Mais la photo sur flickr n'est
 pas géolocalisée.
 http://www.openstreetmap.org/browse/node/670055098
 * power=tower
 * tourisme=view_point
 * place=village
 ...
 Hé, 136 974 points bien référencés, ça inspire...
 Mais c'est sur, il va falloir les protéger, repérer ce qui peut être
 ajouté (peak, tower) et ce qui ne le peut pas.
  
 Il faudrais retrouver les discutions, mais il me semble que l'on avait dit
 qu'il fallait dissocier le support du repère lui même.
 Mise à part les natural=peak c'est tout à fait faisable à la main.

Oui. Je n'ai pas commenté, il était tard !
En dehors de l'image, qui est un ajout intéressant, les autres tags 
ajoutés décrivent un objet différent du repère lui-même. Il est donc 
souhaitable d'avoir un point différent dans la base.
De fait, je pense (apès une bonne nuit) que même 'peak' et 'tower' 
doivent être distingués du repère.

Peut-on prendre comme principe que
- les tags qui ajoutent de l'information sur le repère peuvent être 
conservés (image...)
- les tags qui décrivent un objet autre que le repère géodésique (tower, 
building, view_point, peak...) doivent être reporté sur un autre objet OSM.

Si le principe est accepté, je peux dédoubler les points concernés (via 
JOSM) pour ne pas perdre l'info déja entrée, et je l'inscrit dans le 
wiki. Ça va augmenter le nombre de dupes...
--
FrViPofm

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

Re: [OSM-talk-fr] Vérification import points de gé odésie

[Guillaume Allegre]

Le Fri 14 May 2010 à 10:48 +0200, Frédéric Rodrigo a ecrit :

  Hé, 136 974 points bien référencés, ça inspire...
  Mais c'est sur, il va falloir les protéger, repérer ce qui peut être
  ajouté (peak, tower) et ce qui ne le peut pas.
 
 Il faudrais retrouver les discutions, mais il me semble que l'on avait dit 
 qu'il fallait dissocier le support du repère lui même.
 Mise à part les natural=peak c'est tout à fait faisable à la main.

Dissocier repère et support, c'est bien ce qu'on avait dit.
Cela dit, pour les supports qui sont eux-mêmes ponctuels (tower-pylone et peak),
j'aurais tendance à changer d'avis, et à permettre d'enrichir le node
(surtout pour le peak, qui n'est pas un objet physique, mais un point 
particulier
du terrain).
Tout simplement, parce que c'est plus naturel pour les contributeurs qui passent
derrière. Et je n'ai pas l'impression que ça incite plus à déplacer le node.
Cela dit, il faut voir si cela ne complique pas trop les vérifications par la 
suite.
Etienne, Eric, qu'en pensez-vous ?


A propos des sommets qui font partie de sites, je pensais qu'une règle implicite
est que le premier point du site (numéroté 1 ou A) était toujours réservé au 
vrai sommet, les autres étant répartis autour, mais j'ai des doutes 
maintenant.
Est-ce que vous avez des retours d'expérience ?


-- 
 ° /\Guillaume AllègreMembre de l'April
  /~~\/\   allegre.guilla...@free.fr  Promouvoir et défendre le logiciel libre
 /   /~~\tél. 04.76.63.26.99  http://www.april.org

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

Re: [OSM-talk-fr] Vérification import points de g éodésie

[Eric SIBERT]

Je fais partie de ceux qui utilisent les repères géodésiques pour placer 
les sommets. C'était une partie de ma motivation pour l'import des 
repères géodésiques. Je fais ceci en surchargeant le nœud existant. 
Personnellement, d'un point de vue théorique, je ne vois pas trop où est 
le problème de surcharger les nœuds, du moment que la partie importée 
est conservée. La vérification doit se concentrée sur cette partie 
importée. Maintenant, d'un point de vue pratique, je peux imaginer qu'il 
y ai des risques de confusions pour des utilisateurs pas assez 
consciencieux et/ou attentifs. Une première personne surcharge le repère 
(boule du clocher) avec l'église dessus. Une seconde personne dessine le 
contours de l'église et supprime le point qui n'a plus lieu d'être sans 
se rendre compte qu'il contient d'autres informations. Le risque paraît 
plus faible avec un support qui ne peut exister que sous forme de nœud 
et pas de chemin.

Une nouvelle rubrique Utilisation des repères géodésiques dans le wiki 
me semblerait pertinente une fois qu'on se sera mis d'accord.

 A propos des sommets qui font partie de sites, je pensais qu'une règle 
 implicite
 est que le premier point du site (numéroté 1 ou A) était toujours réservé au
 vrai sommet, les autres étant répartis autour, mais j'ai des doutes 
 maintenant.
 Est-ce que vous avez des retours d'expérience ?

Je vais toujours consulter les fiches pour voir si je peux utiliser un 
repère comme sommet. Et il me semble qu'il y a des exceptions où le 
premier repère de la liste n'est pas le plus important du site. Et aussi 
des fois, aucun point n'est vraiment au sommet.

Frédéric, c'est envisageable à terme d'avoir un import csv similaire au 
précédent depuis le nouveau site des repères géodésiques?

Éric

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

Re: [OSM-talk-fr] Vérification import points de gé odésie

[Guillaume Allegre]

Le Fri 14 May 2010 à 13:17 +0200, Eric SIBERT a ecrit :

 Une nouvelle rubrique Utilisation des repères géodésiques dans le wiki 
 me semblerait pertinente une fois qu'on se sera mis d'accord.

Oui.

-- 
 ° /\Guillaume AllègreMembre de l'April
  /~~\/\   allegre.guilla...@free.fr  Promouvoir et défendre le logiciel libre
 /   /~~\tél. 04.76.63.26.99  http://www.april.org

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

Re: [OSM-talk-fr] Vérification import points de gé odésie

[hpmt]

Eric Sibert a écrit , Le 11/05/2010 18:25:
 (on sait jamais, en cas de typo sur le site IGN)
 Si, on sait: il y en a. J'ai trouvé un morceau de la cathédrale
 d'Orléans dans l'Océan Atlantique. Là, c'était assez visible car le
 repère est tout seul en pleine mer mais je soupçonne qu'il n'y en ait
 d'autre.
C'est peut-être la dernière trace d'un très vieux canular d'officier de 
marine destiné à ridiculiser les bleus qui apprennent à faire le point 
au sextant ; dans mon souvenir (de copine de marin) il y a aussi un 
morceau de Notre Dame de Paris en plein Pacifique.
Évidemment de nos jours où n'importe quel pékin (tel que moi) a la 
possibilité de détenir une carte marine et d'apprendre s'en servir, la 
private joke est beaucoup moins subtile..


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

Re: [OSM-talk-fr] Vérification import points de gé odésie

[Guillaume Allegre]

Le Wed 12 May 2010 à 00:53 +0200, Etienne Chové a ecrit :

  Quelques suggestions :
  * ajouter un en-tête avec le nombre de points déplacés, le nombre de points 
  supprimés,
 
 done ? on verra à la prochaine génération
 
  et un lien direct vers les points supprimés

 comprend pas... un lien vers une slippy map ?
 

non, non, beaucoup plus simple : je parlais d'un lien interne à la page pour
sauter directement à la section DELETED NODES, qui est un peu perdu 
Et du coup, je viens de m'apercevoir qu'il y a aussi une section moved ele,
donc même demande, évidememnt.

Evidemment, un lien vers une slippy map pourrait être bien utile aussi.

  Pour chaque modif signalée
  * mettre un vrai lien sur le champ url (fiche point)
 
 done ? on verra à la prochaine génération
 
  * ajouter l'URL du _site_ correspondant (c'est mal foutu sur le site IGN, 
  on n'a pas moyen
de remonter de la fiche point à la fiche site)
 
 comment elle se construit ?

http://ancien-geodesie.ign.fr/fiche_geodesie.asp?num_site=NNN
si on ajoute : X=NNNY=NNN  on a droit aussi à l'extrait de carte 
IGN, 
mais ce n'est pas très important pour nous

  * éventuellement, indiquer aussi le département et la commune, qui ne sont 
  pas dans les tags
  point, mais qui doivent être dans les données initiales (extraction de F. 
  Rodrigo ?)
  Cela faciliterait un peu la surveillance par zones.
 
 Je les ai pas, mais je dois pouvoir envoyer tout ça sur osmose sans trop 
 de difficulté... juste un peu de temps. Il suffit de générer un xml bien 
 formé à la place d'un html bien pourri.
Si on a accès facilement à la fiche site, ça manque moins.

-- 
 ° /\Guillaume AllègreMembre de l'April
  /~~\/\   allegre.guilla...@free.fr  Promouvoir et défendre le logiciel libre
 /   /~~\tél. 04.76.63.26.99  http://www.april.org

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

Re: [OSM-talk-fr] Vérification import points de gé odésie

[Etienne Chové]

Coucou,

Je pense que c'est bon. Est ce que tu peux regarder si je n'ai rien 
oublié à tes requêtes ?

-- 
Etienne

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

Re: [OSM-talk-fr] Vérification import points de gé odésie

[Damien Boilley]

  Pour chaque modif signalée
  * mettre un vrai lien sur le champ url (fiche point)
  * ajouter l'URL du _site_ correspondant (c'est mal foutu sur le site IGN, 
  on n'a pas moyen
    de remonter de la fiche point à la fiche site)

Juste une remarque sur ces url : il se trouve que le site est en train
d'être remanié (comme le terme ancien le laissait deviner), voir
http://geodesie.ign.fr avec une version beta qui indique
actualisation quotidienne des données.

Damouns

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

Re: [OSM-talk-fr] Vérification import points de gé odésie

[Guillaume Allegre]

Le Wed 12 May 2010 à 16:45 +0200, Damien Boilley a ecrit :
   Pour chaque modif signalée
   * mettre un vrai lien sur le champ url (fiche point)
   * ajouter l'URL du _site_ correspondant (c'est mal foutu sur le site 
   IGN, on n'a pas moyen
     de remonter de la fiche point à la fiche site)
 
 Juste une remarque sur ces url : il se trouve que le site est en train
 d'être remanié (comme le terme ancien le laissait deviner), voir
 http://geodesie.ign.fr avec une version beta qui indique
 actualisation quotidienne des données.

ah, effectivement, et ça promet d'être assez pénible si l'IGN décide de 
supprimer le site ancien, car les nouveaux liens passent par beaucoup plus 
de javascript et surtout ne donnent accès qu'à des documents pdf 
(un pdf multipages de site regroupant la description générale et tous les 
points)


-- 
 ° /\Guillaume AllègreMembre de l'April
  /~~\/\   allegre.guilla...@free.fr  Promouvoir et défendre le logiciel libre
 /   /~~\tél. 04.76.63.26.99  http://www.april.org

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

Re: [OSM-talk-fr] Vérification import points de gé odésie

[Vincent Pottier]

Le 11/05/2010 07:01, hpmt a écrit :
 Justement, je viens de me poser une question à propos du point
 géodésique boule de l'église de mon village, dont je peaufine les
 détails du centre ville.
 Le contour du bâtiment église n'existait pas du tout, je l'ai repris
 du cadastre ; mais fallait-il y rattacher le point géodésique ?
 Comme je maîtrise mal les relations (pour l'instant) je me suis
 abstenue, et j'ai laissé le point géodésique intact par prudence.

 Est-cela que vous attendez des contributeurs de terrain (je veux dire :
 ceux qui font la dentelle à la mimine, et pas d'import massif ?)

 à plus,
 Hélène PETIT


Tout à fait.
Il n'est pas nécessaire de lier la bâtiment église au repère géodésique.
Si jamais ça présente un intérêt pour quelques usages par la suite, on 
sera à même de le faire.

Par contre, ce qui m'intéresserait, c'est de repérer les repères genre 
boule de l'église ;-) qui n'ont pas un bâtiment dessous.
Si quelqu'un peut m'expliquer comment on peut faire ça... Je pourrai 
faire des essais en local.
--
FrViPofm

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

Re: [OSM-talk-fr] Vérification import points de gé odésie

[Guillaume Allegre]

Le Mon 10 May 2010 à 23:30 +0200, Eric SIBERT a ecrit :
  ---
  Bonjour,
  Lors d'une récente contribution à OpenStreetMap, vous avez supprimé ou
  déplacé un ou plusieurs de repères géodésiques
 
 français (ou quelque chose qui indique que ça se passe en France)
 
  importés dans
  Openstreetmap ou ou vous en avez altéré des caractéristiques.
  Ces changements seront rétablis automatiquement par un robot.
  Si lors de ces transformations, vous avez inclus le point dans un objet
  (route, bâtiment...) Le rétablissement de ces points transformera votre
  composition. Veuillez vérifier votre travail et éviter l'emploi d'un
  point géodésique.
  Les repères géodésiques comportent une note invitant à ne pas les
  déplacer, les détruire ou les altérer. Merci d'observer cette consigne.
  Pour plus d'information, vous pouvez consulter le wiki à la page
  http://wiki.openstreetmap.org/wiki/WikiProject_France/Rep%C3%A8res_G%C3%A9od%C3%A9siques
  Vous pouvez aussi contacter la communauté francophone via la mailing-list :
  http://openstreetmap.fr/forum#nabble-f3070341
  Enfin vous pouvez consulter la liste des altérations des repères
  géodésiques :
  http://geodesie.openstreetmap.fr/check/

+ Si vous pensez toutefois que les coordonnées du repère sont clairement 
fausses,
merci de contacter la liste talk-fr@openstreetmap.org avant d'entreprendre 
toute 
modification.

(on sait jamais, en cas de typo sur le site IGN)


Enfin, j'aimerais savoir s'il est possible d'améliorer un peu la page de 
synthèse ?
http://geodesie.openstreetmap.fr/check/check-2010-05-10.html
Quelques suggestions :
* ajouter un en-tête avec le nombre de points déplacés, le nombre de points 
supprimés, 
et un lien direct vers les points supprimés
Pour chaque modif signalée
* mettre un vrai lien sur le champ url (fiche point)
* ajouter l'URL du _site_ correspondant (c'est mal foutu sur le site IGN, on 
n'a pas moyen
 de remonter de la fiche point à la fiche site)
* éventuellement, indiquer aussi le département et la commune, qui ne sont pas 
dans les tags
point, mais qui doivent être dans les données initiales (extraction de F. 
Rodrigo ?)
Cela faciliterait un peu la surveillance par zones.

Je suis bien conscient que c'est encore du travail, et que c'est toujours les 
mêmes qui
le font (pas moi).

-- 
 ° /\Guillaume AllègreMembre de l'April
  /~~\/\   allegre.guilla...@free.fr  Promouvoir et défendre le logiciel libre
 /   /~~\tél. 04.76.63.26.99  http://www.april.org

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

Re: [OSM-talk-fr] Vérification import points de g éodésie

[Eric Sibert]

 + Si vous pensez toutefois que les coordonnées du repère sont  
 clairement fausses,
 merci de contacter la liste talk-fr@openstreetmap.org avant  
 d'entreprendre toute
 modification.

 (on sait jamais, en cas de typo sur le site IGN)

Si, on sait: il y en a. J'ai trouvé un morceau de la cathédrale  
d'Orléans dans l'Océan Atlantique. Là, c'était assez visible car le  
repère est tout seul en pleine mer mais je soupçonne qu'il n'y en ait  
d'autre. Il faudrait par exemple avec un script qui vérifié que les  
points sont bien dans la commune annoncée. Mais est-ce bien notre  
boulot? Surtout, en l'absence de possibilité de retour réel vers  
l'IGN, il va être difficile d'établir une relation gagnante/gagnante  
IGN/OSM.

Eric


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

Re: [OSM-talk-fr] Vérification import points de gé odésie et retour IGN

[Guillaume Allegre]

Le Tue 11 May 2010 à 18:25 +0200, Eric Sibert a ecrit :
  + Si vous pensez toutefois que les coordonnées du repère sont  
  clairement fausses,
  merci de contacter la liste talk-fr@openstreetmap.org avant  
  d'entreprendre toute
  modification.
 
  (on sait jamais, en cas de typo sur le site IGN)
 
 Si, on sait: il y en a. J'ai trouvé un morceau de la cathédrale  
 d'Orléans dans l'Océan Atlantique. Là, c'était assez visible car le  
 repère est tout seul en pleine mer mais je soupçonne qu'il n'y en ait  
 d'autre. Il faudrait par exemple avec un script qui vérifié que les  
 points sont bien dans la commune annoncée. Mais est-ce bien notre  
 boulot? 
Ben non, c'est pas vraiment notre boulot, effectivement.
Mais si on veut que les consignes soient respectées, il va certainement falloir
se résoudre à supprimer les erreurs grossières de la base, vu qu'on ne va pas 
les 
repositionner au GPS.


 Surtout, en l'absence de possibilité de retour réel vers l'IGN, 
 il va être difficile d'établir une relation gagnante/gagnante IGN/OSM.

Est-ce qu'un tel retour vers l'IGN a déjà été tenté ?  
Et s'il s'est mal passé (signalement ignoré), peut-être que dans le cadre
du partenariat OSGeo-fr - IGN et du rapprochement OSM/OSGeo-fr, ça passerait
mieux ?


-- 
 ° /\Guillaume AllègreMembre de l'April
  /~~\/\   allegre.guilla...@free.fr  Promouvoir et défendre le logiciel libre
 /   /~~\tél. 04.76.63.26.99  http://www.april.org

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

Re: [OSM-talk-fr] Vérification import points de gé odésie

[Vincent Pottier]

Le 10/05/2010 16:23, Etienne Chové a écrit :
 Bonjour,

 Je viens de relancer un test :
 http://geodesie.openstreetmap.fr/check/

 On a pas encore pris de décision sur quoi faire ? Déjà il faudrait
 alerter les utilisateurs qui font des erreurs.
+1, Un message bilingue automatique, c'est faisable ?
Qui traduit ?
À partir de quel compte ?
Proposition :
---
Bonjour,
Lors d'une récente contribution à OpenStreetMap, vous avez supprimé ou 
déplacé un ou plusieurs de repères géodésiques importés dans 
Openstreetmap ou ou vous en avez altéré des caractéristiques.
Ces changements seront rétablis automatiquement par un robot.
Si lors de ces transformations, vous avez inclus le point dans un objet 
(route, bâtiment...) Le rétablissement de ces points transformera votre 
composition. Veuillez vérifier votre travail et éviter l'emploi d'un 
point géodésique.
Les repères géodésiques comportent une note invitant à ne pas les 
déplacer, les détruire ou les altérer. Merci d'observer cette consigne.
Pour plus d'information, vous pouvez consulter le wiki à la page 
http://wiki.openstreetmap.org/wiki/WikiProject_France/Rep%C3%A8res_G%C3%A9od%C3%A9siques
Vous pouvez aussi contacter la communauté francophone via la mailing-list :
http://openstreetmap.fr/forum#nabble-f3070341
Enfin vous pouvez consulter la liste des altérations des repères 
géodésiques :
http://geodesie.openstreetmap.fr/check/
Merci de votre compréhension.
La communauté francophone.

 Pour les noeuds
 supprimés, on peut refaire un import. Il faudrait qu'il y ait une suite
 à cet import, car plus ça va aller, plus il va y avoir d'erreurs à corriger.


Pour les autres aussi on fait un rétablissement d'office à l'état initial.

Sur la page wiki, il faudrait noter les erreurs courantes. On peut 
repérer, dans les destructions - changement d'altitude, des fusions de 
points (certainement une suggestion du validator)
--
FrViPofm

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

Re: [OSM-talk-fr] Vérification import points de gé odésie

[hpmt]

Justement, je viens de me poser une question à propos du point 
géodésique boule de l'église de mon village, dont je peaufine les 
détails du centre ville.
Le contour du bâtiment église n'existait pas du tout, je l'ai repris 
du cadastre ; mais fallait-il y rattacher le point géodésique ?
Comme je maîtrise mal les relations (pour l'instant) je me suis 
abstenue, et j'ai laissé le point géodésique intact par prudence.

Est-cela que vous attendez des contributeurs de terrain (je veux dire : 
ceux qui font la dentelle à la mimine, et pas d'import massif ?)

à plus,
Hélène PETIT






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

[OSM-talk-fr] Vérification de mon premier upload

[Patrice Vetsel]

http://www.openstreetmap.org/?lat=44.06276lon=4.09531zoom=17

Voici donc mes toutes premières rues visibles sous osmarender pour le 
moment et faites avec josm.

J'ai un doute sur  highway+unclassified, où il est dit que les véhicules 
peuvent se croiser de face. Que mettre lorsque ce n'est pas le cas ? 
(dans quelques rues, faut reculer, trouver un dégagement pour laisser 
passer les voitures).

Merci de vérifier que je n'ai pas fait de bêtises avant que je n'aille 
plus loin :) En attendant je continue à faire des traces :D

Bonne journée

-- 
Patrice Vetsel [EMAIL PROTECTED]
Aka/Alias Kagou
https://launchpad.net/people/vetsel-patrice
gpg key: 0x15c094db


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

Re: [OSM-talk-fr] Vérification de mon premier upload

[Philippe Piquer]

Heu te biles pas pour les unclassified/residential , c'est très flou 
Pour faire simple tout ce qui n'est pas 'classified'
(motorway,trunk,primary,secondary,tertiary) tombe dans unclassified  (il
y a bien sur des exceptions (pedestrians, living_street,...)

si certaines rues sont plus étroites , tu peux toujours l'indiquer avec le
tag 'lanes' en le mettant à 1 (c'est le nombre total de 'voies' de la rue)
mais cela ne changera rien sur la carte (en tout cas pour le moment)

A mon avis c'est bon ...


Le 30 mai 2008 13:59, Patrice Vetsel [EMAIL PROTECTED] a écrit :

 http://www.openstreetmap.org/?lat=44.06276lon=4.09531zoom=17

 Voici donc mes toutes premières rues visibles sous osmarender pour le
 moment et faites avec josm.

 J'ai un doute sur  highway+unclassified, où il est dit que les véhicules
 peuvent se croiser de face. Que mettre lorsque ce n'est pas le cas ?
 (dans quelques rues, faut reculer, trouver un dégagement pour laisser
 passer les voitures).

 Merci de vérifier que je n'ai pas fait de bêtises avant que je n'aille
 plus loin :) En attendant je continue à faire des traces :D

 Bonne journée

 --
 Patrice Vetsel [EMAIL PROTECTED]
 Aka/Alias Kagou
 https://launchpad.net/people/vetsel-patrice
 gpg key: 0x15c094db


 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr