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

[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 (clef mapillary id<>url)

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

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

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

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

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

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

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

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

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

[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&lon=1.234&lat=5.678&date=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)

[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&lon=1.234&lat=5.678&date=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)

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

[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 + '&lng='+ data.lon + 
'&zoom=16&layers=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)

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

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

[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