Re: [OSM-talk-fr] Chantiers d'été pour OSM-FR ;)

2020-08-09 Par sujet Yves P. 
> L'occasion d'améliorer quelques name:fr !

Les postes de transformation électrique : leur libellé est affiché 2 fois en 
zoom 19 et 20.
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#20/46.58154/5.74565
 

https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#20/46.57432/5.75581
 

https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#20/46.57469/5.75619
 


Il n'a pas de logo au moins en 20, ce qui aiderait à savoir ce que c'est ;)

Afficher le nom (et un logo ?) des postes de transformation électrique sur 
poteaux (power=pole et pas power=substation)
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#20/46.59908/5.62577
 

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



Ici, un accueil de loisir avec un libellé en double en zoom 20 :
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#20/46.57512/5.75540
 


Idem pour la déchèterie :
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#20/46.58608/5.73638
 



Les DAEs ne sont pas affichés : Seulement en septembre pour le projet du mois ? 
:D
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#20/46.57439/5.75571
 

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

https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#20/46.59250/5.73438
 

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


Zone de rencontre : rendu "bizarre" (arrondi en bout de way) et pas très 
parlant.
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#20/46.59250/5.73407
 

https://www.openstreetmap.org/way/580345876 


Libellé violet "Boissia" qui tombe du ciel en zoom 19 et 20 :
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#20/46.59265/5.73319
 


Est-ce le landuse=residential ?
https://www.openstreetmap.org/way/187972711#map=17/46.59229/5.73382 



Les conteneurs des PAVs (points d'apport volontaire) sont regroupés en zoom ≤ 
18 :)
Eventuellement rajouter un logo journaux, verre, détritus… en zoom 20 (mais pas 
évident car les données ne sont pas homogènes en France ?)
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#20/46.58183/5.74556
 

Ici il y en fait 3 conteneurs (1 x verre, 2 x vêtements)

Libellés des limites communales : je les mettrais de la même couleur que le 
trait de limite
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#20/46.58825/5.69348
 



Panneaux de randonnée (PDIPR) le rendu OSM est plus parlant (libellé, altitude 
et logo guidepost)
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#20/46.65332/5.68375
 

https://www.openstreetmap.org/node/6336132998#map=19/46.65338/5.68380 


Monuments aux mort : mettre un logo spécifique ?
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#20/46.65515/5.67978
 

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


Boite à livre par rendue
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#20/46.66565/5.64801
 

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


Il n'y a que le nom ici :
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#20/46.65498/5.59869

Re: [OSM-talk-fr] Chantiers d'été pour OSM-FR ;)

2020-08-09 Par sujet Christian Quest 

Le 05/08/2020 à 19:42, Jérôme Amagat a écrit :


Les mers, baies et détroits (place=sea, natural=bay, natural=strait) 
en surfacique pourraient avoir leur nom qui apparaissent pour les 
mer et détroit et plus tôt lorsqu'ils sont très grands pour les 
baies qui sont déjà rendu.
exemple : le golfe du lion 
https://www.openstreetmap.org/relation/9287303 
http://tile.openstreetmap.fr/?zoom=11=42.99137=4.17341=B






Voilà les océans, mers, baies, détroits maintenant visibles sur le rendu 
FR :)


L'occasion de découvrir le tag sqkm=* qui indique sur un objet ponctuel 
sa superficie approximative en km².


Ceci permet de prioriser ces objets et c'est bien pratique !

Tag documenté sur le wiki en 2016.


Vous pouvez voir ce que ça donne (avec les améliorations précédentes) sur:

https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#2/0/0

C'est un accès direct au rendu en cours de dev (chez moi, pas dispo H24 
et recalculs non continus).



L'occasion d'améliorer quelques name:fr !

--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Défibrillateur et tag name=*

2020-08-09 Par sujet Yves P. 
> Comment as-tu pu positionner le DAE depuis une orthophoto ? ;-)
> 
Je suis rentré dans le collège comme un voleur ;)

> J'ai corrigé les horaires d'ouvertures : SH pour School Holidays.
> 
> 
Merci, mais pour le moment ce n'est pas gérer dans le code (En France on a des 
zones à la con).

> OSM est une base de données géographiques. Si là il y a un collège c'est 
> l'infirmerie du collège.
> 
Oui :)

J'ai tenté d'expliquer que ces données ne sont pas forcément utilisées par une 
appli d'un smartphone disposant d'un GPS (qui capte - au sens propre).
Elles peuvent servir à faire une simple liste papier ;)

> N. B. : ça fait aussi que les horaires d'ouvertures sont relatifs : s'il y 
> aune sonnette, je suppose que tu essayeras même en dehors des horaires 
> d'ouvertures de récupérer le DAE.
> 
> Pour revenir au access=, vous parlez de l'accès au collège, c'est à mon avis 
> hors sujet. Si lors d'une journée porte ouverte un parent fait un arrêt 
> cardiaque vous n'allez pas le traîner en dehors du collège pour vous ramener 
> au cas précédent !
> 
C'est bien sûr l'accès au DAE (ou ses horaires d'accès).
Comme il est dans l'enceinte du bâtiment, on recopie les horaires d'ouverture 
du collège.

J'ai regardé le tag access des DAE ayant une ref:FR:geoDAE :
yes 113
permissive  5
private 2

Pour les 2 privés, 1 est dans l'école primaire 
, l'autre dans une salle du 
COSEC  (complexe omnisports 
évolutif couvert)
Je mettrais plutôt ça en permissif ;)

Pour les permissifs, il y en a 2 dans la même entreprise, 1 dans un ciné, 1 
dans un cinéma et le dernier à la mairie.
Il me semble que l'accès private soit être exceptionnel en France (dans quel 
cas ?)

> Par contre dans des piscines par exemple j'ai vu des DAE accessibles 
> uniquement au personnel : donc il faut trouver du personnel et non le DAE. 
> Dans ce cas access= permet de le savoir (et si besoin de guider le personnel).
> 
Plutôt une note ? Et encore, ces établissement on un accueil ;)
> SaveLife ? Une application spécialisée qui fera du rendu intérieur quand le 
> DAE est décrit comme étant à l'intérieur ?
> 
Oups, SAUV life  :

Une organisation de médecin urgentistes qui collabore avec de nombreux SAMU 
 pour envoyer sur place des 
volontaires munis de l'application.
(Et bien avant que les pompiers aient démarré leur VSAV - du moins à la 
cambrousse)

__
Yves

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

Re: [OSM-talk-fr] Photos > archiver les image=* ?

2020-08-09 Par sujet Yves P. 
> J'avais commencé un fichier MapCSS pour faire de la validation dans JOSM sur 
> les images, ça peut être complété pour être plus exhaustif : 
> https://josm.openstreetmap.de/wiki/Rules/Pictures 
> 
Super mais il y a plusieurs problèmes :
de mémoire il faut explicitement charger cette règle
JOSM n'est pas le seul "éditeur" de données
on réinvente la roue (les contraintes sont déjà décrites dans wikidata).

Je pense qu'il faut pousser l'utilisation des dataitems (nos wikidatas) pour 
décrire une fois pour toutes les règles de validation des données (pour tous 
les logiciels).
Et/ou intégrer ça directement dans l'API, comme ça même si l'éditeur ne fait 
pas son boulot, le nettoyage est fait de toute façon.

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

Le problème est que — peut-être— le modèle de données OSM est à bout de souffle 
?

mapillary:wide=*
image_2=*
image_3=*
Et pourquoi pas mapillary_wide_portrait=* ? :D

Comment un logiciel (et même un humain) va savoir quoi faire de ces variantes 
de tag ?

Dans wikidata, c'est "simple" :)

La propriété image décrit… une image :)
Si tu veux préciser que c'est un plan serré, large… il suffit de rajouter un 
qualificatif.

Dans tous les cas une requête qui affiche les images par exemple des mégalithes 
fonctionnera sans rien changer.

Quelqu'un crée une sous-classe de mégalithe, ça marche aussi :
https://w.wiki/ZA5 

Un élément peut avoir 0 ou plusieurs images, des photos de nuits, des logos… 
qui sont tous des images.

On peut avoir une image en version française, allemande… (pour un logo, une 
copie d'écran…)
En pratique, c'est une image avec le qualificatif "langue de l'œuvre, du nom ou 
du terme" en français.

> 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 ?).
ça fait un moment qu'il y a des photos de fontaines, bornes fontaines, 
hélicoptères, lavoirs…
En fait ça provient des listes de wikipedia.

J'ai relu Commons:Objectifs du projet 
 et Commons:Ce que 
Commons n'est pas 
.
Le caractère éducatif des listes de DAE est limite, mais pas exclu.

Mettre aussi des tonnes de DAE et autre objets de la vie réelle peut permettre 
à des chercheurs de travailler dans les domaines de l'IA, de la sociologie, 
l'histoire…

Un échange entre la fondation OSM et la fondation Wikimedia peut clarifier ces 
usages une fois pour toute ?

__
Yves

On peut aussi faire tourner notre propre instance (serveur) de Commons mais on 
perd le "Commun" ;)___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Défibrillateur et tag name=*

2020-08-09 Par sujet osm . sanspourriel 

Le 09/08/2020 à 08:46, Yves P. - yves.prat...@gmail.com a écrit :

Un exemple réel : "À gauche au fond du couloir, devant l'infirmerie"
https://www.openstreetmap.org/node/6323423304


Faire de l'indoor mapping à partir d'une photo aérienne n'est pas
facile ;)
Peu d'applications font un rendu intérieur.

Avoir un POI d'infirmerie sur OSM ne va pas indiquer comment y aller
(rapidement).


De deux choses l'une : soit la personne est dans l'établissement et
collégiens comme professeurs et autres savent où est l'infirmerie. Soit
elle est à l'extérieur. Et là voir ci-dessous.

Comment as-tu pu positionner le DAE depuis une orthophoto ? ;-)

J'ai corrigé les horaires d'ouvertures : SH pour School Holidays.

Mo-Fr 07:30-18:00; Sa 07:30-12:00; PH off; SH off



Pourquoi pas "Infirmerie" ?


De quoi, de l'entreprise de BTP ou de la maison de retraite du coin ?


OSM est une base de données géographiques. Si là il y a un collège c'est
l'infirmerie du collège. Quand tu ajoutes en cartographie intérieure du
collège un POI infirmerie, tu ajoutes en name "infirmerie du collège des
Lacs, 2B rue du Village Neuf, Clairvaux-les-Lacs
, France" ?


Si il est à la machine à café, je met quoi ;D


Cafétéria, Espace pause... par exemple. Et si les gens disent qu'ils se
retrouvent à la "machine à café", "machine à café".

Et si l'entreprise a fléché ça "espace de restauration légère interdit
pour la pause méridienne", tu mets "espace de restauration légère
interdit pour la pause méridienne" : tu mets ce qui permet de trouver
rapidement. Si c'est une description à la con qui est fléchée, tu mes ce
nom à la con. Sinon tu mets ce qui permettra aux gens du voisinage de te
guider. J'appelle ça du bon sens.


Je connais pas ce collège, mais à ma connaissance en général ils ne
laissent pas rentrer le public, donc le DAE n'est pas vraiment
accessible au public


En cas d'arrêt cardiaque chez le voisin, faut-il donner sa carte de
sécu, sa carte bancaire, sa carte de collégien… pour prendre le DAE ?


/En France ou aux États-Unis ? Là, carte bancaire et pièce d'identité et
en plus tu dois demander à l'ambulance de conduire la personne à
l'hôpital :-(. Hélas je suis sérieux, c'est du vécu, heureusement
seulement comme témoin-traducteur et pour une perte de connaissance.
Mais le problème c'était d'expliquer au conjoint de la victime pourquoi
l'ambulancier voulait savoir que faire de la personne - en Europe on
fait confiance au personnel pour faire au mieux - et pourquoi il avait
confisqué leurs pièces d'identité - carrément un vol pour un Allemand.
Et oui en Allemagne comme en France nécessité fait loi. Et le personnel
d'Air France devait aussi rassurer pour la gestion des bagages ! Là,
version française/européenne : "ça on sait faire, l'ordre de débarquer
vos bagages a déjà été donné et on les met en consigne mais pour le
moment l'important c'est votre mari". Ce n'était pas une demande de
carte bancaire pour facturer les frais de débarquement, de consigne et
de retard de l'avion. Ça s'appelle du savoir-vivre./

Ceci dit effectivement entrer dans l'enceinte de l'établissement pourra
entrainer même en France une certaine négociation.

N. B. : ça fait aussi que les horaires d'ouvertures sont relatifs : s'il
y aune sonnette, je suppose que tu essayeras même en dehors des horaires
d'ouvertures de récupérer le DAE.

Pour revenir au access=, vous parlez de l'accès au collège, c'est à mon
avis hors sujet. Si lors d'une journée porte ouverte un parent fait un
arrêt cardiaque vous n'allez pas le traîner en dehors du collège pour
vous ramener au cas précédent !

Par contre dans des piscines par exemple j'ai vu des DAE accessibles
uniquement au personnel : donc il faut trouver du personnel et non le
DAE. Dans ce cas access= permet de le savoir (et si besoin de guider le
personnel).


Ce qui serait bien c'est que SaveLife appel l'accueil du collège pour
demander de préparer le DAE car quelqu'un arrive en courant pour une
URGENCE VITALE :)


Dans ce cas il faut cartographier les personnes ayant un arrêt cardiaque
pas les DAE (humour).

J'ai tagué un DAE dans une entreprise où personne ne rentre sans laisser
son identité. Sans access=. J'espère que les gens témoins d'un accident
cardiaque à côté sauront sonner et qu'à l'accueil ils sauront soit faire
une exception soit demander à un secouriste de l'entreprise d'intervenir.

Marqué indoor et sans horaires : si l'accueil est fermé et s'il reste
quelqu'un à portée de voix, ça doit suffire.

SaveLife ? Une application spécialisée qui fera du rendu intérieur quand
le DAE est décrit comme étant à l'intérieur ?

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

Re: [OSM-talk-fr] Photos > archiver les image=* ?

2020-08-09 Par sujet PanierAvide 
J'avais commencé un fichier MapCSS pour faire de la validation dans JOSM 
sur les images, ça peut être complété pour être plus exhaustif : 
https://josm.openstreetmap.de/wiki/Rules/Pictures


Adrien P.

Le 09/08/2020 à 15:31, Yves P. a écrit :

Pour la France, il y a 46000 tags uniques.

N'oublie pas les valeurs multiples ;)

D'après taginfo, nombre de valeurs contenant ";"

*Clé*   *Nombre**Commentaire*
mapillary   272 
wikimedia_commons   270 Attention : il y a des noms contenants  !
image   78  
flickr  0   


Et ça devrait augmenter si on importe dans OSM les 2 photos de chaque 
DAE );



Je vais démarrer par les image=* car c'est là en principe où il 
devrait y avoir de la perte car j'imagine que Mapillary est plutôt 
stable et fiable.


Il y a plusieurs syntaxes pour wikimedia_commons, mapillary et leurs 
valeurs stockées dans la clé image.


Je pense qu'un formatage (nettoyage) s'impose. Il faudrait d'ailleurs 
le faire au niveau éditeurs, voir carrément au niveau de l'API ;)


Exemples :

Commons

  * 
https://commons.wikimedia.org/wiki/File%3AA4221-Rathaus-Steyregg_10-2013_005.jpg


  * File%3AA4221-Rathaus-Steyregg_10-2013_005.jpg
  * File:A4221-Rathaus-Steyregg 10-2013 005.jpg
  * 
https://upload.wikimedia.org/wikipedia/commons/1/15/A4221-Rathaus-Steyregg_10-2013_005.jpg
  * 
https://upload.wikimedia.org/wikipedia/commons/thumb/1/15/A4221-Rathaus-Steyregg_10-2013_005.jpg/100px-A4221-Rathaus-Steyregg_10-2013_005.jpg
  * …


Mapillary

  * https://www.mapillary.com/map/im/zvHQ3g83K0Wj1yeO_oh6qw
  * zvHQ3g83K0Wj1yeO_oh6qw

  * https://images.mapillary.com/zvHQ3g83K0Wj1yeO_oh6qw/thumb-640.jpg
  * … ?



Que fait-on des valeurs foireuses (ici du tag mapillary) :D

  * name:en=Elephant␣terrace␣tourism=attraction␣url=

https://youtu.be/ZnJBngOUk2w␣wikidata=Q767080␣wikipedia=en:Terrace␣of␣the␣Elephants


  * mapillary=

https://www.mapillary.com/map/im/rmgaoubjKQabLe34FQHurQ␣image=https://images.mapillary.com/rmgaoubjKQabLe34FQHurQ/thumb-2048.jpg


  * https://www.youtube.com/watch?v=8RFaSbBkCXI
  * 
https://www.symphonyseniorliving.com/wp-content/uploads/2017/06/manor_gal_1.jpg
  * https://www.openstreetmap.org/user/km2bp/traces/2992415
  * …



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'avais bien compris ça :)

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


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


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



Excellente idée :)
(Je rappel les cas de valeurs et syntaxes multiples)

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.



Modifier l'image, bof.
Et être obligé d'utiliser une API pour décortiquer l'EXIF peut-être 
parfois lourd.


Des données JSON ?
http://archive.osm.org/eaaee35521d34a3cb74965cb50dcb500.json

__
Yves

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

Re: [OSM-talk-fr] Photos > archiver les image=* ?

2020-08-09 Par sujet Yves P. 
> Pour la France, il y a 46000 tags uniques.
N'oublie pas les valeurs multiples ;)

D'après taginfo, nombre de valeurs contenant ";"

Clé Nombre  Commentaire
mapillary   272 
wikimedia_commons   270 Attention : il y a des noms contenants  !
image   78  
flickr  0   

Et ça devrait augmenter si on importe dans OSM les 2 photos de chaque DAE );


> Je vais démarrer par les image=* car c'est là en principe où il devrait y 
> avoir de la perte car j'imagine que Mapillary est plutôt stable et fiable.

Il y a plusieurs syntaxes pour wikimedia_commons, mapillary et leurs valeurs 
stockées dans la clé image.

Je pense qu'un formatage (nettoyage) s'impose. Il faudrait d'ailleurs le faire 
au niveau éditeurs, voir carrément au niveau de l'API ;)

Exemples :

Commons
https://commons.wikimedia.org/wiki/File%3AA4221-Rathaus-Steyregg_10-2013_005.jpg
 

File%3AA4221-Rathaus-Steyregg_10-2013_005.jpg
File:A4221-Rathaus-Steyregg 10-2013 005.jpg
https://upload.wikimedia.org/wikipedia/commons/1/15/A4221-Rathaus-Steyregg_10-2013_005.jpg
 

https://upload.wikimedia.org/wikipedia/commons/thumb/1/15/A4221-Rathaus-Steyregg_10-2013_005.jpg/100px-A4221-Rathaus-Steyregg_10-2013_005.jpg
 

…

Mapillary
https://www.mapillary.com/map/im/zvHQ3g83K0Wj1yeO_oh6qw 

zvHQ3g83K0Wj1yeO_oh6qw 
https://images.mapillary.com/zvHQ3g83K0Wj1yeO_oh6qw/thumb-640.jpg 

… ?


Que fait-on des valeurs foireuses (ici du tag mapillary) :D
name:en=Elephant␣terrace␣tourism=attraction␣url= 
https://youtu.be/ZnJBngOUk2w␣wikidata=Q767080␣wikipedia=en:Terrace␣of␣the␣Elephants
 

mapillary= 
https://www.mapillary.com/map/im/rmgaoubjKQabLe34FQHurQ␣image=https://images.mapillary.com/rmgaoubjKQabLe34FQHurQ/thumb-2048.jpg
 

https://www.youtube.com/watch?v=8RFaSbBkCXI 

https://www.symphonyseniorliving.com/wp-content/uploads/2017/06/manor_gal_1.jpg 

https://www.openstreetmap.org/user/km2bp/traces/2992415 

…


> 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'avais bien compris ça :)

> 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
> 
> image=http://site.com/a.jpg  -> 
> http://archive.osm.org/ce7442f69a6ad43fb972724c1a8cdc05 
> 
> mapillary=APQ8H32KnIwG3lKIaMY7HA 
> ->http://archive.osm.org/eaaee35521d34a3cb74965cb50dcb500 
> Excellente idée :)
(Je rappel les cas de valeurs et syntaxes multiples)

> 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.
> 
Modifier l'image, bof.
Et être obligé d'utiliser une API pour décortiquer l'EXIF peut-être parfois 
lourd.

Des données JSON ?
http://archive.osm.org/eaaee35521d34a3cb74965cb50dcb500.json 


__
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 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 > archiver les image=* ?

2020-08-09 Par sujet Christian Quest 

Le 09/08/2020 à 12:45, PanierAvide a écrit :


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,



Je suis en train de regarder ça justement ;)

Extraction en cours de tous les tags image=* et mapillary=* du fichier 
planet (merci osmium).


Pour la France, il y a 46000 tags uniques.

Je vais démarrer par les image=* car c'est là en principe où il devrait 
y avoir de la perte car j'imagine que Mapillary est plutôt stable et fiable.



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

[OSM-talk-fr] hebdoOSM Nº 524 2020-07-28-2020-08-03

2020-08-09 Par sujet theweekly . osm 
Bonjour,

Le résumé hebdomadaire n° 524 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

https://www.weeklyosm.eu/fr/archives/13472/

Bonne lecture !

Saviez-vous que vous pouvez vous aussi soumettre des messages pour la note 
hebdomadaire sans être membre ? Il vous suffit de vous connecter sur 
https://osmbc.openstreetmap.de/login avec votre compte OSM. Pour en savoir plus 
sur la rédaction d'un article, cliquez ici: 
http://www.weeklyosm.eu/fr/this-news-should-be-in-weeklyosm

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Anniversaire OSM et défibrillateurs

2020-08-09 Par sujet Yves P. 
> Anniversaire OSM
> 
> Que pouvons-nous faire ?
> 
> Organiser une carto partie avec partage d'un gâteau d'anniversaire OSM 
>  ?
> Avec à l'issue, une photo : bravo aux Kabouliennes et Kabouliens 
> 

Et pourquoi pas des carto-parties pour recenser les DAE ?
Des présentations (vidéos) pour montrer les applis OSM pour les trouver et les 
cartographier ?

Pour les plus pointus, le travail d'assurance qualité fait Osmose…

__
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. 
> 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] Défibrillateur et tag name=*

2020-08-09 Par sujet Yves P. 

> Mais souvent dans les jeux de données il y a des infos fausses, subjectives 
> ou redondantes. Pas tout est bon à prendre.
En est d'accord. C'est pour ça qu'on parle d'intégration de données : il faut 
faire le ménage :)

>> Pour "A droite au fond du couloir", je ne vois pas de tag qui décrit ça ;)
> Avec le level, la position dans OSM et les panneaux sur place ça doit suffire 
> largement. Si ça suffit pas, il y a un problème d'accessibilité du DAE.
> 
Dans la FAQ de GéoDAE, il y a des conseilles pour choisir un endroit 
accessible, visible et facilement identifiable.

Dans la pratique, il y a des DAEs placés à des endroits peu logiques, avec un 
accès "compliqué".

>> Un exemple réel : "À gauche au fond du couloir, devant l'infirmerie"
>> https://www.openstreetmap.org/node/6323423304 
>> 
>> 
> Merci pour l'exemple. On dirait que l'infirmerie n'est pas cartographiée, ça 
> réglerait le problème sans tag dédié pour le DAE.
> 
Faire de l'indoor mapping à partir d'une photo aérienne n'est pas facile ;)
Peu d'applications font un rendu intérieur.

Avoir un POI d'infirmerie sur OSM ne va pas indiquer comment y aller 
(rapidement).

>> Dans un listing, il manque une info essentielle : "Collège des Lacs"
> Pourquoi pas "Infirmerie" ?
> 
De quoi, de l'entreprise de BTP ou de la maison de retraite du coin ?
Si il est à la machine à café, je met quoi ;D
> Ou "Collège" ?
> 
Mieux :)
> Ou "Collège de Clairvaux-les-Lacs" ? Le nom n'est toujours pas pertinent à 
> mon avis.
> 
C'est le nom du Collège :)
> Autre tag manquant : access=customers ou access=private.
> 
Oui, mais en pratique je ne sais pas.
> Je connais pas ce collège, mais à ma connaissance en général ils ne laissent 
> pas rentrer le public, donc le DAE n'est pas vraiment accessible au public
> 
En cas d'arrêt cardiaque chez le voisin, faut-il donner sa carte de sécu, sa 
carte bancaire, sa carte de collégien… pour prendre le DAE ?
Ce qui serait bien c'est que SaveLife appel l'accueil du collège pour demander 
de préparer le DAE car quelqu'un arrive en courant pour une URGENCE VITALE :)

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

Re: [OSM-talk-fr] Celebrate the 16th OSM anniversary!

2020-08-09 Par sujet Yves P. 

>> https://blog.openstreetmap.org/2020/07/15/opnvkarte-une-nouvelle-couche-mise-en-evidence-sur-www-openstreetmap-org/?lang=fr
>>  
Note aux traducteurs :

"Carreaux gracieuseté de xxx" ??
"créer une carte-monde" ?

Faire une copie d'écran en français d'une ville francophone est bienvenue ;)

En tout cas j'ai appris le sens de ÖPNVKarte :)

> Suis-je la seule à penser qu'elle fait doublon avec "Carte de transport" ?
Vu son nom, oui :)

> Ou, comme tu le dis, puisque c'est progressif, osm.org attend de voir la 
> montée en charge d'OPVNKarte pour supprimer l'autre ?


En comparent rapidement les 2, je trouve que la première est plus adaptée pour 
un fond de plan pour afficher d'autres POI.
https://tools.geofabrik.de/mc/#17/48.8761/2.3585=2=public_transport=thunderforest-transport
 


Je garderais les 2 :)

Anniversaire OSM

Que pouvons-nous faire ?

Organiser une carto partie avec partage d'un gâteau d'anniversaire OSM 
 ?
Avec à l'issue, une photo : bravo aux Kabouliennes et Kabouliens 


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