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

[Yves P.]

Le 19-11-07 à 07 h 26, marc marc a écrit :
> lPic4review montre bien qu'il n'y a pas besoin de codé en dur l'image,
> on peux la récupérer quand on a besoin, sans besoin de maintenance

Pour info, il existe WikiShootMe!  qui 
permet récupérer des images et articles géolocalisés

Il est utilisé ainsi par le code javascript de la carte historic.place 
 :
'https://tools.wmflabs.org/wikishootme/#lat=' + data.lat + '='+ data.lon + 
'=16=commons,flickr,mixnmatch,wikidata_image,wikidata_no_image,wikipedia';

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

Re: [OSM-talk-fr] Mulhouse, un vignoble ?

[George Kaplan]

Bonjour,

C’est un contributeur qui a, sans doute par erreur, ajouté les mêmes tags que 
le chemin inner à la relation multi polygon. J’ai modifié la relation pour 
revenir à landuse=residential et type=multipolygon.

George Kaplan

> Le 7 nov. 2019 à 23:23, Muselaar  a écrit :
> 
> Bonsoir,
> 
> Quelqu'un a-t-il remarqué cette étrangeté, qui date de quelques semaines, 
> mais que je n'avais pas comprise jusqu'ici. Cela provoque l'affichage en vert 
> de tout Mulhouse, ville que je ne connais pas plus que ça, et ça m'intriguait 
> :
> 
> https://www.openstreetmap.org/relation/371773
> 
> Si quelqu'un peut réparer, je pense que ça serait une vraie B.A. Moi, je ne 
> comprends pas trop, je subodore la blague, mais je ne suis pas capable de 
> comprendre si c'en est une, ou seulement une mauvaise manipulation d'un 
> débutant.
> 
> Muselaar
> 
> 
> ___
> 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] Outil pour additionner longueur de ways ?

[phyks]

Attention à ne pas oublier oneway=-1 !

Le 7 novembre 2019 19:19:51 UTC+01:00, osm.sanspourr...@spamgourmet.com a écrit 
:
>Tu utilises la sélection par attributs pour récupérer toutes les rues
>oneway=yes à compter une fois, tu met la longueur L1 de côté.
>
>Tu utilises la sélection par attributs pour récupérer toutes les rues
>!oneway=yes à compter deux fois, tu met la longueur L2 de côté.
>
>Je vais l'hypothèse que tu n'as chargé dans JOSM que les rues qui
>t'intéressent.
>
>Et tu trouves un outil capable de te calculer L1 + 2 * L2 ;-)
>
>Le 07/11/2019 à 16:41, Shohreh - codecompl...@free.fr a écrit :
>> Phyks wrote
>>> Le plus simple (et sûr) est de compter le linéaire total (en
>filtrant les
>>> highways pour ne pas prendre les chemins privés etc) avec le sens de
>>> circulation en prenant :
>>> * La longueur des ways pour les ways à sens unique
>>> * La longueur des ways * 2 pour les ways à double sens (pas de
>oneway ou
>>> oneway=no)
>> Bien vu.
>>
>> Comment faire ?
>>
>>
>>
>> --
>> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>>
>> ___
>> 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

[OSM-talk-fr] Mulhouse, un vignoble ?

[Muselaar]

Bonsoir,

Quelqu'un a-t-il remarqué cette étrangeté, qui date de quelques 
semaines, mais que je n'avais pas comprise jusqu'ici. Cela provoque 
l'affichage en vert de tout Mulhouse, ville que je ne connais pas plus 
que ça, et ça m'intriguait :


https://www.openstreetmap.org/relation/371773

Si quelqu'un peut réparer, je pense que ça serait une vraie B.A. Moi, je 
ne comprends pas trop, je subodore la blague, mais je ne suis pas 
capable de comprendre si c'en est une, ou seulement une mauvaise 
manipulation d'un débutant.


Muselaar


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

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

[osm . sanspourriel]

Le 07/11/2019 à 14:00, marc marc - marc_marc_...@hotmail.com a écrit :


Une fois que j'ai sélectionné la meilleur image pour un passage piéton,
j'ajoute les infos d'accessibilité du passage piéton dans osm.
Retrouver la meilleur image n'est plus utile vu que j'en ai extrait
les infos.

Outre le cas mentionné, tu peux vouloir utiliser l'image pour une raison
et un autre pour une autre ou pour vérifier parce qu'un attribut te
titille. Mettons pour voir s'il y a un appel piéton.

Le 07/11/2019 à 16:28, JB - jb...@mailoo.org a écrit :

Je suis convaincu que toutes ces clefs externes sont du genre à
rebuter un nouvel entrant qui, ne sachant pas ce qu'elles veulent
dire, préfèreront ne rien toucher que de risquer de tout casser…


Effectivement il vaut mieux qu'ils évitent de toucher aux clés s'ils n'y
comprennent rien^^.

Que ce soit sur JOSM ou iD il y a des assistants (preset) pour enrichir
sans connaître les attributs.

Mais tu n'as pas complètement tort. Si on a sur openstreetmap.org des
liens qui utilisent ces références, c'est plus parlant.

Yves, je dis ça, je ne dis rien^^.


(Apparemment, en 2019, on n'arrive toujours pas à croiser les
contrôles techniques issus d'OSM avec une base externe sans utiliser
un identifiant unique ? La clef unique est vraiment la solution de
facilité…)


La clé unique c'est la solution fiable.

Si _toutes_ les données de _toutes_ les bases de données étaient
correctes _et_ complètes, tu pourrais faire fiablement sans mais avec un
fort surcout de calcul.

Prenons l'identifiant des stations services en France.

Ça permet à Adrien P. d'afficher les infos à la bonne position dans
OpenFuel.
Ça permet à Fred de proposer les attributs plus détaillés dans Osmose.
Ça permet aussi de remonter au fournisseur de données des positions
incorrectes.

Chaque base de donnée a ses points forts, avec les identifiants on peut
consolider les infos.

Par exemple de prendre les positions dans OSM et les prix sur le site
gouvernemental.

Version brute : le Carrefour Market de Vire est mal positionné
<https://www.carburants.org/stations/vire/carrefour-market_carrefour-market.DDxmAz>,
confondu avec le Carrefour Contact de Vire
<https://www.carburants.org/stations/vire/carrefour-contact_carrefour-contact.DDxmAn>.

Version consolidée : sur OpenFuel le Carrefour Market de Vire est bien
positionné <https://openfuelmap.net/#15/48.8566/-0.8707> (au nord de la
carte).

Mais bon, si tu arrives à faire comprendre à la CPAM qui tu es sans
donner ton numéro INSEE...

Le 07/11/2019 à 16:14, Adrien André via Talk-fr -
talk-fr@openstreetmap.org a écrit :

source=mapillary + source:date=20191107 ne suffit-il pas ?


Tu proposes de mettre plus d'infos, je vois mal le gain (hormis créer
moins de clés... en codant des clés dans des valeurs). Le lien que tu as
donné ne marche pas. Mais dans ce cas regarde plutôt du côté du greffon
OpenSwitchMaps.

Et si tu utilisais Mapillary tu saurais qu'il y a pas mal de déchets,
trouver /la/ bonne photo n'est pas évident (Cf. la remarque à propos de GM).


Si on tient à stocker des informations de lien, alors la place de ces
informations ne serait-elle pas plutôt ailleurs ?


On peut considérer que c'est de la méta donnée, donc à mettre au niveau
des changeset. Sauf que l'on a vu que l'info ne sert pas qu'à ça et
qu'elle est à la modification d'un objet pas d'un ensemble de
modifications. Techniquement ton système tient la route mais ne fait que
cacher la donnée (plus la maintenance des liens, voir plus loin).

Voir rapidement que le panneau "90" vient d'une photo de 2019 et non
d'une photo de 2016 permet de savoir si ça vaut le coup de vérifier la
donnée.

Le 07/11/2019 à 16:14, Adrien André via Talk-fr -
talk-fr@openstreetmap.org a écrit :

Les informations sémantiques sur les éléments restent ainsi séparées
de la donnée technique de lien. (...)


Voir ce point
<https://github.com/openstreetmap/openstreetmap-website/issues/2405#issuecomment-548917729>
sur le GitHub d'openstreetmap.org ;-).

Sur le principe OK mais dans la pratique c'est déjà fait par Wikidata.

Jean-Yvon

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

Re: [OSM-talk-fr] Outil pour additionner longueur de ways ?

[HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT GE PPE)]

Ou Qgis et quickOSM !

-Message d'origine-
De : Shohreh  
Envoyé : jeudi 7 novembre 2019 14:34
À : talk-fr@openstreetmap.org
Objet : [OSM-talk-fr] Outil pour additionner longueur de ways ?

Bonjour,

J'ai besoin de connaître la distance que représente l'ensemble de rues données.

Idéalement, via une requête à Overpass-Turbo qui calculera lui-même le 
résultat, ou alors en downloadant le résultat dans un GPX, en l'ouvrant dans un 
logiciel équipé d'une règle qui me permettrait manuellement de mesurer + 
additioner toutes les ways.

Merci.



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
---
Ce message et toutes les pièces jointes sont établis à l'intention exclusive de 
ses destinataires et sont confidentiels. L'intégrité de ce message n'étant pas 
assurée sur Internet, la SNCF ne peut être tenue responsable des altérations 
qui pourraient se produire sur son contenu. Toute publication, utilisation, 
reproduction, ou diffusion, même partielle, non autorisée préalablement par la 
SNCF, est strictement interdite. Si vous n'êtes pas le destinataire de ce 
message, merci d'en avertir immédiatement l'expéditeur et de le détruire.
---
This message and any attachments are intended solely for the addressees and are 
confidential. SNCF may not be held responsible for their contents whose 
accuracy and completeness cannot be guaranteed over the Internet. Unauthorized 
use, disclosure, distribution, copying, or any part thereof is strictly 
prohibited. If you are not the intended recipient of this message, please 
notify the sender immediately and delete it. 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Outil pour additionner longueur de ways ?

[osm . sanspourriel]

Tu utilises la sélection par attributs pour récupérer toutes les rues
oneway=yes à compter une fois, tu met la longueur L1 de côté.

Tu utilises la sélection par attributs pour récupérer toutes les rues
!oneway=yes à compter deux fois, tu met la longueur L2 de côté.

Je vais l'hypothèse que tu n'as chargé dans JOSM que les rues qui
t'intéressent.

Et tu trouves un outil capable de te calculer L1 + 2 * L2 ;-)

Le 07/11/2019 à 16:41, Shohreh - codecompl...@free.fr a écrit :

Phyks wrote

Le plus simple (et sûr) est de compter le linéaire total (en filtrant les
highways pour ne pas prendre les chemins privés etc) avec le sens de
circulation en prenant :
* La longueur des ways pour les ways à sens unique
* La longueur des ways * 2 pour les ways à double sens (pas de oneway ou
oneway=no)

Bien vu.

Comment faire ?



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

___
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] asso ou groupe de contributeurs OSM en Vendée ?

[Vincent Bergeot]

Le 06/11/2019 à 11:33, Laurence Picado a écrit :


Bonjour,


Bonjour,

une connaissance me demande s'il existe une asso ou un groupe de 
contributeurs OSM en Vendée (cette personne aimerait bien s'initier à 
OSM).


je ne peux que renvoyer sur cette page des évènements (agenda du libre) 
et des groupes locaux "déclarés" (si il en manque ne pas hésiter à le 
signaler, en cliquant sur le à propos de la carte umap, toutes les 
informations sont disponibles)


Mes 2 sous !



Merci d'avance de vos réponses.

Cordialement,

--
Laurence Picado
www.veloetmarche.fr

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



--
Vincent Bergeot

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

Re: [OSM-talk-fr] Outil pour additionner longueur de ways ?

[Shohreh]

Phyks wrote
> Le plus simple (et sûr) est de compter le linéaire total (en filtrant les
> highways pour ne pas prendre les chemins privés etc) avec le sens de
> circulation en prenant :
> * La longueur des ways pour les ways à sens unique
> * La longueur des ways * 2 pour les ways à double sens (pas de oneway ou 
> oneway=no)

Bien vu.

Comment faire ?



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

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

[JB]

Merci, Adrien, pour ce message… Je me sens moins seul.
Je suis convaincu que toutes ces clefs externes sont du genre à rebuter 
un nouvel entrant qui, ne sachant pas ce qu'elles veulent dire, 
préfèreront ne rien toucher que de risquer de tout casser…

JB.

(Apparemment, en 2019, on n'arrive toujours pas à croiser les contrôles 
techniques issus d'OSM avec une base externe sans utiliser un 
identifiant unique ? La clef unique est vraiment la solution de facilité…)


Le 07/11/2019 à 16:14, Adrien André via Talk-fr a écrit :

Le 19-11-07 à 07 h 26, marc marc a écrit :

l'autre "piste" c'est de se demander de l'utilité de la clef mapillary
on y encode la meilleur image dispo au moment de l'encodage.
et puis ?
Pic4review montre bien qu'il n'y a pas besoin de codé en dur l'image,
on peux la récupérer quand on a besoin, sans besoin de maintenance


J'ai toujours eu du mal avec cette tendance des attributs d'OSM à 
devenir le réceptacle des identifiants de toutes les bases externes 
existantes.


Je ne suis pas utilisateur de mapillary, et je me demande ce qui le 
différencie tant des sources habituelles.

Tout comme source=Bing + source:date=20191107,
source=mapillary + source:date=20191107 ne suffit-il pas ?
Pour aller plus loin, et afficher des photos dans une interface, je 
chercherais du coté de

https://www.mapillary.com#gimme=pics=1.234=5.678=20191107

Si on tient à stocker des informations de lien, alors la place de ces 
informations ne serait-elle pas plutôt ailleurs ?
Par exemple, dans des tables (OSM ou base satellite) à part. Tables 
qui pourraient ressembler au brouillon suivant :


type | id| version | database | key
 | - | --- |  | ---
relation | 65606 | 289 | wikidata | Q84
 |   | |  |


database | url  | url_pattern
 |  | 

wikidata | https://www.wikidata.org | 
https://www.wikidata.org/entity/{key}

 |  |

Ceci pouvant également servir à des systèmes spécifiques pour lier 
leurs données avec celles d'OSM.


Les informations sémantiques sur les éléments restent ainsi séparées 
de la donnée technique de lien.
Les interfaces utilisant OSM peuvent s'en servir pour afficher les 
données de bases externes (photos, extraits d'articles, etc).

Et je présume que la maintenance d'openstreetmap.org en serait allégée.





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

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

[Adrien André via Talk-fr]

Le 19-11-07 à 07 h 26, marc marc a écrit :

l'autre "piste" c'est de se demander de l'utilité de la clef mapillary
on y encode la meilleur image dispo au moment de l'encodage.
et puis ?
Pic4review montre bien qu'il n'y a pas besoin de codé en dur l'image,
on peux la récupérer quand on a besoin, sans besoin de maintenance


J'ai toujours eu du mal avec cette tendance des attributs d'OSM à 
devenir le réceptacle des identifiants de toutes les bases externes 
existantes.


Je ne suis pas utilisateur de mapillary, et je me demande ce qui le 
différencie tant des sources habituelles.

Tout comme source=Bing + source:date=20191107,
source=mapillary + source:date=20191107 ne suffit-il pas ?
Pour aller plus loin, et afficher des photos dans une interface, je 
chercherais du coté de

https://www.mapillary.com#gimme=pics=1.234=5.678=20191107

Si on tient à stocker des informations de lien, alors la place de ces 
informations ne serait-elle pas plutôt ailleurs ?
Par exemple, dans des tables (OSM ou base satellite) à part. Tables qui 
pourraient ressembler au brouillon suivant :


type | id    | version | database | key
 | - | --- |  | ---
relation | 65606 | 289 | wikidata | Q84
 |   | |  |


database | url  | url_pattern
 |  | 
wikidata | https://www.wikidata.org | https://www.wikidata.org/entity/{key}
 |  |

Ceci pouvant également servir à des systèmes spécifiques pour lier leurs 
données avec celles d'OSM.


Les informations sémantiques sur les éléments restent ainsi séparées de 
la donnée technique de lien.
Les interfaces utilisant OSM peuvent s'en servir pour afficher les 
données de bases externes (photos, extraits d'articles, etc).

Et je présume que la maintenance d'openstreetmap.org en serait allégée.

--
Adrien



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

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

[Phyks]

Donc qui/pq a-t-on besoin de la clef mapillary dans osm ?
à part pour entraîner une IA, je ne saisis pas quel réutilisation
les contributeur en font, hormis si quelqu'un se passionne par faire
les "match mapillary" et laisse le soin à un autre contributeur
d'ajouter les autres tag osm.


Je m'en suis servi récemment pour argumenter avec une collectivité 
(Montrouge) sur la nécessité d'avoir des données ouvertes et sur la 
qualité des données (stationnements vélos). OSM avait des données bien 
plus complètes que celles que la collectivité a bien voulu nous fournir. 
Face à la méfiance de la mairie envers OSM, je leur ai envoyé un tableau 
(requête Overpass exportée en CSV, avec quelques retouches) des 
stationnements vélos connus d'OSM à Montrouge.


Comme la plupart des stationnements vélos à Montrouge avait une clé 
Mapillary, il leur suffisait de cliquer dans le champ "Image" pour voir 
l'aperçu du parking en direct. C'était, je pense, plutôt convaincant sur 
la qualité des données, même s'il n'y a malheureusement pas 
particulièrement eu de suite...



Le 07.11.19 à 13:49, PanierAvide a écrit :
Pic4Review propose aussi de mettre en avant l'image désignée par la 
clé

mapillary=*, et de changer l'image si une autre est plus
récente/pertinente. Lier explicitement une image à un objet a du sens 
en

terme de réutilisation : plutôt que d'afficher 10 images moches et mal
cadrées, un humain a précisé que cette image est pertinente. Donc 
plutôt

pour l'utilisation de ce tag, et adapter nos outils pour que la donnée
reste à jour.

Adrien P.

Le 07/11/2019 à 13:43, Cyrille37 OSM via Talk-fr a écrit :

Le 07/11/2019 à 13:26, marc marc a écrit :
l'autre "piste" c'est de se demander de l'utilité de la clef 
mapillary

on y encode la meilleur image dispo au moment de l'encodage.
et puis ? demain quelqu'un recapture l'objet, plus à jour ou en 
meilleur

qualité, quelqu'un ou un outil va maintenir cette info à jour ?
quelqu'un cible les objets dans osm ayant la clef mapillary mais 
n'ayant
pas certains clefs (ex typique : l'accessibilité des passages 
piétons).
Pic4review montre bien qu'il n'y a pas besoin de codé en dur 
l'image,

on peux la récupérer quand on a besoin, sans besoin de maintenance


Je partage cet avis.

Cyrille37.


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


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


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


--
Phyks

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

Re: [OSM-talk-fr] Outil pour additionner longueur de ways ?

[Phyks]

Le 2019-11-07 14:43, Shohreh a écrit :

Trouvé : peut-être qu'OTurbo en est capable, mais JOSM peut le faire.

Après avoir ouvert le GPX et l'avoir converti en couche de données, il
suffit de sélectionner toutes les ways par CTRL+A : JOSM affiche le 
total

dans la barre d'état en bas.


Attention, le but est-il bien d'avoir la longueur des ways, ou la 
longueur des rues ?


J'ai récemment essayé de sortir la longueur total des rues d'une ville. 
Il y a une différence car certaines rues sont séparées en plusieurs ways 
dans OSM (terre-plein central par exemple). Le plus simple (et sûr) est 
de compter le linéaire total (en filtrant les highways pour ne pas 
prendre les chemins privés etc) avec le sens de circulation en prenant :

* La longueur des ways pour les ways à sens unique
* La longueur des ways * 2 pour les ways à double sens (pas de oneway ou 
oneway=no)


Bonne journée,
--
Phyks

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

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

[Stéphane Péneau]

Le 07/11/2019 à 14:00, marc marc a écrit :

Cela me plairait de lire s'il y a d'autres utilisations de cette clef.


Lorsque tu fais des vérifications, et qu'il y a cette clé, c'est 
pratique car retrouver la bonne photo n'est pas toujours évident 
(mauvaise géoloc, nbr de photo très important, etc..)


Ensuite, une fois que tu as cette photo, tu peux encore filtrer les 
photos du même lieu en utilisant la date de la photo de la clé.


Exemple concret : le suivi des aménagements cyclables, qui évoluent très 
vite dans certaines zones.


Stf


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

Re: [OSM-talk-fr] Créer relation pour zone bleue stationnement ?

[Yves P.]

Un détail si tu n’es pas spécialiste des requêtes overpass :

> Une requête du type
> 
> // query part for: “"parking:condition:left"=disc”
>  node["parking:condition:left"="disc"](area.searchArea);
>  way["parking:condition:left"="disc"](area.searchArea);
>  relation["parking:condition:left"="disc"](area.searchArea);
>  // query part for: “"parking:condition:right"=disc”
>  node["parking:condition:right"="disc"](area.searchArea);
>  way["parking:condition:right"="disc"](area.searchArea);
>  relation["parking:condition:right"="disc"](area.searchArea);
> 
> devrait fonctionner

Il y a la version assistant. C’est ce que j’utilise 95% du temps.

C’est plus simple et lisible, et on peut même mettre un lien sur la requête 

"parking:condition:right"="disc" or "parking:condition:left"="disc"
https://overpass-turbo.eu/s/NS5

Celle-ci marche aussi (plus lente) :
~"^parking:condition:"~disc

—
Yves

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

Re: [OSM-talk-fr] Outil pour additionner longueur de ways ?

[Yves P.]

> Après avoir ouvert le GPX et l'avoir converti en couche de données, il
> suffit de sélectionner toutes les ways par CTRL+A : JOSM affiche le total
> dans la barre d'état en bas.
Pas besoin de conversion en GPX.

Tu sélectionnes les chemins qui t’intéressent, et la longueur totale s’affiche 
en bas

En tout cas merci pour ta question et ta réponse, je n’avais pas remarqué ça 

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

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

[Yves P.]

@marc
> Bien sur que les outils doivent s'adapter mais pour en faire quoi ?
> Une fois que j'ai sélectionné la meilleur image pour un passage piéton,
> j'ajoute les infos d'accessibilité du passage piéton dans osm.
Oui

> Retrouver la meilleur image n'est plus utile vu que j'en ai extrait
> les infos.
ça sert aussi de source. (Ok, on peut mettre source:mapillary ?)
ça sert à vérifier la qualité de la contribution.

Pour une plaque d’un mémorial, l’inscription n’est souvent pas retranscrite 
complètement.
La photo (mapillary) peut servir à ça…
Rue d’Arménie 


> Donc qui/pq a-t-on besoin de la clef mapillary dans osm ?
> La seule utilité post-contribution que je vois c'est pour les poi,
> Mais sur un passage piéton, il n'y a pas ce besoin, si ?
> 
> Cela me plairait de lire s'il y a d'autres utilisations de cette clef.
J’utilise beaucoup la carte des objets historiques.

C’est intéressant (et aussi important) d’avoir une photo.
Il n’y en a pas toujours sur wiki* et une photo mapillary c’est bien (même mal 
cadrée).

Tient, grâce à cette carte 

 et à Benoît Prieur, j’ai découvert ce que c’est qu’un khatchkar 


Un exemple — quand même — avec une photo mapillary : Widening of Bath Street 
1906 


@Cyrille
> Elle préférait les photos de toitures, il préférait les passages piétons, ils 
> créèrent de nombreuses clé Mapillary.
Bein non, c’est comme la clé image, une seule 

—
Yves

PS: Tient au passage, il n’y a pas (encore ) de clé OpenStreetCam___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Outil pour additionner longueur de ways ?

[Shohreh]

Trouvé : peut-être qu'OTurbo en est capable, mais JOSM peut le faire.

Après avoir ouvert le GPX et l'avoir converti en couche de données, il
suffit de sélectionner toutes les ways par CTRL+A : JOSM affiche le total
dans la barre d'état en bas.



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk-fr] Créer relation pour zone bleue stationnement ?

[Shohreh]

Merci pour les infos.



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

[OSM-talk-fr] Outil pour additionner longueur de ways ?

[Shohreh]

Bonjour,

J'ai besoin de connaître la distance que représente l'ensemble de rues
données.

Idéalement, via une requête à Overpass-Turbo qui calculera lui-même le
résultat, ou alors en downloadant le résultat dans un GPX, en l'ouvrant dans
un logiciel équipé d'une règle qui me permettrait manuellement de mesurer +
additioner toutes les ways.

Merci.



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

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

[PanierAvide]

C'est plus évident l'intérêt pour les POIs, mais qui sait. Si une 
application pour l'accessibilité souhaite montrer à quoi ressemble le 
passage piéton, on sera content de les avoir à disposition ;-)


Adrien P.

Le 07/11/2019 à 14:00, marc marc a écrit :

Bien sur que les outils doivent s'adapter mais pour en faire quoi ?
Une fois que j'ai sélectionné la meilleur image pour un passage piéton,
j'ajoute les infos d'accessibilité du passage piéton dans osm.
Retrouver la meilleur image n'est plus utile vu que j'en ai extrait
les infos.
Donc qui/pq a-t-on besoin de la clef mapillary dans osm ?
à part pour entraîner une IA, je ne saisis pas quel réutilisation
les contributeur en font, hormis si quelqu'un se passionne par faire
les "match mapillary" et laisse le soin à un autre contributeur
d'ajouter les autres tag osm.

La seule utilité post-contribution que je vois c'est pour les poi,
comme le fait GoogleMap (miniature puis lien direct vers StreetView)
Mais sur un passage piéton, il n'y a pas ce besoin, si ?

Cela me plairait de lire s'il y a d'autres utilisations de cette clef.

Le 07.11.19 à 13:49, PanierAvide a écrit :

Pic4Review propose aussi de mettre en avant l'image désignée par la clé
mapillary=*, et de changer l'image si une autre est plus
récente/pertinente. Lier explicitement une image à un objet a du sens en
terme de réutilisation : plutôt que d'afficher 10 images moches et mal
cadrées, un humain a précisé que cette image est pertinente. Donc plutôt
pour l'utilisation de ce tag, et adapter nos outils pour que la donnée
reste à jour.

Adrien P.

Le 07/11/2019 à 13:43, Cyrille37 OSM via Talk-fr a écrit :

Le 07/11/2019 à 13:26, marc marc a écrit :

l'autre "piste" c'est de se demander de l'utilité de la clef mapillary
on y encode la meilleur image dispo au moment de l'encodage.
et puis ? demain quelqu'un recapture l'objet, plus à jour ou en meilleur
qualité, quelqu'un ou un outil va maintenir cette info à jour ?
quelqu'un cible les objets dans osm ayant la clef mapillary mais n'ayant
pas certains clefs (ex typique : l'accessibilité des passages piétons).
Pic4review montre bien qu'il n'y a pas besoin de codé en dur l'image,
on peux la récupérer quand on a besoin, sans besoin de maintenance

Je partage cet avis.

Cyrille37.


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

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

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


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

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

[Yves P.]

> je sais pas s'il est nécessaire d'aller remplir des lignes sur le wiki.
Si tous les lecteurs de cette liste (et tous les contributeurs d’OSM) maitrise 
GitHub, ça ne sert à rien

> un des principaux mainteneur d'osm.org trouve que c'est une mauvaise 
> idée, non pas l'idée en elle-même mais à cause de la maintenance 
> (rajouter et/ou modifier la table de correspondance id <> url).
> surtout que chaque id est à ajouter dans osm.org josm etc
Je ne suis pas sûr de comprendre ?

Tu parles de créer un tableau dans le wiki qui permettrait (automatiquement ou 
manuellement) aux dev de créer ces liens dans le site web d’OSM ?

> Une piste de solution est là :
>> https://github.com/openstreetmap/openstreetmap-website/issues/2405#issuecomment-548917729
Oui, c’est moi qui ai écrit cette requête 

> le plus utile est d'en discuter, de faire un PR
Sur cette liste ?

Pour la PR, vu les commentaires des développeurs ça ne m’encourage pas à le 
faire.
(du style d’un asin sur un pont qui refuse d’avancer ou de reculer )

Il y a quelqu’un qui en a fait une, mais ça ne bouge pas !!

> l'autre "piste" c'est de se demander de l'utilité de la clef mapillary
Oui effectivement.

Mais aussi des clés image, wikimedia_commons, flickr…

> on y encode la meilleur image dispo au moment de l'encodage.
> et puis ? demain quelqu'un recapture l'objet, plus à jour ou en meilleur 
> qualité, quelqu'un ou un outil va maintenir cette info à jour ?
OSM c’est comme un journal, il y a des choix à faire.
On ne peut pas, et on ne veut pas montrer toutes les photos d’un objet (idem 
pour les objets : on ne cartographie pas tout, et on « modélise » la réalité)

> quelqu'un cible les objets dans osm ayant la clef mapillary mais n'ayant 
> pas certains clefs (ex typique : l'accessibilité des passages piétons).
> Pic4review montre bien qu'il n'y a pas besoin de codé en dur l'image,
> on peux la récupérer quand on a besoin, sans besoin de maintenance
il existe actuellement des clés image, mapillary dans la base
et des logiciels et/ou utilisateurs qui s’en servent
regarde les photos d’un lieu sur Google Map : tu vois le blaireau de service 
qui se prend en selfy, son chien, un truc qui n’a rien à voir mais qui était 
photographié le même jour, un truc mal géolocalisé…
pour le moment, le choix « éditorial » reste une bonne option

>> J’ai corrigé 99% des valeurs
> 
> tu parles de ce point ou de tout ?
De mémoire, de tout 

> url du changeset ?
Il y en a plein, j’ai essayé de faire pays par pays… sauf un ou deux loupé.

> fait attention avec les éditions de masse.
oui je me suis fait allumé par un allemand 

> tu ferrais mieux de proposer en premier une modif à l'échelle de la 
> France, ouvrir un ticket josm pour ce qui manque, recevoir des retours
> d'utilisateur en France... avant de vouloir le faire à l'échelle monde
J’ai fait ça à chaud, je pensais bien faire (et oui, l’enfer est pavé…)

Du coup, pour la discussion c’est l’objet de ce mél 

D’un autre coté, un italien content, un allemand qui râle et la majorité qui ne 
s’exprime pas, c’est plutôt positif 

> ouvrir un ticket josm pour ce qui manque, 
?

Cordialement,

—
Yves

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

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

[Cyrille37 OSM via Talk-fr]

Le 07/11/2019 à 13:49, PanierAvide a écrit :
Pic4Review propose aussi de mettre en avant l'image désignée par la 
clé mapillary=*, et de changer l'image si une autre est plus 
récente/pertinente. Lier explicitement une image à un objet a du sens 
en terme de réutilisation : plutôt que d'afficher 10 images moches et 
mal cadrées, un humain a précisé que cette image est pertinente. Donc 
plutôt pour l'utilisation de ce tag, et adapter nos outils pour que la 
donnée reste à jour.



Elle préférait les photos de toitures, il préférait les passages 
piétons, ils créèrent de nombreuses clé Mapillary.


;-)

Cyrille37.




Adrien P.

Le 07/11/2019 à 13:43, Cyrille37 OSM via Talk-fr a écrit :

Le 07/11/2019 à 13:26, marc marc a écrit :

l'autre "piste" c'est de se demander de l'utilité de la clef mapillary
on y encode la meilleur image dispo au moment de l'encodage.
et puis ? demain quelqu'un recapture l'objet, plus à jour ou en 
meilleur

qualité, quelqu'un ou un outil va maintenir cette info à jour ?
quelqu'un cible les objets dans osm ayant la clef mapillary mais 
n'ayant

pas certains clefs (ex typique : l'accessibilité des passages piétons).
Pic4review montre bien qu'il n'y a pas besoin de codé en dur l'image,
on peux la récupérer quand on a besoin, sans besoin de maintenance


Je partage cet avis.

Cyrille37.


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


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


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

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

[marc marc]

Bien sur que les outils doivent s'adapter mais pour en faire quoi ?
Une fois que j'ai sélectionné la meilleur image pour un passage piéton,
j'ajoute les infos d'accessibilité du passage piéton dans osm.
Retrouver la meilleur image n'est plus utile vu que j'en ai extrait
les infos.
Donc qui/pq a-t-on besoin de la clef mapillary dans osm ?
à part pour entraîner une IA, je ne saisis pas quel réutilisation
les contributeur en font, hormis si quelqu'un se passionne par faire
les "match mapillary" et laisse le soin à un autre contributeur 
d'ajouter les autres tag osm.

La seule utilité post-contribution que je vois c'est pour les poi,
comme le fait GoogleMap (miniature puis lien direct vers StreetView)
Mais sur un passage piéton, il n'y a pas ce besoin, si ?

Cela me plairait de lire s'il y a d'autres utilisations de cette clef.

Le 07.11.19 à 13:49, PanierAvide a écrit :
> Pic4Review propose aussi de mettre en avant l'image désignée par la clé 
> mapillary=*, et de changer l'image si une autre est plus 
> récente/pertinente. Lier explicitement une image à un objet a du sens en 
> terme de réutilisation : plutôt que d'afficher 10 images moches et mal 
> cadrées, un humain a précisé que cette image est pertinente. Donc plutôt 
> pour l'utilisation de ce tag, et adapter nos outils pour que la donnée 
> reste à jour.
> 
> Adrien P.
> 
> Le 07/11/2019 à 13:43, Cyrille37 OSM via Talk-fr a écrit :
>> Le 07/11/2019 à 13:26, marc marc a écrit :
>>> l'autre "piste" c'est de se demander de l'utilité de la clef mapillary
>>> on y encode la meilleur image dispo au moment de l'encodage.
>>> et puis ? demain quelqu'un recapture l'objet, plus à jour ou en meilleur
>>> qualité, quelqu'un ou un outil va maintenir cette info à jour ?
>>> quelqu'un cible les objets dans osm ayant la clef mapillary mais n'ayant
>>> pas certains clefs (ex typique : l'accessibilité des passages piétons).
>>> Pic4review montre bien qu'il n'y a pas besoin de codé en dur l'image,
>>> on peux la récupérer quand on a besoin, sans besoin de maintenance
>>
>> Je partage cet avis.
>>
>> Cyrille37.
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

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

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

[PanierAvide]

Pic4Review propose aussi de mettre en avant l'image désignée par la clé 
mapillary=*, et de changer l'image si une autre est plus 
récente/pertinente. Lier explicitement une image à un objet a du sens en 
terme de réutilisation : plutôt que d'afficher 10 images moches et mal 
cadrées, un humain a précisé que cette image est pertinente. Donc plutôt 
pour l'utilisation de ce tag, et adapter nos outils pour que la donnée 
reste à jour.


Adrien P.

Le 07/11/2019 à 13:43, Cyrille37 OSM via Talk-fr a écrit :

Le 07/11/2019 à 13:26, marc marc a écrit :

l'autre "piste" c'est de se demander de l'utilité de la clef mapillary
on y encode la meilleur image dispo au moment de l'encodage.
et puis ? demain quelqu'un recapture l'objet, plus à jour ou en meilleur
qualité, quelqu'un ou un outil va maintenir cette info à jour ?
quelqu'un cible les objets dans osm ayant la clef mapillary mais n'ayant
pas certains clefs (ex typique : l'accessibilité des passages piétons).
Pic4review montre bien qu'il n'y a pas besoin de codé en dur l'image,
on peux la récupérer quand on a besoin, sans besoin de maintenance


Je partage cet avis.

Cyrille37.


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


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

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

[Cyrille37 OSM via Talk-fr]

Le 07/11/2019 à 13:26, marc marc a écrit :

l'autre "piste" c'est de se demander de l'utilité de la clef mapillary
on y encode la meilleur image dispo au moment de l'encodage.
et puis ? demain quelqu'un recapture l'objet, plus à jour ou en meilleur
qualité, quelqu'un ou un outil va maintenir cette info à jour ?
quelqu'un cible les objets dans osm ayant la clef mapillary mais n'ayant
pas certains clefs (ex typique : l'accessibilité des passages piétons).
Pic4review montre bien qu'il n'y a pas besoin de codé en dur l'image,
on peux la récupérer quand on a besoin, sans besoin de maintenance


Je partage cet avis.

Cyrille37.


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

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

[marc marc]

Bonjour,

Le 07.11.19 à 11:48, Yves P. a écrit :
> Il y a aussi le wiki qui permet de s’exprimer (en espérant  
> que les développeurs d’OSM le lisent aussi).

je sais pas s'il est nécessaire d'aller remplir des lignes sur le wiki.
un des principaux mainteneur d'osm.org trouve que c'est une mauvaise 
idée, non pas l'idée en elle-même mais à cause de la maintenance 
(rajouter et/ou modifier la table de correspondance id <> url).
surtout que chaque id est à ajouter dans osm.org josm etc
Une piste de solution est là :
> https://github.com/openstreetmap/openstreetmap-website/issues/2405#issuecomment-548917729
le plus utile est d'en discuter, de faire un PR

l'autre "piste" c'est de se demander de l'utilité de la clef mapillary
on y encode la meilleur image dispo au moment de l'encodage.
et puis ? demain quelqu'un recapture l'objet, plus à jour ou en meilleur 
qualité, quelqu'un ou un outil va maintenir cette info à jour ?
quelqu'un cible les objets dans osm ayant la clef mapillary mais n'ayant 
pas certains clefs (ex typique : l'accessibilité des passages piétons).
Pic4review montre bien qu'il n'y a pas besoin de codé en dur l'image,
on peux la récupérer quand on a besoin, sans besoin de maintenance

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

Re: [OSM-talk-fr] L’enfer est pavé de bonnes intentions

[Yves P.]

> Décryptage du message d'Yves :
> 
> Pensez à dire ce que vous pensez des tickets style :
> https://github.com/openstreetmap/openstreetmap-website/issues/986 
> 
> https://github.com/openstreetmap/openstreetmap-website/issues/2405 
> C’est ça

Par contre tous les lecteurs de cette liste n’ont pas un compte GitHub…

Il y a aussi le wiki qui permet de s’exprimer (en espérant que les développeurs 
d’OSM le lisent aussi).
https://wiki.openstreetmap.org/wiki/Talk:Key:wikimedia_commons#Support_on_the_OSM_website

Ce qui interroge, c’est que les tags wikidata et wikipedia ont un lien, mais 
pas wikimedia_commons (de la même fondation et avec la même syntaxe) ?
https://www.openstreetmap.org/way/62280106

Je vous invite aussi à donner votre avis à propos de la syntaxe du tag 
wikimedia_commons qui permet de spécifier un fichier ET une catégorie :
https://wiki.openstreetmap.org/wiki/Talk:Key:wikimedia_commons#Why_Category%3A.23.2Fmedia.2FFile%3A_syntax_is_Controversial_.3F

Comme l’a rappelé notre colibri du jour, il y a aussi les clés suivantes qui 
mériteraient d’être affichées correctement par le site web d’OSM :
openplaques:id  
openstreetmap-website#2405 

mapillary  
openstreetmap-website#986 


Cette liste n’est pas exhaustive : n’hésitez pas à en proposer d’autres 
> Ou mieux si vous pouvez proposez un PR !
> 


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