from:"Éric Gillet"

Le 15/11/2020 à 17:21, Jérôme Amagat a écrit :

Le dim. 15 nov. 2020 à 11:04, Éric Gillet <mailto:e%2btalkfr2...@linuxw.info>> a écrit :

Le 15/11/2020 à 00:57, Jérôme Amagat a écrit :

Le sam. 14 nov. 2020 à 21:01, Éric Gillet
mailto:e%2btalkfr2...@linuxw.info>> a
écrit :

Le 13/11/2020 à 22:09, David Faure via Talk-fr a écrit :
> On vendredi 13 novembre 2020 18:23:11 CET Éric Gillet wrote:
>> Le 12/11/2020 à 10:02, David Faure via Talk-fr a écrit :
>>>> Et il faut garder les anciennes sources (sauf les
anciennes versions de
>>>> ce que tu importes).
>>>>
>>>> Typiquement tu auras des source
>>>> source=LaPoste -03/2019 dus aux ref:FR:LaPoste
>>>>
>>>> Il ne fallait pas supprimer la source du bâti (par exemple).
>>> Ah, j'avais mal lu le wiki. Source sur un object c'est
historique mais il
>>> ne faut pas effacer. Je croyais avoir lu le contraire (et
aussi Éric
>>> disait qu'il fallait effacer, cf mail de mardi). Pas de
problème, j'y
>>> touche pas.
>> Je penses que la phrase du wiki "so don't go around
deleting those
>> source tags"/"ne vous précipitez pas pour supprimer ces
balises sources"
>> c'est pour éviter que des contributeurs
suppriment/modifient en masse
>> "uniquement" un tag.
> Ah, en effet, c'est ce que j'avais lu en premier, et qui
m'avait fait implémenter ça.
>
> Mais depuis j'ai vu
> "Comme celui-ci n'est pas officiellement obsolète, ne
commencez pas à supprimer ces marques avant qu'une décision
générale du projet décide de le faire."
>

https://wiki.openstreetmap.org/wiki/FR:Key:source#Usage_historique_sur_les_objets_et_les_attributs
>
> Et pareil dans la version anglophone, " As usual don't
start deleting those tags unless and until there is a general
project decision to do so. "
>
>> [...]
>> La source précédente (celle existante sur l'objet) n'est
pas perdue,
>> elle est stockée dans l'historique de l'objet. Tout comme
le tag
>> source=* que tu apposes aux changesets.
> Je suis d'accord avec ton raisonnement. Mais je suis
nouveau, je vais pas aller
> supprimer un attribut si le wiki dit "c'est pas encore
vraiment décidé au niveau du projet".

Si tu ne supprimes par le tag existant il y aura donc 2
sources sur les
horaires :

- data.gouv.fr:LaPoste - 04/2012 (par exemple)

La source LaPoste dans le tag source=* ce n'est pas
obligatoirement pour les horaires, il y a même de grandes chances
que ce soit la source de la position du bureau de poste donc pas
de raison de le supprimer si l'on ne change que l'horaire sans
déplacer le bureau de poste. Et supprimer la source quand c'est
"cadastre", c'est la source de la géométrie du bâtiment, il y
a surement beaucoup d'autre source=* différentes, qui peuvent
être la source de la position du bureau de poste, du nom du
bureau, , du nombre d'étages du bâtiment, de la couleur de
ses murs..., de n'importe quel tag sur l'objet ou n'importe quel
élément de sa géométrie.

Justement on ne peut pas savoir à quoi s'applique le tag source en
le laissant. Le laisser lorsqu'on fait des modifs ça veut dire
qu'il s'applique également à la version courante de l'objet, alors
que c'est pas le cas vu qu'il y a plusieurs autres ajouts avec des
sources différentes.

Les bibliographies à la fin de texte donnent la liste des sources 
utilisées pour réaliser le texte mais chaque source n'a pas servi à 
faire tout le texte et on sait rarement quelle source a servi à faire 
quoi. Là c'est pareil, ce qu'il y a dans source=* a servi à un moment 
donné à ajouter une ou plusieurs infos présentes sur l'objet mais pas 
moyen sans recherche de savoir la ou lesquelles.
OSM c'est une base de données, pas un texte lu par un humain. On sait 
apposer les sources à chaque modification, ça ne me paraît pas comparable.

En modifiant le tag opening_hours=*, seule la source dans
source:opening_hours=* peut être modifiée ou supprimée.

Elle n'est pas supprimée, elle devient non visible dans la version
actuelle de l'objet. Elle est présente dans l'historique, tout
comme les tags source dans les changesets, qui sont la façon
retenue par la majorité des modifications dans OpenStreetMap.

La majorité des modifications dans osm utilise encore source=*. Osmose 
ajoute sou

Re: [OSM-talk-fr] Suppression de l'attribut source (Re: Import des horaires des bureaux de poste)


Le 15/11/2020 à 12:25, David Faure via Talk-fr a écrit :

On dimanche 15 novembre 2020 11:10:10 CET Éric Gillet wrote:

Eric, la modification de wiki nécessaire à ceci (celle à laquelle je
pensais en fait) c'est la suppression de "it seems the historic practice
of tagging objects or individual attributes has not been officially
deprecated yet". Le jour où c'est vraiment déprécié, alors pas de
problème pour supprimer, mais clairement ce n'est pas l'avis de tout le
monde.

Pas besoin de déprécier dans ton cas, il n'y a pas d'autres solution que
de l'enlever pour faire une modification avec une source différente.

Si tu le laisse, on peut pas savoir à quoi s'applique la source qui est
sur l'objet et celle qui est dans ton script, à moins de lire son code
source pour voir ce qu'il vérifie/modifie comme attribut (et faut faire
pareil pour chacune des version des objets OSM).



Quand j'ai renseigné les horaires d'ouverture d'un bureau de Poste avec
l'application StreetComplete (ce qui m'a donné l'idée de ce projet), est-ce
que StreetComplete a supprimé l'attribut source du bureau de Poste ?
Non, je confirme que ce n'est pas le cas.
https://www.openstreetmap.org/api/0.6/changeset/92125368/download

Non et c'est une erreur en effet pour les raisons détaillées au dessus.
StreetComplete ajoute aussi des adresses en doublon, alors que c'est une 
erreur Osmose (et JOSM je crois) d'avoir des adresses en double. 
Pourtant il le fait.

Je suis d'accord avec toi sur le fond. Mais clairement la communauté OSM n'est
pas (encore) de cet avis là.


Tous les éditeurs ont migré vers les tags de changeset pour indiquer la 
source, "la communauté" est donc à priori de cet avis.


Si je comprends bien tu es d'accord avec les problèmes que ça engendre, 
que la solution que je propose est la bonne mais ne va pas l'appliquer.
Désolé de t'avoir fait perdre du temps, je te souhaite bonne 
continuation pour ton import !



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

Re: [OSM-talk-fr] Suppression de l'attribut source (Re: Import des horaires des bureaux de poste)


Le 15/11/2020 à 00:57, Jérôme Amagat a écrit :



Le sam. 14 nov. 2020 à 21:01, Éric Gillet <mailto:e%2btalkfr2...@linuxw.info>> a écrit :


Le 13/11/2020 à 22:09, David Faure via Talk-fr a écrit :
> On vendredi 13 novembre 2020 18:23:11 CET Éric Gillet wrote:
>> Le 12/11/2020 à 10:02, David Faure via Talk-fr a écrit :
>>>> Et il faut garder les anciennes sources (sauf les anciennes
versions de
>>>> ce que tu importes).
>>>>
>>>> Typiquement tu auras des source
>>>> source=LaPoste -03/2019 dus aux ref:FR:LaPoste
>>>>
>>>> Il ne fallait pas supprimer la source du bâti (par exemple).
>>> Ah, j'avais mal lu le wiki. Source sur un object c'est
historique mais il
>>> ne faut pas effacer. Je croyais avoir lu le contraire (et
aussi Éric
>>> disait qu'il fallait effacer, cf mail de mardi). Pas de
problème, j'y
>>> touche pas.
>> Je penses que la phrase du wiki "so don't go around deleting those
>> source tags"/"ne vous précipitez pas pour supprimer ces balises
sources"
>> c'est pour éviter que des contributeurs suppriment/modifient en
masse
>> "uniquement" un tag.
> Ah, en effet, c'est ce que j'avais lu en premier, et qui m'avait
fait implémenter ça.
>
> Mais depuis j'ai vu
> "Comme celui-ci n'est pas officiellement obsolète, ne commencez
pas à supprimer ces marques avant qu'une décision générale du
projet décide de le faire."
>

https://wiki.openstreetmap.org/wiki/FR:Key:source#Usage_historique_sur_les_objets_et_les_attributs
>
> Et pareil dans la version anglophone, " As usual don't start
deleting those tags unless and until there is a general project
decision to do so. "
>
>> [...]
>> La source précédente (celle existante sur l'objet) n'est pas
perdue,
>> elle est stockée dans l'historique de l'objet. Tout comme le tag
>> source=* que tu apposes aux changesets.
> Je suis d'accord avec ton raisonnement. Mais je suis nouveau, je
vais pas aller
> supprimer un attribut si le wiki dit "c'est pas encore vraiment
décidé au niveau du projet".

Si tu ne supprimes par le tag existant il y aura donc 2 sources
sur les
horaires :

- data.gouv.fr:LaPoste - 04/2012 (par exemple)

[...]
En modifiant le tag opening_hours=*, seule la source dans 
source:opening_hours=* peut être modifiée ou supprimée.


Tu as entièrement raison ! Du coup comment faire quand quelqu'un a mis 
source=* ? Il est sans suffixe donc s'applique à toutes les données de 
l'objet : position, tags, membres (dans le cas d'une way ou relation).


Il n'y a pas d'autre solution que de la supprimer et d'utiliser soit les 
tags de changesets (façon utilisée par la grande majorité des éditeurs), 
soit des tags source:* suffixés pour les prochaines modifs.


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

Re: [OSM-talk-fr] Suppression de l'attribut source (Re: Import des horaires des bureaux de poste)


Le 15/11/2020 à 10:32, David Faure via Talk-fr a écrit :

On dimanche 15 novembre 2020 00:57:22 CET Jérôme Amagat wrote:

En modifiant le tag opening_hours=*, seule la source dans
source:opening_hours=* peut être modifiée ou supprimée.

Sauf qu'on a dit que je ne modifiais pas le tag opening_hours s'il était déjà
là, donc je ne touche pas non plus à source:opening_hours...

Bon, je constate un manque évident de consensus sur la suppression de
l'attribut source, et je dois donc me ranger avec le camp plus conservateur.

Surtout que c'est pas vraiment pour faire le ménage que je suis venu :)
C'est pas faire le ménage, c'est pour attribuer la source de tes 
modifications.

Eric, la modification de wiki nécessaire à ceci (celle à laquelle je pensais
en fait) c'est la suppression de "it seems the historic practice of tagging
objects or individual attributes has not been officially deprecated yet".
Le jour où c'est vraiment déprécié, alors pas de problème pour supprimer,
mais clairement ce n'est pas l'avis de tout le monde.


Pas besoin de déprécier dans ton cas, il n'y a pas d'autres solution que 
de l'enlever pour faire une modification avec une source différente.


Si tu le laisse, on peut pas savoir à quoi s'applique la source qui est 
sur l'objet et celle qui est dans ton script, à moins de lire son code 
source pour voir ce qu'il vérifie/modifie comme attribut (et faut faire 
pareil pour chacune des version des objets OSM).


Je me répète, mais laisser le tag source=A sur un objet dans un 
changeset avec source=B, c'est comme si dans tu avais mis dans ton 
changeset source=A; B. Ce qui n'est pas correct.



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

Re: [OSM-talk-fr] Suppression de l'attribut source (Re: Import des horaires des bureaux de poste)

Le 15/11/2020 à 00:57, Jérôme Amagat a écrit :

Le sam. 14 nov. 2020 à 21:01, Éric Gillet <mailto:e%2btalkfr2...@linuxw.info>> a écrit :

Le 13/11/2020 à 22:09, David Faure via Talk-fr a écrit :
> On vendredi 13 novembre 2020 18:23:11 CET Éric Gillet wrote:
>> Le 12/11/2020 à 10:02, David Faure via Talk-fr a écrit :
>>>> Et il faut garder les anciennes sources (sauf les anciennes
versions de
>>>> ce que tu importes).
>>>>
>>>> Typiquement tu auras des source
>>>> source=LaPoste -03/2019 dus aux ref:FR:LaPoste
>>>>
>>>> Il ne fallait pas supprimer la source du bâti (par exemple).
>>> Ah, j'avais mal lu le wiki. Source sur un object c'est
historique mais il
>>> ne faut pas effacer. Je croyais avoir lu le contraire (et
aussi Éric
>>> disait qu'il fallait effacer, cf mail de mardi). Pas de
problème, j'y
>>> touche pas.
>> Je penses que la phrase du wiki "so don't go around deleting those
>> source tags"/"ne vous précipitez pas pour supprimer ces balises
sources"
>> c'est pour éviter que des contributeurs suppriment/modifient en
masse
>> "uniquement" un tag.
> Ah, en effet, c'est ce que j'avais lu en premier, et qui m'avait
fait implémenter ça.
>
> Mais depuis j'ai vu
> "Comme celui-ci n'est pas officiellement obsolète, ne commencez
pas à supprimer ces marques avant qu'une décision générale du
projet décide de le faire."
>

https://wiki.openstreetmap.org/wiki/FR:Key:source#Usage_historique_sur_les_objets_et_les_attributs
>
> Et pareil dans la version anglophone, " As usual don't start
deleting those tags unless and until there is a general project
decision to do so. "
>
>> [...]
>> La source précédente (celle existante sur l'objet) n'est pas
perdue,
>> elle est stockée dans l'historique de l'objet. Tout comme le tag
>> source=* que tu apposes aux changesets.
> Je suis d'accord avec ton raisonnement. Mais je suis nouveau, je
vais pas aller
> supprimer un attribut si le wiki dit "c'est pas encore vraiment
décidé au niveau du projet".

Si tu ne supprimes par le tag existant il y aura donc 2 sources
sur les
horaires :

- data.gouv.fr:LaPoste - 04/2012 (par exemple)

La source LaPoste dans le tag source=* ce n'est pas obligatoirement 
pour les horaires, il y a même de grandes chances que ce soit la 
source de la position du bureau de poste donc pas de raison de le 
supprimer si l'on ne change que l'horaire sans déplacer le bureau de 
poste. Et supprimer la source quand c'est "cadastre", c'est la 
source de la géométrie du bâtiment, il y a surement beaucoup d'autre 
source=* différentes, qui peuvent être la source de la position du 
bureau de poste, du nom du bureau, , du nombre d'étages du 
bâtiment, de la couleur de ses murs..., de n'importe quel tag sur 
l'objet ou n'importe quel élément de sa géométrie.

Justement on ne peut pas savoir à quoi s'applique le tag source en le 
laissant. Le laisser lorsqu'on fait des modifs ça veut dire qu'il 
s'applique également à la version courante de l'objet, alors que c'est 
pas le cas vu qu'il y a plusieurs autres ajouts avec des sources 
différentes.

En modifiant le tag opening_hours=*, seule la source dans 
source:opening_hours=* peut être modifiée ou supprimée.
Elle n'est pas supprimée, elle devient non visible dans la version 
actuelle de l'objet. Elle est présente dans l'historique, tout comme les 
tags source dans les changesets, qui sont la façon retenue par la 
majorité des modifications dans OpenStreetMap.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Suppression de l'attribut source horaires des bureaux de poste)

2020-11-14 Per discussione Éric Gillet


Le 14/11/2020 à 23:14, osm.sanspourr...@spamgourmet.com a écrit :


Le 14/11/2020 à 22:08, David Faure via Talk-fr -
talk-fr@openstreetmap.org a écrit :

On samedi 14 novembre 2020 21:34:52 CET Éric Gillet wrote:

Le 14/11/2020 à 21:05, David Faure a écrit :

On samedi 14 novembre 2020 20:59:13 CET Éric Gillet wrote:
Si quelqu'un change le wiki, je fais :-)⎄

Je l'ai fait en français et anglais :

OK, merci, j'ai remis la suppression de 'source' dans le script.


Désolé, ça me gène de devoir parcourir l'historique de l'objet pour
trouver quand la référence de l'objet était ref:FR:LaPoste=04598A


C'est vraiment facile avec des outils comme l'historique JOSM (Ctrl+H) 
ou DeepHistory <https://osmlab.github.io/osm-deep-history/>, et sûrement 
plein d'autres méthodes que je connais pas ;)
Rien ne dit que le tag ref:FR:LaPoste n'ont pas été modifié après le 
changeset qui a ajouté le tag source=* sur l'objet. C'est bien là le 
problème !
Avec ou sans tag source sur l'objet pour savoir quand a été modifié pour 
la dernière fois cette ref:FR:LaPoste il faut de toute façon regarder 
chercher le dernier changeset ayant modifié la clé.



Car les commentaires sont :

Version #6 Rajouts de nouvelles boutiques
Version #5 Fix with Osmose
Version #4 France, suppression des clés moneo:loading
Version #3 ajouts divers
Version #2 add building
Version #1 (aucun commentaire)

Autant ça ne me dérange pas que la source d'une mise à jour d'horaires
soit mise dans le changeset, tout comme la mise à jour d'une
ref:FR:LaPoste si l'ojjet du changeset est la mise à jour de cet
attribut (par exemple si l'historique avait compris Version #3
source=data.gouv.fr:LaPoste - 01/2013), autant ça me dérange de virer un
source qui a son sens.


Voir au dessus, il est supprimé de la version actuelle de l'objet car il 
devient faux. Mais il reste présent dans la base de données grâce à 
l'historique, tout comme un attribut source=* sur un changeset ;)



D'autant que les ref:FR:LaPoste ont une validité
qui semble limitée (mais sans doute par le fait que La Poste ferme
beaucoup de bureaux de poste).

Je préfèrerai de faire ça en deux passes : une pour virer le source (en
mettant en commentaire la valeur en question) puis une pour mettre à
jour les horaires.


Ça me semble pas soutenable comme approche d'ajouter un tag source dans 
l'objet (au lieu du changeset) pour chacune des modifs afin de faciliter 
son traitement par la suite.
Rien que dans ton exemple au dessus, ça ferait entre 4 et 7 sources ! 
Les tags de changesets sont là pour ça, utilisons-les :)


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

Re: [OSM-talk-fr] Suppression de l'attribut source (Re: Import des horaires des bureaux de poste)

2020-11-14 Per discussione Éric Gillet


Le 14/11/2020 à 21:05, David Faure a écrit :

On samedi 14 novembre 2020 20:59:13 CET Éric Gillet wrote:

Le 13/11/2020 à 22:09, David Faure via Talk-fr a écrit :

On vendredi 13 novembre 2020 18:23:11 CET Éric Gillet wrote:

Le 12/11/2020 à 10:02, David Faure via Talk-fr a écrit :

Et il faut garder les anciennes sources (sauf les anciennes versions de
ce que tu importes).

Typiquement tu auras des source
source=LaPoste -03/2019 dus aux ref:FR:LaPoste

Il ne fallait pas supprimer la source du bâti (par exemple).

Ah, j'avais mal lu le wiki. Source sur un object c'est historique mais
il
ne faut pas effacer. Je croyais avoir lu le contraire (et aussi Éric
disait qu'il fallait effacer, cf mail de mardi). Pas de problème, j'y
touche pas.

Je penses que la phrase du wiki "so don't go around deleting those
source tags"/"ne vous précipitez pas pour supprimer ces balises sources"
c'est pour éviter que des contributeurs suppriment/modifient en masse
"uniquement" un tag.

Ah, en effet, c'est ce que j'avais lu en premier, et qui m'avait fait
implémenter ça.

Mais depuis j'ai vu
"Comme celui-ci n'est pas officiellement obsolète, ne commencez pas à
supprimer ces marques avant qu'une décision générale du projet décide de
le faire."
https://wiki.openstreetmap.org/wiki/FR:Key:source#Usage_historique_sur_le
s_objets_et_les_attributs

Et pareil dans la version anglophone, " As usual don't start deleting
those tags unless and until there is a general project decision to do so.
">

[...]
La source précédente (celle existante sur l'objet) n'est pas perdue,
elle est stockée dans l'historique de l'objet. Tout comme le tag
source=* que tu apposes aux changesets.

Je suis d'accord avec ton raisonnement. Mais je suis nouveau, je vais pas
aller supprimer un attribut si le wiki dit "c'est pas encore vraiment
décidé au niveau du projet".

Si tu ne supprimes par le tag existant il y aura donc 2 sources sur les
horaires :

- data.gouv.fr:LaPoste - 04/2012 (par exemple)

Cet attribut est sur l'objet lui même, est plus ou moins déprécié et donc
j'imagine ignoré ? En tous cas s'il ne l'est pas, j'imagine que tout le monde
comprend ça comme "la source de la création initiale de l'objet, quelques
détails ont pu changer depuis".
C'est ce que je pense aussi :) Du coup si tout le monde comprends qu'il 
n'a plus d'effet, pourquoi le garder ?

- datanova.laposte.fr, 2020-11-15

Cette valeur de l'attribut source est sur le changeset, pas sur l'objet.
Le changeset montre clairement qu'il modifie les horaires.

Si quelqu'un change le wiki, je fais :-)⎄


Je l'ai fait en français et anglais :

https://wiki.openstreetmap.org/w/index.php?title=Key:source=2061096=2061095
https://wiki.openstreetmap.org/w/index.php?title=Key:source=2061090=2061087
https://wiki.openstreetmap.org/w/index.php?title=FR:Key:source=2061119=1551177



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

Re: [OSM-talk-fr] Suppression de l'attribut source (Re: Import des horaires des bureaux de poste)

2020-11-14 Per discussione Éric Gillet


Le 13/11/2020 à 22:09, David Faure via Talk-fr a écrit :

On vendredi 13 novembre 2020 18:23:11 CET Éric Gillet wrote:

Le 12/11/2020 à 10:02, David Faure via Talk-fr a écrit :

Et il faut garder les anciennes sources (sauf les anciennes versions de
ce que tu importes).

Typiquement tu auras des source
source=LaPoste -03/2019 dus aux ref:FR:LaPoste

Il ne fallait pas supprimer la source du bâti (par exemple).

Ah, j'avais mal lu le wiki. Source sur un object c'est historique mais il
ne faut pas effacer. Je croyais avoir lu le contraire (et aussi Éric
disait qu'il fallait effacer, cf mail de mardi). Pas de problème, j'y
touche pas.

Je penses que la phrase du wiki "so don't go around deleting those
source tags"/"ne vous précipitez pas pour supprimer ces balises sources"
c'est pour éviter que des contributeurs suppriment/modifient en masse
"uniquement" un tag.

Ah, en effet, c'est ce que j'avais lu en premier, et qui m'avait fait 
implémenter ça.

Mais depuis j'ai vu
"Comme celui-ci n'est pas officiellement obsolète, ne commencez pas à supprimer ces 
marques avant qu'une décision générale du projet décide de le faire."
https://wiki.openstreetmap.org/wiki/FR:Key:source#Usage_historique_sur_les_objets_et_les_attributs

Et pareil dans la version anglophone, " As usual don't start deleting those tags 
unless and until there is a general project decision to do so. "


[...]
La source précédente (celle existante sur l'objet) n'est pas perdue,
elle est stockée dans l'historique de l'objet. Tout comme le tag
source=* que tu apposes aux changesets.

Je suis d'accord avec ton raisonnement. Mais je suis nouveau, je vais pas aller
supprimer un attribut si le wiki dit "c'est pas encore vraiment décidé au niveau du 
projet".


Si tu ne supprimes par le tag existant il y aura donc 2 sources sur les 
horaires :


- data.gouv.fr:LaPoste - 04/2012 (par exemple)

et

- datanova.laposte.fr, 2020-11-15

Comment savoir de quelle date et site viennent les horaires dans ce cas ?


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

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

2020-11-13 Per discussione Éric Gillet


Le 12/11/2020 à 10:02, David Faure via Talk-fr a écrit :



Et il faut garder les anciennes sources (sauf les anciennes versions de
ce que tu importes).

Typiquement tu auras des source
source=LaPoste -03/2019 dus aux ref:FR:LaPoste

Il ne fallait pas supprimer la source du bâti (par exemple).

Ah, j'avais mal lu le wiki. Source sur un object c'est historique mais il ne 
faut pas effacer.
Je croyais avoir lu le contraire (et aussi Éric disait qu'il fallait effacer, 
cf mail de mardi).
Pas de problème, j'y touche pas.


Je penses que la phrase du wiki "so don't go around deleting those 
source tags"/"ne vous précipitez pas pour supprimer ces balises sources" 
c'est pour éviter que des contributeurs suppriment/modifient en masse 
"uniquement" un tag. Par exemple supprimer tous les is_in=* de France.


Mais ce n'est pas ton cas : tu ajoutes/modifie des données basées sur 
une autre source que celle dans source=* sur l'objet. Ce tag devient 
donc faux, il n'y a pas d'autres solutions que de le supprimer. 
Concaténer les deux sources sur l'objet n'est pas souhaitable non plus 
car il n'est pas possible de savoir quelles données proviennent de 
quelle source.


La source précédente (celle existante sur l'objet) n'est pas perdue, 
elle est stockée dans l'historique de l'objet. Tout comme le tag 
source=* que tu apposes aux changesets.



Pas de mention de l'outil d'importation, au cas où quelqu'un veuille
remonter à comment un mauvais import a eu lieu ?

Non

Bon ben va falloir se mettre d'accord sur ce point là aussi :-)
https://wiki.openstreetmap.org/wiki/Key:created_by peut soit dire JOSM
vu que j'uploade le changement avec JOSM (mais bon il n'aura pas fait grand 
chose
dans l'histoire), soit j'y mets le nom de mon script comme dans le premier test
que j'ai fait, https://www.openstreetmap.org/changeset/93931921

La page wiki sur created_by ne mentionne pas le cas des imports


L'important est que l'outil et la personne soient identifiables. La 
méthode me paraît secondaire. Mais ce n'est pas l'avis de tous, et 
certains sont très stricts là-dessus. Le mieux à mon avis c'est de 
mettre en place toutes les méthodes possibles d'identification de 
l'import pour espérer ne pas te faire revert. Il y a d'autres 
suggestions sur le wiki : 
https://wiki.openstreetmap.org/wiki/Import/Guidelines





car pour utiliser un robot tu dois créer un compte spécifique.
Par exemple DavidFaure_bot.

Ah, c'est vrai que j'avais lu de créer un autre compte et que j'ai oublié de le 
faire.
Mais je vois la réponse de Jérôme, je vous laisse vous mettre d'accord, et 
j'obéirai :-)
Personne ici n'a à donner d'ordres ;) La seule chose souhaitable c'est 
de chercher un consensus, mais souvent il n'est jamais atteint sur les 
mailing lists (je suppose dû au format et au public).


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

Re: [OSM-talk-fr] Osmose : documentation interactive de création d'analyse (Jupyter)

2020-11-11 Per discussione Éric Gillet


Le 07/11/2020 à 18:06, Frédéric Rodrigo a écrit :

Bonjour,

Une version interactive de la documentation de création d'analyses 
pour Osmose est disponible en ligne. Le but est de rendre la chose 
accessible à plus de monde.


Bonjour,

Merci pour ce fantastique outil, ça m'a bien aidé pour proposer une 
analyse  ! J'ai pas 
essayé en ligne, mais en local ça marche bien :)


Éric

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

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

2020-11-10 Per discussione Éric Gillet


Le 08/11/2020 à 23:20, David Faure via Talk-fr a écrit :



Horaires : oui on a le droit d'ajouter/modifier des horaires, on met en
général un source=La Poste, 2020-11-08 (histoire de savoir d'où ça vient
et de quand ça date).

Dans le changeset, j'imagine. OK.


+1 pour mettre la source et attribution dans le changeset.
Il faudra aussi enlever le source=* sur chaque objet modifié car il 
n'aura plus de sens. Exemple : "source=data.gouv.fr:LaPoste - 06/2015"



Pas de mention de l'outil d'importation, au cas où quelqu'un veuille remonter
à comment un mauvais import a eu lieu ?
Bonne idée ! Il y a le tag created_by=* 
 qui est fait pour 
ça. Tu peux aussi mettre la page wiki de documentation que t'as faite 
dans le commentaire.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

2020-11-10 Per discussione Éric Gillet


Le 09/11/2020 à 21:11, David Faure via Talk-fr a écrit :

On lundi 9 novembre 2020 19:42:59 CET Yves P. wrote:

Disons que ces informations (les colonnes Heure_limite_dépôt_Courrier,
Heure_limite_dépôt_Chrono, et Heure_limite_dépôt_Colis)
ne vont pas dans opening_hours, donc je les considère hors périmètre.
C'est déjà assez compliqué comme ça :-)

C'est OK d'inventer des suffixes non standardisés/documentés comme ça ?


Comme c'est bien en ligne avec les pratiques usuelles : suffixe après un 
':', clé collection_times bien documentée. Il n'y a que peu d'erreur 
d'interprétation.


Documenter ça (sur la page wiki OSM collection_times par ex.) en 
parallèle de l'import me semble adapté :)



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

Re: [OSM-talk-fr] Twitter : OpenData : GrandPoitiers

2020-11-05 Per discussione Éric Gillet


Le 23/10/2020 à 10:59, Jacques Lavignotte a écrit :


Nouvelles données sur les LogementsSociaux disponibles sur la 
plateforme opendata de GrandPoitiers !


 http://ow.ly/cWKq50BYJq6

Ref : https://twitter.com/Grand_Poitiers/status/1319285103470604296


Bonjour,

Merci pour le partage ! Ils sont aussi sur data.gouv.fr 
, 
ce sera facile de les retrouver.


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

Re: [OSM-talk-fr] Mettre à jour un panneau dégradé

2020-10-12 Per discussione Éric Gillet via Talk-fr


Le 11/10/2020 à 15:11, osm.sanspourr...@spamgourmet.com a écrit :

1) on avertit le gestionnaire de panneau (et on lui demande de mettre à
jours OSM quand il est réparé ou de nous informer quand il est réparé -
ça fait une petite pub pour montrer le potentiel d'OSM).

2) un panneau et un point de vue ce sont a priori deux objets distincts.

3) *was:*information=map et compagnie. Je dis was, car je doute que tu
puisses mettre un end_date.

4) un survey_date peut être utile pour savoir quand c'était dégradé.

5) une note si tu trouves que ce qui précède n'est pas suffisant. 


Bonjour,

Très bonnes suggestions. Je suggérerais juste de préférer indiquer la 
date de survey dans le changeset (exemple "survey 2020-10-10") plutôt 
qu'avec survey_date sur les objets.


Ce tag (comme les tags source=* sur les objets), a tendance à ne pas 
être tenu à jour, et deviens une sorte de trolltag 
 dès qu'un contributeur 
utilise une autre source de données que survey pour modifier l'objet.


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

Re: [OSM-talk-fr] Simplification représentation "Cédez-le-passage cycliste au feu"

2020-09-29 Per discussione Éric Gillet


Le 29/09/2020 à 21:26, Ralf Treinen a écrit :

Bonsoir,

On Mon, Sep 28, 2020 at 11:02:18AM +0200, Axel Listes wrote:

Bonjour,

Le 28/09/2020 à 09:40, Éric Gillet a écrit :

Donc, dans le schéma d'origine que je découvre, il faudrait trois

relations.

Mais les éditeurs facilitent la création de telles relations.

Exactement ça me semble être une question d'éditeurs plus qu'une
question de tags/objets OSM.

Alors voici globalement les « défauts » qui en découlent :
- Les multiples césures des chemins, il faut les couper à l'emplacement
du point « via » de la relation.

c'est écrit ou qu'il faut découper les chemins ? Sur la page wiki (anglaise)

https://wiki.openstreetmap.org/wiki/Relation:restriction

je ne trouve pas que le point "via" doit être un point terminal des deux
chemins "from" et "to".


C'est un peu caché, mais bien présent dans la page :

https://wiki.openstreetmap.org/wiki/Relation:restriction#cite_note-waysplit-2


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

Re: [OSM-talk-fr] on dessine ou on cartographie ?

2020-09-29 Per discussione Éric Gillet


Le 29/09/2020 à 22:51, osm.sanspourr...@spamgourmet.com a écrit :
http://osmose.openstreetmap.fr/en/map/#item==18=48.441338=-4.413868=1%2C2%2C3== 



Bonjour,

comme vous voyez il y a dessiné des parkings en surfacique avec du coup
des "trous" avec la voirie.

Je suis plus pour faire des voies de service en indiquant des
parking:lane:both=perpendicular et compagnie.

Et une enveloppe comportant places et voies en amenity=parking.

Exemple : https://www.openstreetmap.org/changeset/90462674.

C'est plus précis et plus propre.

Là on a des parkings en surfacique approximatif et des voies en linéaire.

Du coup Osmose lance plein d'alertes.

Avoir des amenity=parking allant jusqu'au milieu de la route pourrait
résoudre cela aussi.

Des avis ?


Bonjour,

À mon avis :

 * Pour les voies à usage autre que parking, genre rue de ville :
   "parking:lane:both=perpendicular et compagnie."
 * Le cas de ton exemple osmose et en général les voies qui ne servent
   qu'au parking ou quasiment : "enveloppe comportant places et voies
   en amenity=parking"

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

Re: [OSM-talk-fr] Simplification représentation "Cédez-le-passage cycliste au feu"

2020-09-29 Per discussione Éric Gillet


Le 29/09/2020 à 10:09, lejun a écrit :


Bonjour,

Le 28/09/2020 à 14:03, Vincent de Château-Thierry a écrit :
Dans le cas d'un cédez-le-passage cycliste, on peut se demander à 
quoi donc cela peut servir


Je suis également perplexe sur la nécessité, non pas d'indiquer où se
trouvent les M12 (référence du panneau à apposer là où se trouve le feu
tricolore), mais d'accompagner le mouvement du cycliste.
Ça a été déjà répondu par d'autres, mais je pense qu'il faut pas (trop) 
présager des usages d'OSM.
Surtout que j'ai l'impression qu'il y a un gros chevauchement (héhé) 
entre les populations cyclistes et usagers OSM.


OSM est une base de données visant à représenter l'environnement sur la
base de l'existence physique et la vérifiabilité, en ce sens, indiquer
où se trouve le panneau est justifié. À l'inverse, je ne pense pas utile
de cartographier explicitement la fonction du panneau par des méthodes
souvent complexes. Ce raisonnement poussé à l'extrême nous inviterait
également à créer des relations pour les feux tricolores en apposant une
condition "Ne pas passer quand le feu est rouge".


"Ne pas passer quand le feu est rouge" est déjà "encodé" dans le tag 
highway=traffic_signals.
Le chemin impacté est lui encodé par l'appartenance du nœud. Après avoir 
franchi le feu, les règles "classiques" s'appliquent de nouveau, donc 
pas utile de les mettre dans OSM à mon avis.


Le cédez-le-passage cycliste est moins évident, voici un exemple :

https://www.mapillary.com/map/im/Fvkc5IbfFl9Z45RM-HppYA

Bon le panneau est illisible, mais en vélo on peut tourner à droite au 
rouge sur la piste cyclable et sur la route, qui sont deux voies 
séparées donc 2 relations normalement.

Évidemment celui-ci n'est pas cartographié... Je m'empresse de le faire :)


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

Re: [OSM-talk-fr] Simplification représentation "Cédez-le-passage cycliste au feu"

2020-09-28 Per discussione Éric Gillet


Le 28/09/2020 à 11:02, Axel Listes a écrit :

Bonjour,

Le 28/09/2020 à 09:40, Éric Gillet a écrit :

Donc, dans le schéma d'origine que je découvre, il faudrait trois

relations.

Mais les éditeurs facilitent la création de telles relations.

Exactement ça me semble être une question d'éditeurs plus qu'une
question de tags/objets OSM.

Alors voici globalement les « défauts » qui en découlent :
- Les multiples césures des chemins, il faut les couper à l'emplacement
du point « via » de la relation.


Dans la plupart des cas l'intersection sera composée de 2 voies de la 
manière suivante : -|-, donc ça fait 2 coupures au maximum. J'ai 
l'impression que les intersections plus complexes avec + de voies (donc 
plus dangereuses) n'ont pas de cédez-le-passage tout-droit ou à gauche.



- La maintenance, comme toutes relations, celles-ci sont susceptibles
d’être cassées lorsque qu'un contributeur débutant ou non vigilant
intervient sur l'un des éléments intégrés dans la relation.


Oui en effet, mais ça malheureusement il n'y a pas de solution. Même 
avec une myriade d'avertissement des contributeurs arrivent 
régulièrement à fusionner des nœuds de routes 1km plus loin sur iD. 
Pourtant ce sont des opérations simple (fusion de nœuds) sur des 
"données simples" (nœuds, pas de relation), donc je ne suis pas sûr que 
ce soit un problème de complexité du modèle de données.


Si l'éditeur a une vue dédiée aux cédez-le-passage, il serait sûrement  
facile de mettre cette vue lors d'erreurs de validation pour faire 
corriger le contributeur.



Les systèmes
de suivi d’éditions ont plus de difficultés à donner des informations
concernant des éditions de relations que de points (Achavi, OSMcha ...)
Oui en effet. Je pense que c'est l’œuf et la poule, il y a beaucoup plus 
de modifications (et donc d'erreurs à surveiller) sur les nœuds et 
voies, donc plus d'attention est portée à leur rendu.

- La complexité de l'usage des relations, honnêtement pourquoi
obligatoirement passer par un système hyper complexe alors que l'on peut
juste ajouter une balise sur un point pour arriver au même résultat ?
L'exemple d'Éric est intéressant, car il permet de se poser cette
question : Une balise sur un point déjà existant ou trois relations ?


C'est plus complexe qu'un seul tag sur un seul nœud, de là à dire 
"hyper-complexe" pas sûr. Le monde est complexe, pas tout n'est 
forcément cartographiable facilement. Par exemple on pourrait dire qu'il 
serait plus simple de cartographier les arbres de la manière suivante :


natural=tree
espece=platane

Au lieu de :

natural=tree
genus=Platanus
species=Platanus × hispanica
deciduous=leaf_cycle
leaf_type=broadleaved

Mais ça me semble pas pertinent pour une base de données.

Pour revenir sur les panneaux, il faut se demander ce que l'on veut 
cartographier : le panneau (ce que tu suggères si j'ai bien compris) ou 
son effet.


Panneau :

 * Plus simple à cartographier
 * Ne représente que le panneau, et nécessite donc une interprétation
   pour savoir quelle voie sont concernées. Cette interprétation est
   potentiellement différente par pays/état.

Relations:

 * Plus complexe à cartographier
 * Pas d'ambiguïté pour les utilisateurs

Certains pourraient suggérer une approche hybride (panneau quand pas 
d'ambiguïté, relation quand ambiguïté possible), mais ça veut dire 
implémenter logiciellement (et faire comprendre aux contributeurs) les 
deux manières de cartographier, ce qui me semble empirer le problème.


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

Re: [OSM-talk-fr] Choisir le bon name pour les trajets de bus

2020-09-28 Per discussione Éric Gillet


Le 27/09/2020 à 16:46, Gad Jo a écrit :

Bonjour a tous,

Exemple extrême (y aura pas pire que ça) : Bus 12 bis : 
Montredon-des-Corbières - Montredon Pôle d’échanges → 
Montredon-des-Corbières - Clos des Ormeaux

(Désolé le copier-coller sur l'application ajoute le format)
Relation concernée : https://www.openstreetmap.org/relation/11674315

Auriez vous des propositions à me faire ? À moins que des règles 
existent et j'applique... Je serait tenté de placer que le nom de l'arrêt


Bonjour,

Je pense qu'il faut mettre le nom tel que diffusé au public par le 
réseau (en données ouvertes, sur les documents ou sur le terrain).


"name=:  → /" /[1][2]//ou 
autre variante n'est pas un nom mais une description//redondante avec 
les autres tags présents dans la relation/. /Pas toutes les applications 
affichent ces détails-là donc une telle description en nom me paraît 
acceptable, mais uniquement en "solution de repli" quand la ligne n'a 
pas de nom.


[1]https://wiki.openstreetmap.org/wiki/Public_transport#Service_routes
[2]https://lists.openstreetmap.org/pipermail/tagging/2019-May/045180.html

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

Re: [OSM-talk-fr] Simplification représentation "Cédez-le-passage cycliste au feu"

2020-09-28 Per discussione Éric Gillet


Le 28/09/2020 à 09:15, osm.sanspourr...@spamgourmet.com a écrit :

> Donc, dans le schéma d'origine que je découvre, il faudrait trois
relations.

Mais les éditeurs facilitent la création de telles relations.


Exactement ça me semble être une question d'éditeurs plus qu'une 
question de tags/objets OSM.



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

Re: [OSM-talk-fr] Covoiturage et véhicules propres : une signalisation expérimentale pour les voies réservées

2020-09-13 Per discussione Éric Gillet


Le 13/09/2020 à 19:49, Philippe Verdy a écrit :
Pour informer les usagers de la route, des panneaux de signalisation 
indiquent les voies réservées aux transports en commun, bus, taxis 
mais aussi aux véhicules en covoiturage et aux véhicules propres, en 
agglomération comme sur les voies rapides. Depuis le 31 août 2020, une 
expérimentation de signalisation a débuté sur tout le territoire pour 
harmoniser la matérialisation de ces voies. Un arrêté publié au 
Journal officiel le 29 août 2020 précise ces modalités.


https://www.service-public.fr/particuliers/actualites/A14270?xtor=EPR-141


Merci pour le partage !


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

Re: [OSM-talk-fr] Tags addr: pour les radars

2020-09-07 Per discussione Éric Gillet


Le 06/09/2020 à 22:23, Romain MEHUT a écrit :


Quand j'ai supprimé les polygones boundary=urban, il m'est arrivé de 
faire quelques corrections annexes comme de retirer des tags 
addr:country, addr:city en particulier sur les relations des radars de 
vitesse.


Un contributeur m'a contacté car il utilise ces tags pour contrôler 
leur présence via la requête suivante :


Vous validez ma méthode et vous êtes d'accord pour retirer les tags 
addr: ?


Je suis entièrement d'accord 
, il y a de nombreuses 
façon de géocoder ce genre d'objets, mais mettre les tags en dur sur 
chaque ne me semble pas la bonne non plus.


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

Re: [OSM-talk-fr] Photos — Re: Projet du mois de septembre (en préparation) : défibrillateurs !

2020-08-15 Per discussione Éric Gillet


Le 15/08/2020 à 09:04, Christian Quest a écrit :

Le 15/08/2020 à 00:02, Éric Gillet a écrit :

Le 14/08/2020 à 19:12, Yves P. a écrit :


C'est une très bonne idée ce projet !

peut-être ça vaut le coup de regarder du côté d'IPFS 
<https://ipfs.io/> ? Ça utilise exactement le mécanisme que tu 
décris :)


Quelques avantages que je vois à utiliser ça plutôt qu'une archive 
"maison" :


- Gestion de l'adressage, des dossiers déjà implémentée depuis 
longtemps, donc robuste
- Possibilité à n'importe quel contributeur disposant de stockage 
de faire mirroir, idem pour les passerelles IPFS/HTTP

- Moins de trafic à gérer du coup

Pour les photos, il y a son stockage (simple avec IPFS), ses 
métadonnées, et son ou ses adresses.

Est-ce que Mapillary, Commons utilisent aussi IPFS ?

Je ne pense pas.

Comment authentifier les paires clés OSM / photos ?


Ah oui j'ai mal lu le message de Christian, qui voulait que le hash 
soit calculé à partir du couple clé-valeur fichier et pas le hash du 
fichier en lui-même.


Du coup c'est un peu moins direct, mais ça peut se faire avec IPFS 
aussi en mettant les images dans un dossier. Elles auraient comme nom 
le hash que proposait Christian, ou tout autre transformation 
conservant une relation 1-1 (ou presque) avec le tag originel. 
Exemple rapide :


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

https://bafybeidbdqxzzorb7gktaovapiq3agjh33brhgvkolnejhgxspac6ds5t4.ipfs.dweb.link/

Je n'ai rien par principe contre IPFS, ça me semble juste trop 
exotique actuellement (un peu comme le web sémantique) pour baser une 
telle archive dessus.


Des technos plus basiques (HTTP) me semblent largement suffisantes 
pour démarrer et pour faciliter l'adoption initiale.



L'adoption des consommateurs ou l'adoption par les archiveurs ?
Les consommateurs accéderaient les images via une passerelle HTTP, donc 
aucune différence pour eux.
Pour les archiveurs/miroirs idem, ils pourraient faire miroir via IPFS 
ou via n'importe quel autre protocole (rsync, FTP...). Ce ne serait 
qu'un avantage supplémentaire.


Le but d'une archive est qu'elle soit pérenne. La rendre 
"mirrorable"/"shardable" facilement me semble important pour éviter les 
risques associés à avoir qu'un seul miroir. C'est là qu'IPFS excelle vu 
que n'importe qui peut devenir lui-même miroir sans manipulation de la 
part du miroir principal.


Mais je comprends que ça fasse encore une techno de plus à gérer pour le 
gestionnaire du miroir principal. Même si son utilisation est assez simple.


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

Re: [OSM-talk-fr] Photos — Re: Projet du mois de septembre (en préparation) : défibrillateurs !

2020-08-14 Per discussione Éric Gillet


Le 14/08/2020 à 19:12, Yves P. a écrit :


C'est une très bonne idée ce projet !

peut-être ça vaut le coup de regarder du côté d'IPFS 
 ? Ça utilise exactement le mécanisme que tu décris :)


Quelques avantages que je vois à utiliser ça plutôt qu'une archive 
"maison" :


- Gestion de l'adressage, des dossiers déjà implémentée depuis 
longtemps, donc robuste
- Possibilité à n'importe quel contributeur disposant de stockage de 
faire mirroir, idem pour les passerelles IPFS/HTTP

- Moins de trafic à gérer du coup

Pour les photos, il y a son stockage (simple avec IPFS), ses 
métadonnées, et son ou ses adresses.

Est-ce que Mapillary, Commons utilisent aussi IPFS ?

Je ne pense pas.

Comment authentifier les paires clés OSM / photos ?


Ah oui j'ai mal lu le message de Christian, qui voulait que le hash soit 
calculé à partir du couple clé-valeur fichier et pas le hash du fichier 
en lui-même.


Du coup c'est un peu moins direct, mais ça peut se faire avec IPFS aussi 
en mettant les images dans un dossier. Elles auraient comme nom le hash 
que proposait Christian, ou tout autre transformation conservant une 
relation 1-1 (ou presque) avec le tag originel. Exemple rapide :


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

https://bafybeidbdqxzzorb7gktaovapiq3agjh33brhgvkolnejhgxspac6ds5t4.ipfs.dweb.link/

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

Re: [OSM-talk-fr] Photos — Re: Projet du mois de septembre (en préparation) : défibrillateurs !

2020-08-14 Per discussione Éric Gillet


Le 09/08/2020 à 12:06, Christian Quest a écrit :

Le 09/08/2020 à 10:14, Yves P. a écrit :

de Christian


Pour le stockage des photos ou autres sources externes, wikipedia 
garde une copie d'archive.
Je pense que ce serait bénéfique de faire pareil pour OSM, car tout 
lien externe est potentiellement instable


Tu suggères de mettre un système de cache au niveau de l'API OSM ? ;)

Un contributeur OSM édite un objet avec les tags suivant et l'API 
fait automatiquement un copie :


  * image=http://site.com/a.jpg
  * mapillary=APQ8H32KnIwG3lKIaMY7HA
  * wikimedia_commons=File:Defibrillator am Hafenbüro Kappeln.jpg
  * une combinaison de tout ça dans le tag image
  * avec des valeurs multiples ;)


Comment retrouve-t-on les photos ?


Je ne pense pas à un cache (temporaire), mais à une copie d'archive, 
comme wikipédia le fait sur les sources qui peuvent disparaître, 
changer d'adresse ou autre.


J'ai un peu réfléchit au problème... le plus simple me semble de 
calculer un hash à partir du tag au contenu à archiver. Ceci évite de 
devoir rajouter un tag avec le lien de l'archive dans la base OSM.


Exemple (avec du md5)

image=http://site.com/a.jpg -> 
http://archive.osm.org/ce7442f69a6ad43fb972724c1a8cdc05


mapillary=APQ8H32KnIwG3lKIaMY7HA -> 
http://archive.osm.org/eaaee35521d34a3cb74965cb50dcb500


etc...


C'est une très bonne idée ce projet !

Si archive.org ou autre archive "standard" n'est pas utilisée, peut-être 
ça vaut le coup de regarder du côté d'IPFS  ? Ça 
utilise exactement le mécanisme que tu décris :)


Quelques avantages que je vois à utiliser ça plutôt qu'une archive 
"maison" :


- Gestion de l'adressage, des dossiers déjà implémentée depuis 
longtemps, donc robuste
- Possibilité à n'importe quel contributeur disposant de stockage de 
faire mirroir, idem pour les passerelles IPFS/HTTP

- Moins de trafic à gérer du coup


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

Re: [OSM-talk-fr] josm traduction dans les préréglage highway les attributs liés à "placement"

2020-08-13 Per discussione Éric Gillet


Le 11/08/2020 à 11:50, leni a écrit :
Dans le préréglage de certaines routes, il y a les infos "placement" 
(https://wiki.openstreetmap.org/wiki/Key:placement) certains attributs 
décrits dans la proposition 
(https://wiki.openstreetmap.org/wiki/Proposed_features/placement) ne 
sont pas encore traduits.


"placement" a été traduit  par "localisation" est-ce que ce ne serait 
pas plutôt "positionnement" ?


et pour la traduction des valeurs ?
"left_of:x"        > "à gauche de la voie x"
"middle_of:x"  > "au milieu de la voie x"
"right_of:x"  > "à droite de la voie 1"

"Placement in way direction" > "Positionnement dans le sens du chemin"
"Placement opposed to way direction" > "Positionnement dans le sens 
opposé au chemin" 

Oui tes suggestions me semblent + lisibles et + correctes

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

Re: [OSM-talk-fr] Défibrillateur et tag name=*

2020-08-07 Per discussione Éric Gillet


Le 07/08/2020 à 10:10, Yves P. a écrit :
soit trop "simple" (Mairie) et ne correspondant pas à un panneau sur 
place ou un "identifiant".

Le panneau c'est le gros texte gravé sur la façade du dit établissement ;D

Si tu parles d'une étiquette officielle apposée sur l'appareil, 
effectivement non.


C'est pour répondre à ton exemple d'arrêt de bus, qui lui a sûrement une 
étiquette.



Mais cette info est dans le fichier GeoDAE.
En effet. Mais souvent dans les jeux de données il y a des infos 
fausses, subjectives ou redondantes. Pas tout est bon à prendre.



Pour "A droite au fond du couloir", je ne vois pas de tag qui décrit ça ;)


Avec le level, la position dans OSM et les panneaux sur place ça doit 
suffire largement. Si ça suffit pas, il y a un problème d'accessibilité 
du DAE.

Le cas échéant, defibrilator:location + signalement aux entités concernées.


Un exemple réel : "À gauche au fond du couloir, devant l'infirmerie"
https://www.openstreetmap.org/node/6323423304

Merci pour l'exemple. On dirait que l'infirmerie n'est pas 
cartographiée, ça réglerait le problème sans tag dédié pour le DAE.



Dans un listing, il manque une info essentielle : "Collège des Lacs"


Pourquoi pas "Infirmerie" ? Ou "Collège" ? Ou "Collège de 
Clairvaux-les-Lacs" ? Le nom n'est toujours pas pertinent à mon avis.


Autre tag manquant : access=customers ou access=private. Je connais pas 
ce collège, mais à ma connaissance en général ils ne laissent pas 
rentrer le public, donc le DAE n'est pas vraiment accessible au public



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

Re: [OSM-talk-fr] Défibrillateur et tag name=*

2020-08-06 Per discussione Éric Gillet


Le 06/08/2020 à 16:43, Yves P. a écrit :

Suite au travail lancé pour ajouter des jeux de données dans Osmose autour des défibrillateurs, la 
question se pose de la pertinence du tag name=* sur les défibrillateurs [1,2]. En effet, dans les 
jeux de données (GéoDAE, AEDMAP, bases locales), un nom est souvent associé au DAE. Ce nom est 
plutôt descriptif, exemples "DAE de la mairie", "Défibrillateur de la salle 
XYZ". Dans certains cas, il ressemble plutôt à une référence. Il est proposé ainsi d'opter 
pour l'utilisation de ref=* ou description=*.

En parallèle, dans la base de données OSM aujourd'hui, on constate que 14% des 
DAE ont un tag name=* associé. C'est plus que ref=* (5%) ou description=* 
(moins de 3% ?). Une requête Overpass fait ressortir que les valeurs du champ 
name=* sur les DAE sont plutôt descriptives. C'est un usage qui dépasse nos 
frontières à la vue des langues utilisées. Même si ce sont des noms 
descriptifs, l'usage montre que name=* est l'attribut pour stocker cette info.

Tient, ça me rappel la discussion sur les panneaux d'informations touristiques 
;)

+1 :p

La question est donc la suivante : doit-on préferer le champ name=* pour cette 
info (usage international), utiliser un champ ref=* (plus logique 
sémantiquement, mais qui sera une spécificité FR), voire ne pas proposer 
d'ajouter l'info du nom dans OSM (arbitrage simple mais on perd une info) ? 
Merci pour vos avis qui permettront de débloquer l'ajout de nouveaux jeux dans 
Osmose :-)

Evitons le franco-français : name est parfait
(Il faut peut-être vérifier que les moteurs de rendu ne l'affichent pas).

Pour moi la question est : que mettre dedans pour retrouver un DAE rapidement ?

name="DAE de la mairie" est trop descriptif.

Je préfère :

name="Mairie"
defibrillator:location="Au premier étage à droite"


Je pense qu'il vaut mieux pas de nom, car il sera soit trop long 
(Premier étage mairie de Tourcoing), soit trop "simple" (Mairie) et ne 
correspondant pas à un panneau sur place ou un "identifiant".


Pour indiquer la position à un humain : defibrillator:location="Premier 
étage de la mairie à droite", mais même cet exemple peut être bien 
décrit avec les tags :


level=1
location=indoor
opening_hours=*
access=*
operator=Mairie de X (pas sûr, ça doit être une boîte externe qui gère)

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

Re: [OSM-talk-fr] Pourquoi inventer un aire urbaine imaginaire ?

2020-08-02 Per discussione Éric Gillet


Le 02/08/2020 à 15:07, rme...@openstreetmap.fr a écrit :

J'aimerais également supprimer les traffic_sign=city_limit créés par le 
contributeur à l'origine des polygones mais uniquement ceux restés en version 
1. Comment faire cette distinction dans overpass turbo ?


Exemple :

node[traffic_sign=city_limit](if: version() == 1)(user: "osm-operon");
out;

https://overpass-turbo.eu/s/WGA

Ça représente tout de même environ 3500 nœuds. Sont-ils vraiment à enlever ?


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

Re: [OSM-talk-fr] Le nom ou le titre ...

2020-07-30 Per discussione Éric Gillet


Le 30/07/2020 à 09:44, Yves P. a écrit :

J'hésite entre "name" ou "board:title" pour e titre des panneaux.

En France, il y a 6888 panneaux avec name et seulement 59 avec board:title.
Même si c'est une information à considérer, le fait que ce soit + 
utilisé ne veut pas forcément dire que c'est utilisé correctement. Cf 
name=* sur des toilettes ou arbres "banals" par exemple.

Je ne connaissais pas l'autre tag et je doute qu'il soit ni rendu, ni trouvé 
par Nominatim.


Justement, est-ce qu'on souhaite que les utilisateurs trouvent le 
panneau qui décrit l'objet ou l'objet en lui-même ? Le panneau en 
lui-même n'a pas de nom, le nom qu'il arbore est celui de l'objet qu'il 
décrit.


Je pense que c'est une bonne chose que le titre d'un panneau ne soit pas 
affiché dans les rendus généralistes.


En conclusion, je penche plutôt vers board:title (ou autre tag qui n'est 
pas name).



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

Re: [OSM-talk-fr] Carte d'intensité

2020-07-28 Per discussione Éric Gillet


Le 26/07/2020 à 21:04, André Laurenti a écrit :
La carte de la répartition des intensités du séisme du 23 février 1887 
sur la Riviera italienne et française avance. J'ai terminé le 
département des Alpes-Maritimes à partir de mes archives.


http://u.osmfr.org/m/469058/

Questions : peut-on améliorer la légende en faisant apparaître les 
différents points de couleur ? (exemple, intensité VI avec un point 
jaune)


On peut intégrer des images de la manière suivante dans la légende des 
calques (expliqué par le point d’interrogation dans l'interface 
d'édition de la description du calque) :


 * Image : {{http://image.url.com}}
 * Image avec largeur (en pixels) : {{http://image.url.com|largeur}}

Mais ça implique d'héberger quelque part une petite image par couleur 
qu'on veut mettre dans la légende. Je n'ai pas l'impression qu'on puisse 
utiliser du style CSS directement.



J'ai remarqué aussi qu'au bout d'un certain temps la carte n'est plus 
accessible pour compléter les informations que faut-il faire exactement ?


Ne serais-tu pas juste déconnecté d'uMap ? C'est visible en haut de la 
page d’accueil (bouton connexion ou déconnexion en fonction) : 
http://umap.openstreetmap.fr/fr/


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

Re: [OSM-talk-fr] Désaccord sur un highway=footway

2020-07-15 Per discussione Éric Gillet


Le 02/06/2020 à 10:11, Éric Gillet a écrit :

Le 01/06/2020 à 22:31, osm.sanspourr...@spamgourmet.com a écrit :


Donc si on revient sur le coin d'où on est parti :

- y a-t-il un panneau autorisant les cycles ? Non
- y a-t-il un panneau interdisant les cycles ? Non

De partout on arrive sur ce qui ressemble soit à un trottoir soit à 
une place piétonne.


Dans le premier cas bicycle=no (implicite, c'est un footway).

Dans le second cas bicycle=yes (implicite c'est un pedestrian).

Et comme c'est pas clair on met bicycle=permissive : pas fait pour 
mais personne ne dit rien.
J'ai l'impression d'avoir suivi ta logique et j'aboutis à une 
solution qui semblait convenir aussi à Eric.


highway=footway/pedestrian + bicycle=permissive me semble en effet le 
bon compromis entre la légalité/l'intention de l'urbanisme et ce que 
les gens font en général dans cette zone.


Après avoir laissé décanter j'ai pris la solution qui a fait le moins de 
vagues pour indiquer les zones grises : access=permissive.


Merci pour l'échange !


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

Re: [OSM-talk-fr] Des panneaux de direction

2020-07-14 Per discussione Éric Gillet


Le 19/06/2020 à 11:59, Jean-Christophe Becquet a écrit :

Bonjour,

Comment bien taguer ces points qualifiés par erreur comme panneaux
publicitaires alors qu'il s'agit de panneaux de direction ?

Les 2 premiers indiquent des quartiers ou des équipements structurants
pour la ville.
https://www.openstreetmap.org/node/1276519475
https://www.openstreetmap.org/node/1276520956
https://www.mapillary.com/app/?focus=photo=osqPf08fXanxs02gEepT2w=44.0894084=6.2294785=17=0.4845607940873434=0.47819761608877726=0.41570438799076215

  traffic_sign= ?


Pour ceux-là le formalisme est clair, ce sont des panneaux de direction 
routiers (moins sûr pour le Musée Gassendi). Je pense que le plus 
important est de mettre le tag destination="Centre Ville; etc" sur les 
voies, mais si tu tiens à mettre les nœuds panneaux il y a 
traffic_sign=FR:D21b


https://fr.wikipedia.org/wiki/Panneau_de_signalisation_directionnelle_de_position_en_France
https://wiki.openstreetmap.org/wiki/Key:traffic_sign#Lists_of_IDs_per_country


Le troisième indique des points d'intérêt : hôtel, camping, maison de
retraite, magasin
https://www.openstreetmap.org/node/4688783242
https://www.mapillary.com/app/?focus=photo=_XWVSbqnOLi-ugYdUCdLDA=44.089407=6.229187=17=0.30797704088175976=0.4262211197759842=2.0785219399538106

  tourism=information ?


C'est entre l'information pour touristes et la publicité, j'ai pas trop 
d'idées. Peut-être :


advertising=yes
message=tourism
tourism=information
information=guidepost
description=Panneau de direction pour établissements touristiques

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

Re: [OSM-talk-fr] Tagrequest :: "Nouveau lieu de loisirs et d’animations familiales"

2020-07-14 Per discussione Éric Gillet


Le 10/07/2020 à 13:36, Jacques Lavignotte a écrit :

Ce noeud

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

"Nouveau lieu de loisirs et d’animations familiales"

selon :

https://www.lanouvellerepublique.fr/vienne/a-biard-ce-soir-le-mana-ouvre-ses-portes-en-fanfare 



comme on y joue à la pétanque et qu'il y'a un panneau de basket j'ai 
mis « leisure=pitch » en attendant vos conseils avisés et que j'y 
aille ce soir boire une 


Comme toujours c'est compliqué les lieux à multi-usages sur OSM...

Là comme j'imagine que les "terrains" et la restauration ne sont pas 
exactement au même endroit, j'imagine deux nœuds ou zones, l'un pour la 
buvette/bar/resto, l'autre pour le(s) terrains. Les deux partageraient 
le même nom/opérator etc.



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

Re: [OSM-talk-fr] url et ODbL

2020-07-11 Per discussione Éric Gillet


Le 11/07/2020 à 15:50, osm.sanspourr...@spamgourmet.com a écrit :

j'ai trouvé des images intéressantes, publiées en ligne, mais aux droits
incertains.
Peut-on les mettre en image= ?
Ou vaut mieux vaut-il s'abstenir ?
Les URL sont publiques, la photo pas forcément (photo issue d'une
collection, années 50 maxi et carte postale d'une maison d'édition
disparue, là aussi années 50 maxi., sans doute 1944). 


Bonjour,

Comme tu le dis, si l'image à vocation à être publique (référencée et 
dispo sans authentification notamment), pas de problème à mon avis pour 
le tag image.
Idéalement l'image aurait une licence libre, mais tant qu'elle ne sert 
pas de source c'est ok :)



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

Re: [OSM-talk-fr] Test mission Pic4Review "Passage piéton en fauteuil roulant"

2020-07-10 Per discussione Éric Gillet


Le 09/07/2020 à 14:21, Percherie OnDaNet a écrit :
La mission "Passages piéton en fauteuil roulant" : 
https://pic4review.pavie.info/#/mission/1103


Avant de la proposer comme modèle sur Pic4Review, pouvez-vous vérifier 
si je n'ai pas fait de coquille dans les tags utilisé ? Vous pouvez 
les consulter quand vous dupliquez la mission pour votre zone. Au 
besoin je peut les énumérer ici mais si je peut éviter de polluer la 
liste.


Petit détail, mais je pense qu'il faudrait homogénéiser les termes entre 
les boutons de la revue et sa présentation (exemple "Parfait"="Aucune 
restriction").


Autre soucis mais sûrement plus général à Pic4Review, il n'indique pas 
la source (image Mapillary par ex.) dans les changesets.



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

Re: [OSM-talk-fr] OverPass et rue sans éclairage en ville

2020-07-08 Per discussione Éric Gillet


Le 03/07/2020 à 15:13, Percherie OnDaNet a écrit :
Je suis en train de regarder comment extraire les voies sans éclairage 
en ville et les voies principale hors aglo. Je part de la requête 
suivante :

[out:json][timeout:250];
(
   way["highway"][!"lit"]({{bbox}})(if: length() > 30);
);
// print results
out body;
>;
out skel qt;

Comment ajouter une zone englobante ayant les tags suivant  : 
landuse=residential|retail|commercial|industrial


En dehors de ces zones, je compte exclure les tag suivant : 
highway=track|path|road


Pas toutes les "aires" présentes dans OSM sont utilisables dans 
Overpass, sûrement pour des raisons de performance : 
https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#By_area_.28area.29


Les landuses sans nom sont concernés. Exemple de la différence entre une 
aire présente et non-présente : https://overpass-turbo.eu/s/VVB


Je vois deux solutions :

- Considérer que ce qui est dans les limites administratives de ville 
est "en agglomération". Exemple : https://overpass-turbo.eu/s/VVC
- Importer la zone dans une base de données Postgis et faire les 
requêtes "à la main"


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

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-07-08 Per discussione Éric Gillet


Je suis 100% d'accord et j'applique ce qu'indique Christian.

Le 08/07/2020 à 16:17, Christian Quest a écrit :


En général ce qui me gêne c'est :

- la duplication de l'information,

- et pour dédupliquer le besoin de vérifier des tags en plus pour se 
dire que non, ce n'est pas ce que je cherche (ça complique beaucoup la 
réutilisation des données, on a déjà eu le cas avec les "disused")



Pourquoi dupliquerai-t-on l'adresse sur chaque entrée/accès et pas le 
type de POI (c'est une entrée... de cinéma, un sortie de secours... de 
cinéma, etc) ? Où est la cohérence globale ? Pourquoi répéter l'un 
mais pas l'autre ?



On prends un peu de recul ? A quoi servent le plus souvent les adresses ?

1) à retrouver la position d'un lieu quand on n'a pas d'autre 
information pour s'y rendre (adresse géographique) avec une 
description hiérarchique (commune > voie > numéro > complément comme 
le bâtiment ou un numéro d'entrée, d'escalier)


2) à faire des envois à un destinataire (adresse postale), là il n'y a 
pas forcément concordance géographique (cas des CEDEX, BP et autre, 
mais aussi des secrétariats qui ne sont pas sur place).


De mon point de vue, contact:xxx répond à ce besoin d'adresse postale, 
çàd quelle adresse je met pour un contact par courrier. Elle ne 
devrait jamais être utilisée pour du routage pour cette raison.



L'adresse géo, elle, servira à déterminer une position pour un calcul 
d'itinéraire si on n'a pas mieux, car si je cherche "Ciné Montrouge", 
je n'ai pas besoin de son adresse... la position du POI suffit à 
calculer l'itinéraire, qui d'ailleurs quand on fournit juste une 
adresse va chercher la position géographique correspondant pour faire 
ensuite son routage.


Si je veux aller au 88 rue Racine (sans savoir que c'est là où il y a 
le ciné, l'espace Colucci, etc), un seul noeud suffit pour ça.


Donc dans les exemples que tu donnes:



Voici donc l'exemple de la mairie de Montrouge, constitué d'un 
bâtiment avec 3 accès :

- le bâtiment https://www.openstreetmap.org/way/83237614
  addr:role=contact
- l'entrée principale https://www.openstreetmap.org/node/2232200912
  addr:role=entrance;visitors
- l'entrée secondaire https://www.openstreetmap.org/node/2443190668
addr:role=entrance;delivery
- l'entrée reservée au personnel 
https://www.openstreetmap.org/node/6245192824

  addr:role=staff

L'adresse pourrait être simplement sur le bâtiment, ensuite chaque 
entrée/accès avec un noeud entrance=* et décrivant les règles d'accès.


Pas besoin de dupliquer addr:xxx partout dans un tel cas.



Pour un exemple plus classique et simple d'un cinéma, on aurait :
- le bâtiment https://www.openstreetmap.org/way/83233476
  addr:role=contact
- l'entrée principale https://www.openstreetmap.org/node/5914047022
  addr:role=entrance
- la sortie de secours https://www.openstreetmap.org/node/7694884485
  addr:role=emergency

Il me semble que ce modèle est solide et remplacerait avantagement 
addr:contact
Assigner des /usages/ aux adressses : Christian n'est pas l'évolution 
dont tu rêves depuis des lustres ?


Sur ce cas, l'Espace Colucci me semble être le site entier, la 
parcelle, car on y trouve aussi un théâtre d'extérieur et le cinéma 
fait partie de cet espace (je suis allé voir sur leur site web). Les 3 
adresses serait bien à leur place en limite de la parcelle entière, le 
88 au début du footway qui mène à l'entrée, le 129 sûrement plutôt à 
la grille, le 131 à l'escalier qui donne sur la rue.



On a, je pense, trop tendance à ramener tout aux bâtiments, des tags, 
des noeuds d'adresse, etc


Sur le centre sportif juste à côté, le sport_centre est sur le site 
entier... les adresses en limite de parcelle (no comment sur les deux 
name=Gymnase).


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

Re: [OSM-talk-fr] Comptage d'objets avec overpass

2020-06-29 Per discussione Éric Gillet


Le 29/06/2020 à 22:34, Florian LAINEZ a écrit :
Je n'arrive -toujours pas !- à comprendre comment extraire des stats 
fiables avec overpass.
Par exemple, là j'ai 8 cinémas https://overpass-turbo.eu/s/Vzp et en 
bas de la page d'overpass ce n'est pas le bon chiffre. Où le trouver ?
Pourtant il ne devait pas y avoir de piège, il n'y a pas de relation, 
rien de complexe.

Du coup je pense que toutes mes stats antérieures sont fausses.

Mais pourquoi diable overpass n'affiche-t-il pas de manière évidente 
le comptage des objets requêtés ? Un simple chiffre, simple, efficace, 
vrai.


Si tu veux avoir le nombre d'objets, tu as le mode de sortie "count". 
Exemple : https://overpass-turbo.eu/s/VAA



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

Re: [OSM-talk-fr] Enquête usagers data.gouv.fr

2020-06-29 Per discussione Éric Gillet


Le 29/06/2020 à 11:56, Magalie Dartus a écrit :
D'ailleurs je vous invite à répondre au questionnaire usagers : 
https://framaforms.org/enquete-datagouvfr-usagers-1590438305


Les avis de la communauté seront très utiles.

Merci pour le partage !

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

Re: [OSM-talk-fr] FTTH Références à fignoler

2020-06-29 Per discussione Éric Gillet


Le 28/06/2020 à 14:55, Jacques Lavignotte a écrit :

Je l'ai posée au bon endroit :

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

Aidez-moi à compléter les  et les 

Merci, Jacques

Je connais pas ce domaine spécifiquement, mais je pense qu'il vaut mieux 
ne pas mettre les références plutôt que mettre des placeholders qui vont 
masquer le manque d'infos. Au minimum il faudrait mettre un tag fixme à 
mon avis.



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

Re: [OSM-talk-fr] Désaccord sur un highway=footway

2020-06-02 Per discussione Éric Gillet


Le 02/06/2020 à 15:41, Jérôme Amagat a écrit :
Si jai bien compris le lieu du débat, pour la métropole, ça fait parti 
des aménagements cyclables, donc accessible aux vélos :

https://data.grandlyon.com/jeux-de-donnees/amenagements-cyclables-metropole-lyon/donnees


Très bonne observation, merci de l'avoir partagée !

En effet ça semble être la volonté de la métropole (qui est logique 
d'ailleurs) d'avoir un axe structurant vélo est-ouest qui suit la ligne 
de tramway T3. Juste à l'est de cette zone à débat 
, en effet la 
voie est dédiée en vélo, avec aucun obstacles, un bon éclairage et 
enrobés. Bref cela est digne d'une voie "super-structurante". Par 
exemple un croisement piétons/vélos/voitures/tram. 



La zone a débat est classifiée de la même manière, mais ça ne reflète 
pas du tout la situation au sol :


- Passages étroits, en virage et avec des poteaux
- Pavés relativement glissants
- Angles morts piétons/vélos non signalisés
- Arrêt de la piste cyclable juste avant cette zone
- Piétons et vélos mélangés
- Pas de signalisation relative au vélo

Il semble donc que ça soit pas forcément raccord entre ce jeu de données 
et la réalité du terrain physique et signalétique. Peut-être que par 
simplicité ils ne séparent pas les zones courtes non-adaptées au vélo 
dans le réseau "super-structurant" ?


Et même si c'est une bonne indication de la volonté de "tout en haut" 
(la métropole), malheureusement ça ne "fait pas loi" (légalement et en 
terme d'infrastructure)


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

Re: [OSM-talk-fr] Désaccord sur un highway=footway

2020-06-02 Per discussione Éric Gillet


Le 01/06/2020 à 22:31, osm.sanspourr...@spamgourmet.com a écrit :


/J'avais l'impression que les pistes cyclables à Paris ça servait 
aussi aux voitures comme place de parking :-(. Ah, non seulement les 
bandes !

/

Bon argument les pistes/bandes cyclables empruntées par les autre 
usagers comme contre-point, c'est mieux que mes autoroutes cyclables :D


//

Donc si on revient sur le coin d'où on est parti :

- y a-t-il un panneau autorisant les cycles ? Non
- y a-t-il un panneau interdisant les cycles ? Non

De partout on arrive sur ce qui ressemble soit à un trottoir soit à 
une place piétonne.


Dans le premier cas bicycle=no (implicite, c'est un footway).

Dans le second cas bicycle=yes (implicite c'est un pedestrian).

Et comme c'est pas clair on met bicycle=permissive : pas fait pour 
mais personne ne dit rien.
J'ai l'impression d'avoir suivi ta logique et j'aboutis à une solution 
qui semblait convenir aussi à Eric.


highway=footway/pedestrian + bicycle=permissive me semble en effet le 
bon compromis entre la légalité/l'intention de l'urbanisme et ce que les 
gens font en général dans cette zone.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Désaccord sur un highway=footway

2020-06-01 Per discussione Éric Gillet

Le 31/05/2020 à 19:30, Florimond Berthoux a écrit :

Le sam. 30 mai 2020 à 10:34, Éric Gillet <mailto:e%2btalkfr2...@linuxw.info>> a écrit :

Le 29/05/2020 à 22:48, Florimond Berthoux a écrit :

Le ven. 29 mai 2020 à 16:09, Éric Gillet
mailto:e%2btalkfr2...@linuxw.info>> a
écrit :

Le 29/05/2020 à 10:44, Florimond Berthoux a écrit :

Est-ce que les cyclistes y roulent sans jamais se faire
verbaliser ? -> oui
-> bicycle=yes

Les forces de l'ordre ne connaissent pas trop le code de la
route sur l'utilisation des aménagements vélo. Bon nombre
circulent sans avertisseurs (gyrophare/sirène) dans les voies
bus/vélo.
Mais aussi de très nombreux cyclistes grillent des feux/stop,
utilisent des téléphones sans jamais se faire verbaliser.
Cela rends la chose pas moins illégale ou dangereuse.

Il y a une différence j'ai vu plusieurs fois des cyclistes se
faire verbaliser pour grillage de feu, y-a-t-il eu une seule fois
une verbalisation pour avoir roulé sur cette espace ?

Il y a déjà la réponse dans mon précédent commentaire. Les forces
de l'ordre en général ne connaissent pas très bien le code de la
route pour les infractions "mineures". Hors mission particulière
ils ne sanctionnent pas trop les cyclistes pour les infractions
qu'ils connaissent de mon expérience.
De plus, avec la signalisation pas top, et le fait que même à tête
reposée en lisant le code de la route, inspectant scrupuleusement
les photos on a du mal à se mettre d'accord, ce serait difficile
pour les FDO passant par là de s'assurer qu'une infraction est en
cours.

Dernièrement, ce n'est pas parce que j'en ai pas vu qu'il n'y en a
pas eu. Difficile de savoir, encore plus pour un contributeur à
distance tel que OP ;)

Il me semble que footway+bicycle=yes indique bien qu’il y a
un problème d’aménagement (normalement ça ne devrait pas
exister sur un axe de transit vélo).

Oui en effet ça indique que l'axe de transit n'est pas
continu, mais en soit c'est pas gravissime si c'est
correctement signalisé et qu'il n'y a pas de dangers. Là ce
n'est ni correctement signalisé, ni sécurisé.

Mettre bicycle=yes masque ce problème, et empêche les
cyclistes d'avoir cette info et d'emprunter d'éventuels
chemins plus sécurisés/rapides.

Non, bicycle=yes signifie que c'est "légalement" (de facto)
possible ça ne dit rien de la dangerosité de la chose.

Non, bicycle=yes veut dire que c'est légal (sans guillement) de
circuler à vélo. Souvent la légalité va de mise avec la sécurité.
Ici c'est ni légal, ni sécurisé. J'ai déjà parlé plusieurs fois de
la légalité, donc je me suis focalisé sur la dangerosité sur cette
phrase.

C'est ton point de vue de dire que ce n'est pas légal, c'est ton
interprétation de la loi sauf que ce n'est pas le sujet.

Ce n'est pas un point de vue, c'est l’interprétation de la loi, que j'ai
sourcée. Peux-tu sourcer des éléments qui prouvent le contraire ?

Le sujet c'est est-ce que les cyclistes peuvent circuler sur l'espace.
Déjà adressé. Les cyclistes peuvent techniquement rouler sur
l'autoroute, mais c'est ni légal ni souhaitable.

Seul le terrain compte : aucun panneau l'interdit,
Déjà adressé : pas besoin c'est interdit par défaut. Il n'y a pas de
panneau interdisant de rouler ou stationner sur les trottoirs, c'est
pourtant bien interdit et pas souhaitable.

la signalisation le suggère,
Déjà adressé. S'ils voulaient vraiment le suggérer, il y a d'autres
panneaux.

les cyclistes l'utilisent, aucun policier ne l'a interdit

Déjà adressé.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Comment tagguer une passerelle piétonne/cyclable surplombant la mer ?

2020-05-31 Per discussione Éric Gillet


Le 31/05/2020 à 07:55, Francescu GAROBY a écrit :
Sa particularité : elle est construite en partie sur les rochers au 
pied des remparts de la Citadelle, et en partie en "suspension" 
au-dessus de la mer (cf. photo 12 du lien ci-dessus). Il y aussi un 
passage creusé dans la roche, mais ça c'est facile à tagguer.
Ma question est donc : faut-il un tag supplémentaire spécifique, pour 
indiquer cette sorte de passerelle suspendue ?


Je cartographie pas souvent des ponts, mais en me basant sur le wiki 
pour cette image 
 
je ferais pour la voie:


highway=footway
bridge=yes

Et le contour de la structure avec :

man_made=bridge
bridge=viaduct
bridge:support=abutment
bridge:structure=beam

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

Re: [OSM-talk-fr] Ancestris


Le 30/05/2020 à 14:55, Yannick a écrit :

Le 30/05/2020 à 14:34, Éric Gillet a écrit :

Moi non plus je n'y connais rien, mais je suis curieux de savoir à
partir de quand ce genre d'informations (qui semblent pouvoir être
entrées par des particuliers) deviennent "publiques". Si tu as la
possibilité de partager un lien je suis preneur par curiosité.

Merci :)

Éric

Re,

Les données d'état-civil sont libres d'accès dans les conditions suivantes:
Naissance 75 ans sauf si décès auquel cas 25 ans
Mariage 75 ans sauf si décès des protagonistes 25 ans
Décès immédiat
Les archives notariales c'est en général 75 ans
Toutefois il y a des sources qui permettent de contourner partiellement
ces restrictions de communications comme les listes électorales qui sont
immédiates, les recensements de population avant 1975. Et ce manière
parfaitement légale.

À partir du moment où un document est communicable son usage est libre
dans la limite de non nuisance à autrui (code civil)

Tous les délais sont visibles ici, entre autres)
http://www.archivesnationales.culture.gouv.fr/anom/fr/PDFs/General/delais-com-archives.pdf
ou sur
https://fr.geneawiki.com/index.php/D%C3%A9lais_de_communication_des_Archives


Merci bien, c'est parfaitement clair !


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

Re: [OSM-talk-fr] Ancestris


Le 30/05/2020 à 14:25, Yannick a écrit :

Le 30/05/2020 à 14:04, Philippe Verdy a écrit :
Tu viens de montrer que tu ne connais RIEN à la loi sur les archives.
Tu montres que tu ne connais RIEN à la pratique généalogique.


Moi non plus je n'y connais rien, mais je suis curieux de savoir à 
partir de quand ce genre d'informations (qui semblent pouvoir être 
entrées par des particuliers) deviennent "publiques". Si tu as la 
possibilité de partager un lien je suis preneur par curiosité.


Merci :)

Éric


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

Re: [OSM-talk-fr] Ancestris

Merci pour ta réponse Yannick, ça éclaircit pas mal de points pour des 
non-initiés comme moi, mais qui s'intéressent quand même à leur vie privée.
J'avais commencé à répondre plus en détail sur les points, mais Philippe 
a répondu avant, adressant la plupart de mes remarques.


Dans tous les cas, même si la fonctionnalité "partage" est source de 
débat, il n'en reste pas moins que ça a l'air d'être un logiciel très 
complet, exécuté avec précision par une communauté bienveillante. 
L'installation sur mon système était très facile d'ailleurs, et j'ai pu 
prendre en main quelques fonctions basiques très rapidement !

L'utilisation d'OSM est la cerise sur le gâteau, merci pour le partage !

On oublie souvent (moi le premier) de souligner le positif, en essayant 
d’adresser le négatif à tout prix...


Salutations,

Éric

Le 30/05/2020 à 13:10, Yannick a écrit :

Le 30/05/2020 à 03:44, Philippe Verdy a écrit :

J'ai du mal à croire à une "généalogie libre" si elle met en base de
données "libre" des personnes vivantes (sans leur accord) ou décédées
depuis moins de 70 ans (ou leurs ayant-droits).

Une telle base de données nominative devrait faire l'objet d'une
déclaration à la CNIL, surtout si en plus on y attache des infos comme
les dates de naissance, lieu de naissance, liens avec d'autres personnes
vivantes, professions, lieux de travail, écoles ou entreprises,
mariages/partenariats/concubinages, enfants, et en aucun cas une
distribution libre, mais un accord de licence personnelle pour un usage
bien précis encadré par la loi et interdisant l'exploitation en masse (à
des fins commerciales par exemple). Hors si on doit restreindre l'usage
de ces données, ces données ne sont nécessairement pas libres.
En revanche cela peut être utile seulement pour les recherches sur les
personnes décédées depuis longtemps et sans ayant-droit, dont les
données peuvent alors devenir publiques.

Bref toute personne mentionnée qui n'est pas décédée avant 1950
(aujourd'hui) ne devrait pas être du tout dans cette base de données, et
pour avoir les données, il faudrait faire des démarches personnelles
auprès de l'Insee ou l'état-civil, précisant la finalité, et avec un
engagement contractuel (et pénal) signé auprès de l'autorité, contre les
mauvaises utilisations: le respect de la vie privée s'impose...

Je ne sais pas trop quels sont vos termes d'utilisation et ce que
contiennent les bases de données que vous développez, et encore mois si
c'est légal d'échanger entre "généalistes autodéclarés" sur des forums
publics pour obtenir de telles informations sans l'accord des personnes
nommées (et même si ces personnes figurent dans un annuaire publié, leur
exploitation à cette fin est aussi soumise aux règles de droit et
contractuelles de ces annuaires que ce soit l'annuaire téléphonique
universel, les fichiers postaux, des adresses mail ou liens vers des
pages perso sur des réseaux sociaux, eux aussi protégés par leur éditeur
selon leurs termes d'utilisation).

Quelles précautions prenez-vous? Le copyright concernant les données OSM
ou les illustrations n'est pas la seule condition, ou la licence de
votre logiciel, c'est une partie seulement des droits à respecter.
Bref espérons que ce soit déjà étudié.

Le ven. 29 mai 2020 à 22:02, Yannick mailto:yann...@voyeaud.org>> a écrit :

 Bonsoir,

 La carte des utilisateurs d'Ancestris, logiciel de généalogie, vient
 d'être mise à jour avec OSM.
 Dans le coin bas droite il a été mis un lien vers la page de la licence
 j'espère que cela suffit.

 Maintenant Ancestris est entièrement OSM dans le logiciel ET sur le
 site.

 Amitiés

Bonjour,

Philippe Ancestris n'est pas une base de données mais simplement un
logiciel donc un outil.
Le partage de données (il a fallu lui trouver un nom explicite) n'en est
pas vraiment un. En effet il faut être volontaire pour partager la
présence d'informations. Les deux, ou plus, protagonistes sont informés
de possibilités sans que RIEN ne sortent de leur machine, c'est à eux de
faire l'échange véritable. Les éléments de connexion sont détruits dès
lors que le partageur se déconnecte.

Concernant le fichier proprement dit il est exempt de déclaration à la
CNIL tout comme les sites généalogiques (entre autres) de
particuliers.Par contre Généanet et autres sociétés sont bien soumis à
la déclaration.

Il ne faut pas confondre un logiciel et le produit qu'il génère ce sont
deux entités différentes. Tu jettes la suspicion sur tout un loisir qui
contribue à la sauvegarde de la mémoire.
De toute évidence tu méconnais le monde généalogique et historique en
général alors avant de t'exprimer aussi durement tourne ta langue sept
fois avant de t'exprimer.

Tu aurais fait le minimum de recherche tu aurais vu que le logiciel est
en GPLv3. Certes l'accès est un peu délicat mais parfaitement possible.

Ancestris a un vécu de 25 ans donc le problème des licences et des
droits des personnes est largement étudié. Même si les fichiers
personnels

Re: [OSM-talk-fr] [HS] Re: Ancestris


Le 30/05/2020 à 10:24, deuzeffe a écrit :

Le 30/05/2020 à 03:44, Philippe Verdy a écrit :


J'ai du mal à croire

Personne ne te demande de croire. Tout le monde te demande de savoir.

Yannick est un pilier de la généalogie francophone, une espèce de 
wizard comme on en rencontre peu. Et toi ? Tu fais quoi dans ce domaine ?


Attaque personnelle qui ne prends aucunement en compte le point qu'il 
soulève : Qu'en est-il de la vie privée ?
Pas besoin de travailler dans la généalogie pour avoir l'autorisation de 
se soucier de ça.


Pas sûr qu'ici soit le meilleur endroit pour en discuter de cette 
problématique, mais ça ne retire en rien le côté abject de ta réponse.



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

Re: [OSM-talk-fr] Désaccord sur un highway=footway

Le 29/05/2020 à 22:48, Florimond Berthoux a écrit :

Le ven. 29 mai 2020 à 16:09, Éric Gillet <mailto:e%2btalkfr2...@linuxw.info>> a écrit :

Le 29/05/2020 à 10:44, Florimond Berthoux a écrit :

Est-ce que les cyclistes y roulent sans jamais se faire
verbaliser ? -> oui
-> bicycle=yes

Les forces de l'ordre ne connaissent pas trop le code de la route
sur l'utilisation des aménagements vélo. Bon nombre circulent sans
avertisseurs (gyrophare/sirène) dans les voies bus/vélo.
Mais aussi de très nombreux cyclistes grillent des feux/stop,
utilisent des téléphones sans jamais se faire verbaliser. Cela
rends la chose pas moins illégale ou dangereuse.

Il y a une différence j'ai vu plusieurs fois des cyclistes se faire
verbaliser pour grillage de feu, y-a-t-il eu une seule fois une
verbalisation pour avoir roulé sur cette espace ?

Il y a déjà la réponse dans mon précédent commentaire. Les forces de
l'ordre en général ne connaissent pas très bien le code de la route pour
les infractions "mineures". Hors mission particulière ils ne
sanctionnent pas trop les cyclistes pour les infractions qu'ils
connaissent de mon expérience.
De plus, avec la signalisation pas top, et le fait que même à tête
reposée en lisant le code de la route, inspectant scrupuleusement les
photos on a du mal à se mettre d'accord, ce serait difficile pour les
FDO passant par là de s'assurer qu'une infraction est en cours.

Dernièrement, ce n'est pas parce que j'en ai pas vu qu'il n'y en a pas
eu. Difficile de savoir, encore plus pour un contributeur à distance tel
que OP ;)

Il me semble que footway+bicycle=yes indique bien qu’il y a un
problème d’aménagement (normalement ça ne devrait pas exister sur
un axe de transit vélo).

Oui en effet ça indique que l'axe de transit n'est pas continu,
mais en soit c'est pas gravissime si c'est correctement signalisé
et qu'il n'y a pas de dangers. Là ce n'est ni correctement
signalisé, ni sécurisé.

Mettre bicycle=yes masque ce problème, et empêche les cyclistes
d'avoir cette info et d'emprunter d'éventuels chemins plus
sécurisés/rapides.

Non, bicycle=yes signifie que c'est "légalement" (de facto) possible
ça ne dit rien de la dangerosité de la chose.
Non, bicycle=yes veut dire que c'est légal (sans guillement) de circuler
à vélo. Souvent la légalité va de mise avec la sécurité. Ici c'est ni
légal, ni sécurisé. J'ai déjà parlé plusieurs fois de la légalité, donc
je me suis focalisé sur la dangerosité sur cette phrase.

Pour dire que ce n'est pas sécurisé faudra utiliser un ou des autres tag.

Je n'avais pas ajouté les obstacles étant donné qu'ils sont tout à fait
classiques pour de la voirie piétonne, mais autant les mettre vu le
débat. [1]

[1] https://www.openstreetmap.org/changeset/85974594

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

Re: [OSM-talk-fr] Fwd: Re: Désaccord sur un highway=footway


Le 29/05/2020 à 17:26, Éric Gillet a écrit :

Le 29/05/2020 à 16:16, osm.sanspourr...@spamgourmet.com a écrit :


S'ils avaient voulu signaler l'interdiction de continuer ils auraient 
mis un panneau d'interdiction "circulation interdite" B0 
<https://fr.wikipedia.org/wiki/Panneau_de_signalisation_de_circulation_interdite_en_France>.


Pas nécessaire, les vélo sont interdits par défaut pour les trottoirs. 
Autre exemple que j'ai capturé :


Pas de B0, mais j'invite un vélo à essayer d'aller à droite, ça envoie 
dans les passages piétons et ça débouche sur rien [1]



Je me suis trompé de lien, le voici :

[1] https://www.mapillary.com/map/im/xm3Vc9meCZXJKbGtFevM_w

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

Re: [OSM-talk-fr] Fwd: Re: Désaccord sur un highway=footway

Le 29/05/2020 à 16:16, osm.sanspourr...@spamgourmet.com a écrit :

Le 28/05/2020 à 18:29, Éric Gillet - e+talkfr2...@linuxw.info a écrit :

Je garderais le bicycle=yes, voire en designated.
Rien ne désigne le vélo comme autorisé sur cette place piétonne, ce
serait encore moins adapté qu'un bicycle=yes.

-1 : si on dit qu'ils ne sont pas prioritaires c'est qu'_ils sont
autorisés_. A minima tolérés.

Alors oui le panneau n'est pas explicitement dans le code de la route
mais c'est bien un panneau de signalisation routière de danger.

> Ce panonceau n'a aucune existence légale.

https://www.mapillary.com/map/im/6lubeDufWJhvkUBhpeADyA

C'est le panneau de danger A14
<https://fr.wikipedia.org/wiki/Panneau_de_signalisation_de_danger_en_France>.
complété par le panneau M9 précisant le danger :

CYCLISTES
ATTENTION :
PIÉTONS PRIORITAIRES

J'ai pas été très clair. Le panneau existe bien dans le code de la
route, mais son utilisation n'enclenche aucune obligation ou restriction
particulière. C'est juste une information.

On termine aussi l'obligation de voie cyclable.

Qui est également une fin d'interdiction pour les piétons. Sans ça le
trottoir/accotement/"zone piétonne" ne serait pas autorisée aux piétons.

S'ils avaient voulu signaler l'interdiction de continuer ils auraient
mis un panneau d'interdiction "circulation interdite" B0
<https://fr.wikipedia.org/wiki/Panneau_de_signalisation_de_circulation_interdite_en_France>.

Pas nécessaire, les vélo sont interdits par défaut pour les trottoirs.
Autre exemple que j'ai capturé :

Pas de B0, mais j'invite un vélo à essayer d'aller à droite, ça envoie
dans les passages piétons et ça débouche sur rien [2]

On peut aussi noter les bandes rugueuses au sol signalant qu'on entre
dasn une autre zone.

Bien vu, j'avais pas pensé aux bandes comme séparateur ! Il y a aussi le
changement de matière au sol.

Si l'autorité avait voulu marquer la fin de l'aménagement "complet",
ils auraient demandé de mettre pied à terre, voir mis une micro
bordure de début de trottoir.

Il n'y a rien de tout ça.

Le panneau fin de piste cyclable est quand même assez "fort" comme
séparation, en plus des autres critères.

> /S'ils avaient voulu faire une continuité légale, ils auraient eu
plein d'autres moyens explicites. Ils ne l'ont pas fait, c'est un
choix actif de leur part./

> /Exemple de ce à quoi ça ressemble juste à côté, lorsqu'ils font le
choix de faire un "trottoir/accotement/zone piéton" partagé
vélos/piétons [2]/

Et donc ils ont voulu une continuité à la légalité douteuse car plus
loin il y aurait un problème de place.

On est d'accord : plus on représentera les choses telles qu'elles sont
dans OSM, plus on arrivera à montrer les problèmes sans aller
nécessairement sur le terrain.

> /À 50m à l'[ouest] de cette photo les piétons sont obligés de
marcher sur la piste cyclable [3], un autre problème d'aménagement de
cette zone.../

> [3] /https://www.mapillary.com/map/im/ntQTeDajclvXt2wq63DZvA/

De manière symétrique je mettrais :
highway=cycleway
foot=permissive

(segregated=no ? Ça me semble implicite)

C'est d'ailleurs un problème : on dit aux cyclistes (qui selon
Florimond ne peuvent être arrivés là sauf à pied) qu'ils doivent
continuer là. Mais on ne dit rien aux piétons (alors qu'on le dit
ailleurs).
Peut être ajouter les photos en référence comme images mapillary dans
OSM histoire de voir le pourquoi des choix et monter aussi les
problèmes aux aménageurs.

Et si Éric et Simon ne sont pas d'accord sur la manière de le
représenter, je crois que vous êtes d'accord pour dire que ce n'est
pas un bon aménagement. Idéalement rencontrer les élus et venir avec
des propositions pour améliorer l'existant.

Oui il faudrait, j'ai pas trop la fibre "politique" mais tu as
entièrement raison.

J'ai remarqué qu'ils ont mis une interdiction piétonnes B9a
<https://fr.wikipedia.org/wiki/Panneau_d%27interdiction_d%27acc%C3%A8s_aux_pi%C3%A9tons_en_France>
au niveau de la voie du tram. L'ont-ils mises au début du panneau B22a
<https://fr.wikipedia.org/wiki/Panneau_de_signalisation_d%27une_piste_ou_bande_cyclable_obligatoire_en_France>
(je suppose) de piste cyclable ? Sans doute que non.

Il n'y a pas besoin : B22a et C113 tous deux deux interdisent par défaut
les piétons.

Le 29/05/2020 à 10:44, Florimond Berthoux -
florimond.berth...@gmail.com a écrit :
Il me semble que footway+bicycle=yes indique bien qu’il y a un
problème d’aménagement (normalement ça ne devrait pas exister sur un
axe de transit vélo).

Non, il y a plein d'endroits où la densité de piétons et de cycles
ainsi que la largeur de la voie permet une cohabitation apaisée. Par
exemple d'anciennes voies ferrées transformées en voies vertes : ça
peut être un axe de transit vélo avec des piétons de temps en temps.

Là on est plus au niveau d'une tolérance que d

Re: [OSM-talk-fr] Désaccord sur un highway=footway

Le 29/05/2020 à 10:44, Florimond Berthoux a écrit :
Il me semble important de rappeler qu’OpenStreetMap n’est pas une base
de donnée légale, on ne tag pas la lois.
On ne tag pas la loi parce que nous ne sommes pas des juges et que si
les juges existent c’est parce que la loi est interprétative.

Bien entendu qu'on taggue la loi, et heureusement ! Physiquement rien
n'empêche un vélo d'utiliser une autoroute, c'est juste dangereux et
illégal. Donc on cartographie l'interdiction via highway=motorway.

Idem pour les limites de vitesse, les zones privées, les bases
militaires, et limites administratives etc etc.

Et j’aimerai qu’on évite de s’embarquer dans des débats de juriste
stérile.

Moi aussi c'est ma plus grande volonté, cf mon dernier message du changeset.

Est-ce qu’il y a un panneau qui interdit d’y pédaler ? -> non

Pas besoin, c'est interdit par défaut en agglomération (trottoirs et
assimilés). Ce serait inimaginable de mettre un panneau interdiction de
pédaler sur tous les trottoirs.

Est-ce que les cyclistes y roulent sans jamais se faire verbaliser ?
-> oui

-> bicycle=yes

Les forces de l'ordre ne connaissent pas trop le code de la route sur
l'utilisation des aménagements vélo. Bon nombre circulent sans
avertisseurs (gyrophare/sirène) dans les voies bus/vélo.
Mais aussi de très nombreux cyclistes grillent des feux/stop, utilisent
des téléphones sans jamais se faire verbaliser. Cela rends la chose pas
moins illégale ou dangereuse.

Il me semble que footway+bicycle=yes indique bien qu’il y a un
problème d’aménagement (normalement ça ne devrait pas exister sur un
axe de transit vélo).

Oui en effet ça indique que l'axe de transit n'est pas continu, mais en
soit c'est pas gravissime si c'est correctement signalisé et qu'il n'y a
pas de dangers. Là ce n'est ni correctement signalisé, ni sécurisé.

Mettre bicycle=yes masque ce problème, et empêche les cyclistes d'avoir
cette info et d'emprunter d'éventuels chemins plus sécurisés/rapides.

Le ven. 29 mai 2020 à 08:32, Éric Gillet <mailto:e%2btalkfr2...@linuxw.info>> a écrit :

Le 28/05/2020 à 22:47, osm.sanspourr...@spamgourmet.com
<mailto:osm.sanspourr...@spamgourmet.com> a écrit :

c'est donc un footway.

On est d'accord.

[si les piétons] sont prioritaires c'est que d'autres usagers
ceux à qui s'adresse le panneau, ici les cyclistes, sont
autorisés _en tant que tels_ et donc sans mettre pied à terre :
malgré les apparence ce n'est pas un trottoir !

Ce panonceau n'a aucune existence légale. À mon avis il s'adresse
aux vélos qui s'autorisent contre la signalétique/loi de continuer
à circuler, afin de réduire les accidents. Autre exemple de ce
panonceau [1], là encore pas utile car aux passages piétons les
piétons sont dans tous les cas prioritaires.

S'ils avaient voulu faire une continuité légale, ils auraient eu
plein d'autres moyens explicites. Ils ne l'ont pas fait, c'est un
choix actif de leur part.

Exemple de ce à quoi ça ressemble juste à côté, lorsqu'ils font le
choix de faire un "trottoir/accotement/zone piéton" partagé
vélos/piétons [2]

On ne demande pas aux cyclistes de mettre pied à terre donc ils
ont le droit de rester, donc :

bicycle
<https://wiki.openstreetmap.org/wiki/Key:bicycle?uselang=en>=yes

Du coup non, pas adapté.

ou plutôt permissive. "Where bicycles do not have a legal
right-of-way, but the land owner has indicated that bicycles are
allowed".

On est sur la bonne voie (pun intended), mais non ce n'est
toujours pas autorisé, et puni par une amande classe 4.

Est-ce que sur ce qui semble être un trottoir il y a un panneau
avertissant les piétons de la circulation de cycles ? Rien vu
depuis Mapillary.

Bonne remarque ! Malheureusement il n'y a rien, ni à proximité de
la pharmacie qui fait un angle mort, ni à la pointe est où le
passage et étroit et semé de bollards.

Par contre ce n'est pas sur cette liste mais avec la mairie ou la
com com qu'il faudrait voir afin d'avoir une continuité dans de
bonnes conditions.

Entièrement d'accord. D'ailleurs OSM est une base de données
géographiques représentant le terrain et ses problèmes, pratique
pour exposer les problèmes à la comcom non ? Sauf si l'on masque
ces problèmes à coup de bicycle=yes là où il n'y a pas continuité.
Dans ce cas ni les usagers, ni les comcoms peuvent voir les problèmes.

En cas d'accident il serait possible de se retourner contre
l'aménageur car il semble que le piéton puisse de bonne foi se
croire sur un trottoir. Et le cycliste sur une voie qui lui est
ouverte.

Exactement. C'est d'ailleurs pour ça je pense qu'ils ne se
risquent pas à autoriser les vélos, le passage est dangereux dans
cette zone.

Mais à côté on voit aussi des piétons sur la v

Re: [OSM-talk-fr] Désaccord sur un highway=footway


Le 29/05/2020 à 10:31, Yves P. a écrit :


Par contre ce n'est pas sur cette liste mais avec la mairie ou la 
com com qu'il faudrait voir afin d'avoir une continuité dans de 
bonnes conditions.



Entièrement d'accord.


D'ailleurs OSM est une base de données géographiques représentant le 
terrain et ses problèmes, pratique pour exposer les problèmes à la 
comcom non ?
Sauf si l'on masque ces problèmes à coup de bicycle=yes là où il n'y 
a pas continuité.

Dans ce cas ni les usagers, ni les comcoms peuvent voir les problèmes.


Il y a cette outil 
https://carto.parlons-velo.fr/#18.02/45.75278/4.869234 pour voir les 
points noirs à vélo (cliquer sur la couche "Points noirs").


Joli outil ! Bon dommage apparemment il n'est pas possible d'y 
contribuer hors campagnes baromètres si j'ai bien compris. Le côté 
"point noir" est assez limitant en terme d'expression possible par 
rapport à OSM.


Mais surtout c'est difficilement intégrable avec une carte, ou un moteur 
d'itinéraire pour adapter les trajets et informer les usagers. Et il me 
semble que parlons-vélo/la FUB ne couvre que la France.


Et cette page pour les signaler à Lyon : 
https://www.maisonduvelolyon.org/signaler-incident-velo/


J'ai fait un signalement très simple à corriger (1 panonceau manquant, 
interdisant un contre-sens-cyclable) il y a bientôt 1 an, toujours rien 
de fait [1]. Si j'ai la motivation je le ferais pour le sujet de ce fil 
aussi.


[1] https://demarches.toodego.com/signalements/voirie-et-signalisation/2246/


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

Re: [OSM-talk-fr] Désaccord sur un highway=footway


Le 28/05/2020 à 18:48, Yves P. a écrit :
Ici, surtout avec le panneau "attention aux piétons" et les logos de 
sorties/entrées


Si c'était le cas, pourquoi mettre ce panneau plutôt que le B54 et 
B55, ou C113/C114 ?
Je vois les B54 et B55 signalant une aire piétonne 
 quand 
je circule en voiture sur une voie qui devient ou croise une aire.


Les panneaux C113/C114 indiquants une piste ou bande cyclable 
conseillée et réservée aux cycles 
 ne 
sont pas adaptés ici : c'est fait à la base pour les piétons :)


En effet B54/B55 (aire piétonne) serait plus adapté que C113/C114 vu 
qu'il n'y a pas la place d'avoir une piste/bande réservées aux cycles. 
Bien vu !


Pour moi, cette zone *est* une *aire piétonne.* Voir ici 
.


Malheureusement ça n'en est pas une. Comme inscrit dans l'article 
R110-2, et présenté dans la plaquette que tu partage :


« [...] Les entrées et sorties de cette zone sont annoncées par une 
signalisation [...] »


Ce n'est pas le cas ici, pas de B54/B55. Par défaut c'est donc assimilé 
à un (grand) trottoir en agglomération, avec les interdictions que ça 
implique pour les vélos.


Mais je suis d'accord avec toi, c'est ce que la ville devrait faire ici.

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

Re: [OSM-talk-fr] Désaccord sur un highway=footway