Re: [OSM-talk-fr] cimetière Cesson-Sévigné (35)

[Marc Gauthier via Talk-fr]

Bonjour,
Quelque part dans ce secteur : 48.118167 , -1.608088
angle nord-est de rue de la Croix Connue/mail de Bourgchevreuil

Sur le site de l'IGN, la photo est mal référencée : 
https://remonterletemps.ign.fr/comparer/?lon=-1.604760=48.117394=17.5=19=1=split-h


Marc

Le 24/03/2024 à 14:40, Yannick a écrit :

Bonjour,

Je cherche l'ancien cimetière de cette commune citée en objet.
Je vois bien le nouveau mais impossible de trouver l'ancien.
J'ai besoin de le géolocaliser.

Merci de votre aide

Amitiés

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



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

Re: [OSM-talk-fr] cimetière Cesson-Sévigné (35)

[Marc Gauthier via Talk-fr]

Bonjour,
Quelque part dans ce secteur : 48.118167 , -1.608088
angle nord-est de rue de la Croix Connue/mail de Bourgchevreuil

Sur le site de l'IGN, la photo est mal référencée : 
https://remonterletemps.ign.fr/comparer/?lon=-1.604760=48.117394=17.5=19=1=split-h


Marc

PS : avec la copie d'écran le mail est en attente d'approbabtion

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

Re: [OSM-talk-fr] Relations intermédiaires pour les routes de bus ?

[Marc Gauthier via Talk-fr]

Bonjour à tous,

On a déjà un élément partagé qui est à l'origine d'une part très 
importante des ruptures de continuité des tracés : le rond-point.
C'est un élément très local et on corrige assez simplement : on segmente 
de plus en plus.
Manipuler des segments va demander des évolutions importantes dans les 
outils, j'attends d'abord celle pour les ronds-points.


Marc

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

Re: [OSM-talk-fr] Relations intermédiaires pour les routes de bus ?

[Marc Gauthier via Talk-fr]

Le 02/03/2024 à 18:19, deuzeffe a écrit :
Solution simple suggérée en son temps par un membre du DWG : ne garder 
que les points d'arrêt (stop_position et platform/bus_stop) pour un PTv3.


Sur Rennes à partir de 22 heures il est possible de descendre entre deux 
arrêts, avoir le tracé est un plus dans ce cas.


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

Re: [OSM-talk-fr] Relations intermédiaires pour les routes de bus ?

[Marc Gauthier via Talk-fr]

Bonsoir à tous,

Je suis partagé sur l'intérêt des relations partagées. Si sur certains 
tronçons l'intérêt est évident, j'ai sur la ville de Rennes de nombreux 
tracés qui évoluent très régulièrement et qui d'une fois sur l'autre ne 
partagent plus les mêmes tronçons communs.
La mise à jour dans ce cas sera plus complexe et ne sera possible 
qu'avec de rares outils manipulés par de plus rares initiés.


Marc
PS : j'ai renoncé à cartographier toutes les différentes dessertes, 
certaines lignes en comportent plus de 40.


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

Re: [OSM-talk-fr] public transport edit war in the Nice area

[Marc Gauthier via Talk-fr]

Bonjour à tous,

Vu l'évolution de ce fil de messages, la place de ces échanges ne 
serait-elle pas mieux sur le forum <https://forum.openstreetmap.fr/> ? 
ou en reste en v1 !


Marc

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

Re: [OSM-talk-fr] public transport edit war in the Nice area

[Marc Gauthier via Talk-fr]

Bonsoir à tous,

Je fais partie des utilisateurs des données en opendata pour 
cartographier les lignes de bus.
Je n'ai pas encore trouvé un jeu de données qui donne la position 
d'arrêt d'un bus sur la route (le public_transport=stop_position ?).

N'ayant pas cette information, je ne la cartographie pas !

Sur les signalements d'osmose liés à ces tags j'utilise josm avec une 
orthophoto.
Pour les "The platform is part of a way", la solution est souvent 
d'extraire le nœud et le placer du bon côté de la route.
Pour les "The stop_position is not part of a way", je déplace sur la 
route et je joins le nœud au chemin. Le placement est fait au doigt mouillé.


Marc

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

Re: [OSM-talk-fr] Bretelles d'autoroutes

[Marc Mongenet]

Le dim. 6 nov. 2022 à 16:17, Eric SIBERT  a écrit :

>
> En marge de la discussion sur la vitesse des voies de sortie, je me pose
> des questions sur la modélisation fine des bretelles d'entrée/sortie et
> des échangeurs d'autoroutes et autres voies express. À l'heure du GNSS
> centimétrique, on peut savoir dans quelle voie on circule... si on sait
> où est la voie.
>
> On a des premiers éléments ici:

https://wiki.openstreetmap.org/wiki/FR:Lanes#Autoroute
>
>
Sinon en anglais, qui illustre en plus change:lanes=* pour exprimer les
restrictions imposées par les lignes blanches continues:
https://wiki.openstreetmap.org/wiki/Lanes#Motorway_with_lanes_and_destinations


> Mais ça ne parle pas de où on met le(s) way(s).


Il existe déjà la règle générale qui dit de ne dessiner 2 routes qu'en cas
de séparation physique.
Reste effectivement la question de centrage du segment dans la partie voie
voie de présélection. En général on continue de centrer par rapport aux
voies principales, c'est plus simple. Et un moteur de rendu qui voudrait
être précis pourrait deviner que la voie de présélection se greffe à droite.


> J'avais tendance à
> mettre la voie de sortie dès le début de l'apparition de la voie de
> sortie mais j'accepte le modèle où on ne fait apparaître la nouvelle
> voie que quand commence la ligne continue comme ça:
>
>
> https://wiki.openstreetmap.org/wiki/File:Lane_Placement_Aerial_Example_1.jpeg
>
>
Faire apparaître une nouvelle route quand commence la ligne continue viole
aussi la règle de ne tracer 2 routes qu'en cas de séparation physique.
Je n'interprète cependant pas
https://wiki.openstreetmap.org/wiki/File:Lane_Placement_Aerial_Example_1.jpeg
ainsi. Je dirais plutôt qu'une tangente à la fin de la courbe de la
bretelle a été tracée. On peut aussi penser que ceux qui ont tracé la ligne
blanche sur le terrain se sont aussi basés sur cette tangente.

Je ne vois pas de raison de faire des sorties d'autoroute un cas spécial.
On est dans un cas d'intersection avec une voie de présélection comme il
existe un peu partout: sur autoroute, sur nationale, en ville.

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

Re: [OSM-talk-fr] Bretelles d'autoroutes

[Marc Mongenet]

Le lun. 7 nov. 2022 à 12:34, Georges Dutreix via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

>
> Je suis personnellement pour une représentation la plus simple possible
> (KISS). Les clés lanes et turn:lanes auxquelles on peut éventuellement
> ajouter width:lanes me semblent permettre une représentation extrêmement
> fine de la géométrie des voies. Cela suppose de tracer le highway au
> milieu de la chaussée principale (bande de roulement sans les voies de
> sortie/entrée, d'arrêt d'urgence ou autres),


Pareil.


> et de faire démarrer les
> sorties/entrées à l'extrémité de la ligne continue.
>

Ça dépend. Parfois  la ligne continue s'étend sur bien plus de cent mètres.
La carte montre alors deux chaussées alors qu'il n'y en a qu'une, et elle
introduit une erreur de plus de cents mètres quant à la position de la
séparation des chaussées sur le terrain. Ça commence à faire beaucoup (trop
pour moi qui tique dès qu'il y a plus de quelques décamètres d'imprécision).


> Le seul cas à l'heure actuelle, où je n'ai pas de solution élégante, est
> l'arrivée sur un péage d'autoroute, où on passe graduellement à 12 ou 15
> voies... sachant en plus que sur certains péages, cela change entre les
> départs en vacances et les retours :-)
>
>
Ah oui, les péages, je n'ai jamais su comment faire.

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

Re: [OSM-talk-fr] Bretelles d'autoroutes

[Marc Mongenet]

Le dim. 6 nov. 2022 à 16:17, Eric SIBERT  a écrit :

> On a des premiers éléments ici:
>
> https://wiki.openstreetmap.org/wiki/FR:Lanes#Autoroute
>
> (Et aussi, dans les voies d'autoroute proposées plus haut, on a la zone
> 5 avec ligne continue au milieu mais un seul way.)
>
>
Je ne connaissais pas cet exemple.
J'ai un doute quant aux tags destination qui ne figurent pas dans les
segments 2 et 5. Les destinations restent-elles implicitement tant qu'il y
a le même nombre de lanes? Ou bien est-ce une indication qui n'est que
ponctuellement utile?
Le manque de tag turn:lanes dans le segment 5 ne pourrait-il laisser
faussement penser que tout le monde peut à nouveau aller où il veut, et
donc passer la double ligne blanche continue?

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

Re: [OSM-talk-fr] vitesse limitée a 70 pour les véhicules qui vont utiliser une bretelle de sortie (lanes)

[Marc Mongenet]

Le dim. 6 nov. 2022 à 14:33,  a écrit :

>
> Avant : inutile, c'est le milieu de la bande de roulement.Marc : tu
> parles du milieu de chaussée, en fait c'est de la bande de roulement -
> il doit y avoir un terme plus exact -, on ne tient pas compte des bandes
> d'arrêt d'urgence shoulder=right).
>
>
>
Oui c'est très juste, pour les autoroutes et 2x2 voies avec bande d'arrêt
d'urgence, j'ai toujours vu le filaire placé au milieu de la bande de
roulement, et pas au milieu de la chaussée.

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

Re: [OSM-talk-fr] vitesse limitée a 70 pour les véhicules qui vont utiliser une bretelle de sortie (lanes)

[Marc Mongenet]

Le jeu. 3 nov. 2022 à 22:58,  a écrit :

> Le 03/11/2022 à 21:34, Marc Mongenet - marc.monge...@gmail.com a écrit :
>
> > Enfin, je suppose qu'avec la généralisation des tags lanes et turn:lanes
> > (et peut-être placement dans le futur) cela va être progressivement
> > corrigé, et les lignes blanches ne seront plus utilisées comme
> > pseudo-séparations de voies.
> Les lignes blanches sont des vraies séparations de voies. Mais on est
> plus d'accord que ce que ne semble indiquer cette phrase.
>

Oui je me suis mal exprimé. Ce que je voulais dire, c'est que dans OSM, on
trace deux routes parallèles quand il y a deux chaussées avec une
séparation en dur (un muret, de l'herbe ou une glissière), ce que n'est pas
une ligne peinte.


>
> - tu donnes une règle (les lignes représentant le centre des routes)
> sauf que tu donnes l'image du haut et non celle du bas qui précise "If
> one tries to draw the OSM-way as often as possible in the middle of the
> road".
>
>
Oui en fait c'était l'application correcte de la règle d'angle
d'intersection qui m'intéressait dans
https://wiki.openstreetmap.org/wiki/File:Lane_Placement_Aerial_Example_1.jpeg
(aussi bien que dans
https://wiki.openstreetmap.org/wiki/File:Lane_Placement_Aerial_Example_2.jpeg
).
Concrêtement, je mapperais la sortie 21 ainsi:
https://wiki.openstreetmap.org/wiki/File:Sortie-francilienne-21.png


> Est-ce que la sortie 21 devrait être à la hauteur de la séparation de la
> voie avec "placement=transition" en amont sur la partie entre  2 et 3
> voies ?
>
> Où est le "milieu de la voie" : pour la voie qui continue et a deux
> voies c'est le trait pointillé centre de ces deux voies.
>
>
J'ai toujours hésité avec les milieux de chaussée concernant les autoroutes.
Je fais un peu comme tout le monde en suivant généralement la ligne
centrale, ce qui déroge effectivement à la stricte règle du milieu de
chaussée.
Je fais notamment cela car la bande d'arrêt d'urgence peut être de largeur
irrégulière, et suivre systématiquement le milieu de la chaussée
introduirait des petits virages assez peu compréhensibles.


> Donc pourquoi pas mais il faudrait un exemple clair :
>
> - ou place-t-on le motorway_junction (sortie) : où la voie commence à se
> diviser ? Quand elle se divise ? ÀMHA quand elle commence. Ainsi dans ce
> cas précis la voie principale reste à deux voies.
>

Je ne me souviens pas avoir placé de motorway_junction alors je ne me suis
jamais posé la question.
Dans https://wiki.openstreetmap.org/wiki/Tag:highway=motorway_junction je
lis: This node should be positioned as the last point before the splay at
which it is still possible to make a smooth turn.



> Avoir un simple trait quasi parallèle pour aller de l'endroit où il y a
> 2 voies à l'endroit ou il y en a 2 + 1 serait graphiquement très proche
> et placement=transition et serait suffisant.
>
> D'autres avis plus éclairés ?
>
>
Pour ma part je trace les traits comme dans
https://wiki.openstreetmap.org/wiki/File:Lane_Placement_Aerial_Example_1.jpeg
plutôt que
https://wiki.openstreetmap.org/wiki/File:Lane_Placement_Aerial_Example_2.jpeg
car:
- c'est plus simple
- l'autoroute ne tourne pas
- je trouve que le turn:lanes=none|none|slight_right est suffisamment
explicite

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

Re: [OSM-talk-fr] vitesse limitée a 70 pour les véhicules qui vont utiliser une bretelle de sortie

[Marc Mongenet]

Le jeu. 3 nov. 2022 à 23:42, Marc_marc  a écrit :

> Bonsoir,
>
> Le 03.11.22 à 19:09, didier a écrit :
> > Cf www.mapillary.com/app/?pKey=172038741799101
> >
> > 110 tout droit et 90 pour ceux qui vont emprunter la sortie.
>
> je ne lis pas "90 pour ceux qui *vont* emprunter
> la sortie". mais "90 quand tu *es* sur la bande de sortie".
>
> Cordialement,
> Marc
>
>
>
C'est aussi ce que je comprends de
https://www.equipementsdelaroute.developpement-durable.gouv.fr/IMG/pdf/iisr_1epartie_vc_20210409_cle2b4269.pdf

Dans le cas où on impose une limitation de vitesse sur une voie de
décélération, on peut
exceptionnellement signaler cette prescription par un panneau B14 complété
par un panonceau
directionnel M3a placé sur accotement conformément aux indications données par
l'article 9-1,
paragraphe B.3.a.

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

Re: [OSM-talk-fr] vitesse limitée a 70 pour les véhicules qui vont utiliser une bretelle de sortie

[Marc Mongenet]

Le jeu. 3 nov. 2022 à 20:21,  a écrit :

>
> La vitesse de la voie
> https://www.openstreetmap.org/way/623900993#map=19/48.70338/2.59662 est
>

J'ai une question sans rapport immédiat avec la vitesse, mais avec la façon
bizarre dont la voie de sortie est mappée.
Pourquoi dans les cas d'entrée/sortie, et uniquement dans ces cas à ma
connaissance, voit-on souvent un virage en S être inventé à la jonction
avec la voie principale?
Ça crée des virages qui n'existent pas et donne l'impression erronée qu'il
faut brusquement tourner à droite puis à gauche pour sortir (ou à gauche
puis à droite en arrivant sur la route principale).

L'observation de l'orthophoto donne l'impression que la ligne continue
blanche entre la voie principale et l'entrée/sortie est considérée comme
une séparation de voie. Et dès la fin de la ligne continue, un angle plus
ou moins arbitraire (disons entre 30° et 60°) est imprimé pour rejoindre la
voie principale. Je devine d'ailleurs que le mappeur ne met pas un angle de
90° car il se rend bien compte qu'il est en train de faire qqch d'inélégant.

La règle de mapper le centre de la chaussée, et pas les lignes blanches, me
semble pourtant aussi vieille que OSM.
Il me semble aussi que la règle des jonctions de routes est très ancienne :
on conserve l'angle à l'intersection pour poursuivre tout droit les lignes
représentant le centre des routes.
Bref, il me semble que les règles disent depuis toujours qu'il faut mapper
comme dans
https://wiki.openstreetmap.org/wiki/File:Lane_Placement_Aerial_Example_1.jpeg
.
Dans la même région, on voit d'ailleurs sur
https://www.openstreetmap.org/#map=19/48.67452/2.54959 que l'intersection
entre la rue de Quincy et l'avenue de Jarcy est mappée selon les règles.

Enfin, je suppose qu'avec la généralisation des tags lanes et turn:lanes
(et peut-être placement dans le futur) cela va être progressivement
corrigé, et les lignes blanches ne seront plus utilisées comme
pseudo-séparations de voies.

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

Re: [OSM-talk-fr] Villeurbanne au niveau de zoom 6

[Marc Mongenet]

Le mer. 12 oct. 2022 à 23:09, Rene Chalon  a écrit :

> Re-bonsoir,
>
> On 12/10/2022 22:52, osm.sanspourr...@spamgourmet.com wrote:
> >
> > Et ici pour éviter que Lyon et ARA ne soient affichés au même endroit.
> >
> > Sans doute faut-il décaler plus le texte vers le sud-ouest (autant
> > laisser les locaux juger où le placer).
>
> Il y a longtemps que j'ai déplacé le label d'AURA plus au sud vers
> Annonay mais visiblement l'algo de rendu n'est tient pas compte :
> https://www.openstreetmap.org/relation/3792877#map=7/45.302/5.982
>
>
 CyclOSM et le rendu humanitaire semblent en revanche en tenir compte.


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

Re: [OSM-talk-fr] Villeurbanne au niveau de zoom 6

[Marc Mongenet]

Bonjour

Le mer. 12 oct. 2022 à 23:21, Marc_marc  a écrit :

>
> > marquer le nœud de Villeurbanne comme "place=town" et on aurait plus de
> conflits.
>
> je suis peut-être le cartographe zelé dont tu parles :) dont
> le changement de tag pour le rendu n'enchante guerre !
>

Je trouve extrêmement cavalier d'écrire "tag pour le rendu" tout en
omettant l'argumentaire qui montrait qu'il ne s'agit pas de cela:
"Use the place=city tag to identify the largest settlement or settlements
within a territory, including national, state and provincial capitals, and
other major conurbations." Il serait donc
logique d'avoir uniquement "Lyon" comme "place=city".

Je pense aussi depuis longtemps qu'il serait logique que seul Lyon soit
"city".

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

[OSM-talk-fr] Villeurbanne au niveau de zoom 6

[Marc Mongenet]

Bonjour,

J'ai remarqué que le rendu par défaut de https://www.openstreetmap.org au
niveau de zoom 6 affichait "Villeurbanne" au lieu de "Lyon". Je suppose que
c'est dû au fait que la place de "Lyon" est prise par
"Auvergne-Rhône-Alpes". Est-il possible de déplacer le texte
"Auvergne-Rhône-Alpes"? J'ai l'impression que c'est positionné par un
label. Pourquoi ne pas simplement supprimer le label?

Toujours à propos de "Villeurbanne", le rendu CyclOSM place "Villeurbanne"
un vingtaine de kilomètres au sud de "Lyon" en zoom 8. Mais je suppose
qu'il s'agit là d'un bug dans l'algorithme de placement, n'est-ce pas?

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

Re: [OSM-talk-fr] Comment faire? forêt broadleaved & needleleaved

[Marc Mongenet]

Bonjour

Le jeu. 8 sept. 2022 à 17:19, Marc_marc  a écrit :

> Bonjour,
>
> Le 07.09.22 à 21:02, Marc Mongenet a écrit :
> > relation type=site qui représente et fait exactement
> > ce qu'il faut.
>
> https://wiki.openstreetmap.org/wiki/Relation:site#Rationale
> pour les cas oü l'objet ne peux pas être représenté
> par une géométrie ou par des multipolygone :)
> ex : les noeuds d'un parc éolien
>

Pour mon marais ça tombe bien puisque je ne pouvais pas le représenter par
une géométrie (j'ai besoin de plusieurs (natural=wetland;wetland=swamp) et
(natural=wetland;wetland=reedbed), ni par un multipolygone (car pour une
obscure raison les polygones d'un multipolygone ne doivent pas partager des
côtés).
Et puis la restriction "ne peux pas être représenté par" me paraît trop
arbitraire pour être respectée sans autre motivation.

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

Re: [OSM-talk-fr] Comment faire? forêt broadleaved & needleleaved

[Marc Mongenet]

Bonjour

Le mar. 6 sept. 2022 à 07:19, David Marchal via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

>
> Comme une telle forêt n’est pas nécessairement intégralement boisée ou
> même intégralement exploitée, je n’ai pas trouvé mieux que découplér sa
> représentation des landuse=forest/natural=wood. De plus, boundary=forest
> tel qu’approuvé me semble correspondre aux besoins de Marc Mongenet.
>
>
En fait, pour l'instant, je n'ai eu besoin de nommer qu'un marais. Et j'ai
finalement utilisé une relation type=site qui représente et fait exactement
ce qu'il faut.

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

Re: [OSM-talk-fr] Comment faire? forêt broadleaved & needleleaved

[Marc Mongenet]

Bonjour,

Le lun. 5 sept. 2022 à 07:21, David Marchal via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Bonjour, Marc.
>
> C’est précisément pour ce genre de cas que j’avais conçu le tag
> boundary=forest (cf
> https://wiki.openstreetmap.org/wiki/Tag:boundary=forest?uselang=fr pour
> plus d’info) : tu cartographies le terrain avec landuse=forest,
> natural=wetland, natural=grassland… avec autant de polygones différents
> qu’il le faut pour représenter le terrain (par exemple les variations de
> leaf_type), puis tu ajoutes par dessus un (multi)polygone type=boundary +
> boundary=forest + name=… pour représenter le fait que l’ensemble est une
> seule et unique forêt, en dépit des variations de terrain, et quand bien
> même le terrain n’est pas landuse=forest ou natural=wood (clairières, zones
> marécageuses, étangs…).
>
>
Oui, cela semble correspondre exactement à ce que je cherche, au petit
détail près que j'en ai d'abord besoin pour un marais (boundary=wetland ?).


> Un exemple ici : https://www.openstreetmap.org/j'attendrelation/13897472
> <https://www.openstreetmap.org/relation/13897472>
>
> Soit dit en passant, on peut constater la mauvaise circulation des infos
> dans l’écosystème OSM : ce tag a été approuvé il y a des mois, à la
> troisième proposition avec la première datant de près de deux ans
> maintenant, et pourtant sa simple existence n’est généralement pas connue.
> Certes, l’écosystème OSM est complexe, mais il n’empêche…
>

Je remarque que le nom de la forêt n'apparaît pas sur la carte. S'il n'y a
aucun rendu, question circulation de l'information, c'est presque comme si
le tag n'existait pas.

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

Re: [OSM-talk-fr] Comment faire? forêt broadleaved & needleleaved

[Marc Mongenet]

Le dim. 4 sept. 2022 à 21:42,  a écrit :

> Pourquoi ne pas faire une "bonne grosse" forêt nommée avec mixed et des
> sous-parties sans nom et de même clé principale avec les deux types de
> plantations ?
>
> Jean-Yvon
>
>
Et bien le mixed ne fonctionne pas dans le cas de la zone humide.
Et puis si la forêt n'a aucune zone mixed, mais des zones bien délimitées
de needleleaved (plantation d'épicéas par exemple) et de broadleaved, ça ne
fonctionne pas non plus.
Et surtout, je veux qu'à la fin, quand on recherche le nom de la forêt, ça
entoure toute la forêt. Et je veux aussi que le nom de la forêt apparaisse
dessus, bien centré, et d'une taille proportionnelle à la forêt. Bref, je
cherche une solution propre, pas une bidouille.
Je pensais au multipolygone qui entoure tout, comme suggéré par
pepilepi...@ovh.fr, mais alors je suppose que le nom de la forêt (du
marais) sera rattaché à un multipolygone sans attribut et ne représentera
rien, n'est-ce pas ?

Marc Mongenet


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

Re: [OSM-talk-fr] Comment faire? forêt broadleaved & needleleaved

[Marc Mongenet]

Mouais, le place=locality n'est pas du tout satisfaisant. Déjà, c'est un
tag pour le rendu.
Et en plus ça ne donne pas le bon rendu aussi bien au niveau taille que
couleur des caractères.

Pour ce qui est du landuse=forest vs natural=wood, comme je m'occupe
énormément d'occupation des sols, j'utilise landuse pour residential,
vineyard, farmland, farmyard, meadow, quarry... du coup je reste dans le
landuse pour forest par habitude. Cela dit, j'utilise occasionnellement
natural=wood lorsqu'il y a des arbres si serrés dans un autre landuse que
ça forme un petit bois. Par exemple dans du residential.

Marc Mongenet

Le dim. 4 sept. 2022 à 20:19, Marc_marc  a écrit :

> Bonjour,
>
> Le 04.09.22 à 20:07, Marc Mongenet a écrit :
> > Comment mapper une forêt dont certaines parties sont broadleaved et
> > d'autres needleleaved?
> > Tout cela en donnant un nom unique à la forêt.
>
> un place=locality pour le nom
> des natural=wood pour les zones boisées broadleaved et needleleaved
>
> > Le plus logique serait un grand landuse=forest
>
> non landuse=forest n'a rien de logique :)
> landuse c'est forestry ou loisir ou chasse ou un peu tout cela à la fois
>
> > même question se pose pour une zone humide natural=wetland
> > avec des parties wetland=swamp et d'autres wetland=reedbed.
>
> des natural=wetland pour les différents sous-type
> et un objet place=locality pour héberger le nom
>
> Cordialement,
> Marc
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Comment faire? forêt broadleaved & needleleaved

[Marc Mongenet]

Bonjour

Comment mapper une forêt dont certaines parties sont broadleaved et
d'autres needleleaved?
Tout cela en donnant un nom unique à la forêt.
Le plus logique serait un grand landuse=forest name=Foo avec des parties
leaftype=broadleaved et d'autres leaftype=needleleaved. Mais ça ne semble
pas prévu par OSM.

Un pis-aller possible avec les forêts serait leaftype=mixed. Mais la même
question se pose pour une zone humide natural=wetland avec des parties
wetland=swamp et d'autres wetland=reedbed.

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

Re: [OSM-talk-fr] Bonnes pratiques pour la délimitation des landuse et autres natural ?

[Marc Mongenet]

Le mar. 12 juil. 2022 à 20:29,  a écrit :


>
> Le 12/07/2022 à 19:40, Marc Mongenet - marc.monge...@gmail.com a écrit :
> > Grâce à une magnifique orthophoto d'hiver, je pense arriver à un mètre de
> > précision sur les limites de forest dans le canton de Genève.
>
> Tu as de la chance de vivre dans une zone ou le contraste peut être fort
> en hiver, où les arbres en hiver offrent une telle transparence et
> d'avoir une telle ortho.
>
> Si tu peux le faire proprement, je n'ai rien contre.
>
> Ce qui me déplait c'est de fabriquer de la fausse information au
> prétexte que c'est plus rigoureux d'un point de vue topologique.
>
>
Oui, la fausse information est un vrai problème, il y a d'ailleurs eu une
discussion à ce propos tout récemment dans la mailing list suisse.


> Un autre soucis c'est qu'on n'a pas une rigueur constante concernant les
> landuse, on le voit souvent au niveau des residential en zone rurale où
> les limites sont les parcelles ou le bâti ou quelque chose d'approximatif.
>
>
La précision variable est un problème général. Avec une bonne ortho on
arrive à une précision de 5-10 cm pour les routes, et encore, les chemins
de fer. Mais dans une vallée reculée à l'ombre, on n'arrive pas toujours à
voir les routes, sans parler des pistes en forêt.


>
> Pas vraiment car dans les cas simples (je ne parle pas d'autoroute mais
> de route de campagne, de chemins), la largeur de la route définit
> l'emprise.
>
>
C'est peut-être propre à certaines régions, mais avec les fossés et talus,
l'infrastructure routière est facilement 50% à 100% plus large que le
goudron. Après, il y en a qui mettent un landuse=grass sur cette partie. :-)

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

Re: [OSM-talk-fr] Bonnes pratiques pour la délimitation des landuse et autres natural ?

[Marc Mongenet]

Le lun. 11 juil. 2022 à 18:50,  a écrit :

> Le 11/07/2022 à 16:41, Marc_marc - marc_m...@mailo.com a écrit :
>
> >
> > PS: on le fait correctement avec les landuse=railway : le champs ne va
> > pas jusqu'au milieu des rails
> >
> > niveau pratique : faire une bonne géométrie pour la route, dupliquer
> > 2x la route et décaler les copies de la largeur de l'emprise routière,
> > cela fait souvent une très bonne géométrie de départ en peu de temps
>
> Pas trop d’accord. Le « problème » est celui soulevé par David : la
> route est modélisée en filaire et les landuse en surfacique.
>
>
Quand on arrête le landuse=farmland là où s'arrête le champ, alors le vide
autour du filaire de la route correspond simplement à ce que serait un
landuse=highway s'il existait dans OSM. Je me demande d'ailleurs depuis
longtemps pourquoi il n'existe pas de landuse=highway.


> Tant qu’on fait ça, la représentation la plus logique est de faire aller
> les landuse jusqu’à la route. Et c'est parce que du as des
> landuse=railway que tu ne vas pas jusqu'au rails.
>

Ce n'est pas parce qu'on n'a pas de landuse=highway que l'on doit faire
déborder les autres landuse.
Cela dit, je vais jusqu'au fil pour les track, et très occasionnellement
pour des petites routes, mais c'est hors de question pour les autoroutes.


> Et si plus tard on veut faire du surfacique pour la route, alors on va
> arrêter le surfacique des côtés au surfacique de la route (comme c’est
> fait pour les rails).
>

Il ne s'agit pas de surfacique pour la route, mais pour l'infrastructure
routière, qui est généralement plus large (beaucoup plus dans le cas d'un
échangeur autoroutier).


> Mettre une largeur (width=) à une route tout en conservant le filaire me
> semble préférable : la cartographie c’est une modélisation du monde, pas
> du dessin.
>

Oui, le width manque à la plupart des routes, c'est bien dommage, mais
c'est sans rapport avec les landuse.


> Je mets au défi quiconque de faire proprement du surfacique quand la
> route longe une forêt : pour que ce soit propre vous allez partir du
> centre de la route et dériver les limites via la largeur
> (essentiellement constante) de la route, vous n’allez pas essayer
> d’estimer la limite de la forêt par les troncs ou le houppier.
>

Grâce à une magnifique orthophoto d'hiver, je pense arriver à un mètre de
précision sur les limites de forest dans le canton de Genève. Ça dépend des
circonstance: au bord d'une route la limite de la forêt est souvent très
nette, c'est moins clair au bord d'un pré.

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

Re: [OSM-talk-fr] Bonnes pratiques pour la délimitation des landuse et autres natural ?

[Marc Mongenet]

Le lun. 11 juil. 2022 à 16:13, Volker Schmidt  a écrit :

> Je suis dans le "métier" des voies cyclables, lesquelles souvent, en un
> premier instant sont taggués sur la route avec cycleway=track. Dans une
> deuxième phase on ajoute la cyclable comme way séparé et les landuse
> attaqués à la route te rendent fou.
> Et on peut aussi penser à ajouter des guardrails ou des murs ecc.
>
>
>
De même, j'évite de coller les landuse aux routes car ça rend la
maintenance plus difficile.
Le pire du pire étant les landuse en multipolygone qui réutilisent des
segments de routes, d'autres landuse, etc.
Je n'ai jamais réussi à les modifier significativement, et quand je dois le
faire, je supprime le multipolygone et reprend tout à zéro.
Je suppose que ça s'appelle mapper pour la maintenance. :-) A moins que ce
soit dû à mon incompétence avec les multipolygon. Je ne sais pas.

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

Re: [OSM-talk-fr] Flopées de highway=pedestrian qui n'en sont pas

[Marc Mongenet]

Le lun. 27 juin 2022 à 20:57, Ralf Treinen  a écrit :

> Bonsoir,
>
> On Mon, Jun 27, 2022 at 06:54:00PM +0200, deuzeffe wrote:
>
> > tombe sur des flopées de highway=pedestrian qui n'en sont pas, toujours
> > mappées par la même personne.
> >
> > Ça peut être un bout d'herbe en bordure de voie :
> > https://www.openstreetmap.org/way/904660169
> > ou un grand trottoir :
> https://www.openstreetmap.org/way/905604363/history
> > ou https://www.openstreetmap.org/way/905538162
> >
> > On est bien d'accord que le tagging n'est pas correct ?
>
> Plutot mettre "highway=footway" et "footway=sidewalk", plus "area=yes"
> le cas du surfacique échéant. Voir
>
> https://wiki.openstreetmap.org/wiki/FR:Trottoirs
>
> "highway=pedestrian" est pour les rues qui sont principalement pour des
> pietons :
>
> https://wiki.openstreetmap.org/wiki/FR:Tag:highway%3Dpedestrian
>
>
Oui, highway=pedestrian est une rue indépendante des autres, avec un nom,
et qui a souvent été une rue ouverte au trafic motorisé dans le passé.
Je vois plus highway=footway pour les allées et sentiers réservés aux
piétons, qui sont souvent anonymes.
Et pour le cas d'une aire comme
https://www.openstreetmap.org/way/905604363/history, comme elle est
dépendante de la rue, j'aurais mis highway=footway area=yes. Cela dit, j'ai
plus l'habitude de mapper la campagne et d'utiliser des highway=path et
highway=track.

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

Re: [OSM-talk-fr] MS BOT

[Marc SIBERT]

Bonjour,

Sur ce point, je vais faire un "revert" sur Bel-Air et supprimer cette 
"correction".


Marc

Le 25/02/2022 09:43, leni a écrit :

Le 24/02/2022 à 20:51, osm.sanspourr...@spamgourmet.com a écrit :

Je crois que le Topographe Fou a été clair : pour La/la c'est clair :


Ok c'est clair !!!

Wikipedia n'est pas tout à fait d'accord avec le Larousse, en ce qui
concerne son nom "Delatour" présent sur les actes officiel
(https://www.larousse.fr/encyclopedie/peinture/Maurice_Quentin_Delatour_dit_Maurice_Quentin_de_La_Tour/152910)

Par contre en ce qui concerne :
https://fr.m.wikipedia.org/wiki/Bel_Air, puisque les deux orthographes
coexistent, il me semble que le local doit avoir la préférence : dans
ce cas "Chemin de Bel Air"







Et pour https://www.openstreetmap.org/way/23605881 le trait d'union 
a

été ajouté alors que :
"source:name=panneaux sur place pas de trait d'union"

  * il semble y avoir un trait d'union sur le calque du cadastre
  * il n'y en a pas si on consulte une parcelle du cadastre (CHE DE 
BEL
    AIR) le fichier BANO (310560018A|A|CHE|DE BEL AIR) et sur place 
j'ai

    la photo du panneau

Il me semblait que le terrain était la référence.

bonne soirée

leni


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


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

Re: [OSM-talk-fr] MS BOT

[Marc SIBERT]

Bonjour,

On est ok alors puisque mes règles sont :

(?i)^(.+)\bde\sla\sTour\b(.*)$,\1de la Tour\2
(?i)^(.+)\bLouise[\s-][Éée]milie\sde\sLa\sTour\sd'Auvergne(.*)$,\1Louise-Émilie 
de La Tour d'Auvergne\2

(?i)^(.+)\bde\sla\sTour\sBoileau\b(.*)$,\1de la Tour Boileau\2
(?i)^(.+)\bGeorges\sde\sLa\sTour\b(.*)$,\1Georges de La Tour\2
(?i)^(.+)\bQuentin\sde\sLa\sTour\b(.*)$,\1Quentin de La Tour\2
(?i)^(.+)\bMaurice[\s-]Quentin\sde\sLa\sTour\b(.*)$,\1Maurice-Quentin de 
La Tour\2


qui se lisent 'la Tour' en cas général et 'La Tour' quand c'est associé 
avec Louise, Georges, Quentin ou Maurice


Marc
---
Marc SIBERT
m...@sibert.fr

Le 24/02/2022 20:51, osm.sanspourr...@spamgourmet.com a écrit :

Je crois que le Topographe Fou a été clair : pour La/la c'est clair :
*SI* c'est une partie de nom de famille c'est avec une majuscule.

*SI* c'est par rapport à un lieu-dit c'est en minuscule, style Rue de 
la

Tour d'Argent.

Tant que tu le fais à la main, tu dois pouvoir trouver s'il est 
question

d'une personne (présence d'un prénom par exemple) ou pas.

Pareil pour de/De : si tu ne sais pas, tu ne changes pas.

Par contre tu peux demander aux locaux (note, fixme) et regarder
l'historique.

Jean-Yvon

Le 24/02/2022 à 13:47, Marc SIBERT - m...@sibert.fr a écrit :

Bonjour,

So what ? Je suis preneur d'une conclusion claire pour encoder une
correction cohérente et applicable sur une base nationale. Et s'il n'y
en a pas, ben je vais continuer à corriger "La Tour" puisque c'est pas
juste mais c'est pas faux non plus.

A++

---
Marc SIBERT
m...@sibert.fr

Le 23/02/2022 19:58, Topographe Fou a écrit :

Bonjour,

En effet le "La" n'est pas (jamais ?) une particule. Une particule ne
prends pas de majuscule car ne fait pas historiquement partie du nom
de famille (qui lui prends une voir des majuscules). On parle
d'ailleur de la famille La Tour (et non pas de la famille de La 
Tour).

Cela est également en cohérence avec la règle rendue quasi inconnue à
cause de l'informatique qui veut que la particule ne rentre pas dans
le tri alphabétique (donc à classer à L et non D dans l'exemple qui
nous occupe). J'avais eu l'occasion de développer un algo de tri qui
en tienne compte, c'est un challenge assez intéressant.

Cela étant dit il n'est pas rare de voir des erreurs dans les
documents officiels, avec des majuscules aux particules. C'est très
souvent des erreurs dûes à des saisies plus ou moins automatisées (il
suffit aussi de voir les fautes dans les prénoms ou noms...), à des
gens ignorant cette particularité de notre culture française ou
souhaitant la voir disparaître.

Après comme toujours il peut y avoir des exceptions... Mais qui ne
font pas la règle.

LeTopographeFou


  Message original


De: lenny.li...@orange.fr
Envoyé: 23 février 2022 7:04 PM
À: talk-fr@openstreetmap.org
Répondre à: talk-fr@openstreetmap.org
Objet: Re: [OSM-talk-fr] MS BOT



Le 23/02/2022 à 15:15, Marc SIBERT a écrit :

J'ai mis à jour la page Wiki ;-)
Et oui https://fr.wikipedia.org/wiki/Quentin_de_La_Tour prend une
majuscule à 'La'.


Même quand le cadastre n'en met pas ? Je ne suis pas allé voir sur
place, j'irais


Et pour https://www.openstreetmap.org/way/23605881 le trait d'union a
été ajouté alors que :
"source:name=panneaux sur place pas de trait d'union"

  * il semble y avoir un trait d'union sur le calque du cadastre
  * il n'y en a pas si on consulte une parcelle du cadastre (CHE DE 
BEL
    AIR) le fichier BANO (310560018A|A|CHE|DE BEL AIR) et sur place 
j'ai

    la photo du panneau

Il me semblait que le terrain était la référence.

bonne soirée

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


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




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


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

Re: [OSM-talk-fr] MS BOT

[Marc SIBERT]

Bonjour,

So what ? Je suis preneur d'une conclusion claire pour encoder une 
correction cohérente et applicable sur une base nationale. Et s'il n'y 
en a pas, ben je vais continuer à corriger "La Tour" puisque c'est pas 
juste mais c'est pas faux non plus.


A++

---
Marc SIBERT
m...@sibert.fr

Le 23/02/2022 19:58, Topographe Fou a écrit :

Bonjour,

En effet le "La" n'est pas (jamais ?) une particule. Une particule ne
prends pas de majuscule car ne fait pas historiquement partie du nom
de famille (qui lui prends une voir des majuscules). On parle
d'ailleur de la famille La Tour (et non pas de la famille de La Tour).
Cela est également en cohérence avec la règle rendue quasi inconnue à
cause de l'informatique qui veut que la particule ne rentre pas dans
le tri alphabétique (donc à classer à L et non D dans l'exemple qui
nous occupe). J'avais eu l'occasion de développer un algo de tri qui
en tienne compte, c'est un challenge assez intéressant.

Cela étant dit il n'est pas rare de voir des erreurs dans les
documents officiels, avec des majuscules aux particules. C'est très
souvent des erreurs dûes à des saisies plus ou moins automatisées (il
suffit aussi de voir les fautes dans les prénoms ou noms...), à des
gens ignorant cette particularité de notre culture française ou
souhaitant la voir disparaître.

Après comme toujours il peut y avoir des exceptions... Mais qui ne
font pas la règle.

LeTopographeFou


  Message original  


De: lenny.li...@orange.fr
Envoyé: 23 février 2022 7:04 PM
À: talk-fr@openstreetmap.org
Répondre à: talk-fr@openstreetmap.org
Objet: Re: [OSM-talk-fr] MS BOT



Le 23/02/2022 à 15:15, Marc SIBERT a écrit :

J'ai mis à jour la page Wiki ;-)
Et oui https://fr.wikipedia.org/wiki/Quentin_de_La_Tour prend une
majuscule à 'La'.


Même quand le cadastre n'en met pas ? Je ne suis pas allé voir sur
place, j'irais


Et pour https://www.openstreetmap.org/way/23605881 le trait d'union a
été ajouté alors que :
"source:name=panneaux sur place pas de trait d'union"

  * il semble y avoir un trait d'union sur le calque du cadastre
  * il n'y en a pas si on consulte une parcelle du cadastre (CHE DE BEL
    AIR) le fichier BANO (310560018A|A|CHE|DE BEL AIR) et sur place 
j'ai

    la photo du panneau

Il me semblait que le terrain était la référence.

bonne soirée

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


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

Re: [OSM-talk-fr] MS BOT

[Marc SIBERT]

Bonjour à tous,

Oui pardonnez moi parce que j'ai péché ! J'ai rien demandé avant de 
lancer des corrections, que je valide unitairement dans JOSM avant de 
les envoyer.
Pour le moment, je me limite aux noms des voies (way, highway, name), 
(node, addr:street), (relations name) pour rester cohérant. Je me limite 
à la surface France Continentale. Les règles sont dans ce fichier : 
https://raw.githubusercontent.com/Marcussacapuces91/Check-OSM/main/invalid_ways_name.csv


Vous pouvez envoyer des "pull-request" et même tester le code en local 
(les corrections de sont appliquées que lorsque vous validez dans JOSM - 
télécommande obligatoire).


J'ai mis à jour la page Wiki ;-)
Et oui https://fr.wikipedia.org/wiki/Quentin_de_La_Tour prend une 
majuscule à 'La'.


N'hésitez pas à me faire vos remarques.

Ah ! Cette fois le code est libre et disponible : 
https://github.com/Marcussacapuces91/Check-OSM


A++

Marc & MS_BOT

---
Marc SIBERT
m...@sibert.fr

Le 23/02/2022 14:34, Vincent de Château-Thierry a écrit :

Bonjour,


De: "lenny.libre" 

Je vois depuis quelques temps des mises à jour de
https://www.openstreetmap.org/user/MS%20BOT/history sur tout le
territoire en mettant comme unique commentaire "Corrections sur France 
"


En a-t-il parlé quelque part ? je n'ai rien vu !!!


Rien vu de récent non plus, mais sa page parle de 2022 :
https://wiki.openstreetmap.org/wiki/MS_BOT
Derrière ce bot c'est Marc Sibert (initiales MS). Peut-être lit-il
encore cette liste, et sinon joignable via la page de discussion de
MS_BOT sur le wiki.

J'ai trouvé une des corrections (il y en a peut-être d'autres) qui 
n'est

pas conforme à
https://wiki.openstreetmap.org/wiki/FR:Toponymes,_odonymes#Majuscules.2C_minuscules_et_trait_d.27union
"les articles ... prennent ... une minuscule à l'intérieur du nom ..."

https://www.openstreetmap.org/way/307914880/history : "Place Quentin 
de

*l*a Tour" a été remplacé par "Place Quentin de *L*a Tour"


Si Wikipedia ne se trompe pas, alors la correction est valide :
https://fr.wikipedia.org/wiki/Quentin_de_La_Tour

vincent

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


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

Re: [OSM-talk-fr] Open Street Misogynie ? inclusif ?

[Jean-Marc Liotier]

On 12/11/20 4:14 PM, FR via Talk-fr wrote:
Il y a quand même une phrase qui m’a fait tiquer dans ce fil : "une 
femme qui s'en plaint sera étiquetée emmerdeuse féministe". Cher ami 
quels clichés ! (c'est bien connu dans les cours d'écoles les filles 
ce sont que des pisseuses). Les femmes et les féministes (garçons et 
filles) ne sont pas dans le registre de la plainte mais plutôt dans 
celui revendication du droit à l'égalité. En dans ce contexte se faire 
traiter d’emmerdeuse c’est plutôt compliment. 


Ce cliché (je suis l'auteur de la phrase, plus haut dans le thread) a 
malheureusement toujours cours. Je suis représentant du personnel... 
Entre représentants du personnel, être traité d'emmerdeur est une forme 
compliment - mais vu de la direction nettement moins. La même chanson ne 
fera pas vibrer les deux publics de la même manière. Aller au carton 
avec la direction sous les encouragements des collègues du syndicat est 
une gloire coûteuse - et surtout vaine lorsqu'on est minoritaire. Mon 
propos n'est pas de juger la légitimité de la revendication mais d'en 
considérer la stratégie.



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

Re: [OSM-talk-fr] Open Street Misogynie ?

[Jean-Marc Liotier]

On 12/10/20 2:55 PM, Baptiste Lemoine - Cipher Bliss wrote:

Aucune ne le fera - et pour cause: une femme qui s'en plaint sera étiquetée 
emmerdeuse féministe. Ça fait partie du problème.

sauf si personne n'est là pour dire que le féminisme emmerde la communauté OSM, 
voire - syons fous - que c'est un combat qui est soutenu officiellement et que 
nous ne tolérerons pas les comportements qui iraient à l'encontre de cela.


Le silence des détracteurs n'empêche pas l'ostracisme - c'est la 
situation courante en entreprise. Les plus hardies se réfugient derrière 
un mandat syndical et s'auto-placardisent au passage, les autres 
finissent par partir et seules restent quelques spécimen avec des 
piquants et quelques autres renfermées dans leur résignation.


Le soutien officiel explicite est un bon début - c'est même la condition 
de tout autre progrès. Dans le milieu de l'informatique, on entend 
encore des blagues misogynes ou homophobes - pour se sentir légitime à 
en faire remarque à leur auteur, même un homme a besoin de d'appui, 
surtout lorsque l'auteur lui est hiérarchiquement supérieur.



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

Re: [OSM-talk-fr] Open Street Misogynie ?

[Jean-Marc Liotier]

On 12/10/20 2:07 PM, Baptiste Lemoine - Cipher Bliss wrote:

J'ai hâte qu'une femme donne son avis sur la mysoginie dans la communauté OSM.


Aucune ne le fera - et pour cause: une femme qui s'en plaint sera 
étiquetée emmerdeuse féministe. Ça fait partie du problème.




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

Re: [OSM-talk-fr] Open Street Misogynie ?

[Jean-Marc Liotier]

On 12/10/20 12:35 PM, Christian Quest wrote:
Depuis hier, il y a des échanges assez rudes sur la misogynie qui 
régnerait dans la communauté OSM ("systemic behavior").


Je crois que la campagne électorale n'est pas étrangère à la relance de 
ce débat par nos amis Américains dans la nébuleuse autour de HOT et à la 
manière exaltée dont il est présenté: je soupçonne qu'il s'agit d'une 
manœuvre consciemment destinée à presser le leadership plutôt Européen 
d'Openstreetmap en s'appuyant sur le réseau international autour de HOT, 
dont les intérêts ne sont pas tout à fait alignés avec ceux 
d'Openstreetmap en tant que projet de logiciel libre.


Ce n'est pas la première fois que le sujet est posé et c'est normal 
que la question se pose quand on voit la répartition hommes/femmes au 
sein du projet, quel que soit le niveau où l'on regarde.


Le problème dépasse Openstreetmap. Dans l'industrie logicielle et dans 
les télécommunications j'ai toujours eu la chance d'avoir des employeurs 
s'efforçant de recruter des femmes, mais c'est toujours un effort 
conscient car la situation par défaut est 90% masculine. Notre société 
se prive des contributions de celles qu'elle ne parvient pas à inclure. 
C'est un problème profond, d'ordre culturel - je n'ai pas de recette 
immédiate pour le résoudre, mais j'estime que nous devons faire un 
effort conscient pour en comprendre les ressorts et les traiter... Mais 
pas de manière caricaturale.




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

Re: [OSM-talk-fr] addok et demo.addok.xyz : géocodage avec données OSM

[Jean-Marc Liotier]

On 11/24/20 6:22 PM, Frédéric Rodrigo wrote:
Ce n'est pas aussi facile que ça pour faire une emprise mondiale. Il 
est nécessaire d'écrire des adaptateurs pour chaque langue ou pays 
pour traiter les particularités.


Je découvre donc:

- La phonemicization: 
https://github.com/addok/addok-fr/blob/master/addok_fr/utils.py


- Les particularités Françaises: 
https://github.com/addok/addok-france/blob/master/addok_france/utils.py


On comprend vite qu'il sera compliqué d'accepter une recherche sans 
connaître dans quel zone administrative et linguistique elle s'inscrit...



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

Re: [OSM-talk-fr] addok et demo.addok.xyz : géocodage avec données OSM

[Jean-Marc Liotier]

On 11/23/20 10:32 PM, Christian Quest wrote:
L'index redis occupe dans les 16Go de RAM, la base sqlite 2Go, elle 
aussi en RAM pour un max de perfs.
Pour la France seulement... Ca apporte d'un coup tous ce dont l'absence 
frustre dans Nominatim - mais c'est un sérieux investissement en 
matériel pour une emprise mondiale... Même problème que la mise à 
disposition de tuiles: vitrine indispensable mais qui risque d'être 
considéré comme un service public.


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

Re: [OSM-talk-fr] addok et demo.addok.xyz : géocodage avec données OSM

[Jean-Marc Liotier]

On 11/23/20 7:17 PM, leni wrote:

Le 23/11/2020 à 09:55, Cyrille37 OSM via Talk-fr a écrit :

Le 22/11/2020 à 20:02, Christian Quest a écrit :
https://demo.addok.xyz/ où vous pouvez tester l’auto-complétion avec 
préférence géographique centrée sur la carte.


Wouah !!

Ça dépote! Et tolérant o fotes d'ortogafe. J'adore :-)
+1, sans les accents, sans apostrophes, sans les articles, centré à 
l'autre bout de la France et il trouve instantanément : j'adopte


Impressionnant. C'est gourmand ?



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

Re: [OSM-talk-fr] Élection Fondation OSM

[Jean-Marc Liotier]

J'en profite pour signaler ma candidature - à ceux que j'ai déjà 
rencontré aux SOTM, SOTM-FR et autres rencontres locales, et à ceux que 
je n'ai pas encore eu la chance de croiser. La semaine prochaine je 
posterai mes réponses aux questions officielles posées par l'OSMF aux 
candidats - si par la suite vous souhaitez rebondir dessus en Français, 
je serai ravi de converser ici !



On 11/19/20 12:57 PM, Vincent Bergeot wrote:

Bonjour,

la liste officielle des questions posées aux candidats est finalisée 
depuis hier en anglais 
(https://wiki.openstreetmap.org/wiki/Talk:Foundation/AGM20/Election_to_Board).


Il y a 7 candidats pour 3 sièges si j'ai tout compris.

Voici la liste des candidats comportant les liens vers leur compte OSM 
et wiki : 
https://wiki.openstreetmap.org/wiki/Foundation/AGM20/Election_to_Board#List


à vos analyses (ne cherchez pas les femmes, il n'y en a pas) !




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

Re: [OSM-talk-fr] OSMF 2020 entre inquiétude et déception

[Jean-Marc Liotier]

Le "Is responsible for allocating $$ to diverse worthwhile software 
projects with grants and microgrants" de 
https://wiki.osmfoundation.org/wiki/Mission_Statement me gène également 
beaucoup. Je vois la Fondation comme arbitre de conflits et garant 
ultime de la license - or on sent le glissement vers ce qui pourrait 
finir par ressembler à la Mozilla Foundation - une course en avant dans 
toutes les directions en même temps plutôt que la dalle stable sur 
laquelle repose tout le reste.




On 10/22/20 10:03 PM, severin.menard via Talk-fr wrote:

Bonjour,

Pour info, pour celles et ceux qui ne seraient pas membres de l'OSMF, 
j'ai publié cet article sur sa liste de discussion : 
https://lists.openstreetmap.org/pipermail/osmf-talk/2020-October/007294.html
et également sur mon journal OSM : 
https://www.openstreetmap.org/user/SeverinGeo/diary


Les retours (positifs ou négatifs) sont toujours bienvenus.



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

Re: [OSM-talk-fr] rues en landuse residential

[Marc Mongenet]

Bonjour

Le sam. 12 sept. 2020 à 14:40, Georges Dutreix via Talk-fr
 a écrit :
>
> Je viens de tomber sur ça à La Ciotat : 
> https://www.openstreetmap.org/way/433148353/history#map=18/43.17743/5.60195
> une emprise de rue en landuse=residential
>
> Tout le quartier est comme ça, je trouve ça assez lourd, et ça me semble même 
> être un contresens puisque la zone "résidentielle" serait justement toute la 
> zone en dehors de l'emprise des rues et trottoirs.
>
> Qu'en pensez-vous ?
> Doit-on laisser tel quel ? le signaler à l'auteur puis corriger ?

Je fais beaucoup de landuse, mais je n'ai jamais fait, et jamais vu,
ça. Je ne suis pas pour. Si comme le pense Philippe c'est pour nommer
les landuse, alors ce n'était pas nécessaire, ni même désirable,
d'exclure les rues.

Marc Mongenet

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

Re: [OSM-talk-fr] maxspeed par défaut

[Marc Mongenet]

Bonjour

> Le 02/09/2020 à 10:33, Eric SIBERT via Talk-fr - talk-fr@openstreetmap.org a 
> écrit :
>
> +1 avec les avis précédents: en extra-urbain, l'implicite est devenu 
> tellement incompréhensible qu'il vaut mieux coder explicitement.
> Par défaut c'est 80 km/h sur les chaussées à double sens:
> - sauf sur certaines portions de départementale dans certains départements
Oui, mais je suppose que la source sera alors toujours un panneau.
Mais si le panneau n'est pas répété après une intersection, je suppose
que ça retombe à 80.

> - sauf quand il y a un une voie supplémentaire pour faire un créneau de 
> dépassement
90 km/h dans ce cas.

> - pareil pour les routes pour automobile (panneau C107) à double-sens?
De ce que j'ai compris de l'Article 5 (voir mon autre message), C107
implique le 110 km/h sauf limitation explicite.

> - On peut imaginer une route à double-sens avec un terre-plein temporaire
> pour un carrefour. Ce n'est pas pour autant que le long du terre-plein,
> la limite va passer à 90 km/h.
Effectivement, dans ce cas ça passe carrément à 110 km/h d'après R413-2 !

> Donc l'implicite est difficile à expliquer à l'humain et à l'ordinateur.
> Je ne sais même plus ce qu'il faut mettre pour source:maxspeed dans ces cas 
> là.
Je ne sais pas quelle maxspeed mettre dans certains cas. C'est pour
cette raison que je pense préférable de ne pas essayer de deviner la
limite explicite, mais plutôt indiquer "maxspeed=FR:rural".

Le mer. 2 sept. 2020 à 10:54,  a écrit :
>
> > - On peut imaginer une route à double-sens avec un terre-plein
> >  temporaire pour un carrefour. Ce n'est pas pour autant que le
> > long du terre-plein, la limite va passer à 90 km/h.
>
> En théorie tu as raison. En pratique... Je ne sais si un gars a eu une
> offre spéciale pour réutiliser les anciens panneaux !

A noter que ce cas ne correspond pas à l'exemple avec un terre-plein
temporaire ; c'est le cas à plusieurs voies dans le même sens.
Le panneau 90 est ici superflu, maxspeed=FR:rural + lanes:forward=2
impliquant 90 km/h.

Marc Mongenet

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

Re: [OSM-talk-fr] maxspeed par défaut

[Marc Mongenet]

Le mer. 2 sept. 2020 à 01:16, Yannick  a écrit :
> L'implicite est désormais quasi impossible à deviner.
> Je suis donc partisan de mettre systématiquement le maxspeed=* au
> moins c'est clairement renseigné sans équivoque possible.

Oui l'implicite est difficile à maîtriser. Mais le problème que j'ai
rencontré, et je pense qu'il est répandu, c'est que les mappeurs ne
connaissent pas suffisamment bien le code de la route pour expliciter
correctement l'implicite! D'ailleurs, en relisant les textes
réglementaires avant de poster, je me suis rendu compte que je ne suis
pas tout à fait au clair moi-même.

Ainsi, je pense que
https://wiki.openstreetmap.org/wiki/FR:Key:maxspeed#Limitation_de_vitesse
se trompe en écrivant:
> hors agglomération : 80 km/h sur les routes sans séparateur
> de voie, 90 km/h sur les routes avec séparateur
En effet l'article R413-2 donne 110 et pas 90 km/h:
> Hors agglomération, la vitesse des véhicules est limitée à []
> 110 km/ h sur les routes à deux chaussées séparées par
> un terre-plein central ;
Le cas n'est pas théorique, je connais une occurrence près de chez moi:
https://www.google.fr/maps/@46.1980371,6.2917578,3a,75y,342.01h,94.36t/data=!3m6!1e1!3m4!1sifBdoBwUx_iYoXFBxbB-lA!2e0!7i16384!8i8192

Il y a aussi la question des routes à accès réglementé, signalées par
le panneau C107 (le carré bleu avec une auto).
Est-ce qu'une route à accès réglementé dont la chaussée contient une
voie dans chaque sens sans terre-plein central est limitée à 80 ou 110
km/h?
Je pense que c'est 110 km/h par application de l'Article 5 de l'Arrêté
du 24 novembre 1967 relatif à la signalisation des routes et des
autoroutes:
> Ce signal annonce le début d'une section de route autre
> qu'une autoroute, réservée à la circulation automobile,
> sur laquelle les règles de circulation sont les mêmes que
> celles prescrites aux articles R. 412-8, R. 417-10, R. 421-2
> (à l'exception de 9°), R. 421-4 à R. 421-7, R. 432-1, R. 432-3,
> R. 432-5, R. 432-7 et R. 433-4 (1°) du code de la route et sur
> laquelle, sauf indication contraire, la vitesse maximale des
> véhicules est fixée à 110 km / h.
Mais le cas est peut-être théorique, car je ne connais pas de telle
route sans limitation explicite.

Le 02/09/2020 à 07:16, Gad Jo a écrit :
> Préfère source:maxspeed=FR:urban + maxspeed=80 pour définir partout
> où la vitesse est à 80.

Je suppose que tu voulais écrire source:maxspeed=FR:rural, non?

Le 02/09/2020 à 10:34, Frédéric Rodrigo a écrit :
> Quand la vitesse est implicite, il y encore plus générique que mettre
> explicitement la vitesse. Mais plutôt :
> maxspeed=FR:urban

Est-ce que maxspeed=FR:rural seul est OK pour une route rurale?
Ou bien maxspeed=FR:rural + source:maxspeed=FR:rural est meilleur?
Un simple maxspeed=FR:rural me semble déjà implicitement indiquer que
la source est la vitesse implicite, mais bon.

En fait, ce qui m'intéresse beaucoup avec FR:rural, c'est
1. la simplification induite pour les créneaux de dépassement ;
1.1. Au lieu de maxspeed:forward=90 + maxspeed:backward=80 ;
simplement maxspeed=FR:rural ;
2. De ne pas devoir choisir entre 80, 90, et 110, pour les routes à
chaussées séparées ;
2.2. Sur la route visible avec l'URL google que j'ai donné ci-dessus,
je pense que la loi dit 110, mais les automobilistes vont pratiquement
tous à 80.

Marc Mongenet

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

[OSM-talk-fr] maxspeed par défaut

[Marc Mongenet]

Bonjour,

Près de chez moi passe la route D 903 avec une succession de portions
à accès réglementé en 2x2 voies séparées
(https://www.openstreetmap.org/way/825204700), à 2+1 voies
(https://www.openstreetmap.org/way/24205655), à 1+1 voies
(https://www.openstreetmap.org/way/6069166), à 1+1 voies séparées
(https://www.openstreetmap.org/way/654772946), sans compter les voies
d'insertion, etc.

De nombreuses portions ont une limite de vitesse implicite car il n'y
a pas de panneau limitant la vitesse, et les règles générales
s'appliquent (R413-2). Le problème est que ces règles sont mal
connues, et presque tout a été mal mappé avec maxspeed=80. Pour
l'instant j'ai supprimé ce qui était faux.

Mais est-ce que ça vaut la peine de mapper les limitations par défaut?
Informatiquement parlant, ça me semble profondément contre-productif:
c'est le boulot de l'ordinateur de calculer cela. Sauf qu'il faut tout
de même taguer qqch pour faire la différence entre une route de
maxspeed inconnue, et une route de maxspeed implicite. Ma question est
donc:
Est-ce qu'utiliser source:maxspeed=FR:rural sans maxspeed=* est une
bonne pratique?

PS: Les règles du code de la route sont si mal connues que
https://wiki.openstreetmap.org/wiki/FR:Key:maxspeed#Limitation_de_vitesse
contient une erreur de 20 km/h.

Marc Mongenet

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

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

[Marc M.]

Le 29.06.20 à 22:34, Florian LAINEZ a écrit :
> j'ai 8 cinémas https://overpass-turbo.eu/s/Vzp

non ce n'est pas ce que tu as demandé dans ta requête
avec (._;>;); tu demandes aussi tous les objets "enfants"
cad les noeuds des ways qui les composent
du coup le comptage les contient.

je sort la hache pour virer tout ce qui n'est pas utile
https://overpass-turbo.eu/s/VAD
résultat 4 nœuds 4 chemins = 8 :)
a noter que out count est encore plus clair pour faire
des stats https://overpass-turbo.eu/s/VAE

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

Re: [OSM-talk-fr] Alternative locale à Mapillary

[Marc M.]

Bonjour,

Le 29.06.20 à 12:19, Eric SIBERT a écrit :
> Question : y a-t-il un moyen de faire quelque chose de similaire sans
> passer par Mapillary?

il y a une discussion un clic à côté :)
en gros on expérimente diverses briques
la brique pour récupérer les images depuis un compte mapillary va bien,
les afficher sur une carte aussi. tout le reste est à faire ou à
(re)trouver.

Cordialement,
Marc

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

Re: [OSM-talk-fr] Poteaux de randonnée aux tags "baroques" dans le Vaucluse

[Marc M.]

Le 29.06.20 à 10:39, Yves P. a écrit :

> *hiking*=yes je ne le met pas car dans ma région il servent  
> autant pour les randos pédestres, vélo, VTT, cheval…

ou mettre les 3 (parce que si tu veux sélectionner "chevaux",
ca va être compliqué de faire une requête "si région=celle
de yves, alors pas de valeur=vélo+vtt+cheval" :)
il y a souvent des pictogrammes indiquant les moyens de transport,
c'est dans ce sens là que j'ajoute ces tags.

> *pole:position* a-t-il encore un intérêt avec une qualité correcte
> d'orthophotos et surtout une vue mapillary ?

sûrement du détail peu utile, (pour les bornes incendies, on le fait
parfois quand la borne est masquée par les hautes herbes. pour un
poteau je doute que la végétation monte si haut)
Mais j'aurais surtout utilisé la clef courante location=*

> *start_date* ?

c'est quoi la question ?

> *arrows* n'est pas standard et est-ce vraiment utile.

j'aurais mis direction=les 3 valeurs

> mapillary:wide
> Je propose donc de ne mettre que la photo la plus lisible

proposer d'effacer est rarement le plus agréable.
mapillary=valeur1;valeur2;valeur3
si c'est logiciels ont du mal avec le support des valeurs
multiples, il faut les améliorer au lieu d'effacer des données.

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

Re: [OSM-talk-fr] coupure serveur overpass-api osm.fr

[Marc M.]

Bonjour,

Le service est rétablit sur osm47
https://overpass-turbo.eu/s/Vyy
Il devrait être plus rapide qu'avant.
n'hésitez pas à signaler d'éventuelle anomalie
ici ou sur tech ou sur github
https://github.com/osm-fr/infrastructure/issues/19

A suivre :
- les améliorations pour le rendre plus robuste aux pannes
- maj du code overpass (pour entre autre nwr)
- le retour des graphes munin

Cordialement,
Marc

Le 26.06.20 à 12:39, Marc M. a écrit :
> Bonjour,
> 
> pour diverses raisons (manque d'harmonisation entre les hosteurs,
> soucis de perf sur l'un d'eux), les 2 serveurs overpass-api osm-fr
> subissent des jours de lag, au point que j'ai coupé le service.
> 
> une nouvelle base est en cours de maj sur un ssd
> avec l'espoir d'y réactiver le service ce we.
> s'en suivra la maj applicative tant attendue,
> ainsi que diverse amélioration pour essayer de rendre cela
> plus robuste
> 
> Cordialement,
> Marc
> 


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

Re: [OSM-talk-fr] maj base de rendu bloquée (osm.org, osm.fr, osm.ch et surement d'autres)

[Marc M.]

Le 27.06.20 à 20:35, Jacques Lavignotte a écrit :
> Le 27/06/2020 à 17:24, Marc M. a écrit :
>> pour info, un diff bloque le maj des bases de rendu utilisant osm2pgsql,
> 
> Merci de nous informer, Marc
> 
> De quelle machine s'agit-il ?
> 
> https://wiki.openstreetmap.org/wiki/FR:Serveurs_OpenStreetMap_France

pour osm-fr c'est https://munin.openstreetmap.fr/osm-day.html
(osm25 a en plus un bug dans son graphe, osm105 était déjà ko
par arrêt des soins palliatifs avant ce bug ci).

pour osm.org c'est https://munin.openstreetmap.org/renderd-day.html
partie "Data import lag"

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

[OSM-talk-fr] maj base de rendu bloquée (osm.org, osm.fr, osm.ch et surement d'autres)

[Marc M.]

Bonjour,

pour info, un diff bloque le maj des bases de rendu utilisant osm2pgsql,
entre autre celle de osm.org, osm.fr, osm.ch
sequenceNumber=4082799
timestamp=2020-06-26T19:17:02Z

On attend le correctif :)

Regards,
Marc

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

Re: [OSM-talk-fr] Nouveau jeu de données IdfM (STIF)

[Marc M.]

Bonjour,

Le 26.06.20 à 11:19, Florian LAINEZ a écrit :
> Ile-de-france-mobilité, l'autorité organisatrice des transports
> anciennement nommée STIF, vient de publier un jeu de données comparant
> leurs données avec celles d'OSM :
> https://data.iledefrance-mobilites.fr/explore/dataset/ecarts-arrets-referentiel-et-openstreetmap/information/

y a-t-il un moyen de flager erreur côté opendata <> osm <> a vérifier ?

comment fonctionne le menu de gauche ? j'ai essayé de trouver
l'arrêt avec une différence de 7km, il m'affiche  Filtres actifs
Distance (m) 7460 mais j'ai toujours toutes les différences sur la carte

Cordialement,
Marc

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

[OSM-talk-fr] coupure serveur overpass-api osm.fr

[Marc M.]

Bonjour,

pour diverses raisons (manque d'harmonisation entre les hosteurs,
soucis de perf sur l'un d'eux), les 2 serveurs overpass-api osm-fr
subissent des jours de lag, au point que j'ai coupé le service.

une nouvelle base est en cours de maj sur un ssd
avec l'espoir d'y réactiver le service ce we.
s'en suivra la maj applicative tant attendue,
ainsi que diverse amélioration pour essayer de rendre cela
plus robuste

Cordialement,
Marc

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

Re: [OSM-talk-fr] listing des cinémas sur data.gouv

[Marc M.]

Le 26.06.20 à 10:59, PanierAvide a écrit :
> qu'est-ce qui serait à documenter, et où ?

si un jour quelque chose se grippe et que les fichiers ne sont plus
à jour sur
https://www.data.gouv.fr/fr/datasets/cinemas-issus-dopenstreetmap/ il va
chercher pourquoi ou cliquer sur "contacter openstreetmap".
celui chez qui cela arrive (je sais même pas qui) serra content
d'avoir les 4 lignes que tu viens d'écrire :)

je ne sais pas vraiment quel est le meilleur endroit pour cela.
faire une page wiki.openstreetmap.org listant les différents export
du compte osm sur data.gouv.fr ?

genre
sujet / source / hébergement / code / url
ciné / download.osm-fr/... / OpenDataFrance /
https://framagit.org/PanierAvide/GeoDataMine /
https://www.data.gouv.fr/fr/datasets/cinemas-issus-dopenstreetmap/

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

Re: [OSM-talk-fr] listing des cinémas sur data.gouv

[Marc M.]

très sympa.
suggestions : documenter quelque part et ajouter un lien vers ce quelque
part sur le comment cela tourne (où est le code qui prend le dump
geodatamine pour l'envoyer sur www.data.gouv.fr, où cela tourne,
où signaler une anomalie si un jour c'est ko

Le 25.06.20 à 18:41, PanierAvide a écrit :
> Pour les curieux, les exports sont disponibles via GéoDataMine pour
> toutes les thématiques présentes dans l'outil (France métropole +
> DROM/COM, màj quotidienne) : https://geodatamine.fr/dump/
> 
> Adrien P.
> 
> Le 25/06/2020 à 17:58, Florian LAINEZ a écrit :
>> Hey, cadeau du jour : un extract quotidien des cinémas de france sur
>> data.gouv :
>> https://www.data.gouv.fr/fr/datasets/cinemas-issus-dopenstreetmap/
>> Merci de ne pas encore communiquer largement sur le sujet : ce n'est
>> qu'une première version, vu tout le boulot qu'on est en train de mener
>> sur le sujet actuellement, attendez vous à voir bouger les données.
>> On espère avoir une "V1" d'ici quelque temps donc votre aide est la
>> bienvenue pour améliorer les données dans OSM. En particulier on a
>> besoin d'aide pour créer les infos de contact : adresse, numéro de
>> téléphone, site web, page facebook ...
>>
>> Avec Adrien on va par ailleurs publier pas mal de nouveaux jeux de
>> données sur data.gouv sur des sujets différents, on vous tient au jus
>> pour ça aussi.
>>
>> -- 
>>
>> *Florian Lainez*
>>
>> @overflorian 
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 


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

Re: [OSM-talk-fr] Zone de croisement pour fauteuil roulant

[Marc M.]

Bonjour,

Le 25.06.20 à 22:38, Emmanuel Aubert a écrit :
> il y a des pistes piétonnes  pas bien larges.
> Sur ces pistes, il y a des surfaces que je soupçonne être 
> des zone de croisement. 
> Y a t’il un tag pour ça ?

un bout de way avec le width=* qui va bien ?

Cordialement,
Marc

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

Re: [OSM-talk-fr] Bano v2

[Marc M.]

Bonjour,

Le 24.06.20 à 09:40, Cyrille37 OSM a écrit :
> Le 07/05/2020 à 10:59, Marc M. a écrit :
>> la veille base dont il dépend ne se met plus à jour
>> depuis le 11 avril, et donc les fichiers produits ne le sont pas.
> 
> C'est largement suffisant pour être très utile.

ce n'est pas moi qu'il faut convaincre :)

hélas le serveur n'a pas l'option upgrade
--inutilement-différent-des-autres-mais-fix-sans-que-j-y-passse-des-heures
:)
la culture du "mutualisation minimale" a un prix humain et fonctionnel,
les mêmes choix conceptuels sont discutés pour la v2, avec donc
les mêmes conséquences tant à court terme (l'install) qu'à long terme
(la maintenance)

Merci à Jacques d'avoir trouvé une des causes (fichier de style
contenant une ip publique en dur, hors celle-ci ont changés récemment)
j'ai appliqué le correctif.

a vu de nez, il y en a au moins encore 2 (droit sur la bdd, https)

Cordialement,
Marc

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

Re: [OSM-talk-fr] cadastre.openstreetmap.fr ???

[Marc M.]

Bonjour,

Le 23.06.20 à 11:37, Hélène PETIT a écrit :
> Après une migration mouvementée de win7 à debian10

félicitations :)

> c'est chouette ; ça résout mon problème immédiat

et pour fêter cela, la configuration a été corrigée
pour http://cadastre.openstreetmap.fr
(adaptation du fichier de config suite à la maj
d'il y a 2-3 jours. c'était passé inapercu).

Cordialement,
Marc

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

Re: [OSM-talk-fr] feed mastodon cassé sur osm.fr

[Marc M.]

Le 23.06.20 à 18:48, Florian LAINEZ a écrit :
> -une belle 404 ;) https://www.openstreetmap.fr/null-island

c'est bien trouvé :)

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

Re: [OSM-talk-fr] BANO ça n'existe plus ?

[Marc M.]

Le 23.06.20 à 15:56, Vincent Bergeot a écrit :
> Je pense que tout ne se ferra pas du jour au lendemain

pour préciser, la seule chose qu'il manque c'est la feuille
de style v2 tout le reste existe.
si qlq se sent d'attaque pour l'écrire, je la met sur un serveur
et cela tourne pendant qu'on discute philosophie sur tech :)

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

Re: [OSM-talk-fr] BANO ça n'existe plus ?

[Marc M.]

Bonjour,

>> il y a des mois j'ai découvert BANO. Je l'utilisais selon mes besoins
>> et ma manière de contribuer. C'était lent, mais bon... ça marchait;
>> Y'a que moi que ça gêne ?

si tu parles du rendu ko depuis mai, non il n'y a pas que toi.
mais ceux qui savent le rétablir le savent, du coup bah...

Cordialement,
Marc

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

Re: [OSM-talk-fr] Alternatives à Mapillary

[Marc M.]

Le 22.06.20 à 19:03, Christian Quest a écrit :
> je peux m'en charger en lançant le script sur un serveur perso

installe le front de fred pour supprimer la contrainte humaine ?

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

Re: [OSM-talk-fr] Alternatives à Mapillary

[Marc M.]

Bonjour,

Le 22.06.20 à 10:29, Stéphane Péneau a écrit :
> Recensons les alternatives complètes ou partielles à Mapillary, les
> briques réutilisables, etc...

https://github.com/gitouche-sur-osm/mapillary_takeout
https://github.com/frodrigo/mapillary_takeout_web
en cours d'install sur l'infra osm.fr

> il manque au moins le floutage, le nerf de la guerre.

cela ne dépend-t-il pas du but et de l'accessibilité ?
par analogie geofabrik a restreint les données personnelles
aux contributeurs osm mais ils sont accessible aux contributeurs.
du coup un openstreetview accessible qu'aux contributeurs osm
est peut-être un groupe privé dispensé de ce genre de soucis.

Cordialement,
Marc

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

Re: [OSM-talk-fr] Data OSM

[Marc M.]

Le 20.06.20 à 14:20, Georges Dutreix via Talk-fr a écrit :
> 
> Le 20/06/2020 à 12:53, Nelson Tayou a écrit :
>>
>> L'URL serait alors osmdata.openstreetmap.fr
>>  Qu'en pensez-vous ?
>>
> Pourquoi repréciser "osm" et pas plus simplement data.openstreetmap.fr
>  ?

data c'est ultra générique pour des données brutes
alors qu'ici c'est un outil précis et plus une interface
vers les données que les données eux meme.
sinon overpass turbo et api pourrait aussi devenir data
download.osmn-fr aussi
etc :)

moi j'aime l'idée que l'url d'un outil porte le nom de l'outil

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

Re: [OSM-talk-fr] Data OSM

[Marc M.]

Bonjour,

Le 20.06.20 à 12:53, Nelson Tayou a écrit :
> il est pas adequat vu la ressemblance avec "JOSM". 

c'est en effet mieux d'éviter la confusion orale.

> Nous avons envisagé un nouveau nom plus simple qui pourrait être "OSMdata".

j'aime le oeil à OpenData

Cordialement,
Marc

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

Re: [OSM-talk-fr] Facebook achète Mapillary !

[Marc M.]

Bonjour,

Le 19.06.20 à 17:01, Stéphane Péneau a écrit :
> Le 19/06/2020 à 16:23, Marc M. a écrit :
>> - des personnes pour établir les besoins/buts. ex faut-il faire
>> les 3 par défaut ? à l'époque c'était évidement, ajd p'tre que
>> l'utilisateur voudrait configurer le partage qu'à une partie des 3)
> Si on souhaite se défaire de ce genre de problème, il faut une solution
> complète qui ne soit pas rattachée à une entreprise.

j'entends bien ce que tu dis, mais il y a surement des contributeurs
souhaitant continuer à alimenter xyz
si un outil permet à ces personnes de contribuer à la solution
communautaire en même temps que leur solution favorite,
n'est-ce pas le meilleur moyen de les faire participer ?

pour être plus pragmatique, le démonstrateur peux en effet viser
à alimenter la copie locale et opentrailview par exemple.
et rien n'empeche qlq de faire un plugin pour alimenter xyz
par la suite

Cordialement,
Marc

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

Re: [OSM-talk-fr] Pas de cadastre ce matin

[Marc M.]

Le 19.06.20 à 10:30, Cyrille37 OSM a écrit :
>> https://tms.cadastre.openstreetmap.fr/*/tout/17/67603/46680.png
>> ne répond plus.
> 
> le ticket https://github.com/osm-fr/infrastructure/issues/188

c'est rétablit

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

Re: [OSM-talk-fr] Facebook achète Mapillary !

[Marc M.]

Bonjour,

Le 19.06.20 à 16:41, Vincent de Château-Thierry a écrit :
> si quelqu'un.e a *envie* qu'un démonstrateur "proxy Mapillary/OSC" voit le 
> jour, qu'il/elle n'hésite pas à se lancer

je ne partage pas ta vision du communautaire.

*j*'ai envie de me lancer dans le sujet, comme je l'avais dis
il y a plus d'un an.
mais ce que je n'ai pas envie, c'est d'un Xieme projet mono-leader
qui s'arrête ou se grippe le jour où le mono-leader est indisponible.
le monde libre est plein de projet agonisant, quel gâchis de ne
pas se concentrer sur le durable, ce qui implique aussi d'être
humainement durable. c'est en ce sens que je disais que la
communauté n'avait pas eu envie en 2018 du sujet, ou dit
autrement, il n'y avait pas une manifestation de porteur*s*
pour que l'idée se poursuive

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

Re: [OSM-talk-fr] Facebook achète Mapillary !

[Marc M.]

Le 19.06.20 à 16:15, PanierAvide a écrit :
> Plutôt un manque de temps / ressources ? 

du temps surement, les resources technique pour un démonstrateur
sont dispo (= entendre par là qu'il n'y a évidement pas 1000 To
disponible, mais la première étape est de faire un démonstrateur
avec une taille disque limitée)

> De quoi a-t'on besoin pour voir un tel mécanisme émerger ?

- des personnes pour établir les besoins/buts. ex faut-il faire
les 3 par défaut ? à l'époque c'était évidement, ajd p'tre que
l'utilisateur voudrait configurer le partage qu'à une partie des 3)
- un sysadmin pour créer une vm sur l'infra avec un peu d'espace,
je veux bien m'en charger
- choisir la techno pour avoir la marche à l'entrée la plus faible
- voir les briques existantes utilisables (par exemple ce qui
existe autour de mapillary/osc)
- réfléchir oü héberger la "propriété" du projet. osm.fr ? osmf ?
le premier est rapide à mettre en oeuvre, le 2ieme facilite
une collaboration mondiale sans qu'un s'approprie la chose.
- coder ce qui manque
- des utilisateurs qui l'utilisent :)
- rever la suite :)

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

Re: [OSM-talk-fr] Facebook achète Mapillary !

[Marc M.]

Le 19.06.20 à 08:50, PanierAvide a écrit :
> À quand un Mapillary/OpenStreetCam libre et décentralisé ? ;-P

lors de l'appel aux dons 2018, il avait été évoqué de faire
un démonstrateur permettant à un contributeur d'envoyer
ses photos à un seul endroit, à charge pour cet endroit
d'en faire une copie locale (permettant un usage communautaire
voir un jour entrainer un apprentisage) et un double envoi OSC/mapillary

domage que cela n'ai pas interessé la communauté à l'époque,
l'actualité montre bien les limites d'utiliser des outils non libre :
quand on est lié à l'ateur ou on perd en fonctionalité sans pouvoir
forker le tout

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

Re: [OSM-talk-fr] Facebook achète Mapillary !

[Marc]

June 19, 2020 8:31 AM, "Cédric Frayssinet"  wrote:

> Le 19/06/2020 à 08:27, Stéphane Péneau a écrit :
> 
>> https://blog.mapillary.com/news/2020/06/18/Mapillary-joins-Facebook.html
>> 
>> Stf
> 
> Suis content d'avoir toujours contribué sur OpenStreetCam (Mapillary ne
> fonctionnant pas sans les Google Play Services sur mon smartphone).

Pour info, je les avais contacté à ce sujet, et ça fonctionne si tu mets 
«device only» dans les paramètres de localisation. Si tu mets «high accuracy» 
ça ne marche effectivement pas, même si tu as uNlp.

Marc

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

Re: [OSM-talk-fr] Fontaine fleurie

[Marc M.]

auqul on peux ajouter flowers=yes
même s'il manque sans doute un tag principal genre
landuse=flowerbed
landuse=meadow (pas trop du tout)
leisure=garden garden:style=flower_garden (micro-mapping ?)

Le 18.06.20 à 10:26, European Water Project a écrit :
> Je dirai ...  abandoned:amenity
> =fountain
> .
>  
> qui n'empêche pas quelqu'un qui veut rendre des fontaines ornementales
> sur une carte .
> 
> voici deux catégories où tu pourrais peut-être mettre cette photo :
> 
> https://commons.wikimedia.org/wiki/Category:Defunct_fountains  
> 
> https://commons.wikimedia.org/wiki/Category:Former_fountains  
> 
> 
> 
> On Wed, 17 Jun 2020 at 21:07, Yves P.  > wrote:
> 
> Bonsoir,
> 
> Comment taguer une fontaine remplie de terre et ornée de fleurs
> 
> 
>  ?
> 
> Il n'y a rien dans le wiki, je ne trouve pas non de catégorie dans
> Wikimedia (quel est le nom en anglais).
> 
> amenity=fountain seulement va dépiter les cyclistes et randonneurs
> assoiffés cet été :D
> disused:amenity=fountain va empêcher le rendu. Avec ou sans eau,
> c'est un bon point de repère…
> 
> __
> Yves
> 
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 


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

Re: [OSM-talk-fr] Comment tagguer plusieurs caméras de vidéosurveillance sur un poteau

[Marc M.]

Bonjour,

Le 18.06.20 à 06:28, Quentin Salles a écrit :
> un poteau dans lequel 4 caméras sont posés dessus.
> Chacune de ces caméras cible différentes directions.

camera:direction =valeur1;valeur2;valeur3;valeur4
devices=4

Cordialement,
Marc

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

Re: [OSM-talk-fr] "Échallier" pour VTT

[Marc M.]

Bonjour,

Le 17.06.20 à 11:56, Yves P. a écrit :
> J'ai mis une photo dans la discussion Tag:barrier=stile # Stile for
> bicycles <https://wiki.openstreetmap.org/wiki/Talk:Tag:barrier=stile>.

barrier=stile bicycle=designated ?

Cordialement,
Marc

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

Re: [OSM-talk-fr] Tickets Restaurants et StreetComplete

[Marc M.]

Le 17.06.20 à 10:33, Guy Godfroy a écrit :
> Je ne sais pas quoi déduire ce cette conversation.

au plus on essaye de faire ultra compliqué en une fois,
au moins cela abouti.
j'ai proposé de faire la première étape "papier"
et même là il y a pas concensus puisque Donat
dit qu'un poi doit les accepter tous (ce qui implique
qu'il n'est pas nécessaire de demander la marque)
tandis que d'autre disent que ce n'est pas exact.
et pourtant ce point doit être vérifié pour pouvoir
faire une quête SC efficace et correcte à la fois.

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

Re: [OSM-talk-fr] Comment tagguer un bar à jeux ?

[Marc M.]

Bonjour,

Le 17.06.20 à 08:49, Francescu GAROBY a écrit :
> un lieu (bar/pub/...) qui propose toute une série de jeux de
> sociétés/de cartes/... à ses clients.

si cela avait été son activité principale : amenity=toy_library ?
du coup soit 2 objets amenity=bar et amenity=toy_library takeaway=no
soit un objet amenity=bar toy_library=yes
dans les 2 cas un tag description est sans doute utile.

Cordialement,
Marc

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

Re: [OSM-talk-fr] Sortie de RTKBase V2

[Marc M.]

Bonjour,

Le 16.06.20 à 16:20, Stéphane Péneau a écrit :
>>> S'il y a des obstacles sous les 10 - 15 °, ce n'est pas grave.
>>> Au-dessus par contre c'est problématique.
>> cette exigence disqualifie les endroits auquels je pensais
> Ah dommage...

quel est l'impact d'un obstacle tel qu'un arbre ou une maison dans cet
angle ? on va perdre un sat mais faire la même qualité de fix si on
a assez de sat ? et perdre en précision si on manque de sat et si oui
est-ce que cela arrive souvent de manquer de sat ?

je crois d'ailleurs que c'est une question générale pour plusieurs
éléments technique, je me souviens de ma période CB, avec une antenne
fouet hélicoïdale pour voiture sur un plan de masse 10cmx10cm,
cela ne m'empéchait pas de discuter à courte portée sans différence
avec ceux qui avaient une antenne demi-onde sur leur toit.

Cordialement,
Marc

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

Re: [OSM-talk-fr] Cartopartie : comment relever efficacement les horaires des commerces ?

[Marc M.]

Bonjour,

Le 14.06.20 à 21:02, Arnaud Champollion a écrit :
> Je suis preneur de toutes vos expériences et conseils pour réaliser ces
> relevés sur le terrain de façon fiable et tenable dans le temps.

j'a d'abord fait comme toi : une série de photo de ce qui m’intéresse,
pensant pouvoir les assigner au retour devant un pc.
hélas, même en planifiant de faire la rue dans un ordre précis (par ex
toujours les impairs en premier), il y a toujours un cas tordu qui vient
mettre la pagaille (genre un poi au no3 dont l'entrée est après le poi
au no5). et tout s'écroule dans la série en cascade.
la précision du gps qui ne tourne pas en continue est aussi catastrophique.
du coup maintenant je fais toujours 3 photos par poi : le no, son nom
et l'horaire.
et si l'un des 3 n'est pas photographié, je fais une photo vide
pour garder la série de 3.

j'ai testé aussi l'éditeur sur le terrain, je le trouve trop chronophage
(le temps qu'on passe sur le terrain à encoder sur un clavier minuscule
n'est pas compensé par le temps gagné sur le pc, hormis pour des choses
très ponctuelle genre un no de borne incendie que j'encode tout en
continuant de marcher, idem pour des noms en zone très peu dense)

Cordialement,
Marc

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

Re: [OSM-talk-fr] Les glaciers noirs ou partiellement noirs

[Marc M.]

Le 14.06.20 à 14:36, osm.sanspourr...@spamgourmet.com a écrit :
> avec la version de Marc tu vas avoir 3 glaciers.

ben non :)
1 natural=glacier + name
1 natural=snowfield ou natural=ice_mass sans nom
1 geological=moraine et/ou natural=scree sans nom

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

Re: [OSM-talk-fr] Les glaciers noirs ou partiellement noirs

[Marc M.]

Bonjour,

Le 14.06.20 à 09:28, Arnaud Champollion a écrit :
> Quand le glacier a une partie visible et une partie recouverte, on le
> coupe en deux et on ajoute surface=scree sur la partie recouverte ?

> Est-ce que les deux parties doivent alors porter le nom ?

vu qu'il n'ŷ a qu'un glacier avec ce nom,
je ne ferrais qu'un objet pour le nom (qui comprend la partie blanche
et sa moraine). puis si on veux faire plus précis, 2 autres objets
pour tager séparement les 2 parties, sans nom.

Cordialement,
Marc

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

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

[Marc M.]

Bonjour,

Le 13.06.20 à 20:25, Florimond Berthoux a écrit :
> abréviation de vingt-huitième

https://wiki.openstreetmap.org/wiki/FR:Names#Abr.C3.A9viation_.28.C3.A0_ne_pas_faire.29

la règle est de ne pas mettre d'abréviation dans name

> mais le terrain prime :)

ce n'est pas parce qu'une plaque de rue a une taille limitée,
que osm doit se limiter.
sinon supprimons 99% des noeuds des frontières administratives,
le terrain prime, et il n'y a rien sur le terrain ? :)

Cordialement,
Marc

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

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

[Marc Mongenet]

Bonjour,

Les ouvrages de conventions typographiques françaises que je connais
donnent "28ᵉ" (ou "28e" si l'on n'a pas d'exposant).
Je n'ai jamais vu "28ème" dans un ouvrage de référence, même si c'est
très utilisé dans les textes qui ne suivent pas de convention
typographique. Idem pour "28ième".
Je ne crois jamais avoir vu "28Eme" ni "28Ème", quel que soit le texte.
Voir aussi 
https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Conventions_typographiques#Adjectifs_num%C3%A9raux_ordinaux

Bonne soirée
Marc Mongenet

Le sam. 13 juin 2020 à 19:42, blef  a écrit :
>
> Bonjour,
>
> Je cherche la meilleure façon d'orthographier le "Quai du 28ème Bataillon de 
> Chasseurs".
>
> 28ème comme ci-dessus avec accent (ma préférence)
> 28Eme, 28Ème, 28E
> Sans espace, avec espace.
>
> En tout cas la graphie actuelle 28° ma parait la pire.
>
> Qu'en pensez-vous?
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] et si c'était Nöel ? liste de souhait et d'intérêt des outils existant

[Marc M.]

Bonjour,

Merci pour vos retours.
Voici la compilation chronologique des 8 personnes ayant répondu avec
utilisation et/ou besoin/souhait.
un doubble étonnement : le nombre limité à 8 et le peux de retour
sur les outils existant, à croire qu'on peux fermer la moitié :)

- avoir un éditeur web consensuel utilisable (le fameux id-consensuel
grâce aux patchs de fred)
- accompagner les petites structures pour un switch2osm, ce qui implique
d'avoir un doc Leaflet en français par ex
sur http://www.openstreetmap.fr/fonds-de-carte/
- soutenir les rendus existant (par ex fr) ou à grandir (cyclosm) parce
qu'une donnée qui se voit mal est une donnée un peu gâchée.
- diminuer la marche à l'entrée pour les contributeurs :
-- faciliter/accompagner lorsque quelqu'un veux faire une amélioration
sur un outil majeur, écrire p'tre une doc, identifier les problèmes.
-- avoir des serveurs de test pour cela (par exemple tester une modif de
rendu à plusieurs, ce n'est pas facile. faut installer un docker, le
rendre accessible à l'extérieur, installer le style, etc)
-- faciliter le correspondance besoin<>aidant en aidant par exemple la
communauté à bâtir une page listant les besoins, afin que ceux qui le
souhaitent puisse y piocher sans devoir "parcourir le web".
-- soutenir les communautés locales à grandir voir à se créer dans les
endroits qui en sont dépourvu.
-- aider à l'ajout d'opendata dans osm, non seulement osmose, mais aussi
en discutant d'un possible groupe de travail import/intégration ciblé
(certaines infos ont un "match"
facile entre osm-opendata qui rend inutile de demander un clic par
objet). cfr aussi le osmmybiz version opendata-fr
- un outil qui envoie un mail de présentation d'OSM dès que l'on tagge
email=moncoiff...@orange.fr. Avec un lien vers un soutien financier
- maquette de présentation/communication osm auprès des POI
- éditeur axé poi osmmybiz + horaire, un wizard/éditeur d'ajout de POI
tout public, notamment pour les commerces.
- retour du rendu BANO
- une instance française de https://nrenner.github.io/achavi/ ?
- communiquer autour de  http://geosm.openstreetmap.fr
- URL de chaque point de vente d'une enseigne
https://lists.openstreetmap.org/pipermail/talk-fr/2020-May/099075.html
- du Docker sur l'infra OSM-FR (suposé possible avec proxmox 6 à court
terme)
- du switch2osm qui parle de tuiles vecto
- une version d'Osmose dédié à l'OpenData
- un canal de discussion pour remplacer twitter "Mapillary team fr"
- pouvoir suivre des objets osm en particulier, et être alerté (mail,
flux rss, autre) en cas de modification.
- interface ‘carte cyclable’ rafraichie tous les jours, comme l’est
l’excellent cyclOSM
- completer le docker osm-carto switch2osm afin d'avoir la brique
"récupérer le style"
- CyclOSM
- BD Ortho IGN
- UMap

j'en ai fait un pad pour rajouter facilement d'étentuel avis à venir
https://annuel2.framapad.org/p/osm-retour-communaute-9h8d

Cordialement,
Marc

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

Re: [OSM-talk-fr] GPS Opens source

[Marc M.]

Le 12.06.20 à 14:42, Eric SIBERT a écrit :
> Le 2020-06-12 13:46, ades a écrit :
>> Bonjour
>> Est-ce quelqu’un a des news sur l »’avancement de la réalisation 
>> d’un gps open source ?

parles-tu du projet de Stéphane Péneau "Et si on fabriquait notre
récepteur/logger GPS ?" en mars 2018 ?
https://lists.openstreetmap.org/pipermail/talk-fr/2018-March/088111.html

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

Re: [OSM-talk-fr] Tickets Restaurants et StreetComplete

[Marc M.]

Bonjour,

je pense qu'il faut revenir aux fondamentaux : SC est fait pour des
quêtes simples dont les réponses ne sont pas rébarbatives.
avec une quête avec 50 choix et un schéma fr-fr, cela ne va pas.
pourquoi pas revenir au début ?
ce poi accepte-t-il les tickets resto papier ? oui/non/limité
et reporter à + tard (et surtout au niveau mondial) une hypothétique
héritage des tags entre eux, qui changerait tout bien au dela de
la seule question d'une marque précise multi-usage.

Cordialement,
Marc

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

Re: [OSM-talk-fr] politique de la ville et umap

[Marc M.]

Le 12.06.20 à 10:05, Laurence P a écrit :
> Par contre les iframe n'ont plus l'air de fonctionner et je ne sais pas
> pourquoi :/
> 

le contenu de l'iframe est en erreur
https://storify.com/Cyrille37/cartopartie-lariche-ouest/embed?template=slideshow
https://storify.com dit qu'ils ont fermé en mai 2018

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

Re: [OSM-talk-fr] surveiller une liste d'objet (était : et si c'était Nöel ? liste de souhait et d'intérêt des outils existant)

[Marc M.]

Le 11.06.20 à 16:19, Stéphane Péneau a écrit :
> Le 11/06/2020 à 15:23, BEGUIN,Bruno a écrit :
> je n'ai pas trouvé comment surveiller un node en particulier.

j'ai surveillé un vandale multi-compte comme suit :
- récupération des diff
- grep sur chaque diff pour voir si les id s'y trouvent
- email en cas si cela se produit.

pour en faire un service un peu sympa, il faudrait
évidement au moins quelque chose pour qu'un utilisateur
soumette sa liste. et p'tre sortir un flux rss pour
éviter le volume d'email sortant si beaucoup veulent
l'utiliser

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

Re: [OSM-talk-fr] Ajout d'un identifiant unique des cinémas en France

[Marc M.]

Bonjour,

Le 09.06.20 à 20:37, Yves P. a écrit :
> Je ne sens pas intermittent=yes

je partage cet avis. un magasin fermé pendant les vacances annuelles
est-il plus ou moins intermitant qu'un projecteur de cinéma actif
à cet endroit tous les lundis ?

> opening_hours="cinéma itinérant : consultez les horaires"

c'est une tautologie :) bof. cinéma itinérant est une description
consulter les horaires ? ok la clef opening_hours donc ? qui dit
de consulter les horaires :)
opening_hours:url est plus utile. ou un début d'info.
et si on a rien sur les horaires, pas de clef opening_hours

Cordialement,
Marc

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

[OSM-talk-fr] et si c'était Nöel ? liste de souhait et d'intérêt des outils existant

[Marc M.]

Bonjour,

au niveau de la liste de l'asso osm-fr, démarre une discussion
autour de "à quoi l'asso devrait affecter ses ressources humaines
et financière".
Du coup je trouve que c'est l'occasion de demander à la communauté
ce qu'elle a besoin mais qui n'existe pas, ce qui existe et qu'elle
utilise et de classer un peu tout cela en fonction de priorité (qui
sont évidement propre à chacun).
Cela pourrait éclairer l'association dans ses choix.
La liste des services fournit par l'asso est +- dispo sur
https://wiki.openstreetmap.org/wiki/FR:Serveurs_OpenStreetMap_France#VMs

Et donc je commence par moi-même :)
- avoir un éditeur web consensuel utilisable (le fameux id-consensuel
grâce aux patchs de fred)
- accompagner les petites structures pour un switch2osm, ce
qui implique d'avoir un doc Leaflet en français par ex
sur http://www.openstreetmap.fr/fonds-de-carte/
- soutenir les rendus existant (par ex fr) ou à grandir (cyclosm)
parce qu'une donnée qui se voit mal est une donnée un peu gâchée.
- diminuer la marche à l'entrée pour les contributeurs :
-- faciliter/accompagner lorsque quelqu'un veux faire une amélioration
sur un outil majeur, écrire p'tre une doc, identifier les problèmes.
-- avoir des serveurs de test pour cela (par exemple tester une modif
de rendu à plusieurs, ce n'est pas facile. faut installer un docker,
le rendre accessible à l'extérieur, installer le style, etc)
-- faciliter le correspondance besoin<>aidant en aidant par exemple
la communauté à batir une page listant les besoins, afin que ceux
qui le souhaitent puisse y piocher sans devoir "parcourir le web".
-- soutenir les communautés locales à grandir voir à se créer
dans les endroits qui en sont dépourvu.
-- aider à l'ajout d'opendata dans osm, non seulement osmose,
mais aussi en discutant d'un possible groupe de travail
import/intégration ciblé (certaines infos ont un "match"
facile entre osm-opendata qui rend inutile de demander
un clic par objet). cfr aussi le osmmybiz version opendata-fr

Cordialement,
Marc

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

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

[Marc M.]

Le 09.06.20 à 14:36, Julien djakk a écrit :
> En fait, je ne pense pas faire de relations, trop casse-pied à gérer,

c'est pourtant le plus facile pour détecter que le réseau est complet.

> quand deux itinéraires vélo "secondary" se rejoignent,
> ça peut donner un itinéraire vélo "primary" etc.

j'ai en souvenir ta vision très controversé du réseau voiture.
du coup un exemple et une source utilisable pour osm sur ce point ?
ou c'est juste un feeling comme pour les voitures ?

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

Re: [OSM-talk-fr] Tickets Restaurants et StreetComplete

[Marc M.]

Le 09.06.20 à 11:53, Tyndare a écrit :
> Un resto peut

SC n'aime pas (et moi non plus) les quêtes qui en théorie ont plusieurs
réponses mais qui en pratique ont 99% de la même.
du coup les questions à se poser pour faire la quête sont :
- les cas "le midi mais pas le soir" ou inversement, sont-ils fréquent
au point de devoir l'inclure dans les réponses ou c'est purement
théorique ? perso je n'en connais pas. idem pour les cartes.
- il y a un lien ou pas entre papier et électrique méritant de demander
l'électrique qu'en cas de réponse oui au papier ou cela mérite 2 quêtes
totalement indépendante ? j'aurais tendance à croire qu'un commercant va
continuer le papier pendant une période transitoire vers l'électronique.

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

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

[Marc M.]

Bonjour,

Le 09.06.20 à 12:35, Julien djakk a écrit :
> Je souhaite hiérarchiser

n'est-ce pas la première lettre de network=icn/ncn/rcn/lcn ?
international <> national <> regional <> local route

le wiki renseigne aussi cycle_network=cycle_highway
qui a l'air d'être... hum.. pas très clair :)

Cordialement,
Marc

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

Re: [OSM-talk-fr] Ajout d'un identifiant unique des cinémas en France

[Marc M.]

Bonjour,


Le 09.06.20 à 09:34, Florian LAINEZ a écrit :
> Je me suis également rendu compte que dans la liste des cinémas fermés
> en 2018
> il y en a un qui a simplement changé de numéro

c'est bien là tout le soucis.
sans ref, osm aurait été juste.
l'ajout de la ref conduit à avoir une info fausse sans osm.
il faut donc que cela soie contrebalancé par une utilité.

pour Sirene, j'imagine qu'il suffit de demander à Fred
d'activer la catégorie adéquate.
J'imagine qu'une autre analyse pourrait tout aussi bien
alerter "cinéma dans osm mais fermé dans sirene"

Cordialement,
Marc

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

Re: [OSM-talk-fr] Tickets Restaurants et StreetComplete

[Marc M.]

Bonjour,

Le 09.06.20 à 10:41, Guy Godfroy a écrit :
> pour l'instant il suffit de répondre oui ou non à la question
> "Est-ce que ce restaurant accepte les titres restaurants".
> Est-ce qu'on est d'accord là dessus ?

Pour la France oui, avec le soucis papier<>électronique.
est-ce que tout ceux qui accepte l'electronique accepte
aussi obligatoirement le papier ?

Cordialement,
Marc

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

Re: [OSM-talk-fr] Intégration du bornage du réseau routier national

[Marc M.]

Bonjour,

et tu listes 2 ref ? hum

pour éviter de faire une nouvelle particularité fr-fr,
et vu qu'on a trouvé aucune utilité a dupliquer
la ref de la route sur toutes les bornes,
je suis partisant de respecter la situation actuelle
cad pour ton exemple :
highway=milestone
distance=22
operator=SANEF
ref=77PR22DC

chaque pays qui invente son propre schéma,
c'est nuisible pour osm, surtout quand
aucun argument n'est émis.

Cordialement,
Marc

Le 09.06.20 à 08:47, didier2020 a écrit :
> afin de trouver une solution sans "ref" :
> 
> proposition d'utilisation des attributs de la base rrn
> description complète :
> http://dtrf.setra.fr/pdf/pj/Dtrf/0005/Dtrf-0005792/DT5792.pdf
> 
> Pour les "nodes" highway=milestone
> attribut base rrn
>   
> valeur dans la base rrn
>   
> tag osm proposé
>   
> valeur tag osm
>   
> nota
> route
>   
> A0004
>   
> ref:FR:route
>   A0004   
> ref "A 4" est sur le way
> pr
>   
> 22
>   
> distance
>   
> 22
>   
> information visible sur le terrain
> dep
>   
> 77
>   
> concession
>   
> C
>   
>   
> concédé n'est pas synonyme de payant
> cote
>   
> D
>   
> D,G ou U
> gestionnaire
>   
> SANEF
>   
> operator
>   
> SANEF
>   
> plo
>   
> 77PR22DC
>   
> ref:FR:plo
>   77PR22DC
> avec le plo, on peut retrouver tous les autres attributs et inversement
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> et pour être cohérent, 
> pour les "way" highway=*_link ou junction=roundabout
> attribut base rrn
>   
> valeur dans la base rrn
>   
> tag osm proposé
>   
> valeur tag osm
>   
> nota
> route
>   26N953220   
> ref:FR:route
>   26N953220   
> pr
>   
> 2
>   
>   
> le pr correspond a un n° de bretelle
> dep
>   
> 77
>   
> concession
>   
> C
>   
>   
> cote
>   
> D
>   
> le coté est toujours D
> gestionnaire
>   
> DIRCE
>   
> operator
>   
> DIRCE
>   
> plo
>   
> 26N953220_2
>   
> ref:FR:plo
>   26N953220_2 
> avec le plo, on peut retrouver tous les autres attributs et inversement
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> dans le champs source:plo, l'attribution et le milésime
> 
> 
> Le lundi 08 juin 2020 à 13:26 +0200, didier2020 a écrit :
>> comme il n'y a pas de consensus sur l'utilisation des tags
>> complémentaire a higway=milestone,
>>
>> j'ai téléchargé le pbf de la france et filtrer les nodes
>> highway=milestone pour voir ce qui existe :
>>
>> sur 10935 higway=milestone, 
>> - 9057 ont un tag ref
>> - 442 ont un tag ref avec une valeur numerique
>> - distance :
>>  705 n'ont pas de valeur distance
>>  60 sont du texte/inclus un . ou +
>>  170 ont des valeurs supérieur a 1000, donc a prioris des metres plutot
>> que des kilometres
>> - 400 avec un tag ref:highway
>>
>>
>>
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 


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

Re: [OSM-talk-fr] Ajout d'un identifiant unique des cinémas en France

[Marc M.]

Le 08.06.20 à 18:07, Florian LAINEZ a écrit :
> @marc M j'imagine que tu penses à ajouter le numéro de SIRET 
> comme suggéré par Christian ?

non, je pensais à l'utilisation de la base sirene pour détecter les
cinémas manquant dans osm et les cinémas fermés depuis longtemps.

> Question : d'après vous, devrait-on rajouter une valeur
> *ref:FR:CNC=null* (ou "none") pour les cinémas non-listés dans le
> fichier du CNC ? J'ai bien envie de faire ça.

Je doute comme JB de l'utilité de ce genre de ref mais si tu veux le
faire, la valeur standard =no me semble être *le* choix (comme =yes est
la valeur standard pour dire il y a en a une, à rafiner + tard)

Cordialement,
Marc

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

Re: [OSM-talk-fr] Ajout d'un identifiant unique des cinémas en France

[Marc M.]

Le 08.06.20 à 17:42, Francescu GAROBY a écrit :
> géoloc des cinémas, ça aiderait beaucoup !

sirene via osmose ?

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

Re: [OSM-talk-fr] Tickets Restaurants et StreetComplete

[Marc M.]

ok pour le besoin de doc.

Donat vient de nous informer que c'est tout ou rien en France,
donc la marque n'est pas nécessaire voir induirait en erreur.

pour le namespace, oki lorsqu'il y a un conflit (par exemple une route
sur un point peux avoir un nom pour la route et un pour le pont,
donc logique d'avoir bridge:name)
mais pour les tickets restaurants, cela me sembble une mauvaise
idée de faire dépendre le tag en fonction de l'étendue commerciale
d'une marque genre payment:meal_voucher=Sedexo puisque mondial
et payment:meal_voucher:FR=trucmuchlocal parce que fr-fr
avoir besoin de consulter le plan d'affaire d'une entreprise
pour choisir le tag n'a pas de sens.

Le 08.06.20 à 15:01, Topographe Fou a écrit :
> Par "pas claire" j'entends que le wiki ne propose rien aujourd'hui (ni
> sur la page anglaise, ni sur la française) et que la clé n'étant utilisé
> que 212 fois dans le monde dont seulement 30 fois pour autre chose que
> yes/no (pour Sodexo en l'occurrence) c'est qu'il doit sûrement rester un
> peu de discussion à avoir (83 fois en France métropolitaine avec 82
> yes/no + 1 chèque vacances).
> 
> Par ailleurs il peut y avoir plus d'un émetteur de titre (certes la CRT
> centralise les 4 plus gros émetteurs mais il n'y a pas qu'eux). Par
> 'brand' tu veux dire une liste des titres acceptés séparés par un ; ?
> Cela peut être une option mais d'expérience cela cafouille vite et puis
> la limite du nombre de caractères jouera probablement vite les troubles
> fêtes avec l'arrivée des nouveaux acteurs. D'où ma suggestion de rester
> dans la veine des autres moyens de paiement, ce qui renforce la
> cohérence. Le 'FR:' est une touche personnelle pour éviter d'éventuels
> conflits de noms quand un émetteur est clairement franco-français (ex :
> chèque vacances).
> 
> Le lun. 8 juin 2020 à 14:42, Marc M.  <mailto:marc_marc_...@hotmail.com>> a écrit :
> 
> Le 08.06.20 à 13:58, Topographe Fou a écrit :
> > il faudrait déjà un schéma claire, ce qui n'est pas le cas
> aujourd'hui.
> 
> =yes/brand/no c'est pas clair ?
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> 
> -- 
> LeTopographeFou
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 


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

Re: [OSM-talk-fr] Tickets Restaurants et StreetComplete

[Marc M.]

Le 08.06.20 à 13:58, Topographe Fou a écrit :
> il faudrait déjà un schéma claire, ce qui n'est pas le cas aujourd'hui.

=yes/brand/no c'est pas clair ?

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

Re: [OSM-talk-fr] Intégration du bornage du réseau routier national

[Marc M.]

Le 08.06.20 à 13:26, didier2020 a écrit :
> - 9057 ont un tag ref

ce serrait sans doute utile de chercher quelques photos
de borne avec la ref visible.

>  60 sont du texte/inclus un . ou +

. est le séparateur décimal dans osm, du coup c'est numérique.
le + est + étrange.

> ref:highway
> serait une solution

à mon avis, quand il n'y a pas consensus, osmose doit s'abstenir
donc intégrons déjà toutes les bornes sans ref:highway

> "notre" besoin de référence unique

quel besoin ? si la ref dans la source n'est pas unique, elle n'est pas
unique.
prenons un exemple fictif : si la sncf décide de peindre ses places
de parking en commençant par 1 sur tous ces sites, cela ferra des ref=1
non unique dans osm.
ce n'est pas le rôle d'osm d'inventer une ref genre ref:FR:SNCF:siteA
par dogme d'unicité dans osm.
ou exemple réel : la route ref=1 n'est pas unique dans osm,
c'est la réalité, cela n'empêche pas son utilisation.

dupliquer + tard un ref:highway s'il y a un cas d'usage et un consensus,
c'est toujours possible

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

Re: [OSM-talk-fr] Osmose - proposition analyse sur public_transport=stop_position

[Marc M.]

Le 08.06.20 à 10:40, Percherie OnDaNet a écrit :
> Juste pour être certains que je ne fasse pas d'erreur : Peut-on avec 
> le schéma Public Transport V2 placer deux nœuds pour un arrêt, n°1
> l'emplacement de l'arrêt (stop_position) et n°2 l'emplacement des
> passagers (platform) ? Ou est-ce à éviter ?

c'est possible, non obligatoire et c'est la version la plus "complète"
avis perso : je commencerais par toutes les plateforme
avant d'ajouter éventuelement les stop_position.
histoire d'avoir un réseau qui a au moins une fois l'info (la
plateforme) pour tous les arrêts au lieu d'avoir un réseau
qui est super précis mais qui n'est pas complet)
mais c'est un choix qui t'appartient.

> Pour l'arrêt "Cave Coopérative", le nœud
> https://www.openstreetmap.org/node/2466864152 est bien sur le chemin et
> il à le tag "highway=bus_stop". Je m'attendais à avoir le fix-edit de
> Osmose propose le tag "public_transport=stop_position" au lieu de
> "public_transport=platform". Quelle est la réponse idéale ?

oui idéalement osmose devrait dire "cela appartient à la route,
donc fix avec stop_postion ou déconnectez de la route pour une plateforme"

> Pour l'arrêt "La Ricarde", le nœud
> https://www.openstreetmap.org/node/4498238410 est isolé mais porte des
> tag nécessitant d'être rattaché au chemin (stop_position et bus_stop).
> Je m'attendais à ce qu'Osmose demande à ce qu'il soit rattaché OU BIEN
> que les tag soient modifiés (platform) pour que cela corresponde à un
> nœud isolé. Pour l'instant Osmose ne remonte aucune erreur sur
> "public_transport=stop_position" sur des nœud isolé.

oui idéalement osmose devrait dire "rattachez le stop_position à la
route si c'est l'emplacement du véhicule ou corriger en plateform
si c'est le lieu d'attente du véhicule

Cordialement,
Marc

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