Re: [OSM-talk-fr] Bande cyclable etroite

[Marc_marc]

Bonjour,

Le 23.11.20 à 18:44, Benoît Grunberg a écrit :
> bandes cyclables etroites moins de 1m

Je trouve qu'il est préférable de renseigner une valeur
imprécise (width=1 plutôt qu'une valeur totalement subjective
"c'est étroit" car cette dernière ne dit pas par rapport à quoi :
on ne tag pas le respect de la norme que tu cites,
donc une bande cyclable de 2m de large est étroite
si tout le reste fait 3m.

une imagerie sat même moyenne est souvent suffisante
pour renseigner un ordre de grandeur (peu importe si
c'est 1m ou 1.01m, le génie civil des batiments et des
routes n'est pas précis au cm ni même parfois aux 10cm)
Pour cette même raison je n'utilise pas non plus est_width
tout dans osm est "du mieux qu'on peux", pas besoin
de mettre des est_, le contributeur suivant
ajoutera de la précision s'il le souhaite.

Cordialement,
Marc



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

Re: [OSM-talk-fr] addok et demo.addok.xyz : géocodage avec données OSM

[Jean-Marc Liotier]

On 11/23/20 10:32 PM, Christian Quest wrote:
L'index redis occupe dans les 16Go de RAM, la base sqlite 2Go, elle 
aussi en RAM pour un max de perfs.
Pour la France seulement... Ca apporte d'un coup tous ce dont l'absence 
frustre dans Nominatim - mais c'est un sérieux investissement en 
matériel pour une emprise mondiale... Même problème que la mise à 
disposition de tuiles: vitrine indispensable mais qui risque d'être 
considéré comme un service public.


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

Re: [OSM-talk-fr] JOSM version stable 17329 : traduction du Journal des modifications

[Rpnpif via Talk-fr]

Le 24/11/2020 à 08:07, Cyrille37 OSM via Talk-fr a écrit :

Bonjour

et Mille mercis et bravo pour ce super logiciel que vous savez 
maintenir toutes ces années.


+1.

Dommage qu'il ne gère pas bien le HiDpi (haute résolution d'écran) sous 
Linux (probablement du fait des bibliothèques de Java). Mais un ticket 
est en cours. Donc espoir.


--
Rpnpif

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

Re: [OSM-talk-fr] Bande cyclable etroite

[lejun]

Tout à fait d'accord pour est_width. Soit on a une mesure (quelque soit
la méthode) soit on ne l'a pas, sans compter que l'environnement est
soumis à variations, par exemple le tassement ou la dilatation des
matériaux. La proposition du narrow=yes ne me parait pas non plus
adaptée, en tout cas dans ce contexte précis puisqu'il est plus proche
du "rétrécissement de voie" que "dimensions inférieures à une référence
(qui se trouve être le CERTU)".

Le 24/11/2020 à 10:02, Marc_marc a écrit :

Bonjour,

Le 23.11.20 à 18:44, Benoît Grunberg a écrit :

bandes cyclables etroites moins de 1m


Je trouve qu'il est préférable de renseigner une valeur
imprécise (width=1 plutôt qu'une valeur totalement subjective
"c'est étroit" car cette dernière ne dit pas par rapport à quoi :
on ne tag pas le respect de la norme que tu cites,
donc une bande cyclable de 2m de large est étroite
si tout le reste fait 3m.

une imagerie sat même moyenne est souvent suffisante
pour renseigner un ordre de grandeur (peu importe si
c'est 1m ou 1.01m, le génie civil des batiments et des
routes n'est pas précis au cm ni même parfois aux 10cm)
Pour cette même raison je n'utilise pas non plus est_width
tout dans osm est "du mieux qu'on peux", pas besoin
de mettre des est_, le contributeur suivant
ajoutera de la précision s'il le souhaite.

Cordialement,
Marc


--
Lejun - Groupe Local OpenStreetMap Bourgogne-Franche-Comté

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

[OSM-talk-fr] proposition nouvel attribut

[François Bojarski via Talk-fr]

Bonjour à tous,
Suite au recommandation de Donat, je viens prendre la température pour la 
proposition d'un nouveau tag pour cartographier les boîtiers test de Detecteur 
de Victime en Avalanche (DVA en français, avalanche beacon in english). Ce sont 
des petits boitiers que l'on peut trouver dans les stations aux départs de 
certains grands hors pistes, proche des arrivées de remontées, à côté des 
caisses de forfait, dans des zones dédiés de zone d'entraînement pour sortir 
des gens d'avalanches, etc . Ca me paraît utile, et pourrait facilement avoir 
un rendu, puisque dans des zones peu dense.

Le tag : avalanche_beacon_check ou bien dva_check me paraitrait approprié. Il 
pourrait être combine avec le tag pour dire s'il est à l'intérieur ou à 
l'extérieur des bâtiments.
Qu'en pensez-vous ? Si ma proposition n'amène pas un refus frontal, je ferai la 
proposition "officielle " sur le wiki.

Merci !

Sent with [ProtonMail](https://protonmail.com) Secure Email.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] proposition nouvel attribut : Detecteur de Victime en Avalanche

[Marc_marc]

Bonjour François et bienvenue,

Le 24.11.20 à 13:06, François Bojarski via Talk-fr a écrit :
> je viens prendre la température pour
> la proposition d'un nouveau tag

c'est toujours une bonne idée de surtout récolter
un maximum d'avis.

> Detecteur de Victime en Avalanche (DVA en français, avalanche beacon 
> in english). Ce sont des petits boitiers que l'on peut trouver 
> dans les stations aux départs de certains grands hors pistes

si je comprend bien la page wikipedia [1], c'est un appareil
émetteur/récepteur qu'un sauveteur utilise pour rechercher
un sinistré en ayant lui aussi une.

si c'est correct, que souhaites-tu renseigner ?
l'obligation d'en avoir un sur une zone ?
un magasin/comptoir/stock en libre service pour en emprunter ?

> dva_check 

le terme en fr n'est sûrement pas approprié.
wikipedia anglais renseigne 2 termes
avalanche transceiver
avalanche beacon
je n'ai aucune idée si l'un des 2 est en anglais britanique,
la ml tagging serra sans doute + approprié pour le choix
final du terme
dans osm il y a une occurrence de chaque
https://www.openstreetmap.org/way/243463638
https://www.openstreetmap.org/way/98247837

[1] https://fr.wikipedia.org/wiki/D%C3%A9tecteur_de_victimes_d%27avalanches

Cordialement,
Marc



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

Re: [OSM-talk-fr] addok et demo.addok.xyz : géocodage avec données OSM

[Frédéric Rodrigo]

Ce n'est pas aussi facile que ça pour faire une emprise mondiale. Il est
nécessaire d'écrire des adaptateurs pour chaque langue ou pays pour traiter
les particularités.

Le mar. 24 nov. 2020 à 10:41, Jean-Marc Liotier  a écrit :

> On 11/23/20 10:32 PM, Christian Quest wrote:
> > L'index redis occupe dans les 16Go de RAM, la base sqlite 2Go, elle
> > aussi en RAM pour un max de perfs.
> Pour la France seulement... Ca apporte d'un coup tous ce dont l'absence
> frustre dans Nominatim - mais c'est un sérieux investissement en
> matériel pour une emprise mondiale... Même problème que la mise à
> disposition de tuiles: vitrine indispensable mais qui risque d'être
> considéré comme un service public.
>
> ___
> 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] proposition nouvel attribut : Detecteur de Victime en Avalanche

[Topographe Fou]

Bonjour Marc,

Si je comprend bien le contenu du mail (en laissant de côté son sujet qui est 
un peu différent) François ne veut pas cartographier des zones nécessitant un 
DVA mais des bornes qui permettent de tester qu'un DVA fonctionne bien avant de 
partir à l'aventure.

Cordialement, 

LeTopographeFou


  Message original  


De: marc_m...@mailo.com
Envoyé: 24 novembre 2020 2:51 PM
À: talk-fr@openstreetmap.org
Répondre à: talk-fr@openstreetmap.org
Objet: Re: [OSM-talk-fr] proposition nouvel attribut : Detecteur de Victime en 
Avalanche


Bonjour François et bienvenue,

Le 24.11.20 à 13:06, François Bojarski via Talk-fr a écrit :
> je viens prendre la température pour
> la proposition d'un nouveau tag

c'est toujours une bonne idée de surtout récolter
un maximum d'avis.

> Detecteur de Victime en Avalanche (DVA en français, avalanche beacon
> in english). Ce sont des petits boitiers que l'on peut trouver
> dans les stations aux départs de certains grands hors pistes

si je comprend bien la page wikipedia [1], c'est un appareil
émetteur/récepteur qu'un sauveteur utilise pour rechercher
un sinistré en ayant lui aussi une.

si c'est correct, que souhaites-tu renseigner ?
l'obligation d'en avoir un sur une zone ?
un magasin/comptoir/stock en libre service pour en emprunter ?

> dva_check

le terme en fr n'est sûrement pas approprié.
wikipedia anglais renseigne 2 termes
avalanche transceiver
avalanche beacon
je n'ai aucune idée si l'un des 2 est en anglais britanique,
la ml tagging serra sans doute + approprié pour le choix
final du terme
dans osm il y a une occurrence de chaque
https://www.openstreetmap.org/way/243463638
https://www.openstreetmap.org/way/98247837

[1] https://fr.wikipedia.org/wiki/D%C3%A9tecteur_de_victimes_d%27avalanches

Cordialement,
Marc



___
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] addok et demo.addok.xyz : géocodage avec données OSM

[Christian Quest]

Oui, ce n'est pas le but d'addok... qui trop embrasse mal étreint ;)

J'envisage par contre de rajouter des données hors de France, 
typiquement les noms des villes dans le monde entier pour pouvoir 
chercher "Le caire" ou "Tokyo".


Pour le côté service public, je pense que DEMO.addok.xyz pose bien les 
choses ;)



Le 24/11/2020 à 18:22, Frédéric Rodrigo a écrit :
Ce n'est pas aussi facile que ça pour faire une emprise mondiale. Il 
est nécessaire d'écrire des adaptateurs pour chaque langue ou pays 
pour traiter les particularités.


Le mar. 24 nov. 2020 à 10:41, Jean-Marc Liotier > a écrit :


On 11/23/20 10:32 PM, Christian Quest wrote:
> L'index redis occupe dans les 16Go de RAM, la base sqlite 2Go, elle
> aussi en RAM pour un max de perfs.
Pour la France seulement... Ca apporte d'un coup tous ce dont
l'absence
frustre dans Nominatim - mais c'est un sérieux investissement en
matériel pour une emprise mondiale... Même problème que la mise à
disposition de tuiles: vitrine indispensable mais qui risque d'être
considéré comme un service public.


--
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] proposition nouvel attribut : Detecteur de Victime en Avalanche

[osm . sanspourriel]

Je trouve un peu bizarre de renseigner les DVA.

Pourquoi pas alors les radio balises de location des sinistres
EPIR*B*/EL*T*/PL*B* (leurs équivalents dans le monde Cospar/Sarsat) à
savoir respectivement les balises maritimes, aéronautiques et personnelles ?

B veut dire beacon, c'est dire si avalanche beacon serait le bon terme.
Transceiver n'est pas faux mais beacon est plus "normalisé". Le T de ELT
c'est Transmitter (initialement on de faisait qu'émettre même si avec
Galileo le lien retour - return link - est possible).

Bizarre ? En effet comme dit Marc Marc ce sont des boitiers que l'on
achète ou loue.

Donc ce ne sont pas les équipements que l'on tague mais éventuellement :

- l'obligation de le porter (correspond à description=Avalanche beacon
required), avalanche_beacon=required ? A priori pas de sens pour les
EPIRB et ELT (c'est fonction de l'engin utilié et la zone).
Éventuellement pour les PLB (pour des trek ?)
- la possibilité d'en louer ou d'en acheter. avalanche_beacon=yes ?
Suivant si c'est amenity=ski_rental ou shop, on sait si c'est de la
location ou de la vente ou il est préférable de dire :
avalanche_beacon=rental ou avalanche_beacon=sell ?

Il faudrait aussi ajouter les balises MOB (Man Over Board), balises AIS
pour les hommes à la mer. Marche aussi pour les femmes^^.

Grosso-modo c'est le même principe que les balises d'avalanche, sauf que
de plus en plus de bateaux sont équipés en AIS et donc la recherche peut
être faite par plus que les seuls sauveteurs.

Il y a aussi les les systèmes basés sur le GSM (comme le bracelet SNSM),
etc...
https://www.actunautique.com/2020/01/homme-a-la-mer-mob-3/5-les-aides-electroniques.html

Jean-Yvon


Le 24/11/2020 à 14:47, Marc_marc - marc_m...@mailo.com a écrit :

Bonjour François et bienvenue,

Le 24.11.20 à 13:06, François Bojarski via Talk-fr a écrit :

je viens prendre la température pour
la proposition d'un nouveau tag

c'est toujours une bonne idée de surtout récolter
un maximum d'avis.


Detecteur de Victime en Avalanche (DVA en français, avalanche beacon
in english). Ce sont des petits boitiers que l'on peut trouver
dans les stations aux départs de certains grands hors pistes


si c'est correct, que souhaites-tu renseigner ?
l'obligation d'en avoir un sur une zone ?
un magasin/comptoir/stock en libre service pour en emprunter ?


dva_check

le terme en fr n'est sûrement pas approprié.
wikipedia anglais renseigne 2 termes
avalanche transceiver
avalanche beacon
je n'ai aucune idée si l'un des 2 est en anglais britanique,
la ml tagging serra sans doute + approprié pour le choix
final du terme
dans osm il y a une occurrence de chaque
https://www.openstreetmap.org/way/243463638
https://www.openstreetmap.org/way/98247837

[1] https://fr.wikipedia.org/wiki/D%C3%A9tecteur_de_victimes_d%27avalanches

Cordialement,
Marc



___
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] précision proposition nouvel attribut

[François Bojarski via Talk-fr]

Bonjour
Je confirme ce que dis le topographe fou, le but est de cartographier les 
endroits où l'on peut tester son dva.
Rappel rapide sur les dva que j'aurais du faire avant. En ski de rando ou free 
ride, on a tous sur soi un dva qui émet en permanence. Si une personne de ton 
groupe est prise dans une avalanche, tu mets ton dva en mode réception, et en 
captant le signal de la personne ensevelie, tu peux la retrouver. Dans la 
plupart des stations (en tout cas celles où le hors piste est répandu), il y a 
des boîtiers qui sont comme des dva en mode réception, qui permettent de te 
confirmer que ton dva émet bien et est donc utilisable.
Ce sont ces boitiers que je souhaiterais cartographier.
Cartographier des zones où le dva est nécessaire n'aurait selon moi aucun sens 
: il n'est obligatoire nulle part (à ma connaissance), mais utile partout. De 
même cartographier la possibilité d'en vendre / acheter ne me paraît pas 
intéressante, l'écrasante majorité des magasins de skis en vendent.
(L'équivalent des balises MOB seraient, en sortie de rade, s'il y avait des 
boîtiers pour tester si ta MOB fonctionnait, ce qui n'existe pas àmha).
Je prends note, en effet dva_check est un peu trop franco-français :). 
Peut-être avalanche_beacon_check est trop long ?

Merci à tous

Sent with [ProtonMail](https://protonmail.com) Secure Email.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] addok et demo.addok.xyz : géocodage avec données OSM

[Jean-Marc Liotier]

On 11/24/20 6:22 PM, Frédéric Rodrigo wrote:
Ce n'est pas aussi facile que ça pour faire une emprise mondiale. Il 
est nécessaire d'écrire des adaptateurs pour chaque langue ou pays 
pour traiter les particularités.


Je découvre donc:

- La phonemicization: 
https://github.com/addok/addok-fr/blob/master/addok_fr/utils.py


- Les particularités Françaises: 
https://github.com/addok/addok-france/blob/master/addok_france/utils.py


On comprend vite qu'il sera compliqué d'accepter une recherche sans 
connaître dans quel zone administrative et linguistique elle s'inscrit...



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

Re: [OSM-talk-fr] Proposition - Vote - Les pompes

[François Lacombe]

Bonsoir à tous,

Quelques nouvelles à propos de ce vote.
Difficile d'imaginer la multitude de commentaires reçus avant de se lancer.
Merci à tous ceux qui ont pris le temps de lire, commenter, expliquer
jusqu'ici.

Cette version ne sera probablement pas acceptée et je pense arrêter le vote
pour l'instant.
Il faut que je réfléchisse davantage sur le schéma proposé, pour intégrer
certaines remarques.

Toutefois et sans être spécifique au cas précis et très technique des
pompes, je reste en désaccord avec le maintien d'une clé prétendument
utilisée par principe.
Le niveau d'utilisation d'une clé est imprécis, considéré de manière
différente suivant les personnes.
C'est un risque pour OSM : quand tous les tags seront réputés utilisés, on
ne changera plus rien.
Ici est opposée l'existence de 30 000 utilisations sur 14% *seulement* des
objets censés le recevoir. Ce n'est pas acceptable.
La recherche de qualité, d'innovation propre à OSM mérite vraiment mieux à
mon sens.

A suivre donc, bonne soirée

François

Le ven. 20 nov. 2020 à 14:17, Jacques Lavignotte  a
écrit :

>
>
> Le 19/11/2020 à 20:19, François Lacombe a écrit :
> > le vote sur la proposition traitant des pompes est finalement ouvert
>
> A voté !
>
>
> --
> 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] précision proposition nouvel attribut

[Eric SIBERT via Talk-fr]

Je pense qu'il y a dans certaines stations d'Amérique du Nord des 
portillons à déverrouiller avec son DVA pour sortir du domaine balisé et 
aller en hors-piste.


Eric

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

Re: [OSM-talk-fr] Proposition - Vote - Les pompes

[lejun]

Sur OSM aussi il y a une part de conservateurs qui veulent maintenir
l'usage d'un ancien attribut quitte à en mettre une couche par dessus.
Oui j'pense à vous, ceux qui travaillent sur les transports publics et
qui en êtes au moins à la 4e version officielle surajoutée.

Bon courage pour la suite !

Le 24/11/2020 à 20:41, François Lacombe a écrit :


Toutefois et sans être spécifique au cas précis et très technique des
pompes, je reste en désaccord avec le maintien d'une clé prétendument
utilisée par principe.
Le niveau d'utilisation d'une clé est imprécis, considéré de manière
différente suivant les personnes.
C'est un risque pour OSM : quand tous les tags seront réputés utilisés,
on ne changera plus rien.
Ici est opposée l'existence de 30 000 utilisations sur 14% *seulement*
des objets censés le recevoir. Ce n'est pas acceptable.
La recherche de qualité, d'innovation propre à OSM mérite vraiment mieux
à mon sens.


--
Lejun - Groupe Local OpenStreetMap Bourgogne-Franche-Comté

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

Re: [OSM-talk-fr] addok et demo.addok.xyz : géocodage avec données OSM

[Cyrille37 OSM via Talk-fr]

Bonjour,

Y a t'il une chance que adresse.data.gouv.fr intègre cette nouvelle 
mouture v1.1  ?


C/.

Le 24/11/2020 à 19:39, Christian Quest a écrit :


Oui, ce n'est pas le but d'addok... qui trop embrasse mal étreint ;)

J'envisage par contre de rajouter des données hors de France, 
typiquement les noms des villes dans le monde entier pour pouvoir 
chercher "Le caire" ou "Tokyo".


Pour le côté service public, je pense que DEMO.addok.xyz pose bien les 
choses ;)



Le 24/11/2020 à 18:22, Frédéric Rodrigo a écrit :
Ce n'est pas aussi facile que ça pour faire une emprise mondiale. Il 
est nécessaire d'écrire des adaptateurs pour chaque langue ou pays 
pour traiter les particularités.


Le mar. 24 nov. 2020 à 10:41, Jean-Marc Liotier > a écrit :


On 11/23/20 10:32 PM, Christian Quest wrote:
> L'index redis occupe dans les 16Go de RAM, la base sqlite 2Go,
elle
> aussi en RAM pour un max de perfs.
Pour la France seulement... Ca apporte d'un coup tous ce dont
l'absence
frustre dans Nominatim - mais c'est un sérieux investissement en
matériel pour une emprise mondiale... Même problème que la mise à
disposition de tuiles: vitrine indispensable mais qui risque d'être
considéré comme un service public.


--
Christian Quest - OpenStreetMap France

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