Re: [OSM-talk-fr] Photos — Re: Projet du mois de septembre (en préparation) : défibrillateurs !

2020-08-15 Par sujet Philippe Verdy 
Noter quand même que le téléchargement en torrent d'un fichier Planet de
~53 Go prend pas loin 7 heures même en fibre. Dont au moins 2 heures en
session "stalled". La raison est un démarrage très lent (lié au fait qu'il
y a une préallocation initiale de 53 Go qui peut imposer de bloquer l'appli
pendant plus d'une heure juste pour écrire des zéros avant de pouvoir
écrire le moindre fragment.
C'est un problème de la gestion des IO dans les applis torrent. Une fois
cette heure passée, ce qui a déjà été chargé est perdu (session perdues) et
le client se trouve temporairement "banni" des peers hôtes, et on récupère
très lentement la capacité de télécharger et le débit maximum n'est pas
atteint tant qu'on n'a pas téléchargé au moins 50% du fichier, les derniers
50% se font en moins d'une heure.
C'est un problème de libtorrent toujours pas résolu. Il n'a pas été mis au
point pour supporter correctement des fichiers de plus de 4Go.
Ce qui laisse à penser que pour une distribution efficace, il serait sans
doute avantageux de "splitter" ces fichiers de 50Go en parties de 4Go
maximum et fournir un outil permettant ensuite de les concaténer rapidement.
Ce problème existe aussi bien sous Windows que Linux et notamment si on
télécharge non par sur un SSD (les SSD de forte capacité sont chers) mais
sur un disque dur ou un RAID.
Pour l'instant aucune correction en vue de libtorrent (utilisé pas la
plupart des clients torrent, y compris l'officiel BitTorrent ou
microBittorrent ou qBitTorrent, parmi les plus populaires, mais aussi le
client Torrent intégré à la Freebox).
Bref il faut être TRES patient et ne PAS devoir rebooter son PC pendant
plus d'une heure et demi (en forçant un "kill" de l'appli Torrent qui ne
répond pas et est bloqué avec une I/O depuis une heure ou plus par l'OS qui
passe son temps à écrire des zéros dans les parties non téléchargées avant
de pouvoir écrire le fragment demandé).
Autre solution: télécharger temporairement sur un SSD et déplacer le
torrent terminé vers son nouvel emplacement (non pris en charge par les
applis actuelles: il faut arrêter le torrent, copier le fichier (cela prend
quelques minutes mais ce n'est pas bloquant), modifier le dossier dans les
propriétés du torrent pour indiquer son nouvel emplacement et pouvoir le
repartager. Beaucoup se contenteront d'arrêter le torrent immédiatement une
fois terminé et ne le remettront pas en route : le repartage ne fonctionne
pas. On en reste donc à une dépendance à quelques gros peers
J'ai demandé aux auteurs de libtorrent de prendre en charge la
"préallocation" de façon efficace (on peut tout à fait préallouer un
fichier de 50Go initialisé "virtuellement" à zéro en quelques
millisecondes, aussi bien sous Windows que Linux mais il faut utiliser des
API non POSIX. Libtorrent pour l'instant ne connait et n'utiliser que les
API de création de fichier, "seek" (valable uniquement dans l'espace déjà
alloué) et write et implémente très mal la préallocation (qu'il propose
mais de façon horrible). Seule parade: forcer le téléchargement séquentiel
(mais on perd la capacité du Torrent de distribuer en priorité des
fragments moins partagés: le démarrage sera rapide, mais la fin du
téléchargement sera très lente car il y aura peu de disponibilité hormis
quelques gros peers surchargés qui limitent fortement le débit pour
satisfaire tout le monde).
Pour l'instant si je compare le temps nécessaire, c'est 10 fois plus long
de télécharger un fichier planet en Torrent qu'en simple HTTP.
Le torrent n'est pas pour tout le monde: il faut une connexion fibre (en
DSL pas moyen d'avancer)
Le protocole Torrent n'est pas en cause mais bien l'implémentation
(libtorrent en l'occurrence qui fait office de "standard" pour pas mal
d'applis, porté sous Windows, Linux, et quelques systèmes BSD, sans doute
aussi macOS mais je n'ai pas regardé)

Note: @cquest: tes Torrents mentionnent trois trackers qui ne fonctionnent
pas du tout et rejettent toute connexion (ou connexion échouée en timeout):
* http://tracker.cquest.org:6969/announce (visiblement il est "off" chez
toi)
* http://tracker.computel.fr:80/announce (ne fonctionne quasiment jamais)
* retracker.local (non routable : ne fonctionne jamais, comment on est
sensé y accéder???)
Les deux seuls trackers utilisables sont:

* udp://tracker.opentrackr.org:1337/announce

* udp://tracker.torrent.eu.org:451/announce



Le sam. 15 août 2020 à 11:28, Christian Quest  a
écrit :

> Le 15/08/2020 à 10:04, Yves P. a écrit :
>
> Des technos plus basiques (HTTP) me semblent largement suffisantes pour
> démarrer et pour faciliter l'adoption initiale.
>
> L'adoption des consommateurs ou l'adoption par les archiveurs ?
> Les consommateurs accéderaient les images via une passerelle HTTP, donc
> aucune différence pour eux.
>
> +1
>
> Pour les archiveurs/miroirs idem, ils pourraient faire miroir via IPFS ou
> via n'importe quel autre protocole (rsync, FTP...). Ce ne serait qu'un
> avantage supplémentaire.
>
> Le but d'une archive est qu'elle soi

Re: [OSM-talk-fr] Photos — Re: Projet du mois de septembre (en préparation) : défibrillateurs !

2020-08-15 Par sujet Christian Quest 

Le 15/08/2020 à 10:04, Yves P. a écrit :


Des technos plus basiques (HTTP) me semblent largement suffisantes 
pour démarrer et pour faciliter l'adoption initiale.



L'adoption des consommateurs ou l'adoption par les archiveurs ?
Les consommateurs accéderaient les images via une passerelle HTTP, 
donc aucune différence pour eux.



+1


Pour les archiveurs/miroirs idem, ils pourraient faire miroir via 
IPFS ou via n'importe quel autre protocole (rsync, FTP...). Ce ne 
serait qu'un avantage supplémentaire.


Le but d'une archive est qu'elle soit pérenne. La rendre 
"mirrorable"/"shardable" facilement me semble important pour éviter 
les risques associés à avoir qu'un seul miroir. C'est là qu'IPFS 
excelle vu que n'importe qui peut devenir lui-même miroir sans 
manipulation de la part du miroir principal.



+1

IPFS serait un CDN de facto. Ton / tes serveur (s) stockent nativement 
les images sur IFPS.
La fondation OSM peux rajouter autant de serveurs sans difficultés, 
les performance et la fiabilité en seront améliorées.


Les clients passent par des serveurs webs classique (et pourquoi pas à 
terme directement via IPFS).


Le gain pour un stockage / archivage de photo ne saute pas aux yeux, 
mais pour le stockage / partage de fichiers pbf ça me parait "évident".
D'autant plus que tu avais parler de ça en février : "Héberger un 
mirroir ou un bittorrent pour les planet, possible?"


La diffusion du fichier planet en pbf par bittorrent tourne depuis fin 
janvier: https://osm.cquest.org/torrents/


--
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] Photos — Re: Projet du mois de septembre (en préparation) : défibrillateurs !

2020-08-15 Par sujet Yves P. 
>> Des technos plus basiques (HTTP) me semblent largement suffisantes pour 
>> démarrer et pour faciliter l'adoption initiale.
>> 
> L'adoption des consommateurs ou l'adoption par les archiveurs ?
> Les consommateurs accéderaient les images via une passerelle HTTP, donc 
> aucune différence pour eux.
> 
+1
> Pour les archiveurs/miroirs idem, ils pourraient faire miroir via IPFS ou via 
> n'importe quel autre protocole (rsync, FTP...). Ce ne serait qu'un avantage 
> supplémentaire.
> 
> Le but d'une archive est qu'elle soit pérenne. La rendre 
> "mirrorable"/"shardable" facilement me semble important pour éviter les 
> risques associés à avoir qu'un seul miroir. C'est là qu'IPFS excelle vu que 
> n'importe qui peut devenir lui-même miroir sans manipulation de la part du 
> miroir principal.
> 
+1

IPFS serait un CDN de facto. Ton / tes serveur (s) stockent nativement les 
images sur IFPS.
La fondation OSM peux rajouter autant de serveurs sans difficultés, les 
performance et la fiabilité en seront améliorées.

Les clients passent par des serveurs webs classique (et pourquoi pas à terme 
directement via IPFS).

Le gain pour un stockage / archivage de photo ne saute pas aux yeux, mais pour 
le stockage / partage de fichiers pbf ça me parait "évident".
D'autant plus que tu avais parler de ça en février : "Héberger un mirroir ou un 
bittorrent pour les planet, possible?"

__
Yves

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

Re: [OSM-talk-fr] Photos — Re: Projet du mois de septembre (en préparation) : défibrillateurs !

2020-08-15 Par sujet Éric Gillet 

Le 15/08/2020 à 09:04, Christian Quest a écrit :

Le 15/08/2020 à 00:02, Éric Gillet a écrit :

Le 14/08/2020 à 19:12, Yves P. a écrit :


C'est une très bonne idée ce projet !

peut-être ça vaut le coup de regarder du côté d'IPFS 
 ? Ça utilise exactement le mécanisme que tu 
décris :)


Quelques avantages que je vois à utiliser ça plutôt qu'une archive 
"maison" :


- Gestion de l'adressage, des dossiers déjà implémentée depuis 
longtemps, donc robuste
- Possibilité à n'importe quel contributeur disposant de stockage 
de faire mirroir, idem pour les passerelles IPFS/HTTP

- Moins de trafic à gérer du coup

Pour les photos, il y a son stockage (simple avec IPFS), ses 
métadonnées, et son ou ses adresses.

Est-ce que Mapillary, Commons utilisent aussi IPFS ?

Je ne pense pas.

Comment authentifier les paires clés OSM / photos ?


Ah oui j'ai mal lu le message de Christian, qui voulait que le hash 
soit calculé à partir du couple clé-valeur fichier et pas le hash du 
fichier en lui-même.


Du coup c'est un peu moins direct, mais ça peut se faire avec IPFS 
aussi en mettant les images dans un dossier. Elles auraient comme nom 
le hash que proposait Christian, ou tout autre transformation 
conservant une relation 1-1 (ou presque) avec le tag originel. 
Exemple rapide :


https://www.openstreetmap.org/node/21715092

https://bafybeidbdqxzzorb7gktaovapiq3agjh33brhgvkolnejhgxspac6ds5t4.ipfs.dweb.link/

Je n'ai rien par principe contre IPFS, ça me semble juste trop 
exotique actuellement (un peu comme le web sémantique) pour baser une 
telle archive dessus.


Des technos plus basiques (HTTP) me semblent largement suffisantes 
pour démarrer et pour faciliter l'adoption initiale.



L'adoption des consommateurs ou l'adoption par les archiveurs ?
Les consommateurs accéderaient les images via une passerelle HTTP, donc 
aucune différence pour eux.
Pour les archiveurs/miroirs idem, ils pourraient faire miroir via IPFS 
ou via n'importe quel autre protocole (rsync, FTP...). Ce ne serait 
qu'un avantage supplémentaire.


Le but d'une archive est qu'elle soit pérenne. La rendre 
"mirrorable"/"shardable" facilement me semble important pour éviter les 
risques associés à avoir qu'un seul miroir. C'est là qu'IPFS excelle vu 
que n'importe qui peut devenir lui-même miroir sans manipulation de la 
part du miroir principal.


Mais je comprends que ça fasse encore une techno de plus à gérer pour le 
gestionnaire du miroir principal. Même si son utilisation est assez simple.


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

Re: [OSM-talk-fr] Photos — Re: Projet du mois de septembre (en préparation) : défibrillateurs !

2020-08-15 Par sujet Christian Quest 

Le 15/08/2020 à 00:02, Éric Gillet a écrit :

Le 14/08/2020 à 19:12, Yves P. a écrit :


C'est une très bonne idée ce projet !

peut-être ça vaut le coup de regarder du côté d'IPFS 
 ? Ça utilise exactement le mécanisme que tu décris :)


Quelques avantages que je vois à utiliser ça plutôt qu'une archive 
"maison" :


- Gestion de l'adressage, des dossiers déjà implémentée depuis 
longtemps, donc robuste
- Possibilité à n'importe quel contributeur disposant de stockage de 
faire mirroir, idem pour les passerelles IPFS/HTTP

- Moins de trafic à gérer du coup

Pour les photos, il y a son stockage (simple avec IPFS), ses 
métadonnées, et son ou ses adresses.

Est-ce que Mapillary, Commons utilisent aussi IPFS ?

Je ne pense pas.

Comment authentifier les paires clés OSM / photos ?


Ah oui j'ai mal lu le message de Christian, qui voulait que le hash 
soit calculé à partir du couple clé-valeur fichier et pas le hash du 
fichier en lui-même.


Du coup c'est un peu moins direct, mais ça peut se faire avec IPFS 
aussi en mettant les images dans un dossier. Elles auraient comme nom 
le hash que proposait Christian, ou tout autre transformation 
conservant une relation 1-1 (ou presque) avec le tag originel. Exemple 
rapide :


https://www.openstreetmap.org/node/21715092

https://bafybeidbdqxzzorb7gktaovapiq3agjh33brhgvkolnejhgxspac6ds5t4.ipfs.dweb.link/

Je n'ai rien par principe contre IPFS, ça me semble juste trop exotique 
actuellement (un peu comme le web sémantique) pour baser une telle 
archive dessus.


Des technos plus basiques (HTTP) me semblent largement suffisantes pour 
démarrer et pour faciliter l'adoption initiale.


--
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] Photos — Re: Projet du mois de septembre (en préparation) : défibrillateurs !

2020-08-14 Par sujet Éric Gillet 

Le 14/08/2020 à 19:12, Yves P. a écrit :


C'est une très bonne idée ce projet !

peut-être ça vaut le coup de regarder du côté d'IPFS 
 ? Ça utilise exactement le mécanisme que tu décris :)


Quelques avantages que je vois à utiliser ça plutôt qu'une archive 
"maison" :


- Gestion de l'adressage, des dossiers déjà implémentée depuis 
longtemps, donc robuste
- Possibilité à n'importe quel contributeur disposant de stockage de 
faire mirroir, idem pour les passerelles IPFS/HTTP

- Moins de trafic à gérer du coup

Pour les photos, il y a son stockage (simple avec IPFS), ses 
métadonnées, et son ou ses adresses.

Est-ce que Mapillary, Commons utilisent aussi IPFS ?

Je ne pense pas.

Comment authentifier les paires clés OSM / photos ?


Ah oui j'ai mal lu le message de Christian, qui voulait que le hash soit 
calculé à partir du couple clé-valeur fichier et pas le hash du fichier 
en lui-même.


Du coup c'est un peu moins direct, mais ça peut se faire avec IPFS aussi 
en mettant les images dans un dossier. Elles auraient comme nom le hash 
que proposait Christian, ou tout autre transformation conservant une 
relation 1-1 (ou presque) avec le tag originel. Exemple rapide :


https://www.openstreetmap.org/node/21715092

https://bafybeidbdqxzzorb7gktaovapiq3agjh33brhgvkolnejhgxspac6ds5t4.ipfs.dweb.link/

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

Re: [OSM-talk-fr] Photos — Re: Projet du mois de septembre (en préparation) : défibrillateurs !

2020-08-14 Par sujet Yves P. 
> C'est une très bonne idée ce projet !
> 
> peut-être ça vaut le coup de regarder du côté d'IPFS  ? Ça 
> utilise exactement le mécanisme que tu décris :)
> 
> Quelques avantages que je vois à utiliser ça plutôt qu'une archive "maison" :
> 
> - Gestion de l'adressage, des dossiers déjà implémentée depuis longtemps, 
> donc robuste
> - Possibilité à n'importe quel contributeur disposant de stockage de faire 
> mirroir, idem pour les passerelles IPFS/HTTP
> - Moins de trafic à gérer du coup
> 
> 
Ce que j'ai compris, c'est que InterPlanetary File System 
 (IPFS) permet de 
distribuer des données, augmenter la tolérance aux pannes, diminuer le débit 
d'un serveur donné…
Il ne gère pas des adresses de fichiers, mais leur hash et leur intégrité et 
authenticité.

Au dessus, il est possible de faire plein de choses, de l'archivage du web et 
même du streaming audio ou vidéo en temps réel !

Pour les photos, il y a son stockage (simple avec IPFS), ses métadonnées, et 
son ou ses adresses.
Est-ce que Mapillary, Commons utilisent aussi IPFS ?
Comment authentifier les paires clés OSM / photos ?

Wikimedia Commons à des métadonnées sous forme de wiki et l'image elle même et 
ses déclinaisons en tailles plus petites).
Mapillary à probablement des métadonnées en dehors de l'image elle-même (tag, 
auteur, séquence…).

Il y a encore des parties qui m'échappent :D

__
Yves

PS: IPFS pourrait aussi servir à stocker les données OSM en .pbf ;)

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

Re: [OSM-talk-fr] Photos — Re: Projet du mois de septembre (en préparation) : défibrillateurs !

2020-08-14 Par sujet Éric Gillet 

Le 09/08/2020 à 12:06, Christian Quest a écrit :

Le 09/08/2020 à 10:14, Yves P. a écrit :

de Christian


Pour le stockage des photos ou autres sources externes, wikipedia 
garde une copie d'archive.
Je pense que ce serait bénéfique de faire pareil pour OSM, car tout 
lien externe est potentiellement instable


Tu suggères de mettre un système de cache au niveau de l'API OSM ? ;)

Un contributeur OSM édite un objet avec les tags suivant et l'API 
fait automatiquement un copie :


  * image=http://site.com/a.jpg
  * mapillary=APQ8H32KnIwG3lKIaMY7HA
  * wikimedia_commons=File:Defibrillator am Hafenbüro Kappeln.jpg
  * une combinaison de tout ça dans le tag image
  * avec des valeurs multiples ;)


Comment retrouve-t-on les photos ?


Je ne pense pas à un cache (temporaire), mais à une copie d'archive, 
comme wikipédia le fait sur les sources qui peuvent disparaître, 
changer d'adresse ou autre.


J'ai un peu réfléchit au problème... le plus simple me semble de 
calculer un hash à partir du tag au contenu à archiver. Ceci évite de 
devoir rajouter un tag avec le lien de l'archive dans la base OSM.


Exemple (avec du md5)

image=http://site.com/a.jpg -> 
http://archive.osm.org/ce7442f69a6ad43fb972724c1a8cdc05


mapillary=APQ8H32KnIwG3lKIaMY7HA -> 
http://archive.osm.org/eaaee35521d34a3cb74965cb50dcb500


etc...


C'est une très bonne idée ce projet !

Si archive.org ou autre archive "standard" n'est pas utilisée, peut-être 
ça vaut le coup de regarder du côté d'IPFS  ? Ça 
utilise exactement le mécanisme que tu décris :)


Quelques avantages que je vois à utiliser ça plutôt qu'une archive 
"maison" :


- Gestion de l'adressage, des dossiers déjà implémentée depuis 
longtemps, donc robuste
- Possibilité à n'importe quel contributeur disposant de stockage de 
faire mirroir, idem pour les passerelles IPFS/HTTP

- Moins de trafic à gérer du coup


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

Re: [OSM-talk-fr] Photos — Re: Projet du mois de septembre (en préparation) : défibrillateurs !

2020-08-09 Par sujet osm . sanspourriel 

Le 09/08/2020 à 13:10, Christian Quest - cqu...@openstreetmap.fr a écrit :

j'imagine que Mapillary est plutôt stable et fiable.


Tu imagines sans doute bien.

Par contre Yves nous a déjà remonté des URL ésotériques. C'est plus là
qu'il va y avoir de la perte. Et probablement là l'archive n'y
changerait rien.

Si pour les DAE on veut deux images distinctes à but distinct (vue large
et vue proche), faut-il un ou deux tags ?

Jean-Louis nous avait fait un mapillary:wide.

Donc image, mapillary, ... : vue proche. En général quand on a une photo
d'un objet on a la photo... de l'objet, pas de son environnement.

Donc image:wide, mapillary:wide, ... : vue large (surroundings est
peut-être moins ambigu : wide pourrait signifier le format de photo
landscape/paysage).

Et non Yves je ne suis pas pour mettre des ; : ces photos doivent être
"uniques". Si entre deux photos pour le même but tu ne sais laquelle
choisir c'est sans doute qu'aucune n'est assez bonne.

Comme Christian j'ai des doutes sur la tolérance à long terme de Wiki
d'héberger les photos des bornes incendie, des DAE (demain des boîtes
aux lettres histoire de vérifier les horaires de levée ? Des bouées de
sauvetage en vue large pour la même raison ?).

N. B. : je mets peu de bouées de sauvetage dans OSM car elles sont bien
visibles. Si on ne voit pas une bouée de sauvetage en avoir une sur OSM
plus loin c'est sans doute trop tard.

Jean-Yvon



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

Re: [OSM-talk-fr] Photos — Re: Projet du mois de septembre (en préparation) : défibrillateurs !

2020-08-09 Par sujet PanierAvide 
Question bateau mais a-t'on une idée du nombre d'attributs image=* en 
base pour lesquels la photo n'est plus actuellement disponible ? 
Clairement un système d'archivage de photos a tout son sens, mais 
probablement pas le même degré d'urgence à mettre en place selon si on a 
1% de pertes ou 80%.


Cordialement,

Adrien P.

Le 09/08/2020 à 12:06, Christian Quest a écrit :

Le 09/08/2020 à 10:14, Yves P. a écrit :

de Christian


Pour le stockage des photos ou autres sources externes, wikipedia 
garde une copie d'archive.
Je pense que ce serait bénéfique de faire pareil pour OSM, car tout 
lien externe est potentiellement instable


Tu suggères de mettre un système de cache au niveau de l'API OSM ? ;)

Un contributeur OSM édite un objet avec les tags suivant et l'API 
fait automatiquement un copie :


  * image=http://site.com/a.jpg
  * mapillary=APQ8H32KnIwG3lKIaMY7HA
  * wikimedia_commons=File:Defibrillator am Hafenbüro Kappeln.jpg
  * une combinaison de tout ça dans le tag image
  * avec des valeurs multiples ;)


Comment retrouve-t-on les photos ?


Je ne pense pas à un cache (temporaire), mais à une copie d'archive, 
comme wikipédia le fait sur les sources qui peuvent disparaître, 
changer d'adresse ou autre.


J'ai un peu réfléchit au problème... le plus simple me semble de 
calculer un hash à partir du tag au contenu à archiver. Ceci évite de 
devoir rajouter un tag avec le lien de l'archive dans la base OSM.


Exemple (avec du md5)

image=http://site.com/a.jpg -> 
http://archive.osm.org/ce7442f69a6ad43fb972724c1a8cdc05


mapillary=APQ8H32KnIwG3lKIaMY7HA -> 
http://archive.osm.org/eaaee35521d34a3cb74965cb50dcb500


etc...


A charge pour le script d'archivage de récupérer la photo en elle 
même, ce qui d'ailleurs rendra son accès universel car aujourd'hui il 
faut faire cela avec les différents tags si on veut accéder à l'image 
et par à une page web ou autre.


Je verrai bien quelques métadonnées sur l'image, sa date de 
récupération ou autre, ajoutées dans les données EXIF.



Avantages:

- aucun changement pour les contributeurs

- facile à implémenter pour accéder à une archive


Inconvénients: je vous laisse compléter ;)


D'après taginfo, image=* + mapillary=* ça ne va par bien loin... ça 
sent le POC ;)



PS: je ne pense pas que Wikimédia Commons soit destiné à ce genre de 
contenu, ce n'est pas un stockage cloud fourre-tout. La 1ème photo 
de DAE y apportera quoi ?


--
Christian Quest - OpenStreetMap France

___
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] Photos — Re: Projet du mois de septembre (en préparation) : défibrillateurs !

2020-08-09 Par sujet Christian Quest 

Le 09/08/2020 à 10:14, Yves P. a écrit :

de Christian


Pour le stockage des photos ou autres sources externes, wikipedia 
garde une copie d'archive.
Je pense que ce serait bénéfique de faire pareil pour OSM, car tout 
lien externe est potentiellement instable


Tu suggères de mettre un système de cache au niveau de l'API OSM ? ;)

Un contributeur OSM édite un objet avec les tags suivant et l'API fait 
automatiquement un copie :


  * image=http://site.com/a.jpg
  * mapillary=APQ8H32KnIwG3lKIaMY7HA
  * wikimedia_commons=File:Defibrillator am Hafenbüro Kappeln.jpg
  * une combinaison de tout ça dans le tag image
  * avec des valeurs multiples ;)


Comment retrouve-t-on les photos ?


Je ne pense pas à un cache (temporaire), mais à une copie d'archive, 
comme wikipédia le fait sur les sources qui peuvent disparaître, changer 
d'adresse ou autre.


J'ai un peu réfléchit au problème... le plus simple me semble de 
calculer un hash à partir du tag au contenu à archiver. Ceci évite de 
devoir rajouter un tag avec le lien de l'archive dans la base OSM.


Exemple (avec du md5)

image=http://site.com/a.jpg -> 
http://archive.osm.org/ce7442f69a6ad43fb972724c1a8cdc05


mapillary=APQ8H32KnIwG3lKIaMY7HA -> 
http://archive.osm.org/eaaee35521d34a3cb74965cb50dcb500


etc...


A charge pour le script d'archivage de récupérer la photo en elle même, 
ce qui d'ailleurs rendra son accès universel car aujourd'hui il faut 
faire cela avec les différents tags si on veut accéder à l'image et par 
à une page web ou autre.


Je verrai bien quelques métadonnées sur l'image, sa date de récupération 
ou autre, ajoutées dans les données EXIF.



Avantages:

- aucun changement pour les contributeurs

- facile à implémenter pour accéder à une archive


Inconvénients: je vous laisse compléter ;)


D'après taginfo, image=* + mapillary=* ça ne va par bien loin... ça sent 
le POC ;)



PS: je ne pense pas que Wikimédia Commons soit destiné à ce genre de 
contenu, ce n'est pas un stockage cloud fourre-tout. La 1ème photo 
de DAE y apportera quoi ?


--
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] Photos — Re: Projet du mois de septembre (en préparation) : défibrillateurs !

2020-08-09 Par sujet Yves P. 
> Il faudrait aussi demander [la] licence [des photos].

Le Modèle standard de données V14.3 

 donne une piste :

Champ   LibelléTypeDescription Exemple Valeur  Diffusion   
Valeur fictive
photo1  Photo 1 du DAE dans son environnement   Chaine de caractères   Photo 
au format url.
Il est préconisé un plan large pour que le DAE soit visible dans son 
environnement.
La photo déposée devra être libre de droit, sous format Open Source  
Facultative Publique
photo2  Photo 2 du DAE dans son environnement   Chaine de caractères   Photo 
au format url.
Il est préconisé un plan large pour que le DAE soit visible dans son 
environnement.
La photo déposée devra être libre de droit, sous format Open Source  
Facultative Publique

Je déduis qu'une des photos doit être en plan large, l'autre en plan serré ;)
Allo cont...@geodae.sante.gouv.fr  :D

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

Re: [OSM-talk-fr] Photos — Re: Projet du mois de septembre (en préparation) : défibrillateurs !

2020-08-09 Par sujet Yves P. 
de Christian
> 
> Pour le stockage des photos ou autres sources externes, wikipedia garde une 
> copie d'archive.
> Je pense que ce serait bénéfique de faire pareil pour OSM, car tout lien 
> externe est potentiellement instable

Tu suggères de mettre un système de cache au niveau de l'API OSM ? ;)

Un contributeur OSM édite un objet avec les tags suivant et l'API fait 
automatiquement un copie :
image=http://site.com/a.jpg 
mapillary=APQ8H32KnIwG3lKIaMY7HA
wikimedia_commons=File:Defibrillator am Hafenbüro Kappeln.jpg
une combinaison de tout ça dans le tag image
avec des valeurs multiples ;)

Comment retrouve-t-on les photos ?


Concernant l'intégration des photos de géoDAE dans OSM

Il y a 2 photos par DAE.
On doit donc utiliser un tag avec des valeurs multiples (en espérant que la 
longueur ne soit pas supérieure à 255 caractères).

Osmose ne récupère pas encore les photos : 
https://github.com/PanierAvide/osmose-backend/blob/master/analysers/analyser_merge_defibrillators_FR.py#L55
 


En fait la doc de géoDAE n'indique pas quel est l'URL d'une photo : que faire 
de 5f2d628870074.jpeg ?
J'ai fait une demande…

Il faudrait aussi demander leur licence.

__
Yves

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

Re: [OSM-talk-fr] Photos — Re: Projet du mois de septembre (en préparation) : défibrillateurs !

2020-08-08 Par sujet European Water Project 
Bonsoir,

Je pense que Wikimedia Commons soit le meilleur endroit pour stocké les
images liées aux objets d'OSM pour les raisons citées par Christian.

Voici le workflow actuel ..  pas facile ... surtout quand il y a beaucoup
d'image et on les mets qq jours après leurs prises.

1) prendre une photo 2) télécharger sur Commons 3) retrouver plus tard le
bon objet OSM et 4) editer l'objet OSM ..

Nous avons développé un moyen de prendre les images des fontaines
directement depuis notre app pour les fontaines ... pour l'instant nous
avons eu qq contributions d'images de France, Allemagne Suisse, Espagne,
Italie, Nouvelle Zélande.. ..

voici une démonstration :
https://drive.google.com/file/d/1qgjsj8LKapkDJDwwaIWeVjNOYARLvAv7/view?usp=sharing

Nous stockons les images sur notre serveur .. mais avons l'intention de
tous les transferer vers wikimedia Commons .. si Wikimedias Commons est
d'accord de les hostées ..

Bien cordialement,

Stuart

On Sat, 8 Aug 2020 at 17:49, Georges Dutreix via Talk-fr <
talk-fr@openstreetmap.org> wrote:

> Bonjour,
>
> Pardon de dériver hors sujet, mais je me posais justement la question pour
> des mégalithes que je viens de saisir dans OSM, et dont j'ai pris des
> photos.
> Quel est le meilleur endroit où les mettre pour ajouter un lien dans OSM ?
>
> Merci
>
> 8 août 2020 11:59:41 Christian Quest :
>
> > Pour le stockage des photos ou autres sources externes, wikipedia garde
> une copie d'archive.
> >
> > Je pense que ce serait bénéfique de faire pareil pour OSM, car tout lien
> externe est potentiellement instable:
> >
>
> ___
> 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] Photos — Re: Projet du mois de septembre (en préparation) : défibrillateurs !

2020-08-08 Par sujet Georges Dutreix via Talk-fr 
Bonjour,

Pardon de dériver hors sujet, mais je me posais justement la question pour des 
mégalithes que je viens de saisir dans OSM, et dont j'ai pris des photos.
Quel est le meilleur endroit où les mettre pour ajouter un lien dans OSM ?

Merci

8 août 2020 11:59:41 Christian Quest :

> Pour le stockage des photos ou autres sources externes, wikipedia garde une 
> copie d'archive.
> 
> Je pense que ce serait bénéfique de faire pareil pour OSM, car tout lien 
> externe est potentiellement instable:
> 

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

Re: [OSM-talk-fr] Photos — Re: Projet du mois de septembre (en préparation) : défibrillateurs !

2020-08-08 Par sujet Christian Quest 
Pour le stockage des photos ou autres sources externes, wikipedia garde 
une copie d'archive.



Je pense que ce serait bénéfique de faire pareil pour OSM, car tout lien 
externe est potentiellement instable:


- changement d'URL sans les redirections qui vont bien

- non pérennité du site externe (Mapillary ou autre)


--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Photos — Re: Projet du mois de septembre (en préparation) : défibrillateurs !

2020-08-08 Par sujet Yves P. 
Bonjour,

J'ai analysé les clés et valeurs utilisés pour les photos de DAE.

Dans le monde, on à seulement 3% des DAE avec une photos décrite dans OSM.
(il y en a au moins dans OsmHydrant/Wikimedia Commons)

Clé Nombre  Requête overpass
image   44  https://overpass-turbo.eu/s/WPo 

mapillary   763 https://overpass-turbo.eu/s/WPp 

wikimedia_commons   65  https://overpass-turbo.eu/s/WPq 


Chaque tag décrit une unique photo (pas de valeurs multiples).
C'est peut-être ce qui à pousser l'auteur d'OsmHydrant à lier les objets OSM et 
les photos dans Commons et pas dans OSM ?

268 DAE (1%) sont des chemins ou des relations dans OSM : la photo est-elle 
celle du bâtiment ou celle du DAE ??

Au niveau qualitatif le résultat laisse à désirer (cf. infra pour le détail) :

des URL valides mais avec des syntaxes ésotériques :
un humain va voir la photo
une application risque de ne pas pouvoir l'afficher (sauf à compliquer 
inutilement son code)
JOSM n'arrive pas à ouvrir les liens :(
https://www.mapillary.com/map/im/fL-reQYegJ3R9xjyecqm-A 
 
https://www.mapillary.com/app/?lat=51.240488430277765&lng=4.577619759166737&z=17&pKey=gDY-QrN7paP2LVC6MXgndQ&focus=photo
 


des URLs invalident :(
https://www.mapillary.com/app/?lat=51.240488430277765&lng=4.577619759166737&z=17&pKey=gDY-QrN7paP2LVC6MXgndQ&focus=photo
 

dans la clé image on trouve des valeurs qui gagneraient à être déplacer dans 
les clés mapillary et wikimedia_commons (67%)
ça simplifie la saisie, ça réduit les bugs
du spams et des sites non pérennes (8%)

Voies d'améliorations possibles :

mettre les liens des photos dans wikidata
avantage :
un contrôle oblige à mettre des liens valides
la licence des photos est connue (photos obligatoirement sur Commons)
le stockage est "pérenne" (idem)
une photo peut-être mise à jour dans Commons sans avoir besoin de modifier le 
tag dans OSM
inconvénient :
on perd la trace des photos dans OSM. Ça oblige à maitriser Wikidata et 
Wikimedia Commons
utiliser uniquement mapillary ou Commons et contrôler la syntaxe (mettre 
uniquement l'identifiant de la photo)
avantage :
on garde la trace dans OSM
la licence des photos est connue
en mettant uniquement l'identifiant de la photon :
on simplifie le travail des développeurs (et diminue le risque de bugs)
on s'assure que la photo sera affichée
inconvénient :
il n'existe pas à ce jour de mécanisme "universel" de contrôle des valeurs de 
tag dans OSM
chaque application doit effectuer ce contrôle
améliorer les presets dans les éditeurs
ne proposer que mapillary ou commons
si possible, permettre de télécharger un fichier directement depuis l'éditeur 
dans l'un des 2 sites.

Mise à part des solutions techniques, une (in)formation des contributeurs me 
semble souhaitable :
Nombre de photos à mettre
"Angles" de prise de vue
cadrages correctes
https://www.mapillary.com/map/im/fL-reQYegJ3R9xjyecqm-A 
 (difficile de 
localiser le DAE)
https://www.mapillary.com/map/im/qBMqEjodaq7_TfMbyU8dcw 
 (on situe bien le DAE 
et son panneau de signalisation)

On retrouve des conseils similaires dans le site du SHOM? pour les phares.
Où sur Pl@ntNet  pour les végétaux.

Par exemple, cette unique photo 
 
ne permet pas de trouver le DAE, ni d'identifier le modèle.
Ici on voit bien le DAE et son état, mais il est impossible de visualiser le 
bâtiment dans lequel il se trouve :
https://postimg.cc/mcstLPTM 
https://framapic.org/X5Li6Ihf2yZP/tPemwjh0D5dA.jpg 

__
Yves


Mapillary

484 valeurs à rallonge tel que 
https://www.mapillary.com/app/user/filipc?lat=51.377795706403845&lng=4.479672973994639&z=17&feedItem=user-tKLqKVmOKqyrzeIUbWBtAQ-activity-user-tKLqKVmOKqyrzeIUbWBtAQ-publishing_done-image&pKey=3fWsU6fbLvNwgBP-U5UWAg&focus=photo
 


201 URL complètes "https://www.mapillary.com/map/im/zvKGtMirixKDEmLwcX94LQ";

2 en mode édition ! https://www.openstreetmap.org/edit#map=21/50.99845/4.17625 


2 invalides :
Meerdorp 4
Roeselare, Gasthuisstraat 10: https://www.mapillary.com/app/?lat=50.9 … 
ocus=photo (h

[OSM-talk-fr] Photos — Re: Projet du mois de septembre (en préparation) : défibrillateurs !

2020-08-07 Par sujet Yves P. 

>> Comment publier des photos utiles ?
>> Une, deux ?
> 
> Une : https://postimg.cc/zHk0cms3 
Avec l'expérience des PEI ("bornes" incendie), je soutiens qu'il en faut 
parfois plus :
Une ou plusieurs pour situer le DAE.
Une de près pour voir le modèle, son état (à l'instant t).
Eventuellement une autre pour voir les infos sur les étiquettes (nom du 
fabriquant, du modèle, raison sociale, coordonnée du responsable, date de la 
prochaine maintenance, de remplacement des électrodes, de remplacement de la 
batterie).

>> Sur quel site ?
Mapillary :
Certains y sont hostiles depuis le rachat par Facebook.
De plus, pas évident de mettre une seule photo. Pas de système de tags pour 
regrouper les photos d'un même objet.

Wikimedia Commons :
Photos libre de droits, souvent de qualité.
Catégories pour regrouper les photos d'un même objet ou d'un même sujet.
Bonus, on peut mettre le modèle {{On OSM|type=node|OSM_ID=6274037529}}  qui 
permet de retrouver l'objet dans OSM (et faire de la pub à notre projet)
https://commons.wikimedia.org/wiki/File:DAE,_Jura_(France)_01.jpg 

https://commons.wikimedia.org/wiki/File:DAE,_Jura_(France)_02.jpg 




>> Dans quels champs ?
> 
> image=*
Ce tag est trop permissif car il ne filtre pas les sources.
Tu peux même mettre un lien sur postimg.cc  qui va afficher 
de la pub, ne respecter aucune licence ;)

Si les photos viennent de Mapillary, le tag ad hoc est mapillary.
Idem pour Wikimedia Commons.

Je rajoute comment ?

Si on accepte plusieurs photos, il faut? un tag qui "accepte" des valeurs 
multiples ;)

Est-ce que "toutes" les applis gèrent correctement :
wikimedia_commons=File:DAE,_Jura_(France)_01.jpg 
;File:DAE,_Jura_(France)_02.jpg
 
image=https://upload.wikimedia.org/wikipedia/commons/1/11/DAE%2C_Jura_%28France%29_02.jpg;https://upload.wikimedia.org/wikipedia/commons/3/3e/DAE%2C_Jura_%28France%29_01.jpg
 

mapillary=YiV_q27qaVxKpy6ZGHzK1g 
;tLHykPTfGg5qT0GZuj8KDA
 
;6OtqJuD1iQUq4_IKN0LV3w
 

image=https://www.mapillary.com/map/im/YiV_q27qaVxKpy6ZGHzK1g 
;https://www.mapillary.com/map/im/tLHykPTfGg5qT0GZuj8KDA;https://www.mapillary.com/map/im/6OtqJuD1iQUq4_IKN0LV3w
 


Je rappel (encore) que les tags sont limités à 255 caractères ?

__
Yves


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