date:20200806

Note aussi que rien n'empêche d'utiliser le nom "par défaut"  (name=*) mais
de le transcrire dans l'écriture que tu préfères. Si la seule chose trouvée
est un nom chinois, russe, japonais ou arabe, il y a des romanisations
standards qui te permettront de lire quand même le résultat.
Et dans les pays dont la langue officielle n'est pas écrite en alphabet
latin, il y a très souvent des romanisations proposées aussi et
standisées localement (et qu'on voit aussi sur le terrain, en Chine, au
Japon, en Inde, et presque tous les pays arabophones).
Bref inclure les algos de romanisation (ou de translitération vers d'autres
écritures pour les non-latinistes: utilisateurs russes, chinois,
arabophones, indiens...) est une extension utile pour afficher les
résultats.
Des standards mondiaux (promus par les agences de l'ONU ou d'autres
orgasisations internationales y compris l'UE) existent même pour la
toponymie, la navigation, les documents d'identité, passeports, les billets
de transport, les réservations, la poste et les envois de colis (voir aussi
les standards UPU, ITU, IAT, ...).

On s'en sort car même pour les écritures moins connues (écritures
indiennes, géorgiennes, arméniennes), il y a toujours au moins une
romanisation. La romanisation de l'arabe, du chinois et du russe a
plusieurs romanisations possibles mais certaines sont standards et
s'imposent dans les pays correspondant (en Chine, en Russie et au Japon par
exemple), ce qui permet de standardiser aussi chez eux les panneaux
multilingues sans les surcharger.

Pour le coréen c'est même standardisé dans Unicode lui-même (cas unique) et
la Corée se passe de mentionner ces romanisatiosn sur ses affichages
publics (le Coréen est facile aussi à transcrire par reconnaissance OCR, sa
forme est très régulière, c'est déjà un alphabet même si les lettres sont
groupées syllabe par cellule dans une juxtaposition "étrange" pour nous
mais complètement standardisée et ses lettres ont des tracés en fait très
simples et faciles à décomposer visuellement, ce qui l'est beaucoup moins
pour l'arabe ou les clusters complexes des abugidas indiens sont les
lettres et signes diacritiques changent de forme selon la position dans le
cluster ou selon la présence d'autres signes logiquement avant ou après
dans le cluster, car ces abugidas n'ont pas de disposition aussi régulière
que le coréen et il faut être déjà formé à leur lecture; pour l'hébreux
c'est assez "simple" à décomposer visuellement sauf que tous les signes ne
sont pas toujours transcrits, dont les voyelles: la romanisation simple des
lettres de base peut ne pas suffire à une lecture correcte et les signes
diacritiques s'ils sont présents sont difficiles à distinguer pour ceux qui
ne les connaissent pas, tellement ils sont petits; l'arabe est comme
l'hébreu mais en plus compliqué à cause des liaisons de lettres qui
changent de forme contextuellement et qui forment de nombreuses ligatures).

Romaniser automatiquement l'hébreu ou l'arabe peut aider beaucoup
cependant. Romaniser le chinois (ou les kanjis en Japonais) est difficile à
moins que la romanisation soit indiquée aussi dans OSM. Romaniser le grec
ou le cyrillique (russe...) est très facile (ajouter leurs romanisations
dans OSM n'est pas nécessaire, pas plus qu'il n'est utile de mentionner les
romanisations du coréen, ni celles du Japonais sans Kanji mais juste des
Kanas). Romanier l'hébreu et l'arabe dans OSM est cependant utile car le
nom usuel est souvent insuffisamment diacrité et cele nécessite une
connaissance de la langue.

Romaniser le Thai, le Laotien, le Khmer dans OSM est probablement inutile
aussi (car automatisable facilement). Romaniser le tibétain est en revanche
plus utile. Romaniser les langues dravidiennes (indiennes du sud) est aussi
inutile (contrairement aux autres écriture indiennes du nord): le tamoul
par exemple est un quasi alphabet et ces écrrtures dravidiennes utilisent
très peu de ligatures complexes.

Bref : les noms "par défaut" d'OSM (name=*) ne servent pas à grand monde ou
ne devraient pas leur servir souvent: autant que possible utiliser les
"name:=*" avec BCP 47, puis avec les translitérations standardisées
si on ne trouve pas son écrtiture préférée.

Note: si on a dans ses préférences "français, anglais, russe", on n'aura
jamais besoin de romanisation du bulgare ou du serbe, on peut afficher
directement le nom russe présent. Si le nom russe est absent d'OSM mais
qu'on a le nom bulgare (ou serbe, ou bélarusse), ce dernier nom
(cyrillique) peut servir tel quel en absence de nom français ou anglais
dans OSM car on a indiqué pouvoir lire le russe (donc le cyrillique) et on
n'a pas besoin de translitération cyrillique-latin.


Le jeu. 6 août 2020 à 22:37, Philippe Verdy  a écrit :

> A mon avis ce n'est pas un bogue.
> Dans tes préférences tu as indiqué de voir le français avant l'anglais
> puis l'allemand. Il ne trouve pas le français mais trouve l'anglais, donc
> affiche l'anglais même si le lieu est en Allemagne et que sa langue
>

Re: [OSM-talk-fr] noms anglais en Allemagne ?

A mon avis ce n'est pas un bogue.
Dans tes préférences tu as indiqué de voir le français avant l'anglais puis
l'allemand. Il ne trouve pas le français mais trouve l'anglais, donc
affiche l'anglais même si le lieu est en Allemagne et que sa langue
officielle est l'allemand.

Imagine-toi voyager en Chine ou en Algérie: veux-tu voir les noms officiels
en chinois ou arabe officiel, ou bien les noms que tu préfères lire en
français, sinon anglais ou allemand (s'ils sont là), quitte à n'afficher le
chinois que si c'est la dernière option disponible (en ignorant les
éventuels noms qui existeraient en italien, portugais ou espagnol)?

BCP47 permet pas mal de chose: pas seulement fixer une préférence de langue
mais aussi une préférence d'écriture. Si tes préférences sont le français,
puis l'anglais et l'allemand, dans tous les cas tu as émis une préférence
pour l'écriture latine (que tu sais lire). Donc même si tu n'as mis aucune
préférence pour le l'espagnol, le portugais, le néerlandais ou
l'indonésien, il pourraient t'afficher des noms dans ces langues
puisqu'elles sont latines avant même de t'afficher le nom officiel chinois
ou arabe (qui n'est que le dernier recours parce qu'on ne peut plus faire
autrement), ce qu'on appelle "le nom par défaut" mais qui n'est utilisé
"par défaut" que quand les choix pertinents possibles sont épuisés.


Le mer. 5 août 2020 à 21:23,  a écrit :

> En fait tu as dû mettre en préférences de ton compte OSM :
>
> fr en
>
> J'avais :
>
> fr-FR fr en en-US de
>
> Et je me retrouvais avec *Freiburg Minster* comme toi.
>
> J'ai mis :
>
> fr-FR fr de en en-US et j'ai bien *Münster Unserer Lieben Frau*.
>
> Donc le problème c'est que osm.org ne sait pas que la cathédrale de
> Fribourg-en-Brisgau est en Allemagne et que la langue officielle de
> l'Allemagne est l'allemand (default_language
> =de
> de la relation Allemagne ).
>
> Yves va se faire un plaisir d'ouvrir un ticket pour Tom^^.
>
> Jean-Yvon
> Le 05/08/2020 à 20:47, Muselaar - musel...@ouvaton.org a écrit :
>
> (...)
>
> Mais alors, pourquoi c'est le nom anglais qui apparaît sur la liste des
> objets(...)
>
> comme sur l'intitulé du chemin, alors que mon interface est en français ?
>
> ___
> 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] Aire du viaduc de Millau

Je poense que pour des cas comme ça, il faudrait que l'algo de routage ne
cherche pas la route à partir du seul point accessbile le plus proche masi
à partir d'un ensemble de points accessibles facilement dans un rayon
acceptable (qu'on peut finir à pied).
Malgré tout la difficulté est de trouver ce qui est routable à pied: il n'y
a pas toujours de chemin précis mais des surfaces accessibles.

Bref, pourquoi ne pas chercher les routes qui aboutissent (ou passent) dans
les surfaces englobant le point cherché (aussi bien au départ qu'à
l'arrivée) il reste le bout de route inconnu entre le point cherché et le
dernier point routage: on doit malgré tout s'en sortir avec un rayon de
recherche où existe au moins un point accessible à pied.

Et quand il y a plusieurs point routables dans ce rayon et qu'il ne sont
pas routés directement entre eux, classer les résultats et ne pas se
contenter d'un seul résultat sur le seul point routable le plus proche (car
là on aura toujours des résultats aberrants, mais classer les résultats
obtenus par distance ou par temps de parcours sur la partie routable (tout
en estimant à la louche la distance ou le temps "à vol d'oiseau" de la
partie non routable) peut grandement améliorer les choses. On trouvera
parfois un classement incorrect mais afficher une liste de résultats et non
un seul peut aider beaucoup: il suffit de cliquer sur le choix suivant. Une
liste qui proposerait une choix avec au moins 5 ou 6 alternatives devrait
toujours permettre de s'en sortir.

Si le logiciel ne trouve aucun point routable dans le rayon raisonnable
cherché (environ 50 mètres devrait suffire, au delà le lieu devrait avoir
des chemins piétons ajoutés), il peut demander à l'utilisateur de préciser
mieux son point de départ ou d'arrivée en présentant un zoom sur la zone
déjà cherchée. Ce zoom devrait montrer les positions de départ (ou
d'arrivées) possibles déjà trouvée, de sorte que la plupart du temps il
suffira à l'utilisateur de choisir parmi les points proposés en cliquant
dessus, ou déplacer son point de recherche plus précisément)

Note que Google propose par défaut de compléter les chemins voiture trouvés
par des chemins à pied sur une distance courte (là aussi de l'ordre de 50
mètres).

Conclusion: dans des lieux au cheminement compliqué (barrières et
interdictions/restriuctions) diverses, ne pas oublier de tracer les
chémins pîétons entre les différentes zones. Le logiciel de routage
trouvera alors ce qu'il faut (en tenant compte des préférences:
voiture/vélo, sinon terminer à pied, et il trouvera non seulement le
chmin principal mais aussi les derniers segments de chemins piétons tracés
aussi même s'ils ne sont pas complets et ne détaillent pas les surfaces).


Le jeu. 6 août 2020 à 12:20, Percherie OnDaNet 
a écrit :

> C'est aussi vers cette réflexion que je m'orientais. Les données sont
> cohérente avec le terrain mais c'est au routage de s'adapter.
>
> Après essai sur l'Aire d'Hastingues :
> https://www.openstreetmap.org/way/473891861 :
>
>- OSRM : échec
>- GraphHopper : échec
>- OpenRouteService : échec
>- MapQuest : échec
>- Application OsmAnd : échec
>- Application MapFactor Navigator : déplace l'arrivé (drapeau)
>clairement sur le segment le plus proche, ça à le mérite d'être
>compréhensible
>- Application Magic Earth : échec
>- Bing Maps : échec
>- GoogleMaps y arrive seulement parce que le nœud de l'aire est bien
>positionné, autrement ça plante :
>   - Trajet 1 : https://goo.gl/maps/BTma9uZD7wuTEide6
>   - Trajet 2 : https://goo.gl/maps/y3XSoj7c1YPxzAJR9
>- Waze : échec avec des détours hallucinant
>- ViaMichelin plante avec une arrivée imposée en dehors de l'aire
>- Mappy ne connait pas l'aire
>
> En l'état seul un service GAFAM y arrive. Que faut-il faire ? Remonter
> l'anomalie à tous les services ?
> Le 06/08/2020 à 10:24, Christian Quest a écrit :
>
> Le 05/08/2020 à 22:37, Arnaud Champollion a écrit :
>
> Le 05/08/2020 à 17:23, Jérôme Amagat a écrit :
>
> Si on remplace par un node, je pense qu'on aura toujours le problème, dans
> un sens ou dans l'autre de l'autoroute.
>
>
> Et si l'on met ce node sur une zone non accessible en voiture, par exemple
> une zone de pique-nique, peut-être que le routeur n'aura plus intérêt à
> faire effectuer un détour routier ?
>
>
> Le routeur ça chercher la voie d'accès la plus proche, y projet le POI
> d'arrivée et calculer la route sur ce point trouvé.
>
> Cela ne résoudra pas le problème qui est en fait lié à un routage
> mono-mode. Si on faisait un routage multi-modal (voiture + pédibus) il
> trouverai bien sûr qu'il est plus simple de marcher un peu à l'arrivée que
> de faire un énorme détour en voiture.
>
> C'est pour moi plutôt un défaut des algos de routage sur le routage à
> l'arrivée qu'un problème dans les données OSM qui décrivent, il me semble,
> correctement le terrain.
>
>
> ___
> Talk-fr mailing list
>

Re: [OSM-talk-fr] ref:fr vers site http://t4t35.fr/Megalithes/

2020-08-06 Par sujet Georges Dutreix via Talk-fr

Ce site est il très vivant ? Pérenne ? Le dernier message de la page d'accueil 
est une bonne année 2019.

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

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

Le jeu. 6 août 2020 à 21:03,  a écrit :

> Le SIRET n'aurait pas plus d'intérêt : c'est celui de celui qui gère le
> DAE je suppose.
>

L'obligation légale ne concerne pas les gestionnaires (au choix de l'ERP)
mais les établissements ERP eux-mêmes. Ils devraient donc déclarer leurs
établissements équipés eux-mêmes.
Peu importe ensuite si pour cela ils passent par un prestataire externe.
C'est comme nous pour le choix du chauffagiste pour entretenir sa
chaudière. Certes il faut un professionnel agréé (donc numéro d'agrément à
vérifier). Idem pour le détecteur de fumée: à nous de choisir, mais c'est
notre logement qui doit être équipé à une adresse précise, c'est donc nous
qui sommes responsables (et de la faire savoir à son propriétaire si on est
locataire).
Bref identifier les ERP équipés devrait se faire avec leur propre SIRET et
pas celui de leur installateur. A chacun ensuite de voir que l'installateur
est conforme et agréé et d'obtenir l'engagement et la preuve de la
qulification de l'installateur ou la société de maintenance avant de se
décider pour une de leurs offres: ce choix reste privé, même si la loi
impose à ces installateur aussi de pouvoir justifier leur qualification:
mais on on consulte une base gouvernementale où ces agréments sont
délivrés, on doit pouvoir retrouver le professionnel mais pas la liste de
leurs clients, qui n'a rien à voir et reste du droit privé. Il n'est pas
nécessaire ni même utile de faire appraitre dans une base de données
publiques les relations commerciales entre un ERP et ses fournisseurs.
Bref le SIRET de l'installateur ou de la société de maintenance, on s'en
fout et en fait je pense qu'on n'a même pas le droit de l'indiquer dans une
base publique! Le SIRET de l'ERP en revanche si, car l'ERP doit s'engager
publiquement auprès du public qu'il reçoit ou qu'il peut recevoir, ou doit
être capable de recevoir (pour les DAE, il doit pouvoir recevoir tout le
monde, c'et bien pour ça que l'obligation d'équipement impose la pose à
l'extérieur et non à l'intérieur dans les espaces privés).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2020-08-06 Par sujet Éric Gillet


Le 06/08/2020 à 16:43, Yves P. a écrit :

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

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

Tient, ça me rappel la discussion sur les panneaux d'informations touristiques 
;)

+1 :p

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

Evitons le franco-français : name est parfait
(Il faut peut-être vérifier que les moteurs de rendu ne l'affichent pas).

Pour moi la question est : que mettre dedans pour retrouver un DAE rapidement ?

name="DAE de la mairie" est trop descriptif.

Je préfère :

name="Mairie"
defibrillator:location="Au premier étage à droite"


Je pense qu'il vaut mieux pas de nom, car il sera soit trop long 
(Premier étage mairie de Tourcoing), soit trop "simple" (Mairie) et ne 
correspondant pas à un panneau sur place ou un "identifiant".


Pour indiquer la position à un humain : defibrillator:location="Premier 
étage de la mairie à droite", mais même cet exemple peut être bien 
décrit avec les tags :


level=1
location=indoor
opening_hours=*
access=*
operator=Mairie de X (pas sûr, ça doit être une boîte externe qui gère)

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

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

2020-08-06 Par sujet osm . sanspourriel


Le SIRET n'aurait pas plus d'intérêt : c'est celui de celui qui gère le
DAE je suppose.

Et si c'est la commune qui gère le gymnase et comme le gymnase n'est pas
un établissement au sens SIRET (personne travaillant là exclusievment)...

Renseigner le SIREN ne me semble pas savoir le coût/coup.

Car au mieux tu auras des stats sur les données entrées dans OSM sur une
donnée peu motivante (on ne va pas sauver quelqu'un avec un numéro SIREN).

Le 06/08/2020 à 20:49, PanierAvide - panierav...@riseup.net a écrit :


À noter que je n'ai jamais dit que le SIREN servait à géolocaliser ;-)
Je disais que ça peut pas faire de mal de renseigner le SIREN dans le
sens où on sait qui est le gestionnaire de l'appareil, plus
précisément qu'avec son nom uniquement. Une info qui peut permettre de
faire des statistiques à l'échelle nationale par exemple (telle chaîne
n'équipe que 12% de ses établissements...).

Adrien P.
Le 06/08/2020 à 20:13, Philippe Verdy a écrit :

Le jeu. 6 août 2020 à 09:17, PanierAvide mailto:panierav...@riseup.net>> a écrit :

On ne peut pas tout mettre, puisque seules les informations
publiques nous sont accessibles (pas de dates de péremption, de
maintenance...). Pour l'exploitant, au moins le nom ça me semble
essentiel, et le SIREN ça peut pas faire de mal (on a jamais trop
d'infos...).


Le SIREN ne géolocalise rien du tout, c'est juste un numéro
d'identité de personne morale dont on ne connait à priori qu'un siège
social (qui n'est pas nécessairement le lieu même de son
établissement principal mais juste une adresse de contact légal).

Le SIREN ne sert à rien ici. Je veux bien le SIRET (SIREN + code
établissement).

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

Re: [OSM-talk-fr] ref:fr vers site http://t4t35.fr/Megalithes/

> Désolé, je ne comprends toujours rien à wikidata

Il y avait un greffon dans JOSM qui s'appelait tag2link.
Il créait automatiquement un lien vers une page web à partir d'un tag.

La condition était d'avoir un tag "caractéristique" (reconnaissable) pour
générer le bon lien.
Une clé ref est trop générique.

Si tu crées par exemple une clé ref:t4t35, on peut mettre une règle pour
pointer vers http://www.t4t35.fr/Megalithes/AfficheSite.aspx?NumSite=7271
(Ici 7271 est la référence de ton mégalithe sur ce site).

Et maintenant pour faire ça, on utilise Wikidata.
Ça tombe bien, le lien est déjà décrit, il suffit de rajouter la clé
utilisée dans OSM.

Je peux m'occuper de cette étape 

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

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

À noter que je n'ai jamais dit que le SIREN servait à géolocaliser ;-) 
Je disais que ça peut pas faire de mal de renseigner le SIREN dans le 
sens où on sait qui est le gestionnaire de l'appareil, plus précisément 
qu'avec son nom uniquement. Une info qui peut permettre de faire des 
statistiques à l'échelle nationale par exemple (telle chaîne n'équipe 
que 12% de ses établissements...).


Adrien P.

Le 06/08/2020 à 20:13, Philippe Verdy a écrit :
Le jeu. 6 août 2020 à 09:17, PanierAvide > a écrit :


On ne peut pas tout mettre, puisque seules les informations
publiques nous sont accessibles (pas de dates de péremption, de
maintenance...). Pour l'exploitant, au moins le nom ça me semble
essentiel, et le SIREN ça peut pas faire de mal (on a jamais trop
d'infos...).


Le SIREN ne géolocalise rien du tout, c'est juste un numéro d'identité 
de personne morale dont on ne connait à priori qu'un siège social (qui 
n'est pas nécessairement le lieu même de son établissement principal 
mais juste une adresse de contact légal).


Le SIREN ne sert à rien ici. Je veux bien le SIRET (SIREN + code 
établissement).


Ce SIREN, c'est comme si on devait géolocaliser une personne physique 
d'après son numéro de sécu (qui géolocalise partiellement et très 
sommairement que sa commune de naissance ou d'enregistrement, le sexe 
et au mieux le mois et l'année de naissance s'ils sont connus, et pas 
la localisation actuelle).


___
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] Projet du mois de septembre (en préparation) : défibrillateurs !

Le jeu. 6 août 2020 à 09:17, PanierAvide  a écrit :

> On ne peut pas tout mettre, puisque seules les informations publiques nous
> sont accessibles (pas de dates de péremption, de maintenance...). Pour
> l'exploitant, au moins le nom ça me semble essentiel, et le SIREN ça peut
> pas faire de mal (on a jamais trop d'infos...).
>
>
Le SIREN ne géolocalise rien du tout, c'est juste un numéro d'identité de
personne morale dont on ne connait à priori qu'un siège social (qui n'est
pas nécessairement le lieu même de son établissement principal mais juste
une adresse de contact légal).

Le SIREN ne sert à rien ici. Je veux bien le SIRET (SIREN + code
établissement).

Ce SIREN, c'est comme si on devait géolocaliser une personne physique
d'après son numéro de sécu (qui géolocalise partiellement et très
sommairement que sa commune de naissance ou d'enregistrement, le sexe et au
mieux le mois et l'année de naissance s'ils sont connus, et pas la
localisation actuelle).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

Le mer. 5 août 2020 à 10:39, Yves P.  a écrit :

> Pour certains DAE, il faut* indiquer comment le trouver dans le bâtiment.*
>
>

Si c'est un ERP soumis à l'obligation, c'est non conforme. Il est précisé
que cela doit être installé depuis un site accessible par tous à
l'extérieur.

Cela permettriat donc de repérer (Osmose?) les batiments des ERP et voir
s'il y a autour de leur bâtiment ou à un point accessible de l'extérieur
(pas derrière un portail fermé la nuit) l'équipement requis.

Ceci dit rien n'empêche l'ERP d'en avoir aussi à l'intérieur, mais pour son
usage interne si cela lui facilite la vie (surtout si le DAE réglementaire
se trouve loin du bâtiment principal au bout d'une allée derrière un
portail fermé le soir donc pas facilement accessible si on ne peut sortir
facilement de l'ERP).

Mais cela ne l'abstient pas d'installer et entretenir le DAE réglementaire
à l'extérieur et pour tous, à toute heure (oui, aussi la nuit quand l'ERP
est fermé et n'a plus de personnel ou juste des personnels de
sécurité/surveillance qui ne doivent pas empêcher l'accès au DAE
réglementaire). Seront concernés par exemples les DAE dans les galeries
marchandes de centres commerciaux fermés la nuit mais suppléant le DAE
réglementaire accessible de l'extérieure depuis le parking public: ceux
dans la galerie étant plus pratiques et plus faciles d'accès dans la
journée.

Je me demande si la loi impose un nombre d'équipements en fonction de la
fréquentation ou la taille de l'ERP. Ce n'est pas la même chose pour un
petit gymnase municipal et un grand parc de loisirs (p.ex. Disneyland
devrait en avoir en divers endroits dans le parc pour satisfaire les
besoins réels: restaurants, hôtels, principales attractions intérieures ou
extérieures, et ceci indépendamment du fait que le parc dispose de ses
équipes de sécurité et de secours aux personnes déjà sur place et toute
l'année).

De même pour la tour Eiffel, il devrait y en avoir aux principaux étages
les plus fréquentés sans avoir à attendre et emprunter les quelques
ascenseurs. De même dans les grands musées (le Louvre devrait en avoir dans
ses couloirs sans avoir à sortir de l'enceinte), à moins que le lieu
dispose de ses propres équipes d'assistance sur place facilement joignables
apportant le matos nécessaire (DAE, civière) et en principe bien formée aux
gestes d'urgence (même si ce ne sont pas des pompiers mais des sociétés de
sécurité qui doit les former).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] ref:fr vers site http://t4t35.fr/Megalithes/

2020-08-06 Par sujet leni



Le 05/08/2020 à 17:15, Yves P. a écrit :
Il semble que le ref soit calculé de la même façon 
"ref=megalithic.co.uk 9857" vers la 
pagehttps://www.megalithic.co.uk/article.php?sid=9857:
Oui. On le retrouve dans la propriété wikidata P4356 
.


On peut donc créer un clé ref:megalithic et la rajouter dans wikidata.
Ainsi, un clic droit dans JOSM sur le tag pointera directement sur la 
bonne page de ce site :)


http://www.t4t35.fr/Megalithes/AfficheSite.aspx?NumSite=33300

Il y a aussi une propriété sur wikidata : P4346 
 et sont format d'URL.


Encore une clé à créer dans OSM ?
ref:t4t35 ??

Ou créer un mécanisme pour proposer un lien dans JOSM (et consorts) à 
partir de wikidata (pour éviter à Marc de s'arracher les cheveux)


Par exemple pour le Dolmen de Mané Rohr 
 
https://overpass-turbo.eu/s/WMF

site_type=megalith and wikidata →

  * identifiant T4T35 7271
 →
http://www.t4t35.fr/Megalithes/AfficheSite.aspx?NumSite=7271
  * identifiant Mérimée PA00091767
 →
https://www.pop.culture.gouv.fr/notice/merimee/PA00091767

Désolé, je ne comprends toujours rien à wikidata ; je vais remplacer ces 
ref:fr par une une note  ; et mettre un lien vers tes réponses ?


leni

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

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

2020-08-06 Par sujet Jacques Lavignotte




Le 05/08/2020 à 10:38, Yves P. a écrit :


Comment publier des photos utiles ?
Une, deux ?


Une : https://postimg.cc/zHk0cms3


Sur quel site ? Dans quels champs ?



image=*

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

> Il me semble que le tag pour ça c'est plutôt defibrillator:location
> 
> Et en version simplifiée comme dit Yves.
> 
> Mais sans name=Mairie. C'est le DAE de la mairie, à côté de la mairie,
> dans la mairie Et non quand je cherche la mairie je ne cherche pas
> un DAE nommé Mairie. Là, c'est la proximité qui doit permettre
> d'indiquer que c'est à telle adresse près/dans tel équipement (public en
> général).
Oui et non :D

Ce que tu décris fonctionne bien pour trouver un DAE visuellement sur la carte.
Je vois un logo de DAE à côté ou dans la mairie.

Par contre, si tu dois expliquer à quelqu'un où se trouve le DAE (pourquoi pas 
avec une synthèse vocale) où trouver l'info ?
Pour l'adresse on fait un géo codage inverse et ça roule.

Pour dire que c'est contre le mur de la mairie ou dans la mairie, c'est plus 
dur pour une machine.

Dans OsmHydrant (cf. copie d'écran 
),
 on a une photo, on "voit" le logo du DAE à côté de celui de la mairie, mais 
pour moi il manque un titre bien visible "Mairie".

> J'avais fait une passe sur les DAE brestois (issus d'une base locale).
> 
> http://overpass-turbo.eu/s/WOK 
On a plusieurs tags pour une même infos.
Plusieurs infos dans un même tag (titre, localisation, date, parfois même le 
téléphone)
Je n'ai pas vu de photos. Elles sont dans Wikimedia Commons à la sauce OSM 
Hydrant ?

Il y a donc besoin de normaliser ça (quelque soit l'éditeur utilisé).

Et ça serait intéressant de voir avec quel éditeur ça a été éditer ?
(defibrillator:location avec JOSM, note avec id ?)

__
Yves
"note": "A l'exterieur de la Mairie de Saint-Pierre. 24/24 / Ajout : 
18/05/12",
"defibrillator:location": "À l'extérieur de la Mairie des Quatre-Moulins",
"note": "Au CCI (Port de Commerce) / Ajout : 18/05/12",
"defibrillator:location": "À l'intérieur du Trésor Public",
"note": "A l'EHPAD (résidence BRANDA) / Ajout : 18/05/12",
"defibrillator:location": "À l'extérieur de la Mairie du quartier de 
Saint-Marc.",
"defibrillator:location": "A l'extérieur de la Mairie de Bellevue",
"note": "A l'extérieur de la Mairie du quartier de l'Europe. 24/24. TEL:02 
98 34 26 30 / Ajout : 18/05/12",
"defibrillator:location": "À l'extérieur de la mairie de quatier",
"note": "A l'IFAC (CCI) / Ajout : 18/05/12",
"note": "A l'Hôpital des Armées / Ajout : 20/05/2012",
"note": "Au groupe scolaire Kerichen / Ajout : 20/05/12",
"note": "A la CPAM (Caisse primaire d'assurance maladie) / Ajout : 
20/05/2012",
"note": "A la résidence Ker Héol / Ajout : 20/05/12",
"note": "Au Centre Commercial Géant - Phare de l'Europe / Ajout : 20/05/12",
"note": "Au CIN (Centre d'Instruction Navale)/ Accès restreint / Ajout : 
03/06/12",
"note": "Au Centre de Soins de Suite et de Réadaptation TY YANN / Ajout : 
03/06/12",
"note": "A l'UBO (Université de Bretagne Occidentale), 13 défibrillateurs 
sont répartis sur le site / Ajout : 03/06/12",
"note": "Au groupe scolaire La Croix Rouge / Ajout : 03/06/12",
"note": "Chez Alcatel-Lucent / Ajout : 03/06/12",
"note": "A l'UFR Sciences et Techniques, à l'entrée du batiment C au 
rez-de-chaussée - Ajout 21/07/2012"
"defibrillator:location": "A l'infirmerie du Collège - Lycée Charles de 
Foucauld",
"note": "A Brest'aim (ex SOPAB) - Ajout 21/07/2012",
"note": "A la Marina du Port du Chateau / Ajout : 23/07/12",
"note": "Au Fourneau / Ajout : 23/07/12",
"note": "A la Piscine de Recouvrance / Ajout : 23/07/12",
"note": "Au centre Commercial Iroise/ Ajout :  23/07/12",
"note": "Au Quartz / Ajout : 23/07/12",
"note": "A Océanopolis / Ajout :  23/07/12",
"layer": "-2",
"note": "Situé dans le parking Liberté, Entrée côté Rue Jean Jaurès / Ajout 
: 23/07/12",
"note": "A la residence Amitie D'Armor / Ajout : 23/07/12",
"note": "A la marina du Moulin-Blanc / Ajout : 23/07/12",
"defibrillator:location": "Au Parking Jaurès, entrée par la Rue Yves 
Collet",
"defibrillator:location": "Au Parking de Coat-Ar-Gueven, Entrée par Rue 
Malherbe ou Rue Dupleix",
"note": "A la piscine Foch, centre de secours à proximité/ Ajout : 
23/07/12",
"note": "Au SDIS 29/ Ajout : 23/07/12",
"note": "Au Centre d'examens de Santé / Ajout : 23/07/12",
"defibrillator:location": "A la piscine Saint-Marc",
"defibrillator:location": "A la piscine de Kerhalet",
"defibrillator:location": "A la patinoire Rinkla Stadium",
"defibrillator:location": "A la piscine Ferdinand Buisson",
"defibrillator:location": "A l'ENSTA Bretagne (ex-ENSIETA)",
"defibrillator:location": "A la Caserne des Sapeurs Pompiers",
"description": "Dans le hall de la gare de Brest, vers l'accès aux quais à 
gauche",
"name": "défibrillateur",
"note": "A l'entrée de la vie scolaire du lycée."
"operator": "PC Sécurité",

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

2020-08-06 Par sujet osm . sanspourriel


Il me semble que le tag pour ça c'est plutôt defibrillator:location

Et en version simplifiée comme dit Yves.

Mais sans name=Mairie. C'est le DAE de la mairie, à côté de la mairie,
dans la mairie Et non quand je cherche la mairie je ne cherche pas
un DAE nommé Mairie. Là, c'est la proximité qui doit permettre
d'indiquer que c'est à telle adresse près/dans tel équipement (public en
général).

J'avais fait une passe sur les DAE brestois (issus d'une base locale).

http://overpass-turbo.eu/s/WOK

Visiblement je n'ai pas assez fait le ménage comme on voit ici :

un défibrillateur qui est un point adresse
https://www.openstreetmap.org/node/1774509098

alors qu'il y a à côté un beau point adresse sans redondance :
https://www.openstreetmap.org/node/1702549045

Au fait on voit au passage que la source était privé ou n'est plus publique.

Pour le machin de GeoDAE c'est au plus official_name !

On met des contact:addr ?

Christian, quand je parlais de rapprochement, je pensais à rapprocher
les coordonnées OSM du géocodage (propre, pas Geo DAE) de l'adresse Geo
DAE. Même ça c'est pourri ?

Jean-Yvon

Le 06/08/2020 à 16:32, PanierAvide - panierav...@riseup.net a écrit :

Bonjour à tous,

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

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

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

Cordialement,

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




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

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

> effectivement ça vaudrait le coup de vérifier les presets JOSM et iD (tu 
> pourrais t'en occuper ?).
> 
Les copies d'écran sont là : 
https://wiki.openstreetmap.org/wiki/User:Pyrog/defibrillateurs 


Dans JOSM c'est bien structuré : il manque le fameux tag name (en discussion) 
et la référence (notre ref:FR:GeoDAE).
Il faudrait probablement réorganiser les champs :
"nom"
description de l'emplacement
référence
boutons radio : extérieur / intérieur / ?
…

Dans iD, il manque l'essentiel : le nom du lieu, et l'emplacement dans ce lieu.

Dans les 2 cas, il n'y a rien pour suggérer de mettre une ou plusieurs photos 
dans le tag approprié.

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

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

> Pareil... name c'est pas là pour décrire un objet.
+1 pour une description "boite carré verte avec un voyant clignotant" :D

Par contre, ça peut-être considérer comme un nom :

Arrêt de bus "Mairie". C'est une description ? ;-)


> Pour moi, ce n'est donc pas un name=*, ce serait à concaténer avec les 
> instructions de localisation (au vu de ceux que j'ai voulu intégrer), sinon 
> on va avoir un bout dans un tag et l'autre dans un autre…
Tu proposes quoi concrètement ?

Dans les applications, sites web, listes en tout genre de DAE que j'ai consulté 
on trouve souvent deux infos (en plus de la géolocalisation) :
Un "titre".
Une description claire et concise de l'accès.

"Salle des fêtes" et "dans le hall du RdC à gauche"

Un pompier au CTA qui indique par téléphone la position du DAE ne va pas donner 
de coordonnées GPS.
Il se focalise sur l'info essentielle : c'est à la mairie, puis détail le reste…

> Le fait que name soit souvent mal employé n'est pas une raison suffisante 
> pour continuer.
Je maintiens que name est le plus adapté maintenant.

Une fois un consensus trouvé au niveau international, on aura plus qu'à faire 
des modifications de masses : name → le_bon_tag_sémantiquement_parlant

__
Yves


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

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

Le 06/08/2020 à 16:43, Yves P. a écrit :

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

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

Tient, ça me rappel la discussion sur les panneaux d'informations touristiques
;)

Pareil... name c'est pas là pour décrire un objet.

Pour moi, ce n'est donc pas un name=*, ce serait à concaténer avec les
instructions de localisation (au vu de ceux que j'ai voulu intégrer),
sinon on va avoir un bout dans un tag et l'autre dans un autre...

Le fait que name soit souvent mal employé n'est pas une raison
suffisante pour continuer.

--
Christian Quest - OpenStreetMap France

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

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

> Suite au travail lancé pour ajouter des jeux de données dans Osmose autour 
> des défibrillateurs, la question se pose de la pertinence du tag name=* sur 
> les défibrillateurs [1,2]. En effet, dans les jeux de données (GéoDAE, 
> AEDMAP, bases locales), un nom est souvent associé au DAE. Ce nom est plutôt 
> descriptif, exemples "DAE de la mairie", "Défibrillateur de la salle XYZ". 
> Dans certains cas, il ressemble plutôt à une référence. Il est proposé ainsi 
> d'opter pour l'utilisation de ref=* ou description=*.
> 
> En parallèle, dans la base de données OSM aujourd'hui, on constate que 14% 
> des DAE ont un tag name=* associé. C'est plus que ref=* (5%) ou description=* 
> (moins de 3% ?). Une requête Overpass fait ressortir que les valeurs du champ 
> name=* sur les DAE sont plutôt descriptives. C'est un usage qui dépasse nos 
> frontières à la vue des langues utilisées. Même si ce sont des noms 
> descriptifs, l'usage montre que name=* est l'attribut pour stocker cette info.
Tient, ça me rappel la discussion sur les panneaux d'informations touristiques 
;)

> La question est donc la suivante : doit-on préferer le champ name=* pour 
> cette info (usage international), utiliser un champ ref=* (plus logique 
> sémantiquement, mais qui sera une spécificité FR), voire ne pas proposer 
> d'ajouter l'info du nom dans OSM (arbitrage simple mais on perd une info) ? 
> Merci pour vos avis qui permettront de débloquer l'ajout de nouveaux jeux 
> dans Osmose :-)
Evitons le franco-français : name est parfait
(Il faut peut-être vérifier que les moteurs de rendu ne l'affichent pas).

Pour moi la question est : que mettre dedans pour retrouver un DAE rapidement ?

name="DAE de la mairie" est trop descriptif.

Je préfère :

name="Mairie"
defibrillator:location="Au premier étage à droite"

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

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


Bonjour à tous,

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


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


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


Cordialement,

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

--
Adrien P.


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

[OSM-talk-fr] Ajout de l'ortho-photo de Bordeaux 2016 sur wms.openstreetmap.fr

Je ne sais pas pourquoi je ne l'avais pas déjà ajoutée sur 
wms.openstreetmap.fr, peut être à cause du clicodrome pour récupérer les 
dalles d'images ?


Je l'ai ajoutée hier, couche bordeaux_2016 mais aussi intégrée à la 
couche "tous_fr" qui est la composite avec priorité données aux orthos 
les plus récentes/précises et que je vous recommande.


--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] bug calcul itinéraire - Aire du viaduc de Millau

2020-08-06 Par sujet Cyrille37 OSM



Le 06/08/2020 à 12:18, Percherie OnDaNet a écrit :


C'est aussi vers cette réflexion que je m'orientais. Les données sont 
cohérente avec le terrain mais c'est au routage de s'adapter.


Après essai sur l'Aire d'Hastingues : 
https://www.openstreetmap.org/way/473891861 :


  * OSRM : échec
  * GraphHopper : échec

Juste pour imager le bug des routeurs avec cet exemple. Le routeur 
calcule un grand détour pour arriver au plus près du bâtiment, et manque 
donc la bretelle d'accès à l'aire.


https://pic.infini.fr/8qC7lhmj/6KJCdWLv

capture d'écran résultat routeurs OSM et Graphopper

Cyrille37.

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

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

C'est là toute la question :-) À vérifier sur d'autres analyses, il y a 
peut-être des exemples ?


Adrien P.

Le 06/08/2020 à 12:17, Yves P. a écrit :


Par contre je ne saurais pas comment on gère le rapprochement avec 
plusieurs alternatives de tags côté Osmose.
Un seul analyseur avec les tags *emergency=defibrillator* et 
*disused:emergency=defibrillator* si on peut indiquer une condition "OU" ?


Sinon deux analyseurs, un par tag mais bof.

Mapping(

select = Select(

types = ["nodes"],

tags = {"emergency": "defibrillator"}),

__
Yves

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

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

> On a un autre point à prévoir avec l'équipe de GéoDAE après le 15 août, on en 
> parlera à ce moment là.
Tant qu'à demander, mettre aussi un export CSV, JSON…

https://geodae.atlasante.fr/dae/1234.html 

https://geodae.atlasante.fr/dae/1234.csv 

https://geodae.atlasante.fr/dae/1234.json 

…

> Je n'ai pas d'accès au portail, une démo avait été présentée il y a quelques 
> mois en visio
Ok.

J'ai demandé aux élus Jurassiens si ils en ont un…

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

Re: [OSM-talk-fr] Aire du viaduc de Millau

2020-08-06 Par sujet Percherie OnDaNet

C'est aussi vers cette réflexion que je m'orientais. Les données sont 
cohérente avec le terrain mais c'est au routage de s'adapter.


Après essai sur l'Aire d'Hastingues : 
https://www.openstreetmap.org/way/473891861 :


 * OSRM : échec
 * GraphHopper : échec
 * OpenRouteService : échec
 * MapQuest : échec
 * Application OsmAnd : échec
 * Application MapFactor Navigator : déplace l'arrivé (drapeau)
   clairement sur le segment le plus proche, ça à le mérite d'être
   compréhensible
 * Application Magic Earth : échec
 * Bing Maps : échec
 * GoogleMaps y arrive seulement parce que le nœud de l'aire est bien
   positionné, autrement ça plante :
 o Trajet 1 : https://goo.gl/maps/BTma9uZD7wuTEide6
 o Trajet 2 : https://goo.gl/maps/y3XSoj7c1YPxzAJR9
 * Waze : échec avec des détours hallucinant
 * ViaMichelin plante avec une arrivée imposée en dehors de l'aire
 * Mappy ne connait pas l'aire

En l'état seul un service GAFAM y arrive. Que faut-il faire ? Remonter 
l'anomalie à tous les services ?


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

Le 05/08/2020 à 22:37, Arnaud Champollion a écrit :

Le 05/08/2020 à 17:23, Jérôme Amagat a écrit :
Si on remplace par un node, je pense qu'on aura toujours le 
problème, dans un sens ou dans l'autre de l'autoroute.


Et si l'on met ce node sur une zone non accessible en voiture, par 
exemple une zone de pique-nique, peut-être que le routeur n'aura plus 
intérêt à faire effectuer un détour routier ? 


Le routeur ça chercher la voie d'accès la plus proche, y projet le POI 
d'arrivée et calculer la route sur ce point trouvé.


Cela ne résoudra pas le problème qui est en fait lié à un routage 
mono-mode. Si on faisait un routage multi-modal (voiture + pédibus) il 
trouverai bien sûr qu'il est plus simple de marcher un peu à l'arrivée 
que de faire un énorme détour en voiture.


C'est pour moi plutôt un défaut des algos de routage sur le routage à 
l'arrivée qu'un problème dans les données OSM qui décrivent, il me 
semble, correctement le terrain.



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

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


> Par contre je ne saurais pas comment on gère le rapprochement avec plusieurs 
> alternatives de tags côté Osmose.
Un seul analyseur avec les tags emergency=defibrillator et 
disused:emergency=defibrillator si on peut indiquer une condition "OU" ?

Sinon deux analyseurs, un par tag mais bof.

Mapping(
select = Select(
types = ["nodes"],
tags = {"emergency": "defibrillator"}),
__
Yves___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

On a un autre point à prévoir avec l'équipe de GéoDAE après le 15 août, 
on en parlera à ce moment là. Je n'ai pas d'accès au portail, une démo 
avait été présentée il y a quelques mois en visio, et j'ai jeté un coup 
d’œil par le biais de ma conjointe (qui travaille en mairie) lorsqu'elle 
a déclaré celui de son lieu de travail.


Adrien P.

Le 06/08/2020 à 12:09, Yves P. a écrit :

Réservé aux propriétaires/mainteneurs de DAE, pas de lien public.

Oui, mais on pourrait mettre quand même un lien dessus ?
Avec un peu de chance, ça n'affiche que les informations publiques si on n'est 
pas identifié ?

Et si non, on pourrait le suggérer ?
__
Yves

PS: Je pensais que tu avais un accès à l'interface car tu semblais l'avoir 
testé ?
___
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] Projet du mois de septembre (en préparation) : défibrillateurs !

Oui c'est sûr qu'à terme ce sera intéressant d'avoir ce niveau de 
détail. Par contre je ne saurais pas comment on gère le rapprochement 
avec plusieurs alternatives de tags côté Osmose.


Adrien P.

Le 06/08/2020 à 12:06, Yves P. a écrit :

Et ne prend en compte que les DAE notés "En fonctionnement".

Elle pourrait aussi prendre en compte les autres mais avec le tag disused: 
emergency=defibrillator ;)

Ne serait-ce que pour prévenir qu'un DAE dans OSM n'est peut-être pas à jour.
__
Yves
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


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

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

> Réservé aux propriétaires/mainteneurs de DAE, pas de lien public.
Oui, mais on pourrait mettre quand même un lien dessus ?
Avec un peu de chance, ça n'affiche que les informations publiques si on n'est 
pas identifié ?

Et si non, on pourrait le suggérer ?
__
Yves

PS: Je pensais que tu avais un accès à l'interface car tu semblais l'avoir 
testé ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

> Et ne prend en compte que les DAE notés "En fonctionnement".
Elle pourrait aussi prendre en compte les autres mais avec le tag disused: 
emergency=defibrillator ;)

Ne serait-ce que pour prévenir qu'un DAE dans OSM n'est peut-être pas à jour.
__
Yves
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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


Réservé aux propriétaires/mainteneurs de DAE, pas de lien public.

Adrien P.

Le 06/08/2020 à 12:00, Yves P. a écrit :

Du coup il doit y avoir un lien direct sur un DAE dans ce formulaire ?

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


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

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

L'analyse Osmose est ici pour référence : 
https://github.com/osm-fr/osmose-backend/blob/master/analysers/analyser_merge_defibrillators_FR.py


Et ne prend en compte que les DAE notés "En fonctionnement".

Adrien P.

Le 06/08/2020 à 11:05, Yves P. a écrit :

Est-ce vraiment une bonne idée ?
J'ai l'impression qu'on essaye de coller au plus près des données fournies. Si 
un défibrillateur est hors-service ou supprimé, je conseillerai plutôt de la 
cartographier en disused:emergency=defibrillator.

+1

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


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

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

> Il y a effectivement bien une interface web pour gérer ses DAE, avec un 
> formulaire progressif. Ça se prête bien au cas où on a moins d'une dizaine de 
> DAE à gérer, ou pour les mises à jour. Bon évidemment l'ergonomie du 
> formulaire pourrait être améliorée par certains aspects, mais c'est encore 
> autre chose.
Du coup il doit y avoir un lien direct sur un DAE dans ce formulaire ?

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

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

Il y a effectivement bien une interface web pour gérer ses DAE, avec un 
formulaire progressif. Ça se prête bien au cas où on a moins d'une 
dizaine de DAE à gérer, ou pour les mises à jour. Bon évidemment 
l'ergonomie du formulaire pourrait être améliorée par certains aspects, 
mais c'est encore autre chose.


Adrien P.

Le 06/08/2020 à 11:03, Yves P. a écrit :

Pour les DAE, tout exploitant doit fournir un fichier CSV qui va bien, même si 
il ne comporte qu'une ligne... ridicule.

La FAQ dit qu'on peut saisir directement un DAE dans un formulaire ;)


On avait déjà ça avec les IRVE... mais là au moins il y avait une carotte : la 
subvention versée si les données sont publiées.

Ici la carotte est de sauver potentiellement des vies :)

Pour les petites structures, il faut qu'elles connaissent l'existence de GeoDAE et de son 
formulaire de "déclaration".

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


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

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

> Est-ce vraiment une bonne idée ?

> J'ai l'impression qu'on essaye de coller au plus près des données fournies. 
> Si un défibrillateur est hors-service ou supprimé, je conseillerai plutôt de 
> la cartographier en disused:emergency=defibrillator.
+1

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

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


> Pour les DAE, tout exploitant doit fournir un fichier CSV qui va bien, même 
> si il ne comporte qu'une ligne... ridicule.
La FAQ dit qu'on peut saisir directement un DAE dans un formulaire ;)

> On avait déjà ça avec les IRVE... mais là au moins il y avait une carotte : 
> la subvention versée si les données sont publiées.
Ici la carotte est de sauver potentiellement des vies :)

Pour les petites structures, il faut qu'elles connaissent l'existence de GeoDAE 
et de son formulaire de "déclaration".

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

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

2020-08-06 Par sujet JB

Je profite de la discussion pour poser la question de la traduction de « 
etat_fonct » de GeoDAE, convertie dans OSM en :
operational_status=[[Tag:operational_status=operating/out_of_order/closed/short_term_absence/unknown|operating/out_of_order 
/closed/short_term_absence/unknown]] 
(https://wiki.openstreetmap.org/wiki/FR:Tag:emergency=defibrillator#Liste_des_donn.C3.A9es_obligatoires)

Est-ce vraiment une bonne idée ?
J'ai l'impression qu'on essaye de coller au plus près des données 
fournies. Si un défibrillateur est hors-service ou supprimé, je 
conseillerai plutôt de la cartographier en disused:emergency=defibrillator.
(Si je cherche un DAE, je cherche emergency=defibrillator, sans 
forcément filtrer sur les clés « secondaires » pour vérifier qu'il 
existe réellement.)

JB.

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

Le 06/08/2020 à 09:10, PanierAvide a écrit :


On ne peut pas tout mettre, puisque seules les informations publiques 
nous sont accessibles (pas de dates de péremption, de 
maintenance...). Pour l'exploitant, au moins le nom ça me semble 
essentiel, et le SIREN ça peut pas faire de mal (on a jamais trop 
d'infos...).




ref:FR:SIREN devrait décrire une entreprise (plus exactement son 
siège, car ce n'est pas un SIRET correspondant à un de ses 
établissements), pas un équipement exploité par cette entreprise.


Ici il s'agit de la source de l'info, donc un tag xxx:source ou 
source:xxx me semblerait plus approprié, lequel ? celui qui indique 
que la source est ce SIREN et pas quelle est la source du SIREN... 
donc plutôt ref:FR:SIREN:source ;)



Et pas sûr qu'il y ait (pour l'instant ?) de lien direct vers une 
fiche web pour chaque DAE. Quasi toutes les infos exploitables sont 
celles qui ressortent dans Osmose.



Ça viendra d'une façon ou d'une autre, si facile à mettre en place.





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

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


Le 06/08/2020 à 10:34, Yves P. a écrit :
ref:FR:SIREN devrait décrire une entreprise (plus exactement son 
siège, car ce n'est pas un SIRET correspondant à un de ses 
établissements), pas un équipement exploité par cette entreprise.

:)

Ici il s'agit de la source de l'info, donc un tag xxx:source ou 
source:xxx me semblerait plus approprié, lequel ?
euh, la source serait plutôt GeoDAE et plus exactement le fichier OD 
sur data.gouv.fr  ?


Ici je parle de la source d'origine... GeoDAE n'est qu'une agrégation de 
celles-ci.



Le 06/08/2020 à 10:36, PanierAvide a écrit :
C'était pas bien sinon operator:ref:FR:SIREN=* ? Comme le champ 
operator=* contient déjà le nom du gestionnaire, la tendance est à 
operator:ref=*, mais comme on précise le type de référence et bien 
operator:ref:FR:SIREN. Et en terme d'ergonomie, les deux attributs 
seront affichés à la suite dans les éditeurs ;-)



Oui, c'est une bien meilleure option


--
Christian Quest - OpenStreetMap France

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

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


Le 06/08/2020 à 10:29, PanierAvide a écrit :
C'est pas utopique si c'est une obligation légale : ça fonctionne bien 
pour les prix des carburants et les déclarations de revenus, il n'y a 
pas de raisons que ça ne fonctionne pas pour les DAE. Le tout c'est 
qu'il y ait à terme des contrôles et sanctions en cas de manquements.


Une obligation sans conséquence quand elle n'est pas respectée n'est 
qu'un beau souhait...


Pour les carburants, il y a beaucoup moins de stations, et les plus 
petites sont exemptées de remonter leurs prix ;)


Pour les DAE, tout exploitant doit fournir un fichier CSV qui va bien, 
même si il ne comporte qu'une ligne... ridicule.


On avait déjà ça avec les IRVE... mais là au moins il y avait une 
carotte : la subvention versée si les données sont publiées.



Si on ajoute des contrôles et sanctions pour non déclaration de DAE dans 
la base nationale et bien on verra mécaniquement diminuer le nombre de 
DAE non obligatoires (hors ERP), pour ne pas avoir à s'emm*** avec des 
démarches administratives supplémentaires.



Pour alimenter des bases nationales, il faut viser le petit nombre 
d'acteurs par qui ces données passent déjà ou existent déjà.


Imaginerait-on devoir déclarer son bilan DPE à l'ademe de façon 
individuelle ? Non, ce sont les diagnostiqueurs qui les font remonter 
dans la base nationale, et du coup elle est quasi exhaustive (et quand 
même pas super propre).


--
Christian Quest - OpenStreetMap France


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

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

C'était pas bien sinon operator:ref:FR:SIREN=* ? Comme le champ 
operator=* contient déjà le nom du gestionnaire, la tendance est à 
operator:ref=*, mais comme on précise le type de référence et bien 
operator:ref:FR:SIREN. Et en terme d'ergonomie, les deux attributs 
seront affichés à la suite dans les éditeurs ;-)


Adrien P.

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


ref:FR:SIREN devrait décrire une entreprise (plus exactement son 
siège, car ce n'est pas un SIRET correspondant à un de ses 
établissements), pas un équipement exploité par cette entreprise.


Ici il s'agit de la source de l'info, donc un tag xxx:source ou 
source:xxx me semblerait plus approprié, lequel ? celui qui indique 
que la source est ce SIREN et pas quelle est la source du SIREN... 
donc plutôt ref:FR:SIREN:source ;)


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

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

> ref:FR:SIREN devrait décrire une entreprise (plus exactement son siège, car 
> ce n'est pas un SIRET correspondant à un de ses établissements), pas un 
> équipement exploité par cette entreprise.
:)

> Ici il s'agit de la source de l'info, donc un tag xxx:source ou source:xxx me 
> semblerait plus approprié, lequel ?
euh, la source serait plutôt GeoDAE et plus exactement le fichier OD sur 
data.gouv.fr  ?

__
Yves

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

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


Le 06/08/2020 à 09:10, PanierAvide a écrit :


On ne peut pas tout mettre, puisque seules les informations publiques 
nous sont accessibles (pas de dates de péremption, de maintenance...). 
Pour l'exploitant, au moins le nom ça me semble essentiel, et le SIREN 
ça peut pas faire de mal (on a jamais trop d'infos...).




ref:FR:SIREN devrait décrire une entreprise (plus exactement son siège, 
car ce n'est pas un SIRET correspondant à un de ses établissements), pas 
un équipement exploité par cette entreprise.


Ici il s'agit de la source de l'info, donc un tag xxx:source ou 
source:xxx me semblerait plus approprié, lequel ? celui qui indique que 
la source est ce SIREN et pas quelle est la source du SIREN... donc 
plutôt ref:FR:SIREN:source ;)



Et pas sûr qu'il y ait (pour l'instant ?) de lien direct vers une 
fiche web pour chaque DAE. Quasi toutes les infos exploitables sont 
celles qui ressortent dans Osmose.



Ça viendra d'une façon ou d'une autre, si facile à mettre en place.

--

Christian Quest - OpenStreetMap France


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

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

C'est pas utopique si c'est une obligation légale : ça fonctionne bien 
pour les prix des carburants et les déclarations de revenus, il n'y a 
pas de raisons que ça ne fonctionne pas pour les DAE. Le tout c'est 
qu'il y ait à terme des contrôles et sanctions en cas de manquements.


Adrien P.

Le 06/08/2020 à 10:18, Christian Quest a écrit :
C'est toute la difficulté. Ce sont potentiellement des centaines de 
milliers d'exploitants qui vont devoir déclarer leur DAE dans la base 
ce qui est utopique.


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

Re: [OSM-talk-fr] Aire du viaduc de Millau


Le 05/08/2020 à 22:37, Arnaud Champollion a écrit :

Le 05/08/2020 à 17:23, Jérôme Amagat a écrit :
Si on remplace par un node, je pense qu'on aura toujours le problème, 
dans un sens ou dans l'autre de l'autoroute.


Et si l'on met ce node sur une zone non accessible en voiture, par 
exemple une zone de pique-nique, peut-être que le routeur n'aura plus 
intérêt à faire effectuer un détour routier ? 


Le routeur ça chercher la voie d'accès la plus proche, y projet le POI 
d'arrivée et calculer la route sur ce point trouvé.


Cela ne résoudra pas le problème qui est en fait lié à un routage 
mono-mode. Si on faisait un routage multi-modal (voiture + pédibus) il 
trouverai bien sûr qu'il est plus simple de marcher un peu à l'arrivée 
que de faire un énorme détour en voiture.


C'est pour moi plutôt un défaut des algos de routage sur le routage à 
l'arrivée qu'un problème dans les données OSM qui décrivent, il me 
semble, correctement le terrain.



--
Christian Quest - OpenStreetMap France


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

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

> On ne peut pas tout mettre, puisque seules les informations publiques nous 
> sont accessibles (pas de dates de péremption, de maintenance…).
> 
En théorie, c'est visible  sur le terrain : "Depuis le 1er janvier 2020, pour 
les dispositifs installés, il est obligatoire d’apposer sur le boîtier ou à 
proximité immédiate de l’appareil une étiquette conforme au modèle suivant" 
(cf. FAQ 
)
> SIREN ça peut pas faire de mal (on a jamais trop d'infos...).
> 
trop d'info tue l'info ;)

> Et pas sûr qu'il y ait (pour l'instant ?) de lien direct vers une fiche web 
> pour chaque DAE. Quasi toutes les infos exploitables sont celles qui 
> ressortent dans Osmose.
> 
Il faut demander ça à data.gouv.fr  (en général) ou dans 
ce cas précis à https://geodae.atlasante.fr/  ?

__
Yves

PS: j'ai du mal avec data.gouv.fr  et ses cousins 
geo.data.gouv.fr … (il me semble qu'il en y en a 
d'autres)
Pourquoi plusieurs sites avec semble-t-il les mêmes données ?
Quelles sont leur différences ?___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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


Le 05/08/2020 à 20:58, osm.sanspourr...@spamgourmet.com a écrit :


Le 05/08/2020 à 19:57, Christian Quest - cqu...@openstreetmap.fr a écrit :


- peut-on améliorer le jeu de données OSM à partir de la base Geo DAE ?

On peut, mais c'est fastidieux vu la mauvaise qualité de la géoloc 
fournie par GeoDAE...


Je me suis mal fait comprendre je pensais aux champs autres de la 
base. Si tu prends ta commune et qu'il est écrit disons Mairie, tu 
sais où aller chercher le DAE s'il n 'est pas dans OSM (et ajouter la 
ref:FR:GeoDAE).


Pas sûr malheureusement. Les "noms" ne sont pas forcément cohérents à ce 
que j'ai pu voir sur ceux que j'ai voulu intégrer.


Avant d'avoir le moindre avis sur le contenu de cette base, je me suis 
pris les DAE d'un département pour voir... et j'ai pas été déçu (enfin 
si, déçu de ce que j'ai trouvé).



Au fait, emergency 
=defibrillator 
 
n'est plus affiché sur le style OSM FR ? On est resté sur le tag aed ?



Oups... je corrige ça.

Les deux tags sont reconnus, par contre, j'ai supprimé le rendu des 
medical=aed. Ceux en indoor=yes sont toujours un peu transparents pour 
les différencier.




Le 05/08/2020 à 20:11, Philippe Verdy - ver...@gmail.com a écrit :
Et tu crois que le 18/112 va chercher les DAE dans OSM pour guider 
l'appelant ?


15/18/112 : pourquoi veux-tu qu'ils utilisent la page osm.org ?

Je crois que tu sais que OSM c'est une base de données réutilisable^^ 
et que la création de GeoDAE est la preuve qu'actuellement 
l'information est mal consolidée.


Est-ce qu'un site départemental d'appel connait tous les DAE du 
département ?


J'aimerai en être sûr. Et si les données OSM peuvent servir de 
référence tant mieux. Alors soit une couche spécialisée sera faite 
pour leurs outils soit des applications/sites seront développés 
utilisant les données OSM.


Si effectivement les 15/18/112 connaissent toutes les positions des 
DAE, il faut qu'ils nous les donnent, ça leur fera gagner du temps !


Personne ne connait l'ensemble des DAE car il s'en installe de plus en 
plus dans des lieux non publics comme les commerces et les entreprises.


C'est toute la difficulté. Ce sont potentiellement des centaines de 
milliers d'exploitants qui vont devoir déclarer leur DAE dans la base ce 
qui est utopique.



--
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] noms anglais en Allemagne ?

> fr-FR fr de en en-US et j'ai bien Münster Unserer Lieben Frau.
> 
> Donc le problème c'est que osm.org  ne sait pas que la 
> cathédrale de Fribourg-en-Brisgau est en Allemagne et que la langue 
> officielle de l'Allemagne est l'allemand (default_language 
> =de
>  de la relation Allemagne ).
> 
Ok, je n'avais pas vu que Muselaar parlait du libellé affiché dans la page OSM 
et pas du tag name.

>> Par contre name:de fait doublon avec name…
> Sûr ? Pourtant il permet :
> 
> 1) d'être sûr d'obtenir un nom en allemand
> 
> 2) de détecter que name=* est ici en allemand vu qu'il est identique à 
> name:de=*
> 
Ok, je n'avais pas pensé à ça :)

Par contre si je te suis bien, il faut dupliquer tous les name en name:fr pour 
tous les objets OSM en France ??

Est-ce que ça ne serait pas plus "économique" de spécifier la langue dans le 
tag name comme dans le tag wikipedia ?
name="fr:Tour Eiffel"
name:en="Eiffel Tower"
…

Pour les noms multilingues comment fait-on ?
name="de;fr:Biel-Bienne"
name:de ="Biel"
name:fr ="Bienne"

ou 

name="Biel-Bienne" // ni français, ni allemand
name:de ="Biel"
name:fr ="Bienne"

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

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

On ne peut pas tout mettre, puisque seules les informations publiques 
nous sont accessibles (pas de dates de péremption, de maintenance...). 
Pour l'exploitant, au moins le nom ça me semble essentiel, et le SIREN 
ça peut pas faire de mal (on a jamais trop d'infos...).


Et pas sûr qu'il y ait (pour l'instant ?) de lien direct vers une fiche 
web pour chaque DAE. Quasi toutes les infos exploitables sont celles qui 
ressortent dans Osmose.


Adrien P.

Le 06/08/2020 à 08:55, Yves P. a écrit :
Les attributs supplémentaires sont décrits dans le tableau ici, qui 
fait le lien avec le schéma de données officiel : 
https://wiki.openstreetmap.org/wiki/FR:Tag:emergency%3Ddefibrillator#En_France 


Doit on tout mettre dans OSM ??

Le SIREN de l'exploitant  : c'est pas le DAE qui a un SIREN, mais 
l'opérateur.
Ça serait plus logique de mettre operator:ref:FR:SIREN=* mais quel est 
l'intérêt ?


ref:FR:GeoDAE=* (avec le format d'URL approprié dans wikidata/data 
items) permet de retrouver ces infos (et évite les pb de mise à jour).


Note: il y a des infos intéressantes dans la FAQ
https://carto.atlasante.fr/IHM/cartes/infofactures/geodae/GeoDAE_FAQ_v1.pdf

Je pense qu'il faut se concentrer sur ce qui permet de trouver un DAE 
(en état) rapidement.

En texte "Mairie : sur la façade à droite de la porte d'entrée"
Avec des coordonnées GPS précis (certains l'utilisent)
Avec des photos : c'est complémentaire au deux localisations précédentes.

Sur la plateforme Atlasanté tu as les liens vers les flux WMS/WFS 
pour visualiser les données complètes dans QGIS ou Leaflet/OpenLayers 
par exemple : 
https://www.atlasante.fr/geonetwork/srv/fre/catalog.search#/metadata/f9bc1743-deae-446d-b9fa-bab68b2aaee9

Y-a-t-il un lien utilisable par JOSM ?

Et un lien vers la fiche du DAE à partir de sa référence GeoDAE ?

__
Yves


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

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

> Les attributs supplémentaires sont décrits dans le tableau ici, qui fait le 
> lien avec le schéma de données officiel : 
> https://wiki.openstreetmap.org/wiki/FR:Tag:emergency%3Ddefibrillator#En_France
>  
> 
Doit on tout mettre dans OSM ??

Le SIREN de l'exploitant  : c'est pas le DAE qui a un SIREN, mais l'opérateur.
Ça serait plus logique de mettre operator:ref:FR:SIREN=* mais quel est 
l'intérêt ?

ref:FR:GeoDAE=* (avec le format d'URL approprié dans wikidata/data items) 
permet de retrouver ces infos (et évite les pb de mise à jour).

Note: il y a des infos intéressantes dans la FAQ
https://carto.atlasante.fr/IHM/cartes/infofactures/geodae/GeoDAE_FAQ_v1.pdf 


Je pense qu'il faut se concentrer sur ce qui permet de trouver un DAE (en état) 
rapidement.
En texte "Mairie : sur la façade à droite de la porte d'entrée"
Avec des coordonnées GPS précis (certains l'utilisent)
Avec des photos : c'est complémentaire au deux localisations précédentes.

> Sur la plateforme Atlasanté tu as les liens vers les flux WMS/WFS pour 
> visualiser les données complètes dans QGIS ou Leaflet/OpenLayers par exemple 
> : 
> https://www.atlasante.fr/geonetwork/srv/fre/catalog.search#/metadata/f9bc1743-deae-446d-b9fa-bab68b2aaee9
>  
> 
Y-a-t-il un lien utilisable par JOSM ?

Et un lien vers la fiche du DAE à partir de sa référence GeoDAE ?

__
Yves

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

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


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

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

Plusieurs améliorations possibles :

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


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


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


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


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


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



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

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


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

- name:fr
- intl_name
- name

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



--
Christian Quest - OpenStreetMap France


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

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