Re: [OSM-talk-fr] maxspeed par défaut

2020-09-02 Par sujet Marc Mongenet 
Bonjour

> Le 02/09/2020 à 10:33, Eric SIBERT via Talk-fr - talk-fr@openstreetmap.org a 
> écrit :
>
> +1 avec les avis précédents: en extra-urbain, l'implicite est devenu 
> tellement incompréhensible qu'il vaut mieux coder explicitement.
> Par défaut c'est 80 km/h sur les chaussées à double sens:
> - sauf sur certaines portions de départementale dans certains départements
Oui, mais je suppose que la source sera alors toujours un panneau.
Mais si le panneau n'est pas répété après une intersection, je suppose
que ça retombe à 80.

> - sauf quand il y a un une voie supplémentaire pour faire un créneau de 
> dépassement
90 km/h dans ce cas.

> - pareil pour les routes pour automobile (panneau C107) à double-sens?
De ce que j'ai compris de l'Article 5 (voir mon autre message), C107
implique le 110 km/h sauf limitation explicite.

> - On peut imaginer une route à double-sens avec un terre-plein temporaire
> pour un carrefour. Ce n'est pas pour autant que le long du terre-plein,
> la limite va passer à 90 km/h.
Effectivement, dans ce cas ça passe carrément à 110 km/h d'après R413-2 !

> Donc l'implicite est difficile à expliquer à l'humain et à l'ordinateur.
> Je ne sais même plus ce qu'il faut mettre pour source:maxspeed dans ces cas 
> là.
Je ne sais pas quelle maxspeed mettre dans certains cas. C'est pour
cette raison que je pense préférable de ne pas essayer de deviner la
limite explicite, mais plutôt indiquer "maxspeed=FR:rural".

Le mer. 2 sept. 2020 à 10:54,  a écrit :
>
> > - On peut imaginer une route à double-sens avec un terre-plein
> >  temporaire pour un carrefour. Ce n'est pas pour autant que le
> > long du terre-plein, la limite va passer à 90 km/h.
>
> En théorie tu as raison. En pratique... Je ne sais si un gars a eu une
> offre spéciale pour réutiliser les anciens panneaux !

A noter que ce cas ne correspond pas à l'exemple avec un terre-plein
temporaire ; c'est le cas à plusieurs voies dans le même sens.
Le panneau 90 est ici superflu, maxspeed=FR:rural + lanes:forward=2
impliquant 90 km/h.

Marc Mongenet

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

Re: [OSM-talk-fr] maxspeed par défaut

2020-09-02 Par sujet Marc Mongenet 
Le mer. 2 sept. 2020 à 01:16, Yannick  a écrit :
> L'implicite est désormais quasi impossible à deviner.
> Je suis donc partisan de mettre systématiquement le maxspeed=* au
> moins c'est clairement renseigné sans équivoque possible.

Oui l'implicite est difficile à maîtriser. Mais le problème que j'ai
rencontré, et je pense qu'il est répandu, c'est que les mappeurs ne
connaissent pas suffisamment bien le code de la route pour expliciter
correctement l'implicite! D'ailleurs, en relisant les textes
réglementaires avant de poster, je me suis rendu compte que je ne suis
pas tout à fait au clair moi-même.

Ainsi, je pense que
https://wiki.openstreetmap.org/wiki/FR:Key:maxspeed#Limitation_de_vitesse
se trompe en écrivant:
> hors agglomération : 80 km/h sur les routes sans séparateur
> de voie, 90 km/h sur les routes avec séparateur
En effet l'article R413-2 donne 110 et pas 90 km/h:
> Hors agglomération, la vitesse des véhicules est limitée à []
> 110 km/ h sur les routes à deux chaussées séparées par
> un terre-plein central ;
Le cas n'est pas théorique, je connais une occurrence près de chez moi:
https://www.google.fr/maps/@46.1980371,6.2917578,3a,75y,342.01h,94.36t/data=!3m6!1e1!3m4!1sifBdoBwUx_iYoXFBxbB-lA!2e0!7i16384!8i8192

Il y a aussi la question des routes à accès réglementé, signalées par
le panneau C107 (le carré bleu avec une auto).
Est-ce qu'une route à accès réglementé dont la chaussée contient une
voie dans chaque sens sans terre-plein central est limitée à 80 ou 110
km/h?
Je pense que c'est 110 km/h par application de l'Article 5 de l'Arrêté
du 24 novembre 1967 relatif à la signalisation des routes et des
autoroutes:
> Ce signal annonce le début d'une section de route autre
> qu'une autoroute, réservée à la circulation automobile,
> sur laquelle les règles de circulation sont les mêmes que
> celles prescrites aux articles R. 412-8, R. 417-10, R. 421-2
> (à l'exception de 9°), R. 421-4 à R. 421-7, R. 432-1, R. 432-3,
> R. 432-5, R. 432-7 et R. 433-4 (1°) du code de la route et sur
> laquelle, sauf indication contraire, la vitesse maximale des
> véhicules est fixée à 110 km / h.
Mais le cas est peut-être théorique, car je ne connais pas de telle
route sans limitation explicite.

Le 02/09/2020 à 07:16, Gad Jo a écrit :
> Préfère source:maxspeed=FR:urban + maxspeed=80 pour définir partout
> où la vitesse est à 80.

Je suppose que tu voulais écrire source:maxspeed=FR:rural, non?

Le 02/09/2020 à 10:34, Frédéric Rodrigo a écrit :
> Quand la vitesse est implicite, il y encore plus générique que mettre
> explicitement la vitesse. Mais plutôt :
> maxspeed=FR:urban

Est-ce que maxspeed=FR:rural seul est OK pour une route rurale?
Ou bien maxspeed=FR:rural + source:maxspeed=FR:rural est meilleur?
Un simple maxspeed=FR:rural me semble déjà implicitement indiquer que
la source est la vitesse implicite, mais bon.

En fait, ce qui m'intéresse beaucoup avec FR:rural, c'est
1. la simplification induite pour les créneaux de dépassement ;
1.1. Au lieu de maxspeed:forward=90 + maxspeed:backward=80 ;
simplement maxspeed=FR:rural ;
2. De ne pas devoir choisir entre 80, 90, et 110, pour les routes à
chaussées séparées ;
2.2. Sur la route visible avec l'URL google que j'ai donné ci-dessus,
je pense que la loi dit 110, mais les automobilistes vont pratiquement
tous à 80.

Marc Mongenet

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

Re: [OSM-talk-fr] test n° 3 depuis Thunderbird

2020-09-02 Par sujet Georges Dutreix via Talk-fr 
Test n° 2 rejeté par la police (expéditeur incorrect). Je soupçonne un 
petit souci de configuration de FairEmail et non pas de mon fournisseur 
Zaclys, mais je ne vois pas trop quoi.
Je tenterai donc de ne répondre que depuis mon ordinateur... pour voir 
si ça continue. Si jamais vous recevez encore mes messages en Spam, 
dites-le moi en direct.


Merci encore pour les réponses. Bonne soirée.


Le 02/09/2020 à 22:07, osm.sanspourr...@spamgourmet.com a écrit :
Pareil ici : 1 et 3 reçus, pas 2 qui n'est pas en pourriel, ni côté 
serveur ni côté client.


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

Re: [OSM-talk-fr] Test n°1 compte zaclys

2020-09-02 Par sujet Jacques Lavignotte 

Pas reçu le 3.


Le 02/09/2020 à 21:48, Georges Dutreix via Talk-fr a écrit :

Bonjour à tous,



--
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] test n° 3 depuis Thunderbird

2020-09-02 Par sujet osm . sanspourriel 


Le 02/09/2020 à 21:58, Florian_G - forums+...@floriang.eu a écrit :


Reçu dans ma boite de réception.

Je n'ai pas encore reçu le numéro 2.

++


Pareil ici : 1 et 3 reçus, pas 2 qui n'est pas en pourriel, ni côté
serveur ni côté client.

Je suppose que le message 2 a été expédié avant le 3 ;-)

Jean-Yvon


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

Re: [OSM-talk-fr] test n° 3 depuis Thunderbird

2020-09-02 Par sujet Denis Helfer 


Le 02/09/2020 à 21:54, Georges Dutreix via Talk-fr a écrit :

Dernier test depuis mon ordinateur.
Merci de me signaler si vous avez eu ce mail en indésirable. Sinon 
vous pouvez le jeter :-)


C'est fini, je ne vous embête plus.

Merci beaucoup.
Georges


Eagle has landing (1)

1. https://www.fai.org/news/apollo-11-eagle-has-landed

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

Re: [OSM-talk-fr] test n° 3 depuis Thunderbird

2020-09-02 Par sujet Florian_G 
Re,

Le 02/09/2020 à 21:54, Georges Dutreix via Talk-fr a écrit :
> Dernier test depuis mon ordinateur.
> Merci de me signaler si vous avez eu ce mail en indésirable. Sinon
> vous pouvez le jeter :-)
>
> C'est fini, je ne vous embête plus.
>
> Merci beaucoup.
> Georges

Reçu dans ma boite de réception.

Je n'ai pas encore reçu le numéro 2.

++

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

Re: [OSM-talk-fr] Test n°1 compte zaclys

2020-09-02 Par sujet Florian_G 
Hello,

Le 02/09/2020 à 21:48, Georges Dutreix via Talk-fr a écrit :
> Mail envoyé depuis FairEmail en changeant l'expéditeur.
>
> Merci beaucoup de me dire si vous avez ce message en indésirable.

Reçu dans ma boite de réception.

++

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

[OSM-talk-fr] test n° 3 depuis Thunderbird

2020-09-02 Par sujet Georges Dutreix via Talk-fr 

Dernier test depuis mon ordinateur.
Merci de me signaler si vous avez eu ce mail en indésirable. Sinon vous 
pouvez le jeter :-)


C'est fini, je ne vous embête plus.

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

Re: [OSM-talk-fr] Test n°1 compte zaclys

2020-09-02 Par sujet Denis Helfer 


Le 02/09/2020 à 21:48, Georges Dutreix via Talk-fr a écrit :

Bonjour à tous,

Je vais être un peu hors sujet et vous prie de me pardonner.
Plusieurs d'entre vous m'ont signalé que mes mails arrivaient en 
indésirables. Avant d'accuser Zaclys, je voudrais faire quelques 
tests. Trois tests dont celui ci est le premier.

Mail envoyé depuis FairEmail en changeant l'expéditeur.

Merci beaucoup de me dire si vous avez ce message en indésirable.

Georges


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

[OSM-talk-fr] Test n°1 compte zaclys

2020-09-02 Par sujet Georges Dutreix via Talk-fr 
Bonjour à tous,

Je vais être un peu hors sujet et vous prie de me pardonner.
Plusieurs d'entre vous m'ont signalé que mes mails arrivaient en indésirables. 
Avant d'accuser Zaclys, je voudrais faire quelques tests. Trois tests dont 
celui ci est le premier.
Mail envoyé depuis FairEmail en changeant l'expéditeur.

Merci beaucoup de me dire si vous avez ce message en indésirable.

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

Re: [OSM-talk-fr] Rond point et relations routes

2020-09-02 Par sujet Gad.Jo 
Dans un monde parfait mettre uniquement les arrêts serait nickel mais 
cela prive les usagers du tracé.


Dans l'agglo où je vie à part des pdf inexploitable sur un smartphone il 
n'y a aucun plan du réseau. En sus la majorité des plans pdf ne sont pas 
orienté dans le sens nord sud. Cela rend complexe la compréhension de 
leur plan.


Peut être que dans les années à venir seul les arrêts seront suffisant + 
les nœuds où passe la ligne pour lever toute ambiguïté quand le bus 
emprunte non pas la route la plus logique mais celle décidé par la régie 
de transport...


Le 02/09/2020 à 18:49, leni a écrit :



Le 01/09/2020 à 18:23, Gad Jo a écrit :
Pour avoir mis en place l'ensemble du réseau de bus sur Narbonne 
c'est la mort dans l'âme que j'ai du segmenter en plusieurs section 
des routes ou rue. C'est vite ingérable et pourtant j'ai tout le 
réseau en tête.
Pour les giratoire c'est totalement inutile de les segmenter sauf cas 
très très particulier. Le routage fonctionne très bien tel quel.


Avec les restrictions de vitesse, bande cyclable et autre info 
(trottoir, revêtement, éclairage) ça multiplie les découpes


Malheureusement je ne vois aucune solutions pour éviter cela.

Le September 1, 2020 9:44:37 AM UTC, Christian Rogel 
 a écrit :


Le 1 sept. 2020 à 11:25, Yves P.  a
écrit : Je tombe sur des itinéraires vélos, bus… qui passent
par des ronds-points. Ces derniers sont coupés en petits
morceaux pour avoir un bel itinéraire. Ça part d'une bonne
intention (j'ai fait la même chose au début), mais c'est
ingérable ! S'il vous plait ne serez pas le sécateur quand
vous croisez un giratoire. Merci pour lui et son intégrité  




Déjà mentionné, mais, j’approuve cette piqûre de rappel. Il faut pour agir 
ainsi, soit appartenir à la team 1er degré, soit être certain que le RP est 
positionné correctement. Et surtout au bon diamètre.
Eh, bien, non, ça n’existe qu’au pays de Gaston Lagaffe.
Plusieurs fois, j’ai rétabli l’intégrité et, par respect pour les autres 
contributeurs, laissé dans l’état normal.

Christian R.


Il y a les pour et les contre les découpages des giratoires, je ne 
suis pas sûr que l'on arrive à un consensus.


Il y a quelque temps, j'avais fait une analyse des giratoires du 
département où j'habite et j'avais constaté que 16% étaient découpés 
(pas uniquement pour les bus) et qu'un tiers des giratoires découpés 
et traversés par des lignes de bus avaient les relations routes en 
erreur. E cela empirait avec le temps.


Maintenant, si je crée une ligne qui n'a pas encore de relation route, 
je ne met que les arrêts dans l'ordre.


cordialement

leni



___
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] Rond point et relations routes

2020-09-02 Par sujet Yves P. 
> Il y a les pour et les contre les découpages des giratoires, je ne suis pas 
> sûr que l'on arrive à un consensus.
> 

Quel est l'intérêt de découper un giratoire ?

Il y a un cas particulier cité sur la liste vélosm qui "nécessite" un découpage.
Ça reste l'exception, donc (à vu de nez) 99% des giratoires ne devraient pas 
être découpés.

Et encore, si on indique que tout le giratoire à une bande cyclable (alors que 
c'est uniquement une section) les logiciels de routage pour vélo devraient 
fonctionner quand même.
C'est juste le rendu qui poserait problème (comme Waymarked Trails actuellement 
qui colorie tout le rond-point).


> un tiers des giratoires découpés et traversés par des lignes de bus avaient 
> les relations routes en erreur. Et cela empirait avec le temps.
> 
Les relations de lignes de bus étaient déjà bien cassées :(


> Maintenant, si je crée une ligne qui n'a pas encore de relation route, je ne 
> met que les arrêts dans l'ordre.
> 
C'est encore plus radical que ce que je proposais :D
Mais au moins, ça évite les prises de tête.

Par contre, il n'y a plus de rendu du trajet exacte, mais en a t'on vraiment 
besoin pour les bus ??

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

Re: [OSM-talk-fr] Attribution eaupotable.info

2020-09-02 Par sujet Philippe Verdy 
S'ils ne garantissent rien eux-mêmes, le minimum qu'ils puissent faire
c'est tracer et identifier leurs sources pour savoir d'où ca vient et
comment corriger. S'ils ne le font pas, c'est leur responsabilité directe,
ils peuvent mettre n'importe quoi, n'importe comment, juste pour "faire du
chiffre" et faire croire qu'ils sont une ressource utile (voire
indispensable) ayant une autorité quelconque (par exemple pour utiliser
cela et obtenir des subventions indues même s'ils n'ont aucune expertise ni
aucun processus qualité).

Il vaut mieux une petite source incomplète mais fiable qui peut ensuite
coopérer et échanger avec d'autres petites sources capables de se faire
confiance entre elles et s'accorder du crédit (et sinon ayant des moyens de
contact, un "guichet" d'échange et un système de suivi (ne serait-ce qu'un
dépot GitHub ou similaire, ou une simple feuille de calcul, un forum en
ligne avec archives et un peu de classement possible).

Là ce site me semble totalement fermé et comme n plus il ignore le
minimum légal, ça pose des questions sur son sérieux.

Le mer. 2 sept. 2020 à 16:57, European Water Project <
europeanwaterproj...@gmail.com> a écrit :

> Salut Vincent,
>
> Je reste dubitatif sur le site en lui même qui se nomme eaupotable et
> qui en bas de page signale " Warning: We are unable to guarantee the
> drinkability of the water. Most springs listed are known to be safe, but
> few are regularly checked. "
>
> > Je trouve qu'ils ont raison de signaler qu'ils ne peuvent en aucun
> cas garantir la qualité de l'eau de chaque fontaine.  Notre "disclaimer" va
> pas mal dans le même sens.
>
> A bientôt,
>
> Stuart
>
>
>
> On Wed, 2 Sep 2020 at 09:24, Vincent Bergeot  wrote:
>
>> Le 19/07/2018 à 08:44, Vincent Bergeot a écrit :
>> > Le 11/07/2018 à 09:37, Vincent Bergeot a écrit :
>> >> Le 11/07/2018 à 09:12, Johnparis a écrit :
>> >>> https://eaupotable.info/en/contact/
>> >>
>> >> merci, je leur signale :)
>> >
>> > pour suivi, aucune réponse
>>
>> interpellé sur twitter
>> (https://twitter.com/spoutnik/status/1301014314736742400, ben oui 2 ans,
>> comme quoi les archives publiques c'est bien !!!) j'ai de nouveau
>> utilisé la page contact pour dire que
>> (https://eaupotable.info/en/fr-france) semblait en accord avec
>> https://www.openstreetmap.org/copyright.
>>
>> Je reste dubitatif sur le site en lui même qui se nomme eaupotable et
>> qui en bas de page signale " Warning: We are unable to guarantee the
>> drinkability of the water. Most springs listed are known to be safe, but
>> few are regularly checked. "
>>
>> Et coté données, non utilisable (du moins je n'ai trouvé aucune licence)
>> et la création de nouveau point se fait en utilisant google
>> (https://eaupotable.info/en/create) ce qui doit d'autant plus
>> restreindre une éventuelle licence.
>>
>> pour suivi, puisque qu'un tweet est apparu :)
>>
>>
>> --
>> Vincent Bergeot
>>
>>
>> ___
>> 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] Rond point et relations routes

2020-09-02 Par sujet leni 


Le 01/09/2020 à 18:23, Gad Jo a écrit :
Pour avoir mis en place l'ensemble du réseau de bus sur Narbonne c'est 
la mort dans l'âme que j'ai du segmenter en plusieurs section des 
routes ou rue. C'est vite ingérable et pourtant j'ai tout le réseau en 
tête.
Pour les giratoire c'est totalement inutile de les segmenter sauf cas 
très très particulier. Le routage fonctionne très bien tel quel.


Avec les restrictions de vitesse, bande cyclable et autre info 
(trottoir, revêtement, éclairage) ça multiplie les découpes


Malheureusement je ne vois aucune solutions pour éviter cela.

Le September 1, 2020 9:44:37 AM UTC, Christian Rogel 
 a écrit :


Le 1 sept. 2020 à 11:25, Yves P.  a
écrit : Je tombe sur des itinéraires vélos, bus… qui passent
par des ronds-points. Ces derniers sont coupés en petits
morceaux pour avoir un bel itinéraire. Ça part d'une bonne
intention (j'ai fait la même chose au début), mais c'est
ingérable ! S'il vous plait ne serez pas le sécateur quand
vous croisez un giratoire. Merci pour lui et son intégrité  




Déjà mentionné, mais, j’approuve cette piqûre de rappel. Il faut pour agir 
ainsi, soit appartenir à la team 1er degré, soit être certain que le RP est 
positionné correctement. Et surtout au bon diamètre.
Eh, bien, non, ça n’existe qu’au pays de Gaston Lagaffe.
Plusieurs fois, j’ai rétabli l’intégrité et, par respect pour les autres 
contributeurs, laissé dans l’état normal.

Christian R.


Il y a les pour et les contre les découpages des giratoires, je ne suis 
pas sûr que l'on arrive à un consensus.


Il y a quelque temps, j'avais fait une analyse des giratoires du 
département où j'habite et j'avais constaté que 16% étaient découpés 
(pas uniquement pour les bus) et qu'un tiers des giratoires découpés et 
traversés par des lignes de bus avaient les relations routes en erreur. 
E cela empirait avec le temps.


Maintenant, si je crée une ligne qui n'a pas encore de relation route, 
je ne met que les arrêts dans l'ordre.


cordialement

leni


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

Re: [OSM-talk-fr] [SDIS/SAMU] Projet du mois défibrillateurs

2020-09-02 Par sujet Jacques Lavignotte 

Merci Adrien.

J.

Le 02/09/2020 à 18:27, PanierAvide a écrit :

Pour l'argumentaire, tu peux reprendre ce qui est présent dans l'article :

- Diffuser l'info au plus grand nombre : plus les localisations 
ressortent dans diverses applis, plus il y a de chances d'avoir l'info 
au bon moment


- Contrainte légale : les propriétaires ont obligation de déclarer, info 
qui finit dans une base nationale ouverte, donc pas de problèmes "légal" 
à diffuser une base de DAE sous licence ouverte ou ODBL


- Possibilité de bénéficier de retours de la communauté sur les données 
libérées : DAE constatés déplacés sur le terrain, absents...


Cordialement,

Adrien P.

Le 02/09/2020 à 18:18, Jacques Lavignotte a écrit :



Le 02/09/2020 à 15:05, PanierAvide a écrit :

Bonjour,

C'est à tenter, de préférence par les contacts locaux.


C'est le S(D)IS (D comme département) 86 Je sais qu'ils ont une liste 
et un système de cartographie.


 De mon côté j'ai
fait les 4 SDIS de Bretagne, deux toujours en attente et les deux 
autres n'avaient pas


Pas de recencement des DAE ?

 (c'est le SAMU qui a et ça n'a pas été ouvert). Sur la
base de ça, je dirais plutôt tenter les SAMU, 


Je n'ai aucun indice sur le SAMU 86 mais peut-être une piste sur SAMU 
79 qui fait la promo de Sauv'Life.



::
Argumentaire ??
::

 En plus de leur signaler ce "Projet du mois" quels seraient les 
arguments à avancer pour les inciter à collaborer ?

J'ai les coordonnées d'un officier.


Adrien P.


Jacques


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


--
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] [SDIS/SAMU] Projet du mois défibrillateurs

2020-09-02 Par sujet PanierAvide 

Pour l'argumentaire, tu peux reprendre ce qui est présent dans l'article :

- Diffuser l'info au plus grand nombre : plus les localisations 
ressortent dans diverses applis, plus il y a de chances d'avoir l'info 
au bon moment


- Contrainte légale : les propriétaires ont obligation de déclarer, info 
qui finit dans une base nationale ouverte, donc pas de problèmes "légal" 
à diffuser une base de DAE sous licence ouverte ou ODBL


- Possibilité de bénéficier de retours de la communauté sur les données 
libérées : DAE constatés déplacés sur le terrain, absents...


Cordialement,

Adrien P.

Le 02/09/2020 à 18:18, Jacques Lavignotte a écrit :



Le 02/09/2020 à 15:05, PanierAvide a écrit :

Bonjour,

C'est à tenter, de préférence par les contacts locaux.


C'est le S(D)IS (D comme département) 86 Je sais qu'ils ont une liste 
et un système de cartographie.


 De mon côté j'ai
fait les 4 SDIS de Bretagne, deux toujours en attente et les deux 
autres n'avaient pas


Pas de recencement des DAE ?

 (c'est le SAMU qui a et ça n'a pas été ouvert). Sur la
base de ça, je dirais plutôt tenter les SAMU, 


Je n'ai aucun indice sur le SAMU 86 mais peut-être une piste sur SAMU 
79 qui fait la promo de Sauv'Life.



::
Argumentaire ??
::

 En plus de leur signaler ce "Projet du mois" quels seraient les 
arguments à avancer pour les inciter à collaborer ?

J'ai les coordonnées d'un officier.


Adrien P.


Jacques


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

Re: [OSM-talk-fr] [SDIS/SAMU] Projet du mois défibrillateurs

2020-09-02 Par sujet Jacques Lavignotte 



Le 02/09/2020 à 15:05, PanierAvide a écrit :

Bonjour,

C'est à tenter, de préférence par les contacts locaux.


C'est le S(D)IS (D comme département) 86 Je sais qu'ils ont une liste et 
un système de cartographie.


 De mon côté j'ai
fait les 4 SDIS de Bretagne, deux toujours en attente et les deux autres 
n'avaient pas


Pas de recencement des DAE ?

 (c'est le SAMU qui a et ça n'a pas été ouvert). Sur la
base de ça, je dirais plutôt tenter les SAMU, 


Je n'ai aucun indice sur le SAMU 86 mais peut-être une piste sur SAMU 79 
qui fait la promo de Sauv'Life.



::
Argumentaire ??
::

 En plus de leur signaler ce "Projet du mois" quels seraient les 
arguments à avancer pour les inciter à collaborer ?

J'ai les coordonnées d'un officier.


Adrien P.


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] maxspeed par défaut

2020-09-02 Par sujet Percherie OnDaNet 

Nickel je l'avais en tête mais je ne l'ai pas retrouvé sur le wiki

comme cela plus besoin de modifier le 80 en autre chose si la loi 
change. Si au niveau local le 80 à sauté, c'est obligatoirement un 
explicite avec signalisation verticale via source:maxspeed=sign


Pour ne plus y retoucher la combinaison maxspeed=FR:urban + 
source:maxspeed=FR:urban fonctionne bien.
Pour les sections à deux voies mieux vaut utiliser maxspeed=90 + 
source:maxspeed=sign ça lève tout ambiguïté et risque de faux positif. 
Exemple si un contributeur à indiqué 2 voie en ayant en tête "deux sens 
= deux voies". C'est souvent une erreur de débutant qui risque de 
générer des erreurs sur le routage.


En résumé, tout en automatique sauf si on n'est pas à 80 km/h.

Y a tellement de cas particulier qu'on pourrait en discuter encore 
quelques jours ;-)



Le 02/09/2020 à 10:34, Frédéric Rodrigo a écrit :

Le 02/09/2020 à 07:16, Gad Jo a écrit :
Préfère source:maxspeed=FR:urban + maxspeed=80 pour définir partout 
où la vitesse est à 80. Cela permettra facilement de modifier en 
masse les vitesses si on change les vitesses au niveau du pays 
(diminution à 70 ou rétablissement à 90)


Quand la vitesse est implicite, il y encore plus générique que mettre 
explicitement la vitesse. Mais plutôt :


maxspeed=FR:urban


Frédéric.




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

Re: [OSM-talk-fr] Attribution eaupotable.info

2020-09-02 Par sujet European Water Project 
Salut Vincent,

Je reste dubitatif sur le site en lui même qui se nomme eaupotable et
qui en bas de page signale " Warning: We are unable to guarantee the
drinkability of the water. Most springs listed are known to be safe, but
few are regularly checked. "

> Je trouve qu'ils ont raison de signaler qu'ils ne peuvent en aucun
cas garantir la qualité de l'eau de chaque fontaine.  Notre "disclaimer" va
pas mal dans le même sens.

A bientôt,

Stuart



On Wed, 2 Sep 2020 at 09:24, Vincent Bergeot  wrote:

> Le 19/07/2018 à 08:44, Vincent Bergeot a écrit :
> > Le 11/07/2018 à 09:37, Vincent Bergeot a écrit :
> >> Le 11/07/2018 à 09:12, Johnparis a écrit :
> >>> https://eaupotable.info/en/contact/
> >>
> >> merci, je leur signale :)
> >
> > pour suivi, aucune réponse
>
> interpellé sur twitter
> (https://twitter.com/spoutnik/status/1301014314736742400, ben oui 2 ans,
> comme quoi les archives publiques c'est bien !!!) j'ai de nouveau
> utilisé la page contact pour dire que
> (https://eaupotable.info/en/fr-france) semblait en accord avec
> https://www.openstreetmap.org/copyright.
>
> Je reste dubitatif sur le site en lui même qui se nomme eaupotable et
> qui en bas de page signale " Warning: We are unable to guarantee the
> drinkability of the water. Most springs listed are known to be safe, but
> few are regularly checked. "
>
> Et coté données, non utilisable (du moins je n'ai trouvé aucune licence)
> et la création de nouveau point se fait en utilisant google
> (https://eaupotable.info/en/create) ce qui doit d'autant plus
> restreindre une éventuelle licence.
>
> pour suivi, puisque qu'un tweet est apparu :)
>
>
> --
> Vincent Bergeot
>
>
> ___
> 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] [SDIS] Projet du mois défibrillateurs : c'est parti !

2020-09-02 Par sujet PanierAvide 

Bonjour,

C'est à tenter, de préférence par les contacts locaux. De mon côté j'ai 
fait les 4 SDIS de Bretagne, deux toujours en attente et les deux autres 
n'avaient pas (c'est le SAMU qui a et ça n'a pas été ouvert). Sur la 
base de ça, je dirais plutôt tenter les SAMU, mais ça dépend peut-être 
des régions.


Cordialement,

Adrien P.

Le 02/09/2020 à 14:40, Jacques Lavignotte a écrit :

Bonjour,

essayer de collaborer avec le SDIS local est-il un axe sur ce projet 
ou est-ce vain du fait des concurrences entre les services d'urgence ?


J.






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

Re: [OSM-talk-fr] maxspeed par défaut

2020-09-02 Par sujet Jérôme Seigneuret 
implicite en rural dépend du nombre de voies sauf cas mentionné avec des
panneaux. Maintenant des département ont et vont remettre à 90km des
départementale. CF:
http://www.departements.fr/loi-mobilite-promulguee-retour-aux-90-kmh-possible-conditions

Donc avec c'est 80km par sens en voie unique. Sinon pour toute double voies
c'est 90km (implicite)
Le relèvement des voies de 10km doit être motivé. Donc avec panneaux
(explicite)

A+

Le mer. 2 sept. 2020 à 10:54,  a écrit :

> +0,9 ;-)
>
> > - sauf sur certaines portions de départementale dans certains
> départements
>
> Non, je crois que ça c'est une exception *explicite* car on a la liste et
> ça va figurer sur le terrain (je suppose). L'implicite c'est ce que dit le
> code de la route.
>
> En général dans les cas indiqués il y a des panneaux 90.
>
> > - On peut imaginer une route à double-sens avec un terre-plein
> temporaire pour un carrefour. Ce n'est pas pour autant que le long du
> terre-plein, la limite va passer à 90 km/h.
>
> En théorie tu as raison. En pratique
> ... Je ne sais si un gars a
> eu une offre spéciale pour réutiliser les anciens panneaux !
>
> Je réserve le source:maxspeed=FR:rural au 80. Les autres ça va être du
> source:maxspeed=sign.
>
> Jean-Yvon
> Le 02/09/2020 à 10:33, Eric SIBERT via Talk-fr - talk-fr@openstreetmap.org
> a écrit :
>
> +1 avec les avis précédents: en extra-urbain, l'implicite est devenu
> tellement incompréhensible qu'il vaut mieux coder explicitement.
>
> Par défaut c'est 80 km/h sur les chaussées à double sens:
> - sauf sur certaines portions de départementale dans certains départements
> - sauf quand il y a un une voie supplémentaire pour faire un créneau de
> dépassement
> - pareil pour les routes pour automobile (panneau C107) à double-sens?
> - On peut imaginer une route à double-sens avec un terre-plein temporaire
> pour un carrefour. Ce n'est pas pour autant que le long du terre-plein, la
> limite va passer à 90 km/h.
>
> Donc l'implicite est difficile à expliquer à l'humain et à l'ordinateur.
> Je ne sais même plus ce qu'il faut mettre pour source:maxspeed dans ces cas
> là.
>
> Eric
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [SDIS] Projet du mois défibrillateurs : c'est parti !

2020-09-02 Par sujet Jacques Lavignotte 

Bonjour,

essayer de collaborer avec le SDIS local est-il un axe sur ce projet ou 
est-ce vain du fait des concurrences entre les services d'urgence ?


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] maxspeed par défaut

2020-09-02 Par sujet osm . sanspourriel 

+0,9 ;-)

> - sauf sur certaines portions de départementale dans certains
départements

Non, je crois que ça c'est une exception *explicite* car on a la liste
et ça va figurer sur le terrain (je suppose). L'implicite c'est ce que
dit le code de la route.

En général dans les cas indiqués il y a des panneaux 90.

> - On peut imaginer une route à double-sens avec un terre-plein
temporaire pour un carrefour. Ce n'est pas pour autant que le long du
terre-plein, la limite va passer à 90 km/h.

En théorie tu as raison. En pratique
... Je ne sais si un gars a
eu une offre spéciale pour réutiliser les anciens panneaux !

Je réserve le source:maxspeed=FR:rural au 80. Les autres ça va être du
source:maxspeed=sign.

Jean-Yvon

Le 02/09/2020 à 10:33, Eric SIBERT via Talk-fr -
talk-fr@openstreetmap.org a écrit :

+1 avec les avis précédents: en extra-urbain, l'implicite est devenu
tellement incompréhensible qu'il vaut mieux coder explicitement.

Par défaut c'est 80 km/h sur les chaussées à double sens:
- sauf sur certaines portions de départementale dans certains
départements
- sauf quand il y a un une voie supplémentaire pour faire un créneau
de dépassement
- pareil pour les routes pour automobile (panneau C107) à double-sens?
- On peut imaginer une route à double-sens avec un terre-plein
temporaire pour un carrefour. Ce n'est pas pour autant que le long du
terre-plein, la limite va passer à 90 km/h.

Donc l'implicite est difficile à expliquer à l'humain et à
l'ordinateur. Je ne sais même plus ce qu'il faut mettre pour
source:maxspeed dans ces cas là.

Eric


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

Re: [OSM-talk-fr] maxspeed par défaut

2020-09-02 Par sujet Frédéric Rodrigo 

Le 02/09/2020 à 07:16, Gad Jo a écrit :
Préfère source:maxspeed=FR:urban + maxspeed=80 pour définir partout où 
la vitesse est à 80. Cela permettra facilement de modifier en masse 
les vitesses si on change les vitesses au niveau du pays (diminution à 
70 ou rétablissement à 90)


Quand la vitesse est implicite, il y encore plus générique que mettre 
explicitement la vitesse. Mais plutôt :


maxspeed=FR:urban


Frédéric.



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

Re: [OSM-talk-fr] maxspeed par défaut

2020-09-02 Par sujet Eric SIBERT via Talk-fr 
+1 avec les avis précédents: en extra-urbain, l'implicite est devenu 
tellement incompréhensible qu'il vaut mieux coder explicitement.


Par défaut c'est 80 km/h sur les chaussées à double sens:
- sauf sur certaines portions de départementale dans certains 
départements
- sauf quand il y a un une voie supplémentaire pour faire un créneau de 
dépassement

- pareil pour les routes pour automobile (panneau C107) à double-sens?
- On peut imaginer une route à double-sens avec un terre-plein 
temporaire pour un carrefour. Ce n'est pas pour autant que le long du 
terre-plein, la limite va passer à 90 km/h.


Donc l'implicite est difficile à expliquer à l'humain et à l'ordinateur. 
Je ne sais même plus ce qu'il faut mettre pour source:maxspeed dans ces 
cas là.


Eric


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

Re: [OSM-talk-fr] Les courée de Roubaix : adresse et entrée

2020-09-02 Par sujet osm . sanspourriel 

Bonjour,

Le 02/09/2020 à 09:18, Denis Chenu via Talk-fr -
talk-fr@openstreetmap.org a écrit :

L'accès aux courées est en accès libre (aux piétons) en grosse
majorité. Donc ce ne sont pas des types "appartement" , celle que je
connais ont bien leur propre boite au lettre à la porte par exemple :
le facteur doit entrer dans la courée.
L'adresse officielle de la rue semble être le nom de la courée, mais
dans les faits : sur les courriers : il ya intérêt à indiquer la rue
principale si le facteur est en vacances ou est malades par exemple.

Sinon : l'entrée de la courée : bonne ou mauvaise idée ?


Si les boîtes-aux-lettres sont au niveau de chaque maison, alors une
courée c'est clairement une associatedStreet.

L'entrée de la courée, c'est comme déjà dit le point d'accès, AMHA ça
n'en fait pas partie mais ça se discute.

L'entrée de la courée, c'est à mettre au niveau de la rue d'accès (pas
la courée).

A mettre ou pas mais comme ça figure sur le terrain, je dirais à mettre.

Je fais l'hypothèse qu'un facteur remplaçant saura utiliser un plan,
dérivé d'OSM par exemple, pour localiser les courées et leurs entrées.

Dans ton exemple on voit qu'il y a deux entrées, je suppose que le
facteur va parcourir la courée une seule fois et non deux demies fois
aller retour. Et donc le numéro sur la rue principale ne sera pas celui
qui figurerait sur la seconde ligne de rue mais celui qui l'arrange.
L'un ou l'autre. Il entrera par un ressortira par l'autre.

Jean-Yvon



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

Re: [OSM-talk-fr] Fwd: Des nouvelles de transport.data.gouv.fr ! | Info-lettre Août 2020

2020-09-02 Par sujet Vincent Bergeot 

Merci Yves,
à noter pour expliquer peut-être la diffusion sur la liste qu'il est 
explicitement fait référence à OSM, je cite :


"un travail d'investigation a été mené sur les données de stationnement 
vélo. A partir de l'analyse des données locales publiées sur de nombreux 
portails et des données présentes sur OpenStreetMap, un schéma de 
données a été proposé pour standardiser la publication de ce type de 
données. Un espace de discussion a été créé sur le projet Github de 
schema.data.gouv.fr. Nous vous encourageons vivement à regarder ce 
schéma et proposer des modifications si nécessaire !"



Vincent


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

Re: [OSM-talk-fr] Attribution eaupotable.info

2020-09-02 Par sujet Vincent Bergeot 

Le 19/07/2018 à 08:44, Vincent Bergeot a écrit :

Le 11/07/2018 à 09:37, Vincent Bergeot a écrit :

Le 11/07/2018 à 09:12, Johnparis a écrit :

https://eaupotable.info/en/contact/


merci, je leur signale :)


pour suivi, aucune réponse


interpellé sur twitter 
(https://twitter.com/spoutnik/status/1301014314736742400, ben oui 2 ans, 
comme quoi les archives publiques c'est bien !!!) j'ai de nouveau 
utilisé la page contact pour dire que 
(https://eaupotable.info/en/fr-france) semblait en accord avec 
https://www.openstreetmap.org/copyright.


Je reste dubitatif sur le site en lui même qui se nomme eaupotable et 
qui en bas de page signale " Warning: We are unable to guarantee the 
drinkability of the water. Most springs listed are known to be safe, but 
few are regularly checked. "


Et coté données, non utilisable (du moins je n'ai trouvé aucune licence) 
et la création de nouveau point se fait en utilisant google 
(https://eaupotable.info/en/create) ce qui doit d'autant plus 
restreindre une éventuelle licence.


pour suivi, puisque qu'un tweet est apparu :)


--
Vincent Bergeot


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

Re: [OSM-talk-fr] Prendre les escaliers à vélo

2020-09-02 Par sujet Simon Réau 
Bonjour,

Chez Geovelo nous interprétons de la même manière que toi. Escalier
interdit sauf si bicycle=yes ou ramp:bicycle=yes. Peut être peux tu les
contacter pour qu'il modifie leur algo.

Simon REAU
GEOVELO
www.geovelo.fr
simon.r...@geovelo.fr
Tél : 06 77 15 59 86
1 Impasse du Palais, 37000 Tours 




Le sam. 29 août 2020 à 10:59, blef  a écrit :

> Les "bandes roulables à côté sans marches" sont (ou devraient être)
> taguées avec l'attribut ramp:bicycle=yes
> 
> Mais les routeurs en question ne se limitent pas à ces (rares) cas pour
> créer leurs itinéraires.
>
> Le 28/08/2020 à 23:32, Philippe Verdy a écrit :
>
> Sauf les escaliers à marches près  peu pentues et pas trop hautes (pas
> plus que les ralentisseurs sur les rues ou aires de parking) ou ceux qui
> disposent d'une bande roulable à côté sans marches et de zones planes
> d'arrêt. Assimilables aux voies (lanes) sur les rues/routes (highways=*
> aussi) s'il n'y a pas de réelle séparation physique entre l'escalier piéton
> et la bande roulante, et donc pas forcément détaillés par des "ways" OSM
> séparés.
>
>
> Le ven. 28 août 2020 à 18:44, blef  a écrit :
>
>> Bonjour,
>>
>> Je m'aperçois qu'en faisant une recherche d'itinéraire en mode vélo, que
>> ce soit avec GraphHopper ou OSRM, on m'envoie sans vergogne sur des
>> escaliers.
>> Pourtant, d'après le wiki
>> , le tag
>> highway=steps implique access=no + foot=yes, donc implicitement bicycle=no,
>> ce qui me semble normal, moi qui n'ai pas pour habitude de descendre (ou
>> monter) les escaliers à vélo!
>> Me confirmez vous que le tag highway=steps ne nécessite pas d'ajouter
>> bicycle=no et donc que les routeurs n'appliquent pas correctement les
>> conditions d'accès dans ce cas?
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://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] Les courée de Roubaix : adresse et entrée

2020-09-02 Par sujet Denis Chenu via Talk-fr 
Bonjour,

Sur le libellé «officiel», ce n'est pas constant.

Exemple avec
- 595121761Y :
1. libellé BANO : DESCHAMPS 19 BD DE METZ (j'ai indiqué "Cours
Deschamps, 19 Boulevard de Metz", faut que j'enlève le s de Cours). 2
entrée différentes pour la même cour (en fait 2 voies spéarées)
2. libellé BAN (ban-housenumber-a9713453c5374037b02b147efd833360) Nom du
groupe : COUR DESCHAMPS, le BANO est placé juste à coté sur
https://guichet-adresse.ign.fr/map/ (doublon)
3. Cadastre "Cour Descamp"
- 595122353S
1. libellé BANO "GHESQUIERES RUE DE LA VIGN", j'ai indiqué "Cour
Ghesquieres, 71 bis Rue de la Vigne"
2. libellé BAN (ban-group-fdbe969afb5d46e79fb93652e15c5309) Nom du
groupe : "COUR GHESQUIERES"
3. Cadastre "Cour Ghesquieres Vanderbroeck"
- 595122362B
1. Libellé BANO "CRS GOVAERE RUE DE L EPEULE", j'ai indiqué "Cour
Govaere, Rue de l'Épeule"
2. BAN : "COUR GOVAERE"
3. Cadastre : "Cour Govaere"

En général : les panneaux à l'entrée indique : le nom de la courée, et
certaines fois le numéro de la rue principale. Si la cour Ghesquieres
posséde une porte : c'est exceptionnel.
La majorité c'est comme https://www.openstreetmap.org/way/842114374 (125
rue de l'épeule, cour Govaere, BANO 595122362B) : panneau nom + numéro
rue sur entrée libre sans porte.

L'accès aux courées est en accès libre (aux piétons) en grosse majorité.
Donc ce ne sont pas des types "appartement" , celle que je connais ont
bien leur propre boite au lettre à la porte par exemple : le facteur
doit entrer dans la courée.
L'adresse officielle de la rue semble être le nom de la courée, mais
dans les faits : sur les courriers : il ya intérêt à indiquer la rue
principale si le facteur est en vacances ou est malades par exemple.

Sinon : l'entrée de la courée : bonne ou mauvaise idée ?

Denis


Le 02/09/2020 à 05:38, Philippe Verdy a écrit :
> J'aurais tendance aussi à faire de ces courées des rues à part (pour
> leurs propres adresses habitables, pas pour leur simple accès comme le
> 76 rue du Caire, qui continue à faire partie de la rue du Caire mais
> n'est pas une habitation ou une réelle adresse de résidence, leur seul
> "intérêt étant leur porte d'accès (s'il y en a une).
>
> Du moins si ces courées ont un statut public officialisé dans le
> cadastre ou FANTOIR, ce sont des "rues" par elle-même même si elles
> sont uniquement piétonnes et pas accessibles aux véhicules (hors 2
> roues mais pas pour y rouler).
>
> Si la courée est privée (c'est une copropriété) alors ces adresses
> internes sont comme des numéros d'appartement dans un même immeuble ou
> un ensemble d'immeubles autour d'une partie commune: c'est une
> numérotation interne  (j'ai vécu dans un tel immeuble avec des parties
> communes dont une cour partagée en copropriété aussi par deux maisons
> individuelles non accessibles directement depuis la voie publique mais
> ayant un droit de passage permanent par l'immeuble et leurs boites au
> lettres étaient groupées dans l'immeuble avec celles des appartement,
> le courrier ne mentionnait qu'un seul numéro, les numéros de
> porte/d'appartement étaient optionnels, ce qui compte c'était le nom
> du destinataire sur la boite au lettre mentionnant ensuite l'étage ou
> l'emplacement via la cour commune)
>
> Sur une adresse postale, mettre les deux lignes c'est comme indiquer
> le chemin à suivre avec un point intermédiaire sur une autre rue que
> le point d'arrivée. Mais ça ressemble tout autant à mentionner un
> numéro d'appartement dur une ligne supplémentaire avant l'adresse sur
> la rue publique: le critère de distinction semble être la présence ou
> pas dans le FANTOIR, qui ne détaille pas en principe les copropriétés
> (mais il peut y avoir d'anciennes voies publiques privatisées en
> copropriétés (avec l'accord des propriétaires et après accord et vente
> par la collectivité, et la formation appropriée de la structure légale
> de gestion de la copropriété qui sera taxée) souhaitant sécuriser un
> accès et aménager des installations communes protégées et entretenues
> (cour, jardin, local technique, garage, etc.)
>
> Le mar. 1 sept. 2020 à 22:23,  > a écrit :
>
> J'aurais tendance à voir ça comme une rue à part.
>
> Mais pour la double adresse, addr:full est la solution "crade"
> répondant au besoin.
>
> Si tu considères que c'est ici le 76 rue du Caire, tu le mets dans
> l'associatedStreet de la rue du Caire.
>
> Pour les X Cour Saint Henri, 76 Rue du Caire (ou un autre numéro
> pour l'autre entrée), tu pourrais mettre addr:flats
>  pour les numéros.
>
> Peut-être addr:place
>  pour
> "Saint Henri".
>
> Et donc pas d'associatedStreet pour ces cours car il n'y a pas
> d'associatedStreet pour les place=.
>
> addr:unit  me
> semble préférable.
>
> Du coup tu mettrais ici :
>
>

Re: [OSM-talk-fr] Rond point et relations routes

2020-09-02 Par sujet Jean-Christophe Becquet 
Le 01/09/2020 à 19:13, Georges Dutreix via Talk-fr a écrit :
> J'ai souvent découpé des giratoires pour des lignes de bus : honte sur moi !
> Promis, je ne le ferai plus ;-)
> 
> Peut-être faudrait-il décrire les bonnes pratiques, pour les naïfs comme
> moi, dans des pages comme https://wiki.openstreetmap.org/wiki/FR:Bus
> ou
> https://wiki.openstreetmap.org/wiki/FR:Relation:route#Les_itin.C3.A9raires_de_bus_et_les_ronds-points

Bonjour,

Moi aussi, il m'est arrivé de découper des ronds points pour décrire des
itinéraires cyclables. Je lis donc avec intérêt cette discussion pour
les prochaines fois.

Bonne journée

JCB
-- 
WLM : le concours mondial de photos libres Wiki Loves Monuments
http://www.apitux.org/index.php?2016/02/03/252-wlm-le-concours-mondial-de-photos-libres-wiki-loves-monuments

==APITUX : le choix du logiciel libre==

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

===

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

Re: [OSM-talk-fr] maxspeed par défaut

2020-09-02 Par sujet Topographe Fou 
  Bonjour,Suis entièrement d'accord pour source:maxspeed + maxspeed , cela représente bien la réalité et est explicite ce qui est toujours plus clair. En plus c'est un binôme qui peut aider à détecter des incohérences (je crois même me souvenir qu'il existe une analyse Osmose sur ce point) et donc erreurs de saisies ou évolutions du code de la route comme expliqué précédemment. Personnellement je saisie toujours un maxspeed explicite et agrémente occasionnellement d'un source:maxspeedPar ailleurs sémantiquement parlant le préfixe source:x n'a pas de sens pour moi si le tag x n'a pas été défini. Le préfixe source: dénote de l'origine d'un tag avant de dénoter sa valeur. C'est ma compréhension, laquelle peut être contestée. Mais c'est aussi le sens de la première phrase de description du wiki :The source:maxspeed=* tag records the source of a road's maximum speed limit as provided in the maxspeed=* tag to assist with verifiability and maintenance.  LeTopographeFou   De: perche...@toutenkamion.netEnvoyé: 2 septembre 2020 7:17 AMÀ: talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: Re: [OSM-talk-fr] maxspeed par défaut  J'envisage plutôt l'inverse en anticipant un énième changement de règle au niveau national. Mieux vaut prévenir que guérir. Cela facilitera les corrections en masse si on indique la source.Préfère source:maxspeed=FR:urban + maxspeed=80 pour définir partout où la vitesse est à 80. Cela permettra facilement de modifier en masse les vitesses si on change les vitesses au niveau du pays (diminution à 70 ou rétablissement à 90)Pour tout les autres cas même les portions où c'est sur tout un département que les routes sont repassée à 90, indique une autre source comme source:maxspeed=sign ou source:maxspeed=FR:zone** (souvent 30, parfois 20 ou 50) quand les mairies n'utilise pas les panneaux zone de rencontre ou limitation 50 pour les lotissement hors agglo.Plus d'info et exemple sur https://wiki.openstreetmap.org/wiki/FR:Key:source:maxspeedLe September 1, 2020 11:15:53 PM UTC, Yannick  a écrit :
Le 02/09/2020 à 00:51, Marc Mongenet a écrit :Bonjour,Près de chez moi passe la route D 903 avec une succession de portionsà accès réglementé en 2x2 voies séparées(https://www.openstreetmap.org/way/825204700), à 2+1 voies(https://www.openstreetmap.org/way/24205655), à 1+1 voies(https://www.openstreetmap.org/way/6069166), à 1+1 voies séparées(https://www.openstreetmap.org/way/654772946), sans compter les voiesd'insertion, etc.De nombreuses portions ont une limite de vitesse implicite car il n'ya pas de panneau limitant la vitesse, et les règles généraless'appliquent (R413-2). Le problème est que ces règles sont malconnues, et presque tout a été mal mappé avec maxspeed=80. Pourl'instant j'ai supprimé ce qui était faux.Mais est-ce que ça vaut la peine de mapper les limitations par défaut?Informatiquement parlant, ça me semble profondément contre-productif:c'est le boulot de l'ordinateur de calculer cela. Sauf qu'il faut toutde même taguer qqch pour faire la différence entre une route demaxspeed inconnue, et une route de maxspeed implicite. Ma question estdonc:Est-ce qu'utiliser source:maxspeed=FR:rural sans maxspeed=* est unebonne pratique?PS: Les règles du code de la route sont si mal connues quehttps://wiki.openstreetmap.org/wiki/FR:Key:maxspeed#Limitation_de_vitessecontient une erreur de 20 km/h.Marc MongenetBonsoir,L'implicite est désormais quasi impossible à deviner. Prends lesnationales à 80 et des portions de départementales à 90. Je me mets à laplace de l'étranger pour qui c'est pire qu'un casse-tête chinois. Onfinit par ne plus savoir la limite en vigueur sur telle ou telle portionde route.Je suis donc partisan de mettre systématiquement le maxspeed=* au moinsc'est clairement renseigné sans équivoque possible.Amitiés-- 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