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

[Eric SIBERT]

Je comprends l'intérêt d'avoir l'itinéraire réel pour les transports  
urbains. Pour le longue distance, je ne vois pas ce que ça apporte de  
dire que le bus par l'autoroute et la rue qu'il prend pour desservir  
la gare routière. L'extrême est quand j'ai cassé la relation  
Paris-Lisbonne en éditant une route à Poitiers. Après, on va me dire  
que la limite entre urbain et longue distance va être compliquée à  
définir.


Eric

Patchi Atwork  a écrit :


Le 02/03/2024 à 18:19, deuzeffe a écrit :


Bonjour,

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.



Bonsoir,

Sur ce canal au mois de juin il y eu une longue discussion sur le  
tagging des transports en commun et cette solution de ne garder que  
les points d'arrêt (stop_position et platform/bus_stop) avait été  
évoquée. Je reprendrais le commentaire que j'avais publié "Je  
comprends l’idée de ne plus vouloir indiquer les routes dans  
l’itinéraire pour simplifier au maximum, mais c’est un peu comme  
vider une relation de randonnée de son itinéraire". Je trouve que  
l'itinéraire apporte un vrai plus, il y a même une couche dédiée aux  
transports en commun sur le site osm.org (il y en a même eu 2 un  
certain temps) - je doute qu'une couche n'affichant que les arrêts  
et zones d'attente sans itinéraire soit vraiment intéressante. Et  
générer un itinéraire automatiquement risque d'être hasardeux, un  
trajet de bus ne passe forcément pas le trajet le plus court.


Il existe également une proposition depuis 2018 pour une  
amélioration du PTv2  
(https://wiki.openstreetmap.org/wiki/Proposal:Refined_Public_Transport) qui  
conserve toutefois clairement les itinéraires. Vu que le PTv2 n'a  
jamais vraiment réussi à s'imposer complètement (le simple fait de  
vouloir enlever les tags historiques aka PTv1 fait hurler  
certains/certaines), je doute que cette proposition puisse un jour  
obtenir le statut 'approved'.


Trouver un consensus sur des relations intermédiaires pour de  
relations de transports en commun (bus et sans doute aussi tram car  
certaines lignes utilisent des voies routières) risque d'être une  
tache compliquée. Comme déjà indiqué je préfère personnellement  
avoir une relation complète par trajet, cela a au moins le mérite de  
clarté (une relation = un trajet complet). Certes c'est du lourd  
pour certaines zones, mais est-ce que des relations intermédiaires  
vont vraiment résoudre le problème ? Il faudrait sans doute faire  
des tronçons relativement petit pour garantir l'utilisation commune  
entre plusieurs lignes de transports en commun distinctes, ce qui  
aura pour impact d'avoir un tas de relations intermédiaires  
supplémentaires en plus de nos lignes de transports en commun  
elle-mêmes - je ne suis pas sûr que ce soit plus facile à gérer au  
final.


Bonne continuation,

Patchi.


___
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] Relations intermédiaires pour les routes de bus ?

[Eric SIBERT]

Des fois, je me dis que ça ne serait pas mal qu'il y ai un peu de 
factorisation sur certaines lignes de bus hors agglomération.


Sur un tronçon de la D1075 en Isère, il y a :
- 2 relations Bus 55 (aller et retour) (bus Zou opéré par Transdev 
Dauphiné!!!)

- 2 relations bus T73 (interurbain Isère)
- 8 relations bus T75 (idem): différentes combinaisons de départ/arrivée
- 2 relations TA2A (pour aller au ski)
- 2 relations TAAH (idem)
- 2 relations TAVR (idem)
(- l'ancien train qui roulait sur la chaussée)

Eric

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

Re: [OSM-talk-fr] Route payante en été

[Eric SIBERT]

Tient, on a aussi l'accès au Cirque de Saint-Même qui est payant en été.

https://www.openstreetmap.org/#map=18/45.40796/5.87774

Pour le moment, un contributeur a juste mis la barrière de péage sur la 
route sans informations saisonnières ou quoi que ce soit.


Eric


Le 03/09/2023 à 16:08, Marc_marc a écrit :

Bonjour,

Le 02.09.23 à 22:07, GarenKreiz a écrit :

piste forestière dont l'accès est payant de 9h à 16h30
en juillet-août pour cause d'affluence touristique ( 
https://www.openstreetmap.org/way/206820611)



toll=yes


cela dépend si tu considères que c'est payant en temps normal ou pas (et 
si tu préfères que les applications ne gérant pas les cas complexes 
considère que c'est payant ou pas).

cela me semble une bonne idée de mettre le cas défavorable par défaut


toll:bicycle=no


les piétons payent ?


toll:services=no


qu'est-ce que cela signifie ?
services dans osm me fait penser à highway=services,
une aire de services (disposant généralement d'une
station-service, restaurant, boutique...)
ce n'est probablement pas ce que tu voulais renseigner :)


toll:opening_hours=..


cela décrirait quand le péage est ouvert...
ce qui est ambigu pour décrire que le péage
a lieu de tel à tel heure


Est-ce la bonne approche?


j'aurais plutôt fait ainsi :
toll=yes
toll:conditional= no @ ...

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

Re: [OSM-talk-fr] Noms des résidences

[Eric SIBERT]

En général, un nom à 2 balles donné par le promoteur immobilier ;-),  
nom qui est ensuite le nom de la copropriété. Ex: les balcons du  
périphérique, les terrasses de la francilienne, les jardins de la  
pénétrante...


Eric

Daniel Garcia  a écrit :


Bonjour,

Dans une petite commune de < 20.000 habitants avec un certain nombre de
résidences étudiantes, HLM et senior, le service urbanisme de la mairie a
dit ne pas disposer d'un registre avec les noms des résidences.

Or, ces noms sont très utiles en pratique, même s'ils ne sont pas toujours
visibles depuis la rue.

Est-ce qu'il y a quelqu'un qui est censé enregistrer cela ? De manière plus
générale, qui décide du nom d'une résidence, et quelle portée ça a ? Est-ce
une raison sociale ? Un nom enregistré chez le notaire ? Juste un nom
fantaisie qui peut changer du jour au lendemain ?


Cordialement,
Daniel
___
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] Nouveau défi pour OSM à la Réunion

[Eric SIBERT]

Bonjour,

On ne sait pas encore vraiment comment gérer quelques centimètres de 
dérive des plaques dans OSM 
(https://www.openstreetmap.org/user/StephaneP/diary/390290).


Pourtant, il y a un défi bien plus grand dans le cirque de Salazie:

https://www.youtube.com/watch?v=NF4acZGS5TM

Bon dimanche

Eric


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

Re: [OSM-talk-fr] Encore une question sur les noms de rues

[Eric SIBERT]

Bonjour,
D'après Wikipédia, le nom correct est Alexander, pas Alexandre.


C'est le même genre de problème avec Clemenceau qui n'a pas d'accent. 
Pourtant, on le trouve sur le terrain avec un accent : Clémenceau.


Eric


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

Re: [OSM-talk-fr] 118 valeur de surface=* en français à traduire :)

[Eric SIBERT]

A Madagascar, il y a les ponts où il n'y a que des madriers dans le sens 
de la longueur. Vélo ou moto, tu ne passes pas mais, avec un peu de 
chance, il y a un gué à côté.


Il y a aussi les ponts il faut amener soit-même ses madriers...

https://wiki.openstreetmap.org/wiki/FR:Highway_Tag_Africa#Travers%C3%A9e_de_rivi%C3%A8re

Eric


Le 04/04/2023 à 00:02, Marc_marc a écrit :


- la voie contient des revêtements différent dans sa largeur.
je pense surtout à concrete:lanes
pour le moment il n'y a pas de moyen de renseigner proprement
le revêtement entre les bandes oü roulent les pneus gauches
et droites des véhicules à 4 roues. c'est un manque pour
les vélos cargos où le vélo roule fatalement au milieu.
j'ai vu des asphalt-grass-asphalt qui représente probablement
la même chose.

si du monde est motivé, nous pourrions déjà diminuer
les 2 premiers cas puisqu'ils sont résoluble

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] Réseau spéléologique

[Eric SIBERT]

Bonjour,

En spéléo, on définit un réseau spéléologique comme l'ensemble des 
galeries connectées (jonctionnées on dit) entre elles et donc, 
potentiellement, avec plusieurs entrées. Pour un réseau, on va définir 
le développement (la longueur cumulée de toutes les galeries), 
éventuellement le dénivelé (différence entre le point le plus haut et le 
point le plus bas ou différences par rapport à l'entrée la plus haute). 
Vous tagueriez ça comment dans OSM? Une relation?


Exemples en France :

https://fr.wikipedia.org/wiki/Liste_des_cavit%C3%A9s_naturelles_les_plus_longues_de_France




Eric

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

Re: [OSM-talk-fr] L'Ardèche repasse à 90 km/h

[Eric SIBERT]

Ce pont n'est pas coupé par exemple :
https://www.openstreetmap.org/way/25086393


Corrigé.

Je suis passé dessus il y a deux ans et j'avais déjà complété les 
limites de vitesse mais pas coupé le pont:


https://www.mapillary.com/app/?pKey=1112286489280438

Après, sur tous les petits détails comme ça, chacun peut déjà corriger 
sans attendre un hypothétique volontaire qui s'occuperait d'une 
correction en masse ;-)


Eric


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

Re: [OSM-talk-fr] L'Ardèche repasse à 90 km/h

[Eric SIBERT]

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

Le radar indiqué à 80 km/h sur la départementale qui doit être à 90 mais 
sans indication dans OSM.


Il y a juste le raccord de la Grand Rue qui rentre dans le village qui 
est taggé à 80, et encore, pas tout et pas tout avec une ref=. Je ne 
vais peut-être pas corriger toutes les erreurs pré-existantes.


Et highway=speed_camera retourne 22 points. Ça sent le traitement manuel.

Eric

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

Re: [OSM-talk-fr] L'Ardèche repasse à 90 km/h

[Eric SIBERT]

En faisant des tests, j'ai eu l'impression qu'il y avait pas mal de 
routes de Haute-Loire avec un seul nœud à la frontière de l'Ardèche qui 
étaient retournées dans les requêtes overpass (sans ref="D").


Il faut aussi regarder les maxspeed:forward et maxspeed:backward.

Quant aux rond-pointe, à 80 ou à 90, je ne suis pas sûr que ça change 
grand chose!!!


Eric


Le 09/11/2022 à 01:33, Jérôme Amagat a écrit :



Normalement les ways des départementales sont coupés à la limite du
département mais à vérifier par contre pas obligatoirement les voies
communales et pour les départementales, les ponts ne semble pas coupés


Des fois, les ponts sont coupés comme celui-là :

https://osm.org/go/xV97dr~bU-

Mais, s'agissant de chaussées séparées, il est déjà à 90 km/h dans les
deux départements ;-)



Ce pont n'est pas coupé par exemple :
https://www.openstreetmap.org/way/25086393


Il y a aussi les maxspeed=* des radars sur ces routes à modifier.

Pas pensé. Je vais regarder si c'est important.


Moi je suis partisan d'une modification de masse, par contre bien faite,
récupérer tout les maxspeed=80 sur un département dans JOSM, vérifier les
limites du département, vérifier les objets qui ont ce maxspeed=80, ne

pas

modifier les nationales et d'éventuelles voies d'accès aux nationales

sans

ref=*,...


C'est pour ce dernier point que j'ai tendance à privilégier les
ref="D*". Je vais regarder s'il y a beaucoup de cas à 80 km/h sans ref.

Ce petit pont au milieu d'une départementale n'a pas de ref=* :

https://www.openstreetmap.org/way/161567582
c'est une erreur que personne n'a corrigée et en ne modifiant que les way
en "D XX" ce pont restera à 80, ca ne serai pas bien grave mais autant
s'occuper de lui aussi :)
Un rond point à 80 sur une départementale :
https://www.openstreetmap.org/way/30720308

Il faut faire attention aux limites de département, avec overpass avec "in
Ardèche" j'ai ces 2 ways par exemple (j'ai pas tout regardé) :
https://www.openstreetmap.org/way/366950610
https://www.openstreetmap.org/way/423196543

Il y a aussi des maxspeed dans d'autre tag que maxspeed=*, sur des
départementales d'un département plutôt rural, il y a des chances que l'on
est pas des cas compliqué avec d'autre tag mais pour ne rien oublier il
faudrait vérifier aussi.




Le Cantal, ça fait 2 ans qu'il est repassé à 90, regarder le nombres de
routes départementales encore à 80 dans OSM :
https://overpass-turbo.eu/s/1nxF


93 way à 90 km/h
778 way à 80 km/h

Retour au 90, le 1er février 2020, donc on est presque 3 ans après.




En Ardèche :
34 ways à 90 km/h (dont un certain nombre sont des voies à chaussées
séparées).
972 ways à 80 km/h

Surtout, seulement 25% des départementales de l'Ardèche ont des limites
de vitesse dans OSM. Vivement l'IA avec Mapillary pour nous aider...

Eric


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


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



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

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

[Eric SIBERT]

Le 08/11/2022 à 21:44, osm.sanspourr...@spamgourmet.com a écrit :


Le 08/11/2022 à 19:10, Eric SIBERT - courr...@eric.sibert.fr a écrit :

Dans certains cas, il y a une zone sans marquage :

https://www.mapillary.com/app/?pKey=368476664619944


Ça c'est facile :

lane = 1

;-)


lane_markings=no

https://wiki.openstreetmap.org/wiki/Key:lane_markings



Toujours à l'entrée de Grenoble, sur l'A48, la BAU se transforme en
voie de bus quand il y a embouteillage.


C'est là:

https://www.mapillary.com/app/?pKey=1314859295592200



De facto ou affichage dynamique ? Info accessible par TMC ?


C'était affichage dynamique mais l'affichage en question a été supprimé.

2015 : https://www.mapillary.com/app/?pKey=1314859295592200
2021 : https://www.mapillary.com/app/?pKey=518079659705764

En plus, la voie de gauche a l'air d'avoir récupéré une nouvelle 
fonctionnalité. Si vous arrivez à décoder le panneau à gauche :


https://www.mapillary.com/app/?pKey=1108846552996175

Mais, dans tous les cas, on a quand même tendance à mettre le way au 
milieu de la voie centrale d'une autoroute considérée comme à trois 
voies (en attendant de gérer la voie de bus).


Eric

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

Re: [OSM-talk-fr] L'Ardèche repasse à 90 km/h

[Eric SIBERT]

Le 08/11/2022 à 18:50, Jérôme Amagat a écrit :

Pour les voies communales, c'est pareil que les départementales ou pas ? ne
pas se restreindre au ref avec un D, les rond-point et parfois des voies
d'accès n'ont pas de ref=*


Non, les voies communales ne sont pas concernées.


Normalement les ways des départementales sont coupés à la limite du
département mais à vérifier par contre pas obligatoirement les voies
communales et pour les départementales, les ponts ne semble pas coupés


Des fois, les ponts sont coupés comme celui-là :

https://osm.org/go/xV97dr~bU-

Mais, s'agissant de chaussées séparées, il est déjà à 90 km/h dans les 
deux départements ;-)



Il y a aussi les maxspeed=* des radars sur ces routes à modifier.


Pas pensé. Je vais regarder si c'est important.


Moi je suis partisan d'une modification de masse, par contre bien faite,
récupérer tout les maxspeed=80 sur un département dans JOSM, vérifier les
limites du département, vérifier les objets qui ont ce maxspeed=80, ne pas
modifier les nationales et d'éventuelles voies d'accès aux nationales sans
ref=*,...


C'est pour ce dernier point que j'ai tendance à privilégier les 
ref="D*". Je vais regarder s'il y a beaucoup de cas à 80 km/h sans ref.




Le Cantal, ça fait 2 ans qu'il est repassé à 90, regarder le nombres de
routes départementales encore à 80 dans OSM :
https://overpass-turbo.eu/s/1nxF


93 way à 90 km/h
778 way à 80 km/h

En Ardèche :
34 ways à 90 km/h (dont un certain nombre sont des voies à chaussées 
séparées).

972 ways à 80 km/h

Surtout, seulement 25% des départementales de l'Ardèche ont des limites 
de vitesse dans OSM. Vivement l'IA avec Mapillary pour nous aider...


Eric


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

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

[Eric SIBERT]

Le 08/11/2022 à 01:11, Marc Mongenet a écrit :

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?



Déjà, je pense qu'il faudrait ajouter au schéma le tracé des ways.

Le segment 5 fait ressortir la question de la gestion des lignes 
continues sur séparation/fusion de voie. Mais on d'autres cas de lignes 
continues qui peuvent avoir une influence sur le guidage:


https://www.mapillary.com/app/?pKey=2822941664665018

Si on est sur la file de droite et qu'on veut aller à gauche, on n'a pas 
le droit même si on est loin de la séparation des deux branches et de la 
ligne continue qui la précède.


Il va falloir modéliser le marquage au sol. Un peu de lecture sur la 
signalisation routière horizontale :


https://fr.wikipedia.org/wiki/Signalisation_routi%C3%A8re_horizontale_en_France

Eric


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

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

[Eric SIBERT]

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


Disons que si on a une façon non équivoque de placer le way, derrière, 
width:lanes devrait suffire. Déjà, j'aurais tendance à modifier ta 
proposition en moins KISS textuellement parlant mais pouvant tenir 
compte du fait que toutes les voies n'ont pas la même largeur:

- si nombre pair de voies, tracer le way sur la ligne médiane;
- si nombre impair de voies, tracer le way au milieu de la voie médiane.

Il faudrait aussi se mettre d'accord sur

> bande de roulement sans les voies de
> sortie/entrée, d'arrêt d'urgence ou autres

À Grenoble, l'A480 est en train de passer à trois voies, dont celle de 
droite réservée aux transports en commun, covoiturage et véhicules 
"propres". La voie spéciale est-elle dans la catégorie "autre" ou pas?


Toujours à l'entrée de Grenoble, sur l'A48, la BAU se transforme en voie 
de bus quand il y a embouteillage.




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


Dans certains cas, il y a une zone sans marquage :

https://www.mapillary.com/app/?pKey=368476664619944

(et testé de nuit avec un brouillard épais, il y a une zone de doute 
avant d'apercevoir les stroboscopes de la barrière de péage.)


On note aussi qu'à l'approche de la barrière, certaines voies 
recommencent à être tracées avant d'autres, avec au début des 
pointillés, ensuite des lignes continues et enfin des raquettes.


Si on veut rejoindre l'aire de repos après le péage, il faut 
nécessairement prendre la voie tout à droite (qui a une séparation 
physique après le péage).


Le 07/11/2022 à 13:45, Marc_marc a écrit :
>> Est-ce qu'on aurait pas plutôt intérêt à partir sur du quantitatif,
>> genre :
>> width:lanes=*|*|* : la largeur de chaque voie
>
> c'est évidement toujours possible voir utile (encore faut-il
> une app qui l'utilise)

Il faut anticiper même si, actuellement, il n'y a pas d'usage.


> mais je considère la largeur comme la dernière infos [1]
> cad bien après les modélisaitons plus simple (nombre de bande,
> direction/destination des bandes).
> quand j'écoute une aide à la navigationn, ce qui me manque
> n'est pas "déplacez-vous de 17cm vers la droite"
> c'est plutot tout simplement "prenez la bande de droite direction xyz"

Ça pourrait être "Vous n'êtes pas sur la bonne voie, décalez vous d'une 
voie à gauche/droite".


Ou d'avoir, avec l'affichage tête haute de mon véhicule, en réalité 
augmentée, le tracé en vert des voies à suivre et en rouges celles à éviter.


Eric

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

Re: [OSM-talk-fr] L'Ardèche repasse à 90 km/h

[Eric SIBERT]

en deux en virant la scorie oneway
=no ?^^


Je suis en train de tester une route dans le coin:

bicycle=yes
cycleway=no
lanes=1 (juste les petites marques sur l'axe central)

La borne incendie sur un nœud de la route.

Puis je tombe sur le panneau "Équipements spéciaux requis en hiver":

https://www.mapillary.com/app/?pKey=440808558178100

Certains départements, c'est tout le département (Savoie par exemple). 
D'autres départements, ce n'est que certaines partie (Isère, Ardèche).


Eric


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

Re: [OSM-talk-fr] L'Ardèche repasse à 90 km/h

[Eric SIBERT]

Le 07/11/2022 à 21:08, osm.sanspourr...@spamgourmet.com a écrit :

Le 07/11/2022 à 14:08, Eric SIBERT - courr...@eric.sibert.fr a écrit :


Je continue à mettre des source:maxspeed=FR:rural sur ces machins là
mais en posant la question du sens.


Pour ma part je ne mets du rural que sur du 80 km/h. Ou plutôt je
laisse. Car les 90 sont toujours explicites. Maintenant les 80 souvent
aussi !


C'est vrai aussi. Mais, effectivement, ça se défendrait de ne mettre le 
FR:rural que sur les sections à 80 km/h.




https://www.mapillary.com/app/?pKey=175706105115780

Là on est d'accord : fin de 90 explicite (source:maxspeed=sign) sans
panneau de limitation. On est en Ardèche, sur une départementale.

On passe donc à... 90 km/h.

source:maxspeed
<https://wiki.openstreetmap.org/wiki/FR:Key:source:maxspeed?uselang=fr>=FR-07:rural
???


:-)

En complément du FR:rural sur les voies à 80 km/h (comme la N102 dans sa 
traversée de l'Ardèche).




Si, 1 000 objets potentiellement modifiés c'est une édition de masse.
C'est bien d'en parler et encore mieux de l'expliciter dans le titre.


7 départements qui sont sensés être repassés intégralement à 90 km/h. 
7000 objets potentiels à traiter.


Pour l'Allier, ça semble clair :
https://www.mapillary.com/app/?pKey=666581557947666

Pour la Creuse, ça ne l'était pas en 2019:
https://www.lamontagne.fr/gueret-23000/actualites/quelles-routes-departementales-de-creuse-devraient-repasser-a-90km-h_13563846/

Je crois que je vais mûrir un peu le sujet, traiter mes données en 
retards sur ces régions et rouvrir un sujet spécial édition de masse si 
j'ai encore le courage.


Eric


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

Re: [OSM-talk-fr] L'Ardèche repasse à 90 km/h

[Eric SIBERT]

Oui, ça me paraît une bonne approche pour la vérifiabilité. Il va 
falloir que je fasse des essais. Mais, premier doute, on met où les 
panneaux? Sur le way ou à côté? Parce que jusqu'à présent, je mettais 
les panneaux d'entrée/sortie d'agglomération sur le way, éventuellement 
agrémenté d'un forward/backward quand ils ne sont pas au même niveau.


Pour les panneaux d'entrée/sortie d'agglomération, on en a déjà discuté 
il y a deux ans, de manière pas très conclusive:


https://lists.openstreetmap.org/pipermail/talk-fr/2020-February/096767.html

Pour les panneaux de limite de vitesse, ils sont déjà à côté du way, pas 
de problème.


Eric


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

Re: [OSM-talk-fr] L'Ardèche repasse à 90 km/h

[Eric SIBERT]

de plus je pense que des éditions de masse, certains non 
annoncées/discutées ont globalement dégradé la qualité.


Non mais ce n'est pas de l'édition de masse. On parle juste de quelques 
départementales en Ardèche ;-)


Je fais quelques statistiques avec overpass:

6794 ways "highway" avec la référence commençant par "D"
2173 ways "highway" avec la référence commençant par "D" et limite de 
vitesse
972 ways "highway" avec la référence commençant par "D" et limite de 
vitesse à 80 km/h
346 ways "highway" avec la référence commençant par "D" et limite de 
vitesse à 80 km/h et source:maxspeed=FR:rural


C'est sur les 972 ways que je voudrais agir.

J'avais déjà soulevé la question des repassages à 90 km/h l'an dernier:

https://lists.openstreetmap.org/pipermail/talk-fr/2021-August/104469.html

D'après l'article suivant:

https://www.lemonde.fr/societe/article/2022/08/02/80-ou-90-km-h-la-carte-des-departements-francais-qui-sont-revenus-sur-les-limitations-de-vitesse_6136967_3224.html

Les 7 départements intégralement repassés à 90 km/h sont:
l'Allier, l'Ardèche, l'Aveyron, le Cantal, la Corrèze, la Creuse et le 
Puy-de-Dôme



en plus le modèle de donnée le plus courant (mettre maxspeed sur le way 
sans renseigner le panneau) fait qu'il est virtuelement impossible

de cibler les vitesse non vue sur le terrain depuis longtemps.

je pense qu'il serrait utile de renseigner les panneaux
à leur emplacement, avec un survey:date (pas besoin de la date
exacte, un 20022-11 suffit largement)
couplé avec la détection mapillary, cela pourrait permettre
dans un 2ieme temps de détecter les endroits oü les panneaux
ont été supprimé ou fortement déplacé.


Oui, ça me paraît une bonne approche pour la vérifiabilité. Il va 
falloir que je fasse des essais. Mais, premier doute, on met où les 
panneaux? Sur le way ou à côté? Parce que jusqu'à présent, je mettais 
les panneaux d'entrée/sortie d'agglomération sur le way, éventuellement 
agrémenté d'un forward/backward quand ils ne sont pas au même niveau.


Eric

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

Re: [OSM-talk-fr] L'Ardèche repasse à 90 km/h

[Eric SIBERT]

Le 07/11/2022 à 13:11, osm.sanspourr...@spamgourmet.com a écrit :

Seulement si la source de la vitesse est rural.

Sinon ça peut être une limite explicite (j'en doute)... et comme à peu
près partout des 80 ont été placés explicitement là où en théorie ça
pouvait rester implicite.


Le problème avec l'histoire des 80/90, c'est que l'implicite devient 
capillotracté.


C'est 80 sauf s'il y a un créneau de dépassement avec une voie 
supplémentaire:


https://www.mapillary.com/app/?pKey=347660353363975

Certains départements ont décidé de repasser une partie des 
départementales à 90 km/h.


D'autres départements (dont l'Ardèche) ont repassé toutes leurs 
départementales à 90 km/h.


Je continue à mettre des source:maxspeed=FR:rural sur ces machins là 
mais en posant la question du sens.


Pour l'Ardèche, on a quand même parcouru un certain nombre de routes 
départementales pendant le pont. Je n'ai vu à aucun endroit de 
limitation à 80 km/h mais plutôt des trucs comme ça:


https://www.mapillary.com/app/?pKey=188945106973569

https://www.mapillary.com/app/?pKey=175706105115780

(aux entrées/sorties du département ou quand on quitte/rejoint la 
nationale).




des notes/fixme quand le statut actuel est inconnu ?

Car changer la vitesse et pas dans le sens de la sécurité me semble 
douteux.


Ce que je propose, c'est de mettre à 90 km/h ce qui est actuellement à 
80 et de laisser le reste, y compris les non renseignés inchangés.


Eric


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

[OSM-talk-fr] L'Ardèche repasse à 90 km/h

[Eric SIBERT]

Le conseil départemental de l'Ardèche a décidé de repasser la vitesse 
par défaut à 90 km/h sur toutes les départementales [1]. Et, de passage, 
j'ai constaté que la signalisation avait effectivement été adaptée y 
compris sur les petites routes (mais pas sur la N102 qui est une 
nationale). Je fais une remplacement systématique à l'échelle du 
département de toutes les limites sur départementale à 80 km/h en 90 km/h?


[1] : 
https://www.lemonde.fr/societe/article/2022/08/11/retour-aux-90-km-h-en-ardeche-on-ne-parle-pas-en-kilometres-mais-en-temps_6137726_3224.html


Bonne soirée

Eric

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

[OSM-talk-fr] Bretelles d'autoroutes

[Eric SIBERT]

Bonjour,

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

Mais ça ne parle pas de où on met le(s) way(s). 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

C'est ce qui a été fait vers chez moi mais sans rajouter de voie 
supplémentaire dans la zone de transition :-(.


(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 regarde aussi aussi la proposition "placement" (endormie depuis 2015):

https://wiki.openstreetmap.org/wiki/Proposed_features/placement

Est-ce qu'on aurait pas plutôt intérêt à partir sur du quantitatif, genre :
width:lanes=*|*|* : la largeur de chaque voie
lane_center:lanes=*|*|* : la position du centre de la voie par par 
rapport au way (perpendiculairement au way, compté dans le sens 
trigonométrique direct).


Il y a encore la question des voies transitoires, qui apparaissent ou 
disparaissent et donc changent de largeur dans le tronçon.


Vous en pensez quoi globalement?

Eric







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

Re: [OSM-talk-fr] dalles Lidar IGN colorisées en cartographie OSM

[Eric SIBERT]

Sur une des vidéos de présentation du projet Lidar IGN on voit très
clairement les chemins forestiers. L'ONF qui est un des partenaires
particulièrement intéressés par le projet Lidar dit s'en servir
aussi pour ça, ils sont même capables de différencier spécifiquement
les chemins praticables par des engins lourds afin de tenir à jour
leurs procédures d'exploitation.

Vidéo ici https://www.youtube.com/watch?v=8Isqx1FL4j0


Sur l'exemple de l'Ardèche (1:07:45), on voit bien le sol quand ils 
enlèvent la végétation. Donc, tous les espoirs sont permis.


Eric


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

Re: [OSM-talk-fr] dalles Lidar IGN colorisées en cartographie OSM

[Eric SIBERT]

Bonjour,



Comme vous le savez peut-être, l'IGN a commencé à distribuer en
opendata ses scans Lidar haute résolution (10 points/m²) du territoire
français,

[...]

Quelques km² de dalles de démonstration "colorisées" (avec MNT/MNS/MNH
associés) sont diffusées par l'IGN sur la page précitée, mais c'est
assez limité par rapport à l'ensemble des dalles disponibles, qui
sont diffusées en version brute donc rendu "monochrome" ou en fausses
couleurs.


Tu as pu regarder ce que ça donnait en zone très boisée?

Une relation a pris les données brutes et a essayé de générer  
elle-même un MNT. En zone boisée (Chartreuse), ce n'était pas terrible  
car très peu de points Lidar ont atteint le seul.


Eric



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

Re: [OSM-talk-fr] extraire les exif gps

[Eric SIBERT]

> Je cherche - pour linux - l'équivalent du truc windows : dnrgps.exe
> qui exporte les données gps d'une collection de photos vers un 
fichier csv.


Spontanément, je regarderais avec ExifTool en lui demandant d'extraire 
les champs qui vont bien.


Eric

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

Re: [OSM-talk-fr] Clés pour chemin sous marée

[Eric SIBERT]

En complément des autres réponses, indiquer l'altitude des points de  
la route devrait permettre de savoir pour quelle marée on peut passer.


Et un floodprone=yes (voir=tidal) pour aider à savoir que la route est  
inondable. Même si le trait de côte permet de se douter que la route  
est inondable, elle pourrait passer sur un pont ou un remblais.


Eric



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

Re: [OSM-talk-fr] Cartographier les voies vertes [Le retour]

[Eric SIBERT]

Le 07/05/2022 à 20:21, Axel listes a écrit :

Bonjour,

Je viens juste pour le moment annoncer qu’un texte a été publié le mois 
dernier pour autoriser officiellement le passage de véhicules motorisés 
sur les voies vertes. 


Effectivement, vers chez moi, la voie verte est interrompue sur la 
section où des voitures peuvent passer pour desservir quelques maisons:


https://www.mapillary.com/app/?pKey=515414546707883

On pourrait imaginer avec le nouveau texte que ça reste en voie verte, 
vu le trafic motorisé insignifiant.


Eric

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

Re: [OSM-talk-fr] [OSM-Talk-fr] tagger les dark store

[Eric SIBERT]

https://www.lemonde.fr/economie/article/2021/03/17/dark-store-plongee-dans-un-supermarche-de-l-ombre_6073393_3234.html

Eric

Le 24/03/2022 à 12:58, Philippe Verdy a écrit :

C'est des commerces légaux au moins? Parce que "dark store" ça semblerait
montrer autre chose, comme
- des lieux de revendeurs ou trafiquants
- des ateliers ou cuisines clandestines

Sinon, on n'a pas de meilleur terme? Ça ressemble en fait plus à un
pseudo-anglicisme (il suffit de voir les marques créées en France!), je me
demande si les britanniques ou américains utilisent vraiment ça.
Avant de taguer, vous avez des refs ailleurs qu'en France?

Le mer. 23 mars 2022 à 19:21, Florian LAINEZ  a écrit :


Hello,
Les "dark store " pullulent dans
nos villes, comment mapper ça ?
L'agence d'urbanisme parisienne APUR a récemment publié une étude dédiée
<
https://www.apur.org/sites/default/files/drive_pietons_dark_kitchens_dark_stores_paris.pdf?token=QHM2BKlT



et j'en déduis les points suivants :
- les lieux ne sont pas accessibles au public : ce sont des entrepôts et
non des commerces.
Néanmoins building=warehouse n'est pas adapté car le lieu est souvent situé
au rdc d'un bâtiment d'habitations.
- il faut donc *le plus souvent* les tagger avec un point, comme ici par
exemple https://www.openstreetmap.org/node/9600880977

industrial=warehouse pourrait fonctionner, surtout que son usage explose
cf. https://taginfo.openstreetmap.org/tags/industrial=warehouse#chronology
à cela, on rajoute
operator=Frichti;Kol;Cajoo;Flink;Getir;Gorillas;Glovo;GoPuff;Yango
Deli;Zapp;Rohlik;Bam Courses

Un tag supplémentaire ne serait-il pas le bienvenu pour préciser que c'est
du commerce de détail ?
J'oublie autre chose ?

--

*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

[OSM-talk-fr] Stockage photos de rue : était Re: [osm-fr asso] Prochain CA de l’association OSM-FR - mardi 1 février

[Eric SIBERT]

Des fois je rêve à du stockage distribué / décentralisé. Un géo-fédiverse.


Même en rêvant, comme le signal Christian, on est sur des grosses  
quantités. Perso, quand FB a racheté Mapillary, j'ai regardé pour  
rapatrier mes photos chez moi. J'ai renoncé, n'ayant pas l'espace  
disque nécessaire, genre 1 To.


Quant à se faire un cloud décentralisé, il faut avoir des serveurs à  
la maison ou hébergés chez des prestataires fiables (quand le data  
center crame...). Si on met 1 To chacun, il en faut quand même un  
millier. Dès qu'un serveur tombe, on re-duplique les données ailleurs?  
Même avec la fibre sur mon serveur maison, j'ai peur que ça fume sur  
les connexions.


Eric



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

Re: [OSM-talk-fr] Base RTK Centipede

[Eric SIBERT via Talk-fr]

Pour l'instant des contributeurs veulent tester la solution pour 
améliorer la cartographie sous les chemins forestiers.


Ça serait intéressant de comparer différentiel en temps réel et en 
post-traitement, parce qu'en post-traitement, ce n'est pas terrible pour 
le moment. Si les personnes peuvent aussi enregistrer les données brutes...


Eric

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

Re: [OSM-talk-fr] Tag tourism=alpine_hut

[Eric SIBERT via Talk-fr]

Et que dire du refuge CAF de Bonneval-sur-Arc?

http://www.refuges.info/point/110/cabane-non-gardee/Mont-Cenis-Grand-Paradis/Chalet-de-Bonneval-sur-Arc/
https://chaletbonnevalsurarc.ffcam.fr/

En zone résidentielle et à 50 m de la mairie ;-)

Eric

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

Re: [OSM-talk-fr] précision proposition nouvel attribut

[Eric SIBERT via Talk-fr]

Je pense qu'il y a dans certaines stations d'Amérique du Nord des 
portillons à déverrouiller avec son DVA pour sortir du domaine balisé et 
aller en hors-piste.


Eric

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

Re: [OSM-talk-fr] MNT/Lidar IGN

[Eric SIBERT via Talk-fr]

Convertir en MNT, faire des courbes de niveau, un ombrage ?


L'exemple que j'ai vu, c'était avec ombrage pour une lumière arrivant 
depuis en haut à gauche (nord-ouest) et assez rasant je dirais.


Eric

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

[OSM-talk-fr] MNT/Lidar IGN

[Eric SIBERT via Talk-fr]

Bonjour,

Un collègue universitaire nous a récemment montré un extrait de relevé 
Lidar fait par l'IGN sur un massif alpin. Ces mesures permettent de voir 
le sol sans la végétation. Je trouve ça très intéressant. Ça permettrait 
par exemple de voir les barres rocheuses et les effondrements en forêt 
mais sans doute plein d'autres choses aussi. Ces données sont 
actuellement verrouillées. Il y a eu accès avec un compte chercheur via 
la RGD 73-74 (http://geoportail-des-savoie.org).


D'autres personnes sont au courant de l'existence de ces données? Il y a 
moyen de sonder l'IGN (ou autres organismes financeurs) pour libérer ces 
données? À l'instar des Ortho HR.



Eric

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

Re: [OSM-talk-fr] Comment indiquer une séparation centrale sur une rue ?

[Eric SIBERT via Talk-fr]

(ce qui est différent de la bordure dont il était sujet initialement :
https://www.mapillary.com/app/?pKey=s7OAvWZ8TzqcexpCIhKARw&focus=photo 
)


Pour un truc comme ça, je sépare en deux ways distincts sans hésiter 
(plus interdiction de demi-tour à chaque bout éventuellement).


Eric

PS : on se comprend mieux avec des images ;-)

Eric

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

Re: [OSM-talk-fr] Retour de Ça Reste Ouvert — Re: projet du mois de novembre ? Et projet du mois de décembre

[Eric SIBERT via Talk-fr]

Le 06/11/2020 à 11:54, Philippe Verdy a écrit :
Le click and collect se généralisé à presque tous les commerces de 
proximité à Niort, [...]


C'est triste une ville plus morte qu'un dimanche...


Niort en temps normal?

OK, je sors ->


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

Re: [OSM-talk-fr] Comment indiquer une séparation centrale sur une rue ?

[Eric SIBERT via Talk-fr]

Une séparation pas centrale:

https://www.mapillary.com/map/im/HsxR0OyWJaOFMa8zC7hMwn

Eric

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

Re: [OSM-talk-fr] Projet du mois Décembre : lieux de test COVID (était "Carte des lieux de test COVID")

[Eric SIBERT via Talk-fr]

Ou suite à une suspicion vendredi dernier, un premier appel tardif 
(>19h) sur le labo d'analyse habituel, je tombe sur quelqu'un qui me dit 
que les tests PCR se font sur rendez-vous et qu'il faut appeler le 
lendemain matin à partir de 9h pour prendre rendez-vous.


Donc, le lendemain matin, appel en force mais ça tourne en boucle sur 
des automates sans jamais arriver sur un humain. Une vingtaine d'essais 
plus loin et quelques variations sur d'autres labos à proximité avec le 
même résultat, je me suis rendu physiquement au labo le plus proche où, 
après avoir fait la queue dehors (petit labo), j'ai pu avoir un 
rendez-vous (pour demain :-().


Donc, oui pour un outil ousefairetesteraucovid19 avec les modalités 
d'accès, en particulier rendez-vous ou pas. (voir type de test?).


Eric

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

Re: [OSM-talk-fr] Encore des orthos...

[Eric SIBERT via Talk-fr]

J'ai du mal à suivre en toutes les orthos dispos dans JOSM.


Le 13/10/2020 à 10:11, Christian Quest a écrit :
Les orthos d'un même millésime sont disponibles sur wms.openstreetmap.fr 
dans une couche "orthohr_" =année


A priori, les 2013 à 2020 sont dans les préréglages de JOSM ainsi que 
orthohr. De plus orthohr est proposé directement dans le menu imagerie 
sans demander d'activation dans les préférences.




L'agrégation de toutes les années est dispo dans la couche "orthohr" en 
mettant les plus récente "dessus".


Mais que se passe-t-il si la plus récente est moins résolue? Où "hr" 
c'est forcément au même niveau de résolution? (zoom 21?)


La différence avec "tous_fr"?

Eric

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

Re: [OSM-talk-fr] Contributeur qui passe en trunk

[Eric SIBERT via Talk-fr]

Le 10/10/2020 à 22:04, Georges Dutreix via Talk-fr a écrit :
Le "I made a few changes" et l'absence de réponse aux sollicitations me 
rappellent étrangement le comportement de l'utilisateur RB94, qui a fini 
par être bloqué.


Je viens de regarder. Effectivement, il mettait "J'ai changé certaines 
choses".
Néanmoins RB94 semblait plutôt parisien alors que mt_CSC paraît 
londonien. À priori, ce n'est pas la même personne.


24 heures plus tard, il a fait une demi-douzaine de changsets sans 
réagir à mon message.


Il n'y a plus qu'à contacter le DWG?

Eric


Modus operandi (comme ils disent dans les polars) : jamais de réelle 
volonté de nuire, mais toujours "je fais ce que je veux dans mon coin", 
avec en commentaire : "j'ai modifié certaines choses", et ... je suis 
trop coincé pour avoir envie de communiquer.


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

[OSM-talk-fr] Contributeur qui passe en trunk

[Eric SIBERT via Talk-fr]

Bonjour,

Je constate qu'un nouveau contributeur (6 mois) a commencé à convertir 
des primary en trunk, en France. La plupart de ses commentaires sont 
laconiques : "I made a few changes".


J'ai mis un commentaire sur un changement puis je lui ai envoyé un 
message directement. Je vois que du côté de Lille, un autre contributeur 
a mis des commentaires restés sans réponse.


Je suis quand même inquiet. Sur ces axes importants, il y a souvent des 
modifications diverses. La possibilité de faire des reverts paraît déjà 
perdue.


Vous suggérez quoi comme approche?

Eric

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

Re: [OSM-talk-fr] Capitelles

[Eric SIBERT]

Et le cayolar dans les Pyrénées occidentales.

https://fr.wikipedia.org/wiki/Cayolar

Eric

Le 2020-10-08 11:24, Yves P. a écrit :

La troisième "Capitelle" ressemble furieusement à un borie


Oui c'est pour ça que je propose aux spécialistes de mettre à jour
la page, pour montrer la diversité soit de formes, soit de noms.
Il doit aussi y en avoir en dehors de la France ?

__
Yves

On rajoute aussi celle-ci [1] ? :D



Links:
--
[1]
https://commons.wikimedia.org/wiki/File:All%C3%A9e_couverte_%C3%8Ele-Grande_06.jpg

___
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] JOSM version stable 17084 : traduction du Journal des modifications

[Eric SIBERT]

natural=sinkhole _(​dépression naturelle ou trou visible en surface
[3])_

La traduction française est doline [4] ;)


J'achète ;-).

Je me posais justement la question après des relevés sur un plateau 
calcaire.


Eric


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

Re: [OSM-talk-fr] validation : sorties nommées

[Eric SIBERT]

Le 30/09/2020 à 18:48, Rpnpif a écrit :

Le 30/09/2020 à 14:56, thevenon.jul...@free.fr a écrit :


- Mail original -
De: "osm sanspourriel" 
À: talk-fr@openstreetmap.org
Envoyé: Mercredi 30 Septembre 2020 14:11:35
Objet: Re: [OSM-talk-fr] validation : sorties nommées

*Vous connaissez des routeurs qui affichent les destinations ?*

Magic Earth le fait il me semble

OsmAnd itou.


Et surtout il les annonce vocalement. Ça le fait bien en périphérie de 
grandes villes quand tu arrives perpendiculairement à une autoroute, 
tout ça dans un enchevêtrement d'échangeur. Si le logiciel te dit juste 
"suivre A43", tu as une chance sur deux de partir dans le mauvais sens 
s'il ne dit pas en plus "direction Chambéry; Grenoble".


Eric

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

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

[Eric SIBERT]

Le 2020-09-29 14:48, Gilles a écrit :

On 29/09/2020 13:00, talk-fr-requ...@openstreetmap.org wrote:

Le 2020-09-28 00:07, Eric SIBERT via Talk-fr a écrit :

À Grenoble, on a les panneaux vélo-super-power :

https://www.mapillary.com/map/im/qAFGJjDNEmcMO5BL-gBfIg

Au feu rouge, les vélos peuvent aller partout en cédant le passage.

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

Ou une seule relation avec trois rôles "to"?


Une seule relation, avec trois membres :

1. le feu = via, avec la relation à créer ; si plusieurs ways
avant/après, chacune devra avoir le rôle via

2. la way qui mène au feu = from

3. la way qui quitte le feu = to


Je parle du cas particulier où le panneau dit que les vélos peuvent 
tourner à droite, aller tout droit et tourner à gauche:


https://www.mapillary.com/map/im/qAFGJjDNEmcMO5BL-gBfIg

Eric



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

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

[Eric SIBERT]

Le 2020-09-28 00:07, Eric SIBERT via Talk-fr a écrit :

À Grenoble, on a les panneaux vélo-super-power :

https://www.mapillary.com/map/im/qAFGJjDNEmcMO5BL-gBfIg

Au feu rouge, les vélos peuvent aller partout en cédant le passage.

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


Ou une seule relation avec trois rôles "to"?

Eric


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

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

[Eric SIBERT]

En terme d'utilisation, je connais peu d'algorithmes allant jusqu'à
prendre en compte les feux de signalisation lors de la création de
l'itinéraire et je ne pense pas que ces derniers représentent une part
importante des temps de trajets.


OSMAnd prend en compte les feux dans ses calculs d'itinéraire. Il m'a 
proposé des itinéraires voiture dans mon quartier passant par des 
petites rues peu roulantes mais évitant les feux et ils sont 
effectivement plus rapides.


Après, on se retrouve avec la question générale des panneaux (ou feux, 
radars) et de leur portée. On avait déjà eu une discussion à propos de 
la description des panneaux d'entrée/sortie d'agglomération et leurs 
supports. Je pense qu'à terme il faudra inclure les deux dans OSM.
- d'un côté la description physique du panneau (ou groupe de panneau) 
avec un point spécifique, support, l'orientation du/des panneau(x), la 
description réglementaire, le texte si ça a du sens (pour les 
entrées/sorties d'agglomération)...
- d'autre part, l'effet sur le way de la chaussée, là où change la 
limite de vitesse, où il est interdit de faire demi-tour, là où les 
vélos ont le droit de passer/tourner même au feu rouge...


Et peut-être aussi une relation reliant les deux aspects. Dans le cas du 
tourne-droit des vélos, on a déjà la relation, il faudrait lui rajouter 
un rôle genre traffic-sign vers le panneau physique.


Mes 0,02 €

Eric



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

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

[Eric SIBERT via Talk-fr]

À Grenoble, on a les panneaux vélo-super-power :

https://www.mapillary.com/map/im/qAFGJjDNEmcMO5BL-gBfIg

Au feu rouge, les vélos peuvent aller partout en cédant le passage.

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

Eric

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

Re: [OSM-talk-fr] Maj Cadastre vectoriel

[Eric SIBERT]

Bonsoir,

Ça y est, le cadastre vectoriel a été mis à jour sur la commune de Saint 
Martin d'Hères. Maintenant, il faut que je me souvienne de tous les 
chantiers rencontrés ces derniers mois ;-)


Sinon, il y a le cadastre de Grenoble (raster et vecteur) qui est figé 
depuis 3 ou ans. Toujours pas de traces de bâtiments livrés depuis 3 ans :-(


Eric

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

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

[Eric SIBERT via Talk-fr]

+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
- sauf quand il y a un une voie supplémentaire pour faire un créneau de 
dépassement

- pareil pour les routes pour automobile (panneau C107) à double-sens?
- 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.


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


Eric


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

Re: [OSM-talk-fr] Adhésion gratuite à l'OSMF

[Eric SIBERT via Talk-fr]

Le 29/08/2020 à 09:45, Jean-Claude Repetto a écrit :
Je ne sais pas si c'est récent, mais les contributeurs actifs peuvent 
désormais adhérer gratuitement à l'OSMF:

https://join.osmfoundation.org/active-contributor-membership/


Merci.

J'ai fait ma demande.

Eric

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

Re: [OSM-talk-fr] Dans la Vienne, 200 km de routes vont repasser à 90 km/h :: Collaborer avec le Département ?

[Eric SIBERT via Talk-fr]

Comment voyez-vous une collaboration d'OSM avec les services du 
Département ?




Si elle peut déjà se faire à sens unique, ça sera pas mal... publier les 
200km de routes en opendata ;)


Pourquoi juste les 200 km? On veut les limites de vitesses de toutes les 
départementales du département.


Quid des nationales nombreuses dans la Vienne? Pas concernées par le 
repassage à 90?


Eric

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

Re: [OSM-talk-fr] Altitude des panneaux

[Eric SIBERT]

Le 23/07/2020 à 11:20, Jacques Lavignotte a écrit :

Pour de la précision en GPS il faut aller vers :

https://fr.wikipedia.org/wiki/GPS_diff%C3%A9rentiel


D'ailleurs, à ce propos, je suis en train de faire des essais avec un 
récepteur GNSS différentiel. J'ai voulu faire des mesures sur ce type de 
panneaux, celui-là par exemple:


https://www.mapillary.com/map/im/fuqR2umra-1VDkJKYfG9dQ

J'ai voulu poser l'antenne en haut du poteau pour une meilleure 
réception. Eh bien, ils sont hauts ces poteaux. Vous prenez où 
l'altitude? En bas ou en haut?


Mes 0,02 €.

Eric

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

Re: [OSM-talk-fr] Altitude des panneaux

[Eric SIBERT]

L'altitude, c'est la hauteur au-dessus du géoïde. Le géoïde, c'est le 
niveau moyen de la mer (ou son extrapolation quand il n'y a pas de mer). 
Le géoïde, c'est une surface physique unique. Après, sa détermination 
peut être difficile. A quelques subtilités et erreurs de calcul près 
l'altitude doit être la même, qu'on vienne de France ou d'Italie.


Par ailleurs, comme déjà indiqué, il y a des grilles qui permettent de 
passer de l'ellipsoïde au géoïde. Les récepteurs GPS commencent par 
calculer une hauteur sur l'ellipsoïde. Ensuite ils utilisent une grille 
interne pour convertir en altitude et c'est généralement ce qu'ils nous 
affichent. Malheureusement, j'ai déjà vu une plage à 10 m d'altitude les 
quelques jours que j'ai passé à côté. La grille devait être 
insuffisante.


Enfin, on a des GPS avec capteur barométrique (mon Etrex 30). Ils 
passent leur temps à recaler le baromètre sur le GPS, ce qui ne résout 
pas le problème de grille mais permet de lisser les altitudes.


Pour revenir aux panneaux de rando, pour le moment, je ne mets que ce 
qui est sur le panneau même quand j'ai des doutes, parce que je ne suis 
pas sûr d'être meilleur.


Eric


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

Re: [OSM-talk-fr] Lignes de bus à Courchevel : au secours !

[Eric SIBERT]

Pour répondre à Christian, je commence par un ballon d'essai au niveau 
de la communauté locale avant d'attaquer au niveau global pour qu'on 
entame la discussion sur ce qui doit être dans OSM et ce qui n'a pas 
vocation à y être ;-).


Techniquement, sortir les limites administratives de tout poil ne paraît 
pas trop compliqué.


Le 08/07/2020 à 16:42, Yves P. a écrit :


La vraie question est : quand est-ce qu'on vire tous ces trucs
immatériels d'OSM et qu'on les met dans des bases externes?

En attendant que ça soit pris en compte par la communauté mondiale, 
j'aimerais des conseils sur les relations bus 😉


Au hasard :
- lignes de transports en commun

C'est matériel,  il y a des arrêts...


Pour moi, la partie matérielle (arrêt, abribus, quai, voie bus...) a sa 
place dans OSM. C'est la partie immatérielle, le concept de ligne, que 
je voudrais sortir. En pratique, la relation sur laquelle tu t'arraches 
les cheveux et qui rend très difficile l'édition de certaines routes 
(suite à l'ajout d'un terre-plein central par exemple). Quand il y 20 
relations de bus sur un bout de chaussée, des fois, je renonce à 
modifier. Mon seul conflit d'édition, c'est une fois où je modifiais la 
voirie à un endroit où passait une ligne de bus pendant qu'un autre 
contributeur faisait des modifs sur la même ligne de bus à des 
kilomètres de là.


Après, je suis conscient qu'avoir une base de donnée externe de ligne de 
bus (ou itinéraires de rando(c)) et maintenir un lien correct avec leur 
représentation physique dans OSM va être techniquement très difficile ;-).


Eric

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

Re: [OSM-talk-fr] Lignes de bus à Courchevel : au secours !

[Eric SIBERT]

La vraie question est : quand est-ce qu'on vire tous ces trucs 
immatériels d'OSM et qu'on les met dans des bases externes?

Au hasard :
- lignes de transports en commun
- limites administratives, politiques religieuses, d'aires protégées...

J'en ai rien à faire de connaitre toutes les lignes MachinBus et autres 
dessertes d'aéroports régionaux qui passent sur la nationale à côté de 
chez moi, en dehors des aspects pollution ;-)


Eric


Le 2020-07-08 13:11, Yves P. a écrit :

Bonjour,

Soit la T5 qui va de Moûtiers à Courchevel 1850 (avec semble-t-il un
A/R à la Tania)
https://www.openstreetmap.org/relation/8292018#map=14/45.4201/6.6372

Soit la B qui va de Courchevel 1850 à Saint-Bon-en-Tarentaise
https://www.openstreetmap.org/relation/1919549#map=14/45.4201/6.6372

LA B fait l'aller/retour mais elle est cassée à plusieurs endroits,
et à cause des sens-uniques et des ronds points le trajet n'est pas
tout à fait identique à l'aller et au retour.
Le départ et un rond point cassé à la sortie :
https://www.openstreetmap.org/relation/1919549#map=17/45.41440/6.63779

Il me parait plus simple et plus clair de faire une B Aller et une B
retour ?
(de plus JOSM n'arrive pas à trier correctement les membres)

J'ai vu aussi des ronds-points "découpés". J'ai fait ça aussi au
début, mais en fait ça complique la saisie.
Un rond point "intégral" ne pose pas de problème pour le routage,
ça fait seulement moche sur le rendu.

Merci de votre éclairage,

__
Yves

Horaires de la T5 :
https://www.transdevsavoie.com/media/upload/FHCourchevelChampagnyPralognanEte2020.pdf



___
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] Maj Cadastre vectoriel

[Eric SIBERT]

Bonjour,

Je repose une question déjà posée il y a quelques mois. Mais quand 
est-ce que le cadastre vectoriel est à mis à jour?


Ici, sur le terrain en construction :

https://osm.org/go/0CASgkNR4

il y a des nouveaux bâtiments. Ça fait des mois (avant le confinement) 
qu'on le voit dans le cadastre raster.


Le cadastre vecteur est censé être mis à jour tous les trimestres. Ok, 
je veux bien que le 1er avril, ils étaient perturbés. Mais maintenant 
qu'on a passé le 1er juillet, toujours rien.


Que faut-il faire? Où faut-il frapper?

Eric

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

Re: [OSM-talk-fr] takeout Mapillary... déjà 2To et 1.5 million de photos

[Eric SIBERT]

Question :

ça récupère les traces aussi? Ou l'enchaînement des photos au sein de 
séries?


Eric

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

[OSM-talk-fr] Alternative locale à Mapillary

[Eric SIBERT]

Bonjour à tous,

Suite au rachat de Mapillary par Facebook, je ne veux plus contribuer à 
Mapillary...


Néanmoins, Mapillary constituait un élément clé dans ma chaîne de 
contribution à OSM, lors de mes déplacement en voiture. Je suis un peu 
orphelin :-(. En pratique, je réalisais d'une part une capture d'images 
avec l'application Mapillary sur smartphone. D'autre part, 
j'enregistrais ma trace avec un GPS, en prenant des waypoints sur les 
éléments à ajouter (limites de vitesse, entrée d'agglomération...). De 
retour à la maison, je téléversais les images dans Mapillary. Ensuite, 
sur mon PC, j'ouvrais JOSM avec la trace GPS, dans un écran, et 
Mapillary dans un navigateur web dans le second écran. Je n'utilise pas 
beaucoup le plugin Mapillary dans JOSM. Quand je veux localiser 
précisément un objet (panneau par exemple), je compare ce qu'on voit 
dans la photo Mapillary avec l'orthophoto dans JOSM.


Question : y a-t-il un moyen de faire quelque chose de similaire sans 
passer par Mapillary? A priori, il n'y a pas d'alternative valable sur 
internet. En faisant ça en local? Toujours en enregistrant les photos 
sur smartphone en déplacement mais en les transférant directement sur 
PC? Ensuite pouvoir les afficher sur fond de carte OSM, à la Mapillary? 
Toute piste est bienvenue.


Eric

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

[Eric SIBERT]

Le 18/06/2020 à 13:27, Jacques Lavignotte a écrit :

OSMAnd n'est pas le bon outil. Il fait trop de choses.


+1.

Il faut prendre OSMTracker. On active l'enregistrement de la trace en 
continue comme ça le GPS fonctionne en permanence même téléphone éteint 
et arrive à capter plus de satellites, d'où une meilleure précision. 
Quand on ne prend pas de photo, on tient le téléphone à bout de bras, le 
plus haut possible ;-). Ne pas oublier le gilet OSM pour expliquer ce 
que tu fais...


Eric

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

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

[Eric SIBERT]

Lorsque tu utilises un récepteur mobile, et qu'il y a des masques, cela 
n'impactera que toi. 


Au niveau du récepteur mobile, plus tu as de satellites en commun avec 
la base et plus facilement tu vas détecter ceux qui subissent des 
réflexions parasites (sur façade de bâtiment par exemple) avant 
d'atteindre ton récepteur et tu pourras les enlever du calcul.


Pour la question de Sébastien sur la localisation de la base, j'ai fait 
des essais de mesure depuis mon balcon. On capte sans difficulté les 
satellites masqués par les bâtiments mais qui se réfléchissent sur les 
façades voisines. Si on introduit ça dans des calculs différentiels...


En ville, ce n'est pas facile d'installer une station de référence sauf 
à être en terrasse au dernier étage.


Eric

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

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

[Eric SIBERT]

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 ?


Celui-là?

https://gnss-sdr.org/

Eric

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

Re: [OSM-talk-fr] import cadastre d'une petite zone

[Eric SIBERT]

Dans JOSM, quand on télécharge une zone, il y a un onglet 
"Téléchargement depuis le Cadastre". On choisit Objets : bâtiments. Ça 
télécharge dans un nouveau calque (par planches cadastres entières). On 
copie les bâtiments qu'on veut et on fait un "Coller à la position 
originale" Ctrl+Alt+V dans le calque OSM.



Question annexe: à quelle fréquence sont mises à jour les données 
cadastre vecteur? J'ai un secteur à côté de chez moi avec des nouveaux 
bâtiments visibles depuis des mois dans le cadastre raster mais pas en 
import dans JOSM?


Eric

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

Re: [OSM-talk-fr] Evolution des règles pour les plages et la ligne de côte

[Eric SIBERT]

Le 07/05/2020 à 13:54, Djo_man via Talk-fr a écrit :
J'aimerais bien et j'y pense depuis un bout de temps car effectivement 
le wiki lui-même (coastline, Beach, bare_rock, mud, tidal, tidalflat, 
frontieres marines, shoal, etc) manque de ces images. Mais il va falloir 
s'y coller car ce n'est pas si simple...


S'il vous plaît... dessine-moi une mangrove...

;-)

Mes 0,02 €

Eric

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

Re: [OSM-talk-fr] En regardant passer le train...

[Eric SIBERT]

Sur le changeset il y avait "review_requested [2]=yes".

Et aussi "changesets_count [3]=1". Donc qu'il casse la relation, pas
vraiment étonnant.


Je n'avais pas investigationné l'origine de la contribution.



Marc te rappellera l'importance d'accueillir les nouveaux. C'est
valable dans le Far West aussi.


Oui, c'est ce qu'on se dit au début...


Tu le contactes (in English) sur le changeset ? Tu fais la modif
proprement ?


J'ai fait la modif.



Sachant que la personne a contribué 2 fois et la dernière fois il y
près d'un an, je ne sais si ça vaut le coup.


Par expérience, je considère que ça ne vaut pas le coup.




Donc pour revenir à ta question du début, l'habitat est concentré
en Amérique du Nord (CA, USA) même s'il y a de l'étalement urbain
au format XXL. Et dans ces coins éloignés,


Éloigné??? J'ai passé quelques mois dans le Middle East puis j'ai fait 
du tourisme dans l'Utah. Là, c'est éloigné :-).



le réseau routier c'est
essentiellement de l'import Tiger


On a déjà dit que Tiger était l'exemple type du mauvais import.

Eric


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

[OSM-talk-fr] En regardant passer le train...

[Eric SIBERT]

En ces temps de confinement, on regarde n'importe quoi sur youtube:

https://www.youtube.com/watch?v=9wT5O0k3vec

Puis assez rapidement, je me demande où c'est dans OSM. Tiens, on voit 
une voie ferrée dans la vidéo qui n'est pas dans OSM. Qu'est-ce qu'on a 
comme source? Bing. C'est bien calé ça? Allons voir l'échangeur 
autoroutier voisin. À voir les traces GPS et Mapillary, Bing est bien 
calé. Par contre les bretelles de l'échangeur... :-(. D'ailleurs, il n'y 
a pas que la position. Il y aussi le nombre de voies, les séparations de 
bretelle et j'en passe, qui posent problème. Trop gros chantier. Je me 
contente de rajouter la seconde voie ferrée.


Puis sur la fin de la vidéo, il y a une route qui fait des zigzags le 
long de la voie. Là, il y a eu des travaux, qu'on voit sur la vidéo. La 
route a été reprofilée. Ça a été intégré dans OSM à la hache. Plus, 
manque un pont. La relation de la route est restée sur le tronçon 
désaffecté...


Donc, la question: le réseau routier US dans OSM, c'est tout comme ça?

Bon confinement.

Eric

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

Re: [OSM-talk-fr] Ça reste ouvert et notes : avis et retours

[Eric SIBERT]

Je n'ai pas répondu aux réponses de mon message :-p.

Mais je pense effectivement qu'il ne faut pas hésiter à utiliser 
description:covid19 plutôt qu'essayer de tout faire rentrer dans des 
boîtes (pardon, des clés).


Pour le cas particulier de l'opticien, il faut mettre 
opening_hours:covid19=off car tu ne peux pas te pointer à la permanence 
si tu n'as pas demandé avant par téléphone.


Et je vais de ce pas le modifier.

Eric

Le 17/04/2020 à 18:42, George Kaplan a écrit :

Le 14 avr. 2020 à 17:45, Eric SIBERT  a écrit :


Dans le style, opticien qui assure une permanence de 15h à 16h pour les 
livraisons. Pour les nouvelles commandes (lentilles, lunettes) ou les 
réparations, prendre rendez-vous avec un numéro de téléphone différent de 
l'habituel.

J'ai mis :
- phone:covid19 = 06 xx -> Ça s'affiche sur le site !!!
- takeaway:covid19 -> "Vente à emporter uniquement". Non, c'est plutôt retrait 
de commande. Comment coder? La pizzeria voisine fait pareil : uniquement retrait des 
commandes faites par téléphone.

Eric


Je me pose une question à ce sujet, je n’ai pas vu de consensus sur la liste.

Pour ce genre de cas (un commerce qui n’assure plus que des livraisons ou sur 
RDV), est-ce qu’on le considère ouvert ou fermé ? Traduit en tags, ça donne :
takeaway:covid19=only
opening_hours:covid19=open ou =off ?

J’avoue que j’hésite encore.

George


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

Re: [OSM-talk-fr] Comment lier une pompe à essence dans OSM avec le prix-carburants.gouv.fr

[Eric SIBERT]

Le 17/04/2020 à 14:03, PanierAvide a écrit :

Bonjour Yves,

Le tag en question c'est ref:FR:prix-carburants=*

Et dans l'oreillette on me dit qu'un site pour avoir les prix des 
carburants reliés à OSM existe déjà : https://openfuelmap.net/


Je viens d'essayer pour le GPL et c'est moyen. Quand on clique sur GPLc, 
très peu de stations apparaissent:

https://openfuelmap.net/#10/45.1612/5.2927

Des fois, en se décalant, des stations apparaissent mais il en manque 
encore:

https://openfuelmap.net/#10/45.4365/5.4080

Quand on regarde autour de Grenoble, certaines stations manquent dans
https://www.prix-carburants.gouv.fr/
mais j'en ai trouvé deux qui:
- ont une clé ref:FR:prix-carburants (3861 et 38320006)
- ont fuel:lpg=yes
- sont dans prix-carburants

Station GPL dans osm mais pas sur prix-carburants : 3873

E85 semble aussi avoir des problèmes.

Tests avec Firefox et Edge.

Cordialement

Eric

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

Re: [OSM-talk-fr] Ça reste ouvert et notes : avis et retours

[Eric SIBERT]

1) "détails" contient juste une précision qui pourrait être saisie
directement dans "description:covid19" (ex : "permanence
téléphonique")


Dans le style, opticien qui assure une permanence de 15h à 16h pour les 
livraisons. Pour les nouvelles commandes (lentilles, lunettes) ou les 
réparations, prendre rendez-vous avec un numéro de téléphone différent 
de l'habituel.


J'ai mis :
- phone:covid19 = 06 xx -> Ça s'affiche sur le site !!!
- takeaway:covid19 -> "Vente à emporter uniquement". Non, c'est plutôt 
retrait de commande. Comment coder? La pizzeria voisine fait pareil : 
uniquement retrait des commandes faites par téléphone.


Eric


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

Re: [OSM-talk-fr] Rue trop étroite pour que 2 voitures se croisent ?

[Eric SIBERT]

Le 11/04/2020 à 17:03, Florimond Berthoux a écrit :

J'allais mettre +1 mais visiblement non :
lanes=* « Note that it is valid to tag lanes count also in case where 
lanes are not marked with paint on the surface »


Je vois qu'il s'agit d'une modification récente (juin 2019) suite à une 
discussion sur la liste tagging dont on ne peut pas dire qu'elle ait 
abouti à un consensus.


https://lists.openstreetmap.org/pipermail/tagging/2019-June/046002.html

Il y a aussi discussion sur la page du wiki:
https://wiki.openstreetmap.org/wiki/Talk:Key:lanes#Marked_or_unmarked_lanes

Pour revenir au point de départ :

Le fait qu'il n'y ait qu'une voie n'indique pas que c'est étroit. C'est 
un détournement de ce pourquoi le tag est fait. Il y a des tas de routes 
de campagne sans marquage où on peut se croiser sans difficulté.


Eric

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

Re: [OSM-talk-fr] Rue trop étroite pour que 2 voitures se croisent ?

[Eric SIBERT]

Pour moi, lanes=* doit être réservé aux chaussées où des voies sont 
matérialisés par traçage. Ce n'est pas le cas de la rue en question.


+1 pour :

narrow=yes
width=*

https://lists.openstreetmap.org/pipermail/talk-fr/2010-June/023564.html

Eric

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

[OSM-talk-fr] Cestdejaferme

[Eric SIBERT]

Bonjour,

J'ai un petit problème avec ma banque. L'agence a été fermée (le DAB 
aussi) pour travaux un peu avant le confinement. Les travaux...


Alors, j'ai mis un access=no le temps des travaux et je n'ai rien ajouté 
pour le covid. Je vois que ça apparaît en vert dans caresteouvert.


https://www.caresteouvert.fr/@45.186494,5.744184,18.40

Une autre proposition pour coder la fermeture temporaire pour travaux?


Dans un autre style, la banque d'à côté pendant le confinement:
- sur rendez-vous le matin
- par téléphone l'après-midi
On code comment?

A+

Eric

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

Re: [OSM-talk-fr] restrictions temporaires

[Eric SIBERT]

- on évite généralement les restrictions temporaires courte durée,
dans osm, de nombreux calculateur ne mettent pas assez souvent
leur donnée à jour pour les traiter. on dit parfois qu'il faut
n'encoder que ce qui dure plus qu'un mois.


L'autre logique est de ne signaler que ce qu'on peut contrôler 
régulièrement.


Annoncer une fermeture temporaire de 15 jours dans un coin où on passe 
une fois par an, c'est risquer d'introduire une erreur à long terme.


Annoncer la même fermeture sur un itinéraire qu'on emprunte tous les 
jours, pas de problème. Si les outils en aval ne sont pas assez 
réactifs, ce n'est pas notre problème. (On ne taggue pas pour le rendu 
:-p).


Eric


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

Re: [OSM-talk-fr] restrictions temporaires

[Eric SIBERT]

Disons que si on reprend ce qui se fait pour les commerces, on partirait 
sur un

access:covid19=no

Si on veut rester dans la logique de l'accès conditionnel, on serait 
plus sur

access:conditional=no @ covid19

Mes 0,02 €

Eric


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

Re: [OSM-talk-fr] Carrosserie

[Eric SIBERT]

Bonjour,

J'ai constaté à Madagascar que les garages auto étaient presque tous 
spécialisés:

- un pour la mécanique
- un pour la carrosserie
- un pour l'électricité
- un pour les pneus...

Ça serait bien d'avoir une approche générale.

Genre:

service:car_repair:***=yes/no

ça me paraît pas mal.

Eric


Le 2020-04-03 09:55, Yves P. a écrit :

Bonjour,

En traiter des notes cette nuit, je suis tombé sur une colle :
comment taguer une carrosserie ?

Le tag de base est SHOP=CAR_REPAIR mais pour le tag secondaire, il
n’est pas décrit dans la page française et il y a des variantes !

* SERVICE=BODY

ou

* SERVICE:VEHICLE:BODY_REPAIR=YES

La version initiale a 2 inconvénients : service est utilisé par
d’autres objets (HIGHWAY=SERVICE notamment) et il contient plusieurs
valeurs séparées par des ;
Avec les variantes de valeurs suivantes :

* AUTO_BODY
* AUTO_BODY_REPAIR
* auto_paint
* BODY
* body painter
* BODY REPAIR
* BODY_REPAIR
* body_shop
* BODY_WORK
* BODYWORK
* BODYWORK REPAIR
* BODYWORKS
* bumper_repair
* car_paint
* chroming
* COLLISION_REPAIR
* paint
* paint_and_body
* paint_shop
* painter

iD à introduit la seconde version qui est beaucoup plus utilisée. Il
y a une page wiki en anglais [1] seulement
Voici un exemple [2].

La traduction dans iD de la clé est Véhicule de service :D
Les valeurs ne sont pas traduites.

Voilà, il y a des discussions et du nettoyage en perspective ;)

__
Yves



Links:
--
[1] https://wiki.openstreetmap.org/wiki/Key:service:vehicle
[2]
https://www.openstreetmap.org/edit?editor=id&node=5762528386#map=19/49.89602/16.45754

___
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] Création de points de référence pour calage des imageries satellites - quelle approche et quel matériel ?

[Eric SIBERT via Talk-fr]

Le 2020-02-17 13:55, marc marc a écrit :

Merci pour les précieuses réponses précédentes.

Le 17.02.20 à 13:27, Eric SIBERT via Talk-fr a écrit :

ma recommandation première pour caler les photos satellites est
d'enregistrer un maximum de trace GPS sur les zones de travail.


je suis mitigé par cette solution.

[...]

Là, je parle surtout de l'Afrique, la question initiale du fil de 
discussion. À Madagascar, j'ai l'impression d'être presque le seul 
contributeur à téléverser des traces GPS. La seule ville où il y a trop 
de traces, c'est celle de ma belle-famille. Sur les grands axes, ça 
devient illisible mais on peut aussi caler l'imagerie avec les axes 
secondaires.



Ou alors tu as un outil pour trouver la valeur médiane d'un ensemble de
traces ?


Non. À un moment donné, il y avait un outil comme ça avec les données 
strava. J'ai essayé avec les traces GPS des cyclistes en montagne mais 
ce n'était pas très concluant. Les cyclistes enregistrent beaucoup plus 
de points à la montée qu'à la descente, ce qui tirait latéralement les 
traces côté montée. Ensuite, l'algorithme coupait un oeu sauvagement les 
virages.





comparativement, laisser un enregistreur gps quelque part pour obtenir
une position précise me plaît beaucoup.
en déduire ensuite par différentiel la position précise d'un point bien
identifiable sur imagerie me semble le top. au final un seul point dans
osm et surtout une grande facilité à faire l'alignement, tant pour moi


Oui mais beaucoup plus cher, un facteur limitant dans certains coins 
d'Afrique.


La solution avec deux F9P va couter 800 € (pour une portée de 35 km). On 
pourrait imaginer de travailler en mono-fréquence avec une puce Neo-M8M 
pour une centaine d'euros par récepteur et une portée limitée à 10 km.


Alors que pour ceux qui ont déjà un smartphone...

Eric


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

Re: [OSM-talk-fr] Création de points de référence pour calage des imageries satellites - quelle approche et quel matériel ?

[Eric SIBERT via Talk-fr]

faut-il laisser tourner une appli utilisant
le gps en permanence ?


Oui. OSMTracker par exemple, surtout que ma recommandation première pour 
caler les photos satellites est d'enregistrer un maximum de trace GPS 
sur les zones de travail.




paramètres de la ionosphère...).


cela est-il pris en compte aussi quand l'appareil est allumé en
intérieur avant de sortir (voiture, veranda) ou cette mesure risque
d'être faussée ?


Plus il y a de satellites, plus on récupère les infos rapidement. Sinon, 
on risque de travailler avec des informations incomplètes, voir 
périmées. De plus, en captant bien les satellites, le récepteur va, pour 
chaque satellite, en plus de la mesure de distance, récupérer la phase 
(le nombre de cycles de l'onde porteuse entre deux mesures de distance 
successives). La phase est très précise car elle est mesurée à une 
fraction de longueur d'onde près (longueur d'onde du signal GPS=20 cm). 
Ça permet de lisser efficacement la position dans le temps. Si on coupe 
la réception, on repart plus ou moins à zéro. Dans la véranda, collée à 
la maison et avec une structure métallique, ça risque de ne pas être top 
car on ne voit pas tous les satellites. Pour la voiture, un parebrise 
athermique risque aussi de poser problème. C'est néanmoins ce que je 
fais. Dès que j'arrive à la voiture, je mets en route le GPS sur le 
tableau de bord, le plus loin possible sous le parebrise. Ensuite, je 
charge les enfants, les bagages et tout...


Eric


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

Re: [OSM-talk-fr] Création de points de référence pour calage des imageries satellites - quelle approche et quel matériel ?

[Eric SIBERT via Talk-fr]

Bonjour,

En complément de mon précédent message et de celui de Stéphane.

Pour l'utilisation d'un récepteur GPS autonome ou d'un smartphone, on le 
met en route à l'avance et on le laisse sur un point dégagé pendant 
10-15 mn, histoire de bien capter un maximum de satellites et de 
récupérer les dernières informations du réseau (satellites en service, 
paramètres de la ionosphère...).


Pour la future campagne à Madagascar, je prévois de partir avec deux 
enregistreurs F9P. Pour les périodes plus ou moins en fixe, une dans un 
Parc National, l'autre dans une ville, je prévois de laisser un 
récepteur en fixe pour la durée du séjour alors que l'autre servira aux 
relevés sur le terrain. De retour en France, un calcul PPP sur les 
stations fixes temporaires doit permettre de descendre à 10 cm de 
précision sur ces stations. Ensuite, on fait un calcul différentiel 
entre la station fixe et la station mobile qui se déplace à quelques 
kilomètres de là, avec une incertitude de 1 cm + (1 mm par kilomètre 
d'écart). L'usage de deux récepteurs/antennes identiques permet de 
limiter certains biais de calcul.


Eric


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

Re: [OSM-talk-fr] Création de points de référence pour calage des imageries satellites - quelle approche et quel matériel ?

[Eric SIBERT via Talk-fr]

Mon expérience à Madagascar (36 15 My Life pour les plus anciens...)

Depuis quelques années, je travaille avec un Garmin etrex 30, captant 
les satellites GPS et Glonass. Des mesures répétées plusieurs jours de 
suite sur un point dégagé me donnent un écart type en X et Y de 1,60 m. 
Je pense qu'en France métropolitaine, avec les corrections Egnos, on 
doit être à moins d'un mètre. En tout cas, assez pour voir la différence 
entre WGS84 et RGF93 [1,2].


Il y a eu une période à Madagascar où je mesurais la position de points 
de repères sur le terrain. Ensuite, j'allais dans JOSM. Pour chaque 
point de repère, j'estimais le décalage. Je reportais des valeurs X et Y 
du décalage dans un tableur. Je faisais la moyenne des valeurs pour 
l'ensemble d'une ville (en faisant attention qu'il n'y ait pas 
juxtaposition de plusieurs vues aérienne). Enfin, dans JOSM, 
j'appliquais la correction moyenne. Un peu lourd puis il faut vérifier 
de temps à autre qu'ils n'ont pas changé l'image source avec un nouveau 
décalage. Maintenant, je me contente d'ouvrir la vue aérienne dans JOSM. 
Je fais afficher les traces GPS disponibles dans OSM. Visuellement, je 
recale la vue aérienne. Ça va pas mal aussi. Il faut avoir assez de 
traces GPS. Dans certains coins, mon problème est que j'ai trop de 
traces et que je ne vois plus rien ;-).


Ensuite, pour un récepteur plus précis, laisse tomber le récepteur à 2 
k€. Il ne fait pas grand chose de plus qu'un récepteur grand public et 
la précision métrique nécessite une correction comme EGNOS non 
disponible en Afrique.


À l'instigation de Stéphane Péneau, je suis en train de me monter un 
enregistreur de donnée GNSS brutes [3]. Quatre constellations, 
bi-fréquence. 400 € de pièces, y compris la TVA payée à l'import. Il 
faut calculer à postériori les corrections pour avoir la meilleure 
précision, idéalement, par rapport à une station de référence. Stéphane 
a aussi fait plusieurs forks [4] (dont support bluetooth? Je ne retrouve 
pas).


Ce n'est peut-être pas la meilleure solution pour avoir la meilleure 
précision possible en temps réel car il ne supporte pas les corrections 
SBAS (WAAS, EGNOS...). Il est vraiment fait pour travailler en 
différentiel, que ce soit en temps réel ou à postériori. Dans tous les 
cas je vais essayer d'évaluer la précision dans les différents cas de 
figure en France et à Madagascar.


Eric


[1] : 
https://lists.openstreetmap.org/pipermail/talk-fr/2019-September/094202.html

[2] : https://www.openstreetmap.org/user/StephaneP/diary/390290
[3] : https://github.com/PaulZC/F9P_RAWX_Logger
[4] : https://github.com/Stefal/F9P_RAWX_Logger



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

Re: [OSM-talk-fr] Nouvelles communes françaises issues de fusion et OSM

[Eric SIBERT via Talk-fr]

Et j'obtiens 943 communes qui n'ont pas comme nom celui de leur 
admin_centre.

[...]



Il y en a peut être un peu moins que ça, en regardant rapidement je vois 
des trucs bizarres :
un name=Saint-Pierre-d'Entremont (Isère) et un 
name=Saint-Pierre-d'Entremont (Savoie)


Un village traversé par la frontière entre la Savoie* et la France!

Au final, deux communes distinctes avec le même nom mais dans deux 
départements différents:


https://www.mapillary.com/map/im/XNQGJlkkRhXWYQ6lthzkFg

Et le code postal de la commune iséroise rattaché à la Savoie!!!

Eric

* Savoie indépendante, du fois pour nos vaches!!!

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

Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages

[Eric SIBERT via Talk-fr]

Je dirais que quasi-systématiquement, il y a rupture des ways au niveau 
du panneau d'entrée/sortie d'agglomération parce que les limites de 
vitesse changent généralement de part et d'autre (ou au moins le 
source:maxspeed=*, ou le nom de rue si on saute d'une commune urbaine à 
l'autre...).


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

Peut ne pas fonctionner et non ne peut pas fonctionner.

Il faut pour que ça ne marche pas que les voies soient tracées en sens 
opposé.


En général on peut retourner une voie.

[===>]°[>]
        rue A                     rue B
Pas de soucis.

[===>]°[<]
        rue A                     rue B
Soucis. Retourner l'une des voies résout le problème.


On reste à la merci d'un contributeur qui retournerait ultérieurement 
le(s) way(s) pour une raison ou une autre (aménagement latéral 
disymétrique...) et qui n'aurait pas conscience de l'impact sur les 
panneaux entré/sortie.


Eric

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

Re: [OSM-talk-fr] OpenStreetMap un bloatware ?

[Eric SIBERT via Talk-fr]

Le 18/01/2020 à 18:10, Stéphane Péneau a écrit :
> J'ai été assez surpris d'un commentaire sur linuxfr, qui citait
> OpenStreetMap dans sa liste des "bloatwares" [1]. Après lui avoir
> demandé comment il en était arrivé à cette conclusion, sa réponse [2] me
> donne l'impression qu'il mélange la BDD, et le rendu. Je me trompe ?


C'est un peu l'impression. Tu peux lui dire qu'OSM est bien à la base de 
données. Il y a pleins d'utilisations en aval dont le rendu par défaut. 
Ce rendu par défaut est juste un démonstrateur qui n'a pas vocation à 
être utilisé en production. Ceux qui tirent trop dessus se font bloquer. 
Libre à lui de faire son propre serveur/rendu ultra-optimisé mais le 
temps (même bénévole) c'est de l'argent. Alors, on fait des choix entre 
ressources matériels et ressources humaines.


Tout n'est pas perdu. Il faut lui montrer la démo de serveur de tuiles 
vectorielles sur rasp ;-)


Eric


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

Re: [OSM-talk-fr] Import bâti cadastre dans JOSM

[Eric SIBERT]

 Je
voudrais ré-importer mais en conservant les tags des anciens bâtiments.
Une méthode facile proposée?


https://cadastre.damsy.net te prémache un conflate dans josm qui te
permet de conserver les id et les tags existant dans osm


Commune de Lumbin (38).

1428 correspondances. 1300 conflits. Je ne sais que faire...

(Il n'y a pas que le bâti qui aurait besoin d'un gros coup de chiffon 
d'ailleurs).





Tu peux bien évidement aussi charger le tout "à la main" comme
d'habitude


En fait, j'ai fait du remplacement pur et simple sur certaines parties 
de la commune au début de l'année.



la dernière solution si c'est juste un décalage est de sélectionner tout
le batiment et de déplacer (à la souris) la sélection pour l'aligner par
exemple sur l'imagerie.


Non, ça ne marche jamais ;-). Le décalage est toujours variable à 
l'échelle de la commune.


Eric

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

Re: [OSM-talk-fr] Import bâti cadastre dans JOSM

[Eric SIBERT]

Heu... et sinon, j'ai un autre problème. J'arrive sur une zone. Je 
constate que le bâti dans OSM est mal calé (par rapport au GPS, aux 
orthophotos...). Je vois aussi que le cadastre actuel est mieux calé. Je 
voudrais ré-importer mais en conservant les tags des anciens bâtiments. 
Une méthode facile proposée?


Eric

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

Re: [OSM-talk-fr] Import bâti cadastre dans JOSM

[Eric SIBERT]

Disons que quand je n'y arrive pas d'un côté, j'essaie de l'autre ;-). 
En l'absence de mode d'emploi, je n'avais pas trouvé la nouvelle méthode 
à utiliser dans JOSM. Par ailleurs, ce que je reproche à l'import direct 
dans JOSM, c'est de ramener tout le bâti des planches cadastrales 
concernées, pas uniquement la zone concernée. Il y aurait une 
élimination automatique de ce qu'on a pas demandé, que je ne serais pas 
contre.


Après, remplacer cadastre.openstreetmap.fr par un mode d'emploi actuel, 
oui. De toute façon, cadastre.openstreetmap.fr est inutilisable 
actuellement.


Eric

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

Re: [OSM-talk-fr] Import bâti cadastre dans JOSM

[Eric SIBERT]

Le 26/12/2019 à 19:44, Eric SIBERT a écrit :

Comment merge-t-on la sélection?


Dans le menu Sélection ou

Ctrl+Shift+M

;-)

Eric

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

Re: [OSM-talk-fr] Import bâti cadastre dans JOSM

[Eric SIBERT]

il ne faut pas merger tout le calque 


Oui, je nettoie le calque avant de merger.


mais sélectionner les batiments
manquant et merger la sélection


Comment merge-t-on la sélection?

Cordialement

Eric

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

[OSM-talk-fr] Import bâti cadastre dans JOSM

[Eric SIBERT]

Bonjour,

J'ai l'impression de poser les mêmes questions tous les 6 mois :-(
La fois d'avant:
https://lists.openstreetmap.org/pipermail/talk-fr/2019-July/093691.html

En allant sur cadastre.openstreetmap.fr, en non sécurié, en sécurisé 
simple, en sécurisé en cliquant sur le cadenas vert pour dire que ce 
n'est pas grave si tout n'est pas sécurisé, la fenêtre pour sélectionner 
la zone à exporter reste vide.


Directement dans JOSM, je vais dans Télécharger puis l'onglet 
"Téléchargement depuis le Cadastre". Je sélectionne la zone et ça 
télécharge. Je me retrouve avec des couches edigo-xxx.tar.bz2 avec deux 
petits triangles oranges d'avertissement. Quand je fusionne avec le 
calque principal, les triangles sont transmis au calque principal. Je ne 
peux alors pas renvoyer les données vers OSM.


Comment j'importe un morceau de bâti du cadastre???

Merci d'avance

Eric

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

Re: [OSM-talk-fr] Rendu transport routier...

[Eric SIBERT]

Pour les hauteurs maxi, le panneau est obligatoire en dessous de
4,30m. Il me semble que sur les autoroutes, l'indication commence au
delà.


De mémoire, qu'on a déjà discuté ici, 4,30 m sur les petites routes, 
4,50 m sur les routes principales, 4,75 m pour les autoroutes mais aussi 
moins de 6m sous les câbles, en particulier les caténaires.


Il y a aussi la limite de poids par défaut à 44T, plus ou moins:
https://www.lemoniteur.fr/article/les-poids-lourds-de-44-t-autorises-mais-sous-des-contraintes-techniques.621579

Et la limitation de poids par essieu est rendue? (je ne retrouve pas 
d'exemple sur le terrain...).


Eric


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

Re: [OSM-talk-fr] Rendu transport routier...

[Eric SIBERT via Talk-fr]

- restriction dans un seul sens?


En ajoutant une flèche sur le halo rouge ?


Non car je vois venir le cas de restrictions différentes dans les deux 
sens ;-)

10 T à la montée, 3,5T à la descente...

Une flèche derrière le panneau?

Eric


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

Re: [OSM-talk-fr] Rendu transport routier...

[Eric SIBERT]

Le 14/12/2019 à 18:29, Christian Quest a écrit :
Je travaille depuis quelques temps sur un rendu destiné au transport 
routier.


Je finalise une couche en overlay qui rend visible les restrictions:
- maxheight
- maxweight
- maxwidth
- hgv/goods
- hazmat

Voici ce que ça donne: http://osm.cquest.org/fortissimo/#15/48.8324/2.3837


Je viens de regarder. Quelques remarques:
- maxwidth/maxheight : on ne voit pas bien les petites pointes autour de 
la valeur et on a du mal à distinguer les deux limitations.
- double-restriction (maxweight = 3.5 et maxwidth = 2.2 par exemple). On 
ne voit que le maxweight.
- restriction dans un seul sens? (la côte de Laffrey : 
https://www.openstreetmap.org/#map=15/45.0344/5.7682

https://fr.wikipedia.org/wiki/Rampe_de_Laffrey )



Je découvre du coup de valeurs pas très catholiques dans ces tags !


Des exemples, des exemples !!!


Comme quoi, dès qu'on rend visible certaines données OSM...


On ne taggue pas pour le rendu... mais ça aide ;-).

Eric

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

Re: [OSM-talk-fr] Systèmes géodésiques et OSM

[Eric SIBERT]

Le 06/09/2019 à 11:14, Eric SIBERT via Talk-fr a écrit :
D'ailleurs, je suis en train de faire des mesures répétées sur mon 
trajet domicile-travail  pour voir ce qu'il en est.



C'est chose faite avec un récepteur Garmin Etrex 30 en mode GPS+Glonass, 
en terrain dégagé, sur le campus de Saint-Martin-d'Hères:


http://geek86.free.fr/osm/campus_saint_martin_dheres.jpg

J'ai essayé de rouler précisément sur le raccord entre zone claire et 
zone sombre. Voir dans mapillary:

https://www.mapillary.com/map/im/xFBBFuiCsI6Pu-WK4dsGbw

Le cadastre et la BDOrtho sont très bien alignés entre eux. Par contre, 
les traces GPS sont systématiquement décalées.


Conclusion on peut mesurer la dérive des plaques avec un récepteur GPS 
grand public ;-)

Quant à OSM...

Eric

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

Re: [OSM-talk-fr] Systèmes géodésiques et OSM

[Eric SIBERT via Talk-fr]

Variante, comme la dérive des points de référence est aussi fournie
avec la réalisation, tous les jours à minuit, on corrige les
coordonnées dans OSM pour tenir compte de la dérive :-).


D'ailleurs, c'est déjà en place mais peut-être pas tous les jours:

https://blog.openstreetmap.org/2017/03/31/osm-plate-tectonics/

;-)

Eric

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

Re: [OSM-talk-fr] Systèmes géodésiques et OSM

[Eric SIBERT via Talk-fr]

Demain on peut supposer que nos GPS donneront les coordonnées dans le
système local : il s'agit de projeter un point dont on a la date dans
un système,


Non, ce n'est pas simple. Ça suppose de connaître pour toutes les zones 
de la planète le système local retenu. Pas très global comme solution.



c'est bien plus simple que de projeter des milliards de
points dont on n'est pas sûrs de la date dans un système.


Justement, le travail à faire pour le futur, c'est de faire en sorte de 
clarifier cette question de date.




Quand à la fréquence de rafraichissement des données, on a une
idée avec l'Australie qui bouge vite : une modification en 25 ans et
après passage à un système plus dynamique, voir
https://www.spatialsource.com.au/surveying/gda2020-and-overcoming-the-web-mercator-dilemma


Et pendant 25 ans, des contributions mélangées entre GDA94 et 
WGS84(réalisation inconnue à date inconnue) qui te font prendre 
l'autoroute à contre sens ;-)


D'ailleurs dans l'article, ils disent que WGS84 ne veut rien dire, qu'il 
faudrait parler de  WGS84(G1762)@2019.5 par exemple. Tant qu'on ne 
clarifie ça dans OSM, on est dans le blocage.



Oui, j'entends entre les GPS à 100 m près de 1994 et ceux
d'aujourd'hui il y a eu quelques progrès, mais rassurez-moi, si vous
trouvez que d'après le GPS la boîte-aux-lettres se trouve à côté
de la boulangerie et non de la poste, vous l'ajoutez bien à côté de
la poste ?


On ne taggue pas pour le rendu. On a des organismes publics qui nous 
fournissent des données au millimètre. Si on veut des échanges 
bidirectionnelles, il ne faut pas qu'en retour, on sorte des données 
avec des doutes de plusieurs mètres.



Et oui, on travaille en relatif, les coordonnées absolues
sont un confort récent.


C'est plus qu'un confort, c'est une opportunité ;-).

Eric


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

Re: [OSM-talk-fr] Systèmes géodésiques et OSM

[Eric SIBERT via Talk-fr]

Vu la précision du stockage, chaque jour on ajoutera une dérive de
(0,0) à tous les points. Soit une dérive de (0,0) au bout d'un an.


C'est que le stockage n'est pas assez précis ;-). C'est côté OSM qu'il 
faut bouger.


D'ailleurs, je viens de chercher des infos sur le stockage interne d'OSM 
[1]. Il semble que les latitudes/longitudes sont en int4 (Entier signé 
sur 4 octets ). Ça fait au mieux une résolution de 9 mm (=4 km/2^32) 
:-(. Quand on voit que ITRF2014 [2] est annoncé avec une précision sur 
les positions à 3 mm et sur les dérives à 0,2 mm/an, il va vraiment 
falloir faire quelque chose au niveau d'OSM.


[1] : https://wiki.openstreetmap.org/wiki/Database

[2] 
https://www.iers.org/SharedDocs/Publikationen/EN/IERS/Publications/tn/TechnNote38/tn38.pdf?__blob=publicationFile&v=4


Eric

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

Re: [OSM-talk-fr] Systèmes géodésiques et OSM

[Eric SIBERT via Talk-fr]

Je suppose qu'Eric veut dire que les "anciennes" données étaient de 
facto mettons en GDA94 et qu'elles doivent être reprojetées en GDA2020.


Non, tel n'est point mon propos. Du passé, faisons table rase ;-). Je me 
pose la question du présent et du futur. Quelle solution globale peut-on 
proposer pour tenir compte de la dérive des plaques pour les futures 
contributions?


Si je comprends bien, la réalisation d'un système géodésique consiste à 
fournir, pour une date donnée, les coordonnées d'un certain nombre de 
stations de référence (et aussi leur vitesse de dérive).


On a par exemple l'ITRF (International Terrestrial Reference System) 
avec des réalisations en 92 (à l'epoch astronomique 1992,0), 93, 94, 96, 
2000, 2005, 2008, 2014 et bientôt 2020 (pour une publication fin 2021).


WGS84 a aussi des réalisations successives qui sont des reprises en 
retard des réalisations ITRF ces derniers temps.


Mon idée, dans le cadre d'OSM, c'est de continuer à contribuer en WGS84, 
dans la dernière réalisation figé à sa date de réalisation (ou en ITRF 
si on trouve que WGS84 est trop en retard sur ses réalisations). 
C'est-à-dire qu'on contribue dans un système local initialement 
coïncidant avec WGS84. À chaque nouvelle réalisation, il faut une 
conversion de toute la base OSM de l'ancienne réalisation à la nouvelle 
réalisation.


Variante, comme la dérive des points de référence est aussi fournie avec 
la réalisation, tous les jours à minuit, on corrige les coordonnées dans 
OSM pour tenir compte de la dérive :-). Il y aura sans doute aussi des 
corrections résiduelles à appliquer lors des changements de réalisation 
pour tenir compte des plaques qui ont pris des virages.


Solution intermédiaire, on fait une correction de dérive une fois par an 
ainsi qu'une correction résiduelle aux changements de réalisation.


Dans tous les cas, ce sont aux fournisseurs de données en amont et aux 
utilisateurs en aval à s'adapter pour bien passer de leur système local 
au système global. Sachant que les fournisseurs/utilisateurs ne sont pas 
nécessairement les utilisateurs finaux mais les concepteurs de logiciels 
et autres plugins.


On pourrait imaginer, pour RGF93, d'avoir un service centralisé qui 
fournit une grille en latitude/longitude avec les paramètres locaux de 
conversion RGF93<->WGS84(dernière réalisation avec dérive ou pas suivant 
l'option choisie ci-dessus) à chaque point de la grille.


Eric

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

Re: [OSM-talk-fr] Systèmes géodésiques et OSM

[Eric SIBERT via Talk-fr]

D'abord, remarque préliminaire sur ceux qui disent que ce n'est pas 
grave car nos récepteurs n'ont pas une précision suffisante, je réponds 
qu'on ne taggue pas pour le rendu ;-). Puis nos récepteurs commencent à 
avoir une précision pas mal non plus. À Madagascar, j'ai mesuré 
plusieurs jours de suite le même point bien dégagé avec mon Etrex 30 
(GPS+Glonass). L'écart-type est de 1,60 m. Sachant qu'en plus, en 
Europe, on a les corrections temps réel EGNOSS, je pense que le métrique 
est à portée de main. D'ailleurs, je suis en train de faire des mesures 
répétées sur mon trajet domicile-travail  pour voir ce qu'il en est.


Pour le fond du problème, mon avis est que OSM est un projet mondial et 
qu'il faut rester avec une référence globale, à savoir WGS84 mais en 
précisant bien que c'est dans sa réalisation actuelle. Les données dans 
des références locales doivent alors être converties en 
WGS84(réalisation actuelle). Quand il y a un changement de réalisation 
de WGS84, il faut convertir les coordonnées dans la base OSM de 
l'ancienne à la nouvelle réalisation de WGS84 (ou au moins le faire dans 
les zones où la dérive des plaques est plus grande que l'incertitude sur 
les données sources du coin).


Eric


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

Re: [OSM-talk-fr] Critères pour cartographier les sommets (natural=peak)

[Eric SIBERT via Talk-fr]

Le 18/08/2019 à 16:22, Olivier a écrit :

Je suis actuellement en Provence dans une zone où apparaissent de nombreux 
sommets, avec pour seule étiquette natural=peak. L'altitude et le nom ne sont 
pas renseignés.
 
J'aimerais donc savoir s'il est correct de cartographier en grand nombre des sommets sans connaître leur altitude, leur nom ou tout autre caractéristique, juste car cela apparaît comme une bosse dans une carte de relief contenant les courbes de niveaux.


Déjà que des fois, je m'interroge sur le fait de mettre les différentes 
antécimes d'un sommet. Là je ne vois pas trop le sens si c'est 
effectivement déduit de lignes de niveau. La précision horizontale est 
loin d'être garantie. Celui qui voudrait toutes les bosses aurait plus 
intérêt à refaire lui-même une extraction depuis un MNT que de prendre 
ce qui est dans OSM.


Mes 0,02 €.

Eric

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

Re: [OSM-talk-fr] Cadastre : exporter une zone

[Eric SIBERT via Talk-fr]

Le 27/07/2019 à 21:08, Jérôme Amagat a écrit :
ou avec le plugin cadastre dans JOSM lorsque l'on veux télécharger une 
zone, il y a un nouvel onglet "télécharger depuis le cadastre". 


Sauf que ça télécharge tous les bâtiments de la planche, pas juste ceux 
de la zone sélectionnée.


(je passe par le site non sécurisé http://cadastre.openstreetmap.fr/ 
comme proposé dans un autre message).


Eric

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

Re: [OSM-talk-fr] Mobilier urbain anti-SDF

[Eric SIBERT via Talk-fr]

Il y a aussi les équipements anti-djeuns... avec des petites 
protubérances ajoutées sur les arrêtes des bancs ou sur les rambardes 
pour éviter que les jeunes (ou pas) ne viennent faire des figures de 
style en roller dessus.


Eric

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