[OSM-talk-fr] Données Overture Maps
Overture Maps est une fondation dirigée par Meta, Microsoft, Amazon et TomTom dont le but est de créer une liste de POIs et assimilés qui ont été vérifiés et sont prêts à être utilisés en production. https://www.cnbc.com/2023/07/26/meta-microsoft-amazon-join-overture-maps-to-vie-with-apple-google.html Bref, ils ne font pas confiance aux données d'OpenStreetMap. Ils comptent aggréger des données de plusieurs sources dont des données des membres de la fondation (donc normalement ils ne vont pas juste dupliquer les données OSM). Ce qui compte pour nous c'est que leurs jeux de données sont sous licence ODBL, évidemment compatible avec OSM, et CDLA-Permissive v2. https://overturemaps.org/download/ Places Theme CDLA Permissive v2.0 Buildings Theme ODBL Transportation Theme ODBL Administrative Boundaries Theme CDLA Permissive v2.0 Concernant CDLA-Permissive v2, l'OSM Foundation avait trouvé que la v1 était globalement compatible avec ODBL et cela semble être encore plus clairement le cas pour la v2 : https://wiki.osmfoundation.org/wiki/Licence/Licence_Compatibility#Linux_Foundation_CDLA_Permissive Donc la bonne nouvelle c'est qu'OSM devrait pouvoir intégrer les jeux de données d'Overture... après validation bien sûr (via Osmose par exemple). -- Francois Gouget http://fgouget.free.fr/ E-Voting: Those who cast the votes decide nothing. Those who count the votes decide everything. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Erreurs Osmose pour les transformateurs sur poteau
Osmose génère plein d'erreurs pour les transformateurs sur poteaux : https://osmose.openstreetmap.fr/fr/map/#item=9001=12=45.9717=0.7335=1%2C2%2C3 attribut manquant : substation sans power=substation ou pipeline=substation Ceci parce que ces poteaux sont taggés avec : power = pole substation = minor_distribution transformer = main Effectivement la page power=pole indique qu'il faudrait les tagger différemment : https://wiki.openstreetmap.org/wiki/Tag:power%3Dpole#Design power = pole transformer = distribution (mais pas substation = *) J'ai l'impression que cela fait suite à la proposition suivante qui a été adoptée : https://wiki.openstreetmap.org/wiki/Proposal:Substation_nodes_extension Y a-t-il eu un retournement de situation ou est-ce juste que tout n'a pas été mis à jour ? -- Francois Gouget http://fgouget.free.fr/ Computers are like airconditioners They stop working properly if you open WINDOWS ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sculpture d'enfant sur passage piéton
On Fri, 24 Feb 2023, Philippe Verdy wrote: > A mon avis, le but n'est pas artistique ni touristique > (tourism=artwork) mais plutôt pédagogique : c'est un signal de > prudence envoyé aux usagers de la route, un peu plus sympathique qu'un > bête panneau "attention, école" ou le simple marquage au sol d'un > passage piéton. > > Toutefois on ne peut pas en mettre partout, car c'est aussi un > obstacle, même si c'est sur un trottoir assez large. Peut-être que cela devrait être un nouveau type de traffic_calming ? https://wiki.openstreetmap.org/wiki/FR:Key:traffic_calming Bien que dans ce cas le dispositif ne soit pas vraiment "sur la route". -- Francois Gouget http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, it's computer science. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Accessibilité d'une ville : recommandations
On Wed, 7 Dec 2022, Marc_marc wrote: > Le 07.12.22 à 17:04, Daniel Garcia a écrit : > > j'ai cherché "mediatheque" > > > Je pense qu'une bonne partie des problèmes pourrait être résolue en > > supprimant tout résultat qui ne soit pas dans la ville > > c'est pour cela que je te proposais de faire mediatheque, ville :) > mais mediathèque n'est pas un bon exemple pour commencer vu l'absence de tag > précis dans osm pour cela fait des tests avec bibliothèque Je suis assez d'accord avec Daniel que les recherches dans OsmAnd sont inutilisables. Par exemple je cherche "Lyon" et j'obtiens des "Rue de Lyon", "Route de Lyon", "Route de Paris à Lyon", etc, etc, etc. 89 résultats en tout mais la ville de Lyon ? Non. Inconnue au bataillon. Ou alors il faut élargir le cercle de recherche. Si je cherche "bibliothèque, Lyon" (avec les accents), c'est pas mieux : en première page il me sort "Place de la Bibliothèque, Metz", en deuxième "Rue de la Bibliothèque, Besançon" ! C'est dire si le rayon de recherche est déjà large. Mais rien à Lyon (ou alors, vu la taille de l'ascenseur peut-être en page 400). Quitte à ignorer la ville que j'ai spécifié il pourrait au moins commencer par les bibliothèques de ma ville, mais elles ne sont qu'en page 3 ! Pas mieux avec "mairie, lyon". Donc pour planifier un trajet, si on n'est pas capable de trouver sa destination sur la carte de visu, c'est même pas la peine d'y penser ! Dans le temps OsmAnd avait un dialogue où on pouvait spécifier la ville, la voie, le numéro. C'était pas terrible, laborieux et pas au goût du jour, mais dans mes souvenirs au moins il y avait moyen de s'en sortir. Bref. À revoir. -- Francois Gouget http://fgouget.free.fr/ Research is the transformation of money to knowledge. Innovation is the transformation of knowledge to money. -- Dr. Hans Meixner ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose perd des corrections
On Thu, 21 Jul 2022, Frédéric Rodrigo wrote: [...] > Le conseil est d’envoyer plus souvent. C'est ce que j'ai fait hier soir. Résultat : j'ai perdu des changesets qui devaient avoir moins de 20 modifications ce qui n'est franchement pas beaucoup quand on corrige des addr:street. Vu que dans mon estimation il y a au moins 30% de chance que les modifications soient perdues, Osmose devrait afficher un avertissement recommandant de ne pas l'utiliser. Pas la peine de faire perdre leur temps aux contributeurs. -- Francois Gouget http://fgouget.free.fr/ Theory is where you know everything but nothing works. Practice is where everything works but nobody knows why. Sometimes they go hand in hand: nothing works and nobody knows why. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Osmose perd des corrections
J'ai l'impressions que cela fait quelques semaines qu'Osmose perd des changements. Je n'ai pas noté de problème lorsque je fais un changement et que je le sauve immédiatement. Par contre j'ai fait quelques chanegsets de 40 à 150 corrections qui ne sont jamais apparues dans ma liste de changesets. Et pourtant je n'ai eu aucun message d'erreur lors de la sauvegarde. Par exemple ce soir : * J'ai fait quelques corrections dans iD à Saint-Georges-de-Rex. https://www.openstreetmap.org/changeset/123867221 * Puis j'ai fait 47 corrections toponymiques et orthographiques directement dans Osmose à la Réunion. * Puis j'ai fait une correction toponymique directement dans Osmose, toujours à la Réunion. https://www.openstreetmap.org/changeset/123867502 Dans mon historique de changesets aucune trace du changeset du milieu. Avec un peu de chance les modifications ont été sauvegardées mais ne m'ont pas été attribuées ce qui serait un moindre mal. Mais je me souviens avoir corrigé un "Chemin des Pelicans" à Saint-Joseph qui je pense était ce noeud : https://www.openstreetmap.org/node/7605262476 Or aucune trace de correction (accent dans Pélicans). De plus la semaine dernière il me semble bien avoir refait des corrections que j'avais déjà faites. Mais comme je n'avais pas noté la liste des noeuds corrigés la première fois difficile d'être sûr. Du coup je n'ai pas l'impression que ce c'est lié à l'heure de la sauvegarde mais plutôt que c'est lié à la taille du changeset, la durée d'édition, ou à d'éventuels conflits (probabilité croissante avec la taille du changeset mais je doute un peu). Ouvrir iD à partir d'Osmose nécessite souvent de se reconnecter ce qui me paraît louche mais il n'y a peut-être pas de rapport. Quelqu'un sait-il ce qui se passe ? Navigateur : Firefox 102.0.1 (64 bits) / Debian 11 -- Francois Gouget http://fgouget.free.fr/ A particle is an irreducible representation of the Poincaré Group - Eugene Wigner ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] HTTP 502 sur Volta
Depuis le week-end dernier (environ, 2022-04-16) la couche Volta ne semble plus fonctionner. En testant dans josm aujourd'hui je vois qu'il se prend plein d'erreurs "502 Bad Gateway" : 2022-04-24 16:10:38.114 INFOS: GET http://a.tile.openstreetmap.fr/volta/17/65076/45100.png -> HTTP/1.1 502 (14 ms; 157 B) Je suppose que ceci explique cela... -- Francois Gouget http://fgouget.free.fr/ f u kn rd ts, ur wy 2 gky 4 ur wn gd. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Dégradations à annuler
Je suis tombé sur un groupe de changesets douteux : https://www.openstreetmap.org/changeset/103961825 https://www.openstreetmap.org/changeset/103961280 Ils ajoutent des bureaux Google France, Microsoft France et Samsung France dans une petite rue de Saint-Émilion. Il se trouve que leur auteur, joyeuxbernard687, a été banni pour 9 ans encore. Mais les changesets ci-dessus n'ont pas été annulés. Comme je ne sais pas faire de revert si je m'y colle ça ne sera probablement pas bien fait. Du coup quelqu'un pourrait-il se porter volontaire pour annuler les changesets ci-dessus ? J'ai l'impression que la plupart de ses autres changesets (il n'y en a que 20) ont été annulés manuellement (pas via un revert). -- Francois Gouget http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [OSM-Talk-fr] tagger les dark store
On Sat, 26 Mar 2022, Florian LAINEZ wrote: > > > > warehouse=local pour distinguer des plateformes logistiques livrant sur > > une région / un pays ? > > Là on commence à parler ! > > En marking il existe un concept de "zone de chalandise" qui est l'aire > couverte par la livraison ou le lieu d'habitation des clients. > Du coup, peut-être *target=local;regional;national;international* ? target > <https://wiki.openstreetmap.org/wiki/Key:target> étant déjà utilisé sur les > ambassades pour désigner le pays cible. > Néanmoins target n'est pas très spécifique, peut être : > - catchment_area (qui est la traduction de zone de chalandise) > - range (mon choix préféré) > - reach > - scope > > Il existe aussi visibility > <https://wiki.openstreetmap.org/wiki/FR:Key:visibility> pour panneaux > d'affichage : visibilty=house;street;area qui est similaire mais pas > applicable en l'état. Il y a aussi map_size qui me semble un peu similaire et donc pourrait peut-être amener à une uniformisation après renommage. map_size=* - Quelle est la zone couverte par la carte ? map_size=site | city | landscape | region https://wiki.openstreetmap.org/wiki/Tag:information%3Dmap#map_size -- Francois Gouget http://fgouget.free.fr/ Sufficently advanced incompetence is indistinguishable from malice. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] un début de OSM - mon commerce
On Thu, 17 Dec 2020, Stéphane Péneau wrote: [...] > Autre solution intermédiaire : > > Afficher les horaires des différents services (Osm, google, pages > jaunes, etc...). C'est probable que ça intéresse les commerçants de > vérifier depuis une seule page que tout est à jour. Et dans un premier > temps, depuis ce site il ne sera possible que de modifier les horaires Osm. Sauf que "afficher les horaires des différents services" suppose d'utiliser les données de ces services. Encore faut-il que ces derniers autorisent ce type d'utilisation via une license adéquate. Pas de problème pour OSM, mais pour les autres ça reste à voir... -- Francois Gouget http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] un début de OSM - mon commerce
On Thu, 17 Dec 2020, Jacques Lavignotte wrote: > > > Le 17/12/2020 à 05:12, Francois Gouget a écrit : > > > d'horaire etc dans une base de données séparée sous une license plus > > permissive et qui servira à alimenter, entre autres, OSM. > > C'est le principe même du blanchiment d'argent ;) À part que cela rien à voir, ni légalement, ni moralement. -- Francois Gouget http://fgouget.free.fr/ question = ( to ) ? be : ! be; -- Wm. Shakespeare___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] un début de OSM - mon commerce
On Wed, 16 Dec 2020, Florian LAINEZ wrote: > Bonjour François, > Il existe une bonne raison pour laquelle aucun outil n'existe aujourd'hui > pour mettre à jour les données sur tous ces sites en une seule fois. > Il est possible d'élaborer longuement sur le sujet mais pour faire court : > la licence OdbL a été créée pour protéger le projet OSM des prédateurs qui > pourraient être tentés de piller les données sans reverser en retour. C'est pour cela que je ne propose pas de prendre les données OSM pour les mettre sur les autres sites mais de mettre *uniquement* les données d'horaire etc dans une base de données séparée sous une license plus permissive et qui servira à alimenter, entre autres, OSM. *KO* : Commerçants -> OSM -> "Site horaires" -> Google, Pages Jaunes, etc. *OK* : Commerçants -> "Site horaires"-> OSM, Google, Pages Jaunes, etc. Donc pas de problème de license. > A partir de là, mon analyse personnelle est que Google ne jouera > jamais le jeu D'accord. Pour les horaires on peut ajouter Facebook dans cette catégorie. > et que dans la situation actuelle, la totalité des autres acteurs > peut potentiellement basculer de notre côté par anti-Googleulisme. D'une part, spécifiquement pour ce qui est des informations dynamiques type horaires, j'en doute. Déjà il manque les deux poids lourds : Google et Facebook. Et puis même si c'est le cas, comment les données arriveraient-elles dans OSM ? Mettons que Yahoo utilise les données OSM. Si un commerçant met à jour ses horaires d'ouvertures sur Yahoo va-t-on autoriser les Pages Jaunes à faire une mise à jour automatisée d'OSM ? Quid des règles sur les éditions de masse ? Et on laisse n'importe quel autre site faire de même ? Enfin la logique des commerçants n'est pas celle d'OSM : ce qu'ils veulent c'est diffuser leurs informations aussi largement que possible, pas promouvoir le logiciel libre. Un site / outil qui n'alimente qu'OSM n'intéressera que les utilisateurs d'OSM. Un site / outil qui peut potentielement alimenter tous les sites majeurs peut intéresser aussi tous les commerçants ce qui est la meilleure façon de garantir des données à jour. Je suppose que le point de vue dépend si on considère que sans les champs opening_hours, phone, website, facebook et quelques autres [1] OSM perd une part importante de sa valeur. * Si oui alors ces données doivent être dans OSM et aussi sous license ODBL. * Si non alors ces données pourraient très bien se trouver dans une autre base de données qui serait fusionnée dynamiquement avec les données OSM ; et être sous une autre license compatible avec le logiciel libre. [1] Périmètre à définir et sur lequel il y a probablement matière à débattre. D'emblée j'exclus les données de géolocalisation bien que les commerçants ne seraient peut-être pas d'accord. -- Francois Gouget http://fgouget.free.fr/ If you think the whole world revolves around you, quit staring at the GPS display while driving.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] un début de OSM - mon commerce
On Mon, 14 Dec 2020, Baptiste Lemoine - Cipher Bliss wrote: > Bonjour, > hier avec quelques contributeurs sur le canal osm-fr telegram/riot on > s'est lancés dans l'ébauche d'une version OSM pour que les commerçants > puissent renseigner des informations de leur commerce, un peu à la > façon ça reste ouvert, inspiré par onosm.org. Juste mes 2 euro-cents : Faire un site qui simplifie la mise à jour des données OSM des commerces c'est bien. Faire un outil / site qui permet de mettre à jour les données d'OSM, Google, Les Pages Jaunes, Yahoo et tous les autres d'un coup c'est mieux. C'est pour cela que je pense que les données entrées via cet outil ne devraient pas être sous ODBL mais sous une license plus permissive permettant à toutes les tierces parties de venir y piocher. [1] Sinon comme les commerçants ont autre chose à faire que d'aller mettre à jour 36000 sites, il ne le feront que dans celui qui a la plus grosse part de marché, c'est à dire Facebook [3] et à la rigueur Google. [1] On pourrait aussi prendre le problème à l'envers et faire une application (traduction en language moderne : une app Android / iOS) qui aille mettre à jour tous ces sites, dont OSM. Du coup pas de site / base de données supplémentaire et pas de problème de license de ces données. Mais ça nécessite que les utilisateurs d'une part créent un compte sur chaque site qu'ils veulent mettre à jour [2], et d'autre part fournissent leurs identifiants à cette application. [2] Je suppose ici que certains sites n'autorisent que le 'propriétaire' du commerce à faire ce type de mise à jour. Alors qu'ils seraient peut-être plus enclins à siphoner les données d'une source commune, au moins pour les commerces sans propriétaire déclaré ; ou si le propriétaire a coché une case autorisant ce type de mise à jour (un peu comme Google Mail peut être configuré pour 'unifier' plusieurs comptes mail). [3] Pourquoi Facebook ? Parce que d'après mon expérience avec les commerces locaux (donc hors chaines), la plupart n'ont qu'une page Facebook, voire ont abandonné leur site web pour ne garder que Facebook. Et s'il y a un endroit où ils signaleront leurs changements d'horaires, de numéro de téléphone ou autre c'est bien là. -- Francois Gouget http://fgouget.free.fr/ A polar bear is a cartesian bear after a coordinate transform.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Projet du mois Décembre
On Sun, 22 Nov 2020, Yves P. wrote: [...] > François G, tes liens sont tous identiques Argh. Saleté de Firefox. Avec leur auto-sélection bizarre dans la barre d'adresse il rate régulièrement mes Ctrl+C. * Alors pour les stades j'avais Clairefontaine en fait. https://osmose.openstreetmap.fr/fr/map/#item=8390%2C8391%2C8392=17=48.615817=1.924324 Mais ça s'explique finalement. Ça veut dire qu'il faut aller sur place (ou avoir des photos au sol) pour vérifier quel mat porte effectivement les antennes (ou alors il faut se fier aux équipements pied du mat mais ça ne me paraît pas très fiable). * Et pour la SNCF : https://osmose.openstreetmap.fr/fr/map/#item=8390%2C8391%2C8392=17=48.64552=1.836347 * Et la décheterie de Rambouillet et ses supports containerisés : https://osmose.openstreetmap.fr/fr/map/#item=8390%2C8391%2C8392=17=48.657627=1.838976 -- Francois Gouget http://fgouget.free.fr/ tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY___ 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")
On Wed, 18 Nov 2020, Florian LAINEZ wrote: [...] > La place est libre pour un autre pdm si quelqu'un souhaite s'emparer de > cette opportunité. Je suggèrerais bien un projet autour des supports radio. https://osmose.openstreetmap.fr/fr/map/#item=8390%2C8391%2C8392=10=47.607=1.571 Les pylones sont de bonne taille et donc se voient bien sur les photos aériennes du moins à la campagne. En ville il n'y a pas vraiment de pylone et il y a tellement de structures parasite qu'on a beaucoup plus de mal à repérer les antennes. Mais même si on exclu les villes il y a de quoi faire. C'est particulièrement adapté à la saison : * On peut le faire de chez soi ce qui est pratique en ces temps de confinement (même si peut-être en décembre...) * Pas besoin de mettre le nez. Vu la température en décembre c'est un plus. C'est comme la raclette, un plat d'hiver je vous dis ! * Avec le lancement de la 5G c'est dans l'air du temps. Bon, coté défauts : * J'ai cartographié une douzaine de support à la campagne et les données Osmose collaient bien. Mais en regardant ce soir j'ai trouvé que la concentration de supports radio fantomes autour des stades est assez bizarre : https://osmose.openstreetmap.fr/fr/map/#item=8390%2C8391%2C8392=18=48.784162=2.326757 https://osmose.openstreetmap.fr/fr/map/#item=8390%2C8391%2C8392=18=48.784162=2.326757 * Les supports SNCF semblent un peu décalés, pas évident à identifier, et surtout je n'en trouve que deux sur trois : https://osmose.openstreetmap.fr/fr/map/#item=8390%2C8391%2C8392=18=48.784162=2.326757 * Les données OSM ne me semblent pas toujours terribles. Par exemple ces supports plantés au milieu des containers de cette décheterie alors qu'il y a un support TDF juste à coté. Support mutualisé qui a poussé le contributeur à mettre un support par opérateur ? https://osmose.openstreetmap.fr/fr/map/#item=8390%2C8391%2C8392=18=48.784162=2.326757 * Les opérateurs n'arrêtent pas d'ajouter des supports donc il y en a forcément un certain nombre qui ne seront pas sur les photos aériennes. Là c'est plus compliqué. * C'est de l'infrastructure. Ça ne motive pas forcément les foules. * Je me défausse lachement pour l'organisation... -- Francois Gouget http://fgouget.free.fr/ E-Voting: It's not the people who vote that count. It's the people who count the votes.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import des horaires des bureaux de poste
On Thu, 12 Nov 2020, David Faure via Talk-fr wrote: [...] > 10115A|GUIDEL BP|Mo-We,Fr 09:00-12:00,14:00-17:00; Th > 09:00-12:00,14:30-17:00; Sa 09:00-12:00; Su,PH off > > Ah tiens à ce propos, pour les cas où il existe des horaires dans OSM, je > vois souvent > que la seule différence entre OSM et datanova c'est que je génère "Su,PH off" > à la fin > alors que dans OSM ça n'y est pas. Je sais que ça revient au même, Pas tout à fait. Le "Su off" est bien redondant mais pas le "PH off", même si tous les français se doutent bien que le bureau de poste sera fermé les jours fériés. Pour ce qui est des mises à jour au fil de l'eau (après l'import initial) ; est-ce que le script serait capable de ne faire une mise à jour que si les horaires ont changés dans Datanova ? Cela limiterait les cas d'écrasement des modifications des utilisateurs sur place : si un utilisateur corrige un horaire, cette correction ne serait écrasée que la prochaine fois qu'il y a un changement dans Datanova, auquel cas on peut supposer qu'il serait de toute façon nécessaire de faire une vérif / mise à jour. Le principal cas de faux positif serait si Datanova contient une fermeture exceptionelle pour un jour particulier. -- Francois Gouget http://fgouget.free.fr/ Linux: It is now safe to turn on your computer.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment indiquer une séparation centrale sur une rue ?
On Fri, 6 Nov 2020, Eric SIBERT via Talk-fr wrote: > Une séparation pas centrale: > > https://www.mapillary.com/map/im/HsxR0OyWJaOFMa8zC7hMwn Celle-ci semble traversable par des véhicules (normaux, pas des 4x4). Donc de ce que j'ai compris des anciennes discussions sur le sujet, on ne met rien pour ce type de séparation. (ce qui est différent de la bordure dont il était sujet initialement : https://www.mapillary.com/app/?pKey=s7OAvWZ8TzqcexpCIhKARw=photo ) PS: * Oh le beau transformateur ! * Il y a plein de transformateurs faciles à dégommer sur Massy et Antony (même si j'ai fait un petit trou dans la carte). En gros, tous ceux qu'on voit près d'un petit bâtiment et où il y a des photos Bing / Mapillary pour confirmation. https://osmose.openstreetmap.fr/fr/map/#item=7051%2C8022%2C8280=15=48.71843=2.29253 * Il y a aussi un certain nombre de points "power=substation" sans autre attributs (à part le nom très utile car impossible à récupérer sans se rendre sur place) qui mériteraient d'être proprement intégrés au bâtiment correspondant et enrichis des attributs Enedis. -- Francois Gouget http://fgouget.free.fr/ Un western sans indien c'est comme une police sans serif. -- John Wayne___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Services publics et administrations locales
On Sat, 3 Oct 2020, lejun wrote: > L'idée me plaît, rien à redire dessus. Par contre l'usage de name de > dérange : > - D'une part je me demande dans quelle mesure on privilégie une valeur > explicite, name=CPAM de X, plutôt que name=X + network=CPAM Le problème avec cette approche c'est que, si X=Torcy, sur la carte on va se retrouver avec Torcy, Torcy et Torcy pour la CAF, les impôts et la CPAM. À chacun de deviner qui est qui. Pour éviter ça il faudrait que le rendu de la carte gère que si network=CPAM alors il faut afficher "CPAM de ", etc. Ça paraît usine à gaz. Encore plus avec les traductions, les cas où le contributeur aura mis "Caisse de..." dans le nom, ou si les autres pays font de même avec leurs services publics. Et non, je pense qu'on ne peut pas seulement compter sur les icônes pour lever les ambiguités. L'option opposée me paraît plus logique : name="CPAM" et on laisse tomber le "de Torcy" qui est évident de par l'emplacement géographique [1]. Après est-ce qu'il faut peupler name à partir de brand:name, network ou autres s'il n'est pas spécifié ?... À voir. [1] Encore que ça peut dépendre du niveau de zoom : sur une carte de la ville et ses environs il est évident à quelle ville appartient la CPAM (par exemple). Sur une carte des CPAMs de France où les noms de ville ne sont pas affichés parce que le niveau de zoom est insuffisant, il serait plus logique d'afficher le nom de la ville sous l'icône que "CPAM". Mais dans ce second cas on aurait probablement un rendu spécifique de toute façon. -- Francois Gouget http://fgouget.free.fr/ La terre est une bêta...___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] La gestion des poteaux
On Thu, 3 Sep 2020, Philippe Verdy wrote: [...] > > Le nombre de cables se voit sur les photos aériennes. > > Pas toujours il y a plein de petites lignes même si on est capable de le > dire. Difficile de dire souvent s'il y a 3 ou 5 câbles ou plus. ou même > s'il y en a plus d'un seul. On parle bien du 20kV, pas du 400V en aval des transformateurs de distribution ? Les lignes 400V sont effectivement ingérables. Pareil pour les lignes téléphoniques. > Ca dépend beaucoup du fond (y compris la saison), Ils sont effectivement beaucoup plus visibles sur les fonds sombres que les fonds clairs. C'est pas très pratique dans les vignobles, plus simple là où il y a des prairies. Mais même si on ne voit pas le nombre de cables à un endroit donné, on peut souvent les compter dans un autre champ un peu plus loin. > Et de toute façon pas moyen de deviner les tensions transportées et le > mode (nombre de phases ou continu à certains endroits) Comme dit précédemment la tension se déduit des transformateurs qu'on trouve sur la ligne. > Les transfos sont également pas faciles à voir (et pas toujours montés en > haut des poteaux, Les transformateurs au sol sont au sol sont généralement en bordure des villes. Pour eux il faut compté sur les photos de rue. Mais en campagne c'est huit voir neuf transformateurs sur 10 qui se trouvent en haut du poteau. Ceux-là font une généralement une verrue bien repérable sur l'ombre du poteau. https://www.openstreetmap.org/edit#map=21/45.77978/-0.09650 Du coup ça fait un bon faisceau d'indices : verrue sur l'ombre + ligne 3 cables qui arrive + proche d'un transformateur manquant sur Osmose + à coté d'un hameau => il y a un transformateur. > et ce transfo est souvent caché dans la végétation D'accord avec toi mais en remplaçant 'souvent' par 'parfois'. La verrue est aussi parfois moins visible quand le poteau est dans l'axe du soleil. > parfois enterré sous une trappe difficile à voir (ou dans une armoire > difficile à distinguer d'une armoire télécoms; Tout ça ne concerne que les villes. Et dans ce cas c'est clair qu'i faut des photos de rue. > Pour le gaz c'est plus facile car le chemin est marqué par des gros points > jaunes ou chapiteaux jaunes sur un poteau très visibles presque partout et > presque toujours en bordure de chemin ou en limite de parcelle sur une aire > dégagée. Oui. Et il y a moins de marqueurs que de poteaux électriques. Mais les marqueurs faits pour être vus d'hélicoptère sont assez rares et quand on n'a qu'eux je ne suis pas sûr que le tracé du pipeline soit bien précis. Pour bien faire il faut aussi avoir les marqueurs triangulaires (pedestal) mais ils sont très durs à repérer 'en grous il faut identifier 4 pixels un peu clairs en losange de part et d'autre d'une route proche du tracé supposé du pipeline). > Sinon si j'ai des doutes, tant pis je ne relie pas: Oui. Pareil. -- Francois Gouget ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] La gestion des poteaux
On Thu, 3 Sep 2020, Philippe Verdy wrote: > Note: avec l'imagerie haute résolution on commence à bien voir les poteaux > et lignes électriques mineures (notamment en milieu rural ou périurbain à > travers les champs pour relier les hameaux ou certaines zones > industrielles). Je confirme. En campagne on les voit très bien et on peut cartographier au moins 80% des lignes. Là où il y a des difficultés les photos Mapillary / OpenStreetCam peuvent dépanner. https://www.openstreetmap.org/edit?node=1676592637#map=19/45.88764/-0.00136 En ville les lignes sont enterrées alors forcément c'est plus difficile de les repérer sur les vues aériennes. > Que fait-on de ces lignes mineures ? on continue à les cartographier (comme > on peut) ou on attend des données ouvertes d'un exploitant pour avoir > d'autres infos comme les tensions, La plupart du temps on trouve un transformateur Enedis à un bout de la ligne ce qui permet par continuité de qualifier tout ce qui y est connecté. D'ailleurs Osmose constitue un bon point de départ. Il sufit de choisir un transformateur manquant en rase campagne. https://osmose.openstreetmap.fr/fr/map/?#zoom=16=45.77269=-0.54326=8280 Il se trouvera en haut d'un poteau qu'on pourra ajouter. Ensuite si l'image est bonne et que le fond s'y prête on sait tout de suite dans quelle direction chercher le suivant. Sinon il faut chercher un peu, s'aider des trouées dans les forêt, etc. Ensuite il n'y a plus qu'à dérouler la pelote de laine. Quand elle s'éfiloche on recommence avec un autre transformateur pas loin. Et à la fin, miracle, on se retrouve avec un plat de spaghetti ! https://openinframap.org/#11.46/45.9534/0.7541 > la puissance transportée, La puissance transportée dépend de si le sèche-cheveux est allumé ou éteint. > le nombre de câbles, Le nombre de cables se voit sur les photos aériennes. > la hauteur des poteaux ou leur nature (bois ou métallique) Ou béton. Ça on peut le voir sur les photos Mapillary / OpenStreetCam quand il y en a. Je me demande si c'est une caractéristique régionale ou si c'est une question d'époque. Sur les photos aériennes on repèrera aussi les power=portal. -- Francois Gouget http://fgouget.free.fr/ question = ( to ) ? be : ! be; -- Wm. Shakespeare___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] No U-turn vs BRouter
On Tue, 1 Sep 2020, osm.sanspourr...@spamgourmet.com wrote:
[...]
> > En fait les restrictions ne sont pas totalement superflues :
> > https://brouter.de/brouter-web/#map=19/45.78552/-1.15725/standard=-1.156756,45.785759;-1.158315,45.785505=car-eco
> Si superflues car fausses (mauvais tag).
C'est plus relation incomplète dans ce cas précis : il manque le to.
L'exemple était peut-être mal choisi mais on observe le même problème
sur les rond-points sans restriction.
> Sur Paris c'est interdit
> <https://www.lemonde.fr/archives/article/1966/01/13/le-demi-tour-est-interdit-dans-le-departement-de-la-seine_2702198_1819218.html>
> sauf à un carrefour (mais OSM ne connaît cette règle).
HS : C'est pratique ces petites lois locales qui ne sont indiquées nul
part sur la route ! Nul n'est sensé ignorer la loi mais quand elle
est publiée dans le classeur fermé à clef d'un sous-sol sans
éclairage...
--
Francois Gouget http://fgouget.free.fr/
E-Voting: Those who cast the votes decide nothing.
Those who count the votes decide everything.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] No U-turn vs BRouter
On Sun, 30 Aug 2020, Francois Gouget wrote: [...] > Je pense que le no-u-turn était sensé indiquer qu'on ne doit pas faire > demi-tour là où les deux voies se rejoignent. Cela me parait très > superflu. En fait les restrictions ne sont pas totalement superflues : https://brouter.de/brouter-web/#map=19/45.78552/-1.15725/standard=-1.156756,45.785759;-1.158315,45.785505=car-eco Je pensais que BRouter prenait en compte ce genre de connection aux rond-points. Cela dit je comprends tout à fait que ce ne soit pas le cas: trop d'exceptions à coder à la main. Et puis le cas où le point de départ est en sens unique en sortie de rond-point ne doit pas se produire souvent. Je ne suis tout de même pas sûr que ces restrictions soient justifiées : * Doit-on mettre une interdiction de faire demi-tour à chaque fois qu'il y a une ligne blanche ? * Je ne me vois pas faire demi-tour (en fait tourner à gauche) comme ça en sortie de rond-point. Mais s'il y a une ligne discontinue cela serait-il vraiment interdit ? * Ni la page du wiki sur les rond-points, ni celle sur les relations restriction ne parlent de ce cas. La version anglaise de la page sur les rond-points montre un exemple assez complet mais n'indique pas de mettre des no-left-turn sur leurs sorties. https://wiki.openstreetmap.org/w/images/2/2f/Roundabout-tagging.png Donc il ne semble pas y avoir de règle établie dans un sens ou dans l'autre. Du coup que faire ? Mon plan serait de : * Supprimer les no_u_turn sur la voie qui mène à la paire de sens uniques car elles sont fausses : à partir du moment où il n'y a pas de ligne blanche on peut faire demi-tour. En l'absence de photo il faudrait peut-être quand me vérifier qu'il n'y a pas de panneau interdisant de faire demi-tour. https://www.openstreetmap.org/relation/7488796 * Supprimer les restrictions no_u_turn lorsqu'il n'y a qu'une voie qui mène au rond-point (au lieu d'une paire de sens uniques) car elles cassent le routage et sont fausses. https://www.openstreetmap.org/relation/7488797 * Corriger les autres restrictions incorrectes. Par exemple : https://www.openstreetmap.org/relation/7347721 * Ne pas mettre de restriction lorsque je crée des rond-points. -- Francois Gouget http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, it's computer science.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] No U-turn vs BRouter
On Sat, 29 Aug 2020, Frédéric Rodrigo wrote: > C'est la relation dans OSM qui est problématique. Effectivement. Le wiki dit qu'un no-u-turn avec le from et le to identique c'est pas une bonne idée. > Le node via à mon avis devrait coté giratoire et pas au milieu de la ligne > droite. > > https://www.openstreetmap.org/relation/7488769#map=16/45.7905/-1.1526 En fait il y a un séparateur central infranchissable avec un véhicule standard et une voie pour tourner à gauche. Je pense que le no-u-turn était sensé indiquer qu'on ne doit pas faire demi-tour là où les deux voies se rejoignent. Cela me parait très superflu. Du coup j'ai changé la représentation pour avoir des voies séparées. https://www.openstreetmap.org/way/842417909 Il y a aussi des restrictions au niveau du rond-point plus à l'ouest. Certaines sont correctes mais à mon avis superflues. https://www.openstreetmap.org/relation/7347719 D'autres par contre sont fausses mais ne causent semble-t-il pas de problème : * Pas de to ! https://www.openstreetmap.org/relation/7347721 * Encore un no-u-turn avec from == to ! https://www.openstreetmap.org/relation/7488796 Mais j'en ai encore deux qui 'cassent' BRouter : * No-u-turn avec from == to mais au milieu du segment https://www.openstreetmap.org/node/415958898 https://brouter.de/brouter-web/#map=19/45.78537/-1.15734/standard=-1.157086,45.785166;-1.157067,45.785112=car-eco * Idem https://www.openstreetmap.org/relation/7488795 https://brouter.de/brouter-web/#map=19/45.78537/-1.15734/standard=-1.157454,45.786041;-1.157537,45.786148=car-eco Mais que fait la pol^H^H^H Osmose ? (Il ne dit rien, du coup je me demande si on a beaucoup de problèmes de ce genre.) -- Francois Gouget http://fgouget.free.fr/ Linux: It is now safe to turn on your computer.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] No U-turn vs BRouter
J'ai rencontré un problème de routage bizarre avec BRouter. C'est une relation No U-turn sur un noeud qui semble être la source du problème. Mais comme je ne connais pas le fonctionnement de ces relations je ne sais pas si le problème se trouve dans les données OSM ou dans le code de BRouter (je n'ai pas trouvé de bug BRouter qui semble lié). Voici le noeud qui, je pense, pose problème : https://www.openstreetmap.org/node/965521503#map=19/45.79175/-1.15111 Et voici le trajet voiture crée par BRouter. Ça fait quand même un sacré détour ! En vélo ou à pied il n'y a pas de problème par contre. http://brouter.de/brouter-web/#map=19/45.79194/-1.15119/standard=-1.151057,45.791798;-1.151201,45.791643=car-fast GraphHopper n'a pas ce problème de routage mais je ne sais pas s'il traite les No U-Turn. -- Francois Gouget http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !
On Tue, 4 Aug 2020, PanierAvide wrote: [...] > Il y a quelques semaines, la Direction Générale de la Santé a publié sa > base GéoDAE (en cours de constitution), qui recense les défibrillateurs > du pays. [...] > En parallèle, dans OSM sur la France, on compte ~6500 défibrillateurs. > Évidemment les deux bases ne se recoupent pas, certains DAE sont > présents dans l'une et pas l'autre. En 2020, c'est quand même dommage. Quelqu'un sait-il sur quelle base de donnée s'appuie l'application Staying Alive ? Et surtout quelle est la license de cette base de donnée de défibillateurs ? Sur https://www.stayingalive.org/ je vois "Powered by AEDMap". Mais sur le site de AEDMap rien de bien précis : https://aedmap.org/ J'ai l'impression qu'il s'agit d'une base propriétaire construite sur le travail de bénévoles. Mais leur coeur de métier ne semble pas être cette base de donnée mais plutôt la maintenance de défibrillateurs. Bon indépendamment de ça j'ai décidé de prendre un peu d'avance et j'ai ajouté un défibrillateur à Montparnasse. Un modèle solaire que je n'avais jamais vu avant et qui serait opéré par la Ville de Paris (3ème photo) : https://www.paris.fr/pages/mille-defibrillateurs-prevus-a-paris-d-ici-cinq-ans-4567 Et la carte dépassée et illisible des mille^H^H^H ~100 défibrillateurs de cette initiative : http://labs.paris.fr/commun/pdf/carte_33_sites.pdf Tiens, ça fait penser au xkcd d'aujourd'hui https://xkcd.com/2341/ -- Francois Gouget http://fgouget.free.fr/ Cahn's Axiom: When all else fails, read the instructions.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Segmentation des maisons
On Thu, 23 Jul 2020, André Maroneze wrote: [...] > En tout cas, merci pour vos avis. Vu l'absence de consensus sur le sujet, > je vais réfléchir sur le fait de les fusionner ou non. S'il y a un site qui > permet de voir le rendu 3D, mis à jour relativement souvent, dites-le-moi > s'il vous plaît pour que je puisse voir ce que ça donne les bâtiments > partiellement remplis, pour avoir une meilleure idée des impacts possibles > des fusions. En voici deux : https://demo.f4map.com/#lat=48.8603923=2.2917640=17 Il y a aussi osmbuildings dont le rendu est moins bon (au moins sur cette zone): https://osmbuildings.org/?lat=48.85907=2.29312=16.4=30 Vu les différences de rendu, cela renforce la règle du "ne pas tagger pour le rendu". D'autant que ces deux sites ou d'autres vont probablement continuer d'évoluer. -- Francois Gouget http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Alternatives à Mapillary
On Mon, 22 Jun 2020, Tyndare wrote: [...] > Perso je trouve que flouter le visage n'est pas suffisant pour le > respect de la vie privée, Facebook se vente d'être capable de > reconnaître les gens à leur démarche, même de dos. Il est peut-être possible d'utiliser d'autres éléments mais comme là on n'a que des images fixes on ne peut pas les reconnaître à leur démarche. > J'ai testé le modèle préentrainé suivant pour flouter les personnes en > entier des images que j'envoie sur Mapillary et je trouve que ça marche > assez bien même si ce n'est pas parfait: Est-ce que cet algo floute les plaques d'immatriculation ? Parce que c'est le deuxième plus important élément à flouter après les visages (et probablement indispensable d'un point de vue légal). -- Francois Gouget http://fgouget.free.fr/ Dieu dit: "M-x Lumière". Et la lumière fut.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] NRO avec ref ARCEP sans connection_point
On Wed, 17 Jun 2020, Jacques Lavignotte wrote: [...] > C'est plutôt bizarre... > > https://wiki.openstreetmap.org/wiki/Telecoms/France#Armoires_de_sous-r.C3.A9partition > > ??? > > -> man_made=street_cabinet + street_cabinet=telecom + telecom=exchange ? > (on a même des photos Mapillary pour ceux-là) > > Fais voir... En utilisant les couches 'Photo Overlay' sur iD je tombe sur les photos suivantes (bon, faut pas espérer lire les identifiants). > https://osmose.openstreetmap.fr/fr/error/102b9ece-2d42-7fed-e63a-01a3231586d3 https://www.mapillary.com/map/im/XHt0KpqzND-6P9rQ__DkqA > https://osmose.openstreetmap.fr/fr/error/a25c4498-9177-f631-b17d-137ea375ddba https://www.mapillary.com/map/im/Ik809rutYabgts1T2iHB0g > https://osmose.openstreetmap.fr/fr/error/041aed96-aac5-1690-4ffd-d5b6ccf68a95 https://www.mapillary.com/map/im/jBaHb_RAdZixW0YsnSiWAQ -- Francois Gouget http://fgouget.free.fr/ question = ( to ) ? be : ! be; -- Wm. Shakespeare___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] NRO avec ref ARCEP sans connection_point
On Tue, 16 Jun 2020, deuzeffe wrote: > Bonsoir, > > Soit un NRO dans un zouli shelter. > > Si je lis bien le wiki, les tags minimum sont : > - telecom=exchange > - telecom:medium=fibre À ce propos, est-ce que telecom=exchange serait approprié pour les nombreux phone=substation sur Niort ? https://osmose.openstreetmap.fr/fr/map/#item=3092=15=46.32123=-0.44826=1%2C2%2C3 Par exemple : https://osmose.openstreetmap.fr/fr/error/102b9ece-2d42-7fed-e63a-01a3231586d3 https://osmose.openstreetmap.fr/fr/error/a25c4498-9177-f631-b17d-137ea375ddba https://osmose.openstreetmap.fr/fr/error/041aed96-aac5-1690-4ffd-d5b6ccf68a95 -> man_made=street_cabinet + street_cabinet=telecom + telecom=exchange ? (on a même des photos Mapillary pour ceux-là) -- Francois Gouget http://fgouget.free.fr/ Good judgment comes from experience, and experience comes from bad judgment -- Barry LePatner___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] type de rivière pour la bièvre
On Tue, 9 Jun 2020, Brice wrote: [...] > Concernant la partie la plus en aval, la Bièvre entre dans le réseau des > égouts de Paris. J'ai récemment dessiné cette partie aval en choisissant > au mieux des tronçons d’égouts (pipeline) pour avoir la continuité > jusqu'à la Seine. Le tracé n'est pas top non plus en banlieue (à part quelques bouts à Cachan et L'Haÿ-les-Roses où elle est découverte). Si quelqu'un a des sources pour l'affiner... https://www.openstreetmap.org/way/652551012 (voir rue du Fief des Arcs) https://www.openstreetmap.org/way/652551011 https://www.openstreetmap.org/way/338187373 (voir rue de la Cosarde) -- Francois Gouget http://fgouget.free.fr/ f u kn rd ts, ur wy 2 gky 4 ur wn gd.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose, voirie non connectée
On Sun, 15 Mar 2020, Stéphane Péneau wrote: > Salut, > > Osmose m'indique une erreur de voirie non connectée, et j'avoue que je > ne comprends pas du tout pourquoi : > > http://osmose.openstreetmap.fr/fr/error/fe07c3d2-ba91-f492-f6b4-2c00cbdf8dd2 > > Il s'agit de la jonction entre > > https://www.openstreetmap.org/way/768475052 > et > https://www.openstreetmap.org/way/123276562 > > Bug de l'analyse, ou alors je ne vois pas l'erreur ? Je ne vois pas non plus. Je ne connais pas le code de cette partie d'Osmose mais en suivant le lien je n'ai pas vu d'instance de 'lane' donc je ne pense pas que ce soit à l'origine du rapport. Peut-être marquer le problème comme corrigé pour voir s'il revient (corrigé hein, PAS faux positif). Il y a peut-être eu un cafouillage à un moment donné. -- Francois Gouget http://fgouget.free.fr/ We are Pentium of Borg. You will be approximated. Division is futile.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Données sur les bouches de métro franciliennes
On Fri, 14 Feb 2020, osm.sanspourr...@spamgourmet.com wrote: [...] > https://www.sortiesdumetro.fr > <https://www.sortiesdumetro.fr/cluny-la-sorbonne.php> n'a pas des > données libres, mais ça peut permettre de voir la complétude. Après rien > n'empêche de demander s'ils acceptent une exception. Ce site indique aussi quelles sorties disposent d'un ascenseur. Je ne sais pas si la présence d'un ascenseur doit être représentée dans OpenStreetMap mais ça serait sans doute une bonne idée d'indiquer quelle sorties sont accessibles en fauteuil roulant. Parfois les deux se combinent. Par exemple à Cachan deux des sorties ont un ascenseur et sont donc accessibles en fauteuil roulant (+poussettes & valises lourdes), tandis que deux autres nécessitent d'emprunter un escalier. Pour une sortie je suppose que la géométrie pourrait suffir à expliciter l'accessibilité en chaise roulante, quoiqu'il n'y ait pas le moindre tag wheelchair à l'horizon. https://www.openstreetmap.org/node/6769102196 Mais pour l'autre sortie je ne vois pas trop comment une application pourrait rattacher l'ascenseur à la sortie correspondante et traiter les aspects chaise roulante : https://www.openstreetmap.org/node/3823552596 Bon, et le champ name contient le nom de la station dans les deux cas ce qui serait faux selon Noémie (et je suis d'accord). Par contre, faut-il vraiment mettre le numéro dans le nom ou devrait-il être dans le champ ref ? (pas exit_number apparemment) Ou les deux ? [...] > > 266 noeuds sans tag ref. Est-ce que l'absence de ce tag a aussi une > > sémantique (par exemple il n'y a qu'une sortie), ou est-ce que ce sont > > des données manquantes? ref est-il sensé être unique globalement ? (comme pour les identifiants de boîtes aux lettres ou de transformateur) Parce que si l'on met le numéro de sortie il y aura beaucoup de doublons 1, 2, 3... > > 1070 noeuds ont un attribut name, seulement 57 ont un attribut > > destination. Est-ce que du coup on pourrait faire disparaître l'attribut > > destination? > > Non, destination est bon. C'est plutôt "name" qui est à vérifier et à > remplacer par destination le cas échéant. Si je reprends la gare de Cachan, destination contient le nom des lignes de bus en correspondance. Ça ne me semble pas devoir aller dans name. Mais destination devrait-il indiquer les lignes de bus plutôt que les noms de rues ? Ce qui est bizarre aussi c'est qu'il a deux sorties côte à côte, une pour le quai des RERs en provenance de Paris et l'autre pour ceux venant de la banlieue ; et l'une indique "162;187;193;v3" et l'autre "162;187;193". Pourtant venant de province c'est bien la sortie à prendre pour attraper la Valouette (v3). C'est peut-être une bizarrerie de l'affichage RATP. Il faudra que je vérifie. > > Et qu'en est-il de découper le contenu de name, ou au moins d'en avoir > > une version alternative découpée en plusieurs morceaux? > > destination, ref et le nom de la station portée par la relation > public_transport=stop_area, oui c'est mieux (et au final on vire name, Si à Cachan le champ destination contient bien les noms des lignes de bus, alors il ne permettrait pas de reconstruire le nom des sorties qui, il me semble, contiennent le nom de la rue où elles sont. -- Francois Gouget http://fgouget.free.fr/ "Utilisateur" (nom commun) : Mot utilisé par les informaticiens en lieu et place d'"idiot".___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Héberger un mirroir ou un bittorrent pour les planet, possible?
On Mon, 3 Feb 2020, marc marc wrote: [...] > en passant pour moi la vrai erreur, c'est Https Everywhere qui ne > devrait pas basculer en https si le certificat n'est pas bon. Je suis assez d'accord. Mais il me semblait justement que HTTPS Everywhere avait une liste blanche de sites où on peut passer en HTTPS. D'ailleurs la voilà et openbittorrent est dans la liste : https://atlas.eff.org/letters/o.html Comme OpenBittorrent est dans la liste je pense qu'Https Everywhere doit forcer le passage en https pour éviter les attaques MITM (je me mets au milieu et je renvoie un mauvais certificat pour le https pour forcer HTTPS Everywhere à continuer en http et ce qui me permet d'intercepter et de changer tout le trafic). Bien sûr l'utilisateur se prend une erreur et est donc tenté de continuer en http. Mais cela requière une action consciente (et non évidente) de sa part. Il y a probablement eu une régression du coté d'OpenBittorrent. > chez moi il ne bascule pas, tu ne l'aurais pas forcé en https ? J'ai cliqué sur "Réinitialiser aux paramêtres par défaut" et pas de changement il me renvoie toujours vers le https. -- Francois Gouget http://fgouget.free.fr/ You can have my guns when you pry them from my kids cold, dead hands.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Héberger un mirroir ou un bittorrent pour les planet, possible?
On Wed, 29 Jan 2020, Philippe Verdy wrote: > Traqueurs vides de tous clients connectés dessus, donc pas de > téléchargement du tout. Les deux traqueurs n'annoncent personne (statut > torrent : non annoncé, sur opentracker.org bien que marqué "activé" et > "traqueur principal"; sur le second traqueur sur openbittorrent.com il > l'est même pas pas activé, donc pas annoncé non plus). J'ai eu un peu de mal avec ces sites : * http://openbittorrent.com/ -> Je me retrouve automatiquement sur https://openbittorrent.com/ dont le certificat est valide pour *.opentrackr.org et pas openbittorrent.com. Bon, en fait c'est la faute de Https Everywhere mais il y a quand même un problème avec le certificat. * http://opentracker.org/ Page vide. -> Je suppose qu'en fait il s'agissait de https://opentrackr.org/ Et comme je ne connais pas bien Bittorrent je ne sais pas trop quoi en faire ensuite. Par contre pour ce qui est du téléchargement à partir de http://osm.cquest.org/torrents/ pas de problème : débit de 800 Mb/s en moyenne. Vive la fibre. Ensuite en upload, pratiquement rien. Moins de 100 kb/s de temps en temps. En ce moment 1 à 1,5 Mb/s, loin de la limite de mon coté. Je suppose que ça bouchone à l'autre bout. Perso ce que j'aimerai bien c'est une solution pour fiabiliser l'affichage des différents fonds dans iD et Osmose : régulièrement lorsque je zoome j'ai des morceaux qui ne veulent pas se rafraîchir, du coup j'ai soit un trou noir, soit du flou. Cela dit c'est peut-être plus un mauvais coup de Firefox. Mais si le problème vient de timeout liés à la saturation des serveurs alors une solution distribuée pourrait être intéressante. Quelque chose un peu à la PeerTube par exemple. -- Francois Gouget http://fgouget.free.fr/ There are 10 types of people in the world... those who understand binary and those who don't.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Héberger un mirroir ou un bittorrent pour les planet, possible?
On Sat, 1 Feb 2020, Philippe Verdy wrote: [...] > J'ai bien l'impression que Free a fait un compromis en supprimant ce qu'il > juge "ne plus être utile" sur la Révolution (et répondre à la demande des > abonnés d'avoir accès à Netflix dessus, même si ce n'est pas inclus dans > l'offre, avec leurs propres identifiants Netflix, et sans passer à la Delta Il y a peut-être un problème de place pour le firmware mais je doute fort que Netflix et Youtube Kids soient responsable : les torrents sont gérés sur le boitier serveur alors que tout ce qui est vidéo est géré sur le boitier TV. Deux boitiers donc deux firmwares indépendants. -- Francois Gouget http://fgouget.free.fr/ Good judgment comes from experience, and experience comes from bad judgment -- Barry LePatner___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Type de highway pour voie de bus
On Wed, 22 Jan 2020, Stéphane Péneau wrote: > Le 22/01/2020 à 10:12, Florimond Berthoux a écrit : > > Les piétons n’ont pas à marcher sur la voie bus, mais ils peuvent > > marcher sur les trottoirs ;) > > > > Pour être juste le wiki dit « For dedicated, separate bus tracks, use > > highway=service, access=no, psv=designated (or psv=yes). » > > https://wiki.openstreetmap.org/wiki/Buses > > Mais c’est bête je trouve, dans le cas générale ça devrait plutôt être > > vehicle=no* et psv=yes > > Mais en même temps les chevaux sont interdit aussi xD > > It’s complicated. > > Je ne vois pas vraiment le problème avec access=no + psv=yes/designated. > > Ces tags ne concernent pas le trottoir accessible aux piétons qu'on peut > ajouter avec sidewalk=*, Je doute qu'ajouter un sidewalk=* à une voie foot=no signifie que les piétons peuvent se déplacer le long de la voie. En tout cas lorsqu'il n'y a pas de tag sidewalk (de loin le cas le plus courant) mettre un access=no ou trop restrictif empêche aussi les routeurs de suggérer la voie aux piétons (j'en ai déjà fait les frais). > sinon ça voudrait dire qu'un oneway=yes sur la voie de bus > impliquerait que le trottoir l'est aussi. De la façon dont je comprend la chose access=no impacte aussi le trottoir. Il est nécessaire qu'il ait ce sens afin que l'on puisse décrire des voies interdites aux piétons (*), indépendamment de la présence d'un trottoir. Mais pour les voies de bus dédiées ça passe parce qu'il y a généralement une voie voiture parallèle qui a elle aussi un trottoir associé par défaut et qui elle n'interdit pas les piétons. Par contre si jamais une rue est entièrement réservée aux bus, alors mettre access=no ou foot=no empêcherait les routeurs de suggérer aux piétons de prendre cette rue. (*) Rares je le concède (hors autoroutes et voies rapides mais dans leur cas il n'y a pas besoin de l'expliciter via access). -- Francois Gouget http://fgouget.free.fr/ You can have my guns when you pry them from my kids cold, dead hands.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Talk-fr mailing list bounce policy
On Sun, 29 Dec 2019, Tom Hughes wrote: > This is a matter for the talk-fr admin - they need to change the > list settings (the from_is_list setting) to munge the from addresses > of senders with a hard DMARC policy or the resulting bounces caused > by the list forwarding to gmail and other sites that enforce DMARC > policies will cause those recipients to be unsubscribed. Who is "the talk-fr admin"? How can I contact him? The page below says the talk-fr list is managed by talk-fr-owner at openstreetmap.org so I sent an email to that address but I did not hear back and I'm still regularly getting kicked out (last time was last thursday). https://lists.openstreetmap.org/admin/talk-fr The "Admins" column is empty for the "talk-fr" line on the page below: https://wiki.openstreetmap.org/wiki/Mailing_lists And the page below provides no way to contact administrator of specific lists: https://lists.openstreetmap.org/admin The only address it provides is mail...@openstreetmap.org but as far as I can tell that's not who I should contact. So how can I get this to move forward? -- Francois Gouget http://fgouget.free.fr/ E-Voting: Those who cast the votes decide nothing. Those who count the votes decide everything. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag PMU ?
On Mon, 30 Dec 2019, pepilepi...@ovh.fr wrote: > Bonjour, > > Un point de "vente" du PMU, souvent situé dans un bar, ça se taggue > comment ? C'est pas vraiment du "amenity=gambling", je ne vois pas ça > non plus comme du "shop=bookmaker"... Le wiki semble suggérer gambling=yes. https://wiki.openstreetmap.org/wiki/Key:gambling -- Francois Gouget http://fgouget.free.fr/ Indifference will certainly be the downfall of mankind, but who cares?___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Projet Europeen de l'Eau/European Water Project - Instructions en français
On Fri, 27 Dec 2019, European Water Project wrote: > Bonjour, > > Je serai reconnaissant si vous pouvez nous donner vos commentaires sur les > instructions en français de comment ajouter une fontaine d’eau potable dans > OpenStreetMap et une photo dans Wikimedia Commons. Concernant la photo de la fontaine, pour OpenStreetMap je pense qu'il serait utile qu'elle permette un peu de situer la fontaine dans son environnement. De ce point de vue je trouve que la photo donnée en exemple n'est pas idéale : on ne voit pas si la fontaine est au bord d'un chemin, au milieu d'un parc ou toute proche d'habitations, etc. Elle montre bien la fontaine en elle-même et permet certainement d'en identifier le modèle, ce qui est important aussi, mais elle pourrait pratiquement être la photo de n'importe quelle fontaine de ce modèle. Il y a là une tension entre des buts peut-être pas entièrement compatibles : * Cadrer large afin de placer la fontaine dans son environnement pour aider à la placer sur OpenStreetMap et qu'il soit clair que la photo correspond bien au point se trouvant sur OpenStreetMap. * Mais également cadrer assez serré afin qu'on voie bien les caractéristiques de la fontaine, au moins pour OpenStreetMap, mais peut-être aussi pour Wikimedia Commons, par exemple si les photos sont sensées pouvoir servir d'illustration aux articles Wikipedia (mais pour cette deuxième partie je suppute car je ne connais pas bien Wikimedia). Néanmoins ceci n'est que mon avis. À voir donc si des contributeurs plus experts confirment où non. -- Francois Gouget http://fgouget.free.fr/ A black hole is just God dividing by zero.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Talk-fr mailing list bounce policy
Any news on this? My subscription got deactivated again yesterday evening: Date: Thu, 26 Dec 2019 23:57:15 On Sat, 21 Dec 2019, Francois Gouget wrote: > > Regularly users on the talk-fr mailing list get kicked off. It's my > third time this month! Whenever it happens it looks like multiple users > across multiple ISPs get kicked off at the same time. > > The notification message mentions "excessive bounces" without specifying > how many bounces occurred or providing any information that would help > diagnose the reason for the bounces. Most users rely on their ISP email > servers and thus cannot look at the server logs either. > > Here's the relevant extract of this message (without the link and > password): > > > Votre abonnement à la liste Talk-fr a été désactivé suite à due to > excessive bounces The last bounce received from you was dated > 21-Dec-2019. Vous ne recevrez plus de messages en provenance de cette > liste tant que vous n'aurez pas ré-activé votre abonnement. Vous > recevrez encore 3 rappels comme celui-ci avant que votre abonnement ne > soit supprimé. > > Pour ré-activer votre abonnement, vous pouvez répondre simplement à ce > message (en laissant la ligne Subject: --Objet-- du message intact) ou > vous rendre à la page de confirmation à l'adresse : > > --- > > > Debian also has to deal with bounces on their mailing lists and there > are two things that they do which improve the situation greatly: > > 1. The notification email contains a link to the last bounce >including all the email headers (see attachment). >- This helps get a sense of why the bounce occurred. >- Most of the time it's a spam false positive. Note that most users > cannot prevent their ISPs from doing at least some level of spam > filtering. >- Users can however report false positives to their ISPs, but only if > they can provide the full email headers of the message that > bounced. The link in the notification message provides that > information and thus there is at least a chance that ISPs can > improve. >- The link remains valid for about a week. This way the Debian > servers don't end with a glut of bounced emails. > > 2. A user gets kicked out only if more than 80% of the emails got >bounced over a period of 7 days. Notification emails get sent at a >much lower threshold (I presume weekly in the presence of bounces). >This still lets Debian purge old accounts from their mailing lists >without randomly kicking users out. > > > So it would be great if OSM could implement a similar policy on Talk-fr > (and the other mailing lists at your discretion). > > > -- Francois Gouget http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Talk-fr mailing list bounce policy
Regularly users on the talk-fr mailing list get kicked off. It's my third time this month! Whenever it happens it looks like multiple users across multiple ISPs get kicked off at the same time. The notification message mentions "excessive bounces" without specifying how many bounces occurred or providing any information that would help diagnose the reason for the bounces. Most users rely on their ISP email servers and thus cannot look at the server logs either. Here's the relevant extract of this message (without the link and password): Votre abonnement à la liste Talk-fr a été désactivé suite à due to excessive bounces The last bounce received from you was dated 21-Dec-2019. Vous ne recevrez plus de messages en provenance de cette liste tant que vous n'aurez pas ré-activé votre abonnement. Vous recevrez encore 3 rappels comme celui-ci avant que votre abonnement ne soit supprimé. Pour ré-activer votre abonnement, vous pouvez répondre simplement à ce message (en laissant la ligne Subject: --Objet-- du message intact) ou vous rendre à la page de confirmation à l'adresse : --- Debian also has to deal with bounces on their mailing lists and there are two things that they do which improve the situation greatly: 1. The notification email contains a link to the last bounce including all the email headers (see attachment). - This helps get a sense of why the bounce occurred. - Most of the time it's a spam false positive. Note that most users cannot prevent their ISPs from doing at least some level of spam filtering. - Users can however report false positives to their ISPs, but only if they can provide the full email headers of the message that bounced. The link in the notification message provides that information and thus there is at least a chance that ISPs can improve. - The link remains valid for about a week. This way the Debian servers don't end with a glut of bounced emails. 2. A user gets kicked out only if more than 80% of the emails got bounced over a period of 7 days. Notification emails get sent at a much lower threshold (I presume weekly in the presence of bounces). This still lets Debian purge old accounts from their mailing lists without randomly kicking users out. So it would be great if OSM could implement a similar policy on Talk-fr (and the other mailing lists at your discretion). -- Francois Gouget http://fgouget.free.fr/ Hiroshima '45 - Czernobyl '86 - Windows '95Dear subscriber, We've encountered some problems while sending listmail to your emailaddress fgou...@free.fr. In the last seven days we've seen bounces for the following list: * debian-devel 4 bounces out of 100 mails in 7 days (4%, kick-score is 80%) (https://lists.debian.org/bounces/MmmPJ+ZGdBf5lA6SgIyEGA) (The link above points to a copy of the latest bounce and will be valid for seven days.) If the bounce-rate passes the kick-score, our bounce-detection will forcibly remove your subscription. Bounces happen from time to time when spam slips through our filters but are rejected by your mail provider. If you are your own mail provider and use 'Before-Queue Content filtering', you should whitelist bendel.debian.org from Content filtering. However: You can safely ignore this message (and you will not be unsubscribed :-) ) if your bounce rate remains low. For more information see https://wiki.debian.org/Teams/ListMaster/FAQ You are welcome to contact listmas...@lists.debian.org if you think this message was sent in error. Sincerely, The Listmaster Team -- http://lists.debian.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] adresse mail rejetée
On Mon, 16 Dec 2019, marc marc wrote: > > > ce serait vraiment bien si > > Je redis parce que cela a visiblement été noyé dans la masse : > Il semblent n'yavoir aucun sysadmin osm.org > Donc leur parler ici revient à parler dans le vide (sauf à aider au > diagnostic, qui lui nécessité le message de bounce). > Solution : soit aller voir les logs d'un serveur email perso soit > signaler le soucis aux admin osm.org 1. Je n'ai pas accès aux logs de Free. 2. Je ne sais pas comment contacter les administrateurs osm.org. 3. Manifestement, en plus de ne pas y avoir d'administrateur sur cette liste, il n'y a pas non plus qui que ce soit qui soit motivé pour faire le relai ou au moins indiquer où signaler le problème. Bon. mail...@openstreetmap.org ? Anglais, Français ? -- Francois Gouget http://fgouget.free.fr/ Un western sans indien c'est comme une police sans serif. -- John Wayne___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] adresse mail rejetée
On Tue, 10 Dec 2019, lenny.libre wrote: > Bonjour, > > cela fait deux fois que je reçois un mail de la liste pour réactiver mon > adresse après avoir été rejeté trop de fois (bounced) vaut-il mieux que > je modifie cette adresse (c'est une adresse en orage.fr) ? Pareil ici mais avec Free. La première fois c'était en même temps que tout le monde et la seconde hier soir. Alors bien sûr j'ai réactivé mon abonnement ce matin mais j'ai perdu une douzaine d'heure d'emails. Si je m'abonne à une liste de diffusion c'est pas pour être obligé d'aller la consulter sur une page web parce qu'il me manque en permanence des emails ! Donc ce serait bien que la gestion des bounces soit améliorée. Les listes Debian ont la politique suivante : 1. Un bounce ne suffit pas à se faire jeter. Il en faut plusieurs (3 si mes souvenirs sont bons) sur une période de temps "courte" (une semaine je crois). Ça évite de devoir se réabonner tous les quatre matins. 2. Lorsque la mailing liste reçoit un bounce elle envoie un email avec un lien vers l'email de bounce qui inclut lui-même l'email qui a été rejeté. La moitié du temps c'est un vrai spam qui a réussi à passer sur la liste. Le reste du temps c'est un faux positif et cela permet de le signaler au FAI (non que cela donne l'impression de faire vraiment effet mais il serait hypocrite de se plaindre que des procédures n'ont pas d'effet si on ne les utilise même pas). Donc ce serait vraiment bien si talk-fr pouvait mettre en place une procédure similaire. Aussi bien pour le seuil qui éviterait de se faire désabonner pour un rien, que pour l'email de notification qui permet de signaler le problème au FAI. Concernant les emails de Philippe Verdy, pareil pour moi : je ne reçois plus ses emails depuis le 2018-10-26. En fait je croyais qu'il avait quitté la liste. Je n'ai pas regardé s'il y avait d'autres emails qui ne me parviennent plus mais clairement il y a quelque chose qui n'est pas normal là-dessous. Mais évidemment rien ne me permet de dire si ses emails génèrent des bounces chez mon opérateur où si ça coince encore avant : voir point 2 ci-dessus... -- Francois Gouget http://fgouget.free.fr/ Any sufficiently advanced Operating System is indistinguishable from Linux___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] adresses sur tronc d'arbres
On Wed, 2 Oct 2019, Baptiste Lemoine - Cipher Bliss via Talk-fr wrote: [...] > https://www.mapillary.com/map/im/YC4fb2LeIVSO5ufjuw66bA (désolé pour > la qualité, y'a des affichages agraphés sur le plan, c'est malin) et > voici a quoi ressemblent les marquages sur les arbres. on dirait > clairement des adresses, sauf qu'il n'y a aucune maison dans cette > foret, pas de boite postale non plus. donc pour le moment j'ai mis des > POI marquant une adresse avec juste un numéro, mais pas de nom de rue. C'est juste le numéro des stations du parcours sportif pour le faire dans l'ordre (on voit que le parcours fait un huit). Donc mettre un point fitness_station=xxx pour chaque station, et les joindre dans une relation type=route + route=fitness_trail. https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dfitness_station https://wiki.openstreetmap.org/wiki/FR:Tag:route%3Dfitness_trail Les numéros iraient sur les points fitness_station. Le Wiki dit : name=* a name for the fitness station ref=* a reference number of the fitness station Donc peut-être name="Station N" ou alors simplement ref=N. -- Francois Gouget http://fgouget.free.fr/ Sufficently advanced incompetence is indistinguishable from malice.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cartographie de la pub...
On Mon, 23 Sep 2019, PanierAvide wrote: > Bonjour, > > Et pour avoir un rendu qui donne une vue d'ensemble, il y a OpenAdvertMap : > https://openadvertmap.pavie.info/#15/45.7547/4.8354 Est-ce normal que l'on y trouve les panneaux d'affichage électoraux ? Par exemple : https://openadvertmap.pavie.info/#17/48.79355/2.33282 Ils sont tagués avec advertising=board + message=political + permanent=no. Faudrait-il les tagger autrement ? D'ailleurs certains ont aussi un nom qui correspond à l'appellation du bureau de vote correspondant et qui permet de mieux les croiser avec les informations sur le site de la ville. Par exemple name=Crèche du petit Poucet. Mais je ne suis pas sûr que ce soit approprié. Une meilleure suggestion ? -- Francois Gouget http://fgouget.free.fr/ Linux: Because rebooting is for adding new hardware___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose râle... (5274335220)
On Tue, 27 Aug 2019, osm.sanspourr...@spamgourmet.com wrote: > Merci pour ce numéro de détective. > > Je suis d'accord à une exception : > > Le 27/08/2019 à 19:46, Francois Gouget - fgou...@free.fr a écrit : > > On peut donc corriger le nom du segment de la rue Lafayette ci-dessous > > pour l'appeler ce qui résoudra ce paquet > > d'erreurs Osmose. > > > > https://www.openstreetm"Place de la République" ap.org/way/37175949 > > Certes on peut (doit) nommer les highway en question en "Place de la > République" (si c'est affiché comme tel aux extrémités en question) mais > il faut aussi créer la place de la République en surfacique, avec un > place=square. Rien ne semble avoir changé et pourtant les erreurs Osmose ont disparues. Donc j'ai : * Corrigé le nom des voies autour de la place de la République, ainsi que d'un segment du boulevard Victor Hugo comme je l'avais indiqué dans mon email. * J'ai ajouté place=square sur la même surface que le parking (qui porte déjà un champ name adéquat). -- Francois Gouget http://fgouget.free.fr/ Research is the transformation of money to knowledge. Innovation is the transformation of knowledge to money. -- Dr. Hans Meixner___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose râle... (5274335220)
. C'est donc plus le nom de la place que du parking. Pour comparaison on parle du "parking Citadelle" et non "parking de l'avenue Citadelle". Comme en plus le nom est un peu redondant maintenant qu'il est sur les voies qui entourent la place j'aurais tendance à l'enlever. Mais bon, les places c'est toujours pas très clair dans OpenStreetMap. Voilà. Osmose c'est beaucoup jouer aux détectives et croiser les informations. Je vous laisse faire les changements. -- Francois Gouget http://fgouget.free.fr/ Computers are like airconditioners They stop working properly if you open WINDOWS___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenInfraMap - suggestion
On Mon, 12 Aug 2019, David Crochet wrote: > Bonjour > > Je ne sais pas si les contributeur a OpenInfraMap sont également sur > cette liste, mais Il serait intéressant de modulé l'opacité des données, > car les données "Oil & Gaz" étant d'une couleur très clair, il est pas > facile de les visualiser. Si je peux aussi me permettre une suggestion, ce serait vraiment pratique pour s'y retrouver d'avoir le nom de 3 où 4 villes dans le fond de carte à chaque niveau de zoom. Par exemple à l'heure actuelle typiquement les seuls éléments qui ont un nom sont les postes électriques comme ceux de Asnière-sur-Nouère et Fléac. Mais ce n'est pas très parlant (à part peut-être pour les gens du coin) et avoir un label "Angoulème" là où se trouve la grande ville proche permettrait tout de suite de savoir qu'il s'agit de sa banlieue. Il y a aussi un problème avec les liens vers les noeuds OpenStreetMap (mais je suppose qu'il s'agit d'un problème déjà connu). Par exemple : https://www.openstreetmap.org/way/1399460508 vs. https://openstreetmap.org/node/1399460508 -- Francois Gouget http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Panneaux de signalisation manquant
On Thu, 8 Aug 2019, Jérôme Seigneuret wrote: [...] > vous pensez quoi de ça : > > note=#highwayspeedconflict + maxspeed=50;80 + > source:maxspeed=FR:urban;FR:rural maxspeed=50;80 Osmose n'aime pas : pas une valeur numérique. Il y a déjà un certain nombre d'erreurs à cause de champs 50;90 dont je n'ai aucune idée de ce que l'auteur voulait dire : * 50 dans un sens et 90 dans l'autre ? * 50 à certaines heures et 90 à d'autres ? * 50 pour certains véhicules et 90 pour d'autres ? * 50 sur un bout de la rue et 90 sur l'autre ? Donc à proscrire de mon point de vue. 50;90 https://osmose.openstreetmap.fr/fr/error/30656818936 50;70 (là au moins il y a un fixme) https://osmose.openstreetmap.fr/fr/error/30687341551 70;50 (différent de 50;70 ?) https://osmose.openstreetmap.fr/fr/error/30686695452 -- Francois Gouget http://fgouget.free.fr/ Chemistry professors never die, they just fail to react.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Camera 360
On Wed, 10 Jul 2019, Stéphane Péneau wrote: > Le 10/07/2019 à 12:18, Francois Gouget a écrit : > > > > L'autre point faible c'est qu'elle n'a pas de GPS intégré. En même temps > > sur les smartphones la position GPS semble parfois être rafraichie à une > > fréquence inférieure à celle de la prise de photos ce qui se traduit par > > des photos successives qui ont la même position. > > La corrélation fait une interpolation entre les points, donc ce n'est > pas là qu'est le problème. Si 2 photos ont la même position, c'est > qu'elles ont le même timestamp. Non ! D'abord ci-dessus je parlais des photos prises sur *smartphone*, par l'application Mapillary, et non sur action cam. Lorsque je transfère ces photos du téléphone vers l'ordinateur via USB ou un lecteur de carte microSD je me retrouve avec des photos qui ont des timestamps différents (et une précision sub-seconde) mais exactement les mêmes coordonnées GPS. L'application Mapillary me fournit aussi un fichier GPX qui lui aussi contient des points consécutifs avec des timestamps différents mais exactement les mêmes coordonnées GPS. C'est là que je fait l'interpolation avec une version modifiée des scripts mapillary_tools (vu que de base ils sont plutôt nuls), afin que chaque photo retrouve une position correcte. https://github.com/fgouget/mapillary_tools/commits/fgouget Indépendament de cela, lorsque je regarde ma position sur Osmand parfois je voit un déplacement saccadé, comme si la position n'était rafraîchie qu'une fois par seconde. Donc je pense que ce qui se passe c'est que l'application Mapillary récupère la position GPS, prend la photo, tague la photo avec la position et continue en boucle comme ça. Mais comme je lui ai dit de prendre une photo tous les 5 m avec un interval minimum de 0.9 s, parfois la position GPS n'a pas été rafraîchie entre deux photos. Il y aurait plusieurs solutions pour que l'application Mapillary évite le problème mais elles sont toutes un peu galère à mettre en oeuvre donc je comprends que les développeurs Mapillary ne se soient pas embêtés. > J'ai beau faire du lobbying auprès des fabricants d'action cam pour > qu'ils ajoutent les millisecondes dans les données Exif, pour l'instant > je ne connais que la LG360 qui les intègre. Un effort louable parce que c'est sûr que ça serait bien. > >Pas sûr non plus que Mapillary prenne des photos de 66 Mpx. > > Elles sont acceptées. > > Bien qu'une partie de mes photos 360 équirectangulaire est du noir, les > photos 360 que j'envoie sont en 88 Mpx. > Ce qui est casse-pied, c'est qu'il faut être vraiment patient pour que > le site affiche la qualité max, et qu'il faut zoomer un peu. Exemple : > https://www.mapillary.com/app/?focus=photo=Nefc0jBo8GnL7ymGYH3Vew=47.08559283299879=-1.2745185315505512=17=0.7558841390338722=0.4895506122119632=0.3640677728864865=true=2019-04-15=2019-04-17 88 Mpx. C'est super cool ! J'aurais critiqué le trou zénital mais en fait on voit quand même assez bien les toits (pratique pour repérer corréler les chiens-assis entre les photos et les vues aériennes). -- Francois Gouget http://fgouget.free.fr/ Any sufficiently advanced technology is indistinguishable from magic. Arthur C. Clarke___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Camera 360
On Tue, 9 Jul 2019, Magalie Dartus wrote: [...] > Voilà l’intention, par contre on ne sait absolument pas quelle caméra > prendre pour ce projet > Est-ce que certains d'entre vous ont déjà de l'expérience et pourraient > nous conseiller sur des modèles adéquats? J'utilise une Xiaomi Mi Sphere. http://360rumors.com/mi-sphere-review/ https://www.mapillary.com/map/im/0yLujIYIbCC6Ygp4bOTu5g Pour Mapillary le nerf de la guerre c'est la résolution afin de pouvoir lire le texte des panneaux et des enseignes des boutiques. Du coup le point fort de la Mi Sphere c'est sa résolution de 24 Mpx ce qui à ma connaissance est le maximum qu'on trouve sur les caméra 360 degrés grand public. Malgré tout 24 Mpx c'est pratiquement rien. Si on compte qu'une photo normale couvre un champ de 90 degrés, alors pour prendre une vraie photo 360 il faut 6 photos normales : devant, derrière, à droite, à gauche, haut, bas. Donc lorsqu'on zoome sur un panneau une photo 360 de 24 Mpx fournit la même résolution qu'une photo normale de 4 Mpx :-( C'est aussi pour cela que le mode vidéo des caméras 360 ne sert strictement à rien pour Mapillary : on démarre au mieux avec une résolution "4K", soit 8 Mpx, soit un équivalent de 1,3 Mpx pour une photo normale. L'autre élément important pour Mapillary c'est la fréquence à laquelle on peut prendre des photos. Théoriquement la Mi Sphere peut prendre une photo toutes les 2 secondes. En pratique c'est plutôt 3 à 5 secondes :-( Il y a cependant un firmware beta qui permet de descendre à 2 à 3 secondes. https://1drv.ms/u/s!AvPAszrzDmdOnkebA2oluaGbs_Hg puis voir "How to update by SD Card" : http://ez-team.com/xiaomi.html L'autre point faible c'est qu'elle n'a pas de GPS intégré. En même temps sur les smartphones la position GPS semble parfois être rafraichie à une fréquence inférieure à celle de la prise de photos ce qui se traduit par des photos successives qui ont la même position. Du coup je préfère de toute façon reconstruire les positions GPS à partir d'une trace GPS et des timestamps des photos. C'est notamment indispensable pour les photos prises avec l'application Mapillary ! Donc c'est ce que je fait aussi pour les photos 360 et c'est l'application Mapillary qui me fournit le fichier GPX (et ça me donne en bonus des photos 12 Mpx "haute résolution" pointant vers l'avant). Par contre les timestamps des photos 360 ont une granularité d'une seconde. Pas idéal mais pas catastrophique non plus. Sinon on peut alimenter la Mi Sphere via USB pendant qu'elle prend des photos. Suivant l'emplacement de la prise USB ce n'est pas toujours pratique avec d'autres caméras. Avec un pack de 1 mAh ça permet facilement de faire des séances de 8 heures. Donc pour moi les critères de choix sont : * Résolution >= 24 Mpx. * Intervalle entre deux photos: aussi proche de 1 seconde que possible. * Possibilité de mettre une carte MicroSD (viser directement 128 Go). * Possibilité d'alimentation USB pendant la prise de vue. * GPS intégré ou résolution timestamps sub-seconde. Malheureusment la plupart de ces informations sont introuvables :-( Autres notes : * L'Insta 360 One est assez similaire à la Mi Sphere et semblait aussi avoir assez bonne réputation mais je ne sais pas si elle marche bien pour Mapillary. * À l'époque j'avais hésité entre la Mi Sphere et la Gear 360 de 2016 (la plus récente a perdu en résolution photo) mais cette dernière n'avait pas de mode timelapse utilisable. * Le prix de la Theta Z1 me paraît plutôt élevé vu qu'elle ne fournit pas une meilleure résolution que les Mi Sphere, Gear 360 ou Insta 360 One (pas X). Cela dit ses capteurs 1" devraient permettre une meilleure qualité d'image, notamment moins de grain pour les photos en basse lumière comme en intérieur où la nuit, conditions qu'on ne rencontre normalement pas pour Mapillary. Je demande à voir donc. * Dans la même gamme de prix que la Theta Z1 (~$1200) il y a la Ultracker Aleta S2C qui a une résolution de... 66 Mpx ! http://360rumors.com/ultracker-aleta-s2c/ Ce serait parfait pour Mapillary... si le reste des caractériques suit. Par exemple dans le mode d'emploi on lit que le mode timelapse permet de prendre des photos en 4K à 12K (66 Mpx) avec un intervalle de 0,1 à 60 secondes, mais que l'intervalle dépend de la résolution... (par exemple à 2fps on est limité à 29 Mpx) Pas sûr non plus que Mapillary prenne des photos de 66 Mpx. * Comparatif des caméras 360 : http://360rumors.com/best-360-cameras-virtual-tours/#feb2019 * Mapillary a un forum sur les caméras 360 : https://forum.mapillary.com/c/contributing-and-equipment/cameras -- Francois Gouget http://fgouget.free.fr/ Cahn's Axiom: When all else fails, read the instructions.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose erreurs#1270
On Thu, 13 Jun 2019, David Crochet wrote: > Bonjour > > Le 13/06/2019 à 12:44, lenny.libre a écrit : > > Est-ce le "area=yes" qui perturbe Osmose où une erreur de ma part ? > > Si le chemin arrive à une aire, cela nécessite la continuité dudit > chemin à l'intérieur de l'aire. Donc sur un endroit comme ci-dessous il faut faire traverser les chemins et voies cyclables ? Où est-ce que c'est pas encore bien décidé ? https://osmose.openstreetmap.fr/fr/map/#item=1270=18=47.497935=-0.581093=1%2C2%2C3== -- Francois Gouget http://fgouget.free.fr/ Any sufficiently advanced technology is indistinguishable from magic. Arthur C. Clarke___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BDOrtho IGN en rade ?
On Wed, 5 Jun 2019, Yves P. wrote: > Merci Vincent pour les informations :) > > Je pensais à la base que c'était un problème technique. Moi aussi. J'ai pas dû bien lire les emails précédents. Bon courage pour les négociations. -- Francois Gouget http://fgouget.free.fr/ Cahn's Axiom: When all else fails, read the instructions.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] BDOrtho IGN toujours cassé dans ID ?
Quelle est le status de la BDOrtho IGN dans ID ? Chez moi c'est toujours tout noir dès que je suis au zoom 16 ou plus. Aux zooms inférieurs ça va à peu près. Au zoom 9 j'ai des trous dans la couverture et au zoom 6 j'ai une bande qui coupe la France en 2 et rien hors de France. J'ai effacé les cookies et le cache de Firefox mais le trou est toujours là au-dessus de Rambouillet. J'ai d'ailleurs exactement les mêmes symptomes dans Google Chrome. -- Francois Gouget http://fgouget.free.fr/ A black hole is just God dividing by zero.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modif majeure merdique
On Wed, 8 May 2019, Vincent Bergeot wrote: [...] > il a arpenté le monsieur : http://overpass-turbo.eu/s/IO0 ( [...] Au vu du résultat de la requête Overpass je me suis demandé si ce n'était pas simplement tous les "lieux-dits" FANTOIR. Ces derniers ne sont pour la plupart pas des lieux-dits mais des noms de parcelle du cadastre qui ne sont, dans mon experience, pas réellement usités, même par ceux qui habitent sur cette parcelle où y ont un champ. Du coup pour la plupart le bon status dans FANTOIR semble être : "Nom introuvable sur le terrain". Mais en regardant Saint-Martin-le-Noeud, il y a 55 "lieux-dits" FANTOIR et je n'ai pas l'impression qu'il y en ait autant dans les résultats Overpass. De plus les lieux-dits ajoutés ne correspondent pas tous aux noms FANTOIR. Par exemple rien ne correspond à "Le Pré des Oisons", "Talma" ou "Les Osiers", ce qui suppose une autre source. Par contre on trouve aussi des correspondances comme le "Lieu-dit le Bois de la Grange", ce qui est logique, mais bien sûr impossible pour FANTOIR de s'y retrouver en raison du mauvais type de point et du préfixe "Lieu-dit". https://cadastre.openstreetmap.fr/fantoir/#insee=60586=4 [...] > on part plutôt sur du place=locality -> > https://wiki.openstreetmap.org/wiki/Tag:place%3Dlocality Ou du place=hamlet s'il y a des maisons proches. -- Francois Gouget http://fgouget.free.fr/ Research is the transformation of money to knowledge. Innovation is the transformation of knowledge to money. -- Dr. Hans Meixner___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Scinder way pour voie bus ?
On Thu, 18 Apr 2019, Florimond Berthoux wrote: > Bonjour, > > Y-a-t-il une séparation physique entre les voies ? Non. > Donc il ne faut ajouter de way, c'est la règle sur osm. Qu'est-ce qui constitue une séparation physique. Par exemple, est-ce que cela en est une : https://www.mapillary.com/map/im/Viklm7MTbhNHzY2SQIxkTQ À priori la bordure arrondie peut être franchie par les voitures qui veulent se garer, encore qu'il faut se méfier : on n'a pas toujours autant de garde au sol qu'on croît et je ne suis pas sur que toutes le Ferrari puissent passer. Autre point de repère, cette bordure est interrompue pour les entrées de parking. Et cette partie au premier plan (à gauche) ? https://www.mapillary.com/map/im/TyAnGVUfNnmsOHvQIM28Fw Là la bordure de trottoir est infranchissable (à moins d'avoir un bon 4x4). -- Francois Gouget http://fgouget.free.fr/ We are Pentium of Borg. You will be approximated. Division is futile.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] ça veut dire quoi ça :
On Sun, 3 Mar 2019, Florian_G wrote: [...] > J'ai eu le même hier. Bàl hébergée chez Gandi. Pareil ici. Boîte aux lettres chez Free. C'est bizarre que tous ces fournisseurs aient eu le même problème en même temps. Ou qu'on ait tous eu notre boîte aux lettre pleine simultanément. Cela dit Debian m'informe de temps en temps que j'ai des bounces (*) mais au moins eux ne me jettent que si je dépasse un certain pourcentage de bounces ce qui ne s'est jamais produit sur la dernière décennie... (*) À une époque c'était parce que le serveur de Free rejetait le spam de son propre chef. Rejets que certaines listes de diffusion considéraient comme un bounce. -- Francois Gouget http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Idées rendu des mers
On Thu, 31 Jan 2019, Francois Gouget wrote: [...] > Il y a peut-être le même problème sur d'autres pays... à moins que ce ne > soit spécifique aux îles. Peut-être même que ça pourrait être une > vérification Osmose. On peut avoir le même genre de divergence entre la relation boundary d'une ville et le noeud place=city/town/etc. Le noeud est facilement identifiable à partir de la relation donc vérifier la concordence des champs name serait une bonne vérification dans Osmose. Par exemple Tórshavn : https://www.openstreetmap.org/relation/2098985 -> 3 traductions https://www.openstreetmap.org/node/29023813 -> 36 traductions ! Dans la même veine wikipedia pourrait être utilisé pour identifier les traduction manquantes. Par exemple la relation boundary indique wikipedia=fo:Tórshavn. Or cette page a été traduite en Français, ce qui nous apprend que le nom Français est "Torshavn". Là encore un module Osmose proposant des traductions obtenues à partir de Wikipedia serait bien pratique (même si cela poserait probablement des problèmes de performance). D'ailleurs le noeud place=town a name:fr=Tórshavn (avec l'accent) ce qui contredit Wikipedia. Il y a probablement l'un des deux qui a tort... -- Francois Gouget http://fgouget.free.fr/ La terre est une b\xC3\xAAta...___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Idées rendu des mers
On Wed, 30 Jan 2019, Adrien Grellier wrote: [...] > – Rendu OSM-FR : > http://tile.openstreetmap.fr/?zoom=4=59.05751=-18.29251=BFF [...] > La carte OpenStreetMap est totalement indigente : Aucune mers > n'apparaît, les principales îles n'ont plus (Féroé, Orcades, > Terre-Neuves, etc.), seuls les pays apparaissent, mais dans la langue du > pays. Effectivement. "Island" m'a surpris sur la carte OSM-FR. En fait on voit "Islande" puis lorsqu'on zoome il est remplacé par "Island". J'ai regardé et la relation boundary suivante a le champ name:fr et plein d'autres). https://www.openstreetmap.org/relation/299133 Mais en creusant plus la relation multipolygon ci-dessous ne l'avait pas et je soupçonne que c'est la raison pour laquelle on avait "Island" en zoomant. https://www.openstreetmap.org/relation/7681889 J'ai ajouté le name:fr et on verra si ça aide (j'aurais peut-êter dû copier la douzaine d'autres traduction tant que j'y étais. J'y reviendrait si ça aide). Il y a peut-être le même problème sur d'autres pays... à moins que ce ne soit spécifique aux îles. Peut-être même que ça pourrait être une vérification Osmose. -- Francois Gouget http://fgouget.free.fr/ tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose et les codes UIC
On Sat, 17 Nov 2018, Jérôme Villafruela wrote: > Le 17/11/2018 à 16:47, Frédéric Rodrigo a écrit : > > Osmose utilise ça: > > https://ressources.data.sncf.com/explore/dataset/sncf-ter-gtfs/table/ > > Je ne sais pas ce que ça vaut pour les UIC. > > > Sur la "plateforme ouverte des données publiques françaises" figure la > liste des gares (fret & voyageurs). Il s'agit d'un jeu de données > produit par la SNCF : https://www.data.gouv.fr/fr/datasets/liste-des-gares Ce fichier est intéressant : * Arcueil-Cachan y est mais pas Laplace, Bagneux, Bourg-la-Reine ou Sceaux. * Par contre il y a Antony, Palaiseau-Marchandises, Orsay-Ville, Gif-sur-Yvette-Marchandise et St-Rémy-les-Chevreuses sur la même ligne, la 552000. * A chaque fois les coordonnées GPS correspondent à la gare de RER, même pour les gares "Marchandise". * Le code UIC, 87393199, ne correspond pas à ce qu'il y a sur Wikipedia soit 8775867 ! Je me demande si le code du fichier ne correspond pas plus aux voies de garage au nord de la gare de RER qu'à cette dernière. Pourtant les coordonnées du fichier semblent correspondre à la gare de RER (à moins d'une embrouille avec le système de coordonnées). Fichier : https://www.openstreetmap.org/#map=18/48.79921/2.32821 Voies au nord : https://www.openstreetmap.org/#map=18/48.80226/2.32858 Tout cela donne quand même vraiment l'impression que les gares RATP n'ont pas de code UIC. Ce serait bien si quelqu'un de la RATP pouvait le confirmer. -- Francois Gouget http://fgouget.free.fr/ Chemistry professors never die, they just fail to react.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Soyons carto, contribuons au renouvellement des serveurs OSM-France
On Sun, 18 Nov 2018, mailbd1 wrote: > Bonsoir > > > > Je pense qu'il y a un problème avec le lien vers Assoconnect ci-dessous. Je pense que le bon lien est le suivant : https://openstreetmap.assoconnect.com/billetterie/offre/90295-e-renouvellement-de-nos-serveurs -- Francois Gouget http://fgouget.free.fr/ The greatest programming project of all took six days; on the seventh day the programmer rested. We've been trying to debug the *&^%$#@ thing ever since. Moral: design before you implement.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Osmose et les codes UIC
Le traitement des codes UIC des gares par Osmose est un peu frustrant : * Osmose se plaint que le code UIC de la gare d'Arcueil-Cachan, 8775867, est incorrect. Alors c'est vrai qu'on ne le trouve pas sur beaucoup de sites. Tout ce que j'ai pu trouver qui semblerait confirmer qu'il s'agit du bon code ce sont ces deux sites: - Codes d'oblitération UIC SNCF (Transilien et Grandes Lignes) http://aurelienb.pagesperso-orange.fr/HTML/transports/obli_UIC.htm - Wikipedia Esperanto et Hongrois ! https://eo.wikipedia.org/wiki/Arcueil_-_Cachan_(stacidomo) https://hu.wikipedia.org/wiki/Gare_d%E2%80%99Arcueil_-_Cachan Cela dit, peut-être s'agit-il d'anciens codes qui étaient utilisés du temps de la ligne SNCF de Sceaux ? Sont-ils "périmés" ? * Donc Osmose se plaint que ces codes sont erronés mais le Wiki Key:uic_ref n'indique pas où trouver la base open-data qui lui permet de l'affirmer ! Pourtant Osmose doit bien s'appuyer sur quelque chose, non ? * Et ensuite Osmose tient absolument à ce que toutes les stations de métro aient un code UIC. Mais en ont-elles seulement ? Là encore, savoir s'il existe une base open-data qui les recense serait bien utile. https://osmose.openstreetmap.fr/en/map/#item=7100=13=48.8455=2.3462=3 * Évidemment lorsque l'on active l'item 8051, "gare, intégration possible", il n'y a plus personne. Faut-il marque toutes ces gares en faux positif ? Cela a-t-il un sens de vouloir que des gares de métro aient un code UIC ? https://osmose.openstreetmap.fr/en/map/#item=8051=13=48.8455=2.3462=3 Note : J'ai bien trouvé un fil sur ce sujet mais gmane a perdu le message qui aurait pû être intéressant. https://lists.openstreetmap.org/pipermail/talk-fr/2014-November/072929.html -- Francois Gouget http://fgouget.free.fr/ Sufficently advanced incompetence is indistinguishable from malice.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] opening_hours contre les parcs parisiens
On Fri, 26 Oct 2018, Philippe Verdy wrote: > Le jeu. 25 oct. 2018 à 16:45, Francois Gouget a écrit : [...] > Pas tout à fait : > * le point-virgule dans un attribut indique une liste non-ordonnée (dont > les éléments peuvent être librement permutés sans changement > d'interprétation) : c'est valable normalement pour tout attribut OSM. [...] > Ce qui n'est pas le cas dans l'exemple ici car le premier élément de la > liste séparée par point-virgule "08:00-17:45" couvre une bonne partie du > second (qui indique des horaires différents pour certaines dates). > > Il ne devrait donc pas y avoir de point-virgule du tout dans ton exemple, Clairement opening_hours ne suit pas la règle. Mais mieux vaut suivre un standard, même pas très uniforme, plutôt que faire autre chose qu'aucune application ne saura décoder. On peut aussi changer la règle mais je ne me lancerai pas là-dedans. Ce qui est plus intéressant c'est que l'outil d'évaluation semble avoir un bug lié au passage à l'heure d'hiver. http://openingh.openstreetmap.de/evaluation_tool/ Par exemple pour "10:00-20:00" il affiche bien "open 10:00 to 20:00" pour le 2018-10-28 mais sur la même ligne le graphe retarde d'une heure et indique 11h à 21h ! On retrouve le même problème pour le passage à l'heure d'été le 2018-03-25 mais cette fois-ci le graphe a une heure d'avance. -- Francois Gouget http://fgouget.free.fr/ All generalizations are false, including this one. -- Mark Twain___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] opening_hours contre les parcs parisiens
On Thu, 25 Oct 2018, Megan Parat wrote:
[...]
> En utilisant les particularités des séparateurs de règles, et un ordre
> particulier, j'ai cette expression d'opening_hours qui comporte 161
> caractères :
>
> 08:00-17:45; PH,Sa,Su 08:00-09:00 off, Mar 01-Mar Su[-1] 17:45-19:00,
> Oct 01-Oct Su[-1] 17:45-19:30, Mar Su[-1]-Apr 30,Sep 17:45-20:30, May
> 01-Aug 31 17:45-21:30
>
> Je crois qu'elle est valide.
Joli !
Après consultation de la "spécification complète" (dont je ne trouve le
lien que dans la version anglaise du wiki), je crois aussi qu'elle est
valide.
Là où la page opening_hours laisse penser que la virgule ne peut être
utilisée que dans les listes (d'années, de mois ou d'heures), la
spécification complète indique qu'on peut l'utiliser partout où on peut
utiliser le point-virgule :
| opening_hours =
| : { }
| any_rule_separator: ';' | ',' | '||'
Il même prévu explicitement qu'on puisse l'utiliser ainsi :
| An additional rule is treated exactly the same as a normal rule,
| except that an additional rule does not overwrite the day for which
| it applies (unlike the which starts always
| with a new, empty day, deleting any previous rules applying for the
| given day). Note that an additional rule does not use any data from
| previous or from following rules. If time wraps over midnight are
| involved then you will probably also need to use additional rules to
| not overwrite the part which wraps into the next day. It can also be
| used to specify different comments for one day. Read more (including
| some examples) in this issue on github.
|
| Because of the peskiness that the is the
| same token as the token to separate lists (e.g. { ,
| }) the , (comma) is only interpreted as
| if it follows after one of those symbols:
|
| 12:00-14:00, We 16:00-18:00
| 12:00-14:00 unknown, We 16:00-18:00
| 12:00-14:00 "call us", We 16:00-18:00
Je note aussi l'utilisation de "Mar Su[-1]-Apr 30". J'avais essayé "Mar
Su[-1]-Apr" qui ne marche pas. Si on spécifie un jour de début ou de fin
il faut aussi spécifier un jour de l'autre coté même si on pourrait
penser que le mois est suffisant et que le jour est implicitement
évident.
--
Francois Gouget http://fgouget.free.fr/
A particle is an irreducible representation of the Poincaré Group - Eugene
Wigner___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] opening_hours contre les parcs parisiens
Je crois que les employés qui font les horaires des parc parisiens détestent OpenStreetMap. Sinon comment expliquer des horaires pareils : https://www.mapillary.com/map/im/LHvLpzzp3G_EbWV5tTs9Xw (le Square Louise-Michel présente le même défi) Bon, j'ai quand même réussi à trouver un champ opening_hours qui, je crois, représente correctement ces horaires : 8:00-20:30;PH,Sa,Su 9:00-20:30;May-Aug 8:00-21:30;May-Aug PH,Sa,Su 9:00-21:30;Oct-Feb 8:00-17:45;Oct-Feb PH,Sa,Su 9:00-17:45;Oct 1-Oct Su[-1] 8:00-19:30;Oct 1-Oct Su[-1] Sa,Su 9:00-19:30;Mar 1-Mar Su[-1] 8:00-19:00;Mar 1-Mar Su[-1] PH,Sa,Su 9:00-19:00 Notez que j'exploite le fait qu'il n'y a pas de jours fériés en octobre (autres candidats : septembre et février). Mais j'ai quand même dû faire l'impasse sur le 0 initial des heures d'ouverture pour que ça tienne en 251 caractères. Est-ce catastrophique ? Quelqu'un a-t-il des idées pour compresser la chose ? On peut éventuellement laisser tomber les jours fériés et obtenir ça (251 caractères aussi) : 08:00-20:30;Sa,Su 09:00-20:30;May-Aug 08:00-21:30;May-Aug Sa,Su 09:00-21:30;Oct-Feb 08:00-17:45;Oct-Feb Sa,Su 09:00-17:45;Oct 1-Oct Su[-1] 08:00-19:30;Oct 1-Oct Su[-1] Sa,Su 09:00-19:30;Mar 1-Mar Su[-1] 08:00-19:00;Mar 1-Mar Su[-1] Sa,Su 09:00-19:00 Ou alors on laisser carrément tomber l'heure d'ouverture des week-end et jours fériés et on laisse faire l'ajustement par l'utilisateur : 08:00-20:30; PH,Sa,Su 09:00-20:30;May-Aug 08:00-21:30;Oct-Feb 08:00-17:45;Oct 1-Oct Su[-1] 08:00-19:30;Mar 1-Mar Su[-1] 08:00-19:00 || PH,Sa,Su "ouvre à 9h les week-end et jours fériés" -- Francois Gouget http://fgouget.free.fr/ Un western sans indien c'est comme une police sans serif. -- John Wayne___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bien qu'étant abonné, je ne reçois pas tous les mails
On Sat, 20 Oct 2018, Gwenaël Jouvin wrote: > Bonsoir, > > J’ai le même problème et je remarque que nous sommes tous deux chez la Poste. > > Je suppose que c’est dû à cet hébergeur. J’ai subi de gros problèmes > de réception de messages sur cette boîte il y a quelques mois, des > messages arrivaient 2, 3 jours après leur envoi… Le filtre anti-spam de la poste a de gros problèmes. Les email manquants ne seraient-ils pas dans un dossier spam accessible uniquement sur le webmail de la poste? D'après ce que j'ai pu glaner sur Internet malheureusement ce filtre anti-spam n'est pas désactivable. Mais on peut définir d'autres filtres qui ont la précédence. Le contournement consiste alors a définir un premier filtre qui dit que tous les email dont le sujet contient un 'a' doivent être envoyés directement dans la boite de réception ; puis un deuxième filtre qui dit la même chose pour tous ceux dont le sujet ne contient pas de 'a'. -- Francois Gouget http://fgouget.free.fr/ Linux: the choice of a GNU generation___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Plus de BDOrtho dans iD ?
On Mon, 6 Aug 2018, marc marc wrote: > Le 06. 08. 18 à 06:26, Francois Gouget a écrit : > > > > Depuis une ou deux semaines le fond BDOrtho IGN ne s'affiche plus dans > > l'éditeur ID (à la place j'ai un fond tout noir). > > > > C'est juste moi ? Est-ce un problème temporaire ? > > chez moi cela fonctionne en ce moment > pas constaté de soucis récement. > n'aurais-tu pas privay badger ou extention du genre qui aurait > fait un blocage indésirable ? Bien vu. C'était Privacy Badger. C'est terrible. Privacy Badger arrive a surbloquer assez fréquemment pour que ça ne soit pas la première fois, mais pas assez fréquemment pour que j'y pense d'une fois sur l'autre. Bon j'ai corrigé le surblocage et je l'ai signalé à tout hasard. -- Francois Gouget http://fgouget.free.fr/ Dieu dit: "M-x Lumière". Et la lumière fut.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Plus de BDOrtho dans iD ?
Depuis une ou deux semaines le fond BDOrtho IGN ne s'affiche plus dans l'éditeur ID (à la place j'ai un fond tout noir). C'est juste moi ? Est-ce un problème temporaire ? -- Francois Gouget http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, it's computer science.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] idée idiote pour les apk
On Sun, 29 Jul 2018, Jo wrote: > Si les devs étaient disposés à faire cela, ils l'auraient déjà fait il y a > longtemps, ou Maps.Me n'aurait pas inventé un nouveau format. Maps.me est une chose : c'est une application propriétaire avec ses propres priorités et la compatibilité avec Osmand ne va forcément pas en faire partie. Mais être obligé d'avoir de la data pour visualiser la carte dans StreetComplete alors que j'ai les cartes offline dans Osmand c'est assez idiot. Pareil pour la myriade d'autres applications OpenStreetMap open-source. Bon je suppose que le problème c'est que StreetComplete ne fait que récupérer des tuiles alors qu'Osmand fait un rendu vectoriel, soit deux implémentations complètement différentes. C'est justement là qu'un service commun de rendu de fond de carte serait utile : moins de code, partage des cartes locales, cache de tuiles commun, réduction de la consommation de données, etc. -- Francois Gouget http://fgouget.free.fr/ Be careful of reading health books, you might die of a misprint. -- Mark Twain___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise à jour des POIs
On Fri, 20 Jul 2018, Rpnpif wrote: [...] > Le format des horaires dans OSM permet déjà les exceptions des congés > d'été et cela marche bien. On peut y mettre des horaires très > compliqués sur l'année. Le problème n'est pas qu'il est impossible de rentrer les congés annuels, c'est qu'il y a de grandes chances qu'ils changent chaque année, ce qui veut dire faire le tour de tous les commerces et restaurants tous les ans. [...] > Même un fichier texte sur le site d'un artisan peut-être difficile à > gérer pour un non-informaticien. L'idéal serait un appel à une API > distante appelable en AJAX ou similaire sur un site communautaire hors > GAFAM et affichable sur le site de l'artisan (ou autre entreprise). Euh. Excuses moi juste un instant, je me mets à la place d'un non-informaticien : Ajax... il faut bien prendre le modèle vitre ? Parce que j'ai peur qu'Ajax Sol ne raye l'écran de mon ultrabook. Bon, d'accord, je suppose que l'idée c'est que le site communautaire leur donne un bout de code à copier/coller dans leur propre site. Mais ce site communautaire peut tout ausi bien leur donner un fichier texte. Dans tous les cas je préfèrerai une solution qui leur permette de rester maître de leurs informations de bout en bout s'ils le souhaitent. > Beaucoup plus simple : faire de la propagande pour que ces entreprises > entrent elle-même leurs horaires sur une page OSM réservée à ça avec une > interface à la yohours mais en plus puissant pour permettre d'entrer > ces fameuses périodes d'horaires d'été. Je pense que la propagande, Google la fait déjà... mais pour Google Maps. Alors si on dit aux artisans : faites-le *en plus* sur OpenStreetMap ça ne marchera pas. Et je ne pense pas que Google soit motivé pour venir chercher les informations dans OpenStreetMap. Déjà la licence ne conviendrait probablement pas. -- Francois Gouget http://fgouget.free.fr/ Good judgment comes from experience, and experience comes from bad judgment -- Barry LePatner___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Mise à jour des POIs
On peut mettre pas mal d'information sur les commerces et restaurants dans OpenStreetMap. Avoir ces informations à disposition hors ligne sur un téléphone est très pratique. Mais des informations comme les horaires d'ouverture ont pas mal tendance à changer, notamment pour les congés annuels, et sont donc difficiles à maintenir à jour. En plus, plusieurs sites s'occupent de tenir ces informations à jour : Google Maps bien sûr, mais aussi les Pages Jaunes, Le Figaro, et pas mal d'autres sites spécialisés comme la Fourchette, Travelocity, etc. Pour un commerçant aller mettre tous ces sites à jour n'a aucun sens. Et c'est aussi un gros gaspi que chaque site envoie du monde pour aller collecter les horaires. Ce qu'il faudrait c'est que les commerces disposent d'une méthode standard pour publier leurs horaires et autres informations (du type de cuisine à la présence d'un distributeur de billet), avec une licence qui autorise la réutlisation par tous les acteurs (de Google à OpenStreetMap). Il y a un modèle qui serait simple : robots.txt. Ce fichier est standardisé et indique à n'importe quel moteur de recherche, aussi bien Google que Bing, quelles pages ne doivent pas être indexées. Donc on pourrait définir un standard où il suffirait à tout commerce, restaurant ou artisan ayant un site web de mettre un fichier poi.txt dans la racine dudit site pour publier une bonne fois pour toutes les informations utiles pour leur commerce, restaurant ou service. Pour ceux qui n'ont pas leur propre site mais, par exemple, juste une page FaceBook, ils pourraient mettre le fichier poi.txt quelque part dans leur espace. Les services utilisant le fichier poi.txt auraient plus de mal à le trouver, mais une fois la bonne URL repérée ils obtiendraient toutes les mises à jour automatiquement. Cette solution pourrait aussi être utilisée par les chaînes qui n'ont qu'un site pour tous leurs établissements. D'ailleurs les banques et supermarchés, par exemple, ont déjà tous une page par établissement. Il leur suffit donc d'ajouter une page au format poi.txt. Une autre option serait de permettre le stockage des informations de plusieurs établissements dans un seul fichier poi.txt. Se pose alors le problème de l'identifiant de chaque site : adresse postale (avec les problèmes de majuscule / minuscule, accents, etc) plus nom, le SIRET (valable uniquement en France), etc. Et pour ceux qui n'ont vraiment pas de site web, une association à but non lucratif pourrait monter un site web pour stocker ce type d'information, avec une URL par établissement. Là aussi il faudrait que chaque fichier poi.txt contienne des données permettant d'identifier l'établissement auquel il se rapporte. Quant aux droits d'accès, si un modèle où n'importe qui peut éditer les informations type wiki ne convient pas il sera temps de trouver d'autres solutions. Comment utiliser ces données dans OpenStreetMap ? Et bien à partir du moment où le champ website est positioné un outil type Osmose pourrait tester la présence du fichier poi.txt dans la racine du site et proposer l'intégration des données qu'il contient. Mais d'autres modèles sont aussi possibles : par exemple l'intégration automatique des données, un plugin proposant leur intégration dans Josm, ou même laisser cette intégration à d'autres outils comme Osmand ou Maps.me. Lorsque le fichier poi.txt ne se trouve pas dans la racine du site, le contributeur pourrait à la place renseigner le champ poi_url dans OpenStreetMap afin que les outils sachent où récupérer cette information. Pour le format des données il faut quelque chose de raisonablement simple à utiliser et extensible. J'aurais tendance à reprendre les champs déjà utilisés dans OpenStreetMap, mais à la limite le format importe peu du moment que les données sont là dans un format standard et utilisable par tous. Bien sûr il reste plein de détails à régler. Mais cet email est déjà bien assez long. -- Francois Gouget http://fgouget.free.fr/ A man can fail many times, but he isn't a failure until he begins to blame somebody else. -- John Burroughs___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tramway sur pneu - railway=tram ou highway=bus_guideway
On Mon, 16 Jul 2018, Thomas Ruchin wrote: > Bonjour > > Il existe en île de France 2 lignes de tramway sur pneu. > https://www.openstreetmap.org/relation/5136037 --> le T6 > https://www.openstreetmap.org/#map=19/48.95351/2.35815 --> Le T5 > > Et pour ces 2 lignes, de multiples conflits d'édition entre > - railway=tram et highway=bus_guideway > > A titre personnel, je suis choqué d'un moyen de transport qui n'est pas sur > rail puisse comporter le tag "railway". En même temps il y a quand même un rail de guidage. Du coup, comme pour tout matériel sur rail, pas de volant, impossible d'aller là où le rail ne va pas, etc. Bref c'est aussi similaire à un tram classique que le métro de la ligne 6, sur pneumatique lui aussi, l'est d'un métro classique. Donc ça ne me choque pas. -- Francois Gouget http://fgouget.free.fr/ 145 = 1! + 4! + 5!___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Attribution eaupotable.info
On Wed, 11 Jul 2018, Philippe Verdy wrote: > En l'occurence, l'annuaire "service-public.fr" ne crédite pas OSM puisqu'il > affiche maintenant le fond Géoportail Le site affiche le fond OpenStreetMap si on demande à voir une commune, et le fond Géoportail si on demande à voir une région ou un département. Comparer : https://lannuaire.service-public.fr/grand-est https://lannuaire.service-public.fr/grand-est/haut-rhin avec : https://lannuaire.service-public.fr/grand-est/haut-rhin/mairie-68271-01 J'avais déjà signalé cette bizarrerie (*). https://lists.openstreetmap.org/pipermail/talk-fr/2018-May/088683.html (*) Vous aviez d'ailleurs fait une réponse assez détaillée et un peu hors sujet. Maintenant je me dit que vous aviez peut-être raté le point de mon email... -- Francois Gouget http://fgouget.free.fr/ If you think the whole world revolves around you, quit staring at the GPS display while driving.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de projet du mois de Juillet (ce que vous allez découvrir va vous surprendre)
On Mon, 9 Jul 2018, François Lacombe wrote: > Bonjour à vous, > > Le 9 juillet 2018 à 11:36, Francois Gouget a écrit : > > > Ca serait sympa d'avoir un module Osmose pour faire l'intégration, un > > peut comme pour les panneaux Mapillary : une ligne haute tension est > > signalée à proximité mais aucun objet OSM correspondant n'a été trouvé. > > > > Aux dernières nouvelles ce n'est pas possible pour les objets linéaires. > Osmose ne fait de la conflation que sur les points. > Nous ne pourrions dans tous les cas pas proposer de correction via Osmose : > il manque les poteaux dans les données Enedis, et ce sont pourtant les > seuls sommets qui doivent composer les lignes OSM. L'absence des poteaux dans les données Enedis ne me paraît pas rédihibitoire. Pour chaque portion de ligne qui va tout droit leur fichier contient un segment décrit par les coordonnées de ses extrémités. D'après ce que j'ai pu en voir leurs coordonnées sont assez précises. Donc à proximité de chaque extrémité on devrait retrouver un poteau dans OSM. Je ne sais pas si on peut aussi vérifier que le poteau de départ est bien connecté au poteau d'arrivée mais la détection des poteaux isolés et des lignes incomplètes devrait déjà inciter les contributeurs à ajouter les lignes manquantes. Bien sûr cela ne permettra pas non plus de vérifier que le contributeur OSM n'a pas raté des poteaux intermédiaires. Mais cela permettra d'identifier les morceaux de ligne manquants et c'est déjà beaucoup. En particulier cela permettra de s'assurer que le réseau est correctement connecté et complet. Parce que lorsque le réseau a trois au quatre bifurcations de suite il est facile de continuer sur la branche 'principale' et d'oublier de revenir en arrière pour ajouter celles qu'on a sauté. > Ca se décrit comme ca : > power=line OU power=minor_line (faut choisir, perso c'est line) > voltage=2 > operator=Enedis > cables=3 J'ai une question là-dessus : comme j'ai travaillé à partir des photos j'ai renseigné ce que je voyais, c'est à dire cables=3. Par contre le voltage ne se voyant pas sur les photos je ne l'ai pas positionné. Par contre maintenant je voie que mes lignes correspondent à celles du fichier Enedis. Sait-on si ce fichier ne contient que des lignes à 2 V ? (j'ai pas réussi à le voir d'après leur doc) Déjà dessus je ne voie pas les lignes à 9 V qui passent dans la région donc c'est bon signe. Bref, serait-il présomptueux d'ajouter voltage=2 sur les lignes que j'ai ajouté même si je ne suis pas allé vérifier avec mon voltmètre ? ;-) Et pour les transformateurs il faut transformer=distribution, pas transformer=minor_distribution ? Ça semble incohérent avec les power=substation. https://wiki.openstreetmap.org/wiki/Tag:power=substation#Substation_values https://wiki.openstreetmap.org/wiki/Tag:power=transformer#Transformer_values -- Francois Gouget http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de projet du mois de Juillet (ce que vous allez découvrir va vous surprendre)
On Sun, 1 Jul 2018, François Lacombe wrote: > Le 1 juillet 2018 à 20:24, deuzeffe a écrit : > > > > > J'ai commencé à intégrer quelques poles et ce qui devait arriver arriva, > > osmose me reproche violettement que les poteaux sont isolés (il a de > > l'humour...) : bah oui, il manque le fil, je sais... > > > > Osmose a raison, et les fils en questions peuvent être trouvés ici > https://data.enedis.fr/explore/dataset/reseau-hta/map/ Ca serait sympa d'avoir un module Osmose pour faire l'intégration, un peut comme pour les panneaux Mapillary : une ligne haute tension est signalée à proximité mais aucun objet OSM correspondant n'a été trouvé. Bien sûr il ne faudrait pas en mettre tout les mètres, mais peut-être un par segment où par sommet présent dans les données Enedis. D'ailleurs, s'agissant des lignes à 2V, on arrive à les voir sur la BDOrtho : au plus fort grossissement on arrive à distinguer trois ombres ou traits un peu plus clairs suivant le terrain. Les poteaux eux se voient généralement bien, sauf lorsqu'il y a des arbres autour. Par exemple : https://www.openstreetmap.org/#map=19/45.97491/0.78542 On arrive même à distinguer les poteaux qui ont un transformateur à la forme de l'ombre. Et puis si en plus la ligne se termine juste à coté d'un hameau c'est aussi un gros indice. https://www.openstreetmap.org/#map=19/45.91849/0.75848 Du coup on arrive assez bien à reconstituer les lignes, même sans la carte Enedis. Par contre il est facile de rater une bifurcation. C'est là qu'un module Osmose serait utile pour revenir compléter. -- Francois Gouget http://fgouget.free.fr/ "Utilisateur" (nom commun) : Mot utilis\xC3\xA9 par les informaticiens en lieu et place d'"idiot".___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose: Intégration de panneaux depuis Mapillary
On Wed, 20 Jun 2018, Frédéric Rodrigo wrote: [...] > Il s’agit d'utiliser les panneaux détectés dans les photo Mapillary > pour les comparer aux tags dans OSM et détecter quand un panneau n'a > pas d'application sur les voies. On chercher les tags des effets du > panneau et pas le cartographie du panneau lui même. > > C'est pour l’instant disponible à titre expérimental sur > l'Île-de-France, mais c'est possible de le généraliser. Super ! Ca va rendre la reconnaissance de panneaux de Mapillary très nettement plus utile. Sur un de mes premiers tests je tombe sur un faux positif... de Mapillary qui a pris une fenêtre pour un panneau. https://osmose.openstreetmap.fr/fr/error/18327340825 Je peux le marquer comme faux positif dans Osmose mais en fait ce n'est pas Osmose qui fait l'erreur. Mais je n'ai pas vu de moyen de signaler le problème à Mapillary. Quelqu'un sait-il comment faire ? Sinon est-ce ok de les marquer comme faux positif dans Osmose ? D'après une présentation faite par Mapillary au SOTM FR2016 leur algos de deep learning sont sensés être capable de réaliser qu'un panneau apparaissant sur 3 photos ne correspondaient en fait qu'à un seul objet et de déterminer l'emplacement de cet objet. Est-ce qu'Osmose s'appuie là-dessus ou est-ce qu'il signale le problème pour chaque photo ? Je demande parce qu'il semble y avoir pas mal de répétition par endroits, plus que sur la carte Mapillary. Par exemple le panneau gendarme couché ici : http://osmose.openstreetmap.fr/fr/error/18327339978 Sinon Mapillary a un gros problème avec les limites de vitesse : Interdiction aux plus de 10 t -> Limite à 100 km/h. Bus limité à 70 km/h -> Croit qu'il y a un panneau 70 km/h dans la rue (alors qu'avec leur segmentation sémantique (i.e. identification des objects comme les voitures, bus, camions) il devrait voir que le panneau est sur le bus et donc l'ignorer). Camion de location avec pub pour le tarif à 19€ -> Limite à 100 km/h. Par contre ils sont très efficaces pour les attributs traffic_calming manquants (et il faut bien dire qu'il en manque beaucoup). Mais même avec ces défauts je pense que ça sera très utile. Et puis Mapillary est sensé améliorer leurs algos donc cela ne peut que s'arranger avec le temps. -- Francois Gouget http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Article sur l'open-data à Redon
On Wed, 6 Jun 2018, osm.sanspourr...@spamgourmet.com wrote: > > VincentdeCT > vdct pour les intimes ;-) > > Louis-Julien, tant qu'à faire tu pourras regarder s'ils peuvent publier les > photos prises par les camions chargés de la collecte des ordures ménagères : > ça serait un plus pour cartographier depuis son fauteuil. N'est-ce pas déjà le cas ? D'après cet ancien article ils publient les photos sur Mapillary : https://www.ouest-france.fr/leditiondusoir/data/891/reader/reader.html?t=1481131240#!preferred/1/package/891/pub/892/page/12 -- Francois Gouget http://fgouget.free.fr/ The last time religion ruled, it was called the dark ages.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Oubli de mention OSM...
On Mon, 28 May 2018, HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT GE APPUI PERFORMANCE) wrote: > Et ça, c’est pire encore : > https://lannuaire.service-public.fr/grand-est/ardennes/mairie-08338-01 > Pourtant signalé il y a près de 15 jours ….. Bizarre. On dirait que la vue départementale utilise Geoportail alors que la carte des mairies utilise OpenStreetMap : Par exemple au niveau du virage à angle droit de la rue de Violettes : Geoportail met le nom à tort sur une voie privée qui rejoint la rue du Naegelberg, mais a une voie qui manque sur OpenStreetMap. Comparer : https://lannuaire.service-public.fr/grand-est/haut-rhin https://lannuaire.service-public.fr/grand-est/haut-rhin/mairie-68271-01 Du coup pas trop étonnant que leur site ne sache plus à quel saint s'attribuer ! -- Francois Gouget http://fgouget.free.fr/ If you think the whole world revolves around you, quit staring at the GPS display while driving.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Osmose : Ajout de DELETE TAG sur les stations essence
Osmose veut effectuer plein de mises à jour sur les stations essence mais je ne comprends pas bien ce qu'il propose comme mise à jour : Par exemple : https://osmose.openstreetmap.fr/en/map/#=8202=17=48.9327971=2.2325832=3 + fuel:e85 = DELETE TAG aechohve0Eire4ooyeyaey1gieme0xoo + fuel:lpg = DELETE TAG aechohve0Eire4ooyeyaey1gieme0xoo - fuel:octane_95 À quoi correspondent ces nouveaux champs positionés à DELETE TAG ? Cela ne semble pas correspondre à des carburants que la station ne vend plus puisqu'Osmose propose de juste supprimer le champ fuel:octane_95. Deux poids deux mesures ? Et aussi, quel type de vérification faire avant de valider les mises à jour ? Contrôle sur le terrain ? -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ All generalizations are false, including this one. -- Mark Twain___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] sauvegarde des photos versées sur Mapillary
On Thu, 17 May 2018, Cyrille37 OSM wrote: > Bonjour, > > Juste une question de pérennité, sans aucune paranoïa : quid du > patrimoine versé sur Mapillary si l'entreprise venait à avoir des > problèmes ? Ne serait-il pas intéressant de trouver un partenariat pour > avoir une sauvegarde des photos versées ? > OSM France ou commons.wikimedia.org ou ONU ou UNESCO ou ... ? Je garde une copie de mes photos au cas où mais c'est évidemment pas une solution globale. Plus qu'une solution de sauvegarde mon but serait d'envoyer ces photos sur OpenStreetCam un jour : je n'ai pas de raison de privilégier un acteur par rapport à un autre. Mais ce n'est pas particulièrement simple et je n'ai pas encore eu le temps de me pencher sérieusement sur le problème. Pour l'instant ma priorité c'est les photos 360. Néamoins, uploader les photos sur les deux services serait un premier pas vers plus de pérennité. -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ Un western sans indien c'est comme une police sans serif. -- John Wayne___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import station essence
On Fri, 30 Mar 2018, Philippe Verdy wrote: > The opening_nours specs allows to specify the kind of service it targets > Automats are more and more frequent in various shops (not just fuel > services). > When I see a bakery open from Tuesday to Sunday from 8:00 to 18:00, but > with also an automata open 24/7 for some basic bread products, I would > still not say it's open 24/7, I just tag the automat. So two amenity=fuel points? How would it work wrt ref:FR:prix-carburants and other tags like name? Won't that cause applications to render two service stations which would be a bit weird? -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ May your Tongue stick to the Roof of your Mouth with the Force of a Thousand Caramels. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import station essence
On Fri, 30 Mar 2018, Philippe Verdy wrote: [...] > A "24/7 automat" does not mean the station is open 24/7; so the > opening_hours should not apply to the presence of such automats which > should be completely ignored and tagged separately. How? The English wiki seems to indicate that there is no way to represent different levels of service at this time: | Add the opening hours using the key opening_hours=*. There are not | agreed upon tags for different levels of service, but both | self_service=yes/no and full_service=yes/no and automated=yes/no have | been used. Note that there is no way to correlate self_service, full_service and automated with opening_hours. Most people only care that they can go and get fuel at any time. So this information needs to be preserved somehow. I would also note that not all stations have 24/7 automats, particularly for those in car repair shops. Nobody wants to make a 4 kilometers detour just to find that they cannot get fuel because it's 7 pm or a week-end. So if only one information can be preserved I would say it's the 24/7 one. -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ A man can fail many times, but he isn't a failure until he begins to blame somebody else. -- John Burroughs ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger GPS ?
On Tue, 27 Mar 2018, David Marchal wrote: > L’intérêt est, je pense, d’avoir un boîtier discret, simple et pas > trop cher, qui ne serve qu’à ça pour ne pas avoir besoin d’un > smartphone au prix supérieur et plus complexe. Et se passer d'OsmAnd~, Street-Complete et Mapillary / OSC ? Impensable ;-) ! > Ça pourrait viser, [...] ceux qui n’en ont pas les moyens On peut trouver un bon smartphone à 150€ (Zenfone 2 ZE551ML). Les plus basiques commencent à 80€ à tout casser et je n'ai pas l'impression que leurs GPS soient tellement pire. Donc pour que l'opération ait du sens d'un point de vue strictement économique il faudrait que ce GPS maison coûte moins de 60€ (80€ - 20€ pour un dumbphone), ou moins de 95€ si on retient un prix moyen. [...] > Et puis, il y a bien sûr l’histoire de la précision, qui risque fort > d’être meilleure, ce qui est un gros plus quand on modélise sur OSM. Je suis sceptique sur les chances d'avoir une précision significativement meilleure en restant sur les technologies standard et pas chères ; c'est à dire qui n'exploitent que le signal L1 et sans techniques type GPS différentiel. L'email de Stéphane Péneau aurait tendance à me renforcer dans ces convictions. Mais je ne suis pas un spécialiste des GPS alors peut-être que je suis trop pessimiste. Ou alors j'attends trop des GPS. Une précision de +/- 1 m en ville et en forêt, là ça changerait la donne. Mais déjà à +/- 3 m... bof. -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ In theory, theory and practice are the same, but in practice they're different.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger GPS ?
On Tue, 27 Mar 2018, Stéphane Péneau wrote: > Je viens de faire un test : > 5 récepteurs Gps+Glonass : > - Smartphone Sony Xperia Ray > - Smartphone HTC One mini > - Tablette Nexus 9 > - Tablette Nvidia Tablet Shield K1 > - Navspark GL. > > Le Navspark a son antenne sur le toit. > > Le résultat est visible ici : > http://umap.openstreetmap.fr/fr/map/comparaison-recepteurs-gnss_208577 Que peut-on en conclure ? Je ne suis pas expert du coup tout ce que je voit c'est que la trace bleue et la rouge me semblent pire que les autres (voir le parking un peu avant la boucle et sorties de route dans la grande ligne droite avant). Les autres sont similaires ce qui semble indiquer qu'avoir une antenne sur le toit n'apporte pas grand chose. La trace orange a perdu le signal pendant un bon moment et en ville, dans le coin nord-ouest, elle fait quelques écarts significatifs. Pas terrible non plus. Pas en reste les traces jaune et vertes font elles aussi régulièrement des écarts en ville, peut-être un peu moins prononcés que la trace orange. Mais dans tous les cas ça ne fait pas terrible sur une trace Mapillary par exemple. J'aurais tendance à dire qu'il n'y en a pas un pour rattraper les autres. Mais peut-être ai-je raté les points importants ? -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger GPS ?
On Thu, 22 Mar 2018, Philippe Verdy wrote: > < 1 m en montagne c'est difficile pour une simple raison: le manque de > visibilité d'une part et les réflexions/chemin multiples sur les parois, et > souvent aussi la végétation en zone forestière. Particulièrement sans > correction si c'est l'objectif et encore plus en monofréquence. [...] > L'absence de ces corrections basées sur d'autres observations et mesures > prises par d'autres satellites ou stations d'observation au sol fait qu'on > ne peut espérer mieux qu'une précision de 30 mètres en montagne. On peut > toujours rêver mais il faut comprendre un peut comment et sur quelles > mesures se basent les systèmes GNSS. Du coup quel serait l'intérêt d'un tel GPS par rapport à un smartphone ? Il ne reste guère que l'autonomie et le plaisir d'avoir du matériel libre mais est-ce vraiment suffisant ou cela ne le condamne-t-il pas à être diffusé à une douzaine d'exemplaires seulement ? La précision c'est vraiment le principal reproche que je ferait au GPS de mon smartphone. Paradoxalement en voiture elle est suffisante pour du Mapillary mais dès que je me promène en ville à pied il divague beaucoup (je soupçonne qu'il utilise la vitesse pour restreindre le champ des possibles de la prochaine position). Étant donné les problèmes de réflexion et de masquage des satellites je ne vois guère de solution hors passer justement à un système travaillant à partir de la L5. La fréquence de mise à jour de la position est potentiellement un deuxième problème mais il est tout aussi probable que ce soit juste un bug de Mapillary. Donc, pour moi, un GPS séparé pourrait éventuellement être intéressant mais uniquement s'il offre une meilleure précision. Or il y a à présent assez de satellites qui émettent un signal L5 et on nous promet de nouveaux smartphones avec des puces GPS qui l'utilisent pour 2018. Du coup j'attendrai peut-être simplement de changer de smartphone. https://spectrum.ieee.org/tech-talk/semiconductors/design/superaccurate-gps-chips-coming-to-smartphones-in-2018 -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ A man can fail many times, but he isn't a failure until he begins to blame somebody else. -- John Burroughs___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] opendata : les batis et leur hauteur à Paris
On Wed, 28 Feb 2018, Erwan Salomon wrote: > celui qui fait le rendu c’est F4map > petit exemple de rendu un peu travaillé > http://demo.f4map.com/#lat=47.7361783=-3.4271357=19 > <http://demo.f4map.com/#lat=47.7361783=-3.4271357=19> > l’église, mais aussi 100m au sud la médiathèque Ah. Bien. Mais c'est bizarre que pour un rendu en 3D ils ne prennent pas en compte le relief. Parce que bon, Montmatre plat ça fait un peu bizarre. Et comme ça semble utilisé pour l'immobilier le relief devrait quand même avoir une importance, y compris pour l'ensoleillement (y en a qui sont jamais contents ;-). C'est quand même une super utilisation des données OpenStreetMap et ça donne envie d'aller se promener avec StreetComplete pour renseigner toutes les hauteurs de bâtiments et formes de toits. Ça donne aussi envie d'acheter une caméra 360 pour mieux voir les façades et pouvoir compter le nombre d'étages. -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ Un western sans indien c'est comme une police sans serif. -- John Wayne___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] opendata : les batis et leur hauteur à Paris
On Tue, 27 Feb 2018, Nicolas Bétheuil wrote: > Bonjour, > > L'autre jour j'avais trouvé un site d'immobilier qui m'avait > impressionné : bienici.com Je vous laisse aller faire un tour si ça > vous intéresse c'est ni le sujet ni une pub. Ils réutilisent les > données d'OSM pour les hauteurs de bâtiments. Forcément j'ai été voir > chez moi et les hauteurs ne sont pas renseignées. Le rendu est sympa. D'après mes tests ils se servent des champs building:levels, roof:levels, roof:shape et peut-être roof:material (et peut-être encore d'autres). Et en plus ils mettent à jour leurs données plutôt rapidement : j'ai complété quelques bâtiments cette nuit à partir de Mapillary et aujourd'hui le rendu les prend en compte ! -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ Linux: the choice of a GNU generation___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Interprétation de lanes et lanes:bus
J'ai hérité d'un certain nombre d'erreurs Osmose sur l'avenue du Prado à Marseille : https://osmose.openstreetmap.fr/en/error/1594768 sur voirie bidirectionnelle, (“lanes”=8) ≠ (“lanes:forward”=3) + (“lanes:backward”=3) + (“lanes:both_ways”=None) − (0 sur voies partielles) − (non fullwidth “forward”=0) − (non fullwidth “backward”=0 sur voies partielles) − (“both_ways”=0 sur voies partielles) Le problème c'est ce “lanes”=8. Sur la voie on a : lanes = 6 lanes:bus = 2 et aussi, mais je ne pense pas que cela influe le nombre total de voies : access:lanes:backward = yes|yes|no access:lanes:forward = yes|yes|no bus:lanes:backward = yes|yes|designated bus:lanes:forward = yes|yes|designated D'après le wiki "La clé lanes=* doit être utilisée pour indiquer le nombre total marquées de voies." https://wiki.openstreetmap.org/wiki/FR:Key:lanes Or Osmose semble compter lanes:bus=* comme venant s'ajouter aux voies indiquées dans lanes=* puisque d'après lui “lanes” = 8 = 6 + 2. Un peu plus loin le wiki précise : En complément du nombre total de voies, on peut tagger le nombre de voies spécifiques aux transports en commun avec lanes:psv=*, lanes:bus=* et lanes:taxi=*. Pour moi cette formulation veut dire que l'on a lanes voies au total, dont lanes:bus voies de bus, lanes:taxi voies de taxi, etc. Mais la version Anglaise est plus ambigue : https://wiki.openstreetmap.org/wiki/Key:lanes Additionally to the total number of lanes, consider to tag the number of lanes for PSV with lanes:psv=*, lanes:bus=* and lanes:taxi=*. Alors est-ce que Osmose est erroné ou est-ce le wiki qui a tort ? -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Paris n'existe plus ?
On Fri, 2 Feb 2018, Francois Gouget wrote: > > J'ai hérité de toute une série d'erreurs Osmose disant que > addr:city=Paris est "non concordant avec une ville". > > https://osmose.openstreetmap.fr/fr/error/15563651812 > https://osmose.openstreetmap.fr/fr/error/15563639725 > https://osmose.openstreetmap.fr/fr/error/15563637394 > > Bug Osmose ou bien faut-il mettre autre chose à cause des > arrondissements ? D'après ce qu'on m'a dit (bizarre, l'email n'apparaît pas encore ici) il y a eu une erreur d'édition des limites de Paris ce qui a causé cette floppée d'erreurs. J'ai marqué mes erreurs comme 'corrected' ce qui forcera Osmose à les rescanner et il devrait alors découvrir qu'elles ont effectivement été corrigées. Mais je ne me sens pas le courage de le faire pour les ~21000 erreurs de ce type sur Paris ! https://osmose.openstreetmap.fr/en/errors/?source=683=2060=12 Y a-t-il moyen de demander à Osmose de rescanner la zone pour cette erreur ? Ou alors est-ce qu'il le fait automatiquement une fois de temps en temps ? -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ Stolen from an Internet user: "f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !"___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Paris n'existe plus ?
J'ai hérité de toute une série d'erreurs Osmose disant que addr:city=Paris est "non concordant avec une ville". https://osmose.openstreetmap.fr/fr/error/15563651812 https://osmose.openstreetmap.fr/fr/error/15563639725 https://osmose.openstreetmap.fr/fr/error/15563637394 Bug Osmose ou bien faut-il mettre autre chose à cause des arrondissements ? Je vois la même erreur sur Lyon mais cette fois sur des tags addr:city=Lyon 2eme Arrondissement par exemple. Les noeuds qui ont addr:city=Lyon ne semblent pas être signalés en erreur. https://osmose.openstreetmap.fr/fr/error/15571465364 -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ A polar bear is a cartesian bear after a coordinate transform.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] positionnement des adresses et ménage
On Thu, 25 Jan 2018, marc marc wrote: > Bonjour, > > Le 25. 01. 18 à 07:38, JB a écrit : > > Tu pourrais donner un exemple > > Les 7 derniers exemples listés en fin du précédent email sont > des exemples concret de problème ou de besoin non satisfait. > En voici un : un bâtiment avec une adresse et 2 accès. > Je souhaite un routage de l'adresse sur l'accès le plus proche. Un tel site n'aura-t-il pas plusieurs adresses ? Par exemple ici : https://www.openstreetmap.org/way/68850098 Il y a deux portails piétons, l'un au 29 rue Jules Verne et l'autre au 18 rue Nélaton. Les deux entrées donnent sur une arche qui permet d'accéder à la cour intérieur. Ensuite les "bâtiments" sont identifiés par une lettre : Bat A, Bat B, ... jusqu'à Bat F. Quand à l'entrée parking elle se trouve encore ailleurs. Selon le bâtiment où ils habitent, les résidents préfèrent que leurs invités arrivent par l'une ou l'autre entrée car cela leur fait moins loin à aller pour ouvrir le portail. Et donc ils donnent l'une où l'autre adresse pour identifier à quelle entrée se présenter. Mais eux peuvent indifféremment entrer par l'une ou par l'autre. Par contre il n'y à (il me semble) qu'une adresse postale pour tous les "bâtiments" (ce qui ne veut probablement même pas dire que toutes les boîtes aux lettres se trouvent au même endroit, juste que le facteur entre par là, je ne me souviens pas des détails). Et à ma connaissance on ne peut pas dire qu'un "bâtiment" est plus à une adresse qu'à une autre. Etant donné tout cela : * Je pense que ça n'aurait pas de sens de mettre un point pour chacune des deux adresses quelque part au milieu de la cour. Quelqu'un à qui on dit d'aller au 18 rue Nélaton doit savoir où se présenter. * Pourquoi mettre une adresse plus sur un bâtiment que sur un autre ? En plus, bien qu'il y ait 6 "bâtiments" (en fait 6 escaliers qui ne communiquent pas les uns avec les autres ; sauf peut-être via le sous-sol), d'après les objets de OSM il n'y aurait que deux constructions. * Si on considère que chacun des bâtiments a deux adresses, comment mettre deux adresses sur un seul objet OSM ? * Pour tout bien cartographier il faudrait probablement mettre un point pour l'entrée de chacun des 6 bâtiments. Par contre quelle adresse de rue leur associer ??? La plus proche ? Et il est intéressant de noter que ces points ne seraient pas à la transition entre l'espace public et l'espace privé puisque les bâtiments se trouvent dans l'enceinte privée délimitée par le grillage tout au tour. Bref je pense que c'est un cas où mettre l'adresse sur les bâtiments ou quelque part dans la surface ne marcherait pas. De même je pense qu'un site universitaire cerné par plusieurs rues aurait forcément plusieurs adresses, une pour chaque enrée. Par contre cela ne me choque pas qu'on mette les tags d'adresse sur le l'objet bâtiment d'une maison individuelle. Il peut y avoir des cas particuliers mais dans >90% des cas c'est clair et non ambigu. -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ Broadcast message : fin du monde dans cinq minutes, repentez vous !___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO / Cadastre différence nom de voie
On Wed, 3 Jan 2018, Christian Quest wrote: > Sur le plan cadastral, il y a des libellés qui peuvent être différents de > ceux qu'on trouve dans FANTOIR... même si les deux sources sont la DGFiP. > > Là, il n'y a que le terrain qui peut servir à départager ces incohérences. Pas tout à fait. Wikipedia est très utile pour pas mal de ces incohérences. En l'occurrence on découvre que : * Hongerford est grosso-modo inconnu au bataillon. * Hungerford est une bourgade Anglaise qui est jumelée avec Ligueil, la ville où ce trouve cette voie ! https://fr.wikipedia.org/wiki/Hungerford * Et la page anglaise de Ligueil confirme ce jumelage (mais rien sur la page française). https://en.wikipedia.org/wiki/Ligueil Donc, indépendamment de ce qui est écrit sur les panneaux, il y a de très fortes chances qu'Hungerford soit le nom correct. -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ Be careful of reading health books, you might die of a misprint. -- Mark Twain___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] modification au 1er janvier
On Tue, 2 Jan 2018, Christian Quest wrote: [...] > Exemple: quelques communes on plusieurs codes postaux... de grosses villes, D'ailleurs Osmose se plaint quand ça arrive. Par exemple j'ai "hérité" d'Angers qui correspond à deux codes postaux, 49000 et 49100, et Osmose me dit : https://osmose.openstreetmap.fr/fr/error/15032654220 Code postal au niveau de la rue “49000;49100” non valide pour le code pays “FR” Il y a un certain nombre d'autres erreurs de ce type pour Orléans, Paris, etc. J'ai l'impression que addr:postcode ne devrait pas être utilisé pour des boundary=administrative et devrait être remplacé par postal_code. Mais de toute façon le wiki n'indique pas s'il est autorisé de mettre plusieurs valeurs (pas plus pour postal_code que pour addr:postcode). Donc je ne sais pas trop quoi faire de ce signalement. -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rencontre parisienne le vendredi 10 nov - gare de Lyon
On Mon, 4 Dec 2017, Florian LAINEZ wrote: > quand tu dis qu'il Manque plus que les A7A1M4 et A7A1M5, tu veux dire qu'il > faut les trouver ou il y a juste un besoin de vérification ? je peux y > repasser si besoin Je veux dire que ces boîtes aux lettres ne sont pas dans OSM. Mais je pense qu'elles sont en-dehors de la gare et donc leur cas n'est pas différent de toutes les autres boîtes aux lettres manquantes sur Paris. Donc je ne pense pas que ça vaille le coup de faire le déplacement juste pour elles. Ce qui diffère dans les gares c'est qu'il y a généralement plusieurs boîtes aux lettres toutes plus ou moins hors de portée du GPS et souvent avec peu de repères pour se localiser. Du coup c'est assez difficile de savoir quelle ref va où comme le prouve l'ex-embrouillamini de la gare de Lyon. Là ça aide d'avoir un mappeur expérimenté :-) En tout cas merci encore ! -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Utilisation du tag 'name' avec les langues régionales
Je suis tombé sur un changeset qui ajoute des noms en Occitan dans name:oc, ce qui est bien, et dans le champ name avec un '/' ce qui est moins bien. Donc j'ai laissé un commentaire sur le changeset et pour ne pas perdre l'information, le voici : https://www.openstreetmap.org/changeset/52321720 D'ailleurs à propos de serveurs dédiés pour telle ou telle langue régionale, plutôt que d'avoir chaque communauté qui monte son propre serveur et gère sa propre infrastructure en doublon, serait-il possible : 1. Soit de juste mutualiser les ressources entre les différentes communautés. 2. Soit de carrément monter un seul serveur qui couvrirait la France entière, et rien que la France, et qui ferait un rendu avec les noms en Breton pour la Bretagne, en Alsacien pour l'Alsace, en Occitan pour l'Occitanie, et en Basque pour le pays Basque. Bon, je suppose que pour le Basque il faudrait aussi couvrir une partie de l'Espagne. Voir couvrir toute l'Espagne et ajouter le Catalan tant qu'on y est. Mais est-ce qu'il y aurait des zones où on aurait des conflits entre, par exemple, les noms Basque et Occitan ? Et est-ce que cela conviendrait aux différentes communautés où est-ce que leur but est aussi d'afficher les noms partout en France (par exemple Paris) / dans le monde dans leur langue ? Je note que le serveur Breton ne couvre que la Bretagne par exemple, et que donc cette approche ne serait pas donc immédiatement vouée à l'échec. Est-ce que cela simplifierait la gestion par rapport à l'option 1 ? -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rencontre parisienne le vendredi 10 nov - gare de Lyon
On Mon, 27 Nov 2017, Florian LAINEZ wrote: > Hello François, > Je n'ai pas fait toutes les boites mais j'ai corrigé des erreurs sur > plusieurs d'entre elles : > A2D6U6 : https://www.openstreetmap.org/node/264258714 > A2D6U8 : https://www.openstreetmap.org/node/264258705 > A2Y8H4 : https://www.openstreetmap.org/node/3671830102 > A3T6L2 : https://www.openstreetmap.org/node/3166378481 > > Je suis allé prendre des photos sur place, tu verra les numéros d'ID qui > renvoient vers les photos Mapillary pour preuve ;) > Du coup par déduction tu peux finir le job ? Super ! J'ai complété ce week-end : * A6D2U7 -> A2D6U7. C'est moi qui avait dû me tromper en tapant la référence d'ailleurs. https://www.openstreetmap.org/node/4121546909 * A2D6U7 -> A2D6V0, la seule référence du fichier de la poste qui restait (+ une note vu que la boîte aux lettres n'a aucune référence affichée). https://www.openstreetmap.org/node/3671887230 * Et sur les trois A2D6I8 il y en avait une qui était correcte. https://www.openstreetmap.org/node/3597070375 Ensuite j'ai mis les horaires de levée et voilà. Pour la gare je pense que c'est bon. Manque plus que les A7A1M4 et A7A1M5 (peut-être dans le bureau de poste ?), et les horaires de levée des boîtes aux lettres du bureau de poste et de la A2D6S2 au 14 boulevard Diderot. Quand même la poste pourrait mettre les horaires de levée de ses boîtes aux lettres et de leurs bureaux de poste dans leur fichier en OpenData ! -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Problème Osmose
Osmose a l'air d'avoir un problème depuis hier soir. Mon navigateur n'arrive pas à s'y connecter et si j'insiste j'obtiens : 502 Bad Gateway nginx/1.10.3 -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ All generalizations are false, including this one. -- Mark Twain___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Utilisation du tag 'name' avec les langues régionales
On Thu, 16 Nov 2017, marc marc wrote: [...] > Du coup je comprend pas la suite de ton message. > D'un côté tu as l'air de dire qu'on aurait du faire la procédure > DWG + tôt (je partage ton avis), de l'autre tu as l'air de dire > que la première étape (communiquer) est facultative. J'ai l'impression que cet utilisateur a été largement prévenu, même si ce n'est peut-être pas de la façon prévue par la procédure officielle. Avec en plus le flou qui reigne on obtient cette position contradictoire au premier abord. > Ajouter des outils pour détecter ou rapporter ce genre de problème > ne sert à rien si lorsqu'il est détecté, personne ne veux > lancer la procédure nécessaire pendant des mois... Problème de dilution des responsabilités ? Si je comprend bien personne n'est chargé de s'occuper de ces cas là et donc tout le monde espère que quelqu'un d'autre va s'y coller (ce qui est bien compréhensible). Désigner à l'avance une personne à contacter qui va coordonner / gérer ces cas pourrait faire partie des 'améliorations' dont je supputais l'existence. -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ A black hole is just God dividing by zero.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Utilisation du tag 'name' avec les langues régionales
On Thu, 16 Nov 2017, Philippe Verdy wrote: > La procédure c'était de contacter l'utilisateur et cela a été fait > par plusieurs personnes, au moment où les reverts ont été faits, et on > lui a demandé de contacter la communauté, il a ignoré les messages de > tout le monde. Et cela a été discuté sur cette liste à plusieurs > reprises. La communauté OSM n'a rien à se reprocher. Le message de Vincent me donne l'impression que le compte à rebours pour 'après un temps raisonnable' suivant un commentaire sur un changeset commence le 9 novembre : https://www.openstreetmap.org/changeset/53646881 Or je vois qu'il y a une guerre d'édition depuis environ 6 mois et effectivement ça fait longtemps qu'on en entend parler sur la liste. Mais si la procédure a été suivie depuis le départ alors logiquement on devrait pouvoir pointer vers un commentaire sur un changeset qui date d'il y au moins 4 ou 5 mois. Et 4 mois n'est-ce pas déjà un délai plus que raisonnable ? Mais je ne connais pas la procédure (et je ne sais pas précisément ce qui a été fait jusqu'à présent) alors c'est peut-être pour cela que je suis un peu perdu. Peut-être que des reverts avec commentaire idoine comptent comme notification ? Ou alors des emails ? Privés ? Et qu'est-ce que 'un temps raisonnable' ? Est-ce qu'on est reparti pour attendre 2 ou 3 mois avant de passer à l'étape suivante ? Est-ce qu'une fois le DWG notifié il y a des délais supplémentaires ? Aha ! Jusque là j'avais lu la page Disputes vers laquelle pointe la page 'Contribuer aux données cartographiques'. https://wiki.openstreetmap.org/wiki/Disputes Mais la page Disputes est très vague et ne fait guère que situer le contexte des sources de conflit. La page qu'il faut consulter est en fait la page sur le vandalisme : https://wiki.openstreetmap.org/wiki/FR:Vandalisme Mais la version française n'était pas bien à jour et il y avait des problèmes de traduction. Donc j'ai fait quelques corrections et j'ai ajouté un lien vers cette page sur 'Contribuer aux données cartographiques'. https://wiki.openstreetmap.org/wiki/FR:Contribuer_aux_donn%C3%A9es_cartographiques Pour un blocage temporaire tout ce qui est dit c'est : | Si, après avoir été contacté par l'intermédiaire de discussions sur | les modifications litigieuses et / ou de messages le contributeur ne | modifie pas son comportement, le Groupe de travail de la base de | données (DWG) peut instaurer un blocage temporaire de l'utilisateur. Cela ne mentionne pas de délai spécifique et n'impose pas qu'il y ait eu des "discussions sur les modifications litigieuses". Donc au vu des déclarations de chacun sur cette liste de discussion il semble que l'utilisateur ait été notifié par des "messages" il y déjà assez longtemps. Donc si je me base sur ce paragraphe je pense qu'un blocage temporaire peut être mis en place (ou du moins demandé) sans délai. Pour une exclusion permanente (si on en arrive là) la page à lire serait la suivante (et maintenant la page vandalisme pointe dessus, comme dans la version anglaise) : https://wiki.osmfoundation.org/wiki/Ban_Policy Pour justifier une exclusion permanente il faut : * Qu'il y ait eu plusieurs tentatives d'obtenir un changement de comportement. -> Fait à travers les multiples reverts et, dernièrement, les commentaires sur les changesets. Il semble qu'il y ait également eu d'autres tentatives privées. * Que le vandalisme se poursuive pendant plus de 3 mois. -> C'est le cas. * Que l'utilisateur ait été informé dans sa langue qu'il risque une exclusion permanente. -> Pas encore fait à ma connaissance. D'ailleurs peut-être ce message ne doit-il être envoyé qu'à l'initiative du DWG ? * Qu'un quorum de 50% des membres du DWG soit atteint et que plus de 66% se prononce pour. -> Du ressort du DWG. -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ In theory, theory and practice are the same, but in practice they're different.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Utilisation du tag 'name' avec les langues régionales
On Sat, 11 Nov 2017, Vincent Bergeot wrote: [...] > > - après un temps raisonnable (qui est peut-être déjà écoulé si le point > > précédent a été fait... mais personne n'a donné le lien), écrire au DWG > > en demandant au miminum le revert de tout les names en france et le > > revert de tout les names:fr (y compris de l'autre de la frontière) > > ok, attendons donc :) Enfin les premiers reverts datent quand même d'il y a 6 mois et depuis c'est la guerre. Pour reprendre un des exemples ci-dessus : https://www.openstreetmap.org/node/388577606/history#map=19/43.24205/-1.28367 * v15 - Edited 23 May 2017 by izpura - creacion -> Reverted 29 August 2017 by Vlad - Reset official name in the name tag * v17 - Edited 07 Sept 2017 by izpura - eukaraz -> Reverted 14 Sept 2017 by Vlad - Fix Osmose "local language" error * v19 - Edited 14 Sept 2017 by izpura - transformacion -> Reverted 16 Sept 2017 by Vlad - Fix Osmose "local language" error * v21 - Edited 16 Sept 2017 by izpura - euskaraz -> Reverted 17 Sept 2017 by Vlad - Fix Osmose "local language" error Etc, etc, etc. Aujourd'hui on en est à la v36. Même sans explications pédagogiques et détaillées sur un changeset il me semble que les reverts systématiques, faits par plusieurs contributeurs (verdy_p s'y est mis il y a 1 mois, sans compter la v14 déjà sur le même thème) auraient dû alerter l'utilisateur et le pousser à contacter la communauté pour se renseigner. Et s'il est convaincu de son bon droit pourquoi n'est-il pas venu se plaindre qu'un utilisateur 'sabote' son travail par exemple ? Par contre on peut reprocher à la communuté OSM de s'être laissé entrainer dans une guerre d'édition plutôt que de tout de suite suivre la procédure officielle ce qui au final a perdu un temps considérable. Peut-être y a-t-il matière à amélioration ? Mieux documenter la procédure ? Traduire la page Disputes ? La rendre plus visible ? Ajouter un bouton 'signaler' dans Osmose ? Pourrait-on détecter automatiquement les guerres d'édition et notifier un responsable qui se chargerait de contacter les protagonistes et d'engager la procédure adéquate ? On pourrait par exemple caractériser une guerre d'édition par la présence de 3 versions identiques dans les 8 dernières (ou mieux 3 diff unifiés dont les lignes + correspondent). -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, it's computer science.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
