Re: [OSM-talk-fr] L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

2019-11-09 Par sujet osm . sanspourriel 

tu m'as mal compris.
le problème n'est PAS le lieu (talk-fr, wiki, github)
le problème n'est PAS l'idée (le lien utile ou pas)
donc aller manifester à X pour dire "c'est utile"
ne résout pas le problème dont parle TomH dans
sa réponse "cela va faire de la maintenance »

Je comprenais plutôt qu’il ne voulait pas faire un précédent pour
gérer des liens sur des identifiants extérieurs


+1

C'est woodpeck qui avait peur de la maintenance


Il me semblait vraiment que c’était de la pure mauvaise fois (cf. PR
plus bas)

Pas forcément pure mais aussi.

Le retour c’est que c’est dans un projet externe qu’OSM ne maitrise
pas (l'API peut changer, qui édite les données ?…)
Mauvaise foi ou réelle question ?


J'ai eu l'occasion de dire qu'au pire le cache ne serait plus mis à jour.

Donc ce ne serait pas complètement cassé.


Il y a quelqu’un qui en a fait une, mais ça ne bouge pas !!


url ?

Display a link for wikimedia_commons keys #2277


Le ticket d’incident ne datait que du 25 juin 2019, mais comme le
rappel Bibi59 , la PR datait du 15 Nov 2014.

56 pas 59^^.

Ça a finalement bougé, mais l’accouchement s’est fait aux forceps et
sans péridurale.


À la décharge de TomH il dit être passé à côté de ce PR.

Là j'ai du mal à comprendre la gestion du projet, au bout d'un temps
fini on regarde les PR ouverts non ?

Peut-être qu'il est de bonne foi, disons que la lecture des différentes
réactions n'incitent pas à cette lecture.

Quand il parle de non-sense sur les demandes d'Yves avoir des liens
quand les valeurs sont des références (ici vers une image), j'avoue que
les bras m'en tombent.

J'ai dit et je maintiens que le gros du boulot c'était de savoir passer
d'une référence à un lien et ça c'est ce que fait la requête d'Yves.

Que Tom ne souhaite pas faire ce bout de code est parfaitement entendable.
Mais quand on voit un PR qui reste trainer 5 ans et qui fini par passer
parce que 3 personnes au moins (l'auteur, Yves et moi) poussons il faut
bien mesurer les conséquences.

Et une conséquence c'est la moindre envie des quidams d'essayer de
proposer des PR.

Jean-Yvon

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

Re: [OSM-talk-fr] L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

2019-11-09 Par sujet Yves P. 
> tu m'as mal compris.
> le problème n'est PAS le lieu (talk-fr, wiki, github)
> le problème n'est PAS l'idée (le lien utile ou pas)
> donc aller manifester à X pour dire "c'est utile"
> ne résout pas le problème dont parle TomH dans
> sa réponse "cela va faire de la maintenance »
Je comprenais plutôt qu’il ne voulait pas faire un précédent pour gérer des 
liens sur des identifiants extérieurs
Est-ce un problème de traduction, un point de vue biaisé (de ma part)… ?

Il me semblait vraiment que c’était de la pure mauvaise fois (cf. PR plus bas)

> sous entendu : TomH ne veux pas s'en occuper et il est bénévole.
Je pensais qu’il était salarié de la fondation OSM.

> c'est cela qu'il faut résoudre pour avancer.
Je veux bien écrire des snipets, des bibliothèques de code, recenser 
l’existant, écrire des PR…
Mais il y a la question de la (sa) mauvaise foi (cf. plus bas).

>> Tu parles de créer un tableau dans le wiki qui permettrait 
>> (automatiquement ou manuellement) aux dev de créer ces liens dans le 
>> site web d’OSM ?
> 
> la (ta?) requête remplace utilement la page wiki qui listerait
> tous les liens.
C’est bien « ma » requête 

Avec l’aide de Bibi56, on en a parlé à Tom et al. sur GitHub : possible 
solution mentioned in #2405 

Le retour c’est que c’est dans un projet externe qu’OSM ne maitrise pas (l'API 
peut changer, qui édite les données ?…)
Mauvaise foi ou réelle question ?

> ce qui manque c'est le "sans maintenance" : un script qui produit
> le code "osm.org" nécessaire pour faire ces liens.
> ainsi quelqu'un exécute le script, fait un PR quand il y a une modif,
> et le problème de "cela va faire trop de maintenance" est résolu.
> ou un bout de code qui sait lire le résultat de la requête.
On est bien d’accord et ce n’est pas trop difficile à écrire 

L’intérêt que je vois à faire ça dans wikidata c’est qu’on peut « documenter » 
chaque propriété.
Le projet est mûr, carré, facilement lisible par une machine et par un humain.
Pas besoin non plus de maitriser GitHub et la « dialecte » wiki.

Mais effectivement un simple fichier JSON ou CSV peut faire l’affaire.
Et les administrateurs OSM pourront garder le contrôle si c’est hébergé dans le 
compte GitHub de la foundation.

>> Il y a quelqu’un qui en a fait une, mais ça ne bouge pas !!
> 
> url ?
Display a link for wikimedia_commons keys #2277 

Le ticket d’incident ne datait que du 25 juin 2019, mais comme le rappel Bibi59 
, la PR datait du 15 Nov 2014.
Ça a finalement bougé, mais l’accouchement s’est fait aux forceps et sans 
péridurale.

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

Re: [OSM-talk-fr] L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

2019-11-09 Par sujet marc marc 
Le 07.11.19 à 14:03, Yves P. a écrit :
>> je sais pas s'il est nécessaire d'aller remplir des lignes sur le wiki.
> Si *tous* les *lecteurs* de cette liste (et *tous* les *contributeurs* 
> d’OSM) maitrise GitHub, ça ne sert à rien

tu m'as mal compris.
le problème n'est PAS le lieu (talk-fr, wiki, github)
le problème n'est PAS l'idée (le lien utile ou pas)
donc aller manifester à X pour dire "c'est utile"
ne résout pas le problème dont parle TomH dans
sa réponse "cela va faire de la maintenance"
sous entendu : TomH ne veux pas s'en occuper et il est bénévole.
c'est cela qu'il faut résoudre pour avancer.

>> à cause de la maintenance
>> (rajouter et/ou modifier la table de correspondance id <> url).
>> surtout que chaque id est à ajouter dans osm.org  josm etc
> Je ne suis pas sûr de comprendre ?
> 
> Tu parles de créer un tableau dans le wiki qui permettrait 
> (automatiquement ou manuellement) aux dev de créer ces liens dans le 
> site web d’OSM ?

la (ta?) requête remplace utilement la page wiki qui listerait
tous les liens.
ce qui manque c'est le "sans maintenance" : un script qui produit
le code "osm.org" nécessaire pour faire ces liens.
ainsi quelqu'un exécute le script, fait un PR quand il y a une modif,
et le problème de "cela va faire trop de maintenance" est résolu.
ou un bout de code qui sait lire le résultat de la requête.

>> le plus utile est d'en discuter, de faire un PR
> Sur cette liste ?

le lieux importe peu. si quelqu'un poste la solution ici parce
qu'il n'a pas de compte github, copier/coller la solution sur github 
n'est pas rébarbatif :)

> Il y a quelqu’un qui en a fait une, mais ça ne bouge pas !!

url ?

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

Re: [OSM-talk-fr] L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

2019-11-07 Par sujet Yves P. 
Le 19-11-07 à 07 h 26, marc marc a écrit :
> lPic4review montre bien qu'il n'y a pas besoin de codé en dur l'image,
> on peux la récupérer quand on a besoin, sans besoin de maintenance

Pour info, il existe WikiShootMe!  qui 
permet récupérer des images et articles géolocalisés

Il est utilisé ainsi par le code javascript de la carte historic.place 
 :
'https://tools.wmflabs.org/wikishootme/#lat=' + data.lat + '='+ data.lon + 
'=16=commons,flickr,mixnmatch,wikidata_image,wikidata_no_image,wikipedia';

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

Re: [OSM-talk-fr] L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

2019-11-07 Par sujet osm . sanspourriel 

Le 07/11/2019 à 14:00, marc marc - marc_marc_...@hotmail.com a écrit :


Une fois que j'ai sélectionné la meilleur image pour un passage piéton,
j'ajoute les infos d'accessibilité du passage piéton dans osm.
Retrouver la meilleur image n'est plus utile vu que j'en ai extrait
les infos.

Outre le cas mentionné, tu peux vouloir utiliser l'image pour une raison
et un autre pour une autre ou pour vérifier parce qu'un attribut te
titille. Mettons pour voir s'il y a un appel piéton.

Le 07/11/2019 à 16:28, JB - jb...@mailoo.org a écrit :

Je suis convaincu que toutes ces clefs externes sont du genre à
rebuter un nouvel entrant qui, ne sachant pas ce qu'elles veulent
dire, préfèreront ne rien toucher que de risquer de tout casser…


Effectivement il vaut mieux qu'ils évitent de toucher aux clés s'ils n'y
comprennent rien^^.

Que ce soit sur JOSM ou iD il y a des assistants (preset) pour enrichir
sans connaître les attributs.

Mais tu n'as pas complètement tort. Si on a sur openstreetmap.org des
liens qui utilisent ces références, c'est plus parlant.

Yves, je dis ça, je ne dis rien^^.


(Apparemment, en 2019, on n'arrive toujours pas à croiser les
contrôles techniques issus d'OSM avec une base externe sans utiliser
un identifiant unique ? La clef unique est vraiment la solution de
facilité…)


La clé unique c'est la solution fiable.

Si _toutes_ les données de _toutes_ les bases de données étaient
correctes _et_ complètes, tu pourrais faire fiablement sans mais avec un
fort surcout de calcul.

Prenons l'identifiant des stations services en France.

Ça permet à Adrien P. d'afficher les infos à la bonne position dans
OpenFuel.
Ça permet à Fred de proposer les attributs plus détaillés dans Osmose.
Ça permet aussi de remonter au fournisseur de données des positions
incorrectes.

Chaque base de donnée a ses points forts, avec les identifiants on peut
consolider les infos.

Par exemple de prendre les positions dans OSM et les prix sur le site
gouvernemental.

Version brute : le Carrefour Market de Vire est mal positionné
,
confondu avec le Carrefour Contact de Vire
.

Version consolidée : sur OpenFuel le Carrefour Market de Vire est bien
positionné  (au nord de la
carte).

Mais bon, si tu arrives à faire comprendre à la CPAM qui tu es sans
donner ton numéro INSEE...

Le 07/11/2019 à 16:14, Adrien André via Talk-fr -
talk-fr@openstreetmap.org a écrit :

source=mapillary + source:date=20191107 ne suffit-il pas ?


Tu proposes de mettre plus d'infos, je vois mal le gain (hormis créer
moins de clés... en codant des clés dans des valeurs). Le lien que tu as
donné ne marche pas. Mais dans ce cas regarde plutôt du côté du greffon
OpenSwitchMaps.

Et si tu utilisais Mapillary tu saurais qu'il y a pas mal de déchets,
trouver /la/ bonne photo n'est pas évident (Cf. la remarque à propos de GM).


Si on tient à stocker des informations de lien, alors la place de ces
informations ne serait-elle pas plutôt ailleurs ?


On peut considérer que c'est de la méta donnée, donc à mettre au niveau
des changeset. Sauf que l'on a vu que l'info ne sert pas qu'à ça et
qu'elle est à la modification d'un objet pas d'un ensemble de
modifications. Techniquement ton système tient la route mais ne fait que
cacher la donnée (plus la maintenance des liens, voir plus loin).

Voir rapidement que le panneau "90" vient d'une photo de 2019 et non
d'une photo de 2016 permet de savoir si ça vaut le coup de vérifier la
donnée.

Le 07/11/2019 à 16:14, Adrien André via Talk-fr -
talk-fr@openstreetmap.org a écrit :

Les informations sémantiques sur les éléments restent ainsi séparées
de la donnée technique de lien. (...)


Voir ce point

sur le GitHub d'openstreetmap.org ;-).

Sur le principe OK mais dans la pratique c'est déjà fait par Wikidata.

Jean-Yvon

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

Re: [OSM-talk-fr] L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

2019-11-07 Par sujet JB 

Merci, Adrien, pour ce message… Je me sens moins seul.
Je suis convaincu que toutes ces clefs externes sont du genre à rebuter 
un nouvel entrant qui, ne sachant pas ce qu'elles veulent dire, 
préfèreront ne rien toucher que de risquer de tout casser…

JB.

(Apparemment, en 2019, on n'arrive toujours pas à croiser les contrôles 
techniques issus d'OSM avec une base externe sans utiliser un 
identifiant unique ? La clef unique est vraiment la solution de facilité…)


Le 07/11/2019 à 16:14, Adrien André via Talk-fr a écrit :

Le 19-11-07 à 07 h 26, marc marc a écrit :

l'autre "piste" c'est de se demander de l'utilité de la clef mapillary
on y encode la meilleur image dispo au moment de l'encodage.
et puis ?
Pic4review montre bien qu'il n'y a pas besoin de codé en dur l'image,
on peux la récupérer quand on a besoin, sans besoin de maintenance


J'ai toujours eu du mal avec cette tendance des attributs d'OSM à 
devenir le réceptacle des identifiants de toutes les bases externes 
existantes.


Je ne suis pas utilisateur de mapillary, et je me demande ce qui le 
différencie tant des sources habituelles.

Tout comme source=Bing + source:date=20191107,
source=mapillary + source:date=20191107 ne suffit-il pas ?
Pour aller plus loin, et afficher des photos dans une interface, je 
chercherais du coté de

https://www.mapillary.com#gimme=pics=1.234=5.678=20191107

Si on tient à stocker des informations de lien, alors la place de ces 
informations ne serait-elle pas plutôt ailleurs ?
Par exemple, dans des tables (OSM ou base satellite) à part. Tables 
qui pourraient ressembler au brouillon suivant :


type | id| version | database | key
 | - | --- |  | ---
relation | 65606 | 289 | wikidata | Q84
 |   | |  |


database | url  | url_pattern
 |  | 

wikidata | https://www.wikidata.org | 
https://www.wikidata.org/entity/{key}

 |  |

Ceci pouvant également servir à des systèmes spécifiques pour lier 
leurs données avec celles d'OSM.


Les informations sémantiques sur les éléments restent ainsi séparées 
de la donnée technique de lien.
Les interfaces utilisant OSM peuvent s'en servir pour afficher les 
données de bases externes (photos, extraits d'articles, etc).

Et je présume que la maintenance d'openstreetmap.org en serait allégée.





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

Re: [OSM-talk-fr] L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

2019-11-07 Par sujet Adrien André via Talk-fr 

Le 19-11-07 à 07 h 26, marc marc a écrit :

l'autre "piste" c'est de se demander de l'utilité de la clef mapillary
on y encode la meilleur image dispo au moment de l'encodage.
et puis ?
Pic4review montre bien qu'il n'y a pas besoin de codé en dur l'image,
on peux la récupérer quand on a besoin, sans besoin de maintenance


J'ai toujours eu du mal avec cette tendance des attributs d'OSM à 
devenir le réceptacle des identifiants de toutes les bases externes 
existantes.


Je ne suis pas utilisateur de mapillary, et je me demande ce qui le 
différencie tant des sources habituelles.

Tout comme source=Bing + source:date=20191107,
source=mapillary + source:date=20191107 ne suffit-il pas ?
Pour aller plus loin, et afficher des photos dans une interface, je 
chercherais du coté de

https://www.mapillary.com#gimme=pics=1.234=5.678=20191107

Si on tient à stocker des informations de lien, alors la place de ces 
informations ne serait-elle pas plutôt ailleurs ?
Par exemple, dans des tables (OSM ou base satellite) à part. Tables qui 
pourraient ressembler au brouillon suivant :


type | id    | version | database | key
 | - | --- |  | ---
relation | 65606 | 289 | wikidata | Q84
 |   | |  |


database | url  | url_pattern
 |  | 
wikidata | https://www.wikidata.org | https://www.wikidata.org/entity/{key}
 |  |

Ceci pouvant également servir à des systèmes spécifiques pour lier leurs 
données avec celles d'OSM.


Les informations sémantiques sur les éléments restent ainsi séparées de 
la donnée technique de lien.
Les interfaces utilisant OSM peuvent s'en servir pour afficher les 
données de bases externes (photos, extraits d'articles, etc).

Et je présume que la maintenance d'openstreetmap.org en serait allégée.

--
Adrien



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

Re: [OSM-talk-fr] L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

2019-11-07 Par sujet Phyks 

Donc qui/pq a-t-on besoin de la clef mapillary dans osm ?
à part pour entraîner une IA, je ne saisis pas quel réutilisation
les contributeur en font, hormis si quelqu'un se passionne par faire
les "match mapillary" et laisse le soin à un autre contributeur
d'ajouter les autres tag osm.


Je m'en suis servi récemment pour argumenter avec une collectivité 
(Montrouge) sur la nécessité d'avoir des données ouvertes et sur la 
qualité des données (stationnements vélos). OSM avait des données bien 
plus complètes que celles que la collectivité a bien voulu nous fournir. 
Face à la méfiance de la mairie envers OSM, je leur ai envoyé un tableau 
(requête Overpass exportée en CSV, avec quelques retouches) des 
stationnements vélos connus d'OSM à Montrouge.


Comme la plupart des stationnements vélos à Montrouge avait une clé 
Mapillary, il leur suffisait de cliquer dans le champ "Image" pour voir 
l'aperçu du parking en direct. C'était, je pense, plutôt convaincant sur 
la qualité des données, même s'il n'y a malheureusement pas 
particulièrement eu de suite...



Le 07.11.19 à 13:49, PanierAvide a écrit :
Pic4Review propose aussi de mettre en avant l'image désignée par la 
clé

mapillary=*, et de changer l'image si une autre est plus
récente/pertinente. Lier explicitement une image à un objet a du sens 
en

terme de réutilisation : plutôt que d'afficher 10 images moches et mal
cadrées, un humain a précisé que cette image est pertinente. Donc 
plutôt

pour l'utilisation de ce tag, et adapter nos outils pour que la donnée
reste à jour.

Adrien P.

Le 07/11/2019 à 13:43, Cyrille37 OSM via Talk-fr a écrit :

Le 07/11/2019 à 13:26, marc marc a écrit :
l'autre "piste" c'est de se demander de l'utilité de la clef 
mapillary

on y encode la meilleur image dispo au moment de l'encodage.
et puis ? demain quelqu'un recapture l'objet, plus à jour ou en 
meilleur

qualité, quelqu'un ou un outil va maintenir cette info à jour ?
quelqu'un cible les objets dans osm ayant la clef mapillary mais 
n'ayant
pas certains clefs (ex typique : l'accessibilité des passages 
piétons).
Pic4review montre bien qu'il n'y a pas besoin de codé en dur 
l'image,

on peux la récupérer quand on a besoin, sans besoin de maintenance


Je partage cet avis.

Cyrille37.


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


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


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


--
Phyks

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

Re: [OSM-talk-fr] L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

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

Le 07/11/2019 à 14:00, marc marc a écrit :

Cela me plairait de lire s'il y a d'autres utilisations de cette clef.


Lorsque tu fais des vérifications, et qu'il y a cette clé, c'est 
pratique car retrouver la bonne photo n'est pas toujours évident 
(mauvaise géoloc, nbr de photo très important, etc..)


Ensuite, une fois que tu as cette photo, tu peux encore filtrer les 
photos du même lieu en utilisant la date de la photo de la clé.


Exemple concret : le suivi des aménagements cyclables, qui évoluent très 
vite dans certaines zones.


Stf


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

Re: [OSM-talk-fr] L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

2019-11-07 Par sujet Yves P. 
@marc
> Bien sur que les outils doivent s'adapter mais pour en faire quoi ?
> Une fois que j'ai sélectionné la meilleur image pour un passage piéton,
> j'ajoute les infos d'accessibilité du passage piéton dans osm.
Oui

> Retrouver la meilleur image n'est plus utile vu que j'en ai extrait
> les infos.
ça sert aussi de source. (Ok, on peut mettre source:mapillary ?)
ça sert à vérifier la qualité de la contribution.

Pour une plaque d’un mémorial, l’inscription n’est souvent pas retranscrite 
complètement.
La photo (mapillary) peut servir à ça…
Rue d’Arménie 


> Donc qui/pq a-t-on besoin de la clef mapillary dans osm ?
> La seule utilité post-contribution que je vois c'est pour les poi,
> Mais sur un passage piéton, il n'y a pas ce besoin, si ?
> 
> Cela me plairait de lire s'il y a d'autres utilisations de cette clef.
J’utilise beaucoup la carte des objets historiques.

C’est intéressant (et aussi important) d’avoir une photo.
Il n’y en a pas toujours sur wiki* et une photo mapillary c’est bien (même mal 
cadrée).

Tient, grâce à cette carte 

 et à Benoît Prieur, j’ai découvert ce que c’est qu’un khatchkar 


Un exemple — quand même — avec une photo mapillary : Widening of Bath Street 
1906 


@Cyrille
> Elle préférait les photos de toitures, il préférait les passages piétons, ils 
> créèrent de nombreuses clé Mapillary.
Bein non, c’est comme la clé image, une seule 

—
Yves

PS: Tient au passage, il n’y a pas (encore ) de clé OpenStreetCam___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

2019-11-07 Par sujet PanierAvide 
C'est plus évident l'intérêt pour les POIs, mais qui sait. Si une 
application pour l'accessibilité souhaite montrer à quoi ressemble le 
passage piéton, on sera content de les avoir à disposition ;-)


Adrien P.

Le 07/11/2019 à 14:00, marc marc a écrit :

Bien sur que les outils doivent s'adapter mais pour en faire quoi ?
Une fois que j'ai sélectionné la meilleur image pour un passage piéton,
j'ajoute les infos d'accessibilité du passage piéton dans osm.
Retrouver la meilleur image n'est plus utile vu que j'en ai extrait
les infos.
Donc qui/pq a-t-on besoin de la clef mapillary dans osm ?
à part pour entraîner une IA, je ne saisis pas quel réutilisation
les contributeur en font, hormis si quelqu'un se passionne par faire
les "match mapillary" et laisse le soin à un autre contributeur
d'ajouter les autres tag osm.

La seule utilité post-contribution que je vois c'est pour les poi,
comme le fait GoogleMap (miniature puis lien direct vers StreetView)
Mais sur un passage piéton, il n'y a pas ce besoin, si ?

Cela me plairait de lire s'il y a d'autres utilisations de cette clef.

Le 07.11.19 à 13:49, PanierAvide a écrit :

Pic4Review propose aussi de mettre en avant l'image désignée par la clé
mapillary=*, et de changer l'image si une autre est plus
récente/pertinente. Lier explicitement une image à un objet a du sens en
terme de réutilisation : plutôt que d'afficher 10 images moches et mal
cadrées, un humain a précisé que cette image est pertinente. Donc plutôt
pour l'utilisation de ce tag, et adapter nos outils pour que la donnée
reste à jour.

Adrien P.

Le 07/11/2019 à 13:43, Cyrille37 OSM via Talk-fr a écrit :

Le 07/11/2019 à 13:26, marc marc a écrit :

l'autre "piste" c'est de se demander de l'utilité de la clef mapillary
on y encode la meilleur image dispo au moment de l'encodage.
et puis ? demain quelqu'un recapture l'objet, plus à jour ou en meilleur
qualité, quelqu'un ou un outil va maintenir cette info à jour ?
quelqu'un cible les objets dans osm ayant la clef mapillary mais n'ayant
pas certains clefs (ex typique : l'accessibilité des passages piétons).
Pic4review montre bien qu'il n'y a pas besoin de codé en dur l'image,
on peux la récupérer quand on a besoin, sans besoin de maintenance

Je partage cet avis.

Cyrille37.


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

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

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


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

Re: [OSM-talk-fr] L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

2019-11-07 Par sujet Yves P. 
> je sais pas s'il est nécessaire d'aller remplir des lignes sur le wiki.
Si tous les lecteurs de cette liste (et tous les contributeurs d’OSM) maitrise 
GitHub, ça ne sert à rien

> un des principaux mainteneur d'osm.org trouve que c'est une mauvaise 
> idée, non pas l'idée en elle-même mais à cause de la maintenance 
> (rajouter et/ou modifier la table de correspondance id <> url).
> surtout que chaque id est à ajouter dans osm.org josm etc
Je ne suis pas sûr de comprendre ?

Tu parles de créer un tableau dans le wiki qui permettrait (automatiquement ou 
manuellement) aux dev de créer ces liens dans le site web d’OSM ?

> Une piste de solution est là :
>> https://github.com/openstreetmap/openstreetmap-website/issues/2405#issuecomment-548917729
Oui, c’est moi qui ai écrit cette requête 

> le plus utile est d'en discuter, de faire un PR
Sur cette liste ?

Pour la PR, vu les commentaires des développeurs ça ne m’encourage pas à le 
faire.
(du style d’un asin sur un pont qui refuse d’avancer ou de reculer )

Il y a quelqu’un qui en a fait une, mais ça ne bouge pas !!

> l'autre "piste" c'est de se demander de l'utilité de la clef mapillary
Oui effectivement.

Mais aussi des clés image, wikimedia_commons, flickr…

> on y encode la meilleur image dispo au moment de l'encodage.
> et puis ? demain quelqu'un recapture l'objet, plus à jour ou en meilleur 
> qualité, quelqu'un ou un outil va maintenir cette info à jour ?
OSM c’est comme un journal, il y a des choix à faire.
On ne peut pas, et on ne veut pas montrer toutes les photos d’un objet (idem 
pour les objets : on ne cartographie pas tout, et on « modélise » la réalité)

> quelqu'un cible les objets dans osm ayant la clef mapillary mais n'ayant 
> pas certains clefs (ex typique : l'accessibilité des passages piétons).
> Pic4review montre bien qu'il n'y a pas besoin de codé en dur l'image,
> on peux la récupérer quand on a besoin, sans besoin de maintenance
il existe actuellement des clés image, mapillary dans la base
et des logiciels et/ou utilisateurs qui s’en servent
regarde les photos d’un lieu sur Google Map : tu vois le blaireau de service 
qui se prend en selfy, son chien, un truc qui n’a rien à voir mais qui était 
photographié le même jour, un truc mal géolocalisé…
pour le moment, le choix « éditorial » reste une bonne option

>> J’ai corrigé 99% des valeurs
> 
> tu parles de ce point ou de tout ?
De mémoire, de tout 

> url du changeset ?
Il y en a plein, j’ai essayé de faire pays par pays… sauf un ou deux loupé.

> fait attention avec les éditions de masse.
oui je me suis fait allumé par un allemand 

> tu ferrais mieux de proposer en premier une modif à l'échelle de la 
> France, ouvrir un ticket josm pour ce qui manque, recevoir des retours
> d'utilisateur en France... avant de vouloir le faire à l'échelle monde
J’ai fait ça à chaud, je pensais bien faire (et oui, l’enfer est pavé…)

Du coup, pour la discussion c’est l’objet de ce mél 

D’un autre coté, un italien content, un allemand qui râle et la majorité qui ne 
s’exprime pas, c’est plutôt positif 

> ouvrir un ticket josm pour ce qui manque, 
?

Cordialement,

—
Yves

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

Re: [OSM-talk-fr] L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

2019-11-07 Par sujet Cyrille37 OSM via Talk-fr 

Le 07/11/2019 à 13:49, PanierAvide a écrit :
Pic4Review propose aussi de mettre en avant l'image désignée par la 
clé mapillary=*, et de changer l'image si une autre est plus 
récente/pertinente. Lier explicitement une image à un objet a du sens 
en terme de réutilisation : plutôt que d'afficher 10 images moches et 
mal cadrées, un humain a précisé que cette image est pertinente. Donc 
plutôt pour l'utilisation de ce tag, et adapter nos outils pour que la 
donnée reste à jour.



Elle préférait les photos de toitures, il préférait les passages 
piétons, ils créèrent de nombreuses clé Mapillary.


;-)

Cyrille37.




Adrien P.

Le 07/11/2019 à 13:43, Cyrille37 OSM via Talk-fr a écrit :

Le 07/11/2019 à 13:26, marc marc a écrit :

l'autre "piste" c'est de se demander de l'utilité de la clef mapillary
on y encode la meilleur image dispo au moment de l'encodage.
et puis ? demain quelqu'un recapture l'objet, plus à jour ou en 
meilleur

qualité, quelqu'un ou un outil va maintenir cette info à jour ?
quelqu'un cible les objets dans osm ayant la clef mapillary mais 
n'ayant

pas certains clefs (ex typique : l'accessibilité des passages piétons).
Pic4review montre bien qu'il n'y a pas besoin de codé en dur l'image,
on peux la récupérer quand on a besoin, sans besoin de maintenance


Je partage cet avis.

Cyrille37.


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


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


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

Re: [OSM-talk-fr] L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

2019-11-07 Par sujet marc marc 
Bien sur que les outils doivent s'adapter mais pour en faire quoi ?
Une fois que j'ai sélectionné la meilleur image pour un passage piéton,
j'ajoute les infos d'accessibilité du passage piéton dans osm.
Retrouver la meilleur image n'est plus utile vu que j'en ai extrait
les infos.
Donc qui/pq a-t-on besoin de la clef mapillary dans osm ?
à part pour entraîner une IA, je ne saisis pas quel réutilisation
les contributeur en font, hormis si quelqu'un se passionne par faire
les "match mapillary" et laisse le soin à un autre contributeur 
d'ajouter les autres tag osm.

La seule utilité post-contribution que je vois c'est pour les poi,
comme le fait GoogleMap (miniature puis lien direct vers StreetView)
Mais sur un passage piéton, il n'y a pas ce besoin, si ?

Cela me plairait de lire s'il y a d'autres utilisations de cette clef.

Le 07.11.19 à 13:49, PanierAvide a écrit :
> Pic4Review propose aussi de mettre en avant l'image désignée par la clé 
> mapillary=*, et de changer l'image si une autre est plus 
> récente/pertinente. Lier explicitement une image à un objet a du sens en 
> terme de réutilisation : plutôt que d'afficher 10 images moches et mal 
> cadrées, un humain a précisé que cette image est pertinente. Donc plutôt 
> pour l'utilisation de ce tag, et adapter nos outils pour que la donnée 
> reste à jour.
> 
> Adrien P.
> 
> Le 07/11/2019 à 13:43, Cyrille37 OSM via Talk-fr a écrit :
>> Le 07/11/2019 à 13:26, marc marc a écrit :
>>> l'autre "piste" c'est de se demander de l'utilité de la clef mapillary
>>> on y encode la meilleur image dispo au moment de l'encodage.
>>> et puis ? demain quelqu'un recapture l'objet, plus à jour ou en meilleur
>>> qualité, quelqu'un ou un outil va maintenir cette info à jour ?
>>> quelqu'un cible les objets dans osm ayant la clef mapillary mais n'ayant
>>> pas certains clefs (ex typique : l'accessibilité des passages piétons).
>>> Pic4review montre bien qu'il n'y a pas besoin de codé en dur l'image,
>>> on peux la récupérer quand on a besoin, sans besoin de maintenance
>>
>> Je partage cet avis.
>>
>> Cyrille37.
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

2019-11-07 Par sujet PanierAvide 
Pic4Review propose aussi de mettre en avant l'image désignée par la clé 
mapillary=*, et de changer l'image si une autre est plus 
récente/pertinente. Lier explicitement une image à un objet a du sens en 
terme de réutilisation : plutôt que d'afficher 10 images moches et mal 
cadrées, un humain a précisé que cette image est pertinente. Donc plutôt 
pour l'utilisation de ce tag, et adapter nos outils pour que la donnée 
reste à jour.


Adrien P.

Le 07/11/2019 à 13:43, Cyrille37 OSM via Talk-fr a écrit :

Le 07/11/2019 à 13:26, marc marc a écrit :

l'autre "piste" c'est de se demander de l'utilité de la clef mapillary
on y encode la meilleur image dispo au moment de l'encodage.
et puis ? demain quelqu'un recapture l'objet, plus à jour ou en meilleur
qualité, quelqu'un ou un outil va maintenir cette info à jour ?
quelqu'un cible les objets dans osm ayant la clef mapillary mais n'ayant
pas certains clefs (ex typique : l'accessibilité des passages piétons).
Pic4review montre bien qu'il n'y a pas besoin de codé en dur l'image,
on peux la récupérer quand on a besoin, sans besoin de maintenance


Je partage cet avis.

Cyrille37.


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


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

Re: [OSM-talk-fr] L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

2019-11-07 Par sujet Cyrille37 OSM via Talk-fr 

Le 07/11/2019 à 13:26, marc marc a écrit :

l'autre "piste" c'est de se demander de l'utilité de la clef mapillary
on y encode la meilleur image dispo au moment de l'encodage.
et puis ? demain quelqu'un recapture l'objet, plus à jour ou en meilleur
qualité, quelqu'un ou un outil va maintenir cette info à jour ?
quelqu'un cible les objets dans osm ayant la clef mapillary mais n'ayant
pas certains clefs (ex typique : l'accessibilité des passages piétons).
Pic4review montre bien qu'il n'y a pas besoin de codé en dur l'image,
on peux la récupérer quand on a besoin, sans besoin de maintenance


Je partage cet avis.

Cyrille37.


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

Re: [OSM-talk-fr] L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

2019-11-07 Par sujet marc marc 
Bonjour,

Le 07.11.19 à 11:48, Yves P. a écrit :
> Il y a aussi le wiki qui permet de s’exprimer (en espérant  
> que les développeurs d’OSM le lisent aussi).

je sais pas s'il est nécessaire d'aller remplir des lignes sur le wiki.
un des principaux mainteneur d'osm.org trouve que c'est une mauvaise 
idée, non pas l'idée en elle-même mais à cause de la maintenance 
(rajouter et/ou modifier la table de correspondance id <> url).
surtout que chaque id est à ajouter dans osm.org josm etc
Une piste de solution est là :
> https://github.com/openstreetmap/openstreetmap-website/issues/2405#issuecomment-548917729
le plus utile est d'en discuter, de faire un PR

l'autre "piste" c'est de se demander de l'utilité de la clef mapillary
on y encode la meilleur image dispo au moment de l'encodage.
et puis ? demain quelqu'un recapture l'objet, plus à jour ou en meilleur 
qualité, quelqu'un ou un outil va maintenir cette info à jour ?
quelqu'un cible les objets dans osm ayant la clef mapillary mais n'ayant 
pas certains clefs (ex typique : l'accessibilité des passages piétons).
Pic4review montre bien qu'il n'y a pas besoin de codé en dur l'image,
on peux la récupérer quand on a besoin, sans besoin de maintenance

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

Re: [OSM-talk-fr] L’enfer est pavé de bonnes intentions

2019-11-07 Par sujet Yves P. 
> Décryptage du message d'Yves :
> 
> Pensez à dire ce que vous pensez des tickets style :
> https://github.com/openstreetmap/openstreetmap-website/issues/986 
> 
> https://github.com/openstreetmap/openstreetmap-website/issues/2405 
> C’est ça

Par contre tous les lecteurs de cette liste n’ont pas un compte GitHub…

Il y a aussi le wiki qui permet de s’exprimer (en espérant que les développeurs 
d’OSM le lisent aussi).
https://wiki.openstreetmap.org/wiki/Talk:Key:wikimedia_commons#Support_on_the_OSM_website

Ce qui interroge, c’est que les tags wikidata et wikipedia ont un lien, mais 
pas wikimedia_commons (de la même fondation et avec la même syntaxe) ?
https://www.openstreetmap.org/way/62280106

Je vous invite aussi à donner votre avis à propos de la syntaxe du tag 
wikimedia_commons qui permet de spécifier un fichier ET une catégorie :
https://wiki.openstreetmap.org/wiki/Talk:Key:wikimedia_commons#Why_Category%3A.23.2Fmedia.2FFile%3A_syntax_is_Controversial_.3F

Comme l’a rappelé notre colibri du jour, il y a aussi les clés suivantes qui 
mériteraient d’être affichées correctement par le site web d’OSM :
openplaques:id  
openstreetmap-website#2405 

mapillary  
openstreetmap-website#986 


Cette liste n’est pas exhaustive : n’hésitez pas à en proposer d’autres 
> Ou mieux si vous pouvez proposez un PR !
> 


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

Re: [OSM-talk-fr] L’enfer est pavé de bonnes intentions

2019-11-06 Par sujet osm . sanspourriel 

Décryptage du message d'Yves :

Pensez à dire ce que vous pensez des tickets style :
https://github.com/openstreetmap/openstreetmap-website/issues/986
https://github.com/openstreetmap/openstreetmap-website/issues/2405

Ou mieux si vous pouvez proposez un PR !

Jean-Yvon, colibri du jour ;-)

Le 06/11/2019 à 14:05, Yves P. - yves.prat...@gmail.com a écrit :

Bonjour,

Da ma série nettoyage (d’automne) j’ai trouvé des clés redondantes
mapillary et image.

Par exemple : https://www.openstreetmap.org/way/739027745

  * image=https://images.mapillary.com/4mayqgUw7QEHXjeTAXT5nw/thumb-2048.jpg
  * mapillary=https://www.mapillary.com/map/im/4mayqgUw7QEHXjeTAXT5nw

Comme certains logiciels dont openstreetmap.org
 ne gèrent pas les clés mapillary, le
contributeur OSM utilise l’URL complète au lieu de
4mayqgUw7QEHXjeTAXT5nw

De la même façon, ce contributeur « duplique » l’info dans la clé
image pour qu’elle soit affichée, et du coup, avec une URL complète et
compliquée.

Cela donne un gros bazar dans la clé image (idem pour mapillary,
wikipedia, wikimedia_commons…).

Un résumé, cette pratique consiste à taguer pour le rendu.
La solution, c’est que les développeurs du site web openstreetmap.org
 gèrent enfin les clés externes.
Les autres sites suivront…

—
Yves

Pour info, le développeur d’Overpass-Turbo est très réactif et gère
correctement les clés mapillary ,
wikimedia_commons et wikipedia .
Les clés image contenant des fichiers wikimedia ne sont pas
supportées. Exemple :

  * https://overpass-turbo.eu/s/NKu
  * image=File:Hemiksem_Abdij_Luchtfoto.jpg


Exemples de bazar :

  * clés image avec des valeurs « wiki » : elles ne sont pas affichées
par la plupart des applications

  o image=File:Hemiksem_Abdij_Luchtfoto.jpg
wikimedia_commons=File:Hemiksem_Abdij_Luchtfoto.jpg


Note : *20 825 *images*

*
  o image=Datei:Stolperstein Warendorf Warendorfer-Straße 59 Alma
Leffmann.jpg
wikimedia_commons=File:Stolperstein Warendorf
Warendorfer-Straße 59 Alma Leffmann.jpg



Note : *Datei* est un préfixe valide uniquement sur
wikipedia.de 

  o image=Category:Chapel of Holy Trinity (Ivančice)
wikimedia_commons =Category:Chapel of Holy Trinity (Ivančice)



Note : plusieurs images ! La clé image sert justement à en
spécifier une seule

  o 
image=Category:Zur_Waldesruh_24_(Wuppertal)#/media/File:Wuppertal_Zur_Waldesruh_0003.jpg
wikimedia_commons=Category:Zur Waldesruh 24
(Wuppertal)#/media/File:Wuppertal Zur Waldesruh 0003.jpg



Note : cette syntaxe (peu documentée) permet d’indiquer une
photo et une catégorie 

  o 
image=File:%22Grand_H%C3%B4tel_du_Commerce%22_of_%22Grand_H%C3%B4tel%22,_heden_%22Hotel_Navarra%22_-_Sint-Jakobsstraat_41_-_Brugge_-_29674.JPG
wikimedia_commons=File:"Grand Hôtel du Commerce" of "Grand
Hôtel", heden "Hotel Navarra" - Sint-Jakobsstraat 41 - Brugge
- 29674.JPG


  * clés image avec URL complète qui pourraient être raccourcies dans
des clés plus adaptées

  o image=https://images.mapillary.com/4mayqgUw7QEHXjeTAXT5nw/thumb-2048.jpg
mapillary=4mayqgUw7QEHXjeTAXT5nw


  o image=http://mapillary.com/map/im/-5B7enGgaEQ5BBltYpmidw
mapillary=-5B7enGgaEQ5BBltYpmidw


  o image=https://www.mapillary.com/map/im/rkAum6ieaIsLPyzxWvSLyQ
mapillary=rkAum6ieaIsLPyzxWvSLyQ


Note: *17 184* images pour ces 3 derniers cas

  o image=http://commons.wikimedia.org/wiki/File:Fort_van_Haasdonk.jpg

wikimedia_commons=File:Fort_van_Haasdonk.jpg


Note : *42 596 *images (http + https)

  o 
image=https://upload.wikimedia.org/wikipedia/commons/0/0c/Antony_Gormley%2C_Pirmavent_III%2C_2009.jpg


wikimedia_commons=File:Antony Gormley, Pirmavent III, 

[OSM-talk-fr] L’enfer est pavé de bonnes intentions

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

Da ma série nettoyage (d’automne) j’ai trouvé des clés redondantes mapillary et 
image.

Par exemple : https://www.openstreetmap.org/way/739027745
image=https://images.mapillary.com/4mayqgUw7QEHXjeTAXT5nw/thumb-2048.jpg 

mapillary=https://www.mapillary.com/map/im/4mayqgUw7QEHXjeTAXT5nw 

Comme certains logiciels dont openstreetmap.org ne gèrent pas les clés 
mapillary, le contributeur OSM utilise l’URL complète au lieu de 
4mayqgUw7QEHXjeTAXT5nw 
De la même façon, ce contributeur « duplique » l’info dans la clé image pour 
qu’elle soit affichée, et du coup, avec une URL complète et compliquée.

Cela donne un gros bazar dans la clé image (idem pour mapillary, wikipedia, 
wikimedia_commons…).

Un résumé, cette pratique consiste à taguer pour le rendu.
La solution, c’est que les développeurs du site web openstreetmap.org gèrent 
enfin les clés externes.
Les autres sites suivront…

—
Yves

Pour info, le développeur d’Overpass-Turbo est très réactif et gère 
correctement les clés mapillary , 
wikimedia_commons et wikipedia .
Les clés image contenant des fichiers wikimedia ne sont pas supportées. Exemple 
:
https://overpass-turbo.eu/s/NKu
image=File:Hemiksem_Abdij_Luchtfoto.jpg

Exemples de bazar :

clés image avec des valeurs « wiki » : elles ne sont pas affichées par la 
plupart des applications

image=File:Hemiksem_Abdij_Luchtfoto.jpg
wikimedia_commons=File:Hemiksem_Abdij_Luchtfoto.jpg 


Note : 20 825 images 

image=Datei:Stolperstein Warendorf Warendorfer-Straße 59 Alma Leffmann.jpg
wikimedia_commons=File:Stolperstein Warendorf Warendorfer-Straße 59 Alma 
Leffmann.jpg 


Note : Datei est un préfixe valide uniquement sur wikipedia.de

image=Category:Chapel of Holy Trinity (Ivančice)
wikimedia_commons =Category:Chapel of Holy Trinity (Ivančice) 


Note : plusieurs images ! La clé image sert justement à en spécifier une seule

image=Category:Zur_Waldesruh_24_(Wuppertal)#/media/File:Wuppertal_Zur_Waldesruh_0003.jpg
wikimedia_commons=Category:Zur Waldesruh 24 (Wuppertal)#/media/File:Wuppertal 
Zur Waldesruh 0003.jpg 


Note : cette syntaxe (peu documentée) permet d’indiquer une photo et une 
catégorie 

image=File:%22Grand_H%C3%B4tel_du_Commerce%22_of_%22Grand_H%C3%B4tel%22,_heden_%22Hotel_Navarra%22_-_Sint-Jakobsstraat_41_-_Brugge_-_29674.JPG
wikimedia_commons=File:"Grand Hôtel du Commerce" of "Grand Hôtel", heden "Hotel 
Navarra" - Sint-Jakobsstraat 41 - Brugge - 29674.JPG
 

clés image avec URL complète qui pourraient être raccourcies dans des clés plus 
adaptées

image=https://images.mapillary.com/4mayqgUw7QEHXjeTAXT5nw/thumb-2048.jpg 

mapillary=4mayqgUw7QEHXjeTAXT5nw 


image=http://mapillary.com/map/im/-5B7enGgaEQ5BBltYpmidw 

mapillary=-5B7enGgaEQ5BBltYpmidw 


image=https://www.mapillary.com/map/im/rkAum6ieaIsLPyzxWvSLyQ 

mapillary=rkAum6ieaIsLPyzxWvSLyQ 


Note: 17 184 images pour ces 3 derniers cas

image=http://commons.wikimedia.org/wiki/File:Fort_van_Haasdonk.jpg 
 
wikimedia_commons=File:Fort_van_Haasdonk.jpg 


Note : 42 596 images (http + https)

image=https://upload.wikimedia.org/wikipedia/commons/0/0c/Antony_Gormley%2C_Pirmavent_III%2C_2009.jpg
 

wikimedia_commons=File:Antony Gormley, Pirmavent III, 2009.jpg 


image=https://upload.wikimedia.org/wikipedia/commons/thumb/7/72/AlgeriePoste.svg/130px-AlgeriePoste.svg.png
 

wikimedia_commons=File:AlgeriePoste.svg 


Note : 10 932 images (http + https) pour