L’enfer est pavé de bonnes intentions

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

L’enfer est pavé de bonnes intentions

pyrog
Bonjour,

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

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 mapillarywikimedia_commons et wikipedia.
Les clés image contenant des fichiers wikimedia ne sont pas supportées. Exemple :

Exemples de bazar :


Soit  70% des clés image qui pourraient être nettoyées !! (91 537 sur 130 127)

  • clés wikimedia_commons encodées :

    • wikimedia_commons=File:Sept%26Box-Tete_enfant.jpg
      wikimedia_commons=File:Sept&Box-Tete enfant.jpg

      Note : depuis JOSM/Tag2Link commons affiche Mauvais titre : Le titre de la page demandée contient des caractères non valides : « %26 ».
      Ça marche depuis Safari en copiant l’adresse.

  • clés wikimedia_commons avec des espaces remplacés par des soulignés :

    • wikimedia_commons=File:Cementerio_de_Pilar.jpg
      wikimedia_commons=File:Cementerio de Pilar.jpg

      PS: Le validateur de données de JOSM ne les affichent et ne les corrigent pas (mais il le fait pour wikipedia)

J’ai corrigé 99% des valeurs, avec deux commentaires dans mes changesets (1 italien ravi, 1 allemand qui râle : mais où est passé l’entente franco-allemande ? 😁)

  • mapillary (cf. mél précédent sur le nettoyage de ces clés)

  • contact:website

    • contenant des url d’images,
    • des URLs sans préfixe http, 
    • des numéros de téléphone
    • des URLs bizarres (contenant « », « : », « httpwww.cukrarstvimatuska.cz »…)

  • description

    • contenant des url d’images…

Liste NON EXAUSTIVE 😉

PS: pour retrouver dans wikimedia commons une photo issue de Flickr, c’est simple :
rechercher dans le code source de l’image son lien sur Flickr : insource: https://www.flickr.com/photos/65001151@N03/22181878549

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: L’enfer est pavé de bonnes intentions

Bibi

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. - [hidden email] a écrit :
Bonjour,

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

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 mapillarywikimedia_commons et wikipedia.
Les clés image contenant des fichiers wikimedia ne sont pas supportées. Exemple :

Exemples de bazar :


Soit  70% des clés image qui pourraient être nettoyées !! (91 537 sur 130 127)

  • clés wikimedia_commons encodées :

  • clés wikimedia_commons avec des espaces remplacés par des soulignés :

J’ai corrigé 99% des valeurs, avec deux commentaires dans mes changesets (1 italien ravi, 1 allemand qui râle : mais où est passé l’entente franco-allemande ? 😁)

  • mapillary (cf. mél précédent sur le nettoyage de ces clés)

  • contact:website

    • contenant des url d’images,
    • des URLs sans préfixe http, 
    • des numéros de téléphone
    • des URLs bizarres (contenant « », « : », « httpwww.cukrarstvimatuska.cz »…)

  • description

    • contenant des url d’images…

Liste NON EXAUSTIVE 😉

PS: pour retrouver dans wikimedia commons une photo issue de Flickr, c’est simple :
rechercher dans le code source de l’image son lien sur Flickr : insource: https://www.flickr.com/photos/65001151@N03/22181878549

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: L’enfer est pavé de bonnes intentions

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

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

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 :

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 :

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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

France mailing list
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

PanierAvide-2
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
> [hidden email]
> https://lists.openstreetmap.org/listinfo/talk-fr

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: 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
>> [hidden email]
>> https://lists.openstreetmap.org/listinfo/talk-fr
>
> _______________________________________________
> Talk-fr mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/talk-fr

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

France mailing list
In reply to this post by PanierAvide-2
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
>> [hidden email]
>> https://lists.openstreetmap.org/listinfo/talk-fr
>
> _______________________________________________
> Talk-fr mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/talk-fr

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

pyrog
In reply to this post by marc marc
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 ?

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
  1. il existe actuellement des clés image, mapillary dans la base
    et des logiciels et/ou utilisateurs qui s’en servent
  2. 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

PanierAvide-2
In reply to this post by marc marc
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
>>> [hidden email]
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>> _______________________________________________
>> Talk-fr mailing list
>> [hidden email]
>> https://lists.openstreetmap.org/listinfo/talk-fr
> _______________________________________________
> Talk-fr mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/talk-fr

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

pyrog
In reply to this post by marc 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.
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…

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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

StephaneP
In reply to this post by marc marc
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

Phyks
In reply to this post by marc marc
> 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
>>> [hidden email]
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>> _______________________________________________
>> Talk-fr mailing list
>> [hidden email]
>> https://lists.openstreetmap.org/listinfo/talk-fr
>
> _______________________________________________
> Talk-fr mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/talk-fr

--
Phyks

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

France mailing list
In reply to this post by marc marc
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

jbosm
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

Bibi
In reply to this post by marc marc

Le 07/11/2019 à 14:00, marc marc - [hidden email] 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 - [hidden email] 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 - [hidden email] 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 - [hidden email] 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

pyrog
In reply to this post by jbosm
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

marc marc
In reply to this post by pyrog
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 <http://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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

pyrog
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

Bibi
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr