Re: [OSM-talk-fr] [édition mécanique] remplacer 300 noeud school=entrance par entrance=yes en France métropolitaine

2022-06-10 Thread Topographe Fou
Ok pour moi en faisant attention à l'éventuelle clé entrance qui serait déjà 
présente. Merci. 



LeTopographeFou


  Message original  


De: marc_m...@mailo.com
Envoyé: 10 juin 2022 10:38 AM
À: talk-fr@openstreetmap.org
Répondre à: talk-fr@openstreetmap.org
Objet: [OSM-talk-fr] [édition mécanique] remplacer 300 noeud school=entrance 
par entrance=yes en France métropolitaine


Bonjour,

sur la liste tagging, cela parle de la veille clef school=entrance
dans les faits et les logiciels, cela a été remplacé par
entrance=yes/main/...

je propose de remplacer les 300 occurrences de school=entrance
par entrance=yes sur des noeuds en France métropolitaine

avis ?

PS: les 16 occurences sur des ways ne sont pas concerné par
l'opération (il vaut mieux les traiter à la main)
https://overpass-turbo.eu/s/1jbM
si je prend un exemple https://www.openstreetmap.org/way/256137216
c'est à rempalcer par un noeud entrance=yes commun entre la voie et
l'emprise de l'école
je les traiterai à la main, si qlq souhaites le faire, je suis partageur :)

Cordialement,
Marc



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


Re: [OSM-talk-fr] facebook et contact:facebook sont dans un bateau

2022-02-23 Thread Topographe Fou
Bonjour,

Sujet sensible en vue : le problème c'est que même si c'est une ref c'est loin 
d'être un cas isolé. Wikidata aussi devrait être une ref... Comme wikipedia 
d'ailleurs. Et que le simple mot "dépréciation" déclenche des alarmes attaque 
nucléaire chez certains. Et je ne parle pas de "mechanical edit".

Cela me rappelle le débat qu'il y a eu sur la clé booking (qui elle pose en 
plus un problème d'ambiguïté entre la marque et le fait de spécifier comment 
réserver). Au final le wiki recommande des clés alternatives et laisse le tag 
utilisable avec deux définitions possibles... C'est dommage.

De manière constructive l'idéal serait d'abord de promouvoir un ref:facebook 
(avec juste la clé) au nom de la cohérence (même si tous les équivalents ne 
sont pas alignés). Et en roue de secours de promouvoir contact:facebook à la 
place de facebook (en plus selon taginfo cela irait dans le sens le moins 
risqué).

Cordialement, 

LeTopographeFou


  Message original  


De: osm.sanspourr...@spamgourmet.com
Envoyé: 24 février 2022 12:19 AM
À: talk-fr@openstreetmap.org
Répondre à: talk-fr@openstreetmap.org
Objet: [OSM-talk-fr] facebook et contact:facebook sont dans un bateau


Bonjour,

à l'origine facebook= faisait référence à la page FB de l'objet et
contact:facebook n'était à utiliser que si la page servait de moyen de
contact.

Comme FB force la main et fait de facto un moyen de contacter, comme
l'usage est de plus en plus d'utiliser contact:facebook, je serais pour
unifier.

Donc vers facebook= et en utilisant le nom de l'utilisateur dans FB.
Logiquement ça devrait être plutôt ref:facebook, mais bon...

Du coup une proposition de dépréciation et d'édition massive, vous en
pensez quoi ?

https://wiki.openstreetmap.org/wiki/Key:contact:facebook

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

Jean-Yvon



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


Re: [OSM-talk-fr] MS BOT

2022-02-23 Thread Topographe Fou
Bonjour,

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

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

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

LeTopographeFou


  Message original  


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



Le 23/02/2022 à 15:15, Marc SIBERT a écrit :
> J'ai mis à jour la page Wiki ;-)
> Et oui https://fr.wikipedia.org/wiki/Quentin_de_La_Tour prend une
> majuscule à 'La'.

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


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

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

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

bonne soirée

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


Re: [OSM-talk-fr] Tag bons d'achat locaux

2020-12-13 Thread Topographe Fou
  Bonjour,Là comme cela à froid je ne vois pas la pertinence du suffixe :covid19. J'imagine que ces bons ont une durée dans le temps indépendante de la situation sanitaire. La clé (ou la valeur, m'enfin je préfère la clé) doit plutôt permettre d'identifier quels titres sont valables en un lieu donné (car il est possible qu'il y en ait plusieurs grâce à notre millefeuille territorial).Pour le reste de la clé je ne connais pas assez bien les systèmes en place mais me rappel que nous avons eu une discussion récente sur les chèques ANCV et titres restaurants. La problématique me parait liée. Malheureusement je ne crois pas qu'un consensus clair ait émergé (j'accepterai une contradiction avec plaisir).Cordialement,  LeTopographeFou   De: laurent.magrea...@gmail.comEnvoyé: 13 décembre 2020 6:41 PMÀ: talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: [OSM-talk-fr] Tag bons d'achat locaux  Bonjour,Dans le Jura, deux territoires ont mis en place des "bons d'achat bonifiés" pour aider les commerces locaux :- autour de Champagnole, ce sont des "chèques solidaires" : https://www.commerces-champagnole.com/cheques-solidaires.htm- pour la communauté de communes Terre d'Émeraude, des "chèques bonifiés" : https://www.terredemeraude.fr/economie/bons-dachats-bonifies/Je suppose que ça existe dans d'autres départements.Le principe : des points de ventes pour acheter les bons et des commerces éligibles pour les dépenser. Les bons d'un territoire ne sont pas utilisables dans un autre territoire (réseaux distincts qui ne devraient pas se chevaucher à première vue).Je cherche le tag approprié pour :- les commerces éligibles : On trouve sur tag info quelques occurrences en Italie de payment:voucher:covid19=yes https://taginfo.openstreetmap.org/keys/payment%3Avoucher%3Acovid19- les points de vente : change:voucher:covid19=yes sur le modèle des monnaies locales ?https://wiki.openstreetmap.org/wiki/User:FrViPofm/Key:local_currency#XLT-PIVEIl y a toujours la problématique des réseaux distincts. Faut-il multiplier les clés ?Après ça reste un dispositif limité dans le temps. Donc est-ce que ça a sa place dans OSM...Merci pour vos retours éclairés,___)```)___Laurent Magréault d'Attoma@ : laurent.magrea...@gmail.com
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] [édition de masse] convertir le tag déprécié diaper par le tag approuvé changing_table

2020-11-29 Thread Topographe Fou
Bonjour,

Je ne peux pas regarder le détail de ces objets sur Overpass faute d'accès 
Internet adapté mais ok sur le principe.

Cordialement 

LeTopographeFou


  Message original  


De: marc_m...@mailo.com
Envoyé: 27 novembre 2020 8:00 PM
À: talk-fr@openstreetmap.org
Répondre à: talk-fr@openstreetmap.org
Objet: [OSM-talk-fr] [édition de masse] convertir le tag déprécié diaper par le 
tag approuvé changing_table


Bonjour,

et justement puisque j'en parle dans l'autre email,
je propose l'édition de masse suivante :
étendue géographique : la France métropolitaine (je ferrai
des messages auprès d'autres communautés pour les cas
présents ailleurs)
cible :
- les (193) objets ayant le tag diaper déprécié en juin 2019
à remplacer par le tag approuvé changing_table
- les (7) objets ayant le tag diaper et changing_table
avec la même valeur

avis/accord/objection ?

Cordialement,
Marc



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


Re: [OSM-talk-fr] proposition nouvel attribut : Detecteur de Victime en Avalanche

2020-11-24 Thread Topographe Fou
Bonjour Marc,

Si je comprend bien le contenu du mail (en laissant de côté son sujet qui est 
un peu différent) François ne veut pas cartographier des zones nécessitant un 
DVA mais des bornes qui permettent de tester qu'un DVA fonctionne bien avant de 
partir à l'aventure.

Cordialement, 

LeTopographeFou


  Message original  


De: marc_m...@mailo.com
Envoyé: 24 novembre 2020 2:51 PM
À: talk-fr@openstreetmap.org
Répondre à: talk-fr@openstreetmap.org
Objet: Re: [OSM-talk-fr] proposition nouvel attribut : Detecteur de Victime en 
Avalanche


Bonjour François et bienvenue,

Le 24.11.20 à 13:06, François Bojarski via Talk-fr a écrit :
> je viens prendre la température pour
> la proposition d'un nouveau tag

c'est toujours une bonne idée de surtout récolter
un maximum d'avis.

> Detecteur de Victime en Avalanche (DVA en français, avalanche beacon
> in english). Ce sont des petits boitiers que l'on peut trouver
> dans les stations aux départs de certains grands hors pistes

si je comprend bien la page wikipedia [1], c'est un appareil
émetteur/récepteur qu'un sauveteur utilise pour rechercher
un sinistré en ayant lui aussi une.

si c'est correct, que souhaites-tu renseigner ?
l'obligation d'en avoir un sur une zone ?
un magasin/comptoir/stock en libre service pour en emprunter ?

> dva_check

le terme en fr n'est sûrement pas approprié.
wikipedia anglais renseigne 2 termes
avalanche transceiver
avalanche beacon
je n'ai aucune idée si l'un des 2 est en anglais britanique,
la ml tagging serra sans doute + approprié pour le choix
final du terme
dans osm il y a une occurrence de chaque
https://www.openstreetmap.org/way/243463638
https://www.openstreetmap.org/way/98247837

[1] https://fr.wikipedia.org/wiki/D%C3%A9tecteur_de_victimes_d%27avalanches

Cordialement,
Marc



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


Re: [OSM-talk-fr] Réimport (Re: Import des horaires des bureaux de poste)

2020-11-14 Thread Topographe Fou
Ok, ca semble coller, je rajouterai juste (car ton mail très explicite et 
synthétique omettait néanmoins un détail) que dans ton dernier cas où quelqu'un 
a touché aux horaires idéalement on ne lève le drapeau que si le nouvel horaire 
osm est different du nouvel horaire Datanova (ce qui sera probablement souvent 
le cas car je doute que tout le monde rajoute les infos PH ou factorise les 
horaires de la même manière). Pas sûr que la comparaison soit aisée mais cela 
pourrait limiter les flags quand c'est trivial.

LeTopographeFou


  Message original  


De: osm.sanspourr...@spamgourmet.com
Envoyé: 14 novembre 2020 10:28 PM
À: talk-fr@openstreetmap.org
Répondre à: talk-fr@openstreetmap.org
Objet: Re: [OSM-talk-fr] Réimport (Re: Import des horaires des bureaux de poste)


Bonjour, je crois qu'il y a bien plus simple.

Un seul champ nous intéresse, c'est la plage horaire.

Donc David est maintenant convaincu de garder les infos qu'il garde dans
un coin d'une fois sur l'autre.

Il suffit alors de comparer la plage de l'époque, la place actuelle
(pour une même ref:FR:LaPoste), des personnes peuvent avoir déplacé le
bureau de poste, ajouté des précisions sur l'accès handicapé, on s'en
fiche, on prend que qu'il y actuellement en base.

Et là si personne n'a touché aux horaires, on met la nouvelle version
(et seulement s'il y a une évolution).

Si quelqu'un a touché aux horaires, on lève le drapeau fixme et on
ajoute suggested:opening_hours.

Jean-Yvon

Le 14/11/2020 à 17:41, Topographe Fou - letopographe...@gmail.com a écrit :
> Bonjour,
>
> D'accord sur le fait qu'il faut oublier 1 et privilégier 2.
>
> Cependant je pense qu'il faut aménager le cas où le dernier à avoir modifié 
> n'est pas le robot car sinon petit à petit on se retrouvera avec des données 
> qui n'ont pas été mises à jour depuis 10 ans et le problème sera le même. 
> Genre je déplace le POI mais ne fais pas attention à la validité de ses tags, 
> du coup le POI sera ignoré ad vitam aeternam.
>
> Je pense à passer de :
>
> "si le dernier à avoir modifié est le robot Datanova ET si les données ont 
> évoluées depuis"


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


Re: [OSM-talk-fr] Réimport (Re: Import des horaires des bureaux de poste)

2020-11-14 Thread Topographe Fou
Bonjour,

D'accord sur le fait qu'il faut oublier 1 et privilégier 2.

Cependant je pense qu'il faut aménager le cas où le dernier à avoir modifié 
n'est pas le robot car sinon petit à petit on se retrouvera avec des données 
qui n'ont pas été mises à jour depuis 10 ans et le problème sera le même. Genre 
je déplace le POI mais ne fais pas attention à la validité de ses tags, du coup 
le POI sera ignoré ad vitam aeternam.

Je pense à passer de :

"si le dernier à avoir modifié est le robot Datanova ET si les données ont 
évoluées depuis"

 À :

"(si le dernier à avoir modifié est le robot Datanova OU si l'objet n'a pas été 
touché depuis X) ET si les données ont évoluées depuis"

Avec mettons X = 2 ans par exemple. Ce qui permet aux POI à l'abandon d'avoir 
une chance de salut.

Et comme dit par quelqu'un précédemment il faut bien comparer selon les 
ref:FR:LaPoste et non les id de way ou node car ces derniers sont volatiles 
(genre je converti un node en way ou bien je redessine toute une zone from 
scratch car j'aime bien réécrire l'histoire).

LeTopographeFou


  Message original  


De: osm.sanspourr...@spamgourmet.com
Envoyé: 13 novembre 2020 11:37 PM
À: talk-fr@openstreetmap.org
Répondre à: talk-fr@openstreetmap.org
Objet: Re: [OSM-talk-fr] Réimport (Re: Import des horaires des bureaux de poste)


Ça tu oublies, oui tu sauve à part.

Tu peux aussi regarder avec overpass les bureaux qui ont changé depuis
ton import.

Car overpass te permet d'inspecter l'historique de la base.

Par exemple si le dernier à avoir modifié l'objet c'est ton robot, tu
peux foncer.

Et sinon tu prends l'image juste après ton dernier import : un export
CSV par exemple daté avec id, opening_hours et dernier modificateur (si
tu veux vérifier que c'est bien les données du robot afin de ne pas
tester tout opening_hours).

Jean-Yvon

Le 13/11/2020 à 22:32, David Faure via Talk-fr -
talk-fr@openstreetmap.org a écrit :
> 1) quand je sauve un opening_hours (sur un objet qui n'en avait pas, donc),
> je le duplique dans un tag spécifique (datanova:opening_hours ou un truc comme
> ça) que je sauve aussi dans l'objet. Au moment du réimport je compare les deux
> champs, et je ne met à jour (les deux) que s'ils sont encore égaux. Sinon
> c'est que quelqu'un a fait un changement, alors j'y touche plus (et on passe
> sur la solution du fixme et de la suggestion, auquel cas ça fait quand même
> trois champs qui parlent d'horaires d'ouverture, au total...).


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


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

2020-10-28 Thread Topographe Fou
  Oui ce style de pancarte ou un simple A4 disant "Nous ne faisons pas les tests PCR" ou "Nous faisons les tests PCR, appeler au 0x" . LeTopographeFou   De: yves.prat...@gmail.comEnvoyé: 28 octobre 2020 10:58 AMÀ: talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: Re: [OSM-talk-fr] Projet du mois Décembre : lieux de test COVID (était "Carte des lieux de test COVID")  Retour d'expérience d'un de mes collègues : le site sante.fr contiendrait pas mal de données obsolètes. Sur les 10-15 lieux autour de chez lui qu'il a appelé fin septembre, tous lui ont dit qu'ils ne faisaient plus les tests. Merci pour ce retour.Cela ouvre par contre un champ où osm pourrait contribuer à la qualité des données et pourquoi pas reverser à l'ARS ou autre.Oui, sauf que la licence osm ne le permet pas. L'ARS regarde pour rendre compatible sa licence de GEODAE avec la notre.Je vois plusieurs pistes.Ajouter les labos absent d'OSM.Améliorer leur localisation.Mettre à jour les données ref:FR:FINESStéléphone, site web, email...Une partie peut se faire automatiquement.Quand à faire remonter l'info à l'ARS concernant la possibilité de se faire tester pour le covid-19, on peut en discuter avec notre contact ?  Le principe de correlation avec une source terrain me parait donc encore plus indispensable que d'habitude (les labos près de chez moi ont tous une pancarte disant si oui ou non ils peuvent faire du PCR et/ou du virologique).Une pancarte de ce style ?https://94.citoyens.com/2020/un-nouveau-centre-de-depistage-covid-19-sans-rdv-a-la-defense,30-09-2020.html__Yves
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


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

2020-10-28 Thread Topographe Fou
  Bonjour,Retour d'expérience d'un de mes collègues : le site sante.fr contiendrait pas mal de données obsolètes. Sur les 10-15 lieux autour de chez lui qu'il a appelé fin septembre, tous lui ont dit qu'ils ne faisaient plus les tests. J'ignore l'ampleur du problème mais cela refroidit pas mal pour utiliser des données ARS telles quelles. Il a finit pas réserver sur Doctolib... Cela ouvre par contre un champ où osm pourrait contribuer à la qualité des données et pourquoi pas reverser à l'ARS ou autre.Le principe de correlation avec une source terrain me parait donc encore plus indispensable que d'habitude (les labos près de chez moi ont tous une pancarte disant si oui ou non ils peuvent faire du PCR et/ou du virologique).Cordialement,  LeTopographeFou   De: yves.prat...@gmail.comEnvoyé: 27 octobre 2020 6:41 PMÀ: talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: Re: [OSM-talk-fr] Projet du mois Décembre : lieux de test COVID (était "Carte des lieux de test COVID")  c'est dans le langage courant ce n'est pas
  le test qui est introduit dans le nez, - est-ce qu'on indique les différents types de test ?A priori je ne vois pas l'intérêt de saisir ça dans OSM.J'imagine qu'on va au centre le plus proche... le reste concerne les médecins.De plus les critères de l'ARS sont les suivants :Prélèvement Covid-19 (3388)Prélèvement Covid-19 Créneaux pour personnes prioritaires (236)Prélèvement Covid-19 - Temporaire (72)Prélèvement Covid-19 - Personnes prioritaires uniquement (53)ce sont les
  mêmes dans tous les pays ?Je pense que non
Le labo prés de chez moi ne propose ces tests qu'à certaines
  heures, qui ne sont pas les mêmes que celles d'ouverture du labo
  (opening_hours)Bonne remarque : En théorie on peut noter tout ça dans opening_hours...Concernant le nombre, 3749 ça fait beaucoup.Mais on doit en avoir aussi pas mal dans OSM Après conflation, je pense qu'il faut se concentrer sur les autres.Une question reste en suspend pour moi : ou trouver les données ?Je ne vois pas de lien sur le site de L'ARS : https://sante.fr/recherche/trouver/DepistageCovid#Je pense qu'un coup de fil à l'ARS s'impose.__Yves
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Nominatim et plan d'eau

2020-10-17 Thread Topographe Fou
  Philippe, comme tous les projets "l'approximation", le "bancale", le "n'importe comment" et le "stupide" ne pourront s'améliorer qu'avec des humains derrière. Et ces humains, comme tous les humains qu'ils soient de Nominatim ou d'ailleurs, méritent mieux comme encouragement (et remerciements) que ce que j'ai lu à deux reprises aujourd'hui.  Quand bien même le fond serait juste, la forme est juste écoeurante, ce qui gâche tout.Sans avoir à rentrer dans le code tu peux rédiger un ticket sans ces jugements pour apporter ta pierre à l'édifice.Cordialement  LeTopographeFou   De: ver...@gmail.comEnvoyé: 17 octobre 2020 5:52 PMÀ: talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: Re: [OSM-talk-fr] Nominatim et plan d'eau  En fait Nominatim traite les éléments naturels quels que soit leur taille comme des noeuds et leur attribue un admin_level=15 (totalement synthétique) pour classer les résultats. Il les considère plus petits que les noms de batiments (house_name) auxquels il veut les attacher pouyr attribuer une adresse et sinon il cherche un highway.Ces éléments naturels sont donc classés n'importe comment.Et je ne spécule pas du tout sur le fait qu'il crée bel et bien des noeuds "place" artificiels, avec un id interne puisque c'est bien ce qu'il affiche dans ses résultats. Et peu importe si cela ne correspond à rien et que l'attribut synthétique admin_level ne correspond lui aussi à rien du tout. La logique est totalement fausse qui conduit à les "rattacher" à d'autres objets très éloignés et arbitraires qui n'incluient pourtant même pas du tout ces noeuds synthétiques.C'est une très grossière approximation de Nominatim: on ne peut pas réduire ces objets à un simple noeud et Nominatim ne sait pas leur attacher plutôt une bounding box pour avoir quelquechose de plus pertinent. Il se base juste sur une mesure de distance entre deux noeuds (dont le noeud artificiel et un autre noeud arbitraire d'un highway ou d'un vraie relation boundary).C'est très bancale. C'est un gros manque sur quelquechose qu'i n'a pas été réellement développé mais laissé en vrac dans une classe fourre-tout (pseudo-admin_level=15) en attendant un développement sérieux.Tant que ces objets restent assimilable à un noeud et qu'ils sont réellement inclus dans une relation admin_level ou assez proche à un highway indexés pour les rendre "routables" (Nominatim n'indexe pas tous les highways, seulement ceux ayant un nom ou un numéro de référence) il va retourner n'importe quoi, c'est le hasard le plus complet en terme de classification, il n'y a strictement rien qui soit alors réellement pertinent.Personellement je pense qu'une première amélioration de Nominatim serait qu'il vire les noeuds "place" synthétiques pour les objets qui ne sont pas des noeuds (objets linéraires et surfaces polygonales/multi-polygonales), et qu'il les remplace au moins par des bounding box, afin de rendre les calculs de pertinence bien meilleurs. Et il devrait le faire au moins pour tous les objets actuellement classés en pseudo-admin_level=15. et sans doute aussi (après tests pour éveluer les effets de bords dans la détermination des adresses) pour les highways (quoique pour eux il vaudrait sans doute mieux qu'il indexe les deux extrémités, à moins que ce soit un chemin fermé ou que ce soit un "polyligne" formant des branches ou un réseau dans une relation assimilable alors à une surface approximée par la boundingbox)Le sam. 17 oct. 2020 à 15:56, Sarah Hoffmann  a écrit :Bonjour,

apropos la question pourquoi un lac s'attache a une rue et prends
son adresse. C'est justement quelque chose qu'il faut revoir et
probablement reviser. L'attachement aux rues marche bien pour les
petits POIs comme boite aux lettres ou des supermarches. Ca marche
meme bien pour un petit pont de village mais ce n'est pas une bonne
idee pour les grandes lacs ou baies.

Quand a toutes les autres speculations, j'ai vraiment pas envie de
les discuter parce qu'ils sont exactement ca: speculations qui ont
rien du tout a voir avec comment Nominatim fonctionne. 

Sarah

On Sat, Oct 17, 2020 at 01:00:36PM +0200, Philippe Verdy wrote:
> Tu ne réponds pas à la question ni au cas évoqué autour de
> l'Île-Saint-Denis.
> 
> En effet strictement rien n'associe ce polygone à la route en tant
> "qu'adresse". C'est stupide comme association surtout pour ce type
> d'élément. De plus c'est Nominatim qui en interne a généré un "place node"
> (avec un ID interne) sur le polygone (il n'y a aucun node dans le polygone).
> 
> En créant ce "place node", c'est là qu'il a cherché stupidement à lui
> donner une adresse et à chercher une route proche. Et c'est là que
> l'approximation 

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

2020-10-01 Thread Topographe Fou
 HS : à chaud mon côté codeur me fait dire "quand il faut prendre une sortie liste toutes les ways qui ont une destination, découpe les tags au point-virgule et énonce les destinations de la way souhaitée dans l'ordre (donc du plus important au moins important) jusqu'à avoir ennoncé une destination qui n'est pas dans les autres ways" . Cela me parait plus souple et implementable (et il va souvent en citer moins que 3). LeTopographeFou   De: panierav...@riseup.netEnvoyé: 1 octobre 2020 9:10 AMÀ: talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: Re: [OSM-talk-fr] validation : sorties nommées  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.Le 01/10/2020 à 08:47, Topographe Fou a
  écrit :

  
  
  
Bonjour,


Il vaut mieux ouvrir un ticket côté OsmAnd
  (il en existe peut-être déjà un ?) et laisser les données
  complètes dans OSM, même si c'est une liste à la Prévert.
  Idéalement à chaque intersection il faudrait qu'un routeur
  énonce le juste nombre de destination (avec un minimum de 1
  destination, sans oublier la ref) permettant au conducteur de
  discerner la voie à prendre. Car parfois une suffit, dans
  d'autres cas il en faudrait au moins 2 ou 3 pour dedoublonner.
  Avoir un seuil arbitraire sera toujours contestable.


Je rejoint les commentaires fait sur
  OsmAnd : très pratique qu'il donne les destinations même si en
  effet dans certaines intersections très denses ou des cas
  triviaux (genre sortie sur l'autoroute clairement isolée) il
  en devient trop bavard.
 


  LeTopographeFou

  
  


  De: perche...@toutenkamion.net
  Envoyé: 1 octobre 2020 6:31 AM
  À: talk-fr@openstreetmap.org
  Répondre à:
talk-fr@openstreetmap.org
  Objet: Re: [OSM-talk-fr]
validation : sorties nommées

  

  
  
  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 Pley

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

2020-10-01 Thread Topographe Fou
 Bonjour,Il vaut mieux ouvrir un ticket côté OsmAnd (il en existe peut-être déjà un ?) et laisser les données complètes dans OSM, même si c'est une liste à la Prévert. Idéalement à chaque intersection il faudrait qu'un routeur énonce le juste nombre de destination (avec un minimum de 1 destination, sans oublier la ref) permettant au conducteur de discerner la voie à prendre. Car parfois une suffit, dans d'autres cas il en faudrait au moins 2 ou 3 pour dedoublonner. Avoir un seuil arbitraire sera toujours contestable.Je rejoint les commentaires fait sur OsmAnd : très pratique qu'il donne les destinations même si en effet dans certaines intersections très denses ou des cas triviaux (genre sortie sur l'autoroute clairement isolée) il en devient trop bavard. LeTopographeFou   De: perche...@toutenkamion.netEnvoyé: 1 octobre 2020 6:31 AMÀ: talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: Re: [OSM-talk-fr] validation : sorties nommées  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 touristiqueOsmand é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/217668457Peut ê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=258An Teir C'hoazPLEYBENMORLAIXpar Route Touristique.ref et name sont clairs.Pour destination :1. Rien, les destination Pleyben et Morlaix ne sont pas jointes viacette sortie normalement (60 Ar Pouilhod pour Pleyben et pour 64 PontaolMorlaix).2. Pleyben;Morlaix, ça permet aux navigateurs de vous guider.3. Pleyben;Morlaix;par route touristique, ça permet aux navigateurs demieux 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 untype de route pas une destination, à la limite un "via".1 a l'avantage de ne pas risquer d'induire les moteurs en erreur (maisils ne semblent pas tenir compte des panneaux pour inciter à passer partel 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 dessorties.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" mesemble 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/12123625Et la bretelle est nommée : https://www.openstreetmap.org/way/4043036alors qu'elle n'a pas de nom au cadastre. A supprimer à mon avis (lenom, pas la bretelle ;-)).Jean-YvonTalk-fr mailing listTalk-fr@openstreetmap.orghttps://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] Sources pour mise à jour d'aire d'autoroute ?

2020-09-21 Thread Topographe Fou
 Bonjour,Je fais comme toi sauf que j'utilise fixme au lieu de source (genre fixme="Contours du batiment approximatif" ou blabla similaire).Un fixme= a l'avantage de déclencher une alerte côté outils d'analyses qualité et amener quelqu'un à corriger dès que possible. Par ailleurs source='memory' correspond à une modification effectuée de mémoire et non pas un relevé depuis des photos ou sur le terrain.   LeTopographeFou   De: osm.jlzimmerm...@gmail.comEnvoyé: 21 septembre 2020 10:35 AMÀ: talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: Re: [OSM-talk-fr] Sources pour mise à jour d'aire d'autoroute ?  Bonjour,Si tu te mets sur Maxar (ID) on voit les terrassements. Après ce que je fais souvent c'est une géométrie grossière et probable et je met source=memoryLe lun. 21 sept. 2020 à 08:22, Yves P.  a écrit :Bonjour,Près d'Auxerre, l'aire de Venoy Grosse Pierre sur l'A6 (direction Paris - Lyon) n'est plus à jour. Un nouveau bâtiment regroupant la boutique Total et le Mc Do à été construit.Mais il n'apparait pas ni sur le cadastre, ni sur BDOrtho IGN, ni sur Maxar or Ortho HR, ni même chez Google.Existe-t-il d'autres sources potentielles pour faire la mise à jour ?__YvesL'aire : https://www.openstreetmap.org/way/475643814Le nouveau bâtiment : https://commons.wikimedia.org/wiki/File:Aire_de_Venoy-Grosse_Pierre_-_Boutique.jpg


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

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


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

2020-09-13 Thread Topographe Fou
 Bonjour,Cette signalisation est très proche (je n'ose dire identique) de celle existante aux États-Unis, et peut-être ailleurs aussi. Niveau tag et documentation OSM ce sera à première vu du tout cuit. LeTopographeFou   De: ver...@gmail.comEnvoyé: 13 septembre 2020 7:50 PMÀ: talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: [OSM-talk-fr] Covoiturage et véhicules propres : une signalisation expérimentale pour les voies réservées  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
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


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

2020-09-07 Thread Topographe Fou
 Bonjour,Je vois plus de problème que d'avantages à l'utilisation des addr sur les radars :1. Cela revient à utiliser is_in, un tag qui avait une raison d'être à une époque mais qui n'a presque plus de raison de vivre aujourd'hui, surtout dans un pays comme le nôtre ou les différents échelons administratifs sont assez bien cartographiés (Romain, ton approche par area est la bonne, merci pour la suggestion que tu lui fait)2. Je ne comprend pas l'argument du "oui mais moi j'en ai besoin" : dans ce cas on fait la même chose pour les bancs, les lampadaires, les poteaux et les routes, selon les hobbies de chacun ? C'est ingérable et redondant. L'énergie de ce contributeur va être vite usée car je doute que Romain soit le seul à ne pas comprendre la pertinence de ces tags sur un radar.3. il n'y a pas si longtemps on a eu une longue discussion sur l'unicité des adresses. Je vois mal comment en s'arrêtant au pays ou à la ville on est unique.4. rien ne dit qu'une relation radar de vitesse ne soit pas à cheval sur deux villes (en même temps ce n'est peut-être jamais le cas de par les contraintes d'implantation ?)Question naïve : les radars n'ont pas une référence unique pour faciliter les consolidations ?Sinon l'API Nominatim permet de geocoder plusieurs objets à la fois de mémoire pour qui code un minimum.Donc à fond derrière Romain :) LeTopographeFou   De: romain.me...@mailo.comEnvoyé: 6 septembre 2020 10:23 PMÀ: talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: [OSM-talk-fr] Tags addr: pour les radars  Bonjour,Quand j'ai supprimé les polygones boundary=urban, il m'est arrivé
  de faire quelques corrections annexes comme de retirer des tags
  addr:country, addr:city en particulier sur les relations des
  radars de vitesse.Un contributeur m'a contacté car il utilise ces tags pour
  contrôler leur présence via la requête suivante :[out:csv(::id,type,enforcement,"addr:country",maxspeed,"addr:city","addr:postcode","addr:street",ref,milestone,name)];
  relation ["addr:country"="FR"] [type=enforcement]
  [enforcement=maxspeed] ({{bbox}});
  out;Je lui répond qu'OSM étant par nature une base de données
  géographiques, ces tags sont inutiles et que l'on peut remonter
  ces informations pour chaque objet via un géocodage. Il me
  demande alors une requête qui le permet sans les tags addr:J'ai testé ceci :[out:csv(::id,maxspeed,ref,milestone,name,::lat,::lon)];
  area[name="France"]->.pays;
  relation(area.pays) [type=enforcement] [enforcement=maxspeed];
  node(r:device);
  out;et suis passé par https://geo.api.gouv.fr/adresse et
  /reverse/csv/ pour retrouver la ville et le code postal.Vous validez ma méthode et vous êtes d'accord pour retirer les
  tags addr: ?Merci.Romain

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


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

2020-09-02 Thread Topographe Fou
  Bonjour,Suis entièrement d'accord pour source:maxspeed + maxspeed , cela représente bien la réalité et est explicite ce qui est toujours plus clair. En plus c'est un binôme qui peut aider à détecter des incohérences (je crois même me souvenir qu'il existe une analyse Osmose sur ce point) et donc erreurs de saisies ou évolutions du code de la route comme expliqué précédemment. Personnellement je saisie toujours un maxspeed explicite et agrémente occasionnellement d'un source:maxspeedPar ailleurs sémantiquement parlant le préfixe source:x n'a pas de sens pour moi si le tag x n'a pas été défini. Le préfixe source: dénote de l'origine d'un tag avant de dénoter sa valeur. C'est ma compréhension, laquelle peut être contestée. Mais c'est aussi le sens de la première phrase de description du wiki :The source:maxspeed=* tag records the source of a road's maximum speed limit as provided in the maxspeed=* tag to assist with verifiability and maintenance.  LeTopographeFou   De: perche...@toutenkamion.netEnvoyé: 2 septembre 2020 7:17 AMÀ: talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: Re: [OSM-talk-fr] maxspeed par défaut  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:maxspeedLe 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 voiesd'insertion, etc.De nombreuses portions ont une limite de vitesse implicite car il n'ya pas de panneau limitant la vitesse, et les règles généraless'appliquent (R413-2). Le problème est que ces règles sont malconnues, et presque tout a été mal mappé avec maxspeed=80. Pourl'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 toutde même taguer qqch pour faire la différence entre une route demaxspeed inconnue, et une route de maxspeed implicite. Ma question estdonc:Est-ce qu'utiliser source:maxspeed=FR:rural sans maxspeed=* est unebonne pratique?PS: Les règles du code de la route sont si mal connues quehttps://wiki.openstreetmap.org/wiki/FR:Key:maxspeed#Limitation_de_vitessecontient une erreur de 20 km/h.Marc MongenetBonsoir,L'implicite est désormais quasi impossible à deviner. Prends lesnationales à 80 et des portions de départementales à 90. Je me mets à laplace de l'étranger pour qui c'est pire qu'un casse-tête chinois. Onfinit par ne plus savoir la limite en vigueur sur telle ou telle portionde route.Je suis donc partisan de mettre systématiquement le maxspeed=* au moinsc'est clairement renseigné sans équivoque possible.Amitiés-- 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] ref et ref:FR

2020-07-21 Thread Topographe Fou
  Bonjour,Suis pour supprimer la colonne, il y a bien souvent dans les autres déjà des liens vers les annuaires officiels en ligne qui vont bien.Merci pour le toilettage.  LeTopographeFou   De: lenny.li...@orange.frEnvoyé: 20 juillet 2020 7:26 PMÀ: talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: Re: [OSM-talk-fr] ref et ref:FR  
Le 20/07/2020 à 00:39, Yves P. a
  écrit :

  Je propose de supprimer la colonne Tag2Link, ce greffon n'étant plus utilisé.
le greffon n'est plus nécessaire, car il a été intégré dans JOSM
  (https://josm.openstreetmap.de/wiki/Fr%3AHelp/Action/Tag2Link)
  n'en connaissant pas l'utilisation je n'ai pas d'avis, vous me
  confirmez que la colonne n'est plus nécessaire ?leni


  
__
Yves



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


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


Re: [OSM-talk-fr] Envoyer une requête à OSM juste pour connaitre le nombre d'objets ?

2020-07-15 Thread Topographe Fou
Bonjour,

Ce n'est pas satisfaisant pour plus d'une clé et d'un pays mais dans ton cas 
simple tu peux utiliser l'instance Taginfo des Pays-Bas de Geofabrik : 

https://taginfo.geofabrik.de/europe/netherlands/keys/shop#values

2233 objets en l'occurence.

Sinon il y a sûrement moyen de modifier la requête pour passer le timeout mais 
je ne maîtrise pas le barbarisme des codes de sortie Overpass.

LeTopographeFou


  Message original  


De: codecompl...@free.fr
Envoyé: 15 juillet 2020 11:36 AM
À: talk-fr@openstreetmap.org
Répondre à: talk-fr@openstreetmap.org
Objet: [OSM-talk-fr] Envoyer une requête à OSM juste pour connaitre le nombre 
d'objets ?


Bonjour,

Tout est dans le titre : y a-t-il un moyen plus léger d'interroger OSM
pour connaitre le nombre d'objets pour une clé=valeur donnée ?

Par exemple, je voulais connaître le nombre de boutiques de vélo aux
Pays-Bas, mais time out même à 120 secondes :

An error occured during the execution of the overpass query! This is
what overpass API returned:

runtime error: Query timed out in "query" at line 9 after 121 seconds.


[out:json][timeout:120];

//NL 47796
rel(47796);
map_to_area -> .searchArea;

(
node[shop=bicycle](area.searchArea);
way[shop=bicycle](area.searchArea);
);

out body;
>;
out skel qt;



Merci.

PS : Pour une raison inconnue, je ne peux plus poster via l'interface web

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

You Cannot Post Here
Sorry, but you can't create new topics here.
Note that you may still be able to reply to posts.
You may request permission to post here or contact Raven if you
have questions.


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


Re: [OSM-talk-fr] BANO Josm imagerie

2020-07-09 Thread Topographe Fou
Bonjour,

Comme c'est une question récurrente ces derniers temps sur la liste je tente 
une question bête : en attendant la fin du chantier est-il possible de renvoyer 
une image expliquant que c'est en travaux et éventuellement où envoyer des 
pouces d'encouragement / cafés / bières aux oeuvriers ? Je-dis-ca-je-fais-rien.

Le plus simple serait sinon, si ce n'est pas déjà le cas, de renvoyer un code 
d'erreur 501 (maintenance / fonction à venir) mais pas sûr que JOSM adapte son 
message pour autant (idée de ticket pour eux). Cela pourrait bénéficier à tous 
les serveurs de tuiles faisant une maintenance s'il le faisait. Et éviterai de 
générer du traffic de tuiles et des problèmes de caches.

LeTopographeFou


  Message original  


De: osm.v...@free.fr
Envoyé: 9 juillet 2020 6:45 PM
À: talk-fr@openstreetmap.org
Répondre à: talk-fr@openstreetmap.org
Objet: Re: [OSM-talk-fr] BANO Josm imagerie


Bonjour,

> De: "Cyrille37 OSM" 
>
> Dans Josm le tms de BANO est défini ainsi :
> tms[12,20]:https://{switch:a,b,c}.layers.openstreetmap.fr/bano/{zoom}/{x}/{y}.png
>
> Et il retourne "Erreur, Pas de tuiles à ce niveau de zoom" quelque
> soit le zoom.

Oui, on est au milieu du gué, les tuiles BANO v1 n'existent plus, et les tuiles 
BANO v2 pas encore.
La balle est dans mon camp (avec Christian pas loin, merci) mais mon temps ces 
jours-ci est difficile à trouver.

merci pour votre patience
vincent

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


Re: [OSM-talk-fr] Message de service :: Travaux sur l'infra 6/7 après-midi.

2020-07-09 Thread Topographe Fou
Merci à tous !


LeTopographeFou


  Message original  


De: cqu...@openstreetmap.fr
Envoyé: 8 juillet 2020 12:14 AM
À: talk-fr@openstreetmap.org
Répondre à: talk-fr@openstreetmap.org
Objet: Re: [OSM-talk-fr] Message de service :: Travaux sur l'infra 6/7 
après-midi.


Le 06/07/2020 à 12:22, Jacques Lavignotte a écrit :
>
> Cet après-midi, intervention pour upgrade matériel sur nos serveurs
> osm12 et osm13 chez Free.
>
> Quelques coupures sont à prévoir.
>
> Liste des serveurs/services :
>
> https://wiki.openstreetmap.org/wiki/FR:Serveurs_OpenStreetMap_France
>
>

Pour vous tenir au courant, voici ce qui a été fait ces derniers temps
sur notre infra:

- mi-juin, nous avons fait un upgrade logiciel de nos 4 serveurs OVH (le
serveur de rendu FR + le cluster de 3 serveurs).

Il s'agissait de passer à la version 6 de Proxmox, la distrib linux que
nous utilisons et qui nous permet de gérer la virtualisation des
différents services.


- hier, j'ai procédé à l'upgrade hardware du côté de la fondation free

4 nouveaux SSD de 2To chacun ont été installés pour étendre la capacité
et accélérer les accès disque. Ces serveurs, don de la fondation free en
2012, voient ainsi leur espérance de vie rallonger de quelques années.
Les données OSM ne font qu'augmenter en volume et en détail et le trafic
a largement augmenter lui aussi en 8 ans, d'où le besoin de toujours
plus d'espace de stockage rapide !

Pour mémoire, ces serveurs n'avaient aucun SSD à l'origine, nous avons
dû en ajouter au fur et à mesure des années alors que la charge montait
(et continue de monter).

La RAM a aussi été augmentée (64+64Go devenus 160+96Go) et un 4ème
serveur (récupéré gratuitement il y a quelques mois) a aussi été
installé temporairement pour faciliter les mises à jour des 3 autres
déjà présents.


Depuis hier, migration des données sur les nouveaux SSD, un peu de
nettoyage et quelques upgrades sotfware pour osm13 qui assure à nouveau
un service normal pour le rendu humanitaire, les rendus Route500,
Carthage, QA et les rendus "layers".

Il y a eu quelques coupures sur cadastre.openstreetmap.fr et
download.openstreetmap.Fr qui ont été résolus ce matin.


Aventures à suivre... car il y a d'autres épisodes prévus ;)

--
Christian Quest - OpenStreetMap France


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


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

2020-07-01 Thread Topographe Fou
  Personnellement et même si le raisonnement est fragile j'ai toujours perçu les addr: comme des propriétés d'un objet, le tag "principal" qui fait la nature d'un objet étant amenity ou shop ou building ou office ou... Ce qui ne m'empêche pas de trouver une pertinence à leur usage sur des noeuds isolés comme la plupart des objets ayant une adresse à ma connaissance car il faut bien localiser les adresses. Avec un tag type amenity=addr là on pourrait gérer une notion d'unicité d'adresse en rentrant de plein pied dans la règle une feature = un objet et sans s'interdire d'avoir la même adresse sur un cinéma. Mais c'est probablement trop tard pour changer. Pour le coup on peut décider de le faire en France sans tout casser/nous isoler (transparent pour les consommateurs de données, les outils de QA sont assez souples, reste le pb des éditeurs).Je comprend l'esprit de la "décision communautaire" en France mais les adresses sont un pilier des données géographiques que l'on ne peut guère gérer à notre guise. Surtout quand les outils ne suivent pas et incitent à remplir addr:xxx  Reste que l'adresse postale/cadastre n'est pas forcément l'adresse de contact...  LeTopographeFou   De: winner...@free.frEnvoyé: 30 juin 2020 11:30 PMÀ: talk-fr@openstreetmap.org; christian.qu...@gmail.com; v...@laposte.netRépondre à: talk-fr@openstreetmap.orgObjet: Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas  Pour en rajouter une couche, quand on voit la progression de la courbe des tags "contact:" liée aux adresses, elle est carrément flat :https://taghistory.raifer.tech/#***/contact:street/&***/contact:housenumber/&***/contact:postcode/&***/addr:street/&***/addr:housenumber/&***/addr:postcode/Le mar. 30 juin 2020 à 23:18, Florian LAINEZ  a écrit :@jérome @jean-yvon @Yves je suis très conscient des effets de bords que vous mentionnez et je suis embêté.A vrai dire je suis à deux doigts de suggérer d'abandonner totalement ces "contact:" à tout jamais.Je constate en effet que 9500 contact:street sont en France sur les 10300 utilisés de par le Monde, soit 92%. Autant dire que c'est un tag franco-français.Cela me fait réfléchir sérieusement : @christian @vdct pourriez-vous svp rappeler les raisons qui nous ont poussé à utiliser ces tags ?Y a-t-il d'autres raisons que celle, évidente, d'éviter les doublons d'adresse ? Est-ce que cela justifie vraiment de créer tout un jeu de tags qui n'est utilisé que par les français et qui restera durablement incompatible avec les outils d'édition prédominants ?Ces tags n'apparaissent pas sur les pages https://wiki.openstreetmap.org/wiki/FR:Adresseshttps://wiki.openstreetmap.org/wiki/FR:Key:contactPar ailleurs le graphique en haut de la page https://wiki.openstreetmap.org/wiki/Key:contact indique la popularité déclinante des tags "contact:" ces dernières années.Désolé de ressortir ce vieux squelette du placard mais je ne m'étais pas rendu compte que la France faisait exception sur le sujet et j'ai l'impression qu'on a fait fausse route depuis des années.Ne serait-il pas temps de tuer le monstre ?Florian, qui donne entre 2 mails un avis totalement opposé (après avoir creusé le sujet)Le mar. 30 juin 2020 à 15:59, Yves P.  a écrit :On en déduira que quelqu'un a vérifié que le cinéma a été transformé en toilettes^^.Ça ressemble plus à un nettoyage partiel.+1Ou trop rapide :D__Yves___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
-- 


	
	
	
	




	
	
	
	

Florian
Lainez@overflorian
-- 


	
	
	
	




	
	
	
	

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


Re: [OSM-talk-fr] Noms des quartiers en ville

2020-06-30 Thread Topographe Fou
Vue la carte je doute que le Plan de Gaubert soit un hameau, cela m'a tout 
l'air d'un quartier et dans ce cas on utilise au maximum place=suburb (ou 
quarter ou neighboroud si pertinent).

Si il y a un quartier qui s'appelle Les Sieyes alors il mérite son propre noeud 
(ou way s'il y a une limite officielle).

OsmAnd se base sur la proximité géographique d'autres objets pour déterminer 
une adresse à partir d'une coordonnée de ce que j'ai pu comprendre, ce qui 
donne souvent des résultats incorrectes.

LeTopographeFou


  Message original  


De: arnaud.champoll...@linux-alpes.org
Envoyé: 30 juin 2020 7:54 AM
À: talk-fr@openstreetmap.org
Répondre à: talk-fr@openstreetmap.org
Objet: [OSM-talk-fr] Noms des quartiers en ville


Bonjour,

Je viens de constater un phénomène en partageant une adresse avec
l'application Osmand.

Quand on sélectionne cette position :
https://www.openstreetmap.org/?mlat=44.08165=6.20359#map=19/44.08165/6.20359

on obtient le libellé suivant :

Chemin des Gravas (Le Plan de Gaubert) 14, Digne-les-Bains
Position: geo:44.081646,6.20359?z=19
https://osmand.net/go?lat=44.081646=6.20359=19

Je m'interroge sur "Le Plan de Gaubert" qui est certes un quartier de la
ville, mais pas le bon. Il en est même relativement éloigné du point de
vue de l'organisation de la ville, même si proche à vol d'oiseau.

Est-ce parce-que "Le Plan de Gaubert" est le place=hamlet le plus proche ?

Si oui, faut-il créer un place=hamlet "Les Sieyes" qui est le quartier
du lieu correspondant à la position donnée ?

Et comment limiter la "portée" d'un place=hamlet pour qu'il ne soit pas
pris en compte par défaut dans d'autres parties de la ville qui en sont
dépourvues ?

Merci

Arnaud




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


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

2020-06-15 Thread Topographe Fou
  Je le mettrai bien en exception française des abréviations sur le wiki. On est pas au même niveau que rte pour route ou st pour saint ou street. Je le mets au même niveau que 1024 au lieu de mille-vingt-quatre. LeTopographeFou   De: yves.prat...@gmail.comEnvoyé: 15 juin 2020 11:11 AMÀ: talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: Re: [OSM-talk-fr] Comment orthographier un nombre ordinal  Le terrain prime... mais cela a aussi des limites ;)L’homogénéité dans les données ça ne fait pas de mal surtout quand sur le terrain on a pris quelques libertés avec des règles communes.+1Donc un "28ième" sur une plaque, je le mettrai en "28e" en name+1La page FR:Toponymes, odonymes du wiki cite la charte de toponymie de l'IGN.Elle ne détaille pas encore les ièmes…Et elle n'est pas (encore) citée dans la page FR:Key:name ;)__Yves___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


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

2020-06-13 Thread Topographe Fou
  Selon les règles typographiques de l'imprimerie nationale (très bon bouquin que je recommande) : 28e . Cependant ce n'est pas rare de voir 28ème sur des documents officiels ou dans la presse écrite. LeTopographeFou   De: bernard.lefranc...@free.frEnvoyé: 13 juin 2020 7:42 PMÀ: talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: [OSM-talk-fr] Comment orthographier un nombre ordinal  Bonjour, 
Je cherche la meilleure façon d'orthographier le "Quai du 28ème
Bataillon de Chasseurs".28ème comme ci-dessus avec accent (ma préférence)
  28Eme, 28Ème, 28E
  Sans espace, avec espace.En tout cas la graphie actuelle 28° ma parait la pire.Qu'en pensez-vous?

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


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

2020-06-08 Thread Topographe Fou
Par "pas claire" j'entends que le wiki ne propose rien aujourd'hui (ni sur
la page anglaise, ni sur la française) et que la clé n'étant utilisé que
212 fois dans le monde dont seulement 30 fois pour autre chose que yes/no
(pour Sodexo en l'occurrence) c'est qu'il doit sûrement rester un peu de
discussion à avoir (83 fois en France métropolitaine avec 82 yes/no + 1
chèque vacances).

Par ailleurs il peut y avoir plus d'un émetteur de titre (certes la CRT
centralise les 4 plus gros émetteurs mais il n'y a pas qu'eux). Par 'brand'
tu veux dire une liste des titres acceptés séparés par un ; ? Cela peut
être une option mais d'expérience cela cafouille vite et puis la limite du
nombre de caractères jouera probablement vite les troubles fêtes avec
l'arrivée des nouveaux acteurs. D'où ma suggestion de rester dans la veine
des autres moyens de paiement, ce qui renforce la cohérence. Le 'FR:' est
une touche personnelle pour éviter d'éventuels conflits de noms quand un
émetteur est clairement franco-français (ex : chèque vacances).

Le lun. 8 juin 2020 à 14:42, Marc M.  a écrit :

> Le 08.06.20 à 13:58, Topographe Fou a écrit :
> > il faudrait déjà un schéma claire, ce qui n'est pas le cas aujourd'hui.
>
> =yes/brand/no c'est pas clair ?
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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


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

2020-06-08 Thread Topographe Fou
Inclure aussi les chèques vacances ! Qui ne sont pas restreint à la
restauration.

Pour ce qui est de SC attention à la formulation de la quête car ce que la
plupart des gens de mon entourage appellent "tickets restaurants" sont en
fait des titres restaurant d'un émetteur concurrent (voir
https://fr.wikipedia.org/wiki/Titre_restaurant#Organismes). Comme quand on
parle d'un Zodiac ou d'un Frigidaire à la place d'un semi-rigide ou d'un
réfrigérateur. J'imagine que le sujet du mail porte sur tous les émetteurs
de titres restaurant.

Au delà de l'outils il faudrait déjà un schéma claire, ce qui n'est pas le
cas aujourd'hui. Une solution simple consisterait à reprendre le principe
des cartes de crédits :

   - payment:meal_voucher comme "clé générique pour dire que les titres
   restaurant *ne* sont *pas* acceptées"
   - payment:FR:cheque_de_table=*
   - payment:FR:ticket_restaurant=*
   - payment:FR:cheque_vacances=*
   - ...

Pour ce qui est des logos les Data items du wiki OSM peuvent être associés
au Wikidata items de Wikidata, permettant ainsi aux outils de récupérer
dynamiquement logos, opérateurs...

Le lun. 8 juin 2020 à 13:37, Yves P.  a écrit :

> > on peut imaginer proposer les logos des titres restaurant et des cartes
> de paiement, éventuellement regroupées par type. « sélectionnez tous les
> moyens de paiement acceptés ici puis validez la quête ».
>
> Super :)
>
> Pour les différents titres restaurant, tu détails ou pas ?
>
> > Il y a beaucoup de commerces qui ont ces logos sur leur vitrine, donc ça
> devrait pas être trop compliqué.
> Oui :)
>
> Demander quand même car certains commerces n'ont plus le lecteur et n'ont
> pas enlevé l'autocollant sur la vitrine.
>
> __
> Yves
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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


Re: [OSM-talk-fr] Ajout cartes des DOM sur Taginfo FR

2020-06-04 Thread Topographe Fou
Note : http://taginfo.geofabrik.de/europe/france/tags/maxspeed=35%20mph#map
me sors des objets à Guernsey, et en effet en regardant de plus prêt le
périmètre de l'export sur https://download.geofabrik.de/europe/france.html
c'est inclut dedans. Vais leur demander de retirer Jersey et Guernsey de
leur export France.

Le jeu. 4 juin 2020 à 14:58, Topographe Fou  a
écrit :

> J'ai fait une pull-request changeant uniquement le nom de l'instance
> taginfo. J'ai tout laissé en anglais mais me suis demandé pourquoi ce n'est
> pas en français. Ce qui sauterait au yeux serait de mettre une précision
> près du drapeau mais en effet je ne le trouve pas non plus. Le meilleur
> Github pour ouvrir un ticket concernant le drapeau est-il celui
> infrastructure ou ansible-scripts ?
>
> Concernant geofabrik cela se complique : sur
> https://download.geofabrik.de/europe/france.html la zone géographique de
> l'export n'englobe que la métropole mais dans la liste des 'Sub regions' on
> retrouve les DOM. Peut-être est-ce lié au fait que France soit sous Europe
> dans leur arborescence (Europe géographique vs Europe politique). Du coup
> soit je leur demande si ils peuvent renommer "France" en "France
> métropolitaine" (et dans ce cas les DOM n'auraient pas leur place en
> Sub-regions... arg la cohérence) soit je leur demande si ils peuvent
> inclure les DOM dans l'export France (et dans ce cas on est tout bon ! et
> notre taginfo sera bien sur la France) soit si ils peuvent rajouter un
> niveau (donc avoir un export France complet + un export France
> métropolitaine + Un export par région/DOM). Je penche pour la 2 ou la 3.
> Avis ?
>
> Je ne suis pas spécialement demandeur d'une instance taginfo France
> incluant les DOM, j'aime simplement quand les choses sont cohérentes et
> sans ambiguïté :) .
>
> Le jeu. 4 juin 2020 à 13:20, Marc M.  a écrit :
>
>> oui pour le moment taginfo .fr n'a pas les données domtom.
>> Mais les données ne sont pas un soucis, elles sont dispo sur l'infra.
>>
>> avec plaisir pour le ticket osm-fr ajout de l'info "métropolitaine" :)
>> et au moins des liens dans about vers les instances domtom
>> https://github.com/osm-fr/infrastructure
>> si tu es motivé, la configuration est là
>> https://github.com/osm-fr/ansible-scripts/tree/master/roles/taginfo
>> la partie France saute aux yeux :)
>> mais le drapeau ne semble pas là oü il devrait l'être.
>> n'hésites pas à en soumettre un si tu le souhaites.
>>
>> pour le ticket geofabrik, je peux pas garantir qu'ils le traiteront
>> mais cela me semble toujours une bonne idée de signaler une erreur.
>>
>> à toi de me dire si cela correspond à ton besoin ou si une instance
>> france complète serrait aussi utile.
>>
>> Le 04.06.20 à 12:43, Topographe Fou a écrit :
>> > Ahhh !!! En fait le taginfo France est un taginfo France
>> > _métropolitaine_. Donc à supposer que l'on puisse mettre plusieurs
>> > cartes côte à côte il n'y aurait probablement pas les données pour les
>> > remplir... Donc ma question tombe à l'eau.
>> >
>> > Un peu trompeur ce drapeau français et ce .fr. Ne peut-on pas rajouter
>> > un petit "METROPOLE" sous le drapeau de
>> > https://taginfo.openstreetmap.fr/ ou rajouter dans le titre ? De même
>> > sur geofabrik remplacer "Database: France" par "Database: France
>> > métropolitaine" serait adéquat. Je peux créer des tickets si retours
>> > positifs.
>> >
>> > Le jeu. 4 juin 2020 à 12:29, Marc M. > > <mailto:marc_marc_...@hotmail.com>> a écrit :
>> >
>> > la liste https://rlin.eu/osm/geofabrik/?id=france
>> > mais il n'y a pas d'instance France.
>> > ce que osm-fr et geofabrik nome France est la France métropolitaine
>> > https://taginfo.geofabrik.de/europe/france/keys/building#map
>> > Si cela répond à un besoin, cela peux s'envisager.
>> > Mais p'tre que les taginfo sub-nationaux suffisent ?
>> >
>> > Le 04.06.20 à 12:10, PanierAvide a écrit :
>> > > Effectivement dans cet esprit Geofabrik met à disposition des
>> > instances
>> > > de Taginfo sur la base des exports qu'ils proposent sur leur site
>> > > https://download.geofabrik.de/europe/france.html
>> > >
>> > > Il suffit de changer dans l'URL le nom du fichier concerné,
>> exemple :
>> > >
>> > >
>> http://taginfo.geofabrik.de/europe/france/reunion/keys/building#map
>> > >
>> http://taginfo.geofabrik.de/europe/france/gu

Re: [OSM-talk-fr] Ajout cartes des DOM sur Taginfo FR

2020-06-04 Thread Topographe Fou
J'ai fait une pull-request changeant uniquement le nom de l'instance
taginfo. J'ai tout laissé en anglais mais me suis demandé pourquoi ce n'est
pas en français. Ce qui sauterait au yeux serait de mettre une précision
près du drapeau mais en effet je ne le trouve pas non plus. Le meilleur
Github pour ouvrir un ticket concernant le drapeau est-il celui
infrastructure ou ansible-scripts ?

Concernant geofabrik cela se complique : sur
https://download.geofabrik.de/europe/france.html la zone géographique de
l'export n'englobe que la métropole mais dans la liste des 'Sub regions' on
retrouve les DOM. Peut-être est-ce lié au fait que France soit sous Europe
dans leur arborescence (Europe géographique vs Europe politique). Du coup
soit je leur demande si ils peuvent renommer "France" en "France
métropolitaine" (et dans ce cas les DOM n'auraient pas leur place en
Sub-regions... arg la cohérence) soit je leur demande si ils peuvent
inclure les DOM dans l'export France (et dans ce cas on est tout bon ! et
notre taginfo sera bien sur la France) soit si ils peuvent rajouter un
niveau (donc avoir un export France complet + un export France
métropolitaine + Un export par région/DOM). Je penche pour la 2 ou la 3.
Avis ?

Je ne suis pas spécialement demandeur d'une instance taginfo France
incluant les DOM, j'aime simplement quand les choses sont cohérentes et
sans ambiguïté :) .

Le jeu. 4 juin 2020 à 13:20, Marc M.  a écrit :

> oui pour le moment taginfo .fr n'a pas les données domtom.
> Mais les données ne sont pas un soucis, elles sont dispo sur l'infra.
>
> avec plaisir pour le ticket osm-fr ajout de l'info "métropolitaine" :)
> et au moins des liens dans about vers les instances domtom
> https://github.com/osm-fr/infrastructure
> si tu es motivé, la configuration est là
> https://github.com/osm-fr/ansible-scripts/tree/master/roles/taginfo
> la partie France saute aux yeux :)
> mais le drapeau ne semble pas là oü il devrait l'être.
> n'hésites pas à en soumettre un si tu le souhaites.
>
> pour le ticket geofabrik, je peux pas garantir qu'ils le traiteront
> mais cela me semble toujours une bonne idée de signaler une erreur.
>
> à toi de me dire si cela correspond à ton besoin ou si une instance
> france complète serrait aussi utile.
>
> Le 04.06.20 à 12:43, Topographe Fou a écrit :
> > Ahhh !!! En fait le taginfo France est un taginfo France
> > _métropolitaine_. Donc à supposer que l'on puisse mettre plusieurs
> > cartes côte à côte il n'y aurait probablement pas les données pour les
> > remplir... Donc ma question tombe à l'eau.
> >
> > Un peu trompeur ce drapeau français et ce .fr. Ne peut-on pas rajouter
> > un petit "METROPOLE" sous le drapeau de
> > https://taginfo.openstreetmap.fr/ ou rajouter dans le titre ? De même
> > sur geofabrik remplacer "Database: France" par "Database: France
> > métropolitaine" serait adéquat. Je peux créer des tickets si retours
> > positifs.
> >
> > Le jeu. 4 juin 2020 à 12:29, Marc M.  > <mailto:marc_marc_...@hotmail.com>> a écrit :
> >
> > la liste https://rlin.eu/osm/geofabrik/?id=france
> > mais il n'y a pas d'instance France.
> > ce que osm-fr et geofabrik nome France est la France métropolitaine
> > https://taginfo.geofabrik.de/europe/france/keys/building#map
> > Si cela répond à un besoin, cela peux s'envisager.
> > Mais p'tre que les taginfo sub-nationaux suffisent ?
> >
> > Le 04.06.20 à 12:10, PanierAvide a écrit :
> > > Effectivement dans cet esprit Geofabrik met à disposition des
> > instances
> > > de Taginfo sur la base des exports qu'ils proposent sur leur site
> > > https://download.geofabrik.de/europe/france.html
> > >
> > > Il suffit de changer dans l'URL le nom du fichier concerné,
> exemple :
> > >
> > >
> http://taginfo.geofabrik.de/europe/france/reunion/keys/building#map
> > > http://taginfo.geofabrik.de/europe/france/guyane/keys/building#map
> > >
> > > Cordialement,
> > >
> > > Adrien P.
> > >
> > > Le 04/06/2020 à 11:57, Philippe Verdy a écrit :
> > >> Là tu parles de l'instance d'OSM France. On peut noter que cette
> > >> instance continent un sélecteur de langue mais cela ne change pas
> les
> > >> résultats.
> > >> Pour voir les cartes des autres pays il faut trouver les autres
> > >> instances de TagInfo (autres sites), et elles ne sont pas liées
> entre
> > >> elles.
> > >> Il y a sinon la carte mondiale sur l'instance OSM.org:
> > >>
> &

Re: [OSM-talk-fr] Ajout cartes des DOM sur Taginfo FR

2020-06-04 Thread Topographe Fou
Ahhh !!! En fait le taginfo France est un taginfo France *métropolitaine*.
Donc à supposer que l'on puisse mettre plusieurs cartes côte à côte il n'y
aurait probablement pas les données pour les remplir... Donc ma question
tombe à l'eau.

Un peu trompeur ce drapeau français et ce .fr. Ne peut-on pas rajouter un
petit "METROPOLE" sous le drapeau de https://taginfo.openstreetmap.fr/ ou
rajouter dans le titre ? De même sur geofabrik remplacer "Database: France"
par "Database: France métropolitaine" serait adéquat. Je peux créer des
tickets si retours positifs.

Le jeu. 4 juin 2020 à 12:29, Marc M.  a écrit :

> la liste https://rlin.eu/osm/geofabrik/?id=france
> mais il n'y a pas d'instance France.
> ce que osm-fr et geofabrik nome France est la France métropolitaine
> https://taginfo.geofabrik.de/europe/france/keys/building#map
> Si cela répond à un besoin, cela peux s'envisager.
> Mais p'tre que les taginfo sub-nationaux suffisent ?
>
> Le 04.06.20 à 12:10, PanierAvide a écrit :
> > Effectivement dans cet esprit Geofabrik met à disposition des instances
> > de Taginfo sur la base des exports qu'ils proposent sur leur site
> > https://download.geofabrik.de/europe/france.html
> >
> > Il suffit de changer dans l'URL le nom du fichier concerné, exemple :
> >
> > http://taginfo.geofabrik.de/europe/france/reunion/keys/building#map
> > http://taginfo.geofabrik.de/europe/france/guyane/keys/building#map
> >
> > Cordialement,
> >
> > Adrien P.
> >
> > Le 04/06/2020 à 11:57, Philippe Verdy a écrit :
> >> Là tu parles de l'instance d'OSM France. On peut noter que cette
> >> instance continent un sélecteur de langue mais cela ne change pas les
> >> résultats.
> >> Pour voir les cartes des autres pays il faut trouver les autres
> >> instances de TagInfo (autres sites), et elles ne sont pas liées entre
> >> elles.
> >> Il y a sinon la carte mondiale sur l'instance OSM.org:
> >>
> >> https://taginfo.openstreetmap.org/keys/drinking_water#map
> >>
> >>
> >>
> >> Le jeu. 4 juin 2020 à 11:41, Topographe Fou  >> <mailto:letopographe...@gmail.com>> a écrit :
> >>
> >> Bonjour à tous,
> >>
> >> Aux administrateurs du taginfo français : est-ce possible
> >> d'ajouter une carte par DOM en plus de celle de la métropole dans
> >> l'onglet "Carte" ? Example :
> >> https://taginfo.openstreetmap.fr/keys/drinking_water#map
> >>
> >> Si ce n'est pas possible techniquement (ce que je soupçonne) je
> >> peux ouvrir un ticket sur
> >> https://github.com/taginfo/taginfo/issues car c'est dommage de
> >> limiter la France à sa métropole et il doit probablement exister
> >> d'autres cas où plus d'une zone géographique seraient les
> bienvenues.
> >>
> >> Par avance merci.
> >>
> >> LeTopographeFou
> >> ___
> >> Talk-fr mailing list
> >> Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
> >> https://lists.openstreetmap.org/listinfo/talk-fr
> >>
> >>
> >> ___
> >> Talk-fr mailing list
> >> Talk-fr@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk-fr
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
> >
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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


[OSM-talk-fr] Ajout cartes des DOM sur Taginfo FR

2020-06-04 Thread Topographe Fou
Bonjour à tous,

Aux administrateurs du taginfo français : est-ce possible d'ajouter une
carte par DOM en plus de celle de la métropole dans l'onglet "Carte" ?
Example : https://taginfo.openstreetmap.fr/keys/drinking_water#map

Si ce n'est pas possible techniquement (ce que je soupçonne) je peux ouvrir
un ticket sur https://github.com/taginfo/taginfo/issues car c'est dommage
de limiter la France à sa métropole et il doit probablement exister
d'autres cas où plus d'une zone géographique seraient les bienvenues.

Par avance merci.

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


Re: [OSM-talk-fr] #AttributionIsNotAnOption

2020-03-04 Thread Topographe Fou
Bravo !

LeTopographeFou


  Message original  


De: cqu...@openstreetmap.fr
Envoyé: 4 mars 2020 9:38 AM
À: taLk-fr@openstreetmap.org
Répondre à: talk-fr@openstreetmap.org
Objet: [OSM-talk-fr] #AttributionIsNotAnOption


Depuis avant hier, j'ai modifié notre cache de tuiles pour qu'il affiche
quelque tuiles "L'attribution n'est pas une option" parmi les fonds de
carte qu'il sert sur les domaines utilisant les fonds produits par OSM
France et où l'attribution est absente.

Cette petite campagne a commencé sur twitter avec ce tweet:
https://twitter.com/cq94/status/1234516075695525888

Ici c'était les pages jaunes marocaines... et en moins de 24h,
l'attribution est apparue :)

Un premier mail reçu d'un autre site hier, et depuis j'ai ajouté une
adresse mail (ti...@openstreetmap.fr) dans la tuile et ce matin deux
mail reçus demandant comment les retirer !


Bref, ça fonctionne et plutôt pas mal :)


La liste des domaines est gérée manuellement, je vais tenter
d'automatiser ça. L'idée est de récupérer la liste des referer depuis
les logs du cache et de consulter la page en question avec selenium pour
détecter la présence d'un "OpenStreetMap" quelque part sur la page.
Cette liste permettra aussi de repérer les gros consommateurs pour une
éventuelle deuxième campagne sur l'usage abusif de ressources limitées.

En attendant, la page du wiki avec les attributions manquantes est le
meilleur moyen de signaler ces "oublis":

- https://wiki.openstreetmap.org/wiki/Lacking_proper_attribution
-
https://wiki.openstreetmap.org/wiki/FR:Manque_d%27attribution_appropri%C3%A9e

Indiquez bien si possible l'URL de la page concernée...

--
Christian Quest - OpenStreetMap France


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


Re: [OSM-talk-fr] passage en revue de l'utilisateur oc-OpenStreetMap

2020-01-23 Thread Topographe Fou
Bonjour,

Cela me rappelle un (bref) échange que j'avais eu avec lui il y a quelques
temps :
https://www.openstreetmap.org/changeset/68169859

Je ne suis pas allé plus loin.

Le jeu. 23 janv. 2020 à 12:20, marc marc  a
écrit :

> Bonjour,
>
> existe-t-il un outil pour lister les tags modifiés par un utilisateur ?
> pas un changeset à la fois mais l'ensemble.
> histoire de vérifier si ce sont des cas isolés à annuler à la main
> https://www.openstreetmap.org/changeset/68406347
> ou s'il faut faire appel au DWG pour un revert à grande échelle.
>
> je ne suis demandeur d'un coup de main pour vérifier l'un ou l'autre
> changeset au hasard car pour le moment je suis à 100% d'erreur.
>
> Cordialement,
> Marc
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] SPAM, Re: clairière dans une forêt

2019-12-22 Thread Topographe Fou
Perso je télécharge une petite zone où je sais que le chemin délimitant la 
relation a un point. Puis une fois la relation visible dans le panneaux des 
relations on peut éventuellement télécharger ses membres pour une vision 
d'ensemble (clique droit de mémoire). 

Si il s'agit de représenter la forêt dans le sens d'une étendue couverte 
d'arbres cette méthode (mp) fonctionne. Mais si il s'agit d'une clairière de la 
forêt de X il y a fort à parier que la clairière fait partie de la forêt. Donc 
mp oui pour la zone boisée mais pas forcément pour la forêt administrative.

Cordialement, 

LeTopographeFou


  Message original  


De: arnaud.champoll...@linux-alpes.org
Envoyé: 22 décembre 2019 8:47 PM
À: talk-fr@openstreetmap.org
Répondre à: talk-fr@openstreetmap.org
Objet: Re: [OSM-talk-fr] SPAM, Re: clairière dans une forêt


Le 22/12/2019 à 20:29, marc marc a écrit :
> Le MP est la bonne solution

OK. Par contre je n'ai pas compris quelquechose. Avec JOSM pour créer le
multipolygone je dois sélectionner à la fois la forêt et mon polygone
intérieur.

Mais pour sélectionner la forêt il me faut télécharger une zone
tellement étendue que JOSM refuse (trop de données).

Comment ne télécharger que la forêt ?



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


Re: [OSM-talk-fr] JOSM : comment tracer un cercle de rayon donné autour d'un point

2019-12-09 Thread Topographe Fou
  A mon avis un ticket demandant la possibilité, à partir d'un segment, de créer un cercle de centre "le point de départ du way" et passant par le second point serait apprécié car fonction utile à plus d'un utilisateur JOSM je pense (perso j'utilise la technique des 3 points mais en decalquant sur de l'imagerie qui n'indique généralement pas le centre).Autre idée : un ticket pour, à partir d'un point, ouvrir une boite de dialogue qui permette de saisir un rayon et générer un cercle.Autre idée : un ticket pour, à partir d'un point, générer un cercle qui passe par la position de la souris et la suis jusqu'à ce que l'on clique pour figer le rayon.Ou les trois tickets à la fois, car trois méthodes qui peuvent rendre des services ^^. LeTopographeFou   De: yves.prat...@gmail.comEnvoyé: 6 décembre 2019 9:48 PMÀ: talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: Re: [OSM-talk-fr] JOSM : comment tracer un cercle de rayon donné autour d'un point  Le raccourcis shift+o permet de transformer une ligne représentant le diamètre en un cercle.Je restais sur le commentaire du menu « Créer un cercle à partir de 3 noeuds sélectionnés » Si on sélectionne 1 seul noeud ou plus de 3, le message d’erreur est clair 3  :« Sélectionnez exactement deux ou trois noeuds ou un chemin avec exactement deux ou trois noeuds ».Ce n’est pas tout à fait ce que j’ai besoin (je pensais qu’un greffon faisait ça), mais ça simplifie beaucoup l’édition.Merci orhygine—Yves___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Vérification des tags wikipedia et nettoyage ?

2019-12-02 Thread Topographe Fou
Je parlais de Maproulette pour corriger les tags wikipedia incohérents (tels 
que ceux signalés en début de fil) si il y en a "trop". Si il y en a "peu", 
cela peut être fait sans passer par ce service par un contributeur motivé.


LeTopographeFou


  Message original  


De: yves.prat...@gmail.com
Envoyé: 1 décembre 2019 9:20 PM
À: talk-fr@openstreetmap.org
Répondre à: talk-fr@openstreetmap.org
Objet: Re: [OSM-talk-fr] Vérification des tags wikipedia et nettoyage ?


@Topographe Fou
> De même que de pouvoir s'interfacer avec d'autres bdd qui utiliseraient cette 
> clé publique comme osm.

J’ai réussi à faire des requête SPARQL entre wikidata et OSM. En fait on peut 
faire des requête entre pleins de bases de connaissances :
Par exemple, les catalogues de grandes bibliothèques pour trouver des photos, 
vérifier des noms, trouver des articles…

> Et pourquoi pas lancer un maproulette pour les erreurs détectées ?

Avec des requêtes SPARQL, on peut non seulement vérifier que la valeur des tags 
wikidata ou wikipedia est correcte avec une expression régulière,
mais carrément, on peut vérifier que l’élément ou l’article existe bien,
que la page ne soit pas une page de redirection,
que l’élément wikidata corresponde bien à l’objet OSM (j’ai des tags 
man_made=lighthouse, la nature de l’élément wikidata doit être « phare »),
trouver la population d’une ville,
…

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


Re: [OSM-talk-fr] Vérification des tags wikipedia et nettoyage ?

2019-11-27 Thread Topographe Fou
Bonjour,

Tout à fait d'accord avec Yves : c'est même la raison d'être de wikidata, pas 
de remplacer wikipedia mais d'être une porte d'entrée vers les sites wikipedia, 
wikivoyages, wikinews... en plus d'être une base de données puissante, peu 
importe la langue et avec une promesse de maintenance réduite (tant qu'un 
Qx reste valide). De même que de pouvoir s'interfacer avec d'autres bdd qui 
utiliseraient cette clé publique comme osm. Ayant moi-même développé des 
moulinettes alliant wikipedia, wikidata et osm je vois bien la différence entre 
les deux clés. Et à ceux qui comme moi contribuent à Wikidata la mine 
d'information est énorme.

Donc je pense qu'il faut encourager l'usage de cette clé, de manière consciente 
(je saisie le Q) comme de manière sympathique (petit moteur de recherche 
wikidata à condition que ce soit simple de vérifier si un item correspond bien 
à ce que l'on veut, car il y a bcp d'homonymes).

Ceci étant dit il y a en effet fort à faire je pense niveau validation de tags 
wikipedia.

Et pourquoi pas lancer un maproulette pour les erreurs détectées ? D'expérience 
c'est plus lent mais permet de détecter et corriger d'autres erreurs sur le 
même objet / à proximité. Effet de bord tirant la qualité vers le haut.


LeTopographeFou


  Message original  


De: yves.prat...@gmail.com
Envoyé: 28 novembre 2019 12:29 AM
À: talk-fr@openstreetmap.org
Répondre à: talk-fr@openstreetmap.org
Objet: Re: [OSM-talk-fr] Vérification des tags wikipedia et nettoyage ?



>> Si car ça lie directement l’objet OSM aux propriétés wikidata
>
> ils sont déjà lié, ex le plugin josm wikidata propose d'ajouter le wikidata à 
> partir de l'url wikipedia
>
Je n’étais pas assez précis : on a toutes les infos en 1 clic avec wikidata. Et 
en 2 avec wikipedia
Je suis persuadé qu’à terme il n’y aura plus que le tag wikidata.

>> Quel est l’intérêt de consommer de l’énergie à stocker et à maintenir des 
>> données redondantes ?
>
> aucun, mais rien que toi et moi on n'est pas d'accord du quel des 2 
> supprimer. alors on peux philosopher, mais sans aboutir.
D’autres peuvent apporter leur point de vue. Et tout le monde évolue (pendant 
longtemps, je ne voyais pas l’intérêt de wikidata)

> La seule piste d'amélioration possible à court terme c'est de proposer aux 
> outils qui ne le font pas encore de gérer les 2 tags
> (= fonctionner de la même manière en présence de n'importe lequel des 2)
Ça me semble un bon compromis.

La carte des objets historiques fait ça en partie.
Elle utilise https://tools.wmflabs.org/hub pour obtenir des photos à partir de 
wikipedia ou wikidata et vice-versa.

> en passant quelqu'un avait proposé un script d'intégration
> osm-wikidata (par ex ajout de name:xx). a ma connaissance
> aucun rendu ne l'a mis en place (ce serrait pratique sur les
> rendus spécialisé sur une langue précise).
> yaka mais il manque de bras :)
Je verrais bien ça pour OpenStreetMap.org… pour afficher le nom de l’élément 
wikidata et la page wikipedia dans la langue préférée de l’utilisateur…
On pourra ainsi virer le tag wikipedia 

—
Yves




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


Re: [OSM-talk-fr] absence de licence sur "adresse-francaise.com": copyvio? vie privée/CNIL?

2019-11-26 Thread Topographe Fou
  Bonjour Philippe, Pour license OSM : tu peux les contacter en utilisant par exemple la procédure du wiki https://wiki.openstreetmap.org/wiki/FR:Lacking_proper_attributionPour la CNIL : n'hésite pas à leur faire un signalement sur leur site.Cordialement,  LeTopographeFou   De: verd...@wanadoo.frEnvoyé: 26 novembre 2019 11:31 PMÀ: talk-fr@openstreetmap.orgRépondre à: verd...@wanadoo.fr; talk-fr@openstreetmap.orgObjet: [OSM-talk-fr] absence de licence sur "adresse-francaise.com": copyvio? vie privée/CNIL?  Cartes et données OSM sans licence sur "adresse-francaise.com"https://adresse-francaise.com/street.php?i=751015825  (pas plus de mention des licences pour les données DGFiP, Cadastre, BAN, La Poste, et Annuaire universel).C'est clairement du copyvio, mais il y a d'autres problèmes aussi dangereux!Site utilisé pour la revente de fichiers nominatif de prospection commerciale (fichiers en grande partie abusifs, ils indiquent l'oppoition à la prospection commerciale, mais ces fichiers sont utilisés quand même et sans engagement légal supplémentaire concernant les restrictions d'utilisation et sans vérification des autorisations par la CNIL)Note: la CNIL vient d'épingler une société de prospection (pour "l'isolation à 1 euro", une grosse arnaque) à un demi-million d'euros d'amende, mais cette société continue ses harcèlements téléphoniques via une panoplie de centres d'appels tiers et "d'autoentrepreneurs", mais aussi via des appels passant par des relais téléphoniques hors Union Européenne, dont les appels entrant en France sont transmise tels quels, même avec un numéro d'appelant falsifié/détourné, et non masqués car invérifiables quand l'appel issu de France a transité par un relais hors UE, notamment en Inde, au Pakistan, en Azerbaidjan ou en Russie, via des opérateurs et fournisseurs légalement installés dans ces pays et qui authentifient les appels partant de chez eux mais pas ceux venant d'autres pays; il faut savoir que les numéros d'appelants même français sont facilement falsifiés, tous les opérateurs ne le vérifiant pas, et notamment pas pour les interconnexions internationales avec les opérateurs et réseaux hors UE).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] [OSM transport] booking=* <> reservation=*

2019-10-30 Thread Topographe Fou
Merci marc marc de faire le suivi.

Pour les urls à simplifier et la cohérence des langues cela pourrait je pense 
faire l'objet d'une routine Osmose.

LeTopographeFou


  Message original  



De: marc_marc_...@hotmail.com
Envoyé: 29 octobre 2019 11:33 PM
À: talk-fr@openstreetmap.org; transp...@listes.openstreetmap.fr
Répondre à: marc_marc_...@hotmail.com
Objet: Re: [OSM transport] [OSM-talk-fr] booking=* <> reservation=*


Bonsoir,

Personne ne s'y étant opposée, la migration de booking=* vers
reservation=* a été effectuée en France.
Plusieurs relations (de train) concernées ont des arrêts hors France,
il n'est évidement pas réaliste de couper la relation en 2.

LeTopographeFou tu as totalement raison sur les 3 critiques à propos
des url booking.com
Il faudrait en effet supprimer les paramètres
de traçages (tout ce qui est après le ?)
pour booking=* <> reservation:booking=*, la discussion n'a pas
vraiment abouti sur tagging, alors je vais m'abstenir, histoire
de ne pas créer un tag franco-français.

Cordialement,
Marc

Le 04.07.19 à 23:16, LeTopographeFou a écrit :
> Je pense également que réserver "booking=*" au seul site Booking n'est
> pas souhaitable. Il existe plein d'autres services et on est pas à
> l'abris qu'il y en ai un qui s'appelle "amenity" ou "building". Il
> faudrait à minima l'isoler dans un namespace, "reservation:booking" ou
> même "reservation:url:booking" pour pouvoir différencier différents
> moyens de réservation.
>
> Cependant il serait bon de ne pas résumer le débat à "Booking" mais
> parler de tous les sites de location entre particuliers et, en allant
> plus loin, aux plateformes de réservation de rendez-vous médicaux, de
> soins de beautés, de cours, de billets de train/avion/bus, de courses,
> de restauration, de voiture (y compris entre particuliers type Drivy),
> de places de théatre/cinéma...
>
> Cela dit mettre du Booking dans OSM présente aujourd'hui quelques
> soucis. Je ne suis pas opposé mais je dis 'attention' :
>
>  1. Ils n'ont pas de système de clé unique, publique et international
> partageable dans un "ref:booking" et attaquable via API Booking (ce
> qui serait bien plus propre qu'une URL)
>  2. Leurs URL sont moches, tout le monde ne sait pas les simplifier à
> leur stricte nécessaire en virant les éléments qui ne sont là que
> pour faire du suivi de navigation dans le cadre d'une recherche (ce
> qui n'a plus de sens dès qu'on le met dans OSM)
>  3. Dans l'URL il y a la langue (du moins quand je consulte un
> hébergement j'ai un '/fr/'), il conviendrait probablement de
> préciser le code ISO dans la clé (sinon un allemand peut se
> retrouver avec un lien en chinois)
>
> Cordialement,
>
> LeTopographeFou
>
> Le 04/07/2019 à 15:29, marc marc a écrit :
>> Bonjour,
>>
>> je fais écho ici d'une discussion qui a commencé sur la ml tagging
>> pour indiquer qu'un POI accepte/refuse/recommande une réservation,
>> la clef la plus courante est reservation=*
>> un contributeur avait crée une page booking=* et l'avait
>> ajout en recommandation sur plusieurs autres pages.
>> mais outre le fait d'avoir 2 clefs pour la même chose,
>> cela entrait en conflit avec booking=l'url booking.com
>> En est arrivé la conclusion de migrer
>> - booking=* vers reservation=* lorsque concerne la possibilité ou non de
>> réserver
>> - garder dans booking=* les url booking
>> - il y a aussi quelques urls de réservation non booking.
>> rien n'a été décidé mais sans doute que reservation:website serrait le +
>> cohérent.
>>
>> a noter que le plus grand nombre de cas (125) sont des lignes de
>> train passant par la France. à vos correcteurs, prêt ? partez :D
>> et si cela ne motive personne, je m'y collerai :)
>>
>> Cordialement
>> Marc
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>

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


Re: [OSM-talk-fr] Que faire de Cesária Évora

2019-09-09 Thread Topographe Fou
Ajouter un dictionnaire d'exceptions ? Il pourrait contenir des prénoms/noms 
propres et construit à partir d'analyse statistique sur la zone linguistique ou 
à la mano.



LeTopographeFou


  Message original  



De: jacq...@lavignotte.org
Envoyé: 9 septembre 2019 8:41 PM
À: talk-fr@openstreetmap.org
Répondre à: talk-fr@openstreetmap.org
Objet: [OSM-talk-fr] Que faire de Cesária Évora


Bonjour,

Osmose râle ici :

http://osmose.openstreetmap.fr/map/#zoom=16=48.9348629=2.3386770=5070=2

Sur le site de la chanteuse https://www.cesaria-evora.com/ on trouve
bien ce « á » du portugais (et de l'español)

Donc : que faire ?

J.

--
GnuPg : C8F5B1E3 Because privacy matters.


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


Re: [OSM-talk-fr] Sens unique

2019-08-26 Thread Topographe Fou
Bonjour,

Vu les dates je dirai qu'il faut laisser du temps pour que les données se 
synchronisent entre les différents consommateurs de données. L'intérêt d'une 
mise en cache c'est de ne pas avoir à tout recalculer à chaque requête. Le 
rendu peut très bien être en avance/en retard par rapport aux bdd routage.

Cordialement, 



LeTopographeFou


  Message original  



De: jacq...@lavignotte.org
Envoyé: 26 août 2019 10:05 AM
À: talk-fr@openstreetmap.org
Répondre à: talk-fr@openstreetmap.org
Objet: [OSM-talk-fr] Sens unique


Bonjour,

Pourquoi ce way 717949490 mis en sens unique samedi est bien marqué avec
les flèches mais un routage de la « Rue du Petit Bois » vers « Rue des
Bournalières » emprunte toujours le tronçon ?

De même pour 718153479 (établi hier 25/8)

Merci, J.
--
GnuPg : C8F5B1E3 Because privacy matters.


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


Re: [OSM-talk-fr] Sur rendez-vous

2019-08-20 Thread Topographe Fou
Bonjour,

Il vaut mieux à mon sens éviter d'utiliser le champ opening_hours pour cela, 
sinon on en arrive à mélanger la maintenance des horaires avec celle des 
multiples possibilités de réservation (téléphone mais aussi Internet, sur 
place...). En plus le standard n'a pas forcément les mêmes horaires que les 
consultations. Idem pour Internet (24/7). La proposition de Marc est préférable 
à mes yeux : mettre la réservation sur un tag dédié (voir aussi la direction 
qui avait eu lieu en juin je crois sur la réservation hôtelière avec le débat 
booking=*) et laisser les horaires d'ouverture pour les horaires d'ouverture.

C'est bien différent d'un magasin qui n'ouvrirait que sur rendez-vous (sens de 
l'usage dans opening_hours). 

Cordialement, 

LeTopographeFou


  Message original  



De: marc_marc_...@hotmail.com
Envoyé: 20 août 2019 9:41 AM
À: talk-fr@openstreetmap.org
Répondre à: talk-fr@openstreetmap.org
Objet: Re: [OSM-talk-fr] Sur rendez-vous


Bonjour

Le 19.08.19 à 18:52, David Crochet a écrit :
> Le 19/08/2019 à 18:39, Jacques Lavignotte a écrit :
>> je ne sais pas indiquer que voir la dentiste est uniquement « sur
>> rendez-vous »
>
> *opening_hours=xx:xx* |"||reservation by phone"|
>
> en remplacant xx:xx par les jours/horaires d'ouverture

il y aussi reservation=required
https://wiki.openstreetmap.org/wiki/FR%3AKey%3Areservation

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


Re: [OSM-talk-fr] Taguer une place

2019-07-17 Thread Topographe Fou
Moi j'aurais laissé le nom aussi sur la route...

Nota : le jour où une route pourra être proprement representé et géré en 
surfacique (comme les places) alors ma réponse pourrait éventuellement être 
différente. Je ne parle pas de routage surfacique mais bien de modélisation 2D 
des rues et places.


LeTopographeFou


  Message original  



De: marc_marc_...@hotmail.com
Envoyé: 17 juillet 2019 6:54 AM
À: talk-fr@openstreetmap.org
Répondre à: talk-fr@openstreetmap.org
Objet: Re: [OSM-talk-fr] Taguer une place


Le 13.07.19 à 13:35, deuzeffe a écrit :
> Rue/voies qui ont le même name= que la place. Donc on doublonne ?
si on veux l'éviter, on peux renseigner le nom sur l'un (la place)
et mettre un noname=yes sur l'autre (la rue).
qu'en penses les autres ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Josm - traduction du logiciel - couper le chemin

2019-07-05 Thread Topographe Fou
 Merci. Le site me renoi encore une belle page avec une erreur de timeout... G...Selon https://josm.openstreetmap.de/wiki/Translations il faudrait doubler le guillemet simple. Ou alors utiliser un vrai caractère apostrophe ;o) . Essai et cela devrait marcher.LeTopographeFou   De: lenny.li...@orange.frEnvoyé: 5 juillet 2019 9:24 AMÀ: talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: Re: [OSM-talk-fr] Josm - traduction du logiciel - couper le chemin  
Le 05/07/2019 à 08:10, Topographe Fou a
  écrit :

  
  
  
  
 J'ai encore un soucis de timeout...
  J'avais réussi à y accéder entre temps. Peux-tu mettre sur la
  liste la phrase originale en anglais stp, celle avec les {x} ?
  Normalement si tu as les mêmes accolades entre l'original et
  le traduit cela devrait passer.
  
original anglais  : 
Which way segment should reuse the history of {0}?ma traduction :Quel segment de chemin doit réutiliser l'historique de {0} ?J'ai utilisé le bouton copie (la petite flèche à côté de
  English:) donc, ce sont les mêmes accolades (il me semble) et ce
  matin même message d'erreur
Leni

  
 


  LeTopographeFou

  
  


  De: lenny.li...@orange.fr
  Envoyé: 4 juillet 2019 12:08 PM
  À: talk-fr@openstreetmap.org
  Répondre à:
talk-fr@openstreetmap.org
  Objet: Re: [OSM-talk-fr] Josm
- traduction du logiciel - couper le chemin

  

  
  
  

  
  
  Le 24/06/2019 à 22:35,
LeTopographeFou a écrit :
  
  Pour Launchpad, la liste des phrases
non traduits (14 à ce jour pour le français) est accessible
là :
https://translations.launchpad.net/josm/trunk/+pots/josm/fr/+translate?show=untranslated
. Sauf que actuellement j'ai une erreur de Timeout :-( . 

LeTopographeFou 
  
  Comme je ne l'ai pas trouvée dans les éléments à traduire,
j'ai recherché le texte et j'ai trouvé :
https://translations.launchpad.net/josm/trunk/+pots/josm/fr/+translate?batch=10=all=which+way
Elle était indiquée comme traduite, avec le texte anglais.
  J'ai essayé de mettre une nouvelle traduction "Quel segment
de chemin doit réutiliser l'historique de {0} ?" ; mais j'ai
le message d'erreur "There is an
  error in a translation you provided. Please correct it
  before continuing."
  Où ais-je fait
l'erreur ?
  Leni



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


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


Re: [OSM-talk-fr] Josm - traduction du logiciel - couper le chemin

2019-07-05 Thread Topographe Fou
  J'ai encore un soucis de timeout... J'avais réussi à y accéder entre temps. Peux-tu mettre sur la liste la phrase originale en anglais stp, celle avec les {x} ? Normalement si tu as les mêmes accolades entre l'original et le traduit cela devrait passer.LeTopographeFou   De: lenny.li...@orange.frEnvoyé: 4 juillet 2019 12:08 PMÀ: talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: Re: [OSM-talk-fr] Josm - traduction du logiciel - couper le chemin  
Le 24/06/2019 à 22:35, LeTopographeFou
  a écrit :
Pour
  Launchpad, la liste des phrases non traduits (14 à ce jour pour le
  français) est accessible là :
https://translations.launchpad.net/josm/trunk/+pots/josm/fr/+translate?show=untranslated
  . Sauf que actuellement j'ai une erreur de Timeout :-( .
  
  
  LeTopographeFou
  
Comme je ne l'ai pas trouvée dans les éléments à traduire, j'ai
  recherché le texte et j'ai trouvé :
https://translations.launchpad.net/josm/trunk/+pots/josm/fr/+translate?batch=10=all=which+way
  Elle était indiquée comme traduite, avec le texte anglais.J'ai essayé de mettre une nouvelle traduction "Quel segment de
  chemin doit réutiliser l'historique de {0} ?" ; mais j'ai le
  message d'erreur "There is an error in a
translation you provided. Please correct it before continuing."Où ais-je fait
  l'erreur ?Leni
  
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] building=amenity

2019-07-03 Thread Topographe Fou
  Bonjour,As-tu contacté l'auteur de cette modification pour comprendre l'origine de ce changement ? Peut-être a-t-il introduit ce tag sur un autre bâtiment. Il y a 182 objets avec building=amenity selon taginfo, ce serait intéressant de voir si il y en a d'autres en France et si ils n'ont pas un lien.Suis aussi d'accord que cela ne rime pas à grand chose.LeTopographeFou   De: osm.sanspourr...@spamgourmet.comEnvoyé: 2 juillet 2019 9:32 PMÀ: talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: [OSM-talk-fr] building=amenity  Bonjour, usuellement les gares sont des building=yes de base et
  de plus en plus des building
   train_station(ou des station).La gare de Rennes est aujourd'hui taguée building=amenity.Pourtant rien n'indique cette possibilité de valeur.Quand on cherche gare, Rennes avec Nominatim on tombe du coup sur
  un étrange "Amenity Rennes".Et non "Train Station Rennes".Une objection à repasser à building=train_station ?Jean-Yvon



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


Re: [OSM-talk-fr] [Python] Générer image carte statique à partir coordonnées GPS?

2019-06-26 Thread Topographe Fou
Le User-agent peut contenir presque n'importe quoi, en l'occurrence faire 
référence au nom de ton projet/librairie, mentionner la version, mettre la 
version Python, idéalement mettre un moyen de contact pour si ton script génère 
des soucis insoupçonnés côté serveur. Ton script Python n'est pas lancé par 
Firefox je pense, donc ce serait faux de se faire passer pour lui.

Côté referer il est en effet peu probable que ton script soit lancé depuis la 
page d'accueil de Google. Si tu n'as pas d'URL appropriée à mettre (car usage 
en local par exemple) essaie de mettre le nom de ton projet/librairie.

Je pourrais regarder à l'occasion ce que moi je mets (mais pour un usage site 
Internet, donc différents d'un appel script local).

LeTopographeFou


  Message original  



De: codecompl...@free.fr
Envoyé: 26 juin 2019 12:40 AM
À: talk-fr@openstreetmap.org
Répondre à: talk-fr@openstreetmap.org
Objet: Re: [OSM-talk-fr] [Python] Générer image carte statique à partir 
coordonnées GPS?


Que doit-on mettre dans un script ?



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

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


Re: [OSM-talk-fr] Josm - traduction du logiciel - couper le chemin

2019-06-24 Thread Topographe Fou
Perso quand je vois Alt+Maj+B je fais Alt+Maj+B, pas Alt+Maj+Bas. Si le B fais 
référence à la touche Bas alors mieux vaut mettre Bas. Sinon autant mettre 
A+M+B.

Ou alors mettre un symbole flèche vers le bas si les caractères spéciaux 
(unicodes ?) sont gérés.

Mes deux cents,

LeTopographeFou


  Message original  



De: lenny.li...@orange.fr
Envoyé: 22 juin 2019 10:22 AM
À: talk-fr@openstreetmap.org
Répondre à: talk-fr@openstreetmap.org
Objet: [OSM-talk-fr] Josm - traduction du logiciel - couper le chemin


Bonjour,

En mettant à jour la page du wiki
https://josm.openstreetmap.de/wiki/Fr%3AHelp/Action/SplitWay avec la
version anglaise : je me suis aperçu, en faisant la copie écran de la
fenêtre contextuelle qui s'affiche (en mode expert) que le titre de la
fenêtre est restée en anglais.

 Je suis allé voir ​Launchpad ; mais je dois avouer que c'est un peu
trop compliqué pour moi ...

De plus, dans le menu Fichier, le raccourcis-clavier de "Télécharger le
long" est indiqué "Alt + Maj + D" alors que le "D" de "Down" en anglais
devrait être remplacé par "Bas" :  "Alt + Maj + Bas"

Si quelqu'un connaissant ​Launchpad pouvait s'en charger, merci

Cordialement

Leni


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


Re: [OSM-talk-fr] Problème de connexion

2019-06-03 Thread Topographe Fou
Merci pour le suivi et les actions entreprises !

LeTopographeFou


  Message original  



De: yann...@voyeaud.org
Envoyé: 3 juin 2019 7:44 PM
À: talk-fr@openstreetmap.org
Répondre à: talk-fr@openstreetmap.org
Objet: Re: [OSM-talk-fr] Problème de connexion


Le 28/05/2019 à 19:27, Yannick a écrit :
> Le 28/05/2019 à 19:13, Topographe Fou a écrit :
>> En effet, sur le site https://www.ancestris.org/index_fr.html on voit des 
>> captures écrans avec des cartes ayant le même style que le fond de carte 
>> osm.org et, à moins que mes yeux ne me jouent des tours, pas de mention 
>> source osm.
>> Reste l'absence de mention qui elle est un minimum vue la taille de la 
>> carte, même entre gens du libre.
>>
>> Cordialement,
>>
>> LeTopographeFou
>
> Re,
>
> Je vais relayer cet aspect des choses que je n'avait pas remarqué. De
> mémoire dans le logiciel cela y est bien mais dès que les choses seront
> revenus je ferais un contrôle.
>
> Amitiés

Bonsoir,

Bon c'est réparé.
Contrairement à ce que je pensais il n'y avait pas de mention sur la
carte c'est désormais réparé DANS le logiciel. C'est en bas à gauche des
cartes car deux éléments utilisent le fond de carte.

Pour le site je ne sais pas si les copains ont prévu de refaire la copie
d'écran. J'ai signalé le souci mais amha le plus important est le
logiciel lui-même. Sur la copie de carte cela serait illisible et se
résumerait quasiment à un trait noir donc pas dramatique.

Si vous voulez une copie d'écran des deux items je pourrais vous les
faire dans les jours qui viennent.

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 http://www.ancestris.org



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


Re: [OSM-talk-fr] Problème de connexion

2019-05-28 Thread Topographe Fou
En effet, sur le site https://www.ancestris.org/index_fr.html on voit des 
captures écrans avec des cartes ayant le même style que le fond de carte 
osm.org et, à moins que mes yeux ne me jouent des tours, pas de mention source 
osm.

Mais je n'ai pas ce logiciel pour voir les requêtes HTTP qu'il fait. Cela peut 
être vers OSM ou pas.

Reste l'absence de mention qui elle est un minimum vue la taille de la carte, 
même entre gens du libre.

Cordialement,

LeTopographeFou


  Message original  



De: marc_marc_...@hotmail.com
Envoyé: 28 mai 2019 6:33 PM
À: talk-fr@openstreetmap.org
Répondre à: talk-fr@openstreetmap.org
Objet: Re: [OSM-talk-fr] Problème de connexion


Bonsoir,

Le 28.05.19 à 17:30, Yannick a écrit :
> Y a-t-il eut un changement important sur les serveurs OSM hier?

osm.org ? j'ai vu passé une salve de ban anti-abus

> En effet Ancestris qui fait appel à OSM pour sa géolocalisation
> des données ne peut plus accéder.

heu... j'ai peur de comprendre
qlq utilise l'api pour autre chose que la contribution ?
tu peux détailler un peu + ?

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


Re: [OSM-talk-fr] Lenteur BDOrtho

2019-05-14 Thread Topographe Fou
  Bonjour,Idem hier soir, merci pour le tuyau.Cordialement, LeTopographeFou   De: stephane.pen...@wanadoo.frEnvoyé: 14 mai 2019 11:44 AMÀ: talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: [OSM-talk-fr] Lenteur BDOrtho  Hello,Depuis quelque temps, j'ai constaté que l'affichage de la BDOrtho
  est très...très lent, avec de nombreuses erreurs signalée par Josm
  (java.net.SocketTimeoutException: connect timed out)L'url enregistrée dans Josm est  :
  https://proxy-ign.openstreetmap.fr/94GjiyqD/bdortho/{zoom}/{x}/{y}.jpgJe me suis créé une nouvelle couche tms avec
comme Url :
  http://proxy-ign.openstreetmap.fr/bdortho/{zoom}/{x}/{y}.jpg
Et là, ça va beaucoup mieux.Il y a un problème quelque part
  ?A bientôtStf

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


Re: [OSM-talk-fr] JOSM et Java - thread forum allemand (weeklyOSM)

2019-05-07 Thread Topographe Fou
  Bonjour Vincent,Ne t'inquiète pas : peu importe les intentions, tout acte publique amène son lot de critique plus où moins adroitement exprimé. Que cela ne vous démotive pas de donner du temps pour JOSM et de communiquer sur votre stratégie !Perso je n'y connais pas grand chose en la matière mais j'imagine que vous ne faites pas tout cela en aveugle et que vous oserez changer de cap si les craintes exprimées se confirment. Lesquelles craintes seraient sûrement mieux exprimées et traitées sur un des lieux d'échange entre développeurs JOSM que ici.Merci d'avoir partagé votre point de vue sur cette histoire de licence et pour l'avoir transcrit en un article OSM (article OSM + Twitter, les deux endroits se complètent car n'adressent pas le même public. Twitter s'envole, le Wiki reste).Cordialement,LeTopographeFou   De: vincent.pri...@gmail.comEnvoyé: 7 mai 2019 12:09 AMÀ: goues...@orange.fr; talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: Re: [OSM-talk-fr] JOSM et Java - thread forum allemand (weeklyOSM)  L'article est là:https://www.openstreetmap.org/user/josmeditor/diary/172694Désolé j'ai pas lu plus loin. J'ai du mal avec les réactions qui commencent par "Il aurait été préférable que". Je fais ce que je veux non ? Déjà que je me suis cassé le cul à écrire ça c'est pas pour ce prendre ce genre de retour dans la face.A+VincentLe lun. 6 mai 2019 à 11:07,  a écrit :Bonjour
 
Il aurait été préférable de faire un article plutôt qu'une série de "tweets" bien que je sois assez d'accord sur le fond.
 
De plus, Oracle Java ne contient pas grand chose de plus qu'OpenJDK, ce que le schéma ne montre pas vraiment, et c'est encore plus vrai depuis qu'OpenJFX/JavaFX est redevenu un projet séparé et que les applets et Webstart ont été dépréciés puis supprimés d'Oracle Java.
 
Même Oracle s'est engagé à fournir régulièrement des builds d'OpenJDK avec des correctifs de sécurité au moins une fois tous les six mois (tu parles déjà d'AdoptOpenJDK, très bien, je n'encourage pas à "installer" ça sur un système, ce n'est pas dans cet esprit qu'il faille déployer des logiciels en Java désormais, cf. jlink et la modularisation). Je pense que vous vous trompez sur pas mal d'attentes et sur la manière de répondre à des problématiques de sécurité. Je fais du Java depuis environ 16 ans, j'ai laissé tomber les applets en 2006 parce que je savais comment ça finirait et j'ai fini par tourner le dos à Java Webstart aussi. OpenJFX/JavaFX n'est pas nécessaire pour lire des MP3, JOAL + OpenAL-Soft + Paul Lamb Sound Library pourrait faire l'affaire. Ce que vous attendez n'arrivera pas ou tout du moins pas complètement. Vous devriez plutôt adapter vos façons de faire et vos outils plutôt que d'attendre qu'ils s'adaptent à vos usages dans ce cas précis.
 
Il est également possible de mettre en place d'autres systèmes de mise à jour automatique sans passer par Webstart, par exemple GetDown (je n'ai jamais réussi à le faire marcher), IzPack, des solutions basées sur PackR, générer des paquets natifs ou des installeurs (par l'intermédiaire de NSIS-Ant) via mon outil JNDT, ... 
 
A vous de voir. Désolé pour celles et ceux qui seraient largués.
 
Je vais m'abstenir d'étaler tout le mal que je pense d'un outil de micro-blogging d'une firme côtée en bourse qui bénéficie du "zero rating" (violation de la neutralité du net) et dont les centres de données ont une emprunte écologique loin d'être anodine... Je suis déjà suffisamment mal à l'aise chez Orange... Il faudrait aussi rappeler les prises de position d'Oracle pendant le mouvement contre le CPE, rien que pour ça il est hors de question que je recommande d'utiliser Oracle Java.
 
 
> Message du 06/05/19 08:11> De : "PanierAvide" > A : talk-fr@openstreetmap.org> Copie à : > Objet : Re: [OSM-talk-fr] JOSM et Java - thread forum allemand (weeklyOSM)> >
> Bonjour Vincent,
> Merci pour ce condensé très intéressant et très clair sur le futur de Java et les impacts pour JOSM :-)
> Cordialement,>
Adrien P.
Le 05/05/2019 à 22:46, Vincent Privat a écrit :>



Hello,
Le weeklyOSM d'aujourd'hui renvoie vers ce thread du forum allemand au sujet des changements de licence de Java et de l'impact pour JOSM.
J'y ai lu beaucoup de choses fausses, donc j'ai twitté un petit thread sur le sujet:
https://twitter.com/josmeditor/status/1125135390426505218
>
Si des personnes intéressées ne sont pas à l'aise en anglais je peux traduire ici en français.
>
TL;DR: changez rien et vous inquiétez pas, on gère le truc.>
>
A+
Vincent


>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org

Re: [OSM-talk-fr] Dans quel tag mettre le nom d'une résidence ou immeuble de bureaux ?

2018-11-08 Thread Topographe Fou
C'est exclusif sur le Wiki anglophone (
https://wiki.openstreetmap.org/wiki/Key:addr#Commonly_used_subkeys), mais
pas sur la francophone (
https://wiki.openstreetmap.org/wiki/FR:Key:addr#Adresses). Quant à la page
francophone sur les adresses (
https://wiki.openstreetmap.org/wiki/FR:Adresses) il y a une seule
occurrence, dans le cas où un numéro concerne plusieurs bâtiments (cas d'un
campus par exemple). Pas d'autres indications sur quand utiliser ce tag (et
notamment dans les cas cités). Idem pour l'anglophone. Je pense qu'il y a
quelque chose à clarifier.

Perso j'aurais plutôt tendance à mettre le nom d'un bâtiment (qu'il soit
sur le cadastre et/ou sur une plaque non officielle) dans name mais comme
ce n'est pas clair quand utiliser addr:housename...



Le jeu. 8 nov. 2018 à 16:59, marc marc  a écrit :

> addr:housename et addr:housenumber sont supposé être mutuellement
> exclusif : il y a des endroits oü les bâtiments n'ont pas de numéro
> mais un nom utilisé par la poste.
>
> soit t'es passé devant et t'as une idée s'il y avait un no d'immeuble
> soit il faudrait regarder la ban ou la bano pour ce bâtiment
> pour choisir entre addr:housename et name
>
> de manière totalement subjective, j'ai l'impression que les villes
> et les bâtiments récent ont tous un numéro et que le nom est
> purement décoratif (=non postal)... mais c'est subjectif :)
>
> Le 08. 11. 18 à 16:52, Topographe Fou a écrit :
> > Bonjour,
> >
> > Dans le cas où le cadastre précise un nom pour un bâtiment résidentiel
> > ou de bureaux (ou dans le cas où il y a une joli plaque au niveau de
> > l'entrée genre "Villa des Oliviers"), faut-il mettre cette valeur dans
> > 'addr:housename' ou 'name' ou les deux ou une autre ?
> >
> > J'ai trouvé les deux pratiques dans OSM et ne trouve pas de réponse
> > claire sur le Wiki (j'ai regardé la page sur les bâtiments, celle sur
> > name, celle que les adresses et celle sur le cadastre).
> >
> > Quelques exemples à Rueil-Malmaison :
> > https://www.openstreetmap.org/way/71341319
> > https://www.openstreetmap.org/way/71341177
> >
> > Par avance merci.
> >
> > Cordialement,
> >
> > LeTopographeFou
> >
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
> >
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Magic Earth ( etait OsmAnd, un navigateur routier un peu à part)

2018-11-08 Thread Topographe Fou
Bonjour,

J'avoue que cela date d'il y a je pense 2 ans... entre temps le logiciel a
pu évoluer. Je me souviens simplement que j'avais jugé l'interface et les
fonctionnalités (lesquelles exactement ?? bonne question) moins riche et
les données affichées recherchables moins détaillées. OsmAnd me paraissait
également bien plus proche de la communauté et du projet à l'époque (ex :
capacité d'édition, ce que j'apprécie pour faire des ajouts en
déplacement). Mais je ne me risquerait pas à parler davantage ne
connaissant plus cette appli.

Cordialement,

Le mar. 6 nov. 2018 à 10:14,  a écrit :

>
>
> - Mail original -
> De: "Topographe Fou" 
> À: "Discussions sur OSM en français" , "OSM en
> OSM en français" , "OSM en OSM en Bretagne" <
> talk-fr-...@openstreetmap.org>
> Envoyé: Lundi 5 Novembre 2018 19:56:52
> Objet: Re: [OSM-talk-fr] OsmAnd, un navigateur routier un peu à part
>
> > Bonsoir à tous,
>
> Bonjour
>
> > Merci. Pour ma part j'utilise OsmAnd+ après avoir été déçu de Maps.me,
> Magic Earth...
>
> Qu est ce qui n allait pas avec Magic Earth ?
> C est l appli que j utilise sous Android depuis pas mal de temps et jusque
> la elle me va bien
>
> Julien
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


[OSM-talk-fr] Dans quel tag mettre le nom d'une résidence ou immeuble de bureaux ?

2018-11-08 Thread Topographe Fou
Bonjour,

Dans le cas où le cadastre précise un nom pour un bâtiment résidentiel ou
de bureaux (ou dans le cas où il y a une joli plaque au niveau de l'entrée
genre "Villa des Oliviers"), faut-il mettre cette valeur dans
'addr:housename' ou 'name' ou les deux ou une autre ?

J'ai trouvé les deux pratiques dans OSM et ne trouve pas de réponse claire
sur le Wiki (j'ai regardé la page sur les bâtiments, celle sur name, celle
que les adresses et celle sur le cadastre).

Quelques exemples à Rueil-Malmaison :
https://www.openstreetmap.org/way/71341319
https://www.openstreetmap.org/way/71341177

Par avance merci.

Cordialement,

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


Re: [OSM-talk-fr] OsmAnd, un navigateur routier un peu à part

2018-11-05 Thread Topographe Fou
Bonsoir à tous,

Merci. Pour ma part j'utilise OsmAnd+ après avoir été déçu de Maps.me, Magic 
Earth...

Je l'utilise autant en France qu'à l'étranger, rien à dire sur les données par 
rapport aux autres applis précédentes (il y a presque tout ce que OSM contient 
!). Je recommande aussi !

Gros + la possibilité de modifier des POI sans mettre le boxon comme le fait 
Maps.me (ou du moins à ses débuts). Sinon plein de petites fonctions qui font 
que OsmAnd réponds à la plupart des usages que les autres n'adressent pas 
(options d'évitement, limitation de poids/hauteur, personnalisation de la 
carte, usage d'un routeur online...), évitement de routes en travaux/fermées. 
D'autres le font (partiellement) mais OsmAnd le fait mieux à mon goût. 

Le Github est actif et réactif quand on a des bugs.

Le point faible : la recherche de POI ou d'adresse. Même quand un POI est dans 
la base il n'est pas toujours commode de la trouver malgré les constantes 
améliorations au moteur de recherche.

J'ai résilié mon option Live il y a quelques mois pour les raisons suivantes :

- pb de fusions avec les modifications qui font que les routing font parfois 
n'importe quoi dans une zone modifiée 
- prix prohibitif par rapport à mon usage (pas besoin d'être au taquet sur LA 
poubelle ajoutée au coin de la rue pendant la nuit, une mise à jour mensuelle 
de là où je vais suffit pour aller de A à B)
- aucune valeur ajoutée me concernant
- bof l'idée de payer des contributeurs (même si c'est symbolique)

Je précise que j'utilisais cette option en désactivant les Maj automatiques 
mais en les téléchargent à la demande avant chacun de mes déplacements pour la 
carte utilisée uniquement.

Je suis prêt à la reprendre si le prix est plus raisonnable (près de 20€ par an 
actuellement) ou permet une modularité (ex : payer à l'usage. Si je laisse 
l'appli éteinte pendant 1 mois je ne paie pas) et surtout quand ce sera debugé 
ou qu'une vrai valeur ajoutée (pour mon usage) pointe son nez ! Sinon le prix 
de OsmAnd+ vaut le coût (et oui c'est normal de payer pour le travail de 
quelqu'un, même si une alternative égale, légale et gratuite existe par 
ailleurs).

Bref je recommande et pour moi la "killer feature" serait l'intégration de 
données de traffic (sans compromis avec la vie privée, qu'OsmAnd semble 
respecter à la différence d'autres applis connues et gratuites utilisant OSM). 
C'est aujourd'hui le SEUL motif pour lequel je n'ai pas desinstallé Google 
Maps. OsmAnd gère déjà la signalisation (en local) d'obstacles et son 
contournement (pratique quand on sait qu'une zone est en travaux pour un bout 
de temps).

Cordialement, 



LeTopographeFou


  Message original  



De: christian.ro...@club-internet.fr
Envoyé: 5 novembre 2018 4:48 PM
À: Talk-fr@openstreetmap.org; talk-fr-...@openstreetmap.org
Répondre à: talk-fr@openstreetmap.org
Objet: [OSM-talk-fr] OsmAnd, un navigateur routier un peu à part


Certains utilisent OsmAnd, mais, tout le monde n’a pas saisi qu’il s’agit d’un 
navigateur routier pour mobile définitivement à part.

La premier point est qu’il n’utilise pas les satellites en version basique, 
mais des extraits de cartes OSM téléchargées sur demande.

Le deuxième point est que c’est un modèle fremium particulier. On n’a droit 
qu’à 5 cartes ou mises à jour de cartes et sur une bases de mise à jour 
mensuelles, cela rend la gratuité relative, même si les cartes ne sont pas très 
chères (quelques euros).

Si on souhaite accéder à mieux, il faut oublier la version iOS et se tourner 
vers OsmAnd+ (mises à jour hebdo) et, mieux encore passer par le magasin 
F-Droid qui distribue une version gratuite et illimitée.

Le must est l'option geek qui, si l’on appelle F-Droid depuis l’appli permet 
d’utiliser des paquets Android (APK) qui transforment l’appli en OsmAnd Live, 
qui, comme le nom l’indique donne accès à une mise à jour en direct, mais, sous 
réserve de s’affilier à un système de dons utilisant les bitcoins.

D’autres que moi parleront avec plus de pertience du logiciel OsmAndCreatorMap.

Dernier point remarquable : l’ouverture exceptionnelle aux langues, car, 
actuellement il y en pas pas moins de 76. Pour la France, on peut noter le 
basque, le breton et le catalan (il y a aussi le français, mais, comme on sait, 
il assez peu de noms authentiquement français).

Pour l’Afrique, on ne trouve pas de langue de l’espace francophone (il y a 
l’afrikaans et le swahili). Un seul créole, l’haïtien.

Ceci est un résumé du topo que j’ai mis sur le site d’OpenStreetMap ebrezhoneg 
(OSM en breton).
 
http://www.openstreetmap.bzh/fr/2018/11/04/ar-gartenn-vrezhonek-war-an-arload-henchan-ha-merdein-osmand-penaos-he-silan-ennan/


Christian R.


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

Re: [OSM-talk-fr] cartographie d'un institut de formation

2018-09-11 Thread Topographe Fou
Bonjour,

OsmAnd propose amenity=training pour les centres de formation (2087 usages, 
correspond à une proposition abandonnée sur le Wiki). La proposition suggère 
ensuite de raffiner le type de formation avec training=*

Personnellement je l'utilise lors de mes relevés. 

A noter que si c'est dispensé par une association ou une entreprise qui a une 
vocation principale autre que de former (mouvement scout, associations 
proposant des séjours...), il faudrait également référencer l'organisme en tant 
que tel dans un autre objet pour éviter les conflits de tag/value.

Cordialement, 

LeTopographeFou

  Message original  
De: o...@lepiller.eu
Envoyé: 10 septembre 2018 10:28 PM
À: talk-fr@openstreetmap.org
Répondre à: talk-fr@openstreetmap.org
Objet: [OSM-talk-fr] cartographie d'un institut de formation

Bonsoir,

j'ai essayé de cartographier un institut de formation qui propose des
formations pour le BAFA/BAFD. Je n'ai pas réussi à trouver de jeu
d'attribut correspondant à ce que j'essayais de cartographier. À
défaut, j'ai indiqué amenity=college. Qu'en pensez-vous ?

Le nœud : https://www.openstreetmap.org/node/5895819346

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


Re: [OSM-talk-fr] OSM est rapide, enfin bon

2018-08-14 Thread Topographe Fou
Bonjour,

Il y a bien l'initiative OpenTraffic (http://opentraffic.io/) mais apparemment 
ce sont les applications qui sont invités à participer et non des individuels 
(ou alors j'ai raté un truc...).

Cordialement, 

LeTopographeFou

  Message original  
De: marc_marc_...@hotmail.com
Envoyé: 14 août 2018 4:39 PM
À: talk-fr@openstreetmap.org
Répondre à: talk-fr@openstreetmap.org
Objet: Re: [OSM-talk-fr] OSM est rapide, enfin bon

cela dépend quand même un peu du type d’événement :
un pont détruit qui le serra donc pendant des mois,
cela a sa place comme modif dans osm
un incendie de quelques heures, non

est-ce qu'il y a des routages utilisant OpenEventDatabase ?
est-ce qu'il y a un OpenWaze pour contribuer ?
est-ce qu'il y a un OED-mondial ?
tout cela pourrait aider à rendre l'info structurée et utile.
je reste cependant un peu étonné quand OED se décrit lui-même
comme le lieux adapté pour par ex stoker les anciens tracés de routes
cela donne un peu l'impression d'un sacré fourre-tout :-s

Le 15. 08. 18 à 01:22, Jérôme Seigneuret a écrit :
> Hé Hé. Ma remarque est une boutade car on a déjà abordé un sujet sur ce 
> genre de modification. C'est de mémoire @Christian Quest 
> qui nous avait plutôt invité à 
> utiliser une plateforme dédiée évènements. OpenEventDatabase
> http://live.openeventdatabase.org/
> 
> Ca a en outre été abordé quand on parlait de l'incendie du pont de Rouen 
> dont parle @Philippe Verdy 
> 
> 
> Le mer. 15 août 2018 à 01:02,  > a écrit :
> 
> De la supériorité de l'homme sur la machine.
> 
> 
>https://www.google.com/maps/place/44%C2%B025'31.6%22N+8%C2%B053'23.7%22E/@44.4254437,8.8877395,17z
> 
>
> 
> On remarque bien sûr que le pont est toujours là et que la gare de
> triage supprimée voici deux ans sur OSM est elle aussi toujours là.
> Jérôme, ça montre que des vrais gens sont plus réactifs alors qu'on
> est en droit de penser que les unes des journaux peuvent entraîner
> des visites d'endroits et donc des cartes à actualiser.
> Maintenant Google ne connaissant pas le nom du pont c'est via OSM
> que j'ai trouvé l'endroit sur GM...
> 
> *Utiliserez-vous une Google Car utilisant des cartes Google Maps
> pour calculer l'itinéraire ?*
> 
> Jean-Yvon
> 
> Le 14/08/2018 à 14:22, Philippe Verdy - verd...@wanadoo.fr
>  a écrit :
>> Cette crise va être durable, le pont ne sera pas reconstruit avant
>> des mois.
>> Marquer les ways fermés est donc approprié car il faudra utiliser
>> les ponts plus au sud. Après cela il y aura certainement de
>> nouveaux aménagements, et sans doute des voies provisoires et des
>> changements partout autour sur les restrictions de circulation
>> pour gérer le traffic.
>>
>> On a déjà eu ça en France avec le Pont Mathilde à Rouen suite à un
>> incendie.
>>
>> Le mar. 14 août 2018 à 13:36, Jérôme Seigneuret
>> mailto:jerome.seigneu...@gmail.com>>
>> a écrit :
>>
>> Je ne savais pas qu'on faisait de la cartographie de gestion
>> de crise ;-)
>>
>> Le mar. 14 août 2018 à 13:09, Francescu GAROBY
>> mailto:windu...@gmail.com>> a écrit :
>>
>> Ah ouais ! Réactif, en effet... :-/
>> (pour ceux qui se demandent ce qu'il s'est passé :
>> 
>>https://www.lci.fr/international/italie-un-pont-autoroutier-s-ecroule-a-genes-les-pompiers-sont-a-la-recherche-d-eventuelles-victimes-2095689.html)
>>
>> Francescu
>>
>> Le mar. 14 août 2018 à 13:03, David Crochet
>> mailto:david.croc...@free.fr>> a
>> écrit :
>>
>> Bonjour
>>
>> on peut dire qu'OSM est réactif, mais on aurait aimé
>> une meilleur
>> situation (accident de l'A10 à Gênes):
>>
>> https://www.openstreetmap.org/way/616904167
>>
>> -- 
>> David Crochet
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> 
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>>
>> -- 
>> Francescu
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>>
>> -- 
>> Cordialement,
>> Jérôme Seigneuret
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org 
>> 

Re: [OSM-talk-fr] cimetière et religion

2018-07-27 Thread Topographe Fou
Bonjour,

Attention, il peut y avoir des exceptions françaises : carrés musulmans 
(https://fr.m.wikipedia.org/wiki/Carr%C3%A9_musulman), cimetières juifs (ex : 
https://fr.m.wikipedia.org/wiki/Cimeti%C3%A8re_juif_de_Besan%C3%A7on), 
cimetières de communautés religieuses (majoritairement chrétiennes dans le cas 
français) et peut être aussi quelques autres cimetières privés jouissant de 
dérogations ou de statuts pré-1905.

Bref les lois ont évoluées depuis 1905. A tenir compte dans la mise à jour de 
la page des cimetières.

Dans le cas présent, je ne me suis pas renseigné mais il est probable que ce 
soit un cimetière municipal ordinaire et donc sans confession (à vérifier et 
sources si la confession est appropriée) 

Cordialement, 

LeTopographeFou

  Message original  
De: pe...@adrieng.fr
Envoyé: 27 juillet 2018 2:32 PM
À: talk-fr@openstreetmap.org
Répondre à: talk-fr@openstreetmap.org
Objet: [OSM-talk-fr] cimetière et religion

Bonjour,

J'ai eu la surprise de voir un cimetière tagué avec une religion (catho) :

https://www.openstreetmap.org/way/70372780#map=18/48.00631/6.71545

Or en France les cimetières sont des espaces laïques, par la loi de 1905
(article 28) :

« Il est interdit, à l'avenir, d'élever ou d'apposer aucun signe ou
emblème religieux sur les monuments publics ou en quelque emplacement
public que ce soit, à l'exception des édifices servant au culte, des
terrains de sépulture dans les cimetières, des monuments funéraires,
ainsi que des musées ou expositions. »

https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=LEGITEXT06070169=20180727

À mon sens, seule les tombes peuvent donc être marquées d'une religion,
mais en aucun cas le cimetière complet ! C'est d'ailleurs la position de
la Fédération de la libre pensée, confirmé par le Conseil d'État :

https://www.fnlp.fr/news/413/17/Croix-sur-les-parties-communes-des-cimetieres.html


Si personne n'y voit d'inconvénient, je compte donc corriger ce
cimetière, et indiquer clairement cette réflexion sur la page wiki
concernant le tag cimetière. Un test OSMOSE là-dessus comblerait à coup
sûr les défenseurs de la laïcité, mais c'est au delà de mes compétences…


Bonne journée

Adrien

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


Re: [OSM-talk-fr] Route500 et le passage à 80 km/h du 1er juillet...

2018-06-26 Thread Topographe Fou
  Bonjour,Perso j'utilise le greffon JOSM https://github.com/JOSM/turnlanes-tagging/blob/master/README.mdSon interface graphique n'est pas parfaite mais aide grandement à la saisie des voies ! Son défaut est je trouve le manque d'orientation des pictos par rapport à la direction de la voie. Mais sinon c'est top.Cordialement LeTopographeFou   De: jerome.ama...@gmail.comEnvoyé: 26 juin 2018 7:12 PMÀ: talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: Re: [OSM-talk-fr] Route500 et le passage à 80 km/h du 1er juillet...  Petites questions sur les tags lanes :Comment faire dans les rond point ou il n'y a pas de délimitation au sol mais ou 2 voitures (camion pas trop...) passent de front.Lanes=1 ou 2 (ou 1.5)Moi je mets rien :) (je mets 2 seulement si le marquage au sol indique 2 voies)Dans josm vous utilisez quelque chose pour vous aidez?moi j'ai un coloriage "lanes and road attribut" qui permet de representer le nombre de voie, les fleche au sol...il n'y a pas de grefon ou de modele qui permet de simplifier l'ajout des turn:lanes et autres tags sur les lanes?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


[OSM-talk-fr] Conférence « La Terre dans l'œil de Thomas Pesquet »

2018-01-07 Thread Topographe Fou
 Bonjour à tous,Pour démarrer l'année l'association AGP21 organise une conférence (entrée libre) de décryptage par un géographe de photos de la terre prises par le spationaute Thomas Pesquet depuis l'ISS :http://agp21.org/node/37Ouhttp://www.air-cosmos.com/conference-la-terre-dans-l-il-de-thomas-pesquet-105323   Ce qui au vue de la présentation pourrait intéresser tout cartographe surtout les adeptes d'imageries avions ou satelittes.Attention c'est demain lundi soir dans Paris. Le plus c'est que apparemment il reste de la place, s'inscrire auprès de Nathalie (mail présent sur la page d'A).Cordialement, LeTopographeFou ___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Importation des arbres municipaux de Grenoble

2017-11-16 Thread Topographe Fou
  Bonjour,Question : je vois quelques natural=tree_row à Grenoble. L'import va-t-il également chercher à insérer ces arbres dans les ways ou à les fusionner avec des nœuds déjà existant de ces tree_row ? Ou bien ce tag est ignoré ?Vu le peu de tree_row dans cette ville ce travail de fusion peut être manuel mais comme j'imagine que l'algo pourrait être réutilisé ailleurs... Ce serait top qu'il en tienne compte.Cordialement, LeTopographeFou   De: vincent.fri...@gmail.comEnvoyé: 16 novembre 2017 11:24 PMÀ: talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: [OSM-talk-fr] Importation des arbres municipaux de Grenoble  Hello,Je projette d'importer les arbres municipaux de Grenoble disponibles en ODbL sur le portail open date le ville: http://data.metropolegrenoble.fr/ckan/dataset/les-arbres-de-grenobleContrairement aux données de la ville de Nice il n'y a pas que la localisation mais aussi le genre/espèce et l'année de plantation. Pour cette dernière info pensez vous qu'il est possible de rajouter un tag ? Malheureusement je ne vois rien de tel sur le wiki...Mon script regarde si des arbres existent déjà dans un rayon de 3 mètres: s'il y en a pas il créé un nouvel arbre et sinon il met à jour l'arbre (le plus proche s'il y en a plusieurs) en modifiant la position et en ajoutant les tags d'espèces/genre (sauf s'il existe déjà une valeur). Il y a également une vérification pour éviter d'importer un arbre à l'intérieur d'un bâtiment.  Pour info voici quelques stats:2017-11-16 22:52:02  INFO === Loading statistics ===2017-11-16 22:52:02  INFO Total of parsed imports: 308502017-11-16 22:52:02  INFO Total of filtered out imports: 622017-11-16 22:52:02  INFO Total of loaded imports: 307882017-11-16 22:52:02  INFO === Processing statistics ===2017-11-16 22:52:02  INFO Total of makable imports: 307372017-11-16 22:52:02  INFO Total of non makable imports: 512017-11-16 22:52:02  INFO Matching area radius: 3.02017-11-16 22:52:02  INFO Matching closest only: true2017-11-16 22:52:02  INFO Total of created trees: 242112017-11-16 22:52:02  INFO Total of updated trees: 65262017-11-16 22:52:02  INFO Total of created or updated trees: 307372017-11-16 22:52:02  INFO Total of multi matching trees: 5582017-11-16 22:52:02  INFO Job has been executed in 535 seconds2017-11-16 22:52:03  INFO === Closing OSM XML service ===2017-11-16 22:52:03  INFO Total of writing successes: 32017-11-16 22:52:03  INFO Total of writing failures: 02017-11-16 22:52:03  INFO === Closing OSM API service ===2017-11-16 22:52:03  INFO Total of read operations: success=6748 failure=02017-11-16 22:52:03  INFO Total of write operations: success=0 failure=02017-11-16 22:52:03  INFO Total of changeset operations: open=0 close=0++ Vincent
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Configuration JOSM

2017-11-09 Thread Topographe Fou
  Bonjour,De mémoire (et sans pouvoir vérifier...) cela peut aussi venir de la présence de trottoirs (sidewalk=*) et/ou d'un éclairage (lit=yes) surtout depuis que StreetComplete incite à mettre cet attribut.Autant c'est utile à mon goût pour les trottoirs autant c'est casse-pied pour l'éclairage public car cela alourdi tout visuellement. Apparemment le style permettant d'afficher les voies peut également y être pour quelque chose.A creuser :https://josm.openstreetmap.de/wiki/Styles/Lithttps://wiki.openstreetmap.org/wiki/Josm/styles/lane_featuresUn exemple de way et éventuellement une capture écran ainsi que la liste des styles/greffons JOSM utilisés pourraient aider.Cordialement, LeTopographeFou   De: verd...@wanadoo.frEnvoyé: 9 novembre 2017 12:11 AMÀ: winfi...@gmail.com; talk-fr@openstreetmap.orgRépondre à: verd...@wanadoo.fr; talk-fr@openstreetmap.orgObjet: Re: [OSM-talk-fr] Configuration JOSM  Je pense que ces bandes indiquent la présence des voies cyclables ou de service (bus) d'un côté ou de l'autre. Elles indiquent plus clairement de quel côté cela a été réellement tagué car il y a beaucoup d'erreurs liées à l'interprétation visuelle (orientation de la carte avec le nord en haut) et non celle voulue du sens du tracé (confusion fréquence entre les suffixes ":left" et ":right" quand la route est plutôt tracée dans le sens nord-sud et non sud-nord, ou aussi plus généralement entre ":forward" et ":backward")Le 9 novembre 2017 à 00:00, Jo  a écrit :C'est avec quels types de way que ça se passe? Quelle version de JOSM, tested ou latest?Jo2017-11-08 22:48 GMT+01:00 Romain MEHUT :Dans le menu "Coloriage", j'ai "JOSM par défaut (MapCSS)" en modèle actif. Effectivement si je le désactive, je n'ai plus les "bandes" mais du coup tous les ways sont identiques de couleur grise.RomainLe 8 novembre 2017 à 22:38, Jo  a écrit :Est-ce possible que tu as activé un style MapCSS?Jo2017-11-08 22:23 GMT+01:00 Romain MEHUT :Bonsoir,Depuis un moment, je suis gêné par un nouveau paramétrage de JOSM qui met comme une "bande" de part et d'autre de certains ways. Je voudrais qu'il n'y ait pas cette "bande" car elle masque trop l'imagerie pour tracer correctement les ways en dessous.Je ne sais pas où cela se trouve dans la configuration de JOSM... Si vous voyez de quoi je parle, quelqu'un sait comment faire ?Merci.Romain
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

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

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

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


Re: [OSM-talk-fr] Trajets de bus et ronds--points

2017-09-07 Thread Topographe Fou
Merci Lenny, me voila rassuré, désolé si j'ai pu mal interpréter ton propos
:-) .

Le 7 septembre 2017 à 15:14, lenny.libre <lenny.li...@orange.fr> a écrit :

>
>
> Le 07/09/2017 à 13:59, Topographe Fou a écrit :
>
>
>
> Le 7 septembre 2017 à 12:52, lenny.libre <lenny.li...@orange.fr> a écrit :
>
>>
>>
>> Le 07/09/2017 à 09:44, Vincent Pottier a écrit :
>>
>>> Le 07/09/2017 à 08:54, JB a écrit :
>>>
>>>> Bof.
>>>> Je pense que la valeur ajoutée du mappeur est plus dans le repérage et
>>>> la saisie des données au plus simple, et que les tâches ingrates comme le
>>>> découpage des rond-point devraient être sous-traitées aux outils.
>>>> Personnellement, après avoir commencé à trifouiller un rendu transport,
>>>> je me demande presque si les trajets ne devraient pas être carrément
>>>> recalculés intégralement par un routeur pour aboutir à quelque chose de
>>>> cohérent. Pour exemple sur les réseaux tram (donc avec vraiment des voies
>>>> en propres et un réseau évoluant peu), j'ai été désespéré dans certains cas
>>>> par les relations existantes. Alors quand j'imagine ce que ça pourrait
>>>> donner pour les bus…
>>>> JB.
>>>>
>>> Il me semblait que la question avait été traitée, discutée et résolue il
>>> y a quelques années. De mémoire, voici la synthèse des résultats de
>>> discussions.
>>>
>>> Comme le disait Philippe, les ronds-points sont à considérer comme
>>> points un peu gros, sauf cas particuliers de constitution (genre :
>>> https://osm.org/go/0CUlN2EHd?m= ).
>>>
>>> C'est au logiciel de navigation (ou de rendu) de calculer la portion
>>> empruntée (ce que savent bien faire les logiciels de navigation), portion
>>> changeante qu'on soit à pied, à cheval ou en voiture.
>>>
>>> Donc, non, on ne les fractionne pas, sauf cas particuliers, qui ne sont
>>> pas de l'ordre du routage.
>>>
>>> Ces discussions ont changé ma pratique. Et maintenant, je fusionne les
>>> ronds-points fractionnés pour raisons de routage (trajets de bus ou
>>> itinéraires pédestres).
>>>
>>> FrViPofm
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>> Peut-être faut-il poser des question simples, les réponses ne concernant
>> que ce que j'ai vu, ce sont mes statistiques.
>>
>> Qui découpe les giratoires ?
>> - le contributeur qui décrit des différence entre les différents tronçons
>> : c'est la même logique que la découpe de tronçons de voirie avec des
>> différences (type de voie, vitesse ...)
>> - le contributeur de lignes de transport public qui veut voir le routage
>> exact.
>>
>
> Exactement et ce sont pour moi des contributions recevables dans la mesure
> où elles affinent le modèle sans le détruire.
>
>
>>
>> Quelles applications ont besoin de giratoires découpés ?
>> - aucune : les applis de routage savent fonctionner avec ou sans découpage
>>
>
> Ne jamais dire "aucun", OSM est un projet libre, pas fermé. Je suis certes
> incapable d'un citer une avec précision mais je ne vois pas pourquoi il ne
> devrait pas en exister, qui plus est quand cela rentrerait dans des calculs
> internes dont l'utilisateur n'aurait même pas connaissance.
>
> J'ai bien précisé que cela ne concernait que ce que j'ai pu voir " *les
> réponses ne concernant que ce que j'ai vu, ce sont mes statistiques*"
>
>
>
>>
>> Quel est l'impact du découpage/fusion ?
>> - lorsque je consultais certaines lignes de transport public qui me
>> tenaient à cœur, je trouvais qu'elles n'avaient plus de continuité parce
>> qu'un contributeur avait découpé un giratoire pour voir afficher la ligne
>> qui intéressait sans s'occuper des autres lignes.
>>
>
> Et c'est une erreur de la part de celui qui découpe nous sommes
> d'accord... Il doit vérifier toutes les relations (pas juste les bus) pour
> s'assurer qu'il ne créé pas d'erreur.
>
>
>> - Je ne fusionnais pas systématiquement les giratoires, mais quand je le
>> faisais, je partais du segment qui avait l'historique le plus complet et je
>> vérifiais qu'il n'y avait pas de rupture de continuité sur les autres
>> lignes. Je n'ai pas vu de rupture provoquée par contributeur qui regroupent
>
>
> Pardonnez-moi mais là je lis des choses qui me dérangent et je voudrais
> une clarification.
&

Re: [OSM-talk-fr] Trajets de bus et ronds--points

2017-09-07 Thread Topographe Fou
Le 7 septembre 2017 à 12:52, lenny.libre  a écrit :

>
>
> Le 07/09/2017 à 09:44, Vincent Pottier a écrit :
>
>> Le 07/09/2017 à 08:54, JB a écrit :
>>
>>> Bof.
>>> Je pense que la valeur ajoutée du mappeur est plus dans le repérage et
>>> la saisie des données au plus simple, et que les tâches ingrates comme le
>>> découpage des rond-point devraient être sous-traitées aux outils.
>>> Personnellement, après avoir commencé à trifouiller un rendu transport,
>>> je me demande presque si les trajets ne devraient pas être carrément
>>> recalculés intégralement par un routeur pour aboutir à quelque chose de
>>> cohérent. Pour exemple sur les réseaux tram (donc avec vraiment des voies
>>> en propres et un réseau évoluant peu), j'ai été désespéré dans certains cas
>>> par les relations existantes. Alors quand j'imagine ce que ça pourrait
>>> donner pour les bus…
>>> JB.
>>>
>> Il me semblait que la question avait été traitée, discutée et résolue il
>> y a quelques années. De mémoire, voici la synthèse des résultats de
>> discussions.
>>
>> Comme le disait Philippe, les ronds-points sont à considérer comme points
>> un peu gros, sauf cas particuliers de constitution (genre :
>> https://osm.org/go/0CUlN2EHd?m= ).
>>
>> C'est au logiciel de navigation (ou de rendu) de calculer la portion
>> empruntée (ce que savent bien faire les logiciels de navigation), portion
>> changeante qu'on soit à pied, à cheval ou en voiture.
>>
>> Donc, non, on ne les fractionne pas, sauf cas particuliers, qui ne sont
>> pas de l'ordre du routage.
>>
>> Ces discussions ont changé ma pratique. Et maintenant, je fusionne les
>> ronds-points fractionnés pour raisons de routage (trajets de bus ou
>> itinéraires pédestres).
>>
>> FrViPofm
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
> Peut-être faut-il poser des question simples, les réponses ne concernant
> que ce que j'ai vu, ce sont mes statistiques.
>
> Qui découpe les giratoires ?
> - le contributeur qui décrit des différence entre les différents tronçons
> : c'est la même logique que la découpe de tronçons de voirie avec des
> différences (type de voie, vitesse ...)
> - le contributeur de lignes de transport public qui veut voir le routage
> exact.
>

Exactement et ce sont pour moi des contributions recevables dans la mesure
où elles affinent le modèle sans le détruire.


>
> Quelles applications ont besoin de giratoires découpés ?
> - aucune : les applis de routage savent fonctionner avec ou sans découpage
>

Ne jamais dire "aucun", OSM est un projet libre, pas fermé. Je suis certes
incapable d'un citer une avec précision mais je ne vois pas pourquoi il ne
devrait pas en exister, qui plus est quand cela rentrerait dans des calculs
internes dont l'utilisateur n'aurait même pas connaissance.


>
> Quel est l'impact du découpage/fusion ?
> - lorsque je consultais certaines lignes de transport public qui me
> tenaient à cœur, je trouvais qu'elles n'avaient plus de continuité parce
> qu'un contributeur avait découpé un giratoire pour voir afficher la ligne
> qui intéressait sans s'occuper des autres lignes.
>

Et c'est une erreur de la part de celui qui découpe nous sommes d'accord...
Il doit vérifier toutes les relations (pas juste les bus) pour s'assurer
qu'il ne créé pas d'erreur.


> - Je ne fusionnais pas systématiquement les giratoires, mais quand je le
> faisais, je partais du segment qui avait l'historique le plus complet et je
> vérifiais qu'il n'y avait pas de rupture de continuité sur les autres
> lignes. Je n'ai pas vu de rupture provoquée par contributeur qui regroupent


Pardonnez-moi mais là je lis des choses qui me dérangent et je voudrais une
clarification.

Que l'on apprécie ou pas l'utilité d'aller au niveau de détail des
"sections" de rond points, de manière générale (pour toute way) :

   - Découper une way pour appliquer des attributs différents/relations
   différentes aux deux morceaux cela s'appelle affiner le modèle et c'est
   considéré comme une contribution utile, à fortiori quand c'est en utilisant
   le schéma de tag conventionnel (à supposer que les infos soient bonnes et
   libres, ce qui n'est pas la question ici)
   - Fusionner deux ways qui ne sont pas strictement identiques (attributs
   et relations), et donc supprimer un niveau de détail (et à fortiori
   utilisant le schéma de tag conventionnel), sous le prétexte que personne
   (?) n'a besoin de descendre à ce niveau de détail, c'est supprimer une
   contribution sans justification rationnelle. Et quand c'est pour faire
   plaisir à son outils préféré, que ce soit du rendu, de navigation... cela
   s'appelle tagguer pour l'outil (ce qui n'est pas dans les règles convenues
   il me semble).

En bref je voudrais m'assurer qu'il n'est pas question ici de promouvoir la
suppression (que je juge abusive) de telles contributions.


>
>
> 

Re: [OSM-talk-fr] Trajets de bus et ronds--points

2017-09-07 Thread Topographe Fou
  Bonjour,J'avoue que ayant pas mal travaillé sur les lignes et arrêts de bus dans la région de Paris je fais partie de ceux qui découpent les rond-points (et sans vérifier si précédemment ils n'avaient pas été soudés). Je trouve que donner un tracé exact est plus juste par rapport à la réalité du terrain. C'est mon seul argument.Quoiqu'il arrive les outils doivent pouvoir gérer des ronds-points découpés car il peut y avoir d'autres raisons à cela que les lignes de bus (changement de revêtement ? Passage dans un tunnel (rare) ? Sur un pont (plus fréquent) ? Piste cyclable que sur une partie ?...). Donc si les lignes de bus augmentent les occurrences interdire ou déconseiller cette pratique ne résoudra pas fondamentalement le problème. Quelque soit la solution il faudra que les outils s'adaptent aux deux. On ne tag pas pour eux (ou pour le rendu comme on a tendance à simplifier ;-) ). Un outils gérant les deux sera capable de gérer bien plus qu'un problème de bus.Cordialement, LeTopographeFouDe: f.gar...@gmail.comEnvoyé: 7 septembre 2017 12:27 AMÀ: talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: [OSM-talk-fr] Trajets de bus et ronds--points  Bonsoir,Je pense qu'il faudrait se mettre d'accord une bonne fois pour toutes, avec les ronds-points empruntés par les lignes de bus...À chaque fois, ça ne loupe pas : je trouve des ronds-points morcelés, ou refusionnés, puis remorcelés, ... Bref, à cause de tout ça, les tracés des lignes de bus sont incorrects, au niveau des ronds-points.Personnellement, je pense que ça n'a pas de sens de couper un rond-point, étant donné que l'entrée et la sortie sont connues. Charge au logiciel de dessin de tenir compte de ça...-- Cordialement,Francescu GAROBY

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


Re: [OSM-talk-fr] Bar ou resto des 2 côtés du pâté de maison

2017-07-12 Thread Topographe Fou
  Bonjour,Je tagguerai le restaurant/bar avec une aire (et non un nœud) et je mettrai des nœuds d'entrée là où il faut.Ensuite, si le restaurant est l'intégralité du bâtiment ajouter building=yes. Sinon préciser le niveau (level) et laisser le bâtiment à part.A vrai dire dans le meilleure des mondes tous les restaurants et bars devraient être cartographiés sous forme d'aire (et non de point).Cordialement, LeTopographeFouDe: n.toubl...@gmail.comEnvoyé: 12 juillet 2017 10:17 AMÀ: talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: [OSM-talk-fr] Bar ou resto des 2 côtés du pâté de maison  Bonjour,J'espère ne pas trop polluer le forum avec mes questions...Comment taguer le fait qu'un bar ou un resto est présent de 2 côtés d'un pâté de maison, quand celui-ci est assez large pour ne pas pouvoir mettre le tag au milieu?Parfois, un côté peut-être anecdotique, dans quel cas on se contente du côté principal, mais en zone touristique, les 2 côtés peuvent être très développés, avec chacun un devanture et une terrasse, comme si il s'agissait de 2 établissements différents.Merci-- Nicolas Toublanc

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


Re: [OSM-talk-fr] Valeurs multiples pour des altitudes

2017-04-02 Thread Topographe Fou
 S'assurer aussi que Osmose et autres outils ne génèrent pas une erreur quand deux repères géodésiques sont superposés sinon un autre refusionnera pensant bien faire.D'ailleurs une nouvelle règle Osmose pourrait signaler quand un repère géodésique a plusieurs altitudes (ele=*) ou références (réf=*) pour suggérer une séparation. Qu'en pensez-vous ?LeTopographeFouDe: osm.sanspourr...@spamgourmet.comEnvoyé: 2 avril 2017 8:57 PMÀ: talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: Re: [OSM-talk-fr] Valeurs multiples pour des altitudes  
  

  
  
Effectivement Florian avait bien documenté et Olivier-S
  a cassé les deux "double" points il y a 6 ans !

Comme il n'a pas fait de modif depuis 3 ans, peut-être faire
bêtement un revert même si je suis plus pour indiquer aux gens que
l'on corrige et pourquoi.

Jean-Yvon

Le 02/04/2017 à 16:48, Jean-Claude
  Repetto - jrepe...@free.fr a écrit :

Bonjour,
  
  
  A l'origine, il y avait bien deux points, mais quelqu'un les a
  fusionnés:
  
  https://www.openstreetmap.org/changeset/5581294
  
  https://www.openstreetmap.org/changeset/5581232
  
  
  Je pense qu'il faudrait faire un revert de ces modifications, car
  ces points, bien qu'ayant les mêmes coordonnées géographiques,
  n'avaient pas la même altitude.
  
  
  Jean-Claude
  
  
  ___
  
  Talk-fr mailing list
  
  Talk-fr@openstreetmap.org
  
  https://lists.openstreetmap.org/listinfo/talk-fr
  


  

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


Re: [OSM-talk-fr] base VLA (vitesse limite autorisé)

2017-02-20 Thread Topographe Fou
  Bonjour,Personnellement quand le 30 s'applique sur le dos d'âne (ou intersection surélevée), je met le maxspeed=30 sur le node indiquant le dos d'âne sans faire de découpage. J'attends ainsi d'un algo de routage de comprendre qu'il faut être à 30 au passage du node (donc du dos d'âne). Bien entendu je parle bien là du cas où le panneau rond 30 est sous le triangle dos d'âne.Sinon pour revenir au sujet initial, les maxspeed sont pour moi les données qui manquent le plus en France (pour le reste, on est plutôt bien loti même si certaines régions sont moins bien couvertes). Peut-être parce que les maxspeed ne peuvent pas être connus sur une vue aérienne depuis son fauteuil ;-) . Donc c'est une source potentiellement intéressante. Cordialement, LeTopographeFou   De: jerome.ama...@gmail.comEnvoyé: 21 février 2017 1:55 AMÀ: talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: Re: [OSM-talk-fr] base VLA (vitesse limite autorisé)  Le 20 février 2017 à 22:25,   a écrit :
  

  
  
Le 20/02/2017 à 20:36, Jérôme Amagat - jerome.ama...@gmail.com a
  écrit :

D’après le code de la route, la limitation comme ici à
  30 s’arrête à la prochaine intersection si c'est pas rappelé après
  l’intersection. Ce qui fait que des fois comme il y a 1 ou 2
  intersection entre le panneau 30 et le dos d’âne et bien c'est
  limité à 50 sur le dos d’âne.
Tu as raison sur le cas général mais je pensais à un endroit où le
ralentisseur est fait pour une traversée piétonne et point
d'intersection avant 100 m. Oui il y a des zones de 30 de plus de
100 m. Mais là les panneaux de début de 30 (pas de zone de 30) sont
avant le ralentisseur dans chaque sens.

Du coup je me suis demandé comment taguer.
Ne rien mettre = rien de faux ;-)
Mettre le 30 sur le bumper.
Mettre le 30 sur le way.
Couper le way en tronçons correspondant à ce que la mairie a voulu
faire.
http://mc.bbbike.org/mc/?lon=-3.492926=47.795015=16=2=osmfr=mapbox-satellite=ol_mapquest-labels=100?marker&marker=dos%20d%27%C3%A2ne%20avec%20B14%2030%20km/h%20dans%20chaque%20sens%20de%20circulation%3Cbr%3E%20Bref%20laissez-passez%20les%20pi%C3%A9tons%20puis%20continuez%20votre%20route.

En fait je me suis mis dans un coin et j'ai attendu que ça me passe.

Logiquement j'aurais dû ajouter a minima le dos d’âne et les
cédez-le-pas de la voirie douce sur la route.

Philippe, tu as raison en théorie mais en pratique si tu as un
accident c'est le statut réel (voie publique ou accès privé) qui
dira si tu étais en excès de vitesse. Enfin pour un excès de
vitesse, il y a des chances/risques que les forces dites de l'ordre
disent pas vu pas pris même si les projections des véhicules
attestent du contraire.
Je déteste ça les dos d’âne! Vers chez moi, dans l'Ain, ( je sais que ça dépend beaucoup des endroits, la présence ou non de dos d’âne en grand nombre) le moindre petit hameau a ses 2 ou 3 ralentisseurs et ils se multiplient à une vitesse folle.Souvent je me dis que les personnes en charge de la voirie dans les communes ne connaissent rien au code de la route. (c'est surement le cas, vu que c'est sûrement les élus qui décident et qu'ils ont pour la plupart plus de 60 ans qu'ils ont donc passer leur permis il y a plus de 40 ans alors que les dos d'ane n'existaient pas, ni les zone 30, que les rond point était très rare ...)Enfin après ça revenons au limitation de vitesse et à osm :)Pour moi, cette limitation à 30 avant les ralentisseurs c'est en fait seulement un autre moyen d'indiquer la présence d'un dos d’âne (en plus du panneau fait pour ça). dans osm quand je modifie ce genre d'endroit j'indique le dos d'ane mais je laisse toute la rue à maxspeed=50, je fait pas des découpes pour indiqué le passage à 30.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] HebdoOSM

2017-02-16 Thread Topographe Fou
Bonjour,

J'ai rempli hier le formulaire de contact du site dans ce sens (pour de la 
traduction) mais n'ai pas eu encore de réponse.

Perso le fait de ne pas avoir de news sur la communauté francophone me dérange 
moins que de ne pas avoir de news du tout en français (le français est une 
belle langue à faire rayonner !). En ce qui me concerne l'anglais ne me pose 
pas de problème mais la langue ne doit pas être une barrière au bénévolat, donc 
si il y a ne serait-ce que un article de traduit sur 10 se seras mieux que 
d'attendre d'être capable de faire un truc top qualité. Laisser ouvert vs 
Fermer, cela me paraît assez binaire comme option voir radical.

By the way mettre un encart pour rechercher des traducteurs directement dans la 
newsletter serait indispensable. Là c'est assez confidentiel, il n'y a rien sur 
le site et je n'ai trouvé la page de connexion du site de gestion des news 
qu'en passant par le Readme du dépôt Github ! (Ou alors c'est moi qui ne suit 
pas doué...)

J'ai bien aimé d'ailleurs le fait que la première actu soit un clin d'œil à 
Transiflex (même si c'est inadapté dans le cas présent). 

Sinon oui de manière générale les bénévoles ne demandent qu'à être considérés 
et encouragés !

Cordialement 

LeTopographeFou 


  Message original  
De: o...@lepiller.eu
Envoyé: 16 février 2017 5:30 PM
À: talk-fr@openstreetmap.org
Répondre à: talk-fr@openstreetmap.org
Objet: Re: [OSM-talk-fr] HebdoOSM

Le 2017-02-16 16:27, Jérôme Amagat a écrit :
> Bonjour,
> 
> Pour moi, comme David Crochet, en anglais ou dans une autre langue que
> le français, je ne le lirais pas, alors que je le lis depuis qu'il
> est envoyé sur cette liste.
> Et si un sujet m’intéresse mais que le lien est en anglais alors je
> fais un effort (ou je regarde les images si c'est autre chose que du
> français ou de l'anglais :) )

Hello,

je ne comprends pas du tout comment fonctionne la traduction, qui 
traduit et comment, mais si on m'explique quels sont les outils utilisés 
et qui contacter, je suis partant pour faire de la relecture et aider à 
améliorer la traduction.

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


Re: [OSM-talk-fr] Problème de représentation avec des parcelles forestières

2016-12-07 Thread Topographe Fou
  Probablement parce que comme l'explique le Wiki un multipolygon est par défaut une aire (contrairement à boundary qui est une frontière, quelque chose de linéaire) et que si un tag manque au niveau de la relation il va le chercher au niveau des membres (là je suis d'accord avec toi : ce n'est pas normal et pousse à la surinterpretation). Il donne même un exemple en Allemagne ou des mp ont été massivement utilisés au lieu de boundary. Un multipolygon est conçu comme une manière de définir une aire mais en utilisant plusieurs ways au lieu de une.Donc comme le rendu ne reconnaît pas cette manière de tagger un parcelle, il adopte son comportement par défaut qui est "c'est une aire" et "je cherche les tags d'abord dans la relation,  sinon dans les membres". Avec une boundary il ne dessine pas d'aire donc le glitche ne se produit pas. Est-ce une magouille ou un " taguer pour le rendu" ? Je ne sais pas trop encore... Si tu rajoute un tag landuse=forest à un mp de type parcel, on devrait logiquement arriver au même résultat et cela ne me paraît pas sémantiquement faux aussi.Résultat un multipolygon avec que des membres highway est donc vu comme un highway. Contrairement à ce que j'ai pu dire je ne pense plus qu'il y ai bug mais reste persuadé qu'il y a une erreur de conception (à savoir la remontée de tags qui pousse à une mauvaise pratique).Cordialement LeTopographeFouDe: verd...@wanadoo.frEnvoyé: 7 décembre 2016 1:30 AMÀ: talk-fr@openstreetmap.orgRépondre à: verd...@wanadoo.fr; talk-fr@openstreetmap.orgObjet: Re: [OSM-talk-fr] Problème de représentation avec des parcelles forestières  Je ne vois pas en quoi ce changement de "multipolygon" en "boundary" devrait avoir un impact sur l'interprétation et la "remontée" des tags des ways membres vers les relations qui les référence.Cela reste un bogue de la conversion OSM en pgsql, qui ne tient pas compte des critères nécessaires (tags identiques dans tous les ways membres ayant un rôle "outer" ou vide, ce qui n'était pas le cas des "name=*").En revanche remonter les "highway=*" vers la relation (peu importe que ce soit une "boundary" ou un "multipolygon") est problématique, dans les faits tous les "highway=*" sont linéaires (exceptions faite des "highway=pedestrian" et à condition qu'ils soient tagués avec "area=yes", ce qui n'était pas du tout le cas ici, car par défaut les "highway=*" sont soit linéaires, soit des noeuds isolés pour des passages piétons, priorités, stops...).Il reste donc bien une anomalie de osm2pgsql ici, et je ne vois pas pourquoi osm2pgsql devrait se demander ce que sont ces "multipolygon", d'autant plus qu'ils ont déjà des tags nécessaires, qu'ils soient tagués comme "multipolygon", boundary", ou encore comme "landuse", "natural" (qui n'ont eux rien non plus à voir avec les "highway=*")Le 6 décembre 2016 à 23:38, LeTopographeFou  a écrit :
  

  
  

  J'ai basculé ces "type=multipolygon" en
"type=boundary"... et tout rentre dans l'ordre comme je l'avais
imaginé dans mon précédent message qui n'a visiblement pas été
lu ;)
  Bonjour et merveilleux !! Je n'avais pas compris le sous-entendu.
  Merci.


  En terme de logique de tagging je verrai
plutôt quelque chose comme:
type=boundary (il s'agit d'une frontière qui découpe un ensemble
plus grand)
boundary=forest (frontière forestière)
forest=section (il s'agit d'une section)

Mais ça mérite discussion sur le wiki plutôt que d'y aller à
l'arrache... [...]
  
  Tout là fait d'accord (sans rentrer dans la discussion ici :
  j'aime bien ta proposition, elle est plus proche de l'existant et
  donc plus naturelle que la proposition Section).
Pour info il se trouve que j'ai eu un échange de mail avec
  l'auteur de la proposition Section cet été (à propos d'un
  cimetière que je visitais/cartographiais à l'époque) et il m'a dit
  qu'il n'avait pas eu le courage pour animer sa proposition
  jusqu'au bout. Il m'a encouragé à la retravailler voir à faire une
  contre-proposition, car il reste persuadé du besoin initial
  (parcelles forestières, sections dans un cimetière...).


  
Mais ça mérite discussion sur le wiki plutôt que d'y aller
  à l'arrache... surtout que l'import des données est pas génial
  non plus car les données d'origine ne sont pas forcément bien
  calées...
  

Exemple: http://umap.openstreetmap.fr/en/map/test-rendu-osmfr_99740#18/48.53494/1.97682
  Alors là c'est drôle car pendant que tu 

Re: [OSM-talk-fr] refonte openstreetmap.fr / Need help

2016-11-16 Thread Topographe Fou
  +1, j'ai galeré aussi avant de comprendre où trouver la carte. Et je galère encore aujourd'hui (je ne dois pas être doué). Au final je sais qu'il faut que j'ignore ce site dans mon moteur de recherche (pas très pratique). C'est clairement un frein que d'autres utilisateurs (néophytes) m'ont remontés. L'extension .fr devrait être avant tout autre service un raccourci pour s'assurer que l'on va tomber sur une carte en français centrée sur sa localisation (à défaut la France métropolitaine ?). Ce n'est pas très efficace de pénaliser le référencement avec deux sites différents dans l'usage mais partageant le même domaine (à l'extension près) et la même thématique.Quant au site de l'association il devrait être sur un domaine type osmfrance ou autre pour que ce soit plus tranché au niveau référencement."Il n'y a qu'à " comme dirait l'autre ^^.Cordialement LeTopographeFou    Message original    Afficher les détails   De: panierav...@riseup.netEnvoyé: 16 novembre 2016 8:41 AMÀ: talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: Re: [OSM-talk-fr] refonte openstreetmap.fr / Need help  
  

  
  
Bonjour,
  
  Juste une question/remarque : le point d'entrée du domaine
  openstreetmap.fr ce sera la carte ou le site "descriptif" de
  l'association ? De mon retour d'expérience, quand je veux faire
  découvrir OpenStreetMap à quelqu'un, la personne va chercher sur
  son moteur de recherche préféré, et le site .fr ressort en
  premier. Mais là c'est ballot, il faut aller chercher le lien pour
  accéder à la carte sur osm.org. Un détour pas toujours utile. Si
  l'on développe un portail map.osm.fr, ce serait pertinent que ce
  soit le point d'entrée du site openstreetmap.fr. Et après, mettre
  en évidence les menus thématiques (mais de manière plus évidente
  que sur osm.org, où c'est pas hyper intuitif). À mon avis pour les
  "découvreurs", le plus parlant ce sera déjà une carte, et ensuite
  des explications plus générales sur le but, les moyens...
  
  Cordialement.
  
  
  Le 15/11/2016 à 23:06, Florian LAINEZ a écrit :


  

  

  

  

  Hello,
Le site openstreetmap.fr
ne vous a-t-il jamais énervé : vieux, moche et
pas très utile ?
  
  Changeons cela ensemble ! Je cherche des
  volontaires pour passer un peu de temps pour
  refaire le site, est-ce que cela tente du Monde ?

ça se passe ici : https://annuel.framapad.org/p/openstreetmap.fr
C'est une proposition que moi-même, Jean-Louis
  et Donat nous vous soumettons à discussion, de ce
  que pourrai être notre future vitrine.
  

On a plusieurs phases à définir et à mettre en
œuvre, vous pouvez aider selon vos compétences :
  
  1. Définir le besoin/structure du site : besoin de
  n'importe qui de motivé

2. Collecter le contenu multimédia : photos,
  illustrations ... : besoin de n'importe qui de motivé
  3. écrire le contenu : besoin de personnes à l'aise à
  l'écrit / aimant écrire

4. Créer le design : sauf si quelqu'un d'entre vous est
designer, on envisage de sous-traiter cette partie sur
laquelle on manque de compétence
  
  5. Intégrer le design et développer le site en lui-même :
  besoin de dev web (la techo n'est pas encore choisie, nous
  pouvons en discuter ...)

6. Migrer le contenu du vieux site, gérer la redirection des
URLs : besoin de dev web
  
  7. Continuer l'animation / création de contenu une fois le
  site lancé : besoin de personnes à l'aise à l'écrit / aimant
  écrire motivées dans le 

Re: [OSM-talk-fr] Extraire une géométrie représentative d'une relation

2016-08-23 Thread Topographe Fou
  Bonjour Quid de l'algorithme de Douglas-Peucker ? C'est efficace pour éliminer le bruit. Quant à l'appliquer sur autre chose qu'une unique ligne non fermée cela demandera un peu d'adaptation.LeTopographeFou   De:fl.infosrese...@gmail.comEnvoyé:23 août 2016 8:00 AMÀ:talk-fr@openstreetmap.orgRépondre à:talk-fr@openstreetmap.orgObjet:Re: [OSM-talk-fr] Extraire une géométrie représentative d'une relation  En fait, je donnais un exemple et le but est de trouver une méthode pour toutes les relations.Toutes n'ont pas de membre avec le role line.On peut se demander ce qu'est une géométrie représentative (je raisonne tout haut)Le périmètre qui encadre tous les membres par exemple, mais trop "grossier".Ou alors la concaténation des plus gros membres de la relationIl doit surement y avoir d'autres moyens de l'exprimerDans mon exemple, on devrait être capable de retrouver la forme de la ligne qui constitue le plus gros de la relation en éliminant le "bruit" aux extrémités provoqué par des objets proches les uns des autres au regarde de l'étendue de la relation.Mais surtout il ne faut travailler que sur la géométrie des membres, dès qu'on passe aux attributs, ca revient à définir des règles spécifiques dont je ne veux pas.Pas sur que ce soit plus clair :)François Lacombefl dot infosreseaux At gmail dot comwww.infos-reseaux.com@InfosReseaux
Le 22 août 2016 à 16:45, Christian Quest  a écrit :
  

  
  
Dans overpass une requête permet de ne sélectionner que les
  membres portant un certain rôle dans la relation:
rel(5430194);
  way(r:"line");
  (._;>;);out skel;

Après il faut en récupérer la version geojson...


Le 22/08/2016 à 15:25, François Lacombe
  a écrit :


  

  

  Bonjour Philippe, Guillaume,

  
  Personne n'est a coté de la plaque ;)
  

Cependant, seule la méthode m’intéresse.
  
  En effet il y a déjà quelques outils qui parviennent à
  présenter graphiquement une relation mais j'ai besoin de
  l'implémenter de mon côté.
  

Relativement à l'exemple du résultat d'OSM.org. Il n'emploie pas
une géométrie unique. Il affiche tous les objets de la relation
et c'est vite le fouillis, en plus de devoir être découpé pour
être intégré dans du geojson.

  

  
Voir ici : http://www.openstreetmap.org/relation/5430194

Je m'attends à récupérer une ligne toute simple
  sans les deux polygones aux extrémités. C'est la seule
  géométrie "simple" et représentative qu'on puisse
  exploiter sans faire appel à des FeatureCollections ou
  autre.


  


Et ça me semble très dur de
  trouver une méthode générique qui puisse faire
  cette synthèse parce qu'il semble qu'il y ait
  autant de possibilités que de cas :'(



François
  


  Le 22 août 2016 à 14:45,
Philippe Verdy 
a écrit :

  Le site web OSM le fait déjà
quand on "explore" une relation: ça
télécharge un jeu de données JSON permettant
le rendu vectoriel de l'objet sélectionné
par dessus le fond de carte. La Wikipédie
francophone le fait aussi sur ses cartes
(mais elle requête son propre serveur pour
obtenir aussi des POIs géolocalisés sur
Wikipédia ou des photos géolocalisées sur
Commons)
Attention en cas d'inclusion dans un
  script web : l'API ne doit pas surcharger
  le serveur interrogé (on a vu le problème
  ces jours-ci sur Overpass API avec des
  centaines de milliers de requêtes par
  heure au lieu de quelques 

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

2016-07-06 Thread Topographe Fou
 Bonjour,Merci pour ce premier retour.Pour le 1.2 en effet je voulais parler des codes INSEE du département et de celui de la région. Je partage également le point de vue que cela ne contient pas plus d'informations dans le cas des RD. Mais si on se place dans une logique d'arborescence alors il pourrait être pratique de faire des recherches ou filtres par région. Hiérarchiquement parlant entre le pays et le département il y a une région :). Il y a une solution peut-être la plus logique (voir après).Proposition 1.4 : network=FR:78 (cad c'est une route départementale des Yvelines en France) + is_in=FR:11:78 (cad c'est une relation dans le département des Yvelines, région IDF, en France). Is_in est pas mal utilisé aux EU, pour un statut assez vague.Proposition 1.5 : mettre les relations RD membre de la relation Département pour créer explicitement la hiérarchie + network=FR:78Ok pour l'avis sur le 2.Pour le 'operator' je le préciserai sur le Wiki au moment de faire la synthèse.  En ce qui me concerne cela sort de mon périmètre. LeTopographeFou  De:fl.infosrese...@gmail.comEnvoyé:6 juillet 2016 8:05 AMÀ:talk-fr@openstreetmap.orgRépondre à:talk-fr@openstreetmap.orgObjet:Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale  Hello,
Bonne initiative, ça va en effet permettre de significativement améliorer la qualité des données de routage, avec un bon impact sur les rendus routiers
Deux remarques pour amener de l'eau a ton moulin :
Point 1.2 : tu devais vouloir parler de l'INSEE région ? Inutile selon moi, c'est bien un réseau départemental. Si on veut l'INSEE région, on le trouve via l'INSEE du département 
Point 2.3 : En effet, il ne faut pas refonder inutilement l'info et cette solution de passer par network=* est la meilleure sur ce plan.
Autre chose : il faudrait utiliser operator=* pour indiquer l'exploitant, idéalement sur chaque segment de route, puisque l'exploitation des tronçons urbain peut être délégué aux villes.
A+
François
Le 6 juil. 2016 12:25 AM, "LeTopographeFou"  a écrit :
  


  
  
Bonjour,

J'ai attaqué un imposant chantier visant à améliorer la prise en
compte des Routes Départementales (RD) françaises dans OSM. Ce
chantier vise à :
Faire qu'il y ait une relation par RD par département (ex :
http://www.openstreetmap.org/relation/6335278)
  Vérifier et corrigé le tracé des RD
Le tout étant fait à la main (j'insiste sur le fait qu'il
  n'y a pas d'automate) en comparant les données OSM avec Route500.
  A ce jour j'ai fais les Yvelines et attaque l'Essonne. Aucune des
  RD n'avait de relation ad-hoc et certaines n'étaient carrément pas
  (ou incomplètement) référencées par leurs champ ref=*. Donc je les
  attaque une à une avec de belles trouvailles.

Pour le moment je mets 4 tags à chaque relations (cf.
  http://www.openstreetmap.org/relation/6335278) mais je ne trouve
  pas cela très optimal d'où deux points à vous soumettre :

Il faudrait en profiter pour mettre un tag 'network'. Pour
info les RN ont visiblement un tag 'network=FR:n-road'. Afin de
coller avec la logique utilisées aux EU j'ai deux propositions à
faire :Utiliser le code pays et le code INSEE du département (en
  l’occurrence cela ferait 'FR:78')Faire comme précédemment mais avec également le code INSEE
  du département (en l’occurrence cela ferait 'FR:11:78)
Utiliser le code ISO 3166-2 (en l’occurrence cela ferait
  'FR-78')
  Concernant le tag 'name' il y a des risques d'amalgames entre
deux départements. Est-il judicieux d'y mentionner le nom du
département ? Le hic est que, rigoureusement parlant, le nom
"officiel" est 'Route départementale 29' sans autre fioriture
  Exemple 1 : 'Route départementale 29 (Yvelines)' => clair
  et concis, facile à parser
Exemple 2 : 'Route départementale des Yvelines 29' => bofAutre solution : ne rien faire, se dire que l'ajout de
  'network' suffit et que si amalgame il y a c'est un problème à
  gérer par l'éditeur/l'app et non par le cartographe =>
  c'est ma solution préféré mais autant réfléchir avant d'aller
  plus loin.


A ce jour je ne vois pas de réponse ni dans les relations
  existantes ni sur le wiki. Qu'en pensez-vous ?

LeTopographeFou

  

___
Talk-fr mailing list
Talk-fr@openstreetmap.org