Re: [OSM-talk-fr] Comment orthographier un nombre ordinal

[phyks]

À compléter avec la charte de toponymie de l'IGN également :

http://www.ign.fr/sites/all/files/charte_toponymie_ign.pdf

Souvent non respecté sur le terrain ceci dit, et le terrain prime...

Le 13 juin 2020 21:42:39 UTC+02:00, LeTopographeFou  
a écrit :
>Pour être plus précis deux extraits de ce lexique (dernière édition, 
>celle de 2002) :
>
>  * Abréviation des nombres ordinaux : on abrégera première, deuxième,
>   troisième... : 1re, 2e, 3e, et non 1ère, 2me ou 3ème... [Note : avec
>'re' et 'e' en exposant, difficile à retranscrire dans un mail]
>  * Il convient de rappeler que 1°, 2°, 3°... sont les abréviations de
>primo, secundo, tertio..., le signe supérieur étant un o et non un
>zéro.
>
>Cette règle de l'imprimerie nationale ne suffisant pas pour dire que 
>28ème soit une faute d'orthographe ;o) .
>
>LeTopographeFou
>
>Le 13/06/2020 à 21:27, Topographe Fou a écrit :
>> Selon les règles typographiques de l'imprimerie nationale (très bon 
>> bouquin que je recommande) : 28e . Cependant ce n'est pas rare de
>voir 
>> 28ème sur des documents officiels ou dans la presse écrite.
>>
>> LeTopographeFou
>> *De:* bernard.lefranc...@free.fr
>> *Envoyé:* 13 juin 2020 7:42 PM
>> *À:* talk-fr@openstreetmap.org
>> *Répondre à:* talk-fr@openstreetmap.org
>> *Objet:* [OSM-talk-fr] Comment orthographier un nombre ordinal
>>
>>
>> Bonjour,
>>
>> Je cherche la meilleure façon d'orthographier le "Quai du 28ème 
>> Bataillon de Chasseurs
>".
>>
>> 28ème comme ci-dessus avec accent (ma préférence)
>> 28Eme, 28Ème, 28E
>> Sans espace, avec espace.
>>
>> En tout cas la graphie actuelle 28° ma parait la pire.
>>
>> Qu'en pensez-vous?
>>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Hiérarchisation du réseau cyclable

[Phyks]

Bonjour,

Les relations sont souvent des itinéraires touristiques, mais pas
exclusivement. Elles représentent aussi cette notion de réseau (REV, RER
V, Chronovélo, etc). Par exemple
https://cycling.waymarkedtrails.org/#route?id=8664028=13!48.8583!2.3467.

Le network (lcn, rcn, ncn, icn) indique alors l'importance de
l'itinéraire (lcn si géré à l'échelle très locale, rcn pour un
itinéraire d'importance régionale type RER V, ncn pour des véloroutes
nationales et icn pour des Eurovelo).


Il y a d'ailleurs déjà des questions soulevées (sur talk-fr notamment)
pour classifier davantage ces relations (tourisme, utilitaire, course,
etc). Pour l'instant, la seule distinction existante est vélo ou VTT.

-- 
Phyks
Le 09/06/2020 à 13:58, Julien djakk a écrit :
> Merci marc, je vais jeter un œil là-dessus.
> 
> Bonjour Romain, en général ces itinéraires cartographiés avec une
> relation sont des itinéraires touristiques. Et merci : je ne savais
> pas qu'il existait une liste "vélo" ! :)
> 
> Julien "djakk"
> 
> Le mar. 9 juin 2020 à 12:51, Romain MEHUT  a écrit :
>>
>> Bonjour,
>>
>> N'est-ce pas déjà le cas avec les relations qui décrivent des itinéraires ?
>>
>> Romain
>>
>> Le 09/06/2020 à 12:35, Julien djakk a écrit :
>>> Bonjour tout le monde !
>>>
>>> Je souhaite hiérarchiser dans OpenStreetMap le réseau de pistes
>>> cyclables et de routes ouvertes au vélos. Comment faire ?
>>> Je pensais faire à la manière du réseau routier voitures :
>>> highway="primary", "secondary", etc. -> cycleway="primary",
>>> "secondary", etc. ? Bon cycleway étant déjà utilisé il faudrait une
>>> autre clé (cycleway:importance ?).
>>>
>>> On se retrouverait dans certains cas avec des voies
>>> highway="residential" + cycleway:importance="primary".
>>>
>>>
>>> Julien "djakk"
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 

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

Re: [OSM-talk-fr] Calcul d'itinéraire véhicule électrique

[Phyks]

Salut,

Pas directement clé en main, mais BRouter a un modèle dynamique pour le
calcul de véhicule (profil "car") : http://brouter.de/brouter-web/.

Son auteur joue notamment avec BRouter pour des véhicules électriques.
Quelques détails sur https://github.com/abrensch/brouter/issues/177
également. Il m'avait également fait une démo au SotM à Heidelberg l'an
dernier, mais je ne trouve pas trop de détails en ligne, à part
https://www.goingelectric.de/forum/viewtopic.php?t=26752 (en allemand).

-- 
Phyks
Le 15/04/2020 à 19:18, Noémie Lehuby via Talk-fr a écrit :
> Hello,
> 
> vous connaissez des solutions OSM pour calculer des trajets pour
> véhicules électriques (avec estimation de la décharge de la batterie en
> fonction du trajet, affichage des bornes, etc) ?
> 
> Je sais qu'il y a au moins A Better Routeplanner :
> https://abetterrouteplanner.com/
> mais s'il utilise bien OSM pour son calcul d'itinéraire, ce n'a pas
> l'air d'être le cas pour les bornes
> 
> -- 
> Noémie Lehuby
> Jungle Bus - http://junglebus.io
> 
> 
> ___
> 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] Ça reste ouvert : on a besoin de vous !

[Phyks]

Situation similaire, je l'ai traitée comme ça hier :
https://www.openstreetmap.org/changeset/82674882#map=17/48.81439/2.32267=N

Pas forcément idéal, mais je n'ai pas trouvé mieux sur l'instant.

Note : description:covid19 à privilégier à note:covid19, cf correction
d'Adrien derrière.

-- 
Phyks
Le 27/03/2020 à 11:40, Quentin Salles a écrit :
> Bonjour,
> J'ai en ma possession une liste exhaustive de plusieurs commerces,
> restaurants ainsi que les modalités de livraisons. Je compte faire la
> bascule sur OSM en dehors de mes horaires de travail.
> Pour les restaurants, il ne s'agit que de plats à emporter. Les commandes
> peuvent être faites à partir d'une certaine heure. Comment pourrait-on
> présenter l'information ?
> 
> Bonne journée
> 
> Quentin SALLES
> 
> 
> ___
> 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] Covid19 - Access tag

[Phyks]

Sauf qu'ici, contrairement aux horaires d'ouverture, les
"access:conditional" sont déjà utilisés dans d'autres circonstances et
rendues / traitées en conséquence (OSMAnd etc).

Les utiliser me semble permettre de mettre à jour les données et de les
diffuser rapidement, en minimisant le nombre de développements ad-hoc.

Il suffira ensuite de sortir une liste de tous les access:conditional
qui ont du "covid19" dedans et de faire la correction.
-- 
Phyks
Le 27/03/2020 à 12:59, JB a écrit :
> Le 27/03/2020 à 12:38, Florimond Berthoux a écrit :
>> Bonjour,
>> Comme vous le savez les parcs, certaines routes (canal en Seine st
>> Denis par exemple) ou plages sont fermés pendant le confinement.
>> Je vous propose de tagguer cela avec un simple :
>> access:conditional=no @ covid19
> Vous ne préféreriez pas faire comme pour les horaires d'ouverture,
> histoire que le jour où on nettoiera tout ça, ce soit plus simple ? Du
> genre :
> access:covid19=no (ou quelque chose du genre, avec une clé spécifique) ?
>> https://wiki.openstreetmap.org/wiki/Conditional_restrictions
>> Et joie de l’informatique, pour les routes et chemins si ça concerne
>> le vélo (acccess:conditional, vehicle:conditional,
>> bicycle:conditional) ça sera rendu en zoom 20 sur CyclOSM, exemple :
>> https://www.cyclosm.org/#map=20/48.89238/2.38817/cyclosm
>> Bien à vous.
>> -- 
>> Florimond Berthoux
> 
> 
> ___
> 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] Le trafic moyen c'est bien

[Phyks]

> S'agit-il des moyennes ou des normales saisonnières ?
> Le climat est réputé variable sur le temps long (sauf en ce moment), pas le
> trafic

Je parlais bien des normales saisonnières en effet. Concernant le
trafic, tant qu'il n'y a pas de remise en cause profonde du plan de
circulation, il devrait également être réputé variable sur le temps long.

Tout comme les normales saisonnières, on écarte les événements "rares"
(accidents / etc). La discussion serait d'ailleurs probablement plus
simple en zone rurale, dans un premier temps (moins de travaux /
déviations / remises en cause du plan de circulation).

Et j'ai par exemple en tête le cas d'usage typique de la D140 puis la
D140E2
(https://www.openstreetmap.org/way/261316880#map=15/45.6886/-1.0473=N),
petite route secondaire traversant des villages, limitée à 30 km/h, en
pleine zone balnéaire. Il est illusoire de la prendre en vélo l'été sans
y risquer sa vie.


> Pour le routier, une grandeur qui me semblerait d’intérêt serait le trafic
> prévu, qui lui est normalement public puisque partie du cahier des charges
> du maître d'ouvrage.
> Dans nos pays, les normes routières prévoient certains équipements en
> fonction du trafic, de la vitesse, etc...

C'est probablement le cas sur des axes majeurs et structurants
(autoroutes, nationales), mais est-ce le cas sur des déclinaisons
locales (départementales voire réseau communal) ?

Dans mes interactions avec les municipalités autour des questions de
trafic, je n'ai jamais entendu mes interlocuteurs parler de ces trafics
prévus. En revanche, ils font souvent des séances de comptage pour
calculer le trafic et calibrer des simulations pour les aménagements à
venir.

Dans tous les cas, toutes ces données fourniraient effectivement des
données "métier" d'assez bonne qualité a priori.

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

Re: [OSM-talk-fr] fermeture covid19 : suffisamment long pour être dans osm ?

[Phyks]

> Et on met des access=no sur les sentiers littoraux ? Je ne suis pas très
> chaud : là aussi ça peut changer vite.

Pour noter ça, il y a déjà une (bonne) solution (à mon avis) : les
access:conditional. Cf https://wiki.openstreetmap.org/wiki/Key:conditional.

-- 
Phyks

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

Re: [OSM-talk-fr] Le trafic moyen c'est bien

[Phyks]

>> Par contre ce qui m'intéresse et qui change peu dans le temps c'est le
>> trafic moyen.
>> Le trafic moyen est une grandeur physique mesurable et constant dans le
>> temps.
>>
> D'après ce qui est écrit au dessus je ne comprends pas ce point.
> Des événements imprévus et irrésistibles peuvent venir modifier le trafic,
> comment la moyenne pourrait être constante ?

De la même façon qu'en météo, nous avons des moyennes saisonnières. Il y
a potentiellement des écartements par rapport à ces valeurs, mais elles
représentent néanmoins une certaine grandeur constante dans le temps.

-- 
Phyks

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

Re: [OSM-talk-fr] Outil pour additionner longueur de ways ?

[phyks]

Attention à ne pas oublier oneway=-1 !

Le 7 novembre 2019 19:19:51 UTC+01:00, osm.sanspourr...@spamgourmet.com a écrit 
:
>Tu utilises la sélection par attributs pour récupérer toutes les rues
>oneway=yes à compter une fois, tu met la longueur L1 de côté.
>
>Tu utilises la sélection par attributs pour récupérer toutes les rues
>!oneway=yes à compter deux fois, tu met la longueur L2 de côté.
>
>Je vais l'hypothèse que tu n'as chargé dans JOSM que les rues qui
>t'intéressent.
>
>Et tu trouves un outil capable de te calculer L1 + 2 * L2 ;-)
>
>Le 07/11/2019 à 16:41, Shohreh - codecompl...@free.fr a écrit :
>> Phyks wrote
>>> Le plus simple (et sûr) est de compter le linéaire total (en
>filtrant les
>>> highways pour ne pas prendre les chemins privés etc) avec le sens de
>>> circulation en prenant :
>>> * La longueur des ways pour les ways à sens unique
>>> * La longueur des ways * 2 pour les ways à double sens (pas de
>oneway ou
>>> oneway=no)
>> Bien vu.
>>
>> Comment faire ?
>>
>>
>>
>> --
>> 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
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] L’enfer est pavé de bonnes intentions (clef mapillary id<>url)

[Phyks]

Donc qui/pq a-t-on besoin de la clef mapillary dans osm ?
à part pour entraîner une IA, je ne saisis pas quel réutilisation
les contributeur en font, hormis si quelqu'un se passionne par faire
les "match mapillary" et laisse le soin à un autre contributeur
d'ajouter les autres tag osm.


Je m'en suis servi récemment pour argumenter avec une collectivité 
(Montrouge) sur la nécessité d'avoir des données ouvertes et sur la 
qualité des données (stationnements vélos). OSM avait des données bien 
plus complètes que celles que la collectivité a bien voulu nous fournir. 
Face à la méfiance de la mairie envers OSM, je leur ai envoyé un tableau 
(requête Overpass exportée en CSV, avec quelques retouches) des 
stationnements vélos connus d'OSM à Montrouge.


Comme la plupart des stationnements vélos à Montrouge avait une clé 
Mapillary, il leur suffisait de cliquer dans le champ "Image" pour voir 
l'aperçu du parking en direct. C'était, je pense, plutôt convaincant sur 
la qualité des données, même s'il n'y a malheureusement pas 
particulièrement eu de suite...



Le 07.11.19 à 13:49, PanierAvide a écrit :
Pic4Review propose aussi de mettre en avant l'image désignée par la 
clé

mapillary=*, et de changer l'image si une autre est plus
récente/pertinente. Lier explicitement une image à un objet a du sens 
en

terme de réutilisation : plutôt que d'afficher 10 images moches et mal
cadrées, un humain a précisé que cette image est pertinente. Donc 
plutôt

pour l'utilisation de ce tag, et adapter nos outils pour que la donnée
reste à jour.

Adrien P.

Le 07/11/2019 à 13:43, Cyrille37 OSM via Talk-fr a écrit :

Le 07/11/2019 à 13:26, marc marc a écrit :
l'autre "piste" c'est de se demander de l'utilité de la clef 
mapillary

on y encode la meilleur image dispo au moment de l'encodage.
et puis ? demain quelqu'un recapture l'objet, plus à jour ou en 
meilleur

qualité, quelqu'un ou un outil va maintenir cette info à jour ?
quelqu'un cible les objets dans osm ayant la clef mapillary mais 
n'ayant
pas certains clefs (ex typique : l'accessibilité des passages 
piétons).
Pic4review montre bien qu'il n'y a pas besoin de codé en dur 
l'image,

on peux la récupérer quand on a besoin, sans besoin de maintenance


Je partage cet avis.

Cyrille37.


___
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


--
Phyks

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

Re: [OSM-talk-fr] Outil pour additionner longueur de ways ?

[Phyks]

Le 2019-11-07 14:43, Shohreh a écrit :

Trouvé : peut-être qu'OTurbo en est capable, mais JOSM peut le faire.

Après avoir ouvert le GPX et l'avoir converti en couche de données, il
suffit de sélectionner toutes les ways par CTRL+A : JOSM affiche le 
total

dans la barre d'état en bas.


Attention, le but est-il bien d'avoir la longueur des ways, ou la 
longueur des rues ?


J'ai récemment essayé de sortir la longueur total des rues d'une ville. 
Il y a une différence car certaines rues sont séparées en plusieurs ways 
dans OSM (terre-plein central par exemple). Le plus simple (et sûr) est 
de compter le linéaire total (en filtrant les highways pour ne pas 
prendre les chemins privés etc) avec le sens de circulation en prenant :

* La longueur des ways pour les ways à sens unique
* La longueur des ways * 2 pour les ways à double sens (pas de oneway ou 
oneway=no)


Bonne journée,
--
Phyks

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

Re: [OSM-talk-fr] CyclOSM, rendu cyclable libre

[Phyks]

> Y a t-il une difficulté particulière pour que la couche avec relief ne
> soit pas disponible sur le quart sud est de la France ?
> https://www.cyclosm.org/#map=6/44.088/6.240/cyclosm_relief

La couche avec relief actuellement présente est là juste pour donner un
aperçu actuellement. Ce sont de vieilles données et la couverture
spatiale est limitée.

La raison étant qu'on n'a pas pu remettre le relief en place
immédiatement en déplaçant vers les serveurs OSM-Fr. On a la plupart des
fichiers nécessaires et cette couche va donc prochainement disparaître
pour être fusionnée dans le rendu "de base" :)

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

Re: [OSM-talk-fr] CyclOSM, rendu cyclable libre

[Phyks]

>>> On distingue à peine les V70 et V74 au sud de Clermont-Ferrand (alors
>>> qu'il s'agit d'itinéraires nationaux), et on voit encore moins bien le
>>> GTMC en marron [https://www.openstreetmap.org/relation/3858890]

En effet, on pourrait probablement les marquer davantage à faible zoom !
On a créé un ticket pour ça
https://github.com/cyclosm/cyclosm-cartocss-style/issues/182 et c'est
donc prévu :)

>> Une solution à envisager :
>> Se reposer exclusivement sur la couche waymarkedtrails.
> 
> J'allais proposer un truc du même genre ( ne connaissant pas
> waymarkedtrails ;-) ) : proposer les itinéraires sous forme de couche
> (dés)activable (activé par défaut?)

C'est une autre piste, qui a l'avantage de se décharger de toute la
gestion des itinéraires cyclables, mais l'inconvénient qu'il est moins
pratique de gérer deux couches différentes pour les utilisateurs. On a
un ticket à ce sujet aussi d'ailleurs,
https://github.com/cyclosm/cyclosm-cartocss-style/issues/160.

La solution est probablement dans l'entre-deux, en affichant les routes
de façon très visible à faible zoom puis en les estompant (mais en les
gardant en légère surimpression) à faible zoom, pour essayer de convenir
à une majorité d'utilisateurs. Ceux qui voudront le détail exact des
routes à hauts zooms pourront activer Waymarked Trails (déjà disponible
comme surcouche sur https://www.cyclosm.org/ ou BRouter).

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

Re: [OSM-talk-fr] CyclOSM, rendu cyclable libre

[Phyks]

> Intersport, rue Graham Bell à Brest.

En effet, parce qu'il n'a aucun tag pour décrire qu'il propose des
services pour les vélos https://www.openstreetmap.org/way/603039137.
D'ailleurs, il n'apparaît pas non plus sur OpenCycleMap
https://www.opencyclemap.org/?zoom=18=48.4264=-4.4738=B
:)

Avec un service:bicycle:retail ou service:bicycle:repair
(https://wiki.openstreetmap.org/wiki/Tag:shop%3Dbicycle#Additional_keys), il
sera rendu avec une icône vélo.

On pourrait probablement rendre tous les shop=sports, avec une icône
différente (pour ne pas supposer qu'ils ont des services vélo), j'ai
créé un ticket sur Github pour le faire :
https://github.com/cyclosm/cyclosm-cartocss-style/issues/163.

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

Re: [OSM-talk-fr] CyclOSM, rendu cyclable libre

[Phyks]

Merci ! Aurais-tu un exemple de magasin de sport généraliste qui
n'apparaît pas ?

On filtre sur les tags de service vélo
(https://wiki.openstreetmap.org/wiki/Tag:shop%3Dbicycle#Additional_keys)
pour les afficher a priori, par exemple
https://www.cyclosm.org/#map=19/48.83007/2.37678/cyclosm.

-- 
Phyks
Le 21/09/2019 à 22:01, François a écrit :
> Le 21/09/2019 à 07:52, Phyks a écrit :
>> Nous avons pas mal avancé sur la question d'un rendu cyclable libre,
>> alternatif à OpenCycleMap, avec Florimond depuis nos derniers messages
>> en février dernier sur cette liste.
> 
> Félicitations pour cette initiative.
> 
> Si les magasins spécialisés en cycles apparaissent bien, les boutiques
> de sport généralistes présentes sur OSM, qui vendent et réparent
> également des vélos, sont absents de la carte. Je pense qu'il serait
> utile de les rajouter.
> 
> -- 
> François
> 
> 
> 
> ___
> 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] CyclOSM, rendu cyclable libre

[Phyks]

Bonjour à toutes et à tous,

Nous avons pas mal avancé sur la question d'un rendu cyclable libre,
alternatif à OpenCycleMap, avec Florimond depuis nos derniers messages
en février dernier sur cette liste.

Depuis, OSM-Fr a pu nous mettre en place un serveur pour le rendu monde
du style (un grand merci à l'asso !) et le style est donc désormais
visible pour le monde entier sur https://www.cyclosm.org/.

Le code est toujours libre et disponible sur
https://github.com/cyclosm/cyclosm-cartocss-style/. Les tuiles générées
par OSM-FR sont disponibles sur
https://dev.{s}.tile.openstreetmap.fr/cyclosm/{z}/{x}/{y}.png.


La motivation principale guidant les choix de rendus pour l'instant est
d'avoir un rendu adapté à tous les cyclistes cyclistes (urbains,
vélotaffeurs, ou cyclotouristes en rando) pour se repérer et s'orienter
à vélo. Ce rendu permet aussi aux contributeurs de repérer et identifier
les aménagements cyclables manquants. Ceci motive le rendu d'un certain
nombre d'éléments nouveaux tels que les ralentisseurs ou les sas vélos,
déjà traités, ou les cédez-le-passage-cycliste, à venir.


N'hésitez pas à ouvrir des tickets sur Github ou à commenter ici, nous
serions très intéressés par des retours sur cette première version.
Toute aide supplémentaire sur ce rendu est la bienvenue également :)

Pour ceux qui seront au State of the Map à Heidelberg, n'hésitez pas à
venir en discuter de vive voix à 17h aujourd'hui ! :)

Bonne journée !
-- 
Phyks

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

Re: [OSM-talk-fr] Chemins problématiques au Mont Saint-Michel

[Phyks]

> À vérifier, peut-être d'abord remplacer le footway par un track et lui
mettre en plus un trail_visibility=no ?

Bien vu. J'y étais récemment et ça me semble bien adapté ! (mais ça ne
règle pas les problèmes de restriction d'accès :/)


> https://wiki.openstreetmap.org/wiki/Rennes/Archives

Merci pour le lien, je n'étais pas tombé dessus ! J'ai donc mis
access=no, tidal=yes (cf
https://help.openstreetmap.org/questions/57094/what-tags-to-use-for-a-way-only-accessable-at-low-tide)
et un accès conditionnel. Sur ce dernier, il n'y a qu'un seul cas
d'usage pour l'instant dans le monde
https://taginfo.openstreetmap.org/tags/access%3Aconditional=yes%20%40%20(low%20tide)#overview
:/

Tout est mis à jour sur https://www.openstreetmap.org/way/357431172. Si
quelqu'un a plus d'idées pour améliorer, je suis preneur !

Merci !
-- 
Phyks
Le 04/09/2019 à 16:40, 19b350d2-b1b3-4edb-ad96-288ea1238eee--- via
Talk-fr a écrit :
> Je vois ceci sur le wiki:
> "
> Traitements des côtes (avec les marées) :
> chemins inaccessible par marée basse : la page de référence est 
> Conditional_restrictions, préciser chemin access=no pour éviter le routage et 
> ajouter une condition low_tide.
> "
> https://wiki.openstreetmap.org/wiki/Rennes/Archives
> 
> On 9/4/19, 16:03 Phyks  wrote:
> 
> Bonjour à tous,
> 
> Je viens de voir ce chemin
> 
> https://www.openstreetmap.org/way/357431172/history#map=13/48.6590/-1.4996=N
> présent autour du Mont Saint-Michel. Il s'agit, j'imagine, plus ou moins
> du chemin emprunté à marée basse par les guides à pied.
> 
> Malgré les pénalités possibles (surface=mud, etc), il constitue un tel
> raccourci par rapport au tour de la baie par Avranches qu'il est
> quasiment systématiquement pris par les routeurs. Pourtant, il n'est pas
> vraiment empruntable sans guide et pas du tout empruntable à marée haute.
> 
> À ma connaissance, il n'y a d'ailleurs pas vraiment de chemin tracé au
> sol à cet endroit. Du coup, devrait-on le supprimer ?
> 
> Sinon, comment faire en sorte qu'il soit bien taggé comme n'étant pas
> empruntable pour corriger ceci ?
> 
> Bonne journée,
> -- 
> Phyks
> 
> ___
> 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

[OSM-talk-fr] Chemins problématiques au Mont Saint-Michel

[Phyks]

Bonjour à tous,

Je viens de voir ce chemin
https://www.openstreetmap.org/way/357431172/history#map=13/48.6590/-1.4996=N
présent autour du Mont Saint-Michel. Il s'agit, j'imagine, plus ou moins
du chemin emprunté à marée basse par les guides à pied.

Malgré les pénalités possibles (surface=mud, etc), il constitue un tel
raccourci par rapport au tour de la baie par Avranches qu'il est
quasiment systématiquement pris par les routeurs. Pourtant, il n'est pas
vraiment empruntable sans guide et pas du tout empruntable à marée haute.

À ma connaissance, il n'y a d'ailleurs pas vraiment de chemin tracé au
sol à cet endroit. Du coup, devrait-on le supprimer ?

Sinon, comment faire en sorte qu'il soit bien taggé comme n'étant pas
empruntable pour corriger ceci ?

Bonne journée,
-- 
Phyks

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

Re: [OSM-talk-fr] fin à venir du rendu osm.org pour shop=yes

[Phyks]

> - soit, option JB, on considère qu'une station service a aussi une autre
> activité et shop=yes est adapté (le POI apparaitra comme station
> service, on n'a pas "besoin" du point shop)

Pourquoi shop=yes conviendrait ? Il n'est pas question de rendu mais de
description de la station service, et shop=yes me paraît assez imprécis
dans ce cas. En pratique, une station-service, si elle a un magasin
associé, vend des produits bien définis, en général du gaz, de
l'alimentation de base (gâteaux / chips) et des produits automobiles
(essuie-glaces, liquides divers).

Du coup, un shop=convenience;gas me semble plus précis et correct, y
compris s'il est sur le même nœud que l'amenity=fuel.

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

Re: [OSM-talk-fr] fin à venir du rendu osm.org pour shop=yes

[Phyks]

> Avec quel tags pour la boutique ? shop=yes en complément d'une station
> service, ça me semblait bien défini :
> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dfuel#Additional_services

J'aurais mis shop=convenience (pour les boutiques) ou shop=kiosk (si
c'est uniquement un kiosque de paiement pour l'essence).

https://www.openstreetmap.org/node/25214143 par exemple.

-- 
Phyks

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

Re: [OSM-talk-fr] 15 bougies pour OSM !

[Phyks]

Salut,

> Il est relativement aisé de rajouter un restaurant, un point de vue, une
> fontaine ou des toilettes avec un smartphone ; en revanche, utiliser
> Osmose nécessite un ordinateur (qui est un objet qui a tendance à
> disparaître au sein des familles) et une grosse expérience de
> contribution. Si je prends mon cas, excepté lors des missions 'dégommons
> du rouge' (ajouter des chemins près des habitations), je n'utilise quasi
> jamais Osmose car il y a trop d'informations, de cas différents ou je ne
> sais pas corriger.
> 
> Idéalement, il faudrait faire des missions ciblées (ou des projets du
> mois) avec les liens qui vont bien sur Osmose afin de faciliter le
> travail par des contributeurs avancés en devenir.

J'ai découvert depuis quelques temps qu'Osmose dispose d'un flux RSS par
utilisateur. Pour moi par exemple, c'est

http://osmose.openstreetmap.fr/byuser/Phyks.rss

Un des gros avantages est (qu'en temps normal), on a ainsi des
signalements en continu par Osmose, quelques heures après ses
modifications. C'est bien plus pratique et motivant de corriger 2/3
trucs assez bien identifiés au fil de l'eau que de se plonger dans une
mer de signalements dans une zone.

Peut être un mode de fonctionnement d'Osmose à publiciser plus ?

-- 
Phyks

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

Re: [OSM-talk-fr] Epreuve Cyclo-randonnée Paris-Brest-Paris dans OSM

[Phyks]

Finalement, ma modification précédente n'était pas suffisante. Vu que je
n'ai pas de nouvelles de l'auteur initial et qu'il y avait plutôt
consensus pour la suppression,

* J'ai supprimé les relations, dans
https://www.openstreetmap.org/changeset/72847934.
* J'ai déplacé les tracés dans une Umap, ici
https://umap.openstreetmap.fr/fr/map/paris-brest-paris-randonneur_351758
-- 
Phyks

Le 15/07/2019 à 14:30, Vincent de Château-Thierry a écrit :
> 
>> De: "Phyks" 
>>
>> Dans le cas d'événements ponctuels (et non repérables sur le
>> terrain), je te rejoins et je supprimerais bien.
> 
> D'accord aussi pour la suppression, quitte à transférer le tracé dans umap, 
> bien plus adapté à mettre en scène un tracé lié à un évènement. On pourrait 
> fournir un lien d'édition à l'auteur initial de la relation OSM, pour qu'il 
> puisse maintenir son travail si besoin.
> 
> vincent
> 
> ___
> 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] Demande de retours sur l'analyse Osmose d'intégration de la base Sirene

[phyks]

> Il s'agit d'un entrepreneur individuel... à filtrer globalement de mon point 
> de vue car cela génère bien trop de bruit.

Ne pourrait-on pas filtrer par type d'activités ? Sinon on va perdre toutes les 
professions libérales de santé qui avaient l'air très intéressante à récupérer 
par SIREN (mais peut être qu'il y a d'autres bases exploitables) ?

C'est le seul cas d'entreprises individuel pour lesquelles je vois un intérêt 
pour l'instant. 

Le 29 juillet 2019 18:06:16 UTC+02:00, Christian Quest 
 a écrit :
>Le lun. 29 juil. 2019 à 16:07, Phyks  a écrit :
>
>> Salut Fred,
>>
>> Quelques remontées de plus sur Sirene :
>>
>> 1. J'ai des entreprises radiées qui apparaissent. Par exemple,
>> https://osmose.openstreetmap.fr/fr/error/30133361229 mais qui a été
>> radiée en mars 2019 normalement :
>> https://www.societe.com/societe/les-p-tites-pupilles-789829991.html.
>> Peut être que ça vient des données sources qui ne sont pas assez
>> fraîches ceci dit.
>>
>>
>Là aussi WARNING... l'INSEE diffuse désormais toutes les entreprise (et
>leurs établissements), actifs ou non (radié, etc).
>Je ne sais pas si l'analyse osmose prends bien ça en compte dans les
>données source.
>
>Pour le cas présent l'entreprise est toujours active d'après l'INSEE:
>https://avis-situation-sirene.insee.fr/ListeSiretToEtab.action?form.siren=789829991=00015
>
>Attention, radié d'un greffe ne veut pas dire que l'entreprise n'existe
>plus, elle est peut être rattachée à un autre greffe ;)
>Oui, c'est le bazar et difficile de s'y retrouver !
>
>2. J'ai des rapprochements non faits liés au type de POI:
>> - https://osmose.openstreetmap.fr/fr/error/30133356361 annoté
>> dans OSM
>> comme un shop=deli.
>> - https://osmose.openstreetmap.fr/fr/error/30133363991 annoté
>> dans OSM
>> comme un amenity=restaurant.
>>
>> 3. J'ai des hôtels qui apparaissent qui n'en sont pas (société accolé
>à
>> un Airbnb ?), par exemple
>> https://osmose.openstreetmap.fr/fr/error/30133362002. Le site SIRENE
>> (
>>
>https://avis-situation-sirene.insee.fr/ListeSiretToEtab.action?form.nic=00020=432216802
>> )
>> donne un effectif nul. Peut être qu'on peut les filtrer comme ça ?
>>
>>
>Il s'agit d'un entrepreneur individuel... à filtrer globalement de mon
>point de vue car cela génère bien trop de bruit.
>
>
>4. J'ai une agence de voyage qui est en fait le siège de MSC Croisière
>> (https://osmose.openstreetmap.fr/fr/error/30133364947). Pas trop
>d'idées
>> pour filtrer ça, à part peut être en ayant des valeurs "typiques"
>> d'effectifs pour différents types de POIs (shop=travel_agency avec >
>100
>> personnes est sûrement louche).
>>
>> 5. J'ai des sociétés qui ont été liquidées qui apparaissent
>> (https://osmose.openstreetmap.fr/fr/error/30133364905 par exemple, cf
>> https://www.societe.com/societe/croisiere-jaune-441382231.html), je
>ne
>> sais pas trop si ça peut être filtré.
>>
>>
>C'est SIRENE qui n'est pas à jour... indiquée comme "actif"
>
>
>6. social_facility=assisted_living devrait être en synonyme de
>> social_facility=group_home, cf
>> https://osmose.openstreetmap.fr/fr/error/3013339 et
>> https://www.openstreetmap.org/way/83234566.
>>
>>
>> C'est ce que je vois de plus évident pour l'instant et responsable
>d'une
>> bonne majorité de faux positifs. Je pourrais jeter un œil plus dans
>le
>> détail.
>>
>>
>-- 
>Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Phyks]

Salut Fred,

Quelques remontées de plus sur Sirene :

1. J'ai des entreprises radiées qui apparaissent. Par exemple,
https://osmose.openstreetmap.fr/fr/error/30133361229 mais qui a été
radiée en mars 2019 normalement :
https://www.societe.com/societe/les-p-tites-pupilles-789829991.html.
Peut être que ça vient des données sources qui ne sont pas assez
fraîches ceci dit.

2. J'ai des rapprochements non faits liés au type de POI:
- https://osmose.openstreetmap.fr/fr/error/30133356361 annoté dans OSM
comme un shop=deli.
- https://osmose.openstreetmap.fr/fr/error/30133363991 annoté dans OSM
comme un amenity=restaurant.

3. J'ai des hôtels qui apparaissent qui n'en sont pas (société accolé à
un Airbnb ?), par exemple
https://osmose.openstreetmap.fr/fr/error/30133362002. Le site SIRENE
(https://avis-situation-sirene.insee.fr/ListeSiretToEtab.action?form.nic=00020=432216802)
donne un effectif nul. Peut être qu'on peut les filtrer comme ça ?

4. J'ai une agence de voyage qui est en fait le siège de MSC Croisière
(https://osmose.openstreetmap.fr/fr/error/30133364947). Pas trop d'idées
pour filtrer ça, à part peut être en ayant des valeurs "typiques"
d'effectifs pour différents types de POIs (shop=travel_agency avec > 100
personnes est sûrement louche).

5. J'ai des sociétés qui ont été liquidées qui apparaissent
(https://osmose.openstreetmap.fr/fr/error/30133364905 par exemple, cf
https://www.societe.com/societe/croisiere-jaune-441382231.html), je ne
sais pas trop si ça peut être filtré.

6. social_facility=assisted_living devrait être en synonyme de
social_facility=group_home, cf
https://osmose.openstreetmap.fr/fr/error/3013339 et
https://www.openstreetmap.org/way/83234566.


C'est ce que je vois de plus évident pour l'instant et responsable d'une
bonne majorité de faux positifs. Je pourrais jeter un œil plus dans le
détail.

Bonne journée,
-- 
Phyks

Le 21/07/2019 à 01:10, Frédéric Rodrigo a écrit :
> Le 20/07/2019 à 19:13, Phyks a écrit :
>> Salut,
>>
>> J'ai jeté un œil à Montrouge, il y avait pas mal de faux positifs,
>> principalement des entreprises individuelles positionnées sur
>> l'habitation du propriétaire
> 
> Pour l'instant il n'y a que quelque types d'activités pour les quelles
> les entreprises individuelles sont ignorées.
> 
> On peut le généraliser.
> 
> Des avis sur la question sont bien venu.
> 
> 
>> ou avec des tags proches non trouvés
>> (restaurants / bars notamment).
> 
> Il faut remonter ça pour améliorer le mapping, et avoir moins de faux
> positifs.
> 
> https://github.com/osm-fr/osmose-backend/blob/master/merge_data/shop_FR.mapping.json
> 
> 
> 
>> Il y a pas beaucoup de choses intéressantes une fois ceci filtré,
>> notamment pour les professions libérales (dentistes etc).
>>
>> Deux remarques sur la forme :
>>
>> * dans le frontend, le numéro SIRET est cliquable mais renvoie
>> systématiquement vers une page d'erreur. Ce n'est pas le plus pratique,
>> et j'avais toujours un autre onglet pour chercher les SIRET du coup.
> 
> Normalement c'est déjà corrigé depuis mercredi. Il peut en manquer mais
> ça en trouve aussi.
> 
> 
>> * serait-il possible de systématiquement afficher le nom de l'entreprise
>> dans les erreurs dans le frontend Osmose ? On pourrait économiser
>> quelques clics / recherches sur le SIRET comme ça.
> 
> Quand il y un nom c'est affiché.
> 
> 

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

Re: [OSM-talk-fr] Une secondary en zone de rencontre ?

[Phyks]

> @althio mais on s'en fou complet du contexte réglementaire pour le routing
> en encore plus sur OSM et ça se voit encore mieux sur les voies verte et
> sur les "route pour automobile". D'où les conflit d’édition systématique...
> C'est bien pour ça que cette notion n'est pas à spécifier comme tel. De
> plus pour les panneaux il y a ce qu'il faut pour les ajouter.

Il faut quand même garder à l'esprit que le contexte réglementaire
implique un biais piéton (qui peut circuler où bon lui semble, y compris
sur la chaussée, avec une priorité absolue et renforcée), qu'il est
important de conserver pour le routage. Il n'y a pas que le routage
automobile et clairement, un routage piéton devrait préférer passer par
cette place dite "apaisée" plutôt que de faire un tour en longeant une
grande avenue passante.

Il n'y a pas que le routage, et vis-à-vis des restaurants (et leurs
terrasses) installés sur la place, ils préféreraient probablement
apparaître autour de petites routes qu'au bord d'une secondary passante.

Quand à la puissance publique qui a fait cet aménagement, nulle doute
que pour elle cela doit apparaître comme apaisé et parfaitement calme et
sans transit.

Eux aussi pourraient verrouiller le système de la même façon. Tâchons
d'avoir une description aussi neutre et objective de cette chose, en
gardant en tête que :
- réglementairement, un cadre légal spécifique s'y applique. Priorité
absolue aux piétons, c'est potentiellement apaisé.
- sur le terrain, le plan de circulation est cassé et cet espace est sur
un axe de transit.

> Pourtant on n'a pas de highway=greenway pour les voies vertes
> et les routes pour automobiles sont mélangé avec des voies rapide
> intercommunales et des nationales à deux voies...

On a bien le highway=path + bicycle=designated + foot=designated qui
recouvre bien ça. On peut même rajouter des motor_vehicle=destination ou
maxspeed pour raffiner des aménagements étranges du point de vue de la
loi. Ici, on parle de choses qui ne sont pas régies uniquement par des
tags d'accès (ni de vitesses) puisqu'il s'agit de régimes de priorité
spécifiques.

Comme le montre bien certains panneaux européens, dans l'absolu, un
enfant devrait pouvoir jouer au foot sur une place en zone de rencontre,
sans risques.
https://www.lemonde.fr/blog/transports/2016/04/23/dessine-moi-une-zone-de-rencontre/


> Encore une fois (et on en a parlé plusieurs fois) si l'on veut inscrire
> cette notion réglementaire il faut le faire d'une autre manière.
> source:maxspeed le permet aussi et zone:maxspeed également pour les zone 30
> sauf que comme c'est si bien mentionné dans les précédente discussion le
> contexte réglementaire ne porte pas que sur la vitesse.
> En fait le contexte réglementaire permet de définir des notions exploitable
> en routing en y définissant des valeurs implicites qui sont complétées ou
> corrigées par des panneaux supplémentaires. (qui dans certains cas sont mis
> à la suite d’arrêté et de décret d'application) On mentionne pas les
> décrets dans OSM (lol) mais on peut mettre ça dans description ;-)

Non, source:maxspeed etc sont des tags à destination des contributeurs.
Il est très utile d'avoir les arrêtés référencés dans les
source:maxspeed des zones 30 (c'est le cas souvent à Paris), mais ça
n'est ni exploitable facilement, ni la même chose. Ici, on ne parle pas
de source réglementaire mais de régime de priorités.

Dans ce cas, en poussant à l'extrême, on devrait avoir un
highway=pedestrian avec des tags d'accès pour les autres modes de
transport… et c'est un highway=living_street.

> Si on parle de contexte réglementaire les zones urbaines à 50 km/h c'est
> aussi du réglementaire et on n'a pas créé un tag pour cela pour autant sur
> les tronçons de voie.
> Bref cette notion, si elle gène le schéma, (histoire de pas frustré les
> gens) doit pouvoir être mentionné autrement
> 
> PS: coté réglementaire on à aussi des spécificités sur les chemins de
> halage, chemin communaux, chemin ruraux , chemin de servitudes, j'en passe
> car le sujet n'est pas traité pour le moment. Plus toutes les
> particularités pouvant être prises par arrêté et décret...
> Je vais encore sortir sur sujet mais on à également le libre choix laissé
> au département de choisir la vitesse de circulation sur route rural. (
> Va t'on avoir un nouveau panneau à l'entrée des départements pour indiquer
> le choix de vitesse? On va donc devoir trouver des clés spécifiques pour
> mentionner aussi ces éléments...

On a déjà des relations pour indiquer les vitesses par défaut sur les
pays, on pourrait faire de même sur les départements. Les zones urbaines
à 50km/h, on les note avec maxspeed. Et encore une fois, ce ne sont que
des vitesses et oui, on a un tag pour ça qui s'appelle maxspeed.

> Pour moi le contexte réglementaire on l'a aussi bien en mettant
> highway=living_street ou living_street=yes. Sauf que actuellement le
> premier cas casse le routing en mode itinéraire équilibré. Le deuxième
> évite de dégrader le 

Re: [OSM-talk-fr] Uniformiser le wiki "Bicycle" (était Re: Sidewalk:bicycle dans le wiki bicycle)

[Phyks]

Au passage, concernant les trottoirs, je découvre aussi un
cycleway=sidewalk
(https://taginfo.openstreetmap.org/tags/cycleway=sidewalk#overview),
2000 utilisations de par le monde dont un quart en France.

Par exemple celle-ci
https://www.openstreetmap.org/way/272012085#map=17/48.81403/2.30518, qui
correspondrait en réalité au cas S4 (avec une bidirectionnelle).

Le même type d'aménagement un peu plus loin est plutôt taggé comme une
voie verte
https://www.openstreetmap.org/way/688840446#map=18/48.81655/2.31303,
avec ses défauts.

Il me semble assez important du coup de raffiner et repréciser les cas
S3, S4 et TMP/NULL pour homogénéiser ces taggings et pouvoir le
pénaliser correctement dans les routeurs et autres outils.

-- 
Phyks

Le 24/07/2019 à 16:36, Phyks a écrit :
>> Il est vrai qu'à première vue on peut penser que l'illustration ne
>> correspond pas. En réalité sur le terrain il y a des pictogrammes vélos
>> sur le trottoir, mais on les voie pas sur la photo. Peut-être devrais-je
>> reprendre des photos à cet endroit ?
> 
> Je veux bien plus de détails sur cet aménagement, car je ne comprends
> pas très bien. Je ne comprends pas non plus pourquoi il y aurait des
> pictogrammes vélos avec une signalisation "pied à terre". Dans tous les
> cas, "cyclistes pied à terre" m'interdirait de tagguer cela comme un
> aménagement cyclable.
> 
> Un trottoir peut être cyclable, c'est le cas de toutes les pistes autour
> d'ici : https://www.openstreetmap.org/#map=19/49.65218/-1.58044, qui
> sont annotées comme des cycleway simples pour l'instant, comme le cas S3/S4.
> 
>> Mais, paradoxalement, le panneau démontre bien la problématique de ce
>> type d'aménagement : un trottoir ne peut pas être cyclable !
>>
>>> 2. Suite à la discussion qui avait eu lieu sur talk-fr, on avait convenu
>>> de tagger les parkings "deux roues" (ouverts aux vélos mais aussi aux
>>> scooters) comme
>>> https://wiki.openstreetmap.org/wiki/Montrouge#Stationnements_deux_roues
>>> (ce qu'on a adopté à Montrouge). Que pensez-vous de reporter cette
>>> documentation dans la page FR:Bicycle ?
>>
>> Ça me semble logique.
> 
> 
> C'est ajouté !
> 
> ___
> 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] Une secondary en zone de rencontre ?

[Phyks]

> il faut s'assurer que le rendu sera au rendez-vous pour favoriser d'autres 
> itinéraires a priori équivalents et surtout que des applis routières style 
> OsmAnd avertissent du danger/changement de statut de la route. En utilisant 
> un tag à la marge on perd de toute évidence cette possibilité.

C'est le principal truc qui me freine pour l'instant. En regardant
rapidement, j'ai vu que ce n'était pas supporté par BRouter
(https://github.com/abrensch/brouter/issues/174) et on m'a renvoyé vers
https://github.com/gravitystorm/openstreetmap-carto/issues/3514 qui est
plutôt négatif pour openstreetmap-carto.

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

Re: [OSM-talk-fr] simples pictogrammes vélo, pas de voies dédiées [était: Uniformiser le wiki "Bicycle"]

[Phyks]

> Tes explications me semblent logiques, je suis curieux de voir comment
> insérer cela dans la documentation.

Je viens de faire une tentative dans

https://wiki.openstreetmap.org/w/index.php?title=User:Phyks/FR:Bicycle=1881468=1881462

-- 
Phyks

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

Re: [OSM-talk-fr] Uniformiser le wiki "Bicycle" (était Re: Sidewalk:bicycle dans le wiki bicycle)

[Phyks]

> Il est vrai qu'à première vue on peut penser que l'illustration ne
> correspond pas. En réalité sur le terrain il y a des pictogrammes vélos
> sur le trottoir, mais on les voie pas sur la photo. Peut-être devrais-je
> reprendre des photos à cet endroit ?

Je veux bien plus de détails sur cet aménagement, car je ne comprends
pas très bien. Je ne comprends pas non plus pourquoi il y aurait des
pictogrammes vélos avec une signalisation "pied à terre". Dans tous les
cas, "cyclistes pied à terre" m'interdirait de tagguer cela comme un
aménagement cyclable.

Un trottoir peut être cyclable, c'est le cas de toutes les pistes autour
d'ici : https://www.openstreetmap.org/#map=19/49.65218/-1.58044, qui
sont annotées comme des cycleway simples pour l'instant, comme le cas S3/S4.

> Mais, paradoxalement, le panneau démontre bien la problématique de ce
> type d'aménagement : un trottoir ne peut pas être cyclable !
> 
>> 2. Suite à la discussion qui avait eu lieu sur talk-fr, on avait convenu
>> de tagger les parkings "deux roues" (ouverts aux vélos mais aussi aux
>> scooters) comme
>> https://wiki.openstreetmap.org/wiki/Montrouge#Stationnements_deux_roues
>> (ce qu'on a adopté à Montrouge). Que pensez-vous de reporter cette
>> documentation dans la page FR:Bicycle ?
> 
> Ça me semble logique.


C'est ajouté !

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

Re: [OSM-talk-fr] Une secondary en zone de rencontre ?

[Phyks]

> C'est normalement la propos a été rejeté au vote en 2009... On oubli
> souvent qu'OSM sert à faire du routing... D'ailleurs sur la page c'est pas
> rejeté en soit c'est juste que l'on préfèrera quand c'est le cas utiliser
> highway=living_street plutôt que le couple highway=residential|service +
> living_street=yes
> Key:living_street — OpenStreetMap Wiki
> <https://wiki.openstreetmap.org/wiki/Key:living_street>
> Il est considéré comme trolltag ce qui n'est pas le cas!

J'aime pas mal highway=secondary + living_street=yes ici. Ça fait pas
mal la distinction entre le cadre légal et la réalité de l'aménagement.
On définit bien :

* Que c'est une secondary, avec le trafic (et le transit !) associé !
* Qu'il y a un aménagement de type "living_street", avec le cadre légal
associé (et une infrastructure liée).

Ça rend pas mal compte de la bizarrerie d'un highway=secondary avec un
living_street, en restant assez neutre.


Avec 250k usages dans le monde, c'est raisonnable à utiliser, et ça
pourrait être supporté par un certain nombre d'outils (même si je ne
suis pas sûr que ce soit d'ores et déjà supporté).

Vous en pensez quoi ?
-- 
Phyks

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

Re: [OSM-talk-fr] Une secondary en zone de rencontre ?

[Phyks]

> Exemple aussi parlant qui traverse Castelnau-le-Lez avec un place à coté
> d'un axe secondaire
> Le faite de déclasser te fera passer sur les voies annexes avec des
> conditions de circulation encore plus désastreuse voie dangereuse car les
> voies ne sont pas aménager pour les camions. Ces axes ne sont pas seulement
> fait pour orienter le trafic voiture.
> https://www.mapillary.com/map/im/Kx-d4yBay5KldxxFZh4zzg

Doit-on chercher à interpréter l'aménagement à ce point ? À mon avis,
non. C'est un aménagement de type "zone de rencontre" avec tout un cadre
légal associée et une pénalité au routage probablement justifiée pour du
trafic de transit. Si on annote différemment pour biaiser les routeurs,
on tague pour un outil, ce qui à mon avis ne fait que masquer le
problème. S'il y a du trafic de transit possible dans des rues
parallèles encore moins adaptées, c'est que le plan de circulation n'est
pas correct et c'est à la puissance publique d'agir, pas à OSM de
chercher à masquer et corriger ces erreurs.


> Si quand tu mets un source:maxspeed=living_street ou zone:maxspeed=FR:20 ou
> living_street=yes comme proposé
> Je l'ai déjà dit. Ces clés valeur "magique" ne sont pas cohérent avec le
> précédent modèle. Maintenant c'est OSM et chacun fait à son bon vouloir...

Garder un highway=secondary mais rajouter un living_street=yes me paraît
pas mal comme solution (je ne connaissais pas ce tag). Ça correspondrait
pas mal à l'aménagement à mon avis.

Seul problème, même s'il semble largement utilisé (250k fois
https://taginfo.openstreetmap.org/tags/living_street=yes#overview), il
n'a aucune documentation dans le wiki :/

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

Re: [OSM-talk-fr] Une secondary en zone de rencontre ?

[Phyks]

> Pourquoi ? Parce qu'il y a toujours du trafic de transit et pour moi une
> living_street a un faible trafic sinon le piéton ne peut s’approprier toute
> la rue.
> Je ne suis cependant pas certain de mon choix.

Sauf que justement, c'est voulu comme une zone de rencontre. C'est
probablement pété sur le terrain, mais l'aménagement est tel que c'est
une zone de rencontre, avec son cadre légal, qui doit transparaître à
mon avis.

> Phyks as-tu des photos pour voir si physiquement ça ressemble à une zone de
> rencontre ?
> J'imagine que le trafic est important.

L'aménagement est plutôt correct pour une zone de rencontre (suppression
des passages piétons, plateaux traversants à hauteur, ralentisseurs en
entrée, signalisation, priorité à droite). C'est juste une zone de
rencontre avec plusieurs centaines de véhicules par heure, ce qui est
absurde, mais c'est l'aménagement choisi par l'autorité publique…

J'ai pas de photos à jour à cet endroit sur Mapillary. :/

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

Re: [OSM-talk-fr] Une secondary en zone de rencontre ?

[Phyks]

> Je penche pour la décision de la précédente discussion :
> "highway=living_street" sur la zone.

Idem de mon côté. Pour Marc, ce type d'aménagements est une aberration,
en voulant maintenir un transit important sur des axes en zone de
rencontre et en espérant que ça se résolve magiquement. Malheureusement,
c'est le terrain qui est ainsi, et la puissance publique n'est pas
partie pour changer ceci…

On doit donc à mon avis s'en accomoder et chercher à le décrire. On
n'est à mon avis pas là pour chercher à interpréter un aménagement ni à
lire entre les lignes en cherchant à diriger des flux routiers, c'est la
prérogative de l'aménageur.


> A mon humble avis, les voies de Montrouge devraient être classifiées ainsi :
> 
> primary:
> D920 Avenue Aristide Briand
> D906 Avenue Pierre Brossolette

+1

> secondary:
> D62 Avenue Marx Dormoy
> D50 Rue Gabriel Péri

+1

> tertiary:
> D63a Avenue Jean Jaurès (elle vaut peut-être encore son secondary,
> déjà c'est limite... Mais avec le réaménagement, elle devrait, sans
> beaucoup de doute, passer en tertiary)
> D63 Avenue de la République (qui pourrait se reprendre une partie du
> trafic de D63a)
> D128 Avenue Henri Ginoux
> D61 Avenue Verdier
> D59 Rue Maurice Arnoux

J'en garderai une partie en secondary. On a refait une passe dessus
récemment et exception faite du boulevard Romain Rolland qui est
discutable, les annotations actuelles me semblent pas mal et
correspondre à la réalité des flux.

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

[OSM-talk-fr] Une secondary en zone de rencontre ?

[Phyks]

Bonjour à tous,

Montrouge nous a gratifié d'un aménagement de type zone de rencontre
(https://fr.wikipedia.org/wiki/Zone_de_rencontre) en plein milieu d'axes
départementaux structurants (à raison en highway=secondary pour
l'instant) : de part et d'autre de ce carrefour :
https://www.openstreetmap.org/#map=19/48.81614/2.31157.

En suivant le wiki, et pour annoter la spécificité de la zone de
rencontre (notamment la priorité absolue aux piétons, qui peuvent
marcher sur la chaussée), j'aurais utilisé
https://wiki.openstreetmap.org/wiki/FR:Tag:highway=living%20street?uselang=fr.
Ceci résulte en un rendu horrible avec une coupure franche de l'axe
(même si on ne tague pas pour le rendu), qui correspond finalement assez
bien à la réalisation.

On a un doute (https://www.openstreetmap.org/note/1840402) et notamment
vis-à-vis de
https://wiki.openstreetmap.org/wiki/FR:France_roads_tagging#Grands_axes_de_circulation.2C_rues_principales
qui dit de maintenir les primary/secondary en tant que tels dans les
traversées de villes / villages.

Du coup, que faire sur cet aménagement ?

* Garder les living_street partout et les coupures de highway du coup ?
* Garder les secondary / tertiary sur tous les tronçons et ne rien
mettre en living_street ?

Dans le deuxième cas, comment décrire finement l'aménagement (au-delà de
la seule maxspeed=20) ?

Merci !
Bonne journée,
-- 
Phyks

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

Re: [OSM-talk-fr] simples pictogrammes vélo, pas de voies dédiées [était: Uniformiser le wiki "Bicycle"]

[Phyks]

En effet, les cas M3a et S1 mériteraient d'être mieux documentés je pense.

> Alors, est-ce que ça serait correct de préciser :
> S1 : highway=* + oneway=yes + oneway:bicycle=no + ...
> et pictogrammes : ... + cycleway:both=shared_lane +
cycleway:lane=pictogram

Je comprends pas très bien l'intérêt du cycleway:lane=pictogram en
complément du shared_lane. Ne serait-ce pas expliciter une valeur par
défaut ? (j'ai du mal à imaginer un cycleway=shared_lane avec autre
chose qu'une valeur cycleway:lane=pictogram).

Dans ton cas, j'aurais mis

highway=* + oneway=yes + oneway:bicycle=no (si pannonceaux, cf plus bas)
+ cycleway:both=shared_lane + cycleway:left:oneway=-1.



Au passage, d'une discussion récente sur talk-fr, j'avais retenu :

* cycleway > infrastructure
* oneway:bicycle > droit d'accès

Donc, dans le cas idéal (DSC marqué et pannonceaux sous les sens
interdits) : cycleway:left=lane (ou shared_lane),
cycleway:lane:oneway=-1 et oneway:bicycle=no.

S'il n'y a pas de pictogrammes au sol, pas de tags cycleway (mais
éventuellement oneway:bicycle=no).

S'il n'y a pas de pannonceaux sous les sens interdits, pas de tag
oneway:bicycle=no (mais éventuellement des cycleway).

C'est bien ça ? On le détaille comme ceci dans la page FR:Bicycle ?
-- 
Phyks

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

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

[Phyks]

> Des avis sur la question sont bien venu.
> 
> […]
>
> Il faut remonter ça pour améliorer le mapping, et avoir moins de faux
> positifs.

Ce n'est pas remonté quelque part quand on clique sur le bouton "faux
positif" ?

Au passage, je viens de voir que tous les faux positifs que j'avais
marqué sont réapparus… Est-ce normal ?

>> Il y a pas beaucoup de choses intéressantes une fois ceci filtré,
>> notamment pour les professions libérales (dentistes etc).
>>
>> Deux remarques sur la forme :
>>
>> * dans le frontend, le numéro SIRET est cliquable mais renvoie
>> systématiquement vers une page d'erreur. Ce n'est pas le plus pratique,
>> et j'avais toujours un autre onglet pour chercher les SIRET du coup.
> 
> Normalement c'est déjà corrigé depuis mercredi. Il peut en manquer mais
> ça en trouve aussi.

Je confirme, super !

>> * serait-il possible de systématiquement afficher le nom de l'entreprise
>> dans les erreurs dans le frontend Osmose ? On pourrait économiser
>> quelques clics / recherches sur le SIRET comme ça.
> 
> Quand il y un nom c'est affiché.

Par exemple, https://osmose.openstreetmap.fr/fr/error/29754498711 n'a
aucun nom affiché dans l'erreur. Pourtant, chez societe.com (par
exemple), il y a un nom
https://www.societe.com/etablissement/bluebretzel-49172436500029.html.

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

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

[Phyks]

Salut,

J'ai jeté un œil à Montrouge, il y avait pas mal de faux positifs,
principalement des entreprises individuelles positionnées sur
l'habitation du propriétaire ou avec des tags proches non trouvés
(restaurants / bars notamment). J'ai tout signalé en tant que "faux
positif" dans Osmose.

Il y a pas beaucoup de choses intéressantes une fois ceci filtré,
notamment pour les professions libérales (dentistes etc).

Deux remarques sur la forme :

* dans le frontend, le numéro SIRET est cliquable mais renvoie
systématiquement vers une page d'erreur. Ce n'est pas le plus pratique,
et j'avais toujours un autre onglet pour chercher les SIRET du coup.

* serait-il possible de systématiquement afficher le nom de l'entreprise
dans les erreurs dans le frontend Osmose ? On pourrait économiser
quelques clics / recherches sur le SIRET comme ça.

Merci !
-- 
Phyks

Le 20/07/2019 à 15:12, Frédéric Rodrigo a écrit :
> Si mais comme c'est des items cachés, ça bugue sur quelques trucs.
> 
> Sur la carte change le sélecteur de sévérité à Tous, puis reviens sur la
> carte depuis le lien.
> 
> http://osmose.openstreetmap.fr/fr/map/#item==all=15=44.82189=-0.5796=1%2C2%2C3==
> 
> 
> 
> 
> Le 20/07/2019 à 14:19, Stéphane Péneau a écrit :
>> Salut,
>>
>> J'avais réussi à afficher tout ça sur la carte il y a quelques
>> semaines, mais je n'y parviens plus.
>> Le permalink ne fonctionne plus ?
>>
>> Stf
>>
>> Le 11/07/2019 à 19:51, Frédéric Rodrigo a écrit :
>>> Le 11/07/2019 à 19:20, Christian Quest a écrit :
>>>> Content de voir que vous avez avancé sur cette GROSSE source de
>>>> données !
>>>>
>>>> J'ai trouvé beaucoup de coiffeurs sans salon de coiffure... les
>>>> entreprises individuelles ont-elles bien été filtrées ?
>>>> Pareil pour les esthéticiennes... ça se pratique pas mal à domicile.
>>>
>>> Non. Pour l'instant elles y sont, sauf pour les fast_food.
>>>
>>> J'avais peur que ce soit un peu excessif de généraliser ce filtre.
>>>
>>>
>>>
>>>> Il y a assez peu de noms, d'enseignes indiqués.
>>>>
>>>> Le SIRET n'est pas proposé/indiqué... ça serait bien pour accéder à
>>>> la source SIRENE et vérifier le reste des infos.
>>>
>>> Oui, je vais le remettre, au moins pour ça.
>>>
>>>
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] nettoyage du centre de la France

[Phyks]

Salut,

> Le nettoyage a été fait, et reverté par Jawg apparemment parce que
> leur rendu ne gère pas les pays mapé sous forme de way/relation mais 
> uniquement sous forme de nœud (ce qui fait qu'il leur en manque 99 !)
> Vu que le revert intégral, si vous cherchez France métropolitaine,
> osm vous dira à nouveau que c'est un pays name=France :(

Je ne comprends pas trop l'argument ici… Pourquoi annuler un changement
qui (si j'ai bien suivi) est parfaitement valide et cohérent, au motif
que leur outil ne supporte pas ce schéma ?

Pour information, openstreetmap-carto (le style osm.org) et donc, tous
les styles dérivés, utilisent les polygones pour le rendu des noms de
pays :
https://github.com/gravitystorm/openstreetmap-carto/blob/master/project.mml#L1178-L1198.

OSM-Fr utilise par contre le nœud je crois :
https://github.com/cquest/osmfr-cartocss/blob/master/osmfr.yml#L762-L766


> La discussion se poursuit sur le changet pour au moins virer cette 
> erreur en attendant que Jawg améliore son rendu.

Pour ceux qui ne veulent pas chercher, la discussion est ici
https://www.openstreetmap.org/changeset/72226819 :)

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

Re: [OSM-talk-fr] Epreuve Cyclo-randonnée Paris-Brest-Paris dans OSM

[Phyks]

Le 2019-07-15 12:38, marc marc a écrit :

Le 15.07.19 à 12:12, Phyks a écrit :

Salut,


Pour le besoin de différencier les itinéraires par type de pratique
vélo, je suis plus pour dire que route=mtb est une erreur et que la
bonne façon de faire c'est la spécialisation :
route=bicycle
bicycle=mtb/cycling_race/tourism/gravel/commute/...


+1 ! Tu nous gères la proposition de tagging ? :)


cela veux dire que celui qui veux un itinéraire cycliste doit
obligatoirement regarder un sous-tag qui "contredit" le principal ?
à mon avis les évenements temporaires ne sont pas des route=bicycle.


Qui précise et non contredit dans le cas général. Ce serait une route 
pour vélo (route=bicycle), qui pourrait être adaptée qu'à certaines 
pratiques (bicycle=mtb, bicycle=tourism etc).



Dans le cas d'événements ponctuels (et non repérables sur le terrain), 
je te rejoins et je supprimerais bien.


--
Phyks

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

Re: [OSM-talk-fr] Epreuve Cyclo-randonnée Paris-Brest-Paris dans OSM

[Phyks]

Salut,


Pour le besoin de différencier les itinéraires par type de pratique
vélo, je suis plus pour dire que route=mtb est une erreur et que la
bonne façon de faire c'est la spécialisation :
route=bicycle
bicycle=mtb/cycling_race/tourism/gravel/commute/...


+1 ! Tu nous gères la proposition de tagging ? :)


Mon avis :
Supprimer l'itinéraire PBP parce a priori utiliser que quelques jours
tous les 4 ans.


Ça m'embête un peu de supprimer cet itinéraire, vu le boulot qui a été 
fait dessus… En même temps, il est problématique… En attendant, j'ai 
fait un "route=disused:bicycle" pour corriger rapidement le problème, 
sans grande conviction https://www.openstreetmap.org/changeset/72256767. 
Je suis d'accord que la meilleure solution serait probablement une 
spécification de route=bicycle.


Bonne journée,
--
Phyks

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

Re: [OSM-talk-fr] Epreuve Cyclo-randonnée Paris-Brest-Paris dans OSM

[Phyks]

Salut,

> Par contre, j’ai l’impression que telle qu’elle est cartographiée 
> actuellement, cette route=bicycle ne trompe plus les logiciels de routage en 
> étant systématiquement favorisée. C’est un bon point car c’est précisément à 
> cause de cet effet secondaire dans brouter que j’avais remarqué l’existence 
> de la relation.

Je relance ce sujet, car 8 mois plus tard le problème est toujours le
même… Les logiciels de routage se font systématiquement tromper par cet
itinéraire, qui est quand même très particulier et non fléché sur le
terrain.

Sans sombrer dans le tag to router, on ne peut quand même pas vraiment
en vouloir aux routeurs de se tromper, il n'y a strictement aucune
indication dans les tags pour distinguer un itinéraire de ce type (bien
particulier, sportif) d'un itinéraire cyclotouristique comme la
Véloscenie. C'est assez dangereux également, car les données n'affichant
aucune distinction entre ces itinéraires, on se retrouve vite dans des
routes à fort trafic, sauf à bien explorer en détails les itinéraires
proposés.

J'ai contacté le contributeur initial, sans réponse depuis quelques temps…


Avec les attributs existants aujourd'hui, ne pourrait-on pas jouer :
1. Soit sur le state, avec un state=proposed (ou temporary
https://taginfo.openstreetmap.org/keys/state#values) ?

2. Soit sur le network, en mettant un network=PBP ou un network
spécifique ? Est-ce que la PBP s'inscrit dans un parcours d'épreuves
plus larges (comme en rallye automobile, on pourrait tagger une épreuve
avec un network=WRC ou autre ?)

3. En jouant sur le route, avec un route=cycling_race (qui n'existe pas
actuellement :/), comme on fait bien des route=mtb pour les parcours VTT.

Sinon, il faudrait un attribut supplémentaire pour décrire le type
d'itinéraires (sportif / touristique), mais je n'ai rien trouvé de tel
pour l'instant, et je ne me sens pas de faire une proposition de nouveau
tagging etc.

Bonne journée,
-- 
Phyks

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

Re: [OSM-talk-fr] Uniformiser le wiki "Bicycle" (était Re: Sidewalk:bicycle dans le wiki bicycle)

[Phyks]

Bonjour à tous,

Je viens de refaire une passe sur la page FR:Bicycle et ma proposition
actuelle (avec les diffs visibles dans l'historique de la page) est sur

https://wiki.openstreetmap.org/wiki/User:Phyks/FR:Bicycle

J'ai tenté d'harmoniser les descriptions entre elles et avec la version
anglaise.

(Au moins) deux points restent à traiter, à mon avis:

1. Je ne comprends toujours pas très bien ce que décrit
https://wiki.openstreetmap.org/wiki/User:Phyks/FR:Bicycle#Am.C3.A9nagements_cyclables_sur_trottoirs,
surtout que la photographie ne semble pas correspondre aux schémas. Que
devrait-on faire de cette partie ?

2. Suite à la discussion qui avait eu lieu sur talk-fr, on avait convenu
de tagger les parkings "deux roues" (ouverts aux vélos mais aussi aux
scooters) comme
https://wiki.openstreetmap.org/wiki/Montrouge#Stationnements_deux_roues
(ce qu'on a adopté à Montrouge). Que pensez-vous de reporter cette
documentation dans la page FR:Bicycle ?

Bonne journée,
-- 
Phyks
Le 01/07/2019 à 15:12, Phyks a écrit :
>> sauver la page initiale dans son espace utilisateur du wiki,
>> faire la modifi sur cette page, l'historique permet alors à la fois de
>> comparer et de regarder le résultat comme à l'habitude.
> 
> Bien vu, je viens donc de faire
> https://wiki.openstreetmap.org/wiki/User:Phyks/FR:Bicycle.
> 
> Discutons sur le résultat de cette page et oublions le gist du coup :)
> -- 
> Phyks
> 
> ___
> 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

[Phyks]

Salut,



Je viens demander un conseil technique.
 Nous avons bien entendu l'appel du bureau des OSM France proposant de
financer l'achat de matériel pour les groupes locaux. Ainsi les
membres du groupe toulousain ont décidé de se lancer dans la prise
de vues Mappilarry.


Je n'ai pas une grande expérience des caméras 360, mais nous avons une 
LG (https://www.lg.com/be_fr/smartphones/lg-LGR105) à Montrouge, vissée 
au bout d'une perche à selfie. C'est pas trop mal à pied (tant que ça 
vibre pas trop / qu'on va pas trop vite) et qu'il fait beau. Après, les 
textes sont quand même pas ultra exploitables… Tu peux voir des exemples 
de rendus sur https://osmontrouge.fr/ (dernier bouton de la barre à 
droite).


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


Bonne journée,
--
Phyks

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

Re: [OSM-talk-fr] Uniformiser le wiki "Bicycle" (était Re: Sidewalk:bicycle dans le wiki bicycle)

[Phyks]

sauver la page initiale dans son espace utilisateur du wiki,
faire la modifi sur cette page, l'historique permet alors à la fois de
comparer et de regarder le résultat comme à l'habitude.


Bien vu, je viens donc de faire 
https://wiki.openstreetmap.org/wiki/User:Phyks/FR:Bicycle.


Discutons sur le résultat de cette page et oublions le gist du coup :)
--
Phyks

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

Re: [OSM-talk-fr] Sidewalk:bicycle dans le wiki bicycle

[Phyks]

Bonjour,

Si je comprends bien, le but des deux "NO" (et non N0, il faudrait 
probablement mettre "/" ou autre "TMP1" qui serait plus clair) est de 
différencier la présence de marquage séparatif ou non 
(http://a51.idata.over-blog.com/0/08/17/20/70-gambetta-bande-cyclable..jpg 
vs 
http://derailleurscaen.net/WordPress3/wp-content/ressources/2015/Ifs/Ifs_02.jpg). 
Je ne comprends cependant pas très bien ce que ça change en pratique, 
tant qu'il y a à peu près deux couloirs dessinés (on reste dans du 
segregated=yes).


Déjà, je propose de mettre les cas S3 et S4 dans la même sous-section 
que les cas "NO" pour faciliter la lecture de la page.



Mon problème avec sidewalk:bicycle est qu'il n'est décrit nulle part (en 
tant que tag, en français ou en anglais) sur le wiki. Il faudrait donc a 
minima lui créer une page internationale. Il n'est actuellement supporté 
par aucun routeur vélo (à ma connaissance) et vu son faible usage, il 
n'est pas évident de plaider pour son support…


Pour le premier cas "NO", en gardant les trottoirs en implicites, je ne 
vois pas vraiment d'autres solutions. Il y a cependant le 
cycleway=sidewalk 
(https://taginfo.openstreetmap.org/tags/cycleway=sidewalk#combinations), 
guère plus documenté…


Pour le deuxième cas "NO", pourquoi ne pas le fusionner avec la 
description de S3, en mettant une emphase sur la désignation première de 
l'aménagement à travers la valeur de highway ? (path si tout le monde 
est à égalité, footway si c'est un trottoir en priorité, ouvert aux 
vélos, cycleway si c'est pour les vélos, ouvert aux piétons).


Dans tous les cas, je ne comprends pas l'image d'illustration 
(https://wiki.openstreetmap.org/wiki/File:Trottoir_partage.jpg). Ce 
n'est aucunement un trottoir partagé ("cycliste, pied à terre") et il 
manquerait dans ce cas les indications de bicycle=dismount etc dans les 
exemples de tags.


Bonne journée,

Le 2019-07-01 13:42, Florimond Berthoux a écrit :

Le lun. 1 juil. 2019 à 13:11, Axel Listes  a écrit
:


Tu peux ajouter cycleway=sidewalk pour définir que c'est pas

une piste

mais

un truc sur trottoir.
S'il y a une bande cyclable dessus tu peux ajouter

segregated=yes.

Il ne peut y avoir de bande cyclable sur un trottoir.


Il peut avoir ségrégation de l'espace entre piéton et vélo par

une bande.

exemple pont de Suresnes




https://www.google.com/maps/@48.8672069,2.2285553,3a,44.9y,316.44h,89.04t/data=!3m6!1e1!3m4!1sAmW6lGVM_6JIWktbYMFt4A!2e0!7i16384!8i8192


C'est justement ce type de confusion qui complexifie le sujet ! Ce
que
tu montres n'est pas une bande mais une piste cyclable. La surface
dédiée aux vélos n'est de fait plus considérée comme faisant
partie d'un
trottoir ou d'un chemin, mais comme voie de circulation pour vélos
liée
à la chaussée principale qu'elle longe; les piétons ne sont pas
autorisés à circuler dessus et les cyclistes profitent des mêmes
réglementations que les automobilistes (priorités, vitesse ...).


Oui je sais, c'est légalement une piste cyclable, donc une chaussée,
en France, ailleurs je ne sais pas et on ne tag pas la lois.

Taggons plutôt la réalité physique des choses.
Il y a séparation physique (bordure) entre piéton-vélo et
motorisés : deux ways, un path pour les piétons vélo avec
segrageted=yes.


Pour info les allemands aiment beaucoup les pistes sur trottoir




https://www.google.com/maps/@53.5573947,10.0321755,3a,49y,38.74h,89.89t/data=!3m6!1e1!3m4!1svWVWFATmOPOgLEZf2EQlwg!2e0!7i13312!8i6656

(beurk.)


Le long des trottoirs :)
Si les surfaces sont correctement identifiées et laisses
suffisamment de
place aux différents usagers, c'est une approche intéressante.
J'ai déjà
expérimenté ce type d’aménagement et j'en suis plutôt
satisfait.


Quand je dis sur les trottoirs c'est dans l'acceptation courante "voie
cyclable à même niveau que le trottoir",
je pourrais rajouter «et qui se prenne le caniveau à chaque
traversée de route et c'est bien pour ça que c'est pas terrible
comme infra vélo».
On fait beaucoup mieux (Pays-Bas), les cyclistes valent mieux que la
bouilli qu'on nous donne, mais je digresse ;)

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


--
Phyks

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

[OSM-talk-fr] Uniformiser le wiki "Bicycle" (était Re: Sidewalk:bicycle dans le wiki bicycle)

[Phyks]

Bonjour,

En faisant une passe rapide sur la page Bicycle (en intégralité cette 
fois), il y a un certain nombre de points qui diffèrent d'un cas à 
l'autre ou avec la version anglaise. Ne devrait-on pas uniformiser ça ?


J'ai commencé à noter les changements que je propose sur 
https://gist.github.com/Phyks/e604373ccc8f37827b6e8da01f941c13/revisions, 
jusqu'à la zone des sidewalk:bicycle. Le wiki avec ces modifications 
devrait être cohérent avec la version anglaise et les pratiques FR. 
Qu'en pensez-vous ?


(Au passage, quelqu'un a-t-il un meilleur moyen qu'un gist Github pour 
visualiser des modifications proposées sur une page wiki ?)



Un des points-clés restant dans cette partie de la page est la question 
des cycleway:*=opposite_lane. La version anglaise les utilise 
systématiquement (cas M1 par exemple) quand la version FR utilise des 
cycleway:*:oneway et des lane (ma préférence, personnellement). Si on 
garde l'absence d'opposite_lane de façon générale, il faudrait les 
enlever des cas M3a et M4 (et sûrement ajouter une note de page pour 
dire qu'en France, l'usage des oneway est préférée sur opposite_lane).


Bonne journée,


Le 2019-07-01 09:30, Axel Listes a écrit :

Bonjour,

Le 28/06/2019 à 15:02, marc marc a écrit :

Le 28.06.19 à 12:44, Phyks a écrit :

le cas N0


ajout en 2018 sur la page fr mais absente de la page anglaise.
d’où vient la ref ? ne faudrait-il pas une ref différente par cas ?


En fait ce n'est pas N0 mais NO :) C’est-à-dire il n'y a pas (encore ?)
de référence. Effectivement ça prête à confusion.


--
Phyks

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

[OSM-talk-fr] Sidewalk:bicycle dans le wiki bicycle

[Phyks]

Salut,

Je viens de voir dans le wiki "FR:Bicycle" [1], le cas N0 décrivant des
aménagements cyclables sur trottoirs.

La première description mise en avant est en utilisant
sidewalk:bicycle=yes. Cette clé n'existe pas dans le wiki et a l'air
très peu utilisée en pratique (450 utilisations, essentiellement en
Allemagne) [2].


J'ai probablement raté un truc, je suis un peu perdu. J'ai l'impression
que les deux cas N0 (N0 et N1 ?) sont en fait très proches des cas S3 et S4.

Si j'ai bien compris, la principale différence entre ces cas est qu'il
n'y a pas de marquage explicite de séparation. Dans ce cas, j'aurais
plutôt repris les cas S3 et S4 en mettant segregated=no (et peut être un
highway=footway plutôt que cycleway vu la qualité et la désignation
initiale de l'aménagement).

Au passage, la différence entre les cas S3 et S4 est assez subtile
(bas-côté contre trottoir physique, si j'ai bien compris) et serait peut
être à expliciter plus.

Qu'en pensez-vous ?

Bonne journée,

[1]
https://wiki.openstreetmap.org/wiki/FR:Bicycle#Am.C3.A9nagements_cyclables_sur_trottoirs
[2] https://taginfo.openstreetmap.org/keys/sidewalk%3Abicycle#overview
-- 
Phyks

___
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

[Phyks]

Vu la surface en question, je crois que la plupart des routeurs pourront
s'en sortir sans problèmes en routant le long du bord, ce qui ne
donnerait pas des trajets aberrants ici.

Pour le feu tricolore vélo, bonne question… Je ne connais pas de tagging
spécifique.

-- 
Phyks
Le 28/06/2019 à 10:28, Florian LAINEZ a écrit :
> Hello,
> Une nouvelle piste cyclable <https://www.openstreetmap.org/way/683304588>
> vient d'être mise en service sur Ordener à Paris.
> Je l'ai connectée à un trottoir surfacique
> <https://www.openstreetmap.org/way/217028973> car c'est la réalité (un peu
> aberrante) du terrain.
> J'imagine que pour le routing, ça va pas vraiment le faire ... que
> conseillez-vous ?
> 
> J'ai aussi créé un feu tricolore dédié aux vélo
> <https://www.openstreetmap.org/node/6400116392>. Y a-t-il un tag spécifique
> pour ça ? Cette info a l'air de manquer dans le wiki ... merci
> 
> -- 
> 
> *Florian Lainez*
> @overflorian <http://twitter.com/overflorian>
> 
> 
> ___
> 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] [Python] Générer image carte statique à partir coordonnées GPS?

[Phyks]

Bonjour,

En changeant très légèrement les coordonnées par rapport à la version 
qui fonctionne (les dernières décimales), il y a un cadre noir qui 
apparaît autour de la zone initiale. Si c'était un blocage préventif, je 
m'attendrais à ce que soit plutôt tout ou rien (soit une image 
complètement rendue, soit une image complètement noire).


Là, j'ai plutôt l'impression qu'il y a un problème de leur côté et que 
seule une toute petite zone (celle de démonstration) fonctionne, le 
restant étant rendu en noir uniforme.


--
Phyks

Le 2019-06-25 17:04, Shohreh a écrit :

Bonjour,

Le code Python suivant fonctionne si j'utilise l'example donné sur le 
site
StaticMapLite*, mais il retourne un fichier noir si j'utilise mes 
propres

coordonnées.

=
import requests

#NOK
url =
'https://staticmap.openstreetmap.de/staticmap.php?center=48.8591,2.3470=14=400x400=mapnik'
#OK
url =
'https://staticmap.openstreetmap.de/staticmap.php?center=40.714728,-73.998672=14=400x400=mapnik'

headers = {"User-Agent": "Mozilla/5.0 (Windows NT 6.1; WOW64)
AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.52 
Safari/536.5",

"Referer": "https://www.google.com"}

f=open('static.png','wb')
f.write(requests.post(url, headers=headers).content)
f.close()
=

Serait-ce parce que l'admin du serveur ne veut plus que les gens 
l'utilisent

?**

Si c'est le cas, y a-t-il une alternative pour quelques dizaines de
requêtes/jour maximum ?

Merci.

* http://staticmaplite.sourceforge.net/
**
https://wiki.openstreetmap.org/wiki/StaticMapLite#openstreetmap.de_hosting



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


--
Phyks

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

Re: [OSM-talk-fr] Accessibilité des établissements recevant du public (ERP)

[Phyks]

Bonjour,

Je ne connaissais pas ces registres, ça a l'air assez pratique. Chez moi
(Hauts-de-Seine,
http://www.hauts-de-seine.gouv.fr/Politiques-publiques/Accessibilite/Liste-des-etablissements-mis-en-accessibilite-dans-les-Hauts-de-Seine),
c'est un fichier ODS avec les noms des enseignes, des codes postaux
propres et des adresses assez propres. Le fichier est marqué
"16/04/2019", il serait même possible que les données ne soient pas trop
vieilles !

Ça ne semble pas trop dur de faire correspondre semi-automatiquement
(Osmose ?) ces données avec des données OSM (par une géolocalisation
inverse et en cherchant les POIs avec des noms proches à proximité).

Par contre, je n'ai pas encore trouvé d'informations claires sur ce que
ça implique qu'un établissement apparaisse dans le fichier. Est-ce
traduisible facilement avec des tags OSM ?

Bonne journée,
-- 
Phyks

Le 21/06/2019 à 09:30, Yves P. a écrit :
> Bonjour,
> 
> J'ai eu hier une rapide discussion avec une représentante d'une association
> de personnes handicapées, membre d'une *CCDSA* (Commission consultative
> départementale de sécurité et d'accessibilité).
> 
> Il existe pour chaque ERP un *Registre d’accessibilité*, et si j'ai tout
> compris, une liste des ERP accessibles (ou en voie de l'être).
> La liste serait publié pour chaque département par la *DDT* (direction
> départementale des territoires).
> 
> Cette liste et si possible le contenu de chaque registre pourraient être
> une bonne source de données pour OSM et/ou Osmose.
> 
> En regardant sans ma région, je trouve des tableaux au format pdf pour le
> Doubs, rien pour le Jura.
> 
> Le tableau contient le nom et l'adresse de l'ERP ainsi que sa catégorie et
> son Type.
> 
> Est-ce que vous connaissez ces données ?
> Pourrait-on les utiliser dans OSM ?
> Existe-t-il des tentatives ?
> 
> __
> Yves
> 
> L'accessibilité des établissements recevant du public (ERP)
> <https://www.ecologique-solidaire.gouv.fr/laccessibilite-des-etablissements-recevant-du-public-erp>
> *"Le registre a pour objectif d’informer le public sur le degré
> d’accessibilité de l’établissement et de ses prestations. Le parti pris est
> de faire simple et utile."*
> *[...]*
> *"Il doit être consultable sur place au principal point d’accueil
> accessible de l’ERP. [...]À titre alternatif, si l’ERP dispose d’un site
> internet, il est pertinent de mettre en ligne le registre, dans une
> rubrique dédiée.*
> 
> 
> PS: *Les E.R.P sont des *bâtiments ou enceintes, qu’elles soient fixes ou
> provisoires (*Supermarchés, cinémas, théâtres, chapiteaux, universités…*)
> accessibles au public librement ou moyennant une quelconque rétribution.
> 
> *ADAP* : agenda d'accessibilité programmée
> 
> 
> ___
> 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] routage surfacique

[Phyks]

Bonjour,


casser en disant "yaka faire du routage surfacique",
c'est méconnaître ce que cela implique techniquement :
il y a un gros travail de prétraitement à faire.
je ne retrouve plus hélas l'article qui était publiée sur osmweekly
mais la moindre place avec qlq rues est transformée en un nuage
de way qui connectent tous les paires de points de la surface.
en passant, cela veux dire aussi qu'une place surfacique
avec 8 nœuds consomme 9x l'espace disque et mémoire
comparé à sa version linéaire et ce n'est pas en un claquement
de doigt qu'on augmente la puissance d'un serveur gratuit.

je pense que les outils continueront de s'améliorer simplement
à la demande de leur utilisateur, en fonction des ressources dispo.


Dans la plupart des cas, le routage surfacique n'est pas un problème 
quand même. Je mets volontairement de côté une place aussi complexe que 
https://www.openstreetmap.org/relation/8365033 (même le rendu a du mal 
au passage…) pour se concentrer sur des espaces sans trous (tels que les 
espaces dans l'erreur Osmose initiale 
https://osmose.openstreetmap.fr/fr/map/#item=1270=18=47.497894=-0.580999=1%2C2%2C3==).



La plupart des moteurs de routage ne vont pas gérer le routage 
surfacique à travers la place (qui est un problème compliqué). En 
revanche, tous vont pouvoir traiter la place comme un way fermé (le 
contour) et tous savent a priori emprunter des portions de way. Du coup, 
le routage ne sera pas "joli" (on ne va pas traverser la place comme on 
le voudrait, simplement contourner en suivant la bordure), mais le 
routage restera néanmoins fonctionnel.


Dans un cas simple comme ceci, à mon avis, il n'y a aucune raison de 
tracer des continuités des chemins à travers les places, si ce n'est 
alourdir la base avec des ways inutiles (et qui n'existent pas sur le 
terrain). La description en termes d'air a une réelle plus value 
(notamment pour le rendu, mais pas que), et reste parfaitement 
utilisable, à condition que les aires portent bien les attributs 
corrects (highway et droits d'accès).


Sur un cas similaire à l'exemple initial d'Osmose :
* BRouter suit le contour, 
http://brouter.de/brouter-web/#map=19/45.77393/3.08337/standard=3.083773,45.77412;3.083596,45.773869
* Géovélo aussi, 
https://www.geovelo.fr/clermont/itinerary/search?profile=MEDIAN=TRADITIONAL=45.774108,3.08372%7C45.7739,3.0836
* GraphHopper et OSRM aussi, 
https://www.openstreetmap.org/directions?engine=graphhopper_foot=45.77411%2C3.08376%3B45.77387%2C3.08360



Mon avis serait donc que sur des places simples (sans trou), il suffit 
de connecter le polygone aux chemins voisins et tout tracé de chemin en 
travers du polygone relève plutôt du "tag to router", en créant des 
chemins qui amélioreront le rendu du routage, mais en aucun cas sa 
justesse.


D'ailleurs, malgré l'erreur Osmose, le routage se fait très bien 
http://brouter.de/brouter-web/#map=19/47.49783/-0.58158/standard=-0.581248,47.497738;-0.581433,47.498012.



Ma remarque ne tient plus évidemment lorsqu'on considère des surfaces 
avec des trous (multipolygone) où le routage est épouvantable et 
catastrophique s'il n'y a pas de chemins intérieurs "fictifs", comme le 
montre 
http://brouter.de/brouter-web/#map=17/48.84022/2.32019/standard=2.319813,48.841791;2.321146,48.841137=hiking-beta 
par exemple (BRouter ne gère pas le routage surfacique). Ce point est 
beaucoup plus sujet à débat à mon avis et des chemins "fictifs" 
pourraient être justifiés, même si certains ont des avis assez tranchés 
sur la question https://www.openstreetmap.org/note/1654211.

--
Phyks

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

Re: [OSM-talk-fr] exporter les tags d'un projet/style vers taginfo

[Phyks via Talk-fr]

Bonjour à tous,

Pour donner un peu plus de détails sur la question, j'ai actuellement un 
script 
(https://github.com/cyclosm/cyclosm-cartocss-style/blob/master/scripts/generate_taginfo.py) 
qui permet à partir d'un fichier YAML de déclaration de style CartoCSS 
(testé sur CyclOSM, mais ça devrait fonctionner tout pareil sur osm-fr, 
osm-bzh etc) de générer un fichier JSON pour taginfo listant tous les 
tags utilisés. Le seul pré-requis pour l'instant est que la base de 
données utilisée soit une base de données standard d'un import osm2pgsql 
(pour les noms des colonnes), éventuellement avec --hstore.


Mon problème principal actuellement, c'est que j'aimerais pouvoir avoir 
dynamiquement la liste des valeurs (et non seulement les tags) utilisés. 
Par exemple (hypothétique), je voudrais savoir que j'affiche les 
shop=bicycle mais pas tous les autres shop. Le problème est que le 
filtrage peut se faire dans les tables SQL ou dans les styles carto, 
sans compter que les colonnes peuvent être fusionnées, renommées etc 
dans les requêtes SQL. Bref, ça me paraît très compliqué de sortir les 
valeurs vraiment prises en compte sans se constraindre assez fortement 
sur les requêtes SQL qu'on peut écrire.


En y réfléchissant un peu, une idée me semble être de faire tourner les 
requêtes SQL complètes sur une grosse base (monde ?) et de regarder les 
valeurs uniques pour chaque colonne. Ce ne sera pas parfait (une valeur 
pourrait être ignorée car elle n'est pas en base et non parce qu'elle 
n'est pas gérée par le style), mais ça devrait fournir une assez bonne 
approximation en général.


Ceci n'est bien sûr pas parfait, j'ignore notamment les colonnes dans 
les clauses WHERE ainsi que des valeurs renommées / fusionnées / 
transformées dans les requêtes SQL, mais ça devrait être "good enough" 
pour la plupart des usages. Qu'en pensez-vous ?


Je prends bien sûr tout avis ou idée pour gérer ça mieux !

Bonne soirée,
--
Phyks

Le 2019-06-06 18:10, marc marc a écrit :

Bonjour,

Je discutais avec Phyks sur irc à propos de la fonction projet
de taginfo. elle permet de connaitre la liste des tags et/ou
valeurs utilisé par un projet.
C'est pratique par exemple pour faire la différence entre
des tags utilisé ou pas encore, ou pour savoir qui prévenir
quand un tag est affecté par une proposition.
A mes yeux, ce serrait aussi pratique pour détecter
quand un poi est rendu dans un style mais pas dans un autre,
afin de pouvoir faire des PR croisé du code ou de l’icône.

exemple de tag déclaré par des projets
https://taginfo.openstreetmap.org/projects#tags

exemple tag utilisant des vues
https://github.com/giggls/openstreetmap-carto-de/issues/39

une adaptation tag avec les tables sans vue
https://github.com/cyclosm/cyclosm-cartocss-style/issues/123

exemple tag
https://github.com/der-stefan/OpenTopoMap/blob/master/mapnik/tools/maketaginfo.pl

les problèmes :
le premier utilise des vues ce qui n'est pas le cas par défaut
sur un fork osm-carto
le deuxième ne gère pas les valeurs, seulement les tags
et selon Phyks le troisième a le défaut "meh, du perl :("

j'ouvre donc ce sujet pour voir si les différentes personnes
(Christian, Maël, Yohan, sncf?, autre ?) serraient intéressées de :
- mettre en place la création du fichier nécessaire pour taginfo
avec leur projet (je peux ouvrir les tickets si vous voulez)
- collaborer pour améliorer les outils existant

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


--
Phyks

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

Re: [OSM-talk-fr] Photos StreetComplete inaccessibles

[Phyks]

Bonsoir,

Fibre Free chez moi aussi, pas de problèmes.

Peut être une limitation en volume de requêtes qui s'est activée ?
-- 
Phyks
Le 03/06/2019 à 22:43, Cédric Frayssinet a écrit :
> Bonsoir à tous,
> 
> J'ai utilisé ces derniers temps l'envoi de photos avec StreetComplete
> pour créer des notes. C'est très pratique et je me demande si je ne vais
> pas l'utiliser avec mes élèves.
> 
> Cependant, j'ai ouvert un ticket
> <https://github.com/westnordost/StreetComplete/issues/1414> car depuis
> chez moi, avec une connexion Free fibre, je n'accède pas aux photos
> (exemple : https://westnordost.de/p/3461.jpg).
> 
> En fait, je n'accède pas du tout au domaine https://westnordost.de. Je
> reçois un beau 403 - Forbidden - Nginx.
> 
> Est-ce que vous constatez la même chose avec vos connexions, si possible
> Free...
> 
> Je n'ai pas de soucis en 4G avec SFR ou Free. Bizarre...
> 
> Une idée ?
> 
> Merci,
> 
> Cédric
> 
> 
> -- 
> Dégooglisé ! <https://degooglisons-internet.org/> - Sociétaire Enercoop
> <https://souscription.enercoop.fr/code/PARRAIN_OrcGUb>, l'énergie militante
> 
> Sur Mastodon : @bristow...@framapiaf.org <https://framapiaf.org/@Bristow_69>
> 
> Promouvoir et soutenir le logiciel libre <http://www.april.org>
> 
> 
> 
> ___
> 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] Modifications des voies de bus rue de Rivoli

[Phyks]

Bonjour,

Je viens de voir passer 
https://www.openstreetmap.org/changeset/70697665, qui est assez 
illisible et touche un grand nombre d'objets sur la rue de Rivoli. 
Certaines modifications ont clairement l'air incorrectes (nœud commun 
entre le métro et la rue https://www.openstreetmap.org/node/368205 par 
exemple), mais il y a probablement des erreurs plus subtiles aussi que 
j'ai ratées.


Quelqu'un avec une bonne connaissance du coin et des schémas de bus 
peut-il jeter un œil et faire un commentaire en conséquence ? En 
regardant l'historique du contributeur, il a recommencé à contribuer 
récemment après une longue pause (un an), et il y a déjà quelques 
commentaires sur des changesets précédents, sans réponse :/ à suivre,


Bonne journée,
--
Phyks

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

Re: [OSM-talk-fr] [pro] Ajout des données Rézopouce

[Phyks]

Bonjour,

J'en avais ajouté quelques uns du réseau Covoit'ici aussi (par exemple 
https://www.openstreetmap.org/node/5981485462), à partir de leurs 
données et de vérification terrain / Mapillary. C'est assez frustrant 
par contre que ces objets ne soient pas rendus sur osm.org :/ 
https://github.com/gravitystorm/openstreetmap-carto/issues/3456


Bonne journée,

Le 2019-05-28 17:21, Vincent Bergeot a écrit :

Bonjour,

j'en ai discuté sur la liste transport mais pas ici :(

Rezopouce, l'autostop au quotidien (https://rezopouce.fr/), a fourni
les données de ses arrêts dans le Seignanx (le sud-ouest des
Landes).

Après avoir vérifié la cohérence (bord de route et en particulier
croisement ou espace dégagé), ajouté dans Umap pour que des locaux
(les gens de l'office de tourisme) les vérifient, j'ai ajouté les
arrêts.

Ils se retrouvent ici : http://overpass-turbo.eu/s/JpR

4 tags :

* amenity=car_pooling
* network=Rézopouce
* ref=*
* name=*

n'hésitez pas à faire des retours !

Bonne journée

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


--
Phyks

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

Re: [OSM-talk-fr] place de parking dan Paris [était: Peut-être enfoncé-je des portes ouvertes]

[Phyks]

Bonjour,

Le même jeu de données comprend les arceaux vélos et deux roues, sur
lesquels j'ai plus d'expérience. Pour les arceaux, il est plutôt très
bon. Il y a d'ailleurs une visualisation en surimpression avec des
images prises depuis la rue, qui montre que la qualité est plutôt très
satisfaisante : http://capgeo.sig.paris.fr/Apps/Stationnement2Roues/.

D'ailleurs, la partie "stationnement deux roues" est déjà intégrée dans
Osmose
(https://github.com/osm-fr/osmose-backend/blob/master/analysers/analyser_merge_bicycle_parking_FR_paris.py).
Avec les bons tags, ce ne devrait pas être très dur d'adapter ça pour
ingérer aussi les places PMR.



> aucune idée de la fiabilité mais attention à la maintenance
vouloir renseigner les parkings jusqu'à l'emplacement individuel
en voirie, cela va faire un boulot de titan en maintenant
si tu regardes dans osmose opendata, tu verras que même
les objets qui varient peu manquent de bras pour être maintenu

À mon avis, une telle précision dépend de la qualité des jeux de données
et des contributions potentielles. Ici, à Paris, il y a une masse
critique de contributeurs (qui devraient pouvoir maintenir la donnée,
pas comme une action isolée de quelqu'un motivé dans une petite ville).
Il y a aussi de l'orthophotographie avec un très bon zoom qui permet de
les ajouter / confirmer rapidement depuis son canapé.

Et la mairie a un jeu de données de bonne qualité pour l'instant. Tant
que les relevés futurs restent publiés en OpenData, la maintenance
devrait aussi être facilitée avec une intégration Osmose par exemple.

Bonne journée,
-- 
Phyks
Le 29/05/2019 à 09:05, Vincent Bergeot a écrit :
> Le 28/05/2019 à 23:04, marc marc a écrit :
>> Bonsoir,
>>
>> Le 28.05.19 à 19:30, Jacques Foucry a écrit :
>>> Il y a ici :
>>> https://opendata.paris.fr/explore/dataset/stationnement-voie-publique-emplacements/table/?disjunctive.regpri=GIG%2FGIC=19,48.85835,2.34721=jawg.streets
>>>
>> aucune idée de la fiabilité mais attention à la maintenance
>> vouloir renseigner les parkings jusqu'à l'emplacement individuel
>> en voirie, cela va faire un boulot de titan en maintenant
>> si tu regardes dans osmose opendata, tu verras que même
>> les objets qui varient peu manquent de bras pour être maintenu
> 
> 
> Bonjour,
> 
> plusieurs choses de mon point de vue :
> 
>  * aujourd'hui je dirai surtout que c'est l'utisabilité d'osmose-OD qui
>    est à questionner : nous avons commencé à travailler des catégories,
>    des manières de classer les données ouvertes pour pouvoir "séparer"
>    les parties visibles OpenData et QualityAnalysis  d'Osmose et nous
>    n'avons pas finalisé (je précise au cas où que ce n'est pas un
>    reproche de quelques formes que ce soit évidemment, car en plus
>    c'est peut-être moi qui n'ai pas fait :) ),
>  * le gros de l'effort est vraisemblablement à faire au départ pour
>    "l'intégration" du jeu initial de données, car Osmose a la
>    gentillesse par la suite de nous signaler des modifications : donc
>    si la collectivité modifie son jeu de données, Osmose le signale (en
>    vrai c'est des humains qui ont codé cela derrière pour
>    l'automatiser) et réciproquement si la donnée dans OSM est modifiée,
>    alors c'est signalé : ce qui peut aussi servir à la collectivité,
>  * Autour de telles données : évidemment que les contributeurs qui
>    souhaitent le faire peuvent le faire, cela n'exclut pas cependant
>    que les collectivités dédient du temps pour que des agents aient
>    pour mission de le faire, pour cela il faut qu'ils s'y retrouvent
>    également pour que le travail de titan puisse être partagé (et
>    surtout que ce travail est souvent déjà porté par la collectivité,
>    il manque surtout l'interface à OSM et pas "que" la libération d'un
>    jeu de données),
>  * et cela renvoie dans ce cas précis à quel schéma d'attributs :)
> 
> Bonne journée
> 
> 
> -- 
> 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] Cycleway : lane ou shoulder ?

[Phyks]

Bonjour,
> Beaucoup d'accotement ne réponde pas à la condition de largeur mais sont
> pourtant cyclable, d'où je pense l'intérêt d'ajouter cycleway=shoulder plus
> simple que d'aller mesure la largeur et d'ajouter la surface.

Je trouve cycleway=shoulder un peu trop subjectif dans ces cas-ci. On
perd un peu toute notion de largeur ou de surface au profit d'une
appréciation "un vélo peut l'utiliser". Je préférerais personnellement
grandement une description en terme de clé shoulder avec des
restrictions sur la largeur ou la surface, qui serait probablement plus
utilisable (mais moins taggée). Surtout qu'en France par exemple, tous
les accotements sont ouverts aux cyclistes il me semble (donc
cycleway=shoulder pourrait potentiellement se trouver sur toutes les
routes de campagne).

C'est dans tous les cas une information qui me semble très pertinente à
avoir, par exemple sur les itinéraires cyclotouristiques "fléchés" (par
les offices de tourisme) qui empruntent souvent des départementales,
parfois à fort trafic, sans infrastructure dédiée.

> De plus je pense que dans certains pays il est explicitement dit au vélo
> d'utiliser la voie d'arrêt d'urgence d'une voie rapide pour circuler d'où
> cycleway=shoulder.

Aux US par exemple, les autoroutes sont ouvertes aux vélos et il y a des
messages régulièrement pour indiquer aux cyclistes de rouler sur les
accotements. La présence de telles indications me semble plus pertinente
pour apprécier cycleway=shoulder ou non (dans ce cas, ça décrit non
seulement l'infrastructure disponible mais également l'infrastructure à
utiliser en pratique).

Aux US, certains trajets à vélos (vélotaf) obligent même à prendre des
autoroutes (pour traverser des ponts notamment), sous peine d'un détour
de plusieurs dizaines de kms !

> Le mer. 17 avr. 2019 à 13:45, marc marc  a
> écrit :
> 
>> Le 16.04.19 à 19:54, David Crochet a écrit :
>>> Le 16/04/2019 à 18:57, pepilepi...@ovh.fr a écrit :
 Que faut-il mettre ici
 <
>> https://www.google.com/maps/@44.8691841,4.9414101,3a,75y,23.5h,68.53t/data=!3m6!1e1!3m4!1spA2a-9LLzwId27j1sl1xJw!2e0!7i13312!8i6656>,
>>
 et là
 <
>> https://www.google.com/maps/@44.8801864,4.9418571,3a,75y,168.87h,80.37t/data=!3m7!1e1!3m5!1s_sGaBQVoR0tmZwsnVLnyBQ!2e0!6s%2F%2Fgeo0.ggpht.com%2Fcbk%3Fpanoid%3D_sGaBQVoR0tmZwsnVLnyBQ%26output%3Dthumbnail%26cb_client%3Dmaps_sv.tactile.gps%26thumb%3D2%26w%3D203%26h%3D100%26yaw%3D313.39432%26pitch%3D0%26thumbfov%3D100!7i13312!8i6656>
>>
 ?
>>>
>>> Ce ne sont pas forcément des bande cyclable
>>
>> je trouve même fantaisiste la définition de la page anglaise.
>> dire que l'accotement est mérite un cycleway=* lorsqu'il n'est
>> pas interdit d'y rouler... ce serrait comme dire que la rivière
>> mérite un cycleway=waterway si elle n'est pas interdite aux vélos.
>> j'aurais renseigné les 2 premiers cas avec cycleway=no
>> ___
>> 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
> 

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

Re: [OSM-talk-fr] Des projets de construction pas sorti de terre !

[Phyks]

Bonjour à tous,

Je me rajoute dans cette discussion car je suis tombé sur 
https://www.openstreetmap.org/user/Rom%C3%A9ro2878 qui a un certain 
nombre de modifications étranges, notamment avec des éléments qui 
semblent être en projet.


Il a actuellement des blocages en cours 
https://www.openstreetmap.org/user/Rom%C3%A9ro2878/blocks, sans aucune 
réponse aux messages de commits.


SomeoneElse me demande ce qu'il en est et si un revert doit être 
envisagé. Pour les gens qui sont du coin des éditions, avez-vous un avis 
sur la question ? Il y a à mon avis beaucoup de bruit avec du mauvais 
tagging et des choses qui n'existent visiblement pas sur le terrain. Je 
ne sais pas s'il y a des choses à garder malgré tout.


Bonne journée,
--
Phyks

Le 2019-03-20 14:58, Vincent Bergeot a écrit :

Bonjour,

CAS 1

je suis tombé sur des zones comme ici :
https://www.openstreetmap.org/#map=18/47.95889/1.87885

Qui ont été fait sur la base de permis de construire si nous en
croyons un auteur (https://www.openstreetmap.org/user/L3mp1ck4), et
quand on commence à regarder d'autres lieux d'interventions, c'est
souvent du même acabit.

Fait il y a 2 ans si on en croit le changeset :
https://www.openstreetmap.org/changeset/45891332#map=17/47.95862/1.87889


Et les photos aériennes, le cadastre ainsi que les photos mapillary
(sogefi est passé en juillet 2018) ne montrent rien.

J'ai laissé un commentaire :
https://www.openstreetmap.org/changeset/45891332#map=17/47.95862/1.87889


CAS 2

ce contributeur ajoute beaucoup de choses que l'on ne peut pas voir à
distance (https://www.openstreetmap.org/user/Dupuiche).

Et qui dans les 2 cas que j'ai pu constater de visu n'existe pas en
réalité :

* j'ai supprimé le bâtiment en construction dans la zone en
construction
(https://www.openstreetmap.org/way/566767211#map=19/44.83973/-0.60796)
car il n'y a rien de construit (c'est bien marqué comme étant une
zone future de construction)
* ici c'est un contributeur de Dax qui a du réparer :
https://www.openstreetmap.org/note/1446439#map=18/43.71920/-1.05219=N

et on en arrive à ceci
https://www.openstreetmap.org/changeset/67885844#map=19/45.65094/5.85979
que j'ai commenté.

Je me rends compte que cela se recoupe avec le cas 1 ici par exemple :
https://www.openstreetmap.org/changeset/67653948#map=18/47.95845/1.87842


CONCLUSION ?

plusieurs personnes qui alimentent OSM avec des projets de
constructions ? sur aucune réalité de terrain ?

Si vous avez des cas avérés (rien de visible sur le terrain
contrairement à ce que la carte montrer) proches de chez vous, pouvez
vous également faire des commentaires sur les changesets svp ?

Pour la suite, euh je ne sais jamais trop comment faire !

à plus

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


--
Phyks

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

Re: [OSM-talk-fr] [Vélo] Comment cartographier une station Velib’ divisée en 2 parties

[Phyks]

Salut,

J'ai eu le cas récemment avec celle-ci. J'ai fait deux points disjoints, 
mais je ne suis pas convaincu du tout par cette approche : 
https://www.openstreetmap.org/node/6043493986 et 
https://www.openstreetmap.org/node/5998636863. Le nom et la ref seront 
dupliquées, ce qui n'est pas optimal du tout.


En regardant en arrière avec Overpass, j'ai l'impression que même du 
temps de JCDecaux, les stations découpées n'étaient pas découpées dans 
OSM : https://overpass-turbo.eu/s/HDb.


Ça serait une information a priori intéressante à avoir dans OSM, 
notamment car les stations découpées n'ont en général qu'une seule 
partie accessible sans abonnement (du moins avec JCDecaux, seule une 
partie de la station était accessible sans badge d'accès, depuis la 
borne). Ceci dit, les données disponibles sont agrégées par station, 
donc en pratique, je ne sais pas si l'intérêt est si grand que ça : 
https://www.velib-metropole.fr/map#/.


Bonne journée,

Le 2019-04-03 13:28, Charles MILLET a écrit :

Bonjour,

Est-ce que vous savez si il y a une pratique pour cartographier une
station Velib’ qui est divisée en 2 parties comme ici par exemple, au
carrefour de la Rue Jacquard et la Rue Ternaux (à observer avec la
photo aérienne) ?

Pour l'instant j'ai placé le point sur une seule des 2 partie.

Bonne journée.


--
Phyks

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

Re: [OSM-talk-fr] [vélo] Introduction d'un tag complexe pour décrire les DSC sur bande dans le wiki

[Phyks]

Salut,

> En tant que structuraliste opposite_* est intolérable.

Il y a un certain nombre de cas comme ça d'ailleurs sur les attributs
vélos. J'ai en tête par exemple aussi le `bicycle_parking` dont la
variante `motorcycle_parking` n'existe pas. On se retrouve donc avec des
`amenity=motorcycle_parking` et `bicycle_parking=stands` qui ne sont
absolument pas ouverts ou prévus pour des vélos.


> Dans tous les cas, aujourd'hui je ne ressens aucun besoin de changer le
> schéma opposite_*

Idem, je vois un petit intérêt à utiliser l'alternative avec
`cycleway:*:oneway`, mais cela ne vaut probablement pas de casser tout
l'écosystème basé sur le schéma actuel à mon avis (déjà que tous les
outils ne supportent pas les cycleway:left/right proprement…).



Il y avait récemment eu une discussion sur des différences entre la
version anglaise et française de la page "Bicycle" du wiki il me semble
(sur talk-fr, sur un autre cas, mais je ne le retrouve plus :/).

-- 
Phyks


> Le mer. 13 mars 2019 à 22:11, Charles MILLET  a
> écrit :
> 
>> Dans l'absolu sa proposition tient la route. C'est juste que c'est un peu
>> lourd et que dans la pratique le opposite_lane est bien utilisé et
>> parfaitement interprétable.
>>
>> Et comme le dis marc c'est pas la bonne pratique, même quand on est
>> convaincu qu'on a raison... parce qu'on est nombreux à être convaincu
>> d'avoir raison :D
>>
>> J'avais vu ta position sur la distinction entre le sens et l'infra et
>> effectivement vous tombé plutôt d'accord. J'avais la même position il y a
>> quelques années... et puis j'ai laissé tombé :) et en fait j'ai admis que
>> la clé cycleway c'est qu'une clé et du moment qu'on est d'accord sur ce que
>> signifient les tags qui l'utilisent et bien on peut renoncer un peu à cette
>> logique. Donc vois si tu veux rester sur cette position mais dis toi que si
>> elle n'est pas adoptée ça n'aura pas trop d'influence... on en reparle
>> peut-être de vive voix bientôt ? ;)
>>
>> Pour l'instant j'essaie de prendre un peu le pouls sur cette approche du
>> DSC puisque les calculateurs ne l'utilisent pas je pense alors que les
>> cycleway:left/right=opposite_* sont plutôt admis (il me semble qu'au moins
>> BRouter et Geovelo les prennent en compte mais je pense que d'autres le
>> font).
>> On 13/03/2019 21:14, Florimond Berthoux wrote:
>>
>> Bonsoir,
>>
>> Et par ici aussi
>> https://wiki.openstreetmap.org/w/index.php?title=Tag%3Acycleway%3Dopposite_lane=revision=1820887=1639352
>> mais pas ici
>> https://wiki.openstreetmap.org/wiki/Key:cycleway#Dedicated_cycle_lanes
>> Je trouve la communauté particulièrement coulante vis-à-vis de ce genre de
>> modification unipersonnelle.
>>
>> Après je comprend tout à fait son point de vue : la signification d'un tag
>> devrait être la plus simple possible et ne pas comporter deux
>> significations comme avec opposite_lane (sens et infrastructure).
>>
>>
>> Le mer. 13 mars 2019 à 15:04, Charles MILLET  a
>> écrit :
>>
>>> Bonjour à tous
>>>
>>> Un contributeur a mis à jour la page wiki concernant la manière de
>>> décrire les doubles sens cyclables sur bande :
>>>
>>>
>>> https://wiki.openstreetmap.org/w/index.php?title=FR:Bicycle=next=1780997
>>>
>>> Pour résumer, il a supprimé les cycleway:left/richt=opposite_lane car
>>> cette valeur n'est pas documentée dans les valeurs des clé
>>> cycleway:left/richt (même si elle l'est pour la clé cycleway)
>>>
>>> Il recommande donc :
>>>
>>> highway=* + oneway=yes + cycleway:left=lane + cycleway:left:oneway=-1
>>>
>>> plutôt que
>>>
>>> highway=* + oneway=yes + cycleway:left=opposite_lane
>>>
>>> :'(
>>>
>>> Je lui ai envoyé un message pour lui exprimé avec politesse que je pense
>>> qu'il vaudrait mieux admettre ou officialiser
>>> cycleway:left=opposite_lane mais je m'attend que ce type de contribution
>>> traduise une volonté de respecter rigoureusement le wiki...
>>>
>>> Je m'adresse à la liste pour avoir votre avis au regard de l'usage qu'on
>>> peut observer sur taginfo et quelle serait la démarche pour revoir cette
>>> modification et dans l'idéal valider dans les règles les tags
>>> cycleway:left/right=opposite_lane
>>>
>>> Bonne journée
>>>
>>> Charles
>>>
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>&

Re: [OSM-talk-fr] Problème OSRM

[Phyks]

Bonjour,

Il semblerait qu'OSRM soit down en ce moment. 
https://routing.openstreetmap.de/routed-car/route/v1/driving/3.7456136941909794,43.448716857936766;3.7453401088714604,43.44872620477184?overview=false=polyline=true 
renvoie une erreur 500.



Le 2019-02-26 12:27, marc marc a écrit :

Le 26.02.19 à 11:58, Jérôme Seigneuret a écrit :

Bonjour,

Avez-vous ce genre de problème avec OSRM.
Impossible de trouver une route entre ces deux lieux.

https://www.openstreetmap.org/directions?engine=fossgis_osrm_car=43.44859%2C3.74357%3B43.44727%2C3.74199


le mur à travers la route repéré par JB ne devrait pas empecher de
trouver une autre route.
mais c'est un bug que j'ai régulièrement avec OSRM, exemple simplifié
https://www.openstreetmap.org/directions?engine=fossgis_osrm_car=43.44869%2C3.74422%3B43.44865%2C3.74429
souvent il suffit de bouger les marqueurs d'un millimètre
mais là cela ne fonctionne pas
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


--
Phyks

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

[OSM-talk-fr] Un rendu cyclable libre ?

[Phyks]

Bonjour à toutes et à tous,

Nous avons pas mal avancé sur la question d'un rendu cyclable libre avec
Florimond, suite à mon dernier message.

Une démonstration autour de Paris (pour une zone urbaine dense) et
Clermont-Ferrand (pour plus de routes de campagnes) est disponible sur
https://tiles.phyks.me/ entre les zooms 0 et 18. Le code est disponible
et réutilisable sur https://github.com/cyclosm/cyclosm-cartocss-style/.

Il devrait actuellement contenir la plupart des éléments importants :

- pistes cyclables
- bandes cyclables
- POIs
- différents niveaux d'itinéraires cyclables
- quelques améliorations sur OpenCycleMap dont la prise en compte des
voies de bus partagées, des parkings motos autorisés aux vélos et de
plus d'abris (shelter).

La motivation principale guidant les choix de rendus pour l'instant est
d'avoir un rendu adapté aux cyclistes (urbains, vélotaffeurs, ou
cyclotouristes en rando), comme OpenCycleMap, qui puisse également être
utilisé par les associations de cyclistes pour repérer et identifier les
aménagements cyclables et identifier les discontinuités / points faibles
du réseau (ce qui motive le rendu d'un certain nombre d'éléments peu
rendus habituellement tels que les ralentisseurs, déjà traités, ou les
sas vélos et les cédez-le-passage-cycliste, à venir).

Le principal problème connu actuellement est d'ordre stylistique, avec
une palette de couleurs et des icônes à revoir, qui manque un peu de
contraste et de peps.

Un certain nombre d'éléments manquants ou à améliorer est listé dans les
tickets Github, sur
https://github.com/cyclosm/cyclosm-cartocss-style/issues, avec des
labels "good first issue" pour les tickets les plus faciles et "help
wanted" pour les plus complexes. :)

N'hésitez pas à ouvrir des tickets sur Github ou à commenter ici, nous
serions très intéressés par des retours sur cette première version.
Toute aide supplémentaire sur ce rendu est la bienvenue également :)

Bonne journée,
-- 
Phyks
Le 26/01/2019 à 17:09, Phyks a écrit :
> Bonjour à tous,
> 
> Finalement, suite aux retours de plusieurs contributeurs, je suis
> (re)parti sur un style CartoCSS, raster.
> 
> J'ai du coup une première version (plus complète que le style vectoriel
> du message ci-dessous) : https://github.com/Phyks/cyclosm-cartocss-style.
> 
> J'ai mis une démo de ce que ça donne actuellement (Paris, entre les
> zooms 12 et 17) sur https://tiles.phyks.me/#12/48.8588/2.3470. Il y a
> encore du boulot, c'est une toute première version.
> 
> N'hésitez pas à ouvrir des tickets sur Github pour des retours ou idées.
> Tout contribution est bien entendue la bienvenue aussi :)
> 
> Bonne journée,
> -- 
> Phyks
> 
> Le 13/01/2019 à 17:12, Phyks a écrit :
>> Bonjour,
>>
>> Pour ceux qui étaient intéressés par un style libre similaire à
>> OpenCycleMap, j'ai un peu avancé sur cette question, en me basant sur
>> OpenMapTiles (https://github.com/openmaptiles/openmaptiles).
>>
>> Le résultat est ici pour l'instant :
>> https://github.com/Phyks/cyclosm-basic-gl-style. C'est assez basique et
>> il manque notamment les valeurs des tags cycleway (voir
>> https://github.com/openmaptiles/openmaptiles/issues/572) et les noms des
>> relations cyclables (mais les relations sont affichées).
>>
>> N'hésitez pas à me faire signe si vous souhaitez contribuer et avez
>> besoin d'un coup de main pour démarrer :)
>>
>> Au passage, est-ce que par hasard quelqu'un a un serveur OpenMapTiles
>> déjà en service (ou un serveur tout court) et serait intéressé pour
>> rajouter [quelques éléments en
>> plus](https://github.com/openmaptiles/openmaptiles/compare/master...Phyks:cyclosm)
>> pour que le style puisse être affiché facilement sur une carte de démo
>> quelque part ?
>>
>> Bonne journée !
>> -- 
>> Phyks
>>
>> Le 13/12/2018 à 16:44, Phyks a écrit :
>>> Bonjour,
>>>
>>> Je ne saurais répondre particulièrement sur la question des network =
>>> icn, mais OpenCycleMap n'est pas libre (contrairement à ce que son nom
>>> pourrait laisser penser). Ce n'est donc pas possible de contribuer. En
>>> revanche, il y a un suivi de tickets ici
>>> https://trac.openstreetmap.org/query?component=opencyclemap. L'autre
>>> solution est de contacter directement l'auteur par
>>> http://thunderforest.com/contact/.
>>>
>>> En rapport, il était question hier sur le canal IRC osm-fr d'essayer
>>> d'avoir un vrai rendu cyclable collaboratif et libre. OpenCycleMap a un
>>> certain nombre de problèmes/limitations, dont certains qui ne seront
>>> peut être jamais corrigés (comme ça, je vois notamment la question des
>>> parkings partagés motos / vélos qui sont ignorés 

Re: [OSM-talk-fr] Relations de cédez-le-passage cycliste incomplètes

[Phyks]

Bonjour,

J'ai regardé un peu plus en détails, sur Paris je trouve 516 relations
incomplètes sur 584 relations en tout pour l'instant. :/ Sur les 516
relations incomplètes, 498 viennent du même contributeur, je vais le
contacter.

> je pense en effet que c'est le mieux à faire.
> en même temps faire une relation pour un cédez le passage, c'est une 
> usine à gaz. on ne le fait pas pour les cedz le passage normal, ni pour 
> les stop, aucun outil n'a de problème à comprendre que cela s'applique 
> au carefour le plus proche ou d'utiliser direction=*

Le problème ici est que cela ne s'applique qu'à certaines branches du
croisement. Tu peux avoir le droit de tourner à droite au feu avec un
cédez le passage cycliste (CLPC), mais devoir quand même respecter le
feu pour aller tout droit ou à gauche.

Une manière plus simple d'annoter ceci serait probablement utile en
effet, mais cela reste un peu plus compliqué qu'un "cédez le passage"
normal. Je n'ai pas trouvé grand chose d'autre dans le wiki que le
schéma français avec la relation.

Ceci dit, taginfo trouve 1264 telles relations CLPC
(https://taginfo.openstreetmap.org/tags/restriction%3Abicycle=give_way#overview).
Visiblement, presque la moitié sont à Paris (584 à Paris) et la plupart
sont incomplètes :/

-- 
Phyks

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

Re: [OSM-talk-fr] Moulinette pour ajouter "oneway:bicycle=no" ?

[Phyks]

Bonsoir,

Désolé, je suis un peu perdu dans le fil…

>> Le cas S1 est un exemple, ce qui prévaut ce sont les définitions des tags
>> et des attributs.
>> S'il faut documenter toutes les combinaisons de tags/attributs on n'a pas
>> finit.
>>
> 
> Ben justement le wiki le permet et c'est le meilleur moyen pour que les
> données soient cohérentes.

Quelqu'un voit-il une raison pour ne pas éditer le wiki en vue
d'harmoniser sur la version anglaise qui utilise les cycleway:left/right
chaque fois que c'est utilisable (c'est à dire la plupart des cas, mais
*pas* opposite) ?


D'autre part, une requête Overpass sur Paris
(https://overpass-turbo.eu/s/FVI) retourne 103 chemins avec
cycleway:left=opposite, qui si j'y bien suivi la discussion précédente
est considéré comme invalide aujourd'hui. Ne devrait-on pas corriger ces
valeurs et éventuellement rajouter une analyse qualité dessus ?

Bonne soirée,
-- 
Phyks

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

Re: [OSM-talk-fr] Doublons landuse=residential et place=town

[Phyks]

Bonsoir,
Le 04/02/2019 à 14:18, osm.sanspourr...@spamgourmet.com a écrit :
> L'autre question est : est-ce qu'un name sur landuse=residential a un
> sens quand ce nom est celui de la commune (sauf à avoir une commune
> purement dortoir sans autre activité) ?

Pour moi c'est en effet le problème. Que le landuse soit imprécis, ce
n'est pas très grave et le travail itératif d'OSM fait qu'on peut le
corriger ultérieurement, mais le problème ici semble être que le
landuse=residential se situe sur le même objet que le
boundary=administrative.

Une correction pourrait être de créer un deuxième objet, identique au
boundary=administrative pour porte le tag landuse=residential seul.
Serait-ce une correction acceptable ?


J'ai essayé d'extraire les boundary=administrative + landuse=residential
avec Overpass, mais la requête demande trop de RAM visiblement. J'ai une
(petite) base PostGIS avec Auvergne + Ile de France, et j'ai trouvé pour
l'instant les 30 entrées suivantes qui sont concernées :

 Quartier Châtillon   | residential
 Paris 16e Arrondissement | residential
 Juvisy-sur-Orge  | residential
 Malakoff | residential
 Montrouge| residential
 Cachan   | residential
 Arcueil  | residential
 Gentilly | residential
 Le Kremlin-Bicêtre   | residential
 Paris 15e Arrondissement | residential
 Paris 14e Arrondissement | residential
 Paris 7e Arrondissement  | residential
 Paris 13e Arrondissement | residential
 Paris 6e Arrondissement  | residential
 Paris 1er Arrondissement | residential
 Paris 5e Arrondissement  | residential
 Paris 4e Arrondissement  | residential
 Paris 3e Arrondissement  | residential
 Ivry-sur-Seine   | residential
 Paris 11e Arrondissement | residential
 Paris 20e Arrondissement | residential
 Paris 12e Arrondissement | residential
 Paris 17e Arrondissement | residential
 Paris 8e Arrondissement  | residential
 Clichy   | residential
 Paris 9e Arrondissement  | residential
 Paris 2e Arrondissement  | residential
 Paris 10e Arrondissement | residential
 Paris 18e Arrondissement | residential
 Paris 19e Arrondissement | residential


Bonne soirée,
-- 
Phyks

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

[OSM-talk-fr] Relations de cédez-le-passage cycliste incomplètes

[Phyks]

Bonjour,

Le wiki mentionne qu'une relation de cédez-le-passage cycliste (aux
feux) devrait être une relation de type restriction, avec un membre
from, un membre to et un membre via
(https://wiki.openstreetmap.org/wiki/FR:Bicycle#Panonceaux_de_C.C3.A9dez-le-passage_cycliste_au_feu).

Pourtant, de nombreuses telles relations sont incomplètes avec
uniquement un membre "via". Cela ne me semble pas très utilisable. C'est
le cas par exemple de https://www.openstreetmap.org/relation/7507011.

Y a-t-il un sens particulier dans ce cas-ci, absent du wiki ? On
pourrait comprendre qu'il s'agit de tous les mouvements de "tourne à
droite" possibles, mais cela me paraît hasardeux vu qu'on voit désormais
apparaître des panneaux "cédez le passage" pour des mouvements "va tout
droit ou à droite", voir pour tous les mouvements possibles.

Si ces relations sont invalides, je pourrais regarder pour essayer
d'ajouter une règle à Osmose (je ne crois pas qu'il y en ait).

Merci !
Bonne soirée,
-- 
Phyks

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

Re: [OSM-talk-fr] Moulinette pour ajouter "oneway:bicycle=no" ?

[Phyks]

Désolé, mon message n'était pas très clair. Il y avait deux parties
distinctes (sans lien).

1) Comment pourrait-on facilement annoter un contresens cyclable avec
voie partagée, sur le côté droit (donc inhabituel en France) ?

2) La page wiki en anglais utilise pleinement les cycleway:left/right
quand la page en français se limite principalement à cycleway. Ne
devrait-on pas s'aligner sur la page en anglais pour encourager à
l'utilisation de cycleway:left/right ?

Par rapport à 2, j'ai tendance à penser qu'on a tout intérêt à
distinguer avec left/right dans les cas satisfaisants (documentés sur la
version en anglais notamment). Et qu'en voyant la page en anglais
utiliser les left/right mais conserver cycleway=opposite, on est moins
tenté d'introduire un cycleway:left=opposite.

Bonne soirée,
-- 
Phyks
Le 06/02/2019 à 22:21, Romain MEHUT a écrit :
> Non même la page wiki en anglais n'indique pas ces tags pour le cas S1.
> 
> Romain
> 
> Le mer. 6 févr. 2019 à 22:16, Phyks  a écrit :
> 
> 
>> Sinon, en regardant la page du wiki, j'ai l'impression que la page
>> anglaise utilise autant que possible les cycleway:left/right, quand la
>> page française se contente de cycleway. Ne devrait-on pas essayer
>> d'harmoniser (en faveur de cycleway:left/right) ?
> 
> 
> ___
> 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] Moulinette pour ajouter "oneway:bicycle=no" ?

[Phyks]

Bonsoir,

Quelques messages plus haut, Florimond écrivait :

> Je ne vois pas pourquoi cycleway:left=opposite serait incorrecte, je
> connais une rue à Paris ou les pictos vélo sont en cycleway:right (oui les
> cyclistes en contre sens rouleraient à gauche, à l'anglaise).
> La magie de la cartographie vélo c'est que tout est possible et tout a été
> fait :D.

J'ai le même exemple en tête. Il y a quelques raretés comme cela,
souvent en pensant bien faire pour éloigner les cyclistes du
stationnement. Quelle serait la bonne façon de l'annoter ?



Sinon, en regardant la page du wiki, j'ai l'impression que la page
anglaise utilise autant que possible les cycleway:left/right, quand la
page française se contente de cycleway. Ne devrait-on pas essayer
d'harmoniser (en faveur de cycleway:left/right) ?

Bonne soirée,
-- 
Phyks
Le 06/02/2019 à 21:38, Romain MEHUT a écrit :
> Le mer. 6 févr. 2019 à 10:49, Florimond Berthoux <
> florimond.berth...@gmail.com> a écrit :
> 
>> La table est une liste d'exemples de cas, elle n'est pas limitative.
>>
> 
> Comme Antoine, j'insiste, il convient de respecter les tags documentés dans
> le wiki et cycleway:left=opposite ne l'est pas pour le cas S1 présenté
> initialement.
> 
> Romain
> 
> 
> ___
> 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] Crawler sur les horaires d'ouverture

[Phyks]

Salut,

Il y a un projet (lancé par Mapzen je crois), qui a l'air encore actif
pour faire ceci : https://github.com/alltheplaces/alltheplaces.

Le code est libre sous licence MIT, les données sont affichées comme
étant sous CC0 (donc compatible pour OSM), mais ce n'est pas si évident
que ça qu'elles puissent vraiment être sous licence CC0 étant donné le
mode de récupération.

Il y a pas mal de grandes chaînes supportées, dont certaines françaises.

Bonne soirée,
-- 
Phyks
Le 06/02/2019 à 18:57, Epickiwi a écrit :
> Bonjour tout le monde,
> 
> 
> Les horaires d'ouverture des POI sont, le plus souvent, présent sur les sites 
> officiels ou les pages sociales de ces POI. 
> 
> 
> Je me demande si cela est légale au niveau de la licence OSM de créer un 
> robot qui va chercher sur ces pages de reseaux sociaux ou le site officiel 
> les horaires d'ouverture et les ajouter aux données dans le tag 
> `opening_hours`.
> 
> Peut être que ce genre de robot existe déjà...
> 
> 
> Bonne journée
> 
> 
> ___
> 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] Doublons landuse=residential et place=town

[Phyks]

Bonjour,

Il y a un attribut "landuse=residential" à Montrouge sur le même
polygone que le "boundary=administrative" :
https://www.openstreetmap.org/relation/37026. En revanche, la ville en
elle-même est séparée, sur un nœud "place=town" :
https://www.openstreetmap.org/node/26692584.

Je suis tombé dessus en rapportant un bug sur le rendu
https://github.com/gravitystorm/openstreetmap-carto/issues/3664, qui
fait apparaître le nom "Montrouge" en plusieurs exemplaires sur la carte.

Le problème est que le "landuse=residential" correspond à toute
l'étendue de la ville de Montrouge et a un nom associé. Or, le rendu
osm.org affiche les noms des "landuse=residential" (pour afficher les
noms des résidences et aires d'accueil des gens du voyage par exemple).
Le nom sur ce landuse fait doublon avec celui sur le nœud place=town,
d'où le double affichage sur le fond de carte, à certains niveaux de
zooms uniquement.

J'ai l'impression que d'une part ce landuse est incorrect (toute la
ville n'est pas purement résidentielle, il y a des activités
commerciales ou industrielles par exemple) et d'autre part ce landuse ne
devrait probablement pas contenir de nom, qui est déjà sur le place=town.

Pourtant c'est fait de la même façon sur certaines villes alentour comme
Malakoff, Arcueil etc. Donc il y a probablement une justification et je
ne sais pas comment le corriger vraiment. En particulier, je ne sais pas
si le doublon de nom "Montrouge" entre le "boundary=administrative"
(https://www.openstreetmap.org/relation/37026) et le "place=town"
(https://www.openstreetmap.org/node/26692584) est normal ?

Je vois deux solutions pour l'instant :

1. La solution naïve : créer un polygone séparé qui recouvre la même
surface que https://www.openstreetmap.org/relation/37026 et ajouter le
"landuse=residential" dessus (pour séparer le "landuse=residential" du nom).
2. Faire une vraie correction, probablement en créant un multipolygone
exact pour le landuse=residential ?

Auriez-vous plus d'informations ou de conseils à ce sujet ?

Bonne journée,
-- 
Phyks

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

Re: [OSM-talk-fr] Opencyclemap : absence des relations network= icn

[Phyks]

Bonjour à tous,

Finalement, suite aux retours de plusieurs contributeurs, je suis
(re)parti sur un style CartoCSS, raster.

J'ai du coup une première version (plus complète que le style vectoriel
du message ci-dessous) : https://github.com/Phyks/cyclosm-cartocss-style.

J'ai mis une démo de ce que ça donne actuellement (Paris, entre les
zooms 12 et 17) sur https://tiles.phyks.me/#12/48.8588/2.3470. Il y a
encore du boulot, c'est une toute première version.

N'hésitez pas à ouvrir des tickets sur Github pour des retours ou idées.
Tout contribution est bien entendue la bienvenue aussi :)

Bonne journée,
-- 
Phyks

Le 13/01/2019 à 17:12, Phyks a écrit :
> Bonjour,
> 
> Pour ceux qui étaient intéressés par un style libre similaire à
> OpenCycleMap, j'ai un peu avancé sur cette question, en me basant sur
> OpenMapTiles (https://github.com/openmaptiles/openmaptiles).
> 
> Le résultat est ici pour l'instant :
> https://github.com/Phyks/cyclosm-basic-gl-style. C'est assez basique et
> il manque notamment les valeurs des tags cycleway (voir
> https://github.com/openmaptiles/openmaptiles/issues/572) et les noms des
> relations cyclables (mais les relations sont affichées).
> 
> N'hésitez pas à me faire signe si vous souhaitez contribuer et avez
> besoin d'un coup de main pour démarrer :)
> 
> Au passage, est-ce que par hasard quelqu'un a un serveur OpenMapTiles
> déjà en service (ou un serveur tout court) et serait intéressé pour
> rajouter [quelques éléments en
> plus](https://github.com/openmaptiles/openmaptiles/compare/master...Phyks:cyclosm)
> pour que le style puisse être affiché facilement sur une carte de démo
> quelque part ?
> 
> Bonne journée !
> -- 
> Phyks
> 
> Le 13/12/2018 à 16:44, Phyks a écrit :
>> Bonjour,
>>
>> Je ne saurais répondre particulièrement sur la question des network =
>> icn, mais OpenCycleMap n'est pas libre (contrairement à ce que son nom
>> pourrait laisser penser). Ce n'est donc pas possible de contribuer. En
>> revanche, il y a un suivi de tickets ici
>> https://trac.openstreetmap.org/query?component=opencyclemap. L'autre
>> solution est de contacter directement l'auteur par
>> http://thunderforest.com/contact/.
>>
>> En rapport, il était question hier sur le canal IRC osm-fr d'essayer
>> d'avoir un vrai rendu cyclable collaboratif et libre. OpenCycleMap a un
>> certain nombre de problèmes/limitations, dont certains qui ne seront
>> peut être jamais corrigés (comme ça, je vois notamment la question des
>> parkings partagés motos / vélos qui sont ignorés ou l'absence de rendu
>> de zone pour les zones commerciales, qui offrent souvent des points
>> d'eau / toilettes même s'ils ne sont pas explicitement renseignés dans
>> OSM). Plusieurs personnes étaient intéressées, je profite de ce message
>> pour relayer l'info, si d'autres personnes pourraient également être
>> intéressées / vouloir participer.
>>
>> Bonne journée,
>> -- 
>> Phyks
>>
>> Le 2018-12-13 16:21, Mathias Vadot a écrit :
>>> Bonjour à tous,
>>>
>>> Après plusieurs test, je me rends compte que le fond de carte OCM
>>> n’affiche pas les itinéraires internationaux, relations taguées de
>>> cette manière : network = icn. [1] Je m’en suis rendu compte pour
>>> les relations que je connais en France [2], mais c’est finalement un
>>> problème globale. Les relations bien visibles en rouge [3] sont
>>> tagué comme étant des relations nationale, network = ncn [4].
>>>
>>> Dans la légende [5], les icn n’ont en effet pas l’air d’avoir
>>> leurs places, ce qui parait aberrant.  Est-ce un problème qui a
>>> déjà été relevé ? Je n’ai pas trouvé le github de ce projet.
>>>
>>> Mathias
>>>
>>>   [6]
>>>  Garanti sans virus. www.avast.com [6]
>>>
>>>
>>>
>>> Links:
>>> --
>>> [1] https://wiki.openstreetmap.org/wiki/Tag:network%3Dicn
>>> [2]
>>> https://www.openstreetmap.org/relation/5448020#map=15/50.2451/4.0115layers=C
>>>
>>> [3]
>>> https://www.openstreetmap.org/relation/5445857#map=9/49.4360/-1.0547layers=C
>>>
>>> [4] https://wiki.openstreetmap.org/wiki/Tag:network%3Dncn
>>> [5] http://www.opencyclemap.org/docs/
>>> [6]
>>> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>> -- 
>> Phyks
>>
>> ___
>> 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] Fusion de communes... LE chantier annuel ;)

[Phyks]

Ok ! Merci pour la confirmation,
-- 
Phyks
Le 20/01/2019 à 20:08, osm.sanspourr...@spamgourmet.com a écrit :
> Oui on a déjà eu ça l'an dernier : tant que l'INSEE n'a pas fourni les
> nouveaux codes (par exemple en disant très probablement que le nouveau
> code de Vindry-sur-Turdine c'est l'ancien code de Poncharra-sur-Turdine,
> Osmose vérifie avec les anciens codes alors que Christian a anticipé les
> décisions de l'INSEE.
> 
> C'est bien un faux positif.
> 
> Jean-Yvon
> 
> Le 20/01/2019 à 17:48, Phyks - ph...@phyks.me a écrit :
>> Bonjour à tous,
>>
>> J'ai vu une erreur Osmose sur
>> https://www.openstreetmap.org/relation/9135480, disant que le code
>> commune ne correspond pas au nom de la commune. Cette commune a été
>> affectée par une fusion au 1er janvier.
>>
>> En creusant un peu, le code commune 69157 était utilisé par
>> Poncharra-sur-Turdine et semble bien avoir été attribué à la commune
>> nouvelle Vindry-sur-Turdine. En tout cas, c'est l'info que je trouve sur
>> Wikipedia et dans https://www.insee.fr/fr/information/2549968.
>>
>> J'ai marqué en faux positif sur Osmose pour l'instant, mais je ne sais
>> pas si cette erreur est normale / attendue ? D'autres cas similaires
>> existent peut être (réattribution d'un code commune précédent à une
>> nouvelle commune).
>>
>> Bonne journée,
> 
> 
> ___
> 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] Fusion de communes... LE chantier annuel ;)

[Phyks]

Bonjour à tous,

J'ai vu une erreur Osmose sur
https://www.openstreetmap.org/relation/9135480, disant que le code
commune ne correspond pas au nom de la commune. Cette commune a été
affectée par une fusion au 1er janvier.

En creusant un peu, le code commune 69157 était utilisé par
Poncharra-sur-Turdine et semble bien avoir été attribué à la commune
nouvelle Vindry-sur-Turdine. En tout cas, c'est l'info que je trouve sur
Wikipedia et dans https://www.insee.fr/fr/information/2549968.

J'ai marqué en faux positif sur Osmose pour l'instant, mais je ne sais
pas si cette erreur est normale / attendue ? D'autres cas similaires
existent peut être (réattribution d'un code commune précédent à une
nouvelle commune).

Bonne journée,
-- 
Phyks

Le 13/01/2019 à 08:12, Christian Quest a écrit :
> L'INSEE va publier une liste en principe la semaine prochaine... je referai
> une passe en me basant dessus.
> 
> Le dim. 13 janv. 2019 à 01:49, Jérôme Amagat  a
> écrit :
> 
>> Plusieurs ajouts sur Wikipédia depuis le 1er janvier :
>> https://fr.wikipedia.org/wiki/Liste_des_communes_nouvelles_cr%C3%A9%C3%A9es_en_2019
>> il y a des cas bizarres :( :
>> Beyrede-Jumet-Camous sans accent sur Beyrede dans l’arrêté préfectoral
>> alors qu'il y en avait sur l'ancienne commune de Beyrède-Jumet.
>> Fresnay-sur-Sarthe : composé de 3 communes qui ne se touchent pas toutes
>> alors qu'il me semble que c'est obligatoire. Il semble n'y avoir que
>> quelques mètres entre les anciennes communes de Fresnay-sur-Sarthe
>> et Saint-Germain-sur-Sarthe mais elle ne sont pas contiguës.
>> https://www.openstreetmap.org/relation/107624 et
>> https://www.openstreetmap.org/relation/107591.
>> Cette commune nouvelle de Fresnay-sur-Sarthe n'existe pas encore dans osm
>> contrairement aux autres.
>>
>>
>> Le lun. 31 déc. 2018 à 19:53, Christian Quest  a
>> écrit :
>>
>>> Il y a encore de très nombreux usages des limites de communes
>>> correspondant à quelques années en arrière et c'est donc utile de les
>>> conserver quelques années.
>>>
>>> Bien sûr ça pourra dégager quand ça ne servira plus, mais on a aussi des
>>> appellations qui dureront bien plus longtemps car ces communes nouvelles
>>> sont souvent une création vécue comme artificielle par les habitants.
>>>
>>> En choisissant des tags non ambigus, on évite les erreurs pouvant laisser
>>> penser qu'une emprise "passée" est actuelle.
>>> Je pense qu'il n'y a pas de souci pour les réutilisateurs qui se fichent
>>> de ces infos, et rien de spécial à faire pour les contributeurs... ces
>>> infos étant très stables dans le temps, ce n'est pas là dessus qu'on
>>> contribue beaucoup ;)
>>>
>>>
>>> Le lun. 31 déc. 2018 à 19:07, JB  a écrit :
>>>
>>>> Question bête d'un gars dont ce n'est pas le métier :
>>>> Est-ce que c'est vraiment à conserver dans OSM ?
>>>> Avant, on avait juste les admin_level=8. On a transformé en =9 pour les
>>>> anciennes communes. Maintenant, on voudrait repasser les nouvelles =8 en
>>>> quelque chose d'autre parce qu'une commune a intégré la nouvelle commune
>>>> pour faire une autre nouvelle commune ? Est-ce que le modèle de tags d'OSM
>>>> est vraiment fait pour ça ? Est-ce que quelqu'un y comprendra quelque chose
>>>> ? Dans un an, dans 10 ans ? Est-ce qu'un réutilisateur potentiel n'ira pas
>>>> chercher les éléments dans une autre base de données, quitte à ajouter
>>>> l'information spatiale à partir d'éléments simples d'OSM ?
>>>> Dubitatif, et toujours adepte de garder de l'information simple. Pour la
>>>> comprendre quand on contribue. Moi, et surtout les nouveaux contributeurs
>>>> potentiels, qui ne connaissent rien au sujet.
>>>> JB.
>>>>
>>>> Le 31/12/2018 à 18:18, Christian Quest a écrit :
>>>>
>>>> Oui, il va falloir suivre les publications de dernière minute... quel
>>>> bazar !
>>>> Je suis presque chaud pour rajouter un 4ème épisode à ma série
>>>> "Millésimons"*
>>>>
>>>> Bien vue la requête overpass, heureusement que mon script amis à jour
>>>> les admin_level sur les anciennes frontières internes des communes
>>>> nouvelles ;)
>>>>
>>>> Pour les EPCI, il va falloir attendre que la DGCL publie une liste à
>>>> jour (base BANATIC).
>>>>
>>>> Pour les anciennes communes nouvelles qui se sont étendues, j'ai en
>>>> principe mis à jour admin_type:FR=ancienne commune nouvelle
>>>>
>

Re: [OSM-talk-fr] Opencyclemap : absence des relations network= icn

[Phyks]

On en avait rapidement discuté sur IRC. S'il y a un intérêt pour ce type
de rendu et que OSM-FR a de la place sur de futurs serveurs pour
proposer ce rendu, ce serait clairement super ! :)

-- 
Phyks

Le 16/01/2019 à 20:39, Vincent Bergeot a écrit :
> Le 16/01/2019 à 12:38, Vincent Bergeot a écrit :
>>
>> Bonjour
>>
>> Le 16/01/2019 à 12:35, Jérôme Seigneuret a écrit :
>>> Salut, tu peux proposer ton aide et voir sur la liste
>>> t...@listes.openstreetmap.fr
>>> <mailto:t...@listes.openstreetmap.fr> pour la partie concernant ces
>>> sujets
>>
>> je viens de poser la question :) plusieurs serveurs sont arrivés mais
>> je n'ai pas la vision précise des ressources. Effectivement, je pense
>> que cela serait un joli projet :)
>>
> confirmation qu'il va y avoir de la place, mais il faut attendre un peu
> le temps que les chouettes résultats financiers de la campagne de dons
> se transforment en serveurs et ressources supplémentaires !
> 
> @Phyk, n'hésites pas à relancer :)
> 
> à plus
> 
> -- 
> 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] Opencyclemap : absence des relations network= icn

[Phyks]

Bonjour,

Merci ! Je veux bien démarrer un sujet sur le forum, mais je ne l'ai que 
peu utilisé à présent. Dans quelle catégorie devrais-je poster ?


Par ailleurs, par rapport à ma demande d'un éventuel hébergement 
existant de tuiles OpenMapTiles :
* Il ne semble y avoir aucun serveur de tuiles vectorielles pour 
l'instant au niveau de OSM-Fr.
* J'ai en revanche découvert que si je faisais mon fichier mbtiles 
moi-même, je pouvais l'envoyer sur Mapbox et l'utiliser.


Du coup, j'ai mis une petite démo en ligne ici 
https://phyks.github.io/cyclosm-basic-gl-style/examples/openlayers.html.


C'est limité à l'Ile-de-France et au bout de 50 000 vues par mois ça va 
couper (service gratuit de Mapbox), mais ça permet d'avoir une petite 
démo de ce que ça donne pour l'instant :)


Bonne journée,
--
Phyks

Le 2019-01-14 09:51, Antoine Riche a écrit :

Bonjour.

Belle initiative Phyks ! Ça m'intéresse bien de participer, et oui
j'aurais besoin d'un peu d'aide pour démarrer :-)

Est-ce qu'on démarre un sujet dédié sur le forum ?

Antoine.
Le 13/01/2019 à 17:12, Phyks a écrit :


Bonjour,

Pour ceux qui étaient intéressés par un style libre similaire à
OpenCycleMap, j'ai un peu avancé sur cette question, en me basant
sur
OpenMapTiles (https://github.com/openmaptiles/openmaptiles).

Le résultat est ici pour l'instant :
https://github.com/Phyks/cyclosm-basic-gl-style. C'est assez basique
et
il manque notamment les valeurs des tags cycleway (voir
https://github.com/openmaptiles/openmaptiles/issues/572) et les noms
des
relations cyclables (mais les relations sont affichées).

N'hésitez pas à me faire signe si vous souhaitez contribuer et
avez
besoin d'un coup de main pour démarrer :)

Au passage, est-ce que par hasard quelqu'un a un serveur
OpenMapTiles
déjà en service (ou un serveur tout court) et serait intéressé
pour
rajouter [quelques éléments en


plus](https://github.com/openmaptiles/openmaptiles/compare/master...Phyks:cyclosm)

pour que le style puisse être affiché facilement sur une carte de
démo
quelque part ?

Bonne journée !

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


--
Phyks

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

Re: [OSM-talk-fr] Opencyclemap : absence des relations network= icn

[Phyks]

Bonjour,

Pour ceux qui étaient intéressés par un style libre similaire à
OpenCycleMap, j'ai un peu avancé sur cette question, en me basant sur
OpenMapTiles (https://github.com/openmaptiles/openmaptiles).

Le résultat est ici pour l'instant :
https://github.com/Phyks/cyclosm-basic-gl-style. C'est assez basique et
il manque notamment les valeurs des tags cycleway (voir
https://github.com/openmaptiles/openmaptiles/issues/572) et les noms des
relations cyclables (mais les relations sont affichées).

N'hésitez pas à me faire signe si vous souhaitez contribuer et avez
besoin d'un coup de main pour démarrer :)

Au passage, est-ce que par hasard quelqu'un a un serveur OpenMapTiles
déjà en service (ou un serveur tout court) et serait intéressé pour
rajouter [quelques éléments en
plus](https://github.com/openmaptiles/openmaptiles/compare/master...Phyks:cyclosm)
pour que le style puisse être affiché facilement sur une carte de démo
quelque part ?

Bonne journée !
-- 
Phyks

Le 13/12/2018 à 16:44, Phyks a écrit :
> Bonjour,
> 
> Je ne saurais répondre particulièrement sur la question des network =
> icn, mais OpenCycleMap n'est pas libre (contrairement à ce que son nom
> pourrait laisser penser). Ce n'est donc pas possible de contribuer. En
> revanche, il y a un suivi de tickets ici
> https://trac.openstreetmap.org/query?component=opencyclemap. L'autre
> solution est de contacter directement l'auteur par
> http://thunderforest.com/contact/.
> 
> En rapport, il était question hier sur le canal IRC osm-fr d'essayer
> d'avoir un vrai rendu cyclable collaboratif et libre. OpenCycleMap a un
> certain nombre de problèmes/limitations, dont certains qui ne seront
> peut être jamais corrigés (comme ça, je vois notamment la question des
> parkings partagés motos / vélos qui sont ignorés ou l'absence de rendu
> de zone pour les zones commerciales, qui offrent souvent des points
> d'eau / toilettes même s'ils ne sont pas explicitement renseignés dans
> OSM). Plusieurs personnes étaient intéressées, je profite de ce message
> pour relayer l'info, si d'autres personnes pourraient également être
> intéressées / vouloir participer.
> 
> Bonne journée,
> -- 
> Phyks
> 
> Le 2018-12-13 16:21, Mathias Vadot a écrit :
>> Bonjour à tous,
>>
>> Après plusieurs test, je me rends compte que le fond de carte OCM
>> n’affiche pas les itinéraires internationaux, relations taguées de
>> cette manière : network = icn. [1] Je m’en suis rendu compte pour
>> les relations que je connais en France [2], mais c’est finalement un
>> problème globale. Les relations bien visibles en rouge [3] sont
>> tagué comme étant des relations nationale, network = ncn [4].
>>
>> Dans la légende [5], les icn n’ont en effet pas l’air d’avoir
>> leurs places, ce qui parait aberrant.  Est-ce un problème qui a
>> déjà été relevé ? Je n’ai pas trouvé le github de ce projet.
>>
>> Mathias
>>
>>   [6]
>>  Garanti sans virus. www.avast.com [6]
>>
>>
>>
>> Links:
>> --
>> [1] https://wiki.openstreetmap.org/wiki/Tag:network%3Dicn
>> [2]
>> https://www.openstreetmap.org/relation/5448020#map=15/50.2451/4.0115layers=C
>>
>> [3]
>> https://www.openstreetmap.org/relation/5445857#map=9/49.4360/-1.0547layers=C
>>
>> [4] https://wiki.openstreetmap.org/wiki/Tag:network%3Dncn
>> [5] http://www.opencyclemap.org/docs/
>> [6]
>> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> -- 
> Phyks
> 
> ___
> 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] Opencyclemap : absence des relations network= icn

[Phyks]

Bonjour,

Je ne saurais répondre particulièrement sur la question des network = 
icn, mais OpenCycleMap n'est pas libre (contrairement à ce que son nom 
pourrait laisser penser). Ce n'est donc pas possible de contribuer. En 
revanche, il y a un suivi de tickets ici 
https://trac.openstreetmap.org/query?component=opencyclemap. L'autre 
solution est de contacter directement l'auteur par 
http://thunderforest.com/contact/.


En rapport, il était question hier sur le canal IRC osm-fr d'essayer 
d'avoir un vrai rendu cyclable collaboratif et libre. OpenCycleMap a un 
certain nombre de problèmes/limitations, dont certains qui ne seront 
peut être jamais corrigés (comme ça, je vois notamment la question des 
parkings partagés motos / vélos qui sont ignorés ou l'absence de rendu 
de zone pour les zones commerciales, qui offrent souvent des points 
d'eau / toilettes même s'ils ne sont pas explicitement renseignés dans 
OSM). Plusieurs personnes étaient intéressées, je profite de ce message 
pour relayer l'info, si d'autres personnes pourraient également être 
intéressées / vouloir participer.


Bonne journée,
--
Phyks

Le 2018-12-13 16:21, Mathias Vadot a écrit :

Bonjour à tous,

Après plusieurs test, je me rends compte que le fond de carte OCM
n’affiche pas les itinéraires internationaux, relations taguées de
cette manière : network = icn. [1] Je m’en suis rendu compte pour
les relations que je connais en France [2], mais c’est finalement un
problème globale. Les relations bien visibles en rouge [3] sont
tagué comme étant des relations nationale, network = ncn [4].

Dans la légende [5], les icn n’ont en effet pas l’air d’avoir
leurs places, ce qui parait aberrant.  Est-ce un problème qui a
déjà été relevé ? Je n’ai pas trouvé le github de ce projet.

Mathias

 [6]
Garanti sans virus. www.avast.com [6]



Links:
--
[1] https://wiki.openstreetmap.org/wiki/Tag:network%3Dicn
[2]
https://www.openstreetmap.org/relation/5448020#map=15/50.2451/4.0115layers=C
[3]
https://www.openstreetmap.org/relation/5445857#map=9/49.4360/-1.0547layers=C
[4] https://wiki.openstreetmap.org/wiki/Tag:network%3Dncn
[5] http://www.opencyclemap.org/docs/
[6]
https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


--
Phyks

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

[OSM-talk-fr] Compléter les boundary=postal_code manquants

[Phyks]

Bonjour,

Je me demandais récemment s'il était possible d'extraire une "étendue 
géographique" associée à des codes postaux à partir des données OSM. Un 
code postal peut être partagé par plusieurs villes / villages et une 
ville peut avoir plusieurs codes postaux (souvent couvrant des zones 
géographiquement séparées), la question est ici donc "étant donné 
bâtiment avec un code postal donné, quelle idée est-ce que je peux avoir 
de l'endroit où il est en France".


Les codes postaux sont mentionnés sur les boundary=administrative, ce 
qui permettrait a priori de faire cette analyse. La plupart des villes 
n'ont qu'un seul code postal renseigné et c'est alors facile. Certaines 
villes ont plusieurs codes postaux renseignés (Paris par exemple, avec 
un code postal par arrondissement). Dans ce cas, j'ai isolé trois cas 
différents :
* Soit la ville a des arrondissements ou subdivisions (Paris par 
exemple) avec un code postal unique sur ces sous-divisions (un code 
postal par arrondissement) et c'est facile.
* Soit la ville a plusieurs codes postaux et il existe un 
boundary=postal_code 
(https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dpostal_code) pour 
chacun de ces codes postaux, et c'est facile également.
* Soit la ville a plusieurs codes postaux et il n'y a aucune autre 
information disponible (Meudon par exemple) et dans ce cas on ne peut 
pas faire grand chose. Pourtant les codes postaux sont souvent dans des 
zones différentes de la commune (par exemple 63000 et 63100 correspond à 
des quartiers différents dans Clermont-Ferrand).


Ce dernier cas concerne environ 100 codes postaux trouvés dans les 
données françaises. Mon analyse et les résultats sont disponibles sur 
https://gist.github.com/Phyks/049fde37702e993159b64b40fe9c1cce.



L'idéal serait, j'imagine, de rajouter des boundary=postal_code pour 
cette centaine de cas. Quelle serait la meilleure façon de procéder ? Je 
pense que les données pourraient être extraites des adresses de la BAN 
par exemple, mais la licence serait-elle compatible ?


Merci !

P.S. : Je trouve 6066 codes postaux différents sur les communes dans 
OSM. En prenant la base officielle des codes postaux 
(https://datanova.legroupe.laposte.fr/explore/dataset/laposte_hexasmal/information/?disjunctive.code_commune_insee_de_la_commune_postal_d_acheminement_5), 
il y aurait 6329 codes postaux différents en France. Même question du 
coup pour savoir si ce fichier (ou un autre) pourrait être utilisé comme 
source pour compléter les 300 codes postaux manquants ?

--
Phyks

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

Re: [OSM-talk-fr] Projet du mois de novembre: gendarmerie/police

[Phyks]

Salut,

> (je n'ai pas trouvé de source officielle pour un nombre de commissariats
> de police municipale, n'hésitez pas si vous avez ça sous la main)

Je ne sais pas trop ce que ça vaut, mais je viens de voir passer
https://www.data.gouv.fr/fr/datasets/police-municipale-effectifs-par-commune/.

Le fichier est pas forcément de qualité top, et ça concerne les
effectifs plutôt que les commissariats, mais en comptant les communes
avec un nombre de policiers municipaux > 0, ça peut peut être déjà
donner une borne inférieure.

-- 
Phyks

> 
> Le 04/11/2018 à 22:26, Vincent de Château-Thierry a écrit :
>> Bonsoir,
>>
>>> De: "Noémie Lehuby" 
>>>
>>> Le 04/11/2018 à 11:26, lenny.libre a écrit :
>>>> +1 avec Vincent, du fait de la présence des polices municipales
>>>> même s'il n'est pas très utilisé, mais il faudrait définir si on
>>>> utilise
>>>> la valeur "police_municipale" ou "police municipale"
>>> C'est un peu dommage de devoir créer un nouveau tag juste pour
>>> regrouper les polices municipales (vu qu'operator fait bien l'affaire
>>> pour les
>>> deux autres) mais pourquoi pas, ça fait sens.
>>> Je vais laisse modifier la page FR:amenity=police et on voit comment
>>> on peut l'inclure dans notre #projetOSMDuMois en cours ?
>> J'ai modifié la page FR:amenity=police, en optant pour les valeurs
>> "police", "gendarmerie" et "police_municipale". On pourra changer
>> cette dernière ensuite s'il y a débat, mais au moins on construit une
>> typologie des organismes avec un tag ad'hoc.
>>
>> vincent
>>
>> ___
>> 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] Calcul d'itinéraire prenant en compte les travaux

[Phyks]

Salut,

Sur BRouter, j'ai fait https://github.com/abrensch/brouter/pull/117 qui 
est probablement loin d'être parfait mais permet d'attribuer des poids 
aux zones d'exclusion (nogo) plutôt que de les ignorer complètement.


Avec ça d'un côté et les données ouvertes de travaux en cours de 
l'autre, BRouter devrait donc pouvoir faire facilement du routage en 
pénalisant les zones de travaux.


Il y a quelques données ouvertes de trafic qui sont disponibles 
également (à Bordeaux par exemple 
https://www.data.gouv.fr/fr/datasets/etat-du-trafic-en-temps-reel-sur-bordeaux-metropole/) 
qui pourraient être intégrés.


Bonne journée,
--
Phyks


Le 2018-10-26 14:01, Nicolas Bétheuil a écrit :

J'ai été poser la question

https://ask.openrouteservice.org/t/roadworks-and-how-to-handle-it/45
https://groups.google.com/forum/#!topic/osm-android-bikerouting/bsRYArj8fCM
https://groups.google.com/forum/#!topic/opentripplanner-users/ryjK46IoOY8

pour commencer

Le ven. 26 oct. 2018 à 08:28, Phyks  a écrit :


Merci ! J'avais pensé à verser les signalements de cyclassist dans
OED
(et utiliser OED plutôt qu'une base différente pour cyclassist),
mais je
n'étais pas sûr que ça ait parfaitement sa place dans OED.
J'avais eu un
peu de mal à trouver de la doc / des points de contact aussi :/

Mais c'est quelque chose qui pourrait changer facilement, il y a de
quoi
faire un dump des signalements de Cycl'Assist facilement.

Concernant les travaux, pour l'instant je récupère des points
libres
mais je voudrais reprendre ça pour les associer à des objets OSM.
La
plupart des sources fournissent une aire touchée par les travaux et
il
suffit alors de chercher les intersections avec les objets OSM.
C'est
sur ma liste de trucs à faire.

Concernant les modes de transport affectés (ou les fermetures
partielles
/ totales etc), c'est très souvent donné dans un champ texte
libre, avec
toutes les variations possibles du coup… rien de normalisé et de
facile
à réutiliser j'ai l'impression :/

Pour réutiliser ça dans un calculateur d'itinéraires, je sais que
certains proposent d'éviter des zones (OpenRouteService proposé
par JB,
brouter aussi). Du coup, pas besoin d'associer ça précisément à
un objet
OSM. Le seul problème que je vois avec les zones à éviter c'est
que ces
zones de travaux ne sont pas forcément "à éviter" mais plutôt
"à
pénaliser", du moins tant que l'information précise des éléments
(trottoirs, chaussée, fermeture partielle ou totale) n'est pas bien
connu. Des travaux sur un trottoir impliquent probablement des
complications pour les automobilistes, mais il n'y a aucune raison a
priori d'éviter totalement la zone.

--
Phyks

Le 25/10/2018 à 10:45, Nicolas Bétheuil a écrit :

Classe ! Félicitations !
J'adore la richesse d'OSM ! Ou de verser cyclassist dans OED ?

L'api d'OED

est publique.
Dire si ça concerne que les vélos où aussi les voitures, les

piétons,

mobilité réduite ?
Après pour que ce soit exploitable dans OSM par un calculateur
d'itinéraire, il faut rattacher ça à des objets OSM pour les

tagguer ?


Le jeu. 25 oct. 2018 à 09:33, Phyks  a écrit :


Salut,


Vu que chaque ville à sa propre base / api ça me paraît

compliqué que les

calculateurs d'itinéraire le prenne en compte nottament avec

les

arguments

déjà évoqués. Vu aussi que l'idée est de ne pas faire

d'import dans OSM

mais que des contributeurs revalident ces données, modifier OSM

me parait

aussi compliqué en automatique : ce n'est pas qu'ajouter un

POI, faire

une

conflation ... les différents chantiers ont différents impact

donc à

tagguer différemment.


J'ai




https://framagit.org/phyks/cyclassist/blob/master/scripts/opendata/works.py

en stock avec toutes les opendata sur les travaux que j'ai

trouvées en

France pour l'instant (et qui les uniformise un minimum).

Ça devrait être possible de reprendre un script du genre et de
l'injecter dans OED, non ?

--
Phyks



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




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



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

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


--
Phyks

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

[OSM-talk-fr] Calcul d'itinéraire prenant en compte les travaux

[Phyks]

Merci ! J'avais pensé à verser les signalements de cyclassist dans OED
(et utiliser OED plutôt qu'une base différente pour cyclassist), mais je
n'étais pas sûr que ça ait parfaitement sa place dans OED. J'avais eu un
peu de mal à trouver de la doc / des points de contact aussi :/

Mais c'est quelque chose qui pourrait changer facilement, il y a de quoi
faire un dump des signalements de Cycl'Assist facilement.


Concernant les travaux, pour l'instant je récupère des points libres
mais je voudrais reprendre ça pour les associer à des objets OSM. La
plupart des sources fournissent une aire touchée par les travaux et il
suffit alors de chercher les intersections avec les objets OSM. C'est
sur ma liste de trucs à faire.


Concernant les modes de transport affectés (ou les fermetures partielles
/ totales etc), c'est très souvent donné dans un champ texte libre, avec
toutes les variations possibles du coup… rien de normalisé et de facile
à réutiliser j'ai l'impression :/


Pour réutiliser ça dans un calculateur d'itinéraires, je sais que
certains proposent d'éviter des zones (OpenRouteService proposé par JB,
brouter aussi). Du coup, pas besoin d'associer ça précisément à un objet
OSM. Le seul problème que je vois avec les zones à éviter c'est que ces
zones de travaux ne sont pas forcément "à éviter" mais plutôt "à
pénaliser", du moins tant que l'information précise des éléments
(trottoirs, chaussée, fermeture partielle ou totale) n'est pas bien
connu. Des travaux sur un trottoir impliquent probablement des
complications pour les automobilistes, mais il n'y a aucune raison a
priori d'éviter totalement la zone.

-- 
Phyks

Le 25/10/2018 à 10:45, Nicolas Bétheuil a écrit :
> Classe ! Félicitations !
> J'adore la richesse d'OSM ! Ou de verser cyclassist dans OED ? L'api d'OED
> est publique.
> Dire si ça concerne que les vélos où aussi les voitures, les piétons,
> mobilité réduite ?
> Après pour que ce soit exploitable dans OSM par un calculateur
> d'itinéraire, il faut rattacher ça à des objets OSM pour les tagguer ?
> 
> Le jeu. 25 oct. 2018 à 09:33, Phyks  a écrit :
> 
>> Salut,
>>
>>> Vu que chaque ville à sa propre base / api ça me paraît compliqué que les
>>> calculateurs d'itinéraire le prenne en compte nottament avec les
>> arguments
>>> déjà évoqués. Vu aussi que l'idée est de ne pas faire d'import dans OSM
>>> mais que des contributeurs revalident ces données, modifier OSM me parait
>>> aussi compliqué en automatique : ce n'est pas qu'ajouter un POI, faire
>> une
>>> conflation ... les différents chantiers ont différents impact donc à
>>> tagguer différemment.
>>
>> J'ai
>> https://framagit.org/phyks/cyclassist/blob/master/scripts/opendata/works.py
>> en stock avec toutes les opendata sur les travaux que j'ai trouvées en
>> France pour l'instant (et qui les uniformise un minimum).
>>
>> Ça devrait être possible de reprendre un script du genre et de
>> l'injecter dans OED, non ?
>>
>> --
>> Phyks
>>
>>
>>
>> ___
>> 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

[OSM-talk-fr] Calcul d'itinéraire prenant en compte les travaux

[Phyks]

Salut,

> Vu que chaque ville à sa propre base / api ça me paraît compliqué que les
> calculateurs d'itinéraire le prenne en compte nottament avec les arguments
> déjà évoqués. Vu aussi que l'idée est de ne pas faire d'import dans OSM
> mais que des contributeurs revalident ces données, modifier OSM me parait
> aussi compliqué en automatique : ce n'est pas qu'ajouter un POI, faire une
> conflation ... les différents chantiers ont différents impact donc à
> tagguer différemment.

J'ai
https://framagit.org/phyks/cyclassist/blob/master/scripts/opendata/works.py
en stock avec toutes les opendata sur les travaux que j'ai trouvées en
France pour l'instant (et qui les uniformise un minimum).

Ça devrait être possible de reprendre un script du genre et de
l'injecter dans OED, non ?

-- 
Phyks



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

Re: [OSM-talk-fr] Parking/aire de covoiturage : comment les tagguer ?

[Phyks]

Bonjour,

Je profite de cette discussion pour demander ce qu'il en est pour des 
points de rencontre covoiturage, sans vrai parking dédié (ou quelques 
places, le temps de se retrouver tout au plus) mais avec une 
signalisation et un statut officiel (pas juste un point de rencontre 
usuel et officieux). Ce n'est pas vraiment un parking, et ce n'est pas 
du tout du park_ride (on ne peut pas venir ici et laisser sa voiture).


Du coup, pour ces endroits, on met du amenity=car_pooling ou il y a 
mieux ?


Merci,
--
Phyks

Le 2018-10-23 14:48, PanierAvide a écrit :

Bonjour,

Déterrage de vieux courriels :
https://lists.openstreetmap.org/pipermail/talk-fr/2015-November/078620.html

Me basant sur ces discussions, je suis récemment parti sur ça en
Ille-et-Vilaine :
- amenity=parking
- park_ride=hov
- hov=designated

Le amenity=car_pooling est sémantiquement adapté mais avec un usage
encore peu répandu. Et du coup pas encore visible sur les styles
principaux (même si on ne tague pas pour le rendu !).

Cordialement,

Adrien.

Le 23/10/2018 à 14:28, marc marc a écrit :

Le 23. 10. 18 à 14:09, Francescu GAROBY a écrit :

parking/aire de covoiturage (un parking où des covoitureurs
se donnent RDV, pour ensuite entre en ville dans la même voiture,
les autres laissant la leur toute la journée sur le parking/l'aire de
les covoiturages).

https://wiki.openstreetmap.org/wiki/Tag:amenity=car_pooling

à l'intérieur d'un amenity=parking dans ou à la place d'un parking
normal selon que ce sont quelques places réservée ou tout le parking
___
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] Arceaux partagés motos / vélos

[Phyks]

Hmm, je vais passer vérifier celui au 64 avenue Henri Ginoux ce soir.

On parle de quelle rue devant le tabac ? La rue Sadi Carnot ?

De mémoire de quand je suis passé là-bas, ce stationnement 
https://www.google.com/maps/@48.8171366,2.3215206,3a,75y,358.39h,80.11t/data=!3m7!1e1!3m5!1s7Np31aULrZ24vWjIrUM13Q!2e0!6s%2F%2Fgeo2.ggpht.com%2Fcbk%3Fpanoid%3D7Np31aULrZ24vWjIrUM13Q%26output%3Dthumbnail%26cb_client%3Dmaps_sv.tactile.gps%26thumb%3D2%26w%3D203%26h%3D100%26yaw%3D80.504166%26pitch%3D0%26thumbfov%3D100!7i16384!8i8192?hl=fr 
est un stationnement deux roues, mutualisé et pas interdit aux vélos.


Je veux bien plus d'informations sur ce dernier du coup.

Le 2018-09-27 20:29, Philippe Verdy a écrit :

Et même chose un peu plus loin (sur la photo on voit la carotte rouge
d'un tabac de l'autre côté du carrefour: la rue devant ce tabac a
là aussi un parking 2 roues interdit aux vélos.

La rue où a été prise cette photo a bien une voie cyclable, en
théorie, mais cette voie est occupée en permanence par le
stationnement de voitures et de camionnettes de livraison (rarement
verbalisés car ces rues ne sont pas surveillées, même devant les
écoles), bref une piste cyclable inutilisable.

Il ne fait pas bon être cycliste à Montrouge.

Le jeu. 27 sept. 2018 à 19:52, Philippe Verdy  a
écrit :


Il faut espérer que les vélos ont aussi leurs emplacements (sans
doute sur le terre-plain dont on voit juste l'extrémité sur la
photo, protégé par les plots métalliques), pour que ceux-ci ne se
garent pas sur les trottoirs étroits attachés aux réverbères ou
gouttières).

Dans ce cas cette petite bande pour motos/cylomoteurs/scooters est
bienvenue et évite qu'eux aussi occupent les emplacements pour
vélos (d'autant que c'est surbaissé au niveau de la chaussée, et
trop étroit pour un parking voitures/camions sans prendre trop de
place sur les trottoirs ou la chaussée.

Dans la plupart des rues cependant, soit on a interdiction de
stationnement des voitures, comions et motos, soit les emplacements
pour voitures/fourgonnettes/camions sont utilisables aussi par les
motos qui prennent une place entière (elles se garent rarement en
épi de peut qu'un autre véhicule se garant croit avoir la place et
les renversent : c'est difficile de relever seul une moto et souvent
cela fait de la casse lors de la chute ou des tentatives de relevage
sans appui).

Le jeu. 27 sept. 2018 à 19:07, Phyks  a écrit :

Tu saurais où a été prise cette photo ? Je j'ai jamais vu ça.

Comme on fait une passe sur les stationnements deux roues, je
noterai pour celui-ci.

Merci,

Le 25 septembre 2018 17:05:48 GMT+02:00, Shohreh
 a écrit :

cquest wrote
Question peut être bête et en rapport indirect avec le sujet...
qu'est-ce
qui empêche (légalement et pratiquement) de garer un vélo dans
un
emplacement moto ?

Rare, mais ça existe : ici à Montrouge (en proche banlieue
parisienne, pour
les étrangers).

https://postimg.cc/DSttFRmc

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

 ___
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


--
Phyks

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

Re: [OSM-talk-fr] Arceaux partagés motos / vélos

[Phyks]

Tu saurais où a été prise cette photo ? Je j'ai jamais vu ça.

Comme on fait une passe sur les stationnements deux roues, je noterai pour 
celui-ci.

Merci,

Le 25 septembre 2018 17:05:48 GMT+02:00, Shohreh  a écrit 
:
>cquest wrote
>> Question peut être bête et en rapport indirect avec le sujet...
>qu'est-ce
>> qui empêche (légalement et pratiquement) de garer un vélo dans un
>> emplacement moto ?
>
>Rare, mais ça existe : ici à Montrouge (en proche banlieue parisienne,
>pour
>les étrangers).
>
>https://postimg.cc/DSttFRmc
>
>
>
>
>--
>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
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Arceaux partagés motos / vélos

[Phyks]

Pour info, j'ai eu un retour d'OpenCycleMap qui va prochainement prendre 
en compte les "motorcycle_parkings" avec "bicycle=yes". Les tags actuels 
peuvent ne pas être parfaits, mais ils ont le mérite d'être déjà 
utilisés par les applis et le but ici est d'essayer de les utiliser 
autant que possible.


La dernière proposition, à jour sur 
https://wiki.openstreetmap.org/wiki/Montrouge#Stationnements_.22R.C3.A9serv.C3.A9_aux_deux_roues.22, 
s'oriente donc vers


amenity=motorcycle_parking
bicycle=yes
access=yes
bicycle_parking=?
capacity=?

L'intérêt étant que dans le pire des cas les cyclistes y verront un 
parking motos, dans le meilleur des cas ce sera bien traité comme un 
parking pour deux roues.


Je suis en train de faire une passe sur les parkings deux roues de 
Montrouge pour noter si ce sont des parkings vélos ou deux roues. Je 
ferais la transformation après.

--
Phyks

Le 2018-09-25 12:03, marc marc a écrit :
je partage l'avis de Jean-Yvon : une station de véhicule en partage 
(=un

operateur y a mis des véhicules destinés à être emprunté), ce n'est
vraiment pas du tout la même chose qu'un parking (on y met son propre
véhicule qu'on viendra récupéré dans quelques minutes/heures/jours)

c'est difficile d'invoquer un vice "tag pour le rendu"
à propos d'un tag qui n'est pas rendu :-)

Le 25. 09. 18 à 10:55, Florimond Berthoux a écrit :
Un parking de scooter (et de vélo et de trottinette) partagé n'a rien 
à

voir avec un parking ?
Je suis perplexe.

(Oserais-je dire que « amenity=scooter_sharing » c'est du tag to 
render ?)


Le lun. 24 sept. 2018 à 20:41,  a 
écrit :


Si je comprends bien, c'est du scooter partagé, rien à voir avec 
un

parking.

Les emplacements des voitures en partage sont repérés avec la clé
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcar_sharing.

__amenity

<https://wiki.openstreetmap.org/wiki/Key:amenity>__=__bicycle_rental__

<https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dbicycle_rental>
pour les vélos en libre service.

Donc amenity=scooter_sharing ?

Jean-Yvon


Le 24/09/2018 à 14:18, Florimond Berthoux -
florimond.berth...@gmail.com <mailto:florimond.berth...@gmail.com> 
a

écrit :
Je ne retrouve plus l'information, mais la SNCF à ouvert à gare 
de

Lyon (Paris) un stationnement pour le freefloating (scooter
électrique Cityscoot, trottinette électrique Lime, ...)

Alors si on suit la logique amenity=bicycle_parking il faudrait 
un

amenity=freefloating_scooter ? Étrange.
Cela se résout plus facilement avec le droit accès.
D'un point de vue utilisation de la BdD c'est plus simple aussi,
pas besoin de se faire une collection de tag pour trouver tous 
les

parkings de tous les types.


Le lun. 24 sept. 2018 à 13:01, djakk djakk mailto:djakk.dj...@gmail.com>> a écrit :

Merci Florimond tu as mis les mots sur un ressenti flou que
j’avais.

Je trouve que highway=cycleway est un raccourci bien pratique
mais il ne s’agirait que d’un alias vers un objet plus+
complexe ayant des valeurs par défaut.


djakk


Le lun. 24 sept. 2018 à 11:22, Florimond Berthoux
mailto:florimond.berth...@gmail.com>> a écrit :

Bonjour,

plus un pour :

Le jeu. 20 sept. 2018 à 17:54, djakk djakk
mailto:djakk.dj...@gmail.com>> a
écrit :


Ou revoir la méthode :
amenity=parking
bicycle=yes
motorcar=no
hgv=no
motorcycle=yes


Définir le droit d'accès et le type d'aménagement dans le
même tag est une erreur conceptuelle.
C'est d'abord un parking, autorisé aux deux roues (vélo +
moto), avec dessus une infra de type arceaux.

(Il y a le même problème avec le highway=cycleway, qui
définit à la fois une route et un droit d'accès.)

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


--
Phyks

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

Re: [OSM-talk-fr] Arceaux partagés motos / vélos

[Phyks]

Bonne question. Les stationnements "motos" sont en général des 
stationnements "deux roues" donc je pense qu'ils sont ouverts de la même 
façon aux vélos (en France du moins). De même qu'en principe on peut 
garer n'importe quel véhicule sur une place de stationnement pourvu 
qu'on paye le parcmètre, il me semble. Par contre, les emplacements 
réservés aux vélos ne sont accessibles qu'à eux.


Dans le cas présent, le but est que les infos soient utilisables par 
tous (vu que les applis "cyclistes" ont tendance à ignorer les parkings 
motos visiblement) et de faciliter le suivi. Si dans quelques temps la 
mairie décide de passer les stationnements deux roues (mais pas vélo) 
payants (comme ça a été fait à Vincennes par exemple), il faut 
différencier les espaces ouverts à tous les deux roues de ceux ouverts 
uniquement aux vélos pour faciliter l'édition.


Le 2018-09-21 09:20, Christian Quest a écrit :

Question peut être bête et en rapport indirect avec le sujet...
qu'est-ce qui empêche (légalement et pratiquement) de garer un vélo
dans un emplacement moto ?

--

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


--
Phyks

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

Re: [OSM-talk-fr] Arceaux partagés motos / vélos

[Phyks]

-- 
Phyks
J'aimerais autant que possible utiliser des tags existants, pour
m'assurer que les applis déjà existantes puissent utiliser ces données,
et ne pas demander trop d'efforts aux rendus (pour un cas finalement
assez particulier). Vivant dans une zone assez dense, l'objectif est
aussi que les tags soient corrects et clairs sur leurs intentions et
qu'un contributeur ne passe pas tout annuler trop rapidement.

>  >> Est-ce l’occasion d’utiliser le point-virgule pour faire une liste ?
>  >> amenity=motorcycle_parking;bicycle_parking
>  > les valeurs existent déjà.
>
> il y a probablement aucun outil au monde qui l'utilise.
> On dirait un concours pour proposer le moins conventionnel possible :-(

Sans compter que les problèmes de rendus (déjà) sont exactement les
mêmes, voir

https://www.openstreetmap.org/node/5169255354#map=19/43.59062/7.11799

>> stationnements "deux roues"
>>      amenity=motorcycle_parking
> 
> on en avait discuté de mémoire l'an passé
> c'est ce qui en était resorti considérant que qui peux le plus
> peux le moins.
> quitte à proposer un nouvel icone mixte moto+velo si

Ça me semble raisonnable comme argument en effet. J'ai vérifié et OsmAnd
le rend correctement comme un parking vélo. J'ai ouvert un ticket chez
OSM Carto pour mentionner le problème que ce n'est pas rendu
actuellement et avoir des retours
(https://github.com/gravitystorm/openstreetmap-carto/issues/3407). J'ai
demandé à Thunderforst par courriel pour OpenCycleMap aussi.

+1 pour une éventuelle icone mixte.

>>      bicycle_parking=stands
> 
> si l'arceau est utilisable tant pour les motos que pour les vélos (je 
> n'en ai jamais vu utilisable par les 2), soit il faudrait renseigner
> les 2, soit le plus cohérent me semble être motorcycle_parking=stands
> vu que c'est le raffinement de amenity=motorcycle_parking

C'est le cas vers chez moi, mais ils aiment bien les inventions en
matière cycliste je crois… Ce n'est pas forcément très répandu.
`motorcycle_parking=stands` est-il déjà "standard" (je n'en vois pas de
trace dans le wiki). Mettre à la fois `motorcycle_parking` et
`bicycle_parking` pourrait être une solution.

> ___
> 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] Arceaux partagés motos / vélos

[Phyks]

Salut,

Dans ma ville, la plupart des stationnements "vélos" sont en fait des 
stationnements "deux roues" avec des arceaux qui sont utilisables à la 
fois par les motos, les scooters et les vélos (sans distinction). 
Comment devrait-on tagger cela au mieux ?


Il me semble qu'une proposition raisonnable serait un truc comme

access=yes
amenity=motorcycle_parking
bicycle=yes
bicycle_parking=stands
capacity=?
covered=no
fee=no

mais cela est-il réellement optimal ?

Le rendu par défaut des tuiles par défaut et OpenCycleMap ne va pas 
l'afficher (voir 
https://www.openstreetmap.org/node/5028869329#map=19/48.81712/2.31139 
par exemple qui n'est affiché nulle part).


Bref, je suis preneur de retours sur cette situation (par défaut, j'ai 
l'impression que la plupart des gens les ont mis en parking vélos dans 
le coin).


Merci,
--
Phyks

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

Re: [OSM-talk-fr] Parc de stationnement en Zone de rencontre

[Phyks]

Salut,


> En soit rien de franchement étonnant dans beaucoup de voie de service
et de
> parking de supermarché les voies sont déjà limité à 20 voir à 10km. Pour
> info les voies de services n'ont pas de vitesse par défaut (ce sont les
> logiciel de routing qui les déduises en fonction des voies de connexions).
> En France les voies privés ouvertes à la circulation ne sont pas limité de
> manière implicite c'est le même code donc les même conditon de
circulation.
> Elles reprennent la vitesse de la zone dans laquelle tu es. En clair si
> t'es en ville sans panneaux c'est 50km/h... Pareil pour les parking de
> centre commerciaux.

Mes deux centimes là-dessus, quand je passais le permis on m'avait
explicitement dit qu'il fallait passer la première et y rester sur un
parking de centre commercial, sinon c'était éliminatoire.

J'ai aucune idée de si c'est retranscrit tel quel dans le code de la
route ou si c'est une pratique exigée en plus des obligations légales,
mais ça me semble difficile de rouler à plus que 10km/h en première :)
-- 
Phyks

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

Re: [OSM-talk-fr] Différencier aménagement cyclables sur trottoir des autres

[Phyks]

Bonjour,

Le 27/07/2018 à 19:22, marc marc a écrit :

Le 27. 07. 18 à 18:47, Charles MILLET a écrit :

  * cycleway:*=sidewalk + segregated=yes/no
Je préfère cycleway=sidewalk


cela me semble cohérent avec l'existant.
cycleway=sidewalk pour le cas général
et avec des préfixe si la situation n'est pas la même pour les 2
trottoirs : cycleway=sidewalk serrait un alias de 
cycleway:both=sidewalk


Je ne suis pas sûr que ceci permette de tagger une piste
bidirectionnelle sur trottoir, mais j'ai peut être raté un truc. Par 
exemple celle-ci

https://www.google.fr/maps/@48.8155768,2.3064629,3a,75y,215.99h,72.26t/data=!3m6!1e1!3m4!1s10YP8tp9kNTPUlpgbwimrQ!2e0!7i13312!8i6656
ou
https://www.google.fr/maps/@48.8876042,2.3793176,3a,75y,236.5h,67t/data=!3m6!1e1!3m4!1sruTXObVZq4NYgkgL5tWTYg!2e0!7i13312!8i6656,
bidirectionnelle à droite et trottoir de chaque côté. C'est un type
d'aménagement que je rencontre fréquemment.

De ce que j'ai repéré pour l'instant, il y a plusieurs cas de pistes
cyclables sur trottoirs, avec une qualité et une praticité inégale :

* Des pistes en bordure de trottoir, séparées par du marquage ou des
clous, comme
https://www.google.fr/maps/@48.8235666,2.3236568,3a,75y,143.58h,76.56t/data=!3m7!1e1!3m5!1sKhyac6Qw9VQo567DCJHumA!2e0!6s%2F%2Fgeo2.ggpht.com%2Fcbk%3Fpanoid%3DKhyac6Qw9VQo567DCJHumA%26output%3Dthumbnail%26cb_client%3Dmaps_sv.tactile.gps%26thumb%3D2%26w%3D203%26h%3D100%26yaw%3D358.2077%26pitch%3D0%26thumbfov%3D100!7i13312!8i6656

* Des pistes qui traversent réellement des trottoirs, comme
https://www.google.fr/maps/@48.8275762,2.3265773,3a,75y,229.77h,75.56t/data=!3m6!1e1!3m4!1sspbZdG3q161crzyRBBoO1w!2e0!7i13312!8i6656.

* Des bidirectionnelles sur trottoir, comme celle ci-dessus.

* Déjà vu une fois ou deux, un des trottoirs est neutralisé et réservé
aux pistes cyclables et l'autre trottoir est conservé pour les piétons.

* Des aménagements vraiment partagés entre piétons et cyclistes, comme
https://www.google.fr/maps/@48.8917069,2.38638,3a,75y,33.44h,93.08t/data=!3m8!1e1!3m6!1sAF1QipM8WPH6KCj8cLqzXE7W5hoHrnGFgySaWUH2pXfU!2e10!3e11!6shttps:%2F%2Flh5.googleusercontent.com%2Fp%2FAF1QipM8WPH6KCj8cLqzXE7W5hoHrnGFgySaWUH2pXfU%3Dw203-h100-k-no-pi0-ya321.44794-ro-0-fo100!7i7168!8i2902.

D'un point de vue cycliste, ces aménagements sont très différents en 
termes de confort d'utilisation (et de conflits avec les piétons), donc 
j'aurais tendance à penser qu'ils devraient idéalement pouvoir se 
distinguer assez facilement par les tags utilisés :)




Sinon moi j'ai une autre proposition :)
Un bon vieux highway=footway + footway=sidewalk + cycleway=track + en

général oneway=yes

Ça ne devrait pas être plutôt cycleway=lane vu que c'est une bande
peinte sur le trottoir ?

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

Re: [OSM-talk-fr] Cartographier une piste cyclable sur trottoir

[Phyks]

Salut,

Le 2018-07-14 14:18, Axelos a écrit :

Coucou,

Officiellement c'est le cas S4 de la page bicycle qui est en vigueur
(bien qu'à titre perso, je rappelle que l'usage de la balise
highway=cycleway me parait totalement incohérente en France, cf le
tableau des accès)

En fait pour répondre à ta question, je crois que pour le moment il n'y
a pas de bonne représentation existante.


Ok, merci pour toutes les infos ! J'ai repris la route avec le cas S4 du 
coup, qui correspond à ce que j'avais en tête.


--
Phyks

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

[OSM-talk-fr] Cartographier une piste cyclable sur trottoir

[Phyks]

Bonjour à tous,

Je regardais comment cartographier une piste cyclable sur trottoir, et
en lisant le wiki, la bonne façon de faire ne me semble pas évidente. En
l'occurrence il s'agit de [cette piste
cyclable](https://www.openstreetmap.org/way/272012085#map=17/48.81401/2.30518=N)
qui est une bidirectionnelle (obligatoire de surcroît, ce qui est plutôt
rare) sur trottoir (séparée du trafic automobile, mais séparée des
piétons uniquement par du marquage).

En regardant les autres ayant une configuration similaire dans le coin :

* https://www.openstreetmap.org/way/54149191 n'a aucune indication
qu'elle est sur trottoir
* https://www.openstreetmap.org/way/448833811 a l'indication en "note",
pas très réutilisable
* https://www.openstreetmap.org/way/254712531 a exactement la même
configuration que celle que je traitais (bidirectionnelle sur trottoir,
uniquement du marquage au sol pour séparer) et aucune indication
particulière dans OSM.

Quelle est la bonne façon de signaler une piste cyclable sur trottoir ?
En particulier, cela me semble être une information importante pour le
routage, qui pourra préférer orienter un cycliste vers la route ou la
piste cyclable sur trottoir, en fonction de sa vitesse de croisière.

En particulier, ces aménagements sont nettement en-dessous de ce qu'on
peut trouver [ici](https://www.openstreetmap.org/way/161286326) par
exemple, avec une vraie piste, au niveau de la chaussée, séparée du
trafic routier par une bordure et des piétons par le trottoir.

Je pensais tagger ces pistes cyclables sur trottoir comme des
highway=path, foot=designated, bike=designated, segregated=yes par
exemple, mais je ne sais pas si ça serait bien cohérent.

Qu'en dites-vous ?

Merci !
-- 
Phyks

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

Re: [OSM-talk-fr] Export bitmap avec marqueurs "umap"

[Phyks]

Bonjour,

Dans Firefox, il y a moyen de faire pareil (avec un rendu en direct, 
utile pour déboguer) en ouvrant la vue adaptative (menu -> développement 
web -> vue adaptative) et en spécifiant une grande résolution. Il y a un 
bouton en haut pour faire une capture d'écran de la page dans son 
intégralité.


J'ai un problème similaire, j'aurais voulu sortir des cartes 
d'itinéraires cyclistes (genre partir de 
http://umap.openstreetmap.fr/fr/map/a-velo-avec-openstreetmap_202362#8/46.136/-0.610 
et avoir un feuillet de feuilles A4 avec les plans détaillés). Je viens 
de découvrir https://maposmatic.osm-baustelle.de/ par ce fil, qui a 
l'air vraiment top (et fait tous ces exports). Par contre, il ne 
supporte pas vraiment de grandes zones…


Quelqu'un saurait où est le code qui tourne derrière et s'il serait 
possible d'exporter des cartes plus grandes sur une instance perso ?


Merci !
--
Phyks


Le 2018-06-13 11:36, Nicolas Bétheuil a écrit :

Avec chrome, ll y a un mode headless
google-chrome --headless --screenshot --window-size=5000,5000
http://openstreetmap.org
un fichier screenshot.png est créé avec une image de 5000x5000

https://developers.google.com/web/updates/2017/04/headless-chrome

doit être possible de faire kifkif avec firefox mais j'ai pas cherché

j'aurais bien envoyé l'exemple mais il fait 27Mo ...
Le mer. 13 juin 2018 à 11:11, Dominique Rousseau  a 
écrit :


Le Wed, Jun 13, 2018 at 09:38:08AM +0200, Antoine Riche 
[antoine.ri...@zaclys.net] a écrit:

> Bonjour Dominique,
>
> Une possibilité est de télécharger les données complètes de la carte
> uMap (menu partager), puis de les importer dans MapOSMatic (instance
> https://maposmatic.osm-baustelle.de/) : onglet "Umap data file" dès
> le premier écran "Générer votre carte".

J'avais pense a MapOSMatic, mais la zone est trop grande :(

(par contre, j'apprends que MapOSMatic peut importer des données umap,
merci du tuyau ;-)


>
> Antoine.
>
>
> Le 12/06/2018 à 14:14, Dominique Rousseau a écrit :
> >Bonjour la liste,
> >
> >J'ai préparé une carte sur uMap, avec quelques marqueurs, dans le but de
> >pouvoir sortir une version "bitmap" à imprimer (~ format A3, je pense).
> >
> >Quelqu'un aurait une piste, plus "fine" qu'une copie d'écran ?
> >et qui ne nécessite pas d'exporter un fichier .osm, installer mapnik,
> >etc :o)
> >
> >Ma zone couvre en gros 80km x 80km, c'est pour ça que je voudrais une
> >résolution suffisante pour que les détails soient lisibles, une fois
> >imprimé.
> >
> >
>
>
>
> ---
> L'absence de virus dans ce courrier électronique a été vérifiée par le 
logiciel antivirus Avast.
> https://www.avast.com/antivirus

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


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


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


--
Phyks

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

[OSM-talk-fr] Mise à jour des stations Vélib

[Phyks]

Bonjour,

Je crois que la plupart des stations Vélib ont été marquées comme 
"disused" il y a quelques temps, au début des travaux de changement 
d'opérateur (https://www.openstreetmap.org/changeset/52517046). 
Pourtant, certaines stations ont commencé à rouvrir et je crois que les 
données OSM ne sont plus à jour. 
https://www.openstreetmap.org/node/343520022 est rouverte par exemple.


Je ne sais pas exactement quelle est la meilleure solution pour corriger 
ça, à la main ou de mettre en place un import semi-automatisé (osmose 
?). Les deux sources de données que je connaisse sont l'API derrière 
https://www.velib-metropole.fr/map#/ (mais aucune mention de licence à 
ma connaissance, utilisé par http://velib.nocle.fr/) et 
https://opendata.paris.fr/explore/dataset/velib-disponibilite-en-temps-reel/information/ 
(explicitement ODBL mais données de qualité moindre).


Je me dis qu'un import semi-automatisé est sûrement la façon la plus 
simple de garder les données à jour, facilement, lors de l'ajout de 
nouvelles stations et les fermetures temporaires. Auriez-vous des avis 
et des conseils sur la meilleure façon de procéder ?

--
Phyks

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