Re: [OSM-talk-fr] Motorroad sur Trunk en France

2020-01-26 Par sujet Florimond Berthoux 
Merci, vu le manque de réponse c'est bien indéfini en France.
Je me posais la question pour Cyclosm.org : la nouvelle version (fraîche de
ce soir) considère par défaut cyclable les Trunk et non cyclable s'il y a
motorroad=yes.
C'est la position visiblement la plus universelle.
Et ma position, un tag (highway) pour l'aspect et la hiérarchie dans le
réseau routier et un tag pour le côté l'égal du panneau, comme ça on évite
de mélanger les torchons et les serviettes et les moutons sont bien gardés.
Je pense changer cette petite phrase du wiki.

Le dim. 26 janv. 2020 à 20:54, Axel Listes  a écrit :

> Bonsoir,
>
> Le 25/01/2020 à 21:12, Florimond Berthoux a écrit :
> > Je suis tombé sur une phrase qui m'a étonné sur la page de la clé
> motorroad
> > du wiki
> > «France
> > This tag is not required, just use highway=trunk. »
> > https://wiki.openstreetmap.org/wiki/Key:motorroad?uselang=fr#France
> >
> > Et effectivement pas de traduction en français de la page, et sur la page
> > française de Trunk l'explication du tag est resté en anglais.
> >
> > Cette phrase me parait assez fausse parce qu'en France une motorroad ça a
> > un panneau voir
> > https://fr.wikipedia.org/wiki/Route_pour_automobiles#En_France
> > Le tag est très utilisé dans le pays des Trunk (Bretagne) et ailleurs.
> > Et pour ce qui me concerne j'ai l'exemple d'une voie rapide dont un
> premier
> > tronçon est cyclable puis un panneau "route pour automobile" après la
> > premier sortie, où le tag motorroad est fort utile.
> >
> > Alors, je corrige la page ?
>
> J'avais déjà lancé le sujet en 2014, au final il n'y a jamais eu de
> consensus.
>
> http://gis.19327.n8.nabble.com/highway-trunk-en-France-td5821793.html
>
> Si tu arrives à faire bouger les lignes, merci d'avance !
>
> Axel.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [OSM-talk-fr] Ajout de NRO : blocage d'un contributeur à envisager ?

2020-01-26 Par sujet deuzeffe 

Le 26/01/2020 à 22:27, François Lacombe a écrit :


Le dim. 26 janv. 2020 à 22:19, deuzeffe > a écrit :



Cépabien ^^
(dit celle qui ne taggue pas les name pour les points de distribution -
j'ai bon ? - en building pour ne pas qu'ils soient rendus :P)


Les sous-répartiteurs cuivre et certaines armoires fibre peuvent aussi 
avoir des noms d'usage.


Pour que tout le monde comprenne, on ne tague pas en building lorsque 
c'est une armoire parce que man_made=street_cabinet et building=* sont 
strictement incompatibles.


Vivi. J'avions bien compris, pas de souci*.

Mais le champ name= d'un "transfo." sur pole ou un street_cabinet ne 
sont pas rendus, alors que sur un building, oui. Et franchement, c'est 
très très bizarre à voir (genre le transfo. "Gendarmerie" à plus de 500m 
de la dite gendarmerie :/) Je suppose que tout champ name= est rendu par 
défaut ?


* : je t'en ai rajouté deux nouveaux en building nés fin 2019 ^^
--
deuzeffe

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

Re: [OSM-talk-fr] Ajout de NRO : blocage d'un contributeur à envisager ?

2020-01-26 Par sujet Romain MEHUT 
Bonsoir et merci François pour ces compléments.

Je n'ai pas vraiment le temps approfondir ce sujet des réseaux télécoms
mais c'est le fait de voir un tel objet avec un tag name qui m'a fait
"tiquer". C'est quand même le b-a-ba de ne pas taguer pour un rendu.

Pour cet exemple https://www.openstreetmap.org/node/7156119118 que je
pointais, tu es d'accord que les tags du polygone sont à corriger ?

Romain

Le dim. 26 janv. 2020 à 22:11, François Lacombe 
a écrit :

> Salut à tous,
>
> Eric est l'un des contributeurs les plus actifs sur les réseaux télécoms
> en France
> Je vais essayer de comprendre ce qu'il a essayer de faire. Nous échangeons
> souvent sur Twitter, il n'est pour moi pas question de bloquer un
> utilisateur comme lui.
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Ajout de NRO : blocage d'un contributeur à envisager ?

2020-01-26 Par sujet François Lacombe 
Le dim. 26 janv. 2020 à 22:19, deuzeffe  a écrit :

>
> Cépabien ^^
> (dit celle qui ne taggue pas les name pour les points de distribution -
> j'ai bon ? - en building pour ne pas qu'ils soient rendus :P)
>

Les sous-répartiteurs cuivre et certaines armoires fibre peuvent aussi
avoir des noms d'usage.

Pour que tout le monde comprenne, on ne tague pas en building lorsque c'est
une armoire parce que man_made=street_cabinet et building=* sont
strictement incompatibles.
Aucun technicien ne peut physiquement rentrer dans une armoire, un bâtiment
si.
Les sous-répartitions comme les nœuds de raccordement peuvent
indépendamment être en bâtiment ou en armoire, mais jamais les deux en même
temps, même si on dessine l'armoire comme un polygone.
Si le rendu veut les matérialiser aux zooms les plus forts, il utilisera
man_made=street_cabinet.

Voir les 1ere lignes de
https://wiki.openstreetmap.org/wiki/FR:Tag:man_made%3Dstreet_cabinet


> Peut être que quand les bases des opé seront en OD, on y verra plus clair
> ^^
>

En ce moment c'est précisément pour inciter les opérateurs à ouvrir leurs
données que nous ajoutons tous ces objets
Les comparaisons avec les référentiels internes montrent des différences
sensibles, parfois de plusieurs km, c'est un fait.
Ainsi la contribution peut les aider à corriger tout ça.

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

Re: [OSM-talk-fr] Ajout de NRO : blocage d'un contributeur à envisager ?

2020-01-26 Par sujet deuzeffe 

Le 26/01/2020 à 22:11, François Lacombe a écrit :

Salut à tous,


Pareil à toi,

Eric est l'un des contributeurs les plus actifs sur les réseaux télécoms 
en France
Je vais essayer de comprendre ce qu'il a essayer de faire. Nous 
échangeons souvent sur Twitter, il n'est pour moi pas question de 
bloquer un utilisateur comme lui.


Merci François.

Tous les noeuds de raccordement cuivre ont un nom d'usage, bien souvent 
le nom du quartier desservi ou la ville concernée.
Par ailleurs, name=NRO c'est taguer pour le rendu certes. J'ai moi aussi 
cette mauvaise habitude.


Cépabien ^^
(dit celle qui ne taggue pas les name pour les points de distribution - 
j'ai bon ? - en building pour ne pas qu'ils soient rendus :P)


Le sam. 25 janv. 2020 à 23:42, deuzeffe > a écrit :


Va falloir faire un sacré ménage :(

Oui c'est bien ce qui se manifeste ici
https://wiki.openstreetmap.org/wiki/FR:Tag:telecom%3Dexchange#Possibles_erreurs


Ce n'est pas à celui-là que je pensais mais au tag name=NRO de 
Trifouillis-les-oies


Peut être que quand les bases des opé seront en OD, on y verra plus clair ^^

--
deuzeffe

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

Re: [OSM-talk-fr] Ajout de NRO : blocage d'un contributeur à envisager ?

2020-01-26 Par sujet François Lacombe 
Salut à tous,

Eric est l'un des contributeurs les plus actifs sur les réseaux télécoms en
France
Je vais essayer de comprendre ce qu'il a essayer de faire. Nous échangeons
souvent sur Twitter, il n'est pour moi pas question de bloquer un
utilisateur comme lui.

Le sam. 25 janv. 2020 à 21:08, Romain MEHUT  a
écrit :

> Donc ce contributeur ajoute en grand nombre des "NRO". 1ère chose que je
> lui ai fait remarquer est qu'il n'y a pas lieu que ces objets aient un tag
> name.
>

Tous les noeuds de raccordement cuivre ont un nom d'usage, bien souvent le
nom du quartier desservi ou la ville concernée.
Par ailleurs, name=NRO c'est taguer pour le rendu certes. J'ai moi aussi
cette mauvaise habitude.


> 2ème chose, il a ajouté des NRO alors que préexistaient des objets
> man_made=telephone_office et telecom=central_office et ces tags sont
> aujourd'hui dépréciés cf.
> https://wiki.openstreetmap.org/wiki/Tag:telecom%3Dexchange Il
> conviendrait donc de reprendre les tags des objets existants plutôt qu'en
> ajouter des nouveaux.
>

Comme la doc le précise :
https://wiki.openstreetmap.org/wiki/FR:Tag:telecom%3Dexchange#Cas_de_multiples_noeuds_dans_le_m.C3.AAme_b.C3.A2timent
Lorsqu'il y a plusieurs medium desservis dans le même batiment, les noeuds
sont séparés.
Il a simplement créé le NRO sur un noeud dédié parce qu'il reste un NRA
cuivre dans le bâtiment.
Normalement il devrait y avoir deux noeuds mais il explique ne pas avoir
voulu toucher le polygone pour l'instant.

Le cuivre et la fibre vont cohabiter encore pour quelques années. Lorsque
le NRA cuivre disparaîtra, on supprimera le nœud dans toucher au NRO fibre.


> Et malgré mes remarques, il a continué à contribuer sans en tenir compte
> ex : https://www.openstreetmap.org/node/7156119118.
>

Ce site semble bien être mixte, sa contribution est la bonne.

Je sais que le sujet est technique et déroutant, mais il semble que les
pratiques soient bien adaptées ici.
Il faut en tenir compte.

Le sam. 25 janv. 2020 à 23:42, deuzeffe  a écrit :

>
> Va falloir faire une sacré ménage :(
>

Oui c'est bien ce qui se manifeste ici
https://wiki.openstreetmap.org/wiki/FR:Tag:telecom%3Dexchange#Possibles_erreurs

Mais le dernier modèle voté en 2018 est vraiment beaucoup mieux que le
précédent et ce ménage vaut le coup.

Bonne soirée

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

Re: [OSM-talk-fr] Héberger un mirroir ou un bittorrent pour les planet, possible?

2020-01-26 Par sujet marc marc 
Le 26.01.20 à 20:09, Christian Quest a écrit :
> Je viens de regénérer des torrents pour le fichier planet pbf:
> http://osm.cquest.org/torrents/

créer autant de torrent mono-seed initial que de personne ayant l'idée
d'héberger un planet en réduit l'intérêt. surtout combiné à la non
priorisation des sources proches.
c'est p'tre cela qui explique la non utilisation, faudrait au moins
avoir le lien depuis la page osm.fr en attend plus communautaire.

ton planet vient d'osm.org ou c'est une génération locale ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Héberger un mirroir ou un bittorrent pour les planet, possible?

2020-01-26 Par sujet marc marc 
Le 26.01.20 à 15:27, Thomas Gratier a écrit :
> La version courte: l'ensemble de la communauté en récupérant des planet
> complets finit par saturer la bande passante

question courte (de la discussion qui a lieu aussi sur la ml dev) :
pq 100 personnes ont besoin chaque semaine de télécharger le planet ?
je crois que certains ignorent ou trouvent trop compliqué la maj
cela implique de mieux informer et/ou rendre la maj + facile.

> OpenStreetMap France pourrait créer un miroir et/ou une version torrent?

l'ironie c'est que pour le moment, faire un miroir doit se faire
par téléchargement d'un planet toute les semaine.
le planet osm.org lui meme n'est pas produit avec les diff.
après rien n'interdit de produire un planet non mirroir de l'original.
cela dépend de la réponse à la question précédente.

> Un/des avis?

une piste est de comprendre le besoin (voir point 1)
une piste est la création d'un planet non miroir (voir point précédent)
une piste est la création d'un miroir à la volée : pas de dl automatique
entre osm.org et osm.fr chaque semaine mais si qlq clique sur le lien
osm.fr, cela télécharger le dernier planet osm.org et le met à
disposition pendant une semaine (puisqu'après il est "périmé")
ainsi si 2 personnes téléchargent le planet via osm.fr
il y a un gain, sans jamais provoquer de trafic inutile.
la piste d'un miroir osm.org me semble venir après même si perso je
serrai pour, surtout si geolimité pour favoriser l'efficacité (car il y
a deja un outil qui télécharge sur tous les miroirs en meme temps,
c'est très con de télécharger sur un miroir loin quand on en a un proche)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Motorroad sur Trunk en France

2020-01-26 Par sujet Axel Listes 
Bonsoir,

Le 25/01/2020 à 21:12, Florimond Berthoux a écrit :
> Je suis tombé sur une phrase qui m'a étonné sur la page de la clé motorroad
> du wiki
> «France
> This tag is not required, just use highway=trunk. »
> https://wiki.openstreetmap.org/wiki/Key:motorroad?uselang=fr#France
> 
> Et effectivement pas de traduction en français de la page, et sur la page
> française de Trunk l'explication du tag est resté en anglais.
> 
> Cette phrase me parait assez fausse parce qu'en France une motorroad ça a
> un panneau voir
> https://fr.wikipedia.org/wiki/Route_pour_automobiles#En_France
> Le tag est très utilisé dans le pays des Trunk (Bretagne) et ailleurs.
> Et pour ce qui me concerne j'ai l'exemple d'une voie rapide dont un premier
> tronçon est cyclable puis un panneau "route pour automobile" après la
> premier sortie, où le tag motorroad est fort utile.
> 
> Alors, je corrige la page ?

J'avais déjà lancé le sujet en 2014, au final il n'y a jamais eu de
consensus.

http://gis.19327.n8.nabble.com/highway-trunk-en-France-td5821793.html

Si tu arrives à faire bouger les lignes, merci d'avance !

Axel.

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

Re: [OSM-talk-fr] Héberger un mirroir ou un bittorrent pour les planet, possible?

2020-01-26 Par sujet Christian Quest 
Pour de gros fichiers comme ça, à la durée de vie courte, BitTorrent me 
semble bien adapté et les mirroir il y en a déjà plusieurs mais 
visiblement peu utilisés (il faudrait un redirect automatique à la 
sourceforge).


Le p2p est adapté car plus il y a de monde à charger un fichier, plus il 
est disponible au même moment et donc cela ne s'engorge pas à la source 
primaire.



J'avais mis ça en place il y a quelques années, sur un petit scaleway... 
mais comme ce n'était pas utilisé j'ai arrêté.


Je viens de regénérer des torrents pour le fichier planet pbf: 
http://osm.cquest.org/torrents/


Il faut juste maintenant que j'arrive à "seeder" correctement depuis mes 
twin towers, chacune connectée à une fibre différente, ce qui devrait 
faire dans les 500Mbps x 2 en sortie.



Le 26/01/2020 à 15:37, Thomas Gratier a écrit :

Bonjour,

Pour le suivi, cela semble temporaire 
https://lists.openstreetmap.org/pipermail/dev/2020-January/030873.html
Mais la question d'avoir un miroir fr supplémentaire (si ce n'est pas 
déjà le cas) ou un bittorrent reste ouverte.



Thomas Gratier

Le dim. 26 janv. 2020 à 15:27, Thomas Gratier 
mailto:osgeo.mailingl...@gmail.com>> a 
écrit :


Salut à tous,

Il y a une discussion enflammée sur Twitter
https://twitter.com/komzpa/status/1221025538317475842 concernant
la limitation récente de la bande passante pour récupérer un
fichier planet
https://twitter.com/komzpa/status/1221025538317475842qui rend donc
le processus très long.

La version courte: l'ensemble de la communauté en récupérant des
planet complets finit par saturer la bande passante (voir
https://lists.openstreetmap.org/pipermail/dev/2020-January/030873.html)
et cela semble poser des problèmes réseaux. Il faudrait selon
certains ne travailler plus qu'avec des diff pour limiter la bande
passante en argumentant que sinon on va au delà du "fair use"
(pour les tuiles, je comprend mais pour la donnée brute, j'ai plus
de mal). Pour d'autres, il faudrait avoir des miroirs et/ou des
versions torrent pour ne plus avoir ce genre de limitation.

Personnellement, je suis plutôt partisan de la seconde option car
sinon pour travailler avec un planet, il faudra se préoccuper de
mettre en place des diff, ce qui est une barrière à la
réutilisation de mon point de vue.

OpenStreetMap France pourrait créer un miroir et/ou une version
torrent? On peut se rapprocher de la fondation en tant que
chapitre local pour faire avancer le truc?

Un/des avis?


Merci de vos retours

Thomas Gratier
https://twitter.com/komzpa/status/1221179076079235072
https://twitter.com/komzpa/status/1221174462852292608
https://twitter.com/komzpa/status/1221174462852292608


--
Ce message a été vérifié par *MailScanner* 
pour des virus ou des polluriels et rien de
suspect n'a été trouvé.

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


--
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] Bases ULM : sports_centre ?

2020-01-26 Par sujet deuzeffe 

Le 25/01/2020 à 13:23, marc marc a écrit :

Le 25.01.20 à 13:07, deuzeffe a écrit :

on fait comment pour renseigner qu'un tel terrain permet la
pratique de l'ULM (à part sans le name=*) ?


séparer les 2 pour éviter la confusion du lieu global, de la piste et de
ce qui s'y passe

>
> ou alors ce n'est pas une base dédié mais un club sportif qui utilise
> une partie d'un aérodrome. alors plutôt un nœud, par exemple dans leur
> hangar club=sport + sport=*

C'est ce que j'ai fait, une ligne pour l'aistrip et un point pour le 
club ulm (c'est en plein champ...).


J'en ai trouvé d'autre en pleine eau aussi ^^

D'autre part, même si je n'ai pas trouvé de licence pour la base basulm, 
les wizards sont bien d'accord pour dire que son utilisation est licite ?


JY : merci pour les ref= ;)

--
deuzeffe

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

Re: [OSM-talk-fr] Avec quoi taguer une résidence pour étudiants ?

2020-01-26 Par sujet Donat ROBAUX 
Salut Brice,

Personnellement je les taggue comme des foyers-logements pour personnes
âgées (/assisted_living/, car il y a des services), indépendamment de savoir
si c'est public ou privé. Voir:  https://www.openstreetmap.org/way/674207398
  
Pour les cités U, plutôt comme des EHPAD (c-à-d /group_home/) car il s'agit
plus de chambres que d'appartements indépendants. Voir 
https://www.openstreetmap.org/way/48042596
  

Donat



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk-fr] Maxar HS ?

2020-01-26 Par sujet Philippe Verdy 
Note que les plus impactés par ça sont les pays d'Asie, ça chauffe pour
eux, notamment en Indonésie, et pour divers projets HOT qui sont arrêtés
dans d'autres pays.

Le dim. 26 janv. 2020 à 17:54, pepilepi...@ovh.fr  a
écrit :

> Le 26/01/2020 à 13:26, Philippe Verdy a écrit :
>
> C'est en panne et discuté depuis un bon moment. Le service a été victime
> d'usage abusif par des sociétés commerciales qui ont mis à mal la capacité
> de ses serveurs.
> Maxar a temporairement fermé l'accès et la Fondation OSM négoicie un accès
> authentifié pour les contributeurs. D'après les annonces Twitter cela
> devrait bientôt revenir (il faudra une clé d'accès, et sans doute la
> nécessité d'accepter les termes de service la source d'imagerie dans JOSM
> ou iD sera remise à jour pour en tenir compte).
> Ce n'est pas nouveau mais c'est en cours de traitement.
> Maintenant l'ortho IGN n'est pas la seule en Rhône-Alpes, tout dépend des
> zones... Mais j'ai des images dans JOSM et iD pour pas mal d'entre elles
> qui date de 2006 pour les plus anciennes ou bien après.
> Si tu comptais sur Maxar pour avoir des images de certains secteurs après
> 2010, il faudra attendre.
>
> Merci.
>
> Dommage, tant pis, j'attendrai.
>
> Bonne soirée,
>
> JP
>
>
> Le dim. 26 janv. 2020 à 11:07, pepilepi...@ovh.fr  a
> écrit :
>
>> Bonjour,
>>
>> En mai dernier j'avais eu des soucis d'imagerie avec JOSM, résolus avec
>> Maxar
>> .
>>
>> Hélas, il y a quelque temps maxar me renvoyait "pas de tuile à ce niveau
>> de zoom", et depuis peu Maxar n'est même plus dans la liste des imageries
>> disponibles de JOSM.
>>
>> Évidemment je suis dans l'une des zones noires de HR Ortho, et ici
>> l'ortho IGN date du début du siècle...
>>
>> Qu'est-il arrivé à Maxar ? Et quelle imagerie récente peut-on utiliser
>> ans la région Rhône-Alpes ?
>>
>> Merci, bon dimanche
>>
>> Jean-Pierre
>> --
>> --
>>
>> Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas posé la
>> bonne question.
>> ___
>> 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
>
>
> --
> --
>
> Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas posé la
> bonne question.
> ___
> 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] Avec quoi taguer une résidence pour étudiants ?

2020-01-26 Par sujet marc marc 


> Le 26 janv. 2020 à 18:35, Brice  a écrit :
> 
> Des idées ?

building=l'apparence (un gros bloc dormoir est une dès apparence possible)
Building:use=residential
Éventuellement qlq genre for=student ou student=designated 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Avec quoi taguer une résidence pour étudiants ?

2020-01-26 Par sujet Brice 

Bonsoir,

Pour les résidences pour étudiants, il y a building=dormitory 
(https://wiki.openstreetmap.org/wiki/Tag:building%3Ddormitory)
mais c'est un tag pour le bâtiment et non pour la fonction / service rendu.

Jusqu'à maintenant je m'en suis contenté mais je souhaiterais pouvoir taguer la fonction sur un POI, indépendamment du 
bâtiment :

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

J'ai bien trouvé
https://www.openstreetmap.org/way/299297114
mais une résidence pour étudiants n'est pas strictement  amenity=social_facility puisque dans mon cas présent c'est un 
service marchand rendu par une société privée :

https://www.nexity-studea.com/locations-etudiantes/le-pre-saint-gervais/studea-pre-st-gervais-po229

Des idées ?

--
Britzz

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

Re: [OSM-talk-fr] Erreur ID

2020-01-26 Par sujet Cédric Frayssinet 

Ouf, j'ai trouvé \o/  Désolé pour le bruit :)

Le 26/01/2020 à 17:47, Cédric Frayssinet a écrit :
>
> L'erreur est celle-ci : https://github.com/openstreetmap/iD/issues/6817
>
> Du coup, existe-t-il un outil qui permettrait de trouver un champ de
> nœud qui dépasserait 255 caractères dans une zone donnée ? Je ne
> trouve pas dans les éléments que je modifie...
>
> Merci, Cédric
>
> Le 26/01/2020 à 15:46, Cédric Frayssinet a écrit :
>>
>> Bonjour à tous,
>>
>> En voulant envoyer des modifs avec iD, j'ai eu ce message d'erreur :
>>
>> Value has more than 255 unicode characters in Node -6 at line 1,
>> column 2255 
>>
>> Après, impossible d'envoyer, il contacte l'API, iD redemande l'accès
>> à mon compte puis je tombe sur une erreur et je n'arrive pas à valider.
>>
>> Dans une fenêtre privée, j'ai fait une modif sans problème.
>>
>> Il n'y a rien de particulier dans mon changeset... Déjà rencontré le
>> soucis ?
>>
>> Merci, Cédric
>>
>> -- 
>>
>> Sur Mastodon : @bristow...@framapiaf.org
>> 
>>
>> Promouvoir et soutenir le logiciel libre 
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
> -- 
>
> Sur Mastodon : @bristow...@framapiaf.org
> 
>
> Promouvoir et soutenir le logiciel libre 
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr


-- 

Sur Mastodon : @bristow...@framapiaf.org 

Promouvoir et soutenir le logiciel libre 

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

Re: [OSM-talk-fr] Maxar HS ?

2020-01-26 Par sujet pepilepi...@ovh.fr 
Le 26/01/2020 à 13:26, Philippe Verdy a écrit :
> C'est en panne et discuté depuis un bon moment. Le service a été
> victime d'usage abusif par des sociétés commerciales qui ont mis à mal
> la capacité de ses serveurs.
> Maxar a temporairement fermé l'accès et la Fondation OSM négoicie un
> accès authentifié pour les contributeurs. D'après les annonces Twitter
> cela devrait bientôt revenir (il faudra une clé d'accès, et sans doute
> la nécessité d'accepter les termes de service la source d'imagerie
> dans JOSM ou iD sera remise à jour pour en tenir compte).
> Ce n'est pas nouveau mais c'est en cours de traitement.
> Maintenant l'ortho IGN n'est pas la seule en Rhône-Alpes, tout dépend
> des zones... Mais j'ai des images dans JOSM et iD pour pas mal d'entre
> elles qui date de 2006 pour les plus anciennes ou bien après.
> Si tu comptais sur Maxar pour avoir des images de certains secteurs
> après 2010, il faudra attendre.

Merci.

Dommage, tant pis, j'attendrai.

Bonne soirée,

JP

>
> Le dim. 26 janv. 2020 à 11:07, pepilepi...@ovh.fr
>   > a écrit :
>
> Bonjour,
>
> En mai dernier j'avais eu des soucis d'imagerie avec JOSM, résolus
> avec Maxar
> .
>
> Hélas, il y a quelque temps maxar me renvoyait "pas de tuile à ce
> niveau de zoom", et depuis peu Maxar n'est même plus dans la liste
> des imageries disponibles de JOSM.
>
> Évidemment je suis dans l'une des zones noires de HR Ortho, et ici
> l'ortho IGN date du début du siècle...
>
> Qu'est-il arrivé à Maxar ? Et quelle imagerie récente peut-on
> utiliser ans la région Rhône-Alpes ?
>
> Merci, bon dimanche
>
> Jean-Pierre
>
> -- 
> 
>
> Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas
> posé la bonne question.
>
> ___
> 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


-- 


Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas posé la
bonne question.

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

Re: [OSM-talk-fr] Erreur ID

2020-01-26 Par sujet Cédric Frayssinet 

L'erreur est celle-ci : https://github.com/openstreetmap/iD/issues/6817

Du coup, existe-t-il un outil qui permettrait de trouver un champ de
nœud qui dépasserait 255 caractères dans une zone donnée ? Je ne trouve
pas dans les éléments que je modifie...

Merci, Cédric

Le 26/01/2020 à 15:46, Cédric Frayssinet a écrit :
>
> Bonjour à tous,
>
> En voulant envoyer des modifs avec iD, j'ai eu ce message d'erreur :
>
> Value has more than 255 unicode characters in Node -6 at line 1,
> column 2255 
>
> Après, impossible d'envoyer, il contacte l'API, iD redemande l'accès à
> mon compte puis je tombe sur une erreur et je n'arrive pas à valider.
>
> Dans une fenêtre privée, j'ai fait une modif sans problème.
>
> Il n'y a rien de particulier dans mon changeset... Déjà rencontré le
> soucis ?
>
> Merci, Cédric
>
> -- 
>
> Sur Mastodon : @bristow...@framapiaf.org
> 
>
> Promouvoir et soutenir le logiciel libre 
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr


-- 

Sur Mastodon : @bristow...@framapiaf.org 

Promouvoir et soutenir le logiciel libre 

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

[OSM-talk-fr] Erreur ID

2020-01-26 Par sujet Cédric Frayssinet 
Bonjour à tous,

En voulant envoyer des modifs avec iD, j'ai eu ce message d'erreur :

Value has more than 255 unicode characters in Node -6 at line 1, column
2255 

Après, impossible d'envoyer, il contacte l'API, iD redemande l'accès à
mon compte puis je tombe sur une erreur et je n'arrive pas à valider.

Dans une fenêtre privée, j'ai fait une modif sans problème.

Il n'y a rien de particulier dans mon changeset... Déjà rencontré le
soucis ?

Merci, Cédric

-- 

Sur Mastodon : @bristow...@framapiaf.org 

Promouvoir et soutenir le logiciel libre 

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

Re: [OSM-talk-fr] Héberger un mirroir ou un bittorrent pour les planet, possible?

2020-01-26 Par sujet Thomas Gratier 
Bonjour,

Pour le suivi, cela semble temporaire
https://lists.openstreetmap.org/pipermail/dev/2020-January/030873.html
Mais la question d'avoir un miroir fr supplémentaire (si ce n'est pas déjà
le cas) ou un bittorrent reste ouverte.


Thomas Gratier

Le dim. 26 janv. 2020 à 15:27, Thomas Gratier 
a écrit :

> Salut à tous,
>
> Il y a une discussion enflammée sur Twitter
> https://twitter.com/komzpa/status/1221025538317475842 concernant la
> limitation récente de la bande passante pour récupérer un fichier planet
> https://twitter.com/komzpa/status/1221025538317475842qui rend donc le
> processus très long.
>
> La version courte: l'ensemble de la communauté en récupérant des planet
> complets finit par saturer la bande passante (voir
> https://lists.openstreetmap.org/pipermail/dev/2020-January/030873.html)
> et cela semble poser des problèmes réseaux. Il faudrait selon certains ne
> travailler plus qu'avec des diff pour limiter la bande passante en
> argumentant que sinon on va au delà du "fair use" (pour les tuiles, je
> comprend mais pour la donnée brute, j'ai plus de mal). Pour d'autres, il
> faudrait avoir des miroirs et/ou des versions torrent pour ne plus avoir ce
> genre de limitation.
>
> Personnellement, je suis plutôt partisan de la seconde option car sinon
> pour travailler avec un planet, il faudra se préoccuper de mettre en place
> des diff, ce qui est une barrière à la réutilisation de mon point de vue.
>
> OpenStreetMap France pourrait créer un miroir et/ou une version torrent?
> On peut se rapprocher de la fondation en tant que chapitre local pour faire
> avancer le truc?
>
> Un/des avis?
>
>
> Merci de vos retours
>
> Thomas Gratier
> https://twitter.com/komzpa/status/1221179076079235072
> https://twitter.com/komzpa/status/1221174462852292608
> https://twitter.com/komzpa/status/1221174462852292608
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Héberger un mirroir ou un bittorrent pour les planet, possible?

2020-01-26 Par sujet Thomas Gratier 
Salut à tous,

Il y a une discussion enflammée sur Twitter
https://twitter.com/komzpa/status/1221025538317475842 concernant la
limitation récente de la bande passante pour récupérer un fichier planet
https://twitter.com/komzpa/status/1221025538317475842qui rend donc le
processus très long.

La version courte: l'ensemble de la communauté en récupérant des planet
complets finit par saturer la bande passante (voir
https://lists.openstreetmap.org/pipermail/dev/2020-January/030873.html) et
cela semble poser des problèmes réseaux. Il faudrait selon certains ne
travailler plus qu'avec des diff pour limiter la bande passante en
argumentant que sinon on va au delà du "fair use" (pour les tuiles, je
comprend mais pour la donnée brute, j'ai plus de mal). Pour d'autres, il
faudrait avoir des miroirs et/ou des versions torrent pour ne plus avoir ce
genre de limitation.

Personnellement, je suis plutôt partisan de la seconde option car sinon
pour travailler avec un planet, il faudra se préoccuper de mettre en place
des diff, ce qui est une barrière à la réutilisation de mon point de vue.

OpenStreetMap France pourrait créer un miroir et/ou une version torrent? On
peut se rapprocher de la fondation en tant que chapitre local pour faire
avancer le truc?

Un/des avis?


Merci de vos retours

Thomas Gratier
https://twitter.com/komzpa/status/1221179076079235072
https://twitter.com/komzpa/status/1221174462852292608
https://twitter.com/komzpa/status/1221174462852292608
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] protect_class -du périmètre de protection autour de la réserve géologique

2020-01-26 Par sujet Philippe Verdy 
Regarde les autres relations concernant les "aires d'adhésion", il y en a
diverses en France (pour les parcs régionaux ou nationaux); les réserves
elles-mêmes sont hors périmètres administratifs, ce sont les zones
concernées par des plans concrets auxquels participent toutes les communes
via leur syndicat; les aires d'adhésion concernent les communes adhérentes
à la gestion de ces zones protégées avec un plan commun de gestion au sein
du syndicat (souvent un syndicat mixte car il peut aussi y avoir dedans le
département, la région, ou des assos et chambres professionnelles, ou
agences de bassin, syndicats de propriétaires forestiers ou fonciers, qui
ne sont pas concernées pour toute l'étendue de leur territoire mais une
partie et qui n'ont d'ailleurs pas toujours un périmètre administratif bien
défini mais un intérêt local à ces zones où elles mènent des actions (cas
des assos et fondations) ; idem pour les sites Natura 2000 créés par l'Etat
dans le cadre européen: ce sont des domaines d'étude et de recherche plus
que des domaines d'action : l'INPN documente les besoins au plan national,
les syndicats prendront leurs décisions locales avec leurs membres
(communes ou autres syndicats et organisations).

Franchement les aires d'adhésion ne devraient pas vraiment être des parcs,
mais plutôt des "local_authority" (comme les EPCI à fiscalité propre), leur
identité juridique étant en fait un syndicat mixte (SIVOM ou SIVU) pour la
souplesse que ça apporte mais ils n'ont pas de fiscalité (leur financement
vient des apports des membres du syndicats et subventions externes reçues
des départements, régions, l'Etat, ou l'Europe): les aires indiquent
l'étendue maximale d'action du syndicat qui n'a pas forcément d'action à
mener partout en même temps et pas sur toute la zone (ils se concentre sur
des espèces, des habitats, vont financer des plans de protection, émettre
des avis que les aménagements public ou privés et la réglementation
localement applicable sera validée par les arrêtés préfectoraux ou
ministériels ou la loi si nécessaire).


Le dim. 26 janv. 2020 à 11:13, Arnaud Champollion <
arnaud.champoll...@linux-alpes.org> a écrit :

> Bonjour,
>
> Le périmètre de protection autour de la réserve géologique de Haute
> Provence regroupe 59 communes :
>
> https://www.openstreetmap.org/relation/10615882
>
> La relation est constituée des tronçons extérieurs des limites des
> communes concernées.
>
> C'est une extension périphérique de la Réserve proprement dite, qui est
> constituée de 18 petites zones.
>
> Je me demande quelle valeur renseigner pour l'attribut protect_class car
> là il ne s'agit pas de la zone "coeur" mais seulement du périmètre de
> protection.
>
> Merci de votre avis,
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Maxar HS ?

2020-01-26 Par sujet Philippe Verdy 
C'est en panne et discuté depuis un bon moment. Le service a été victime
d'usage abusif par des sociétés commerciales qui ont mis à mal la capacité
de ses serveurs.
Maxar a temporairement fermé l'accès et la Fondation OSM négoicie un accès
authentifié pour les contributeurs. D'après les annonces Twitter cela
devrait bientôt revenir (il faudra une clé d'accès, et sans doute la
nécessité d'accepter les termes de service la source d'imagerie dans JOSM
ou iD sera remise à jour pour en tenir compte).
Ce n'est pas nouveau mais c'est en cours de traitement.
Maintenant l'ortho IGN n'est pas la seule en Rhône-Alpes, tout dépend des
zones... Mais j'ai des images dans JOSM et iD pour pas mal d'entre elles
qui date de 2006 pour les plus anciennes ou bien après.
Si tu comptais sur Maxar pour avoir des images de certains secteurs après
2010, il faudra attendre.

Le dim. 26 janv. 2020 à 11:07, pepilepi...@ovh.fr  a
écrit :

> Bonjour,
>
> En mai dernier j'avais eu des soucis d'imagerie avec JOSM, résolus avec
> Maxar
> .
>
> Hélas, il y a quelque temps maxar me renvoyait "pas de tuile à ce niveau
> de zoom", et depuis peu Maxar n'est même plus dans la liste des imageries
> disponibles de JOSM.
>
> Évidemment je suis dans l'une des zones noires de HR Ortho, et ici l'ortho
> IGN date du début du siècle...
>
> Qu'est-il arrivé à Maxar ? Et quelle imagerie récente peut-on utiliser ans
> la région Rhône-Alpes ?
>
> Merci, bon dimanche
>
> Jean-Pierre
> --
> --
>
> Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas posé la
> bonne question.
> ___
> 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] Type de highway pour voie de bus

2020-01-26 Par sujet Philippe Verdy 
Il n'empêche qu'en cas d'accident, leur responsabilité est réduite à zéro
pour les assurances et à 100% pour le conducteur, le seul qui est tenu
d'être assuré (qui cependant ne sera pas sanctionné de conduite imprudente
puisque l'imprudence était celle du piéton, à moins qu'il ait de bonnes
raisons comme un trottoir impraticable pour lui, cas d'un handicapé, et
l'assurance du conducteur ne pourra pas lui imposer un malus conséquent :
le conducteur peut se défendre, mais l'assurance doit prendre en charge
100% des dommages; les droits du piétons couverts à 100% peuvent cependant
être réduits du fait de son imprudence; et éventuellement l'autorité pourra
lui donner une amende, mais c'est indépendant de la couverture assurance).
Et en milieu urbain, la responsabilité du conducteur reste souvent engagée
(notamment quand le piéton est mineur ou handicapé, c'est au conducteur
d'être prudent. Si un piéton se jette littéralement sur la voiture par un
comportement suicidaire, le conducteur n'est pas non plus sanctionné, mais
il doit le prouver ou un expert le fera, et les familles portent souvent
plainte quand même; les conducteurs sont donc tenus d'être prudents en
toute occasion et engagent toujours une responsabilité qu'il devra défendre
en justice : l'usage du véhicule n'est pas qu'un droit automatique, c'est
une charge et toujours une prise de risques, c'est pour ça qu'il doit être
assuré en toute condition pour les dommages causés aux tiers)

Le dim. 26 janv. 2020 à 09:33, Georges Dutreix via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Bonjour,
>
> Le 23/01/2020 à 16:57, Philippe Verdy a écrit :
> > En France les piétons peuvent aller quasiment partout, sauf
> > signalisation ou équipement spécial (sidewalk en est un) mais ils
> > peuvent traverser partout et sont prioritaires. Les interdictions
> > piétons sont matérialisées par les a signalisation (y compris les
> > panneaux autoroute et voies express, et les barrières de séparation de
> > chaussées). En zone urbaine ils ne sont même pas obligés de traverser
> > seulement aux passages protégés (mais ils le font avec un partage des
> > risques et les conducteurs sont malgré tout responsables des accidents
> > car, eux seulement, sont couverts par des assurances obligatoires.
>
> Le code de la route impose tout de même des choses aux piétons.
> . Art 412-34 :
> "Lorsqu'une chaussée est bordée d'emplacements réservés aux piétons ou
> normalement praticables par eux, tels que trottoirs ou accotements, les
> piétons sont tenus de les utiliser, à l'exclusion de la chaussée."
>
> Art 412-37 :
> "traverser la chaussée[...] Ils sont tenus d'utiliser, lorsqu'il en
> existe à moins de 50 mètres, les passages prévus à leur intention."
>
>
> https://www.legifrance.gouv.fr/affichCode.do?idSectionTA=LEGISCTA06177125=LEGITEXT06074228=20100701
>
>
>
> ___
> 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] wiki JOSM : Mise en Forme de la page Fr:Help/Action/Help modifiée par anonyme

2020-01-26 Par sujet Philippe Verdy 
Non, c'est bien "*:" car les marqueurs de listes imbriqués conservent leur
ordre du niveau de base au niveau imbriqué.
"*:" signifie que c'est un élément de sous-liste (liste de définition) dans
un élément de liste à puce (commencé aux lignes précédentes).
si tu mets ":*" tu auras une sous-liste à puce dans une nouvelle liste
indentée, et tu romps la liste à puces commencée à la ligne précédente.

Le dim. 26 janv. 2020 à 11:02, leni  a écrit :

>
> Le 20/01/2020 à 01:05, Philippe Verdy a écrit :
> > Je ne vois pas de changement de "mise en forme" hormis une
> > wikification de liste avec des "*" (puces) au lieu des numéros (qui
> > supposerait un ordre)
> > C'est somme toute mineur, et ça reste malgré tout une traduction
> conforme.
> qui risque disparaitre s'il y a une modification de la page anglaise,
> j'espérais que la personne était sur la liste et ferait la modif
> également sur la page originale
> > Ceci dit ce n'est pas une "liste" valide puisque les éléments
> > détaillés ont été "indentés" hors liste.
> > On peut proposer le changement correct (supprimer les numéros non
> > significatifs par des puces, et non pas indenter le détail avec des
> > espaces (qui créent un bloc de code) après chaque liste limitée à un
> > seul item mais avec "*:", afin de conserver la liste non rompue, et en
> > profiter pour supprimer les barres obliques inverses en fin de ligne)
> > dans la page anglaise
> > Sans doute quelqu'un qui ne connait pas bien la syntaxe wiki et croit
> > pouvoir l'utiliser correctement, mais à moitié en ne voyant pas que
> > cela ne crée pas une vraie liste mais trois séparées, suivies chacune
> > d'un bloc indenté.
>
> Ce ne serait pas plutôt ":*" ?
>
> Je n’arrives pas à faire ce dont tu parles ; pourrais-tu me l'indiquer
> sur cet extrait ?
>
>   1. With the {{{F1}}} key anywhere.\\
> This invokes the help topic for the screen element under the mouse
> pointer.
> If that element has no own help topic, then the request is passed
> downwards to the surrounding screen element.
> Finally search ends at the [wikitr:/Help/MapView Map view] or
> [wikitr:/Help Main help] pages as last resorts.\\
>
>
> ___
> 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 de retournement

2020-01-26 Par sujet Philippe Verdy 
oui j'ai un peu revu certaines géométries imprécises, des bâtiments
cadastrés peu représentatifs/mal alignés (source BDOrtho), quelques limites
autour (forêt, zone gazonnée, rivière, rangées d'arbres, quelques une des
clôtures, raligné quelques chemins, changé quelques allées d'accès aux
propriétés, mis des portails, et marqué la partie privative derrière le
portail)
Je te laisse faire le reste...

Le dim. 26 janv. 2020 à 11:02, Arnaud Champollion <
arnaud.champoll...@linux-alpes.org> a écrit :

> Bonjour,
>
> Merci de toutes ces infos. J'ai vu que tu avais mis en oeuvre les
> modifications nécessaires (et autres dans le quartier apparemment).
> J'ai ajouté surface=compacted.
>
>
>
>
> Le 25/01/2020 à 12:23, Philippe Verdy a écrit :
>
> En tout cas ça ne peut pas être défini à highway=turning_circle sur le way
> (ce n'est défini que sur un noeud d'extrémité, éventuellement connecté à
> d'autres chemins)
> highway=servive semble le mieux étant donné l'accès résidentiel connecté
> dessus et le fait que les bus les utilise.
> Tu peux toujours rajouter surface=unpaved (bien que ça me semble plutôt
> surface=compacted, sinon les bus ne pourraient pas passer dessus
> régulièrement sans former des ornières, ce n'est pas un chemin de terre ou
> une trace dans la pelouse, c'est au moins empierré et compacté, même s'il y
> a un peu de terre dedans ou un peu d'herbe pousse dessus, et pas non plus
> un "track" agricole ou industriel, alors que c'est un usage régulier des
> bus et véhicules, piétons et sans doute aussi cyclistes, et aucune
> restriction).
> La question c'est plutôt: highway=service ou residential? Je penche pour
> service car il n'y a plus rien d'autre connecté desservi que la voie de
> service privée vers le nord, l'usage des bus , et sinon les chemins piétons
> vers la forêt , il n'y a pas d'arrêt aménagé possible, même pas de
> stationnement latéral, c'est juste fait pour faire demi-tour autour de
> l'îlot.
> Et aussi le nom de la rue doit être ramené dessus: c'est bien une voie
> publique (pour les bus et sinon les marcheurs vers la forêt), et l'allée
> privée vers le nord est aussi à l'adresse de cette rue.
>
>
> Le ven. 24 janv. 2020 à 07:53, Arnaud Champollion <
> arnaud.champoll...@linux-alpes.org> a écrit :
>
>> Le 24/01/2020 à 05:46, Philippe Verdy a écrit :
>> > peut-être une voie de service, mais pas sûr que ce soit réservé
>> > seulement aux bus
>>
>> Non il n'y a pas de signalétique la réservant aux bus.
>>
>> > , et dans ce cas c'est encore la fin de la rue résidentielle qui y
>> > arrive (et d'ailleurs ça se voit aux adresses FANTOIR, le Chemin du
>> > Marquis est en voie publique même si c'est une impasse avec un seul
>> > résident).
>>
>> Donc ça devrait être en highway=residential avec surface=unpaved ? En
>> fait pour l'instant il y a highway=track à cause du non-revêtement, mais
>> c'est peut-être justement une erreur.
>>
>> > Au passage la boucle est mal alignée, elle passe un peu plus à l'ouest
>> > (on la voit bien à travers les branches de arbres dessus à l'extrémité
>> > de l'îlot, et le chmein du Marqui tombe bien sur cette boucle et non
>> > sur le sentier allant vers l'ouest).
>>
>> OK j'ai corrigé cela.
>>
>>
>> ___
>> 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

[OSM-talk-fr] protect_class -du périmètre de protection autour de la réserve géologique

2020-01-26 Par sujet Arnaud Champollion 

Bonjour,

Le périmètre de protection autour de la réserve géologique de Haute 
Provence regroupe 59 communes :


https://www.openstreetmap.org/relation/10615882

La relation est constituée des tronçons extérieurs des limites des 
communes concernées.


C'est une extension périphérique de la Réserve proprement dite, qui est 
constituée de 18 petites zones.


Je me demande quelle valeur renseigner pour l'attribut protect_class car 
là il ne s'agit pas de la zone "coeur" mais seulement du périmètre de 
protection.


Merci de votre avis,


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

[OSM-talk-fr] Maxar HS ?

2020-01-26 Par sujet pepilepi...@ovh.fr 
Bonjour,

En mai dernier j'avais eu des soucis d'imagerie avec JOSM, résolus avec
Maxar
.

Hélas, il y a quelque temps maxar me renvoyait "pas de tuile à ce niveau
de zoom", et depuis peu Maxar n'est même plus dans la liste des
imageries disponibles de JOSM.

Évidemment je suis dans l'une des zones noires de HR Ortho, et ici
l'ortho IGN date du début du siècle...

Qu'est-il arrivé à Maxar ? Et quelle imagerie récente peut-on utiliser
ans la région Rhône-Alpes ?

Merci, bon dimanche

Jean-Pierre

-- 


Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas posé la
bonne question.

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

Re: [OSM-talk-fr] Aire de retournement

2020-01-26 Par sujet Arnaud Champollion 

Bonjour,

Merci de toutes ces infos. J'ai vu que tu avais mis en oeuvre les 
modifications nécessaires (et autres dans le quartier apparemment).

J'ai ajouté surface=compacted.




Le 25/01/2020 à 12:23, Philippe Verdy a écrit :
En tout cas ça ne peut pas être défini à highway=turning_circle sur le 
way (ce n'est défini que sur un noeud d'extrémité, éventuellement 
connecté à d'autres chemins)
highway=servive semble le mieux étant donné l'accès résidentiel 
connecté dessus et le fait que les bus les utilise.
Tu peux toujours rajouter surface=unpaved (bien que ça me semble 
plutôt surface=compacted, sinon les bus ne pourraient pas passer 
dessus régulièrement sans former des ornières, ce n'est pas un chemin 
de terre ou une trace dans la pelouse, c'est au moins empierré et 
compacté, même s'il y a un peu de terre dedans ou un peu d'herbe 
pousse dessus, et pas non plus un "track" agricole ou industriel, 
alors que c'est un usage régulier des bus et véhicules, piétons et 
sans doute aussi cyclistes, et aucune restriction).
La question c'est plutôt: highway=service ou residential? Je penche 
pour service car il n'y a plus rien d'autre connecté desservi que la 
voie de service privée vers le nord, l'usage des bus , et sinon les 
chemins piétons vers la forêt , il n'y a pas d'arrêt aménagé possible, 
même pas de stationnement latéral, c'est juste fait pour faire 
demi-tour autour de l'îlot.
Et aussi le nom de la rue doit être ramené dessus: c'est bien une voie 
publique (pour les bus et sinon les marcheurs vers la forêt), et 
l'allée privée vers le nord est aussi à l'adresse de cette rue.



Le ven. 24 janv. 2020 à 07:53, Arnaud Champollion 
> a écrit :


Le 24/01/2020 à 05:46, Philippe Verdy a écrit :
> peut-être une voie de service, mais pas sûr que ce soit réservé
> seulement aux bus

Non il n'y a pas de signalétique la réservant aux bus.

> , et dans ce cas c'est encore la fin de la rue résidentielle qui y
> arrive (et d'ailleurs ça se voit aux adresses FANTOIR, le Chemin du
> Marquis est en voie publique même si c'est une impasse avec un seul
> résident).

Donc ça devrait être en highway=residential avec surface=unpaved ? En
fait pour l'instant il y a highway=track à cause du
non-revêtement, mais
c'est peut-être justement une erreur.

> Au passage la boucle est mal alignée, elle passe un peu plus à
l'ouest
> (on la voit bien à travers les branches de arbres dessus à
l'extrémité
> de l'îlot, et le chmein du Marqui tombe bien sur cette boucle et
non
> sur le sentier allant vers l'ouest).

OK j'ai corrigé cela.


___
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] wiki JOSM : Mise en Forme de la page Fr:Help/Action/Help modifiée par anonyme

2020-01-26 Par sujet leni 


Le 20/01/2020 à 01:05, Philippe Verdy a écrit :
Je ne vois pas de changement de "mise en forme" hormis une 
wikification de liste avec des "*" (puces) au lieu des numéros (qui 
supposerait un ordre)

C'est somme toute mineur, et ça reste malgré tout une traduction conforme.
qui risque disparaitre s'il y a une modification de la page anglaise, 
j'espérais que la personne était sur la liste et ferait la modif 
également sur la page originale
Ceci dit ce n'est pas une "liste" valide puisque les éléments 
détaillés ont été "indentés" hors liste.
On peut proposer le changement correct (supprimer les numéros non 
significatifs par des puces, et non pas indenter le détail avec des 
espaces (qui créent un bloc de code) après chaque liste limitée à un 
seul item mais avec "*:", afin de conserver la liste non rompue, et en 
profiter pour supprimer les barres obliques inverses en fin de ligne) 
dans la page anglaise
Sans doute quelqu'un qui ne connait pas bien la syntaxe wiki et croit 
pouvoir l'utiliser correctement, mais à moitié en ne voyant pas que 
cela ne crée pas une vraie liste mais trois séparées, suivies chacune 
d'un bloc indenté.


Ce ne serait pas plutôt ":*" ?

Je n’arrives pas à faire ce dont tu parles ; pourrais-tu me l'indiquer 
sur cet extrait ?


 1. With the {{{F1}}} key anywhere.\\
   This invokes the help topic for the screen element under the mouse 
pointer.
   If that element has no own help topic, then the request is passed 
downwards to the surrounding screen element.
   Finally search ends at the [wikitr:/Help/MapView Map view] or 
[wikitr:/Help Main help] pages as last resorts.\\



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

Re: [OSM-talk-fr] Type de highway pour voie de bus

2020-01-26 Par sujet Georges Dutreix via Talk-fr 

Bonjour,

Le 23/01/2020 à 16:57, Philippe Verdy a écrit :
En France les piétons peuvent aller quasiment partout, sauf 
signalisation ou équipement spécial (sidewalk en est un) mais ils 
peuvent traverser partout et sont prioritaires. Les interdictions 
piétons sont matérialisées par les a signalisation (y compris les 
panneaux autoroute et voies express, et les barrières de séparation de 
chaussées). En zone urbaine ils ne sont même pas obligés de traverser 
seulement aux passages protégés (mais ils le font avec un partage des 
risques et les conducteurs sont malgré tout responsables des accidents 
car, eux seulement, sont couverts par des assurances obligatoires.


Le code de la route impose tout de même des choses aux piétons.
. Art 412-34 :
"Lorsqu'une chaussée est bordée d'emplacements réservés aux piétons ou 
normalement praticables par eux, tels que trottoirs ou accotements, les 
piétons sont tenus de les utiliser, à l'exclusion de la chaussée."


Art 412-37 :
"traverser la chaussée[...] Ils sont tenus d'utiliser, lorsqu'il en 
existe à moins de 50 mètres, les passages prévus à leur intention."


https://www.legifrance.gouv.fr/affichCode.do?idSectionTA=LEGISCTA06177125=LEGITEXT06074228=20100701



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