Re: [OSM-talk-fr] Rond-point dupliqués et découpés suite à l'utilisation de OSM-relatify

[Gad Jo]

Effectivement l'outil génère des duplication de donnée d'après mon expérience 
personnelle (je l'utilise activement sur le réseau de mon agglo), ça ressemble 
à un problème synchronisation de donnée effectué à la fois par josm et par 
relatify sur la même zone.

Relatify semble avoir un cache/latence alors que josm arrive à être au plus 
près de la BdD osm.org

Pour limiter la casse les etapes suivante semble fonctionner
- Après un envoi avec JOSM, attendre 2 à 5 min avant de mettre à jour la même 
zone avec relatify
- Après un envoi avec relatify, attendre 30s minimul, mettre jour l'ensemble 
des données en cache et contrôler que les modifications sont présente. Utiliser 
l'outil de validation avant envoi
- Quand disponible, faite rapidement un contrôle avec Osmose avant qu'il y ai 
un gros historique à gérer sur les segments

Il y a de la casse et il faut en avoir conscience, l'outil n'est pas encore 
parfait et devrait être réservé aux contributeurs sérieux qui prennent le temps 
de vérifier le résultat quelques jours ou heures plus tard

Le 24 octobre 2023 05:02:50 UTC, Vincent Bergeot  a écrit :
>Bonjour,
>
>
>
>Le 24 octobre 2023 06:41:50 GMT+02:00, Baptiste Jonglez 
> a écrit :
>>Bonjour,
>>
>>On 19-09-23, Marc_marc wrote:
>>> Bonjour,
>>> 
>>> Le 17.09.23 à 21:43, Baptiste Jonglez a écrit :
>>> > Je ne sais pas comment voir l'état de ces rond-points
>>> > et relations avant la modification
>>> 
>>> le plus simple est overpass avec l'instruction [date:
>>> tu donnes la date avant la modif et tu auras l'état
>>> à ce moment là
>>> 
>>> plus précisement, je vais qlq chose genre :
>>> 
>>> 1) centrer overpass sur la zone en prenant l'id d'un vieil objet
>>> way(id:...);
>>> out geom;
>>> https://overpass-turbo.eu/s/1AH9
>>> exécuter et centrer sur les données, zoomer
>>> 
>>> 2) voir l'état à une date donnée
>>> [date:"2023-06-22T00:00:00Z"];
>>> way[highway]({{bbox}});
>>> out geom;
>>> https://overpass-turbo.eu/s/1AHa
>>
>>Je réponds un peu tard, mais merci du tuyau, je viens de tester et c'est
>>très pratique !  Seul bémol, ça n'a pas l'air de charger les relations de 
>>l'époque.
>
>
>Dans la requête, seul les 'way' sont demandés à la date donnée (way[]), la 
>même chose fonctionne pour une relation, il me semble.
>
>-- 
>Vincent Bergeot
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] RPG 2.0 2019

[Gad Jo]

Ça m'intéresse et je n'ai pas les compétences pour exploiter le jeux de données.

Il y a 6 ans j'ai renseigné les parcelles de culture et naturelle sur l'est de 
l'Aude. Depuis il y a eu énormément de changement, bien plus que les 20 
dernière années (retraite des viticulteurs) et une mise à jour via une source 
fiable serait intéressante

Le 15 décembre 2020 15:53:59 UTC, ades  a écrit :
>Bonjour,
>Le Registre parcellaire graphique (RPG) : contours des parcelles et îlots 
>culturaux et leur groupe de cultures majoritaires 2019 a été récemment publié 
>(cf. : 
>https://geoservices.ign.fr/documentation/diffusion/telechargement-donnees-libres.html#rpg
> 
>),
> c’est une donnée libre.
>
>Il renseigne le type de culture par parcelle, il est issu des déclarations 
>faites par les agriculteurs (obligatoires danbs le cadre de la Pac), donc, a 
>priori, plus précis que des ortho datants de 3 ou 4 ans, plus précis que 
>Corinne, plus précis que les interprétations hasardeuses de l’ortho faites par 
>certain(e)s contribut •eurs•trices.
>
>Dans ma zone de « confort » le cadastre diverge d’environs 2 à 4 pixels par 
>rapport à l’ortho IGN de 2016, donc les parcelle renseignées par le RPG ont 
>une valeur topo correcte (à l’échelle des contrib à OSM, en tous cas plus 
>précise que les tracés a mano à partir des orthos). Dans cette même zone un « 
>imbécile »  a effacé les données Corinnes car "elles devraient être découpée 
>par les routes et ne pas les englober » (je site de mémoire, je n’ai pas envie 
>de recherché plus avant) , je dis imbécile car il n’a pas rempli les trous 
>créés.
>
>Est-ce que l’utilisation du RPG peut être une bonne solution et fait sens ?
>avec comme tags, à préciser  : 
>'landuse : farmland' et 'landcover= *' (en fonction des cultures) et 
>'landcover_date=2019’ et 'landcover source= RPG 2019’ 
>
>Il faut juste faire un regroupement des types de culture du RPG pour 
>correspondre à OSM feature, pas compliqué, faut bien lire et faire une table 
>de correspondances (en cours et à finaliser si ma question fait sens ).
>Question subsidiaire, est-ce que l’utilisation du RPG, sous conditions, 
>pourrait être recommander pour OSM ?
>
>

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Diversity-talk] Etiquette Guidelines bad | Re: Code of conduct

[Jo Walsh]

I continue to stand by the statement that a community CoC is there to protect 
under-represented people, not to enable privileged folks to tone police one 
other. In reverting edits and applying temporary blocks, one must look at 
intention not behaviour. 

Also everyone's on edge now for reasons that go far beyond OSM, fearful for our 
jobs, worried for our friends and families, deprived of our daily distractions 
and outlets, in the depths of midwinter. As appeasing as it may seem, give this 
time. Don't let go of the structural momentum for culture change, but do give 
one another time right now.


zx

-- 
  Jo Walsh
  metaz...@fastmail.net

On Wed, Dec 9, 2020, at 4:33 PM, Rory McCann wrote:
> Have any of yous read the Ettiquette Guidelines¹? They're rubbish.
> 
> Frederik broke them by publically calling Mike Migurski out, and for 
> not assuming he was acting in good faith. *But* if anyone publishes 
> something saying “What Frederik did was wrong” (like I (& others) did), 
> then they are also breaking the Ettiquette Guidelines! That's a 
> horrible outcome!
> 
> ¹ https://wiki.osmfoundation.org/wiki/Etiquette
> 
> On Wed, 9 Dec 2020, at 16:57, Maggie Cawley wrote:
> > I am so happy to see this thread. I believe it will take all of us 
> > coming together and speaking with a unified voice to bring upon the 
> > change we need at the global level. As Clifford mentioned, a few of us 
> > from the LCCWG met on Monday to start talking about next steps. It's 
> > not about one statement, but rather that discussions and comments like 
> > those from this past week affect us all as we work to build diverse 
> > communities around the world.   
> > 
> > Rob, Clifford and I discussed the need for a CoC, but when Rob pointed 
> > out the Etiquette Guidelines exist and are pretty widely accepted it 
> > seems like a logical place to start. It would also enable us to move a 
> > bit more quickly since the document exists and won't need many rounds 
> > of community feedback. What is missing is the process for moderation 
> > and a committee available to moderate any complaints on breaches of 
> > etiquette. It would be helpful to review and suggest edits to the 
> > existing guidelines during this process as well. For the US CoC it took 
> > about 8 months to finalize the CoC and moderation process, and find 
> > volunteers for a committee.
> > 
> > I look forward to growing the conversation. Thanks Heather for starting 
> > this thread here and to all of you who are stepping forward!
> > 
> > Maggie Cawley
> > 
> > 
> > On Tue, 8 Dec 2020 at 21:30, arnalie faye vicario  
> > wrote:
> > > Hello/*Kumusta*,
> > > 
> > > *Salamat*/Thanks everyone for continuing the conversations and taking 
> > > this seriously.
> > > 
> > > It is good to speak up and comment about it in our individual capacities, 
> > > but a collective can build a fire  (charcoal comparison). 
> > > 
> > > This is what we did in OSM PH's Call to Correct Narratives About 
> > > Geospatial Work in the Philippines (re: Amazon-HOT video).  
> > > <https://wiki.openstreetmap.org/w/images/a/aa/A_Call_to_Correct_Narratives_about_Geospatial_Work.pdf>
> > > 
> > > Also, I would like to quote and highlight what David Garcia 
> > > (@mapmakerdavid) has shared in Twitter:
> > >> It is not just the maps that matters. Who *makes* the maps matters. Who 
> > >> *tells* the stories of the mapping matters, too. Who *LEADS* the mapping 
> > >> and storytelling also matters. Who *gets powerful* due to the mapping 
> > >> and storytelling matters most.
> > > 
> > > Thank you Geochicas, Celine @mapeadora, Heather, Rebecca, Miriam 
> > > @mapanauta, Nelson Minar, LCCWG Group, OSMF past/present Board members 
> > > (Kate, Rory and Mikel), HOT Community WG and everyone who expressed 
> > > support and has spoken up (apologies if I missed your name). It is really 
> > > encouraging and inspiring. Please add your thoughts in the document: 
> > > https://docs.google.com/document/d/130JCTX9ve4H4ORXznmIVTpXiN3TX8nRGA8ayuTZ9ECI/edit
> > > 
> > > In case you missed it (like me), here is what Celine sent in the OSM talk 
> > > mailing list: 
> > > https://lists.openstreetmap.org/pipermail/talk/2020-December/085727.html.
> > > 
> > > Let us keep the fire burning!
> > > 
> > > =Arnalie
> > > 
> > > On Wed, Dec 9, 2020 at 5:54 AM Clifford Snow  
> > > wrote:
> > >> I should mention that what we, Maggie Crawely, Rob Nickerson and myse

Re: [Diversity-talk] Code of conduct

[Jo Walsh]

Not sure how to make suggestions directly in the Google Doc or if i want to. 

I appreciate and feel broadly its sentiments but do not feel prepared to sign 
anything which has as a preamble an attack on one person, whatever the trigger. 
It's not equitable, risks entrenching the division. Principles sound but keep 
it about how things should be in a better world, not about how broken they are 
in this one.


zx
-- 
  Jo Walsh
  metaz...@fastmail.net

On Wed, Dec 9, 2020, at 2:29 AM, arnalie faye vicario wrote:
> Hello/*Kumusta*,
> 
> *Salamat*/Thanks everyone for continuing the conversations and taking 
> this seriously.
> 
> It is good to speak up and comment about it in our individual 
> capacities, but a collective can build a fire  (charcoal comparison). 
> 
> This is what we did in OSM PH's Call to Correct Narratives About 
> Geospatial Work in the Philippines (re: Amazon-HOT video).  
> <https://wiki.openstreetmap.org/w/images/a/aa/A_Call_to_Correct_Narratives_about_Geospatial_Work.pdf>
> 
> Also, I would like to quote and highlight what David Garcia 
> (@mapmakerdavid) has shared in Twitter:
> > It is not just the maps that matters. Who *makes* the maps matters. Who 
> > *tells* the stories of the mapping matters, too. Who *LEADS* the mapping 
> > and storytelling also matters. Who *gets powerful* due to the mapping and 
> > storytelling matters most.
> 
> Thank you Geochicas, Celine @mapeadora, Heather, Rebecca, Miriam 
> @mapanauta, Nelson Minar, LCCWG Group, OSMF past/present Board members 
> (Kate, Rory and Mikel), HOT Community WG and everyone who expressed 
> support and has spoken up (apologies if I missed your name). It is 
> really encouraging and inspiring. Please add your thoughts in the 
> document: 
> https://docs.google.com/document/d/130JCTX9ve4H4ORXznmIVTpXiN3TX8nRGA8ayuTZ9ECI/edit
> 
> In case you missed it (like me), here is what Celine sent in the OSM 
> talk mailing list: 
> https://lists.openstreetmap.org/pipermail/talk/2020-December/085727.html.
> 
> Let us keep the fire burning!
> 
> =Arnalie
> 
> On Wed, Dec 9, 2020 at 5:54 AM Clifford Snow  wrote:
> > I should mention that what we, Maggie Crawely, Rob Nickerson and myself, 
> > want to accomplish is to create a committee to moderate the existing 
> > etiquette guidelines and later update the guidelines to reflect best 
> > practices of Code of Conducts.We planned to form a sub committee under the 
> > LCCWG since CoC is critical to Local Chapters. We did a survey of Local 
> > Chapters and those considering forming one. The results showed that 5 LC 
> > already had a CoC, 6 did not and 6 were consider or in a discussion to have 
> > a CoC.
> > 
> > Clifford
> > 
> > On Tue, Dec 8, 2020 at 1:36 PM Heather Leson  wrote:
> >> Always
> >> Heather Leson
> >> heatherle...@gmail.com
> >> Twitter/skype: HeatherLeson 
> >> Blog: textontechs.com
> >> 
> >> 
> >> On Tue, Dec 8, 2020 at 10:31 PM Clifford Snow  
> >> wrote:
> >>> Heather - A small group of the LCCWG met via BigBlueButton yesterday to 
> >>> start a similar initiative. I was going to send an invite to the rest of 
> >>> the LCCWG as well as to this mailing list. Since you have the ball 
> >>> rolling, can you include lo...@osmfoundation.org in the mailing.
> >>> 
> >>> On Tue, Dec 8, 2020 at 1:22 PM Heather Leson  
> >>> wrote:
> >>>> Great. working in the draft now.  
> >>>> 
> >>>> Thank you right back. Saturday is just a way to discuss this restart. We 
> >>>> can keep building. 
> >>>> 
> >>>> Heather 
> >>>> 
> >>>> Heather Leson
> >>>> heatherle...@gmail.com
> >>>> Twitter/skype: HeatherLeson 
> >>>> Blog: textontechs.com
> >>>> 
> >>>> 
> >>>> On Tue, Dec 8, 2020 at 10:10 PM Gertrude Namitala  
> >>>> wrote:
> >>>>> Thanks Heather for starting this. I will try to be available.
> >>>>> 
> >>>>> Kind regards,
> >>>>> Trudy 
> >>>>> 
> >>>>> On Tue, 8 Dec 2020, 23:05 Mikel Maron,  wrote:
> >>>>>> This is great
> >>>>>> 
> >>>>>> * Mikel Maron * +14152835207 @mikel s:mikelmaron
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> On

Re: [OSM-talk-fr] éviter les erreurs de débutant

[Gad Jo]

+1 pour une alerte sans blocage 
OU
Blocage sauf si demande de validation pour les très jeune contributeurs 
(potentiel grosse erreur ou saboteur volontaire)
OU
Mix des deux selon le nombre d'objets modifié depuis l'inscription (le nb 
changeset est imprécis)... Passé un certains nombre c'est open bar

Tout en sachant que les demandes de validation de changeset ne sont pas très 
suivi (perso je n'ai jamais aidé)

Dans tout les cas je préfère faire confiance et ne pas restreindre, avec le 
nombre de contributeur qui augmente peut être qu'un jour ce serai envisageable ?

Le 28 novembre 2020 12:44:15 UTC, Marc_marc  a écrit :
>Bonjour,
>
>Le 28.11.20 à 12:07, Georges Dutreix via Talk-fr a écrit :
>> HotOSM différencie par exemple les cartographes débutants,
>> intermédiaires, expérimentés, et les validateurs. Et certaines tâches
>> sont réservées aux niveaux >= N. Une sécurité de ce style a-t-elle déjà
>> été envisagée sur OSM ?
>
>Oui et non.
>le gestionnaire de tâche Humanitaire est une surcouche sur osm,
>il est donc libre d'implémenter ce qu'il veux en plus, sans que cela
>dépendent de l'api osm
>De même on pourrait imaginer que iD affiche un avertisement objets
>modifiés élevé si l'utilisateur a peu de changeset à son actif.
>josm aussi, mais en même temps c'est écrit sur l'écran "envoyer 10k
>objets modifiés", faudrait-il du rouge clignotant pour que
>l'utilisateur réalise qu'il est entrain de modifier 100x que ce
>qu'il a prévu ? et cela ne fonctionne pas quand l'utilisateur
>a prévu de modifier 10k.
>même à échelle plus modeste, je vois des changeset "ajout d'un commerce"
>avec + d'un objet modifié, et qui ne semble pas interpeller
>l'utilisateur qui valide l'envoi
>
>ceci dit, étonnement josm ne signale pas que les noeuds
>ont le même tag que l'aire
>
>Cordialement,
>Marc
>
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Utilisateur aviné Zeriss, demande de blocage faite

[Gad Jo]

Pou le grand malade...

Tiens nous informé de la suite des événements

Le 27 novembre 2020 05:50:06 UTC, Vincent Bergeot  a écrit 
:
>Bonjour,
>
>cela a été signalé sur @tech et sur le canal telegram-osm-fr mais pas vu 
>passer ici. L'utilisateur Zeriss fait du lourd : 
>https://www.openstreetmap.org/changeset/94791276
>
>En particulier il tague chaque noeud avec crop=grape (raison du sujet de 
>mon mail, je précise au cas où) / 
>https://taginfo.openstreetmap.org/tags/crop=grape#chronology
>
>j'ai signalé pour blocage
>
>à plus
>
>-- 
>Vincent Bergeot
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Suffixe :covid19

[Gad Jo]

C'est envisageable si c'est géré automatiquement via 
opening_hours:before_covid19

En effet ça permet d'alterner les horaires en fonction de la situation de 
chaque pays et en effet seul l'humain sait quand alterner les horaires covid et 
habituelle sur opening_hours

Vu comme cela ça semble gérable

Le 21 novembre 2020 07:33:59 UTC, "Yves P."  a écrit :
>
>> Par ici les horaires covid sont spécifique aux confinement. Généralement 
>> ouvert de 14h à 16h du mardi au samedi. Voir encore plus restrictive
>> Le reste de l'année les horaires sont habituelle.
>
>On est tous d'accord :)
>
>
>> Si la modifications se fait dans un sens qui va faire les relevés le mois 
>> d'après pour contrôler les horaires habituelle ? Autant passer une seule 
>> fois pour ajouter la condition horaire covid. Hors confinement elles ne 
>> doivent plus être prises en compte.
>
>Là encore, on est aussi tous d'accord :)
>
>C'est la question du verre à moitié vide, ou à moitié plein :
>
>1. Une application comme CRO va afficher les horaires en période covid à 
>partir du tag opening_hours:covid19 (comment sait-elle qu'il y a un 
>confinement ??)
>2. Mais les applications non prévues pour ça (la majorité ??) va affiché les 
>horaires "normaux" (tag opening_hours)
>
>Avec la proposition d'Éric, toutes les applications vont afficher les horaires 
>du moment : tag opening_hours :)
>
>Pour répondre à ta remarque, si on note les horaires d'avant confinement dans 
>le tag opening_hours:before_covid19, alors on pourra faire facilement du 
>nettoyage (manuellement ou automatiquement).
>Et ainsi ne passer qu'un seule fois pour ajouter "la condition horaire covid".
>
>
>> De ce côté osmose fait très bien le job en proposant de transformer les 
>> horaires covid en habituelles si elles n'existerait pas (après contrôle sur 
>> place). Autrement la suppression des heures covid est proposé (pas le moment 
>> de les supprimer)
>
>L'analyseur Osmose le fera tout aussi bien en utilisant les clés 
>opening_hours:before_covid19 et opening_hours (plutôt que 
>opening_hours:covid19 et opening_hours)
>
>L'autre alternative est de ne rien changer, et d'espérer que toutes les 
>applications utilisent opening_hours:covid19.
>A-t-on une liste ?
>Exhaustive ??
>
>D'après Taginfo 
> il y a 
>:
> Ça reste ouvert (It stays open) 
> 
> iD Editor 
> AnyFinder - The universal POI finder and locator app 
> 
>
>__
>Yves
>

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Suffixe :covid19

[Gad Jo]

Je ne suis pas d'accord. Par ici les horaires covid sont spécifique aux 
confinement. Généralement ouvert de 14h à 16h du mardi au samedi. Voir encore 
plus restrictive

Le reste de l'année les horaires sont habituelle.

Si la modifications se fait dans un sens qui va faire les relevés le mois 
d'après pour contrôler les horaires habituelle ? Autant passer une seule fois 
pour ajouter la condition horaire covid. Hors confinement elles ne doivent plus 
être prises en compte.
De ce côté osmose fait très bien le job en proposant de transformer les 
horaires covid en habituelles si elles n'existerait pas (après contrôle sur 
place). Autrement la suppression des heures covid est proposé (pas le moment de 
les supprimer)

Le 20 novembre 2020 14:55:18 UTC, "Éric Gillet"  a 
écrit :
>Bonjour,
>
>Le suffixe :covid19 (opening_hours:covid19, delivery:covid19 etc.) a été 
>créé pour le premier confinement, lorsque beaucoup de monde espérait 
>qu'il soit de courte durée et enraye la pandémie.
>La covid19 n'a pas disparu après le premier confinement, mais beaucoup 
>de commerces "non-essentiels" ont rouvert, ou on retrouvé un 
>fonctionnement "classique". D'ici quelques semaines (croisons les 
>doigts), on aura la même situation : déconfinement, peut-être 
>couvre-feu, mais néanmoins covid19 toujours présente.
>
>Ce suffixe ne fait malheureusement pas la distinction entre pandémie et 
>confinement (et couvre-feu etc.), il est donc difficile de connaître son 
>application. De plus, même si l'on dit qu'il ne s'applique que pour le 
>confinement, il est difficile de savoir si les horaires (ou autre) sont 
>revenues à la version pré-confinement, sont restées telle-quelles ou ont 
>été modifiées.
>
>Ne faudrait-il pas de nouveau utiliser les tags sans suffixe :covid19, 
>gérer ces modifications comme des changements classiques ? Que ce soit 
>pour les descriptions, horaires, livraisons, service à emporter etc.
>
>Cela a également l'avantage que ces tags sont affichés et modifiés par 
>la plupart des applications, contrairement aux suffixes :covid19. Cela 
>engendre des contradictions si les contributeurs ou applications ne 
>gèrent pas les deux.
>
>Qu'en pensez-vous ?
>
>Éric
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Données fournies par fichier SIRET

[Gad Jo]

Édit : aurait pris plus de temps pour maintenir la carte à jour

Le 5 novembre 2020 06:04:57 UTC, Gad Jo  a écrit :
>Yes le jeux de données n'est pas forcément tenu à jour par les entrepreneurs.
>
>Ayant trouvé beaucoup d'entreprise ayant fermée, changé légèrement de nom ou 
>ayant leur siège en zone résidentielle j'ai abandonné cette rubrique Osmose.
>Une entreprise pouvant fermer d'un trimestre à l'autre le temps pour maintenir 
>la carte à jour aurait plus important que d'indiquer les infrastructures et 
>équipements urbains. Étant seul il faut être pragmatique
>Autrement ça reste pratique pour les fana intégrant toutes les enseignes (voir 
>le cœur de Montpellier)
>
>Le 29 octobre 2020 11:48:48 UTC, Christian Quest  a 
>écrit :
>>Dans la base SIRENE on a 2 type d'entités:
>>
>>- les unités légales qui décrivent la personne morale (mais aucune adresse)
>>
>>- les établissements... là où il y a une activité, donc localisé (il y a 
>>une adresse)
>>
>>L'un des établissements est le siège, mais ce n'est pas forcément là où 
>>il y a l'activité (dans ce cas il y a au moins un autre établissement, 
>>sauf si l'activité est mobile comme un camion à pizza).
>>
>>A tout ça, s'ajoute parfois l'absence de mise à jour des données, car la 
>>démarche est payante pour les entreprises (ce qui n'aide pas).
>>
>>Le problème pour osmose est de faire le tri entre les établissements où 
>>il y a bien une activité et ceux qui ne sont que le siège... et là pas 
>>de règle miracle malheureusement :(
>>
>>
>>Le 29/10/2020 à 12:02, Frédéric Rodrigo a écrit :
>>> Bonjour,
>>>
>>> Oui c'est un problème fréquent. On a essaye de le limiter avec des 
>>> filtres. On n'a pas gardé les types de professions ou c'est trop 
>>> courant, pour les autre on peut utiliser un filtre sur le nombre 
>>> d’employé minimum.
>>>
>>> https://github.com/osm-fr/osmose-backend/blob/master/merge_data/shop_FR.mapping.json
>>>  
>>>
>>>
>>> Si vous trouvez trop de faux positifs qui peuvent être ajusté suivant 
>>> ses critères ou d'autres, vous pouvez rapporté sur le github.
>>> https://github.com/osm-fr/osmose-backend/issues
>>>
>>>
>>> Frédéric.
>>>
>>>
>>>
>>> Le 29/10/2020 à 11:43, pepilepi...@ovh.fr a écrit :
>>>> Le 29/10/2020 à 11:23, Georges Dutreix via Talk-fr a écrit :
>>>>> Bonjour,
>>>>>
>>>>> Osmose me suggère plein de magasins qui n'existent pas :
>>>>> https://osmose.openstreetmap.fr/fr/map/#zoom=16=48.77059=2.33693=8310=1%2C2%2C3==
>>>>>  
>>>>>
>>>>>
>>>>> Mais je pense qu'Osmose n'est pas en cause. Si je recherche ces 
>>>>> SIRET sur https://annuaire-entreprises.data.gouv.fr/, je les trouve 
>>>>> bien, avec les adresses indiquées par Osmose.
>>>>> Mais autour de chez moi, cela ne correspond absolument à rien de 
>>>>> visible. Ou alors serait-ce juste l'adresse perso (siège social) du 
>>>>> charcutier ou du marchand de fleurs ?
>>>>>
>>>>> Observez-vous la même chose autour de chez vous ? Merci.
>>>>
>>>> Bonjour,
>>>>
>>>> Oui, j'en ai déjà vu dans un quartier résidentiel que je n'avais 
>>>> jamais remarqué en y passant. Faudra juste que j'aille vérifier sur 
>>>> place que rien n'a poussé depuis mon dernier passage.
>>>>
>>>> Bonne journée,
>>>>
>>>> JP
>>>>
>>>>>
>>>>> Georges
>>>>>
>>>>> ___
>>>>> Talk-fr mailing list
>>>>> Talk-fr@openstreetmap.org
>>>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>>
>>>>
>>>> -- 
>>>> 
>>>>
>>>> Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas posé 
>>>> la bonne question.
>>>>
>>>>
>>>> ___
>>>> 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
>>>
>>-- 
>>Christian Quest - OpenStreetMap France
>>
>>
>>___
>>Talk-fr mailing list
>>Talk-fr@openstreetmap.org
>>https://lists.openstreetmap.org/listinfo/talk-fr
>
>-- 
>Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.
-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Données fournies par fichier SIRET

[Gad Jo]

Yes le jeux de données n'est pas forcément tenu à jour par les entrepreneurs.

Ayant trouvé beaucoup d'entreprise ayant fermée, changé légèrement de nom ou 
ayant leur siège en zone résidentielle j'ai abandonné cette rubrique Osmose.
Une entreprise pouvant fermer d'un trimestre à l'autre le temps pour maintenir 
la carte à jour aurait plus important que d'indiquer les infrastructures et 
équipements urbains. Étant seul il faut être pragmatique
Autrement ça reste pratique pour les fana intégrant toutes les enseignes (voir 
le cœur de Montpellier)

Le 29 octobre 2020 11:48:48 UTC, Christian Quest  a 
écrit :
>Dans la base SIRENE on a 2 type d'entités:
>
>- les unités légales qui décrivent la personne morale (mais aucune adresse)
>
>- les établissements... là où il y a une activité, donc localisé (il y a 
>une adresse)
>
>L'un des établissements est le siège, mais ce n'est pas forcément là où 
>il y a l'activité (dans ce cas il y a au moins un autre établissement, 
>sauf si l'activité est mobile comme un camion à pizza).
>
>A tout ça, s'ajoute parfois l'absence de mise à jour des données, car la 
>démarche est payante pour les entreprises (ce qui n'aide pas).
>
>Le problème pour osmose est de faire le tri entre les établissements où 
>il y a bien une activité et ceux qui ne sont que le siège... et là pas 
>de règle miracle malheureusement :(
>
>
>Le 29/10/2020 à 12:02, Frédéric Rodrigo a écrit :
>> Bonjour,
>>
>> Oui c'est un problème fréquent. On a essaye de le limiter avec des 
>> filtres. On n'a pas gardé les types de professions ou c'est trop 
>> courant, pour les autre on peut utiliser un filtre sur le nombre 
>> d’employé minimum.
>>
>> https://github.com/osm-fr/osmose-backend/blob/master/merge_data/shop_FR.mapping.json
>>  
>>
>>
>> Si vous trouvez trop de faux positifs qui peuvent être ajusté suivant 
>> ses critères ou d'autres, vous pouvez rapporté sur le github.
>> https://github.com/osm-fr/osmose-backend/issues
>>
>>
>> Frédéric.
>>
>>
>>
>> Le 29/10/2020 à 11:43, pepilepi...@ovh.fr a écrit :
>>> Le 29/10/2020 à 11:23, Georges Dutreix via Talk-fr a écrit :
 Bonjour,

 Osmose me suggère plein de magasins qui n'existent pas :
 https://osmose.openstreetmap.fr/fr/map/#zoom=16=48.77059=2.33693=8310=1%2C2%2C3==
  


 Mais je pense qu'Osmose n'est pas en cause. Si je recherche ces 
 SIRET sur https://annuaire-entreprises.data.gouv.fr/, je les trouve 
 bien, avec les adresses indiquées par Osmose.
 Mais autour de chez moi, cela ne correspond absolument à rien de 
 visible. Ou alors serait-ce juste l'adresse perso (siège social) du 
 charcutier ou du marchand de fleurs ?

 Observez-vous la même chose autour de chez vous ? Merci.
>>>
>>> Bonjour,
>>>
>>> Oui, j'en ai déjà vu dans un quartier résidentiel que je n'avais 
>>> jamais remarqué en y passant. Faudra juste que j'aille vérifier sur 
>>> place que rien n'a poussé depuis mon dernier passage.
>>>
>>> Bonne journée,
>>>
>>> JP
>>>

 Georges

 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>> -- 
>>> 
>>>
>>> Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas posé 
>>> la bonne question.
>>>
>>>
>>> ___
>>> 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
>>
>-- 
>Christian Quest - OpenStreetMap France
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Carto-Cité - imprimer une carte

[Gad Jo]

Super... C'est l'occasion de réviser depuis le début et de revoir sa façon de 
concevoir ses requettes overpass

Le 4 novembre 2020 17:19:49 UTC, Antoine Riche via Talk-fr 
 a écrit :
>Par contre vous pouvez retrouver sur ce wiki les tutos Overpass publiés 
>sur Twitter lors du 1er : confinement : 
>https://wiki.cartocite.fr/doku.php?id=tutoverpass:tutoriel_overpass_api
>
>Le 04/11/2020 à 18:04, Antoine Riche via Talk-fr a écrit :
>>
>> Oh là là j'ai du ménage à faire : ce genre de contenu est plutôt mes 
>> notes et n'a pas vocation a servir de référence...
>>
>> Antoine.
>>
>> Le 03/11/2020 à 08:41, Cyrille37 OSM via Talk-fr a écrit :
>>> Bonjour
>>>
>>> Sur le wiki de Carto-Cité il y a qlqs outils référencés pour imprimer 
>>> une carte 
>>> https://wiki.cartocite.fr/doku.php?id=openstreetmap:introduction:imprimer_une_carte
>>>
>>> @CartoCité: vous pourriez y ajouter le site osm.org qui avec l'outil 
>>> "partager" permet l'export d'une zone en SVG ou PDF. Je viens de 
>>> générer 2 exemples (Indre-et-Loire et Tours Métropole) là : 
>>> https://www.grosfichiers.com/FMYHhEMPRqF
>>> Ainsi que le lien vers votre tuto 
>>> https://cartocite.fr/tutoriels-openstreetmap/
>>>
>>> Belle journée à tou·te·s
>>> Cyrille37.
>>>
>>>
>>> ___
>>> 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

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-transit] Tagging a public transport route which uses buses and trams simultaneously

[Jo]

If the itineraries between the stops are all the same, I would probably map
it as

route=tram

and consider the buses replacement service.

Why do they do that? Are there too few tram vehicles? Not enough tram
wattman? Are the trams too big/costly at some hours of the day?

Polyglot

On Mon, Oct 19, 2020 at 5:59 PM Michael Tsang  wrote:

> Dear all,
>
> How should I tag a public transport route which is simultaneously a bus
> and a
> tram route? It is operated using both trams (on street-running railway)
> and
> buses on the same way with the same platforms, using the same number.
>
> Regards,
> Michael
> --
> Sent from KMail___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [OSM-talk-be] error for revert a changeset

[Jo]

Hi, have a look at the relations referencing the way in the relation
editor. One of the members will seem 'translucent'. Remove it from the
relation, as it's pointing to the way that doesn't exist anymore.


Polyglot

On Thu, Oct 15, 2020 at 11:53 PM DJ_frombelgium 
wrote:

> Hi
>
> DJ_frombelgium, a mapper in wallonia (big building contributor)
>
> I write because i need some help for a changeset that a could revert on
> josm
>
> I explain.
> In Namur a roundabout (Boulevard Cauchy) have change and now it's not a
> roundabout, way have change a lot (with traffic signals, revert of road
> direction and other)
> The community has change the map very quickly, but now i see a a part of
> the changeset  91713233  has erase everything and redraw the map wit the
> sat image...
>
> https://www.openstreetmap.org/changeset/91713233#map=19/50.46860/4.86838
>
> Before the changeset  (image of my backup of 01/04/2020)
> https://www.zupimages.net/viewer.php?id=20/42/fqfm.png
>
> After the changeset
> https://www.zupimages.net/viewer.php?id=20/42/7e3l.png
>
> It's too much work for redraw for me (because i never use "member"
> relation, and i dont want do a mistake)
>
> So i've try a revert in Josm with the plugin.
>
> i download the map, select way that i would revert, -> "revert selection
> and restore deleted object"
> That ok, but when i try to upload the changeset i've somes conflict that
> i couldn't resolve...
>
> (i have the error in french but i "translate")
>   "error for delete way 852742595, there a reference for relation
> 114261. 2314735 . 11686987
>
> and i cant find this way, and josm conflict said nothing...
>
> Thats probably very basic but not for me.
>
> Help are appreciated
>
>
> Thanks
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-transit] Talk-transit Digest, Vol 104, Issue 1

[Jo]

Number of seats may work. But it would have to be a ballpark figure. Over
here in Belgium, the same line uses bendy and normal buses depending on the
hour of the day, or on what they have available at that specific time.

On Wed, Oct 14, 2020, 14:09 Tony Shield  wrote:

> Hi Alex
>
> Michael Tsang asked a very similar question  about minibus routes a few
> days ago.
>
> My view is that a minibus as just that - a small bus differentiated by the
> number of seats. From that I take the view that perhaps we should be noting
> the number of seats/places available on a bus service - e.g some double
> deckers have 80 seats, single deckers 15-60, bendy-buses - approx 140.
>
> Using seats metric could also be applied to other transport formats - so a
> Settle-Carlisle class 156 2 car train set has approx 150 seats, a class 800
> 9 car train set has 611 seats; Sydney ferries have capacities between 400
> and 1150.
>
> So service capacity may be a better metric.
>
> Tony Shield
>
> TonyS999
> *I'm looking for community consensus about minibus routes (public
> transport routes which are operated by light passenger vehicles of roughly
> 8 to 20 seats with no standing allowed in general). As of present, there
> are two kinds of tagging for minibus routes:*
>
> * A. route=minibus (~30 routes around the world)*
> * B. route=bus & bus=minibus (~300 routes around the world)*
>
> * None of the tags seem to have widespread usage.*
>
> * Currently I can't see any renderer support for both tagging. For option
> A, no renderer shows them at all. For option B, they are shown as regular
> bus routes.*
>
> * Moreover, I can think of different regulatory scenarios, which may match
> the different usage:*
>
> * X. The minibus services are regulated as a separate class of service to
> full-sized bus routes, with different operators, network and fare
> structures, which may even with numbers overlapping (e.g. a minibus route
> 25 and another full sized bus route 25 serving the same area)*
>
> * Y. The minibus services form a part of the bus network but with distinct
> identities (e.g. a range of numbers reserved for minibus routes and another
> range for full sized bus routes, with different fare scales but still in
> the integrated ticket structure)*
>
> * Z. There are no distinction in the branding between bus and minibus
> services, the vehicle used mainly depend on the environment.*
>
> * Tagging A will match scenario X and tagging B will match scenario Z,
> with scenario Y in between in my thinking.*
>
> * I'm looking for input how other people map their minibus routes, and how
> are their routes regulated.*
>
>
> On 13/10/2020 12:27, Alex Dhawan wrote:
>
> Hi all,
>
>
>
> Never actually sent a message to this list, hopefully this works.
>
>
>
> We’ve got a number of minibus routes around the Yorkshire Dales here in
> Northern England. Currently the ones that appear in OSM are just tagged as
> route=bus – with nothing distinguishing them from full size standard buses.
>
>
>
> Personally of your options I’d be tempted to go with B – at least here
> they are treated as bus routes in most ways, just happen to be minibuses.
> They do mostly have different branding, but in most cases are intregrated
> fare and ticket wise, and in some cases to overlap with standard bus
> routes, but do have different numbers, although there is not a set “range”
> so unless you know in advance you couldn’t tell from just the number. At
> least from my local experience they are close enough to standard bus routes
> for most purposes.
>
>
>
> That said to give one example – precovid I used to take groups walking or
> caving, and we often went on the buses and usually made a specific point of
> avoiding the minibus routes. We’d take out all the seats if we turned up.
> In the PDF timetables it will be marked if a route is a minibus, but not on
> journey planners/Google maps.
>
>
>
> Skifans
>
>
>
>
>
>
>
> *From: *talk-transit-requ...@openstreetmap.org
> *Sent: *13 October 2020 12:09
> *To: *talk-transit@openstreetmap.org
> *Subject: *Talk-transit Digest, Vol 104, Issue 1
>
>
>
> S
>
>
>
> ___
> Talk-transit mailing 
> listTalk-transit@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-transit
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [OSM-talk-fr] Etiqueter des routes selon le nom du lieu-dit

[Gad Jo]

Si c'est sur le cadastre et que la ref est conservée c'est OK... Si c'est 
affiché sur un panonceau sans être dans le cadastre il faut penser à 
l'expliquer en note=* pour les autres contributeurs

Autrement il y a confusion entre le nom de la voie et la destination de la 
voie. Si il y a correction il faut l'indiquer cette fois dans comment=* pour 
détailler l'objectif de la modification pour les autres contributeurs afin 
d'éviter un trolltag

À l'extrême tu peut utiliser description=* si tu veut communiquer à destination 
des usagers utilisant ces voies. Là c'est vraiment pousser mémé dans les orties 
(pourtant ça fait du bien aux rhumatismes)

Le October 13, 2020 8:09:44 PM UTC, Jacques  a écrit :
>Bonsoir,
>
>Etiqueter des routes selon le nom du lieu-dit : Je vois de plus en plus
>
>de chemins vicinaux prendre le nom du lieu-dit qu'ils traversent. Ainsi
>
>vc12 devient « La Berge du Ravin » Ceci me semble pas judicieux. Y'a 
>t-il une discussion sur le sujet ?
>
>Jacques
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-es] Herramienta para rellenar el campo wikipedia*

[Jo]

La ventaja del tag Wikidata es que normalmente ya no es tan necesario
agregar el tag Wikipedia. Si alguien quiere más información, siga a la
página wikidata y ahí puede ver en cuales idiomas hay páginas de Wikipedia.
Además hay más objetos Wikidata que páginas WP, WD puede ser más específico
y de esa manera más adecuado desde OSM.

Polyglot

On Tue, Oct 13, 2020 at 5:48 PM Xavier Barnada  wrote:

> Hola lista,
>
> Hace unos días me di cuenta de que hay elementos en OSM que tienen el
> campo wikidata pero no el campo wikipedia*. Creo que esta información se
> podría rellenar de forma automatizada usando la API de wikidata.
>
> La idea sería crear un pequeño script en python para que cualquiera
> pudiera de forma automatizada corregir estos datos en su zona.
>
>
> El flujo sería el siguiente:
> 1- Mediante overpass obtener todos los elementos que tienen el tag
> wikidata i no tienen wikipedia https://overpass-turbo.eu/s/YZ3
> 2- Consultar el valor de wikidata mediante la API de OSM
> https://www.openstreetmap.org/way/696120060
> 3- Aceder a la api de Wikidata y leer el campo del link a la wikipedia
> https://www.wikidata.org/wiki/Special:EntityData/Q18003374.json
> 4- Editar los datos de OSM para añadir todos los posibles valores por
> ejemplo wikidata:ca,wikidata:es.
>
> Mis dudas son las siguientes:
> - ¿Esto se considera una importación? A mi parecer no lo es.
> - ¿Se tiene que reportar a algún sitio esta herramienta de edición
> automatizada? He revisado
> https://wiki.openstreetmap.org/wiki/ES:Ediciones_automatizadas y solo
> indica que se debe registrar aqui
> https://wiki.openstreetmap.org/wiki/Category:Automated_edits_log
>
> Si hay alguna duda o sugerencia será bienvenida
>
> Saludos
> Xavier Barnada
>
>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk-fr] Besoin d'aide pour référence d'un ligne TGV

[Gad Jo]

Merci Philippe pour les explications mais même en augmentant à 4 go je n'ai pas 
obtenu de résultat.

Comme tu a l'air de t'y connaître, peut tu faire un essais en sélectionnant 
tous les éléments de la relations pour trouver la longueur cumulée des segments 
?
Peut être qu'il faut affiner la configuration java ou josm ? Si tu peut faire 
un essai et nous en dire plus sur ta tentative de trouver la longueur total de 
la voie ferrée. Ce serait top.

Cordialement

Le October 13, 2020 12:31:43 AM UTC, Philippe Verdy  a écrit :
>2Go est parfois très juste si on travaille à l'échelle de la France.
>Perso
>j'ai mis une limite de VM à 4Go (dans le panneau de config Java; aucun
>problème car Java ne sert qu'à des applis locales et pas dans un
>navigateur, donc toujours lancé par une ligne de commande "java" ou un
>fichier .jnlp lancé via JavaWebStart, qui télécharge ou met à jour
>l'appli
>dans le cache local de déploiement, puis lance l'appli de façon
>autonome;
>JavaWebStart est mal nommé, en fait il n'a de web que le lancement et
>le
>fait qu'un fichier .jnlp est un tout petit fichier qui contient une ou
>plusieurs URLs pour la mise à jour du cache, et les autres paramètres
>de
>config de la VM qui pourraient être imposés, ainsi que les
>bibliothèques
>binaires nécessaires qui devraient être dans les "/lib" et les packages
>dépendants qui peuvent être eux aussi installés dans le CLASSPATH).
>Par défaut, même en 64 bits, la limite ne dépasse pas 2,5Go.
>Note qu'avec JavaWebStart on n'installe l'appli JOSM que temporairement
>dans le cache de déploiement, certains outils "nettoyeurs" veulent
>vider ce
>cache, mais on perd des infos comme les préférences utilisateur qui
>sont
>aussi dans ce cache, qui agit plutôt comme un container. En revanche
>cela
>ne nettoie pas le cache JOSM des tuiles qui est stocké à part dans le
>système de fichiers local de l'utilisateur et qui peut devenir très
>grand;
>mais heureusement pour limiter la fragmentation de nomlbreux fichiers,
>maintenant JOSM gère son cache de tuile avec un gros fichier "blob"
>unique
>par couche, ce qui va beaucoup plus vite, mais ce gros bloc peut aussi
>se
>fragmenter dans sa structure interne, bien qu'il est plus efficace que
>ce
>que fait le système de fichiers lui-même, et il y staocke les tuiles et
>les
>métadonnées HTTPS de façon plus ordonnée et plus compacte en ne gardant
>que
>les métadonnées utiles et pas tout le "bazar" des entêtes MIME d'HTTP
>ou
>HTTPS.
>
>Le lun. 12 oct. 2020 à 16:56, Percherie OnDaNet
>
>a écrit :
>
>> Étrange... je suis sur une machine windows avec 2Go de défini pour
>Java.
>>
>> Voici la capture écran de ce qui ne fonctionne pas (avec info bulle
>et
>> tout et tout) : https://ibb.co/6bztCmX
>>
>> A la maison je travaille exclusivement sur Mint, je referai une
>tentative
>>
>> Le 12/10/2020 à 16:40, osm.sanspourr...@spamgourmet.com a écrit :
>> > Merci pour la mise à jour.
>> >
>> > Aucun problème pour charger la relation.
>> >
>> > J'ai copié https://osm.org/relation/11741864
>> >
>> > et utilisé la fonction "Télécharger un objet...".
>> >
>> > Linux Mint 20, JOSM canal stable.
>> >
>> > Tu utilises une machine virtuelle 32 bits ?
>> >
>> > Si le chargement est partiel tu peux demander de charger les
>membres.
>> >
>> > Et non Lyon-Toulouse ne fait pas moins de 200 km vu d'ici.
>> >
>> > Jean-Yvon
>> >
>> > Le 12/10/2020 à 16:20, Percherie OnDaNet -
>perche...@toutenkamion.net a
>> > écrit :
>> >
>> >
>> >
>> > ___
>> > 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
>>

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Besoin d'aide pour référence d'un ligne TGV

[Gad Jo]

Ah ! Ça doit être ce qu'à fait https://www.fiches-horaires.net/

Dessus on peut y consulter tous les départ par gare. Les références de train, 
jours de circulations et horaires y sont. Ça donne presque envi de les saisirs 
sur les relations... Mais quid du maintient des infos ? Je préfère m'abstenir 
d'ouvrir un chantier sans fin.

Merci Helfer pour le retour

Le October 11, 2020 9:32:41 AM UTC, Denis Helfer  a écrit :
>Les horaires des TGV et des TER sont disponibles en opendata au format
>GTFS
>
>https://ressources.data.sncf.com/explore/dataset/horaires-des-train-voyages-tgvinouiouigo/table/
>
>https://ressources.data.sncf.com/explore/dataset/sncf-ter-gtfs/table/
>
>yapuka décoder...
>
>
>Le 11/10/2020 à 10:14, Julien djakk a écrit :
>> Salut !
>>
>> On a le droit de copier les fiches horaires de la SNCF ?
>>
>> Julien "djakk"
>>
>> Le dim. 11 oct. 2020 à 01:39, Gad.Jo  a
>écrit :
>>> La modification a été bien plus simple et rapide que prévu :
>>> https://www.openstreetmap.org/changeset/92288895
>>>
>>> J'ai remis à jour les relations qui y ressemblait le plus vers les
>>> nouveau numéro de ligne actuellement active sur le site de la SNCF.
>>> Normalement il n'y a pas de casse sur les gares où je suis passé
>(ajout
>>> de tag, mise en conformité)...
>>>
>>> L'ancienne ligne TGV 752 a été remplacée par les lignes TGV 6871,
>6873,
>>> 6823, 9836 et 9862
>>>
>>> En dehors de la gare Lille Europe où un trou persiste dans les
>relations
>>> (pas chaud pour modifier une grosse gare). Tout les trajets sont
>continu.
>>>
>>> Le 10/10/2020 à 21:42, Gad.Jo a écrit :
 Après une courte recherche j'ai trouvé le très bon site :
 https://www.fiches-horaires.net/ (leur description en pied de page
>est
 très amusante et pleine de bon sens)

 A défaut de trouver les fiches horaires officielle il y a de la
 données valide. Par contre... où on t'ils trouvé leur données ?

 Le 10/10/2020 à 16:40, Adrian via Talk-fr a écrit :
> Il y a deux ans environ, je voulais couper des chemins (ways) de
> chemin de fer pour introduire des ponts. Ces chemins étaient
>membres
> de plus que dix relations d'itinéraire. Comme toi, j'ai vu qu'il y
> avait deux genres de relation. Il y avait les itinéraires
> d'infrastructure, comme la ligne de Combs-la-Ville à Saint-Louis.
>Et
> il y avait les itinéraires passagers, les voyages sans
>correspondance
> proposés par la SNCF, comme le TGV 752. J'ai remarqué que les
> itinéraires passagers reflétaient l'état d'il y a cinq ans ou
>plus.
>
> Les relations étaient un vrai désordre. Toutes étaient cassées à
> multiples endroits avec des types diverses d'erreur. Quelques-unes
> étaient très longues avec jusqu'à trois mille membres. Le format
>de
> toutes les relations est un hybride de v1 et v2 des transports en
> commun. Il y a une liste des gares, et une liste des chemins dans
>les
> deux sens (sauf voie unique), sans les rôles forward ou backward.
>Les
> listes des chemins comprennent des blocs alternés de chemins dans
>le
> sens aller et chemins dans le sens retour. Les relations
> d'infrastructure contiennent souvent toutes les voies des gares, y
> compris les voies de garage et d'évitement. Les relations
>passagers
> contiennent souvent toutes les voies par lesquelles les trains
> pourraient passer par les gares. Je pense que les relations ont
>été
> créées ainsi par des enthousiastes des chemins de fer. Mais je
>n'ai
> pas cherché qui, ou pourquoi, ou si c'est documenté quelque part.
>
> J'ai passé des heures à faire une réparation partielle des
> plus-que-dix relations, sans changer le format. Une réparation
> entière aurait fallu beaucoup trop longtemps. Ainsi j'ai pu
> introduire les ponts sans empirer le bordel.
>
> À mon avis, un tel cas a besoin d'une méthode différente de
> cartographier les itinéraires. Les relations d'itinéraire
>devraient
> avoir comme membres, d'autres relations: des tronçons
>d'itinéraire.
> Ça pourrait être fait avec ou sans des relations superroute. On
> arriverait à une grande simplification.
>
> Et alors, que faire? Mettre en bonne état et à jour seulement les
> relations qui passent par ton coin, est un très grand boulot. Et
>en
> idéal, il faudrait discuter avec ceux qui cartographient les
>chemins
> de fer, quel est le format préféré des relations. Les relations
>sont
> utilisées par https://www.openrailwaymap.org/ et
> https://magosm.magellium.com/portail/#/carte p.ex. Supprimer des
> relations serait dommage, vu le temps que plusieurs contributeurs
>ont
> passé à les créer. À mon avis, il faudrait améliorer ou mettre à
> jour; ou bien laisser tel quel.
>
> À noter qu'il y a toujours des liaisons directes Lyon - Barcelone.
> Mais pas Lyon - Bordeaux, ça va plus vite maintenant via Paris que
> via Montpellier!
>
> Un projet du 

Re: [OSM-talk-fr] Besoin d'aide pour référence d'un ligne TGV

[Gad Jo]

Merci pour ce retour d'expérience j'en suis au même point.

Ça m'embête de supprimer une grosse relation sans étudier tous les impacts. Je 
vais regarde comment les deux sites que tu partage utilisent ces relations.

Pour bien faire il me faudrait les fiches horaires des lignes SNCF en cours 
d'utilisations. Après avoir passer plus d'un an à finaliser le réseau de 
transport en commun de mon agglo j'ai acquis quelques méthodes de travail qui 
me permettent de monter des relations cohérente... Reste à trouver des 
documents sur lequel m'appuyer

Est-ce qu'une personne auraient une idée où trouver les fiches horaires des 
lignes ?

Le October 10, 2020 2:40:17 PM UTC, Adrian via Talk-fr 
 a écrit :
>Il y a deux ans environ, je voulais couper des chemins (ways) de chemin
>de fer pour introduire des ponts. Ces chemins étaient membres de plus
>que dix relations d'itinéraire. Comme toi, j'ai vu qu'il y avait deux
>genres de relation. Il y avait les itinéraires d'infrastructure, comme
>la ligne de Combs-la-Ville à Saint-Louis. Et il y avait les itinéraires
>passagers, les voyages sans correspondance proposés par la SNCF, comme
>le TGV 752. J'ai remarqué que les itinéraires passagers reflétaient
>l'état d'il y a cinq ans ou plus.
>
>Les relations étaient un vrai désordre. Toutes étaient cassées à
>multiples endroits avec des types diverses d'erreur. Quelques-unes
>étaient très longues avec jusqu'à trois mille membres. Le format de
>toutes les relations est un hybride de v1 et v2 des transports en
>commun. Il y a une liste des gares, et une liste des chemins dans les
>deux sens (sauf voie unique), sans les rôles forward ou backward. Les
>listes des chemins comprennent des blocs alternés de chemins dans le
>sens aller et chemins dans le sens retour. Les relations
>d'infrastructure contiennent souvent toutes les voies des gares, y
>compris les voies de garage et d'évitement. Les relations passagers
>contiennent souvent toutes les voies par lesquelles les trains
>pourraient passer par les gares. Je pense que les relations ont été
>créées ainsi par des enthousiastes des chemins de fer. Mais je n'ai pas
>cherché qui, ou pourquoi, ou si c'est documenté quelque part.
>
>J'ai passé des heures à faire une réparation partielle des plus-que-dix
>relations, sans changer le format. Une réparation entière aurait fallu
>beaucoup trop longtemps. Ainsi j'ai pu introduire les ponts sans
>empirer le bordel.
>
>À mon avis, un tel cas a besoin d'une méthode différente de
>cartographier les itinéraires. Les relations d'itinéraire devraient
>avoir comme membres, d'autres relations: des tronçons d'itinéraire. Ça
>pourrait être fait avec ou sans des relations superroute. On arriverait
>à une grande simplification.
>
>Et alors, que faire? Mettre en bonne état et à jour seulement les
>relations qui passent par ton coin, est un très grand boulot. Et en
>idéal, il faudrait discuter avec ceux qui cartographient les chemins de
>fer, quel est le format préféré des relations. Les relations sont
>utilisées par https://www.openrailwaymap.org/ et
>https://magosm.magellium.com/portail/#/carte p.ex. Supprimer des
>relations serait dommage, vu le temps que plusieurs contributeurs ont
>passé à les créer. À mon avis, il faudrait améliorer ou mettre à jour;
>ou bien laisser tel quel.
>
>À noter qu'il y a toujours des liaisons directes Lyon - Barcelone. Mais
>pas Lyon - Bordeaux, ça va plus vite maintenant via Paris que via
>Montpellier!
>
>Un projet du mois, peut-être? Mais je me demande s'il y aurait assez de
>contributeurs intéressés. Et comment découvrir la gamme des itinéraires
>passagers, vu qu'il n'y a plus de fiches horaires TGV disponibles en
>ligne?
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-be] Request to change the cycle highway network tag

[Jo]

Hi Wannes and Frank,

I think that is about the numbered node network. That's a different network
from the cycle_highway network. We tag that one at the rcn level. Of course
it's odd if the node numbers differ between 2 renderings.

Jo

On Wed, Oct 7, 2020 at 12:43 PM Frank Vdm  wrote:

> I see difference in node numbers, view arrond st Vith.
> https://cycling.waymarkedtrails.org/#?map=14!50.2864!6.1335
> https://www.ostbelgien.eu/nl/fiets/fietsrouteplaner
>
> Op wo 7 okt. 2020 om 11:29 schreef Wannes Soenen :
>
>>
>>
>> Op 7 okt. 2020, om 10:40 heeft Jo  het volgende
>> geschreven:
>>
>> In Wallonia they don't have cycle highways yet, but they have had RaVeL
>> for longer than we do in Flanders. OK, it's not a network yet, but that can
>> change.
>>
>>
>> https://www.ostbelgien.eu/nl/fiets/fietsrouteplaner
>>
>> Eastbelgium (German speaking part of Wallonia) has a cycle network with
>> numbers and signposts. It contains the Vennbahn (which is part of the RaVel)
>> (Also a walking network at
>> https://www.ostbelgien.eu/nl/wandelen/wandelrouteplaner )
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Request to change the cycle highway network tag

[Jo]

I don't have big issues with prepending a prefix. Having said that, if the
issue is that they are signposted differently in each country, here in
Belgium they are likely to become signposted differently depending on the
region.

The way I understood it, in Flanders it's Fxyz. In Brussels it would be
Cxyz, where xyz would be the same number as in Flanders, for example, F3
would continue as C3, F203 as C203. Anyway, that was the plan about a year
ago, not sure if it's still the case. Actually F203 already continues to
Diamant, but according to that logic it should become C203 west of Tollaan.
It runs parallel to the E40 highway for the last stretch. Last time I went
there, nothing was signposted, but ofc, I went a little too early. It was
not quite finished.

In Wallonia they don't have cycle highways yet, but they have had RaVeL for
longer than we do in Flanders. OK, it's not a network yet, but that can
change.

Will cycle_network=BE:cycle_highway be sufficient, or do we need to
subdivide it further for the regions? Even though the signposting might be
different between Flanders and Brussels, the plan is still to have 2
networks that interconnect seamlessly.

Jo



On Wed, Oct 7, 2020 at 9:53 AM s8evq  wrote:

>  I think the arguments of Minh Nguyễn are valid.  It wouldn't be a big
> deal to change cycle_network=cycle_highway to
> cycle_network=BE:cycle_highway for example (or to
> cycle_network=BE:fietssnelweg). I would additionally also add
> cycle_highway=yes.
>
> On Tue, 6 Oct 2020 20:53:06 +0200, Pieter Vander Vennet <
> pieterv...@posteo.net> wrote:
>
> > Hello everyone,
> >
> > Minh NGuyen had the following remark on the wiki
> > <
> https://wiki.openstreetmap.org/wiki/Talk:Tag:cycle_network%3Dcycle_highway
> >
> > about the current tagging scheme of the cycle highways.
> >
> > Anyone any thought on it?
> >
> >
> > Incompatible with cycle_network
> >
> > This tag is incompatible with the predominant usage of cycle_network
> > <https://wiki.openstreetmap.org/wiki/Key:cycle_network>=*. This key was
> > originally intended to identify a specific network with uniform
> > signage – a renderer was supposed to be able to choose a shield based on
> > a combination of cycle_network
> > <https://wiki.openstreetmap.org/wiki/Key:cycle_network>=* and ref
> > <https://wiki.openstreetmap.org/wiki/Key:ref>=*. But it appears that
> > cycle highways are signposted and numbered differently in each country,
> > so there's no such cycle network as "cycle highway":
> >
> >   *
> > <
> https://wiki.openstreetmap.org/wiki/File:F7_teller_-_Gent_-_Kortrijk_-_ter_hoogte_van_station_Deinze.jpg
> >
> >
> > Belgium
> >
> >   *
> > <https://wiki.openstreetmap.org/wiki/File:2019Radschnellweg.jpg>
> >
> > Germany
> >
> >   *
> > <
> https://wiki.openstreetmap.org/wiki/File:Fietssnelweg_F35_at_Go_Planet.jpg
> >
> >
> > Netherlands
> >
> > A renderer would have to perform a spatial query to reliably display the
> > correct shield for each of these routes, somewhat undermining the push
> > to have renderers use route relations instead of ref
> > <https://wiki.openstreetmap.org/wiki/Key:ref>=* tags on ways.
> >
> > We already made this mistake once by repurposing the network
> > <https://wiki.openstreetmap.org/wiki/Key:network>=lcn/rcn/ncn tags for
> > routes outside the United Kingdom, leading to the otherwise redundant
> > key cycle_network
> > <https://wiki.openstreetmap.org/wiki/Key:cycle_network>=* as a
> > workaround. Let's avoid making this mistake again by deprecating
> > cycle_network
> > <https://wiki.openstreetmap.org/wiki/Key:cycle_network>=cycle_highway
> > <https://wiki.openstreetmap.org/wiki/Tag:cycle_network%3Dcycle_highway>
> > in favor of country-prefixed values like cycle_network
> > <https://wiki.openstreetmap.org/wiki/Key:cycle_network>=NL:cycle_highway
> > <
> https://wiki.openstreetmap.org/w/index.php?title=Tag:cycle_network%3DNL:cycle_highway=edit=1
> >,
> > or by choosing a different key altogether like cycle_highway
> > <
> https://wiki.openstreetmap.org/w/index.php?title=Key:cycle_highway=edit=1
> >=yes.
> >
> >
> > – Minh Nguyễn <https://wiki.openstreetmap.org/wiki/User:Minh_Nguyen> ^
> > <https://wiki.openstreetmap.org/wiki/User_talk:Minh_Nguyen> 00:51, 5
> > October 2020 (UTC)
> >
> > --
> > Met vriendelijke groeten,
> > Pieter Vander Vennet
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be
>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

[Gad Jo]

En effet c'est aux logiciels de s'adapter. Je vais remonter l'information vers 
Osmand.

En vue d'améliorer Osmose, petit exemple pratique sur 
https://www.openstreetmap.org/node/363708793

J'ai l'impression que le name est nécessaire. Est-ce que exit_to est nécessaire 
? Au passage le tag destination est manquant sur le way alors que exit_to 
existe. Est-ce qu'un contrôle Osmose serai intéressant ?

Le October 1, 2020 11:02:31 AM UTC, osm.sanspourr...@spamgourmet.com a écrit :
>+0,5 ;-)
>
>Normalement l'ordre ce sont les plus proches en haut et par couleur
>(bleu : liaison autoroutière, verte : ville importante - en général via
>départementale ou nationale, blanc : autre).
>
>Pour l'importance, il y a la couleur des panneaux (non documentée ici)
>mais on a les attributs population= ou capital= pour trouver les plus
>importants.
>
>S'il y a 5-10 destinations, on n'a pas forcément le temps de lire non
>plus ;-), on va survoler en cherchant la destination finale ou une
>étape
>importante. Bref on fait ce qu'Adrien suggère que les routeurs fassent.
>Un peu plus subtil effectivement.
>
>Et comme dit Christian si on annonce le premier de la liste c'est le
>plus simple et le plus efficace.
>
>Merci à Adrien pour les mises-à-jour logicielles.
>
>Jean-Yvon
>
>Le 01/10/2020 à 09:04, PanierAvide - panierav...@riseup.net a écrit :
>>
>> Bonjour,
>>
>> +1, il ne faut pas se limiter dans la liste des destinations pour
>> compenser le souci de synthèse vocale ;-) D'autant que niveau
>logiciel
>> c'est assez facile de ne conserver que les 3 premières destinations.
>> On pourrait imaginer que le routeur choisisse les noms selon
>l'endroit
>> où l'on se rend, ou selon l'importance des lieux nommés, mais là ça
>> devient déjà plus subtil niveau code.
>>
>> Cordialement,
>>
>> Adrien P.
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Écoles maternelles -> amenity=school et school:FR=maternelle / et primaire-élémentaire-maternelle / était [Re: Osmose - Demande d'aide pour les écoles en France]

[Gad Jo]

Au vu du contenu de wikipedia, peut être qu'il faudrait reprendre ou affiner la 
définition officielle de amenity=kindergarten ? Et aux contributeurs de chaque 
pays d'affiner la définition en fonction de leur système scolaire ?

Le October 2, 2020 1:19:43 AM UTC, "Jérôme Amagat"  a 
écrit :
>> Vincent, tu me fais prendre conscience du fait que des changements
>> importants sur le wiki en français peuvent opérer par un seul
>contributeur
>> sans aucun mandat moral de la communauté francophone.
>> Où on s’aperçoit que les Belges, les Canadiens et les Suisses ne sont
>> guère intéressés par ce qui y est écrit.
>>  Rappel : les pages FR: du wiki ne conernent pas que la République
>> française.
>>
>> Oui peu de contributeur sur le wiki fr (et je pense sur toutes les
>langues) donc une modification peut prendre une grande ampleur.
>Mais ici le sujet des maternelles a été plusieurs fois abordé sur cette
>liste et à chaque fois, il me semble, la discussion va vers le fait que
>amenity=kindergarten n'est pas adapter aux écoles maternelles
>françaises et
>que amenity=school plait plus.
>
>Je suis d'accord que les tags osm sont internationaux mais il faut bien
>les
>adapter à chaque pays et la communauté française peut juger que
>amenity=school c'est de la maternelle au bac et amenity=kindergarten
>c'est
>les crèches et autres garderies de jeunes enfants comme des choix ont
>été
>fait pour les niveau administratif admin_level=*.
>Si l'on regarde cette source :
>https://data.education.gouv.fr/explore/dataset/fr-en-annuaire-education
>où il y a une colonne pour indiquer que l'école à des classes de
>maternelle
>et une autre pour dire qu'elle a des classes élémentaires, il y a, sur
>50632 écoles, 13670 écoles seulement maternelle, 12027 seulement
>élémentaire et 24934 où il y a les 2, les écoles primaires. donc si
>l'on
>reste comme jusqu'à maintenant (kindergarten pour les maternelles et
>school
>pour les élémentaires et primaires) il n'y a, en fait, qu'environ un
>tiers
>des écoles maternelles en amenity=kindergarten le reste est à
>l'intérieur
>de school.
>
>Je ne connais pas les systèmes éducatifs à l'étranger mais quand je
>regarde
>https://en.wikipedia.org/wiki/Kindergarten , je me dis qu'il y a peut
>être
>un problème dans le choix du mot kindergarten. ça dit que kindergarten
>est
>peu utilisé en uk alors que c'est normalement l'anglais uk qui est
>utilisé
>dans osm et pour les usa, c'est seulement l'année précédant l'entrée à
>l'école et non tout le préscolaire comme le dit le wiki osm.

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Gad Jo]

Le problème est que l'information "par route touristique" n'est pas 
parfaitement claire. Est-ce pour toutes les destinations ou seulement pour la 
dernière ?

En tant que conducteur n'ayant pas mémorisé toutes les sorties, je lis première 
destination recommandée et seconde destination comme route touristique.
Alors option 4 et c'est plutôt moche : 
Pleyben;Morlaix par route touristique

Osmand énonce parfaitement les destination mais attention... Il les énonces 
toutes au risque de ne pas avoir le temps de guider à l'intersection suivante.
Il y a 4 ans j'ai fait quelques essais sur Narbonne je m'en mange toujours les 
doigt. J'ai indiqué toutes les destinations visible et parfois il y a plus de 5 
éléments. Ça en devient ridicule et pire... incompréhensible.
Exemple avec destination trop longue pour entendre à temps "tourner à droite 
sur rue Blaise Pascal" :
https://openstreetmap.org/way/217668457

Peut être qu'il faut se limiter aux destinations principales ? Voir recommander 
de ne pas dépasser 3 destinations et en mettre plus pour les intersections 
complexe ? Ou peut-être 2 par défaut, 3 si besoin, plus si indispensable 
(aucune limite). Qu'en pense les contributeurs des grosses agglo qui y sont 
plus confronté à ce type de destination ? À mon niveau je n'ai pas assez de 
grosse intersection pour avoir une vision globale.

Le September 30, 2020 12:11:35 PM UTC, osm.sanspourr...@spamgourmet.com a écrit 
:
>Bonjour voici un cas limite :
>
>https://www.mapillary.com/app/?lat=48.1197593=-4.0228083=17=gGVYaub7M-9e3vPHAI9PuA=photo=0.521660257395191=0.4046908617951483=2
>
>58
>An Teir C'hoaz
>
>PLEYBEN
>MORLAIX
>par Route Touristique.
>
>
>ref et name sont clairs.
>
>Pour destination :
>
>1. Rien, les destination Pleyben et Morlaix ne sont pas jointes via
>cette sortie normalement (60 Ar Pouilhod pour Pleyben et pour 64
>Pontaol
>Morlaix).
>
>2. Pleyben;Morlaix, ça permet aux navigateurs de vous guider.
>
>3. Pleyben;Morlaix;par route touristique, ça permet aux navigateurs de
>mieux vous guider.
>
>4. Autre, précisez ;-)
>
>J'hésite entre 1 et 2, Adrien penche pour 3.
>
>3 a l'avantage de bien montrer le choix mais la route touristique est
>un
>type de route pas une destination, à la limite un "via".
>
>1 a l'avantage de ne pas risquer d'induire les moteurs en erreur (mais
>ils ne semblent pas tenir compte des panneaux pour inciter à passer par
>tel ou tel endroit).
>
>2 est un compromis... boiteux ?
>
>*Vous penchez pour quoi ?*
>
>Tiens, OSRM et GraphHopper n'affichent pas les noms ou les numéros des
>sorties.
>
>OSMAnd affiche deux fois le nom de la sortie et une fois la référence
>(soit An Teir C'hoaz An Teir C'hoaz 58).
>
>*Vous connaissez des routeurs qui affichent les destinations ?*
>
>"Prendre la sortie 58 An Teir C'hoaz, direction Pleyben, Morlaix" me
>semble plus parlant que "Prendre la bretelle à droite" (OSRM) ou pire
>"Restez sur la droite" (GraphHooper).
>
>N. B. : actuellement la sortie n'a pas de destination :
>https://www.openstreetmap.org/node/12123625
>
>Et la bretelle est nommée : https://www.openstreetmap.org/way/4043036
>alors qu'elle n'a pas de nom au cadastre. A supprimer à mon avis (le
>nom, pas la bretelle ;-)).
>
>Jean-Yvon
>
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Gad Jo]

Pour l'instant je n'ai pas traité ces notes car je n'ai pas vraiment compris ce 
qui est attendu.

Doit on déplacer l'info sur la tag destination ? Est ce qu'on peut conserver le 
numéro de sortie sur le segment ? En gros que doit-on faire ?

Le September 29, 2020 4:51:27 PM UTC, Christian Quest  
a écrit :
>Le 29/09/2020 à 18:11, osm.sanspourr...@spamgourmet.com a écrit :
>> Bonjour, je suis tombé sur une notification Osmose qui m'interpelle.
>>
>> En fait une règle JOSM _spécifique à la France_ :
>>
>> https://josm.openstreetmap.de/wiki/Rules/FranceSpecificRules
>>
>> Unusually named motorway_junction; use of 'name=*' for the exit 
>> destination?
>>
>> Sauf qu'il est usuel en Bretagne que les sorties soient numérotées et
>> nommées (en breton dans la zone bretonnante).
>>
>> Et là c'était du côté d'Albi où ça semble aussi systématique.
>>
>> Un exemple :
>>
>>
>http://osmose.openstreetmap.fr/en/error/1d1a8a63-be65-2dfb-73ba-fbd66513cf76
>
>>
>>
>> https://www.openstreetmap.org/node/250116724
>>
>> Kerfleury est le nom de la sortie (et du lieu-dit le plus proche).
>>
>> Les gens prennent la sortie Kerfleury.
>>
>> Sur le panneau :
>>
>> 46.1 Kerfleury
>>
>> et en dessous Quimperlé-Est (la destination en jargon DIR, que
>personne
>> n'utilise).
>>
>>
>https://www.mapillary.com/app/?lat=47.84639403=-3.50455297=17=PStmBHEEK35wa2mql8FHQw=photo=0.5324220118049187=0.5275405429846113=1
>
>>
>>
>> Je veux bien qu'on conseille d'ajouter la destination, mais de là à
>> proposer de supprimer de la bonne information...
>>
>> Dans d'autres coins de la France les règles sont différentes ?
>>
>>
>
>Une sortie d'autoroute peut avoir un nom, sans qu'il corresponde à une 
>destination, exemple sur l'A6: Auxerre Nord / Auxerre Sud.
>
>C'est le texte du warning qui devrait être plus explicite pour séparer 
>le cas destination et le cas du nom.
>
>-- 
>Christian Quest - OpenStreetMap France
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Gad Jo]

Yes j'utilise ce merveilleux outils qu'est busy hours. C'est super le travail 
que cela abat.

J'ai contacté Noémie concernant l'ajout des mois. En attendant je les précises 
à la main dans josm mais celui-ci couine lors de la validation des données.
Je fait le point avec la doc sur le wiki et j'ouvrirai un sujet spécifique à ce 
sujet. C'est tellement complexe que je souhaite pas parasiter le sujet de cette 
discussion.

Le September 29, 2020 8:42:51 AM UTC, leni  a écrit :
>
>Le 28/09/2020 à 20:07, Gad Jo a écrit :
>> C'est exactement ça. Sur la même ligne j'ai des variante qui font
>tous 
>> les villages et d'autres seulement quelques villages. En bonus 
>> certains arrêt en milieu de ligne peuvent être ignoré en milieu de 
>> journée ou pendant le ramassage scolaire
>>
>> J'avais tenté name=: commune - 
>>  → commune - 
>>
>> Au final je vais faire sauter le nom des communes. Le from et to sont
>
>> justement changeant suivant les horaires et périodes de l'année. La 
>> clé via permet de préciser un peu plus le otrajet
>>
>> En tout merci pour votre réactivité
>>
>> Ps : Prochain mail : comment gérer les horaires sur les lignes de bus
>
>> (c'est coton). Je fait le point et au besoin je poserai ma question
>>
>Un message de Noémie concernant les horaires sur la liste transport
>dont 
>parle Jean-Yvon 
>https://listes.openstreetmap.fr/wws/arc/transport/2019-11/msg7.html
>>
>>
>> Le September 28, 2020 5:22:08 PM UTC, blef 
>>  a écrit :
>>
>> Le 28/09/2020 à 09:55, Éric Gillet a écrit :
>>> Le 27/09/2020 à 16:46, Gad Jo a écrit :
>>>> Bonjour a tous,
>>>>
>>>> Exemple extrême (y aura pas pire que ça) : Bus 12 bis :
>>>> Montredon-des-Corbières - Montredon Pôle d’échanges →
>>>> Montredon-des-Corbières - Clos des Ormeaux
>>>> (Désolé le copier-coller sur l'application ajoute le format)
>>>> Relation concernée :
>https://www.openstreetmap.org/relation/11674315
>>>>
>>>> Auriez vous des propositions à me faire ? À moins que des
>règles
>>>> existent et j'applique... Je serait tenté de placer que le nom
>>>> de l'arrêt
>>>
>>> Bonjour,
>>>
>>> Je pense qu'il faut mettre le nom tel que diffusé au public par
>>> le réseau (en données ouvertes, sur les documents ou sur le
>terrain).
>>>
>>> "name=:  → /"
>>> /[1][2]//ou autre variante n'est pas un nom mais une
>>> description//redondante avec les autres tags présents dans la
>>> relation/. /Pas toutes les applications affichent ces détails-là
>>> donc une telle description en nom me paraît acceptable, mais
>>> uniquement en "solution de repli" quand la ligne n'a pas de nom.
>>>
>>>
>[1]https://wiki.openstreetmap.org/wiki/Public_transport#Service_routes
>>>
>[2]https://lists.openstreetmap.org/pipermail/tagging/2019-May/045180.html
>>>
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>> Bonjour,
>>
>> Le problème survient quand il y a des variantes sur une ligne.
>> Le nom officiel de la ligne est toujours le même, mais les
>trajets
>> et arrêts desservis varient.
>> Comme il faut établir une relation par variante, il faut bien
>> différencier les noms.
>> Dans une petite ville comme la mienne, il y a un nombre restreint
>> de lignes, mais suivant les moments de la journée, la ligne x
>> passe ou pas par le collège, la zone industrielle ou le
>cimetière.
>> J'ai donc dû différentier arbitrairement les noms de variantes de
>> celui "fourni" par le gestionnaire du réseau, en général en
>> faisant figurer le "via" qui caractérise la variante.
>>
>>
>> -- 
>> Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma 
>> brièveté.
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Serveur Discord créé

[Gad Jo]

Hors sujet :
Je ne connaissait pas le fonctionnement de discord. C'est intéressant par 
contre Romain peut tu préciser ce qui n'est pas recommandé ?

Est-ce les usages détourné par les groupes d'extrême droite ou l'infection par 
un malware ? Est-ce que cette infection a été propagée par l'éditeur du 
logiciel (à son insu) ? Est-ce toujours d'actualité ?

Je pose ces questions pour pouvoir comparer avec Zoom qu'on utilise au taf :-/
Le nextcloud talk que j'avais monté pendant le confinement disposait de trop 
peut de ressources matériel pour être utilisable et le responsable à choisi 
Zoom un peu  dans l'urgence. Je recherche une alternative.

Le September 28, 2020 8:11:01 PM UTC, Romain MEHUT  a 
écrit :
>Bonsoir,
>
>J'ai été contacté par la messagerie interne d'osm.org pour y participer
>
>mais j'ai décliné la proposition en raison notamment des éléments 
>décrits sur Wikipedia https://fr.wikipedia.org/wiki/Discord_(logiciel)
>
>Romain
>
>Le 27/09/2020 à 16:10, Emilie Laffray a écrit :
>> Bonjour tout le monde,
>>
>> juste un petit passage pour signaler que quelqu'un a créé un serveur 
>> discord pour la communauté OpenStreetMap Fr.
>> L'utilisateur s'appelle Khryashch#1881.
>> Voila le lien https://discord.gg/wxNGfdT
>>
>> Pour ceux qui ne connaissent pas Discord, c'est une sorte de IRC 
>> moderne avec persistance des discussions et la possibilité de faire
>du 
>> vocal/vidéo facilement.
>> C'est surtout utilisé à la base pour faciliter les communaute de 
>> gamers et ca touche a des gens un peu plus jeune généralement pour
>qui 
>> IRC est un truc un peu abscon :)
>>
>> Voila voila,
>> Emilie Laffray
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Gad Jo]

C'est exactement ça. Sur la même ligne j'ai des variante qui font tous les 
villages et d'autres seulement quelques villages. En bonus certains arrêt en 
milieu de ligne peuvent être ignoré en milieu de journée ou pendant le 
ramassage scolaire

J'avais tenté name=: commune -  → 
commune - 

Au final je vais faire sauter le nom des communes. Le from et to sont justement 
changeant suivant les horaires et périodes de l'année. La clé via permet de 
préciser un peu plus le  otrajet

En tout merci pour votre réactivité

Ps : Prochain mail : comment gérer les horaires sur les lignes de bus (c'est 
coton). Je fait le point et au besoin je poserai ma question



Le September 28, 2020 5:22:08 PM UTC, blef  a écrit 
:
>Le 28/09/2020 à 09:55, Éric Gillet a écrit :
>> Le 27/09/2020 à 16:46, Gad Jo a écrit :
>>> Bonjour a tous,
>>>
>>> Exemple extrême (y aura pas pire que ça) : Bus 12 bis : 
>>> Montredon-des-Corbières - Montredon Pôle d’échanges → 
>>> Montredon-des-Corbières - Clos des Ormeaux
>>> (Désolé le copier-coller sur l'application ajoute le format)
>>> Relation concernée : https://www.openstreetmap.org/relation/11674315
>>>
>>> Auriez vous des propositions à me faire ? À moins que des règles 
>>> existent et j'applique... Je serait tenté de placer que le nom de
>l'arrêt
>>
>> Bonjour,
>>
>> Je pense qu'il faut mettre le nom tel que diffusé au public par le 
>> réseau (en données ouvertes, sur les documents ou sur le terrain).
>>
>> "name=:  → /" 
>> /[1][2]//ou autre variante n'est pas un nom mais une 
>> description//redondante avec les autres tags présents dans la 
>> relation/. /Pas toutes les applications affichent ces détails-là donc
>
>> une telle description en nom me paraît acceptable, mais uniquement en
>
>> "solution de repli" quand la ligne n'a pas de nom.
>>
>>
>[1]https://wiki.openstreetmap.org/wiki/Public_transport#Service_routes
>>
>[2]https://lists.openstreetmap.org/pipermail/tagging/2019-May/045180.html
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>
>Bonjour,
>
>Le problème survient quand il y a des variantes sur une ligne.
>Le nom officiel de la ligne est toujours le même, mais les trajets et 
>arrêts desservis varient.
>Comme il faut établir une relation par variante, il faut bien 
>différencier les noms.
>Dans une petite ville comme la mienne, il y a un nombre restreint de 
>lignes, mais suivant les moments de la journée, la ligne x passe ou pas
>
>par le collège, la zone industrielle ou le cimetière.
>J'ai donc dû différentier arbitrairement les noms de variantes de celui
>
>"fourni" par le gestionnaire du réseau, en général en faisant figurer
>le 
>"via" qui caractérise la variante.

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-be] Hoppin / Mobipunt

[Jo]

Hi,

I wanted to map our shiny new Hoppin points meant to group sharing
facilities for bicycles and cars + public transport.

https://www.openstreetmap.org/relation/11683352/history#map=16/50.8633/4.7005
https://www.openstreetmap.org/relation/11683353#map=18/50.86545/4.69504

are my first attempts.

I used a site relation, because we already have tags for the amenities that
form part of the group. They are supposed to be concentrated in a 'point',
but sometimes the bus or train stops are a bit further away.

There should also be a sign, possibly with a map on them, but I didn't map
those yet.

For those I thought of

tourism=information
information=board
maybe
board_type


Any comments?

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

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

[Gad Jo]

Pour l'instant rien n'a été publié sur transport data gouv. 
Quand j'ai commencé à créé les trajets je pensai plutôt à mettre en avant la 
commune de départ et d'arrivée + nom des arrêts. Quand on ne sait pas quelle 
ligne prendre ça peut aider.

Avec le recul c'était une mauvaise idée rendant la lecture complexe sur 
certains trajets.
J'attends quelques jours au cas où un avis contraire me le déconseille mais je 
pense opter pour placer uniquement le depart et terminus sans le nom des 
communes.

Le September 27, 2020 4:02:31 PM UTC, deuzeffe  a 
écrit :
>Le 27/09/2020 à 16:46, Gad Jo a écrit :
>> Bonjour a tous,
>
>Bonjour,
>
>> Un point que j'ai mis de côté en me promettant de le régler est le 
>> format pour le nom des trajets (1 ligne, plusieurs trajets)
>> 
>> Sur les trajets desservant des communes différentes j'ai ajouter le
>nom 
>> des communes + arrêt. Problème ça commence à être sacrement
>illisible.
>> > Auriez vous des propositions à me faire ? À moins que des règles
>> existent et j'applique... Je serait tenté de placer que le nom de
>l'arrêt
>
>J'ai peut-être été hétérodoxe, mais pour les lignes de bus de 
>l'intercommunalité voisine et celles du département, j'ai "bêtement" 
>repris les dénominations officielles du réseau, de terminus à terminus.
>
>Bon, j'avoue, les données sont en LO, c'est plus facile :) Aucune idée 
>si ta collectivité a publié des données sur
>https://transport.data.gouv.fr/
>
>Ça donne un truc comme ça : 
>https://wiki.openstreetmap.org/wiki/Limoges/Transports_en_commun#R.C3.A9seau_STCLM
>
>(WIP) ou ça : 
>https://wiki.openstreetmap.org/wiki/Haute-Vienne/Transports_en_commun#R.C3.A9seau_Moohv87
>
>(WIP aussi)
>
>Et pour les terminus hors grosse ville, parfois le réseau précise 
>l'arrêt parfois non. Donc, je fais pareil ;)
>
>-- 
>deuzeffe
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Gad Jo]

Bonjour a tous,


J'avance à grand pas vers la fin d'un vieux projet commencé en 2012 : 
cartographier les lignes de bus sur Narbonne

Un point que j'ai mis de côté en me promettant de le régler est le format pour 
le nom des trajets (1 ligne, plusieurs trajets)

Sur les trajets desservant des communes différentes j'ai ajouter le nom des 
communes + arrêt. Problème ça commence à être sacrement illisible.

Exemple extrême (y aura pas pire que ça) : Bus 12 bis : Montredon-des-Corbières 
- Montredon Pôle d’échanges → Montredon-des-Corbières - Clos des Ormeaux 
(Désolé le copier-coller sur l'application ajoute le format)
Relation concernée : https://www.openstreetmap.org/relation/11674315

Plus d'exemple sur la page de suivi :
https://wiki.openstreetmap.org/w/index.php?title=Narbonne/Transports_en_commun#Lignes_P.C3.A9riurbaines

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

Ps : si vous avez des suggestions sur le contenu de la page de suivi je suis 
preneur. Je compte la communiquer à l'Agglo
-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Question sur la formulation d'une demande de données à une Mairie

[Gad Jo]

Je suis également très intéressé pour proposer à mon agglo le partage des 
quelques données qu'elle à mis en ligne 

Le September 16, 2020 5:06:43 PM UTC, Water-Map  a écrit :
>Bonjour,
>
>La Mairie d’Avignon a récemment mis à disposition une carte qui recense
>des
>points d'eau potable sur la ville.
>
>https://www.echodumardi.com/actualite/avignon-une-carte-pour-trouver-les-fontaines-et-les-points-deau-de-la-ville/
>
>https://cartes.mairie-avignon.com/cartes/index.php/view/map/?repository=rep=ville_fraiche=00B000TFTTTFF=84144
>
>Est-ce que quelqu'un pourrait m'aider à formuler une demande à la
>Mairie
>d'Avignon de mise en accès libre ces données en citant la licence ODbL
>de
>la bonne façon et un exemple d'un bon format de données que la ville
>pourrait partager qui conviendrait à la communauté et qui ne sera pas
>trop
>compliqué à importer dans OSM ?
>
>Merci en avance,
>
>Stuart
>
>
>https://water-map.org
>*Twitter * - *Facebook
>* - *LinkedIn
>*

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Article dans le Parisien sur Water-Map

[Gad Jo]

Pas mal du tout.

Je viens testé et je me demande si certains point d'eau ne devrait pas être 
ignoré comme celui ci https://www.openstreetmap.org/node/3323930001 (accès 
réservé aux clients)

Ce sont des WC réservé aux usagés du collège. C'est les WC de la cour fréquenté 
par les élèves.
À moins que j'ai utilisé les mauvais tag (tu me dira). À l'époque c'était mappé 
pour montrer le potentiel aux profs de technologie qui s'en sont servi pour des 
travaux avec les élèves.
En tout cas l'accès sera formellement refusé au public.

Le September 13, 2020 12:13:43 PM UTC, Water-Map  a écrit 
:
>Bonjour,
>
>Nous avons eu un article dans le Parisien cette semaine sur notre
>projet
>collaboratif qui cartographie les points d'eau (fontaines + cafés) dans
>le
>but de combattre le plastique à usage unique.
>
>Nous avons également changé le nom de notre Web App cette semaine juste
>avant l'apparition de l'article à Water-Map pour avoir un nom plus
>parlant
>et pour avoir un url plus court.
>
>Voici l'article :
>https://drive.google.com/file/d/1_Kj3XIw71l08Gb5y-JJS0hWYkvc5EnFr/view?usp=sharing
>
>Bonne semaine,
>
>Stuart
>
>https://water-map.org

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Gad Jo]

Merci Philippe pour le partage. Super d'avoir pensé à nous.

Le September 13, 2020 5:49:08 PM UTC, Philippe Verdy  a écrit 
:
>A voir:
>
>Pour informer les usagers de la route, des panneaux de signalisation
>indiquent les voies réservées aux transports en commun, bus, taxis mais
>aussi aux véhicules en covoiturage et aux véhicules propres, en
>agglomération comme sur les voies rapides. Depuis le 31 août 2020, une
>expérimentation de signalisation a débuté sur tout le territoire pour
>harmoniser la matérialisation de ces voies. Un arrêté publié au Journal
>officiel le 29 août 2020 précise ces modalités.
>
>https://www.service-public.fr/particuliers/actualites/A14270?xtor=EPR-141

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] La proposition shadok : les pompes

[Gad Jo]

Ton dossier pour la proposition est très bien construit et très clair.

Félicitations

Le September 8, 2020 10:12:40 PM UTC, "François Lacombe" 
 a écrit :
>Salut à tous
>
>Voici une proposition de nouveaux tags pour décrire les pompes,
>beaucoup de
>modèles différents, dont je vient d'achever la traduction
>https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Pumping_proposal
>
>Elle m'a occupé une partie du confinement de ce printemps et a déjà
>reçu de
>nombreux commentaires sur la version anglaise, ce qui permet
>aujourd'hui
>d'avoir un modèle assez mature.
>
>L'idée est de réutiliser ce qui a été mis en place pour décrire les
>puits à
>eau ou de pétrole pour l'étendre à d'autres univers comme l'industrie
>ou le
>médical.
>En tout cas il est proposé de considérer les pompes comme des appareils
>à
>part entière, quel que soit leur usage en situation.
>
>Je cherche encore des exemples ou des photos. Certains modèles sont
>quasi
>introuvables dans la nature et ca ne pousse pas sur les arbres.
>
>Le modèle attributaire proposé sera également présenté au groupe de
>travail
>de l'ASTEE qui débute la semaine prochaine pour l'élaboration d'un
>nouveau
>géostandard pour l'adduction d'eau potable et la gestion des eaux
>usées.
>J'essaierai d'y apporter un peu de culture OSM
>(le précédent GT
>https://www.astee.org/groupe-de-travail-sig-participez-a-la-consultation-externe/
>)
>
>Preneur de vos retours, à bientôt
>
>François

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Gad Jo]

Oui erreur de jeunesse que je n'ai pas remis au goût du jour faute de 
l'utiliser.

Veuillez ignorer mon dernier retour sur le nombre de voies. C'est bien le 
nombre total de voies existante sur la chaussée qui est à indiquer

Le September 4, 2020 9:03:57 AM UTC, osm.sanspourr...@spamgourmet.com a écrit :
>Le 03/09/2020 à 16:05, Percherie OnDaNet - perche...@toutenkamion.net a
>écrit
>
>>> Attention pour le nombre de voies. C'est le nombre de voies par sens
>>> de circulation. Je m'en suis rendu compte quand mes applications de
>>> routage m'indiquez 4 voies (2 + 2 par sens) sur une route de
>>> campagne. C'était une découverte sur un cas pratique.
>>
>> Non, c'est bien le nombre *total* de voies :
>>
>> FR:Key:lanes /
>> /
>>
>> /La clé //lanes=*//doit être utilisée pour indiquer le nombre total
>> marquées de voies. /
>>
>Vérifié et confirmé.
>
>Jean-Yvon
>
>P. S.  : FR:Key:lanes#Présupposés
>
>indique bien quand on peut se contenter du nombre de voies par défaut.

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rond point et relations routes

[Gad Jo]

Si vous voulez je peu m'en occuper à minima pour les bonnes pratique en France.

Le cas des giratoires à ne pas découper on le comprend mieux chez nous, le pays 
des rond point... On en a un nombre très important sans commune mesure avec 
celui qui est en deuxième position (info entendu sur le journal TV).
Il est probable que dans les autres pays que le cas se présente rarement et que 
personne ne s'y est intéressé.

Pour faire les modifications sur les pages EN faut il faire une demande de 
consensus via une page de discussions ? Quitte a passer sur l'hebdo osm pour 
stimuler les réponses
Il me faut juste quelques conseils et je me lance

Le September 3, 2020 2:38:45 PM UTC, Rpnpif via Talk-fr 
 a écrit :
>Le 01/09/2020 à 19:13, Georges Dutreix via Talk-fr a écrit :
>> Bonjour,
>>
>> J'ai souvent découpé des giratoires pour des lignes de bus : honte
>sur 
>> moi !
>> Promis, je ne le ferai plus ;-)
>>
>> Peut-être faudrait-il décrire les bonnes pratiques, pour les naïfs 
>> comme moi, dans des pages comme
>https://wiki.openstreetmap.org/wiki/FR:Bus
>> ou 
>>
>https://wiki.openstreetmap.org/wiki/FR:Relation:route#Les_itin.C3.A9raires_de_bus_et_les_ronds-points
>
>> ?
>>
>> Je ne maîtrise pas assez celles-ci pour m'amuser à modifier le wiki 
>> moi-même. Et il semblerait qu'il n'y ait pas consensus...
>> Peut-on écrire par ci par là que la bonne pratique en France est de, 
>> si possible, ne pas casser les rond points en plusieurs segments ?
>
>
>+1 ! Tout à fait d'accord.
>
>-- 
>Rpnpif

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-be] regional cycle routes in Brussels

[Jo]

Yes, I'll look at those as well.

Jo

On Thu, Sep 3, 2020 at 1:00 PM Yves bxl-forever 
wrote:

> Hello,
>
> Thanks for this.
>
> @Polyglot, I saw you updated numbered cycle routes (1 to 12).
> The Brussels cycle route network also has 7 routes with letters.  I
> suppose we should apply the same change.
> A small circle: https://www.openstreetmap.org/relation/237027
> B middle circle: https://www.openstreetmap.org/relation/116569
> C large circle: https://www.openstreetmap.org/relation/7418111
> CC: Canal/Kanaal: https://www.openstreetmap.org/relation/1119347
> SZ Senne/Zenne valley: https://www.openstreetmap.org/relation/116611
> MM Maalbeek valley: https://www.openstreetmap.org/relation/114235
> PP (King’s Palace): https://www.openstreetmap.org/relation/2133184
>
> Cheers.
> Yves
>
>
> On Thu, 3 Sep 2020 10:40:29 +0200
> Jo  wrote:
>
> > I had a look at them after downloading them using Overpass API and
> started
> > making them continuous where they were 'broken'. So I went ahead and also
> > converted them all to rcn.
> >
> > Jo
> >
> > On Thu, Sep 3, 2020 at 9:41 AM Jo  wrote:
> >
> > > Hi Joost,
> > >
> > > In Flanders it depended more on topology than anything else. We used:
> > >
> > > lcn: for loops
> > > rcn: for the numbered node networks, this logic was taken to rwn and
> rhn
> > > later on
> > > ncn: for long routes going from A to B (LFx) and then later for the
> Fxxx
> > > cycle highways
> > > icn: for European routes going from A to B
> > >
> > > In Brussels rcn doesn't seem to be used and those routes are
> topologically
> > > more similar to the numbered routes system used in Flanders and
> Wallonia.
> > >
> > > I agree with you that it makes more sense to tag them as rcn.
> > >
> > > Jo
> > >
> > > On Thu, Sep 3, 2020 at 9:14 AM joost schouppe <
> joost.schou...@gmail.com>
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >> I was always a little confused that the regional cycle network is
> mapped
> > >> as lcn in Brussels. Since this network is organized by
> Brussels-the-region,
> > >> not Brussels-the-city, it seems logical that it should have the rcn
> tag. In
> > >> fact, more so than the Flemish cycle node network, which is composed
> of
> > >> several networks and almost by coincidence covers the region.
> > >>
> > >> This is also what we say in the wiki:
> > >>
> > >>
> https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Cycle_Routes#Itin.C3.A9raires_Cyclables_R.C3.A9gionaux_-_Gewestelijke_Fietsroute
> > >>
> > >> But the example given there (
> https://www.openstreetmap.org/relation/9623
> > >> I believe), is now mapped as an lcn.
> > >>
> > >> Looking at the edit history, it looks like there was a minor edit war
> > >> about this, where user RoRay repeatedly changed it from rcn to lcn
> > >> https://www.openstreetmap.org/changeset/8141976
> > >> https://www.openstreetmap.org/changeset/12902663
> > >> (RoRay is still mapping, still using the not-very helpful default
> > >> changeset description "update")
> > >>
> > >> User BenoitL tried to change it back to rcn (with much better
> changeset
> > >> comments :) - https://www.openstreetmap.org/changeset/12849599), but
> I
> > >> guess he gave up. Polyglot later seems to have mapped most of the
> other
> > >> routes; my guess is he just went with lcn because that's how the
> others
> > >> were mapped.
> > >>
> > >> Apart from the network not showing up when it should on some maps, it
> > >> doesn't really matter much. However, bxl-forever is now mapping
> -actual-
> > >> lcn routes in the Brussels region, operated by Anderlecht
> municipality.
> > >> Example: https://www.openstreetmap.org/relation/11544325
> > >> Putting both types of routes in the same level is just wrong IMHO.
> > >>
> > >> Can anyone provide some more context? Based on my own research, I'd
> > >> suggest we simply retag all the regional operated routes from lcn to
> rcn.
> > >>
> > >> Best,
> > >> Joost Schouppe
> > >> ___
> > >> Talk-be mailing list
> > >> Talk-be@openstreetmap.org
> > >> https://lists.openstreetmap.org/listinfo/talk-be
> > >>
> > >
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] regional cycle routes in Brussels

[Jo]

I had a look at them after downloading them using Overpass API and started
making them continuous where they were 'broken'. So I went ahead and also
converted them all to rcn.

Jo

On Thu, Sep 3, 2020 at 9:41 AM Jo  wrote:

> Hi Joost,
>
> In Flanders it depended more on topology than anything else. We used:
>
> lcn: for loops
> rcn: for the numbered node networks, this logic was taken to rwn and rhn
> later on
> ncn: for long routes going from A to B (LFx) and then later for the Fxxx
> cycle highways
> icn: for European routes going from A to B
>
> In Brussels rcn doesn't seem to be used and those routes are topologically
> more similar to the numbered routes system used in Flanders and Wallonia.
>
> I agree with you that it makes more sense to tag them as rcn.
>
> Jo
>
> On Thu, Sep 3, 2020 at 9:14 AM joost schouppe 
> wrote:
>
>> Hi,
>>
>> I was always a little confused that the regional cycle network is mapped
>> as lcn in Brussels. Since this network is organized by Brussels-the-region,
>> not Brussels-the-city, it seems logical that it should have the rcn tag. In
>> fact, more so than the Flemish cycle node network, which is composed of
>> several networks and almost by coincidence covers the region.
>>
>> This is also what we say in the wiki:
>>
>> https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Cycle_Routes#Itin.C3.A9raires_Cyclables_R.C3.A9gionaux_-_Gewestelijke_Fietsroute
>>
>> But the example given there (https://www.openstreetmap.org/relation/9623
>> I believe), is now mapped as an lcn.
>>
>> Looking at the edit history, it looks like there was a minor edit war
>> about this, where user RoRay repeatedly changed it from rcn to lcn
>> https://www.openstreetmap.org/changeset/8141976
>> https://www.openstreetmap.org/changeset/12902663
>> (RoRay is still mapping, still using the not-very helpful default
>> changeset description "update")
>>
>> User BenoitL tried to change it back to rcn (with much better changeset
>> comments :) - https://www.openstreetmap.org/changeset/12849599), but I
>> guess he gave up. Polyglot later seems to have mapped most of the other
>> routes; my guess is he just went with lcn because that's how the others
>> were mapped.
>>
>> Apart from the network not showing up when it should on some maps, it
>> doesn't really matter much. However, bxl-forever is now mapping -actual-
>> lcn routes in the Brussels region, operated by Anderlecht municipality.
>> Example: https://www.openstreetmap.org/relation/11544325
>> Putting both types of routes in the same level is just wrong IMHO.
>>
>> Can anyone provide some more context? Based on my own research, I'd
>> suggest we simply retag all the regional operated routes from lcn to rcn.
>>
>> Best,
>> Joost Schouppe
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] regional cycle routes in Brussels

[Jo]

Hi Joost,

In Flanders it depended more on topology than anything else. We used:

lcn: for loops
rcn: for the numbered node networks, this logic was taken to rwn and rhn
later on
ncn: for long routes going from A to B (LFx) and then later for the Fxxx
cycle highways
icn: for European routes going from A to B

In Brussels rcn doesn't seem to be used and those routes are topologically
more similar to the numbered routes system used in Flanders and Wallonia.

I agree with you that it makes more sense to tag them as rcn.

Jo

On Thu, Sep 3, 2020 at 9:14 AM joost schouppe 
wrote:

> Hi,
>
> I was always a little confused that the regional cycle network is mapped
> as lcn in Brussels. Since this network is organized by Brussels-the-region,
> not Brussels-the-city, it seems logical that it should have the rcn tag. In
> fact, more so than the Flemish cycle node network, which is composed of
> several networks and almost by coincidence covers the region.
>
> This is also what we say in the wiki:
>
> https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Cycle_Routes#Itin.C3.A9raires_Cyclables_R.C3.A9gionaux_-_Gewestelijke_Fietsroute
>
> But the example given there (https://www.openstreetmap.org/relation/9623
> I believe), is now mapped as an lcn.
>
> Looking at the edit history, it looks like there was a minor edit war
> about this, where user RoRay repeatedly changed it from rcn to lcn
> https://www.openstreetmap.org/changeset/8141976
> https://www.openstreetmap.org/changeset/12902663
> (RoRay is still mapping, still using the not-very helpful default
> changeset description "update")
>
> User BenoitL tried to change it back to rcn (with much better changeset
> comments :) - https://www.openstreetmap.org/changeset/12849599), but I
> guess he gave up. Polyglot later seems to have mapped most of the other
> routes; my guess is he just went with lcn because that's how the others
> were mapped.
>
> Apart from the network not showing up when it should on some maps, it
> doesn't really matter much. However, bxl-forever is now mapping -actual-
> lcn routes in the Brussels region, operated by Anderlecht municipality.
> Example: https://www.openstreetmap.org/relation/11544325
> Putting both types of routes in the same level is just wrong IMHO.
>
> Can anyone provide some more context? Based on my own research, I'd
> suggest we simply retag all the regional operated routes from lcn to rcn.
>
> Best,
> Joost Schouppe
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

[Gad Jo]

J'envisage plutôt l'inverse en anticipant un énième changement de règle au 
niveau national. Mieux vaut prévenir que guérir. Cela facilitera les 
corrections en masse si on indique la source.

Préfère source:maxspeed=FR:urban + maxspeed=80 pour définir partout où la 
vitesse est à 80. Cela permettra facilement de modifier en masse les vitesses 
si on change les vitesses au niveau du pays (diminution à 70 ou rétablissement 
à 90)

Pour tout les autres cas même les portions où c'est sur tout un département que 
les routes sont repassée à 90, indique une autre source comme 
source:maxspeed=sign ou source:maxspeed=FR:zone** (souvent 30, parfois 20 ou 
50) quand les mairies n'utilise pas les panneaux zone de rencontre ou 
limitation 50 pour les lotissement hors agglo.

Plus d'info et exemple sur 
https://wiki.openstreetmap.org/wiki/FR:Key:source:maxspeed

Le September 1, 2020 11:15:53 PM UTC, Yannick  a écrit :
>Le 02/09/2020 à 00:51, Marc Mongenet a écrit :
>> Bonjour,
>> 
>> Près de chez moi passe la route D 903 avec une succession de portions
>> à accès réglementé en 2x2 voies séparées
>> (https://www.openstreetmap.org/way/825204700), à 2+1 voies
>> (https://www.openstreetmap.org/way/24205655), à 1+1 voies
>> (https://www.openstreetmap.org/way/6069166), à 1+1 voies séparées
>> (https://www.openstreetmap.org/way/654772946), sans compter les voies
>> d'insertion, etc.
>> 
>> De nombreuses portions ont une limite de vitesse implicite car il n'y
>> a pas de panneau limitant la vitesse, et les règles générales
>> s'appliquent (R413-2). Le problème est que ces règles sont mal
>> connues, et presque tout a été mal mappé avec maxspeed=80. Pour
>> l'instant j'ai supprimé ce qui était faux.
>> 
>> Mais est-ce que ça vaut la peine de mapper les limitations par
>défaut?
>> Informatiquement parlant, ça me semble profondément contre-productif:
>> c'est le boulot de l'ordinateur de calculer cela. Sauf qu'il faut
>tout
>> de même taguer qqch pour faire la différence entre une route de
>> maxspeed inconnue, et une route de maxspeed implicite. Ma question
>est
>> donc:
>> Est-ce qu'utiliser source:maxspeed=FR:rural sans maxspeed=* est une
>> bonne pratique?
>> 
>> PS: Les règles du code de la route sont si mal connues que
>>
>https://wiki.openstreetmap.org/wiki/FR:Key:maxspeed#Limitation_de_vitesse
>> contient une erreur de 20 km/h.
>> 
>> Marc Mongenet
>
>Bonsoir,
>
>L'implicite est désormais quasi impossible à deviner. Prends les
>nationales à 80 et des portions de départementales à 90. Je me mets à
>la
>place de l'étranger pour qui c'est pire qu'un casse-tête chinois. On
>finit par ne plus savoir la limite en vigueur sur telle ou telle
>portion
>de route.
>Je suis donc partisan de mettre systématiquement le maxspeed=* au moins
>c'est clairement renseigné sans équivoque possible.
>
>Amitiés
>
>
>-- 
>Yannick VOYEAUD
>Nul n'a droit au superflu tant que chacun n'a pas son nécessaire
>(Camille JOUFFRAY 1841-1924, maire de Vienne)
>http://www.voyeaud.org
>Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/
>Journées du Logiciel Libre: http://jdll.org
>Généalogie en liberté avec Ancestris https://www.ancestris.org

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rond point et relations routes

[Gad Jo]

Pour avoir mis en place l'ensemble du réseau de bus sur Narbonne c'est la mort 
dans l'âme que j'ai du segmenter en plusieurs section des routes ou rue. C'est 
vite ingérable et pourtant j'ai tout le réseau en tête.
Pour les giratoire c'est totalement inutile de les segmenter sauf cas très très 
particulier. Le routage fonctionne très bien tel quel.

Avec les restrictions de vitesse, bande cyclable et autre info (trottoir, 
revêtement, éclairage) ça multiplie les découpes

Malheureusement je ne vois aucune solutions pour éviter cela.

Le September 1, 2020 9:44:37 AM UTC, Christian Rogel 
 a écrit :
>
>> Le 1 sept. 2020 à 11:25, Yves P.  a écrit :
>> Je tombe sur des itinéraires vélos, bus… qui passent par des
>ronds-points.
>> 
>> Ces derniers sont coupés en petits morceaux pour avoir un bel
>itinéraire.
>> Ça part d'une bonne intention (j'ai fait la même chose au début),
>mais c'est ingérable !
>> 
>> S'il vous plait ne serez pas le sécateur quand vous croisez un
>giratoire.
>> Merci pour lui et son intégrité 
>
>
>Déjà mentionné, mais, j’approuve cette piqûre de rappel. Il faut pour
>agir ainsi, soit appartenir à la team 1er degré, soit être certain que
>le RP est positionné correctement. Et surtout au bon diamètre.
>Eh, bien, non, ça n’existe qu’au pays de Gaston Lagaffe.
>Plusieurs fois, j’ai rétabli l’intégrité et, par respect pour les
>autres contributeurs, laissé dans l’état normal.
>
>Christian R.
>
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-be] Fietsstraatzones in Leuven and a question about zones inside zones

[Jo]

I added some A23 here and there around Leuven. It made me realise I don't
have recent Mapillary images for many streets in Leuven to determine where
exactly those school zone30 start and end... Time to go out and cycle to
make more pictures, I guess.

Jo

On Mon, Aug 31, 2020 at 9:52 AM Tim Couwelier 
wrote:

> F4a should remain yes, despite both implying the same speed limit, UNLESS
> the local gov removed the F4a signs due to the 'fietszone' completely
> overlapping with the 'zone 30'.
> Ideally, for the 'zone 30', differentiate between 'normal' with F4a only
> and 'school- zone 30'  (F4a + A23)
>
> If there's living streets within, I'd say the restrictions 'stack': no
> overtaking, 20 km/h.
> There may actually be a slight nuance here - generally in case of possible
> contradiction, the rule applies 'traffic sign takes priority over traffic
> rules'. The speed limits in both fietszone and living_street are traffic
> rules, but this might leave a loophole where 'zone 30' as a sign takes
> priority.
>
> There used to be a loophole where a C43 70km/h would trump the 50km/h
> speed limit in a built up area until the first intersection (extent of the
> validity for the C43) but afaik that's been 'patched' in legislation now.
> This might just be an unforeseen edge case opening another such loophole,
> although I'm not 100% sure on this.
>
>
> Sidenote: I think I agree with not making a seperate sign for this, but
> just giving it a 'zonal' extent. If anything, F4a/b signs existing as such
> is confusing. But then again, so were the original streetsigns as they were
> semi-assumed to be zonal, but the law wasn't overly specific (and didn't
> mention it being zonal). Readability, in database or map format, is far
> better if you speak of 'zonal C43' and 'zonal F111' without having to know
> another number for the same type of thing.
>
> Op zo 30 aug. 2020 om 14:50 schreef Jo :
>
>> Hi,
>>
>> I added the new fietsstraatzones in Leuven to the map. They will be in
>> vigor on September 1st. The legislator didn't create a separate sign, they
>> just decided that it's allowed use F111 on a ZONE sign...
>>
>> I do like to distinguish between the 'real' cycle streets and the
>> 'pretenders', so the ones inside zones and the ones connecting the zones, I
>> guess. I used BE:F111zone as the traffic_sign. I may have done something
>> silly though, as I removed the F4a from the traffic sign tag.
>>
>> If you search for F111 you get all.
>> If you search for F111zone you get all the ones inside the zones.
>> If you search for "F111 -F111zone" in JOSM, you get only the cyclestreets
>> with an actual cycle street sign.
>>
>> If you search for F4a you get all the streets inside the zone30, but the
>> cycle streets are not included in that. How do we want to work with zones
>> within zones? There are also parking zones...
>>
>> Should I have put traffic_sign=BE:F111;BE:F4a;BE:F1a ?
>>
>> Initially I didn't because both are limited to 30km/h, but now I'm
>> thinking I should have.
>>
>> What about the living_street ways? They are also inside the zone30 (and
>> in built-up area), but the traffic rules that apply are BE:F12a. Do we add
>> BE:F12a;BE:F4a;BE:F1a ?
>>
>> Jo
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

[OSM-talk-be] Fietsstraatzones in Leuven and a question about zones inside zones

[Jo]

Hi,

I added the new fietsstraatzones in Leuven to the map. They will be in
vigor on September 1st. The legislator didn't create a separate sign, they
just decided that it's allowed use F111 on a ZONE sign...

I do like to distinguish between the 'real' cycle streets and the
'pretenders', so the ones inside zones and the ones connecting the zones, I
guess. I used BE:F111zone as the traffic_sign. I may have done something
silly though, as I removed the F4a from the traffic sign tag.

If you search for F111 you get all.
If you search for F111zone you get all the ones inside the zones.
If you search for "F111 -F111zone" in JOSM, you get only the cyclestreets
with an actual cycle street sign.

If you search for F4a you get all the streets inside the zone30, but the
cycle streets are not included in that. How do we want to work with zones
within zones? There are also parking zones...

Should I have put traffic_sign=BE:F111;BE:F4a;BE:F1a ?

Initially I didn't because both are limited to 30km/h, but now I'm thinking
I should have.

What about the living_street ways? They are also inside the zone30 (and in
built-up area), but the traffic rules that apply are BE:F12a. Do we add
BE:F12a;BE:F4a;BE:F1a ?

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

Re: [OSM-talk-fr] Projet du mois défibrillateurs : c'est parti !

[Gad Jo]

Nickel, j'avais peur qu'une notion de licences m'interdisait d'exploiter ces 
informations.

Je vais faire un premier import suivant la localisation indiquée sur la fiche 
avec un fixme demandant de préciser la localisation exact dans le bâtiment. 
Autrement j'aurai fini de les importer dans 2 ans (je suis seul sur Narbonne).

Astuces : dans les journaux locaux on peut trouver des articles indiquant la 
création de DAE et souvent il y a les photos des appareils. Sans forcément 
réutiliser les photos (licence ?) on peut déjà faire un ajout assez précis.
Pratique pour les villages environnant pour éviter de brûler du carburant à 
tout vas...
D'ailleurs, a t'on le droit de réutiliser une photos postée dans un journal 
local ?

Le August 29, 2020 4:48:54 AM UTC, "Yves P."  a écrit :
>> Ils ne sont pas proposé sur Osmose. Ai-je le droit de les intégrer
>tel quel ?
>Tu as le devoir de le intégrer :D
>
>J'ai regardé celui de la Hall d'honneur Pech de Laclause
> : 
>Sans photo de terrain, difficile de faire quoi que ce soit avec si peu
>d'informations.
>
>Dans ce cas, je suggère de l'ajouter uniquement après une visite et 2
>publier 2 photos (autre qu'un pompier soufflant dans un truc en
>plastique
>
>:D)
>
>de Philippe :
>> Attention à l'intégration avec Osmose, notamment sur:
>
>Ce n'est pas osmose en soit le problème, mais la qualité des données.
>
>
>> - le placement: la position est approximative car souvent l'adresse
>n'est pas bien localisée et manque;
>> - si l'adresse est présente, le placement proposée dessus n'est pas
>réellement le bon placement car l'adresse est souvent un noeud en
>bordure de propriété
>
>
>Le placement est souvent approximatif car l'adresse est géocodée (et
>pas toujours très bien selon la base de données utilisée).
>La personne qui saisi la fiche n'est pas forcément allée sur le
>terrain.
>
>Hier j'ai rajouté un DAE dans une entreprise. Elle est dans une zone
>industrielle, "loin" du village.
>GéoDAE la situait au centre.
>
>
>> - regarder l'attribut indoor=yes proposé, pour ajuster le noeud dans
>le bâtiment à cet adresse, près de son entrée mais bien à l'intérieur
>
>Idem. Un DAE était à l'extérieur, mais la fiche GéoDAE indiquait le
>contraire.
>
>Si une photo utile est fournie par GeoDAE et/ou que le défibrillateur
>est visible sur une photo terrain, j'intègre.
>Sinon, je laisse…
>
>
>Seulement 2 294 DAE sont "validés", et 14 040 sont en "attente de
>validation".
>
>Est-ce que quelqu'un en sait plus sur la validation d'un DAE ?
>Je n'ai rien trouvé sur le site.
>
>
>Autre remarque sur les données GéoDAE : la saisie semble libre, du coup
>c'est un vrai bazar.
>On se retrouve avec des infos peu structurées (les horaires notamment),
>des infos dans le mauvais champ, des descriptions manquantes ou trop
>vagues, pas de photos de situation…
>
>Donc plein de travail d'intégration en perspective :)
>
>__
>Yves

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet du mois défibrillateurs : c'est parti !

[Gad Jo]

T'inquiète sur Narbonne pas besoin de BANO, y a quelques années j'ai indiqué 
les numéro de rue partout où je pouvait. Il doit en manquer 5% qui reste facile 
à interpoler :-)

Le August 29, 2020 2:41:43 AM UTC, Philippe Verdy  a écrit :
>Attention à l'intégration avec Osmose, notamment sur:
>- le placement: la position est approximative car souvent l'adresse
>n'est
>pas bien localisée et manque;
>- si l'adresse est présente, le placement proposée dessus n'est pas
>réellement le bon placement car l'adresse est souvent un noeud en
>bordure
>de propriété
>- regarder l'attribut indoor=yes proposé, pour ajuster le noeud dans le
>bâtiment à cet adresse, près de son entrée mais bien à l'intérieur
>- avec indorr=yes il y a souvent des indications horaires, mais
>celles-ci
>ne sont pas "traduites" en attribut, ou parfois c'est vague: il faut
>chercher les hoareis d'ouverture de l'établissement (en profiter pour
>taguer l'établissement lui-même avec son POI), et reprendre ensuite les
>opening_hours sur le noeud du défibrillateur
>
>Souvent on bloque car la première étape, les adresses, ne sont pas
>localisées. On en revient à l'étape première: BANO reste prioritaire,
>consulter les points du cadastre s'ils ne sont pas proposés par Osmose
>dans
>un import (mais les imports d'adresse des grandes agglos ont déjà eu
>lieu,
>pas ceux du cadastre qu'il fauit chercher dans les planches, avec les
>petits numéros à ne pas confondre avec les gros numéros de parcelles)
>
>Parfois il manque les bâtiments correspondant ou leur import depuis le
>cadastre est à rectifier avec l'imagerie avant même de pouvoir mieux
>positionner le noeud d'adresse, les noeuds POI éventuels à
>repositionner
>aussi... puis enfin le DAE: le DAE n'est que la dernière étape: le
>projet
>DAE est donc bien plus facile à faire dans les grandes métropoles et
>agglos
>denses que les villes moyennes et périurbaines, ou les zones
>commerciales/artisanales/industrielles (où on trouve souvent les
>gymnases
>et salles de sport souvent équipées en DAE (et il faut s'occuper aussi
>des
>voies d'accès et chemins piétons.
>
>Pour les DAE dans les écoles ou services publics c'est plus facile car
>ils
>sont souvent déjà là et avec une adresse correcte. Mais on est loin du
>compte pour le reste.
>
>Le "projet du mois ne suffira pas sur cette durée limitée, le travail
>de
>fond reste l'intégration BANO, les cheminements piétons vers les
>commerces et services, les horaires d'ouvertures à chercher.
>
>Le sam. 29 août 2020 à 02:05, Gad Jo  a
>écrit :
>
>> Bonsoir,
>>
>>
>> J'ai consulté le site de la mairies de Narbonne et 45 DAE sont
>référencé
>> sur leur site : https://www.narbonne.fr/liste-des-defibrillateurs
>>
>> Ils ne sont pas proposé sur Osmose. Ai-je le droit de les intégrer
>tel
>> quel ? J'en connaît quelques uns et leur description concorde.
>J'envisage
>> de placer un fixme pour les vérifier sur le moyen ou long terme au
>fil de
>> mes déplacements.
>>
>> Qu'est ce que vous me conseillez ? Intégration grâce au site ? Avec
>fixme
>> ou pas ? Ou intégration **uniquement** si constaté présent après
>visite ?
>>
>> Le August 28, 2020 7:52:43 AM UTC, PanierAvide
> a
>> écrit :
>>>
>>> Bonjour à tous,
>>>
>>> Après plusieurs semaines de préparation, le projet du mois sur les
>>> défibrillateurs est officiellement lancé ! L'objectif : trouver le
>plus
>>> de ces défibrillateurs inconnus dans les bases de données ouvertes.
>>> Voici l'article sur le site OSM France pour (re)découvrir les
>enjeux,
>>> comment participer, et pouvoir relayer l'initiative dans vos réseaux
>:
>>>
>>> https://openstreetmap.fr/projet-du-mois-defibrillateurs/
>>>
>>> Pensez également à faire passer le mot dans les canaux de
>discussions de
>>> vos groupes locaux ;-)
>>>
>>> Bons relevés et à très vite !
>>>
>>>
>> --
>> Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma
>brièveté.
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet du mois défibrillateurs : c'est parti !

[Gad Jo]

Bonsoir,


J'ai consulté le site de la mairies de Narbonne et 45 DAE sont référencé sur 
leur site : https://www.narbonne.fr/liste-des-defibrillateurs

Ils ne sont pas proposé sur Osmose. Ai-je le droit de les intégrer tel quel ? 
J'en connaît quelques uns et leur description concorde. J'envisage de placer un 
fixme pour les vérifier sur le moyen ou long terme au fil de mes déplacements.

Qu'est ce que vous me conseillez ? Intégration grâce au site ? Avec fixme ou 
pas ? Ou intégration **uniquement** si constaté présent après visite ?

Le August 28, 2020 7:52:43 AM UTC, PanierAvide  a écrit 
:
>Bonjour à tous,
>
>Après plusieurs semaines de préparation, le projet du mois sur les 
>défibrillateurs est officiellement lancé ! L'objectif : trouver le plus
>
>de ces défibrillateurs inconnus dans les bases de données ouvertes. 
>Voici l'article sur le site OSM France pour (re)découvrir les enjeux, 
>comment participer, et pouvoir relayer l'initiative dans vos réseaux :
>
>https://openstreetmap.fr/projet-du-mois-defibrillateurs/
>
>Pensez également à faire passer le mot dans les canaux de discussions
>de 
>vos groupes locaux ;-)
>
>Bons relevés et à très vite !
>
>-- 
>Adrien P.
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Besoin de conseils pour les diagrammes de transport public

[Gad Jo]

Bonsoir,


Depuis 2012 j'ai commencé à cartographier les lignes de bus de l'Agglo 
narbonnaise (souvent mis de côté, toujours repris). Grâce à Pic4Review et 
Mapillary/OpenStreetCam j'ai accéléré sur ce projet (plus besoin de faire les 
relevés de tête)

Le suivi de l'avancement est disponible sur 
https://wiki.openstreetmap.org/wiki/Narbonne/Transports_en_commun#Lignes_Urbaines

Actuellement je travail sur le rendu des diagrammes grâce à l'outil dédié 
https://overpass-api.de/
Pour l'occasion le style "narbonne" a été créé en partant du style "paris".

Problème : si les plateform possède le tag highway=bus_stop les arrêts sont 
comptabilisé en double. Pourtant le modèle public_transport l'indique comme 
recommandé. Sans ça le rendu osm n'affiche plus les arrêts et Osmose couine.

Actuellement et le temps d'analyser toutes les lignes j'ai supprimé le tag 
highway=bus_stop. C'est l'exemple parfait de taguer pour le rendu. En attendant 
les diagramme sont maintenant lisible : 
https://overpass-api.de/api/sketch-line?ref=A=Citibus=narbonne

J'aurai besoin de conseils pour faire fonctionner correctement 
https://overpass-api.de/ quitte à proposer des améliorations mais où le faire ?
Le problème semble exister depuis pas mal de temps et j'ai constaté un peu 
partout dans le monde que cela incite les contributeurs à taguer pour le rendu. 
Je me demande si ils n'ont pas arrêté de corriger leur générateur de diagramme.
À moins que d'autres générateur de diagramme existe.

Là j'aurai besoin qu'on me conseil pour arriver à une solution fonctionnelle.



-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] Call for verification (Was: Re: VANDALISM !)

[Jo]

On Sat, Aug 22, 2020, 11:30 pangoSE  wrote:

> Hi 
>
> Mateusz Konieczny  skrev: (22 augusti 2020
> 10:51:49 CEST)
> >(1) Wikipedia may strongly encourage or mandate it in theory, but there
> >are
> >still edits being made without any citations
>
> Yeah I know, but the point is its really hard to create a new article in
> WP without references without it being flagged for deletion. So by
> "threatening" with deletion they raise the bar for inclusion and hence
> hopefully raise the quality too. We have no system to flag for deletion,
> nor to verify an object.
>

I find this highly annoying on Wikipedia and it is the reason I don't
contribute there anymore.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-de] Auftrennung der highways an Mautstellen

[Jo]

Ich würde das warscheinlich mit getrennten service ways mappen.

Bon solchen Regeln have ich noch nie gehört.

Jo

On Sat, Aug 22, 2020, 00:59 Volker via Talk-de 
wrote:

> Auch wenn ich von dieser Entscheidung noch nichts gehört habe, gibt es
> ein ungeschriebenes Gesetz bei OSM:*"Wir mappen nicht für Renderer und
> Router."* Ich denke auch, dass man auf Grund der on the Ground Regel,
> dass mappen sollte, was da ist; incl. der Barrieren, Schranken, Tunnel
> und Überdachungen etc. Wer an solchen Mautstellen nicht auf Sicht fährt
> sondern auf sein Navi hört, ist selbst dran schuld. Vom Navi muss halt
> dann eine Ansage kommen:"Bitte nutzen sie die nächste freie
> Abfertigungsspur in Richtung..." Aber das ist Sache der Naviprogrammierer.
>
> Gruß
>
> aeonesa
>
> Am 21.08.2020 um 18:50 schrieb Martin Koppenhoefer:
> > Ich würde Euch gerne um eine Einschätzung bitten: an den Mautstellen in
> Italien (und anderswo) splittet sich die Fahrbahn üblicherweise in mehrere
> Teile, grundsätzlich physisch getrennt durch meist Betonwände,
> Fußgängertunnel (gelegentlich/oft?), Leitplanken und Kassiererhäuschen,
> Beispielbild hier:
> >
> http://image.nanopress.it/r/623X0/www.nanopress.it/wp-content/uploads/2014/03/casello-autostradsle.jpg
> >
> > Die einzelnen Durchfahrten haben z.T. auch spezielle Eigenschaften
> (akzeptierte Zahlungsmittel, und ob eine Person da ist oder nur ein
> Automat, und für LKW) die
> >
> > Im italienischen Telegramm-Chat wird nun behauptet dass aufgrund von
> Entscheidungen der internationalen Community an diesen Stellen der highway
> nicht aufgesplittet werden darf, weil das angeblich die Naviprogramme
> überfordern würde, und dass alle mit mehr als einem highway pro Richtung
> gemappten Stellen jeweils zurückgebaut werden müssen.
> >
> > Kennt Ihr solche Entscheidungen?
> > Wäre es nicht eher dem System entsprechend, aufgrund der baulichen
> Trennungen den highway aufzufächern?
> >
> >
> > Gruß Martin
> > ___
> > Talk-de mailing list
> > Talk-de@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-de
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
>
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk-be] Import of GPX files for marked trails in OSM / Import de traces GPX pour promenades balisées dans OSM

[Jo]

Please have a look at JOSM's PT_Assistant plugin for helping with this. For
foot/walking/hiking and bicycle relations, there is an additional button,
"routing helper". Originally it only worked for public transport, but now
it works for all route relations that describe itineraries.

The GPX tracks can be shown with various options (thicker line, colouring)
in the background. That's standard JOSM.

Polyglot

On Thu, Aug 20, 2020 at 7:53 AM Matthieu Gaillet 
wrote:

>
> Génial ! Count me in. J’ai l’expérience de ce genre de relation et suis
> donc opérationnel.
>
> Matthieu G.  (en mode mobile)
>
> Le 20 août 2020 à 07:46, Julien Minet  a écrit :
>
> 
> Hello / Bonjour,
>
> Thanks to an active lobbying of Jacques Fondaire, contributor in Aubange,
> we had the explicit right (well, an email) to use some GPX files from the
> local tourism offices from the province of Luxembourg for completing the
> marked trails in South-Luxembourg in OSM. We did not receive all the tracks
> yet but in total there are about 120 walking marked trails in the Parc
> Naturel Haute-Sure Forêt d'Anlier.
>
> This is not an automatic import since, to the best of my knowledge, there
> is no automatic tool to convert some GPX into OSM relations. So we have to
> manually add these relations based on the GPX information. From my
> experience, it takes about 15 min. per relation to do so (in JOSM). I plan
> to write a few lines about this import somewhere on the OSM wiki such as
> here
> .
>
>
> If anyone wants to help to enter this information in OSM, just let me
> know! If you want to know how to add some marked trails in OSM, have a look
> at this page  and that
> one
> 
> for Belgian specificities. A nice app rendering all these routes is
> https://hiking.waymarkedtrails.org/.
>
> // en français //
>
> Grâce à un lobbying actif de Jacques Fondaire, collaborateur à Aubange,
> nous avons eu le droit explicite (enfin, un email) d'utiliser certains
> fichiers GPX des offices de tourisme locaux de la province de Luxembourg
> pour compléter les sentiers balisés du Sud-Luxembourg dans OSM. Nous
> n'avons pas encore reçu tous les fichiers, mais il s'agit d'environ 120
> pistes balisées dans le Parc Naturel Haute-Sure Forêt d'Anlier.
>
> Il ne s'agit pas d'une importation automatique car, à ma connaissance, il
> n'existe pas d'outil automatique permettant de convertir des GPX en
> relations OSM. Nous devons donc ajouter manuellement ces relations sur la
> base des GPX. D'après mon expérience, il faut environ 15 minutes par
> relation pour le faire (dans JOSM). J'ai l'intention d'écrire quelques
> lignes sur cette importation quelque part, par exemple ici
> .
>
>
> Si quelqu'un veut aider à saisir ces informations dans OSM, faites-le moi
> savoir ! Si vous voulez savoir comment ajouter quelques pistes balisées
> dans OSM, jetez un coup d'oeil à cette page
>  et à celle-ci
> 
> (spécificités belges). Une belle application rendant tous ces parcours est
> https://hiking.waymarkedtrails.org/.
>
> Happy mapping,
>
> juminet
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-fr] Diagramme de transport publique

[Gad Jo]

Je m'attendais à obtenir une ligne avec une boucle comme ce qui est obtenu sur 
la ville de Bern. La ligne aller et la seconde boucle la ligne retour quand les 
arrêts sont différents (nom différent)

Je me doute que le problème viens de la façon dont les arrêts sont répertorié 
dans la relation

J'ai repris les recommandations du schéma v2 public transport où on indique 
l'emplacement où attendent les passagers. 
Sur certains arrêt l'emplacement où s'arrête les véhicules est éloigné l'un de 
l'autre. Il n'est pas impossible que j'ai fait de l'excès de zèle quand les 
stop_position sont de part et d'autre d'une intersection. 
Cela génère deux attentes pour passagers (normal, un de chaque côté) mais 
parfois deux stop_position (arrêt distant de 10 à 150m ou sur voie à sens 
unique).

À moins que ce ne soit pas du tout la cause. Je découvre cet outils

Le August 18, 2020 4:23:14 PM UTC, osm.sanspourr...@spamgourmet.com a écrit :
>Autnat dire ce que tu obtiens, ça évite de rechercher :
>
>https://overpass-api.de/api/sketch-line?ref=15=Citibus
>
>
>Tu as regardé pourquoi certains arrêts sont en double ?
>Bus 15 : Port Leucate - Grande Bleue → Leucate La Franqui - Office du
>Tourisme (6801854) 
>Bus 15 : Port Leucate
>-
>Grande Bleue → Narbonne - Bonne Source (11488167)
>
>
>Bus 15 : Leucate La Franqui - Las Pitchinos → Port Leucate - Grande
>Bleue (11488166)
>Bus 15 : Narbonne - Bonne Source → Port Leucate - Grande Bleue
>(6801852)
>
>
>Donc c'est un Y que tu veux voir comme un I ? ;-).
>
>Qaund je regarde
>https://s3.cloud.actigraph.com/citibus/upload/Plans/2019-Plan_Periurbain.pdf
>
>je ne vois qu'une branche.
>
>
>Le 18/08/2020 à 17:09, Percherie OnDaNet - perche...@toutenkamion.net a
>écrit :
>> Bonjour,
>>
>>
>> Je suis en train de finaliser le réseau de transport en commun sur
>> Narbonne (hors transport scolaire) et je cherche à faire afficher les
>> diagrammes de chaque ligne de la même façon que sur
>> https://overpass-api.de/api/sketch-line?ref=10=Libero
>>
>> Sur la relation route_master n° 4113572 à Bern (Suisse) :
>> https://www.openstreetmap.org/relation/4113572
>> le diagramme fonctionne tel quel avec un brin pour chaque sens car
>les
>> arrêts ne sont pas identique à l'aller et au retour.
>>
>> Sur la relation route_master n° 6743131 à Narbonne (France) :
>> https://www.openstreetmap.org/relation/6743131
>> le diagramme ne s'affiche pas de la même manière, je m'attendait à
>> voir un brin pour chaque sens départ/terminus
>>
>> J'ai quelques essais infructueux via le formulaire disponible sur
>> https://overpass-api.de/public_transport.html mais sans succès.
>>
>> Comment faire en sorte pour que la relation présente de la ligne 15
>> sur Narbonne affiche un diagramme similaire à celui de la ligne 10
>sur
>> Bern (Suisse) ?
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-de] Starrflügel-Drohne für Luftbilder

[Jo]

Heute würde ich ein Drone kaufen das 250 gram wiegt. Leider muss man dann
aber selber fliegen. Es gibt noch kein Software um die automatisch ein Pfad
fliegen zu lassen. Die machen jedenfalls auch nicht viel Lärm, fliegen
halbe Stunde und schaffen es um fotos zu machen die benutzbar sind für
OpenDroneMap.

Es ist aber viel einfacher um dann die Zulassung zu bekommen. Es kann sein
dass das nur wichtig ist in Belgien. Mit meines (900g) darf ich hier nur
10m hoch fliegen und das reicht ja nicht für Luftbilder.

Polyglot

On Fri, Aug 14, 2020 at 1:10 PM Frederik Ramm  wrote:

> Hallo,
>
> On 14.08.20 12:52, dktue wrote:
> > Muss es denn ein Starrflügler sein, falls ja, warum? Quadrokopter
> > schaffen heute auch 30 Minuten, sind günstig und Software die autonom
> > ein Polygon abzeilt gibt es auch.
>
> Das wäre schon auch interessant. Ich dachte, dass Starrflügler leiser
> sind und ruhiger fliegen und daher vermutlich besser geeignet sind. Hast
> Du denn mit einem bestimmten Quadrokopter/einer bestimmten Software gute
> Erfahrungen gemacht?
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
>
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk-fr] Chantiers d'été pour OSM-FR ;)

[Gad Jo]

Super Christian

Voici quelques retours

Selon leur orientation Le rendu des escaliers est étrange 
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#20/43.18428/3.00210

Le rendu des bâtit apparaît comme un gros monobloc. Il devient impossible de 
différencier les monuments, administration et tout autres bâti qui n'est pas 
une habitation 
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#19/43.18426/3.00377

Le nom Les Halles apparaît deux fois 
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#19/43.18133/3.00509

Facultatif : les caméras de surveillance n'apparaissent pas. À tester si ça 
'alourdi pas le rendu

Plus difficile La référence des route apparaît autant de fois qu'il y a de 
section entre giratoire comme sur le contournement D 6009a. Je sais que c'est 
très complexe mais l'afficher une seule fois ET dans l'axe de la voie serait 
parfait surtout pour la D 68 
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#13/43.1929/3.0236
Parfois c'est affiché de multiples fois et sur une grande section il n'y a plus 
d'information comme pour la D 6009 côté ouest et nord 
https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#13/43.1922/2.9816



Le August 10, 2020 8:32:08 PM UTC, osm.sanspourr...@spamgourmet.com a écrit :
>Tu veux supprimer la crête et les autres îles.
>
>Avec le réchauffement climatique ça va se réparer tout seul :-(.
>
>Le 10/08/2020 à 18:48, Adrien via Talk-fr - talk-fr@openstreetmap.org a
>écrit :
>> Autre léger bug : la mer de Kara, au nord de la Russie, apparait,
>> disparait, puis réapparait en zoomant. Voici sa disparition :
>>
>>
>https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#3/60.54/59.94
>>
>> Adrien
>>
>> Le 10/08/2020 à 18:41, Adrien a écrit :
>>> Bonjour,
>>>
>>> Merci pour ce rendu !!
>>>
>>> Par contre, la Méditerranée bien tard : à ce zoom, le Golfe du Lion
>ou
>>> la mer d'Alboran apparaissent bien, mais il faut zoomer encore pour
>>> avoir le nom « Méditerranée » :
>>>
>>>
>https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#4/44.68/11.16
>>>
>>> Bonne journée
>>>
>>> Adrien
>>>
>>> Le 09/08/2020 à 23:18, Christian Quest a écrit :
 Le 05/08/2020 à 19:42, Jérôme Amagat a écrit :
>>> Les mers, baies et détroits (place=sea, natural=bay,
>>> natural=strait) en surfacique pourraient avoir leur nom qui
>>> apparaissent pour les mer et détroit et plus tôt lorsqu'ils sont
>>> très grands pour les baies qui sont déjà rendu.
>>> exemple : le golfe du lion
>>> https://www.openstreetmap.org/relation/9287303
>>>
>http://tile.openstreetmap.fr/?zoom=11=42.99137=4.17341=B
>>>
 Voilà les océans, mers, baies, détroits maintenant visibles sur le
 rendu FR :)

 L'occasion de découvrir le tag sqkm=* qui indique sur un objet
 ponctuel sa superficie approximative en km².

 Ceci permet de prioriser ces objets et c'est bien pratique !

 Tag documenté sur le wiki en 2016.


 Vous pouvez voir ce que ça donne (avec les améliorations
>précédentes)
 sur:


>https://umap.openstreetmap.fr/fr/map/rendu-fr-en-developpement_483858#2/0/0


 C'est un accès direct au rendu en cours de dev (chez moi, pas dispo
 H24 et recalculs non continus).


 L'occasion d'améliorer quelques name: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

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Gad Jo]

Depuis plusieurs semaine j'utilise un script permettant de faire une copie chez 
openstreetcam sans passer par ma connexion ADSL : 
https://osm.svimik.com/photosync/
Manque plus que le transferts OSC vers Mapillary pour que je passe à la capture 
avec l'application OSC.

D'un je n'ai pas les moyens physique et technique pour les stocker (Merci 
Christian pour ta proposition de backup) puis les redéployer ailleurs (pas de 
fibre).
Quitte à les récupérer autant que ça alimente un service déjà fonctionnel

Christian je reste intéressé par ta proposition de backup mais j'ai préféré le 
faire ailleurs pour que ça profite au plus grand nombre... Et l'espace n'étant 
pas extensible je préfère économiser les ressources fournies par un particulier 
pour solliciter de manière plus intensive celle d'une entreprise. Dès qu'un 
usage applicatif sera mise en place je serai de la partie.

Faite un essai sur https://osm.svimik.com/photosync/ pour vous faire une idée

Le August 10, 2020 9:08:52 AM UTC, Christian Quest  a 
écrit :
>Le 10/08/2020 à 10:31, Axel Listes a écrit :
>> Bonjour,
>>
>> Le 19/06/2020 à 12:25, Laurence P a écrit :
>>> Mapillary était un service très pratique, mais il n'est pas
>>> indispensable. Lors que j'ai effectué mes premières prises de vue,
>cela
>>> me posait déjà un cas de conscience : est ce que le monde doit être
>>> photographié sous ses moindre coutures ? / Stocker toutes ces photos
>>> c'est pas écolo / Aider une société qui va aider au développement
>des
>>> véhicules autonomes est-ce bien raisonnable ? ...
>> Pour les mêmes raisons, je voudrais moi aussi supprimer toutes mes
>> photos téléversées ces dernières années sur Mapillary.
>
>
>Tu as accepté de mettre ces photos sous licence CC, c'est irrévocable
>
>Il serait bon de ne pas perdre de vue les principes des licences libre.
>
>Demander à Mapillary de les supprimer, revient à les rendre 
>indisponibles pour tous, sauf pour eux (because licence irrévocable). 
>C'est donc contre-productif.
>
>
>> J'ai anticipé en les téléversant sur OpenStreetCam, que j'avais déjà
>> utilisé parallèlement au débit puis abandonné, car la plateforme
>> générait des erreurs.
>>
>> Aujourd'hui, je voudrais remplacer des sources mapillary=* par
>> OpenStreetCam dans la base de données OSM. Mais je ne trouve pas de
>doc
>> à ce sujet, j'ignore si les liens et références que donne OSC sont
>> pérennes ?
>>
>> Certain·e·s ont déjà réalisé des recherches à ce sujet ?
>>
>> https://wiki.openstreetmap.org/wiki/FR:Key:mapillary
>>
>> Axel.
>
>
>Tu peux récupérer tes photos en plein définition chez mapillary.
>
>Nous avons mis en place un petit service qui s'occupe de ça et en 
>conserve donc une copie d'archive.
>
>C'est ici (et il reste quelques To): 
>https://takeitout.cquest.org/mapillary_takeout
>
>Le problème étant surtoutqu'on n'est pas à l'abri d'un changement de 
>politique de Mapillary sur l'accès libre aux photos déposées depuis des
>
>années, c'est l'intérêt d'avoir une archive. OpenStreetCam n'est pas 
>plus fiable (racheté aussi par une société pas très culture OSM).
>
>
>Pour les tags, on a justement une discussion à ce sujet en ce moment en
>
>lien avec les DAE.
>
>Faudrait-il archiver les photos qui sont derrière les tags image=* ou 
>mapillary=* ?
>
>
>-- 
>Christian Quest - OpenStreetMap France
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-be] Mapping disapPeared vicinal paths

[Jo]

Meerdaalwoud is mapped quite well. I think we are at least 3 experienced
mappers doing so. Not always easy with aerial imagery alone and GPX gets
distorted, although that has improved a lot over the past 10 years.

I'm afraid there is not much chance to still find this person alive now,
after more than 2 weeks of intensive searching.


Jo

On Sun, Aug 9, 2020, 14:27 Philippe Casteleyn 
wrote:

> Recently I was searching for a disappeared  person in the woods.
>
> Looking at OSMAnd I advised the group leader that we could split a search
> parcel in two because the small  path went to the next wider path.
>
> I was happy that I was luckily correct.
>
> In my region (Mechelen) I have seen that not all ditches are mapped.  I
> find them difficult to map.
>
> Neither are fences.
>
>
>
> The person is still missing.
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk] Proposal for Software Dispute Resolution Panel

[Jo]

I support your nomination. You're a really good candidate for it. I would
propose myself, but I don't, as I have almost zero experience with using iD.

Polyglot

On Thu, Aug 6, 2020, 06:47 Roland Olbricht  wrote:

> Hello,
>
> first of all I'm glad to read that the board addresses the sudden
> funding hole for iD, and does in addition care about the critique around
> iD.
>
> I would like to self-nominate for the software dispute resolution panel.
>
> For my understanding of the task please (re-)read
> https://lists.openstreetmap.org/pipermail/osmf-talk/2020-June/006909.html
> tl;dr: There is no silver bullet, hence no team of experts is going to
> find one. Conflict resolution is painful work for all involved, but it
> also likely to yield insight and an improved software. I see a panel's
> member's job in encouraging the involved people to keep walking through
> the resolution process.
>
> I also promise resp. reserve the right to share or paraphrase (for the
> purpse of removing personal issues) all communications regarding the
> nomination process. There have been concerns about whether the
> nomination process is balanced and being open is the best way to address
> them. On a personal note: I have no doubts it is, and the artifacts we
> currenty encounter are consistent with a board intensely keeping many
> trains in their rails in parallel.
>
> Regarding potential CoI:
> - I develop the Overpass API but it is intentionally tag agnostic.
> - I do not plan to put the Overpass API under the panel regime.
> Thus, I do not expect any CoI from my contributions as developer to
> OpenStreetMap.
>
> Best regards,
> Roland
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Aire du viaduc de Millau

[Gad Jo]

Pour l'aire des Pyrénées même en sélectionnant la station de carburant qui est 
bien au milieu entre les deux voies d'accès je retrouve le même problèmes

Si on part de l'ouest ça rallonge le trajet de 25 km. Magnifique pour celui qui 
se trouve en rade de carburant et qui change sa destination pendant son trajet

Idéalement les panneaux de direction font foie mais j'ai constaté comme 
passager que dans la pratique pas mal de gens inexpérimenté préfère suivre les 
indications de leurs appareils ou bien hésite quitte à avoir une conduite 
dangereuse pour les autres (OK go je file à l'aire au dernier moment maintenant 
que j'ai compris que mon GPS fait de la merde... Oups désolé pour la queue de 
poisson)

Le August 5, 2020 9:06:40 PM UTC, Ruboqif  a écrit :
>Bonsoir,
>Avez-vous regardé les autres aires de repos avec la même configuration 
>pour voir comment elles sont taguées ? ça peut donner des idées pour 
>celle de Millau ou au contraire c'est le même soucis pour toutes les
>aires ?
>Il n'y en a pas des masses avec exactement la même configuration 
>(passage impossible de "l'autre coté" en voiture) mais il y en a 
>quelques-unes.
>Par exemple sur l'A64 :
>Aire d'Hastingues : https://www.openstreetmap.org/way/473891861
>Aire des Pyrénées https://www.openstreetmap.org/way/473888794
>Aire du Comminges : https://www.openstreetmap.org/way/500070724
>
>Pour en trouver d'autres : 
>https://routes.fandom.com/wiki/Aire_de_service à la rubrique "Celles 
>accessibles dans les deux sens"
>
>
>Le 05/08/2020 à 21:25, Gad Jo a écrit :
>> Pas facile de gérer cette aire de repos
>>
>> J'ai essayé de plaçant la destination sur la boutique de souvenir
>plus 
>> ou moins au sud. À quelques mètre ça fonctionne en arrivant du nord 
>> mais depuis le sud cela propose un nouveau détour
>>
>> Je sèche pour trouver une solution propre, compréhensible et en
>accord 
>> avec le terrain
>>
>> Au passage sur place le tag place=* avec name=Brocuéjouls n'a pas été
>
>> trouvé. Ça ressemble à une bâtisse de restauration mais c'est 
>> uniquement de la vente de souvenir
>>
>> Le August 5, 2020 3:23:56 PM UTC, "Jérôme Amagat" 
>>  a écrit :
>>
>> J'ai modifié un peu la géometrie
>> https://www.openstreetmap.org/way/434996171 pour qu'elle cole
>plus
>> au terrain mais ca ne devrait pas changé le problème.
>> Je pense que le problème vient du faite que le polygon est
>> transformé en un point au centre donc comme il y a des barrières
>> pour ne pas faire demi tour sur l'aire
>> (https://www.openstreetmap.org/node/2920654534) pour le GPS il
>> faut entrer sur l'aire dans l'autre sens pour arriver plus près
>du
>> point.
>>
>> Le probleme est le même pour d'autres aire du meme genre,
>> https://www.openstreetmap.org/way/434996170 ou
>> https://www.openstreetmap.org/way/185442798
>> Dans ces 2 cas je pense qu'il faudrait coupé l'aire en 2, une de
>> chaque côté de l'autoroute mais si elles ont le même nom, le GPS
>> va t il choisir le bon ?
>>
>> La solution pour Millau, soit diviser en 2 l'aire, il y a 2 aires
>> du point de vu de la voiture, vu que l'on ne peut pas passer d'un
>> côté à l'autre...
>> ou supprimer la barrière...
>> Ou ce que je préfère attendre que le GPS gère mieux ces cas.
>>
>> Si on remplace par un node, je pense qu'on aura toujours le
>> problème, dans un sens ou dans l'autre de l'autoroute.
>>
>>
>> -- 
>> Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma 
>> brièveté.
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Aire du viaduc de Millau

[Gad Jo]

Bonne idée de comparer


Je viens de faire un essais sur l'aire d'hastingues et le problèmes est 
identique même en pointant au milieu de la surface entouré de sentier présent à 
l'est de l'aire

Dans le doute j'ai testé avec openrouteservice et lui aussi est en échec

Le August 5, 2020 9:06:40 PM UTC, Ruboqif  a écrit :
>Bonsoir,
>Avez-vous regardé les autres aires de repos avec la même configuration 
>pour voir comment elles sont taguées ? ça peut donner des idées pour 
>celle de Millau ou au contraire c'est le même soucis pour toutes les
>aires ?
>Il n'y en a pas des masses avec exactement la même configuration 
>(passage impossible de "l'autre coté" en voiture) mais il y en a 
>quelques-unes.
>Par exemple sur l'A64 :
>Aire d'Hastingues : https://www.openstreetmap.org/way/473891861
>Aire des Pyrénées https://www.openstreetmap.org/way/473888794
>Aire du Comminges : https://www.openstreetmap.org/way/500070724
>
>Pour en trouver d'autres : 
>https://routes.fandom.com/wiki/Aire_de_service à la rubrique "Celles 
>accessibles dans les deux sens"
>
>
>Le 05/08/2020 à 21:25, Gad Jo a écrit :
>> Pas facile de gérer cette aire de repos
>>
>> J'ai essayé de plaçant la destination sur la boutique de souvenir
>plus 
>> ou moins au sud. À quelques mètre ça fonctionne en arrivant du nord 
>> mais depuis le sud cela propose un nouveau détour
>>
>> Je sèche pour trouver une solution propre, compréhensible et en
>accord 
>> avec le terrain
>>
>> Au passage sur place le tag place=* avec name=Brocuéjouls n'a pas été
>
>> trouvé. Ça ressemble à une bâtisse de restauration mais c'est 
>> uniquement de la vente de souvenir
>>
>> Le August 5, 2020 3:23:56 PM UTC, "Jérôme Amagat" 
>>  a écrit :
>>
>> J'ai modifié un peu la géometrie
>> https://www.openstreetmap.org/way/434996171 pour qu'elle cole
>plus
>> au terrain mais ca ne devrait pas changé le problème.
>> Je pense que le problème vient du faite que le polygon est
>> transformé en un point au centre donc comme il y a des barrières
>> pour ne pas faire demi tour sur l'aire
>> (https://www.openstreetmap.org/node/2920654534) pour le GPS il
>> faut entrer sur l'aire dans l'autre sens pour arriver plus près
>du
>> point.
>>
>> Le probleme est le même pour d'autres aire du meme genre,
>> https://www.openstreetmap.org/way/434996170 ou
>> https://www.openstreetmap.org/way/185442798
>> Dans ces 2 cas je pense qu'il faudrait coupé l'aire en 2, une de
>> chaque côté de l'autoroute mais si elles ont le même nom, le GPS
>> va t il choisir le bon ?
>>
>> La solution pour Millau, soit diviser en 2 l'aire, il y a 2 aires
>> du point de vu de la voiture, vu que l'on ne peut pas passer d'un
>> côté à l'autre...
>> ou supprimer la barrière...
>> Ou ce que je préfère attendre que le GPS gère mieux ces cas.
>>
>> Si on remplace par un node, je pense qu'on aura toujours le
>> problème, dans un sens ou dans l'autre de l'autoroute.
>>
>>
>> -- 
>> Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma 
>> brièveté.
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Aire du viaduc de Millau

[Gad Jo]

Pas facile de gérer cette aire de repos

J'ai essayé de plaçant la destination sur la boutique de souvenir plus ou moins 
au sud. À quelques mètre ça fonctionne en arrivant du nord mais depuis le sud 
cela propose un nouveau détour

Je sèche pour trouver une solution propre, compréhensible et en accord avec le 
terrain

Au passage sur place le tag place=* avec name=Brocuéjouls n'a pas été trouvé. 
Ça ressemble à une bâtisse de restauration mais c'est uniquement de la vente de 
souvenir

Le August 5, 2020 3:23:56 PM UTC, "Jérôme Amagat"  a 
écrit :
>J'ai modifié un peu la géometrie
>https://www.openstreetmap.org/way/434996171
>pour qu'elle cole plus au terrain mais ca ne devrait pas changé le
>problème.
>Je pense que le problème vient du faite que le polygon est transformé
>en un
>point au centre donc comme il y a des barrières pour ne pas faire demi
>tour
>sur l'aire (https://www.openstreetmap.org/node/2920654534) pour le GPS
>il
>faut entrer sur l'aire dans l'autre sens pour arriver plus près du
>point.
>
>Le probleme est le même pour d'autres aire du meme genre,
>https://www.openstreetmap.org/way/434996170 ou
>https://www.openstreetmap.org/way/185442798
>Dans ces 2 cas je pense qu'il faudrait coupé l'aire en 2, une de chaque
>côté de l'autoroute mais si elles ont le même nom, le GPS va t il
>choisir
>le bon ?
>
>La solution pour Millau, soit diviser en 2 l'aire, il y a 2 aires du
>point
>de vu de la voiture, vu que l'on ne peut pas passer d'un côté à
>l'autre...
>ou supprimer la barrière...
>Ou ce que je préfère attendre que le GPS gère mieux ces cas.
>
>Si on remplace par un node, je pense qu'on aura toujours le problème,
>dans
>un sens ou dans l'autre de l'autoroute.

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-be] Help to young active men in kivu

[Jo]

If you need someone to teach JOSM online, I can help with that. I can't do
much about prices for internet access.

Polyglot

On Wed, Aug 5, 2020, 13:02 CHAVEZ CIKURU  wrote:

> Hello Prof. Nicolas, Hello Georges, Hello everyone.
>
> Hope you are well.
>
> Here in Kivu, we already use Telegram a lot, we had difficulties being
> able to create accounts on Riot.
>
> In KIVU as in the whole of the national territory, these are the foreign
> communication companies (VODACOM, ORANGE, AIRTEL and AFRICEL in Kinshasa)
> which provide us with the connection, and this is what causes it to have
> the prices high levels of Internet access due to much higher taxes and the
> weak control of the Congolese authorities on the sale of Internet packages,
> weak control of consumption, etc.
>
> I also don't know what the cost of opening a regional service
> communication with Riot can be; maybe it can be done independently without
> accepting the terms of VODACOM, ORANGE or AIRTEL. On this issue, I want to
> try to contact these different companies for clarification.
>
> I wish you a good day and good work.
>
> Yours truly.
>
> Alain
>
> Le ven. 31 juil. 2020 à 14:02, Georges Khaznadar <
> georges.khazna...@free.fr> a écrit :
>
>> Hello Nicolas, hello everybody,
>>
>> using Riot rather than Telegram does not change much when one cannot
>> master the web servers which are providing the service.
>>
>> As far as I undestood, the high prices of Internet access in Kivu are
>> due to foreign companies trusting the scarse hardware network.
>>
>> If I live in Kivu, and if I want to create a small communication
>> company, what would be the cost of opening a regional communication
>> service, eventually featuring Riot? Can I do it independently, or must I
>> accept the conditions of Orange, Airtel or Vodacom?
>>
>> Best regards,   Georges.
>>
>> Nicolas Pettiaux a écrit :
>> > Hello,
>> >
>> > A team of active young men in kivu with very limited internet access
>> are looking for help to map better their city of Bukavu and surroundings.
>> >
>> > They have smatphones and expensive connections with low bandwidth.
>> >
>> > They use telegram and email, but I don't know for riot.
>> >
>> > Some are in cc and more are on the mailing list k...@educode.ne
>> >
>> > Much thanks to everyone who van guide and help thème better than I can
>> or do.
>> >
>> > Regards,
>> >
>> > Nicolas
>> >
>> > --
>> > Nicolas Pettiaux
>> > --
>> > Nicolas Pettiaux, PhD - tel +32.496.24.55.01
>> > Collaborer pour mieux enseigner - https://wiki.educode.be
>> > Educode accompagne les écoles face aux défis du numérique
>> > Envoyé de mon fairphone - veuillez excuser la brièveté
>> >
>>
>> --
>> Georges KHAZNADAR et Jocelyne FOURNIER
>> 22 rue des mouettes, 59240 Dunkerque France.
>> Téléphone +33 (0)3 28 29 17 70
>>
>>
>
> --
>
> *CIKURU KAMERA Alain Chavez*
>
> Technicien en Développement Rural et consultant en matière de développement
>
> *Adresse* : *55, Av. Cibera/A, Q. Nkafu, C. Kadutu, Ville de Bukavu RD.
> Congo*
>
> *Tél* : +243 97 57 57 359, +243 85 23 36 465
>
> *Skype* : Alain Chavez Cikuru Kamera
>
> *Linkedln* : Chavez Alain Cikuru Kamera
>
> *Facebook* : Alain Kamera Cikuru Chavez
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

[Gad Jo]

Je me suis mal exprimé

L'analyse Osmose serait pour les point d'entrée de ville. Pas pour les way qui 
ne respecte pas les admin_level existant

Si ça peut permettre de placer les panneaux d'entrée/sortie de commune ce 
serait pas mal (et autres infos placée au même endroit)

Le August 4, 2020 7:13:56 AM UTC, osm.sanspourr...@spamgourmet.com a écrit :
> > Au lieu de supprimer autant de nœud, pourquoi ne pas remonter cette
>anomalie vers Osmose pour ajouter un nouveau contrôle ?
>
>Peut-être parce que la seule possibilité c'est de supprimer cette
>infox.
>
>Sur les 4639 points ajoutés par notre ami, approximativement 703 sont
>sur des highway (703 routes passent par ces points).
>
>Concernant 4 000 points environ : on a l'information que le
>contributeur
>a estimé que la limite urbaine c'était par là (au vue d'une imagerie
>_aérienne_ comme si les limites correspondaient forcément !).
>
>Absolument pas parce qu'il y a un panneau là.
>
>Donc tu fais quoi ? Tu regardes une imagerie de rue pour voir s'il y a
>un panneau dans le coin ?
>
>Non, supprimer ces 4 000 points c'est hélas la bonne solution.
>
>À ne pas confondre avec le cas de Florian (il a vu le panneau et a mis
>la limite non au niveau de la route mais au niveau du panneau, il peut
>mettre à jour sans problème).
>
>Jean-Yvon
>
>
>Le 04/08/2020 à 07:28, Gad Jo - perche...@toutenkamion.net a écrit :
>>
>>
>> Je suis sûr que d'autre contributeur en ont créé de la même façon et
>> qu'il pourraient bénéficier de ce type de correction.
>> Au passage ça évite les suppression accidentelle de nœud où d'autres
>> tag seraient ajoutés (honnêtement ça m'étonnerait mais autant
>prévoir).
>>
>> Le August 3, 2020 10:05:46 AM UTC, Romain MEHUT
>>  a écrit :
>>
>> Je viens d'envoyer un message par la messagerie interne
>d'osm.org.
>> J'attends donc encore un peu avant de passer au
>> traffic_sign=city_limit.
>>
>> Romain
>>
>>> De : Christian Quest 
>>> À : talk-fr@openstreetmap.org
>>> Sujet : Re: [OSM-talk-fr] {Disarmed} Re: Pourquoi inventer un
>>> aire urbaine imaginaire ?
>>> Date : 03/08/2020 09:00:10 Europe/Paris
>>>
>>> Le 02/08/2020 à 22:51, Romain MEHUT a écrit :
>>> > Les hésitations ont trop duré, c'est souvent le problème dans
>>> OSM, on
>>> > n'ose pas toujours pour ne pas froisser des susceptibilités.
>Je
>>> n'ai
>>> > rien contre le tag boundary=urban, c'est juste que dans le cas
>>> > présent, son emploi s'est fait sans tenir compte des données
>déjà
>>> > présentes...
>>> >
>>> > Romain
>>> >
>>> Pour ça que la première chose à faire est de prendre contact
>avec le
>>> contributeur avant de faire la modification massive, surtout
>>> quand c'est
>>> un régulier comme ici.
>>>
>>>
>>> --
>>> Christian Quest - OpenStreetMap France
>>>
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>> --
>> Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma
>> brièveté.
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Aire du viaduc de Millau

[Gad Jo]

Bonsoir,


En rentrant de Clermont-Ferrand pour aller vers le sud avec une halte à l'aire 
du viaduc de Millau j'ai eu droit à une belle erreur de routage.
J'étais invité à descendre 15km plus au sud en ignorant l'aire pour remonter 
vers le nord et rejoindre l'aire

Après simulation avec Osmand, il s'avère que l'aire est en fait composé de deux 
aires de repos. Les véhicules ne peuvent pas changer d'aire (portail visible à 
fort zoom) mais les piétons peuvent le faire pour admirer le point de vue.
Dans les fait, l'intitulé de l'aire sélectionne celle dans le sens sud-nord. 
Pour l'autre sens il ne faut pas sélectionner l'aire du viaduc de Millau mais 
placer l'étape dans le parking existant au sud.

Sachant qu'on ne tague pas pour le rendu mais que beaucoup d'utilisateur 
peuvent rencontrer la même erreur (j'ai pesté grave et ma chérie a sortie 
GoogleMaps + Waze), comment corriger cela ?
Identifier deux aires ? Sur le terrain il y a qu'un seul nom mais ça à le 
mérite d'être compréhensible
Revoir la géométrie de l'aire pour que le barycentre soit mieux placer ? Pas 
sûr que ça tienne sur le long ou très long terme
Créer une relation ou multipolygone avec un nœud comme centre ? Cela risque de 
complexifier les modifications pour les nouveaux au risque que des doublons 
soient ajouter

Là je sèche... Si vous avez des suggestions je prend

PS : le bug existait l'année dernière mais j'ai accusé les applications sans 
regarder la carte. Cette fois ci j'avais placé un marqueur au sud de l'aire 
(pour le sens nord-sud) mais j'arrivai de l'autre sensm (sud-nord)... Résulta 
je ne m'y suis jamais arrêté à cause d'un gros détour à 5 km au nord pour 
revenir dans le sud Fallait savoir que l'aire était séparée en deux. De 
loin ça à l'aire d'une grosse aire qui n'en manque pas (de l'air)
-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Gad Jo]

Au lieu de supprimer autant de nœud, pourquoi ne pas remonter cette anomalie 
vers Osmose pour ajouter un nouveau contrôle ?

Je suis sûr que d'autre contributeur en ont créé de la même façon et qu'il 
pourraient bénéficier de ce type de correction.
Au passage ça évite les suppression accidentelle de nœud où d'autres tag 
seraient ajoutés (honnêtement ça m'étonnerait mais autant prévoir).

Le August 3, 2020 10:05:46 AM UTC, Romain MEHUT  a 
écrit :
>Je viens d'envoyer un message par la messagerie interne d'osm.org.
>J'attends donc encore un peu avant de passer au
>traffic_sign=city_limit.
>
>
>
>Romain
>
>
>De : Christian Quest 
>À : talk-fr@openstreetmap.org
>Sujet : Re: [OSM-talk-fr] {Disarmed} Re: Pourquoi inventer un aire
>urbaine imaginaire ?
>Date : 03/08/2020 09:00:10 Europe/Paris
>
>Le 02/08/2020 à 22:51, Romain MEHUT a écrit :
>> Les hésitations ont trop duré, c'est souvent le problème dans OSM, on
>
>> n'ose pas toujours pour ne pas froisser des susceptibilités. Je n'ai 
>> rien contre le tag boundary=urban, c'est juste que dans le cas 
>> présent, son emploi s'est fait sans tenir compte des données déjà 
>> présentes...
>>
>> Romain
>>
>Pour ça que la première chose à faire est de prendre contact avec le 
>contributeur avant de faire la modification massive, surtout quand
>c'est 
>un régulier comme ici.
>
>
>-- 
>Christian Quest - OpenStreetMap France
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] [Osmf-talk] Funding of iD Development and Maintenance

[Jo]

The way I read this, is that there is money that will be used toward
advancing the 3 projects and funding is being sought to finance continued
development of iD. So I'd say there is a difference.

I take it all as good news. Of course, I would also like to see some
financial support for JOSM and Vespucci, but one can only spend each
euro/dollar/pound once, so choices must be made.

Polyglot

On Sun, Aug 2, 2020 at 2:53 PM JB  wrote:

> So, with sarcasm (at least half-)on, and english not being my
> mothertongue: the osm2pgsql/Nomatim/Potlatch grants were just Troyan
> horses to enable the OSMF funding of (ex or not ex?) Mapbox developer,
> with contributors not screaming too loudly? And explaining the iD
> conflict resolution process that was proposed lately (and, surprise,
> accepted by Mapbox iD developers)?
> Much thanks to the iD developers for having kept long, trustful and
> peaceful relationships with the community over the years of iD development.
> Just saying out loud what some people may or may not think, but would
> not dare to write. It does not expect answers.
> JB.
>
> Le 02/08/2020 à 13:44, Mikel Maron a écrit :
> > Hello
> >
> > The OSMF board is working to make OSM's core software and infrastructure
> more stable and sustainable by supporting paid roles for priority needs,
> such as the Senior Site Reliability role (
> https://lists.openstreetmap.org/pipermail/osmf-talk/2020-July/006973.html),
> and the pilot to fund "OSM Infrastructure" projects (
> https://lists.openstreetmap.org/pipermail/osmf-talk/2020-August/006987.html
> ).
> >
> > As part of this focus, we want to organise coordinated funding to
> support continued maintenance and development of the iD editor, as iD's
> strong continuous development over the past several years has served the
> OSM community well. Quincy Morgan is iD's maintainer and lead developer.
> Unfortunately, full-time support of his work recently ended. He'd very much
> like to continue, and the OSMF Board wants to see that happen. He has
> written up this proposal (
> https://github.com/quincylvania/quincylvania.com/blob/main/resources/Morgan%20iD%20work%20proposal%207_27.pdf)
> with his ideal plans for iD over the next year, along with notes about how
> he'll organise, grow the developer base, communicate, and set priorities,
> and make iD better. The final priorities for the year will be made in
> consultation with the community.
> >
> > To help fund this project, as well as the SSRE role, we're looking at
> earmarked donations from companies, chapters and organisations.
> Administratively, we believe this is easier than other methods of pooled
> funding, as the OSMF is already in most companies' procurement systems, and
> it would limit paperwork to one contract for iD. Initial contract would be
> for 1 year, and that's what the OSMF would look to raise now.
> >
> > With the OSMF holding the contract, the Board would take a key
> accountability role, reviewing work done on the contract and assessing
> progress on the plans Quincy develops for the project. Additionally, the
> OSMF is working in cooperation with Quincy to establish a formal appeal
> process (
> https://blog.openstreetmap.org/2020/06/08/toward-resolution-of-controversies-related-to-id/)
> for the relatively rare community issues iD cannot resolve itself.
> >
> > The OSMF would not see its role as a traditional "boss", instructing iD
> to focus on this or that feature. We would not be prescriptive about
> priorities. This does not mean work in a vacuum. Our expectation is that
> Quincy, in addition to following our hiring framework's principles for
> transparent service to the community, would regularly convene stakeholders
> from the community to share their priorities and feedback. Quincy would
> assess all priorities holistically as he decides on a workable plan for the
> project.
> >
> > Over the course of the year, we'll evaluate and learn from how the
> arrangement is working for all, as we look towards year 2 and beyond. For
> future years, we are looking at developing an overall plan for long-term
> support for all parts of the OSMF infrastructure. We want to be able to
> offer similar support to other OSM editors. Our early focus on iD is to
> ensure continued development.
> >
> > We want to find out what you, the OSM community, think. Do you have any
> feedback?
> >
> > If you know of an organisation that might want to fund this, please feel
> free to ask them to contact the OSMF Board.
> >
> > -Mikel, for the OSMF Board
> >
> > * Mikel Maron * +14152835207 @mikel s:mikelmaron
> >
> > ___
> > osmf-talk mailing list
> > osmf-t...@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/osmf-talk
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org

Re: [OSM-talk-fr] Question sur la règle de nommage des rues

[Gad Jo]

Heuu justement l'erreur qui à fait que j'ai écris :-)
https://fr.m.wikipedia.org/wiki/Avenue_Pierre-de-Coubertin

Après si c'est extrêmement rare chez wikipedia mieux vaut conserver des 
ressources pour d'autres projets. C'était une réflexion à chaud.

Merci Christian pour ton retour fort clair et concis sur le changeset en 
espérant qu'il lira après les gros blocs d'explications précédent. 

Le July 22, 2020 1:48:43 PM UTC, Christian Quest  a 
écrit :
>Le 22/07/2020 à 14:57, Gad Jo a écrit :
>> Merci Christian, je pensai que je devenait fou mais c'était un 
>> contributeur néerlandais qui a pris pour argent comptant la toponymie
>
>> utilisée dans wikipedia.
>> Il aurait observé le nom des rues et des relations utilisé sur les 
>> rues il aurait eu un doute mais non... Il a fait ça un peu partout en
>
>> France.
>> C'est vraiment qu'on est des handicapés du bocal pour avoir fait la 
>> même erreur partout dans le pays :-)
>>
>> D'ailleurs est-il envisageable de remonter automatiquement ces
>erreurs 
>> de toponymie aux contributeur de wikipedia ou est-ce leur normes de 
>> nommage ? Si oui c'est dommage et complexifie la mutualisation de 
>> l'information.
>
>
>Quelle erreur sur wikipédia ?
>
>Exemple: https://fr.wikipedia.org/wiki/La_Celle-Saint-Cloud
>
>C'est ok pour moi.
>
>https://fr.m.wikipedia.org/wiki/Avenue_Pierre-de-Coubertin par contre
>ne 
>me semble pas correct vu que 
>https://fr.m.wikipedia.org/wiki/Pierre_de_Coubertin
>
>Erreur de wikipedia, la source officielle (opendata.paris.fr): "Avenue 
>Pierre de Coubertin" 
>https://opendata.paris.fr/explore/dataset/voie/table/?q=coubertin
>
>
>-- 
>Christian Quest - OpenStreetMap France

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Question sur la règle de nommage des rues

[Gad Jo]

Merci Christian, je pensai que je devenait fou mais c'était un contributeur 
néerlandais qui a pris pour argent comptant la toponymie utilisée dans 
wikipedia.
Il aurait observé le nom des rues et des relations utilisé sur les rues il 
aurait eu un doute mais non... Il a fait ça un peu partout en France.
C'est vraiment qu'on est des handicapés du bocal pour avoir fait la même erreur 
partout dans le pays :-)

D'ailleurs est-il envisageable de remonter automatiquement ces erreurs de 
toponymie aux contributeur de wikipedia ou est-ce leur normes de nommage ? Si 
oui c'est dommage et complexifie la mutualisation de l'information.

Le July 22, 2020 9:23:47 AM UTC, Christian Quest  a 
écrit :
>Le 21/07/2020 à 20:32, Gad Jo a écrit :
>> Bonsoir,
>>
>> Suite à un changement sur quelques rues j'ai contacté le contributeur
>
>> comme quoi on met des tirets entre les mots généralement sur les 
>> villes ou après le mot saint(e)... C'est n'est pas exhaustif bien
>sûr.
>>
>> Suite à sa réponse il me met le doute quand il me renvoie vers 
>> l'orthographe utilisé sur wikipedia. J'aurai besoin d'information et 
>> par défaut je préfère toujours me dire que j'ai tort et vérifier
>avant 
>> de répondre
>>
>> La discutions est sur ce changeset 
>>
>https://www.openstreetmap.org/changeset/88176811#map=15/43.1820/3.0232
>>
>> Quelle est la réponse approprié ?
>> -- 
>
>On n'ajoute pas de traits d'union dans les noms (sauf là où ils sont 
>normaux: Saint-Glinglin, Jean-Pierre, etc).
>
>Exception: la règle de toponymie pour les noms officiels des communes
>
>Là il y a des traits d'union partout, sauf après l'article initial:
>
>- Saint-Maur-des-Fossés
>
>- La Celle-Saint-Cloud
>
>
>Dans la zone du changeset je vois une "Rue Etienne-Gaillard", le trait 
>d'union ne devrait pas y figurer.
>
>-- 
>Christian Quest - OpenStreetMap France
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Question sur la règle de nommage des rues

[Gad Jo]

Cool,

Qu'est ce qui l'a induit en erreur ? Je n'ai pas bien compris sa démarche

Le July 21, 2020 7:12:34 PM UTC, Romain MEHUT  a écrit :
>Bonsoir,
>
>
>
>J'ai contacté également ce contributeur
>https://www.openstreetmap.org/changeset/88176435 et au final j'ai
>annulé ses contributions récentes.
>
>
>
>Romain
>
>
>De : Gad Jo 
>À : talk-fr@openstreetmap.org
>Sujet : [OSM-talk-fr] Question sur la règle de nommage des rues
>Date : 21/07/2020 20:32:06 Europe/Paris
>
>Bonsoir,
>
>Suite à un changement sur quelques rues j'ai contacté le contributeur
>comme quoi on met des tirets entre les mots généralement sur les villes
>ou après le mot saint(e)... C'est n'est pas exhaustif bien sûr.
>
>Suite à sa réponse il me met le doute quand il me renvoie vers
>l'orthographe utilisé sur wikipedia. J'aurai besoin d'information et
>par défaut je préfère toujours me dire que j'ai tort et vérifier avant
>de répondre
>
>La discutions est sur ce changeset
>https://www.openstreetmap.org/changeset/88176811#map=15/43.1820/3.0232
>
>Quelle est la réponse approprié ?
>-- 
>Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma
>brièveté. ___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Question sur la règle de nommage des rues

[Gad Jo]

Bonsoir,

Suite à un changement sur quelques rues j'ai contacté le contributeur comme 
quoi on met des tirets entre les mots généralement sur les villes ou après le 
mot saint(e)... C'est n'est pas exhaustif bien sûr.

Suite à sa réponse il me met le doute quand il me renvoie vers l'orthographe 
utilisé sur wikipedia. J'aurai besoin d'information et par défaut je préfère 
toujours me dire que j'ai tort et vérifier avant de répondre

La discutions est sur ce changeset 
https://www.openstreetmap.org/changeset/88176811#map=15/43.1820/3.0232

Quelle est la réponse approprié ?
-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Y a t'il des lenteur pour l'envoi vers Mapillary ?

[Gad Jo]

Bonsoir,


Depuis hier soir je n'arrive pas à envoyer mes captures sur Mapillary. En Wi-Fi 
ou 4g. Même après redémarrage et vidage du cache Android via le mode recovery.

Y a t'il des latences qui demandes à être patient ou est-ce un problème qui 
peut être liée à mon matériel ?

Actuellement quand je regarde mon profil Mapillary j'ai 3 pending édits en 
cours et 680 pending images... Comme si le traitement des envois précédent 
était arrêté.
-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-transit] Bus routes in Málaga: Should we add "stop_area" relations?

[Jo]

Hi Daniel,

If you would like to participate in a Hangout, I can explain to you how
PT_Assistant can help you with this task.

We can even do that in Spanish, si te gusta.

Personally, I would also only map highway=bus_stop (with or without
public_transport=platform) on nodes next to the highway, so no real need
for stop_area relations.

Polyglot

On Sat, Jul 18, 2020 at 7:36 PM Mateusz Konieczny via Talk-transit <
talk-transit@openstreetmap.org> wrote:

>
>
>
> Jul 18, 2020, 19:17 by dcapil...@gmail.com:
>
> Hi!
>
> I'll try to check the bus routes in Malagá. [1] I haven't checked them for
> a long time because I have been busy with other mapping tasks and because
> there were many changes in the central area of Málaga. The bus routes
> changed too often. Now it seems to be stabilizing, there are less and less
> changes, and I thought it would be a good time to check the mapping. I'd
> like to ask you something first.
>
> When we started mapping the bus routes in Málaga, Alan Grant and I came to
> the conclusion that it was not necessary to add "stop_area" relations due
> to the type of bus stops in Málaga, [2] where there are no actual stop
> areas (only a stop position in the own road and a pole on the sidewalk
> usually).
>
> Is that solution correct? Should we add "stop_area" relations at every bus
> stop position? I would have to create a lot of additional relations, only
> with the stop position and the platform features. I am not sure if that
> would be reasonable/useful for any purpose. What do you think?
>
> highway=bus_stop node is typically sole useful and needed part of mapping
> bus stop
>
> (additional tags on this node, starting from name are obviously useful)
>
> stop_position, stop_areas and so on are generally not useful, except
> extremely rare cases
>
> I would rather map bus routes than and do other OSM mapping over pointless
> duplicating
> of information available thanks to highway=bus_stop
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [OSM-talk-fr] API indisponible ?

[Gad Jo]

C'était probablement lié à une erreur de configuration chez cloudflare et ça à 
perduré pendant quelques dizaine de minutes.

https://blog.cloudflare.com/cloudflare-outage-on-july-17-2020/

Le July 17, 2020 10:10:39 PM UTC, Jacques Lavignotte  a 
écrit :
>
>
>Le 17/07/2020 à 23:29, Gaël Simon a écrit :
>
>> api.openstreetmap.org n’a pas pu être résolu.
>
>Résolu en 6 et en 4.
>
>J.
>
>api.openstreetmap.org. 286 IN  A   130.117.76.13
>api.openstreetmap.org. 286 IN  A   130.117.76.12
>api.openstreetmap.org. 286 IN  A   130.117.76.11
>
>Non, rien.
>
>
>-- 
>GnuPg : 156520BBC8F5B1E3 Because privacy matters.
>« Quand est-ce qu'on mange ? » AD (c) (tm)
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] wikidata OpenStreetMap

[Jo]

Io vorrei aggiungere funzionalità a JOSM per facilitare quest tipo de
operazione

Jo

On Fri, Jul 17, 2020, 1:06 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
>
> qualche giorno fa ho scoperto che qualcuno ha importato 2 anni fa 1701
> oggetti da OpenStreetMap in wikidata senza attribuzione. Vorrei rimediare e
> fare due operazioni:
>
> 1.
> aggiungere la licenza ODbL agli oggetti in wikidata e OpenStreetMap come
> fonte
>
> 2.
> aggiungere un relativo tag wikidata agli oggetti in OpenStreetMap
>
>
> Qualcuno di voi ha già fatto un’operazione simile? Ci sono degli script
> per farlo?
>
> Eventualmente qualcuno pratico in questo tipo di operazione avrebbe voglia
> di farlo? Posso fornire una query per trovare questi 1700 oggetti in
> wikidata.
>
> Ciao Martin
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Découpage administratif à Paris, les conseils de quartier

[Gad Jo]

Je ne suis pas certains que les conseils de quartier peuvent faire parti des 
limites administrative.
Sur ma ville un conseil de quartier peut englober jusqu'à 5 quartier ceci par 
manque de conseil existant. Mais ça peut donner une bonne idée sur le nom des 
quartier existant.

Le July 16, 2020 9:26:56 PM UTC, Brice  a écrit :
>Le découpage administratif, tel que défini pour la France
>https://wiki.openstreetmap.org/wiki/FR:Tag:boundary%3Dadministrative#Valeurs_sp.C3.A9cifiques_par_pays_pour_admin_level
>défini admin_level=10 comme "limites des quartiers utilisés pour la 
>démocratie locale"
>
>Dans le cas de Paris,
>sous l'arrondissement (admin_level=9)
>ont été tracés 80 quartiers administratifs 
>(https://fr.wikipedia.org/wiki/Liste_des_quartiers_administratifs_de_Paris)
>
>avec admin_level=10
>exemple : https://www.openstreetmap.org/relation/2195038
>
>Mais il se trouve qu'il y a un découpage encore plus fin : les conseils
>
>de quartier 
>(https://fr.wikipedia.org/wiki/Conseils_de_quartier_de_Paris) définis 
>avec une extension territoriale 
>(https://www.apur.org/sites/default/files/documents/54.pdf), il y en a 
>124 dans Paris.
>Cas particuliers :
>- dans le  1er, 3ème, 4ème, 5ème et 7ème arrondissements les conseils
>de 
>quartier ont la même extension que les quartiers administratifs (soit 4
>
>/ arrondissement)
>- dans le  2ème, un conseil de quartier s'étend sur 2 quartiers 
>adminsitratifs
>
>Si on se réfère à "limites des quartiers..." alors admin_level=10 
>correspond bien au quartier administratif
>mais si on se réfère à la deuxième partie de la définition
>("...utilisés 
>pour la démocratie locale") alors admin_level=10 correspond au conseil 
>de quartier, à Paris.
>
>Je prévois de tracer ces conseils de quartier, que faire ?
>1/ leur attribuer un admin_level=11 ? : ne fonctionnera pas dans le 
>2ème, ni 1er à 7 non plus d'ailleurs (ou si ?)
>2/ déclasser les quartiers actuels (mais pour en faire quoi) et 
>attribuer admin_level=10 aux conseils de quartier ?
>3/ un autre type de balisage, à la façon des EPCI 
>(https://wiki.openstreetmap.org/wiki/France/Limites_administratives/Tracer_les_limites_administratives#.C3.89tablissements_publics_de_coop.C3.A9ration_intercommunale_.28EPCI.29_.C3.A0_fiscalit.C3.A9_propre)
>
>?
>4/ autre ?
>
>-- 
>Cordialement
>Britzz
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Link Wikidata-OSM: no match

[Jo]

Ciao,

Hai provato di utilizzare il plugin Wikipedia de JOSM?

Polyglot

On Thu, Jul 16, 2020 at 11:32 AM Cascafico Giovanni 
wrote:

> Sto cercando di integrare in OSM eventuali biblioteche toscane
> presenti in Wikidata. Ho scaricato da WD con questa [1] query.
>
> Perchè, tra i diversi oggetti "no match", c'è anche questa [2]
> biblioteca? L'oggetto OSM è dalla parte opposta della piazza, ben
> entro il raggio di ricerca [3] della query che usa questo strumento di
> link
>
>
> [1] https://w.wiki/Wym
> [2] https://osm.wikidata.link/Q86537068
> [3] (around:1000,44.07872,10.09992)
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Mapillary -> opensStreetCam

[Gad Jo]

Après essai la gestion des doublons est prisent en compte. Un message 
d'information indique que l'envoi est déjà prévu ou déjà fait.

J'ai tellement de séquences à envoyer que la file d'attente est longue mais 
d'autres tests doivent être fait.
J'ai constaté que si un envoi est déjà prévu et qu'on sélection plusieurs 
séquence pour demander un nouvel upload vers openstreetcam on peut retrouver 
plusieurs fois la même séquences en file d'attente... C'est ce cas là qui est à 
contrôler, normalement ça devrait être OK mais à vérifier...

Le July 11, 2020 7:52:48 PM UTC, Jacques Lavignotte  a 
écrit :
>Lu sur le foroum Mapillary :
>
>
>I made a tool to copy your images between Mapillary and OpenStreetCam: 
>https://osm.svimik.com/photosync/
>
>https://forum.mapillary.com/t/mapillary-openstreetcam-synchronization-tool/4246
>
>J.
>
>-- 
>GnuPg : 156520BBC8F5B1E3 Because privacy matters.
>« Quand est-ce qu'on mange ? » AD (c) (tm)
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Mapillary/Osmose/*signs

[Gad Jo]

Perso j'indique la limite sur la voie concernée. Pour le panneau et pour 
alléger les modifications pour le jour où les limites changent je m'abstient de 
créer les panneaux.

Prends le cas ou la vitesse est changée sur place et tu a les deux 
informations. Si tu en oubli une, un autre contributeur peut être tenter de 
corriger la bonne valeur par l'ancienne. Mettre les deux pourquoi pas mais 
autant limiter les informations redondante.

Le July 14, 2020 9:09:41 AM UTC, Jacques Lavignotte  a 
écrit :
>Bonjour,
>
>
>Je fais des capture d'itinéraires avec Mapillary.
>
>Quelques temps plus tard Osmose me propose les panneaux maxspeed / 
>maxweight.
>
>Autant que possible je reporte les restrictions sur la route.
>
>Mais j'en fais quoi de ces panneaux ?
>
>- posés sur le bord/dans le fossé ?
>
>- sur la way de la route ?
>
>- autre ?
>
>Merci, Jacques
>
>-- 
>GnuPg : 156520BBC8F5B1E3 Because privacy matters.
>« Quand est-ce qu'on mange ? » AD (c) (tm)
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Mapillary -> opensStreetCam

[Gad Jo]

J'ai testé cet nuit et ça fonctionne bien.

Par contre ce matin sur mon petit écran j'ai appuyé de nouveau sur upload. 
J'espère que ça ne va pas repartir en double.
Tu a des infos à ce sujet ?

Le July 11, 2020 7:52:48 PM UTC, Jacques Lavignotte  a 
écrit :
>Lu sur le foroum Mapillary :
>
>
>I made a tool to copy your images between Mapillary and OpenStreetCam: 
>https://osm.svimik.com/photosync/
>
>https://forum.mapillary.com/t/mapillary-openstreetcam-synchronization-tool/4246
>
>J.
>
>-- 
>GnuPg : 156520BBC8F5B1E3 Because privacy matters.
>« Quand est-ce qu'on mange ? » AD (c) (tm)
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-transit] bus=yes opinion

[Jo]

Let's go back to 2012. An attempt was made to solve a 'problem' and the
'new' model for mapping public transport was proposed.

Some people were mapping stops on the rail/highway, others were mapping
them next to the highway.

For rail, and especially if you have only a single OSM way to represent
multiple tracks, it made sense to map them as a node on the OSM way.

For bus stops however one wants to know on which side of the road the
passengers have to wait, so there it makes most sense to map them as a node
alongside the highway.

The bright mind that created the new model was apparently more used to
mapping railway.

So a stop alongside the way supposedly didn't need a mode of transport.

When I tried to adopt this new way of mapping stops, I thought, like many
others that eventually public_transport=platform would replace
highway=bus_stop. For it to be able to do that, information was missing
though. So I asked on the mailing lists and the answer was to add the mode
of transport to public_transport=platform as well.

Over the course of 8 years the people responsible for rendering were
dragging their feet, first it was technical issues, bus/tram/... was not in
their postgresql tables, later it was simply unwillingness.

Anyway, about a year ago, or maybe already 2 by now it became clear that
public_transport=... will never replace highway=bus_stop,
railway=tram_stop, etc.

So, my conclusion is that the whole public_transport scheme has become
moot. It even causes problems, because people are adding identical details
like name, ref, route_ref, operator, network to both the platform and the
stop_position and are adding both of them to the route relations, which
makes maintenance harder.

If it were me,  I would just map the stop nodes next to the highway with
highway=bus_stop and be done with it. If it serves as a tram stop as well,
I would add railway=tram_stop to that node next to the highway.

I've never mapped public_transport=stop_position very much. Except at the
beginning and the end of the itinerary, as I want to split the way there
anyway.

Polyglot

On Sat, Jul 11, 2020 at 7:34 AM Agustin Rissoli 
wrote:

> What are your opinion of adding bus=yes along with
> public_transport=platform + highway=bus_stop?
> I can't find info on the wiki that supports this practice, I know it was
> introduced by iD, but I don't see where this has been discussed.
> My question arises because there is only one user who is adding bus=yes
> (and train=yes on railway platforms, etc.), to all stops in Argentina,
> probably correcting the errors that iD marks.
>
>
> Saludos, Agustín.
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

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

[Gad Jo]

Je viens de corriger la description pour ajouter "parfait" à "aucune 
restriction". L'idée est de conserver un texte court pour les petit écran.

Yes pas de source dans le changeset mais le détail de la source est présent sur 
chacune des modifications. L'image mapillary associé est placé sur le nœud.

Ce week-end je fait une version en anglais et je propose cette mission comme 
modèle à la place de celle déjà existante.

Je travail sur deux missions en lien avec les panneaux publicitaire mais cette 
fois ci ça demande des modifications dans le code de pic4review (conflit de tag 
entre les deux missions). Quand j'aurai monté une instance locale il est 
probable que je remonte quelques questions à ce sujet dans un sujet dédié.
Pour les curieux c'est les missions (en test) 
https://pic4review.pavie.info/#/mission/1161
https://pic4review.pavie.info/#/mission/1174

Le July 10, 2020 9:21:01 AM UTC, "Éric Gillet"  a 
écrit :
>Le 09/07/2020 à 14:21, Percherie OnDaNet a écrit :
>> La mission "Passages piéton en fauteuil roulant" : 
>> https://pic4review.pavie.info/#/mission/1103
>>
>> Avant de la proposer comme modèle sur Pic4Review, pouvez-vous
>vérifier 
>> si je n'ai pas fait de coquille dans les tags utilisé ? Vous pouvez 
>> les consulter quand vous dupliquez la mission pour votre zone. Au 
>> besoin je peut les énumérer ici mais si je peut éviter de polluer la 
>> liste.
>
>Petit détail, mais je pense qu'il faudrait homogénéiser les termes
>entre 
>les boutons de la revue et sa présentation (exemple "Parfait"="Aucune 
>restriction").
>
>Autre soucis mais sûrement plus général à Pic4Review, il n'indique pas 
>la source (image Mapillary par ex.) dans les changesets.
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Gad Jo]

Bonjour,


J'ai fait quelques essais supplémentaires et mes requêtes sont toujours en 
erreur ou bien les commandes utilisée ne sont pas les bonnes.

Est-ce qu'une personne aurait une piste de recherche en m'indiquant le nom des 
commandes à utiliser ?

Le July 3, 2020 1:13:19 PM UTC, Percherie OnDaNet  
a écrit :
>Bonjour,
>
>
>Je suis en train de regarder comment extraire les voies sans éclairage 
>en ville et les voies principale hors aglo. Je part de la requête
>suivante :
>
>[out:json][timeout:250];
>(
>   way["highway"][!"lit"]({{bbox}})(if: length() > 30);
>);
>// print results
>out body;
>>;
>out skel qt;
>
>Comment ajouter une zone englobante ayant les tags suivant  : 
>landuse=residential|retail|commercial|industrial
>
>En dehors de ces zones, je compte exclure les tag suivant : 
>highway=track|path|road

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Extracteur de fichier GeoJSON correspond aux points d'arrêts et aux lignes à partir d'un fichier GTFS

[Gad Jo]

Je suis en train de reprendre la construction du réseau de bus de l'Agglo de 
Narbonne.
J'ai commencé il y a longtemps avec le schéma de transport V1 et je suis en 
train de tout recontroler pour un passage en V2.
La page de suivis est également est cours de correction car les façon de taguer 
ont changé : https://wiki.openstreetmap.org/wiki/Narbonne/Transports_en_commun

Je suis intéressé ce qui est indiqué dans l'info lettre de 
transport.data.gouv.fr mais je n'ai rien trouvé concernant la zone de Narbonne. 
Qui publie les jeux de données ?

Le June 30, 2020 2:31:07 PM UTC, "Yves P."  a écrit :
>Bonjour,
>
>Pour celles et ceux qui veulent cartographier dans OSM les lignes de
>transport en commun, transport.data.gouv.fr
> vient d'annoncer ceci dans son
>Info-lettre de Juin 2020.
>
>__
>Yves
>
>
>Des réseaux de transport cartographiés
>Un extracteur de GeoJSON pour ouvrir de nouveaux usages.
>[lien vers la photo dans l'article
>]
>Le format GTFS peut faire peur. Le Point d'Accès National n'a pas pour
>seul but d'alimenter des calculateurs d'itinéraires mais doit permettre
>au plus grand nombre d'organisations de s'approprier ces données. Aussi
>diffuser les données sous d'autres formats peut être un moyen de
>toucher de nouveaux utilisateurs et développer de nouveaux usages.
>C'est pourquoi nous avons mis en place un extracteur de GeoJSON qui
>génère pour chaque fichier GTFS un fichier GeoJSON correspond aux
>points d'arrêts et aux lignes. La visualisation de ce GeoJSON est pour
>le moment disponible dans les résultats d'analyses de GTFS. Ceci sera
>également ajouté comme ressource communautaire sur chaque jeu de
>données pour permettre de télécharger ce fichier GeoJSON. Nous
>envisageons également de produire un fichier complet pour la France et
>une interface de visualisation. N'hésitez pas à nous indiquer votre
>intérêt pour ce travail, il serait alors priorisé !

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Comment restaurer des données supprimée

[Gad Jo]

Bonjour,


J'ai fait une suppression malheureuse mais je m'en rend compte très 
tardivement. La zone est très limité. Sur deux immeubles.

C'est plus simple de refaire un import du cadastre mais je demande ça aussi 
pour apprendre comment répondre à cette étude de cas.

J'ai posté la demande sur le forum pour que le plus grand nombre profite de la 
réponse mais sans succès depuis depuis mai.

Est-ce qu'une personne aurait une solution ?
https://forum.openstreetmap.fr/viewtopic.php?f=5=7400
-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Gad Jo]

Bonjour,


Pour l'instant les discutions et les crainte restent cantonnée à la France et 
l'association osm-fr est sollicitée.

Je présume que c'est partout similaire dans les autres pays. Quelles sont les 
réactions des autres communautés ? Une réponse au niveau de osm-world est 
probablement à l'étude.
Une mutualisation des idées est parfois envisageable mais il faut en avoir 
connaissance. Je suis curieux, voilà tout.

Le June 19, 2020 3:53:40 PM UTC, Christian Quest  a 
écrit :
>Le changement de paysage peut relancer l'intérêt pour un tel outil.
>
>L'idée à l'époque avait plus ou moins été de conserver une copie et 
>d'envoyer vers les deux.
>
>Contrairement à Mapillary, le code d'OpenStreetCam est ouvert, il
>serait 
>peut être pertinent d'y jeter un oeil et de reprendre éventuellement ce
>
>flambeau.
>
>
>L'essentiel quand même dans tout ça est la conservation du stock de 
>photos, car même si elles sont disponibles sous une licence libre,
>elles 
>dépendent de l'hébergement fait par Mapillary (et donc gratuit pour 
>nous, mais pas pour eux) et celui-ci peut très bien être coupé, réduit,
>
>changer de politique, etc...
>
>L'urgence pour moi est donc dans l'immédiat le "takeout" ;)
>
>
>Le 19/06/2020 à 17:28, PanierAvide a écrit :
>> C'est le problème de la poule ou l'oeuf : difficile de mobiliser sans
>
>> un début de solution, et pas évident d'avoir une solution technique 
>> sur ce sujet lancée par une personne qui soit motivante pour amener 
>> des contributions rapidement...
>>
>> Adrien P.
>>
>> Le 19/06/2020 à 17:24, Marc M. a écrit :
>>> Bonjour,
>>>
>>> Le 19.06.20 à 16:41, Vincent de Château-Thierry a écrit :
 si quelqu'un.e a *envie* qu'un démonstrateur "proxy Mapillary/OSC" 
 voit le jour, qu'il/elle n'hésite pas à se lancer
>>> je ne partage pas ta vision du communautaire.
>>>
>>> *j*'ai envie de me lancer dans le sujet, comme je l'avais dis
>>> il y a plus d'un an.
>>> mais ce que je n'ai pas envie, c'est d'un Xieme projet mono-leader
>>> qui s'arrête ou se grippe le jour où le mono-leader est
>indisponible.
>>> le monde libre est plein de projet agonisant, quel gâchis de ne
>>> pas se concentrer sur le durable, ce qui implique aussi d'être
>>> humainement durable. c'est en ce sens que je disais que la
>>> communauté n'avait pas eu envie en 2018 du sujet, ou dit
>>> autrement, il n'y avait pas une manifestation de porteur*s*
>>> pour que l'idée se poursuive
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>-- 
>Christian Quest - OpenStreetMap France
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Gad Jo]

Bonsoir,


C'est probablement une mauvaise idée mais je tente le coup.

Avec une première équipe qui ajoute à chaud les enseignes avec Osmand ou 
Vespucci. Puis quelques dizaine de minutes plus loin une seconde équipe qui 
ajoute les horaires avec streetcomplete
Il faut rafraîchir régulièrement la liste des requête pour récupérer les ajouts 
tout frais.
Streetcomplete à un super assistant de saisie pour les horaires.

Seul et en saisie à la volée de quelques secondes pendant les balades en 
poussette, je suis obligé de le faire en deux temps. Le laps de temps entre mes 
deux saisie étant très espacé (plusieurs semaines) je ne suis certains pas que 
streetcomplete puisse fonctionner à chaud.
A tester

Le June 14, 2020 7:02:03 PM UTC, Arnaud Champollion 
 a écrit :
>Bonjour,
>
>Je sollicite vos conseils d'organisation.
>
>Jeudi 18 mai le groupe OsmDigne que j'anime sera en cartopartie au 
>centre-ville de Digne-les-Bains, sur le thème des ERP (établissements 
>recevant du public) : commerces, restaurants, bars, cabinets médicaux, 
>administrations ...
>
>http://www.linux-alpes.org/osmdigne-ca-repart/
>
>Nous prévoyons
>
>-  des équipes chargées des relevés de noms, qui annoteront une carte 
>papier imprimée :
>http://linux-alpes.org/osmdigne/bd_gassendi_4_pages.pdf
>
>- des équipes chargées des relevés des horaires
>
>Pour cette deuxième équipe, avez-vous au l'occasion de mettre en place 
>des procédures en particulier ?
>
>Noter les horaires sur place peut être très long, donc j'imaginais
>avoir 
>recours à la photo. Une équipe avec un photographe et un secrétaire, le
>
>premier photographiant les panneaux d'horaires, le second notant dans
>un 
>tableau préalablement numéroté les noms des commerces, afin que l'on 
>puisse établir les correspondances pour le versement des contributions 
>... à considérer que le photographe s'astreigne à ne prendre qu'une 
>seule photo de chaque panneau horaire.
>
>Je suis preneur de toutes vos expériences et conseils pour réaliser ces
>
>relevés sur le terrain de façon fiable et tenable dans le temps.
>
>Merci
>
>Arnaud
>
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] On va changer notre infra informatique

[Gad Jo]

Bonjour,


Suite au mail, c'est Noël je viens de fairr le rapprochement qu'au boulot nous 
allons changer notre infra d'ici quelques semaines, c'est SPIE qui va tout 
récupérer pour recyclage.

Si ça intéresse l'association je peut en parler au DSI voir si c'est 
envisageable de vous le céder. Sous réserve d'accord du DG.

Je n'ai pas le détail techniques mais je peut l'avoir dans la journée. Il y a 
deux ESX Dell, baie de stockage de quelques tera en raid, switch et l'ensemble 
des rack de rangement.

Si ça peut aider pour les projets de test et développement ce sera déjà ça... 
Surtout qu'ils sont en train de découvrir uMap et OSM via les démo que je leur 
ai fait.

Ne tardez pas pour que je puisse avoir le temps d'en parler et si possible de 
mettre la cession du matériel en place.

Hors sujet : les équipes sur le terrain et dans les services de construction ou 
la politique de la ville sont conquises par l'utilisation d'uMap et ont de 
grande difficultés pour montrer l'intérêt au DG qui prends ça pour un gadget. 
Les équipes vont lui refaire une présentation d'uMap, y a t'il des exemples ou 
blog qui pourrait les inspirer pour leur présentation de projet ? (Je bosse 
pour un office HLM)

Cordialement 

Le June 10, 2020 9:34:37 PM UTC, Christian Rogel 
 a écrit :
>
>
>> Le 10 juin 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".
>> 
>> - avoir un éditeur web consensuel utilisable (le fameux id-consensuel
>> grâce aux patchs de fred)
>
>
>Sans avoir idée de ce que pourraient apporter les patchs de Frédéric,
>je signale que le président et le CA
>de la Fondation d’OSM ont présenté à la discussion par la communauté
>(RFC) l’idée d’une instance qui 
>pourrait aplanir les divergences entre développeurs d’ID et les
>contributeurs :
>
>https://blog.openstreetmap.org/2020/06/08/toward-resolution-of-controversies-related-to-id/
>
>Ce texte a été appprouvé par les développeurs d’iD.
>
>La discussion sur la liste internationale a mis en lumière que, si
>Mapbox a payé et paie encore une partie
>du développement, la propriété morale d’iD appartient à la Fondation.
>
>
>Christian R.
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] fake mapping

[Jo]

And there is no need to be comprehensive. Map it as you you, little
by little.

On Tue, Jun 9, 2020, 12:15 Mateusz Konieczny via talk <
talk@openstreetmap.org> wrote:

>
>
>
> Jun 9, 2020, 00:26 by talk@openstreetmap.org:
>
> just to be safe i went to a pre-edit location, less than 5 miles 2 hours
> by public transportation.
>
> the satellite view was wrong, the river area were ponds because of the
> dam, which was not there in 1969
>
> when we went down the river in cement tubs, and the golf cart paths were
> all marked unmaintained track road.
>
> there are pologons around the greens, holes and fairways not the whole
> property, where natural woods
>
> that have separate pologons.
>
> the point is there is to much there to fix.
>
> Yes, in many cases map should be updated. If aerial images are wrong it is
> useful to add
> something like
> note=edited based on survey, as of 2020 Bing aerial imagery is outdated
> and wrong
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk-be] Mappen van fietssnelwegen, mapping of cycling highways

[Jo]

English below

Hallo,

Het mappen van fietssnelwegen op OSM is een beetje een uitdaging.
Persoonlijk heb ik graag routerelaties die een continue reeks van ways
zijn, maar de fietssnelwegen liggen er nagenoeg nergens over hun volle
lengte. Ik vind het interessant om de geplande fietssnelwegen nu al op de
kaart te kunnen zetten, maar anderzijds wil ik ook aangeven wat de
alternatieve omleidingen zijn, aangenaam fietsbaar zonder al teveel omweg.

Ik meen dat ik nu een goede oplossing gevonden heb: superroute-relaties.

Hiermee kunnen we de deeltrajecten in route-relaties stoppen, al dan niet
met proposed (zodat ze in stippellijn op de cyclemap getoond worden).

Deze route-relaties kunnen dan in superroutes worden opgenomen. Hier en
daar is het ook zo dat fietssnelwegen elkaar overlappen. F2 en F44, F3 en
F8. Ook voor deze gemeenschappelijke stukken zijn afgesplitste
route-relaties een goede oplossing.

josm-latest laat sinds een dikke maand toe om te zien dat
superroute-relaties continu zijn. (als de laatste way in de vorige route
zijn laatste node gemeenschappelijk heeft met de eerste way zijn eerste
node).

Ik ben gaandeweg alles aan het omzetten. F3, F8, F24, F25, F26 en nog een
paar zijn al klaar. Gisteren F2 gedaan, nu ben ik bezig met F44.

Dit is een goede query om ze te downloaden in JOSM:

[out:xml][timeout:190][bbox:{{bbox}}];
(
  nwr["cycle_network"="cycle_highway"];
);
(._;>;);
out meta;

(expert mode activeren en dan 2e tab, download from Overpass)

Hi,

Mapping cycling highways on OSM is a bit of a challenge. Personally I like
for route relations to have continuous sequences of ways, but there are
very few cycle highways that are already realised over their full length. I
think it's interesting to already include the planned cycling highways, but
their practical use for routing is negligent. So it seems important to me
to also include how to get from A to B today, following ways that are nice
to ride along with overly big detours.

I think I found a good solution to have my cookie and eat it too:
superroute relations.

This allows us to put the different parts in separate route relations.
Those composed of highway=proposed/proposed=cycleway tagged with
state=proposed, so they are shown in a dashed line on the cyclemap
rendering.

Then those route relations can be used to compose superroute relations. It
also happens that cycle highways overlap, f.e.  F2 en F44 in Gent, F3 en F8
in Leuven. Also for these parts it's interesting to split them off in
separate route relations.

For about a month, maybe 2 now, josm-latest also shows continuity for
superroute relations.

This is a good query to download them in JOSM:

[out:xml][timeout:190][bbox:{{bbox}}];
(
  nwr["cycle_network"="cycle_highway"];
);
(._;>;);
out meta;

(activate expert mode and then 2nd tab, download from Overpass)

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

Re: [OSM-talk] Should we map things that do not exist?

[Jo]

Here in Belgium many of these are repurposed as cycling highway
infrastructure. I wouldn't mind having highway=cycleway, railway=razed on
them.

Polyglot

On Mon, May 25, 2020 at 1:47 PM Mateusz Konieczny via talk <
talk@openstreetmap.org> wrote:

>
>
>
> May 25, 2020, 06:37 by jacknst...@sprynet.com:
>
> Greetings.
>
>
> Recently, a user mapped “razed” railways inside a construction zone (link
> below). These rails had been removed by our local mappers since they don’t
> exist anymore. Using the latest imagery (Maxar), you can see the rails have
> been completely removed from “Project 70”, a $1.2 billion Denver-area
> transportation corridor construction project.
>
>
> I think this mapper has good intentions, but what is the point of mapping
> something that does not exist? Doesn’t this clearly contradict the OSM Good
> Practice wiki in regards the sections, “Verifiability”, “Map what's on the
> ground” and “Don't map historic events and historic features”? The last
> section states, "*Do not map objects if they do not exist currently*."
>
> Rails were removed - but is there embankment or something similar that
> makes clear
> that railway line was there?
>
> In cases of still present embankment it is a bit tricky what is border
> between "present" and "gone".
>
> Note also that recently gone objects may be temporarily keep to prevent
> them from accidental
> remapping - for example based on old memory or old aerial images.
>
> But yes, something completely gone can and should be deleted from
> OpenStreetMap
> (temporarily kept in way that marks it as gone if likely to be
> accidentally remapped).
>
> Should we leave (invisible) destroyed buildings in place, tag them as
> razed and then create new buildings on top of them?
>
> I do this to make people using outdated aerial images less confused. And
> delete them
> once aerial images are updated.
>
> I deleted object where people were either importing old objects,
> nonexisting objects unlikely
> to be remapped by accident, supposedly existing old objects that were
> unverifiable.
>
>
> > Should we map things that do not exist?
>
> No, but remapping existing objects as "this is gone now" (building=yes ->
> demolished:building=yes)
> is often a good idea.
>
> But someone adding nonexisting railways, nonexisting buildings, historic
> boundaries and so on
> should stop, and such additions be reverted.
>
> (note that ruined buildings, ruined railways are mappable, just completely
> gone are not).
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-be] privacy ed

[Jo]

Not only their faces, also license plates. And if you're doing it manually
maybe also stickers with recognisable information.

Jo

On Fri, May 15, 2020, 19:38 Marc Gemis  wrote:

> Hello,
>
> I see no difference between contributing to OpenStreetMap via JOSM and
> iD or StreetComplete.
> Mapping a house, street, waste bin, etc. will not break any privacy.
> We do not map the names of the inhabitants of a house. Mapping items
> from someone's garden based on aerial imagery might be on the
> borderline of what is allowed. However, I do map sheds, ponds and
> swimming pools.
>
> Taking pictures of people is not a problem, it's what you do with them
> afterwards that is important. If you use the image yourself and map
> the things you see on them from your PC, it doesn't matter that there
> are people.
> If you post the image on a public website (as you do via
> StreetComplete), you have to make sure that there are no people or
> that their faces are blurred (e.g. uploading to Mapillary is OK I
> think).
>
> Of course, you cannot enter private grounds.
>
> On Thu, May 14, 2020 at 3:49 PM wbrt  wrote:
> >
> > Hello,
> >
> > a question about privacy of people in general (not the mapper) (in
> Belgium)
> >
> > when contributing using for example streetcomplete:
> https://github.com/westnordost/StreetComplete
> > answering the questions, i suppose this is ok juridical?
> >
> > when taking pictures to make it clear for the mappers,
> > i guess this also ok, as long as people are not recognizable in it?
> >
> > or am i wrong?
> > and can you get in trouble for contributing to openstreetmap?
> >
> > The info i found:
> >
> https://wiki.openstreetmap.org/wiki/Limitations_on_mapping_private_information
> >
> > kr
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-es] Formación para geovoluntarios.org

[Jo]

Hola,

El español no es mi idioma maternal, pero soy bastante fluente. Hablo ambas
variaciones, porqué he aprendido el español en España y pués me fui a Perú.
De GIS solo conozco QGIS, pero de OpenStreetMap conozco muy bien el editor
JOSM.

Tienen alguna preferencia del tema? Edificios, rutas/itinerarios,
transporte público? No me conozco super bien en 3D, puedo explicar el
básico.

Polyglot

On Fri, May 15, 2020 at 10:57 AM Santiago Crespo 
wrote:

> Hola!
>
> Desde geovoluntarios.org están interesados en colaborar con OSM. El
> problema que tienen es que a pesar de que la inmesa mayoría de personas
> de esa comunidad son profesionales que usan ArcGIS, apenas tienen
> experiencia aportando a OSM.
>
> Les veo bastante motivados y con ganas de colaborar. La mayoría están en
> España pero hay también en América Latina y otros países, por lo que la
> formación tendría que ser en Español y por la tarde.
>
> ¿Hay alguien interesado en ofrecer formación online, mediante
> videollamada, a esta buena gente?
>
> Por favor que responda por aquí o por privado y nos organizamos.
>
> Recuerdo que alguna vez alguien compartió documentación útil para este
> tipo de formación. ¿Os importaría compartirla de nuevo?
>
> Gracias!
> Santiago
>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk-be] Weggetje verdwenen, hoe terug ?

[Jo]

Er is nog een 'truuk' om verwijderde ways terug te halen. (werkt enkel voor
ways).

Start editeersessie met Potlatch2.

Je wilt eigenlijk de vorige versie van Potlatch gebruiken, haal daarom de 2
weg uit de url in de adresbalk...

De originele versie van Potlatch maakt gebruik van een niet gedocumenteerde
'feature' in de API.

Er is een knop om deleted ways te zien.

Jo

On Tue, May 12, 2020 at 1:07 PM Tim Couwelier 
wrote:

> Bijlage bleeft hangen wegens groter dan 80kb, maar hierbij even ter
> illustratie hoe je ze kan traceren met de 'skyview' laag.  Is een soort
> hoogtemodelweergave op grondniveau, de bomen zie je dus niet.. en het pad
> wordt zichtbaar.
>
> https://framapic.org/r01ExtbzPorU/Z1Zri8oU24QM.jpg
>
> (ik had al even afzonderlijk gemaild naar de betrokken persoon, maar
> mogelijks zijn er nog mensen waarvoor dit een meerwaarde kan betekenen.)
>
>
> Op di 12 mei 2020 om 10:57 schreef Wannes Soenen :
>
>> Ok, dan lijkt me het het “handigste” dat ik een GPX neem en het pad terug
>> teken (want het zit onder de bomen)
>> Die relaties, en GR enz toevoegen/verleggen, zal ik eerst eens moeten
>> bestuderen, want dat heb ik nog nooit gedaan.
>>
>> Op 12 mei 2020, om 10:53 heeft Sander Deryckere 
>> het volgende geschreven:
>>
>> Hallo,
>>
>> Het hangt er van af hoe lang de wijziging geleden is.
>> Als het vrij recent is (enkele dagen), kan je de geschiedenis van een
>> gebied opvragen (de geschiedenis knop op de hoofdpagina).
>> Maar deze wijziging lijkt langer geleden te zijn, dus valt dit moeilijk
>> te bespeuren.
>>
>> Wat je wel kan is bekijken welke objecten waarschijnlijk ook gewijzigd
>> zijn bij die aanpassing (zoals het fietspad dat nu gebruikt wordt).
>>
>> 
>>
>> Als je dat fietspad selecteert, en de geschiedenis opvraagt, dan kom je
>> hier terecht: https://www.openstreetmap.org/way/24520913/history
>>
>> Er is dus in de laatste maanden tamelijk wat aangepast aan het pad.  In
>> het bijzonder zie ik een wijziging van 4 maand geleden met het commentaar 
>> "cycleroute
>> 03-04 update: broken (again), now due to missing segments". Wat er op
>> wijst dat iemand er voor die regio heeft aangepast, zonder rekening te
>> houden met de relaties.
>>
>> Het is dus waarschijnlijk niet 1 iemand die de relatie verlegd heeft,
>> maar iemand heeft dat pad verwijderd, en iemand anders heeft de relatie
>> opnieuw verbonden met de bestaande paden...
>>
>> Mvg,
>> Sander
>>
>> Op di 12 mei 2020 om 10:18 schreef Wannes Soenen :
>>
>>> Hoi,
>>>
>>> Ik zie dat er zeer lokaal, een wegje verdwenen is op de kaart.
>>> Ik kan dat er zelf terug op gaan zetten, maar dan is de kans groot dat
>>> diegene die de edit gedaan heeft het weer wist.
>>>
>>> Hoe kan ik 1) zien wie de edit deed, of er een comment bij was? 2)
>>> rollback doen
>>>
>>> Het betreft een pad net ten zuiden van het Ringfietspad op
>>> https://www.openstreetmap.org/edit#map=18/51.20462/4.44275
>>> De plaatselijke merkkringen van het GR-pad (en van op de GR site) loopt
>>> wel degelijk over dat pad, niet over het fietspad.
>>> Dus, de huidige gemaakte situatie is fout, want 1) pad is niet meer
>>> gemapt 2) GR loopt over het fietspad.
>>> ___
>>> Talk-be mailing list
>>> Talk-be@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-be
>>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-it] Nuova Responsabile OpenStreetMap e Wikidata - Wikimedia Italia

[Jo]

complimenti e buona fortuna!

Polyglot

On Tue, May 5, 2020, 14:54 Anisa Kuci  wrote:

> Ciao a tutti,
>
>
> sono Anisa Kuci, la nuova responsabile OSM e Wikidata presso Wikimedia
> Italia.
>
> Sono di origine albanese ma vivo in Italia da due anni, ho già contribuito
> ad OSM e sono stata parte della prima comunità/hackerspace che ha promosso
> e continua a
>
> promuovere le tecnologie FLOSS in Albania.
>
>
> E lì che ho conosciuto il progetto OSM e ho aiutato a far crescere la
> comunità nel mio paese, contribuendo online (mapping) e offline,
> promuovendo il progetto,
>
> organizzando mapathons, workshops, OSM infobooths etc.
>
>
> Ho partecipato a SOTM 2017, dove ho creato contatti con comunità di tanti
> paesi e ho fatto anche una presentazione sul "Community building”.
>
> Sono stata “Mapper of the Month” per OSM Belgium nel 2018. Ho
> co-organizzato workshops riguardo a OSM e progetti Wikimedia
> nell'hackerspace e nelle scuole.
>
> Sono stata parte del core team che ha fatto un accordo con il Municipio di
> Tirana per liberare i dati geospaziali e inserirli in OpenStreetMap.
>
>
> Sono molto entusiasta ed interessata a far crescere ancora di più il
> progetto, anche se devo ancora imparare tante cose sia su OpenStreetMap sia
> su Wikimedia Italia
>
> e dovrò affrontare un periodo di formazione, ma a breve spero di
> interagire più attivamente con la comunità.
>
> Quindi mi farò sentire presto con delle proposte e delle richieste.
>
>
> A causa della situazione per il Covid-19 lavorerò inizialmente da remoto.
> Quando la situazione e le misure di lockdown cambieranno, sarò presente in
> sede a Milano.
>
>
> Per qualsiasi cosa potete contattarmi a questo indirizzo:
> anisa.k...@wikimedia.it
>
> Sono anche sul gruppo telegram di OpenStreetMap Italia.
>
>
> Ci sentiamo presto,
>
> Anisa
>
>
> --
> Anisa Kuci
> Responsabile OpenStreetMap e Wikidata
> Wikimedia Italia - Associazione per la diffusione della conoscenza libera
> Via Bergognone 34 - 20144 Milano
> Tel. (+39) 02 97677170 | anisa.k...@wikimedia.it | www.wikimedia.it
>
> DAI ALLA CONOSCENZA LIBERA UN NUOVO NOME. IL TUO.
> Devolvi il 5x1000 a Wikimedia Italia:
> nella tua dichiarazione dei redditi inserisci il Codice Fiscale 94039910156
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-transit] Making bus lines more specific

[Jo]

The basic objection they voice is why need 2 tags, if 1 does the job.

highway=bus_stop

is not exactly nonsensical. It's concise and expresses what is meant. (OK,
it's not a highway and my preference is to map it next to the highway)


public_transport=platform

was designed at first to not need a mode of transport like
bus=yes/tram=yes. I am the one who proposed adding it, so that it COULD
start replacing highway=bus_stop back in 2012.

There is not always a platform present, so it's a bit of a misnomer as well.

Anyway, someone who wants to render a bus stop ideally wants to look at a
single tag, not a combination of 2, apparently. For a long time it was
supposedly a technical problem, but as soon as that was resolved somewhere
around 2017, it was still considered problematic to look at 2 tags.

I wish you good luck with proposing another way of mapping public
transport. Many have tried before you. It's really hard to beat status quo.
And the status quo is not the same across the planet. If you can propose
something that is both simpler, more elegant and still expressive enough
for all usecases, I'll vote yes on it.

Polyglot

On Tue, Apr 28, 2020 at 10:26 AM Robin Däneke  wrote:

> Indeed, these are good points. I would say, that the „platform“ is enough.
> This could then mean either the „stop pole“ of the station (which I would
> not say is the most important piece as that could also just be a sticker on
> a shelter or a lamp post) close but not at the station (sadly there are big
> inconsequent uses in real life), or the area of the visible platform, if
> applicable.
>
> But the rest of the community will have to accept the death of (old) tags,
> when it is voted for. If this mailing list could come up with a proposal
> most users here could live with, we all vote for it (with the spelling of
> the end to certain tags) and it is accepted that way, the community will
> have to accept that. The first iteration was just to „nice“ to that
> conservative fraction. Public transport can be complex, but this is why it
> needs dedicated (own, simple) tags instead of legacy nonsense.
>
> This is, why I would be happy to have many people work on this „ideal“
> solution, that is simple on the one hand, but powerful on the other hand. I
> will make a Document where I put in my personal critique and goal for a new
> scheme, and am then looking forward to input on it. Will share it here when
> I have a framework of what the current scheme says and have some changes in
> it. Then, the specifying of the bus lines, the simplifying of the bus
> stations (so that one or two tags can replace bus_stop but still do the
> same thing functionally) and other points could be put in there.
> Maybe we actually end up with a useful consensus, that one could propose.
>
> The more people get on board, the more acceptable it can become...
>
> KR
> RobinD
>
> Am 28.04.2020 um 10:07 schrieb Jo :
>
> For years and years we have tried to convince the people working on carto,
> our default rendering to start supporting public_transport=platform/bus=yes
> instead of highway=bus_stop.
>
> They have clearly stated that this will never happen. Conclusion:
> highway=bus_stop is NOT a legacy tag.
>
> That's my conclusion anyway. In Belgium I'm even considering to drop
> public_transport=platform on the bus stop nodes, but that's not
> straightforward either anymore,, since the editor software started to
> depend on them.
>
> stop_position nodes, I have never considered them to be important, so I
> never mapped them for ALL the stops. I do map them for initial and terminus
> stops, was I want to split the way there anyway. What I will definitely not
> do, the way I see it done in Germany is to duplicate information.
>
> I want to have a single object, preferably a node, that has all the
> details of the stop AND I want to include this object in the route
> relations. 1 object per stop, so not a sequence of
> stop_position/platform/stop_position/platform.
>
> As I don't consider the stop_position nodes to be important enough to map
> them everywhere I don't put name/ref/ etc on them. In Belgium most
> stop_position nodes will have only 1 extra tag, the mode of transport.
>
> For me it's an advantage that highway=bus_stop can only be used on a node.
> I want to map the object that represents the bus stop as a node anyway,
> next to the highway on the side where the passengers wait.
>
> If there is a physical platform, then it makes sense to map it as a way or
> a closed_way/area. In that case it gets highway=platform and possibly
> tactile_paving=yes/wheelchair=yes, maybe a height as well. But no
> repetition of name,ref,route_ref,operator,network, etc.
>
> If there is to be a next version of how we map public transport we should
> think a

Re: [Talk-transit] Making bus lines more specific

[Jo]

For years and years we have tried to convince the people working on carto,
our default rendering to start supporting public_transport=platform/bus=yes
instead of highway=bus_stop.

They have clearly stated that this will never happen. Conclusion:
highway=bus_stop is NOT a legacy tag.

That's my conclusion anyway. In Belgium I'm even considering to drop
public_transport=platform on the bus stop nodes, but that's not
straightforward either anymore,, since the editor software started to
depend on them.

stop_position nodes, I have never considered them to be important, so I
never mapped them for ALL the stops. I do map them for initial and terminus
stops, was I want to split the way there anyway. What I will definitely not
do, the way I see it done in Germany is to duplicate information.

I want to have a single object, preferably a node, that has all the details
of the stop AND I want to include this object in the route relations. 1
object per stop, so not a sequence of
stop_position/platform/stop_position/platform.

As I don't consider the stop_position nodes to be important enough to map
them everywhere I don't put name/ref/ etc on them. In Belgium most
stop_position nodes will have only 1 extra tag, the mode of transport.

For me it's an advantage that highway=bus_stop can only be used on a node.
I want to map the object that represents the bus stop as a node anyway,
next to the highway on the side where the passengers wait.

If there is a physical platform, then it makes sense to map it as a way or
a closed_way/area. In that case it gets highway=platform and possibly
tactile_paving=yes/wheelchair=yes, maybe a height as well. But no
repetition of name,ref,route_ref,operator,network, etc.

If there is to be a next version of how we map public transport we should
think about making it simpler. What I see in Germany is way too complicated
and error prone, as information is duplicated across objects.

Polyglot




On Tue, Apr 28, 2020 at 9:45 AM Robin Däneke  wrote:

> Hello everybody,
>
> I have lately been thinking about somehow reworking (or giving a new push
> to) the current p_t:v2 scheme.
> Especially for the fact, that, since it was first proposed and accepted,
> not a lot has changed in which tags are rendered, how certain things are
> hence mapped and the Wiki-Pages on the topic have also changed in the last
> years without any visible going through another proposal process.
>
> When I started mapping in 2011, and first read the german and then the
> english p:t:v2 wiki pages, it was:
> - highway=bus_stop is a legacy tag that should eventually be completely
> phased out
> - stop positions and platforms are to be both mapped
> and some other things I already forgot…
> Now, iD has a rule in its verifyer, that requires highway=bus_stop on
> platform nodes. The point of the public_transport tags is, among other
> points, to replace less dedicated highway tags.
> I think it would be time for a p_t:v2.5 proposal, where we take the
> innicial ideas of the v2, maybe refine a few small details (like is
> stop_position required, or just platforms, can relations of route-parts be
> used in route relations to save on redundancy…) and then put it forward for
> voting. If accepted, we would possibly now have more leverage to get the
> editor and render-programers to actually properly implement it this time
> around.
>
> Maybe I could find some time to write my suggestions into a document, and
> we could collect the ideas for those extra tags in there too. I think it
> would make more sense that way, than just the addition of a few tags to the
> current scheme, to then be ignored by the rest of OSM once again.
>
> Kind Regards
> Robin D. (emergency99)
>
>
> PS: The problem with bus_stop on platform: platforms can be nodes, lines,
> ways, even relations, highway=bus_stop can only be a node. This old tag
> should go the same way as the farm tag, which was (forcefully) abandoned a
> couple of years back. There it worked, why not for the „new“ p_t scheme?
>
> > Am 28.04.2020 um 00:12 schrieb Guilherme Braga Alves <
> gbragaal...@gmail.com>:
> >
> > I read your responses and I tend to agree that the opening_hours tag is
> enough to characterize services that are only operated during peak hours.
> >
> > On the other hand, it seems to me that there is also agreement on the
> relevance of having tags to differentiate bus services.
> >
> > How can we expand this debate and expand this discussion? It may be
> interesting for other members of the list to speak out, and then we can
> create or redeem a proposal for implementing new tags.
> >
> > P.S .: I don't know if this message will enter the reply queue
> correctly; I hope I'm not opening a new topic. I apologize for my
> inexperience with maillists.
> > ___
> > Talk-transit mailing list
> > Talk-transit@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-transit
>
>
> 

Re: [OSM-talk-be] archives - streams and rivers

[Jo]

In Dutch it's very likely that the spelling 'progressed' in the meantime.

How does one search for a specific map of a river in the region of interest?

Jo

On Sat, Apr 25, 2020 at 11:19 AM Pierre Parmentier <
pierrecparment...@gmail.com> wrote:

> Hello,
>
> The Belgian State Archives have put the following archives online:
> 'Ministère de l'Intérieur. Plans généraux des cours d'eau non navigables ni
> flottables' (1877-1890).
>
> You can find them via Cartesius.be. They can be useful for
> finding/veryfying the correct names of small streams and rivers. But be
> careful: it appears that in some cases the actual current names (hydronyms)
> are slightly different from what they were at the end of the nineteenth
> century! These maps cover the entire Belgian territory they said but I did
> not check it really ;-)
>
> Two samples:
>
>-
>
> https://search.arch.be/imageserver/topview.php?FIF=510/510_0156_000/510_0156_000_00159_000/510_0156_000_00159_000_0_0003.jp2
>-
>
> https://search.arch.be/imageserver/topview.php?FIF=510/510_0156_000/510_0156_000_00132_000/510_0156_000_00132_000_0_0095.jp2
>
> Pierre P.
> aka foxanddpotatoes
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-pe] Fwd: [HOT] Experienced JOSM users - place names task in Peru

[Jo]

Yo tengo eso:

The task could not be locked for mapping. Mapping not allowed because:
USER_NOT_ON_ALLOWED_LIST

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

Re: [OSM-talk-be] cycling allong the R4 in Gent

[Jo]

Since both the highway and the cycleway are separate (mostly parallel)
'entities' in OSM, I think it does make sense to use bicycle=use_sidepath.
For routing purposes, it's probably not needed, while editing in JOSM and
for highlighting using MapCSS it is handy to have the tags directly on the
objects they apply to.

Jo

On Thu, Apr 9, 2020 at 12:00 PM Wouter Hamelinck 
wrote:

> Hi,
>
> All three are correct in my opinion. Tbh, I've never really understood the
> use of use_sidepath. The only case where it contains really helpful
> information for me is when that alternative is not mapped. But then there
> is a more efficient solution...
> But I don't really have anything for or against any of the options.
>
> The third option is correct, but is a little uninformative, especially
>> since you actually ARE allowed to cycle on some parts of this same R4
>>
>
> Isn't the first question here if they should be trunk if you are allowed
> to cycle?
>
> wouter
> --
> "Den som ikke tror på seg selv kommer ingen vei."
>- Thor Heyerdahl
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-de] Korrektes Einfügen von Buslinien

[Jo]

Hallo Philip,

Wenn du willst machen wir ein Google Hangout und dann werd ich dich genau
erklären wie man das machen kann.
Jo

On Thu, Mar 26, 2020 at 4:11 PM Philip Albrecht 
wrote:

> Hallo zusammen,
>
> ich möchte Buslinien aktualisieren. Die neuen Verläufe der Buslinien
> habe ich in QGIS digitalisiert. Nun würde ich diese gerne in OSM
> ebenfalls aktualisieren.
>
> Ich habe in JOSM die OSM Daten für den gewünschten Bereich
> heruntergleaden. Dann die JOSM Erweiterung OpenData installiert. Dann
> habe ich das Shapefile mit den Buslinien in JOSM importiert. Jetzt habe
> ich den OSM Layer sowie meinen Shapelayer. Den Shapelayer muss ich nun
> richtig tagen. Sind die folgenden Tags soweit richtig:
>
> from
> name
> network
> network:guid
> network:short
> operator
> public:transport:version
> ref
> route
> to
> type
>
> Ist generell dieser Ablauf so korrekt?
>
> Nun frage ich mich auch noch, wie ich die neuen Buslinien mit den schon
> vorhandenen verknüpfe? Bzw wie erstelle ich die Realtionen von den
> Buslinien zu den Straßen?
>
> Vielen Dank im voraus, Philip
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
>
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk] SotM 2020 - Move to virtual conference

[Jo]

The reason I'm asking is that I couldn't request a scholarship this year
and SA is too far to travel to at my own expense. Thus, I didn't propose a
talk. If the conference becomes virtual that changes completely.

If things change, I'll most likely (proof)-read it in WeeklyOSM.

Cheers,

Jo

On Thu, Mar 26, 2020 at 2:45 PM Christine Karch 
wrote:

> Hi,
>
> the deadline ended a month ago. At the moment it is not planned to call
> for additional submissions. We will ask the speakers of "accepted talks"
> first, and then see what the feedback is. If we have too much
> cancellations, we would make an additional call. But this is not planned
> at the moment, just a thought.
>
> Cheers,
>
> Christine
>
> Am 26.03.20 um 14:41 schrieb Jo:
> > Hi Christine,
> >
> > That's great news, better than to have to cancel it completely anyway.
> >
> > If the conference is virtual, I wouldn't mind submitting a talk for it.
> > Is this still possible?
> >
> > Polyglot
> >
> > On Thu, Mar 26, 2020 at 1:50 PM Christine Karch  > <mailto:christ...@hermione.de>> wrote:
> >
> > Hi all,
> >
> > SotM 2020 will be a virtual conference!
> >
> > Due to the high infection risk of SARS-COV-2 virus and all its
> > consequences like travel restrictions, cancellation of physical
> > meetings, "social distancing", and more, a physical SotM is not
> possible
> > this year.
> >
> > The local team - who have done great work preparing this conference
> so
> > far - have suggested to change the physical conference to a virtual
> one.
> > This wasn't just an idle talk:  they have already started a cool open
> > source software project - https://gitlab.com/billowconf/billowconf
> for
> > managing this!
> >
> > So the SotM working group adopted this plan, and agreed to have a
> > virtual SotM conference this year instead of a physical one.
> >
> > We know about your disappointment not meeting each other physically
> this
> > year (we are disappointed too), but after a few months of lockdown
> and
> > "social distancing" we are sure we will all be excited to be reading
> and
> > seeing each other in chats and videos. We will share more of the
> > technical plans as the date comes closer.
> >
> > The date of the conference will stay the same, but shortened to two
> > days: 4-5 July 2020. We planned an extended Q session after each
> talk
> > and plenty of free spaces for discussions. So that the OpenStreetMap
> > community can have a great week-end together.
> >
> >
> > Christine
> >
> > on behalf of State of the Map Working Group
> >
> > ___
> > talk mailing list
> > talk@openstreetmap.org <mailto:talk@openstreetmap.org>
> > https://lists.openstreetmap.org/listinfo/talk
> >
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk