Re: [OSM-talk-fr] Comment restaurer des données supprimée

2020-06-29 Par sujet PanierAvide

Bonjour,

Pour référence : https://wiki.openstreetmap.org/wiki/Change_rollback

Et dans ce cas là, à priori le plus simple est le plugin "undelete" de 
JOSM https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Undelete


Cordialement,

Adrien P.

Le 30/06/2020 à 06:33, Gad Jo a écrit :

Bonjour,


J'ai fait une suppression malheureuse mais je m'en rend compte très 
tardivement. La zone est très limité. Sur deux immeubles.


C'est plus simple de refaire un import du cadastre mais je demande ça 
aussi pour apprendre comment répondre à cette étude de cas.


J'ai posté la demande sur le forum pour que le plus grand nombre 
profite de la réponse mais sans succès depuis depuis mai.


Est-ce qu'une personne aurait une solution ?
https://forum.openstreetmap.fr/viewtopic.php?f=5=7400
--
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma 
brièveté.


___
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] Noms des quartiers en ville

2020-06-29 Par sujet Arnaud Champollion

Bonjour,

Je viens de constater un phénomène en partageant une adresse avec 
l'application Osmand.


Quand on sélectionne cette position :
https://www.openstreetmap.org/?mlat=44.08165=6.20359#map=19/44.08165/6.20359

on obtient le libellé suivant :

Chemin des Gravas (Le Plan de Gaubert) 14, Digne-les-Bains
Position: geo:44.081646,6.20359?z=19
https://osmand.net/go?lat=44.081646=6.20359=19

Je m'interroge sur "Le Plan de Gaubert" qui est certes un quartier de la 
ville, mais pas le bon. Il en est même relativement éloigné du point de 
vue de l'organisation de la ville, même si proche à vol d'oiseau.


Est-ce parce-que "Le Plan de Gaubert" est le place=hamlet le plus proche ?

Si oui, faut-il créer un place=hamlet "Les Sieyes" qui est le quartier 
du lieu correspondant à la position donnée ?


Et comment limiter la "portée" d'un place=hamlet pour qu'il ne soit pas 
pris en compte par défaut dans d'autres parties de la ville qui en sont 
dépourvues ?


Merci

Arnaud




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


[OSM-talk-fr] Comment restaurer des données supprimée

2020-06-29 Par sujet Gad Jo
Bonjour,


J'ai fait une suppression malheureuse mais je m'en rend compte très 
tardivement. La zone est très limité. Sur deux immeubles.

C'est plus simple de refaire un import du cadastre mais je demande ça aussi 
pour apprendre comment répondre à cette étude de cas.

J'ai posté la demande sur le forum pour que le plus grand nombre profite de la 
réponse mais sans succès depuis depuis mai.

Est-ce qu'une personne aurait une solution ?
https://forum.openstreetmap.fr/viewtopic.php?f=5=7400
-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-06-29 Par sujet Jérôme Amagat
Ces contact:*=* c'est pour avoir un unique objet par adresse, le plus
souvent un node qui représente seulement une adresse mais pas
obligatoirement. Mais les addr:*=* des cinémas sont surement pour bon
nombre d'entre elles déjà uniques donc les changer en contact:*=* fera
disparaître des adresses de osm.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] FTTH Références à fignoler

2020-06-29 Par sujet Jacques Lavignotte



Le 29/06/2020 à 22:37, François Lacombe a écrit :

Bonsoir à vous


Merci François :)

--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

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


Re: [OSM-talk-fr] Alternatives à Mapillary

2020-06-29 Par sujet Tyndare


Le 29/06/2020 à 23:45, Frédéric Rodrigo a écrit :
> Je n'ai pas fait le floutage, ou la séparation des classes, juste la
> détection. Je suis toujours preneur si tu as quelque chose.

Je viens de mettre mon script sur github:
https://github.com/tyndare/blur-persons


> Cerise sur le gâteau ce n'est même pas si lent que ça même sans GPU...

Le modèle travaille sur des image de 512x512, donc je répète la 
détection autant de fois que nécessaire sur l'image source, du coup 
c'est très lent chez moi (j'ai pas réussi à refaire marche tensorflow 
sur le GPU de mon portable).




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


Re: [OSM-talk-fr] Alternatives à Mapillary

2020-06-29 Par sujet Frédéric Rodrigo

Le 29/06/2020 à 07:20, Tyndare a écrit :

Le June 28, 2020 8:14:03 PM UTC, "Frédéric Rodrigo"  a 
écrit :

Le 22/06/2020 à 22:59, Tyndare a écrit :

https://averdones.github.io/real-time-semantic-image-segmentation-with-deeplab-in-tensorflow/

Tu as un script/outil prêt à l’emploi pour faire ça ?

J'ai un script python pour flouter les personnes en téléchargeant et lançant le 
réseau que j'ai mentionné mais il faut que je le nettoie (il est codé en dur 
pour la taille de mes photos).
J'essaye de le partager ce soir.


J'ai bidouillé le tuto pour le faire marcher la détection sur des photo. 
Ça marche vraiment mieux que tout ce que j'ai pu tester.


Je n'ai pas fait le floutage, ou la séparation des classes, juste la 
détection. Je suis toujours preneur si tu as quelque chose.


Cerise sur le gâteau ce n'est même pas si lent que ça même sans GPU... 
par contre c'est gros à installer.


Frédéric.


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


Re: [OSM-talk-fr] Comptage d'objets avec overpass

2020-06-29 Par sujet Marc M.
Le 29.06.20 à 22:34, Florian LAINEZ a écrit :
> j'ai 8 cinémas https://overpass-turbo.eu/s/Vzp

non ce n'est pas ce que tu as demandé dans ta requête
avec (._;>;); tu demandes aussi tous les objets "enfants"
cad les noeuds des ways qui les composent
du coup le comptage les contient.

je sort la hache pour virer tout ce qui n'est pas utile
https://overpass-turbo.eu/s/VAD
résultat 4 nœuds 4 chemins = 8 :)
a noter que out count est encore plus clair pour faire
des stats https://overpass-turbo.eu/s/VAE

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


Re: [OSM-talk-fr] Comptage d'objets avec overpass

2020-06-29 Par sujet Éric Gillet

Le 29/06/2020 à 22:34, Florian LAINEZ a écrit :
Je n'arrive -toujours pas !- à comprendre comment extraire des stats 
fiables avec overpass.
Par exemple, là j'ai 8 cinémas https://overpass-turbo.eu/s/Vzp et en 
bas de la page d'overpass ce n'est pas le bon chiffre. Où le trouver ?
Pourtant il ne devait pas y avoir de piège, il n'y a pas de relation, 
rien de complexe.

Du coup je pense que toutes mes stats antérieures sont fausses.

Mais pourquoi diable overpass n'affiche-t-il pas de manière évidente 
le comptage des objets requêtés ? Un simple chiffre, simple, efficace, 
vrai.


Si tu veux avoir le nombre d'objets, tu as le mode de sortie "count". 
Exemple : https://overpass-turbo.eu/s/VAA



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


Re: [OSM-talk-fr] FTTH Références à fignoler

2020-06-29 Par sujet François Lacombe
Bonsoir à vous

C'est surement un NRO SFR
Oui SFR a la technologie pour mettre ses NRO en armoire.

G2R est en tout cas le référentiel infrastructure de SFR.
ref:FR:SFR est déjà utilisé pour le FTTH avec des références différentes.
Je serais presque d'avis d'utiliser ref:FR:G2R ou ref:FR:SFR_G2R (moins fan
de la deuxième)

Donc
man_made=street_cabinet
utility=telecom
telecom=exchange
telecom:medium=fibre
ref:FR:SFR=PTI1
ref:FR:G2R=861604

Qu'en pensez-vous ?

François

Le lun. 29 juin 2020 à 17:40, Éric Gillet  a
écrit :

> Le 28/06/2020 à 14:55, Jacques Lavignotte a écrit :
> > Je l'ai posée au bon endroit :
> >
> > https://www.openstreetmap.org/node/7660605456
> >
> > Aidez-moi à compléter les  et les 
> >
> > Merci, Jacques
> >
> Je connais pas ce domaine spécifiquement, mais je pense qu'il vaut mieux
> ne pas mettre les références plutôt que mettre des placeholders qui vont
> masquer le manque d'infos. Au minimum il faudrait mettre un tag fixme à
> mon avis.
>
>
> ___
> 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] Salle de spectacle

2020-06-29 Par sujet Christian Rogel
> Le 29 juin 2020 à 21:52, Donat ROBAUX  a écrit :
> Je dirai que la distinction se fait sur le fait que les installations de la 
> salle de spectacle est en dur ou pas, c'est-à-dire que les sièges, la scène 
> sont inamovibles (comme un cinéma). Dans ce cas amenity=theatre, sinon 
> amenity=community_centre. Dans la plupart des communes de petite taille ou 
> même moyenne, ce sont quand même plus des salles polyvalentes que des salles 
> de spectacles.
> Concernant ce tag  amenity=events_venue, je ne le connaissais pas et pour 
> cause, c'est une ébauche. Honnêtement pour moi ca ferait doublon avec  
> community_centre sauf si c'est un lieu dédié à ca, ce qui est rarement le 
> cas, sauf peut-être chez des prestataires privés.


Justement, community_centre vise bien les salles, qui en plus de leur fonction 
d’accueillir des réunions publiques et privées, des spectacles sont 
susceptibles d’héberger des activités socio-culturelles permanentes.

Une autre case est l’ art_centre qui sera plus tourné vers la fonction 
culturelle (pas seulement les beaux-arts)

Enfin, amenity = events_venue concerne justement ces prestataires privés qui 
accueillent des réunions privées (mariages, réunions professionneles, 
séminaires) sans avoir de salle de spectacle

amenity = conference_centre n’est qu’une proposition, mais passablement 
utilisée.


Il y a aussi 2 propositions encore peu utilisées et qui se recoupent, car elles 
visent les parcs d’exposition, mais, aussi les centres de congrès. :

events_centre
exhibitions_centre

Et les « arenas » qui sont et pour le sportif et pour le culturel ?



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


[OSM-talk-fr] Comptage d'objets avec overpass

2020-06-29 Par sujet Florian LAINEZ
Hey,
Je n'arrive -toujours pas !- à comprendre comment extraire des stats
fiables avec overpass.
Par exemple, là j'ai 8 cinémas https://overpass-turbo.eu/s/Vzp et en bas de
la page d'overpass ce n'est pas le bon chiffre. Où le trouver ?
Pourtant il ne devait pas y avoir de piège, il n'y a pas de relation, rien
de complexe.
Du coup je pense que toutes mes stats antérieures sont fausses.

Mais pourquoi diable overpass n'affiche-t-il pas de manière évidente le
comptage des objets requêtés ? Un simple chiffre, simple, efficace, vrai.
Les développeurs d'overpass ont-il adopté la méthode de dev de Steve Ballmer
 ?
Tant de questions sans réponses ...

-- 

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


Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-06-29 Par sujet osm . sanspourriel

STOP !

Malgré ce qui précède je suis pour.

Mais avec précautions.

Je vais à nouveau de me faire avoir avec iD. Tu me diras qu'en utilisant
iD il ne faut pas se plaindre après.

Un cinéma était donné comme étant le chemin building=yes.

Id propose de l'extraire.

Sans toucher à la relation associatedStreet.

Du coup je me suis retrouvé avec un membre house sans addr:housenumber
ou addr:housename. Heureusement Osmose est passé derrière.

Là tu risques d'avoir le même problème : il ne faut pas perdre d'adresse.

Si le cinéma est dans une associatedStreet il faut créer un point
d'adresse dans le bâtiment ayant cette adresse, le mettre dans la
relation, supprimer le cinéma de la relation puis roule ma poule.

Yves : en France on veut l'unicité des points adresse.

Jean-Yvon

Le 29/06/2020 à 22:03, Florian LAINEZ - winner...@free.fr a écrit :

Hello,
On avance bien sur le référencement des cinémas en france et leur
publication sur
https://www.data.gouv.fr/fr/datasets/cinemas-issus-dopenstreetmap et
il est temps de s'occuper de leurs adresses.

Comme beaucoup d'entre vous le savent, en france, une décision
communautaire est de créer un node séparé du cinéma (ou de tout autre
POI) pour indiquer sont adresse.
En conséquence, en théorie, les tags suivants n'ont pas leur place sur
les objets amenity=cinema : addr:housenumber, addr:street,
addr:postcode, addr:city ainsi que les autres tags commençant par
"addr". Ces informations doivent apparaître sur un nœud séparé.

En conséquence, dans la ville de Montrouge, on a déjà fait le choix de
passer toutes les addr en contact (voir la discussion
).
/exemple : addr:housenumber=* en contact:housenumber=*
/

Le problème principal de cette solution est la non-comptabilité avec
les éditeurs iD et Maps.Me, qui proposent tous les 2 la seule édition
des adresses formatées de manière standard.
Malgré cette limitation je compte respecter la décision (très
européano-centrée
) de
la communauté Française et en conséquence changer sur tous les cinémas :
addr:housenumber -> contact:housenumber
addr:housename -> contact:housename
addr:street -> contact:street
addr:postcode -> contact:postcode
addr:city -> contact:city
addr:district -> contact:district
addr:place -> contact:place
addr:suburb -> contact:suburb
addr:territoire -> contact:territoire
addr:unit -> contact:unit

Je suis preneur d'éventuels commentaires avant de lancer l'édition de
masse avec le compte "overflorian-mass-edits".

--

*Florian Lainez*

@overflorian 

___
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] édition en masse sur les adresses des cinémas

2020-06-29 Par sujet Yves P.
> Malgré cette limitation je compte respecter la décision (très 
> européano-centrée 
> ) de la 
> communauté Française et en conséquence changer sur tous les cinémas :
> addr:housenumber -> contact:housenumber
> addr:housename -> contact:housename
> …

Autre décision franco-française ? Un effet de bord de la première ?
Je ne suis pas chaud.

Dans le cas des cinoches, on a l'adresse dans le fichier du CNC.
On peut déjà comparer celle-ci avec les quelques tags addr:*=* déjà dans OSM 
(normalement ça doit être identique) ou les quelques adresses dans wikidata.
Et surtout, comparer avec un géocodage inversé.

Si effectivement il y a de grosses différences, voir si l'agit d'un point 
adresse régle le problème.
Si non, se résoudre à mettre des tags adresses et à les faire accepter par la 
communauté mondiale et les développeurs d'éditeurs.

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


Re: [OSM-talk-fr] preset Défibrillateur dans JOSM et iD

2020-06-29 Par sujet Yves P.
> Tu as regardé la page française sur les défibrillateurs?
Non, pas depuis quelques mois voir années ;)

> J'y ai retranscris toutes les informations du décret sur la base de données 
> nationale des DAE (avec quelques propositions à débattre pour les tags que 
> j'ai dû inventer).
Super :)

> Ca vaudrait le coup de faire un preset version France.
Je pensais effectivement à un système de presets nationaux (facile dans JOSM, 
possible dans iD??)

Mais revoir les presets JOSM et iD pour les harmoniser ne ferait pas de mal.
Et puis à part nos spécificités réglementaires, il doit y avoir des infos 
universelles comme une description générale du lieu, et plus détaillée, de même 
que l'accès H24 ou pas.

__
Yves

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


[OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-06-29 Par sujet Florian LAINEZ
Hello,
On avance bien sur le référencement des cinémas en france et leur
publication sur
https://www.data.gouv.fr/fr/datasets/cinemas-issus-dopenstreetmap et il est
temps de s'occuper de leurs adresses.

Comme beaucoup d'entre vous le savent, en france, une décision
communautaire est de créer un node séparé du cinéma (ou de tout autre POI)
pour indiquer sont adresse.
En conséquence, en théorie, les tags suivants n'ont pas leur place sur les
objets amenity=cinema : addr:housenumber, addr:street, addr:postcode,
addr:city ainsi que les autres tags commençant par "addr". Ces informations
doivent apparaître sur un nœud séparé.

En conséquence, dans la ville de Montrouge, on a déjà fait le choix de
passer toutes les addr en contact (voir la discussion
).

*exemple : addr:housenumber=* en contact:housenumber=* *

Le problème principal de cette solution est la non-comptabilité avec les
éditeurs iD et Maps.Me, qui proposent tous les 2 la seule édition des
adresses formatées de manière standard.
Malgré cette limitation je compte respecter la décision (très
européano-centrée
) de la
communauté Française et en conséquence changer sur tous les cinémas :
addr:housenumber -> contact:housenumber
addr:housename -> contact:housename
addr:street -> contact:street
addr:postcode -> contact:postcode
addr:city -> contact:city
addr:district -> contact:district
addr:place -> contact:place
addr:suburb -> contact:suburb
addr:territoire -> contact:territoire
addr:unit -> contact:unit

Je suis preneur d'éventuels commentaires avant de lancer l'édition de masse
avec le compte "overflorian-mass-edits".

-- 

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


Re: [OSM-talk-fr] Salle de spectacle

2020-06-29 Par sujet Yves P.
> Je dirai que la distinction se fait sur le fait que les installations de la 
> salle de spectacle est en dur ou pas, c'est-à-dire que les sièges, la scène 
> sont inamovibles
C'est clair, merci :)

> Concernant ce tag  amenity=events_venue, je ne le connaissais pas et pour 
> cause, c'est une ébauche.
Ok.

> Honnêtement pour moi ca ferait doublon avec  community_centre sauf si c'est 
> un lieu dédié à ca, ce qui est rarement le cas, sauf peut-être chez des 
> prestataires privés.
Il me semble que le terme vient des anglo-saxons.
Venue : the place where something happens, especially an organized event such 
as a concert, conference, or sports competition: the club is the city's main 
venue for live music. 

Mais il me semble que ça désigne un lieu comme les Zénith. 
https://en.wikipedia.org/w/index.php?title=Music_venue

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


Re: [OSM-talk-fr] preset Défibrillateur dans JOSM et iD

2020-06-29 Par sujet Donat ROBAUX
Yves,

Tu as regardé la page française sur les défibrillateurs?
J'y ai retranscris toutes les informations du décret sur la base de données
nationale des DAE (avec quelques propositions à débattre pour les tags que
j'ai dû inventer).
Ca vaudrait le coup de faire un preset version France.

Donat

>
> -- Forwarded message --
> From: "Yves P." 
> To: "Discussion OSM en français" 
> Cc:
> Bcc:
> Date: Mon, 29 Jun 2020 18:28:15 +0200
> Subject: [OSM-talk-fr] preset Défibrillateur dans JOSM et iD  略
> Bonsoir,
>
> Dans JOSM : 略 "Tous modes de transport : " pas top pour indiquer (dans de
> rares cas ?) si un défibrillateur est "privé".
>
> L'ergonomie n'est pas des plus lumineuses : "Situé à l'intérieur d'un
> bâtiment ?" coché / décoché / grisé.
> On pourrait mettre 2 ou 3 boutons radios : intérieur / extérieur / inconnu
>
> C'est guerre mieux dans iD pour "intérieur".
>
> iD propose par défaut le tag "Code d'identification" (pour la référence)
> (mais pas JOSM).
>
> Quelles informations importantes faut-il saisir pour un défibrillateur ?
> Et dans quel tags ?
>
> __
> Yves
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Poteaux de randonnée aux tags "baroques" dans le Vaucluse

2020-06-29 Par sujet Yves P.
> - Yves, pourquoi tu as supprimé la N 4 ?
> 
Je ne sais pas. Un clic de trop ?
As-tu un lien ?
> - Il y avait des photos Mapillary qui montraient que là il y avait une route 
> et on voyait que c'était la N 4.
> 
Idem
> MdR. Bah, on connait bien des utilisateurs expérimentés qui remplacent des 
> baies représentées par des multi-polygones par des points…
> 
:D

>> Dans ce cas, il me semble que non. Que va faire un calculateur d'itinéraire 
>> avec la position d'un poteau sur le trottoir, dans l'herbe ou au dessus de 
>> la chaussée ?
> Ben si : toi, TU n'as pas besoin de ça pour avoir TON itinéraire.
> 
Je cherche mais je ne vois pas le rapport.
> Mais OSM ce n'est pas fait juste pour qu'Yves puisse faire SA randonnée.
> 
On est d'accord.

Plus sérieusement, dans les "Alpes" les itinéraires de rando sont décrit de 
poteaux indicateurs en poteaux indicateurs, avec un nom de lieu-dit et une 
altitude.
C'est ça le repère.
Dans le Vaucluse et les Hautes-Alpes ça semble identique. Les panneaux sont 
comment en Bretagne ?
> start_date, oui c'est moins utile que pour un bâtiment mais si le département 
> utilise OSM pour trouver les poteaux en bois plantés dans l'herbe qui datent 
> de 1994 parce qu'ils sont à remplacer, la base de certains pourrissant, j'ai 
> du mal à voir où est le mal.
> 
Je ne disais pas que c'est mal, mais que je n'en voyais pas l'usage.
Je ne met (presque) plus de smileys pour modérer mon propos, ça agace au moins 
sur IRC.

Et surtout à la base, j'ai été surpris par cette quantité de tags pour un 
simple poteau.
Ça fait de la lecture :D
> En plus tu cherches à libérer des données poteaux, ne va pas reprocher aux 
> gens de mettre ces informations dans OSM, c'est contre productif.
> 
> A-t-on vu un utilisateur utiliser la référence STIF/IdFM des arrêts de bus ? 
> Est-ce pour autant inutile ?
> 
L'intérêt des tags ref:xyz c'est de faire le lien entre un objet OSM et une 
base de données externe (ici "métier").
Doit-on mettre tous les champs d'une BDD dans OSM ?
SI OSM est LA base de données partagée par plusieurs acteurs, pourquoi pas.

En poussant le raisonnement à l'extrême, on va mettre dans OSM l'intégralité 
des données GTFS (arrêts et lignes de bus, horaires…) ?
> Si tu ne veux pas dans ta base avoir les dates des poteaux, en une requête 
> SQL tu as fait le ménage chez toi pour toi.
> 
J'aimerais avoir l'exhaustivité des poteaux, éventuellement avec une photo 
lisible… avant d'avoir des détails sur la marque, le modèle, date de 
fabrication et n° de série de quelques poteaux.
Les randonneurs ont avant tout besoin des poteaux sur la carte :)
> Au début il n'y avait pas 279 building=yes non plus ;-).
> 
Je suis d'accord avec Marc, il faut peut-être revoir les applis… mais j'ai été 
pas mal échaudé. Je ne me fais pas trop d'illusions.
> Ceci dit le problème est un tag mapillary:wide dont on n'a pas la définition 
> et on ne sait si ça veut dire "photo d'ensemble, pris de loin" ou "photo 
> panoramique".
> 
> Du coup peu utilisé et peu utilisable.
> 
> Peu utile à mon avis aussi.
> 
Avec mon expérience des PEI (tient, encore des poteaux :D) il faut en pratique 
les 2.
Une photo pour situer un objet (poteau, borne incendie, fontaine…) qui sert à 
le retrouver dans la réalité, vérifier qu'il est à sa place lors de l'édition.
Une photo de pied. Elle est plus lisible dans une application, et elle permet 
de voir l'état d'un objet, des détails comme une référence.
Et dans certains cas des photos additionnelles…
> Après du Mapillary multi-valeur est peu utile, on va vouloir "la" meilleure 
> photo. Et bien sûr suivant ses propres critères^^.
> 
OSM Hydrant permet d'afficher 1, 2 ou plusieurs photos, mais avec des 
"template" dans les photos Wikimedia : 
https://commons.wikimedia.org/wiki/File:Fire-fighting-facility_node-4750331829.jpg
Du coup coté OSM le tag wikimedia_commons n'est pas renseigné, et ça oblige à 
faire des requêtes côté wikimedia en plus des requêtes overpass coté OSM :/

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


Re: [OSM-talk-fr] Salle de spectacle

2020-06-29 Par sujet Donat ROBAUX
Salut Yves,

Je dirai que la distinction se fait sur le fait que les installations de la
salle de spectacle est en dur ou pas, c'est-à-dire que les sièges, la scène
sont inamovibles (comme un cinéma). Dans ce cas amenity=theatre, sinon
amenity=community_centre. Dans la plupart des communes de petite taille ou
même moyenne, ce sont quand même plus des salles polyvalentes que des
salles de spectacles.
Concernant ce tag  amenity=events_venue, je ne le connaissais pas et pour
cause, c'est une ébauche. Honnêtement pour moi ca ferait doublon avec
community_centre sauf si c'est un lieu dédié à ca, ce qui est rarement le
cas, sauf peut-être chez des prestataires privés.

Donat




> -- Forwarded message --
> From: "Yves P." 
> To: "Discussion OSM en français" 
> Cc:
> Bcc:
> Date: Mon, 29 Jun 2020 18:09:32 +0200
> Subject: [OSM-talk-fr] Salle de spectacle
> Bonjour,
>
> Pour une salle de spectacle, on met quoi ?
>
> amenity=community_centre
>  (une
> salle polyvalente, une salle des fêtes)
> amenity=theatre
>  +
> theatre:genre=variety
> amenity=events_venue
> 
>
> C'est l'ancienne salle des fêtes d'un village qui est devenue salle de
> spectacle.
>
> __
> Yves
>
>
>
> -- Forwarded message --
> From: "Yves P." 
> To: "Discussion OSM en français" 
> Cc:
> Bcc:
> Date: Mon, 29 Jun 2020 18:28:15 +0200
> Subject: [OSM-talk-fr] preset Défibrillateur dans JOSM et iD  略
> Bonsoir,
>
> Dans JOSM : 略 "Tous modes de transport : " pas top pour indiquer (dans de
> rares cas ?) si un défibrillateur est "privé".
>
> L'ergonomie n'est pas des plus lumineuses : "Situé à l'intérieur d'un
> bâtiment ?" coché / décoché / grisé.
> On pourrait mettre 2 ou 3 boutons radios : intérieur / extérieur / inconnu
>
> C'est guerre mieux dans iD pour "intérieur".
>
> iD propose par défaut le tag "Code d'identification" (pour la référence)
> (mais pas JOSM).
>
> Quelles informations importantes faut-il saisir pour un défibrillateur ?
> Et dans quel tags ?
>
> __
> Yves
>
>
>
>
> -- Forwarded message --
> From: osm.sanspourr...@spamgourmet.com
> To: talk-fr@openstreetmap.org
> Cc:
> Bcc:
> Date: Mon, 29 Jun 2020 21:16:38 +0200
> Subject: Re: [OSM-talk-fr]  Poteaux de randonnée aux tags "baroques" dans
> le Vaucluse
> Le 29/06/2020 à 11:48, Vincent Bergeot - vinc...@bergeot.org a écrit :
>
> Le 29/06/2020 à 11:04, Yves P. a écrit :
>
> - pole:position=green : je ne comprends pas ce tag, et je n'ai rien trouvé
> dans le wiki. Quelqu'un peut-il expliquer ?
>
> c'est par analogie avec fire_hydrant:position
> 
> =lane/parking_lot/sidewalk/green
>
> C'est utile quand la précision des coordonnées est mauvaise ou en
> l'absence de photo de situation, sinon complètement inutile.
>
> je ne pense pas que la présence d'une photo soit un argument pour sortir
> une donnée car il est plus facile il me semble d'utiliser une donnée pour
> du routing ou de la synthèse vocale par exemple (d'autant plus pour les cas
> où l'on ne peut pas voir la photo).
>
> - Yves, pourquoi tu as supprimé la N 4 ?
>
> - Il y avait des photos Mapillary qui montraient que là il y avait une
> route et on voyait que c'était la N 4.
>
> MdR. Bah, on connait bien des utilisateurs expérimentés qui remplacent des
> baies représentées par des multi-polygones par des points...
>
> La pertinence du tag en lui-même je ne sais pas.
>
>
> Le 29/06/2020 à 11:54, Yves P. - yves.prat...@gmail.com a écrit :
>
> Dans ce cas, il me semble que non. Que va faire un calculateur
> d'itinéraire avec la position d'un poteau sur le trottoir, dans l'herbe ou
> au dessus de la chaussée ?
>
> Ben si : toi, TU n'as pas besoin de ça pour avoir TON itinéraire.
>
> Mais OSM ce n'est pas fait juste pour qu'Yves puisse faire SA randonnée.
>
> start_date, oui c'est moins utile que pour un bâtiment mais si le
> département utilise OSM pour trouver les poteaux en bois plantés dans
> l'herbe qui datent de 1994 parce qu'ils sont à remplacer, la base de
> certains pourrissant, j'ai du mal à voir où est le mal. En plus tu cherches
> à libérer des données poteaux, ne va pas reprocher aux gens de mettre ces
> informations dans OSM, c'est contre productif.
>
> A-t-on vu un utilisateur utiliser la référence STIF/IdFM des arrêts de bus
> ? Est-ce pour autant inutile ?
>
> Si tu ne veux pas dans ta base avoir les dates des poteaux, en une requête
> SQL tu as fait le ménage chez toi pour toi.
>
> > Pas sûr que les devs en tiennent compte pour 279 tags, mapillary en plus
> !
>
> Au début il n'y avait pas 279 building=yes non plus ;-).
>
> Ceci dit le problème est un tag mapillary:wide dont on n'a pas la
> définition et on ne sait si ça veut dire "photo d'ensemble, pris de loin"
> ou "photo panoramique".
>
> Du coup peu 

Re: [OSM-talk-fr] Poteaux de randonnée aux tags "baroques" dans le Vaucluse

2020-06-29 Par sujet osm . sanspourriel

Le 29/06/2020 à 11:48, Vincent Bergeot - vinc...@bergeot.org a écrit :

Le 29/06/2020 à 11:04, Yves P. a écrit :

- pole:position=green : je ne comprends pas ce tag, et je n'ai rien
trouvé dans le wiki. Quelqu'un peut-il expliquer ?

c'est par analogie avec fire_hydrant:position
=lane/parking_lot/sidewalk/green

C'est utile quand la précision des coordonnées est mauvaise ou en
l'absence de photo de situation, sinon complètement inutile.


je ne pense pas que la présence d'une photo soit un argument pour
sortir une donnée car il est plus facile il me semble d'utiliser une
donnée pour du routing ou de la synthèse vocale par exemple (d'autant
plus pour les cas où l'on ne peut pas voir la photo).


- Yves, pourquoi tu as supprimé la N 4 ?

- Il y avait des photos Mapillary qui montraient que là il y avait une
route et on voyait que c'était la N 4.

MdR. Bah, on connait bien des utilisateurs expérimentés qui remplacent
des baies représentées par des multi-polygones par des points...


La pertinence du tag en lui-même je ne sais pas.



Le 29/06/2020 à 11:54, Yves P. - yves.prat...@gmail.com a écrit :

Dans ce cas, il me semble que non. Que va faire un calculateur
d'itinéraire avec la position d'un poteau sur le trottoir, dans
l'herbe ou au dessus de la chaussée ?


Ben si : toi, TU n'as pas besoin de ça pour avoir TON itinéraire.

Mais OSM ce n'est pas fait juste pour qu'Yves puisse faire SA randonnée.

start_date, oui c'est moins utile que pour un bâtiment mais si le
département utilise OSM pour trouver les poteaux en bois plantés dans
l'herbe qui datent de 1994 parce qu'ils sont à remplacer, la base de
certains pourrissant, j'ai du mal à voir où est le mal. En plus tu
cherches à libérer des données poteaux, ne va pas reprocher aux gens de
mettre ces informations dans OSM, c'est contre productif.

A-t-on vu un utilisateur utiliser la référence STIF/IdFM des arrêts de
bus ? Est-ce pour autant inutile ?

Si tu ne veux pas dans ta base avoir les dates des poteaux, en une
requête SQL tu as fait le ménage chez toi pour toi.

> Pas sûr que les devs en tiennent compte pour 279 tags, mapillary en
plus !

Au début il n'y avait pas 279 building=yes non plus ;-).

Ceci dit le problème est un tag mapillary:wide dont on n'a pas la
définition et on ne sait si ça veut dire "photo d'ensemble, pris de
loin" ou "photo panoramique".

Du coup peu utilisé et peu utilisable.

Peu utile à mon avis aussi.

Après du Mapillary multi-valeur est peu utile, on va vouloir "la"
meilleure photo. Et bien sûr suivant ses propres critères^^.

Jean-Yvon

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


[OSM-talk-fr] preset Défibrillateur dans JOSM et iD 略

2020-06-29 Par sujet Yves P.
Bonsoir,

Dans JOSM : 略 "Tous modes de transport : " pas top pour indiquer (dans de rares 
cas ?) si un défibrillateur est "privé".

L'ergonomie n'est pas des plus lumineuses : "Situé à l'intérieur d'un bâtiment 
?" coché / décoché / grisé.
On pourrait mettre 2 ou 3 boutons radios : intérieur / extérieur / inconnu

C'est guerre mieux dans iD pour "intérieur".

iD propose par défaut le tag "Code d'identification" (pour la référence) (mais 
pas JOSM).

Quelles informations importantes faut-il saisir pour un défibrillateur ?
Et dans quel tags ?

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


[OSM-talk-fr] Salle de spectacle

2020-06-29 Par sujet Yves P.
Bonjour,

Pour une salle de spectacle, on met quoi ?

amenity=community_centre 
 (une 
salle polyvalente, une salle des fêtes)
amenity=theatre 
 + 
theatre:genre=variety 
amenity=events_venue 


C'est l'ancienne salle des fêtes d'un village qui est devenue salle de 
spectacle.

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


Re: [OSM-talk-fr] Enquête usagers data.gouv.fr

2020-06-29 Par sujet Éric Gillet

Le 29/06/2020 à 11:56, Magalie Dartus a écrit :
D'ailleurs je vous invite à répondre au questionnaire usagers : 
https://framaforms.org/enquete-datagouvfr-usagers-1590438305


Les avis de la communauté seront très utiles.

Merci pour le partage !

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


Re: [OSM-talk-fr] FTTH Références à fignoler

2020-06-29 Par sujet Éric Gillet

Le 28/06/2020 à 14:55, Jacques Lavignotte a écrit :

Je l'ai posée au bon endroit :

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

Aidez-moi à compléter les  et les 

Merci, Jacques

Je connais pas ce domaine spécifiquement, mais je pense qu'il vaut mieux 
ne pas mettre les références plutôt que mettre des placeholders qui vont 
masquer le manque d'infos. Au minimum il faudrait mettre un tag fixme à 
mon avis.



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


Re: [OSM-talk-fr] Alternative locale à Mapillary

2020-06-29 Par sujet Marc M.
Bonjour,

Le 29.06.20 à 12:19, Eric SIBERT a écrit :
> Question : y a-t-il un moyen de faire quelque chose de similaire sans
> passer par Mapillary?

il y a une discussion un clic à côté :)
en gros on expérimente diverses briques
la brique pour récupérer les images depuis un compte mapillary va bien,
les afficher sur une carte aussi. tout le reste est à faire ou à
(re)trouver.

Cordialement,
Marc

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


Re: [OSM-talk-fr] Alternative locale à Mapillary

2020-06-29 Par sujet Georges Dutreix via Talk-fr
Si tu ouvres une photo correctement géolocalisée (données EXIF) dans 
JSOM avec Fichier > ouvrir, JOSM va te créer un calque "images géololisées".

Et elle sera ua bon endroit.
Essaie aussi le glisser/déposer...



Le 29/06/2020 à 12:19, Eric SIBERT a écrit :

Bonjour à tous,

Suite au rachat de Mapillary par Facebook, je ne veux plus contribuer 
à Mapillary...


Néanmoins, Mapillary constituait un élément clé dans ma chaîne de 
contribution à OSM, lors de mes déplacement en voiture. Je suis un peu 
orphelin :-(. En pratique, je réalisais d'une part une capture 
d'images avec l'application Mapillary sur smartphone. D'autre part, 
j'enregistrais ma trace avec un GPS, en prenant des waypoints sur les 
éléments à ajouter (limites de vitesse, entrée d'agglomération...). De 
retour à la maison, je téléversais les images dans Mapillary. Ensuite, 
sur mon PC, j'ouvrais JOSM avec la trace GPS, dans un écran, et 
Mapillary dans un navigateur web dans le second écran. Je n'utilise 
pas beaucoup le plugin Mapillary dans JOSM. Quand je veux localiser 
précisément un objet (panneau par exemple), je compare ce qu'on voit 
dans la photo Mapillary avec l'orthophoto dans JOSM.


Question : y a-t-il un moyen de faire quelque chose de similaire sans 
passer par Mapillary? A priori, il n'y a pas d'alternative valable sur 
internet. En faisant ça en local? Toujours en enregistrant les photos 
sur smartphone en déplacement mais en les transférant directement sur 
PC? Ensuite pouvoir les afficher sur fond de carte OSM, à la 
Mapillary? Toute piste est bienvenue.


Eric

___
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] Alternative locale à Mapillary

2020-06-29 Par sujet Eric SIBERT

Bonjour à tous,

Suite au rachat de Mapillary par Facebook, je ne veux plus contribuer à 
Mapillary...


Néanmoins, Mapillary constituait un élément clé dans ma chaîne de 
contribution à OSM, lors de mes déplacement en voiture. Je suis un peu 
orphelin :-(. En pratique, je réalisais d'une part une capture d'images 
avec l'application Mapillary sur smartphone. D'autre part, 
j'enregistrais ma trace avec un GPS, en prenant des waypoints sur les 
éléments à ajouter (limites de vitesse, entrée d'agglomération...). De 
retour à la maison, je téléversais les images dans Mapillary. Ensuite, 
sur mon PC, j'ouvrais JOSM avec la trace GPS, dans un écran, et 
Mapillary dans un navigateur web dans le second écran. Je n'utilise pas 
beaucoup le plugin Mapillary dans JOSM. Quand je veux localiser 
précisément un objet (panneau par exemple), je compare ce qu'on voit 
dans la photo Mapillary avec l'orthophoto dans JOSM.


Question : y a-t-il un moyen de faire quelque chose de similaire sans 
passer par Mapillary? A priori, il n'y a pas d'alternative valable sur 
internet. En faisant ça en local? Toujours en enregistrant les photos 
sur smartphone en déplacement mais en les transférant directement sur 
PC? Ensuite pouvoir les afficher sur fond de carte OSM, à la Mapillary? 
Toute piste est bienvenue.


Eric

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


Re: [OSM-talk-fr] Enquête usagers data.gouv.fr

2020-06-29 Par sujet Magalie Dartus
D'ailleurs je vous invite à répondre au questionnaire usagers :
https://framaforms.org/enquete-datagouvfr-usagers-1590438305

Les avis de la communauté seront très utiles.

Magalie

Le ven. 26 juin 2020 à 20:50, Donat ROBAUX  a écrit :

> Hello,
>
> Une petite news qui devrait ravir ou en tout cas intéresser de nombreuses
> personnes ici.
>
> https://www.etalab.gouv.fr/participez-a-lelaboration-de-la-nouvelle-feuille-de-route-open-data-detalab
>
>
> Donat
>
>
> 
>  Garanti
> sans virus. www.avast.com
> 
> <#m_-6635657510614362911_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> 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] Poteaux de randonnée aux tags "baroques" dans le Vaucluse

2020-06-29 Par sujet Yves P.
> je ne pense pas que la présence d'une photo soit un argument pour sortir une 
> donnée car il est plus facile il me semble d'utiliser une donnée pour du 
> routing ou de la synthèse vocale par exemple (d'autant plus pour les cas où 
> l'on ne peut pas voir la photo).
> 
Oui :)
> La pertinence du tag en lui-même je ne sais pas. 
> 
Dans ce cas, il me semble que non. Que va faire un calculateur d'itinéraire 
avec la position d'un poteau sur le trottoir, dans l'herbe ou au dessus de la 
chaussée ?

destination est utile, et apparemment utilisé par les synthèses vocales des 
logiciels de guidage.
Voir même pour le calcul d'itinéraires.

Mais c'est galère à saisir (les IA de mapillary pourront peut-être nous aider ?)
(J'ai des centaines de photos en attente)

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


Re: [OSM-talk-fr] Poteaux de randonnée aux tags "baroques" dans le Vaucluse

2020-06-29 Par sujet Vincent Bergeot

Le 29/06/2020 à 11:04, Yves P. a écrit :
- pole:position=green : je ne comprends pas ce tag, et je n'ai rien 
trouvé dans le wiki. Quelqu'un peut-il expliquer ?
c'est par analogie avec fire_hydrant:position 
=lane/parking_lot/sidewalk/green


C'est utile quand la précision des coordonnées est mauvaise ou en 
l'absence de photo de situation, sinon complètement inutile.


je ne pense pas que la présence d'une photo soit un argument pour sortir 
une donnée car il est plus facile il me semble d'utiliser une donnée 
pour du routing ou de la synthèse vocale par exemple (d'autant plus pour 
les cas où l'on ne peut pas voir la photo).


La pertinence du tag en lui-même je ne sais pas.

à plus

--

Vincent Bergeot

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


Re: [OSM-talk-fr] Poteaux de randonnée aux tags "baroques" dans le Vaucluse

2020-06-29 Par sujet Yves P.
> - quand aux autres tags, quoique non absolument indispensables, ils apportent 
> une information: pourquoi vouloir les supprimer ? Je ne vois pas en quoi ils 
> pourraient être gênants.
Je pose la question 

C'est un peu comme le catalogage (de livres), il faut trouver un équilibre 
entre pas assez d'info, et trop d'info.
Ou même le fait de garder des livres. Les bibliothécaires appellent l'opération 
consistant à se débarrasser de "vieux" bouquins le désherbage ☺️

> ou mettre les 3 (parce que si tu veux sélectionner "chevaux",
> ca va être compliqué de faire une requête "si région=celle
> de yves, alors pas de valeur=vélo+vtt+cheval" :)
C'est vrai :)
Mais je préfère saisir les relations de randonnées pour les voir dans Waymarked 
Trails, OsmAnd…

Je ne suis pas sûr que quelqu'un organise une rando uniquement à partir des 
poteaux (présents ???) dans OSM.
Ça me rappel d'ailleurs qu'il faut que je dégaine Madada pour avoir un export 
des panneaux et itinéraires PDIPR dans mon secteur !


> il y a souvent des pictogrammes indiquant les moyens de transport,
> c'est dans ce sens là que j'ajoute ces tags.
Ici on retrouve des "jalons" VTT, rando équestre (GTJ) et maintenant Trail sur 
les poteaux ou sur les panneaux directionnels.

>> *start_date* ?
> 
> c'est quoi la question ?
Pour un monument je trouve ça intéressant, pour un poteau nettement moins.
(L'info doit être dans la précieuse base de données PDIPR que les gestionnaires 
ont du mal à "libérer").


> 
>> *arrows* n'est pas standard et est-ce vraiment utile.
> 
> j'aurais mis direction=les 3 valeurs
tu voulais dire destination 
=* ?

> proposer d'effacer est rarement le plus agréable.
je suis d'accord, mais il faut relativiser, ça ne concerne que 279 tags.

> mapillary=valeur1;valeur2;valeur3
> si c'est logiciels ont du mal avec le support des valeurs
> multiples, il faut les améliorer au lieu d'effacer des données.
Je suis d'accord, mais rappel toi les conversations sur les tickets et demande 
de fusion de code (PR) sur GitHub.
Pas sûr que les devs en tiennent compte pour 279 tags, mapillary en plus !

Si on regarde de l'autre bout de la lorgnette, on peut élargir ça à la gestion 
des tags multi-valeurs.
Traiter une fois pour toute la gestion de ces valeurs (mes mails sur l'API 0.7 
n'ont eu aucun retour )
Mettre en place un mécanisme commun à tous les éditeurs (DataItems ?) pour 
empêcher (ou autoriser) la saisie pour certains tags
__
Yves___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Poteaux de randonnée aux tags "baroques" dans le Vaucluse

2020-06-29 Par sujet Yves P.
> tourism  
> information 
> 
> information 
>  guidepost 
> 
> est important.
> 
Oui, je les avais mis en gras :)

> - information=guidepost est obligatoire, tu aurais dû le mettre en gras;
oups, j'ai effectivement oublié celui-ci mais vous avez corrigé de vous même :)

> pole:material […] permet […] de l'entretenir
> 
> start_date 
> 
>  1999-09-17 aussi.
> 
Le gestionnaire doit avoir ça dans son SIG ;)

> et pole:position permet de le retrouver,
> 
Les coordonnées et la photo c'est mieux ;)

> name ? Je ne sais pas trop.
> 
> À l'opposé ele, tu as le MNT pour ça^^.
Pour le randonneur en zone montagneuse, c'est très utile (et c'est ce que tu 
peux lire de tangible sur le poteau).
C'est aussi sur toutes les cartes des Offices de Tourismes…

Mais il n'y a peut-être pas assez de relief par chez toi en dehors de la houle 
;D

ele est aussi utile lors d'une rando pédestre, vélo pour avoir une idée du 
dénivelé à franchir (mais des logiciels de rando font mieux avec le MNT)

> - pole:position=green : je ne comprends pas ce tag, et je n'ai rien trouvé 
> dans le wiki. Quelqu'un peut-il expliquer ?
c'est par analogie avec fire_hydrant:position 
=lane/parking_lot/sidewalk/green

C'est utile quand la précision des coordonnées est mauvaise ou en l'absence de 
photo de situation, sinon complètement inutile.
__
Yves

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


Re: [OSM-talk-fr] Poteaux de randonnée aux tags "baroques" dans le Vaucluse

2020-06-29 Par sujet Marc M.
Le 29.06.20 à 10:39, Yves P. a écrit :

> *hiking*=yes je ne le met pas car dans ma région il servent  
> autant pour les randos pédestres, vélo, VTT, cheval…

ou mettre les 3 (parce que si tu veux sélectionner "chevaux",
ca va être compliqué de faire une requête "si région=celle
de yves, alors pas de valeur=vélo+vtt+cheval" :)
il y a souvent des pictogrammes indiquant les moyens de transport,
c'est dans ce sens là que j'ajoute ces tags.

> *pole:position* a-t-il encore un intérêt avec une qualité correcte
> d'orthophotos et surtout une vue mapillary ?

sûrement du détail peu utile, (pour les bornes incendies, on le fait
parfois quand la borne est masquée par les hautes herbes. pour un
poteau je doute que la végétation monte si haut)
Mais j'aurais surtout utilisé la clef courante location=*

> *start_date* ?

c'est quoi la question ?

> *arrows* n'est pas standard et est-ce vraiment utile.

j'aurais mis direction=les 3 valeurs

> mapillary:wide
> Je propose donc de ne mettre que la photo la plus lisible

proposer d'effacer est rarement le plus agréable.
mapillary=valeur1;valeur2;valeur3
si c'est logiciels ont du mal avec le support des valeurs
multiples, il faut les améliorer au lieu d'effacer des données.

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


Re: [OSM-talk-fr] Poteaux de randonnée aux tags "baroques" dans le Vaucluse

2020-06-29 Par sujet Jean-Claude Repetto

Bonjour,

- Je suis d'accord pour is_in, qui est désormais obsolète;

- pole:position=green : je ne comprends pas ce tag, et je n'ai rien 
trouvé dans le wiki. Quelqu'un peut-il expliquer ?


- information=guidepost est obligatoire, tu aurais dû le mettre en gras;

- quand aux autres tags, quoique non absolument indispensables, ils 
apportent une information: pourquoi vouloir les supprimer ? Je ne vois 
pas en quoi ils pourraient être gênants.


Jean-Claude


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


[OSM-talk-fr] Poteaux de randonnée aux tags "baroques" dans le Vaucluse

2020-06-29 Par sujet Yves P.
Bonjour,

Je tombe sur un poteau avec beaucoup de tags qui ne rendent pas la "lecture" 
facile et pour certains surprenants et peu utiles : 
https://overpass-turbo.eu/s/VyW

Un exemple au hasard : 5433687571 

• arrows=3
• ele=346
• hiking=yes
• information=guidepost
• is_in:city=Malaucène
• mapillary=0Ww_5sMHNlX8v87ShgbpJg
• mapillary:wide=bCUDY2vXmKDhafcnRrDvgg
• name=Route des Crottes
• operator=CD84
• pole:material=wood
• pole:position=green
• ref:CD84=1824
• source:ref=CD84
• start_date=1999-09-17
• tourism=information

J'ai mis en gras ce qui est nécessaire.

hiking=yes je ne le met pas car dans ma région il servent autant pour les 
randos pédestres, vélo, VTT, cheval…

is_in:city est superflu d'autant que l'auteur (coucou Jean-Louis ) à un SIG 
sur son bureau ;)
pole:position a-t-il encore un intérêt avec une qualité correcte d'orthophotos 
et surtout une vue mapillary ?
source:ref, start_date ??
arrows n'est pas standard et est-ce vraiment utile. Il y a des tags pour 
indiquer des directions, et surtout une photo.

Je suis tombé sur un poteau avec mapillary:wide. Aucun logiciel ne l'utilise !
On pourrait mettre des valeurs multiples séparées par des ;

Overpass ne sait pas afficher de lien dans ce cas. (OSM ne le fait pas du tout)
JOSM génère un lien qui ne fonctionne pas (il n' "explose" pas les valeurs pour 
produire plusieurs URLs)

Je propose donc de ne mettre que la photo la plus lisible et significative. 
Ensuite c'est à l'utilisateur de se balader dans Mapillary (ou son successeur )

Et un "gros" nettoyage de ces objets.

Merci d'avance ☺️

__
Yves

PS: le premier  que j'ai 
trouvé est "coton" avec les clés suivantes (en plus des autres) :
fixme=picture
mapillary:wide=jj88miCK4llKZQ47HvC9Rw
picture=no



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


Re: [OSM-talk-fr] coupure serveur overpass-api osm.fr

2020-06-29 Par sujet Jacques Lavignotte



Le 29/06/2020 à 08:02, Marc M. a écrit :


Le service est rétablit sur osm47
https://overpass-turbo.eu/s/Vyy


Merci Marc !

J.

--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

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


Re: [OSM-talk-fr] coupure serveur overpass-api osm.fr

2020-06-29 Par sujet Jean-Christophe Becquet
Le 29/06/2020 à 08:02, Marc M. a écrit :
> Le service est rétablit sur osm47
> https://overpass-turbo.eu/s/Vyy
> Il devrait être plus rapide qu'avant.
> n'hésitez pas à signaler d'éventuelle anomalie
> ici ou sur tech ou sur github
> https://github.com/osm-fr/infrastructure/issues/19
> 
> A suivre :
> - les améliorations pour le rendre plus robuste aux pannes
> - maj du code overpass (pour entre autre nwr)
> - le retour des graphes munin

Merci à toi Marc et merci à tous ceux qui participent à cette maintenance.

Des serveurs overpass qui répondent, des rendus réactifs et à jour, des
outils d'analyse qualité...

Cela représente énormément de travail pour faire fonctionner tout ça !

Bon début de semaine

JCB
-- 
MOUSTIC - Mise en Œuvre des Usages Sociaux
des Technologies et de l'Intelligence Collective
Rendez-vous dans les Alpes du 2 au 5 août 2020
http://moustic.info


==APITUX : le choix du logiciel libre==

APITUX - Jean-Christophe Becquet
2 chemin du Tivoli - 04000 Digne-les-Bains
06 25 86 07 92 - j...@apitux.com - http://www.apitux.com
SIRET : 452 887 441 00031 - APE : 6202A

===

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


Re: [OSM-talk-fr] coupure serveur overpass-api osm.fr

2020-06-29 Par sujet Marc M.
Bonjour,

Le service est rétablit sur osm47
https://overpass-turbo.eu/s/Vyy
Il devrait être plus rapide qu'avant.
n'hésitez pas à signaler d'éventuelle anomalie
ici ou sur tech ou sur github
https://github.com/osm-fr/infrastructure/issues/19

A suivre :
- les améliorations pour le rendre plus robuste aux pannes
- maj du code overpass (pour entre autre nwr)
- le retour des graphes munin

Cordialement,
Marc

Le 26.06.20 à 12:39, Marc M. a écrit :
> Bonjour,
> 
> pour diverses raisons (manque d'harmonisation entre les hosteurs,
> soucis de perf sur l'un d'eux), les 2 serveurs overpass-api osm-fr
> subissent des jours de lag, au point que j'ai coupé le service.
> 
> une nouvelle base est en cours de maj sur un ssd
> avec l'espoir d'y réactiver le service ce we.
> s'en suivra la maj applicative tant attendue,
> ainsi que diverse amélioration pour essayer de rendre cela
> plus robuste
> 
> Cordialement,
> Marc
> 


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