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

[Stéphane Péneau]

Bonjour Adrian,

Pour discuter de CentipedeRTK, les 2 canaux sont :
 - Le forum : https://forum.geocommuns.fr/c/rtk-centipede/
 - Le groupe telegram : https://t.me/Centipede_RTK

J'ai vérifié vite fait les bases ASAGI et CETTE. Je n'ai pas constaté de 
problème.


Stéphane

Le 10/09/2023 à 23:21, Adrian via Talk-fr a écrit :

J'ai trouvé un problème avec le serveur Centipede. J'ai essayé quatre bases. 
Deux - AGDE et SETE - avec récepteur Trimble, marchent. Deux - ASAGI et CETTE - 
avec récepteur ublox F9P, ne marchent pas. Toutes sont marquées actives sur la 
carte Centipede. Mais les deux qui ne marchent pas sont absentes de la liste du 
caster (caster table).

J'ai essayé de saisir ASAGI et CETTE avec deux clients différents. Avec 
Bluetooth GNSS (Android) le flux démarre et s'arrête toutes les quelques 
secondes et on obtient peu de paquets. Avec RTKLIB STRSVR il y a une erreur no 
mountp.

Comment puis-je signaler ce problème?

___
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

[Stéphane Péneau]

Le 08/11/2022 à 19:10, Eric SIBERT a écrit :



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

.


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.




Osmand affiche déjà les voies à suivre, et je pense que ce n'est pas le 
seul.


Stf


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

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

[Stéphane Péneau]

Le 06/11/2022 à 14:31, osm.sanspourr...@spamgourmet.com a écrit :

J'allais dire "Hélas les turn:lanes sont inapplicables en l'état car il
n'y a pas de signalisation horizontale dans ce cas précis."

En fait la version anglaise insiste sur le fait que ce soit signalé mais
in fine n'indique pas que le marquage au sol.

https://www.mapillary.com/app/?z=17=48.701982=2.595105=172038741799101=photo 

 



montre bien que

turn:lanes=none|none|slight_right

est correct.


Oui, et j'avais totalement oublié d'ajouter ce turn:lanes




J'ai aussi placé la sortie 21 au niveau du bout du pont. C'est
discutable, j'ai suivi la recommandation de "dernier moment pour changer
de file en sécurité" et pour éviter le point d'inflexion sur le tracé
filaire. Oui le second point est un peu pour le rendu mais n'est pas
tordre la réalité non plus.


Là je suis moins d'accord, on peut changer de voie pendant encore 
presque 30 mètres après la position que tu as choisie. L'argument du 
"dernier moment pour changer de file en sécurité" me parait un peu 
curieux, car totalement dépendant de la vitesse, et très subjectif.


Stf

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

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

[Stéphane Péneau]

Le 03/11/2022 à 20:42, osm.sanspourr...@spamgourmet.com a écrit :

Stéphane, pour la voie que tu as mise à jour ce serait plutôt :

lanes=2

turn:lanes=through|through;slight_right



Bah non, il y a bien une troisième voie. Elle s'ouvre progressivement, 
mais elle est bien là.



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

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

[Stéphane Péneau]

Je viens de faire 2-3 modifs, mais globalement c'était déjà pas mal, et 
le tag maxspeed:lanes est tout à fait adapté dans cette situation


Ou alors je n'ai pas compris ce que tu essaies de faire.

Stf

Le 03/11/2022 à 19:09, didier a écrit :

Bonsoir,

Ce que je recherche, ce n'est pas la vitesse de la voie de droite.
Cf www.mapillary.com/app/?pKey=172038741799101

Dans ce cas, 110 tout droit et 90 pour ceux qui vont emprunter la
sortie.

sinon je peux taguer uniquement le panneau, mais la non plus je ne sais
pas taguer un panneau avec un pannonceau en dessous...


___
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] vitesse limitée a 70 pour les véhicules qui vont utiliser une bretelle de sortie

[Stéphane Péneau]

Salut,


Le 02/11/2022 à 08:31, didier a écrit :

Bonjour,
lors du Sotm de Nantes on m'a dit que l'on pouvait décrire la vitesse
limitée (a 70km/h) pour les véhicules qui vont utiliser une bretelle de
sortie (la section courante étant a +20km/h soit 90km/h).


C'est avec les maxspeed:lanes=

Un exemple ici : https://www.osm.org/way/765373464

un autre exemple avec d'autres machin:lanes : 
https://www.osm.org/way/20359780


Stf


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

Re: [OSM-talk-fr] Population des viles

[Stéphane Péneau]

Salut,

La population de la commune n'est pas la même chose que la population du 
"bourg" ou "centre".
Les populations légales sont celles des communes, d'où leur présence sur 
les relations.


Normalement, et je dis bien "normalement", la population sur le node 
"place" ne devrait indiquer que la population de cette entitée, si on la 
connait, ce qui est rarement le cas.


Stf

Le 06/10/2022 à 15:38, Arnaud Champollion a écrit :

Bonjour,

On trouve la clé "population" à la fois dans les place_town (noeuds 
"centraux") et dans les boundary_administrative (contours de commune).


Parfois la clé est absente de l'un des deux, comme ici :

https://www.openstreetmap.org/node/26691545
https://www.openstreetmap.org/relation/365373

Je m'en suis rendu compte en éditant une carte de mon département ; le 
filtre par population lnagissait pas pareil selon que je l’appliquais 
sur le point central ou la surface communale.


Est-ce que ça vaudrait le coup de répliquer massivement cette donnée 
de l'un à l'autre, tout au moins pour les cas où elle est absente dans 
l'un des deux ?


Merci de vos avis,

Bonne journée,

Arnaud


___
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] dalles Lidar IGN colorisées en cartographie OSM

[Stéphane Péneau]

J'ai vu tes exemples sur Twitter, et c'est magnifique, bravo !
Je vais certainement essayer ton script un de ces jours pour regarder 
comment ça se comporte en cas d'erreur de parallaxe sur les images 
aériennes.


A+

Stf

Le 13/09/2022 à 15:05, Pierre Beyssac a écrit :

Bonjour à tous,

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, et c'est superbe.

Cf https://geoservices.ign.fr/lidarhd

À ce stade, 16717 dalles sont disponibles (ce qui sauf erreur de
ma part correspond à 16717 km²), les plus au nord étant au niveau
du lac Léman.

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.

Comme j'avais envie de voir d'autres régions "en couleurs naturelles",
j'ai écrit un script Python pour les coloriser à volonté "chez soi"
à partir des orthophotographies IGN (ou autre d'ailleurs, le script
est à 99 % prêt pour gérer n'importe quelle zone de la planète).

Je me permets d'en parler ici car cela peut être d'une grande aide
en contribution OSM, notamment pour qualifier les ponts, passerelles,
auvents (quais de gare au hasard), souterrains, et autres éléments
pas faciles à identifier sur l'orthophotographie 2D classique.

On peut configurer le script avec des dalles au protocole TMS d'OSM,
donc utiliser les mêmes sources que celles configurables dans JOSM,
Id etc, et avec la même syntaxe que sous JOSM.

C'est ici :
https://github.com/pbeyssac/lidarpaint

Attention, il est recommandé d'avoir un peu l'habitude d'installer
des programmes Python et idéalement des logiciels libres associés
à la cartographie (PDAL, GDAL, displaz). De plus, à ce stade c'est
testé sous Unix/Linux mais pas sous Windows.




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

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

[Stéphane Péneau]

Bonjour Hélène,

A tout hasard, si ce qui t'intéresse c'est de pouvoir recréer une trace 
gpx depuis la position des photos, c'est possible nativement dans Josm 
depuis 1 an.
Il suffit de faire un clic droit sur le calque photo, et de faire 
"export to gpx"


Stf

Le 13/09/2022 à 18:39, Hélène PETIT a écrit :

Bonjour !

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.


Merci m'siers-dames !

___
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] Bonnes pratiques pour la délimitation des landuse et autres natural ?

[Stéphane Péneau]

Salut,

Lorsque je rencontre des landuses collés à des routes, je hurle 
intérieurement pour au moins 2 raisons :
- La mauvaise : C'est un enfer lorsqu'on a besoin de faire des éditions 
sur la route, ajouter un giratoire, des séparateurs,etc..
- La correcte : Surfacique contre filaire, ce sont 2 notions 
différentes. En poussant les landuses jusqu'au centre de la route, la 
surface du landuse devient fausse.


Je pourrais en lister plein d'autres, comme le fait qu'ajouter une piste 
cyclable (donc séparée de la route) fait qu'elle se retrouve intégrée 
dans un landuse qui n'a rien à voir si on ne commence pas par le 
décoller de la route...et là on revient à ma mauvaise raison :-)


Donc, s'il te plait, non, ne colle pas les landuses à du filaire.

Stf


Le 11/07/2022 à 15:31, pepilepi...@ovh.fr a écrit :

Bonjour,

Quand, comme ça arrive très souvent (ici
, par exemple),
on a une route avec d'un côté un champ cultivé et de l'autre une forêt,
il est tentant de réutiliser les segments de la route dans la définition
des landuse. C'est ce que je fais d'habitude, un peu par flemme et
beaucoup pour ne pas surcharger inutilement la base de données (oui, je
sais, quand on a dix milliards de noeuds on n'en est pas à dix ou cent
mille près, mais j'aime pas ça).

Dans certaines zones (ici
, par exemple)
on voit aussi la route, une limite séparée pour le bois, et une autre
limite de l'autre côté pour la zone résidentielle.

Certes c'est vrai (en France du moins) qu'en toute rigueur il y a
toujours une petite bande, un talus ou un fossé, entre la route et le
champ cultivé. Mais est-ce vraiment la peine de la mentionner ?

Laquelle de ces deux pratiques doit-elle être préférée ?

Bonne journée,

Jean-Pierre





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

Re: [OSM-talk-fr] géolocalisation des photos

[Stéphane Péneau]

Le 24/06/2022 à 08:55, Sébastien Dinot a écrit :


Ça, c'est intéressant si on arrive à indiquer soi-même la direction, 
parce que si JOSM s'appuie sur un calcul (direction de la tangente à 
la trajectoire), ce n'est pas pertinent pour quelqu'un qui se balade à 
pied et s'arrête pour photographier quelque chose qui peut se trouver 
n'importe où autour de lui.


C'est possible aussi. Il te faut le plugin photoadjust. Il permet de 
déplacer les photos, et de modifier l'orientation de manière individuelle.





C'est dommage. Mais cela peut se faire en deux temps, comme je le fais 
déjà : 1. Recalage temporel via exiftool, 2. Géolocalisation dans JOSM.



(l'offset de temps est généralement suffisant).


Dans l'exemple réel que j'ai donné, le décalage était supérieur à la 
minute et il m'est déjà arrivé de constater un quart d'heure de 
décalage. Nous sommes bien au delà de la milliseconde.


Si tu souhaites que tes photos comportent définitivement l'heure exacte, 
je comprends ta manip. Si c'est juste pour pouvoir les géolocaliser 
alors ajouter un offset à la correlation dans Josm est suffisant. (en 
heures/minutes/secondes/millisecondes)


Lorsque je géolocalise avec une trace externe des photos prises avec mon 
smartphone, je m'en fiche un peu que l'heure de prise de vue soit 
décalée de quelques minutes. S'il y a plusieurs heures d'écart, alors là 
oui, je peux éventuellement corriger directement dans les exif au préalable.





Quant à mon GPS, j'était à peu près certain de l'avoir vérifié, mais 
je l'ai refait ce matin, c'est bien l'heure locale qu'il affiche, à 
moins que ma montre et mon smartphone n'affichent l'heure GPS. ;)


Une bonne excuse pour ne pas être à l'heure ?  ;-)


Stf


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

Re: [OSM-talk-fr] géolocalisation des photos

[Stéphane Péneau]

Salut,

Josm peut tout à fait injecter les coordonnées dans les photos. Il faut 
que le plugin photo_geotagging soit installé.

C'est aussi un des seuls logiciels à savoir faire
- une corrélation avec un offset temporel comprenant des millisecondes
- un offset x/y/z par rapport à la trace Gpx,
- à ajouter la direction de la photo, avec ou sans offset.
etc...
Et le tout en graphique avec une vérification sur fond BdOrtho.

J'en parle sur la fin de ma présentation du Sotm-FR 2022 :
https://peertube.openstreetmap.fr/w/76f6fce6-e7b5-43a3-8da4-564b2d5b1d31

Par contre, oui, il ne peut pas modifier l'horodatage des photos 
(l'offset de temps est généralement suffisant). Au passage, il faut se 
méfier du temps indiqué par un récepteur Gnss, il y a en 3 possibles : 
Heure locale, UTC et GPS. L'heure GPS a un décalage de plusieurs 
secondes avec l'heure UTC (18 en ce moment) :

https://en.wikipedia.org/wiki/Leap_second

A+

Stf

Le 22/06/2022 à 18:16, Sébastien Dinot a écrit :

Stéphane Péneau a écrit :

Je viens de regarder ton article, et puisque les photos sont vérifiées
dans Josm, pourquoi ne pas faire la géoloc directement dans Josm ?

Pour deux raisons :

* Mon souhait de géolocalisationn ne se limite ni à OSM, ni à la
   cartographie, il m'arrive de géolocaliser d'autres photographies.

* À ma connaissance, JOSM n'injecte pas les coordonnées GPS dans les
   méta-données de la photographie, pas plus qu'il ne rectifie dans le
   fichier l'horodatage de la photographie, alors que c'est ce que je
   souhaite.

A++, Sébastien




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

Re: [OSM-talk-fr] géolocalisation des photos

[Stéphane Péneau]

Bonjour Sébastien,

Je dévie un peu la discussion :
Je viens de regarder ton article, et puisque les photos sont vérifiées 
dans Josm, pourquoi ne pas faire la géoloc directement dans Josm ?


Stéphane

Le 22/06/2022 à 16:52, Sébastien Dinot a écrit :

Bonjour Hélène,

Le problème peut être imputable au service de transmission, qui purge
les métadonnées à la volée. Mais il peut aussi être imputable à l'outil
de gestion des photographies. Certains outils injectent les métadonnées
dans les fichiers eux-mêmes, d'autres les stockent dans une base
externe, d'autres enfin proposent les deux stratégies (c'est alors une
affaire de configuration de l'outil). Tu t'en doutes, lorsque les
méta-données sont injectées dans le fichier lui-même, elles se propagent
avec lui, mais pas lorsqu'elles sont injectées dans la base de données.
Chaque approche présente des avantages et des inconvénients.

Il se peut donc que certains des outils utilisés par tes amis soient
inappropriés ou mal configurés au regard de vos attentes.

Si tu disposes de la trace GPS, tu peux aussi géolocaliser les
photographies a posteriori, comme je l'explique dans l'article
ci-dessous :

https://www.palabritudes.net/2021/07/20/geolocalisation-photographies.html

Sébastien




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

Re: [OSM-talk-fr] Attribution ?

[Stéphane Péneau]

C'est probablement involontaire. Les liens hypertextes sont en blanc sur 
le reste du site.



Le 26/02/2022 à 14:11, Listes a écrit :

Le 26/02/2022 à 13:34, Jacques Lavignotte a écrit :


J'ai des doutes

https://sfanm.fr/

Fond/données OSM ?

J.

C'est noté en blanc, donc invisible : Données OpenStreetMap et rendu 
OSM France.





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

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

[Stéphane Péneau]

Le 28/12/2020 à 09:55, Jean-Claude Repetto a écrit :


Bonjour,

Si des données de haute précision sont disponibles, va se poser le 
problème du système de référence. OSM utilise le WGS84, l'IGN le 
RGF93, et il y a la dérive des continents.



J'en ai parlé ici il y a quelque temps, et sur un "journal" :

https://www.openstreetmap.org/user/StephaneP/diary/390290

En résumé, en France, lorsqu'on utilise l'imagerie Ign, on est en RGF, 
donc une bonne partie des données Osm du territoire ne sont pas en 
WGS84. La situation est identique dans d'autres pays qui ont une 
imagerie de bonne qualité.


Stf


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

Re: [OSM-talk-fr] un début de OSM - mon commerce

[Stéphane Péneau]

Le 17/12/2020 à 05:12, Francois Gouget a écrit :

On Wed, 16 Dec 2020, Florian LAINEZ wrote:


Bonjour François,
Il existe une bonne raison pour laquelle aucun outil n'existe aujourd'hui
pour mettre à jour les données sur tous ces sites en une seule fois.
Il est possible d'élaborer longuement sur le sujet mais pour faire court :
la licence OdbL a été créée pour protéger le projet OSM des prédateurs qui
pourraient être tentés de piller les données sans reverser en retour.

C'est pour cela que je ne propose pas de prendre les données OSM pour
les mettre sur les autres sites mais de mettre *uniquement* les données
d'horaire etc dans une base de données séparée sous une license plus
permissive et qui servira à alimenter, entre autres, OSM.

*KO* : Commerçants -> OSM -> "Site horaires" -> Google, Pages Jaunes, etc.
*OK* : Commerçants -> "Site horaires"-> OSM, Google, Pages Jaunes, etc.

Donc pas de problème de license.


Autre solution intermédiaire :

Afficher les horaires des différents services (Osm, google, pages 
jaunes, etc...). C'est probable que ça intéresse les commerçants de 
vérifier depuis une seule page que tout est à jour. Et dans un premier 
temps, depuis ce site il ne sera possible que de modifier les horaires Osm.



Stf


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

Re: [OSM-talk-fr] Regrouper les activités d'une ferme

[Stéphane Péneau]

Salut,

Le 01/12/2020 à 13:07, emeric Prouteau a écrit :

Bonjour,

En faisant le tour des shop=farm sur mon département (Dordogne), Je 
suis tombé sur une ferme décrite (Producteur de Laine) par trois noeuds :


  * place = farm --> https://www.openstreetmap.org/node/7916522978




Pourquoi place=farm ? Le hameau semble être nommé "Millac".

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

Re: [OSM-talk-fr] ascenseur

[Stéphane Péneau]

Le 22/11/2020 à 10:32, leni a écrit :

Le 22/11/2020 à 08:37, Stéphane Péneau a écrit :


The starting level is not included in this list, e.g. a feature with 
level="0" then repeat_on starts with "1".


Stf


Merci à tous pour vos réponses, en plus j'avais à tord utilisé layer 
(que j'avais utilisé pour la passerelle) à la place de level


Ceci dit, je me rends compte que dans le schémas, ils n'utilisent pas 
level, mais uniquement repeat_on.


https://wiki.openstreetmap.org/wiki/File:Indoor2.0_buildingpart.svg

Je pense qu'il faudrait en discuter sur la liste tagging, mais je n'ai 
pas le temps de m'occuper de ça pour le moment.


Perso, je suis partisan du level=x + repeat_on

Stf



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

Re: [OSM-talk-fr] ascenseur

[Stéphane Péneau]

Le 21/11/2020 à 21:22, blef a écrit :

Je corrige: pas besoin de level=0, repeat_on=0;1 suffit


Si si, level=* est indispensable :

The starting level is not included in this list, e.g. a feature with 
level="0" then repeat_on starts with "1".


Stf


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

Re: [OSM-talk-fr] ascenseur

[Stéphane Péneau]

Salut,

Le 21/11/2020 à 12:51, leni a écrit :
Si je met les "entrance=yes" + "door=sliding", des deux niveaux, 
superposés, Josm m'indique "nœuds à la même position" bien qu'il y ait 
layer=1 


Pour ce genre de cas, tu peux utiliser le tag repeat_on :

https://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging#Multi-level_features_and_repeated_features


"highway=elevator" c'est un highway qui peut, donc, être utilisé en 
routage piéton, faut-il le relier au chemin piéton qui va du parking 
aux portes des ascenseurs avec un chemin à l'intérieur jusqu'au nœud 
avec "indoor=yes"?



Oui, et il doit aller jusqu'au noeud highway=elevator.

Stf



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

Re: [OSM-talk-fr] [ EXIT Loomio ] Reconnaître des services "officiellement édités par osm-fr" ?

[Stéphane Péneau]

Le 15/10/2020 à 18:31, Vincent Bergeot a écrit :

Bonjour à tous,

Je suis un des administrateurs de loomio.

Je voulais faire du 'ménage' sur les 50 'membres' loomio pour pouvoir 
accepter des 'nouveaux' sans passer à la version 100 personnes. Je 
n'en ai pas eu le temps.


Je continue de trouver que loomio (code libre et service payant pour 
ne pas avoir à gérer un service nous même) est un choix pertinent qui 
a permis de décider.


On ne peut pas utiliser l'instance de Framasoft (framavox) ? Ou celle 
éventuellement payante d'un CHATON ?


Stf


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

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

[Stéphane Péneau]

Le 08/10/2020 à 22:15, Stéphane Péneau a écrit :


Pour les aires, en effet je dirais que c'est à la fois le nom de la 
sortie et de la destination. Dans les données, l'usage est par contre 
bien tranché :


- 500 nœuds highway=motorway_junction + name=Aire...
- 13 nœuds highway=motorway_junction +destination=Aire...
- 3 nœuds highway=motorway_junction + name=Aire... +destination=Aire...

Si tu ne regardes que les noeuds, c'est normal que tu n'en trouves pas 
beaucoup avec des tags destination :-)


Je trouve plus de 800 ways avec destination=Aire* Ce n'est donc pas si 
simple.


http://overpass-turbo.eu/s/YR3

J'ai modifié le wiki pour ajouter l'utilisation du tag destination sur 
le way de la bretelle, car il est indispensable pour que les logiciels 
de navigation indiquent la voie à utiliser.



Stf


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

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

[Stéphane Péneau]

Le 08/10/2020 à 15:45, PanierAvide a écrit :

Bonjour Stéphane,

Merci pour les améliorations de la page ;-)

Pour les aires, en effet je dirais que c'est à la fois le nom de la 
sortie et de la destination. Dans les données, l'usage est par contre 
bien tranché :


- 500 nœuds highway=motorway_junction + name=Aire...
- 13 nœuds highway=motorway_junction +destination=Aire...
- 3 nœuds highway=motorway_junction + name=Aire... +destination=Aire...

Si tu ne regardes que les noeuds, c'est normal que tu n'en trouves pas 
beaucoup avec des tags destination :-)


Je trouve plus de 800 ways avec destination=Aire* Ce n'est donc pas si 
simple.


http://overpass-turbo.eu/s/YR3

Je n'ai pas la requête pour comparer les cas où il y a le tag 
motorway_junction ou pas sur le node qui connecte la bretelle d'accès à 
l'aire de service/repos.


Stf


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

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

[Stéphane Péneau]

Salut,

J'ai fait quelques corrections sur les exemples du wiki, principalement 
l'ajout de l'espace entre la lettre et le numéro pour les ref (A 83 et 
non A83), ainsi que l'ajout de destination:int_ref lorsqu'on a du E XXX.


Je suis un peu gêné pour l'exemple de la sortie vers l'aire de repos 
(dernier exemple)


De mon point de vue, "Aire du Granier" est la destination, pas le nom de 
la sortie, ou alors ce sont les 2. Ensuite, je ne mets généralement pas 
de tag highway=motorway_junction, car il n'y a pas réellement de 
jonction avec d'autres destinations.


Qu'est-ce que vous en pensez ?

https://wiki.openstreetmap.org/wiki/FR:Tag:highway%3Dmotorway_junction#Exemples

Stf


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

Re: [OSM-talk-fr] bâtiment sans numéro de rue

[Stéphane Péneau]

Le 08/09/2020 à 23:20, Philippe Verdy a écrit :
Note le numéro 1 sur le cadastre est semble-t-il le numéro de 
parcelle. Le 1 est un peu plus au sud (avant les marais, mais c'est le 
seul numéro impair. Il n'y a pas de 2 ni de 3 indiqués, de fait la 
mairie purrait bien être au 3 (à l'entrée de la rue) si le 2 est pour 
l'école juste à côté.


Il y a bien un numéro 3, un peu plus au sud, c'est même toi qui l'a 
ajouté :-)


Stf

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

Re: [OSM-talk-fr] comment taguer le stockage des déchets verts et agricoles?

[Stéphane Péneau]

Le 31/08/2020 à 14:48, JB a écrit :
Je ne sais pas si c'est moi, JB.  Si vous insistez, je ne crois pas 
que je ferai mieux que Stéphane :
Ensilage : sous bâche lisse noire avec dessus boudins lourds ou pneus 
(il me semble que ce serait interdit maintenant, mais on en voit bien 
sur l'exemple de Stéphane). 


Je crois que c'est progressif, les pneus sont récupérés petit à petit. 
Sur l'ortho, on voit qu'il y a un mélange pneu et boudins. On aperçoit 
quelques boudins sur les côtés du silo sur cette photo :


https://www.mapillary.com/app/?lat=47.06118873055211=-1.350107841666756=17=_KOsyTRj3UD2XyyGqtOtTQ=photo=0.3269973996028876=0.5001938939558493=1.4968684759916489


Pour ceux que ça intéresse, une fosse à lisier de près : 
https://www.mapillary.com/app/?lat=47.061056305526705=-1.348506155548639=17=LsEzMTnA9eT4SiEjv_Qb4w=photo=0.32418964286608165=0.5242661698147242=1.121085594989561



Stf


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

Re: [OSM-talk-fr] comment taguer le stockage des déchets verts et agricoles?

[Stéphane Péneau]

Le 31/08/2020 à 15:00, Stéphane Péneau a écrit :

Le 31/08/2020 à 14:42, Yves P. a écrit :
Ce que tu appels du "jus" c'est du lisier 
<https://fr.wikipedia.org/wiki/Lisier> ou du purin 
<https://fr.wikipedia.org/wiki/Purin> ?

La différence entre les deux est subtile pour un non initié.

Hmm, après vérification de la différence, je pense qu'il s'agit plutôt 
de purin. Je demanderai.



Raté, c'est du lisier. Le purin est assez rare.


Je pensais que c'était uniquement ça, mais les balles de foin sous 
plastique c'est aussi de l'ensilage.


JB et/ou Stéphane pourront nous éclairer ?


Je ne sais pas, ça a l'air d'être à mi-chemin entre le foin et 
l'ensilage. je demanderai.


Confirmation, c'est à mi-chemin, mais ça dépend aussi de ce qu'il y a à 
l'intérieur de l'emballage, chose impossible à savoir sans les ouvrir.


Sur les orthophotos, on voit souvent 2 fosses à lisier autour des 
fermes. En général, c'est parce que les normes ont changé et les 
agriculteurs ont dû augmenter leur volume de stockage. Pour ceux qui 
étaient déjà aux normes d'avant... ils ont construit une seconde fosse.


Stf


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

Re: [OSM-talk-fr] comment taguer le stockage des déchets verts et agricoles?

[Stéphane Péneau]

Le 31/08/2020 à 14:42, Yves P. a écrit :
Ce que tu appels du "jus" c'est du lisier 
 ou du purin 
 ?

La différence entre les deux est subtile pour un non initié.

Hmm, après vérification de la différence, je pense qu'il s'agit plutôt 
de purin. Je demanderai.



Je pensais que c'était uniquement ça, mais les balles de foin sous 
plastique c'est aussi de l'ensilage.


JB et/ou Stéphane pourront nous éclairer ?


Je ne sais pas, ça a l'air d'être à mi-chemin entre le foin et 
l'ensilage. je demanderai.


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

Re: [OSM-talk-fr] comment taguer le stockage des déchets verts et agricoles?

[Stéphane Péneau]

Le 31/08/2020 à 13:43, Yves P. a écrit :

https://www.openstreetmap.org/edit?editor=id#map=20/47.75009/-3.49276

C'est une zone de stockage, ici sur la droite on voit des bottes 
(rouleaux) de paille.

… de foin


A gauche soit de la paille compostée soit du fumier.
j'ai l'impression que c'est de l'ensilage 




Je suis du même avis.

Quelques exemples dans une ferme :

http://umap.openstreetmap.fr/fr/map/carte-sans-nom_493975#19/47.06119/-1.34998


Stf


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

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

[Stéphane Péneau]

Hello !

Un point intéressant qui pourrait changer un peu la donne :

Dorénavant, Mapillary ne conserve plus les images non floutées. Je viens 
de vérifier, mes anciennes images sont effectivement déjà floutées 
lorsque je télécharge la version "unprocessed".



Source :

https://blog.mapillary.com/news/2020/08/31/imagery-privacy-blurring.html

Stéphane


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

Re: [OSM-talk-fr] Comment qualifier un Chaussidou

[Stéphane Péneau]

Le 23/07/2020 à 17:42, Nicolas Dumoulin a écrit :

Salut :-)

Je me demande comment qualifier un chaussidou, aussi appelé "Chaussée 
à Voie Centrale Banalisée" (CVCB) décrite ici par exemple : 
https://www.cc37.org/chaussee-a-voie-centrale-banalisee-chaucidou/


Une recherche de "chaussidou" sur taginfo ne me renvoie rien à part 
des mentions en attribut "note". Ça me semblerait intéressant de 
qualifier ce genre d'aménagement pour être plus précis et permettre 
une vue générale de la présence de cet aménagement.


Ça ne semble bien sûr pas opportun d'utiliser un highway=* spécifique 
ni d'omettre les tags "cycleway=*" mais d'ajouter un complément genre 
highway:chaussidou=yes ou bien zone:chaussidou=yes. Pour rappel, ce 
type d'aménagement n'est pas spécifiquement Français, donc pas de "FR:".


Qu'en pensez-vous ?

P.S. : Ça faisait longtemps que je n'étais pas passé sur cette liste, 
j'espère que vous allez bien. En tout cas, je constate qu'OSM continue 
à se faire sa place, quelle réjouissance pour un projet libre. 
Portez-vous bien.



Salut Nicolas !

Tu auras ta réponse ici : 
https://wiki.openstreetmap.org/wiki/FR:Bicycle#Bandes_cyclables


C'est le cas L3


Stf


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

Re: [OSM-talk-fr] Segmentation des maisons

[Stéphane Péneau]

Le 23/07/2020 à 13:24, André Maroneze a écrit :


Je ne vois pas l'intérêt de conserver ces segmentations ; puis-je donc 
les fusionner via JOSM ou un autre outil ?



Perso je ne recommande pas la fusion de ces éléments, on perd des 
informations qui seront intéressantes lorsque quelqu'un voudra faire de 
la 3d.


Cas n°1 : J'ai du temps et du courage :

Je dessine un polygone qui fait le tour complet de la maison, avec pour 
tag building=house

Les anciens polygone deviennent des building:part=yes/house/etc...


Cas n°2 : Je n'ai pas le courage

Je laisse comme c'est


Stf

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

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

[Stéphane Péneau]

Le 22/06/2020 à 22:59, Tyndare a écrit :


Perso je trouve que flouter le visage n'est pas suffisant pour le 
respect de la vie privée, Facebook se vente d'être capable de 
reconnaître les gens à leur démarche, même de dos.


J'ai testé le modèle préentrainé suivant pour flouter les personnes en 
entier des images que j'envoie sur Mapillary et je trouve que ça 
marche assez bien même si ce n'est pas parfait:


https://averdones.github.io/real-time-semantic-image-segmentation-with-deeplab-in-tensorflow/ 




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




C'est pas mal du tout !

Sinon, j'avais oublié que Mappy avait leur streetview aussi. Je ne sais 
pas si c'est maintenu, si ça évolue, s'il y a du libre derrière, etc..


https://fr.mappy.com/#/20/M1/THome/N300.4,-7.8,2.35452,48.85255/Z12/

Stf


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

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

[Stéphane Péneau]

Le 22/06/2020 à 10:53, Marc M. a écrit :

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



Il faudrait vérifier, mais à partir du moment où n'importe qui peut 
devenir contributeur, je doute qu'on puisse considérer ça comme "privé".


Geofabrik a fait ces modifications pour le RGPD, mais pour les photos, 
il faut ajouter les restrictions du droit à l'image.


Pour ceux qui veulent creuser :

https://www.youtube.com/watch?v=-PP_aexji_s
https://blog.droit-et-photographie.com/

Stf



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

[OSM-talk-fr] Alternatives à Mapillary

[Stéphane Péneau]

Salut,


Recensons les alternatives complètes ou partielles à Mapillary, les 
briques réutilisables, etc...


Pour ceux qui sont motivés, on peut tenter de détailler les briques 
disponibles dans chaque cas.


https://opentrailview.org

https://github.com/openstreetcam/

https://github.com/mapillary/

https://openpathview.fr/

Dans tous ces cas, il manque au moins le floutage, le nerf de la guerre.


Vous en voyez d'autres ?


Stéphane


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

Re: [OSM-talk-fr] Data OSM

[Stéphane Péneau]

Le 20/06/2020 à 14:56, PanierAvide a écrit :


Ça fait doublon avec les échanges sur le Loomio 
https://www.loomio.org/d/awNJn3j1/comment/2278570?utm_campaign=discussion_mailer_medium=email_source=new_comment


Mais ce qui a été dit c'est que "data" on s'attend à voir des données 
brutes en mode téléchargement automatique. J'aime bien "carte" / 
"portail" qui est plus révélateur du service.




C'est une sorte de catalogue de données. Donc pourquoi pas 
catalogue.openstreetmap.fr ?


Stf


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

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

[Stéphane Péneau]

Le 19/06/2020 à 16:23, Marc M. a écrit :


- des personnes pour établir les besoins/buts. ex faut-il faire
les 3 par défaut ? à l'époque c'était évidement, ajd p'tre que
l'utilisateur voudrait configurer le partage qu'à une partie des 3)


Aujourd'hui, je ne suis même pas sûr que ce genre de service aurait 
encore beaucoup de sens.


Mapillary appartient à Facebook

OpenStreetCam est au ralenti, voire dysfonctionnel selon certains[1], et 
est tout aussi susceptible d'être racheté que Mapillary (bien que 
largement moins intéressant).


Si on souhaite se défaire de ce genre de problème, il faut une solution 
complète qui ne soit pas rattachée à une entreprise.


Il y a bien l'auteur de https://opentrailview.org qui est prêt à ouvrir 
un peu plus les vannes[2], mais il manque toute la partie floutage, qui 
est indispensable.


1) https://lists.openstreetmap.org/pipermail/talk/2020-June/084993.html

2)https://lists.openstreetmap.org/pipermail/talk/2020-June/084994.html


Stf

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

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

[Stéphane Péneau]

Bonjour Laurence,

Le 19/06/2020 à 12:25, Laurence P a écrit :

Stocker toutes ces photos c'est pas écolo


Juste une petite remarque à ce sujet. La consommation des datacenters 
n'augmente pas comme on le pense.


source :

https://twitter.com/pbeyssac/status/1271095739402379266

https://www.iea.org/reports/data-centres-and-data-transmission-networks


Stf

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

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

[Stéphane Péneau]

Le 19/06/2020 à 09:31, PanierAvide a écrit :


Si on est sur un modèle décentralisée / distribué, le coût du stockage 
/ maintenance est réparti, ce qui en fait une solution probablement 
plus viable et surtout qui ne dépend plus d'une unique entité. Même si 
Mapillary reste bienveillant à la vue de leur communication, on est 
quand même dans un écosystème où ces solutions sont entièrement sous 
la responsabilité des GAFAM : pas génial, on est quand même mieux dans 
un monde où on a des alternatives.


Quand on voit des outils comme Peertube, ou les plus vieux systèmes de 
partage de fichier BitTorrent, je me dis qu'il y a sûrement une carte 
à jouer sur les photos de rue géolocalisées... Une instance de 
stockage par chapitre local OSM + instances d'entreprises qui font du 
relevé photo, qui communiquent entre elles et avec un beau portail web 
et des flux WFS... Ça fait rêver :-) Je crois que certains dans l'asso 
avaient commencé à réfléchir au sujet.


Est-ce que tu connais des algos vraiment performants pour le floutage 
des visages/plaques d'immatriculation, etc.. ? C'est un point très très 
important.


Stf


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

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

[Stéphane Péneau]

Il y a plusieurs points.

Ce qui change aujourd'hui :
A part l'utilisation gratuite pour l'usage commercial, pas grand-chose.
Je vois ça comme un pied dans la porte. Google a fait la même chose avec 
Google Maps.
Et rien ne dit que ça ne redeviendra pas payant d'ici quelques 
annéescomme Google Maps.


Ça ne concerne pas vraiment les contributeurs à Osm/Mapillary.
On peut parier que tout restera très propre vis à vis des contributeurs 
pendant un certain temps, pour ne pas les faire fuir. Mais qu'en 
sera-t-il dans 1 an ? 5 ans ? Il va falloir rester très vigilant.


Changement d'image :
De mon point de vue, contribuer pour Mapillary/OpenStreeMap, ou 
contribuer pour Facebook/OpenStreetMap, ce n'est pas vraiment la même 
chose. Rien que de mettre côte à côte Facebook et Osm...b ça me dérange.


Je repense à des moments ou équipé du #V4MPack 
<https://twitter.com/hashtag/V4MPack?src=hashtag_click>, j'ai été 
interpelé par des passants. Leur répondre que ce n'était pas pour Google 
les rassurait ou leur faisait plaisir. Mais si maintenant je dois dire 
que ça arrivera chez Facebookje ne crois pas que ça va toujours 
plaire...au contraire.
Pour modérer, j'ai aussi eu pas mal de "C'est google ?" avec de larges 
sourires.


Pourquoi ce rachat ?
Et surtout, pourquoi Mapillary a accepté ?
Est-ce qu'ils arrivaient à être rentable ? Pas sûr...

Stf


Le 19/06/2020 à 08:31, Cédric Frayssinet a écrit :


Le 19/06/2020 à 08:27, Stéphane Péneau a écrit :

https://blog.mapillary.com/news/2020/06/18/Mapillary-joins-Facebook.html

Stf


Suis content d'avoir toujours contribué sur OpenStreetCam (Mapillary 
ne fonctionnant pas sans les Google Play Services sur mon smartphone).


Cédric


___
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] Facebook achète Mapillary !

[Stéphane Péneau]

https://blog.mapillary.com/news/2020/06/18/Mapillary-joins-Facebook.html

Stf


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

Re: [OSM-talk-fr] open-orthos: 3 départements de plus: 27, 53, 76...

[Stéphane Péneau]

Le 18/06/2020 à 10:48, Christian Quest a écrit :
Je pense qu'on est en dessous d'1m, mais je ne trouve pas l'info et 
comme le site "pro" de l'IGN est indisponible depuis décembre, 
difficile de mieux répondre.


De mémoire c'était 80cm maximum, et la valeur moyenne était bien plus 
bassemais c'est vraiment de mémoire.





Le 18/06/2020 à 10:14, Denis Bigorgne a écrit :

Merci, mais plus précisément : 1m, 3m, 5m ?
Ce sont des précisions qu'on peut atteindre avec les GPS actuels, et 
on est un peu dans l'incertitude quand on veut porter un POI dans la 
nature et qu'il y a contradiction entre le GPS et l'orthophoto ( à 
droite ou à gauche du sentier ? Qu'est ce que je rectifie : le POI ou 
le sentier ? )


En France, avec la BDOrtho, tu peux considérer que cette dernière est 
bien plus précise que ton récepteur GPS.


Stf



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

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

[Stéphane Péneau]

Le 16/06/2020 à 23:28, Sébastien Dinot a écrit :

Stéphane Péneau a écrit :

http://www.stemani.fr/public/gnss/Fabrication_base_GNSS.pdf

Je viens de parcourir cette présentation et j'en conclus que j'aurais
adoré assister à ta conférence. A-t-elle été enregistrée ? Le cas
échéant, l'enregistrement est-il disponible en ligne ?

Sébastien


Malheureusement non, elle n'a pas été enregistrée.

Stf


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

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

[Stéphane Péneau]

Le 10/06/2020 à 11:12, Yves P. a écrit :
Je ne sais pas ce qu'on pourrait demander au téléphone : on sait que 
ces salles existent et on sait qu'elles ne sont pas référencées par 
le CNC.


De mémoire quand j'avais travaillé sur le logiciel de billetterie, une 
salle ne peut rien projeter si elle n'a pas d'autorisation du CNC.

C'est très contrôlé !!



C'est peut-être tout simplement parce que ces salles ne diffusent pas de 
films provenant du circuit commercial classique, mais leurs propres 
productions (par exemple). Elle n'aurait donc pas besoin d'autorisation 
pour ça.



Stf


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

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

[Stéphane Péneau]

Le 16/06/2020 à 19:39, Jacques Lavignotte a écrit :



Le 16/06/2020 à 17:22, Sébastien Dinot a écrit :


Le positionnement à 3 mètres n'est pas suffisant pour tout un tas
d'applications, notamment en lien avec la robotique et la conduite
autonome sur route ou même dans les airs ou sur l'eau.


Le rapport avec OSM ?

Il y a un nouvel aménagement près de chez toi. Pour l'intégrer sur Osm, 
on te propose une trace précise à +/- 3 mètres, ou une autre à +/- 5 cm.


Quelle trace choisiras-tu, et pourquoi ?

Stf


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

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

[Stéphane Péneau]

Le 16/06/2020 à 16:58, Marc M. a écrit :

Bonjour,

Le 16.06.20 à 16:20, Stéphane Péneau a écrit :

S'il y a des obstacles sous les 10 - 15 °, ce n'est pas grave.
Au-dessus par contre c'est problématique.

cette exigence disqualifie les endroits auquels je pensais

Ah dommage...

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


Il y a tout un tas de conséquences possibles :

1- On perd entièrement un ou plusieurs satellites.

2- Le signal du satellite qui est derrière l'obstacle pourra être 
atténué, perturbé.


3- Les signaux des satellites qui sont un peu plus haut peuvent rebondir 
sur l'obstacle


Le cas n°1 n'est pas problématique, car ça ne va pas perturber les 
calculs. Il y a peu, ne pas avoir assez de satellites était assez 
courant, j'ai galéré souvent à cause de ça, allant jusqu'à vérifier 
quelle plage horaire était idéale. Maintenant qu'on a plusieurs 
constellations, et que les récepteurs récents les gèrent, c'est plus 
rare d'être gêné par ça.


Les cas n°2 et 3 sont bien plus gênants, car le résultat peut être une 
perte de précision, voir une impossibilité d'obtenir un "fix".


Il ne faut pas oublier que le signal qu'on reçoit est extrêmement faible.

Un dernier point :

Lorsque tu utilises un récepteur mobile, et qu'il y a des masques, cela 
n'impactera que toi. Si ta base a des masques et que tu la partages, ce 
sont toutes les personnes qui l'utilisent qui en subiront les 
éventuelles conséquences sans même savoir qu'il y a des obstacles.


Stf


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

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

[Stéphane Péneau]

Le 16/06/2020 à 15:49, Sébastien Dinot a écrit :

Stéphane Péneau a écrit :

Est-ce que le schéma que tu peux voir à la page 3 de ce pdf t'éclaire ?

http://www.stemani.fr/public/gnss/Fabrication_base_GNSS.pdf

S'il y a des obstacles sous les 10 - 15 °, ce n'est pas grave.
Au-dessus par contre c'est problématique.

Oui, mais du coup, c'est « au dessus de » et non « sous » comme c'est
indiqué sur le site. Et là, ça me semble plus clair. :)
Exact, je n'avais même pas fait attention au contresens. J'ai prévenu 
Julien, la phrase sera corrigée très rapidement.

Par contre, cette exigence disqualifie les endroits auquels je pensais
pour une éventuelle implantation d'antenne.


Ah dommage...

C'est vrai que trouver un point adapté n'est pas facile.

Stf

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

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

[Stéphane Péneau]

Le 16/06/2020 à 13:26, Sébastien Dinot a écrit :


Je ne suis pas sûr de comprendre car, pour moi, il y a une contradiction
entre « l’antenne de réception ne nécessite pas une position dominante »
et « il est indispensable de ne pas avoir d’obstacles sous les 10
premiers degrés par rapport à la base de l’antenne ».

Cela veut-il dire par exemple qu'installer une telle base en bas d'une
vallée, même non encaissée, n'a pas de sens ? Quid d'un bâtiment à flan
de coteaux ?


Est-ce que le schéma que tu peux voir à la page 3 de ce pdf t'éclaire ?

http://www.stemani.fr/public/gnss/Fabrication_base_GNSS.pdf

S'il y a des obstacles sous les 10 - 15 °, ce n'est pas grave. Au-dessus 
par contre c'est problématique.


Stf


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

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

[Stéphane Péneau]

Le 16/06/2020 à 11:33, Sébastien Dinot a écrit :


Il faut ajouter au moins 20 € pour le F9P, annoncé à 220 € et non 200
sur le site pointé.


Non, c'est bien 200€ HT : 
https://store-drotek.com/891-1023-rtk-zed-f9p-gnss.html#/105-case-without


Le sparkfun est à 204€ chez Digikey
Il y en a un 190 (sans usb) chez gnss.store 
(https://www.gnss.store/gnss-gps-modules/105-ublox-zed-f9p-rtk-gnss-receiver-board-with-sma-base-or-rover.html?search_query=f9p=9)



  Et il faut peut-être ajouter quelques dizaines
d'euros pour la Raspberry-Pi en fonction du modèle requis. Celui pointé,
qui coute 43 €, est une R-Pi 3 avec 1 Go de RAM seulement. Est-ce
suffisant pour l'application ?


Ca suffit largement. La carte Orange Pi Zero est bien moins puissante, 
et ça tourne sans problème (cpu load inférieur à 5%). J'ai juste 
quelques soucis avec la version 256Mo de Ram qui est un peu limite si la 
page web est affichée + ssh + etc... Encore qu'avec un peu 
d'optimisation il doit y avoir moyen que ça passe sans avoir des "out of 
memory". Avec la version 512Mo (10€), ça doit passer sans problème (j'en 
attends une d'ici quelques jours)


Stf


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

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

[Stéphane Péneau]

Le 16/06/2020 à 10:05, Yves P. a écrit :

Aujourd'hui c'est la sortie officielle de RTKBase v2.

:)

On peut passer commande auprès du Père Noël ?
Je parle du financement (de tout ou partie) du matériel pour une base 
et un rover pour un groupe local :)


Si la page est à jour, les coûts en matériel sont les suivants :

  * base RTK
 :
410 €
  * mobile RTK

 :
370 €


Stef, tu confirmes ?


Oui, on est dans ces tarifs là. Attention, il faut ajouter la Tva.

On peut baisser un peu le tarif en troquant le Raspberry pi par un 
orange pi zero.
On l'augmente un peu en utilisant du POE, ce qui permet de n'avoir qu'un 
seul câble pour alimenter la base.


Ce sont les solutions que j'ai choisies : 
https://github.com/Stefal/rtkbase/raw/master/images/base_f9p_orange_pi_zero.jpg



Il y a aussi Navspark qui a sorti un récepteur concurrent du F9P, et qui 
est un peu moins cher, mais je ne l'ai pas testé, et il ne se connecte 
pas en Usb. C'est donc un peu plus compliqué à monter pour qui n'a pas 
l'habitude.


Stf

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

[OSM-talk-fr] Sortie de RTKBase V2

[Stéphane Péneau]

Salut tout le monde,

Aujourd'hui c'est la sortie officielle de RTKBase v2.

Qu'est-ce que c'est ?

Un ensemble logiciel pour gérer facilement une station de base Gnns. Ces 
bases sont nécessaires pour faire du positionnement centimétrique en RTK.


Nouveautés :
- Interface Web
- Installation automatique
- Configuration automatique des Ublox F9P connectés en Usb
- Niveaux de réception des satellites
- Carte
- Paramétrage
- Mise à jour depuis l'interface web
- Gestion des fichiers Raw

C'est bien entendu du logiciel libre, et c'est disponible ici :

https://github.com/Stefal/rtkbase


Et il y a même une image préparée prête à être flashée pour #RaspberryPi 
et rejoindre facilement le réseau ouvert #centipede

https://github.com/jancelin/pi-gen/releases
https://jancelin.github.io/docs-centipedeRTK/docs/base/


En attendant que je publie sur mon journal Osm, il y a quelques captures 
et vidéo sur mon compte twitter :


https://twitter.com/stfmani/status/1272751871959224320

Stéphane


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

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

[Stéphane Péneau]

Salut,

Le projet a été abandonné faute de suffisamment de personnes intéressées.

En revanche, je continue à travailler sur ces sujets de mon côté. J'ai 
un logger qui fonctionne avec un arduino-like, mais il mérite des 
améliorations, pour le moment tout est encore sur une plaque de prototypage.


Ce qui a bien avancé, c'est du côté des stations de base, nécessaires 
pour que le rover obtienne une précision centimétrique.

Une nouvelle version sera annoncée la semaine prochaine, j'en reparlerai.

Stéphane

Le 12/06/2020 à 22:32, Jean-Claude Repetto a écrit :

Le 12/06/2020 à 20:06, ades a écrit :

C’était ça merci
L’idée est d’envisager de fabriquer un gnss à partir d’arduino ou de 
raspberry. Je ne suis qu’au début du projet  ;-)




Mais ce n'est pas un projet de récepteur GNSS open source, il était 
question d'utiliser un module du commerce.


Jean-Claude

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




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

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

[Stéphane Péneau]

Le 11/06/2020 à 15:56, Vincent Bergeot a écrit :

Le 11/06/2020 à 15:41, Yves P. a écrit :


cela fait plusieurs fois que je teste discourse et je trouve cela 
assez sympa, avec des fonctions comme un rappel de conversations 
ayant déjà eu lieu, de sujets ouverts, la possibilité de gérer par 
mail ou en ligne, utilisable sur téléphone facilement, ...



Je ne connaissais pas non plus : https://fr.wikipedia.org/wiki/Discourse

Dans la proposition de Stéphane, je comprends messagerie instantanée.


Ah non, par forcément.

Les aspects bloquants des solutions actuelles proposées par osm france 
c'est.


Mailing List : Taille des pj ne permettant pas de joindre des photos, 
puis bon, le mail n'est pas trop fait pour ça.


Forum phpbb : les images affichées dans un message doivent être dispo 
sur un serveur externe.Tout le monde n'en a pas, c'est long, compliqué, 
et au bout de quelques années, la moitié des images a disparue.


On a le même problème sur les journaux des contributeurs osm.


Discourse, oui, c'est pas mal du tout. C'est parait-il un peu gourmand 
en ressources machine.



Stf


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

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

[Stéphane Péneau]

Le 11/06/2020 à 15:23, BEGUIN,Bruno a écrit :


Re-bonjour,

Le bon tag est en prod, il est disponible ici : 
https://www.lebontag.fr/, et là : https://gitlab.com/Geonov/le-bon-tag 



Et c’est un plaisir, ça marche très bien !

J'ai essayé, mais je n'ai pas trouvé comment surveiller un node en 
particulier.


Ce qui m'intéresse, ce n'est pas un type d'objet, mais une liste de 
noeuds/way, etc.. référencés par leur id.



Stf

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

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

[Stéphane Péneau]

Le 10/06/2020 à 18:15, Marc M. a écrit :

Bonjour,

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


1)

Sur twitter, il y a un groupe "Mapillary team fr" ou on discute de 
...Mapillary, de prises de vues, de matos, etc...


L'idée avait été émise d'avoir un canal de discussion plus approprié. Il 
y a un prérequis assez important qui exclut la mailing liste ou le forum 
actuel :


Pouvoir insérer des photos ou captures d'écrans très facilement. Un 
glisser-déposer ou ctrl+v doit suffire.


2)

Sinon, autre cadeau : pouvoir suivre des objets osm en particulier, et 
être alerté (mail, flux rss, autre) en cas de modification.


J'avais commencé à modifier osmada pour ça, mais je manque de temps 
libre. Ça implique aussi l'utilisation d'une instance Overpass qui gère 
les addif, et ce n'est pas le cas de l'instance française.



Stf


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

Re: [OSM-talk-fr] Etang sur arroux

[Stéphane Péneau]

Le 07/06/2020 à 16:45, Yves P. a écrit :

Une requête addif aurait pu faire l'affaire aussi.

Kesako ?


C'est une requête qui permet d'afficher les modifications entre 2 dates :

https://wiki.openstreetmap.org/wiki/Overpass_API/Augmented_Diffs

Stf

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

Re: [OSM-talk-fr] Etang sur arroux

[Stéphane Péneau]

Je l'ai retrouvé avec Whodidit. Une requête addif aurait pu faire 
l'affaire aussi.

Voici le coupable, il a été supprimé il y a une semaine :
https://www.openstreetmap.org/node/7537744869/history

Stf

Le 07/06/2020 à 13:44, Gaël Simon a écrit :

Merci Marc
Mais bizarrement j’ai l’impression que cela fait plus d’une semaine que je l’ai 
vu. Wait and see

Gaël

Le 7 juin 2020 à 12:15, Marc M.  a écrit :

Bonjour,


Le 07.06.20 à 11:55, Gaël Simon a écrit :
une entité du nom de « Etang sur arroux » (sans majuscule à arroux) apparaît 
sur le rendu osm standard

hormis la déchetterie, il n'y a rien dans cette zone avec arroux
https://overpass-turbo.eu/s/UO6
vu que le rendu des premiers niveaux ne se fait qu'une fois
par semaine, je conseille d'attendre une semaine au cas oü
quelqu'un a entre temps corrigé le problème.

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




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

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

[Stéphane Péneau]

Le 01/06/2020 à 10:57, Florimond Berthoux a écrit :

C'est TON interprétation de la loi et j'en ai strictement rien à faire.
Car on ne tag pas la loi, on ne map pas avec le code de la route dans 
la main gauche et la souris dans la main droite.
Sinon il arrive ce qu'il arrive dans cette suite de mail un conflit 
d'interprétation que seul un juge peut régler, et c'est tout à fait 
hors de propos d'OSM.


Le terrain, rien que le terrain, seulement le terrain.


Hmmm, on est tout de même un peu obligé de se référer au code de la route.

Démonstration par l'absurde:

Je vais faire un tour à Paris, je me promène 5mn dans les rues pour 
regarder ce qui circule sur les pistes/bandes cyclables.


Qu'est-ce que je fais lorsque je rentre chez moi ? J'ouvre Josm, et 
ajoute moped=yes + motorcycle=yes sur tous les cycleways...


Tu es ok avec ça ?

Stf


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

Re: [OSM-talk-fr] Point d'apport volontaire, point de collecte, point de regroupement

[Stéphane Péneau]

Le 15/05/2020 à 13:09, Yves P. a écrit :

>Des photos seraient les bienvenues pour différencier les 2 types de 
conteneurs/déchets.


Comme ça ?
https://www.mapillary.com/map/im/r3-7eaUqvjER2K6KQCbIPg

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

https://www.mapillary.com/map/im/lKjOCV-HlhHMnpFHH1tEYQ


Pour les types de "clés" je n'en ai aucune idée. Je n'en possède pas 
moi-même.


Stf


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

Re: [OSM-talk-fr] Point d'apport volontaire, point de collecte, point de regroupement

[Stéphane Péneau]

Le 14/05/2020 à 18:05, Yves P. a écrit :
Je pensais importer des conteneurs : ça tombe bien, il y a pleins de 
PAV dans data.gouv.fr 

Il y a déjà un fichier traité dans Osmose : Clisson Sèvre et Maine 
Agglo 



Yep, j'en suis à l'origine, et on en a discuté un peu ici :

https://lists.openstreetmap.org/pipermail/talk-fr/2020-March/097360.html


J'ai l'impression que le fichier utilisé n'est plus disponible et 
qu'il ne traitait que les PAV d'ordures ménagères (avec ou sans clé 
électronique)


Il est ici :

https://github.com/osm-fr/osmose-backend/blob/master/merge_data/PAV_CSMA.csv.bz2

J'ai largement remanié celui d'origine pour qu'il soit utilisable dans 
Osmose. Entre autres, 1 ligne = 1 conteneur


Il y a 2 analyses pour lui :

- Une pour les conteneurs d'ordures ménagères

- Une autre pour les conteneurs "recyclage" (verre papier, etc..)

http://osmose.openstreetmap.fr/fr/map/#zoom=12=47.1357=-1.2961=8120=3==

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

Re: [OSM-talk-fr] Moulinette pour lire EXIF, générer GPX, et préremplir dans JOSM?

[Stéphane Péneau]

Exiftool permet de faire ça, j'en parle un peu ici :
http://www.stemani.fr/index.php?post/2016/09/16/Construire-son-V4MPod-pour-prendre-des-photos-%C3%A0-360%C2%B0-Partie-2

Mais franchement, dans ton cas je ne vois pas du tout l'intérêt. La 
position des photos n'est pas la position du POI, sans parler des cas où 
le POI existe déjà.


Stf

Le 09/05/2020 à 14:23, Shohreh a écrit :

Je vois que OSMTracker génère un GPX avec un lien vers le JPG pour chaque
waypoint photographié :


20.0
2019-10-06T15:49:00Z


2019-10-06_11-49-01.jpg

0

324.93212890625


Quelqu'un a-t-il du code pour générer ce genre de GPX à partir d'un ensemble
de JPG géotaggés ?



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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




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

Re: [OSM-talk-fr] [Edition mécanique] virer contact:google_plus et *~plus.google.com

[Stéphane Péneau]

Le 14/04/2020 à 00:41, Marc M. a écrit :

avis ? objection ?


Go !



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

Re: [OSM-talk-fr] copyright erroné

[Stéphane Péneau]

Je pense à 99,9% que c'est bien du Osm.

Stf

Le 09/04/2020 à 19:13, Erwan Salomon a écrit :

il y a des ressemblances en effet,
mais la carte est vieille (si vous cherchez vos contributions)
entre 2 et 3 ans
pour être précis selon mes modifications à Plœmeur 56270 (et c’est ma 
lubie de respecter le e dans l’o) entre le changeset #44313407 
 (création de la 
voie D163) et le #55626956 
 (passage de la rue 
de Savoie de secondary en résidentiel)


Le 9 avr. 2020 à 14:56, osm.sanspourr...@spamgourmet.com 
 a écrit :


https://www.apec.fr/mon-centre.html#/recherche



___
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 Circonscriptions académiques

[Stéphane Péneau]

Le 09/04/2020 à 12:50, David Crochet a écrit :

Bonjour

Le 09/04/2020 à 12:19, Marc M. a écrit :

une circonscriptions académiques n'est pas une entité administrative
(boundary=administrative) ayant un chef lieu, il ne devrait y avoir
aucun admin_center (de la même manière qu'il y a pas d'admin center
pour la sncf, ni pour une forêt, un parking, etc)


Hum, je suis circonspect pour cette réponse. Une académie ou une DSDEN 
est bien une entité administrative pusiqu'il y a un Recteur ou un 
DASEN et elur résidence adminsitrative sont les Rectorat et la DSDEN 
qui ne sont pas forcément les chef-lieu d'une région ou d'un département.


Tu as tronqué la phrase d'origine qui est :

"n'est pas une entité administrative ayant un chef lieu"

C'est un peu comme les EPCI qui n'ont pas de chef-lieu non plus, et dont 
il était question il y a quelques semaines. Il faudrait que je m'occupe 
de cette histoire.



Stf


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

Re: [OSM-talk-fr] Barrière délimitant une aire de jeux

[Stéphane Péneau]

Le 21/03/2020 à 03:05, Jérôme Amagat a écrit :


Moi je préfère mettre le tag  barrier=fence sur le même élément que 
leisure=playground



Pour le rendu mettre les 2 tags sur la même chose ça marche.

Le problème, c'est que c'est à cause de ça que le rendu osm a cesser de 
rendre les surface barrier=*


https://github.com/gravitystorm/openstreetmap-carto/pull/3844

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

Re: [OSM-talk-fr] Osmose, voirie non connectée

[Stéphane Péneau]

Bonjour Jocelyn,

Je ne sais pas si c'est le même problème que le ticket que tu as créé, 
mais ici aussi j'ai corrigé l'erreur il y a 10 jours :

http://osmose.openstreetmap.fr/fr/error/daed4c07-1737-313c-98c2-816a2d1e5e1b

Stf

Le 16/03/2020 à 22:35, Jocelyn Jaubert a écrit :

Bonjour,

Le 16/03/2020 à 12:02, Stéphane Péneau a écrit :

J'ai l'impression que la BDD utilisée par Osmose cafouille un peu car je
vois des erreurs sur des choses que j'ai corrigées il y a presque 10 jours.

exemple :
http://osmose.openstreetmap.fr/fr/error/ba1e3dcb-6631-70b3-b2d1-30ca256913e2


le tag amenity = bus_station a été enlevé le 7 mars.

Merci pour avoir donné cette exemple précis.

J'ai ouvert un ticket sur le frontend, pour qu'on étudie le souci plus
précisément:

https://github.com/osm-fr/osmose-frontend/issues/225




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

Re: [OSM-talk-fr] Osmose, voirie non connectée

[Stéphane Péneau]

Le 16/03/2020 à 11:53, Francois Gouget a écrit :


Je ne vois pas non plus. Je ne connais pas le code de cette partie
d'Osmose mais en suivant le lien je n'ai pas vu d'instance de 'lane'
donc je ne pense pas que ce soit à l'origine du rapport.

Peut-être marquer le problème comme corrigé pour voir s'il revient
(corrigé hein, PAS faux positif). Il y a peut-être eu un cafouillage à
un moment donné.


J'ai l'impression que la BDD utilisée par Osmose cafouille un peu car je 
vois des erreurs sur des choses que j'ai corrigées il y a presque 10 jours.


exemple : 
http://osmose.openstreetmap.fr/fr/error/ba1e3dcb-6631-70b3-b2d1-30ca256913e2


le tag amenity = bus_station a été enlevé le 7 mars.


Stf


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

Re: [OSM-talk-fr] Osmose, voirie non connectée

[Stéphane Péneau]

La signification est identique entre les 2 types d'écritures, donc je ne 
pense pas que ça vienne de ça.

Je ne suis même pas sûr que l'analyse prenne en compte ce type de tag.


Stf

Le 15/03/2020 à 17:57, Georges Dutreix via Talk-fr a écrit :
Je ne maîtrise pas trop la syntaxe des turn:lanes, mais ne faudrait-il 
pas "none|none|merge_to_left" au lieu de "||merge_to_left" ?


Peut-être cela crée-t-il le souci ?

Georges


Le 15/03/2020 à 09:45, Stéphane Péneau a écrit :

Salut,

Osmose m'indique une erreur de voirie non connectée, et j'avoue que 
je ne comprends pas du tout pourquoi :


http://osmose.openstreetmap.fr/fr/error/fe07c3d2-ba91-f492-f6b4-2c00cbdf8dd2 



Il s'agit de la jonction entre

https://www.openstreetmap.org/way/768475052
et
https://www.openstreetmap.org/way/123276562


Bug de l'analyse, ou alors je ne vois pas l'erreur ?


Stf


___
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] Osmose, voirie non connectée

[Stéphane Péneau]

Salut,

Osmose m'indique une erreur de voirie non connectée, et j'avoue que je 
ne comprends pas du tout pourquoi :


http://osmose.openstreetmap.fr/fr/error/fe07c3d2-ba91-f492-f6b4-2c00cbdf8dd2

Il s'agit de la jonction entre

https://www.openstreetmap.org/way/768475052
et
https://www.openstreetmap.org/way/123276562


Bug de l'analyse, ou alors je ne vois pas l'erreur ?


Stf


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

Re: [OSM-talk-fr] recycling ou waste_disposal

[Stéphane Péneau]

Le 11/03/2020 à 20:50, Georges Dutreix via Talk-fr a écrit :


Un point de tri en ville peut par exemple inclure plusieurs conteneurs 
enterrés dont un est destiné aux ordures. Comment étiquetter 
l'ensemble si on ne veut pas faire 3, 4 ou 5  POI's ?


Je crée autant de POI qu'il y a de conteneur, parce que c'est ce qu'il y 
a sur le terrain, et aussi parce que dans la majorité des cas pour les 
colonnes enterrées, les conditions d'accès ne sont pas les mêmes pour 
papier/verre/etc.. que pour les déchets ménagers. C'est en général 
gratuit/libre d'accès pour les premiers, et payant pour les seconds.


Donc on n'a pas vraiment le choix, il faut les séparer.

Stf




Le 11/03/2020 à 09:44, Stéphane Péneau a écrit :

Il y a environ 2500 recycling:waste=yes en France :
http://overpass-turbo.eu/s/RuQ

Je suppute qu'une grande partie est à corriger.

Stf

Le 11/03/2020 à 08:43, Vincent Bergeot a écrit :

Le 10/03/2020 à 21:25, osm.sanspourr...@spamgourmet.com a écrit :

Le 10/03/2020 à 21:07, Stéphane Péneau - stephane.pen...@wanadoo.fr a
écrit :


je pense rester sur "waste_disposal"
+1 


+1 également (car effectivement c'est le vrac de ce qui a été trié 
par ailleurs et la destination ultime)


à plus

--
Vincent Bergeot

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




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



___
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] admin_centre pour une comcom/agglo etc..

[Stéphane Péneau]

Le 11/03/2020 à 12:31, Marc M. a écrit :

s'il n'y a pas de localité/chef lieu, pourquoi discuter qui l'est ?
ma relation de bus n'a pas de chef lieu, du coup pas d'admin_center mis
sur le bureau de la direction
une grosse entreprise dans la zone industrielle n'a pas de chef lieu,
du coup pas d'admin_center mis sur le siege social
etc


C'est un point de vue intéressant.

Mais indiquer où sont les bureaux d'une comcom (qui accueille le public) 
reste une info intéressante. Donc on pourrait :


1) supprimer les admin_centre des EPCI
2) remplacer les admin_centre actuels par le siège social
3 remplacer les admin_centre actuels par le siège social, en utilisant 
un autre/nouveau type de role.



Stf



Le 11.03.20 à 10:36, Pierre-Yves Mevel via Talk-fr a écrit :

Bonjour Stéphane,

Je suis d'accord avec toi, le centre d'un EPCI doit être placé sur le
bâtiment en accueillant le siège. C'est d'ailleurs ce que j'avais fait
au moment des redécoupages de 2017 dans mon secteur, mais je constate
que les mêmes changements inconsidérés ont été opérés dans mon
secteur... Je peux comprendre que ce soit fait quand on ne connaît pas
le siège (BANATIC n'est pas toujours explicite là-dessus) mais il est
dommageable que ce soit systématique.

Bonne journée,
P-Y

Le mer. 11 mars 2020 à 09:59, Stéphane Péneau
mailto:stephane.pen...@wanadoo.fr>> a écrit :

 Hello,

 A l'époque de la création d'une communauté d'agglomération dans mon
 secteur, je l'avais créée avec pour membre admin_centre, le bâtiment où
 sont installés les bureaux de cette collectivité. J'en avais fait de
 même pour d'autres epci dans la région.

 Depuis, ces relations ont été modifiées pour utiliser le noeud "place"
 d'une commune en tant qu'"admin_centre".

 Le souci, c'est que de ce que j'ai compris, et contrairement aux
 communes, les EPCI n'ont pas de chef-lieu, mais simplement un siège
 social. Donc utiliser le noeud "place" de la commune où est situé le
 siège n'a pas vraiment de sens.

 extrait de l'arrêté de création :

 "Le siège de la communauté d'agglomération est fixé au 15 rue des
 Malifestes, 44190 CLISSON"
 
http://www.loire-atlantique.gouv.fr/content/download/29861/209689/file/RAA%20sp%C3%A9cial%20n%C2%B0%20104%20du%2016%20novembre%202016.pdf


 Me trompe-je ?

 Si ce n'est pas le cas, alors on a quelques corrections à faire.

 Stf


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


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



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




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

[OSM-talk-fr] admin_centre pour une comcom/agglo etc..

[Stéphane Péneau]

Hello,

A l'époque de la création d'une communauté d'agglomération dans mon 
secteur, je l'avais créée avec pour membre admin_centre, le bâtiment où 
sont installés les bureaux de cette collectivité. J'en avais fait de 
même pour d'autres epci dans la région.


Depuis, ces relations ont été modifiées pour utiliser le noeud "place" 
d'une commune en tant qu'"admin_centre".


Le souci, c'est que de ce que j'ai compris, et contrairement aux 
communes, les EPCI n'ont pas de chef-lieu, mais simplement un siège 
social. Donc utiliser le noeud "place" de la commune où est situé le 
siège n'a pas vraiment de sens.


extrait de l'arrêté de création :

"Le siège de la communauté d'agglomération est fixé au 15 rue des 
Malifestes, 44190 CLISSON"

http://www.loire-atlantique.gouv.fr/content/download/29861/209689/file/RAA%20sp%C3%A9cial%20n%C2%B0%20104%20du%2016%20novembre%202016.pdf


Me trompe-je ?

Si ce n'est pas le cas, alors on a quelques corrections à faire.

Stf


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

Re: [OSM-talk-fr] recycling ou waste_disposal

[Stéphane Péneau]

Il y a environ 2500 recycling:waste=yes en France :
http://overpass-turbo.eu/s/RuQ

Je suppute qu'une grande partie est à corriger.

Stf

Le 11/03/2020 à 08:43, Vincent Bergeot a écrit :

Le 10/03/2020 à 21:25, osm.sanspourr...@spamgourmet.com a écrit :

Le 10/03/2020 à 21:07, Stéphane Péneau - stephane.pen...@wanadoo.fr a
écrit :


je pense rester sur "waste_disposal"
+1 


+1 également (car effectivement c'est le vrac de ce qui a été trié par 
ailleurs et la destination ultime)


à plus

--
Vincent Bergeot

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



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

Re: [OSM-talk-fr] recycling ou waste_disposal

[Stéphane Péneau]

Le 10/03/2020 à 21:25, osm.sanspourr...@spamgourmet.com a écrit :



La palme de l'écoblanchiment revient à EDF/Orano qui parce de recyclage
alors que 99,5 % du combustible usé n'est pas recyclé et quand il l'est
c'est une fois.
 



Je ne vois pas trop ce que ça vient faire ici, surtout que c'est 
beaucoup, beaucoup, mais alors vraiment beaucoup plus compliqué que ça.
Quelques explications en vidéo : 
https://www.youtube.com/playlist?list=PLhgpBc0hGjSvCZ4Uo9mE1XTc7aSa4NRLE


Stf


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

Re: [OSM-talk-fr] recycling ou waste_disposal

[Stéphane Péneau]

Le 10/03/2020 à 20:36, Marc M. a écrit :

Bonjour,

je n'ai pas compris ta question :
tu hésites entre poubelle et recyclage ?


C'est ça, j'hésite entre les 2 solutions pour qualifier les conteneurs à 
déchets ménagers.


Mais la lecture de la page wikipedia sur le recyclage me donne une piste:

Le terme /recyclage/ fait l'objet d'une définition réglementaire dans le 
Code de l'Environnement : « Recyclage : toute opération de valorisation 
 par 
laquelle les déchets, y compris les déchets organiques, sont retraités 
en substances, matières ou produits aux fins de leur fonction initiale 
ou à d'autres fins. Les opérations de valorisation énergétique 
 
des déchets, celles relatives à la conversion des déchets en combustible 
 et 
les opérations de remblaiement ne peuvent pas être qualifiées 
d'opérations de recyclage^1 
 . »


Donc on oublie la partie production d'énergie. Il ne reste que 
l'opération de triage/recyclage (fer, plastique) qui pourrait entrer 
dans cette catégorie. Ce qui représente une faible partie du volume 
initiale. A priori, et sauf si je lis des arguments contraires, je pense 
rester sur "waste_disposal"



Stf


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

[OSM-talk-fr] recycling ou waste_disposal

[Stéphane Péneau]

Salut,

dans ma communauté d'agglo, après avoir pris quelques renseignements, 
j'ai appris que les déchets "tout venant", sont :


- envoyés dans un incinérateur qui produit de l'énergie

ou

- triés grossièrement (plastique, métaux ferreux) puis enfouis pour ce 
qui reste.


La question est donc comment tagger les conteneurs pour ces déchets :

amenity=recycling + recycling:waste=yes

ou bien

amenity=waste_disposal


J'avais choisi waste_disposal, mais maintenant j'ai un doute.


A+

Stf


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

Re: [OSM-talk-fr] parking

[Stéphane Péneau]

Je ne suis pas trop fan de coller le parking à l'axe de la route.

Malheureusement, je ne crois pas qu'il y a de solution parfaite 
lorsqu'on mélange du surfacique et du filaire.


Dans 1 cas, on "invente" une voie d'accès, et la représentation 
surfacique du parking est correcte.
Dans l'autre, on fausse la surface du parking en l'agrandissant pour 
venir se coller à l'axe de la route.


Perso, je suis plutôt partisan de la première solution.

Stf


Le 09/03/2020 à 21:30, Romain MEHUT a écrit :

Bonsoir,

J'ai annulé ma modification.

Romain

Le lun. 9 mars 2020 à 16:23, Bernard Lefrançois 
mailto:bernard.lefranc...@free.fr>> a écrit :


Bonjour,
Je partage plutôt la vision de Jean-Yvon.
Sur ta dernière version:
- tu laisses un espace vide qui n'existe pas entre le parking et
la route.
- tu crées à un emplacement aléatoire une voie qui n'existe pas
non plus.

Lorsque je cartographie un parking, j'applique la règle suivante:
- le parking est séparé réellement de la route (par un fossé, une
bande d'herbe, un trottoir etc.), je le trace en surfacique avec
ses limites réelles. Et dans ce cas, il y a forcément une voie
pour y accéder et je la représente à sa place.
- ou bien:  le parking borde la route sans séparation et dans ce
cas une partie du polygone représentant le parking est commune
avec le linéaire de la route. Inutile de rajouter ici une voie
d'accès puisque cet accès est possible sur toute la longueur.

Le 08/03/2020 à 21:38, Romain MEHUT a écrit :

J'ai proposé une autre version toute simple.
Romain

Le dim. 8 mars 2020 à 11:53, mailto:osm.sanspourr...@spamgourmet.com>> a écrit :

Oui voir : http://osmose.openstreetmap.fr/en/byuser/ririahp

L'erreur c'est d'avoir fait coller le parking au dessin de la
route au
lieu de le faire coller au fil de la route : mélange
représentation
filaire/représentation surfacique. J'ai corrigé.

Jean-Yvon

Le 08/03/2020 à 08:36, Arnaud Champollion -
arnaud.champoll...@linux-alpes.org
 a écrit :
> Bonjour,
>
> Question suite aux contributions du groupe OSMDigne réuni hier
> après-midi.
>
> Quand on trace un parking comme surface, faut-il nécessairement
> ajouter une voie de type highway pour le connecter à la route ?
>
> Le cas se trouve ici :
> https://www.openstreetmap.org/#map=19/43.81467/6.24606
>
> Sur la vue aérienne il est visible qu'il n'y a pas
réellement de voies
> pour entrer / sortir, ni de voies de parking, seulement une
aire en
> terre battue qui borde la route.
>
> Merci de vos avis,
>
> Bonne journée,
>
> Arnaud
>
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr


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


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



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


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



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

Re: [OSM-talk-fr] Projet du mois de mars - #balanceTaBorne

[Stéphane Péneau]

C'est bon, c'est corrigé pour le doubs.
Ajoutons ça une petite modif sur le script etalab, et la prochaine 
consolidation devrait ajouter un peu plus de 1500 bornes de recharges. 
Ensuite ce sera à Noémie d'importer cette nouvelle version dans Osmose.


Malgré tout, il reste encore de nombreux fichiers qui ne sont pas dans 
les clous pour être intégrés.


Stf

Le 03/03/2020 à 13:59, Stéphane Péneau a écrit :



Un contributeur à fait le boulot :
https://www.data.gouv.fr/fr/datasets/r/601cffc9-d63e-45da-a7d4-82461223c077 



J'ai vu, mais c'est une vieille version (2018), et elle n'est pas 
récupérée par le script.


Stf

___
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] Projet du mois de mars - #balanceTaBorne

[Stéphane Péneau]

Un contributeur à fait le boulot :
https://www.data.gouv.fr/fr/datasets/r/601cffc9-d63e-45da-a7d4-82461223c077

J'ai vu, mais c'est une vieille version (2018), et elle n'est pas 
récupérée par le script.


Stf

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

Re: [OSM-talk-fr] Projet du mois de mars - #balanceTaBorne

[Stéphane Péneau]

Le 01/03/2020 à 14:34, Yves P. a écrit :
Par exemple, il n’y a qu’une seule borne dans tout le Jura et rien 
dans le Doubs. Osmose 



Pour le Doubs, le fichier est présent sur data.gouv, mais est mal encodé 
ce qui le rend inutilisable par le script qui consolide tous les 
fichiers des différentes collectivités.


J'ai demandé à ce qu'il soit corrigé :

https://www.data.gouv.fr/fr/datasets/irve-syded-recensement-et-information-doubs/#discussion-5e5e2687634f416ca89964c5

Stf

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

[Stéphane Péneau]

Le 17/02/2020 à 20:02, severin.menard via Talk-fr a écrit :


Pour la solution basée sur le boîtier Drotek Sirius utilisant la carte 
ublock F9, que faut-il prévoir en plus côté accessoires ?





Un gros trépied ?


Oui


De quoi l'alimenter ?


Batterie fournie


Un boîtier étanche pour les intempéries ?


Le mieux est peut-être de leur demander



Et côté softs ?

Tu peux presque tout faire avec RTKLib qui est FOSS. Ce fork est 
recommandé : https://github.com/rtklibexplorer/RTKLIB



Si j’ai bien compris, l’idée n’est pas de créer une base GNSS comme le 
montrait Stéphane dans sa présentation, mais d’avoir deux récepteurs 
qui enregistrent leur position de manière Indépendante et du 
post-traitements une fois le terrain fini ?


L'idée c'est d'utiliser un récepteur en tant que base qui pourra être 
déplacée de temps en temps. Mais pour que les coordonnées de cette base 
soit correctes, il faudra tout de même la laisser assez longtemps 
(plusieurs heures) sur un endroit fixe.


Quelle surface tu souhaites couvrir ?

Y a-t-il d’autres personnes que moi qui seraient intéressées par un 
atelier pratique lors du SotM de Nantes sur toute la chaîne des deux 
approches Ublock en PPP et deux ublocs + ? Je pourrais amener un ou 
deux Drotek.



Pourquoi pas.

Stf


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

[Stéphane Péneau]

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

Le 17/02/2020 à 17:20, Eric SIBERT via Talk-fr -
talk-fr@openstreetmap.org a écrit :


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


RTKGPS ?



RTKGPS n'est que RTKLIB pour Android. Il faut tout de même un récepteur 
qui propose les données "RAW", ce qui est plutôt rare sur les 
smartphones, et les résultats sont ... moyens ... pour cause d'antenne 
pas terrible.



Stf


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

Re: [OSM-talk-fr] Données sur les bouches de métro franciliennes

[Stéphane Péneau]

Le 17/02/2020 à 11:19, osm.sanspourr...@spamgourmet.com a écrit :


N. B. : curieux une bouche de métro au niveau -2. Non accessible depuis
l'arrêt de bus ?

Il y a un escalier, et le rideau métallique qui permet de fermer 
l'entrée est en bas de cet escalier.


il y a des photos sur Mapillary : 
https://www.mapillary.com/map/im/SVmAQGYC3wBDC8l7rxBwtg



Stf



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

Re: [OSM-talk-fr] Données sur les bouches de métro franciliennes

[Stéphane Péneau]

Le 17/02/2020 à 09:19, Christian Quest a écrit :


Le fait qu'elle soit reliée à la station (stop_area) donne la première 
indication, et le fait qu'elle porte un nom/numéro/destination donne 
la seconde.



Le 17/02/2020 à 11:19, osm.sanspourr...@spamgourmet.com a écrit :


D'une manière générale les bouches n'ont pas de nom, sauf peut-être
certaines entrées monumentales ayant leur propre page Wikipédia par 
exemple.



Bah alors, elles ont un nom ou pas ?

Je me trompe peut-être, mais je pense que si on s'amuse a supprimer les 
"name" sur les bouches de métro/rer/train, ça ne va pas plaire à tout le 
monde.




Ici tout simplement :
noname=yes
destination=Rue Van Gogh
ref=13

"destination" sur un noeud, ça ne fonctionne pas. C'est fait pour être 
utilisé sur un way.



Le 17/02/2020 à 09:19, Christian Quest a écrit :



Faire intervenir un autre type de relation (destination_sign) ne 
simplifie pas la réutilisation et de moins en moins KISS ;)



Coquin ! :-)

Ce type de relation existe pour les cas complexes que ne peut pas 
décrire seul le tag "destination". Lorsqu'on mélange "grandes gares", 
"indoor" et représentation surfacique, on se retrouve rapidement obligé 
de les utiliser.



Stf


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

Re: [OSM-talk-fr] zone résidentielle dans une zone résidentielle ?

[Stéphane Péneau]

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


> Je suis le seul à trouver ça un peu tordu ?
Peut-être pas.

Mais en tous cas, moi ça ne me choque pas.

Si tu veux mélanger une notion surfacique et une notion ponctuelle, 
dans OSM la réponse c'est la relation. Après si tu dérives la notion 
ponctuelle à partir du surfacique, tu peux t'en passer. Mais ici le 
rendu ne tenant compte que des place sur les nœuds, tu n'y coupes pas.


Sauf à manquer d'une information.



Donc c'est tagger pour le rendu, non ?

Stf



Jean-Yvon

Le 16/02/2020 à 13:09, Stéphane Péneau - stephane.pen...@wanadoo.fr a 
écrit :
Une relation pour délimiter un ensemble de 8 maisons ? Je suis le 
seul à trouver ça un peu tordu ?


Stf


Le 05/02/2020 à 21:58, osm.sanspourr...@spamgourmet.com a écrit :


https://www.openstreetmap.org/relation/10060749#map=19/47.78699/-3.48688

Le Prat et Les Jardins de Vitalis sont deux lotissements jointifs. 
Et tu pourrais les englober dans des place de plus haut niveau.


Ils font partie du landuse=residential de la zone agglomérée du 
bourg de Guidel.


On ne mélange pas l'utilisation (landuse) des dénominations (ici Le 
Prat et Les Jardins de Vitalis) qui ont leur vie propre si j'ose dire.


Jean-Yvon

Le 05/02/2020 à 21:26, Arnaud Champollion - 
arnaud.champoll...@linux-alpes.org a écrit :

Le 05/02/2020 à 21:23, pepilepi...@ovh.fr a écrit :


Pourquoi tu veux faire ça ? Si c'est juste pour le nommer il y a 
place=neighbourhood 
<https://wiki.openstreetmap.org/wiki/FR:Tag:place%3Dneighbourhood>...


Bonne soirée,



Justement je ne veux pas le faire.

Je suis tombé dessus car il y a plusieurs zones mappées ainsi à 
Digne les Bains.


Je me suis dit que ça n'avait pas l'air normal, mais je voulais 
m'en assurer avant de supprimer ou remplacer par un tag plus adapté.




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


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




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



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

Re: [OSM-talk-fr] zone résidentielle dans une zone résidentielle ?

[Stéphane Péneau]

Une relation pour délimiter un ensemble de 8 maisons ? Je suis le seul à 
trouver ça un peu tordu ?


Stf


Le 05/02/2020 à 21:58, osm.sanspourr...@spamgourmet.com a écrit :


https://www.openstreetmap.org/relation/10060749#map=19/47.78699/-3.48688

Le Prat et Les Jardins de Vitalis sont deux lotissements jointifs. Et 
tu pourrais les englober dans des place de plus haut niveau.


Ils font partie du landuse=residential de la zone agglomérée du bourg 
de Guidel.


On ne mélange pas l'utilisation (landuse) des dénominations (ici Le 
Prat et Les Jardins de Vitalis) qui ont leur vie propre si j'ose dire.


Jean-Yvon

Le 05/02/2020 à 21:26, Arnaud Champollion - 
arnaud.champoll...@linux-alpes.org a écrit :

Le 05/02/2020 à 21:23, pepilepi...@ovh.fr a écrit :


Pourquoi tu veux faire ça ? Si c'est juste pour le nommer il y a 
place=neighbourhood 
...


Bonne soirée,



Justement je ne veux pas le faire.

Je suis tombé dessus car il y a plusieurs zones mappées ainsi à Digne 
les Bains.


Je me suis dit que ça n'avait pas l'air normal, mais je voulais m'en 
assurer avant de supprimer ou remplacer par un tag plus adapté.




___
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] Données sur les bouches de métro franciliennes

[Stéphane Péneau]

Une partie des bouches portent des indications différentes selon si on 
entre ou sort du métro.
Pour se conformer à cette situation, tout en cartographiant les zones 
intérieures en surfacique, on avait utilisé les relations destination_sign.

Exemple à la gare de lyon :
https://www.openstreetmap.org/node/4086374120
Cette bouche porte le nom "Gare de Lyon" lorsqu'on vient de l'extérieur, 
et "Sortie Rue Van Gogh" lorsqu'on sort.

Et sa relation destination_sign :
https://www.openstreetmap.org/relation/10054778

Stf

Le 14/02/2020 à 15:26, Francois Gouget a écrit :

On Fri, 14 Feb 2020, osm.sanspourr...@spamgourmet.com wrote:
[...]

https://www.sortiesdumetro.fr
 n'a pas des
données libres, mais ça peut permettre de voir la complétude. Après rien
n'empêche de demander s'ils acceptent une exception.

Ce site indique aussi quelles sorties disposent d'un ascenseur. Je ne
sais pas si la présence d'un ascenseur doit être représentée dans
OpenStreetMap mais ça serait sans doute une bonne idée d'indiquer quelle
sorties sont accessibles en fauteuil roulant.

Parfois les deux se combinent. Par exemple à Cachan deux des sorties ont
un ascenseur et sont donc accessibles en fauteuil roulant (+poussettes &
valises lourdes), tandis que deux autres nécessitent d'emprunter un
escalier.

Pour une sortie je suppose que la géométrie pourrait suffir à expliciter
l'accessibilité en chaise roulante, quoiqu'il n'y ait pas le moindre tag
wheelchair à l'horizon.

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

Mais pour l'autre sortie je ne vois pas trop comment une application
pourrait rattacher l'ascenseur à la sortie correspondante et traiter les
aspects chaise roulante :

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

Bon, et le champ name contient le nom de la station dans les deux cas
ce qui serait faux selon Noémie (et je suis d'accord). Par contre,
faut-il vraiment mettre le numéro dans le nom ou devrait-il être dans
le champ ref ? (pas exit_number apparemment) Ou les deux ?


[...]

266 noeuds sans tag ref. Est-ce que l'absence de ce tag a aussi une
sémantique (par exemple il n'y a qu'une sortie), ou est-ce que ce sont
des données manquantes?

ref est-il sensé être unique globalement ? (comme pour les
identifiants de boîtes aux lettres ou de transformateur) Parce que si
l'on met le numéro de sortie il y aura beaucoup de doublons 1, 2, 3...



1070 noeuds ont un attribut name, seulement 57 ont un attribut
destination. Est-ce que du coup on pourrait faire disparaître l'attribut
destination?

Non, destination est bon. C'est plutôt "name" qui est à vérifier et à
remplacer par destination le cas échéant.

Si je reprends la gare de Cachan, destination contient le nom des lignes
de bus en correspondance. Ça ne me semble pas devoir aller dans name.
Mais destination devrait-il indiquer les lignes de bus plutôt que les
noms de rues ?

Ce qui est bizarre aussi c'est qu'il a deux sorties côte à côte, une
pour le quai des RERs en provenance de Paris et l'autre pour ceux venant
de la banlieue ; et l'une indique "162;187;193;v3" et l'autre
"162;187;193". Pourtant venant de province c'est bien la sortie à
prendre pour attraper la Valouette (v3). C'est peut-être une bizarrerie
de l'affichage RATP. Il faudra que je vérifie.



Et qu'en est-il de découper le contenu de name, ou au moins d'en avoir
une version alternative découpée en plusieurs morceaux?

destination, ref et le nom de la station portée par la relation
public_transport=stop_area, oui c'est mieux (et au final on vire name,

Si à Cachan le champ destination contient bien les noms des lignes de
bus, alors il ne permettrait pas de reconstruire le nom des sorties qui,
il me semble, contiennent le nom de la rue où elles sont.




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

[Stéphane Péneau]

Bonjour Séverin,

Je ne vais pas discuter du SX Blue, d'autres l'ont fait, mais un peu 
plus des autres options disponibles, principalement à base de puce Ublox 
F9P.


- On va partir du principe qu'il n'y a pas de réseau de base gnss 
accessible comme le RGP en France [1].


Si on utilise un récepteur standard, ou même un récepteur plus évolué 
comme le F9P, mais en fonctionnement basique, alors on ne sera pas en 
submétrique.
Dans ce genre de cas, on peut utiliser le PPP pour "Precise Point 
Positionning". Ça ne peut se réaliser qu'avec un récepteur type F9P ou 
autre produit de la même gamme.
Pour ce faire, on place notre récepteur sur un point fixe, et on le 
laisse enregistrer sur plusieurs heures, l'idéal étant 24h. Ensuite, on 
peut récupérer les données et les traiter avec des services en lignes 
(gratuits) ou avec RTKLIB (logiciel libre), mais c'est un peu plus 
compliqué avec ce dernier. Là, on obtiendra une position sous les 10 cm, 
et encore mieux si on attend quelques semaines avant de faire le 
post-traitement (je t'épargne les détails techniques pour l'instant). Je 
pense que le Sirius qu'a mentionné Christian est adapté à ce genre de cas.
L'inconvénient de cette solution PPP, c'est qu'il faut pouvoir laisser 
le récepteur en place sur une longue durée.


Il y a une évolution du PPP qui utilise des corrections (SSR) et qui 
permet d'obtenir une très bonne précision bien plus rapidement, mais 
c'est encore assez expérimental[3].


L'étape suivante, c'est d'installer des bases fixes pour recréer un 
réseau comme celui du RGP, comme Centipede [2]. Ensuite, le récepteur 
qui pourra être basé lui aussi sur une puce F9P, utilisera la position 
de la base pour calculer la sienne avec plus de précision (toujours - de 
10cm si on reste dans un rayon de 30 à 60 km de la base). Cette position 
pourra être obtenue en général en moins d'1mn si on peut recevoir les 
données de la base en direct (connexion internet), ou alors on 
enregistre les données séparément, et on post traite ça une fois qu'on 
retrouve un ordi et une connexion, c'est en général ce que je fais et 
j'obtiens ce genre de chose : http://www.stemani.fr/public/Osm/anim_rtk.gif
On appelle ça du RTK, ou Post-RTK si on n'est pas en temps réel (parfois 
abrégé en PPK).


J'ai construit ma propre base et j'en ai parlé au dernier Sotm, mais 
malheureusement ce n'était pas filmé. Les diapos sont là : 
http://www.stemani.fr/public/gnss/Fabrication_base_GNSS.pdf

Le code : https://github.com/Stefal/rtkbase
Depuis, d'autres ont été fabriquées sur le même concept et rejoindront 
le réseau centipede prochainement : 
https://twitter.com/complementterre/status/1204801663321726976


J'ai aussi un logger mobile qui enregistre sur une carte micro SD, mais 
je n'ai pas documenté pour le moment. Je récupère son signal via 
Bluetooth sur mon smartphone, mais c'est de la localisation standard 
puisque la plupart du temps je ne suis pas connecté à une base, je fais 
du post-traitement un fois rentré.



Pour ce qui est de récupérer ce signal Bluetooth via une appli libre, 
j'ai forké un fork de fork deBlueGPS. Il est loin d'être parfait, 
n'est pas 100% stable, mais il existe : 
https://github.com/Stefal/bluegnss4droid/releases
Mes compétences en Java étant proches du néant, j'ai du mal à 
l'améliorer


[1]http://rgp.ign.fr/DONNEES/diffusion/
[2]https://centipede.fr/
[3]https://rtklibexplorer.wordpress.com/2018/05/08/using-ssr-corrections-with-rtklib-for-ppp-solutions/

A+

Stéphane


Le 14/02/2020 à 03:00, severin.menard via Talk-fr a écrit :

Bonjour à tou-te-s,

J'ai eu l'occasion d'en parler de manière informelle à quelques 
personnes et peut-être ce sujet a-t-il déjà été discuté en long et en 
travers sur un fil de cette liste ou sur le forum, mais je ne l'ai pas 
trouvé. Désolé si c'est le cas !


Après une assez longue période (en gros entre 2012 et mi 2017) pendant 
laquelle la communauté OSM s'est appuyée sur l'imagerie Bing pour 
digitaliser, l'arrivée d'autres ressources (Digital Globe en mai 2017, 
Esri puis Maxar remplaçant Digital Globe avec une imagerie différente, 
qui n'est plus disponible actuellement) a permis de bénéficier 
d’imageries généralement plus récentes que Bing et parfois sans nuages 
sur des zones qui restaient encore à digitaliser complètement. 
Cependant, chacune de ces images possède un géo-référencement 
légèrement différent, à quelques mètres pràs, sans qu'il soit souvent 
possible de déterminer lequel serait le meilleur à partir des traces 
de terminaux GPS grand public à 2-5 m de précision. En France, la 
convention passée entre OSM France et l'IGN permet de s'appuyer sur 
son imagerie dont le géo-référencement, j'imagine, peut être considéré 
comme faisant référence. Sur d'autres territoires francophones, 
l'usage d'autres sources que Bing rend la carte OSM certes  
globalement plus à jour, mais avec une diminution de l’homogénéité du 
géo-référencement des objets dans la base, tous les contributeurs ne 

Re: [OSM-talk-fr] Demande d'intervention de tiers sur un conflit d'édition

[Stéphane Péneau]

Le 12/02/2020 à 13:31, Charles MILLET a écrit :


Je ne suis pas à l'aise avec l'idée de faire un signalement au DWG 
car en dehos de ce genre de comportement, ses contributions sont 
bonnes. Pensez-vous qu'il faille le faire ?



Oui, mais j'ai un point de vue biaisé puisque partie prenante.

Stf


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

Re: [OSM-talk-fr] Proposition de mise à jour : la population des communes

[Stéphane Péneau]

Bonjour,

Dupliquer la population sur l'admin-centre me semble une mauvaise idée 
surtout sur les nouvelles communes. En effet, elle a pu être mise à 
jour pour cette ancienne commune seulement et n'a donc pas la même 
valeur que la nouvelle. Je rappelle que beaucoup (la majorité ?) de 
nouvelles communes n'ont pas le même nom que l'ancienne et aussi que 
l'ancienne peut avoir deux relations admin_centre (pour elle-même et 
pour la nouvelle).


Exact, et dans ce cas, je n'ai pas dupliqué la population de la commune 
nouvelle sur l'"admin_centre"


Stf

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

Re: [OSM-talk-fr] Proposition de mise à jour : la population des communes

[Stéphane Péneau]

Si je récapitule :

- Vincent lance l'outil aidant la maj de la population sur les relations 
des communes.


- Je soulève l'idée de supprimer le tag "population" des noeuds car ce 
n'est pas cohérent.


- Christian indique qu'il l'utilise

- Discussions sur les différents cas qui se présentent. Avec plusieurs 
propositions de supprimer "population" des noeuds.


- J'indique que si c'est utilisé par le rendu FR, ça bloque un peu ce 
processus.



Dans ma tête, j'en suis resté à l'idée qu'il fallait le conserver pour 
l'instant, et sur les maj que j'ai effectuées, j'ai copié la valeur de 
"population" sur le noeud "admin_centre".

D'autres sont partis du principe qu'il fallait le supprimer.

Stf


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

Re: [OSM-talk-fr] Proposition de mise à jour : la population des communes

[Stéphane Péneau]

Je vois des discussions et des changesets avec des suppressions du tag 
"population" sur le node "admin_centre", mais on a réellement décidé de les 
supprimer ? Je croyais qu'on devait les laisser puisque c'est utilisé pour le 
rendu FR.

Stf


6 févr. 2020 a écrit :
>Le 06/02/2020 à 15:04, Vincent de Château-Thierry a écrit :
>
 Il semble que quelqu'un conteste tes mises à jour ou plutôt ne
 les as pas comprises. C'est sur :
 
 https://forum.openstreetmap.org/viewtopic.php?id=68546
>> 
>> Merci Alain pour le pointeur. Comme dit par Marc on a reçu en
>> parallèle un message de Clinton par un autre canal. Toutes nos
>> réponses convergent donc il devrait pouvoir synthétiser. Je vois qu'à
>> l'instant il a remercié Marc ici.
>Il y a même un breton qui a répondu sur le forum.
>-- 
>deuzeffe - je n'ai pas le nom
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- Envoyé de mon téléphone Android avec K-@ Mail. Excusez la brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Fwd: [OSM-dev] OpenStreetMap Carto release v4.25.0

[Stéphane Péneau]

Le 02/02/2020 à 20:48, François Lacombe a écrit :


Le dim. 2 févr. 2020 à 18:41, pepilepi...@ovh.fr 
<mailto:pepilepi...@ovh.fr> <mailto:pepilepi...@ovh.fr>> a écrit :


Le 02/02/2020 à 14:50, Stéphane Péneau a écrit :


Ça m'a tout cassé mes jolies haies  :-(((

https://www.openstreetmap.org/#map=19/47.09460/-1.35571


Natural=scrub est-il incompatible ici ? (si tu veux retrouver tes
jolies haies...)


C'est plutôt pour la broussaille basse, les haies peuvent être 
composées d'arbres à part entière.
Et le rendu vert kaki reflète peu la broussaille qu'on trouve ici je 
trouve


De plus, les haies sont des barrières, ça n'a pas la même implication 
pour le routing.


Il y a une partie des haies que j'ai tracées à l'époque, qui devraient 
être moins larges qu'elles ne le sont. Les images sont meilleures 
maintenant.



Bon, je ne vais pas en faire tout un foin, c'est juste le rendu, et je 
crois que je n'ai pas tout compris aux discussions sur le ticket. De mon 
point de vue, un landuse=meadow + barrier=hedge, c'est mélanger 2 types 
de données.


https://github.com/gravitystorm/openstreetmap-carto/pull/3844


Stf

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

Re: [OSM-talk-fr] Fwd: [OSM-dev] OpenStreetMap Carto release v4.25.0

[Stéphane Péneau]

Le 01/02/2020 à 11:18, marc marc a écrit :

* Supprimer le rendu de remplissage des polygones pour les zones de
barrier=hedge (#3844)
  Cela rend le rendu cohérent entre les murs et les haies en tant que
zones


Ça m'a tout cassé mes jolies haies  :-(((

https://www.openstreetmap.org/#map=19/47.09460/-1.35571

Stf

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

Re: [OSM-talk-fr] Type de highway pour voie de bus

[Stéphane Péneau]

Le 22/01/2020 à 22:25, marc marc a écrit :

Le 22.01.20 à 22:06, Stéphane Péneau a écrit :

Le 22/01/2020 à 20:41, marc marc a écrit :

Le 22.01.20 à 20:27, Stéphane Péneau a écrit :

interdite à tout le monde, mais les trottoirs accessibles aux piétons.

access=no + foot=yes :)

Bah non, dans ce cas, la rue entière est accessible  aux piétons.
Je parle de l'hypothétique cas où il n'y a que les trottoirs qui
seraient accessibles à pied.

la loi ne dit-elle pas que le piéton doit marcher sur le trotoir quand
il y en a un ?


Ah ben tient, il semblerait que ma période "urbaine" soit trop loin pour 
me souvenir de ça.


Merci.

Stf

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

Re: [OSM-talk-fr] Type de highway pour voie de bus

[Stéphane Péneau]

Le 22/01/2020 à 20:41, marc marc a écrit :

Le 22.01.20 à 20:27, Stéphane Péneau a écrit :

interdite à tout le monde, mais les trottoirs accessibles aux piétons.

access=no + foot=yes :)


Bah non, dans ce cas, la rue entière est accessible  aux piétons.
Je parle de l'hypothétique cas où il n'y a que les trottoirs qui 
seraient accessibles à pied.


Stf

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

Re: [OSM-talk-fr] Type de highway pour voie de bus

[Stéphane Péneau]

Le 22/01/2020 à 13:23, Florimond Berthoux a écrit :

Comme déjà dit access=no c’est vraiment no pour tous même les piétons.
Par contre oneway ait explicitement définit pour uniquement les véhicules
«The oneway tag is used to indicate the access restriction on highways 
and other linear features for _*/vehicles /*_as appropriate.»

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


Ok.

Par contre ce schéma ne permet pas de représenter une voie qui serait 
interdite à tout le monde, mais les trottoirs accessibles aux piétons. 
Oui bon d'accord, c'est vraiment pour chercher le cas bizarre et rare :-)



Stf


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

Re: [OSM-talk-fr] Type de highway pour voie de bus

[Stéphane Péneau]

Le 22/01/2020 à 10:12, Florimond Berthoux a écrit :

Les piétons n’ont pas à marcher sur la voie bus, mais ils peuvent
marcher sur les trottoirs ;)

Pour être juste le wiki dit « For dedicated, separate bus tracks, use
highway=service, access=no, psv=designated (or psv=yes). »
https://wiki.openstreetmap.org/wiki/Buses
Mais c’est bête je trouve, dans le cas générale ça devrait plutôt être
vehicle=no* et psv=yes
Mais en même temps les chevaux sont interdit aussi xD
It’s complicated.


Je ne vois pas vraiment le problème avec access=no + psv=yes/designated.

Ces tags ne concernent pas le trottoir accessible aux piétons qu'on peut 
ajouter avec sidewalk=*, sinon ça voudrait dire qu'un oneway=yes sur la 
voie de bus impliquerait que le trottoir l'est aussi.


Stf



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

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

[Stéphane Péneau]

Merci pour vos réponses.

Je ne pense pas que ce soit un troll, mais plutôt qu'il a vu une toute 
petite partie de ce qu'est réellement "OpenStreetMap". J'ai fait une 
dernière réponse :

https://linuxfr.org/users/kwiknclean/journaux/tout-cela-me-fatigue#comment-1797124

Stf

Le 19/01/2020 à 00:16, marc marc a écrit :

Le 18.01.20 à 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 ?

[1] https://linuxfr.org/nodes/119088/comments/1796042

[2] https://linuxfr.org/nodes/119088/comments/1796846

il y a beaucoup de "caricature simpliste d'un monde complexe"
mais je trouve qu'il y a quand même un part de vrai :
les serveurs osm.org de rendu par exemple, c'est un exemple de pelote,
tellement emmelé que leur évolution a du mal.

ceci dit, là où il se trompe à mes yeux, c'est que l'empilement permet
de réutiliser des briques simples au lieu d'inventer un nouveau Xieme
protocole ou Xieme brique qui fait quasi pareil que l'existant mais qui
a 1% de différence "d'optimisation" et qui au final rendra le moins
performant ou moins facile à maintenir (parce qu'à chaque amélioration
de la brique standard, il faudra du temps pour maintenir
le fork optimisé). On a cela pas loin...
___
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] OpenStreetMap un bloatware ?

[Stéphane Péneau]

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 ?


[1] https://linuxfr.org/nodes/119088/comments/1796042

[2] https://linuxfr.org/nodes/119088/comments/1796846


Stf


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