Re: [Talk-us] Marking structure as damaged or condemned

[Tod Fitch]

> On Aug 5, 2020, at 6:11 PM, Eric H. Christensen via Talk-us 
>  wrote:
> 
> Tropical Storm Isaias left several homes in my neighborhood severely damaged 
> and condemned.  Is there a proper way to map these structures?
> 

I would look to the lifecycle prefix [1] but I don’t see a tag prefix there 
that exactly corresponds to the situation. abandoned:building=* would be for 
something that could be repaired but the word “abandoned” has a different 
connotation for me than “damaged”. If beyond repair, then destroyed:building=* 
found in the “less common prefix values” section of that page would seem to 
apply.

— Tod


[1] https://wiki.openstreetmap.org/wiki/Lifecycle_prefix




signature.asc
Description: Message signed with OpenPGP
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

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

[Gad Jo]

Pour l'aire des Pyrénées même en sélectionnant la station de carburant qui est 
bien au milieu entre les deux voies d'accès je retrouve le même problèmes

Si on part de l'ouest ça rallonge le trajet de 25 km. Magnifique pour celui qui 
se trouve en rade de carburant et qui change sa destination pendant son trajet

Idéalement les panneaux de direction font foie mais j'ai constaté comme 
passager que dans la pratique pas mal de gens inexpérimenté préfère suivre les 
indications de leurs appareils ou bien hésite quitte à avoir une conduite 
dangereuse pour les autres (OK go je file à l'aire au dernier moment maintenant 
que j'ai compris que mon GPS fait de la merde... Oups désolé pour la queue de 
poisson)

Le August 5, 2020 9:06:40 PM UTC, Ruboqif  a écrit :
>Bonsoir,
>Avez-vous regardé les autres aires de repos avec la même configuration 
>pour voir comment elles sont taguées ? ça peut donner des idées pour 
>celle de Millau ou au contraire c'est le même soucis pour toutes les
>aires ?
>Il n'y en a pas des masses avec exactement la même configuration 
>(passage impossible de "l'autre coté" en voiture) mais il y en a 
>quelques-unes.
>Par exemple sur l'A64 :
>Aire d'Hastingues : https://www.openstreetmap.org/way/473891861
>Aire des Pyrénées https://www.openstreetmap.org/way/473888794
>Aire du Comminges : https://www.openstreetmap.org/way/500070724
>
>Pour en trouver d'autres : 
>https://routes.fandom.com/wiki/Aire_de_service à la rubrique "Celles 
>accessibles dans les deux sens"
>
>
>Le 05/08/2020 à 21:25, Gad Jo a écrit :
>> Pas facile de gérer cette aire de repos
>>
>> J'ai essayé de plaçant la destination sur la boutique de souvenir
>plus 
>> ou moins au sud. À quelques mètre ça fonctionne en arrivant du nord 
>> mais depuis le sud cela propose un nouveau détour
>>
>> Je sèche pour trouver une solution propre, compréhensible et en
>accord 
>> avec le terrain
>>
>> Au passage sur place le tag place=* avec name=Brocuéjouls n'a pas été
>
>> trouvé. Ça ressemble à une bâtisse de restauration mais c'est 
>> uniquement de la vente de souvenir
>>
>> Le August 5, 2020 3:23:56 PM UTC, "Jérôme Amagat" 
>>  a écrit :
>>
>> J'ai modifié un peu la géometrie
>> https://www.openstreetmap.org/way/434996171 pour qu'elle cole
>plus
>> au terrain mais ca ne devrait pas changé le problème.
>> Je pense que le problème vient du faite que le polygon est
>> transformé en un point au centre donc comme il y a des barrières
>> pour ne pas faire demi tour sur l'aire
>> (https://www.openstreetmap.org/node/2920654534) pour le GPS il
>> faut entrer sur l'aire dans l'autre sens pour arriver plus près
>du
>> point.
>>
>> Le probleme est le même pour d'autres aire du meme genre,
>> https://www.openstreetmap.org/way/434996170 ou
>> https://www.openstreetmap.org/way/185442798
>> Dans ces 2 cas je pense qu'il faudrait coupé l'aire en 2, une de
>> chaque côté de l'autoroute mais si elles ont le même nom, le GPS
>> va t il choisir le bon ?
>>
>> La solution pour Millau, soit diviser en 2 l'aire, il y a 2 aires
>> du point de vu de la voiture, vu que l'on ne peut pas passer d'un
>> côté à l'autre...
>> ou supprimer la barrière...
>> Ou ce que je préfère attendre que le GPS gère mieux ces cas.
>>
>> 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.
>>
>>
>> -- 
>> Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma 
>> brièveté.
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Gad Jo]

Bonne idée de comparer


Je viens de faire un essais sur l'aire d'hastingues et le problèmes est 
identique même en pointant au milieu de la surface entouré de sentier présent à 
l'est de l'aire

Dans le doute j'ai testé avec openrouteservice et lui aussi est en échec

Le August 5, 2020 9:06:40 PM UTC, Ruboqif  a écrit :
>Bonsoir,
>Avez-vous regardé les autres aires de repos avec la même configuration 
>pour voir comment elles sont taguées ? ça peut donner des idées pour 
>celle de Millau ou au contraire c'est le même soucis pour toutes les
>aires ?
>Il n'y en a pas des masses avec exactement la même configuration 
>(passage impossible de "l'autre coté" en voiture) mais il y en a 
>quelques-unes.
>Par exemple sur l'A64 :
>Aire d'Hastingues : https://www.openstreetmap.org/way/473891861
>Aire des Pyrénées https://www.openstreetmap.org/way/473888794
>Aire du Comminges : https://www.openstreetmap.org/way/500070724
>
>Pour en trouver d'autres : 
>https://routes.fandom.com/wiki/Aire_de_service à la rubrique "Celles 
>accessibles dans les deux sens"
>
>
>Le 05/08/2020 à 21:25, Gad Jo a écrit :
>> Pas facile de gérer cette aire de repos
>>
>> J'ai essayé de plaçant la destination sur la boutique de souvenir
>plus 
>> ou moins au sud. À quelques mètre ça fonctionne en arrivant du nord 
>> mais depuis le sud cela propose un nouveau détour
>>
>> Je sèche pour trouver une solution propre, compréhensible et en
>accord 
>> avec le terrain
>>
>> Au passage sur place le tag place=* avec name=Brocuéjouls n'a pas été
>
>> trouvé. Ça ressemble à une bâtisse de restauration mais c'est 
>> uniquement de la vente de souvenir
>>
>> Le August 5, 2020 3:23:56 PM UTC, "Jérôme Amagat" 
>>  a écrit :
>>
>> J'ai modifié un peu la géometrie
>> https://www.openstreetmap.org/way/434996171 pour qu'elle cole
>plus
>> au terrain mais ca ne devrait pas changé le problème.
>> Je pense que le problème vient du faite que le polygon est
>> transformé en un point au centre donc comme il y a des barrières
>> pour ne pas faire demi tour sur l'aire
>> (https://www.openstreetmap.org/node/2920654534) pour le GPS il
>> faut entrer sur l'aire dans l'autre sens pour arriver plus près
>du
>> point.
>>
>> Le probleme est le même pour d'autres aire du meme genre,
>> https://www.openstreetmap.org/way/434996170 ou
>> https://www.openstreetmap.org/way/185442798
>> Dans ces 2 cas je pense qu'il faudrait coupé l'aire en 2, une de
>> chaque côté de l'autoroute mais si elles ont le même nom, le GPS
>> va t il choisir le bon ?
>>
>> La solution pour Millau, soit diviser en 2 l'aire, il y a 2 aires
>> du point de vu de la voiture, vu que l'on ne peut pas passer d'un
>> côté à l'autre...
>> ou supprimer la barrière...
>> Ou ce que je préfère attendre que le GPS gère mieux ces cas.
>>
>> 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.
>>
>>
>> -- 
>> Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma 
>> brièveté.
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-us] Marking structure as damaged or condemned

[Shawn K. Quinn]

On 8/5/20 23:47, Dave Swarthout wrote:
> Another thing that will help future mappers is to add a note tag that
> informs them what you did and why so they don't add the building back
> again because it will still be visible in the satellite imagery. Add the
> date as well.

Also, when the building is demolished, you can change the tag to
not:building=house (or whatever it was). This is what I've seen other
mappers do when the imagery still shows buildings that a survey has
revealed are no longer standing. I think demolished:building=house is
also a valid tag as well.

-- 
Shawn K. Quinn 
http://www.rantroulette.com
http://www.skqrecordquest.com

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

Re: [Talk-us] Marking structure as damaged or condemned

[Dave Swarthout]

Another thing that will help future mappers is to add a note tag that
informs them what you did and why so they don't add the building back again
because it will still be visible in the satellite imagery. Add the date as
well.

On Thu, Aug 6, 2020 at 8:13 AM Eric H. Christensen via Talk-us <
talk-us@openstreetmap.org> wrote:

> Tropical Storm Isaias left several homes in my neighborhood severely
> damaged and condemned.  Is there a proper way to map these structures?
>
> Thanks,
> Eric
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk] Proposal for Software Dispute Resolution Panel

[Roland Olbricht]

Hello,

first of all I'm glad to read that the board addresses the sudden
funding hole for iD, and does in addition care about the critique around iD.

I would like to self-nominate for the software dispute resolution panel.

For my understanding of the task please (re-)read
https://lists.openstreetmap.org/pipermail/osmf-talk/2020-June/006909.html
tl;dr: There is no silver bullet, hence no team of experts is going to
find one. Conflict resolution is painful work for all involved, but it
also likely to yield insight and an improved software. I see a panel's
member's job in encouraging the involved people to keep walking through
the resolution process.

I also promise resp. reserve the right to share or paraphrase (for the
purpse of removing personal issues) all communications regarding the
nomination process. There have been concerns about whether the
nomination process is balanced and being open is the best way to address
them. On a personal note: I have no doubts it is, and the artifacts we
currenty encounter are consistent with a board intensely keeping many
trains in their rails in parallel.

Regarding potential CoI:
- I develop the Overpass API but it is intentionally tag agnostic.
- I do not plan to put the Overpass API under the panel regime.
Thus, I do not expect any CoI from my contributions as developer to
OpenStreetMap.

Best regards,
Roland

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

Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?

[Bryce Jasmer]

For those interested in knowing what a "typical" bounding box size is,
check out my diary entry where I sample changesets over the last 8 years
and generate a heatmap of bounding box sizes over time.
https://www.openstreetmap.org/user/b-jazz/diary/393858


On Sun, Jun 14, 2020 at 3:21 AM  wrote:

> On Sat, 13 Jun 2020 21:36:37 +0100, Alan Mackie 
> wrote:
>
> >I have no problem with big bounding boxes that result from editing large
> >objects. I get annoyed by the ones where somebody added twontiny houses on
> >opposite sides of the world.
>
>   And those with a normal work method of editing random items in their
> 'home location' and an 'away location' on the other side of the country,
> with a comment of 'updating'.
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-us] Marking structure as damaged or condemned

[Eric H. Christensen via Talk-us]

Tropical Storm Isaias left several homes in my neighborhood severely damaged 
and condemned.  Is there a proper way to map these structures?

Thanks,
Eric

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

[Talk-us] app for keeping track of relations

[Ray Kiddy]

Hello -

I have an early version of an application that I wanted to share. Please 
be kind with it. There is documentation on the app.


The idea here is that people may want to keep track of the health of a 
set of relations. Governmental entities, if they find a way to use OSM, 
will want to "watch over" the relations that they care about. Someone 
doing thematic analysis of maps using OSM data will most likely have to 
maintain external references to the OSM relations that they are relating 
their data to, so they may want to be aware of the referential integrity 
of the relations.


Does anyone have suggestions or thoughts on this? I am more interested 
in ideas than an evaluation of this particular implementation. I used a 
fairly old-school technology for building the app, but I was in the team 
at Apple that developed these frameworks, so I still use it. Which is 
not the point.


If anyone is interested in having write=access to the app, let me know. 
See the link on "Accounts" for details.


Right now, I have sets for:

- 'Cities of California'

- 'Counties of California'

- 'US Federally Recognized Native American Reservations' - names only, 
no relation links yet. (a work in progress)


- 'States of Countries' - includes Colombia and a start at Peru.

Well, if anyone has ideas, do not be shy. But then, that is not a 
problem for this group, is it? :--)


cheers - ray


ps: the URL will change once I finish tweaking my web server, but 
forwarding information should be up if it is needed.


See: 
http://opencalaccess.org:5/cgi-bin/WebObjects/app.woa/wa/boundaries?i=f9e5024c-2c68-4621-8d6a-1bae0f93dcc3




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

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

[Ruboqif]

Bonsoir,
Avez-vous regardé les autres aires de repos avec la même configuration 
pour voir comment elles sont taguées ? ça peut donner des idées pour 
celle de Millau ou au contraire c'est le même soucis pour toutes les aires ?
Il n'y en a pas des masses avec exactement la même configuration 
(passage impossible de "l'autre coté" en voiture) mais il y en a 
quelques-unes.

Par exemple sur l'A64 :
Aire d'Hastingues : https://www.openstreetmap.org/way/473891861
Aire des Pyrénées https://www.openstreetmap.org/way/473888794
Aire du Comminges : https://www.openstreetmap.org/way/500070724

Pour en trouver d'autres : 
https://routes.fandom.com/wiki/Aire_de_service à la rubrique "Celles 
accessibles dans les deux sens"



Le 05/08/2020 à 21:25, Gad Jo a écrit :

Pas facile de gérer cette aire de repos

J'ai essayé de plaçant la destination sur la boutique de souvenir plus 
ou moins au sud. À quelques mètre ça fonctionne en arrivant du nord 
mais depuis le sud cela propose un nouveau détour


Je sèche pour trouver une solution propre, compréhensible et en accord 
avec le terrain


Au passage sur place le tag place=* avec name=Brocuéjouls n'a pas été 
trouvé. Ça ressemble à une bâtisse de restauration mais c'est 
uniquement de la vente de souvenir


Le August 5, 2020 3:23:56 PM UTC, "Jérôme Amagat" 
 a écrit :


J'ai modifié un peu la géometrie
https://www.openstreetmap.org/way/434996171 pour qu'elle cole plus
au terrain mais ca ne devrait pas changé le problème.
Je pense que le problème vient du faite que le polygon est
transformé en un point au centre donc comme il y a des barrières
pour ne pas faire demi tour sur l'aire
(https://www.openstreetmap.org/node/2920654534) pour le GPS il
faut entrer sur l'aire dans l'autre sens pour arriver plus près du
point.

Le probleme est le même pour d'autres aire du meme genre,
https://www.openstreetmap.org/way/434996170 ou
https://www.openstreetmap.org/way/185442798
Dans ces 2 cas je pense qu'il faudrait coupé l'aire en 2, une de
chaque côté de l'autoroute mais si elles ont le même nom, le GPS
va t il choisir le bon ?

La solution pour Millau, soit diviser en 2 l'aire, il y a 2 aires
du point de vu de la voiture, vu que l'on ne peut pas passer d'un
côté à l'autre...
ou supprimer la barrière...
Ou ce que je préfère attendre que le GPS gère mieux ces cas.

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.


--
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma 
brièveté.


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


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

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

[Arnaud Champollion]

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 ?



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

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

[Muselaar]

En fait, quand je me déconnecte, l'affichage revient aussitôt en 
anglais, sitôt cliqué sur « Se déconnecter ».


Le 05/08/2020 à 22:11, Muselaar a écrit :


Ah, voilà la solution ! Effectivement, je n'avais que fr-FR fr, je 
vois maintenant à quoi ça sert de mettre d'autres langues… Du coup, il 
faudrait mettre toutes les langues du monde avant l'anglais pour avoir 
l'affichage de l'interface dans la langue du pays…  ?


Merci !

Muselaar

Le 05/08/2020 à 21:23, osm.sanspourr...@spamgourmet.com 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] noms anglais en Allemagne ?

[Muselaar]

Ah, voilà la solution ! Effectivement, je n'avais que fr-FR fr, je vois 
maintenant à quoi ça sert de mettre d'autres langues… Du coup, il 
faudrait mettre toutes les langues du monde avant l'anglais pour avoir 
l'affichage de l'interface dans la langue du pays…  ?


Merci !

Muselaar

Le 05/08/2020 à 21:23, osm.sanspourr...@spamgourmet.com 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] Projet du mois de septembre (en préparation) : défibrillateurs !

[Julien Lepiller]

Le Tue, 4 Aug 2020 12:29:09 +0200,
PanierAvide  a écrit :

> Bonjour à tous,
> 
> Et si on s'organisait un projet du mois en septembre, par exemple sur 
> les défibrillateurs (DAE) ? :-)
> 
> https://wiki.openstreetmap.org/wiki/FR:Project_of_the_month/Defibrillateurs
> 

J'ai regardé sur la commune de mes parents, où j'avais renseigné deux
DAE. L'un d'entre eux n'est pas remonté par osmose (je me serais
attendu à ce qu'il propose un rapprochement, ne serait-ce que pour
ajouter un ref:fr:GeoDAE ou un nom) :

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

Le deuxième est rapporté par osmose (sans doute parce que mal
localisé) :

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

et

https://osmose.openstreetmap.fr/fr/error/c4cda4f3-e2ae-d720-ad31-9500c2ef7f15

Il y en a a priori deux autres dans la commune, et vu leur nom, tout
aussi mal localisés. Au passage, osmose indique que celui que j'ai déjà
renseigné est à l'intérieur, mais, à moins qu'il ait bougé depuis
l'année dernière, il est bien à l'extérieur.

Je ne comprends pas bien les attributs proposés (reception_desk,
security_desk, surveillance), ça n'a pas l'air indiqué sur la page du
wiki :).

Il y a moyen d'accéder à une carte qui affiche les données de GeoDAE,
en dehors d'osmose qui ignore normalement ce qui est déjà dans OSM ?

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

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

[Gad Jo]

Pas facile de gérer cette aire de repos

J'ai essayé de plaçant la destination sur la boutique de souvenir plus ou moins 
au sud. À quelques mètre ça fonctionne en arrivant du nord mais depuis le sud 
cela propose un nouveau détour

Je sèche pour trouver une solution propre, compréhensible et en accord avec le 
terrain

Au passage sur place le tag place=* avec name=Brocuéjouls n'a pas été trouvé. 
Ça ressemble à une bâtisse de restauration mais c'est uniquement de la vente de 
souvenir

Le August 5, 2020 3:23:56 PM UTC, "Jérôme Amagat"  a 
écrit :
>J'ai modifié un peu la géometrie
>https://www.openstreetmap.org/way/434996171
>pour qu'elle cole plus au terrain mais ca ne devrait pas changé le
>problème.
>Je pense que le problème vient du faite que le polygon est transformé
>en un
>point au centre donc comme il y a des barrières pour ne pas faire demi
>tour
>sur l'aire (https://www.openstreetmap.org/node/2920654534) pour le GPS
>il
>faut entrer sur l'aire dans l'autre sens pour arriver plus près du
>point.
>
>Le probleme est le même pour d'autres aire du meme genre,
>https://www.openstreetmap.org/way/434996170 ou
>https://www.openstreetmap.org/way/185442798
>Dans ces 2 cas je pense qu'il faudrait coupé l'aire en 2, une de chaque
>côté de l'autoroute mais si elles ont le même nom, le GPS va t il
>choisir
>le bon ?
>
>La solution pour Millau, soit diviser en 2 l'aire, il y a 2 aires du
>point
>de vu de la voiture, vu que l'on ne peut pas passer d'un côté à
>l'autre...
>ou supprimer la barrière...
>Ou ce que je préfère attendre que le GPS gère mieux ces cas.
>
>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.

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[osm . sanspourriel]

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

Re: [Talk-us] Talk-us Digest, Vol 153, Issue 3

[Mike Thompson]

On Wed, Aug 5, 2020 at 6:42 AM Bob Gambrel  wrote:

> It seems to me that having a relationship is absolutely appropriate and
> that it should have the name of entire trail/route, just as you have done.
>
> It also seems to me that having a name on individual segments (the local
> name) is also appropriate. I don't think this is inconsistent and in fact,
> seems very desirable. Highway 65 (a state route that has an OSM relation,
> and is named as such in the relation) also has segments in some places that
> are named "Central Avenue" by the city and locals, and in other places are
> named "Highway 65", again by the locals.
>
> I don't think labeling the individual segments maps for the renderer
> primarily. It attaches a local name to the individual way, which is what
> OSM expects, I believe. It also has rendering advantages, which makes the
> map more useful to real people, not just cartographers.
>
> Thanks.  That seems to be the safest approach as perhaps some data
consumers don't yet process route relations.
Mike
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

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

[osm . sanspourriel]

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).

Au fait, emergency
=defibrillator

n'est plus affiché sur le style OSM FR ? On est resté sur le tag aed ?

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 !

Jean-Yvon

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

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

[Muselaar]

Bonsoir,

Effectivement, c'est vrai, je n'avais pas vu ça.

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 ?


Le 05/08/2020 à 13:42, Yves P. a écrit :

Je découvre par hasard que […] a son nom principal en anglais, et non 
en allemand, alors qu'on est en Allemagne…
name  
Münster Unserer Lieben Frau
name:de  
Münster Unserer Lieben Frau
name:en  
Freiburg Minster



Je le lis en allemand ;)

Par contre name:de fait doublon avec name…
__
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 !

[Yves P.]

>
> - 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...
>
Peut on comparer l'adresse OSM (en texte) obtenue par géocodage inverse
avec celle fournie par GeoDAE ?
La saisie ne semble pas toujours rigoureuse, ça ne fonctionnera pas dans
tous les cas.

Ou le contraire, comparer les adresses lat/lon en faisant cette fois ci un
géocodage direct à partir de l'adresse texte de GeoDAE ?
(Ça revient à faire de la conflation ? )

Pour la qualité des données OSM, si on a des photos ça présage d'une
position exploitable : le contributeur est allé au moins sur place et le
DAE existait bien au moment de la prise du cliché.

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

[Philippe Verdy]

Le mer. 5 août 2020 à 19:58, Christian Quest  a
écrit :

> Le 05/08/2020 à 19:04, osm.sanspourr...@spamgourmet.com a écrit :
>
> Le 05/08/2020 à 18:38, Jacques Lavignotte - jacq...@lavignotte.org a
> écrit :
>
> Le 05/08/2020 à 18:13, Philippe Verdy a écrit :
>
> J'ai du mal à croire que les services d'urgence en seront les premiers
> utilisateurs et perdront du temps à les chercher.
>
>
> Je suis de cet avis.
>
> Moi presque - j'ose imaginer que si quelqu'un fait le 112 pour un problème
> cardiaque non seulement le centre d'appel lancera les secours mais aussi
> indiquera si besoin à l'appelant qu'il y a un DEA à droite de la porte
> principale de la mairie (par exemple - je dis ça au cas où quelqu'un
> regardant le doigt au lieu de la lune voudrait pré-enregistrer cette
> réponse ^^).
>
>
Et tu crois que le 18/112 va chercher les DAE dans OSM pour guider
l'appelant ?

A mon avis le 18/112 (normalement local sauf cas de saturation avec un
reroutage régional ou national) sait déjà où sont tous les appareils dans
leur zone d'intervention et ont déjà tout ça sur les outils informatiques
utilisés par l'opérateur qui répond et géolicalise l'appelant et toutes les
ressources les plus proches disponibles. Les DAE sont un des éléments, ils
ont aussi les médecins de garde, pharmaciens, police/gendarmerie, hopitaux,
et toutes les autres services nécessaires (y compris l'armée et les assos
locales concernées comme Croix-Rouge) sans chercher et de quoi faire les
appels en un clic sur une liste thématique.
Les cartes par défaut d'OSM ne sont pas adaptées (trop de chose qui les
intéresse moins), même si ils les sont en fond de carte, ils ont des
surcouches.
Et ils n'utilisent pas qu'OSM, mais certainement des cartes de divers
fournisseurs (pas tous libres) et diverses imageries aériennes, ou
fournisseurs d'image radar et d'autres données remontées par les
exploitants de réseaux. le 18/112 devrait disposer de tout ce qui est à
dispo des SDIS au plan national. Concernant le SAMU/15 c'est moins clair,
et pourtant c'est ce qu'on recommande appeler d'abord pour les urgences
médicales et disposer d'une aide immédiate, le 15 se chargeant de prendre
contact avec le SDIS/112 et les autres servicces pouvant envoyer un
véhicule d'urgence si nécessaire, avec une meillure évaluation des besoins.
___
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 !

[Christian Quest]

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


Le 05/08/2020 à 18:38, Jacques Lavignotte - jacq...@lavignotte.org a 
écrit :



Le 05/08/2020 à 18:13, Philippe Verdy a écrit :

J'ai du mal à croire que les services d'urgence en seront les 
premiers utilisateurs et perdront du temps à les chercher.


Je suis de cet avis. 


Moi presque - j'ose imaginer que si quelqu'un fait le 112 pour un 
problème cardiaque non seulement le centre d'appel lancera les secours 
mais aussi indiquera si besoin à l'appelant qu'il y a un DEA à droite 
de la porte principale de la mairie (par exemple - je dis ça au cas où 
quelqu'un regardant le doigt au lieu de la lune voudrait 
pré-enregistrer cette réponse ^^).


De la même manière qu'il aide les gens à faire un massage cardiaque ou 
tout autre action d'urgence avant l'arrivée des secours.


Donc potentiels premiers utilisateurs virtuels mais probablement pas 
effectifs.


Et pour moi les principales questions sont :

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




- est-ce que ça peut servir ?

Oui, soit en utilisant directement les données OSM, soit en espérant un 
jour qu'un canal de remontée vers GeoDAE se mette en place... et que 
GeoDAE soit utilisée par les secours (et là problème de confiance dans 
les données et leur qualité).




Je crois qu'on sera d'accord ici sur les réponses (oui/oui).

Et donc on en arrive aux attributs à renseigner et aux moyens de les 
renseigner.


Le plus important me semble être de faire le lien OSM /GéoDAE... par le 
ref:FR:GeoDAE comme ça on peut améliorer des deux côtés et croiser les 
données selon les besoins (mises à jour croisées, etc).



--
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] Importer du Umap dans OSM

[Christian Quest]

Le 05/08/2020 à 17:39, Jacques Lavignotte a écrit :

Bonjour,

J'ai quelques POI sur une carte Umap.

Qu'est ce que je peux espérer importer de cette carte dans OSM ?

Merci, Jacques



Tu peux récupérer le contenu d'une couche umap en geojson (ou autre) et 
l'ouvrir dans JOSM.


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

[Philippe Verdy]

Attention à l'interprétation de "'doublon". le "name=*" par défaut
n'indique pas explicitement dans quelle langue il est, ce qui fausse le
mécanisme de fallback, par exemple: demande à afficher en néerlandais. Si
tu n'as que name="*" et name:en", lequel des deux afficher  celui par
défaut (supposé en allemand mais pourrait aussi bien être en bavarois, ou
même en italien, polonais ou danois), ou celui explicitement en anglais
(qui serait sans doute préférable, et encore plus si on cherche en
langle bas-saxonne ou frisonne) ?
Les mécanismes de fallback (de BCP 47) demande de connaitre la langue par
défaut et la racine est une ressource indépendant de la langue locale mais
peut aussi être juste une langue de repli habituel. OSM demande d'utiliser
*une* langue locale, mais rien n'indique cette langue locale ne soit que
l'allemand ce pourrait aussi être une variété régionale.
Maintenant demandons avec le nom en breton (absent) mais dont la langue de
repli est habituellement le français avant l'anglais.
On n'a pas ce problème si on tague explicitement le nom avec sa langue,
surtout dans les pays ou régions officiellement multilingues (et ça
concerne énormément de régions dans le monde; même les USA n'ont pas de
langue "officielle" au plan national juste des langues "de facto", leur
constitution interdisant de restreindre la liberté d'expression ne
serait-ce que la langue; seuls certains états ont légiféré pour indiquer
non pas une seule langue mais plusieurs).
Même avec une seule langue les orthographes varient parfois aussi le
système d'écriture. Le nom "officiel" peut aussi être multilingue (deux
langues simultanées et égales): name=* contiendrait alors les deux, même si
name:=* n'indiquera qu'une seule.
Quant à l'emploi obligatoiremetn du français en France, rien n'interdit
qu'officiellement ce soit le nom issu d'une langue régionale qui soit
officiel aussi en français, ce qui n'interdit pas d'autres traductions non
officielles (le nom anglais ne sera alors pas officiel du tout et peut
juste être un nom d'usage, et parfois il y en a plusieurs).
Ce n'est pas simple. Un "name=*" tout seul ne peut pas facilement indiquer
qu'il ne s'agit pas d'un non incorrect mais bien du nom officialisé
localement (dans une langue non précisée).

S'il y a plus d'une seule langue indiquée dans name=* ou name:*=*, je pense
qu'il faut préciser en plus un "name:code=*" indiquant explicitement la
même valeur que "'name=*" (ou une partie de ce nom) mais
indiquant clairement dans quelle langue est ce nom. La "langue par défaut"
n'est jamais assez fiable ou peut n'être utilisable que par une toute
petite minorité (exemple une des centaines de langues en Inde; et parfois
avec un conflit sur l'écriture à utiliser , et leur
translitérations mutuelles, par exemple entre Hindi et Urdu)

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

> Je découvre par hasard que […] a son nom principal en anglais, et non en
> allemand, alors qu'on est en Allemagne…
>
> name  Münster
> Unserer Lieben Frau
> name:de  Münster
> Unserer Lieben Frau
> name:en  Freiburg
> Minster
>
> Je le lis en allemand ;)
>
> Par contre name:de fait doublon avec name…
> __
> 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] noms anglais en Allemagne ?

[Christian Quest]

Le 05/08/2020 à 13:42, Yves P. a écrit :
Je découvre par hasard que […] a son nom principal en anglais, et non 
en allemand, alors qu'on est en Allemagne…
name  
Münster Unserer Lieben Frau
name:de  
Münster Unserer Lieben Frau
name:en  
Freiburg Minster



Je le lis en allemand ;)

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 alemand vu qu'il est identique à 
name:de=*



--
Christian Quest - OpenStreetMap France

___
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 ;)

[Jérôme Amagat]

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

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.

Le sam. 1 août 2020 à 17:38, Christian Quest  a
écrit :

> Le 26/07/2020 à 23:53, Christian Quest a écrit :
> > Moins de trafic aussi sur les serveurs de l'asso alors c'est le moment
> > des chantiers !
>
> Le chantier continue avec la remise à jour des limites terre/mer et
> l'occupation des sols à petite échelle...
>
>
> Limites terre/mer :
>
> Les natural=coastline mises bout à bout forment d'immenses polygones qui
> sont nécessaires pour avoir la mer en bleu et la terre dans une couleur
> claire par défaut.
>
> Ces polygones sont relativement coûteux à calculer, car composés de très
> nombreux noeuds. Ils sont gigantesques car couvrant des continents entiers.
>
> Du coup, ils sont calculés de temps en temps et mis à disposition sur
> https://osmdata.openstreetmap.de/ sous une forme découpée (oui, façon
> puzzle) avec une version aux géométries simplifiées adaptée aux petites
> échelles.
>
> Les derniers fichiers shapefile dataient de janvier et ils ont été remis
> à jour hier.
>
> Pour le rendu FR, j'en ai profité pour changer la logique car depuis
> toujours, on mettait un fond bleu par défaut et on dessinait les
> continents par dessus.
>
> Or... on calcule bien plus souvent des tuiles sur terre que sur mer,
> donc autant avoir ça de moins à dessiner dans la majorité des cas même
> si c'est sûrement négligeable.
>
>
> L'occupation des sols à petite échelle :
>
> Pour les premiers niveaux de zoom, le rendu FR affiche l'occupation des
> sols (landuse=*). Le problème ici c'est le très grand nombre de
> polygones, parfois très petits et non visibles à ces échelles.
>
> Il y a quelques années, j'avais calculé une couche transparente au zoom
> 8 ne contenant que ces landuse pour l'appliquer par simple réduction sur
> les zoom 0 à 7.
>
> J'ai regénéré cette couche, cette fois-ci directement au zoom 7, en
> éliminant tous les polygones d'une surface de moins d'un pixel.
>
> Le résultat est un fichier geotif de 89Mo :
> http://osm13.openstreetmap.fr/~cquest/z7.tif
>
> On a désormais des déserts bien plus cohérents en Afrique !
>
>
> Conséquence, les tuiles ont toutes été recalculées jusqu'au zoom 12 et
> devraient apparaître au fur et à mesure de la mise à jour du cache.
>
>
> Si vous voyez des anomalies... signalez-les...
>
> --
> 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

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

[Philippe Verdy]

Je sais où il y a un DAE pas loin de chez moi, mais pas sûr que ce soit
vraiment le plus proche (plus d'un kilomètre: si on y va à pied il faut au
moins 20 minutes pour un adulte en santé normale sachant où il va, et au
moins autant pour revenir).

Dans les zones résidentielles (notamment périurbaines où l'habitat est
moins dense et où il y a peu d'équipement publics, le DAE peut être assez
loin et il y aura aussi peu de monde pour aider). Le temps d'aller le
chercher et revenir, on a souvent plus vite fait de prendre son portable et
d'attendre les pompiers, le SAMU, ou un médecin local qui seraient là bien
avant. Perdre 3/4 d'heure sans assister la victime c'est pire que rester
sur place et faire les massages cardiaques (même mal).

Qui sait en fait où il sont. souvent on les voit près des portes des
gymnases municipaux, écoles, mairies, salles d'activités, centres
commerciaux. En principe ils sont à l'extérieur (au moins un, il peut y en
avoir à l'intérieur des galeries marchandes ou au milieu d'une très grande
surface). On devrait en trouver dans toutes les aires de service des
autoroutes.

Mais on peut en trouver plus proches dans des endroits moins attendus.

Pas bien loin de chez moi, un EPADH n'est toujours pas équipé ou s'il en a
un ce n'est pas affiché alors que cela devrait l'être (mais en temps de
confinement je pense qu'il est en fait dans l'établisssement qui n'est pas
ouvert à tous)...

Je me demande pourquoi il n'y a pas d'obligation d'équipement pour tous
commerces ayant un nombre important de clients (notamment les fast-foods,
les grand cafés et les commerces "drive-in/through") d'après un seuil de
chiffre d'affaire ou selon leur capacité d'accueil mais aussi par le fait
qu'ils sont très repérables et accessibles.

Le mer. 5 août 2020 à 19:04,  a écrit :

> Le 05/08/2020 à 18:38, Jacques Lavignotte - jacq...@lavignotte.org a
> écrit :
>
> Le 05/08/2020 à 18:13, Philippe Verdy a écrit :
>
> J'ai du mal à croire que les services d'urgence en seront les premiers
> utilisateurs et perdront du temps à les chercher.
>
>
> Je suis de cet avis.
>
> Moi presque - j'ose imaginer que si quelqu'un fait le 112 pour un problème
> cardiaque non seulement le centre d'appel lancera les secours mais aussi
> indiquera si besoin à l'appelant qu'il y a un DEA à droite de la porte
> principale de la mairie (par exemple - je dis ça au cas où quelqu'un
> regardant le doigt au lieu de la lune voudrait pré-enregistrer cette
> réponse ^^).
>
> De la même manière qu'il aide les gens à faire un massage cardiaque ou
> tout autre action d'urgence avant l'arrivée des secours.
>
> Donc potentiels premiers utilisateurs virtuels mais probablement pas
> effectifs.
>
> Et pour moi les principales questions sont :
>
> - peut-on améliorer le jeu de données OSM à partir de la base Geo DAE ?
> - est-ce que ça peut servir ?
>
> Je crois qu'on sera d'accord ici sur les réponses (oui/oui).
>
> Et donc on en arrive aux attributs à renseigner et aux moyens de les
> renseigner.
>
> Jean-Yvon
> ___
> 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 !

[Yves P.]

>> J'ai du mal à croire que les services d'urgence en seront les premiers 
>> utilisateurs et perdront du temps à les chercher.
> 
> Je suis de cet avis.

Les SMURs et les pompiers ont un DAE et un scope dans chaque véhicule (VSAV 
pour les pompiers).

Les DAEs à disposition du public sont efficaces si ils sont utilisés très 
rapidement, donc bien avant l'arrivée des secours.

En campagne, un pompier après une alerte doit :
se rendre au centre de secours
s'habiller
attendre ses collègues
se rendre sur les lieux
trouver la bonne adresse

Il s'en passe du temps !

Le SMUR n'a que les points 4 et 5 mais il part de plus loin et souvent les 
pompiers sont là avant.

> 
> Même si dans quelques départements les pompiers ont recensé les DAE, publié 
> le document puis l'ont retiré sans explication.
Dans le JURA, il y a un site web pas maintenu et pas à jour des DAE du 
département.
Je doute que les opérateurs du CTA transmettent encore l'information aux 
appelants.

> Si le souci de Santé Publique "Sauver des Vies" est évident, d'autres 
> intérêts se greffent à cette affaire.
Oui.
A Lons-le-Saunier, il y a une rivalité entre le SAMU et le SDIS.
Les appels au 15 sont gérés dans le Doubs et pas dans le Jura !!

L'application SaveLife n'est pas mise en place ici probablement à cause de ça.
Dommage, c'est ça qui pourrait sauver une vie en cas d'arrêt cardiaque.
__
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 !

[osm . sanspourriel]

Le 05/08/2020 à 18:38, Jacques Lavignotte - jacq...@lavignotte.org a écrit :


Le 05/08/2020 à 18:13, Philippe Verdy a écrit :


J'ai du mal à croire que les services d'urgence en seront les
premiers utilisateurs et perdront du temps à les chercher.


Je suis de cet avis.


Moi presque - j'ose imaginer que si quelqu'un fait le 112 pour un
problème cardiaque non seulement le centre d'appel lancera les secours
mais aussi indiquera si besoin à l'appelant qu'il y a un DEA à droite de
la porte principale de la mairie (par exemple - je dis ça au cas où
quelqu'un regardant le doigt au lieu de la lune voudrait pré-enregistrer
cette réponse ^^).

De la même manière qu'il aide les gens à faire un massage cardiaque ou
tout autre action d'urgence avant l'arrivée des secours.

Donc potentiels premiers utilisateurs virtuels mais probablement pas
effectifs.

Et pour moi les principales questions sont :

- peut-on améliorer le jeu de données OSM à partir de la base Geo DAE ?
- est-ce que ça peut servir ?

Je crois qu'on sera d'accord ici sur les réponses (oui/oui).

Et donc on en arrive aux attributs à renseigner et aux moyens de les
renseigner.

Jean-Yvon

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

[Jacques Lavignotte]

Le 05/08/2020 à 18:13, Philippe Verdy a écrit :

J'ai du mal à croire que les services d'urgence en seront les premiers 
utilisateurs et perdront du temps à les chercher.


Je suis de cet avis.

Même si dans quelques départements les pompiers ont recensé les DAE, 
publié le document puis l'ont retiré sans explication.


Si le souci de Santé Publique "Sauver des Vies" est évident, d'autres 
intérêts se greffent à cette affaire.


J.

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

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

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

[Philippe Verdy]

Le mar. 4 août 2020 à 17:33, Christian Quest  a
écrit :

> Les premiers utilisateurs que sont les SAMU ou pompiers risquent de s'en
> détourner bien vite après quelques échecs... on ne peut faire bonne
> impression qu'une fois, la première ;)
>

J'ai du mal à croire que les services d'urgence en seront les premiers
utilisateurs et perdront du temps à les chercher.

A mon avis ils ont leur propre équipement avec eux dans leurs véhicules, et
le but des DAE c'est pour le grand public, afin qu'il puisse intervenir
efficacement en attendant les secours. D'ailleurs leur mode de
fonctionnement automatique et assisté est fait justement pour que ce soit
utilisable par des gens non formés sans perdre de temps.

Car déjà avant qu'ils arrivent il a fallu le temps de les appeler (même si
on peut appeler de puis n'importe où et n'importze quel teléphone au 112
(souvent mobile aujourd'hui), et qu'ils arrivent. Le problème pour ceux qui
veulent aider c'est plutôt le fait qu'ils ne peuvent pas s'éloigner de
la victime longtemps et que les aidants sont parfois tous seuls à pouvoir
se déplacer (et il peut s'écouler du temps avec qu'un autre témoin passe et
sache où aller ensuite trouver le DAE).

Je ne dis pas que les secours ne vont pas utiliser ces DAE, mais ce sera
exceptionnel. Exemple en cas de défaillance de leur propre appareil (défaut
de charge/batterie), mais en principe ils devraient avoir toujours avec eux
un appareil en état. Les rares cas sont en cas de multi-accident et qu'ils
n'ont pas assez de matériel (et en atendant qu'un plan rouge se déclenche
et fasse venir d'autres secours de plus loin, là ils peuvent utiliser les
ressources supplémentaires qui ne sont pas trop loin d'eux, sinon ils
savent faire les massage cardiaque et en principe ils arrivent en équipe et
un équiper peut utiliser le véhicule d'intervention sans laisser la victime
seule).

Et qui contrôle l'état des DAE ? Ils sont dans des établissements publics
qui sont régulièrement visités et où ils interviennent relativement plus
souvent qu'ailleurs du fait de la fréquentation par tous publics, et donc
ces DAE sont en principe en état ("en principe", ce n'est pas toujours le
cas pour les DAE placés à côté de petits gymnases ou d'écoles publiques
dans des communes rurales ou des zones résidentielles de quartiers
périurbains, dont les DAE ne sont visités au mieux qu'une ou deux fois
l'année, ne serait-ce que pour vérifier l'état de la batterie et du bloc
chargeur, et si le matos est toujours en place et n'a pas été oublié par
une précédente utilisation qui l'aurait laissé sur place sur le lieu de
l'accident ou par négligence ou oubli de celui qui est venu le prendre et
n'a pas rapporté l'appareil après l'intervention de secours).

Il y a des usages bizarres aussi où des DAE disparaissent sans raison,
peut-être pour juste subtiliser la batterie, ou des cas de destruction par
vandalisme...

Ceci dit un appareil qui a déjà servi n'a plus ses sparadraps en état pour
les électrodes: l'équipe de secours devrait signaler le fait que le DAE
utilisé doit être révisé, mais en ont-ils le temps dans des cas d'urgence ?
Et l'appareil récupéré identifie-t-il la société de maintenance ? Ou la
société de maitenance n'est-elle pas automatiquement prévenue (message
automatique par SMS par exemple) quand on vient chercher l'appareil et
qu'on le débranche de sa station de charge?

Certes la loi impose que le DAE inclue dans la boite une notice
conernant quoi en faire après utilisation, mais peut-être cette notice est
mal comprise, ou elle demande d'appeler un numéro pour la société de
maintenance qui ne sera pas disponible immédiatement (par exemple usage la
nuit). La notice peut aussi être illisible ou abimée. L'utilisateur peut
aussi oublier de le faire le lendemain et s'il est uintervenu pour un
proche avoir autre chose à penser ou ne plus être lui-même disponible pour
le faire (travail, déplacement loin ailleurs) quand le service sera ouvert.

Aussi il me semble que le DAE utilisé devrait être simplement emporté par
les secours qui se chargeront de faire le nécessaire correctement dans un
temps raisonnable.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Importer du Umap dans OSM

[Jacques Lavignotte]

Bonjour,

J'ai quelques POI sur une carte Umap.

Qu'est ce que je peux espérer importer de cette carte dans OSM ?

Merci, Jacques

--
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] Aire du viaduc de Millau

[Jérôme Amagat]

J'ai modifié un peu la géometrie https://www.openstreetmap.org/way/434996171
pour qu'elle cole plus au terrain mais ca ne devrait pas changé le problème.
Je pense que le problème vient du faite que le polygon est transformé en un
point au centre donc comme il y a des barrières pour ne pas faire demi tour
sur l'aire (https://www.openstreetmap.org/node/2920654534) pour le GPS il
faut entrer sur l'aire dans l'autre sens pour arriver plus près du point.

Le probleme est le même pour d'autres aire du meme genre,
https://www.openstreetmap.org/way/434996170 ou
https://www.openstreetmap.org/way/185442798
Dans ces 2 cas je pense qu'il faudrait coupé l'aire en 2, une de chaque
côté de l'autoroute mais si elles ont le même nom, le GPS va t il choisir
le bon ?

La solution pour Millau, soit diviser en 2 l'aire, il y a 2 aires du point
de vu de la voiture, vu que l'on ne peut pas passer d'un côté à l'autre...
ou supprimer la barrière...
Ou ce que je préfère attendre que le GPS gère mieux ces cas.

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.
___
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/

[Yves P.]

>> Il semble que le ref soit calculé de la même façon "ref=megalithic.co.uk 
>> 9857" vers la page 
>> https://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 


__
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

[osm . sanspourriel]

Le 04/08/2020 à 22:56, Gad Jo - perche...@toutenkamion.net a écrit :


(j'ai pesté grave et ma chérie a sortie GoogleMaps + Waze), comment
corriger cela ?


Changer de copine^^
Non je déconne, une nouvelle pourrait faire pareil.
Abandonner ta chérie sur l'aire précédente c'est plus sûr pas contre il
y a ensuite des effets de bord je crois - jamais essayé mais je pense
qu'après tu n'es plus son chéri.

Normalement avant de suivre bêtement un trajet on le regarde.

Ou lire les panneaux : tu es passé devant un panneau "Aire du Viaduc de
Milliau".

"Chérie je comprends que tu veuilles prendre une solution logicielle
alternative, mais pourquoi ne regardais-tu pas la route ?"



Le problème n'est pas la description de l'aire.

En effet

https://www.openstreetmap.org/directions?engine=fossgis_osrm_car=44.09571%2C3.02500%3B44.10059%2C3.02356

donne un parcours de 1,3 km et

https://www.openstreetmap.org/directions?engine=fossgis_osrm_car=44.09571%2C3.02501%3B44.10059%2C3.02356

20 km.

Par contre que je demande "Aire du Viaduc de Millau" vers Lyon ou
Montpellier, ça marche.

De Montpellier à l'aire ça marche mais par contre de Lyon vers "Aire du
Viaduc de Millau" ça déclenche l'utilisation de GM+Waze chez ton
autorité de tutelle.

Si tu veux que ça marche sans rien changer d'autre, tu places 2 nœuds
"Aire du Viaduc de Millau depuis nord" et "Aire du Viaduc de Millau
depuis sud" là où il faut :-(.

Mais il me pense plus intéressant de questionner les routeurs.

https://www.openstreetmap.org/directions?engine=fossgis_osrm_car=44.09571%2C3.02495%3B44.10287%2C3.02476#map=14/44.1177/3.0340

Comme en déplaçant à peine le point on arrive à obtenir le bon trajet je
pense que c'est la distance maximale de détour apparent qui est trop petite.

N. B. : je trouve bizarre que le parking au nord, qui est routièrement
connecté uniquement avec la route au nord fasse partie de cette aire.

N. B. 2 : je vois qu'un pont en surfacique
https://www.openstreetmap.org/way/440836275 se voit attribuer un tas
d'informations routières notamment fausses (oneway
=yes). À
supprimer (les infos routières, pas le pont) ou à corriger ?

Jean-Yvon

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

[Yves P.]

> Il semble que le ref soit calculé de la même façon "ref=megalithic.co.uk 
> 9857" vers la page 
> https://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 :)

> a-t-on le droit de pointer sur leur id ? Je n'ai pas très bien compris leur 
> "Terms and Conditions"
Après une discussion similaire sur le Bistro wikidata, la réponse est oui. Un 
id n'est pas une oeuvre :)

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

[Jacques Lavignotte]

Le 05/08/2020 à 13:46, Yves P. a écrit :


+1


Je le savais ;)))

 __

Yves


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

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

[leni]

Bonjour

J'ai trouvé trois ref:fr qui semblent pointer vers le site 
http://t4t35.fr/Megalithes/


https://www.openstreetmap.org/way/51037567 avec "ref:fr=t4t35.fr:FOCAUS"
https://www.openstreetmap.org/node/3495511108 avec "ref:fr=t4t35 29345 
DLVIAS"

https://www.openstreetmap.org/node/818616630 avec "ref:fr=t4t35.fr LHRIEU"

J'ai contacté le contributeur qui semblait avoir ajouté ces valeurs, 
mais il m'a répondu que ce n'était pas lui qui les avais mises !!!


En fait, j'ai trouvé que le t4t35 correspondait au site 
http://t4t35.fr/Megalithes/ et les mots en majuscules correspondent à 
l'ID de l'objet sur le site par exemple 
http://t4t35.fr/Megalithes/AfficheSite.aspx?Projet=France=FOCAUS


Ce site semble fonctionner avec des contributeurs (la carte est une 
carte osm), je pensais écrire au site pour savoir si les données étaient 
libres (je n'ai rien vu sur le site), si oui, ne vaudrait-il pas mieux 
mettre un lien vers la page qu'un ref:fr ?


Il semble que le ref soit calculé de la même façon "ref=megalithic.co.uk 
9857" vers la page https://www.megalithic.co.uk/article.php?sid=9857 : 
a-t-on le droit de pointer sur leur id ? Je n'ai pas très bien compris 
leur "Terms and Conditions"


cordialement

leni


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

Re: [OSM-talk] [Osmf-talk] Funding of iD Development and Maintenance

[Guillaume Rischard]

On 5 Aug 2020, at 12:31, Mateusz Konieczny via osmf-talk 
 wrote:
> 
> Have you reached out to JOSM devs about also supporting their work?

Hi Mateusz,

Yes, I have told them explicitly and clearly that for us, the door is wide open.

During informal conversations in the past, the JOSM people have mentioned that 
this wasn’t really necessary for them - JOSM is something to enjoy working on 
after work. I understand them, I certainly waste a lot of my spare time having 
fun trying to improve JOSM a bit :).

If someone else wants to do work like this on JOSM, they should talk to the 
JOSM maintainers first.

Guillaume___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Arnaud Champollion]

Le 04/08/2020 à 22:56, Gad Jo a écrit :

C'est bien d'ici qu'on parle ?

https://www.openstreetmap.org/way/434996171#map=16/44.0965/3.0251

Identifier deux aires ? Sur le terrain il y a qu'un seul nom mais ça à 
le mérite d'être compréhensible


Je ne pense pas car il n'y a bien qu'une seule aire, avec des chemins 
différenciés pour les voitures.



Revoir la géométrie de l'aire pour que le barycentre soit mieux placer ? 
Pas sûr que ça tienne sur le long ou très long terme


Et ça obligerait à créer un faux polygone qui ne décrirait pas l'emprise 
de l'aire.


Créer une relation ou multipolygone avec un nœud comme centre ? Cela 
risque de complexifier les modifications pour les nouveaux au risque que 
des doublons soient ajouter


Je pencherais plutôt vers ça.

Il y a le rôle 'label" pour positionner l'étiquette du nom mais ça ne 
répond pas au problème du routage.


Sinon, sans faire de relation, juste en remplaçant le polygone rest_area 
par un nœud placé au bon endroit ?








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

Re: [Talk-us] Talk-us Digest, Vol 153, Issue 3

[Bob Gambrel]

It seems to me that having a relationship is absolutely appropriate and
that it should have the name of entire trail/route, just as you have done.

It also seems to me that having a name on individual segments (the local
name) is also appropriate. I don't think this is inconsistent and in fact,
seems very desirable. Highway 65 (a state route that has an OSM relation,
and is named as such in the relation) also has segments in some places that
are named "Central Avenue" by the city and locals, and in other places are
named "Highway 65", again by the locals.

I don't think labeling the individual segments maps for the renderer
primarily. It attaches a local name to the individual way, which is what
OSM expects, I believe. It also has rendering advantages, which makes the
map more useful to real people, not just cartographers.

IMHO

On Wed, Aug 5, 2020 at 6:02 AM  wrote:

> Send Talk-us mailing list submissions to
> talk-us@openstreetmap.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.openstreetmap.org/listinfo/talk-us
> or, via email, send a message with subject or body 'help' to
> talk-us-requ...@openstreetmap.org
>
> You can reach the person managing the list at
> talk-us-ow...@openstreetmap.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Talk-us digest..."
>
>
> Today's Topics:
>
>1. Re: Mtb Route Relations (Nathan Hartley)
>
>
> --
>
> Message: 1
> Date: Tue, 4 Aug 2020 13:12:04 -0400
> From: Nathan Hartley 
> To: Mike Thompson 
> Cc: Open Street Map Talk-US 
> Subject: Re: [Talk-us] Mtb Route Relations
> Message-ID:
> <
> caae2jozhu015m-mt8ftq8eaxq0f03708r-7nd6h0td06y_x...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
>  Following this thread.
>
> I have the same question, after recently moving the names that folks had
> added to the way (and bridge) segments, of a linear park spanning lower
> Michigan, to the relations representing the trail segment. The entire trail
> is known as " The Great Lake-to-Lake Trails" [image: relation]
>  7962984
> , whereas it has segments known by other
> names. For instance, 22 miles are also known as the "Mike Levine Lakelands
> Trail State Park" [image: relation]
>  272564
> . I felt this was the most accurate way
> to
> map this trail. However, the temptation is strong to "map for the
> renderer", after seeing the trail names disappear from the rendered map
> .
>
> On Fri, Jul 31, 2020 at 6:55 PM Mike Thompson  wrote:
>
> > Let's say you have a trail in the US National Forest that was
> specifically
> > created for mountain biking. It has a name and a FS trail number. It is
> > represented in OSM by three ways currently: before a bridge, the bridge,
> > and after the bridge.
> >
> > Is this a good candidate for a route relation?
> > Should name=* tag appear just on the relation, or on all of the member
> > ways as well?
> > Should ref=* tag appear just on the relation, or on all of the members as
> > well?
> >
> > I am assuming that physical and legal access tags should only appear on
> > the member ways, even if every member has the same value, right?
> >
> > Just don't want to break anything...
> >
> > Mike
> > ___
> > Talk-us mailing list
> > Talk-us@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-us
> >
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstreetmap.org/pipermail/talk-us/attachments/20200804/7c00b018/attachment-0001.htm
> >
>
> --
>
> Subject: Digest Footer
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
> --
>
> End of Talk-us Digest, Vol 153, Issue 3
> ***
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [talk-cz] SotM a OpenAlt 2020?

[Tom Ka]

Vzhledem k nulovym reakcim vykopavam termin letosniho samostatneho
SotM CZ(+SK?) na

Soboru 19.9.2020

Jako varianta pak asi dalsi vikend tj. 26.09.2020 pokud by bylo pro
vic lidi schudnejsi.
Upozornuju, ze zaroven probehne valna hromada OSM CR, k reseni zatim
asi nic, jen report za 2020.

Je nekdo, kdo se chce zucastnit a v danem terminu nemuze?

Diky tom.k

pá 12. 6. 2020 v 9:08 odesílatel Tom Ka  napsal:
>
> Ahoj, pokud by se melo drzet toho, jak se to zatim delalo (tj. jednou
> solo, jednou s altem), tak letos solo. Jak s COVIDem na podzim ted
> tezko predvidat. Za mne bych zatim pocital s fyzickou akci zvlast.
> Predpokladam, ze to zase spadne na Brno, ale kdyby se v Praze (nebo
> jinde) chteli hecnout, budu jenom rad :-)
>
> Kdyz uz jsme v tom, jak to vidite s terminem, za mne prelom zari / rijna?
>
> A rovnou i nejake napady, koho pozvat? Ja bych rad oslovil mapy.cz, uz
> jsme se chvili nevideli a rad bych jim prezentoval co je noveho u nas
> a slysel, jak to jde u nich.
>
> Bye
>
> čt 11. 6. 2020 v 19:29 odesílatel Ladislav Nesnera  napsal:
> >
> > Zdravím. Jak to letos vidíte s konferováním? Symbióza, sólo nebo COVID
> > výmluvy? 藍
> > ;?
> > ___
> > talk-cz mailing list
> > talk-cz@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-cz
> > https://openstreetmap.cz/talkcz

___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] SotM a OpenAlt 2020?

[Tom Ka]

st 5. 8. 2020 v 13:31 odesílatel Jiri Vlasak  napsal:
> mám související otázku. Stejně jako loni bychom letos chtěli udělat Meeting
> Missing Maps CZ & SK. Loni jsme to sfoukli v neděli po SotM CZ + SK na
> OpenAltu, letos jsme to zatím neřešili.
>
> No a teď ta otázka, že jo -- mohli bychom se přidat k SotM CZ + SK? Pro nás
> bude určitě zajímavé se SotM CZ + SK zúčastnit, zároveň ale asi budeme
> pořebovat alespoň 2 hodiny na vlastní talky a diskuzi.

Zatim to asi nikdo nezacal resit, resp. se lidi ani neozvali na termin
apod., takze nedokazu rict, jak bude prostor s casem. Asi to zacnu
zase strkat at se neco deje, tak snad brzo bude nejaka predstava. BTW
kolik vas je? Tto muze byt taky dulezite.

Byt tom.k

___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

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

[Yves P.]

> quand je vois le temps qu'on perd passe à se faire des nœuds au cerveau pour 
> passer d'une licence libre à une autre licence libre mais pas pareille, je me 
> dis qu'on est pas efficaces.
> 
+1

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

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

[Yves P.]

> Je découvre par hasard que […] a son nom principal en anglais, et non en 
> allemand, alors qu'on est en Allemagne…

name    Münster 
Unserer Lieben Frau
name:de Münster 
Unserer Lieben Frau
name:en 
Freiburg Minster

Je le lis en allemand ;)

Par contre name:de fait doublon avec name…
__
Yves___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] [Osmf-talk] Funding of iD Development and Maintenance

[Mateusz Konieczny via talk]

Aug 5, 2020, 13:36 by dieterdre...@gmail.com:

>
>
> Am Mi., 5. Aug. 2020 um 12:35 Uhr schrieb Mateusz Konieczny via osmf-talk <> 
> osmf-t...@openstreetmap.org> >:
>
>>
>> Especially given that JOSM is used for similar number of edits
>>
>
>
>
> this is not correct, JOSM accounts for 522 335 462 edits in 2020, while iD 
> users have committed 227 706 433 edits, this is less than half the edits of 
> JOSM (43,6%). Of all contributions to OSM in 2020, 65,4% came in through JOSM 
> and 28,5% through iD. This is more or less unchanged also in the previous 3 
> years: > 
> https://wiki.openstreetmap.org/wiki/Editor_usage_stats#by_number_of_edits
>
Sorry for misleading way of stating this, it was not my intention to 
overestimate iD importance.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [Osmf-talk] Funding of iD Development and Maintenance

[Martin Koppenhoefer]

Am Mi., 5. Aug. 2020 um 12:35 Uhr schrieb Mateusz Konieczny via osmf-talk <
osmf-t...@openstreetmap.org>:

> Especially given that JOSM is used for similar number of edits
>



this is not correct, JOSM accounts for 522 335 462 edits in 2020, while iD
users have committed 227 706 433 edits, this is less than half the edits of
JOSM (43,6%). Of all contributions to OSM in 2020, 65,4% came in through
JOSM and 28,5% through iD. This is more or less unchanged also in the
previous 3 years:
https://wiki.openstreetmap.org/wiki/Editor_usage_stats#by_number_of_edits

Cheers
Martin
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[PanierAvide]

Question de point de vue, quand je vois le temps qu'on perd passe à se 
faire des nœuds au cerveau pour passer d'une licence libre à une autre 
licence libre mais /pas pareille/, je me dis qu'on est pas efficaces. Et 
en face les GAFAM avancent toujours plus vite, toujours plus loin, 
toujours plus privateurs ;-)


Adrien P.

Le 05/08/2020 à 13:25, Jacques Lavignotte a écrit :


s/métaphysiques/essentielles

J.

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

Re: [talk-cz] SotM a OpenAlt 2020?

[Jiri Vlasak]

Ahoj,

mám související otázku. Stejně jako loni bychom letos chtěli udělat Meeting
Missing Maps CZ & SK. Loni jsme to sfoukli v neděli po SotM CZ + SK na
OpenAltu, letos jsme to zatím neřešili.

No a teď ta otázka, že jo -- mohli bychom se přidat k SotM CZ + SK? Pro nás
bude určitě zajímavé se SotM CZ + SK zúčastnit, zároveň ale asi budeme
pořebovat alespoň 2 hodiny na vlastní talky a diskuzi.

Díky, díky,
jiri

On Fri, Jun 12, 2020 at 09:08:58AM +0200, Tom Ka wrote:
> Ahoj, pokud by se melo drzet toho, jak se to zatim delalo (tj. jednou
> solo, jednou s altem), tak letos solo. Jak s COVIDem na podzim ted
> tezko predvidat. Za mne bych zatim pocital s fyzickou akci zvlast.
> Predpokladam, ze to zase spadne na Brno, ale kdyby se v Praze (nebo
> jinde) chteli hecnout, budu jenom rad :-)
> 
> Kdyz uz jsme v tom, jak to vidite s terminem, za mne prelom zari / rijna?
> 
> A rovnou i nejake napady, koho pozvat? Ja bych rad oslovil mapy.cz, uz
> jsme se chvili nevideli a rad bych jim prezentoval co je noveho u nas
> a slysel, jak to jde u nich.
> 
> Bye
> 
> čt 11. 6. 2020 v 19:29 odesílatel Ladislav Nesnera  napsal:
> >
> > Zdravím. Jak to letos vidíte s konferováním? Symbióza, sólo nebo COVID
> > výmluvy? 藍
> > ;?
> > ___
> > talk-cz mailing list
> > talk-cz@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-cz
> > https://openstreetmap.cz/talkcz
> 
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz

___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

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

[Muselaar]

Bonjour,

Je découvre par hasard que :

https://www.openstreetmap.org/way/110404213

a son nom principal en anglais, et non en allemand, alors qu'on est en 
Allemagne…


Je m’apprêtais à corriger ça, mais je me suis dit que c'était peut-être 
une nouvelle norme d'OSM ? Ou peut-être un usage qui a cours en Allemagne ?


Quoi qu'il en soit, ça me choque…

Muselaar


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

[Jacques Lavignotte]

Le 05/08/2020 à 12:26, PanierAvide a écrit :

Si ça se fait, ça résoudra de fait pas mal de problèmes et questions 
métaphysiques.


s/métaphysiques/essentielles

J.

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

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

Re: [OSM-talk-be] Help to young active men in kivu

[Jo]

If you need someone to teach JOSM online, I can help with that. I can't do
much about prices for internet access.

Polyglot

On Wed, Aug 5, 2020, 13:02 CHAVEZ CIKURU  wrote:

> Hello Prof. Nicolas, Hello Georges, Hello everyone.
>
> Hope you are well.
>
> Here in Kivu, we already use Telegram a lot, we had difficulties being
> able to create accounts on Riot.
>
> In KIVU as in the whole of the national territory, these are the foreign
> communication companies (VODACOM, ORANGE, AIRTEL and AFRICEL in Kinshasa)
> which provide us with the connection, and this is what causes it to have
> the prices high levels of Internet access due to much higher taxes and the
> weak control of the Congolese authorities on the sale of Internet packages,
> weak control of consumption, etc.
>
> I also don't know what the cost of opening a regional service
> communication with Riot can be; maybe it can be done independently without
> accepting the terms of VODACOM, ORANGE or AIRTEL. On this issue, I want to
> try to contact these different companies for clarification.
>
> I wish you a good day and good work.
>
> Yours truly.
>
> Alain
>
> Le ven. 31 juil. 2020 à 14:02, Georges Khaznadar <
> georges.khazna...@free.fr> a écrit :
>
>> Hello Nicolas, hello everybody,
>>
>> using Riot rather than Telegram does not change much when one cannot
>> master the web servers which are providing the service.
>>
>> As far as I undestood, the high prices of Internet access in Kivu are
>> due to foreign companies trusting the scarse hardware network.
>>
>> If I live in Kivu, and if I want to create a small communication
>> company, what would be the cost of opening a regional communication
>> service, eventually featuring Riot? Can I do it independently, or must I
>> accept the conditions of Orange, Airtel or Vodacom?
>>
>> Best regards,   Georges.
>>
>> Nicolas Pettiaux a écrit :
>> > Hello,
>> >
>> > A team of active young men in kivu with very limited internet access
>> are looking for help to map better their city of Bukavu and surroundings.
>> >
>> > They have smatphones and expensive connections with low bandwidth.
>> >
>> > They use telegram and email, but I don't know for riot.
>> >
>> > Some are in cc and more are on the mailing list k...@educode.ne
>> >
>> > Much thanks to everyone who van guide and help thème better than I can
>> or do.
>> >
>> > Regards,
>> >
>> > Nicolas
>> >
>> > --
>> > Nicolas Pettiaux
>> > --
>> > Nicolas Pettiaux, PhD - tel +32.496.24.55.01
>> > Collaborer pour mieux enseigner - https://wiki.educode.be
>> > Educode accompagne les écoles face aux défis du numérique
>> > Envoyé de mon fairphone - veuillez excuser la brièveté
>> >
>>
>> --
>> Georges KHAZNADAR et Jocelyne FOURNIER
>> 22 rue des mouettes, 59240 Dunkerque France.
>> Téléphone +33 (0)3 28 29 17 70
>>
>>
>
> --
>
> *CIKURU KAMERA Alain Chavez*
>
> Technicien en Développement Rural et consultant en matière de développement
>
> *Adresse* : *55, Av. Cibera/A, Q. Nkafu, C. Kadutu, Ville de Bukavu RD.
> Congo*
>
> *Tél* : +243 97 57 57 359, +243 85 23 36 465
>
> *Skype* : Alain Chavez Cikuru Kamera
>
> *Linkedln* : Chavez Alain Cikuru Kamera
>
> *Facebook* : Alain Kamera Cikuru Chavez
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Help to young active men in kivu

[CHAVEZ CIKURU]

Hello Prof. Nicolas, Hello Georges, Hello everyone.

Hope you are well.

Here in Kivu, we already use Telegram a lot, we had difficulties being able
to create accounts on Riot.

In KIVU as in the whole of the national territory, these are the foreign
communication companies (VODACOM, ORANGE, AIRTEL and AFRICEL in Kinshasa)
which provide us with the connection, and this is what causes it to have
the prices high levels of Internet access due to much higher taxes and the
weak control of the Congolese authorities on the sale of Internet packages,
weak control of consumption, etc.

I also don't know what the cost of opening a regional service communication
with Riot can be; maybe it can be done independently without accepting the
terms of VODACOM, ORANGE or AIRTEL. On this issue, I want to try to contact
these different companies for clarification.

I wish you a good day and good work.

Yours truly.

Alain

Le ven. 31 juil. 2020 à 14:02, Georges Khaznadar 
a écrit :

> Hello Nicolas, hello everybody,
>
> using Riot rather than Telegram does not change much when one cannot
> master the web servers which are providing the service.
>
> As far as I undestood, the high prices of Internet access in Kivu are
> due to foreign companies trusting the scarse hardware network.
>
> If I live in Kivu, and if I want to create a small communication
> company, what would be the cost of opening a regional communication
> service, eventually featuring Riot? Can I do it independently, or must I
> accept the conditions of Orange, Airtel or Vodacom?
>
> Best regards,   Georges.
>
> Nicolas Pettiaux a écrit :
> > Hello,
> >
> > A team of active young men in kivu with very limited internet access are
> looking for help to map better their city of Bukavu and surroundings.
> >
> > They have smatphones and expensive connections with low bandwidth.
> >
> > They use telegram and email, but I don't know for riot.
> >
> > Some are in cc and more are on the mailing list k...@educode.ne
> >
> > Much thanks to everyone who van guide and help thème better than I can
> or do.
> >
> > Regards,
> >
> > Nicolas
> >
> > --
> > Nicolas Pettiaux
> > --
> > Nicolas Pettiaux, PhD - tel +32.496.24.55.01
> > Collaborer pour mieux enseigner - https://wiki.educode.be
> > Educode accompagne les écoles face aux défis du numérique
> > Envoyé de mon fairphone - veuillez excuser la brièveté
> >
>
> --
> Georges KHAZNADAR et Jocelyne FOURNIER
> 22 rue des mouettes, 59240 Dunkerque France.
> Téléphone +33 (0)3 28 29 17 70
>
>

-- 

*CIKURU KAMERA Alain Chavez*

Technicien en Développement Rural et consultant en matière de développement

*Adresse* : *55, Av. Cibera/A, Q. Nkafu, C. Kadutu, Ville de Bukavu RD.
Congo*

*Tél* : +243 97 57 57 359, +243 85 23 36 465

*Skype* : Alain Chavez Cikuru Kamera

*Linkedln* : Chavez Alain Cikuru Kamera

*Facebook* : Alain Kamera Cikuru Chavez
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk] [Osmf-talk] Funding of iD Development and Maintenance

[Mateusz Konieczny via talk]

What is the reason for funding iD and not funding JOSM?

Especially given that JOSM is used for similar number of edits
and is much more successful at several important points,
including developers with significantly higher respect toward mapping
community?

Is it just result of "He has written up this proposal"? Have you reached out to
JOSM devs about also supporting their work?

Aug 2, 2020, 13:44 by mikel.ma...@gmail.com:

> Hello
>
> The OSMF board is working to make OSM's core software and infrastructure more 
> stable and sustainable by supporting paid roles for priority needs, such as 
> the Senior Site Reliability role 
> (https://lists.openstreetmap.org/pipermail/osmf-talk/2020-July/006973.html), 
> and the pilot to fund "OSM Infrastructure" projects 
> (https://lists.openstreetmap.org/pipermail/osmf-talk/2020-August/006987.html).
>
> As part of this focus, we want to organise coordinated funding to support 
> continued maintenance and development of the iD editor, as iD's strong 
> continuous development over the past several years has served the OSM 
> community well. Quincy Morgan is iD's maintainer and lead developer. 
> Unfortunately, full-time support of his work recently ended. He'd very much 
> like to continue, and the OSMF Board wants to see that happen. He has written 
> up this proposal 
> (https://github.com/quincylvania/quincylvania.com/blob/main/resources/Morgan%20iD%20work%20proposal%207_27.pdf)
>  with his ideal plans for iD over the next year, along with notes about how 
> he'll organise, grow the developer base, communicate, and set priorities, and 
> make iD better. The final priorities for the year will be made in 
> consultation with the community.
>
> To help fund this project, as well as the SSRE role, we're looking at 
> earmarked donations from companies, chapters and organisations. 
> Administratively, we believe this is easier than other methods of pooled 
> funding, as the OSMF is already in most companies' procurement systems, and 
> it would limit paperwork to one contract for iD. Initial contract would be 
> for 1 year, and that's what the OSMF would look to raise now.
>
> With the OSMF holding the contract, the Board would take a key accountability 
> role, reviewing work done on the contract and assessing progress on the plans 
> Quincy develops for the project. Additionally, the OSMF is working in 
> cooperation with Quincy to establish a formal appeal process 
> (https://blog.openstreetmap.org/2020/06/08/toward-resolution-of-controversies-related-to-id/)
>  for the relatively rare community issues iD cannot resolve itself.
>
> The OSMF would not see its role as a traditional "boss", instructing iD to 
> focus on this or that feature. We would not be prescriptive about priorities. 
> This does not mean work in a vacuum. Our expectation is that Quincy, in 
> addition to following our hiring framework's principles for transparent 
> service to the community, would regularly convene stakeholders from the 
> community to share their priorities and feedback. Quincy would assess all 
> priorities holistically as he decides on a workable plan for the project.
>
> Over the course of the year, we'll evaluate and learn from how the 
> arrangement is working for all, as we look towards year 2 and beyond. For 
> future years, we are looking at developing an overall plan for long-term 
> support for all parts of the OSMF infrastructure. We want to be able to offer 
> similar support to other OSM editors. Our early focus on iD is to ensure 
> continued development.
>
> We want to find out what you, the OSM community, think. Do you have any 
> feedback?
>
> If you know of an organisation that might want to fund this, please feel free 
> to ask them to contact the OSMF Board.
>
> -Mikel, for the OSMF Board
>
> * Mikel Maron * +14152835207 @mikel s:mikelmaron
>
> ___
> osmf-talk mailing list
> osmf-t...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osmf-talk
>

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

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

[Christian Quest]

Le 04/08/2020 à 22:24, osm.sanspourr...@spamgourmet.com a écrit :


Donc deux possibilités :

- à partir de leurs données et des nôtres on fait une base consolidée 
conforme en ODbL



BADO: BAs des Dae Ouverte ;)


- les contributeurs qui travaillent sur leurs données les améliorent 
en double licence ODbL/LO.


Du coup et à condition que l'historique complet des données 
pertinentes des points intégrés soient faites par de tels 
contributeurs, on peut faire un export LO.


Donc c'est possible en théorie. En pratique c'est une usine à gaz. Le 
but est me semble-t-il de sauver des vies pas de faire des moulinettes 
à la con pour contourner des problèmes de licences.


Usine à gaz tech et legal... et pour que ce soit clean, il faudrait une 
contribution hors OSM qui alimente OSM... ce qu'on avait envisagé pour 
la BAN, mais jamais passé à la réalisation.



Mais on est d'accord une localisation bonne, ce n'est pas important 
pour sauver des vies...


_Geo_ DAE comme les régimes ni républicains ni démocratiques mettent 
"République démocratique de xxx" ?


Veulent-ils sauver des vies ou gérer des parcs de DAE ? Sans doute les 
deux mais sauver des vies ce sera dans un second temps.


Bien sûr le but des DAE et du parc de DAE est de sauver des vies, mais 
beaucoup regardent le doigt qui montre la lune :(


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

[PanierAvide]

Après des discussions avec l'interlocuteur côté Ministère ce matin, ils 
vont étudier la possibilité de basculer en Odbl. Si ça se fait, ça 
résoudra de fait pas mal de problèmes et questions métaphysiques. En 
attendant ça ne nous empêche pas de continuer à avancer de notre côté 
par les relevés terrains et l'intégration vérifiée des données GéoDAE.


Adrien P.

Le 04/08/2020 à 22:24, osm.sanspourr...@spamgourmet.com a écrit :


Donc deux possibilités :

- à partir de leurs données et des nôtres on fait une base consolidée 
conforme en ODbL
- les contributeurs qui travaillent sur leurs données les améliorent 
en double licence ODbL/LO.


Du coup et à condition que l'historique complet des données 
pertinentes des points intégrés soient faites par de tels 
contributeurs, on peut faire un export LO.


Donc c'est possible en théorie. En pratique c'est une usine à gaz. Le 
but est me semble-t-il de sauver des vies pas de faire des moulinettes 
à la con pour contourner des problèmes de licences.


Mais on est d'accord une localisation bonne, ce n'est pas important 
pour sauver des vies...


_Geo_ DAE comme les régimes ni républicains ni démocratiques mettent 
"République démocratique de xxx" ?


Veulent-ils sauver des vies ou gérer des parcs de DAE ? Sans doute les 
deux mais sauver des vies ce sera dans un second temps.


Jean-Yvon

Le 04/08/2020 à 15:53, PanierAvide - panierav...@riseup.net a écrit :


Les licences... éternelle prise de tête pour (presque) aucune valeur 
ajoutée ;-) On peut peut-être les convaincre de passer sur l'Odbl, ça 
s'est fait pour les adresses pourquoi pas ici.


Adrien P.
Le 04/08/2020 à 15:32, Donat ROBAUX a écrit :

Hello,

Ce qui m'emmerde dans tout ca, c'est surtout cette histoire de 
licence (et pas que pour ce projet) puisque Geo DAE est en LO donc 
incompatible dans le sens OSM => GeoDEA, alors que des contributeurs 
sont prêts à améliorer les données.


Donat

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


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


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

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

[osm . sanspourriel]

Donc deux possibilités :

- à partir de leurs données et des nôtres on fait une base consolidée
conforme en ODbL
- les contributeurs qui travaillent sur leurs données les améliorent en
double licence ODbL/LO.

Du coup et à condition que l'historique complet des données pertinentes
des points intégrés soient faites par de tels contributeurs, on peut
faire un export LO.

Donc c'est possible en théorie. En pratique c'est une usine à gaz. Le
but est me semble-t-il de sauver des vies pas de faire des moulinettes à
la con pour contourner des problèmes de licences.

Mais on est d'accord une localisation bonne, ce n'est pas important pour
sauver des vies...

_Geo_ DAE comme les régimes ni républicains ni démocratiques mettent
"République démocratique de xxx" ?

Veulent-ils sauver des vies ou gérer des parcs de DAE ? Sans doute les
deux mais sauver des vies ce sera dans un second temps.

Jean-Yvon

Le 04/08/2020 à 15:53, PanierAvide - panierav...@riseup.net a écrit :


Les licences... éternelle prise de tête pour (presque) aucune valeur
ajoutée ;-) On peut peut-être les convaincre de passer sur l'Odbl, ça
s'est fait pour les adresses pourquoi pas ici.

Adrien P.
Le 04/08/2020 à 15:32, Donat ROBAUX a écrit :

Hello,

Ce qui m'emmerde dans tout ca, c'est surtout cette histoire de
licence (et pas que pour ce projet) puisque Geo DAE est en LO donc
incompatible dans le sens OSM => GeoDEA, alors que des contributeurs
sont prêts à améliorer les données.

Donat

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


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

Re: [OSM-talk] [Osmf-talk] Proposal for Software Dispute Resolution Panel

[Christoph Hormann]

On Wednesday 05 August 2020, Allan Mustard wrote:
>
> Please re-read the RFC that led to this proposal at
> https://blog.openstreetmap.org/2020/06/08/toward-resolution-of-contro
>versies-related-to-id/, which includes the statement, "This request
> for comment is expected to lead to adoption of community structures
> that will not answer to the Board or be influenced by the Board, in
> keeping with the OSM philosophy that the Board supports OSM but does
> not tell anybody what to map or how to map."

I have read all that carefully and the bottom line is the current board 
has a poor track record for considerably revising decisions once they 
are made (could provide a long list here but i don't think that is 
necessary).  So excuse me if i argue based on the work hypothesis that 
in substance that RFC will become policy mostly as is.  Happy to be 
proven wrong about this.

> OSM has no political appointees.  [...]

No point in arguing about language semantics.  What i mean is that there 
is no auditable selection process based on defined and documented 
criteria of qualification.  The board looks at the nominees.  Each 
board member has their favorites (based on well meaning but individual, 
subjective criteria, "volunteers whose work we know and enjoy") and 
then they negotiate how to fill the limited number of seats.  The 
result is one of political balance rather than qualification.  There 
will be some corporate employees but also some hobby craft mappers - 
maybe also someone with HOT affiliations or some compromise candidate 
in between.  You will try to have at least one or two women and at 
least one or two people from outside Europe and North America.  The 
majority will be native English speakers matching the 
overrepresentation of those in the OSMF.

See the microgrants committee as an example.

> The Board selected the members of the
> Diversity and Inclusion Special Committee and the Microgrants
> Committee from among volunteers, and that was not controversial.

Just because you so far have not perceived critique does not mean it is 
non-controversial.  People often do not feel very inclined to 
articulate critique in personnell selection because that is hard to do 
without it appearing as critique of the people selected.

> > Interesting also that the composition of the panel is supposed to
> > reflect "all interests of the OSM community" but competence of the
> > panel members on the subject, experience with and knowledge of
> > mapping and tagging in OSM or in other words:  The competence to
> > assess evidence on the cases they deal with and to deliberate on
> > the matters in a qualified and knowledgable way, is not a
> > criterion.  Neither is impartiality on prominent special interests
> > like those of corporate data users.
>
> Taking the latter point first, if you consider the
> conflict-of-interest rules the Board has proposed for all
> OSMF-related bodies to be inadequate, please offer alternative
> language.

I do consider the conflict-of-interest handling and corruption 
prevention of the OSMF inadequate but i will not offer alternative 
regulation on that.  Why?  Because this is a problem of the lack of 
awareness.  You cannot instill awareness through policy, imposing such 
policy (theoretically, practically i don't have the power to do that of 
course) in the absence of sufficient awareness will lead to people 
following the letter of said policy and trying to weasel around 
restrictions but not follow the spirit of it.  In other words - 
corruption would be treated as a compliance problem rather than a 
social and cultural issue.

> Since the panel would be an arm of the OSMF, it would 
> quite likely need to adopt
> conflict-of-interest rules in order to conform to the requirements of
> the Companies Act, and might adopt rules similar to those of the DWG:
> https://wiki.osmfoundation.org/wiki/Data_Working_Group/DWG_Conflict_o
>f_Interest_Policy 

We have a saying in German: "Der Fisch stinkt vom Kopf her" - integrity 
in an organization almost always has to come from the top through 
leading by example.  Or the other way round - a lack of responsibility 
on the top level can rarely be compensated by islands of integrity 
below.  The DWG is a rare exception here, deriving largely from the 
high degree of independence of the DWG from the board - and this has 
caused significant friction between the DWG and board members in the 
past by the way.  If you think to outsource the responsibility to 
ensure an ethical work style to panels and committees you appoint - 
that is most likely not going to work.  The microgrants committee is a 
good example here - they have not documented any ethical principles for 
their work so far.

> As to the competence of panel members, I am surprised that you would
> assume the Board would prefer incompetent candidates over competent
> candidates. 

I did not make such an assumption.  I pointed out that in the part about 
composition of the panel the 

[talk-cz] WeeklyOSM CZ 523

[Tom Ka]

Ahoj, je dostupné vydání 523 týdeníku WeeklyOSM:

https://weeklyosm.eu/cz/archives/13451

* Lokální zastoupení Nadace OSM.
* Výpadky KAPOR.
* 16. narozeniny OSM.
* 10 let WeeklyOSM.
* Otevřené adresy v UK.
* Změny OSM v čase.
* Konzervativci v OSM?
* Interakce s CartONG.
* 3D muzeum v OSM.
* Neimporty Facebooku.
* Zkušenosti s RapiD.
* Kde aktualizovat OSM?
* Editor iD dotykově.
* Generování městských map.
* Nefunkční Garmin.
* Budoucnost cyklo Berlína.

Pěkné počtení ...

___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

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

[PanierAvide]

Bonjour,

J'ai réalisé une version fusionnée + mise à jour des fichiers (et qui 
sera actualisée quotidiennement) : 
https://files.pavie.info/depot/remote/aedmap_merge.csv


Pas de script d'import, la qualité des données au niveau nommage ne le 
permet pas. Je fais une proposition d'intégration à Osmose pour 
faciliter la tâche ( https://github.com/osm-fr/osmose-backend/pull/940 ).


Pour ce qui est des tags permanents, j'ai fait une passe sur le wiki ( 
https://wiki.openstreetmap.org/wiki/FR:Tag:emergency%3Ddefibrillator ) 
pour réorganiser/détailler les attributs supplémentaires (à discuter), 
et effectivement ça vaudrait le coup de vérifier les presets JOSM et iD 
(tu pourrais t'en occuper ?).


Cordialement,

Adrien P.

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


Une partie (à priori) des données d'AED Map sont publiées sur 
data.gouv : https://www.data.gouv.fr/fr/datasets/defibrillateurs-publics/



Il y a un fichier par commune. Sont-ils vraiment homogènes ?

Je viens de voir la version fusionnée de Christian et avec des 
coordonnées WGS 84 :)

https://www.data.gouv.fr/fr/datasets/r/ee8bf6fe-5043-447a-9a49-06458b4c6604

Il y a des informations redondantes dans les champs *Nom*, *Adresse* 
et *Adresse 2* :
Ce n'est pas gênant pour un contributeur qui va intégrer le POI (et 
surtout aller vérifier sur place), mais attention avec un script d'import.


*Identifiant* 	*Nom* 	*Adresse* 	*Adresse 2* 	*Code postal* 	*Ville* 
*Country* 	*Longitude* 	*Latitude* 	*Modification*
110755 	GYMNASE Gérard SEBASTIA 	GYMNASE Gérard SEBASTIA Complexe de 
la bâtie 	579 Avenue Jean Moulin – La Bâtie 	83220 	Le Pradet 	FR 
6.01535 	43.111674 	13/11/2017 15:03:01
110753 	POLICE MUNICIPALE 	POLICE MUNICIPALE 	440, avenue 1ére DFL 
83220 LE PRADET 	83220 	Le Pradet 	FR 	6.016704 	43.106835 	13/11/2017 
14:48:37
95540 	DAE point information Plagne Bellecote 	Plagne Bellecote 	Point 
Information 	73210 	Mâcot-la-Plagne 	FR 	6.697529 	45.514204 
29/10/2018 13:58:19
95539 	DAE point information Plagne 1800 	Plagne 1800 	Point 
Information 	73210 	Mâcot-la-Plagne 	FR 	6.678088 	45.513558 
29/10/2018 14:34:30



*Comment cartographier ça dans OSM de façon utile (et homogène) ?* En 
cas d'arrêt cardiaque, chaque minute compte ;)


Pour certains DAE, il faut*indiquer comment le trouver dans le bâtiment.*
Préciser les horaires d'accès (il n'y en a aucun dans les données 
publiées dans data.gouv.fr ) et un n° de tél si 
c'est accessible uniquement aux heures d'ouverture de l'établissement ?


Et dans les bâtiments complexes, l'indoor mapping n'est probablement 
pas une option ;)


Et que fait-on du véhicule de patrouille de la Police Municipale 
d'Angoulême ?

Il manque au moins un n° de téléphone ?

Comment publier des photos utiles ?
Une, deux ?
Sur quel site ? Dans quels champs ?

La version (2) beta d'osmHydrant peut afficher plusieurs photos mais 
il n'y a aucun tag dans OSM (il y a des "modèles" dans les photos 
Wikimedia Commons).

La carte fait des requêtes overpass (c'est lent et peu fiable).
Exemple : mairie d'Hautecour 
 et 
copie d'écran 



 Ceci dit, rien n'empêche de ne publier que ce qui a été 
rapproché/validé mais d'avoir un bac à sable dans la base avec tout 
ce qui est possible, histoire d'identifier des DAE potentiellement 
existants sur le terrain mais toujours pas signalés par leurs 
exploitants. 
Ou indiquer les*DAE absents* de leur boîtier (l'asso dans laquelle je 
travaillais l'a enlevé car elle n'a pas les moyens de changer sa 
batterie) mais *toujours signalé sur le terrain* par un beau panneau 
vert DAE !

J'en ai croisé 2 autres dans un village.

__
Yves

Pour la saisie efficace et homogène dans OSM, je relance mon message : 
les presets JOSM et iD sont-ils homogènes et adaptés ??



___

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

[Yves P.]

> Une partie (à priori) des données d'AED Map sont publiées sur data.gouv : 
> https://www.data.gouv.fr/fr/datasets/defibrillateurs-publics/ 
> Il y a un 
> fichier par commune. Sont-ils vraiment homogènes ?

Je viens de voir la version fusionnée de Christian et avec des coordonnées WGS 
84 :)
https://www.data.gouv.fr/fr/datasets/r/ee8bf6fe-5043-447a-9a49-06458b4c6604 


Il y a des informations redondantes dans les champs Nom, Adresse et Adresse 2 :
Ce n'est pas gênant pour un contributeur qui va intégrer le POI (et surtout 
aller vérifier sur place), mais attention avec un script d'import.

Identifiant Nom Adresse Adresse 2   Code postal Ville   Country 
Longitude   LatitudeModification
110755  GYMNASE Gérard SEBASTIA GYMNASE Gérard SEBASTIA Complexe de la bâtie
579 Avenue Jean Moulin – La Bâtie   83220   Le Pradet   FR  6.01535 
43.111674   13/11/2017 15:03:01
110753  POLICE MUNICIPALE   POLICE MUNICIPALE   440, avenue 1ére DFL 
83220 LE PRADET83220   Le Pradet   FR  6.01670443.106835
   13/11/2017 14:48:37
95540   DAE point information Plagne Bellecote  Plagne BellecotePoint 
Information   73210   Mâcot-la-Plagne FR  6.69752945.514204 
  29/10/2018 13:58:19
95539   DAE point information Plagne 1800   Plagne 1800 Point 
Information   73210   Mâcot-la-Plagne FR  6.67808845.513558 
  29/10/2018 14:34:30

Comment cartographier ça dans OSM de façon utile (et homogène) ? En cas d'arrêt 
cardiaque, chaque minute compte ;)

Pour certains DAE, il faut indiquer comment le trouver dans le bâtiment. 
Préciser les horaires d'accès (il n'y en a aucun dans les données publiées dans 
data.gouv.fr ) et un n° de tél si c'est accessible 
uniquement aux heures d'ouverture de l'établissement ?

Et dans les bâtiments complexes, l'indoor mapping n'est probablement pas une 
option ;)

Et que fait-on du véhicule de patrouille de la Police Municipale d'Angoulême ?
Il manque au moins un n° de téléphone ?

Comment publier des photos utiles ?
Une, deux ?
Sur quel site ? Dans quels champs ?

La version (2) beta d'osmHydrant peut afficher plusieurs photos mais il n'y a 
aucun tag dans OSM (il y a des "modèles" dans les photos Wikimedia Commons).
La carte fait des requêtes overpass (c'est lent et peu fiable).
Exemple : mairie d'Hautecour 

 et copie d'écran 


>  Ceci dit, rien n'empêche de ne publier que ce qui a été rapproché/validé 
> mais d'avoir un bac à sable dans la base avec tout ce qui est possible, 
> histoire d'identifier des DAE potentiellement existants sur le terrain mais 
> toujours pas signalés par leurs exploitants. 
Ou indiquer les DAE absents de leur boîtier (l'asso dans laquelle je 
travaillais l'a enlevé car elle n'a pas les moyens de changer sa batterie) mais 
toujours signalé sur le terrain par un beau panneau vert DAE !
J'en ai croisé 2 autres dans un village.

__
Yves

Pour la saisie efficace et homogène dans OSM, je relance mon message : les 
presets JOSM et iD sont-ils homogènes et adaptés ??

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

[Christian Quest]

Le 04/08/2020 à 23:51, Francois Gouget a écrit :

On Tue, 4 Aug 2020, PanierAvide wrote:
[...]

Il y a quelques semaines, la Direction Générale de la Santé a publié sa
base GéoDAE (en cours de constitution), qui recense les défibrillateurs
du pays.

[...]

En parallèle, dans OSM sur la France, on compte ~6500 défibrillateurs.
Évidemment les deux bases ne se recoupent pas, certains DAE sont
présents dans l'une et pas l'autre. En 2020, c'est quand même dommage.

Quelqu'un sait-il sur quelle base de donnée s'appuie l'application
Staying Alive ? Et surtout quelle est la license de cette base de
donnée de défibillateurs ?


Propriétaire


Sur https://www.stayingalive.org/ je vois "Powered by AEDMap". Mais sur
le site de AEDMap rien de bien précis : https://aedmap.org/

J'ai l'impression qu'il s'agit d'une base propriétaire construite sur le
travail de bénévoles. Mais leur coeur de métier ne semble pas être cette
base de donnée mais plutôt la maintenance de défibrillateurs.


C'est bien ça. Le créateur d'AEDmap est un ancien médecin (SAMU).


Le 05/08/2020 à 06:55, PanierAvide a écrit :


Une partie (à priori) des données d'AED Map sont publiées sur 
data.gouv : https://www.data.gouv.fr/fr/datasets/defibrillateurs-publics/


Cela ne concerne que ceux déclarés par les collectivités, donc pas la 
partie contribution bénévole.


C'est ça, ils ont publié "pour le compte" de collectivité qui sont leur 
clients en maintenance, mais pas plus.



Une fusion de ces jeux de données en août 2019 par Christian laissait 
ressortir 900 DAE de cette base. Je ne sais pas dans quelle mesure ils 
ont été contactés pour diffuser les données créées par les bénévoles.


Je ne sais pas non plus si la DGS a beaucoup fait pour récupérer ces 
données ou pas. Je pense que non vu leur doctrine de ne faire figurer 
dans leur base que les données provenant des exploitants, pensant 
qu'elles seraient plus fiables (ou bien sortant le parapluie en 
renvoyant la balle vers les exploitants).


Accepter d'autres données leur fait porter une responsabilité car cela 
sortirait du cadre de la Loi. Ceci dit, rien n'empêche de ne publier que 
ce qui a été rapproché/validé mais d'avoir un bac à sable dans la base 
avec tout ce qui est possible, histoire d'identifier des DAE 
potentiellement existants sur le terrain mais toujours pas signalés par 
leurs exploitants. Ceci permettrait aussi d'identifier des exploitants 
qui n'ont pas fait les démarches qu'ils auraient dû faire...


Une telle démarche proactive est malheureusement très loin du 
fonctionnement habituel administratif qui part plutôt du principe que 
tout le monde est censé déclarer ses DAE, respecter le schéma de 
données, fournir des informations correctes... et que leur rôle est 
juste de mettre en place de quoi recevoir ces déclarations et fournir le 
résultat, pas de constituer la base la plus complète, à jour et 
d'utilité vitale.


--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk] Many processes not defined | Re: Proposal for Software Dispute Resolution Panel

[Rory McCann]

I meant, that the board hasn't decided how the board will 
vote/appoint/choose the members of this panel.


On 05/08/2020 01:07, Christoph Hormann wrote:

On Tuesday 04 August 2020, Rory McCann wrote:

The Board hasn't decided on how the panel will be
formed/elected/appointed/choosen.


Quoting from the proposal:


In appointing members of the Panel, the Board shall strive for Panel

composition (membership) that reflects [...]

Seems there are some eddies in the fabric of spacetime...

<>___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk