Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
Bravo pour ce travail c'est hyper enthousiasmant! Et merci pour le petit exemple OverPass, c'est instructif à lire! Sébastien. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
Bien joué
Le ven. 14 févr. 2020 à 19:48, a écrit :
> Bonsoir,
>
> ça y est, nous avons fini la journée de Cartopartie à tagger les panneaux
> d'entrée et de sorties de villes du Gers.
> 966 panneaux ont été créés.
>
> Voici la requette Overpass Turbo pour consulter les données:
>
> [out:json][timeout:25];
> // Définir la zone de recherche:
> {{geocodeArea:"Gers"}}->.dept;
> ( // Prospecter pour les noeuds, chemins et relation
> node["traffic_sign:forward"="city_limit"](area.dept);
> node["traffic_sign:backward"="city_limit"](area.dept);
> node["traffic_sign"="city_limit"](area.dept);
> node["traffic_sign"="city_limit,FR:EB10"](area.dept);
> node["traffic_sign"="city_limit,FR:EB20"](area.dept);
> );
> // Afficher les résultats:
> out body;
> >;
> out skel qt;
>
>
> Je dois encore vérifier et corriger quelques petites choses pour voir s'il
> n'y a pas d'erreurs.
> Je compléterais également la doc OSM.
>
> Nous n'avons pas tant utilisés le tag traffic_sign:forward car certains
> étudiants n'étaient pas forcément à l'aise avec le sens du tracet, etc.
>
> Merci à tous ceux qui m'ont aidé à préparé et débrousailler ce travail!
>
> Bonne soirée,
>
> Onésime.
>
> --
> *De: *onesim...@free.fr
> *À: *"Discussions sur OSM en français"
> *Envoyé: *Jeudi 13 Février 2020 23:26:01
> *Objet: *Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de
> villes & villages
>
> Bonsoir,
>
> Ok, merci pour cette précisions.
> Je vais voir comment ça se passe.
> Et si jamais c'est trop compliqué de tagger directement dans OSM, est ce
> qu'on peut transmettre le fichier shapefile avec les données, et les
> métadonnées pour que quelqu'un puisse les charger directement dans OSM? Si
> oui, comment ça se passe, il y a un lieu fait pour ça, ou c'est sur ce
> genre de liste?
> Avant, on utilisait le plugin OSM de QGis, mais maintenant il n'y ai
> plus... et l'utilisation de Josm est un peu compliquée à employer dans le
> cadre d'une cartopartie avec des personnes qui ne sont pas familières.
>
> Merci à vous,
>
> Onésime.
>
> --
> *De: *"Florimond Berthoux"
> *À: *"Discussions sur OSM en français"
> *Envoyé: *Mercredi 12 Février 2020 22:13:39
> *Objet: *Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de
> villes & villages
>
>
> Sur le wiki en créant une page, par exemple en anglais tu suis un des
> liens et tu appuies sur "créer"
> https://wiki.openstreetmap.org/wiki/Key:pole:sealed
> ou https://wiki.openstreetmap.org/wiki/Key:support:sealed
>
> Le mar. 11 févr. 2020 à 21:30, a écrit :
>
>> Ok, je vais tenter avec cela.
>> Pour le documenter, comment ça se passe?
>>
>> Merci!
>>
>> --
>> *De: *"Florimond Berthoux"
>> *À: *"Discussions sur OSM en français"
>> *Envoyé: *Mardi 11 Février 2020 19:38:44
>> *Objet: *Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de
>> villes & villages
>>
>> Tout bien réfléchi je pense que c'est une erreur de considérer le sol ou
>> le béton comme étant le support du poteau (c'est pas faux, mais pas top non
>> plus).
>> Je verrais plutôt un tag pour préciser si le poteau est scellé ou non
>> dans du béton.
>>
>> propositions :
>> support:sealed=yes|concrete
>> ou
>> pole:sealed=yes|concrete
>>
>> (sealed ou embedded ?)
>>
>> @Onésime oui il n'y a pas de tag documenté pour différencier les poteaux
>> scellé des non scellé.
>> Dans l'absolue vaut mieux inventer inventer un nouveau tag, le
>> documenter, et s'il faut le changer un peu plus tard on pourra le faire de
>> façon presque automatique.
>>
>> Le mar. 11 févr. 2020 à 14:34, marc marc a
>> écrit :
>>
>>> Le 11.02.20 à 14:05, Florimond Berthoux a écrit :
>>> > support=pole
>>> > support:pole:support=ground
>>> >
>>> > plutôt parce que s’il y a plusieurs support (support=pole;wall) on
>>> > pourra pas préciser le support de quel support.
>>>
>>> une photo d'un panneau supporté à la fois par un poteau et un mur ?
>>> j'ai l'impression qu'on est une fois de + entrain de faire une usine à
>>> gaz "par défaut" pour au cas oü il y a besoin de traiter un cas plus
>>> complexe que le cas par défaut. et le contributeur lambda est largé
>>> depuis longtemps par la marche toujours plus grande à entr
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
Bonsoir,
ça y est, nous avons fini la journée de Cartopartie à tagger les panneaux
d'entrée et de sorties de villes du Gers.
966 panneaux ont été créés.
Voici la requette Overpass Turbo pour consulter les données:
[out:json][timeout:25];
// Définir la zone de recherche:
{{geocodeArea:"Gers"}}->.dept;
( // Prospecter pour les noeuds, chemins et relation
node["traffic_sign:forward"="city_limit"](area.dept);
node["traffic_sign:backward"="city_limit"](area.dept);
node["traffic_sign"="city_limit"](area.dept);
node["traffic_sign"="city_limit,FR:EB10"](area.dept);
node["traffic_sign"="city_limit,FR:EB20"](area.dept);
);
// Afficher les résultats:
out body;
>;
out skel qt;
Je dois encore vérifier et corriger quelques petites choses pour voir s'il n'y
a pas d'erreurs.
Je compléterais également la doc OSM.
Nous n'avons pas tant utilisés le tag traffic_sign:forward car certains
étudiants n'étaient pas forcément à l'aise avec le sens du tracet, etc.
Merci à tous ceux qui m'ont aidé à préparé et débrousailler ce travail!
Bonne soirée,
Onésime.
- Mail original -
De: onesim...@free.fr
À: "Discussions sur OSM en français"
Envoyé: Jeudi 13 Février 2020 23:26:01
Objet: Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes &
villages
Bonsoir,
Ok, merci pour cette précisions.
Je vais voir comment ça se passe.
Et si jamais c'est trop compliqué de tagger directement dans OSM, est ce qu'on
peut transmettre le fichier shapefile avec les données, et les métadonnées pour
que quelqu'un puisse les charger directement dans OSM? Si oui, comment ça se
passe, il y a un lieu fait pour ça, ou c'est sur ce genre de liste?
Avant, on utilisait le plugin OSM de QGis, mais maintenant il n'y ai plus... et
l'utilisation de Josm est un peu compliquée à employer dans le cadre d'une
cartopartie avec des personnes qui ne sont pas familières.
Merci à vous,
Onésime.
- Mail original -----
De: "Florimond Berthoux"
À: "Discussions sur OSM en français"
Envoyé: Mercredi 12 Février 2020 22:13:39
Objet: Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes &
villages
Sur le wiki en créant une page, par exemple en anglais tu suis un des liens et
tu appuies sur "créer"
https://wiki.openstreetmap.org/wiki/Key:pole:sealed
ou https://wiki.openstreetmap.org/wiki/Key:support:sealed
Le mar. 11 févr. 2020 à 21:30, < onesim...@free.fr > a écrit :
Ok, je vais tenter avec cela.
Pour le documenter, comment ça se passe?
Merci!
De: "Florimond Berthoux" < florimond.berth...@gmail.com >
À: "Discussions sur OSM en français" < talk-fr@openstreetmap.org >
Envoyé: Mardi 11 Février 2020 19:38:44
Objet: Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes &
villages
Tout bien réfléchi je pense que c'est une erreur de considérer le sol ou le
béton comme étant le support du poteau (c'est pas faux, mais pas top non plus).
Je verrais plutôt un tag pour préciser si le poteau est scellé ou non dans du
béton.
propositions :
support:sealed=yes|concrete
ou
pole:sealed=yes|concrete
(sealed ou embedded ?)
@Onésime oui il n'y a pas de tag documenté pour différencier les poteaux scellé
des non scellé.
Dans l'absolue vaut mieux inventer inventer un nouveau tag, le documenter, et
s'il faut le changer un peu plus tard on pourra le faire de façon presque
automatique.
Le mar. 11 févr. 2020 à 14:34, marc marc < marc_marc_...@hotmail.com > a écrit
:
Le 11.02.20 à 14:05, Florimond Berthoux a écrit :
> support=pole
> support:pole:support=ground
>
> plutôt parce que s’il y a plusieurs support (support=pole;wall) on
> pourra pas préciser le support de quel support.
une photo d'un panneau supporté à la fois par un poteau et un mur ?
j'ai l'impression qu'on est une fois de + entrain de faire une usine à
gaz "par défaut" pour au cas oü il y a besoin de traiter un cas plus
complexe que le cas par défaut. et le contributeur lambda est largé
depuis longtemps par la marche toujours plus grande à entrée...
> Le mar. 11 févr. 2020 à 00:15, marc marc a écrit :
>
> support=pole : le panneau est porté par un poteau
> support:support=ground : le poteau est directement mis dans le sol
___
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] Tagger correctement les panneaux entrées de villes & villages
Bonsoir, Ok, merci pour cette précisions. Je vais voir comment ça se passe. Et si jamais c'est trop compliqué de tagger directement dans OSM, est ce qu'on peut transmettre le fichier shapefile avec les données, et les métadonnées pour que quelqu'un puisse les charger directement dans OSM? Si oui, comment ça se passe, il y a un lieu fait pour ça, ou c'est sur ce genre de liste? Avant, on utilisait le plugin OSM de QGis, mais maintenant il n'y ai plus... et l'utilisation de Josm est un peu compliquée à employer dans le cadre d'une cartopartie avec des personnes qui ne sont pas familières. Merci à vous, Onésime. - Mail original - De: "Florimond Berthoux" À: "Discussions sur OSM en français" Envoyé: Mercredi 12 Février 2020 22:13:39 Objet: Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages Sur le wiki en créant une page, par exemple en anglais tu suis un des liens et tu appuies sur "créer" https://wiki.openstreetmap.org/wiki/Key:pole:sealed ou https://wiki.openstreetmap.org/wiki/Key:support:sealed Le mar. 11 févr. 2020 à 21:30, < onesim...@free.fr > a écrit : Ok, je vais tenter avec cela. Pour le documenter, comment ça se passe? Merci! De: "Florimond Berthoux" < florimond.berth...@gmail.com > À: "Discussions sur OSM en français" < talk-fr@openstreetmap.org > Envoyé: Mardi 11 Février 2020 19:38:44 Objet: Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages Tout bien réfléchi je pense que c'est une erreur de considérer le sol ou le béton comme étant le support du poteau (c'est pas faux, mais pas top non plus). Je verrais plutôt un tag pour préciser si le poteau est scellé ou non dans du béton. propositions : support:sealed=yes|concrete ou pole:sealed=yes|concrete (sealed ou embedded ?) @Onésime oui il n'y a pas de tag documenté pour différencier les poteaux scellé des non scellé. Dans l'absolue vaut mieux inventer inventer un nouveau tag, le documenter, et s'il faut le changer un peu plus tard on pourra le faire de façon presque automatique. Le mar. 11 févr. 2020 à 14:34, marc marc < marc_marc_...@hotmail.com > a écrit : Le 11.02.20 à 14:05, Florimond Berthoux a écrit : > support=pole > support:pole:support=ground > > plutôt parce que s’il y a plusieurs support (support=pole;wall) on > pourra pas préciser le support de quel support. une photo d'un panneau supporté à la fois par un poteau et un mur ? j'ai l'impression qu'on est une fois de + entrain de faire une usine à gaz "par défaut" pour au cas oü il y a besoin de traiter un cas plus complexe que le cas par défaut. et le contributeur lambda est largé depuis longtemps par la marche toujours plus grande à entrée... > Le mar. 11 févr. 2020 à 00:15, marc marc a écrit : > > support=pole : le panneau est porté par un poteau > support:support=ground : le poteau est directement mis dans le sol ___ 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 -- 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] Tagger correctement les panneaux entrées de villes & villages
Sur le wiki en créant une page, par exemple en anglais tu suis un des liens et tu appuies sur "créer" https://wiki.openstreetmap.org/wiki/Key:pole:sealed ou https://wiki.openstreetmap.org/wiki/Key:support:sealed Le mar. 11 févr. 2020 à 21:30, a écrit : > Ok, je vais tenter avec cela. > Pour le documenter, comment ça se passe? > > Merci! > > -- > *De: *"Florimond Berthoux" > *À: *"Discussions sur OSM en français" > *Envoyé: *Mardi 11 Février 2020 19:38:44 > *Objet: *Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de > villes & villages > > Tout bien réfléchi je pense que c'est une erreur de considérer le sol ou > le béton comme étant le support du poteau (c'est pas faux, mais pas top non > plus). > Je verrais plutôt un tag pour préciser si le poteau est scellé ou non dans > du béton. > > propositions : > support:sealed=yes|concrete > ou > pole:sealed=yes|concrete > > (sealed ou embedded ?) > > @Onésime oui il n'y a pas de tag documenté pour différencier les poteaux > scellé des non scellé. > Dans l'absolue vaut mieux inventer inventer un nouveau tag, le documenter, > et s'il faut le changer un peu plus tard on pourra le faire de façon > presque automatique. > > Le mar. 11 févr. 2020 à 14:34, marc marc a > écrit : > >> Le 11.02.20 à 14:05, Florimond Berthoux a écrit : >> > support=pole >> > support:pole:support=ground >> > >> > plutôt parce que s’il y a plusieurs support (support=pole;wall) on >> > pourra pas préciser le support de quel support. >> >> une photo d'un panneau supporté à la fois par un poteau et un mur ? >> j'ai l'impression qu'on est une fois de + entrain de faire une usine à >> gaz "par défaut" pour au cas oü il y a besoin de traiter un cas plus >> complexe que le cas par défaut. et le contributeur lambda est largé >> depuis longtemps par la marche toujours plus grande à entrée... >> >> > Le mar. 11 févr. 2020 à 00:15, marc marc a écrit : >> > >> > support=pole : le panneau est porté par un poteau >> > support:support=ground : le poteau est directement mis dans le sol >> >> ___ >> 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 > -- Florimond Berthoux ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
Ok, je vais tenter avec cela. Pour le documenter, comment ça se passe? Merci! - Mail original - De: "Florimond Berthoux" À: "Discussions sur OSM en français" Envoyé: Mardi 11 Février 2020 19:38:44 Objet: Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages Tout bien réfléchi je pense que c'est une erreur de considérer le sol ou le béton comme étant le support du poteau (c'est pas faux, mais pas top non plus). Je verrais plutôt un tag pour préciser si le poteau est scellé ou non dans du béton. propositions : support:sealed=yes|concrete ou pole:sealed=yes|concrete (sealed ou embedded ?) @Onésime oui il n'y a pas de tag documenté pour différencier les poteaux scellé des non scellé. Dans l'absolue vaut mieux inventer inventer un nouveau tag, le documenter, et s'il faut le changer un peu plus tard on pourra le faire de façon presque automatique. Le mar. 11 févr. 2020 à 14:34, marc marc < marc_marc_...@hotmail.com > a écrit : Le 11.02.20 à 14:05, Florimond Berthoux a écrit : > support=pole > support:pole:support=ground > > plutôt parce que s’il y a plusieurs support (support=pole;wall) on > pourra pas préciser le support de quel support. une photo d'un panneau supporté à la fois par un poteau et un mur ? j'ai l'impression qu'on est une fois de + entrain de faire une usine à gaz "par défaut" pour au cas oü il y a besoin de traiter un cas plus complexe que le cas par défaut. et le contributeur lambda est largé depuis longtemps par la marche toujours plus grande à entrée... > Le mar. 11 févr. 2020 à 00:15, marc marc a écrit : > > support=pole : le panneau est porté par un poteau > support:support=ground : le poteau est directement mis dans le sol ___ 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] Tagger correctement les panneaux entrées de villes & villages
Tout bien réfléchi je pense que c'est une erreur de considérer le sol ou le béton comme étant le support du poteau (c'est pas faux, mais pas top non plus). Je verrais plutôt un tag pour préciser si le poteau est scellé ou non dans du béton. propositions : support:sealed=yes|concrete ou pole:sealed=yes|concrete (sealed ou embedded ?) @Onésime oui il n'y a pas de tag documenté pour différencier les poteaux scellé des non scellé. Dans l'absolue vaut mieux inventer inventer un nouveau tag, le documenter, et s'il faut le changer un peu plus tard on pourra le faire de façon presque automatique. Le mar. 11 févr. 2020 à 14:34, marc marc a écrit : > Le 11.02.20 à 14:05, Florimond Berthoux a écrit : > > support=pole > > support:pole:support=ground > > > > plutôt parce que s’il y a plusieurs support (support=pole;wall) on > > pourra pas préciser le support de quel support. > > une photo d'un panneau supporté à la fois par un poteau et un mur ? > j'ai l'impression qu'on est une fois de + entrain de faire une usine à > gaz "par défaut" pour au cas oü il y a besoin de traiter un cas plus > complexe que le cas par défaut. et le contributeur lambda est largé > depuis longtemps par la marche toujours plus grande à entrée... > > > Le mar. 11 févr. 2020 à 00:15, marc marc a écrit : > > > > support=pole : le panneau est porté par un poteau > > support:support=ground : le poteau est directement mis dans le sol > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > -- Florimond Berthoux ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
Bonsoir, Merci pour vos échanges... la date de la session de cartoparty approche (vendredi)... et je suis toujours dans le flou. Comme je l'ai évoqué, la commande est de faire: - une mise à jour des panneaux de villes et villages, - renseigner le EB10 ou EB20 (entrée ou sortie de village), - renseigner si les 2 panneaux sont au même niveau, - renseigner si le panneau est zérophyto ou non => si le poteau est ancré dans le sol directement ou s'il y a un carré de béton au pied (qui ne nécessite pas de désherbant). C'est une cartoparty avec une classe de géomaticien, et pour faire découvrir OSM et l'enrichir par la même occasion, on se base sur OSM pour répondre à la commande qui nous est faite (en général, ça se passe en classe en se basant sur des ressources libres telles que Mapillary, OpenStreetCam, etc.). Là, j'avoue que les différents échanges font que je n'y voit toujours pas plus claire. Je suis entrain de préparer les consignes avec les tags, etc. - on est d'accord pour utiliser traffic_sign=city_limit , puis éventuellement name= pour le nom du village. - pour le sens, par contre, on a le choix - entre traffic_sign:forward= city_limit et traffic_sign:backward = city_limit - OU traffic_sign=city_limit,FR:EB10 et traffic_sign=city_limit,FR:EB20 - pour le poteau, si je comprends bien, il faut utiliser support=pole dans tous les cas si le panneau est sur un poteau... par contre, il n'y a pas trop de solution pour renseigner si le poteau est sur du béton ou non? Il y aurait une 30ne d'élèves pour bosser dessus sur une journée... et ce serait dommage qu'OSM ne profite pas de cette aubaine? (renseigner OSM est du bonus, on nous demande juste un shapefile avec les infos). Concernant le département, c'est le Gers, donc on est pas trop sur la problématique de passer d'une agglo à l'autre avec les histoires de vitesse, on est vraiment dans un contexte rural. Merci, bonne fin de journée, Onésime - Mail original - De: "Christian Quest" À: talk-fr@openstreetmap.org Envoyé: Mardi 11 Février 2020 17:00:25 Objet: Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages Le 11/02/2020 à 14:33, marc marc a écrit : > Le 11.02.20 à 14:05, Florimond Berthoux a écrit : >> support=pole >> support:pole:support=ground >> >> plutôt parce que s’il y a plusieurs support (support=pole;wall) on >> pourra pas préciser le support de quel support. > une photo d'un panneau supporté à la fois par un poteau et un mur ? > j'ai l'impression qu'on est une fois de + entrain de faire une usine à > gaz "par défaut" pour au cas oü il y a besoin de traiter un cas plus > complexe que le cas par défaut. et le contributeur lambda est largé > depuis longtemps par la marche toujours plus grande à entrée... +1000 ! KISS -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
Le 11/02/2020 à 14:33, marc marc a écrit : Le 11.02.20 à 14:05, Florimond Berthoux a écrit : support=pole support:pole:support=ground plutôt parce que s’il y a plusieurs support (support=pole;wall) on pourra pas préciser le support de quel support. une photo d'un panneau supporté à la fois par un poteau et un mur ? j'ai l'impression qu'on est une fois de + entrain de faire une usine à gaz "par défaut" pour au cas oü il y a besoin de traiter un cas plus complexe que le cas par défaut. et le contributeur lambda est largé depuis longtemps par la marche toujours plus grande à entrée... +1000 ! KISS -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
> > j'ai visiblement mal formulé ma remarque : > FAIT: quand on passe de "hors zone urbaine" à "zone urbaine" en > croissant donc un panneau EB10 dans un sens et un panneau EB20 dans > l'autre sens, cela se MODELISE dans osm par traffic_sign=city_limit > QUESTION : si on modélise l'entrée sur un way bi-directionnel, > a-t-on besoin de dire que dans le sens inverse c'est une sortie ? > Non sauf si tu modélise le matériel en tant que tel. Donc on peut définir : un niveau 1 de précision en lien avec juste l'information routière et son découpage simple on considère que le cas par défaut c'est traffic_sign=city_limit+ direction=forward traffic_sign:forward=FR:EB10[agglo];traffic_sign:backward=FR:EB20[agglo] Avec 1 noeud à la limite des zones > > On pourrait réserver ce niveau de précision au cas des voie en > sens-unique puisque dans ce cas (seulement ?) le panneau entrée n'est pas dans ce cas en effet tu as une notion de sortie en entrée traffic_sign:forward=FR:EB10[agglo]; en sortie traffic_sign:backward=FR:EB20[agglo] Dans les autres (99% ?) cas, c'est une complexification dont > je ne vois l'information supplémentaire qu'elle apporte. > Toi peut être mais on me modélise pas tous pour les même chose et certains pas pour le routing @marc il suffirait de limiter le niveau de détail (ou d'abstraction) que l'on souhaite c'est aussi ça une base... Mais c'est pas fait (tous du moins pas jusqu'a un certain niveau) On voit ça sur l'électricité ou l'on atteint le niveau de précision d'une base métier D'où la multiplicité des méthodes et niveaux détails sur les données. Pour revenir au niveau des support: Pour éviter de renter dans l'usine à gaz on prend l'objet en tant que tel. L'objet que l'on décrit est matérialisé sous forme de point est situer où? sur un mur ou au sol? si tu veux aller plus loin dans ce cas on va dans du commentaire ( regrouper sur un poteau) On doit pouvoir comme on le disait plus haut trouver certains modèles et les décrire assez bien pour que des outils puissent exploiter les données et que des contributeurs puissent fournir des informations. Si l'on commence à avoir des imbrications d'un même éléments (chose que je ne pensais pas accepté) ça va aller super loin. Et plus loin jusqu'à présent s'était ailleurs -- Cordialement, Jérôme Seigneuret ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
Le 11.02.20 à 14:00, Florimond Berthoux a écrit : > > > Le mar. 11 févr. 2020 à 00:18, marc marc a écrit : > > > donc une alternative et une meilleure manière de le noter est la > suivante : > > - traffic_sign=city_limit,FR:EB20. > > je comprend pas ce que tu veux dire avec cette totologie. > une limite urbaine est un panneau EB20 et vice-versa. > a-t-on besoin de dire que si on suit le chemin inverse d'une entrée > c'est une sortie ? cela me semble lourd pour un gain qui m’échappe. > > > city_limit c’est FR:EB10 *ou* EB20, le city_limit ne définit pas si > c’est une entrée ou une sortie > (oui city_limit est pas top comme tag) j'ai visiblement mal formulé ma remarque : FAIT: quand on passe de "hors zone urbaine" à "zone urbaine" en croissant donc un panneau EB10 dans un sens et un panneau EB20 dans l'autre sens, cela se MODELISE dans osm par traffic_sign=city_limit QUESTION : si on modélise l'entrée sur un way bi-directionnel, a-t-on besoin de dire que dans le sens inverse c'est une sortie ? On pourrait réserver ce niveau de précision au cas des voie en sens-unique puisque dans ce cas (seulement ?) le panneau entrée n'est pas sur le même way que celui de sortie. Dans les autres (99% ?) cas, c'est une complexification dont je ne vois l'information supplémentaire qu'elle apporte. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
Le 11.02.20 à 14:05, Florimond Berthoux a écrit : > support=pole > support:pole:support=ground > > plutôt parce que s’il y a plusieurs support (support=pole;wall) on > pourra pas préciser le support de quel support. une photo d'un panneau supporté à la fois par un poteau et un mur ? j'ai l'impression qu'on est une fois de + entrain de faire une usine à gaz "par défaut" pour au cas oü il y a besoin de traiter un cas plus complexe que le cas par défaut. et le contributeur lambda est largé depuis longtemps par la marche toujours plus grande à entrée... > Le mar. 11 févr. 2020 à 00:15, marc marc a écrit : > > support=pole : le panneau est porté par un poteau > support:support=ground : le poteau est directement mis dans le sol ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
support=pole support:pole:support=ground plutôt parce que s’il y a plusieurs support (support=pole;wall) on pourra pas préciser le support de quel support. (support:pole:support:ground:support=earth support:pole:support:ground:support:earth:support=space :D) Le mar. 11 févr. 2020 à 00:15, marc marc a écrit : > Le 10.02.20 à 22:23, osm.sanspourr...@spamgourmet.com a écrit : > > pour préciser l'ancrage : > > pole_mount=ground ou concrete_slab à la manière de > > https://wiki.openstreetmap.org/wiki/Key:lamp_mount > > > lamp_mount est une horreur à ne pas suivre. > support=pole : le panneau est porté par un poteau > support:support=ground : le poteau est directement mis dans le sol > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > -- Florimond Berthoux ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
Le mar. 11 févr. 2020 à 00:18, marc marc a écrit : > > donc une alternative et une meilleure manière de le noter est la > suivante : > > - traffic_sign=city_limit,FR:EB20. > > je comprend pas ce que tu veux dire avec cette totologie. > une limite urbaine est un panneau EB20 et vice-versa. > a-t-on besoin de dire que si on suit le chemin inverse d'une entrée > c'est une sortie ? cela me semble lourd pour un gain qui m’échappe. > city_limit c’est FR:EB10 *ou* EB20, le city_limit ne définit pas si c’est une entrée ou une sortie (oui city_limit est pas top comme tag) -- Florimond Berthoux ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
*je comprend pas ce que tu veux dire avec cette totologie.une limite urbaine est un panneau EB20 et vice-versa.a-t-on besoin de dire que si on suit le chemin inverse d'une entréec'est une sortie ? cela me semble lourd pour un gain qui m’échappe. * Je suis d'accord sur ce sujet. Un FR:EB20 c'est égal à la valeur de sortie du city_limit Ducoup c'est soit l'un soit l'autre dans le cas du point sur le réseau traffic_sign=city_limit ou traffic_sign=FR:EB20 pour la sortie d'une voie en sens unique traffic_sign=FR:EB10 pour les autre cas on peut considéré que c'est le cas implicite Sinon c'est hors topologie avec placement au réel du panneau ce qui permet d'identifier la présence ou absence de matériel sur le terrain. Graphiquement. L'analyse de vitesse on s'en fou un peu puisse que le maxspeed doit être saisie sur la voie et que la source d'information est matérialisé. traffic_sign=FR:EB10 et traffic_sign=FR:EB20 Prennent tous leur sens et c'est les problème que l'on a toujours entre Montpellier Lattes et Saint-Jean de Védas où on a de réel problème pour les vitesses portion à 50 ou à 80 voir 90 avant l'entrée sur le rond point. sortie 1 90 https://www.mapillary.com/map/im/ixB69C61ZJJIDtY3KLZzrw entrée 1 50 https://www.mapillary.com/map/im/Zo3aje8wMAYuV5kjF0QLdA sortie 2 90 https://www.mapillary.com/map/im/wst74HSo9hjkXTabdGlKxQ entrée 2 50 https://www.mapillary.com/map/im/OoJ7Mk2eXmhsA0fy6LUD-w sortie 3 80 https://www.mapillary.com/map/im/KSwwyWu3Pl53VKzXhj4CdQ entrée 3 50 ici suivant d'où je viens j'ai un problème clair de vitesse J'ai pas de photo mais au bout de la sortie 3 le l'autre coté du rond point on a un panneau d'entrée mais pas de sortie ce qui génère un problème de topologie. Et en base on fait quoi? et les outils traite le problème comment? C'est un peu comme le trou ou le chevauchement sur des limites de frontières dont les pays sont en désaccord. C'est pour cela que je préfère les implantations réelles puis fournir sur le tronçon l'information de vitesse correspondantes (ou une erreur à corriger). Je vais pas reprendre le cours sur le traitement des vitesses du code de la route mais on pourrait envisager de détailler ce point sur le wiki vu la problématique. *Si l’autorité détentrice du pouvoir de police souhaite abaisser la vitesse, il doit en principe rappeler cette limite après chaque intersection. Mais il dispose également de différents outils qui permettent de ne pas rappeler la vitesse à chaque intersection (cas des panneaux de zones) * Le problème c'est le suivi du développement urbain qui n'est pas forcément réanalysé en terme de signalisation Pour moi ces panneaux sont dans tous les cas indispensable à leur emplacement pour bien interpréter la réalité terrain. Si on met l'info de vitesse sur le tronçon c'est pour éviter ces cas d'interprétation par les outils vu que c'est pas performant et que ça pause aussi des problèmes problème de responsabilité. C'est pour cela que l'on a autant de problème à trouver des sources fiable sur le sujet alors que les DDTM on des infos sur les implantations de leurs panneaux. Pour les communes j'en parle pas car vu les problèmes il est clair que l'on ne retrouvera des infos que dans 30% des cas. Ne pas oublier qu'un panneau 30 sous un panneau de ville transpose l'ensemble de l'agglomération à 30km/h sauf signalisation au sol ou vertical signalant le contraire dans l'agglomération (oui la ville peut être limité à 30km/h sauf axes majeurs qui peuvent être élevé à une vitesse de 70km/h https://www.ornikar.com/code/cours/panneaux/interdiction/limitation-vitesse#les-panneaux-en-agglomeration-1 J'ai corrigé la ville de Beauvoisin en ce sens. https://www.openstreetmap.org/node/7121675138 Nœud simple sur le réseau (pour le moment) Le problème reste les chemins sur lesquels il manque les panneaux d'entrée et sortie et qui retombent sur la départementale hors agglomération... Les chemin sont carrossés... Bonne journée Le mar. 11 févr. 2020 à 00:18, marc marc a écrit : > Bonsoir, > > Le 10.02.20 à 21:59, onesim...@free.fr a écrit : > > Je pense qu’on va partir sur des points à proximité de la route, à > > l’emplacement exact du panneau. > > je me demande s'il y un logiciel de routage qui l'utilisera > > > Il n’est pas possible de mettre 2 fois la même clé par ex. : > > si : clef=valeur1;valeur2 (exemple avec la clef cuisine > > > donc une alternative et une meilleure manière de le noter est la > suivante : > > - traffic_sign=city_limit,FR:EB20. > > je comprend pas ce que tu veux dire avec cette totologie. > une limite urbaine est un panneau EB20 et vice-versa. > a-t-on besoin de dire que si on suit le chemin inverse d'une entrée > c'est une sortie ? cela me semble lourd pour un gain qui m’échappe. > > Cordialement, > Marc > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > -- Cordialement, Jérôme Seigneuret
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
Bonsoir, Le 10.02.20 à 21:59, onesim...@free.fr a écrit : > Je pense qu’on va partir sur des points à proximité de la route, à > l’emplacement exact du panneau. je me demande s'il y un logiciel de routage qui l'utilisera > Il n’est pas possible de mettre 2 fois la même clé par ex. : si : clef=valeur1;valeur2 (exemple avec la clef cuisine > donc une alternative et une meilleure manière de le noter est la suivante : > - traffic_sign=city_limit,FR:EB20. je comprend pas ce que tu veux dire avec cette totologie. une limite urbaine est un panneau EB20 et vice-versa. a-t-on besoin de dire que si on suit le chemin inverse d'une entrée c'est une sortie ? cela me semble lourd pour un gain qui m’échappe. Cordialement, Marc ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
Le 10.02.20 à 22:23, osm.sanspourr...@spamgourmet.com a écrit : > pour préciser l'ancrage : > pole_mount=ground ou concrete_slab à la manière de > https://wiki.openstreetmap.org/wiki/Key:lamp_mount lamp_mount est une horreur à ne pas suivre. support=pole : le panneau est porté par un poteau support:support=ground : le poteau est directement mis dans le sol ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
Bonjour, J'ai un problème avec ça car pour moi le support dans les deux cas c'est un poteau, donc pole. Ce qui change c'est l'ancrage : avec ou sans plot béton. Peut-être : https://wiki.openstreetmap.org/wiki/Key:support * support=ground The feature is directly put on the ground. * support=pedestal The feature is supported by a pedestal. Mais ce n'est pas le panneau, c'est le poteau qui est dans le sol. Donc pole et pedestal ? Bof pour pedestal. J'aurais tendance à dire support=pole dans les deux cas. et pour préciser l'ancrage : pole_mount=ground ou concrete_slab à la manière de https://wiki.openstreetmap.org/wiki/Key:lamp_mount Jean-Yvon Le 10/02/2020 à 21:59, onesim...@free.fr a écrit : Concernant le type de fixation du poteau, que pensez vous de ce qu’on pensais faire : - support= post quand le panneau est simplement planté - support = pole si le panneau est scellé au sol avec du béton ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
Ce qui existe réellement c'est la sortie d'une commune et l'entrée dans une autre, superposés sur le même poteau du même côté droit de la route dans une direction donnée; et un autre panneau de l'autre côté de la route avec les deux panneaux de sortie et d'entrée superposés. Dans ce cas il n'y a habituellement pas de changement de limite de vitesse (cela reste 50 km/h par défaut avant et après car on reste en agglomération), mais il arrive aussi qu'un panneau EB10 ou EB20 soit aussi accompagné d'un panneau de limitation de vitesse différent de la valeur par défaut (par exemple un 30km/h en zone urbaine dense, ou un 70 km/h en agglomération peu dense sur une départementale avec peu de piétons et de commerce et pas d'écoles, et qu'il y ait donc là un changement de limite au passage d'une commune à l'autre: le panneau de limitation de vitesse modifie en priorité le sens du panneau d'entrée ou sortie d'agglomération dont la limite par défaut est alors à ignorer). Le lun. 10 févr. 2020 à 21:59, a écrit : > Bonsoir, > > > Je pense qu’on va partir sur des points à proximité de la route, à > l’emplacement exact du panneau. > > > Si je récapitule : > > Il n’est pas possible de mettre 2 fois la même clé par ex. : > > - traffic_sign=city_limit > > et > > - traffic_sign=FR:EB20 > > donc une alternative et une meilleure manière de le noter est la > suivante : > > - traffic_sign=city_limit,FR:EB20. > > > Même si je doute que l’on ai le panneau d’entrée et de sortie du village > sur le même poteaux, si ça arrive, on se base sur le sens de création du > trait, puis on définit si c’est backward ou forward. > > traffic_sign:backward=city_limit > traffic_sign:forward=city_limit > > > Concernant le type de fixation du poteau, que pensez vous de ce qu’on > pensais faire : > > - support= post quand le panneau est simplement planté > > - support = pole si le panneau est scellé au sol avec du béton > > ? > > > Merci pour votre aide ! > > > Bonne soirée, Onesime > > > -------------- > *De: *"leni" > *À: *talk-fr@openstreetmap.org > *Envoyé: *Lundi 10 Février 2020 18:17:49 > *Objet: *Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de > villes & villages > > Désolé, mon message a été envoyé à la liste au lieu d'à la poubelle > > leni > > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
Bonsoir, Je pense qu’on va partir sur des points à proximité de la route, à l’emplacement exact du panneau. Si je récapitule : Il n’est pas possible de mettre 2 fois la même clé par ex. : - traffic_sign=city_limit et - traffic_sign=FR:EB20 donc une alternative et une meilleure manière de le noter est la suivante : - traffic_sign=city_limit,FR:EB20. Même si je doute que l’on ai le panneau d’entrée et de sortie du village sur le même poteaux, si ça arrive, on se base sur le sens de création du trait, puis on définit si c’est backward ou forward. traffic_sign:backward=city_limit traffic_ sign:forward=city_limit Concernant le type de fixation du poteau, que pensez vous de ce qu’on pensais faire : - support= post quand le panneau est simplement planté - support = pole si le panneau est scellé au sol avec du béton ? Merci pour votre aide ! Bonne soirée, Onesime - Mail original - De: "leni" À: talk-fr@openstreetmap.org Envoyé: Lundi 10 Février 2020 18:17:49 Objet: Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages Désolé, mon message a été envoyé à la liste au lieu d'à la poubelle leni ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
Désolé, mon message a été envoyé à la liste au lieu d'à la poubelle leni ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
Le 10.02.20 à 16:00, Jérôme Seigneuret a écrit : > comment matérialiser la face arrière du panneau qui est sur le même poteau > Si l'on fait deux point très proches ce qui fera qu'entre les deux > points on aura 1 mètre hors agglomération? simplifie toi la vie :-) 2 points soit exactement au même endroit soit séparé de 1mm (vu que iD par exemple rend très compliqué la sélection d'un objet précis parmis plusieurs superposés) OU traffic_sign:backward=city_limit traffic_sign:forward=city_limit ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
Le dim. 9 févr. 2020 à 23:07, onesime31 a écrit : > Bonsoir, > > Ce n'est pas taguer 2 fois le même feature, vu qu'ils sont distingués par > leur code eb20 ou eb10 qui sont des standards en France. > Feature : objet du monde réel que l’on souhaite modéliser dans OSM Ici le feature c’est le panneau, placer sur deux nœuds traffic_sign= pour le même panneau c’est tagguer deux fois le même panneau, c’est dire qu’il y a deux panneaux. Pour avoir les deux info sur le même nœud j’ai peut-être une solution : traffic_sign=city_limit,FR:EB20 https://wiki.openstreetmap.org/wiki/Key:traffic_sign#Traffic_sign_IDs « If traffic signs are related, the additional sign IDs should be separated from the main sign by comma , » > Pour le forward ou backward, comment différenciez vous le sens? ! > Encore une fois, c'est un département rural, et ce sont majoritairement > des villages, traversés par une simple voie à double sens, sans marquage au > sol. > > Bonne soirée > > Message d'origine > De : Florimond Berthoux > Date : 09/02/2020 21:06 (GMT+01:00) > À : Discussions sur OSM en français > Objet : Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de > villes & villages > > Bonsoir, > > Non il ne faut pas tagguer deux fois la même feature (bonjour la cohérence > des données et la maintenance). > Si on veut être sympa pour le routeur on met le nœud sur le way de la > route avec: > traffic_sign:forward=city_limit > traffic_sign:backward=city_limit > à la hauteur du panneau de début ou de fin d'agglomération. > Attention le forward et le backward se réfère au sens du way dans le quel > le panneau est lu. > > https://wiki.openstreetmap.org/wiki/FR:Key:traffic_sign#Sur_un_way_ou_une_zone_.28area.29 > > Le dim. 9 févr. 2020 à 17:38, David Marchal a écrit : > >> >> >> > Le 9 févr. 2020 à 13:43, onesime31 a écrit : >> > >> > >> > Bonjour, >> Bonsoir. >> >> > >> > Nous avons un projet avec une classe de géomaticiens en formation. >> > On a une commande et on aimerait faire cela en utilisant OSM, faire une >> cartoparty dans le cadre de leur formation. La commande est de >> cartographier les entrées et sorties de villes et villages. >> > >> > Pour le panneau d'entrée de village, voici le key et le value qu'on >> pensait utiliser: traffic_sign=city_limit >> > à priori, il n'y a pas possibilité de préciser si c'est le panneau >> d'entrée ou de sortie du village? >> > On peut les distinguer via le code EB10 et EB20... est ce une bonne >> manière de référencer comme cela: >> > - traffic_sign=city_limit >> > - traffic_sign=FR:EB20 >> > ? >> À mon avis, il vaudrait mieux garder la convention de mettre un nœud >> traffic_sign=city_limit sur la route, à l’endroit où le panneau est placé, >> car ça permet aux utilisateurs des données de savoir, par exemple, à partir >> de quel point les règles de circulation en agglomération s’appliquent. En >> revanche, ça n’empêche pas de placer un autre nœud traffic_sign=FR:EB20 à >> l’emplacement précis du panneau, et sans lien avec la route. Faire les deux >> fait plus de travail, mais au moins tout le monde est content. >> > > -- > Florimond Berthoux > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > -- Florimond Berthoux ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
Le 10/02/2020 à 12:30, leni a écrit : Il me semble que si on lit la version anglaise https://wiki.openstreetmap.org/wiki/Tag:traffic_sign%3Dcity_limit : direction=* should be specified. The traffic sign should be faced when you drive into the city. on ne regarde que le sens du tronçon qui va vers la commune Avec direction=* indiqué, c'est mieux, mais ça complique pas mal les réutilisations. La modélisation c'est essentiellement un processus pour que des données puissent être facilement réutilisées par une machine sans avoir à faire des analyses spatiales complexes. Pour ce type de choix il faut donc avoir aussi (avant tout ?) la réutilisation automatisée en tête. Le forward/backward à la jointure de plusieurs way me semble exploitable si les ways vont dans le même sens. Il faudrait vérifier que les éditeurs mettent bien à jour les forward/backward dans le cas où le noeud est terminal. Je viens de vérifier, JOSM le gère comme il faut. Il manque par contre une analyse pour détecter les incohérences quand on a deux ways de directions opposées. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
Soit || mon panneau à deux faces cas A ---> || <--- cas B <--- || <--- cas C <--- || ---> Si l'on ne prend que la géométrie en bout de noeud le forward backward va avoir un problème sens normal de circulation --> direction à prendre en compte pour le vecteur du panneau <--- || comment matérialiser la face arrière du panneau qui est sur le même poteau Si l'on fait deux point très proches ce qui fera qu'entre les deux points on aura 1 mètre hors agglomération? Ca c'est dans le schéma où l'on matérialise le panneau sur le réseau L'autre solution c'est de dissocié les points d'entrée du réseau pour les mettre à leur implantation réelle. Cela ne fix pas de problème de double faces mais traite le problème de topologie. C'est le même problème au final que pour les panneaux de destination mais pour les destinations de ce type il me semble que c'est mis dans une relation face A face B \ \ \ ° \ \ \ direction pour A = 240 direction pour B = 60 L'avantage de prendre l'angle c'est qu'on se dissocié du problème de sens de circulation Si l'on met ça dans une relation on se retrouve avec la possibilité de mettre ce que l'on veut sur le point concerné et de respecter le sens d'entrée sortie avec from via to Le lun. 10 févr. 2020 à 15:37, Jérôme Seigneuret < jerome.seigneu...@gmail.com> a écrit : > e > > Le lun. 10 févr. 2020 à 13:38, marc marc a > écrit : > >> Le 10.02.20 à 12:30, leni a écrit : >> > https://wiki.openstreetmap.org/wiki/Tag:traffic_sign%3Dcity_limit : >> > >> > direction=* should be specified. The traffic sign should be faced when >> > you drive into the city. >> > >> > on ne regarde que le sens du tronçon qui va vers la commune >> >> > En effet sauf quand ton panneau sert à la fois à l'entrée de deux > agglomérations et à la sortie de ces même agglomération. Dans ce cas il > faut bien choisir un sens et son opposé > > -- Cordialement, Jérôme Seigneuret ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
e Le lun. 10 févr. 2020 à 13:38, marc marc a écrit : > Le 10.02.20 à 12:30, leni a écrit : > > https://wiki.openstreetmap.org/wiki/Tag:traffic_sign%3Dcity_limit : > > > > direction=* should be specified. The traffic sign should be faced when > > you drive into the city. > > > > on ne regarde que le sens du tronçon qui va vers la commune > > En effet sauf quand ton panneau sert à la fois à l'entrée de deux agglomérations et à la sortie de ces même agglomération. Dans ce cas il faut bien choisir un sens et son opposé ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
Le 10.02.20 à 12:30, leni a écrit : > https://wiki.openstreetmap.org/wiki/Tag:traffic_sign%3Dcity_limit : > > direction=* should be specified. The traffic sign should be faced when > you drive into the city. > > on ne regarde que le sens du tronçon qui va vers la commune bien vu... ce serrait à tester si les apps s'en sorte lorsque les 2 way ont une direction opposée. >> On reste à la merci d'un contributeur qui retournerait ultérieurement >> le(s) way(s) pour une raison ou une autre (aménagement latéral >> disymétrique...) et qui n'aurait pas conscience de l'impact sur les >> panneaux entré/sortie. tu as constaté ce cas ? si oui tu te souviens de sa localisation ? c'est le genre de chose qu'il faut remonter aux éditeurs, c'est pas à l'humain de passer en revue tous les noeuds d'un way pour les inverse. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
on peut toujours placer le noeud en position non terminale avec un petit
écart (la signalisation routière de toute façon impose au minimum 50 mètres
de visibilité, dans cette distance on peut placer le noeud facilement même
si on le décale de 50 centimètres), pour couper ensuite au changement de
maxspeed; dans ce cas, "forward" et "backward" marchent ("opposite" aussi,
car cela nécessite aussi une direction du way en sens unique).
Personnellement je pense que ces noeuds de panneaux devraient être hors de
la voie et à leur place réelle à côté de la chaussée, et une frontière
"boundary=urban" passera par ce noeud panneau. Il n'y a alors plus
d'ambiguité et peu importe où les voies sont découpées. C'est la solution
la plus propre.
On peut discuter du tag "boundary=urban" pour ces relations qui existent
déjà mais ne tiennent pas compte des limites communales dans la même
agglomération, où il ne me semble pas utile de créer des relations
limitrophes reprenant les frontières communales (ce qui n'empêche pas pour
autant de placer des noeuds de panneaux à coté des voies, même si aucune
frontière "boundary=urban" ne passe dessus, ni même la frontière
"boundary=adminsitrative".
Les noeuds ensuite peuvent être orientés vers la voie pour indiquer leur
face visible depuis la voie concernée. un tag avec une direction angulaire
approximative (points cardinaux ou intercardinaux devrait suffire et pour
les cas où il y a plusieurs rues candidates proches).
Le lun. 10 févr. 2020 à 09:00, Jérôme Seigneuret <
jerome.seigneu...@gmail.com> a écrit :
> Dans les archives j'avais abordé le problème sur les panneaux en double
> face.
> On a aussi le problème lié à la topologie car si le panneaux est placé sur
> le noeud terminal des deux voies la notion de forward backward ne peux pas
> fonctionner
>
> Exemple 1 : changement de nom de rue
> entrée
> et sortie
>d'agglomération
> [===]°[]
>rue A rue B
>
> Exemple 2 : changement de nom de rue
> entrée
> et sortie
>d'agglomération
> [===]°[]
> rue A rue A
> vitesse 30km/hvitesse 50km/h
>
> Et autant de cas qui fond que forward et backward ça ne peut dans certains
> cas ne pas marcher
>
> Après une des solutions que j'avais pas envisager à l'époque c'est
> d'utiliser opposite
>
> la notion de direction peut être mentionné avec un angle en degré en
> partant du nord à 0
> L'angle permet de définir la direction de la face visible
>
>
> Le lun. 10 févr. 2020 à 01:48, Philippe Verdy a écrit :
>
>> Quasiment toutes les communes ont au moins une agglomération (sauf les
>> rares communes sans habitants). le mot "agglomération" au sens des panneaux
>> EB10 et EB20 existe donc aussi en milieu rural (autant que de villages dans
>> la commune, mais même en milieu rural on a des villages à cheval sur plus
>> d'une commune, le plus souvent autour d'un pont sur une rivière frontière,
>> ou autour d'un carrefour avec une des routes faisant frontière: c'est ce
>> carrefour, ce pont, et l'activité qui s'est développée autour qui a conduit
>> à ces villages multicommunes, au départ peut-être juste un corps de ferme
>> ou une usine, ensuite les dépendances, habitations ou commerces qui se sont
>> ajoutés, justement du fait de la facilité d'accès et du passage local
>> important).
>>
>> "Agglomération" ne signifie pas grande ville : même un hameau de moins de
>> 100 âmes peut être une agglomération formant un ilôt urbanisé dans la
>> commune rurale. Un très grand nombre de communes rurales ont plusieurs
>> agglomérations, une d'elle étant le "bourg" centre et ayant donné son nom à
>> la commune, mais pas toujours (une agglo excentrée peut être aujourd'hui
>> plus peuplée et plus dense que le bourg centre historique, notamment en
>> frontière d'une autre commune voisine beaucoup plus urbanisée et ayant
>> étendu son agglomération sur la commune rurale voisine).
>>
>> "Agglomération" ne signifie donc pas non plus "commune".
>>
>>
>> Le dim. 9 févr. 2020 à 22:59, onesime31 a écrit :
>>
>>> Bonsoir,
>>> Merci pour votre réponse.
>>> Ce serait pour un département rural qui n'a pas d'agglomération... donc
>>> je parlais surtout des panneaux des entrées de village, et de quelques
>>> villes.
>>>
>>> Bonne soirée
>>>
>>>
>>>
>>> Message d'origine
>>> De : Philippe Verdy
>>> Date
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
Le 10/02/2020 à 12:16, Eric SIBERT via Talk-fr a écrit : Je dirais que quasi-systématiquement, il y a rupture des ways au niveau du panneau d'entrée/sortie d'agglomération parce que les limites de vitesse changent généralement de part et d'autre (ou au moins le source:maxspeed=*, ou le nom de rue si on saute d'une commune urbaine à l'autre...). Le 10/02/2020 à 10:34, osm.sanspourr...@spamgourmet.com a écrit : Peut ne pas fonctionner et non ne peut pas fonctionner. Il faut pour que ça ne marche pas que les voies soient tracées en sens opposé. En général on peut retourner une voie. [===>]°[>] rue A rue B Pas de soucis. [===>]°[<] rue A rue B Soucis. Retourner l'une des voies résout le problème. Il me semble que si on lit la version anglaise https://wiki.openstreetmap.org/wiki/Tag:traffic_sign%3Dcity_limit : direction=* should be specified. The traffic sign should be faced when you drive into the city. on ne regarde que le sens du tronçon qui va vers la commune On reste à la merci d'un contributeur qui retournerait ultérieurement le(s) way(s) pour une raison ou une autre (aménagement latéral disymétrique...) et qui n'aurait pas conscience de l'impact sur les panneaux entré/sortie. oui, et c'est dommage Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
Je dirais que quasi-systématiquement, il y a rupture des ways au niveau du panneau d'entrée/sortie d'agglomération parce que les limites de vitesse changent généralement de part et d'autre (ou au moins le source:maxspeed=*, ou le nom de rue si on saute d'une commune urbaine à l'autre...). Le 10/02/2020 à 10:34, osm.sanspourr...@spamgourmet.com a écrit : Peut ne pas fonctionner et non ne peut pas fonctionner. Il faut pour que ça ne marche pas que les voies soient tracées en sens opposé. En général on peut retourner une voie. [===>]°[>] rue A rue B Pas de soucis. [===>]°[<] rue A rue B Soucis. Retourner l'une des voies résout le problème. On reste à la merci d'un contributeur qui retournerait ultérieurement le(s) way(s) pour une raison ou une autre (aménagement latéral disymétrique...) et qui n'aurait pas conscience de l'impact sur les panneaux entré/sortie. Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
Peut ne pas fonctionner et non ne peut pas fonctionner.
Il faut pour que ça ne marche pas que les voies soient tracées en sens
opposé.
En général on peut retourner une voie.
[===>]°[>]
rue A rue B
Pas de soucis.
[===>]°[<]
rue A rue B
Soucis. Retourner l'une des voies résout le problème.
Jean-Yvon
Le 10/02/2020 à 08:59, Jérôme Seigneuret - jerome.seigneu...@gmail.com a
écrit :
Dans les archives j'avais abordé le problème sur les panneaux en
double face.
On a aussi le problème lié à la topologie car si le panneaux est placé
sur le noeud terminal des deux voies la notion de forward backward ne
peux pas fonctionner
Exemple 1 : changement de nom de rue
entrée
et sortie
d'agglomération
[===]°[]
rue A rue B
Exemple 2 : changement de nom de rue
entrée
et sortie
d'agglomération
[===]°[]
rue A rue A
vitesse 30km/h vitesse 50km/h
Et autant de cas qui fond que forward et backward ça ne peut dans
certains cas ne pas marcher
Après une des solutions que j'avais pas envisager à l'époque c'est
d'utiliser opposite
la notion de direction peut être mentionné avec un angle en degré en
partant du nord à 0
L'angle permet de définir la direction de la face visible
Le lun. 10 févr. 2020 à 01:48, Philippe Verdy mailto:ver...@gmail.com>> a écrit :
Quasiment toutes les communes ont au moins une agglomération (sauf
les rares communes sans habitants). le mot "agglomération" au sens
des panneaux EB10 et EB20 existe donc aussi en milieu rural
(autant que de villages dans la commune, mais même en milieu rural
on a des villages à cheval sur plus d'une commune, le plus souvent
autour d'un pont sur une rivière frontière, ou autour d'un
carrefour avec une des routes faisant frontière: c'est ce
carrefour, ce pont, et l'activité qui s'est développée autour qui
a conduit à ces villages multicommunes, au départ peut-être juste
un corps de ferme ou une usine, ensuite les dépendances,
habitations ou commerces qui se sont ajoutés, justement du fait de
la facilité d'accès et du passage local important).
"Agglomération" ne signifie pas grande ville : même un hameau de
moins de 100 âmes peut être une agglomération formant un ilôt
urbanisé dans la commune rurale. Un très grand nombre de communes
rurales ont plusieurs agglomérations, une d'elle étant le "bourg"
centre et ayant donné son nom à la commune, mais pas toujours (une
agglo excentrée peut être aujourd'hui plus peuplée et plus dense
que le bourg centre historique, notamment en frontière d'une autre
commune voisine beaucoup plus urbanisée et ayant étendu son
agglomération sur la commune rurale voisine).
"Agglomération" ne signifie donc pas non plus "commune".
Le dim. 9 févr. 2020 à 22:59, onesime31 mailto:onesim...@free.fr>> a écrit :
Bonsoir,
Merci pour votre réponse.
Ce serait pour un département rural qui n'a pas
d'agglomération... donc je parlais surtout des panneaux des
entrées de village, et de quelques villes.
Bonne soirée
Message d'origine
De : Philippe Verdy mailto:ver...@gmail.com>>
Date : 09/02/2020 15:53 (GMT+01:00)
À : Discussions sur OSM en français mailto:talk-fr@openstreetmap.org>>
Objet : Re: [OSM-talk-fr] Tagger correctement les panneaux
entrées de villes & villages
Un ennui : l'entrée d'une commune et la sortie d'une autre
peuvent être au même emplacement (même poteau support) dans le
cas d'une frontière communale au sein d'une même agglomération.
Ce qui a été déjà fait dans certaines agglomération pour les
distinguer c'est de créer des boundary=urban, passant par ces
panneaux indicateurs.
Mais "boundary=urban" ne traite pas encore ces cas de
frontières communales intra-agglomération où c'est la
frontière communale (boundary=administrative et
admin_level<=8) qui tient lieu de limite. Et il reste aussi
des cas de frontières au sein des communes nouvelles (ou
associations de communes), entre les communes déléguées ou
associées (admin_level=9), où la toponymie de chaque commune
déléguée (ou associée) est conservée (même si les panneaux
annotent en dessous et plus petits caractères "(Commune de
)".
Le "boundary=urban" est surtout destiné à limiter les
frontières d'agglomération pour la régulation routière: le
tracé des contours reste approximatif (pas exactement sur les
limi
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
Dans les archives j'avais abordé le problème sur les panneaux en double face. On a aussi le problème lié à la topologie car si le panneaux est placé sur le noeud terminal des deux voies la notion de forward backward ne peux pas fonctionner Exemple 1 : changement de nom de rue entrée et sortie d'agglomération [===]°[] rue A rue B Exemple 2 : changement de nom de rue entrée et sortie d'agglomération [===]°[] rue A rue A vitesse 30km/hvitesse 50km/h Et autant de cas qui fond que forward et backward ça ne peut dans certains cas ne pas marcher Après une des solutions que j'avais pas envisager à l'époque c'est d'utiliser opposite la notion de direction peut être mentionné avec un angle en degré en partant du nord à 0 L'angle permet de définir la direction de la face visible Le lun. 10 févr. 2020 à 01:48, Philippe Verdy a écrit : > Quasiment toutes les communes ont au moins une agglomération (sauf les > rares communes sans habitants). le mot "agglomération" au sens des panneaux > EB10 et EB20 existe donc aussi en milieu rural (autant que de villages dans > la commune, mais même en milieu rural on a des villages à cheval sur plus > d'une commune, le plus souvent autour d'un pont sur une rivière frontière, > ou autour d'un carrefour avec une des routes faisant frontière: c'est ce > carrefour, ce pont, et l'activité qui s'est développée autour qui a conduit > à ces villages multicommunes, au départ peut-être juste un corps de ferme > ou une usine, ensuite les dépendances, habitations ou commerces qui se sont > ajoutés, justement du fait de la facilité d'accès et du passage local > important). > > "Agglomération" ne signifie pas grande ville : même un hameau de moins de > 100 âmes peut être une agglomération formant un ilôt urbanisé dans la > commune rurale. Un très grand nombre de communes rurales ont plusieurs > agglomérations, une d'elle étant le "bourg" centre et ayant donné son nom à > la commune, mais pas toujours (une agglo excentrée peut être aujourd'hui > plus peuplée et plus dense que le bourg centre historique, notamment en > frontière d'une autre commune voisine beaucoup plus urbanisée et ayant > étendu son agglomération sur la commune rurale voisine). > > "Agglomération" ne signifie donc pas non plus "commune". > > > Le dim. 9 févr. 2020 à 22:59, onesime31 a écrit : > >> Bonsoir, >> Merci pour votre réponse. >> Ce serait pour un département rural qui n'a pas d'agglomération... donc >> je parlais surtout des panneaux des entrées de village, et de quelques >> villes. >> >> Bonne soirée >> >> >> >> ---- Message d'origine ---- >> De : Philippe Verdy >> Date : 09/02/2020 15:53 (GMT+01:00) >> À : Discussions sur OSM en français >> Objet : Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de >> villes & villages >> >> Un ennui : l'entrée d'une commune et la sortie d'une autre peuvent être >> au même emplacement (même poteau support) dans le cas d'une frontière >> communale au sein d'une même agglomération. >> Ce qui a été déjà fait dans certaines agglomération pour les distinguer >> c'est de créer des boundary=urban, passant par ces panneaux indicateurs. >> >> Mais "boundary=urban" ne traite pas encore ces cas de frontières >> communales intra-agglomération où c'est la frontière communale >> (boundary=administrative et admin_level<=8) qui tient lieu de limite. Et il >> reste aussi des cas de frontières au sein des communes nouvelles (ou >> associations de communes), entre les communes déléguées ou associées >> (admin_level=9), où la toponymie de chaque commune déléguée (ou associée) >> est conservée (même si les panneaux annotent en dessous et plus petits >> caractères "(Commune de )". >> >> Le "boundary=urban" est surtout destiné à limiter les frontières >> d'agglomération pour la régulation routière: le tracé des contours reste >> approximatif (pas exactement sur les limites de propriétés) mais passe par >> des points précis sur les voies publiques où ces panneaux limites >> d'agglomération sont posés. >> >> En principe il y a des panneaux de chaque côté de la voie mais ils ne >> sont pas toujours en vis-à-vis (par exemple quand l'entrée ou la sortie >> d'agglomération se fait par des voies séparées comme des bretelles de >> ronds-points ou par un séparateur de chaussée visant aussi à renforcer la >> limite de vitesse, ou des bretelles d'accès de r
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
Quasiment toutes les communes ont au moins une agglomération (sauf les rares communes sans habitants). le mot "agglomération" au sens des panneaux EB10 et EB20 existe donc aussi en milieu rural (autant que de villages dans la commune, mais même en milieu rural on a des villages à cheval sur plus d'une commune, le plus souvent autour d'un pont sur une rivière frontière, ou autour d'un carrefour avec une des routes faisant frontière: c'est ce carrefour, ce pont, et l'activité qui s'est développée autour qui a conduit à ces villages multicommunes, au départ peut-être juste un corps de ferme ou une usine, ensuite les dépendances, habitations ou commerces qui se sont ajoutés, justement du fait de la facilité d'accès et du passage local important). "Agglomération" ne signifie pas grande ville : même un hameau de moins de 100 âmes peut être une agglomération formant un ilôt urbanisé dans la commune rurale. Un très grand nombre de communes rurales ont plusieurs agglomérations, une d'elle étant le "bourg" centre et ayant donné son nom à la commune, mais pas toujours (une agglo excentrée peut être aujourd'hui plus peuplée et plus dense que le bourg centre historique, notamment en frontière d'une autre commune voisine beaucoup plus urbanisée et ayant étendu son agglomération sur la commune rurale voisine). "Agglomération" ne signifie donc pas non plus "commune". Le dim. 9 févr. 2020 à 22:59, onesime31 a écrit : > Bonsoir, > Merci pour votre réponse. > Ce serait pour un département rural qui n'a pas d'agglomération... donc je > parlais surtout des panneaux des entrées de village, et de quelques villes. > > Bonne soirée > > > > Message d'origine > De : Philippe Verdy > Date : 09/02/2020 15:53 (GMT+01:00) > À : Discussions sur OSM en français > Objet : Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de > villes & villages > > Un ennui : l'entrée d'une commune et la sortie d'une autre peuvent être au > même emplacement (même poteau support) dans le cas d'une frontière > communale au sein d'une même agglomération. > Ce qui a été déjà fait dans certaines agglomération pour les distinguer > c'est de créer des boundary=urban, passant par ces panneaux indicateurs. > > Mais "boundary=urban" ne traite pas encore ces cas de frontières > communales intra-agglomération où c'est la frontière communale > (boundary=administrative et admin_level<=8) qui tient lieu de limite. Et il > reste aussi des cas de frontières au sein des communes nouvelles (ou > associations de communes), entre les communes déléguées ou associées > (admin_level=9), où la toponymie de chaque commune déléguée (ou associée) > est conservée (même si les panneaux annotent en dessous et plus petits > caractères "(Commune de )". > > Le "boundary=urban" est surtout destiné à limiter les frontières > d'agglomération pour la régulation routière: le tracé des contours reste > approximatif (pas exactement sur les limites de propriétés) mais passe par > des points précis sur les voies publiques où ces panneaux limites > d'agglomération sont posés. > > En principe il y a des panneaux de chaque côté de la voie mais ils ne sont > pas toujours en vis-à-vis (par exemple quand l'entrée ou la sortie > d'agglomération se fait par des voies séparées comme des bretelles de > ronds-points ou par un séparateur de chaussée visant aussi à renforcer la > limite de vitesse, ou des bretelles d'accès de routes express, ou quand il > y a des feux dans un seul sens, ou quand la partie habitée commence d'un > seul côté, l'autre étant encore agricole ou forestier (et hors zone > constructible selon les PLU en vigueur). > > Délimiter les agglomérations peut avoir plusieurs significations: > * celle de l'INSEE se base sur des distances minimales entre bâtis (50 > mètres?), et permet à l'INSEE de définir les secteurs de populations > urbaines ou rurales, ces frontières du découpage urbain du territoire aux > fins statistiques sont évolutives. > * celle décidée par les communes qui décident de mettre en place des > limitations vitesse, et accéder aux demandes des "riverains" (peu importe > la définition de l'INSEE, la commune peut considérer d'autres facteurs > comme la présence de parcs de loisirs ou terrrains de sports ou des > équipements publics comme un cimetière communal, ou certaines autres > activités de loisir ou touristiques, même si elles ne sont pas habitées, ou > simplement une activité commerciale ou industrielle attirant de nombreux > piétons): la limitation de vitesse "urbaine" n'est pas la même définition > que .l'INSEE. > > On n'a pas de distinction des deux types de découpage urbain (statistique > de l'INSEE, ou routier au sens du code de la route et
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
Le dim. 9 févr. 2020 à 23:07, onesime31 a écrit : > Bonsoir, > > Ce n'est pas taguer 2 fois le même feature, vu qu'ils sont distingués par > leur code eb20 ou eb10 qui sont des standards en France. > > Pour le forward ou backward, comment différenciez vous le sens? > C'était expliqué: si tu poses le noeud sur le way, c'est selon le sens de tracé du way "highway=*"; (cependant ces panneaux sont plutôt à côté du way et sur un côté spécifique, il pourrait théoriquement y en avoir suspendus au dessus s'il y a un portique ou si c'est situé sur le tablier d'un pont, ou au dessus de l'entrée d'un tunnel). C'est comme les emplacements d'arrêts de bus, ou les "highway=giveway" et "stop" qui ont aussi une "direction=forward/backward" selon le sens du tracé, et aussi "oneway=yes" qui indique que le sens unique est dans le sens du tracé et "oneway=-1" quand le sens unique est dans le sens opposé. Ce qui me chagrine c'est qu'on peut avoir une entrée et sortie de commune au même endroit et dans le même sens, donc concurrence des panneaux EB10 et EB20 pour le même sens forward ou backward. Si on place le panneau à coté de la route, là où il est réellement et qu'on veut taguer son support (y compris son piétement au sol si on veut distinguer les bases béton, mais ce panneau pourrait aussi être sur le support d'un luminaire ou d'un feu de circulation, ou contre un mur de bâtiment ou de clôture le long de la voie, même d'un bâtiment privé, pour ne pas empiéter un trottoir peu large), alors plus moyen de distinguer forward/backward, et la solution des relations boundary=urban résoud le problème car les noeuds de panneaux peuvent être placé hors de la voie de circulation. Ce problème de placement vient quand on veut faire du mapping plus fin avec plus de détails. Ça et là dans certaines communes déjà bien avancées mais denses, on commence à voir les trottoirs, les barrières et plots de protection, les luminaires, les équipements publics, et l'emplacement exact des panneaux constituent aussi des obstacles pour les piétons et notamment le déplacement en fauteuil sur des trottoirs peu larges (raison pour laquelle, les panneaux peuvent alors être placés sur les murs, ou fixés un peu plus en hauteur et accrochés par un portique au mur pour laisser le trottoir libre (cela concerne surtout les limites de communes dans la même agglomération urbaine; aux limites urbain/rural, il y a normalement de la place et on peut presque toujours trouver un emplacement correct un peu avant ou après l'entrée/sortie d'agglomération laissant un espace libre suffisant et n'entravant pas la circulation des véhicules. J'ai aussi vu des panneaux aussi fixés au tronc d'un arbre (ou sur sa barrière de protection), et sur des piliers de ponts (mieux placés là que suspendus au tablier trop haut ou mal orientés quand il y a un virage juste avant le franchissement sous le pont. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
Bonsoir, Ce n'est pas taguer 2 fois le même feature, vu qu'ils sont distingués par leur code eb20 ou eb10 qui sont des standards en France. Pour le forward ou backward, comment différenciez vous le sens? !Encore une fois, c'est un département rural, et ce sont majoritairement des villages, traversés par une simple voie à double sens, sans marquage au sol.Bonne soirée Message d'origine De : Florimond Berthoux Date : 09/02/2020 21:06 (GMT+01:00) À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages Bonsoir,Non il ne faut pas tagguer deux fois la même feature (bonjour la cohérence des données et la maintenance).Si on veut être sympa pour le routeur on met le nœud sur le way de la route avec:traffic_sign:forward=city_limittraffic_sign:backward=city_limità la hauteur du panneau de début ou de fin d'agglomération.Attention le forward et le backward se réfère au sens du way dans le quel le panneau est lu.https://wiki.openstreetmap.org/wiki/FR:Key:traffic_sign#Sur_un_way_ou_une_zone_.28area.29Le dim. 9 févr. 2020 à 17:38, David Marchal a écrit : > Le 9 févr. 2020 à 13:43, onesime31 a écrit : > > > Bonjour, Bonsoir. > > Nous avons un projet avec une classe de géomaticiens en formation. > On a une commande et on aimerait faire cela en utilisant OSM, faire une > cartoparty dans le cadre de leur formation. La commande est de cartographier > les entrées et sorties de villes et villages. > > Pour le panneau d'entrée de village, voici le key et le value qu'on pensait > utiliser: traffic_sign=city_limit > à priori, il n'y a pas possibilité de préciser si c'est le panneau d'entrée > ou de sortie du village? > On peut les distinguer via le code EB10 et EB20... est ce une bonne manière > de référencer comme cela: > - traffic_sign=city_limit > - traffic_sign=FR:EB20 > ? À mon avis, il vaudrait mieux garder la convention de mettre un nœud traffic_sign=city_limit sur la route, à l’endroit où le panneau est placé, car ça permet aux utilisateurs des données de savoir, par exemple, à partir de quel point les règles de circulation en agglomération s’appliquent. En revanche, ça n’empêche pas de placer un autre nœud traffic_sign=FR:EB20 à l’emplacement précis du panneau, et sans lien avec la route. Faire les deux fait plus de travail, mais au moins tout le monde est content. -- Florimond Berthoux ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
Bonsoir, C'est ce qu'il me semble le plus cohérent. Et en effet noter les 2 panneaux Par contre, il me reste à voir pour les plots béton. Bonne soirée Message d'origine De : David Marchal Date : 09/02/2020 17:40 (GMT+01:00) À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages > Le 9 févr. 2020 à 13:43, onesime31 a écrit :> > > Bonjour,Bonsoir.> > Nous avons un projet avec une classe de géomaticiens en formation.> On a une commande et on aimerait faire cela en utilisant OSM, faire une cartoparty dans le cadre de leur formation. La commande est de cartographier les entrées et sorties de villes et villages.> > Pour le panneau d'entrée de village, voici le key et le value qu'on pensait utiliser: traffic_sign=city_limit > à priori, il n'y a pas possibilité de préciser si c'est le panneau d'entrée ou de sortie du village? > On peut les distinguer via le code EB10 et EB20... est ce une bonne manière de référencer comme cela:> - traffic_sign=city_limit> - traffic_sign=FR:EB20> ?À mon avis, il vaudrait mieux garder la convention de mettre un nœud traffic_sign=city_limit sur la route, à l’endroit où le panneau est placé, car ça permet aux utilisateurs des données de savoir, par exemple, à partir de quel point les règles de circulation en agglomération s’appliquent. En revanche, ça n’empêche pas de placer un autre nœud traffic_sign=FR:EB20 à l’emplacement précis du panneau, et sans lien avec la route. Faire les deux fait plus de travail, mais au moins tout le monde est content.> Il nous faudrait également indiquer s'ils sont zérophyto: c'est à dire que les poteaux de ces panneaux aient un dé ou une dalle béton au pied (et qu'on utilise pas de pesticide pour enlever l'herbe au pied de ceux-ci).> Pour la fixation du panneau, on pensait utiliser le key "support" puis les value suivant pour les distinguer:> - support= post quand le panneau est simplement planté (donc pas zerophyto)> - support = pole si le panneau est scellé au sol (= zerophyto pour nous)> Existe t-il une autre manière de tagger s'il y a un dé, ou une dalle béton au pied du panneau?> > L'idée serait de travailler sur OSM, et de faire une extraction pour répondre à la commande qui nous est faite.> > Si vous avez des conseils, précisions, ressources, etc. n'hésitez pas.> > Bonne soirée, Onésime.Cordialement.___Talk-fr mailing listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
Bonsoir, Merci pour votre réponse. Ce serait pour un département rural qui n'a pas d'agglomération... donc je parlais surtout des panneaux des entrées de village, et de quelques villes. Bonne soirée Message d'origine De : Philippe Verdy Date : 09/02/2020 15:53 (GMT+01:00) À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages Un ennui : l'entrée d'une commune et la sortie d'une autre peuvent être au même emplacement (même poteau support) dans le cas d'une frontière communale au sein d'une même agglomération.Ce qui a été déjà fait dans certaines agglomération pour les distinguer c'est de créer des boundary=urban, passant par ces panneaux indicateurs.Mais "boundary=urban" ne traite pas encore ces cas de frontières communales intra-agglomération où c'est la frontière communale (boundary=administrative et admin_level<=8) qui tient lieu de limite. Et il reste aussi des cas de frontières au sein des communes nouvelles (ou associations de communes), entre les communes déléguées ou associées (admin_level=9), où la toponymie de chaque commune déléguée (ou associée) est conservée (même si les panneaux annotent en dessous et plus petits caractères "(Commune de )".Le "boundary=urban" est surtout destiné à limiter les frontières d'agglomération pour la régulation routière: le tracé des contours reste approximatif (pas exactement sur les limites de propriétés) mais passe par des points précis sur les voies publiques où ces panneaux limites d'agglomération sont posés.En principe il y a des panneaux de chaque côté de la voie mais ils ne sont pas toujours en vis-à-vis (par exemple quand l'entrée ou la sortie d'agglomération se fait par des voies séparées comme des bretelles de ronds-points ou par un séparateur de chaussée visant aussi à renforcer la limite de vitesse, ou des bretelles d'accès de routes express, ou quand il y a des feux dans un seul sens, ou quand la partie habitée commence d'un seul côté, l'autre étant encore agricole ou forestier (et hors zone constructible selon les PLU en vigueur).Délimiter les agglomérations peut avoir plusieurs significations:* celle de l'INSEE se base sur des distances minimales entre bâtis (50 mètres?), et permet à l'INSEE de définir les secteurs de populations urbaines ou rurales, ces frontières du découpage urbain du territoire aux fins statistiques sont évolutives.* celle décidée par les communes qui décident de mettre en place des limitations vitesse, et accéder aux demandes des "riverains" (peu importe la définition de l'INSEE, la commune peut considérer d'autres facteurs comme la présence de parcs de loisirs ou terrrains de sports ou des équipements publics comme un cimetière communal, ou certaines autres activités de loisir ou touristiques, même si elles ne sont pas habitées, ou simplement une activité commerciale ou industrielle attirant de nombreux piétons): la limitation de vitesse "urbaine" n'est pas la même définition que .l'INSEE.On n'a pas de distinction des deux types de découpage urbain (statistique de l'INSEE, ou routier au sens du code de la route et de la réglementation communale/préfectorale et des panneaux EB10 et EB20, qui ne sont pas disposés partout sur toutes les voies résidentielles "mineures" ni sur les voies privées).Le dim. 9 févr. 2020 à 13:44, onesime31 a écrit :Bonjour,Nous avons un projet avec une classe de géomaticiens en formation.On a une commande et on aimerait faire cela en utilisant OSM, faire une cartoparty dans le cadre de leur formation. La commande est de cartographier les entrées et sorties de villes et villages. Pour le panneau d'entrée de village, voici le key et le value qu'on pensait utiliser: traffic_sign=city_limit à priori, il n'y a pas possibilité de préciser si c'est le panneau d'entrée ou de sortie du village? On peut les distinguer via le code EB10 et EB20... est ce une bonne manière de référencer comme cela:- traffic_sign=city_limit- traffic_sign=FR:EB20?Il nous faudrait également indiquer s'ils sont zérophyto: c'est à dire que les poteaux de ces panneaux aient un dé ou une dalle béton au pied (et qu'on utilise pas de pesticide pour enlever l'herbe au pied de ceux-ci).Pour la fixation du panneau, on pensait utiliser le key "support" puis les value suivant pour les distinguer:- support= post quand le panneau est simplement planté (donc pas zerophyto)- support = pole si le panneau est scellé au sol (= zerophyto pour nous)Existe t-il une autre manière de tagger s'il y a un dé, ou une dalle béton au pied du panneau?L'idée serait de travailler sur OSM, et de faire une extraction pour répondre à la commande qui nous est faite.Si vous avez des conseils, précisions, ressources, etc. n'hésitez pas.Bonne soirée, Onésime.___ Talk-fr mailing li
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
Bonsoir, Non il ne faut pas tagguer deux fois la même feature (bonjour la cohérence des données et la maintenance). Si on veut être sympa pour le routeur on met le nœud sur le way de la route avec: traffic_sign:forward=city_limit traffic_sign:backward=city_limit à la hauteur du panneau de début ou de fin d'agglomération. Attention le forward et le backward se réfère au sens du way dans le quel le panneau est lu. https://wiki.openstreetmap.org/wiki/FR:Key:traffic_sign#Sur_un_way_ou_une_zone_.28area.29 Le dim. 9 févr. 2020 à 17:38, David Marchal a écrit : > > > > Le 9 févr. 2020 à 13:43, onesime31 a écrit : > > > > > > Bonjour, > Bonsoir. > > > > > Nous avons un projet avec une classe de géomaticiens en formation. > > On a une commande et on aimerait faire cela en utilisant OSM, faire une > cartoparty dans le cadre de leur formation. La commande est de > cartographier les entrées et sorties de villes et villages. > > > > Pour le panneau d'entrée de village, voici le key et le value qu'on > pensait utiliser: traffic_sign=city_limit > > à priori, il n'y a pas possibilité de préciser si c'est le panneau > d'entrée ou de sortie du village? > > On peut les distinguer via le code EB10 et EB20... est ce une bonne > manière de référencer comme cela: > > - traffic_sign=city_limit > > - traffic_sign=FR:EB20 > > ? > À mon avis, il vaudrait mieux garder la convention de mettre un nœud > traffic_sign=city_limit sur la route, à l’endroit où le panneau est placé, > car ça permet aux utilisateurs des données de savoir, par exemple, à partir > de quel point les règles de circulation en agglomération s’appliquent. En > revanche, ça n’empêche pas de placer un autre nœud traffic_sign=FR:EB20 à > l’emplacement précis du panneau, et sans lien avec la route. Faire les deux > fait plus de travail, mais au moins tout le monde est content. > -- Florimond Berthoux ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
> Le 9 févr. 2020 à 13:43, onesime31 a écrit : > > > Bonjour, Bonsoir. > > Nous avons un projet avec une classe de géomaticiens en formation. > On a une commande et on aimerait faire cela en utilisant OSM, faire une > cartoparty dans le cadre de leur formation. La commande est de cartographier > les entrées et sorties de villes et villages. > > Pour le panneau d'entrée de village, voici le key et le value qu'on pensait > utiliser: traffic_sign=city_limit > à priori, il n'y a pas possibilité de préciser si c'est le panneau d'entrée > ou de sortie du village? > On peut les distinguer via le code EB10 et EB20... est ce une bonne manière > de référencer comme cela: > - traffic_sign=city_limit > - traffic_sign=FR:EB20 > ? À mon avis, il vaudrait mieux garder la convention de mettre un nœud traffic_sign=city_limit sur la route, à l’endroit où le panneau est placé, car ça permet aux utilisateurs des données de savoir, par exemple, à partir de quel point les règles de circulation en agglomération s’appliquent. En revanche, ça n’empêche pas de placer un autre nœud traffic_sign=FR:EB20 à l’emplacement précis du panneau, et sans lien avec la route. Faire les deux fait plus de travail, mais au moins tout le monde est content. > Il nous faudrait également indiquer s'ils sont zérophyto: c'est à dire que > les poteaux de ces panneaux aient un dé ou une dalle béton au pied (et qu'on > utilise pas de pesticide pour enlever l'herbe au pied de ceux-ci). > Pour la fixation du panneau, on pensait utiliser le key "support" puis les > value suivant pour les distinguer: > - support= post quand le panneau est simplement planté (donc pas zerophyto) > - support = pole si le panneau est scellé au sol (= zerophyto pour nous) > Existe t-il une autre manière de tagger s'il y a un dé, ou une dalle béton au > pied du panneau? > > L'idée serait de travailler sur OSM, et de faire une extraction pour répondre > à la commande qui nous est faite. > > Si vous avez des conseils, précisions, ressources, etc. n'hésitez pas. > > Bonne soirée, Onésime. Cordialement. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages
Un ennui : l'entrée d'une commune et la sortie d'une autre peuvent être au même emplacement (même poteau support) dans le cas d'une frontière communale au sein d'une même agglomération. Ce qui a été déjà fait dans certaines agglomération pour les distinguer c'est de créer des boundary=urban, passant par ces panneaux indicateurs. Mais "boundary=urban" ne traite pas encore ces cas de frontières communales intra-agglomération où c'est la frontière communale (boundary=administrative et admin_level<=8) qui tient lieu de limite. Et il reste aussi des cas de frontières au sein des communes nouvelles (ou associations de communes), entre les communes déléguées ou associées (admin_level=9), où la toponymie de chaque commune déléguée (ou associée) est conservée (même si les panneaux annotent en dessous et plus petits caractères "(Commune de )". Le "boundary=urban" est surtout destiné à limiter les frontières d'agglomération pour la régulation routière: le tracé des contours reste approximatif (pas exactement sur les limites de propriétés) mais passe par des points précis sur les voies publiques où ces panneaux limites d'agglomération sont posés. En principe il y a des panneaux de chaque côté de la voie mais ils ne sont pas toujours en vis-à-vis (par exemple quand l'entrée ou la sortie d'agglomération se fait par des voies séparées comme des bretelles de ronds-points ou par un séparateur de chaussée visant aussi à renforcer la limite de vitesse, ou des bretelles d'accès de routes express, ou quand il y a des feux dans un seul sens, ou quand la partie habitée commence d'un seul côté, l'autre étant encore agricole ou forestier (et hors zone constructible selon les PLU en vigueur). Délimiter les agglomérations peut avoir plusieurs significations: * celle de l'INSEE se base sur des distances minimales entre bâtis (50 mètres?), et permet à l'INSEE de définir les secteurs de populations urbaines ou rurales, ces frontières du découpage urbain du territoire aux fins statistiques sont évolutives. * celle décidée par les communes qui décident de mettre en place des limitations vitesse, et accéder aux demandes des "riverains" (peu importe la définition de l'INSEE, la commune peut considérer d'autres facteurs comme la présence de parcs de loisirs ou terrrains de sports ou des équipements publics comme un cimetière communal, ou certaines autres activités de loisir ou touristiques, même si elles ne sont pas habitées, ou simplement une activité commerciale ou industrielle attirant de nombreux piétons): la limitation de vitesse "urbaine" n'est pas la même définition que .l'INSEE. On n'a pas de distinction des deux types de découpage urbain (statistique de l'INSEE, ou routier au sens du code de la route et de la réglementation communale/préfectorale et des panneaux EB10 et EB20, qui ne sont pas disposés partout sur toutes les voies résidentielles "mineures" ni sur les voies privées). Le dim. 9 févr. 2020 à 13:44, onesime31 a écrit : > > Bonjour, > > Nous avons un projet avec une classe de géomaticiens en formation. > On a une commande et on aimerait faire cela en utilisant OSM, faire une > cartoparty dans le cadre de leur formation. La commande est de > cartographier les entrées et sorties de villes et villages. > > Pour le panneau d'entrée de village, voici le key et le value qu'on > pensait utiliser: traffic_sign=city_limit > à priori, il n'y a pas possibilité de préciser si c'est le panneau > d'entrée ou de sortie du village? > On peut les distinguer via le code EB10 et EB20... est ce une bonne > manière de référencer comme cela: > - traffic_sign=city_limit > - traffic_sign=FR:EB20 > ? > > Il nous faudrait également indiquer s'ils sont zérophyto: c'est à dire que > les poteaux de ces panneaux aient un dé ou une dalle béton au pied (et > qu'on utilise pas de pesticide pour enlever l'herbe au pied de ceux-ci). > Pour la fixation du panneau, on pensait utiliser le key "support" puis les > value suivant pour les distinguer: > - support= post quand le panneau est simplement planté (donc pas zerophyto) > - support = pole si le panneau est scellé au sol (= zerophyto pour nous) > Existe t-il une autre manière de tagger s'il y a un dé, ou une dalle béton > au pied du panneau? > > L'idée serait de travailler sur OSM, et de faire une extraction pour > répondre à la commande qui nous est faite. > > Si vous avez des conseils, précisions, ressources, etc. n'hésitez pas. > > Bonne soirée, Onésime. > ___ > 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] Tagger correctement les panneaux entrées de villes & villages
Bonjour,Nous avons un projet avec une classe de géomaticiens en formation.On a une commande et on aimerait faire cela en utilisant OSM, faire une cartoparty dans le cadre de leur formation. La commande est de cartographier les entrées et sorties de villes et villages. Pour le panneau d'entrée de village, voici le key et le value qu'on pensait utiliser: traffic_sign=city_limit à priori, il n'y a pas possibilité de préciser si c'est le panneau d'entrée ou de sortie du village? On peut les distinguer via le code EB10 et EB20... est ce une bonne manière de référencer comme cela:- traffic_sign=city_limit- traffic_sign=FR:EB20?Il nous faudrait également indiquer s'ils sont zérophyto: c'est à dire que les poteaux de ces panneaux aient un dé ou une dalle béton au pied (et qu'on utilise pas de pesticide pour enlever l'herbe au pied de ceux-ci).Pour la fixation du panneau, on pensait utiliser le key "support" puis les value suivant pour les distinguer:- support= post quand le panneau est simplement planté (donc pas zerophyto)- support = pole si le panneau est scellé au sol (= zerophyto pour nous)Existe t-il une autre manière de tagger s'il y a un dé, ou une dalle béton au pied du panneau?L'idée serait de travailler sur OSM, et de faire une extraction pour répondre à la commande qui nous est faite.Si vous avez des conseils, précisions, ressources, etc. n'hésitez pas.Bonne soirée, Onésime.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
