Re: [OSM-talk-fr] Moulinette pour ajouter "oneway:bicycle=no" ?
Le jeu. 7 févr. 2019 à 15:25, Florimond Berthoux < florimond.berth...@gmail.com> a écrit : > Le cas S1 est un exemple, ce qui prévaut ce sont les définitions des tags > et des attributs. > S'il faut documenter toutes les combinaisons de tags/attributs on n'a pas > finit. > Ben justement le wiki le permet et c'est le meilleur moyen pour que les données soient cohérentes. > Et c'est visiblement néfaste de mettre trop d'exemple, suffit d'un exemple > ambigüe comme pour le S1 pour avoir de longue discussion... > Pourquoi ambiguë, il est bien décrit dans le wiki avec les tags ad hoc. Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sensibiliser à OpenStreetMap - Dépliant OSM France
Le 2019-02-07 16:05, marc marc a écrit : Le 07.02.19 à 15:46, Jean-Marc Liotier a écrit : Polyligne (ouverte) il y a bien https://fr.wikipedia.org/wiki/Polyligne pour "ligne polygonale" mais : - qu'à mon avis la majorité des gens n'ont jamais entendu - vont mal comprendre (parce que poly=plusieurs donne l'impression qu'il y a plusieurs lignes alors que l'explication est que c'est une ligne composée d'un ou plusieurs segment) - qui me semble donc être une complication gratuite :) Le seule avantage serrait d'utiliser le même terme qu'en géomatique. mais je suis pas convaincu qu'on gagne à aligner du jardon pour parler avec le contributeur standard Ha ! je m'absente et voilà déjà cinq réponses qui rebondissent sur le terme de « chemin ». Vous avez raison évidemment, en voyant le terme de « ligne » utilisé par iD, ça a l'air beaucoup plus naturel, donc j'utiliserai maintenant plutôt ce terme. Merci pour toutes ces réponses ! ___ 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] Sensibiliser à OpenStreetMap - Dépliant OSM France
Le jeu. 7 févr. 2019 à 11:21, Rpnpif a écrit : > Bonjour, > > Le 6 février 2019, Eric a écrit : > > > Bonjour, > > > > J'ai eu à en faire un rapidement pour une présentation récente, si ça > peut > > aider... > > http://www.blueb.fr/osm/PresOSM.pdf (ou .docx) > > http://www.blueb.fr/osm/SlidesOSM.pdf(ou pptx) > > Merci pour ce travail très intéressant. > > Juste quelques petites remarques : > > Je traduirais « field papers » par « papier, crayon » si c'est bien le > sens. > FieldPapers fait référence à un outil en ligne qui permettait d'imprimer un fond de carte d'une zone pour ensuite servir de support à un relevé terrain. Cette fonction n'existe peut être plus... https://wiki.openstreetmap.org/wiki/Field_Papers > > « Pas de données nominatives », le tag operator sur les commerces ou > services est parfois ou souvent complété par une donnée nominative. > C'est interdit ? De même le nom d'une zone est nominatif par > définition ;). À moins que nominatives veuillent dire données > personnelles d'un individu, donc données « personnelles » (répétition). > > Exact, c'est pas limpide. L'idée est de ne pas faire apparaitre des noms de personnes n'ayant pas cherché à être public mais c'est à mieux définir. Compliqué quand on a droit à peu de mots « Pas de données ponctuelles dans le temps » : la plupart des données > évoluent dans le temps. Des routes se modifient et se créent, des noms > changent, des routes ou zones en travaux sont reportées (à condition de > suivre leur finalisation), des arbres disparaissent, etc. Donc c'est > une affirmation à nuancer. > D'accord aussi. Je pensais en mettant ca par exemple à de vieilles discussions du style "est-ce que je peux faire une relation pour identifier une étape du Tour de France vélo ?" C'est une question générale qui ne me semble pas faire consensus. Je > pense que l'on peut reporter une donnée temporaire si on est capable > soi-même ou avec l'aide de contributeur plus proche, et à terme, de la > faire évoluer jusqu'à un état soi-disant plus stable. Cela sous-entend > de suivre en quasi temps réel. C'est très utile pour le calcul > d'itinéraires. > > Je m'inspirerai de ce travail très utile. > -- > Alain Rpnpif > > ___ > 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] Sensibiliser à OpenStreetMap - Dépliant OSM France
Le 07.02.19 à 15:46, Jean-Marc Liotier a écrit : > Polyligne (ouverte) il y a bien https://fr.wikipedia.org/wiki/Polyligne pour "ligne polygonale" mais : - qu'à mon avis la majorité des gens n'ont jamais entendu - vont mal comprendre (parce que poly=plusieurs donne l'impression qu'il y a plusieurs lignes alors que l'explication est que c'est une ligne composée d'un ou plusieurs segment) - qui me semble donc être une complication gratuite :) Le seule avantage serrait d'utiliser le même terme qu'en géomatique. mais je suis pas convaincu qu'on gagne à aligner du jardon pour parler avec le contributeur standard ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sensibiliser à OpenStreetMap - Dépliant OSM France
Polyligne est exact mais peu usité. Ligne (brisée ou droite) est compréhensible du commun des mortels. Pour l'autre remarque : sa _ou ses_ valeurs ! ;-) Jean-Yvon Le 07/02/2019 à 15:46, Jean-Marc Liotier - j...@liotier.org a écrit : On 2019-02-07 15:11, marc marc wrote: est-ce que way ne devrait-il pas être traduit par trait ou ligne ? Polyligne (ouverte) ou polygone (fermé) de même avec node, au lieu de nœud (qui en français sous-entend qu'il y a un lien entre plusieurs chose), le mot point me semble plus adapté. Dans mes vieux souvenirs de noviciat, le mot "noeud" pour ce qui était pour moi un point semblait une complication gratuite. Donc, pour un document de vulgarisation, le mot "point" est à mon avis mieux adapté. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sensibiliser à OpenStreetMap - Dépliant OSM France
On Thu, February 7, 2019 11:46 am, Julien Lepiller wrote: > > Si on en est là, moi je traduis « tag » par « attribut » et « way » > par « chemin » ;) C'est ce que j'utilise toujours lorsque je parle d'Openstreetmap en Français: un attribut, formé d'une clé et de sa valeur. Je ne devrais pas ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sensibiliser à OpenStreetMap - Dépliant OSM France
On 2019-02-07 15:11, marc marc wrote: > > est-ce que way ne devrait-il pas être traduit par trait ou ligne ? Polyligne (ouverte) ou polygone (fermé) > de même avec node, au lieu de nœud (qui en français sous-entend qu'il y > a un lien entre plusieurs chose), le mot point me semble plus adapté. Dans mes vieux souvenirs de noviciat, le mot "noeud" pour ce qui était pour moi un point semblait une complication gratuite. Donc, pour un document de vulgarisation, le mot "point" est à mon avis mieux adapté. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Moulinette pour ajouter "oneway:bicycle=no" ?
Le cas S1 est un exemple, ce qui prévaut ce sont les définitions des tags et des attributs. S'il faut documenter toutes les combinaisons de tags/attributs on n'a pas finit. Et c'est visiblement néfaste de mettre trop d'exemple, suffit d'un exemple ambigüe comme pour le S1 pour avoir de longue discussion... Après, à part pour le cas bizarre cycleway:right=opposite, je continuerai à utiliser cycleway=opposite par défaut. Le jeu. 7 févr. 2019 à 13:01, Romain MEHUT a écrit : > Phyks wrote > > 2) La page wiki en anglais utilise pleinement les cycleway:left/right > > quand la page en français se limite principalement à cycleway. Ne > > devrait-on pas s'aligner sur la page en anglais pour encourager à > > l'utilisation de cycleway:left/right ? > > Sauf que dans le wiki, même en anglais, la valeur "opposite" n'est pas > documenté pour "cycleway:left/right". Et j'insiste encore, le tag > "cycleway:left/right" n'est pas proposé pour le cas S1 proposé par Shoreh > qui a lancé ce sujet. S'il doit y avoir une évolution de tag pour ce cas de > figure, il faudra passer au préalable par un accord de l'ensemble de la > communauté OSM comme l'a rappelé précédemment Antoine. > > Romain > > > > > -- > 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 > -- Florimond Berthoux ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sensibiliser à OpenStreetMap - Dépliant OSM France
Le 07.02.19 à 11:46, Julien Lepiller a écrit : > « way » par « chemin » ;) c'est pas l'idéal quand même d'en arriver à écrire "pour ajouter un bâtiment, faite un chemin fermé" ou "pour ajouter une piste cyclable, faites un chemin" est-ce que way ne devrait-il pas être traduit par trait ou ligne ? de même avec node, au lieu de nœud (qui en français sous-entend qu'il y a un lien entre plusieurs chose), le mot point me semble plus adapté. > une route bloquée pour > cause de travaux pendant quelques jours, sans que le tracé ou le propriétés > de la route ne doivent changer. > Dans le premier cas, cela peut demander de la réactivité pour rétablir > l'ancienne donnée et il n'est pas forcément très utile de changer la > donnée de manière temporaire. je partage ton avis. soit on sait être hyper réactif, et on pourrait imaginer d'ajouter un point barrier=* si les travaux vont durée "un certains temps" soit on fait mieux de rien faire parce qu'on risque d'être + longtemps faux que juste. > Le deuxième, c'est un local commercial > qui abritait un magasin de vêtements et qui change de propriétaire, pour > devenir un magasin d'instruments de musique. Le local est en travaux pour > refaire la décoration. > Dans le deuxième cas, ça n'a pas de sens de laisser la donnée même > si l'état actuel est temporaire : l'ancien magasin ne reviendra pas, > inutile donc de le laisser. je suis 'accord avec toi. pour ma part shop=vaccant est le mieux adapté : - c'est clair que l'occupant précédent n'y est plus - c'est clair que l'occupant suivant n'est pas encore actif - on garde l'historique ce qui peux parfois éviter des ping-pong pour des modifs de salon (qlq quivoit sur une image mappilary l’existence du commerce ayant entre temps fermé) je me demande même si StreetComplete n'a pas une quête pour demander si le lieu est rouvert après un certain délais. > laisser une note le soucis c'est qu'il y a bcp trop de peu de monde qui traite les notes, en plus d'être inaccessible à certain outil (la personne avec StreetComplete pourrait éventuellement compléter la note s'il y a une question mais ne pourra pas recréer un magasin si le précédent a été supprimé) > mettent à jour que rarement leur carte (osmand, ...) oui c'est un soucis, même en étant très réactif, c'est inévitable de faire parfois une modif le lendemain de la maj de la carte hors ligne et d'avoir donc des cartes hors ligne "incorrecte" pendant un moi en même temps il y a des utilisateurs maps.me qui ont parfois des cartes de 2 ans :) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sensibiliser à OpenStreetMap - Dépliant OSM France
Le 2019-02-07 12:13, Rpnpif a écrit : Le 7 février 2019, Julien Lepiller a écrit : > Je traduirais « field papers » par « papier, crayon » si c'est bien le > sens. Si on en est là, moi je traduis « tag » par « attribut » et « way » par « chemin » ;) Non, parce que ce sont des termes techniques utilisés qu'il faut connaître (après explication) pour utiliser ID ou JOSM. Faisant des micro-formations à des novices pas geek pour un sou, je peux vous dire que le minimum de jargon est important, sinon ils partent. Je parle d'expérience. Je ne comprends pas, iD me dit bien par exemple « Tous les attributs (6) » sur un nœud que je sélectionne. Par contre il parle de « ligne » et pas de « chemin », ce qui est peut-être plus exact. Je ne peux pas vérifier dans JOSM pour le moment, mais ça serait dommage qu'il y ait incohérence entre les deux éditeurs. Pour le reste, je suis d'accord, sauf qu'Osmand a un module qui s'appelle Osmand Live qui met à jour la carte en quasi temps réel (même s'il a quelques petits bogues sur le calcul d'itinéraires). Oups, pas taper, j'ai écrit en français, j'ai écrit bogues :)). Explication : je milite pour l'absence de jargon, facteur de fracture sociale, d'entre-soi et anti-éducation populaire. Je crois que je comprends la motivation, mais en quoi « tag » est-il moins du jargon que « attribut » ? Inversement, pourquoi « nœud » ou « point » et pas « node » ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Moulinette pour ajouter "oneway:bicycle=no" ?
Phyks wrote > 2) La page wiki en anglais utilise pleinement les cycleway:left/right > quand la page en français se limite principalement à cycleway. Ne > devrait-on pas s'aligner sur la page en anglais pour encourager à > l'utilisation de cycleway:left/right ? Sauf que dans le wiki, même en anglais, la valeur "opposite" n'est pas documenté pour "cycleway:left/right". Et j'insiste encore, le tag "cycleway:left/right" n'est pas proposé pour le cas S1 proposé par Shoreh qui a lancé ce sujet. S'il doit y avoir une évolution de tag pour ce cas de figure, il faudra passer au préalable par un accord de l'ensemble de la communauté OSM comme l'a rappelé précédemment Antoine. Romain -- 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
Re: [OSM-talk-fr] Sensibiliser à OpenStreetMap - Dépliant OSM France
Le 7 février 2019, Julien Lepiller a écrit : > > Je traduirais « field papers » par « papier, crayon » si c'est bien le > > sens. > > Si on en est là, moi je traduis « tag » par « attribut » et « way » > par « chemin » ;) Non, parce que ce sont des termes techniques utilisés qu'il faut connaître (après explication) pour utiliser ID ou JOSM. Faisant des micro-formations à des novices pas geek pour un sou, je peux vous dire que le minimum de jargon est important, sinon ils partent. Je parle d'expérience. Pour le reste, je suis d'accord, sauf qu'Osmand a un module qui s'appelle Osmand Live qui met à jour la carte en quasi temps réel (même s'il a quelques petits bogues sur le calcul d'itinéraires). Oups, pas taper, j'ai écrit en français, j'ai écrit bogues :)). Explication : je milite pour l'absence de jargon, facteur de fracture sociale, d'entre-soi et anti-éducation populaire. -- Alain Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sensibiliser à OpenStreetMap - Dépliant OSM France
Le 2019-02-07 11:21, Rpnpif a écrit : Bonjour, Le 6 février 2019, Eric a écrit : Bonjour, J'ai eu à en faire un rapidement pour une présentation récente, si ça peut aider... http://www.blueb.fr/osm/PresOSM.pdf (ou .docx) http://www.blueb.fr/osm/SlidesOSM.pdf(ou pptx) Merci pour ce travail très intéressant. Juste quelques petites remarques : Je traduirais « field papers » par « papier, crayon » si c'est bien le sens. Si on en est là, moi je traduis « tag » par « attribut » et « way » par « chemin » ;) « Pas de données nominatives », le tag operator sur les commerces ou services est parfois ou souvent complété par une donnée nominative. C'est interdit ? De même le nom d'une zone est nominatif par définition ;). À moins que nominatives veuillent dire données personnelles d'un individu, donc données « personnelles » (répétition). « Pas de données ponctuelles dans le temps » : la plupart des données évoluent dans le temps. Des routes se modifient et se créent, des noms changent, des routes ou zones en travaux sont reportées (à condition de suivre leur finalisation), des arbres disparaissent, etc. Donc c'est une affirmation à nuancer. C'est une question générale qui ne me semble pas faire consensus. Je pense que l'on peut reporter une donnée temporaire si on est capable soi-même ou avec l'aide de contributeur plus proche, et à terme, de la faire évoluer jusqu'à un état soi-disant plus stable. Cela sous-entend de suivre en quasi temps réel. C'est très utile pour le calcul d'itinéraires. À mon avis il faut différencier deux cas : la donnée est bonne en général mais il y a actuellement un changement d'état temporaire (par exemple des travaux bloquent une route pour quelques jours, mais ensuite il n'est pas prévu de changer la rue) et la donnée est incorrecte mais on est en transition (par exemple, un local commercial en travaux avant l'ouverture d'un nouveau magasin). Je vous propose deux exemple : le premier, c'est une route bloquée pour cause de travaux pendant quelques jours, sans que le tracé ou le propriétés de la route ne doivent changer. Le deuxième, c'est un local commercial qui abritait un magasin de vêtements et qui change de propriétaire, pour devenir un magasin d'instruments de musique. Le local est en travaux pour refaire la décoration. Dans le premier cas, cela peut demander de la réactivité pour rétablir l'ancienne donnée et il n'est pas forcément très utile de changer la donnée de manière temporaire. Dans le deuxième cas, ça n'a pas de sens de laisser la donnée même si l'état actuel est temporaire : l'ancien magasin ne reviendra pas, inutile donc de le laisser. Si on ne peut pas surveiller l'arrivée du nouveau magasin, on peut au moins laisser une note, mais je ne crois pas qu'il soit nécessaire de pouvoir être réactif dans ce cas. Donc, on peut mettre à jour dans les cas de transition (l'ancienne donnée est fausse et le restera), mais pas les cas de modifications temporaires (l'ancienne donnée n'est actuellement pas valide, mais le sera de nouveau un peu plus tard), sauf si on peut s'engager à maintenir la donnée en question ou que le temporaire est particulièrement long. Il faut penser aussi aux utilisations qui ne mettent à jour que rarement leur carte (osmand, ...) et qui risquent de voir ces changements pendant plus de temps que nécessaire. Mais on ne cartographie pas pour le rendu, n'est-ce pas ? Finalement, pour dire tout ça en une phrase, c'est pas facile ;) Je m'inspirerai de ce travail très utile. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sensibiliser à OpenStreetMap - Dépliant OSM France
Bonjour, Le 6 février 2019, Eric a écrit : > Bonjour, > > J'ai eu à en faire un rapidement pour une présentation récente, si ça peut > aider... > http://www.blueb.fr/osm/PresOSM.pdf (ou .docx) > http://www.blueb.fr/osm/SlidesOSM.pdf(ou pptx) Merci pour ce travail très intéressant. Juste quelques petites remarques : Je traduirais « field papers » par « papier, crayon » si c'est bien le sens. « Pas de données nominatives », le tag operator sur les commerces ou services est parfois ou souvent complété par une donnée nominative. C'est interdit ? De même le nom d'une zone est nominatif par définition ;). À moins que nominatives veuillent dire données personnelles d'un individu, donc données « personnelles » (répétition). « Pas de données ponctuelles dans le temps » : la plupart des données évoluent dans le temps. Des routes se modifient et se créent, des noms changent, des routes ou zones en travaux sont reportées (à condition de suivre leur finalisation), des arbres disparaissent, etc. Donc c'est une affirmation à nuancer. C'est une question générale qui ne me semble pas faire consensus. Je pense que l'on peut reporter une donnée temporaire si on est capable soi-même ou avec l'aide de contributeur plus proche, et à terme, de la faire évoluer jusqu'à un état soi-disant plus stable. Cela sous-entend de suivre en quasi temps réel. C'est très utile pour le calcul d'itinéraires. Je m'inspirerai de ce travail très utile. -- Alain Rpnpif ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Ingénieur le jour, cartographe la nuit : qui sont ces bénévoles qui font vivre Waze ou Google Maps
Le 07/02/2019 à 08:17, Vincent Bergeot a écrit : Le 07/02/2019 à 06:52, Vincent Bergeot a écrit : Bonjour Le 6 février 2019 22:26:20 GMT+01:00, marc marc a écrit : le projet européen dont le nom m’échappe. OpenTraffic, il y a une conférence de Frédéric le dimanche matin du sotm 2018 avec le lien sur la présentation :) https://nextcloud.openstreetmap.fr/index.php/s/KnSA5Pei9re4a89 Bonne journée À noter que le projet n'a rien d'européen. Il était porté par la WorldBank et développé par Mapzen. Perso, j'ai n'ai pas encore avancé là dessus. mais c'est toujours dans mes cartons (quand on aura réussit à stabiliser Osmose, aide bien venu). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Crawler sur les horaires d'ouverture
Bonjour, entièrement d'accord avec Marc. il y a une différence entre un site web / une page FB du POI publiant ses horaires (y compris les pages des chaînes) et un site dont le but est notamment de regrouper les horaires, comme les Pages Jaunes ou Yelp. FB ne fait que mettre à disposition un espace de stockage, il n'y a pas de service lié aux horaires d'ouverture (et FB pompe toutes les données pour valoriser sa pub : son modèle économique ne dépend nullement des horaires d'ouverture : si le POI publie ses horaires, c'est juste un plus). Oui Mapzen est la bonne piste. Jean-Yvon Le 07/02/2019 à 00:45, EpicKiwi - m...@epickiwi.fr a écrit : Mais dans ce cas, Facebook fait aussi un travail de stockage sur les horaires d'ouverture... On févr. 6 2019, at 6:26 pm, marc marc wrote: Le 06.02.19 à 23:50, EpicKiwi a écrit : Il semble aussi que les informations de POI sur Yelp ou TripAdvisor proviennent aussi du POI lui même donc il serait possible d'extraire de ce genre de sources... non parce que yelp a fait une base de donnée (= du travail pour regrouper toutes ces infos) et cela pose les mêmes soucis que recopier les pages jaunes ___ 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
