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

[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] Chantiers d'été pour OSM-FR ;)

[Christian Quest]

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

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

Tout d'abord, merci pour ce très beau rendu !

Plusieurs améliorations possibles :

Les aires d'autoroutes highway=services ne sont pas rendu 
contrairement au aires sans service highway=rest_area
exemple : https://www.openstreetmap.org/way/125646404 
http://tile.openstreetmap.fr/?zoom=17=45.84394=5.07038=B


Les barrage non plus, pas rendu waterway=dam, il y a seulement le nom 
qu apparaît.
exemple : https://www.openstreetmap.org/way/37953758 
http://tile.openstreetmap.fr/?zoom=15=45.22418=6.95203=B


Les rivières waterway=river sans natural=water ou waterway=riverbank 
n'apparaissent qu'au zoom 15 ce qui est tard, il me semble.
exemple : https://www.openstreetmap.org/way/30785271 
http://tile.openstreetmap.fr/?zoom=14=42.6065=8.9894=B


Il y a des déserts en natural=desert et en natural=sand pour les 
déserts de sable, a faible zoom il sont rendu de la même façon mais à 
partir du zoom 8 les natural=sand disparaissent. Et il serait 
intéressant que leur noms apparaissent aussi et peut être une couleur 
un peu différente ?
exemple : https://www.openstreetmap.org/way/232227949 
http://tile.openstreetmap.fr/?zoom=8=30.16904=0.24451=B


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


Il faudrait mettre ça en issues sur 
https://github.com/cquest/osmfr-cartocss/issues



Truc plus compliqué et je ne sais pas si c'est possible C'est un 
rendu fr, mais n' y a pas de name:fr partout :) et les noms sont 
illisibles pour la plupart des francophones lorsqu'il sont dans un 
autre alphabet, par contre les noms en anglais sont beaucoup plus 
présent et sont souvent les même que les français, serait il possible 
de faire apparaître les noms en anglais lorsque le name=* est dans un 
autre alphabet que l'alphabet latin et qu'il n'y a pas de name:fr ? 
Je pense surtout au noms des villes et régions en Chine, Japon, 
Thaïlande, pays arabe... mais aussi l'europe de l'est et la Grèce 
avec leurs alphabet plus proche du nôtre mais difficile à lire pour 
la plupart des francophones.

Je ne sais pas si c'est possible de trier par alphabet ou par pays.


C'est déjà en partie le cas, l'ordre c'est:

- name:fr
- intl_name
- name

Difficile par contre de déterminer l'alphabet utilisé et d'aller plus 
loin en insérant par exemple un name:en.





J'ai fait pas mal de modif ces derniers jours sur le style du rendu FR:

- les barrages sur rendu en surfaciques

- les rivières sont de retour

- les déserts (natural=sand) sont visibles sur tous les zoom


Pour les noms, j'ai trouvé un moyen de détecter que name=* contient des 
caractères en laphabet latin ou pas. Si il n'y en a pas, j'ai rajouté 
les name:en, name:es et name:de en rattrapage. Cela donne de bons 
résultats sur Tokyo.



Toujours les noms... j'ai tenté d'aller un peu plus loin dans les 
abréviations, car vu qu'ils prennent moins de place, on a plus de chance 
de les voir apparaître.


Des noms abrégés étaient déjà utilisés (jusqu'au zoom 16), j'ai rajouté 
un traitement sur les prénoms dans les noms de rues.


"Rue Pierre et Marie Curie" > "Rue P. et M. Curie"

"Jean-Pierre Thimbaud" > " J-P. Thimbaud"

Mais...

"Saint-François d'Assise" > "St-François d'Assise"

"Jean-Paul II" > "Jean-Paul II"


Dans les autres améliorations mineures, beaucoup de coupures de texte 
ont été améliorées. En fait, les réglage de la feuille de style 
tentaient de composer avec le fonctionnement de mapnik 2.x... et la 
majorité des causes de coupure en bord de métatuiles sont désormais bien 
gérées par mapnik 3.x.


Vous pouvez voir l'ensemble des modifs sur 
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858


Un peu de patience, le cache a été vidé, donc il faut un peu de temps 
pour les calculs des tuiles (qui chauffe mon bureau comme si il en avait 
besoin).


N'hésitez pas à remonter des anomalies, avant que je ne pousse cette 
nouvelle version du style en production (ou pas selon vos retours).


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

[Christian Quest]

L'afficher pour aider au rapprochement... sauf si tu a regéocodé ça 
mieux que GeoDAE ;)



Le 08/08/2020 à 17:38, PanierAvide a écrit :
C'est fait pour le ref:FR:SIREN qui est passé operator:ref:FR:SIREN, 
après il faut le temps que ça se mette à jour côté résultats Osmose. 
Tu veux dire afficher l'adresse dans la popup, ou bien l'ajouter aux 
données ?


Adrien P.

Le 08/08/2020 à 17:35, Christian Quest a écrit :

Le 08/08/2020 à 13:35, PanierAvide a écrit :

Bonjour,

Merci à tous pour vos retours. La proposition majoritaire semble 
donc être de ne pas utiliser le champ name, mais plutôt d'utiliser 
defibrillator:location, à défaut d'une information d'accès plus 
précise disponible. Je propose les modifications en conséquence sur 
Osmose.


Cordialement,



Tu en profite pour modifier le ref:FR:SIREN ?

Ce qui manque dans osmose pour faciliter l'intégration, c'est 
l'adresse...





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


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

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

[PanierAvide]

C'est fait pour le ref:FR:SIREN qui est passé operator:ref:FR:SIREN, 
après il faut le temps que ça se mette à jour côté résultats Osmose. Tu 
veux dire afficher l'adresse dans la popup, ou bien l'ajouter aux données ?


Adrien P.

Le 08/08/2020 à 17:35, Christian Quest a écrit :

Le 08/08/2020 à 13:35, PanierAvide a écrit :

Bonjour,

Merci à tous pour vos retours. La proposition majoritaire semble donc 
être de ne pas utiliser le champ name, mais plutôt d'utiliser 
defibrillator:location, à défaut d'une information d'accès plus 
précise disponible. Je propose les modifications en conséquence sur 
Osmose.


Cordialement,



Tu en profite pour modifier le ref:FR:SIREN ?

Ce qui manque dans osmose pour faciliter l'intégration, c'est 
l'adresse...





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

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

[Christian Quest]

Le 08/08/2020 à 13:35, PanierAvide a écrit :

Bonjour,

Merci à tous pour vos retours. La proposition majoritaire semble donc 
être de ne pas utiliser le champ name, mais plutôt d'utiliser 
defibrillator:location, à défaut d'une information d'accès plus 
précise disponible. Je propose les modifications en conséquence sur 
Osmose.


Cordialement,



Tu en profite pour modifier le ref:FR:SIREN ?

Ce qui manque dans osmose pour faciliter l'intégration, c'est l'adresse...


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

[PanierAvide]

Bonjour,

Merci à tous pour vos retours. La proposition majoritaire semble donc 
être de ne pas utiliser le champ name, mais plutôt d'utiliser 
defibrillator:location, à défaut d'une information d'accès plus précise 
disponible. Je propose les modifications en conséquence sur Osmose.


Cordialement,

Adrien P.

Le 06/08/2020 à 16:32, PanierAvide a écrit :

Bonjour à tous,

Suite au travail lancé pour ajouter des jeux de données dans Osmose 
autour des défibrillateurs, la question se pose de la pertinence du 
tag name=* sur les défibrillateurs [1,2]. En effet, dans les jeux de 
données (GéoDAE, AEDMAP, bases locales), un nom est souvent associé au 
DAE. Ce nom est plutôt descriptif, exemples "DAE de la mairie", 
"Défibrillateur de la salle XYZ". Dans certains cas, il ressemble 
plutôt à une référence. Il est proposé ainsi d'opter pour 
l'utilisation de ref=* ou description=*.


En parallèle, dans la base de données OSM aujourd'hui, on constate que 
14% des DAE ont un tag name=* associé. C'est plus que ref=* (5%) ou 
description=* (moins de 3% ?). Une requête Overpass fait ressortir que 
les valeurs du champ name=* sur les DAE sont plutôt descriptives. 
C'est un usage qui dépasse nos frontières à la vue des langues 
utilisées. Même si ce sont des noms descriptifs, l'usage montre que 
name=* est l'attribut pour stocker cette info.


La question est donc la suivante : doit-on préferer le champ name=* 
pour cette info (usage international), utiliser un champ ref=* (plus 
logique sémantiquement, mais qui sera une spécificité FR), voire ne 
pas proposer d'ajouter l'info du nom dans OSM (arbitrage simple mais 
on perd une info) ? Merci pour vos avis qui permettront de débloquer 
l'ajout de nouveaux jeux dans Osmose :-)


Cordialement,

[1] https://github.com/osm-fr/osmose-backend/issues/936
[2] https://github.com/osm-fr/osmose-backend/pull/940



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

[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] Celebrate the 16th OSM anniversary!

[deuzeffe]

Le 08/08/2020 à 10:19, osm.sanspourr...@spamgourmet.com a écrit :

Bonjour,

Mais Phyk, Florimond & Cie ont déjà préparé un texte comme 
https://blog.openstreetmap.org/2020/07/15/opnvkarte-une-nouvelle-couche-mise-en-evidence-sur-www-openstreetmap-org/?lang=fr 


Suis-je la seule à penser qu'elle fait doublon avec "Carte de transport" 
? 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 ?


--
deuzeffe

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

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

[Yves P.]

> C'est vrai qu'on pourrait un peu anticiper, là c'est un peu tard
> 
Il y a les vacances, la canicule, le corona virus…
Il me semble que d'autres pays ont organisé des événements plus tard.

On en organise en France ?
Fin septembre, en octobre ?

… avant le 31/12/2020 quoi ;D

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

[osm . sanspourriel]

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


Est-ce qu'il y a des événements en projet ? c'est samedi aujourd'hui ;)


C'est vrai qu'on pourrait un peu anticiper, là c'est un peu tard mais
sinon ça aurait fait une bonne pub pour OSM France et CyclOSM d'ajouter
officiellement la couche aujourd'hui.

Mais Phyk, Florimond & Cie ont déjà préparé un texte comme
https://blog.openstreetmap.org/2020/07/15/opnvkarte-une-nouvelle-couche-mise-en-evidence-sur-www-openstreetmap-org/?lang=fr
je crois.

Si ce n'est fait c'est en gestation et ce sera leur contribution ? ;-)

Comme la mise en place est progressive, normalement on peut passer un
point aujourd'hui (voir la liste tech, "Chantiers d'été pour OSM-FR" du
02/08/2020 à 14:07 ;)).

Jean-Yvon

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

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

[Yves P .]

Bonjour,

En jouant avec les calculateurs d'itinéraires, un message est apparu je ne sais 
comment :

Il renvoie vers les pages :
https://blog.openstreetmap.org/2020/08/01/celebrate-the-16th-osm-anniversary/ 

https://blog.openstreetmap.org/2020/08/01/celebration-du-16eme-anniversaire-de-l-osm/?lang=fr
 


Est-ce qu'il y a des événements en projet ? c'est samedi aujourd'hui ;)

__
Yves

Pas de copie d'écran (refusée par la liste )




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

[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=4.577619759166737=17=gDY-QrN7paP2LVC6MXgndQ=photo
 


des URLs invalident :(
https://www.mapillary.com/app/?lat=51.240488430277765=4.577619759166737=17=gDY-QrN7paP2LVC6MXgndQ=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=4.479672973994639=17=user-tKLqKVmOKqyrzeIUbWBtAQ-activity-user-tKLqKVmOKqyrzeIUbWBtAQ-publishing_done-image=3fWsU6fbLvNwgBP-U5UWAg=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 (het linkse gebouw op de foto is on OSM gelabeled als 'OCMW'

Et seulement 33 correctes  "G11A5omLnm6Ats2kjqr3nA" !!