Re: [OSM-talk-fr] Demande de retours sur l'analyse Osmose d'intégration de la base Sirene

[Vincent Privat]

Quelques faux positifs à Toulouse:
- un salon de beauté indiqué 2 fois dans SIRENE, de chaque côté de la rue.
L'un sans nom, l'autre correctement nommé. Le nommé est bon, l'anonyme est
faux. Je suppose que le salon a déménagé à un moment.
- un garage auto (sans nom) qui était là dans les années 80, qui a déménagé
depuis à quelques centaines de mètres.
=> Je ne vois pas trop ce qu'on peut faire sans contrôle manuel. Peut être
ne pas indiquer les entrées sans nom ?

- un commerce de type restauration rapide qui vend aussi du pain. Osmose
l'indique manquant en tant que "Boulangerie et boulangerie-pâtisserie"
(shop=bakery + name="EAT'S TIME" en majuscule). Il est présent dans OSM en
tant que "amenity=fast_food" + "name=Eat's Time".
=> Faire un rapprochement sur des tags proches sémantiquement ?
=> Faire un rapprochement sur le nom (sans être sensible à la casse) ?

Sinon globalement ça me semble plutôt pas mal en l'état, je n'ai pas encore
trouvé de truc totalement farfelu.

Le mer. 10 juil. 2019 à 23:23, Frédéric Rodrigo  a
écrit :

> Bonjour,
> On essaye de tirer quelque chose de la base SIRENE pour enrichir OSM,
> mais ce n'est pas facile.
> Il y a depuis long temps une analyse cachée pour ça sur Osmose.
> On utilise en fait la base des établissements (SIRET) géocodé par
> Christian.
> On ne garde que les résultats géocodés à l'adresse avec un score d'au
> moins 90%.
> Uniquement certains types d'activités sont conservés, celles étant
> exécutées surplace et visible depuis la rue.
> Les types d'activités sont converti vers plusieurs tags possibles dans
> OSM pour recherche une correspondance (le SIRET est pour l'instant ignoré).
> On peut aussi filtrer le type d'activité sur le nombre de salariés pour
> augmenter la probabilité que l'activé soit faire sur place.
> Le mapping des tags :
>
> https://github.com/osm-fr/osmose-backend/blob/master/merge_data/shop_FR.mapping.json
> La recherche est faite à 50m.
> Le code de l'analyse :
>
> https://github.com/osm-fr/osmose-backend/blob/master/analysers/analyser_merge_shop_FR.py
>
> L'historique des échanges sur le sujet :
> https://github.com/osm-fr/osmose-backend/pull/338
> Les résultats :
> http://osmose.openstreetmap.fr/fr/errors/?item=8310=all
>
> http://osmose.openstreetmap.fr/fr/map/#item==all=14=44.92716=2.44844=1%2C2%2C3==
>
> Tous les retours sont les bien venue, les idées de filtre, les
> faux-positifs, les améliorations du mapping...
>
> Frédéric.
>
>
> ___
> 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] Demande de retours sur l'analyse Osmose d'intégration de la base Sirene

[Frédéric Rodrigo]

Bonjour,
On essaye de tirer quelque chose de la base SIRENE pour enrichir OSM, 
mais ce n'est pas facile.

Il y a depuis long temps une analyse cachée pour ça sur Osmose.
On utilise en fait la base des établissements (SIRET) géocodé par Christian.
On ne garde que les résultats géocodés à l'adresse avec un score d'au 
moins 90%.
Uniquement certains types d'activités sont conservés, celles étant 
exécutées surplace et visible depuis la rue.
Les types d'activités sont converti vers plusieurs tags possibles dans 
OSM pour recherche une correspondance (le SIRET est pour l'instant ignoré).
On peut aussi filtrer le type d'activité sur le nombre de salariés pour 
augmenter la probabilité que l'activé soit faire sur place.

Le mapping des tags :
https://github.com/osm-fr/osmose-backend/blob/master/merge_data/shop_FR.mapping.json
La recherche est faite à 50m.
Le code de l'analyse :
https://github.com/osm-fr/osmose-backend/blob/master/analysers/analyser_merge_shop_FR.py

L'historique des échanges sur le sujet :
https://github.com/osm-fr/osmose-backend/pull/338
Les résultats :
http://osmose.openstreetmap.fr/fr/errors/?item=8310=all
http://osmose.openstreetmap.fr/fr/map/#item==all=14=44.92716=2.44844=1%2C2%2C3==

Tous les retours sont les bien venue, les idées de filtre, les 
faux-positifs, les améliorations du mapping...


Frédéric.


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

Re: [OSM-talk-fr] Indiquer un croisement

[osm . sanspourriel]

Je suis d'accord : si on veut nommer une place place=square c'est fait
pour ça.

Éventuellement dans une relation si on veut à la fois le contour et les
les tronçons de route les traversant.

Maintenant s'il n'y a pas de trace sur le terrain, le polygone est sans
doute suffisant.

Une place sans nom affiché ? Il y a des cas étranges. Bah, on a bien des
noms officiels et des noms pratiques. Si vous cherches la place de
Gaulle à Brest mieux vaut avoir un plan que demander à un Brestois qui
par contre vous indiquera la place du Château sans problème.

Et une place c'est bien quelque chose de standard en Europe.

Le 09/07/2019 à 17:46, althio - althio.fo...@gmail.com a écrit :

Julien djakk:

Salut ! Regarde le cas sud-coréen ou japonais !

C'est ici :
https://wiki.openstreetmap.org/wiki/Named_spots_instead_of_street_names

Et... c'est le cas sud-coréen ou japonais !
C'est (très très) minoritaire en France, d'avoir des noms spécifiques
à de simples croisements/carrefours. Et où les noms des croisements
sont plus importants que le nom des rues.

Alors que une place, c'est significatif, en France et pays alentours.


avec https://wiki.openstreetmap.org/wiki/Tag:place%3Dsquare

C'est mon 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] Camera 360

[Stéphane Péneau]

Le 10/07/2019 à 20:21, Francois Gouget a écrit :

On Wed, 10 Jul 2019, Stéphane Péneau wrote:


Le 10/07/2019 à 12:18, Francois Gouget a écrit :

L'autre point faible c'est qu'elle n'a pas de GPS intégré. En même temps
sur les smartphones la position GPS semble parfois être rafraichie à une
fréquence inférieure à celle de la prise de photos ce qui se traduit par
des photos successives qui ont la même position.

La corrélation fait une interpolation entre les points, donc ce n'est
pas là qu'est le problème. Si 2 photos ont la même position, c'est
qu'elles ont le même timestamp.

Non !

D'abord ci-dessus je parlais des photos prises sur *smartphone*, par
l'application Mapillary, et non sur action cam.
Smartphone ou action cam, je fais presque toujours la géoloc en post 
processing, donc je n'ai pas ce souci.


Je suis assez d'accord avec toi pour les outils Mapillary, et je vois 
qu'on a des corrections en commun.


Je m'arrête là, parce qu'on devient hors sujet.



J'aurais critiqué le trou zénital mais en fait on voit quand même assez
bien les toits (pratique pour repérer corréler les chiens-assis entre
les photos et les vues aériennes).


Ajouter des caméras pour obtenir une sphère presque complète est sur ma 
todo-list. Ce n'est qu'une question de fabrication de la "tête photo", 
le reste est déjà prêt pour gérer 8 caméras.


Stf



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

Re: [OSM-talk-fr] Camera 360

[Francois Gouget]

On Wed, 10 Jul 2019, Stéphane Péneau wrote:

> Le 10/07/2019 à 12:18, Francois Gouget a écrit :
> >
> > L'autre point faible c'est qu'elle n'a pas de GPS intégré. En même temps
> > sur les smartphones la position GPS semble parfois être rafraichie à une
> > fréquence inférieure à celle de la prise de photos ce qui se traduit par
> > des photos successives qui ont la même position.
> 
> La corrélation fait une interpolation entre les points, donc ce n'est 
> pas là qu'est le problème. Si 2 photos ont la même position, c'est 
> qu'elles ont le même timestamp.

Non !

D'abord ci-dessus je parlais des photos prises sur *smartphone*, par 
l'application Mapillary, et non sur action cam.

Lorsque je transfère ces photos du téléphone vers l'ordinateur via USB 
ou un lecteur de carte microSD je me retrouve avec des photos qui ont 
des timestamps différents (et une précision sub-seconde) mais exactement 
les mêmes coordonnées GPS.

L'application Mapillary me fournit aussi un fichier GPX qui lui aussi 
contient des points consécutifs avec des timestamps différents mais 
exactement les mêmes coordonnées GPS.

C'est là que je fait l'interpolation avec une version modifiée des 
scripts mapillary_tools (vu que de base ils sont plutôt nuls), afin que 
chaque photo retrouve une position correcte.

  https://github.com/fgouget/mapillary_tools/commits/fgouget


Indépendament de cela, lorsque je regarde ma position sur Osmand parfois 
je voit un déplacement saccadé, comme si la position n'était rafraîchie 
qu'une fois par seconde. Donc je pense que ce qui se passe c'est que 
l'application Mapillary récupère la position GPS, prend la photo, tague 
la photo avec la position et continue en boucle comme ça. Mais comme je 
lui ai dit de prendre une photo tous les 5 m avec un interval minimum de 
0.9 s, parfois la position GPS n'a pas été rafraîchie entre deux photos. 
Il y aurait plusieurs solutions pour que l'application Mapillary évite 
le problème mais elles sont toutes un peu galère à mettre en oeuvre donc 
je comprends que les développeurs Mapillary ne se soient pas embêtés.


> J'ai beau faire du lobbying auprès des fabricants d'action cam pour 
> qu'ils ajoutent les millisecondes dans les données Exif, pour l'instant 
> je ne connais que la LG360 qui les intègre.

Un effort louable parce que c'est sûr que ça serait bien.


> >Pas sûr non plus que Mapillary prenne des photos de 66 Mpx.
> 
> Elles sont acceptées.
> 
> Bien qu'une partie de mes photos 360 équirectangulaire est du noir, les 
> photos 360 que j'envoie sont en 88 Mpx.
> Ce qui est casse-pied, c'est qu'il faut être vraiment patient pour que 
> le site affiche la qualité max, et qu'il faut zoomer un peu. Exemple :
> https://www.mapillary.com/app/?focus=photo=Nefc0jBo8GnL7ymGYH3Vew=47.08559283299879=-1.2745185315505512=17=0.7558841390338722=0.4895506122119632=0.3640677728864865=true=2019-04-15=2019-04-17

88 Mpx. C'est super cool !

J'aurais critiqué le trou zénital mais en fait on voit quand même assez 
bien les toits (pratique pour repérer corréler les chiens-assis entre 
les photos et les vues aériennes).

-- 
Francois Gouget   http://fgouget.free.fr/
 Any sufficiently advanced technology is indistinguishable from magic.
Arthur C. Clarke___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Camera 360

[Stéphane Péneau]

Le 10/07/2019 à 15:28, osm.sanspourr...@spamgourmet.com a écrit :


https://www.mapillary.com/app/?lat=47.08559283299879=-1.2745185315505512=17=0.7558841390338722=0.4895506122119632=0.3640677728864865=true=2019-04-15=2019-04-17 
répond :


/Sorry, we can't find the image you're looking for. Most likely, the 
image is still under processing and will be visible soon. Please check 
back later. If you need more help, //contact us 
//./



Ca devrait être mieux

https://www.mapillary.com/app/?lat=47.08559283299879=-1.2745185315505512=17=0.7558841390338722=0.4895506122119632=0.3640677728864865=true=2019-04-15=2019-04-17=Nefc0jBo8GnL7ymGYH3Vew=photo

/
/


Je n'arrive qu'à voir le timbre-poste./
/

Sinon, pixels noirs ou pas, un pixel c'est toujours un pixel. Tu 
voulais parler de Mo ?/

/

Non non, c'est juste que le nombre de pixel total ne correspond pas à la 
partie "utile"



Stf


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

Re: [OSM-talk-fr] Camera 360

[Stéphane Péneau]

Le 09/07/2019 à 15:02, Phyks a écrit :



Pour des comparaisons de rendu, je connais aussi 
http://www.stemani.fr/pano/Passy/Gear360.html / 
http://www.stemani.fr/pano/Passy/V4MPack.html / 
http://www.stemani.fr/pano/Passy/LG360.html (même scène avec une 
Samsung Gear 360, le V4MPack fait maison et une LG360).


J'ai fait un autre test. Pour comparer, vous pouvez vous amuser à zoomer 
sur l'horloge de l'église, ou les panneaux de la boucherie.


Samsung Gear 360 (2016) :
http://www.stemani.fr/pano/Vieillevigne/Gear360.html

Plusieurs Yi 2K
http://www.stemani.fr/pano/Vieillevigne/Yi_2K.html

Plusieurs Gitup G3 Duo 170°
http://www.stemani.fr/pano/Vieillevigne/G3_duo_150.html

Plusieurs Gitup G3 Duo 90° (assez longue à charger)
http://www.stemani.fr/pano/Vieillevigne/G3_duo_90.html

Pour cette dernière, je n'ai pas calculé le nbr exact de caméra 
nécessaire, mais il en faudrait plus de 10. Le résultat final est une 
image de . 145Megapixels !!

les artefacts rose/vert sont un bug de Hugin.

Stf



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

Re: [OSM-talk-fr] Camera 360

[Stéphane Péneau]

Le 10/07/2019 à 12:18, Francois Gouget a écrit :


L'autre point faible c'est qu'elle n'a pas de GPS intégré. En même temps
sur les smartphones la position GPS semble parfois être rafraichie à une
fréquence inférieure à celle de la prise de photos ce qui se traduit par
des photos successives qui ont la même position.


La corrélation fait une interpolation entre les points, donc ce n'est 
pas là qu'est le problème. Si 2 photos ont la même position, c'est 
qu'elles ont le même timestamp.
J'ai beau faire du lobbying auprès des fabricants d'action cam pour 
qu'ils ajoutent les millisecondes dans les données Exif, pour l'instant 
je ne connais que la LG360 qui les intègre.




   Pas sûr non plus que Mapillary prenne des photos de 66 Mpx.


Elles sont acceptées.

Bien qu'une partie de mes photos 360 équirectangulaire est du noir, les 
photos 360 que j'envoie sont en 88 Mpx.
Ce qui est casse-pied, c'est qu'il faut être vraiment patient pour que 
le site affiche la qualité max, et qu'il faut zoomer un peu. Exemple :

https://www.mapillary.com/app/?focus=photo=Nefc0jBo8GnL7ymGYH3Vew=47.08559283299879=-1.2745185315505512=17=0.7558841390338722=0.4895506122119632=0.3640677728864865=true=2019-04-15=2019-04-17


Stf


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

Re: [OSM-talk-fr] Données routières ouvertes en France

[osm . sanspourriel]

Le 10/07/2019 à 12:14, marc marc - marc_marc_...@hotmail.com a écrit :

Bonjour,

Le 09.07.19 à 09:31, Julien Minet a écrit :

Pour info, le but est de relier des rues (avec leur nom et attributs) à
des points lumineux (lampadaires) pour évaluer l'éclairage public.

et quelle source pour les lampadaires ?

Cordialement,
Marc


L'électricité, les becs à gaz se font rares de nos jours ;-).
https://taginfo.openstreetmap.fr/keys/lit_by_gaslight pour la France ^^

Je pense qu'il est bon et si la licence le permet d'ajouter lit=yes - ou
mieux - sur le jeu de données OSM quand la rue est effectivement
éclairée. Voir la position et la description des lampadaires.

Comme dit Christian, le taux de couverture d'OSM est largement suffisant
pour ça. Vont manquer par ci par là les voiries des derniers
lotissements, très probablement éclairés.

Si la source pour les lampadaires est bonne, on doit pouvoir chercher
les points lumineux trop loin d'une route OSM donnant un indice pour un
lotissement manquant dans OSM.

Jean-Yvon en zone lit=no et c'est tant mieux ;-)

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

Re: [OSM-talk-fr] Camera 360

[Francois Gouget]

On Tue, 9 Jul 2019, Magalie Dartus wrote:
[...]
> Voilà l’intention, par contre on ne sait absolument pas quelle caméra
> prendre pour ce projet
> Est-ce que certains d'entre vous ont déjà de l'expérience et pourraient
> nous conseiller sur des modèles adéquats?

J'utilise une Xiaomi Mi Sphere.
http://360rumors.com/mi-sphere-review/

https://www.mapillary.com/map/im/0yLujIYIbCC6Ygp4bOTu5g


Pour Mapillary le nerf de la guerre c'est la résolution afin de pouvoir 
lire le texte des panneaux et des enseignes des boutiques. Du coup le 
point fort de la Mi Sphere c'est sa résolution de 24 Mpx ce qui à ma 
connaissance est le maximum qu'on trouve sur les caméra 360 degrés grand 
public. Malgré tout 24 Mpx c'est pratiquement rien. Si on compte qu'une 
photo normale couvre un champ de 90 degrés, alors pour prendre une vraie 
photo 360 il faut 6 photos normales : devant, derrière, à droite, à 
gauche, haut, bas. Donc lorsqu'on zoome sur un panneau une photo 360 de 
24 Mpx fournit la même résolution qu'une photo normale de 4 Mpx :-(

C'est aussi pour cela que le mode vidéo des caméras 360 ne sert 
strictement à rien pour Mapillary : on démarre au mieux avec une 
résolution "4K", soit 8 Mpx, soit un équivalent de 1,3 Mpx pour une 
photo normale.

L'autre élément important pour Mapillary c'est la fréquence à laquelle 
on peut prendre des photos. Théoriquement la Mi Sphere peut prendre une 
photo toutes les 2 secondes. En pratique c'est plutôt 3 à 5 secondes :-( 
Il y a cependant un firmware beta qui permet de descendre à 2 à 3 
secondes.

  https://1drv.ms/u/s!AvPAszrzDmdOnkebA2oluaGbs_Hg

  puis voir "How to update by SD Card" :
  http://ez-team.com/xiaomi.html


L'autre point faible c'est qu'elle n'a pas de GPS intégré. En même temps 
sur les smartphones la position GPS semble parfois être rafraichie à une 
fréquence inférieure à celle de la prise de photos ce qui se traduit par 
des photos successives qui ont la même position. Du coup je préfère de 
toute façon reconstruire les positions GPS à partir d'une trace GPS et 
des timestamps des photos. C'est notamment indispensable pour les photos 
prises avec l'application Mapillary !

Donc c'est ce que je fait aussi pour les photos 360 et c'est 
l'application Mapillary qui me fournit le fichier GPX (et ça me donne en 
bonus des photos 12 Mpx "haute résolution" pointant vers l'avant). Par 
contre les timestamps des photos 360 ont une granularité d'une seconde. 
Pas idéal mais pas catastrophique non plus.

Sinon on peut alimenter la Mi Sphere via USB pendant qu'elle prend des 
photos. Suivant l'emplacement de la prise USB ce n'est pas toujours 
pratique avec d'autres caméras. Avec un pack de 1 mAh ça permet 
facilement de faire des séances de 8 heures.


Donc pour moi les critères de choix sont :
* Résolution >= 24 Mpx.
* Intervalle entre deux photos: aussi proche de 1 seconde que 
  possible.
* Possibilité de mettre une carte MicroSD (viser directement 128 Go).
* Possibilité d'alimentation USB pendant la prise de vue.
* GPS intégré ou résolution timestamps sub-seconde.

Malheureusment la plupart de ces informations sont introuvables :-(


Autres notes :

* L'Insta 360 One est assez similaire à la Mi Sphere et semblait aussi 
  avoir assez bonne réputation mais je ne sais pas si elle marche bien 
  pour Mapillary.

* À l'époque j'avais hésité entre la Mi Sphere et la Gear 360 de 2016 
  (la plus récente a perdu en résolution photo) mais cette dernière 
  n'avait pas de mode timelapse utilisable.

* Le prix de la Theta Z1 me paraît plutôt élevé vu qu'elle ne 
  fournit pas une meilleure résolution que les Mi Sphere, Gear 360 ou 
  Insta 360 One (pas X). Cela dit ses capteurs 1" devraient permettre 
  une meilleure qualité d'image, notamment moins de grain pour les 
  photos en basse lumière comme en intérieur où la nuit, conditions 
  qu'on ne rencontre normalement pas pour Mapillary. Je demande à voir 
  donc.

* Dans la même gamme de prix que la Theta Z1 (~$1200) il y a la 
  Ultracker Aleta S2C qui a une résolution de... 66 Mpx !
  http://360rumors.com/ultracker-aleta-s2c/

  Ce serait parfait pour Mapillary... si le reste des caractériques 
  suit. Par exemple dans le mode d'emploi on lit que le mode timelapse 
  permet de prendre des photos en 4K à 12K (66 Mpx) avec un intervalle 
  de 0,1 à 60 secondes, mais que l'intervalle dépend de la résolution...
  (par exemple à 2fps on est limité à 29 Mpx)
  Pas sûr non plus que Mapillary prenne des photos de 66 Mpx.

* Comparatif des caméras 360 :
  http://360rumors.com/best-360-cameras-virtual-tours/#feb2019

* Mapillary a un forum sur les caméras 360 :
  https://forum.mapillary.com/c/contributing-and-equipment/cameras


-- 
Francois Gouget   http://fgouget.free.fr/
   Cahn's Axiom: When all else fails, read the instructions.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Données routières ouvertes en France

[marc marc]

Bonjour,,

Le 09.07.19 à 09:31, Julien Minet a écrit :
> Pour info, le but est de relier des rues (avec leur nom et attributs) à 
> des points lumineux (lampadaires) pour évaluer l'éclairage public.

et quelle source pour les lampadaires ?

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

Re: [OSM-talk-fr] Bègles limite la vitesse dans ses rues à 30km/h

[Dominique Rousseau]

Salut la liste,

Le Tue, Jul 09, 2019 at 06:08:45PM +0200, Erwan [r...@gmx.fr] a écrit:
> Sur Port-Louis, ville à 30 km/h il y a des panneaux spécifiques ??ville 30??
> Dans un article le maire expliquait qu???une ville 30 impliquait
> obligatoirement une généralisation de la propriété à droite, ce qui a

La propriété est bien un concept plutôt "de droite", mais pour la
"priorité à droite", je pense que ce n'est qu'une recommandation dans le
cadre des "zones 30", puisque ça contirbue au ralentissement global des
véhicules.
Les "villes 30", ça n'a l'air d'être q'une initiative privée de
promotion de la limitation à 30 km/h en agglomération ("zone 30"
généralisée, donc).

> changé pas mal les habitudes et nécessité pas mal de gommage de cédez
> le passage au sol
> Je n???ai pas vérifié 
> 
> Les zones 30 impliquent une priorité au cycliste et piéton ??
> Je croyais que c???était juste pour les zones de rencontres (20 km/h) 

Les piétons ont toujours priorité, pour traverser une rue.
(sauf carrefours aménagés avec des feux)

Dans les "zones de rencontre", les piétons ont priorité sur la chaussée
(càd qu'ils ont tout autant le droit d'y circuler que les véhciules
motorisés)

En terme d'aménagement, ce qui est également recommandé pour la mise en
place d'une "zone 30", c'est de supprimer les marquages peints de
"passage piéton", car lorsqu'il y en a de matérialisé, il y a une
obligation de l'emprunter pour les piétons.
Lorsqu'il y en a pas, les piétons sont tout simplement autorisés à
traverser où ils le souhaitent, on est dans le cadre général du code de
la route.

-- 
Dominique Rousseau
d...@lee-loo.net - 06 82 43 12 27

A l'instant où l'esclave décide qu'il ne sera plus esclave,
ses chaînes tombent.  -- Mahatma Gandhi

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

Re: [OSM-talk-fr] piste cyclable connectée à un trottoir

[althio]

> Florian  :
> > traffic_signals=bicycle

marc marc :
> j'imagine que c'est https://www.openstreetmap.org/node/6400116392
> On peux avoir une photo du feu (sa lampe) ?
> cela permettrait de documenter cette valeur :)

Ou alors découper celle-là ;)
https://commons.wikimedia.org/wiki/File:Ampel-Kassel-02.jpg

Mais revenons un peu sur ce choix de tag :)

résumé "TLDR" :
j'ai fait mes devoirs, j'ai fait ma recherche, et je propose
maintenant, pour spécifier l'aspect cycliste-vélo :
cycleway=traffic_signals + [traffic_signals=signal]

[fin du "TLDR", vous entrez dans un long message de tagging]

Quand je vois la liste documentée sur le wiki, les valeurs proposées
https://wiki.openstreetmap.org/wiki/Key:traffic%20signals
ou les valeurs utilisées sur taginfo
https://taginfo.openstreetmap.org/keys/traffic_signals#values

j'ai bien du mal à voir l'intérêt et le sens de cette valeur
traffic_signals=bicycle.
Pour moi, c'est et ce sera encore :
traffic_signals=signal: a standard traffic signal, typically with
three steady aspects


Je reprends donc à la base de la documentation :
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_signals
highway=traffic_signals | Indicates traffic signals for cars.
crossing=traffic_signals | Indicates traffic signals for pedestrians.
Tout cela dénote une vision très centrée "voiture qui passe & piéton
qui traverse".

En fait, on pourrait plutôt considérer qu'il s'agit de "flux rapide"
(en highway=traffic_signals) et "flux traversant" (en
highway=crossing).
https://wiki.openstreetmap.org/wiki/Key:crossing mentionne la
possibilité que les vélos existent (mais pour traverser la grosse
route, pas pour être le flux rapide...)

Du coup, en flux rapide, il existe déjà :
sur le segment du flux rapide
- highway|railway=*
et sur le noeud à la jonction avec le flux traversant
- highway=traffic_signals + [traffic_signals=signal] (ou d'autres
trucs avec railway...)

et en flux traversant, on a :
sur le nœud à la jonction avec le flux rapide
- highway=crossing + crossing=traffic_signals|* + segregrated=yes|no +
bicycle=yes|no
avec plus de détails, on a aussi le segment du flux traversant
- highway=footway + footway=crossing
- et/ou highway=cycleway|* + bicycle=yes|designated + cycleway=crossing

(ouf...)

Dans cette idée, dans ce schéma-là, issu de la documentation actuelle,
mais pas du tout adaptée pour les cyclistes, je pense que la pièce
manquante, c'est pour le flux rapide à vélo :
sur le segment du flux rapide à vélo
- highway=cycleway|* + bicycle=yes|designated
sur le nœud à la jonction avec le flux traversant
- cycleway=traffic_signals + [traffic_signals=signal]

d'où ma suggestion "cycleway=traffic_signals", usage actuel : existant
mais négligeable

et...
tant pis pour le léger troll... j'espère faire comprendre ainsi mon
point de vue sur la vision destinataire ≠ type ≠ droit d'utilisation,
appliquée à votre sauce
[le troll rentre]
Quand je lis les définitions de traffic_signals=signal, blinker,
continuous_green...
Puis quand je vois ce tag traffic_signals=bicycle, j'imagine quoi ?
Le mécanisme qui régule le trafic et qui indique la priorité, c'est un
vélo, un vrai vélo réel, physique ?
[le troll sort]
Ou bien c'est un signal lumineux, standard, trois lumières, trois
couleurs. Donc "traffic_signals=signal".
Avec une forme de vélo.

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