Re: [OSM-talk-fr] Etiqueter des routes selon le nom du lieu-dit
Cela dit, je m'interroge, représenter un lieu-dit par un point ou un polygone, ok, mais par une ligne c'est étrange non, de plus en utilisant l'objet "route" ? Est-ce une bonne idée de copier cette technique depuis le cadastre ? Julien "djakk" Le mer. 14 oct. 2020 à 10:50, Julien djakk a écrit : > > Salut ! Pour moi c'était une mauvaise pratique pour faire comme Google > Maps ! J'ignorai que c'était dans le cadastre. > > Julien "djakk" > > Le mer. 14 oct. 2020 à 07:18, Arnaud Champollion > a écrit : > > > > Le 14/10/2020 à 07:05, Gad Jo a écrit : > > > description=* si tu veut communiquer à destination des usagers utilisant > > > ces voies. > > > > Bonjour, une question que je me pose parfois (car j'utilise aussi > > souvent ce tag pour décrire) : quelles applications utilisent et > > affichent la valeur de l'attribut "description" à destination des usagers ? > > > > > > > > > > ___ > > Talk-fr mailing list > > Talk-fr@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Etiqueter des routes selon le nom du lieu-dit
Salut ! Pour moi c'était une mauvaise pratique pour faire comme Google Maps ! J'ignorai que c'était dans le cadastre. Julien "djakk" Le mer. 14 oct. 2020 à 07:18, Arnaud Champollion a écrit : > > Le 14/10/2020 à 07:05, Gad Jo a écrit : > > description=* si tu veut communiquer à destination des usagers utilisant > > ces voies. > > Bonjour, une question que je me pose parfois (car j'utilise aussi > souvent ce tag pour décrire) : quelles applications utilisent et > affichent la valeur de l'attribut "description" à destination des usagers ? > > > > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Besoin d'aide pour référence d'un ligne TGV
Salut ! On a le droit de copier les fiches horaires de la SNCF ? Julien "djakk" Le dim. 11 oct. 2020 à 01:39, Gad.Jo a écrit : > > La modification a été bien plus simple et rapide que prévu : > https://www.openstreetmap.org/changeset/92288895 > > J'ai remis à jour les relations qui y ressemblait le plus vers les > nouveau numéro de ligne actuellement active sur le site de la SNCF. > Normalement il n'y a pas de casse sur les gares où je suis passé (ajout > de tag, mise en conformité)... > > L'ancienne ligne TGV 752 a été remplacée par les lignes TGV 6871, 6873, > 6823, 9836 et 9862 > > En dehors de la gare Lille Europe où un trou persiste dans les relations > (pas chaud pour modifier une grosse gare). Tout les trajets sont continu. > > Le 10/10/2020 à 21:42, Gad.Jo a écrit : > > Après une courte recherche j'ai trouvé le très bon site : > > https://www.fiches-horaires.net/ (leur description en pied de page est > > très amusante et pleine de bon sens) > > > > A défaut de trouver les fiches horaires officielle il y a de la > > données valide. Par contre... où on t'ils trouvé leur données ? > > > > Le 10/10/2020 à 16:40, Adrian via Talk-fr a écrit : > >> Il y a deux ans environ, je voulais couper des chemins (ways) de > >> chemin de fer pour introduire des ponts. Ces chemins étaient membres > >> de plus que dix relations d'itinéraire. Comme toi, j'ai vu qu'il y > >> avait deux genres de relation. Il y avait les itinéraires > >> d'infrastructure, comme la ligne de Combs-la-Ville à Saint-Louis. Et > >> il y avait les itinéraires passagers, les voyages sans correspondance > >> proposés par la SNCF, comme le TGV 752. J'ai remarqué que les > >> itinéraires passagers reflétaient l'état d'il y a cinq ans ou plus. > >> > >> Les relations étaient un vrai désordre. Toutes étaient cassées à > >> multiples endroits avec des types diverses d'erreur. Quelques-unes > >> étaient très longues avec jusqu'à trois mille membres. Le format de > >> toutes les relations est un hybride de v1 et v2 des transports en > >> commun. Il y a une liste des gares, et une liste des chemins dans les > >> deux sens (sauf voie unique), sans les rôles forward ou backward. Les > >> listes des chemins comprennent des blocs alternés de chemins dans le > >> sens aller et chemins dans le sens retour. Les relations > >> d'infrastructure contiennent souvent toutes les voies des gares, y > >> compris les voies de garage et d'évitement. Les relations passagers > >> contiennent souvent toutes les voies par lesquelles les trains > >> pourraient passer par les gares. Je pense que les relations ont été > >> créées ainsi par des enthousiastes des chemins de fer. Mais je n'ai > >> pas cherché qui, ou pourquoi, ou si c'est documenté quelque part. > >> > >> J'ai passé des heures à faire une réparation partielle des > >> plus-que-dix relations, sans changer le format. Une réparation > >> entière aurait fallu beaucoup trop longtemps. Ainsi j'ai pu > >> introduire les ponts sans empirer le bordel. > >> > >> À mon avis, un tel cas a besoin d'une méthode différente de > >> cartographier les itinéraires. Les relations d'itinéraire devraient > >> avoir comme membres, d'autres relations: des tronçons d'itinéraire. > >> Ça pourrait être fait avec ou sans des relations superroute. On > >> arriverait à une grande simplification. > >> > >> Et alors, que faire? Mettre en bonne état et à jour seulement les > >> relations qui passent par ton coin, est un très grand boulot. Et en > >> idéal, il faudrait discuter avec ceux qui cartographient les chemins > >> de fer, quel est le format préféré des relations. Les relations sont > >> utilisées par https://www.openrailwaymap.org/ et > >> https://magosm.magellium.com/portail/#/carte p.ex. Supprimer des > >> relations serait dommage, vu le temps que plusieurs contributeurs ont > >> passé à les créer. À mon avis, il faudrait améliorer ou mettre à > >> jour; ou bien laisser tel quel. > >> > >> À noter qu'il y a toujours des liaisons directes Lyon - Barcelone. > >> Mais pas Lyon - Bordeaux, ça va plus vite maintenant via Paris que > >> via Montpellier! > >> > >> Un projet du mois, peut-être? Mais je me demande s'il y aurait assez > >> de contributeurs intéressés. Et comment découvrir la gamme des > >> itinéraires passagers, vu qu'il n'y a plus de fiches horaires TGV > >> disponibles en ligne? > >> > >> ___ > >> Talk-fr mailing list > >> Talk-fr@openstreetmap.org > >> https://lists.openstreetmap.org/listinfo/talk-fr > > > > ___ > > Talk-fr mailing list > > Talk-fr@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk-fr > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mappons le temporaire qui dur
Bonsoir ! Je ressuscite cette discussion pour proposer / remarquer qu'il faut en général utiliser un "namespace" avec temporary : https://www.openstreetmap.org/way/809893926 <- il faudrait ajouter cycleway:right:temporary=yes - le reste de la rue n'est pas temporaire donc un temporary=yes ne marche pas … Julien "djakk" Le jeu. 28 mai 2020 à 17:06, Florimond Berthoux a écrit : > > Il y a simplement end_date pour préciser la date prévu de fin d'une feature. > > Le jeu. 28 mai 2020 à 14:18, Marc M. a écrit : >> >> Bonjour, >> >> Le 27.05.20 à 16:22, Florimond Berthoux a écrit : >> > explicitement marqué par un panneau un début et de fin, etc. >> >> pour le début start_date >> pour la fin : il serrait utile d'avoir un tag pour encoder >> une date à partir de laquelle il faudrait retourner voir >> si le temporaire a été prolongé ou si cela a changé. >> une sorte de opening_date inversé -> ending_date ? >> >> > contrôle qualité pour lister les aménagements à vérifier régulièrement. >> >> survey:date pourrait être utile pour cela lorsque la vérif >> sur place ne nécessite aucun changement dans osm parce que >> rien n'a changé. >> ou alors un changement blanc mais c'est tordu et >> source de confusion pour les autres contributeurs. >> >> Cordialement, >> Marc >> >> ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr > > > > -- > Florimond Berthoux > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendus FR en vectoriels, on se lance ?
Salut ! Ça m'intéresse ! :) Est-ce que ça pourrait potentiellement être un peu rémunéré ? Il y a quelque temps j’avais fait ceci : https://github.com/djakk/openstreetmap-on-heroku Julien « djakk » Le ven. 18 sept. 2020 à 11:41, Florian LAINEZ a écrit : > Hello, > Et si on se mettait sérieusement au boulot pour créer des rendus français > en vectoriel ? > On voit clairement la limite de ceux affichés sur > https://www.openstreetmap.fr et dans nos service connexes (umap, projet > du mois, ...). > On pourrait commencer avec le rendu osm-fr ou bien le rendu vélo. > > Je sais, c'est un serpent de mer. Je sais, ce n'est pas si facile. Et je > sais aussi que je ne serai sûrement pas d'une grande utilité pour le faire, > mais je pense que ça serait tout de même un grand pas en avant qui > mériterait une plus grande attention de notre part. > #AppelABonnesVolontés > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *FlorianLainez* > @overflorian <http://twitter.com/overflorian> > > > ___ > > Talk-fr mailing list > > Talk-fr@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk-fr > > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Hiérarchisation du réseau cyclable
> c'est pourtant le plus facile pour détecter que le réseau est complet. Que veux-tu dire par là ? > j'ai en souvenir ta vision très controversé du réseau voiture. > du coup un exemple et une source utilisable pour osm sur ce point ? > ou c'est juste un feeling comme pour les voitures ? Il y a quelques boucles de comptage sur les routes et les pistes cyclables mais oui c'est beaucoup de feeling, il me semble pas plus+ pas moins- que pour construire le réseau de highway pour voitures : à force d'arpenter sa ville, le contributeur sait par où passent les voitures, par où passent les vélos, et si c'est très fréquenté ou pas trop selon chaque mode de transport. Exemple : j'aurai pu ressentir que la récente piste cyclable du boulevard Sébastopol est plus+ empruntée que la rue Saint-Denis parallèle (https://www.openstreetmap.org/#map=19/48.85984/2.34936) bien que cette dernière supporte un itinéraire vélo officiel, fléché et cartographié dans OpenStreetMap par plusieurs relation. Julien "djakk" Le mar. 9 juin 2020 à 14:41, Marc M. a écrit : > > Le 09.06.20 à 14:36, Julien djakk a écrit : > > En fait, je ne pense pas faire de relations, trop casse-pied à gérer, > > c'est pourtant le plus facile pour détecter que le réseau est complet. > > > quand deux itinéraires vélo "secondary" se rejoignent, > > ça peut donner un itinéraire vélo "primary" etc. > > j'ai en souvenir ta vision très controversé du réseau voiture. > du coup un exemple et une source utilisable pour osm sur ce point ? > ou c'est juste un feeling comme pour les voitures ? > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Hiérarchisation du réseau cyclable
En fait, je ne pense pas faire de relations, trop casse-pied à gérer, mais faire comme le réseau routier voitures, caractériser ligne par ligne. De plus, quand deux itinéraires vélo "secondary" se rejoignent, ça peut donner un itinéraire vélo "primary" etc. Julien "djakk" Le mar. 9 juin 2020 à 13:58, Julien djakk a écrit : > > Merci marc, je vais jeter un œil là-dessus. > > Bonjour Romain, en général ces itinéraires cartographiés avec une > relation sont des itinéraires touristiques. Et merci : je ne savais > pas qu'il existait une liste "vélo" ! :) > > Julien "djakk" > > Le mar. 9 juin 2020 à 12:51, Romain MEHUT a écrit : > > > > Bonjour, > > > > N'est-ce pas déjà le cas avec les relations qui décrivent des itinéraires ? > > > > Romain > > > > Le 09/06/2020 à 12:35, Julien djakk a écrit : > > > Bonjour tout le monde ! > > > > > > Je souhaite hiérarchiser dans OpenStreetMap le réseau de pistes > > > cyclables et de routes ouvertes au vélos. Comment faire ? > > > Je pensais faire à la manière du réseau routier voitures : > > > highway="primary", "secondary", etc. -> cycleway="primary", > > > "secondary", etc. ? Bon cycleway étant déjà utilisé il faudrait une > > > autre clé (cycleway:importance ?). > > > > > > On se retrouverait dans certains cas avec des voies > > > highway="residential" + cycleway:importance="primary". > > > > > > > > > Julien "djakk" > > > > > > ___ > > > Talk-fr mailing list > > > Talk-fr@openstreetmap.org > > > https://lists.openstreetmap.org/listinfo/talk-fr > > > > > > ___ > > Talk-fr mailing list > > Talk-fr@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Hiérarchisation du réseau cyclable
Merci marc, je vais jeter un œil là-dessus. Bonjour Romain, en général ces itinéraires cartographiés avec une relation sont des itinéraires touristiques. Et merci : je ne savais pas qu'il existait une liste "vélo" ! :) Julien "djakk" Le mar. 9 juin 2020 à 12:51, Romain MEHUT a écrit : > > Bonjour, > > N'est-ce pas déjà le cas avec les relations qui décrivent des itinéraires ? > > Romain > > Le 09/06/2020 à 12:35, Julien djakk a écrit : > > Bonjour tout le monde ! > > > > Je souhaite hiérarchiser dans OpenStreetMap le réseau de pistes > > cyclables et de routes ouvertes au vélos. Comment faire ? > > Je pensais faire à la manière du réseau routier voitures : > > highway="primary", "secondary", etc. -> cycleway="primary", > > "secondary", etc. ? Bon cycleway étant déjà utilisé il faudrait une > > autre clé (cycleway:importance ?). > > > > On se retrouverait dans certains cas avec des voies > > highway="residential" + cycleway:importance="primary". > > > > > > Julien "djakk" > > > > ___ > > Talk-fr mailing list > > Talk-fr@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk-fr > > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Hiérarchisation du réseau cyclable
Bonjour tout le monde ! Je souhaite hiérarchiser dans OpenStreetMap le réseau de pistes cyclables et de routes ouvertes au vélos. Comment faire ? Je pensais faire à la manière du réseau routier voitures : highway="primary", "secondary", etc. -> cycleway="primary", "secondary", etc. ? Bon cycleway étant déjà utilisé il faudrait une autre clé (cycleway:importance ?). On se retrouverait dans certains cas avec des voies highway="residential" + cycleway:importance="primary". Julien "djakk" ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagging/suppression d'un passage dangereux
Il s’agit d’une ligne de désir ! Pour moi elles ont leur place dans OSM. Certains endroits, certaines routes, sont dangereux pour les piétons et les vélos mais on ne le cartographie pas dans osm ... sauf si panneau explicite (exemple : la N79, route française). Julien « djakk » Le mer. 27 mai 2020 à 18:02, André Maroneze a écrit : > Bonjour, > > En utilisant OsmAnd pour trouver un chemin de promenade, je suis tombé sur > un "chemin" sauvage qui traverse une avenue puis une départementale dans > les deux sens. Le chemin en question n'est autre que de l'herbe écrasée à > force du passage des gens. Il est donc non-officiel, dangereux (même en > pleine journée un dimanche, je n'ai pas voulu essayer de l'emprunter, car > les voitures le croisaient régulièrement), et à mon avis sans intérêt ; on > pourrait très bien choisir de passer à côté, si on veut vraiment faire > n'importe quoi. Sinon, à 5 minutes à vélo de là, un passage souterrain > permet de franchir la route en toute sécurité. Ce dernier ne m'a pas été > suggéré justement à cause de ce chemin alternatif, plus court. > > J'aimerais donc qu'il ne soit plus utilisé pour le routage piéton, ou au > minimum qu'il soit affiché en tant que "dangereux". Il y a déjà une note > sur la carte dans ce sens, rajoutée par quelqu'un d'autre, mais elle n'est > pas visible par les applications. > > J'ai vu sur https://wiki.openstreetmap.org/wiki/Key:access qu'il y a > "access=discouraged", mais l'utilisation indiquée ne correspond pas > exactement à ce que je veux. Sur la page française de la clé, je ne vois > pas de mention à cela. > > Est-ce que "access=no" serait valide ici, vu que légalement, il me semble > que traverser une départementale à pied en dehors d'un passage piéton soit > interdit ? Ou sinon, faudrait-il supprimer ce chemin (qui risque d'être > remis plus tard) ? > > Pour information, le chemin en question est là : > https://www.openstreetmap.org/way/81972368#map=19/48.67500/2.18292 > > Merci pour vos avis et suggestions, > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] OpenstreetMap sur Heroku
Salut tout le monde, j'ai réussi à monter un serveur nodejs (du javascript-sans-le-côté-web) pour afficher les données OpenstreetMap en vectoriel grâce à Mapnik, et sous Heroku :) -> http://openstreetmap-on-heroku.herokuapp.com / https://github.com/djakk/openstreetmap-on-heroku C'est centré sur le quartier de la rue Anatole France à Rennes (qui a une station de métro à son nom). Rien de grand public pour le moment, c'est pour celles et ceux qui aiment lire un code informatique ! N'hésitez pas si vous avez des remarques et/ou des questions :) Julien "djakk" ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Valeurs multiples pour shop=*
Salut ! D’un point de vue ingénieur ça me semble plus simple de gérer une liste qu’une multitude de tag ;-) Julien “djakk” Le mar. 7 avr. 2020 à 12:34, Yves P. a écrit : > Bonjour, > > Voici une colle pour les développeur de Ça reste ouvert ? > cf. bug n°28 <https://github.com/osmontrouge/caresteouvert/issues/218> > > C'est difficile de gérer correctement shop=newsagent;tobacco > <https://taginfo.openstreetmap.org/tags/shop=newsagent;tobacco>, > shop=kiosk;lottery;newsagent;tobacco > <https://taginfo.openstreetmap.org/tags/shop=kiosk;lottery;newsagent;tobacco>, > etc. > > Comment taguer ça correctement avec nos éditeurs et logiciels actuels ? > > Que pouvons nous faire ? > >- modifier le wiki (il y a beaucoup de pages) >- faire des éditions de "masse", des maproulettes… >- … ? > > > __ > Yves > > Voici quelques exemples (un inventaire à la Prévert) : > > Un kiosk ? > >- shop=kiosk >- ± tobacco=yes >- ± *?=yes* > > quel tag pour les journaux ? > >- newsagent=yes ><https://taginfo.openstreetmap.org/keys/newsagent#values> >- newspaper=yes <https://taginfo.openstreetmap.org/keys/newspaper> >- newspapers=yes <https://taginfo.openstreetmap.org/keys/newspapers> >- rien (on considère qu'un kiosque vend toujours des journaux ??) > > > quel tag pour le lotto ? > >- gambling=lottery >- lottery=yes >- gambling=yes > > > quel tag pour les courses de chevaux > >- gambling=yes >- gambling=PMU > > > Plutôt un point presse avec du tabac ? > *shop=newsagent;tobacco* > >- shop=newsagent >- tobacco=yes >- lottery=yes > > Plutôt un bureau de tabac avec des journaux ? > *shop=tobacco; newsagent* > > >- shop=tobacco >- ?=yes > > > Un bar - tabac > >- amenity=bar >- tobacco=yes > > > Un bar - tabac - journaux > >- amenity=bar >- tobacco=yes >- ± ?=yes >- ± lottery=yes > > > Un magasin qui vend principalement des tickets de loto : > >- shop=lottery > > > Un petit supermarché qui vend de tout : > >- shop=convenience >- ± tobacco=yes > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Plans lignes RER?
Salut JB ! Je suis aussi très intéressé par ton travail sur le rendu TC ;) Je cherche aussi à compter le nombre de voies sur une voie ferrée. Julien « djakk » Le lun. 9 mars 2020 à 10:47, JB a écrit : > J'arrive avec un peu de retard, et je ne suis pas sûr de comprendre > exactement le besoin : tracé « géographique » tel que sur le terrain, ou > réseau plus ou moins analysé/simplifié, rassemblant les voies sur un > seul axe ? > Si une simplification est recherchée, j'avais sorti ça à une époque : > https://twitter.com/RandoCarto/status/1201458577799569408/photo/1, il y > a possibilité d'arrêter le traitement une étape plus tôt, avant > l'éclatement des lignes superposées, et de sortir la donnée brute. Comme > c'est un peu de boulot, je ne me lance pas dans le travail pour l'instant. > JB. > > Le 09/03/2020 à 01:17, Shohreh a écrit : > > cquest wrote > >> Les tracés d'IDFM ne sont pas non plus parfait, loin de là ! La boucle > de > >> terminus de la ligne 6 à Nation n'a sûrement pas cette allure. Données à > >> prendre avec du recul donc... > > Ils sont un peu plus propres : avec la relation, je récupérais des ways > et > > des nodes en plus (plusieurs voies et points dans une gare). > > > > J'ai eu le même genre de problème en récupérant des parcours vélos dans > OSM > > type Eurovelo etc. → il vaut mieux récupérer une vraie trace sur des > sites > > spécialisés. > > > > > > > > -- > > Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html > > > > ___ > > Talk-fr mailing list > > Talk-fr@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk-fr > > > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de Hack Weekend à Toulouse, 4 et 5 avril
Ouiii :) Julien « djakk » Le lun. 9 mars 2020 à 11:10, PanierAvide a écrit : > +2 rennais qui n'ont pas d'hébergement pour l'instant et qui sont > preneurs d'une solution commune :-) > > Cordialement, > > Adrien P. > > Le 09/03/2020 à 11:04, Sébastien Hinderer a écrit : > > Bonjour, > > > > Frédéric Rodrigo (2020/03/09 10:59 +0100): > >> Parmi ceux qui comptent venir au Hack Weekend il y a du monde qui > cherche un > >> hébergement ou qui ne se sont pas encore organisé ? > > * |Lupini| lève la main :) > > > > Oui, moi, pardon de ne pas m'être inscrit sur le wiki, j'essaie de faire > > ça dès ce soir. > > > > Cheers, > > > > Sébastien. > > > > ___ > > Talk-fr mailing list > > Talk-fr@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk-fr > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Motorroad sur Trunk en France
Oui l’idéal serait de faire comme Angleterre où le trunk est une super-primary ( grandes routes ou grandes artères urbaines) Julien “djakk” Le dim. 26 janv. 2020 à 23:16, Florimond Berthoux < florimond.berth...@gmail.com> a écrit : > Merci, vu le manque de réponse c'est bien indéfini en France. > Je me posais la question pour Cyclosm.org : la nouvelle version (fraîche > de ce soir) considère par défaut cyclable les Trunk et non cyclable s'il y > a motorroad=yes. > C'est la position visiblement la plus universelle. > Et ma position, un tag (highway) pour l'aspect et la hiérarchie dans le > réseau routier et un tag pour le côté l'égal du panneau, comme ça on évite > de mélanger les torchons et les serviettes et les moutons sont bien gardés. > Je pense changer cette petite phrase du wiki. > > Le dim. 26 janv. 2020 à 20:54, Axel Listes a écrit : > >> Bonsoir, >> >> Le 25/01/2020 à 21:12, Florimond Berthoux a écrit : >> > Je suis tombé sur une phrase qui m'a étonné sur la page de la clé >> motorroad >> > du wiki >> > «France >> > This tag is not required, just use highway=trunk. » >> > https://wiki.openstreetmap.org/wiki/Key:motorroad?uselang=fr#France >> > >> > Et effectivement pas de traduction en français de la page, et sur la >> page >> > française de Trunk l'explication du tag est resté en anglais. >> > >> > Cette phrase me parait assez fausse parce qu'en France une motorroad ça >> a >> > un panneau voir >> > https://fr.wikipedia.org/wiki/Route_pour_automobiles#En_France >> > Le tag est très utilisé dans le pays des Trunk (Bretagne) et ailleurs. >> > Et pour ce qui me concerne j'ai l'exemple d'une voie rapide dont un >> premier >> > tronçon est cyclable puis un panneau "route pour automobile" après la >> > premier sortie, où le tag motorroad est fort utile. >> > >> > Alors, je corrige la page ? >> >> J'avais déjà lancé le sujet en 2014, au final il n'y a jamais eu de >> consensus. >> >> http://gis.19327.n8.nabble.com/highway-trunk-en-France-td5821793.html >> >> Si tu arrives à faire bouger les lignes, merci d'avance ! >> >> Axel. >> >> ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > > > -- > Florimond Berthoux > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Numéro en double dans la rue
Bonjour ! Petite remarque : dans ma rue il y a deux fois le numéro 1 : parfois ça peut arriver ;) Julien J Le dim. 12 janv. 2020 à 16:20, Jacques Lavignotte a écrit : > Bonjour, > > > Osmose said : > > « Numéro en double dans la rue > Le numéro “2” apparaît plusieurs fois sur le chemin “Allée de la > République” > node 860267766 » > > Tous les numéros de ce petit bout de placette sont signalés en double... > > Ca date de 2010 et ça sort maintenant dans mes erreurs ? En 2010 > j'ignorai même l'existence d'OSM... > > > J'ai un peu regardé mais ne sais que faire... > > Dites-moi donc que faire... > > Merci, Jacques > > -- > GnuPg : 156520BBC8F5B1E3 Because privacy matters. > On mangera ? (c) (tm) > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] adresse mail rejetée - expéditeur wanadoo.fr via gmail pour destintaire free gmail laposte et autres
Philippe n’a jamais tord 😂 Julien « djakk » Le mer. 8 janv. 2020 à 22:30, Jacques Lavignotte a écrit : > > > Le 08/01/2020 à 22:21, Philippe Verdy a écrit : > > Le gros du problème est sur le serveur de liste d'OSM, son logiciel pas > > à jour depuis longtemps et utilisent certaines vieilles RFC et pas les > > mises à jour et correctifs demandés. > Non, rien. > > J. > > -- > GnuPg : 156520BBC8F5B1E3 Because privacy matters. > On mangera ? (c) (tm) > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] nord/sud/est/ouest et osm-vs-fantoir
Ben quand on se retrouve avec des champs ou une route avec un nom de lieu-dit que je ne connaissais pas malgré ma connaissance du terrain : https://www.openstreetmap.org/#map=19/48.15750/-1.69837 Julien “djakk” Le ven. 3 janv. 2020 à 15:07, Jérôme Amagat a écrit : > > >> Mais pas systématiquement. "Le moulin de" fait parti de l'adresse de ma >> cousine par exemple. Ça correspond à un vrai usage, donc ça a sa place dans >> osm, non ? >> >> C'est pour ça que j'ai écrit : "quand le château existe encore et que le > terme désigne seulement ce château". pareil pour les moulins. > > Sinon, 820 place=* name="Le Bourg" ou "Au Bourg" ou "Bourg" (il y en en > sûrement quelques uns de légitime mais pas la plupart) > https://overpass-turbo.eu/s/Pqj > dont plus de la moitié place=locality > Pour un bon nombre même pas sur le bourg mais un peu a coté là ou c'est > écrit sur le cadastre > > Pour Château, plus de 650 (dont une cinquantaine sans accent circonflexe) > et je n’inclus pas les "Château machin". Dans ce cas c'est plus compliqué > que le bourg je suis d'accord ,pour beaucoup le nom fait référence a un > hameau ou a un bâtiment qui n'est pas un château mais est ce qui s'en > approche le plus sur la commune... > > Je comprend pas bien les avis, il doit y avoir près d'une discussion sur 2 > ou il y a au moins quelqu"un qui va dire "c'est le terrain qui prime ..." > mais là parce que c'est soit disant ancien on se fout de savoir si c'est > encore utilisé ou même si ça a été un jour été utilisé ailleurs que sur le > cadastre. > Et donc il y plein de communes ou les lieux dit du cadastre on été importé > directement sans vérification, tous ou presque avec place=locality, placé > là où c'est écrit sur le cadastre même si on est très loin du lieu réel. > Toujours sur le cadastre, mais là il n'y a pas ce rapport à "l'ancien", il > est pas conseillé d'importer les adresses sans vérification. Pour les > rivières pressentent sur le cadastre il y avait des restrictions à son > import dans osm. > Dans un cas le cadastre à tout bon, dans d'autres c'est approximatif et il > faut vérifier. > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] nord/sud/est/ouest et osm-vs-fantoir
Cyrille, en tout cas j’aimerai trouver un moyen de distinguer ces lieux-dits uniquement administratifs, des autres, encore utilisés ;) Julien “djakk” Le ven. 3 janv. 2020 à 13:54, Donat ROBAUX a écrit : > Ce n'est techniquement pas un ancien nom vs nouveau nom. C'est un nom > ancien > qui n'est plus utilisé ou si peu, donc tombé en désuétude. On crée un > disused:name ? > > Donat > > > > > -- > Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] nord/sud/est/ouest et osm-vs-fantoir
Christian, ok pour ton point de vue. Si c’est toujours utilisé dans le notariat, mais plus utilisé par ailleurs, est-ce qu’on ne taggerait pas avec old_name uniquement ? Julien “djakk” Le ven. 3 janv. 2020 à 12:41, deuzeffe a écrit : > Le 03/01/2020 à 12:35, Christian Quest a écrit : > > > Il n'y a que l'ajout des points cardinaux par la DGFiP qui est > > artificiel et ne correspond qu'à une vue isolée d'une administration. > > This is my point. Thx. > -- > deuzeffe > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] nord/sud/est/ouest et osm-vs-fantoir
Ok mais ... j’ai l’impression que ces lieux-dits font partie du passé et pas du présent ? Julien “djakk” Le ven. 3 janv. 2020 à 09:56, Cyrille37 OSM a écrit : > Hello > > Ces lieux dits ont souvent du sens, OSM n'est pas "que" pour l'adressage > du présent pour du routage sur smartphone. Ne pas systématiquement > effacer les lieux-dits, s'il vous plaît. > > Par exemple, grâce à OSM on peut retrouver des lieux-dits cités dans des > livres, ou par grand-mère ;-) > > Cyrille37. > > Le 03/01/2020 à 02:52, Julien Lepiller a écrit : > > Le 2 janvier 2020 18:20:19 GMT-05:00, "Jérôme Amagat" < > jerome.ama...@gmail.com> a écrit : > >> Oui pour virer les point cardinaux mais il n'y en a d'autres que je > >> n'aime > >> pas. Qui sont là juste pour remplir le cadastre avec des lieu dit. > >> "sous un autre lieu dit", les prés de un autre lieu dit" ... peut être > >> que > >> parfois ça a vraiment une utilité mais pour moi c'est la même chose que > >> les > >> points cardinaux. > >> "Le bourg" si c'est le village de la commune, il faut mettre son nom > >> pas > >> besoin d'un lieu dit qui porte le nom "le bourg" > >> "Le château", quand le château existe encore et que le terme désigne > >> seulement ce château, il faut mettre les bons tags et nom sur le > >> bâtiment > >> mais pas besoin d'ajouter un lieu dit. > >> Pareil pour les moulins (et sûrement d'autres choses du même style) > > Mais pas systématiquement. "Le moulin de" fait parti de l'adresse de ma > cousine par exemple. Ça correspond à un vrai usage, donc ça a sa place dans > osm, non ? > > > > ___ > > Talk-fr mailing list > > Talk-fr@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk-fr > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] nord/sud/est/ouest et osm-vs-fantoir
Pas d’accord avec toi Philippe : Fantoir n’est pas à jour ! Julien “djakk” Le jeu. 2 janv. 2020 à 20:08, Philippe Verdy a écrit : > Le jeu. 2 janv. 2020 à 15:27, deuzeffe a écrit : > >> Le 02/01/2020 à 14:09, Frédéric Rodrigo a écrit : >> >> > Tu peux juste mettre plusieurs code FANTOIR pour un seul objet OSM. >> >> Merci pour ta réponse, j'ai l'impression d'avoir loupé un truc :( mais >> ça va bien m'aider ! >> > > Bof... On est sensé coder l'existant. Hors l'existant c'est ce qui est > officiel dans une base publique, et pas toujorus visible par un panneau sur > le terrain (où les noms affichés varient aussi selon l'usage et qui pose le > panneau ou communique). FANTOIR est sensé représenter l'existant. Mais > mettre deux codes différents ayant des noms et des positions différentes > sur un lieu unique avec deux codes et le même nom ne peut pas aider à > rapprocher les choses. > > C'est là que le guichet public pour la BAN pourrait aider à clarifier les > choses. Sinon si on fait disparaitre les noms qui ne sont pas affichés sur > le terrain ou affichés de façon différente, la BAN ne va plus fonctionner > comme il faut. Par principe même une référence FANTOIR a un nom unique et > deux codes n'ont pas les mêmes noms, et certains lieux-dits sur deux > communes ont deux orthographes distinctes et aucune commune ne va vouloir > en changer (même chose pour les noms de rues)n chacune ayant une compétence > égale sur leur territoire, ne peut décider que pour elle-même ! > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Projet OpenMaps
Je te propose : PCM, Pretty Cool Maps :) Julien “djakk” Le jeu. 10 oct. 2019 à 18:10, Cédric Frayssinet a écrit : > > > Bonjour à tous, > > L'application est dorénavant disponible sur le store F-Droid : > https://f-droid.org/packages/app.fedilab.openmaps/ > > Elle est déjà traduite en 5 langues, dont le français. > > N'hésitez pas à proposer des améliorations sur le dépôt : > https://framagit.org/tom79/openmaps/issues . J'essaierai de qualifier les > demandes sachant que Thomas n'est pas du tout expert OSM, il se contente de > coder et il le fait plutôt bien et vite :) > > A noter que le nom risque de changer car OpenMaps est visiblement plutôt > beaucoup pris sur internet... Faudrait pas avoir un procès pour une > histoire de nom :) > > > Cédric > > Le 06/10/2019 à 15:27, Cédric Frayssinet a écrit : > > > Bonjour, > > Et merci pour vos retours. Je n'ai pas forcément pensé immédiatement > l'application comme outils de contributions mais plutôt un outil à avoir > sur soi pour switcher facilement entre les services éparpillés sur le web. > > On peut imaginer le scénario suivant (purement fictif, hein ^^) : Je veux > aller manger dans un restau végétarien au centre d'une petite ville de > province. > > - je lance l'application et OpenRouteService pour trouver le trajet > adapté, > - je switche sur OpenfuelMap pour faire le plein moins cher, > - je switche sur FreeParking pour trouver un parking gratuit, > - je switche sur OpenVegeMap et avant, je peux avoir basculé sur > OpenBeerMap pour trouver le bar avec ma bière préféré :) > > Bref, l'idée est une application simple et je trouve que l'application s'y > prête mieux qu'un navigateur sur mobile. > De plus, je suis de plus en plus surpris par l'usage des smartphones des > gens 'normaux'. La plupart se contente de recherches dans le champ Google > pour afficher le navigateur, ils n'ont pas l'usage des marque-pages, > historique ou raccourcis sur le bureau du smartphone. > > Concernant la contribution, je l'ai rajouté après car il m'arrive souvent > de lancer la navigateur pour avoir le rendu osm.org afin de savoir si > certains POI que je croise sont déjà dans la base. C'est la contribution > avec OsmAnd qui me rend méfiant. En ajoutant, OpenAdvert ou MapContrib, > cela pourrait être pratique de tout avoir sous la main. > > Cédric > > Le 06/10/2019 à 14:46, Stéphane Péneau a écrit : > > Question peut-être idiote : > Pourquoi une appli et pas un site web ? > > Stf > > Le 06/10/2019 à 14:03, PanierAvide a écrit : > > Bonjour Cédric, > > Content de découvrir cette application, ça me semble très prometteur pour > faire la promotion de la diversité des données d'OSM. Avec quelques > fonctionnalités en plus (liens vers les applis mobiles, ajout de notes ?) > ça pourrait même devenir un bon couteau suisse de contribution ;-) > > Cordialement, > > Adrien P. > > Le 06/10/2019 à 10:43, Cédric Frayssinet a écrit : > > Bonjour à tous, > > Quand je suis en formation SNT, pour présenter OpenStreetMap, j'ai > tendance à afficher quelques cartes thématiques pour montrer la richesse > de l'éco-système OpenStreetMap. Et puis, jeudi, lors d'une formation, je > me suis dit que ce serait pas mal d'avoir une appli qui me recense ces > cartes. > > J'en ai parlé à Tom79, le talentueux développeur de Fedilab (application > pour Mastodon, PeerTube, Pleroma, PixelFed...) qui m'a codé cela hier. > > L'application OpenMaps est donc née et elle propose un unique bouton > menu qui permet de switcher très rapidement sur les différentes cartes > basées sur OSM, classées par catégories. > > J'ai donc la toute première version à vous soumettre, l'apk est sur la > page du projet ici : https://framagit.org/tom79/openmaps > > Dites-moi ce que vous en pensez :) > > Bon dimanche ! > > Cédric > > PS : il y a un bug sur MapContrib, je ne sais pas bien pourquoi... > > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > > > > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > > > -- > Dégooglisé ! <https://degooglisons-internet.org/> - Sociétaire Enercoop > <https://souscription.enercoop.fr/code/PARRAIN_OrcGUb
Re: [OSM-talk-fr] Argumentaire pour la mise en place d'un serveur de tuile OSM
Bien joué ! Moi je n’y connais rien en montage hardware de serveur, j’ai donc loué chez OVH 150€ pour un mois de test mais la capacité était de 1To seulement. Julien “djakk” Le lun. 30 sept. 2019 à 22:00, a écrit : > Ma réponse à Julien : > > *À 100 € le To, tu peux expliquer ?* > > *Je viens d'acheter un Crucial MX500 2 To pour 175 €.* > > *194 > <https://www.ebay.fr/itm/Crucial-MX500-2To-2-5-SSD-CT2000MX500SSD1-neuf-et-scelle-garantie-5-ans/254368375916>** > mais j'avais 10 % de réduction.* > > *C'est la Rolls (avec la Samsung 860) en 2,5" SATA.* > > *Et j'ai fait 500 coupures franches sur un MX300 (moins bien sur tous les > points de vue) pour essayer de mettre le système de protection contre les > coupures sans arriver à le mettre en défaut* > > *Jean-Yvon* > > Je précise que j'ai monté un serveur non pas monde mais plusieurs pays > d'Afrique, plusieurs d'Europe, plusieurs d'Asie (au moins). > > J'utilisais Tessera, aujourd'hui je partirais plutôt d'OpenMapTiles. > > Ils partagent feuilles de style (vectoriel) et imp2osm pour l'import dans > PostGres. > > Jean-Yvon > Le 30/09/2019 à 17:09, PIERRE Sylvain via Talk-fr - > talk-fr@openstreetmap.org a écrit : > > > > Bonjour, > > > > J’ouvre peut-être quelques portes déjà bien ouvertes, mais voilà je me > lance : > > > > Je m’interroge sur la possibilité/nécessité de mettre en place un serveur > de tuile OSM sur le périmètre d’une région française et de ses régions > limitrophes. > > Au départ le constat que le rendu OSM patine un peu de temps en temps (la > rançon du succès ?), plus des besoins secondaires m’amène à cette > interrogation. > > > > Du coup de quel argumentaire factuel, objectif puis-je disposer pour > vendre ce projet à mes responsables ? Le jeu en vaut-il la chandelle ? > > > > Cordialement > > > > Sylvain > > > > ___ > Talk-fr mailing > listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Argumentaire pour la mise en place d'un serveur de tuile OSM
Salut ! J’ai essayé pour la planète mais la technique actuelle demande beaucoup de disque dur ! Le passage du pbf à postgis est gourmand en disque dur ... Bon je te rassure, pour une région française ça ira. Mais monter son serveur de rendu avec Europe.osm ou planet.osm est trop exigeant en infrastructure, malgré les tutoriels ça n’est accessible qu’à l’élite qui dispose d’un super-serveur ... J’aimerai trouver une technique qui permette de démocratiser le rendu mondial. Du genre moins de disque dur mais plus de processeur. Mapnik ne prend pas que du postgis en entrée ... :-) Julien “djakk” Le lun. 30 sept. 2019 à 17:35, Christian Quest a écrit : > Possibilité: > - sans aucun problème, il y a des tonnes de tutoriels pour ça, le > principal étant https://switch2osm.org/ > - choix possible aussi de passer en rendu vectoriel... les tutos > commencent aussi à s'accumuler > > Nécessité: > - si votre usage est important, ceci libère des ressources sur les > serveurs de la fondation > - si votre usage est critique, ceci vous permet de ne pas être ennuyé par > l'indisponibilité (même temporaire par saturation) des serveurs de la > fondation > > Les ressources nécessaires sur une zone restreinte ne sont pas énormes, > surtout si l'on ne fait que des mises à jour pas trop fréquentes. > > > Le lun. 30 sept. 2019 à 17:11, PIERRE Sylvain via Talk-fr < > talk-fr@openstreetmap.org> a écrit : > >> >> >> Bonjour, >> >> >> >> J’ouvre peut-être quelques portes déjà bien ouvertes, mais voilà je me >> lance : >> >> >> >> Je m’interroge sur la possibilité/nécessité de mettre en place un serveur >> de tuile OSM sur le périmètre d’une région française et de ses régions >> limitrophes. >> >> Au départ le constat que le rendu OSM patine un peu de temps en temps (la >> rançon du succès ?), plus des besoins secondaires m’amène à cette >> interrogation. >> >> >> >> Du coup de quel argumentaire factuel, objectif puis-je disposer pour >> vendre ce projet à mes responsables ? Le jeu en vaut-il la chandelle ? >> >> >> >> Cordialement >> >> >> >> Sylvain >> >> >> ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > > > -- > Christian Quest - OpenStreetMap France > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Voies d'accès aux stations-essence
Salut ! Un peu à voir, à Paris les panneaux indiquent "Piste" pour les voies sur trottoir. Je crois que ça s'applique aussi aux quelques station services parisiennes ? Julien "djakk" Le mar. 6 août 2019 à 10:52, marc marc a écrit : > > Bonjour, > > Le 06.08.19 à 10:48, Florian LAINEZ a écrit : > > dégommer du rouge > > dans quel outil ? > > > service=driveway > > "desserve une entreprise" > > c'est ce que j'utilise > > Cordialement, > Marc > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] 15 bougies pour OSM !
Bon anniversaire OSM ! Moi déjà 9 ans OMG Julien "djakk" Le sam. 10 août 2019 à 10:58, Christian Quest a écrit : > > Et oui... déjà 15 ans ! > > Quel formidable travail collaboratif accomplit, il suffit de regarder un peu > en arrière pour mieux s'en rendre compte. > > Voici une bonne occasion de rappeler l'existence de > https://osm.cquest.org/archeosm/ > Vous pouvez y explorer l'état de la carte au 1er janvier 2007, 2008 jusqu'à > 2011, avec le rendu FR actuel. > > 15 ans et toujours une grande défiance de la part des institutions... comme > l'a très rugueusement rappelé Gaël il y a quelques semaines: > https://www.youtube.com/watch?v=9es9773wgIs&t=1805 > > PS: dans moins d'une semaine je fêterai mes 10 ans d'ouverture de compte ;) > -- > Christian Quest - OpenStreetMap France > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Indiquer un croisement
Salut ! Regarde le cas sud-coréen ou japonais ! Julien J Le mar. 9 juil. 2019 à 14:32, althio a écrit : > > je me suis aperçu que la place Jean Jaurès à Montrouge n'était pas un >> élément en tant que tel. >> *Quelle est la meilleure méthode d'après vous pour indiquer une place / >> un croisement ?* >> >> 1. créer un polygone qui englobe tous les éléments de la place >> > > avec https://wiki.openstreetmap.org/wiki/Tag:place%3Dsquare > > C'est mon avis. > > -- althio > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Camera 360
Bonjour Magalie ! J’ai une GoPro fusion 1 et je suis déçu par la qualité des photos : on ne peut pas lire du texte à moins d'être à 2 mètres. Du coup il faut soit acheter plus cher soit utiliser un système DIY avec 4 appareils photos ... La panono est de bonne qualité mais je ne crois pas qu’elle puisse prendre des photos toutes les secondes. Julien “djakk” Le mar. 9 juil. 2019 à 08:45, Magalie Dartus a écrit : > Bonjour, > > Je viens demander un conseil technique. > Nous avons bien entendu l'appel du bureau des OSM France proposant de > financer l'achat de matériel pour les groupes locaux. Ainsi les membres du > groupe toulousain ont décidé de se lancer dans la prise de vues Mappilarry. > Il faut noter que la conférence "Montrouge : la ville la mieux mappée de > France" du SOTM 2019 a très fortement inspiré cette initiative (Merci à > eux!). > > 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? > Question pour les membres du bureau : quel tarif est-il envisageable de > regarder pour cet achat? > > Merci et bonne journée > Magalie > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sotm Heidelberg : on y va ensemble ?
Salut ! Avez-vous rempli le tableur partagé ? :) Sinon, outre les Tesla (modèle "S" à 5 places et modèle "3" à 4 places), j'ai eu un contact d'un ami de mon frère qui loue des "9 places" à Paris, il fait un prix = 80€ la journée, kilométrage illimité. Mais c'est du diesel :( @+ Julien "djakk" Le lun. 17 juin 2019 à 19:05, Julien djakk a écrit : > Bonjour ! J’en serai ! J’émets l’idée d’y aller en Tesla, je connais un > petit loueur sur Rennes qui a tous les modèles :) > > Julien « djakk » > > > Le lun. 17 juin 2019 à 14:53, PanierAvide a > écrit : > >> Bonjour à tous, >> >> Le State of the Map mondial se déroule cette année à Heidelberg, ville >> allemande assez proche de nos frontières. L'association OSM France >> souhaite ainsi faciliter la venue de contributeurs français à >> l'évènement. Plusieurs idées ont été émises pour y parvenir : >> >> - Partager le transport depuis Paris pour converger vers Heidelberg >> - Partager un hébergement sur place pour réduire les frais >> - Prendre en charge les frais de transport/hébergement de contributeurs >> >> Afin que nous puissions trouver les solutions répondant au mieux aux >> attentes, j'ai ouvert un tableur partagé où vous pouvez indiquer si vous >> prévoyez de vous rendre à l'évènement, et quels aspects vous >> intéresseraient pour faciliter votre venue : >> >> https://lite.framacalc.org/orga_fr_sotm_heidelberg >> >> Je vous laisse y ajouter vos infos le plus rapidement possible (avant la >> fin du mois) pour que nous puissions ensuite vous proposer une offre >> mutualisée ou prise en charge dans la mesure du possible :-) >> >> Cordialement. >> >> -- >> Adrien P. >> >> >> ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sotm Heidelberg : on y va ensemble ?
Bonjour ! J’en serai ! J’émets l’idée d’y aller en Tesla, je connais un petit loueur sur Rennes qui a tous les modèles :) Julien « djakk » Le lun. 17 juin 2019 à 14:53, PanierAvide a écrit : > Bonjour à tous, > > Le State of the Map mondial se déroule cette année à Heidelberg, ville > allemande assez proche de nos frontières. L'association OSM France > souhaite ainsi faciliter la venue de contributeurs français à > l'évènement. Plusieurs idées ont été émises pour y parvenir : > > - Partager le transport depuis Paris pour converger vers Heidelberg > - Partager un hébergement sur place pour réduire les frais > - Prendre en charge les frais de transport/hébergement de contributeurs > > Afin que nous puissions trouver les solutions répondant au mieux aux > attentes, j'ai ouvert un tableur partagé où vous pouvez indiquer si vous > prévoyez de vous rendre à l'évènement, et quels aspects vous > intéresseraient pour faciliter votre venue : > > https://lite.framacalc.org/orga_fr_sotm_heidelberg > > Je vous laisse y ajouter vos infos le plus rapidement possible (avant la > fin du mois) pour que nous puissions ensuite vous proposer une offre > mutualisée ou prise en charge dans la mesure du possible :-) > > Cordialement. > > -- > Adrien P. > > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Borne Michelin
Oh oui ajoute dans osm s’il te plaît :) Julien “djakk” Le mer. 8 mai 2019 à 12:30, marc marc a écrit : > Bonjour, > > Le 08.05.19 à 12:05, Jacques Foucry a écrit : > > une vieille borne Michelin d'indication de direction. > > Y a-t-il un intérêt à la signaler ? > > c'est très subjectif :) > il y en a qui aiment renseigner tout ce qui existe. pourquoi pas :) > > > Si oui comment, > > historic=milestone si la borne est aussi une borne kilométrique > si ce n'est pas le cas, je n'ai pas de meilleur idée que historic=stone > mais il doit y avoir mieux :) > > tu peux aussi renseigner les destinations sur les chemins concernés à > condition que les infos de la borne soient utilisable (=visible/lisible > depuis un véhicule) https://wiki.openstreetmap.org/wiki/FR:Key:destination > > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Îlot central
Effectivement c’est bien comme dans le wiki j’avais pas tout bien lu 😂 J’utiliserai cette méthode aussi pour d’autres cas : îlot central avant et après une voie de tourne-à-gauche, muret de séparation de voie bus, îlot de feu rouge, potelets en plastique qui empêchent de tourner à gauche ... Julien « djakk » Le mer. 1 mai 2019 à 10:36, a écrit : > Bonjour comme Axel tu proposes d'utiliser traffic_calming=island comme > indiqué sur le wiki. > > Je vois mal comment on pourrait être contre ! On modélise plutôt qu'on > dessine. J'ai d'ailleurs suggéré à Alex de le proposer en commentant des > modifications faites par l'autre contributeur. > > Jean-Yvon > Le 01/05/2019 à 10:21, Julien djakk - djakk.geograp...@gmail.com a écrit : > > Bonjour ! > > La technique de séparation des chemins est très lourde, du coup perso je > ne l’utilise plus. Et je cherche une technique remplaçante. > > J’ai un peu réfléchi, une « way » pourrait représenter toute la chaussée, > et les îlots centraux seraient des objets posés dessus. > > Certains pourraient être des points (îlot de feu rouge parisien), d’autres > des lignes, comme l’exemple sur la photo de « calming_island » -> dans le > cas de la ligne, ça impliquerait de le couper la « way » pour déclarer sur > le tronçon de route concerné « traffic_calming=island. » > > Qu’en pensez-vous ? > > @+ > Julien « djakk » > > > Le mer. 1 mai 2019 à 08:50, Axel Listes a écrit : > >> Bonjour les contributeurs, >> >> Un contributeur plutôt expérimenté sur Nancy, représente les minis >> terre-pleins (îlots) centraux par une séparation de deux chemins (un >> chemin par sens de circulation), et cela depuis plusieurs années. >> >> Exemple : https://osm.org/go/0DE4Cdi3D >> >> Depuis, je suis tombé sur une balise qui me semble plus approprié pour >> ce type de représentation, l'usage de traffic_calming=island. >> Notamment parce qu'elle décrit plus précisément de quoi il s'agit sur le >> terrain. >> >> http://wiki.osm.org/wiki/Tag:traffic_calming=island >> >> Avez-vous déjà rencontré ce type d'aménagement ? Quel est selon vous la >> meilleure façon de les représenter ? >> >> -- >> >> L’intégralité de ce courrier électronique est exclusivement réservé à >> l'usage des personnes auxquelles il est destiné. L’auteur ne donne pas >> autorisation pour une quelconque autre exploitation de données, >> notamment à des fins de statistiques et de surveillance. >> >> ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > > ___ > Talk-fr mailing > listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Îlot central
Bonjour ! La technique de séparation des chemins est très lourde, du coup perso je ne l’utilise plus. Et je cherche une technique remplaçante. J’ai un peu réfléchi, une « way » pourrait représenter toute la chaussée, et les îlots centraux seraient des objets posés dessus. Certains pourraient être des points (îlot de feu rouge parisien), d’autres des lignes, comme l’exemple sur la photo de « calming_island » -> dans le cas de la ligne, ça impliquerait de le couper la « way » pour déclarer sur le tronçon de route concerné « traffic_calming=island. » Qu’en pensez-vous ? @+ Julien « djakk » Le mer. 1 mai 2019 à 08:50, Axel Listes a écrit : > Bonjour les contributeurs, > > Un contributeur plutôt expérimenté sur Nancy, représente les minis > terre-pleins (îlots) centraux par une séparation de deux chemins (un > chemin par sens de circulation), et cela depuis plusieurs années. > > Exemple : https://osm.org/go/0DE4Cdi3D > > Depuis, je suis tombé sur une balise qui me semble plus approprié pour > ce type de représentation, l'usage de traffic_calming=island. > Notamment parce qu'elle décrit plus précisément de quoi il s'agit sur le > terrain. > > http://wiki.osm.org/wiki/Tag:traffic_calming=island > > Avez-vous déjà rencontré ce type d'aménagement ? Quel est selon vous la > meilleure façon de les représenter ? > > -- > > L’intégralité de ce courrier électronique est exclusivement réservé à > l'usage des personnes auxquelles il est destiné. L’auteur ne donne pas > autorisation pour une quelconque autre exploitation de données, > notamment à des fins de statistiques et de surveillance. > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] polygone pour représenter un trottoir
Salut ! Moi je pense que tout est représentable sous forme de polygone, mais qu’on a pas forcément le temps du coup on simplifie en ligne voire en point. Reste le problème de la généralisation (la transformation du polygone en ligne) qui impose peut être de faire polygone + ligne. Julien « djakk » Le sam. 27 avr. 2019 à 13:39, Noémie Lehuby via Talk-fr < talk-fr@openstreetmap.org> a écrit : > Bonjour, > > que pensez-vous de cette modélisation des trottoirs, sous la forme de > multipolygones ? > > https://www.openstreetmap.org/relation/1979876 > https://www.openstreetmap.org/relation/1979878 > > Je comprends qu'il soit tentant de micro-cartographier les trottoirs > comme des polygones, mais je suis un peu sceptique. > > Le wiki est en tout cas formel, la représentation de ce type d'objet est > normalement uniquement sous forme de chemin : > https://wiki.openstreetmap.org/wiki/FR:Tag:highway%3Dfootway > > -- > nlehuby > > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Les portes de Paris
Même problématique avec les stations de métro dont le nom defini le
quartier ;)
Les portes correspondent au carrefour sur les Maréchaux, en tout cas c’est
ce qu’indiquent les panneaux directionnels pour celles qui sont indiquées.
Julien « djakk »
Le mar. 19 mars 2019 à 10:44, Florimond Berthoux <
florimond.berth...@gmail.com> a écrit :
> Globalement d'accord avec toi Althio.
> Je voudrais insister sur le fait qu'un point place=locality me semble pas
> suffisant du tout, où le placer ? sur le boulevard, sur le periph, sur les
> rails du tramway, aux arrêt de bus ?
> Historiquement c'était assez simple, la porte c'était la porte, un unique
> lieu de passage, aujourd'hui c'est plusieurs lieux.
>
> Finalement je me dis que la porte n'existant plus, la notion de porte est
> portée par ces dérivés : arrêt de bus/tram, bretelle de périph, avenue, si
> bien qu'on pourrait retirer le nœud place=locality.
> Et j'aime pas cette définition de locality "pas de population", alors que
> c'est évidemment faux pour les portes de Paris.
>
> Je ne sais quoi décider, ajouter un place=gateway ?
>
> (Ça va se terminer en changeant rien, mais on peut rajouter les quartiers
> importants tout de même :D)
>
> Le lun. 18 mars 2019 à 22:46, althio a écrit :
>
>> Presque pareil que Jean-Yvon pour moi :
>>
>>> > Place=locality n'est pas un point, c'est un lieu sans habitant, les
>>> (quartiers) des "portes" de Paris sont maintenant habitées.
>>> Et actuellement personne n'habite sur une porte.
>>> Donc locality me va bien. Si par contre des quartiers s'appellent du nom
>>> de la porte d'à côté alors il faut mettre un contour et
>>> suburb/neighbourhood/quarter.
>>>
>>
>> Un point avec place=locality : très bien pour les véritables lieux des
>> "Portes".
>> Je préfère un point, mais à la limite pourquoi pas un polygone qui
>> englobe les voies, le carrefour, de manière très étroite, mais pas les
>> bâtiments.
>> C'est le point exact si on vise une navigation avec cette destination ou
>> un passage par ce point.
>>
>> Un point (ou un polygone qui englobe les habitations du quartier) avec
>> place=suburb/neighbourhood/quarter : si et seulement si il y a un véritable
>> quartier avec une existence locale, qui répond à ce nom.
>> Pour Porte d'Orléans, tout à fait, il me semble que c'est suffisamment
>> reconnu pour être un nom de quartier ("J'habite à Porte d'Orléans", en plus
>> des commerces, aménités et arrêts de transport en commun qui reprennent le
>> nom).
>> Il y aurait quand même un travail de recensement des portes et de leur
>> reconnaissance en tant que quartier, pour affecter le bon niveau de
>> place=suburb/neighbourhood/quarter aux lieux qui pourraient en
>> bénéficier... et puis estimer leur "centre" ou leur "périmètre".
>>
>> On Sun, 17 Mar 2019 at 11:13, djakk djakk wrote:
>>
>>> Salut !
>>>
>>> Un peu perdu dans toutes les sous-discussions, j’en relance une :)
>>>
>>> C’est moi qui avait initié la cartographie des portes de Paris.
>>> Actuellement c’est le nom d’un carrefour, souvent marqué sur les panneaux
>>> routiers. Mais certaines portes sont très proches les une des autres : si
>>> la Porte d’Orléans peut être le nom du quartier, la porte de Montrouge
>>> toute proche n’en est pas un. Elle ferait partie du quartier « porte
>>> d’Orléans » .
>>>
>>> @+
>>> Julien « djakk »
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> --
> Florimond Berthoux
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Interdiction de tourner à gauche non respectée
Marc, tu peux penser personnellement que ça n’est pas utile mais je ne pense pas que tu puisses parler au nom de tous les contributeurs osm ... 🤔 Julien « djakk » Le dim. 17 mars 2019 à 20:45, marc marc a écrit : > Le 17.03.19 à 16:01, djakk djakk a écrit : > > Dans mon voisinage il y a une interdiction de tourner à gauche qui n’est > > pas du tout respectée. Comment le refléter dans openstreetmap ? > > comme un interdiction de tourner à gauche normale > et puis t'ajoute un tag genre zuei=rezzrezw qui ne serra utilisé par > personne mais qui permettra de te dire que t'as fait ton edit trollesque :) > si tu veux croire que c'est utile, tu peux inventer un tag moins > aléatoire genre respectducodedelaroute=rare > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le Santerre
Est-ce que ça existe dans d’autres pays ? Des régions avec des frontières non administratives ? Julien « djakk » Le dim. 17 mars 2019 à 20:11, Florimond Berthoux < florimond.berth...@gmail.com> a écrit : > Salut, > > Dans le même genre, j'aimerai aussi ajouter La Thiérache, région naturelle > et culturelle avec son fromage, son journal local, ses communautés de > communes et sa page wikipedia :) > https://fr.wikipedia.org/wiki/Thi%C3%A9rache > > utiliser place=county « A county - a geographical region of a country. » ? > > > Le dim. 17 mars 2019 à 15:45, djakk djakk a > écrit : > >> Salut ! Le Santerre, un « petit pays » qui a son panneau touristique >> marron sur l’autoroute A29 et sa page Wikipedia. >> Le genre d’info non-administrative que j’aimerai avoir sur OpenStreetMap >> ! :) >> >> Julien « djakk » >> > ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr > > >> > > -- > Florimond Berthoux > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Interdiction de tourner à gauche non respectée
Il ne s’agit pas d’une possibilité isolée mais d’une pratique courante vérifiable facilement ... Julien « djakk » Le dim. 17 mars 2019 à 19:59, GarenKreiz a écrit : > Le jour où un conducteur utilisant OSM provoquera un accident mortel, pas > sûr que cela fasse de la bonne publicité! > > Tant que nos véhicules sont conduits par de personnes dotées de libre > arbitre et pouvant décider à tout moment de griller un feu rouge, couler un > stop, rouler à contre sens, se stationner sur le trottoir, franchir une > ligne blanche pour tourner, etc, il est sans doute inutile de noter dans > OSM que les lois peuvent être contournées sur le terrain. > > > > On Sun, 17 Mar 2019 at 18:46, djakk djakk wrote: > >> >> Oui il faut cartographier d’un côté ce que veut l’administation et de >> l’autre ce qui se passe en vrai. :) >> >> Arf ! Ça serait super si on pouvait faire un grand polygone pour faire un >> héritage d’attributs ... >> >> >> Julien « djakk » >> >> >> >> Le dim. 17 mars 2019 à 18:43, Léo El Amri via Talk-fr < >> talk-fr@openstreetmap.org> a écrit : >> >>> On 17/03/2019 16:01, djakk djakk wrote: >>> > Dans mon voisinage il y a une interdiction de tourner à gauche qui >>> n’est >>> > pas du tout respectée. Comment le refléter dans openstreetmap ? >>> >>> Hum... Est-ce qu'on devrait vraiment cartographier ça ? >>> >>> Parce que si oui, j'ai la moitié des intersections de Saint-Denis et >>> autour à modifier ;) >>> >>> ___ >>> Talk-fr mailing list >>> Talk-fr@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-fr >>> >> ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Interdiction de tourner à gauche non respectée
Oui il faut cartographier d’un côté ce que veut l’administation et de l’autre ce qui se passe en vrai. :) Arf ! Ça serait super si on pouvait faire un grand polygone pour faire un héritage d’attributs ... Julien « djakk » Le dim. 17 mars 2019 à 18:43, Léo El Amri via Talk-fr < talk-fr@openstreetmap.org> a écrit : > On 17/03/2019 16:01, djakk djakk wrote: > > Dans mon voisinage il y a une interdiction de tourner à gauche qui n’est > > pas du tout respectée. Comment le refléter dans openstreetmap ? > > Hum... Est-ce qu'on devrait vraiment cartographier ça ? > > Parce que si oui, j'ai la moitié des intersections de Saint-Denis et > autour à modifier ;) > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Interdiction de tourner à gauche non respectée
althio me propose : type=restriction restriction=no_left_turn except=*lawbreaker* *informal=not_respected* :) Julien « djakk » Le dim. 17 mars 2019 à 16:01, djakk djakk a écrit : > Salut ! > > Dans mon voisinage il y a une interdiction de tourner à gauche qui n’est > pas du tout respectée. Comment le refléter dans openstreetmap ? > > Julien « djakk » > > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Interdiction de tourner à gauche non respectée
Salut ! Dans mon voisinage il y a une interdiction de tourner à gauche qui n’est pas du tout respectée. Comment le refléter dans openstreetmap ? Julien « djakk » ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Le Santerre
Salut ! Le Santerre, un « petit pays » qui a son panneau touristique marron sur l’autoroute A29 et sa page Wikipedia. Le genre d’info non-administrative que j’aimerai avoir sur OpenStreetMap ! :) Julien « djakk » ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Les portes de Paris
Salut ! Un peu perdu dans toutes les sous-discussions, j’en relance une :) C’est moi qui avait initié la cartographie des portes de Paris. Actuellement c’est le nom d’un carrefour, souvent marqué sur les panneaux routiers. Mais certaines portes sont très proches les une des autres : si la Porte d’Orléans peut être le nom du quartier, la porte de Montrouge toute proche n’en est pas un. Elle ferait partie du quartier « porte d’Orléans » . @+ Julien « djakk » ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] améliorer les panneaux entrée et sortie de ville
Salut ! « Direction » c’est l’angle du panneau par rapport au Nord c’est ça ? Name:in et name:out, bonne idée ! Julien « djakk » Le sam. 16 mars 2019 à 13:44, Francescu GAROBY a écrit : > Bonjour, > D'où provient ce "name:2" ? C'est vous qui proposez ce nom de tag ? Je ne > le trouve pas clair du tout ! > Je préférerais "name:in" / "name:out", pour indiquer dans quelle > agglomération on entre/sort. > "Direction", c'est pour indiquer la référence de la route sur laquelle on > se trouve ? Pourquoi ne pas mettre plutôt le nom d'un village/une ville un > peu importante, et se trouvant dans ladite direction ? > > Francescu > > Le ven. 15 mars 2019 à 17:46, Jérôme Seigneuret < > jerome.seigneu...@gmail.com> a écrit : > >> Salut, >> >> J'aimerai améliorer les affichage pour les panneaux d'entrée et sortie de >> ville. >> >> >> voici un cas sur le même panneaux >> direction=310 >> highway=traffic_sign >> name:2=Jouy-en-Josas (sortie) >> name=Les Loges-en-Josas (entrée) >> traffic_sign=city_limit >> >> merci >> >> Jérôme >> ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > > > -- > Francescu > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Les contours de la Bretagne
Et que vas-tu faire de Montmartre qui appartient à moitié au quartier de Clignancourt à moitié au quartier des grandes carrières (je pense que c’est une dénomination typiquement administrative, que personne n'utilise ou ne connais) ? 🤔 Julien “djakk” Le lun. 11 mars 2019 à 11:49, djakk djakk a écrit : > Et le rôle admin_center il est où du coup ? > > Julien “djakk” > > > Le lun. 11 mars 2019 à 11:41, Romain MEHUT a > écrit : > >> "On" ? Sauf erreur, seul Florimond a discuté dans ce sens. >> >> Ce serait pareil encore pour >> https://www.openstreetmap.org/relation/2195026 et >> https://www.openstreetmap.org/node/2143885542 Dans les 2 cas, il s'agit >> bien de définir un quartier (en plus le tag wikidata est identique) et si >> on suit >> https://wiki.openstreetmap.org/wiki/FR:One_feature,_one_OSM_element il >> n'y a pas lieu d'y avoir deux objets. >> >> Romain >> >> Le lun. 11 mars 2019 à 11:09, djakk djakk a >> écrit : >> >>> Bah pourquoi ? On disait justement que ce ne sont pas les mêmes objets >>> (administration contre habitude) >>> >>> Julien “djakk” >>> >>> >>> Le lun. 11 mars 2019 à 10:03, Romain MEHUT a >>> écrit : >>> >>>> Bonjour, >>>> >>>> Au risque "d'échauffer" les échanges, j'ai supprimé les 2 noeuds >>>> "Goutte d'Or" et "Clignancourt" conformément à ce principe >>>> https://wiki.openstreetmap.org/wiki/FR:One_feature,_one_OSM_element >>>> >>>> Romain >>>> >>>> Le dim. 10 mars 2019 à 23:38, Florimond Berthoux < >>>> florimond.berth...@gmail.com> a écrit : >>>> >>>>> Je complète: >>>>> « les 80 quartiers de Paris ont une définition précise pour leurs >>>>> limites » >>>>> définition qui a été arbitrairement décidé par une instance >>>>> administrative, qui n'est même pas présente sur le terrain. >>>>> Un parisien ne parlera par de l'ouest de la porte de la Chapelle comme >>>>> étant la Goutte d'Or ;) >>>>> Donc non, au contraire c'est un bon exemple. >>>>> >>>>> Si le centre d'une région est mieux définit que ses limites extérieurs >>>>> (ce qui est généralement le cas en histoire, les frontières bougent plus >>>>> que le centre d'un territoire). >>>>> Il me parait tout à fait opportun de modéliser cette région par son >>>>> centre. Modélisation certes imparfaite mais qui permet tout de même de >>>>> situer la chose sans trop de subjectivité. >>>>> >>>>> Le dim. 10 mars 2019 à 19:03, Vincent de Château-Thierry < >>>>> osm.v...@free.fr> a écrit : >>>>> >>>>>> Bonjour, >>>>>> >>>>>> Le 10/03/2019 à 17:49, Florimond Berthoux a écrit : >>>>>> > Bonjour, >>>>>> > >>>>>> > Utiliser un point et non un polygone, à placer à peu près au centre >>>>>> de >>>>>> > la région (en espérant qu'il n'y ai pas une guerre de religion du >>>>>> vrai >>>>>> > centre :) ? >>>>>> > C'est ce qui est fait pour les quartiers de Paris, par exemple la >>>>>> Goutte >>>>>> > D'or https://www.openstreetmap.org/node/2142414234 >>>>>> >>>>>> Les quartiers de Paris ne sont pas un bon exemple ici, car >>>>>> contrairement >>>>>> aux régions vécues, dont chacun a sa propre limite (Marc_marc parle >>>>>> de >>>>>> subjectivité et c'est bien le problème de ces limites), les 80 >>>>>> quartiers >>>>>> de Paris ont une définition précise pour leurs limites, reprise par >>>>>> 80 >>>>>> relations comme celle-ci : >>>>>> https://www.openstreetmap.org/relation/2195145#map=15/48.8927/2.3547 >>>>>> >>>>>> Pour revenir à la question initiale pas sûr que boundary=historic >>>>>> soit >>>>>> pratique pour répondre, ça signifierait que chaque zonage correspond >>>>>> à >>>>>> un ancien découpage administratif. Je verrais plutôt une valeur de >>>>>> boundary à définir ou à recycler. Je n'ai pas cherché à quoi >>>>>> correspondent les 161 relations boundary=traditional notamment. >>>>>> >>>>>> vincent >>>>>> >>>>>> ___ >>>>>> Talk-fr mailing list >>>>>> Talk-fr@openstreetmap.org >>>>>> https://lists.openstreetmap.org/listinfo/talk-fr >>>>>> >>>>> >>>>> >>>>> -- >>>>> Florimond Berthoux >>>>> ___ >>>>> Talk-fr mailing list >>>>> Talk-fr@openstreetmap.org >>>>> https://lists.openstreetmap.org/listinfo/talk-fr >>>>> >>>> ___ >>>> Talk-fr mailing list >>>> Talk-fr@openstreetmap.org >>>> https://lists.openstreetmap.org/listinfo/talk-fr >>>> >>> ___ >>> Talk-fr mailing list >>> Talk-fr@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-fr >>> >> ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Les contours de la Bretagne
Et le rôle admin_center il est où du coup ? Julien “djakk” Le lun. 11 mars 2019 à 11:41, Romain MEHUT a écrit : > "On" ? Sauf erreur, seul Florimond a discuté dans ce sens. > > Ce serait pareil encore pour > https://www.openstreetmap.org/relation/2195026 et > https://www.openstreetmap.org/node/2143885542 Dans les 2 cas, il s'agit > bien de définir un quartier (en plus le tag wikidata est identique) et si > on suit > https://wiki.openstreetmap.org/wiki/FR:One_feature,_one_OSM_element il > n'y a pas lieu d'y avoir deux objets. > > Romain > > Le lun. 11 mars 2019 à 11:09, djakk djakk a > écrit : > >> Bah pourquoi ? On disait justement que ce ne sont pas les mêmes objets >> (administration contre habitude) >> >> Julien “djakk” >> >> >> Le lun. 11 mars 2019 à 10:03, Romain MEHUT a >> écrit : >> >>> Bonjour, >>> >>> Au risque "d'échauffer" les échanges, j'ai supprimé les 2 noeuds "Goutte >>> d'Or" et "Clignancourt" conformément à ce principe >>> https://wiki.openstreetmap.org/wiki/FR:One_feature,_one_OSM_element >>> >>> Romain >>> >>> Le dim. 10 mars 2019 à 23:38, Florimond Berthoux < >>> florimond.berth...@gmail.com> a écrit : >>> >>>> Je complète: >>>> « les 80 quartiers de Paris ont une définition précise pour leurs >>>> limites » >>>> définition qui a été arbitrairement décidé par une instance >>>> administrative, qui n'est même pas présente sur le terrain. >>>> Un parisien ne parlera par de l'ouest de la porte de la Chapelle comme >>>> étant la Goutte d'Or ;) >>>> Donc non, au contraire c'est un bon exemple. >>>> >>>> Si le centre d'une région est mieux définit que ses limites extérieurs >>>> (ce qui est généralement le cas en histoire, les frontières bougent plus >>>> que le centre d'un territoire). >>>> Il me parait tout à fait opportun de modéliser cette région par son >>>> centre. Modélisation certes imparfaite mais qui permet tout de même de >>>> situer la chose sans trop de subjectivité. >>>> >>>> Le dim. 10 mars 2019 à 19:03, Vincent de Château-Thierry < >>>> osm.v...@free.fr> a écrit : >>>> >>>>> Bonjour, >>>>> >>>>> Le 10/03/2019 à 17:49, Florimond Berthoux a écrit : >>>>> > Bonjour, >>>>> > >>>>> > Utiliser un point et non un polygone, à placer à peu près au centre >>>>> de >>>>> > la région (en espérant qu'il n'y ai pas une guerre de religion du >>>>> vrai >>>>> > centre :) ? >>>>> > C'est ce qui est fait pour les quartiers de Paris, par exemple la >>>>> Goutte >>>>> > D'or https://www.openstreetmap.org/node/2142414234 >>>>> >>>>> Les quartiers de Paris ne sont pas un bon exemple ici, car >>>>> contrairement >>>>> aux régions vécues, dont chacun a sa propre limite (Marc_marc parle de >>>>> subjectivité et c'est bien le problème de ces limites), les 80 >>>>> quartiers >>>>> de Paris ont une définition précise pour leurs limites, reprise par 80 >>>>> relations comme celle-ci : >>>>> https://www.openstreetmap.org/relation/2195145#map=15/48.8927/2.3547 >>>>> >>>>> Pour revenir à la question initiale pas sûr que boundary=historic soit >>>>> pratique pour répondre, ça signifierait que chaque zonage correspond à >>>>> un ancien découpage administratif. Je verrais plutôt une valeur de >>>>> boundary à définir ou à recycler. Je n'ai pas cherché à quoi >>>>> correspondent les 161 relations boundary=traditional notamment. >>>>> >>>>> vincent >>>>> >>>>> ___ >>>>> Talk-fr mailing list >>>>> Talk-fr@openstreetmap.org >>>>> https://lists.openstreetmap.org/listinfo/talk-fr >>>>> >>>> >>>> >>>> -- >>>> Florimond Berthoux >>>> ___ >>>> Talk-fr mailing list >>>> Talk-fr@openstreetmap.org >>>> https://lists.openstreetmap.org/listinfo/talk-fr >>>> >>> ___ >>> Talk-fr mailing list >>> Talk-fr@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-fr >>> >> ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Les contours de la Bretagne
Effectivement à 10km de Paris on se présente “de Paris” à des gens qui ne sont pas du tout du coin, pour simplifier. 🤗 Julien “djakk” Le lun. 11 mars 2019 à 11:26, marc marc a écrit : > 2 points : > > - dans ce genre d'exemple hautement subjectif, je pense qu'il faut > éviter les "on". untel pense que (y compris s'il est "local" au sens de > source=local knownledge") mais pas "on" permettant de transformer chaque > avis individuel en groupe (fictif ou non) partageant cet avis. > cela gagnerait en visibilité. > > - faire 2 limites administrations <> habitude, franchement j'en vois pas > l'avantage et c'est surtout hautement subjectif. > le gars en bordure mais hors de Paris se considère dans Paris ? > allez hop un place=subjective_truc pour paris, pour la métropole, > pour l’arrondissement, etc > et puis finalement je trouve que je fais partie du prolongement de la > rue d'avant parce que je suis pas d'accord sur le changement de nom de > la rue il y a 10 ans,allez hop encore petit truc pour dire que je > conteste l'administration... > Parce que si ton voisin lui trouve que la limite est une rue + loin, > il a lui aussi le droit de faire une nouvelle relation > place=mon_ressenti_des_limites_de_paris non ? > bienvenu dans OpenAnachiMap... > > Le 11.03.19 à 11:07, djakk djakk a écrit : > > Bah pourquoi ? On disait justement que ce ne sont pas les mêmes objets > > (administration contre habitude) > > > > Julien “djakk” > > > > > > Le lun. 11 mars 2019 à 10:03, Romain MEHUT > <mailto:romain.me...@gmail.com>> a écrit : > > > > Bonjour, > > > > Au risque "d'échauffer" les échanges, j'ai supprimé les 2 noeuds > > "Goutte d'Or" et "Clignancourt" conformément à ce principe > > https://wiki.openstreetmap.org/wiki/FR:One_feature,_one_OSM_element > > > > Romain > > > > Le dim. 10 mars 2019 à 23:38, Florimond Berthoux > > mailto:florimond.berth...@gmail.com>> > > a écrit : > > > > Je complète: > > « les 80 quartiers de Paris ont une définition précise pour > > leurs limites » > > définition qui a été arbitrairement décidé par une instance > > administrative, qui n'est même pas présente sur le terrain. > > Un parisien ne parlera par de l'ouest de la porte de la Chapelle > > comme étant la Goutte d'Or ;) > > Donc non, au contraire c'est un bon exemple. > > > > Si le centre d'une région est mieux définit que ses limites > > extérieurs (ce qui est généralement le cas en histoire, les > > frontières bougent plus que le centre d'un territoire). > > Il me parait tout à fait opportun de modéliser cette région par > > son centre. Modélisation certes imparfaite mais qui permet tout > > de même de situer la chose sans trop de subjectivité. > > > > Le dim. 10 mars 2019 à 19:03, Vincent de Château-Thierry > > mailto:osm.v...@free.fr>> a écrit : > > > > Bonjour, > > > > Le 10/03/2019 à 17:49, Florimond Berthoux a écrit : > > > Bonjour, > > > > > > Utiliser un point et non un polygone, à placer à peu près > > au centre de > > > la région (en espérant qu'il n'y ai pas une guerre de > > religion du vrai > > > centre :) ? > > > C'est ce qui est fait pour les quartiers de Paris, par > > exemple la Goutte > > > D'or https://www.openstreetmap.org/node/2142414234 > > > > Les quartiers de Paris ne sont pas un bon exemple ici, car > > contrairement > > aux régions vécues, dont chacun a sa propre limite > > (Marc_marc parle de > > subjectivité et c'est bien le problème de ces limites), les > > 80 quartiers > > de Paris ont une définition précise pour leurs limites, > > reprise par 80 > > relations comme celle-ci : > > > https://www.openstreetmap.org/relation/2195145#map=15/48.8927/2.3547 > > > > Pour revenir à la question initiale pas sûr que > > boundary=historic soit > > pratique pour répondre, ça signifierait que chaque zonage > > correspond à > > un a
Re: [OSM-talk-fr] Les contours de la Bretagne
Bah pourquoi ? On disait justement que ce ne sont pas les mêmes objets (administration contre habitude) Julien “djakk” Le lun. 11 mars 2019 à 10:03, Romain MEHUT a écrit : > Bonjour, > > Au risque "d'échauffer" les échanges, j'ai supprimé les 2 noeuds "Goutte > d'Or" et "Clignancourt" conformément à ce principe > https://wiki.openstreetmap.org/wiki/FR:One_feature,_one_OSM_element > > Romain > > Le dim. 10 mars 2019 à 23:38, Florimond Berthoux < > florimond.berth...@gmail.com> a écrit : > >> Je complète: >> « les 80 quartiers de Paris ont une définition précise pour leurs limites >> » >> définition qui a été arbitrairement décidé par une instance >> administrative, qui n'est même pas présente sur le terrain. >> Un parisien ne parlera par de l'ouest de la porte de la Chapelle comme >> étant la Goutte d'Or ;) >> Donc non, au contraire c'est un bon exemple. >> >> Si le centre d'une région est mieux définit que ses limites extérieurs >> (ce qui est généralement le cas en histoire, les frontières bougent plus >> que le centre d'un territoire). >> Il me parait tout à fait opportun de modéliser cette région par son >> centre. Modélisation certes imparfaite mais qui permet tout de même de >> situer la chose sans trop de subjectivité. >> >> Le dim. 10 mars 2019 à 19:03, Vincent de Château-Thierry < >> osm.v...@free.fr> a écrit : >> >>> Bonjour, >>> >>> Le 10/03/2019 à 17:49, Florimond Berthoux a écrit : >>> > Bonjour, >>> > >>> > Utiliser un point et non un polygone, à placer à peu près au centre de >>> > la région (en espérant qu'il n'y ai pas une guerre de religion du vrai >>> > centre :) ? >>> > C'est ce qui est fait pour les quartiers de Paris, par exemple la >>> Goutte >>> > D'or https://www.openstreetmap.org/node/2142414234 >>> >>> Les quartiers de Paris ne sont pas un bon exemple ici, car contrairement >>> aux régions vécues, dont chacun a sa propre limite (Marc_marc parle de >>> subjectivité et c'est bien le problème de ces limites), les 80 quartiers >>> de Paris ont une définition précise pour leurs limites, reprise par 80 >>> relations comme celle-ci : >>> https://www.openstreetmap.org/relation/2195145#map=15/48.8927/2.3547 >>> >>> Pour revenir à la question initiale pas sûr que boundary=historic soit >>> pratique pour répondre, ça signifierait que chaque zonage correspond à >>> un ancien découpage administratif. Je verrais plutôt une valeur de >>> boundary à définir ou à recycler. Je n'ai pas cherché à quoi >>> correspondent les 161 relations boundary=traditional notamment. >>> >>> vincent >>> >>> ___ >>> Talk-fr mailing list >>> Talk-fr@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-fr >>> >> >> >> -- >> Florimond Berthoux >> ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Les contours de la Bretagne
Il n’y a de source valide que le cœur des habitants ... et les journaux locaux aussi. Julien “djakk” Le dim. 10 mars 2019 à 13:38, marc marc a écrit : > commencer par trouver une source valide ? :) > il y boundary=historic pour les renseigner > > Le 10.03.19 à 12:49, djakk djakk a écrit : > > Salut ! > > > > Moi j’aimerai bien tagger les “petits pays” dans osm ! La Bretagne > > historique, le Tregor, le Vercors. Ça n’est pas basé sur des limites > > administratives. > > > > Des idées ? > > > > Julien “djakk” > > > > > > Le sam. 9 mars 2019 à 15:34, > <mailto:osm.sanspourr...@spamgourmet.com>> a écrit : > > > > Merci Antoine > > > > Le 09/03/2019 à 15:18, Rpnpif - rpn...@trob.eu > > <mailto:rpn...@trob.eu> a écrit : > >> Les limites > >> historiques pourraient éventuellement être mises avec un tag > historic ou > >> quelque chose comme ça. > > > > C'est dans ce sens que je proposais de créer une relation Bretagne a > > 5 départements avec un end_date : ça permet d'avoir la version > > historique de la Bretagne sans entrer en compétition avec la région > > Bretagne qui ne comporte que 4 des 5 départements ;-). Et en mettant > > des subareas plutôt d'un tracé linéaire afin de ne créer qu'une > > relation à 5 membres et non créer une autre relation difficilement > > maintenable. Après pour afficher il suffit de tenir compte de la > > date de validité de la relation. > > > > Pas la Crimée ? Bah, il y en a bien qui veulent faire Paimbœuf > > traverser la Loire ^^. Et ils n'ont pas forcément tort. > > > > Jean-Yvon > > > > ___ > > Talk-fr mailing list > > Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org> > > https://lists.openstreetmap.org/listinfo/talk-fr > > > > > > ___ > > Talk-fr mailing list > > Talk-fr@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk-fr > > > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Les contours de la Bretagne
Salut ! Moi j’aimerai bien tagger les “petits pays” dans osm ! La Bretagne historique, le Tregor, le Vercors. Ça n’est pas basé sur des limites administratives. Des idées ? Julien “djakk” Le sam. 9 mars 2019 à 15:34, a écrit : > Merci Antoine > Le 09/03/2019 à 15:18, Rpnpif - rpn...@trob.eu a écrit : > > Les limites > historiques pourraient éventuellement être mises avec un tag historic ou > quelque chose comme ça. > > C'est dans ce sens que je proposais de créer une relation Bretagne a 5 > départements avec un end_date : ça permet d'avoir la version historique de > la Bretagne sans entrer en compétition avec la région Bretagne qui ne > comporte que 4 des 5 départements ;-). Et en mettant des subareas plutôt > d'un tracé linéaire afin de ne créer qu'une relation à 5 membres et non > créer une autre relation difficilement maintenable. Après pour afficher il > suffit de tenir compte de la date de validité de la relation. > > Pas la Crimée ? Bah, il y en a bien qui veulent faire Paimbœuf traverser > la Loire ^^. Et ils n'ont pas forcément tort. > > Jean-Yvon > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Une nouvelle manière de tagger les routes
Voilà ! Je ferai une proposition tag par tag. Julien “djakk” Le dim. 3 mars 2019 à 20:00, PanierAvide a écrit : > Bonsoir, > > Merci pour les exemples, c'est plus explicite. La suite c'est de faire une > proposition formelle pour chacun des tags ? Ça permettrait de voir ce qui > passe ou pas au niveau international ;-) > > Cordialement, > > Adrien P. > > Le 03/03/2019 à 18:53, djakk djakk a écrit : > > Salut ! > > J’ai mis à jour la page : > https://wiki.openstreetmap.org/wiki/User:Djakk/new_tagging_scheme_for_roads > > Avec quelques exemples, un tordu et 2 normaux > > Nouveauté : une séparation de la classification locale et de la > classification régionale. > > > Julien “djakk” > > > Le mar. 26 févr. 2019 à 16:01, djakk djakk a > écrit : > >> Bonne question au sujet de la relativité, entre les rues de New York et >> les routes du Nord du Canada ! Moi j’aimerai afficher les routes du Canada >> en « piste » dès zoom=5 et n’afficher les autoroutes urbaines secondaires >> de New York qu’à partir de zoom=12. >> Il faut des attributs pour ça : « importance » et « surface » seraient >> suffisants. « Highway » ne me serait pas utile dans ce cas. >> >> Julien « djakk » >> >> >> Le mar. 26 févr. 2019 à 14:58, marc marc a >> écrit : >> >>> je ne saisis pas en quoi cela aurait tout son sent d'avoir la moitié des >>> infos dans un schéma, l'autre moitié dans l'autre et une partie des >>> infos incohérente entre 2 schémas qui coexisterait pendant 10 ans. >>> >>> je ne vois pas non plus en quoi la proal de djiark t'aiderai dans ton >>> problème, si le trunk japonais permet le piéton et l'européen non. >>> pour résoudre cela il y a la propal des valeur par défaut (avoir le >>> contenu de la page wiki dans des relations par pays voir régions >>> afin que chaque outil ne doivent plus réinventer la roue pour >>> les récupérer) >>> >>> le problème no 1 est peut-être de définir le besoin. >>> la propal parle d'un rendu différent entre la première photo >>> et la 2ieme. >>> j'attends de voir les valeurs des tags et des sources sur les exemples >>> proposés pour voir un peu + clair sur ce qui n'est pas possible >>> avec les tags actuels pour les ways routier (pour les autres il est >>> vrai qu'il y a moins de niveau différent et de critères pertinent) >>> >>> Le 26.02.19 à 14:18, Florimond Berthoux a écrit : >>> > Bonjour, >>> > >>> > Au contraire ça a tout son sens, si OSM a une visée mondiale ça serait >>> > rudement pratique pour les utilisateurs des données que les tags >>> soient >>> > universels. >>> > Parce que là concrètement si je veux faire une carte pour cycliste (à >>> > tout hasard ;) je dois m'amuser à parser la page du wiki >>> > >>> https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restriction >>> > pour connaitre la cyclabilité des trunks et faire un code spécifique >>> > pour chaque région. Ça devient lourd. >>> > >>> > Le mar. 26 févr. 2019 à 13:21, >> > <mailto:osm.sanspourr...@spamgourmet.com>> a écrit : >>> > >>> > Bonjour, >>> > >>> > Le cas du public_transport v2 est un "bon" précédent au même titre >>> > que la privatisation du rail en Grande-Bretagne : l'exemple à ne >>> pas >>> > suivre. >>> > >>> > Si on veut que trunk soient les voies express/rapides actuellement >>> > limitées à 110 km/h, il suffit de se mettre d'accord. >>> > >>> > Changer de modèle parce qu'un attribut n'est pas utilisé en France >>> > comme ailleurs ça n'a aucun sens. >>> > >>> > Jean-Yvon >>> > >>> > -- >>> > Florimond Berthoux >>> > >>> > ___ >>> > Talk-fr mailing list >>> > Talk-fr@openstreetmap.org >>> > https://lists.openstreetmap.org/listinfo/talk-fr >>> > >>> >>> ___ >>> Talk-fr mailing list >>> Talk-fr@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-fr >>> >> > ___ > Talk-fr mailing > listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Une nouvelle manière de tagger les routes
Salut ! J’ai mis à jour la page : https://wiki.openstreetmap.org/wiki/User:Djakk/new_tagging_scheme_for_roads Avec quelques exemples, un tordu et 2 normaux Nouveauté : une séparation de la classification locale et de la classification régionale. Julien “djakk” Le mar. 26 févr. 2019 à 16:01, djakk djakk a écrit : > Bonne question au sujet de la relativité, entre les rues de New York et > les routes du Nord du Canada ! Moi j’aimerai afficher les routes du Canada > en « piste » dès zoom=5 et n’afficher les autoroutes urbaines secondaires > de New York qu’à partir de zoom=12. > Il faut des attributs pour ça : « importance » et « surface » seraient > suffisants. « Highway » ne me serait pas utile dans ce cas. > > Julien « djakk » > > > Le mar. 26 févr. 2019 à 14:58, marc marc a > écrit : > >> je ne saisis pas en quoi cela aurait tout son sent d'avoir la moitié des >> infos dans un schéma, l'autre moitié dans l'autre et une partie des >> infos incohérente entre 2 schémas qui coexisterait pendant 10 ans. >> >> je ne vois pas non plus en quoi la proal de djiark t'aiderai dans ton >> problème, si le trunk japonais permet le piéton et l'européen non. >> pour résoudre cela il y a la propal des valeur par défaut (avoir le >> contenu de la page wiki dans des relations par pays voir régions >> afin que chaque outil ne doivent plus réinventer la roue pour >> les récupérer) >> >> le problème no 1 est peut-être de définir le besoin. >> la propal parle d'un rendu différent entre la première photo >> et la 2ieme. >> j'attends de voir les valeurs des tags et des sources sur les exemples >> proposés pour voir un peu + clair sur ce qui n'est pas possible >> avec les tags actuels pour les ways routier (pour les autres il est >> vrai qu'il y a moins de niveau différent et de critères pertinent) >> >> Le 26.02.19 à 14:18, Florimond Berthoux a écrit : >> > Bonjour, >> > >> > Au contraire ça a tout son sens, si OSM a une visée mondiale ça serait >> > rudement pratique pour les utilisateurs des données que les tags soient >> > universels. >> > Parce que là concrètement si je veux faire une carte pour cycliste (à >> > tout hasard ;) je dois m'amuser à parser la page du wiki >> > >> https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restriction >> > pour connaitre la cyclabilité des trunks et faire un code spécifique >> > pour chaque région. Ça devient lourd. >> > >> > Le mar. 26 févr. 2019 à 13:21, > > <mailto:osm.sanspourr...@spamgourmet.com>> a écrit : >> > >> > Bonjour, >> > >> > Le cas du public_transport v2 est un "bon" précédent au même titre >> > que la privatisation du rail en Grande-Bretagne : l'exemple à ne pas >> > suivre. >> > >> > Si on veut que trunk soient les voies express/rapides actuellement >> > limitées à 110 km/h, il suffit de se mettre d'accord. >> > >> > Changer de modèle parce qu'un attribut n'est pas utilisé en France >> > comme ailleurs ça n'a aucun sens. >> > >> > Jean-Yvon >> > >> > -- >> > Florimond Berthoux >> > >> > ___ >> > Talk-fr mailing list >> > Talk-fr@openstreetmap.org >> > https://lists.openstreetmap.org/listinfo/talk-fr >> > >> >> ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Une nouvelle manière de tagger les routes
Bonne question au sujet de la relativité, entre les rues de New York et les routes du Nord du Canada ! Moi j’aimerai afficher les routes du Canada en « piste » dès zoom=5 et n’afficher les autoroutes urbaines secondaires de New York qu’à partir de zoom=12. Il faut des attributs pour ça : « importance » et « surface » seraient suffisants. « Highway » ne me serait pas utile dans ce cas. Julien « djakk » Le mar. 26 févr. 2019 à 14:58, marc marc a écrit : > je ne saisis pas en quoi cela aurait tout son sent d'avoir la moitié des > infos dans un schéma, l'autre moitié dans l'autre et une partie des > infos incohérente entre 2 schémas qui coexisterait pendant 10 ans. > > je ne vois pas non plus en quoi la proal de djiark t'aiderai dans ton > problème, si le trunk japonais permet le piéton et l'européen non. > pour résoudre cela il y a la propal des valeur par défaut (avoir le > contenu de la page wiki dans des relations par pays voir régions > afin que chaque outil ne doivent plus réinventer la roue pour > les récupérer) > > le problème no 1 est peut-être de définir le besoin. > la propal parle d'un rendu différent entre la première photo > et la 2ieme. > j'attends de voir les valeurs des tags et des sources sur les exemples > proposés pour voir un peu + clair sur ce qui n'est pas possible > avec les tags actuels pour les ways routier (pour les autres il est > vrai qu'il y a moins de niveau différent et de critères pertinent) > > Le 26.02.19 à 14:18, Florimond Berthoux a écrit : > > Bonjour, > > > > Au contraire ça a tout son sens, si OSM a une visée mondiale ça serait > > rudement pratique pour les utilisateurs des données que les tags soient > > universels. > > Parce que là concrètement si je veux faire une carte pour cycliste (à > > tout hasard ;) je dois m'amuser à parser la page du wiki > > > https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restriction > > pour connaitre la cyclabilité des trunks et faire un code spécifique > > pour chaque région. Ça devient lourd. > > > > Le mar. 26 févr. 2019 à 13:21, > <mailto:osm.sanspourr...@spamgourmet.com>> a écrit : > > > > Bonjour, > > > > Le cas du public_transport v2 est un "bon" précédent au même titre > > que la privatisation du rail en Grande-Bretagne : l'exemple à ne pas > > suivre. > > > > Si on veut que trunk soient les voies express/rapides actuellement > > limitées à 110 km/h, il suffit de se mettre d'accord. > > > > Changer de modèle parce qu'un attribut n'est pas utilisé en France > > comme ailleurs ça n'a aucun sens. > > > > Jean-Yvon > > > > -- > > Florimond Berthoux > > > > ___ > > Talk-fr mailing list > > Talk-fr@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk-fr > > > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Une nouvelle manière de tagger les routes
Marc, le “trunk” anglais (et japonais) n’est pas du tout le même qu’en France, il correspond à une classification administrative, la plus forte avant les autoroutes. Il peut très bien s’appliquer à une grosse route classique ou à un grand boulevard d’une ville. Marc, j’avais mis des sources quand j’ai modifié les highway bretons en fonction du trafic (les cartes de trafic par département). Sans ça c’etait souvent Départementale = secondary. Adrien, il y aura beaucoup de valeurs par défaut, donc j'espère que grâce à ça ça ne tournera pas à l’usine à gaz. Oui je vais mettre des exemples. @+ Julien djakk Le lun. 25 févr. 2019 à 20:09, PanierAvide a écrit : > Bonjour, > > Je suis un peu partagé, autant certains aspects ont du sens (un système > admin_level-like pour les routes c'est intéressant), autant d'autres > aspects vont vite tourner à la même situation qu'actuellement avec > highway=* (tag importance, c'est plus flou la frontière entre routes > qu'entres voies ferrées où le réseau est plus "segmenté"). > > Ma crainte c'est que ça finisse comme la proposition des tags > public_transport=* : une bonne idée au départ, un bazar en pratique car les > outils ne suivent pas (ou qu'à moitié). Ceci étant comme proposait marc, ça > vaudrait le coup de documenter des exemples pour voir ce que ça donnerait > concrètement. > > Cordialement, > > Adrien P. > > Le 25/02/2019 à 19:28, djakk djakk a écrit : > > Salut ! J’ai planché sur une nouvelle manière de tagger les routes (au > sens large, ça comprend les pistes cyclables ou les chemins piétons) : > https://wiki.openstreetmap.org/wiki/User:Djakk/new_tagging_scheme_for_roads > (en anglais) > J’en parle aussi sur la mailing-list tagging mondiale. > > J’attend vos réactions, critiques, nouvelles idées ;-) > > @+ > Julien “djakk” > > ___ > Talk-fr mailing > listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Une nouvelle manière de tagger les routes
Salut ! J’ai planché sur une nouvelle manière de tagger les routes (au sens large, ça comprend les pistes cyclables ou les chemins piétons) : https://wiki.openstreetmap.org/wiki/User:Djakk/new_tagging_scheme_for_roads (en anglais) J’en parle aussi sur la mailing-list tagging mondiale. J’attend vos réactions, critiques, nouvelles idées ;-) @+ Julien “djakk” ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Origine des données Waze
J’ai remarqué ça aussi, un parking assez tordu à mapper s’est retrouvé identique dans waze. Par contre pas ceux à côté. Julien « djakk » Le mar. 22 janv. 2019 à 09:55, Nicolas Moyroud a écrit : > Bonjour, > > De même que Gwenaël je suis totalement opposé à l'idée d'introduire des > "oeufs de pâques" dans OSM. Dans mes présentations d'OSM que je fais aux > étudiants en géomatique, je ne me prive d'ailleurs pas pour dénigrer ces > pratiques chez les producteurs de données géographiques propriétaires. > C'est d'ailleurs un point qui les étonne, la plupart ne sont absolument > pas au courant de ce genre de pratiques. > > Par contre le fait d'avoir des informations tellement détaillées (comme > les chemins privés) qu'on puisse être quasiment sûrs qu'elles > proviendraient d'OSM, là on est tout à fait dans l'esprit ! > > Nicolas > > Le 21/01/2019 à 19:52, Gwenaël Jouvin via Talk-fr a écrit : > > Bonsoir, > > > > Je fais une petite digression sur les « œufs de pâques », à mon avis il > n’est pas acceptable de placer de fausses informations dans OSM puisque > d’après ce que j’ai compris (ou comme je vois ce projet ;-) ), OSM se doit > d’être la plus exacte possible, justement pour se démarquer des cartes > commerciales ou privatives qui regorgent de ces pièges contre la > contrefaçon. > > > > Par contre j’aime beaucoup l’idée de placer des chemins privés, il y en > existe d’ailleurs déjà et ce sont des informations pertinentes afin de > s’assurer que tel ou tel trajet est réalisable ou non. > > > > Gwenaël > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chemin en bois sur pilotis
Salut ! Moi dans ce cas j’ai simplement mis bridge=yes ;) https://www.openstreetmap.org/#map=18/48.15156/-1.67961 Julien « djakk » Le sam. 10 nov. 2018 à 12:02, Gwenaël Jouvin a écrit : > Bonjour à tous, > > Récemment j’ai vu dans une forêt, un chemin construit en lattes de bois, > le tout surélevé d’environ 30 cm à 50 cm au-dessus du sol à l’aide de > pilotis. > > Je ne connais pas le terme technique qui désigne ce genre de chose, alors > voici une illustration : > > https://www.visorando.com/images/original/chemin-sureleve-par-un-platelage-visorando-30127.jpg > > > Actuellement il est taggé > highway=path > surface=wood > > … ce qui ne transcrit pas la particularité de l’aménagement. On pourrait > éventuellement y ajouter la largeur. > > Cependant, existe-t-il un attribut particulier pour indiquer précisément > que c’est un platelage surélevé ? > > > Merci. > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [OSM transport] Cartographie des arrêts de bus de substitution de la ligne RER C
Je dirai que la ligne de substitution est une ligne irrégulière, ce qui se verra quand l’utilisateur cherchera les horaires de la ligne. Ajouter une info sur la fréquence de la ligne dans la relation ? djakk Le jeu. 11 oct. 2018 à 18:15, marc marc a écrit : > Le 11. 10. 18 à 17:05, Charles MILLET a écrit : > > Nous pensons utiliser quelque chose comme ça > > substitution=yes > > sur l'arrêt de bus, pour ma part je ne rajouterais pas de tag > en particulier, c'est un arrêt de bus, y dupliquer l'information > de tous les type de lignes pouvant éventuellement l'utiliser ne semble > à la fois peu pratique et surtout galère à maintenir (parce qu'à chaque > changement, il faut veiller à dupliquer le changement pour garder > la cohérence, faire une analyse osmose ou autre pour surveiller > les inévitables désynchronisation entre les 2 et avoir quelqu'un > qui passe du temps à resynchroniser les données). > Je pense que l'utilisation des données du type de ligne qui passe > à un arrêt doit se faire par les infos de(s) relation(s) de l'arrêt. > Mais je sais qu'on a au moins 2 champions de la duplication dans > la communauté qui ne manqueront pas de faire valoir l'inverse :-) > > > subtitution:lines=RER C > > pour les relations représentant les lignes, > Une possibilité serrait d'avoir exactement le même nom > et donc j'aurais plutôt vu quelque chose genre > name=RER C (mais j'ai vu que le nom des lignes RER est un mix entre > le nom, le from, le to, la ref et la branche...) > substitution=only (la ligne n'existe que quand l'autre est en panne) > substitution:of=train (elle remplace une relation train) > et éventuellement sur la relation du RER C: > substitution:by=bus > en ajoutant l'itinéraire de substitution dans la relation route_master > on pourrait sans doute faciliter une utilisation futur + poussée. > le soucis que je vois c'est que c'est pas prévu d'avoir des route=bus > fils d'une relation route_master=train > ce serrait sans doute utile d'en discuter sur tagging > avec une exemple de relation bus comparable à la relation rer > histoire de rendre la chose compréhensible pour ceux qui n'ont > rien de semblable chez eux. > c'est sans doute un peu prématuré si pour le moment vous en êtes > aux arrêts de bus eux-même. > > > Ces tag pourrons être complétés par une note au besoin. > > les notes peuvent être utile pendant l'expérience sur la première > relation mais à long terme, des outils/contributeurs considèrent > la note comme étant souvent le signe que c'est pas stable d’où > le besoin de transmettre une information et qu'il faut donc > un éventuel coup de main pour transformer la note en tag + adapté. > url=la page wiki sur le changeset serrait très utile pour le > contributeur qui veux en savoir plus sur le projet. > > Cordialement, > Marc > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Parking vélo dans un parking sous-terrain
Bonne idées Florimond ! :) djakk Le mer. 3 oct. 2018 à 13:51, marc marc a écrit : > Le 03. 10. 18 à 13:35, Florimond Berthoux a écrit : > > Comment cartographier un parking vélo dans un parking sous-terrain ? > > > Je vois deux possibilités, soit le parking sous-terrain n'est modélisé > > que par un nœud alors j'ajouterais les tags: > > amenity=parking > > parking=underground > > bicycle=yes > > capacity:bicycle=XX > > cela me semble le plus raisonnable/utilisable pour un parking souterrain > > > Soit le parking sous-terrain est cartographié par une relation de > > différents éléments. Dans ce cas je rajouterais un nœud > > amenity=bicycle_parking. > > mais comme cette relation n'est utilisé par (quasi ?) personne, > j'ajouterai un location=underground sur le nœud histoire > de rendre l'information utilisable. > > Cordialement, > Marc > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Arceaux partagés motos / vélos
JB c’est très embêtant ce que tu dis, osm ne pourra plus évoluer ? ... :O djakk Le jeu. 27 sept. 2018 à 00:01, marc marc a écrit : > cela dépend vraiment de l'endroit... > si c'est un lieu uniquement réservé aux véhicules sncf > je vois pas ce qui empêche de mapper les 2 : > le service amenity=*sharing (c'est un peu comme une station velib... > à cet endroit t'as bcp de chance de trouver un véhicule > même si ceux-ci bougent) > pour l'emprise du parking amenity=*parking + access=customers > mais on ne le fait pas pour les velib... pq le faire pour > le freeflooting ? on gagne qlq chose a renseigner le service > disponible "sur" le sol séparément de la peinture du sol ? > ceci dit en passant aucun schéma n'existe (et donc aucune app) > pour trouver les parkings liés au fait d'être "client xyz) > donc l'usage des données du parking serra bien faible. > > par contre si c'est qlq places dont on veux renseigner l'emprise > au sol dans un parking + grand c'est amenity=parking_space > on ne fait pas un amenity=parking pour chaque type de place > dans un seul parking. > > Le 26. 09. 18 à 23:03, osm.sanspourr...@spamgourmet.com a écrit : > > C'est évidemment plus important car si tu ne loues pas un engin, tu n'as > pas de problème pour le garer. Tu peux le louer et l'utiliser sans le garer > par contre tu ne peux le garer avant de l'avoir loué. > > Pour moi c'est juste du bon sens. Principe de la cause et de l'effet si > *tu* préfères. > > > > Ce que la SNCF a fait c'est peindre un scooter et une puce. Je doute que > ça empêche un propriétaire de scooter de se garer là de bonne foi. > > > > Jean-Yvon > > > >> Gesendet: Mittwoch, 26. September 2018 um 22:45 Uhr > >> Von: "Florimond Berthoux - florimond.berth...@gmail.com" > >> An: "Discussions sur OSM en français" > >> Betreff: Re: [OSM-talk-fr] Arceaux partagés motos / vélos > >> > >> Je ne suis pas certain de vivre dans le monde, mais à Paris ce qu'on > appel > >> "free floating" c'est tu loues un scooter mal garé sur le trottoir pour > >> rouler 3km avec et tu le gares sur un parking 2 roues motorisés (parce > que > >> tu es un mec bien). > >> Ce qu'à fait la SNCF c'est de dire, voici un emplacement de > stationnement > >> dédié et uniquement utilisable au free floating. > >> > >> « Ce qui est important ici c'est que tu *loues* pas que tu gares. Tu > peux > >> garer ton scooter où tu veux (mais si tu ne veux plus payer, > l'emplacement > >> est important). » > >> Le problème c'est que *tu* considères que l'important c'est la location, > >> mais c'est purement subjectif. > >> Je le répète une station de velib c'est un assemblage de fonction : > service > >> de location ET stationnement réservé. L'un n'est pas supérieur à > l'autre. > >> > >> Le mar. 25 sept. 2018 à 22:02, a > écrit : > >> > >>> Non, "free flaoting" et "simple parking" (au sens de stationnement > seul) > >>> c'est incompatible. > >>> > >>> Le concept du véhicule partagé à emplacement variable, c'est de la > >>> *location* de véhicule que tu gares à un endroit précis (comme un > >>> véhicule en autopartage classique) sauf que l'endroit où tu déposes le > >>> véhicule peut être différent de l'endroit où tu l'empruntes. > >>> > >>> Ni plus ni moins, c'est donc bien de l'ordre du car_sharing et non du > >>> parking : tu ne peux utiliser cet emplacement que si tu as emprunté le > >>> véhicule à cet endroit. > >>> On ne tague pas plus les emplacements des voitures de location > >>> amenity=parking. > >>> Ce qui est important ici c'est que tu *loues* pas que tu gares. Tu peux > >>> garer ton scooter où tu veux (mais si tu ne veux plus payer, > l'emplacement > >>> est important). > >>> > >>> Jean-Yvon > >>> > >>> Le 25/09/2018 à 20:37, Florimond Berthoux - > florimond.berth...@gmail.com > >>> a écrit : > >>> > >>> L'exemple dont je parle c'est bien du stationnement, rien d'autre que > du > >>> stationnement réservé à des véhicules de free floating voir photo là > >>> https://twitter.com/ManOnDaMoon/status/1039906448283770880?s=19 > >>> > >>> A
Re: [OSM-talk-fr] restrictions d'accès dans les voies de cimetières
Il suffit d’ajouter un surface=excellent pour que le rendu du highway=track change ;) Mais bon si c’est le cas le chemin est sans doute goudronné -> highway=service du coup. djakk Le dim. 23 sept. 2018 à 22:32, Philippe Verdy a écrit : > de plus je ne vois pas trop en fin de compte la différence entre > "access=permissive" et "access=restricted" qui me semblent indiquer la même > chose et impliquer dans le deux cas l'existence de restrictions d'accès qui > ne sont pas tranchés entre access=yes ou access=no. > > Le dim. 23 sept. 2018 à 20:49, marc marc a > écrit : > >> Le 23. 09. 18 à 19:19, Philippe Verdy a écrit : >> > Quelle valeur indiquer ? >> >> mapper ce qui existe et non la législation. >> highway=path si c'est étroit ou track si c'est assez large >> que pour un véhicule de service y passe (sujet à controverse, >> certain ne voyant dans track que l'aspect rural/agricole/forestier) >> + access selon les panneaux présents >> + barrier éventuelle à leur emplacement >> + opening_hour éventuel >> >> >> > - propriété publique mais d'accès restreint et réglementé dans un >> espace >> > délimité >> > - propriété privée mais d'accès "permissif". >> >> on ne mape pas la propriété dans osm. >> donc les 2 sont access=permissif >> si tu veux maper l'opérateur public du parc operator:type=public >> ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Arceaux partagés motos / vélos
Merci Florimond tu as mis les mots sur un ressenti flou que j’avais. Je trouve que highway=cycleway est un raccourci bien pratique mais il ne s’agirait que d’un alias vers un objet plus+ complexe ayant des valeurs par défaut. djakk Le lun. 24 sept. 2018 à 11:22, Florimond Berthoux < florimond.berth...@gmail.com> a écrit : > Bonjour, > > plus un pour : > > Le jeu. 20 sept. 2018 à 17:54, djakk djakk a > écrit : > >> >> Ou revoir la méthode : >> amenity=parking >> bicycle=yes >> motorcar=no >> hgv=no >> motorcycle=yes >> > > Définir le droit d'accès et le type d'aménagement dans le même tag est une > erreur conceptuelle. > C'est d'abord un parking, autorisé aux deux roues (vélo + moto), avec > dessus une infra de type arceaux. > > (Il y a le même problème avec le highway=cycleway, qui définit à la fois > une route et un droit d'accès.) > > Cordialement. > > > -- > Florimond Berthoux > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Domaine public maritime et limites communales/intercommunales.
Salut ! Je me suis effectivement posé la question du trait de côte dans osm ... ça serait super intéressant d’avoir plusieurs lignes de côte (haute mer - basse mer / fort coefficient - faible coefficient) djakk Le ven. 21 sept. 2018 à 18:30, Philippe Verdy a écrit : > Je commence à m'interroger sur l'inclusion dans le périmètre des communes > (et des EPCI) des ilots côtiers qui font partie du domaine public maritime > (national). > En revanche pas de problème pour les inclure dans les arrondissements, > départements et régions puisqu'il sont de la compétence des préfectures et > sous-préfectures (qui représenent l'Etat). > > Ne pourrait-on pas créer une pseudo-commune avec admin_level=8, au minimum > une par arrondissement, et nommée simplement "Domaine public maritime" ? > Cette relation ferait partie des arrondissements, départements et régions, > mais pas des communes ou leurs EPCI à fiscalité propre (elle pourrait en > revanche faire partie de certains syndicats mixtes, dont ceux gérant les > parcs naturels et associant communes, EPCI, départments, région, Etat) > > On reconnait ces îles et îlots hors périmètre communal/intercommunal non > pas parce que qu'elles ne sont pas habitées ou font ou ne font pas partie > d'une réserve naturelle maritime, mais par le fait que leur terrain émergé > n'est PAS cadastré. > > On peut ajouter à admin_level=8 aussi un admin_type:FR pour indiquer que > ce n'est pas une commune (ou commune nouvelle) mais le domaine public de > l'Etat. Cependant il ne s'agit que de la partie terrestre de ce domaine > maritime qui inclut aussi la partie maritime jusqu'aux limites des eaux > territoriales. > > Hors là, si on y inclut les eaux territoriales, on tombe en fait sur la > compétence des préfectures de régions (qui gèrent les régions maritimes, il > n'y a pas d'arrondissement maritime, même si pour des raisons pratiques les > préfectures de régions maritimes délèguent la gestion du secteur côtier > émergé aux sous-préfets qui sont en relation directe avec les communes > littorales, à qui ils confient aussi des missions de surveillance de ce > domaine maritime, en échange de certains crédits de fonctionnement). Les > communes en revanche ne sont pas chargées de la surveillance et le contrôle > du domaine maritime immergé, mais ont une mission concernant l'estran, > mission partagée aussi avec d'autres services comme les CROSS régionaux et > les services nationaux comme la gendarmerie ou les CRS pour la surveillance > des plages, sous l'autorité des préfectures départementales de police, et > aussi la marine pour la défense. > > Donc peut-on affiner davantage le découpage administratif du littoral ? > > Que faire des plages (notamment leur partie immergeables sur l'estran), > sachant qu'OSM a une définition différente de ses "lignes de côtes" > (estimation visuelle sur la ligne de hautes-eaux) alors que les communes > suivent une définition sur la "ligne de base", qui descend plus bas et > inclut les entrées de ports et bassins fermés par des digues et les > estuaires (avec un passage maritime "pas trop large" ou comprenant un > chenal dragué par l'autorité portuaire locale utilisable même à marée basse > la plupart du temps hors périodes de fortes marées, ou comprenant un > système de retenue des eaux avec une barrière immergée) et pas trop larges; > le trait de ligne de base est estimé aussi sur les ouvrages publics > construits au travers (dont les tunnels, ponts et barrages et entrant dans > la compétence soit des communes, soit des départements en tant que > collectivités, soit plus rarement de l'Etat pour les nationales et > concessions autoroutières) et inclut les "eaux intérieures (dont les > bassins et ports et les estuaires soumis à la marée mais pas forcément > complètement hors d'eau à cause des chenaux dragués). > > On retrouve ces compétences communales du domaine maritime sur l'estran ou > les eaux intérieures dans le cadastre, mais rien au niveau du département > (en tant que collectivité et non de leur préfecture/sous-préfecture). Et > l'Etat ne semble pas délimiter vraiment autre chose que les limites des > eaux territoriales et reste flou sur sa limite de gestion du littoral sur > l'estran et dans les grands estuaires (là le plus précis pour nous reste > encore ce que fait et surveille le SHOM mais assez souvent existe des > conflits entre les communes et l'Etat au sujet de l'extension réelle ce ce > littoral, sauf s'il y a eu des acquisitions par le conservatoire du > littoral (mais celui-ci acquiert aussi des terrains cadastrés qui ne > sortent pas des communes même s'
Re: [OSM-talk-fr] Arceaux partagés motos / vélos
Salut ! J’ai quelque idées : Est-ce l’occasion d’utiliser le point-virgule pour faire une liste ? amenity=motorcycle_parking;bicycle_parking (utilisé une trentaine de fois selon taginfo) Ou une nouvelle valeur : amenity=motorcycle_and_bicycle_parking Ou revoir la méthode : amenity=parking bicycle=yes motorcar=no hgv=no motorcycle=yes djakk Le jeu. 20 sept. 2018 à 17:25, Phyks a écrit : > Salut, > > Dans ma ville, la plupart des stationnements "vélos" sont en fait des > stationnements "deux roues" avec des arceaux qui sont utilisables à la > fois par les motos, les scooters et les vélos (sans distinction). > Comment devrait-on tagger cela au mieux ? > > Il me semble qu'une proposition raisonnable serait un truc comme > > access=yes > amenity=motorcycle_parking > bicycle=yes > bicycle_parking=stands > capacity=? > covered=no > fee=no > > mais cela est-il réellement optimal ? > > Le rendu par défaut des tuiles par défaut et OpenCycleMap ne va pas > l'afficher (voir > https://www.openstreetmap.org/node/5028869329#map=19/48.81712/2.31139 > par exemple qui n'est affiché nulle part). > > Bref, je suis preneur de retours sur cette situation (par défaut, j'ai > l'impression que la plupart des gens les ont mis en parking vélos dans > le coin). > > Merci, > -- > Phyks > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Parc de stationnement en Zone de rencontre
Ta proposition ? Oui bonne idée. djakk Le mer. 19 sept. 2018 à 15:06, Jérôme Seigneuret < jerome.seigneu...@gmail.com> a écrit : > Pas abonné pour le moment. Peux-tu retransmettre la proposition? Merci > > Le mer. 19 sept. 2018 à 14:55, djakk djakk a > écrit : > >> Excellent ! >> >> Il y a justement une discussion en cours sur la taggin’ mondiale à propos >> de la vitesse par défaut. Je viens de toucher un mot sur les “zones 30” >> (C’est : [Tagging] maxspeed:type vs source:maxspeed // StreetComplet) >> >> djakk >> >> Le mer. 19 sept. 2018 à 14:34, Jérôme Seigneuret < >> jerome.seigneu...@gmail.com> a écrit : >> >>> Salut, >>> J'ai pas vraiment pris le temps de m'interroger sur cette histoire de >>> zone légale. Mais je vais aller dans ton sens sur ce sujet. >>> >>> Je pense que pour bien décomposer les éléments il faudrait en toucher un >>> mot avec un juriste qui accepterai de nous aider ou via les universités de >>> droits. C'est un sujet à proposer je pense. >>> >>> J'en reviens à la zone 50 en ville (zone légale 50) puis les zone 30 >>> puis les zones 20 >>> Les notions d'accès (private et permissive) car une voie ouverte à la >>> circulation sans barrière physique est de fait dans la loi une voie privé >>> ouverte à la circulation publique (dans mon métier ça a un impact sur notre >>> activité) >>> >>> Mon problème et en lien avec le source:maxspeed=sign avec par exemple >>> maxspeed=70. Vu que les panneaux de sortie et d'entrée de ville ne sont pas >>> sur toutes les voies (problème de chemins classés en highway=residential ou >>> l'inverse) les outils de propagation de vitesse par simulation entre en >>> conflit car un bord est à 80km/h et l'autre des fois à 30km/h. (peut-être >>> aussi un manque sur les vitesses en zone privé. >>> >>> Bref je vois plus un schéma découlant aussi de name du fait de ce soit >>> une zone et que ce soit un critère lié au loi et règlement (code de la >>> route) et que c'est pas lié uniquement à une notion de vitesse. Donc cette >>> clé doit être décorrélé de maxspeed. >>> >>> je pense à un truc du genre *highway:legal_type* >>> >>> Cette clé a déjà été décrit pour les panneaux publicitaire et comblera >>> emplement le dispositif de vitesse >>> >>> en agglo: >>> Si tu es à 50 les vitesses sont implicites >>> après on peut aussi le faire en explicite >>> maxspeed=50 >>> *highway:legal_type=urban *ou *highway:legal_type:FR=agglomération* >>> Si c'est une voie à 70 >>> maxspeed=50 >>> *highway:legal_type=urban *ou *highway:legal_type:FR=agglomération* >>> maxspeed=70 >>> source:maxspeed=sign >>> >>> Le reste est dans le même contexte >>> >>> Ça règle aussi le problème des Voies vertes >>> *highway:legal_type:FR=Voie Verte* >>> >>> Et évite de jouer juste sur des types de "voie spéciale" sachant que les >>> voies vertes traversent des chemins de halage des voies de service etc avec >>> des conditions de circulation très variables. >>> >>> Qu'en pensez-vous? On réutilise une clé existante qui colle à notre >>> contexte. C'est quand mieux que d'avoir >>> maxspeed:type=* >>> source:maxspeed=FR:zone:30 ou FR:zone30 >>> >>> Et avec ça, on libère et fait mieux correspondre la notion de >>> source:maxspeed >>> >>> D'ailleurs il y a aussi des notions de vitesse que j'appelle "de bon >>> sens" car à moins d'être avec un véhicule de rallye tu ne roules pas >>> toujours au max de la vitesse légale (problème de visibilité, sinuosité, >>> pente, nombre d'accès sur la voirie, espaces boisés etc avec passage de >>> faune) >>> >>> Concernant les vitesses de circulation et les outils il faut voir de ce >>> coté >>> https://wiki.openstreetmap.org/wiki/Routing#Speed_data >>> >>> A+ >>> >>> Le mer. 19 sept. 2018 à 12:02, djakk djakk a >>> écrit : >>> >>>> Ou plus simplement living_street=yes :) >>>> >>>> >>>> djakk >>>> >>>> >>>> Le mer. 19 sept. 2018 à 11:06, djakk djakk a >>>> écrit : >>>> >>>>> Salut ! >>>>> >>>>> Dans cette situation, je vois 2 choses à cartograph
Re: [OSM-talk-fr] Parc de stationnement en Zone de rencontre
Excellent ! Il y a justement une discussion en cours sur la taggin’ mondiale à propos de la vitesse par défaut. Je viens de toucher un mot sur les “zones 30” (C’est : [Tagging] maxspeed:type vs source:maxspeed // StreetComplet) djakk Le mer. 19 sept. 2018 à 14:34, Jérôme Seigneuret < jerome.seigneu...@gmail.com> a écrit : > Salut, > J'ai pas vraiment pris le temps de m'interroger sur cette histoire de zone > légale. Mais je vais aller dans ton sens sur ce sujet. > > Je pense que pour bien décomposer les éléments il faudrait en toucher un > mot avec un juriste qui accepterai de nous aider ou via les universités de > droits. C'est un sujet à proposer je pense. > > J'en reviens à la zone 50 en ville (zone légale 50) puis les zone 30 puis > les zones 20 > Les notions d'accès (private et permissive) car une voie ouverte à la > circulation sans barrière physique est de fait dans la loi une voie privé > ouverte à la circulation publique (dans mon métier ça a un impact sur notre > activité) > > Mon problème et en lien avec le source:maxspeed=sign avec par exemple > maxspeed=70. Vu que les panneaux de sortie et d'entrée de ville ne sont pas > sur toutes les voies (problème de chemins classés en highway=residential ou > l'inverse) les outils de propagation de vitesse par simulation entre en > conflit car un bord est à 80km/h et l'autre des fois à 30km/h. (peut-être > aussi un manque sur les vitesses en zone privé. > > Bref je vois plus un schéma découlant aussi de name du fait de ce soit une > zone et que ce soit un critère lié au loi et règlement (code de la route) > et que c'est pas lié uniquement à une notion de vitesse. Donc cette clé > doit être décorrélé de maxspeed. > > je pense à un truc du genre *highway:legal_type* > > Cette clé a déjà été décrit pour les panneaux publicitaire et comblera > emplement le dispositif de vitesse > > en agglo: > Si tu es à 50 les vitesses sont implicites > après on peut aussi le faire en explicite > maxspeed=50 > *highway:legal_type=urban *ou *highway:legal_type:FR=agglomération* > Si c'est une voie à 70 > maxspeed=50 > *highway:legal_type=urban *ou *highway:legal_type:FR=agglomération* > maxspeed=70 > source:maxspeed=sign > > Le reste est dans le même contexte > > Ça règle aussi le problème des Voies vertes > *highway:legal_type:FR=Voie Verte* > > Et évite de jouer juste sur des types de "voie spéciale" sachant que les > voies vertes traversent des chemins de halage des voies de service etc avec > des conditions de circulation très variables. > > Qu'en pensez-vous? On réutilise une clé existante qui colle à notre > contexte. C'est quand mieux que d'avoir > maxspeed:type=* > source:maxspeed=FR:zone:30 ou FR:zone30 > > Et avec ça, on libère et fait mieux correspondre la notion de > source:maxspeed > > D'ailleurs il y a aussi des notions de vitesse que j'appelle "de bon sens" > car à moins d'être avec un véhicule de rallye tu ne roules pas toujours au > max de la vitesse légale (problème de visibilité, sinuosité, pente, nombre > d'accès sur la voirie, espaces boisés etc avec passage de faune) > > Concernant les vitesses de circulation et les outils il faut voir de ce > coté > https://wiki.openstreetmap.org/wiki/Routing#Speed_data > > A+ > > Le mer. 19 sept. 2018 à 12:02, djakk djakk a > écrit : > >> Ou plus simplement living_street=yes :) >> >> >> djakk >> >> >> Le mer. 19 sept. 2018 à 11:06, djakk djakk a >> écrit : >> >>> Salut ! >>> >>> Dans cette situation, je vois 2 choses à cartographier sur les “way” du >>> parking, l’aspect de la route (highway=service + service=parking_aisle) et >>> l'influence du panneau (un couple clé-valeur à inventer qui montre qu’on >>> utilise le panneau officiel “zone de rencontre” : >>> highway_legal=living_street ?) >>> >>> >>> djakk >>> >>> >>> Le mar. 18 sept. 2018 à 22:49, Jérôme Seigneuret < >>> jerome.seigneu...@gmail.com> a écrit : >>> >>>> @Phyks C'est q'une clause de bon sens mais certains parking sont >>>> affiché avec des vitesses de circulation à 10 20 ou 30 km. >>>> >>>> La loi dit: >>>> >>>> * Article R. 413-18. Lorsque des parcs de stationnement de véhicules >>>> sont aménagés sur des trottoirs ou terre-pleins, les conducteurs ne doivent >>>> circuler sur ceux-ci qu'à une allure très réduite et en prenant toute >>>> précaution pour ne pas nuire aux piétons. * >>>>
Re: [OSM-talk-fr] Parc de stationnement en Zone de rencontre
Ou plus simplement living_street=yes :) djakk Le mer. 19 sept. 2018 à 11:06, djakk djakk a écrit : > Salut ! > > Dans cette situation, je vois 2 choses à cartographier sur les “way” du > parking, l’aspect de la route (highway=service + service=parking_aisle) et > l'influence du panneau (un couple clé-valeur à inventer qui montre qu’on > utilise le panneau officiel “zone de rencontre” : > highway_legal=living_street ?) > > > djakk > > > Le mar. 18 sept. 2018 à 22:49, Jérôme Seigneuret < > jerome.seigneu...@gmail.com> a écrit : > >> @Phyks C'est q'une clause de bon sens mais certains parking sont affiché >> avec des vitesses de circulation à 10 20 ou 30 km. >> >> La loi dit: >> >> * Article R. 413-18. Lorsque des parcs de stationnement de véhicules >> sont aménagés sur des trottoirs ou terre-pleins, les conducteurs ne doivent >> circuler sur ceux-ci qu'à une allure très réduite et en prenant toute >> précaution pour ne pas nuire aux piétons. * >> >> D'ailleurs la notion de nuire n'existe plus et à été remplacé par « ne >> pas constituer un danger pour les piétons » >> >> Maintenant si tu roule dans un parking de supermarché tu peux avoir des >> disposition qui font que tu peux rouler sans être confronté à de la >> circulation piétonne >> Exemple un stop à chaque ailes de parking. Dans le cas contraire il te >> sera difficile voir même risqué de prendre de la vitesse si toutes les >> voies à droite sont des priorités. >> >> La loi nous laisse un peu réfléchir et ne fixe pas de limite stricte >> contrairement à ce qui est dit au permis... Mais difficile de faire un >> évitement à plus de 10km ou un frainage d'urgence avec un volant déporté >> dans une voiture d'autoécole... >> >> En clair si la police estime que tu mets en danger les usagers tu risques >> une amande: >> *Une vitesse excessive par rapport à la configuration des lieux est >> sanctionnée au même titre qu’un excès de vitesse par une contravention de >> 4ème classe (amende forfaitaire de 135 €), mais il n’y a pas de retrait de >> point. * >> >> C'est comme si t'es poursuivi par les motards de la gendarmerie alors que >> tu roule 50km/h au dessus de la moyenne et qu'il n'ont pas de radars. >> >> Donc au final, si il n'y a pas de piétons et pas de panneaux et que tu es >> en ville dans un parking avec des voies qui te permettent de rouler à cette >> vitesse sans faire du drift, tu peux rouler à 50km/h si ça te chante. >> >> Bonne soirée >> >> >> >> >> Le mar. 18 sept. 2018 à 22:19, Phyks a écrit : >> >>> Salut, >>> >>> >>> > En soit rien de franchement étonnant dans beaucoup de voie de service >>> et de >>> > parking de supermarché les voies sont déjà limité à 20 voir à 10km. >>> Pour >>> > info les voies de services n'ont pas de vitesse par défaut (ce sont les >>> > logiciel de routing qui les déduises en fonction des voies de >>> connexions). >>> > En France les voies privés ouvertes à la circulation ne sont pas >>> limité de >>> > manière implicite c'est le même code donc les même conditon de >>> circulation. >>> > Elles reprennent la vitesse de la zone dans laquelle tu es. En clair si >>> > t'es en ville sans panneaux c'est 50km/h... Pareil pour les parking de >>> > centre commerciaux. >>> >>> Mes deux centimes là-dessus, quand je passais le permis on m'avait >>> explicitement dit qu'il fallait passer la première et y rester sur un >>> parking de centre commercial, sinon c'était éliminatoire. >>> >>> J'ai aucune idée de si c'est retranscrit tel quel dans le code de la >>> route ou si c'est une pratique exigée en plus des obligations légales, >>> mais ça me semble difficile de rouler à plus que 10km/h en première :) >>> -- >>> Phyks >>> >>> ___ >>> Talk-fr mailing list >>> Talk-fr@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-fr >>> >> >> >> -- >> Cordialement, >> Jérôme Seigneuret >> ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Parc de stationnement en Zone de rencontre
Salut ! Dans cette situation, je vois 2 choses à cartographier sur les “way” du parking, l’aspect de la route (highway=service + service=parking_aisle) et l'influence du panneau (un couple clé-valeur à inventer qui montre qu’on utilise le panneau officiel “zone de rencontre” : highway_legal=living_street ?) djakk Le mar. 18 sept. 2018 à 22:49, Jérôme Seigneuret < jerome.seigneu...@gmail.com> a écrit : > @Phyks C'est q'une clause de bon sens mais certains parking sont affiché > avec des vitesses de circulation à 10 20 ou 30 km. > > La loi dit: > > * Article R. 413-18. Lorsque des parcs de stationnement de véhicules sont > aménagés sur des trottoirs ou terre-pleins, les conducteurs ne doivent > circuler sur ceux-ci qu'à une allure très réduite et en prenant toute > précaution pour ne pas nuire aux piétons. * > > D'ailleurs la notion de nuire n'existe plus et à été remplacé par « ne > pas constituer un danger pour les piétons » > > Maintenant si tu roule dans un parking de supermarché tu peux avoir des > disposition qui font que tu peux rouler sans être confronté à de la > circulation piétonne > Exemple un stop à chaque ailes de parking. Dans le cas contraire il te > sera difficile voir même risqué de prendre de la vitesse si toutes les > voies à droite sont des priorités. > > La loi nous laisse un peu réfléchir et ne fixe pas de limite stricte > contrairement à ce qui est dit au permis... Mais difficile de faire un > évitement à plus de 10km ou un frainage d'urgence avec un volant déporté > dans une voiture d'autoécole... > > En clair si la police estime que tu mets en danger les usagers tu risques > une amande: > *Une vitesse excessive par rapport à la configuration des lieux est > sanctionnée au même titre qu’un excès de vitesse par une contravention de > 4ème classe (amende forfaitaire de 135 €), mais il n’y a pas de retrait de > point. * > > C'est comme si t'es poursuivi par les motards de la gendarmerie alors que > tu roule 50km/h au dessus de la moyenne et qu'il n'ont pas de radars. > > Donc au final, si il n'y a pas de piétons et pas de panneaux et que tu es > en ville dans un parking avec des voies qui te permettent de rouler à cette > vitesse sans faire du drift, tu peux rouler à 50km/h si ça te chante. > > Bonne soirée > > > > > Le mar. 18 sept. 2018 à 22:19, Phyks a écrit : > >> Salut, >> >> >> > En soit rien de franchement étonnant dans beaucoup de voie de service >> et de >> > parking de supermarché les voies sont déjà limité à 20 voir à 10km. Pour >> > info les voies de services n'ont pas de vitesse par défaut (ce sont les >> > logiciel de routing qui les déduises en fonction des voies de >> connexions). >> > En France les voies privés ouvertes à la circulation ne sont pas limité >> de >> > manière implicite c'est le même code donc les même conditon de >> circulation. >> > Elles reprennent la vitesse de la zone dans laquelle tu es. En clair si >> > t'es en ville sans panneaux c'est 50km/h... Pareil pour les parking de >> > centre commerciaux. >> >> Mes deux centimes là-dessus, quand je passais le permis on m'avait >> explicitement dit qu'il fallait passer la première et y rester sur un >> parking de centre commercial, sinon c'était éliminatoire. >> >> J'ai aucune idée de si c'est retranscrit tel quel dans le code de la >> route ou si c'est une pratique exigée en plus des obligations légales, >> mais ça me semble difficile de rouler à plus que 10km/h en première :) >> -- >> Phyks >> >> ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > > > -- > Cordialement, > Jérôme Seigneuret > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Les bretelles
C’est comme dire de ne pas tagger tous les tronçons de route classique mais seulement au niveau des carrefours car le rendu se débrouillera ;-) djakk Le mer. 19 sept. 2018 à 09:51, djakk djakk a écrit : > Oui tu as raison pour le bac à sable. > > Je ne pense pas qu’il soit possible de calculer automatiquement les 2 > valeurs possibles de highway, par exemple : > https://www.openstreetmap.org/#map=15/48.4506/0.1241 > Ou : > https://www.openstreetmap.org/#map=17/49.35320/1.02963 > > djakk > > > Le mer. 19 sept. 2018 à 01:17, Philippe Verdy a > écrit : > >> encore une fois OSM n'est pas un bac à sable où on peut décider tout seul >> de changer des tags abondamment utilisés et briser les règles >> d'uniformisation. Si le but est de changer le rendu il vaut mieux en >> discuter avec ceux qui maintiennent ces rendus pour modifier quelques >> règles d'analyse des données. Cette analyse est possible et déjà faite par >> exemple dans Osmose qui signale les incohérences. >> >> Le mer. 19 sept. 2018 à 00:23, djakk djakk a >> écrit : >> >>> Bon link_to et link_from ça ne marche pas, j’ai essayé ! >>> >>> J’ai voulu tagger les bretelles autrement car je vois chaque bretelle >>> faisant partie d’un itinéraire “trunk”, “primary” ou “secondary” - la >>> valeur de la route croisée par la route principale, dans les cas les plus >>> simples. De ce point de vue, la bretelle ne fait pas partie de la route >>> principale. >>> >>> Je remarque que les bretelles d’accès aux centres commerciaux sont >>> taggées de ce point de vue (avec highway=service) par les contributeurs. >>> Exemples : >>> https://www.openstreetmap.org/#map=18/48.13893/-1.69541 >>> Https://www.openstreetmap.org/#map=17/48.14052/-1.76931 >>> https://www.openstreetmap.org/#map=18/47.69694/-0.87364 >>> >>> >>> djakk >>> >>> >>> Le mar. 18 sept. 2018 à 11:20, djakk djakk a >>> écrit : >>> >>>> Oui, aussi. >>>> >>>> >>>> djakk >>>> >>>> Le mar. 18 sept. 2018 à 11:17, Rpnpif a écrit : >>>> >>>>> Le 18 septembre 2018, djakk djakk a écrit : >>>>> >>>>> > Ça n’est pas fait au hasard, je te l’ai pourtant expliqué avant que >>>>> tu >>>>> > n'écrives ce mail : >>>>> > https://www.openstreetmap.org/changeset/62524278 >>>>> > :O >>>>> > >>>>> >>>>> Une explication ne signifie pas accord de celui qui la reçoit. >>>>> >>>>> -- >>>>> Alain Rpnpif >>>>> >>>>> ___ >>>>> Talk-fr mailing list >>>>> Talk-fr@openstreetmap.org >>>>> https://lists.openstreetmap.org/listinfo/talk-fr >>>>> >>>> ___ >>> Talk-fr mailing list >>> Talk-fr@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-fr >>> >> ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Les bretelles
Oui tu as raison pour le bac à sable. Je ne pense pas qu’il soit possible de calculer automatiquement les 2 valeurs possibles de highway, par exemple : https://www.openstreetmap.org/#map=15/48.4506/0.1241 Ou : https://www.openstreetmap.org/#map=17/49.35320/1.02963 djakk Le mer. 19 sept. 2018 à 01:17, Philippe Verdy a écrit : > encore une fois OSM n'est pas un bac à sable où on peut décider tout seul > de changer des tags abondamment utilisés et briser les règles > d'uniformisation. Si le but est de changer le rendu il vaut mieux en > discuter avec ceux qui maintiennent ces rendus pour modifier quelques > règles d'analyse des données. Cette analyse est possible et déjà faite par > exemple dans Osmose qui signale les incohérences. > > Le mer. 19 sept. 2018 à 00:23, djakk djakk a > écrit : > >> Bon link_to et link_from ça ne marche pas, j’ai essayé ! >> >> J’ai voulu tagger les bretelles autrement car je vois chaque bretelle >> faisant partie d’un itinéraire “trunk”, “primary” ou “secondary” - la >> valeur de la route croisée par la route principale, dans les cas les plus >> simples. De ce point de vue, la bretelle ne fait pas partie de la route >> principale. >> >> Je remarque que les bretelles d’accès aux centres commerciaux sont >> taggées de ce point de vue (avec highway=service) par les contributeurs. >> Exemples : >> https://www.openstreetmap.org/#map=18/48.13893/-1.69541 >> Https://www.openstreetmap.org/#map=17/48.14052/-1.76931 >> https://www.openstreetmap.org/#map=18/47.69694/-0.87364 >> >> >> djakk >> >> >> Le mar. 18 sept. 2018 à 11:20, djakk djakk a >> écrit : >> >>> Oui, aussi. >>> >>> >>> djakk >>> >>> Le mar. 18 sept. 2018 à 11:17, Rpnpif a écrit : >>> >>>> Le 18 septembre 2018, djakk djakk a écrit : >>>> >>>> > Ça n’est pas fait au hasard, je te l’ai pourtant expliqué avant que tu >>>> > n'écrives ce mail : >>>> > https://www.openstreetmap.org/changeset/62524278 >>>> > :O >>>> > >>>> >>>> Une explication ne signifie pas accord de celui qui la reçoit. >>>> >>>> -- >>>> Alain Rpnpif >>>> >>>> ___ >>>> Talk-fr mailing list >>>> Talk-fr@openstreetmap.org >>>> https://lists.openstreetmap.org/listinfo/talk-fr >>>> >>> ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Les bretelles
Bon link_to et link_from ça ne marche pas, j’ai essayé ! J’ai voulu tagger les bretelles autrement car je vois chaque bretelle faisant partie d’un itinéraire “trunk”, “primary” ou “secondary” - la valeur de la route croisée par la route principale, dans les cas les plus simples. De ce point de vue, la bretelle ne fait pas partie de la route principale. Je remarque que les bretelles d’accès aux centres commerciaux sont taggées de ce point de vue (avec highway=service) par les contributeurs. Exemples : https://www.openstreetmap.org/#map=18/48.13893/-1.69541 Https://www.openstreetmap.org/#map=17/48.14052/-1.76931 https://www.openstreetmap.org/#map=18/47.69694/-0.87364 djakk Le mar. 18 sept. 2018 à 11:20, djakk djakk a écrit : > Oui, aussi. > > > djakk > > Le mar. 18 sept. 2018 à 11:17, Rpnpif a écrit : > >> Le 18 septembre 2018, djakk djakk a écrit : >> >> > Ça n’est pas fait au hasard, je te l’ai pourtant expliqué avant que tu >> > n'écrives ce mail : >> > https://www.openstreetmap.org/changeset/62524278 >> > :O >> > >> >> Une explication ne signifie pas accord de celui qui la reçoit. >> >> -- >> Alain Rpnpif >> >> ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Changement unilatéral de la définition de tags
Le sourire était plutôt crispé j’aurai dû mettre :-] ! djakk Le mar. 18 sept. 2018 à 23:26, Jérôme Seigneuret < jerome.seigneu...@gmail.com> a écrit : > > > Le mar. 18 sept. 2018 à 23:03, marc marc a > écrit : > >> djakk n'est pas un bleu même s'il est rarement aussi actif ici :) >> > Maoui! Il est même plus ancien contributeur que moi! Ben désolé mais en > effet c'est pas un novice ce qui n'étonne d'autant plus. > > @djakk fait de l'humour dans ces changeset > *(ne pas expérimenter ici en fait :) )* > <https://www.openstreetmap.org/changeset/62698429> > > Ben c'est pas un bac à sable donc non... J'ai demandé si l'on pouvait en > mettre un en place pour des projets et des tests de comparaison sur la > liste dev mais je pense pas avoir ciblé la bonne liste peut être tech est > plus approprié. > @marc marc on a la possibilité de mettre ça > en place ou vous avez une doc pour mettre un serveur en place "from > scratch". Le but c'est d'avoir une image et de faire les test dessus. > Pouvoir faire des modif dessus sans impacté le système en place et ainsi > s'en servir pour présenter aussi des cas d'étude sur du routing ou du > géocodage. > > Merci > > > > > Cordialement, > Jérôme Seigneuret > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Changement unilatéral de la définition de tags
Oui Marc j’ai pensé sournoisement à la mauvaise fois mais l’envie de travailler sérieusement prend le dessus très très vite :) Explications après le prochain paragraphe. (Oui la valeur trunk est pourrie il faudrait peut être dire huge) Normalement j’avais mis la bonne source pour la clé traffic (données venant de chaque département - j’ai supposé que c’est copiable pour osm, ai-je bon ?) Voilà ce que j’ai répondu à Stereo du Data Working group qui m’interpellait sur un changeset récent : « Traffic » était une première piste, la clé a toujours son intérêt (à condition que les donnés soient copiables : la donnée vient des départements, alors j’ai supposé que c’était compatible avec osm). L’analyse des données du comptage routier permet d'ébaucher un réseau routier pas forcément évident. On voit l’impact des quatre-voies : les automobilistes ne prennent plus l’ancienne grande route naturellement la plus directe mais la quatre-voies puis une route secondaire pas forcément adaptée. Ça donne un réseau en arêtes de poisson autour de la quatre-voies. La clé « traffic » ne suffit pas car le trafic interurbain (c’est-à-dire : entre deux aires urbaines) est en général faible, du coup il faut une clé pour classifier un itinéraire interurbain (highway_class). Alors : faut-il une clé spéciale pour les itinéraires à l’intérieur d’une aire urbaine (routes périurbaines, autoroutes uniquement urbaines ou Grands Boulevards dans une ville ayant un périphérique pour le trafic de transit ?), ç’a à l’air tentant, je vais réfléchir. L’aspect de la route rentre aussi en compte : ça ressemble à une autoroute, à une semi-autoroute, à une grande route classique ? (-> clé looks_like) Je n’oublie pas l’aspect administratif : officiellement une autoroute ou une « route pour automobiles » (clé legal). Pour finir (pour le moment ?), il y a la performance de la route : l’aménagement routier par rapport à son trafic (carrefour à feu connu pour être générateur de bouchon, échangeur autoroutier dit « mal foutu » ...) (clé performance) @+ djakk Ce que je pense traduire pour taggin’ mondial. Bonus : la clé footway_class et la clé cycleway_class pour les itinéraires pédestres et cyclables. djakk Le mar. 18 sept. 2018 à 23:04, Philippe Verdy a écrit : > Pour info une lecture pertiennte concernant le zonage urbain de l'INSEE > > https://www.insee.fr/fr/information/2115011 > > Plus de concepts sur > > https://www.insee.fr/fr/information/2114631 > > qui présente les données d'études proposées sur > > https://www.insee.fr/fr/recherche/recherche-geographique?debut=0 > > L'INSEE n'est pas non plus la seule institution française à faire du > zonage en France. > > Le mar. 18 sept. 2018 à 22:40, François Lacombe > a écrit : > >> Le mar. 18 sept. 2018 à 22:31, Jérôme Seigneuret < >> jerome.seigneu...@gmail.com> a écrit : >> >>> Certains sujets sont portés par peu de personnes car cela nécessite des >>> connaissances métier (réseaux électriques, eau, télécom) et dont certaines >>> informations de schématisation sont trop complexes >>> Je parle pour InfosReseaux qui s'est occupé de compléter les pages >>> concernant les réseaux électriques. >>> D'autres touches beaucoup plus de gens et sont aussi contrôlé par >>> beaucoup plus de personnes et retouché aussi par bien plus de monde. >>> >> >> Merci :) >> >> Je me souviens aussi avoir commencé maladroitement en éditant directement >> une page de features en 2012, la considérant peu à mon gout. >> C'est le métier qui rentre. >> >> Penser que si on atteint le consensus même partiel, sa contribution a >> plus de chances d'être adoptée et utilisée. >> Il faut de l’endurance >> >> Bonne soirée >> >> François >> ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] zones de parcmètres
Ok :)
Le mar. 18 sept. 2018 à 19:07, Philippe Verdy a écrit :
> C'est pas si hors sujet que ça ! Les stationnements isolés en slalom sont
> aussi un problème dans OSM, difficiles à modéliser correctement sans
> découper très fortement les rues: on doit les marquer individuellement, le
> modèle des parking lanes ne marche pas bien pour eux. Et on constate là où
> ils ont été mis en place que les riverains sont finalement très mécontents
> de la physionomie que prend leur quartier mis à l'écart du reste de la
> ville. Et ça se voit rapidement.
>
> On a réduit de façon mineure un problème pour en créer d'autres bien plus
> graves qui se font sentir rapidement (fermeture des commerces, désertion
> des services publics, suppression/détournement des lignes de transport,
> baisse de la valeur en revente des résidences. Difficultés d'accès pour les
> livraisons, temps de parcours allongés, même augmentation du danger pour
> les cyclistes, coût des accidents, absence de présence de la police (sauf
> pour verbaliser les résidents!), hausse des assurances et des incivilités
> et de la criminalité...
>
> Ces rues n'étant plus très visibles, les municipalités arrêtent aussi
> d'entretenir les espaces verts, la collecte et le recyclage des ordures
> ménagères devient compliquée. Ces quartiers devenus des ilots isolés se
> dégradent vite et vite se transforment en ghettos délaissés. Les
> propriétaires cessent aussi l'entretien régulier des locations ou leurs
> locations ne trouvent plus preneur et les tarifs baissent alors que la
> pression immobilière s'accroît encore plus dans les centres-villes qui
> restent bien desservis par les transports même quand il y a des zones
> piétonnes (qui ne concernent pas ces zones résidentielles mises à l'écart).
>
> Je ne suis pas du tout convaincu que ce système a même renforcé la
> sécurité routière et que cela a accu encore plus le prix des places de
> stationnement ailleurs: cela accroit le saupoudrage résidentiel périurbain
> et la pression publique pour des lignes périurbaines supplémentaires, et de
> façon générale le besoin accru en transports publics (de plus en plus
> couteux pour les intercommunalités) et les temps de transports. Au final,
> on déplace le problème et renforce la pression des espaces dédiés aux
> voitures dans les zones périurbaines "rurbanisées" (pas mieux loties an
> services publics, mais avec plus de constructions de parkings et une
> artificialisation accrue des sols et un gaspillage des espaces ruraux
> naturels et agricoles).
>
> Je ne pense pas que c'est comme ça qu'on va réduire l'usage global de la
> voiture particulière ni apporter une réelle "tranquilité" pour les
> résidents de ces rues transformées en îles-ghettos. Au final on force des
> populations à aller plus loin alors que la ville devrait au contraire se
> densifier et se mixifier davantage.
>
> Le mar. 18 sept. 2018 à 17:30, djakk djakk a
> écrit :
>
>> Houlà sur le dernier paragraphe tu es parti dans un sacré hors-sujet je
>> trouve :)
>>
>> Il faut effectivement ne pas avoir à découper le polygone sinon c’est pas
>> la peine.
>>
>>
>> djakk
>>
>>
>> Le mar. 18 sept. 2018 à 17:26, Philippe Verdy a
>> écrit :
>>
>>> note : les polygones s'appliquent essentiellement au stationnement le
>>> long des voies publiques, mais excluent les aires de staionnement avec
>>> entrées/sorties de parking dédiées qui ont leurs propres règles.
>>> Ils doivent aussi exclure les parkings privés, les voies privées. Je me
>>> demande l'intérêt de ces zones difficiles à délimiter sans couper des tas
>>> de bâtiments et propriétés et à exploiter quand il y a aura de nombreux
>>> trous disséminés.
>>> Je pense que cela devrait plutôt être tagué le long des voies, en même
>>> temps que les "parking lanes" et où sont disposés (à vue) aussi les
>>> horodateurs ou les panneaux de restriction d'usage ("sauf jours de marché à
>>> certaines heures", stationnement alterné par quinzaine, gratuit mais disque
>>> obligatoire, dépose-minute gratuite avec arrêt autorisé mais pas le
>>> stationnement sans conducteur visible à proximité immédiate ou encore au
>>> volant de plus de 5 minutes, 2 minutes dans les aéroports où on passe une
>>> barrière avec un ticket qui facturera en sortie les premières secondes de
>>> dépassement, car dans ce cas cela devient payant dès la première minute aux
>>> horodateurs).
>>> En gros les zones de stationnement sont peut-être affichées sommairement
>>> sur les sites des municip
Re: [OSM-talk-fr] Impasse
Un tribunal, ou une université, ou une sous-préfecture, je le résumerai à
des emplois de bureau ...
Mais, ça n’est pas le bon sujet ! ;P
Pour les impasses, en faisant une requête overpass-turbo, je me rend compte
que le noexit sur les ways est pas mal utilisé malgré “l’interdiction” du
wiki ...
djakk
Le lun. 17 sept. 2018 à 20:57, Philippe Verdy a écrit :
> J'en reviens donc à l'idée d'ajouter dans OSM les limites des unités
> urbaines (au sens de l'INSEE) maintenant fixées plus ou moins sur les
> "pays" (anciens pays Voynet, réformés par les lois depuis 2014, dont la loi
> SRU et maintenant composés d'intercommunalités entières).
>
> Ca limite l'impact : le Pays de Rennes par exemple comprend Rennes
> Métropole dont Rennes est la "ville" centre. mais les autres
> intercommunalités autour n'ont pas de "ville" ("city") centre. Mais au
> mieux des "town". ET on évite des trucs classés par djakk comme "city"
> tels que, en Bretagne: Callac, Merdrignac, Collinée, Plélan-le-Grand. En
> revanche, Redon et Fougères passent le critère en tant que ville centre de
> leur pays... mais pas Vitré (exception due cependant à la dualité de
> l'arrondissement de Fougères-Vitré où l'Etat a accepté de maintenir des
> services délocalisés à Vitré).
>
> On pourrait avoir d'autres critères comme la présence d'un tribunal
> d'instance ou un tribunal du commerce mais la réforme profonde de
> l'institution judiciaire en fait fermer beaucoup...
>
> La présence d'une université est discutable (les universités bretonnes ont
> ouvert diverses "antennes" hors de leur siège) mais est pourtant un signe
> de dynamisme économique des commerces et services. La présence d'un lycée
> ne me parait pas pertinente ou suffisante (des lycées déménagent aussi pour
> s'installer en périphérie des villes). Mais pour les universités (publiques
> ou reconnues d'intéret public comme lm'université catholique d'Angers...
> une exception qu'on n'a pas besoin de gérer car Angers est clairement déjà
> une ville sans ce critère et a aussi une université publique) on a une
> liste complète facilement atteignable.
>
>
>
>
> Le lun. 17 sept. 2018 à 20:44, Philippe Verdy a
> écrit :
>
>> Je vois que djakk continue de changer les villes en Bretagne, Pays de la
>> Loire, Normandie. Apparemmetn il a pris le parti pris d'upgrader les
>> communes centre des intercommunalités, mais attention elles bougent
>> beaucoup, et leur siège n'est pas toujours dans la ville centre (au sens du
>> zonage urbain de l'INSEE).
>>
>> Je pense que l'upgrade ne devrait concerner QUE les villes centre des
>> "pays" (ayant un ou plusieurs SCOTs, il y en a plusieurs généralement quand
>> un des EPCI est une métropole ou une communauté urbaine, pas une simple
>> communauté d'agglomération), et que les pays sont plus ou moins calqué sur
>> les "unités urbaines" de l'INSEE, ou sinon les villes centre des aires
>> urbaines de population suffisante.
>>
>> Mais on n'a pas encore défini les seuils, pour se passer de la règle
>> actuelle de la population municipale (où on garde certaines exptions pour
>> les seuils quasiment atteints ou qui ont été atteints il y a encore peu de
>> temps, pas plus de 20 ans AMHA, même si la population a légèrement baissé
>> depuis, ou si c'est une ville chef-lieu de département, en excluant les
>> chef-lieux d'arrondissements en phase de désuétude, et upgradant en "city"
>> les villes chef-lieux de régions (celles d'avant la réforme de fusion des
>> régions) y compris les régions d'autre-mer, mais pas les petites
>> collectivités d'outre-mer insulaires (elles ont déjà un capital=3 mais si
>> on parle de Saint-Pierre à CPM, c'est clairement pas une "city" au
>> détriment des villes canadiennes voisines comme Halifax)
>>
>> On a des données objectives sur les unités urbaines et les aires urbaines.
>>
>> Le lun. 17 sept. 2018 à 15:04, JB a écrit :
>>
>>> Euh,
>>> On pourrait avoir une vue d'ensemble, de conflits d'intérêts possibles,
>>> de projets perso/professionnels derrière tout ça ?
>>> Ça ressemble de plus en plus à un taggage « pour mon projet ».
>>> D'abord on redéfinit les villes (tiens, ça aiderait bien pour de la
>>> moyenne/petite échelle), puis les trunk (idem), puis les bretelles
>>> (chouette, encore pareil), les impasses (on les supprimera du graphe
>>> routier). Ça râle un peu, alors on utilise un tag en p
Re: [OSM-talk-fr] Changement unilatéral de la définition de tags
Ok ok j’ai tout « revert » y compris sur le wiki (sauf l’annulation de Jérôme qui n’a pas fait de « undo » dans le wiki - j’ai pas vérifié si le contenu est cohérent). L’argument qui a fait mouche chez moi : l’absence de retro-compatibilité. Je présenterai sur la mailing-list tagging (mondiale) un moyen d’arriver à une définition commune dans le monde entier pour la définition des routes, en contournant l’actuelle clé highway au lieu de changer brutalement la définition de ses valeurs. Je trouve que c’est améliorer Openstreetmap de gommer (autant que possible) les différences entre pays sur les définitions de valeurs. (Comment ? en décomposant ce qui fait une route, de l’aspect visuel à la définition administrative à l’utilisation plus ou moins intensive, pour du trajet interurbain ou du trajet intra-urbain). @+ djakk Le mar. 18 sept. 2018 à 09:31, Christian Quest a écrit : > Le dim. 16 sept. 2018 à 15:43, djakk djakk a > écrit : > >> Je pense que je rajoute de l’information sans en supprimer ... ? Bon >> certes je chamboule l’existant ... >> >> djakk >> > > Dommage de procéder ainsi "en force". > > Le tagging sur OSM fonctionne grâce à un consensus, il faut le respecter > ou ouvrir une discussion (large) pour faire naître un nouveau consensus et > ne pas "chambouler" ainsi l'existant, au risque d'un douloureux retour de > flamme. > > > -- > Christian Quest - OpenStreetMap France > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] SOTM-FR 2019 et Fotoquest GO
Bonjour sebseb ! Bienvenue ! Oh, le fond de carte de fotoquest est openstreetmap :) Il y aura peut être un entrefilet dans weeklyosm à ce sujet ? djakk Le mar. 18 sept. 2018 à 17:43, Philippe Verdy a écrit : > En gros c'est une sorte de Pokemon Go pour trouver un trésor (1 ou 2 euros > par photo géolocalisée au point prédéfini, les points étant disposés sur un > maillage carré quasi régulier tous les kilomètres, cela fait juste une > photo par kilomètre carré. Mais les points désignés sont choisis un peu au > hasard et pas accessibles (les photos les plus valorisées sont au milieu de > lacs ou étangs ou dans des zones privées). > > Je ne vois pas trop ce que va faire l'aspect scientifique du projet avec > des photos sur un maillage aussi lâche. Si toutes les emplacements proposés > sont visités, cela coûterait une fortune et je doute de la rentabilité > réelle. Pour moi c'est plus un jeu mobile comme Pokemon Go, mais on ne peut > pas y jouer longtemps ou on oblige les joueurs à prendre des risques et > bafouer la loi et le droit privé, et aussi dépenser beaucoup en déplacement > (bien plus que la rémunération proposée au final chaque joueur ne fera > qu'un cliché ou deux et l'appli ensuite ne sert plus à grand chose, sauf > comme support de diffusion publicitaire). > > Je me demande même si l'appli n'est pas là non pas pour obtenir les > photos, mais plutôt les parcours géolocalisés utilisés pour parvenir aux > points proposés, et mesurer les temps d'accès, bref collecter les traces > GPS (plus ou moins précises sur les mobiles) encore très utilisées en > Allemagne. > > Si l'appli ne décolle pas en France (sauf quelques points visités ça et là > sans doute par des visiteurs germanophones) c'est parce qu'elle n'a aucune > description en français, et la page "à propos" en allemand mélange tout y > compris des clauses de vie privée (pour le RGPD sans doute) assez obscures. > J'ai donc du mal à être convaincu du bénéfice qu'on aurait en France, en > comparaison de Mapillary qui a des buts plus clairs, et sinon de l'imagerie > aérienne (maintenant de très bonne qualité en France métropolitaine) et des > données open data des services publics et exploitants privés de concessions > publiques. > > > > Le mar. 18 sept. 2018 à 16:06, a écrit : > >> >> >> Bonjour à tous, >> je suis nouveau sur la liste mais je suis un peu OSM depuis quelques mois. >> J'avais 2 sujets à aborder, je ne sais pas trop si l'endroit s'y prête >> mais à tout hasard ;) >> >> J'ai vu que la ville de Montpellier était seule candidate pour le State >> Of The Map FR de l'année prochaine >> et sauf erreur de ma part la date de proclamation des résultats est >> dépassée mais je n'ai pas vu de confirmation... >> J'ai loupé quelque chose ? >> >> Autre sujet qui cette fois ne concerne pas vraiment OSM mais que je >> souhaite évoquer ;) >> Connaissez vous http://fotoquest-go.org/en/map/ ou >> http://fotoquest-go.org/en ? >> C'est une initiative autrichien de sciences participatives relatives à >> l'occupation du sol. >> A priori ça n'a pas trop de succès, notamment sur le territoire français >> mais je trouve le sujet intéressant. >> >> Bien cordialement >> S. Silvestre >> >> ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] zones de parcmètres
(Je répondais à Philippe)
Le mar. 18 sept. 2018 à 17:30, djakk djakk a écrit :
> Houlà sur le dernier paragraphe tu es parti dans un sacré hors-sujet je
> trouve :)
>
> Il faut effectivement ne pas avoir à découper le polygone sinon c’est pas
> la peine.
>
>
> djakk
>
>
> Le mar. 18 sept. 2018 à 17:26, Philippe Verdy a
> écrit :
>
>> note : les polygones s'appliquent essentiellement au stationnement le
>> long des voies publiques, mais excluent les aires de staionnement avec
>> entrées/sorties de parking dédiées qui ont leurs propres règles.
>> Ils doivent aussi exclure les parkings privés, les voies privées. Je me
>> demande l'intérêt de ces zones difficiles à délimiter sans couper des tas
>> de bâtiments et propriétés et à exploiter quand il y a aura de nombreux
>> trous disséminés.
>> Je pense que cela devrait plutôt être tagué le long des voies, en même
>> temps que les "parking lanes" et où sont disposés (à vue) aussi les
>> horodateurs ou les panneaux de restriction d'usage ("sauf jours de marché à
>> certaines heures", stationnement alterné par quinzaine, gratuit mais disque
>> obligatoire, dépose-minute gratuite avec arrêt autorisé mais pas le
>> stationnement sans conducteur visible à proximité immédiate ou encore au
>> volant de plus de 5 minutes, 2 minutes dans les aéroports où on passe une
>> barrière avec un ticket qui facturera en sortie les premières secondes de
>> dépassement, car dans ce cas cela devient payant dès la première minute aux
>> horodateurs).
>> En gros les zones de stationnement sont peut-être affichées sommairement
>> sur les sites des municipalités, à titre informatif, mais le terrain
>> détaille les conditions réelles avec une précision bien supérieure et un
>> équipement ou marquage détaillé.
>>
>> Taguer au niveau des voies publiques sera nettement supérieur (et on
>> pourra aussi délimiter les véritables "parking lanes" ont il y a
>> effectivement des places, ou des emplacements individuels qu'on peut taguer
>> directement
>>
>> Les emplacements individuels sont dans des rues résidentielles de plus en
>> plus nombreuses où les municipalités les installent avec sens de
>> circulation prioritaire alterné en "slalom" , pour ne garder qu'une voie à
>> côté des emplacements, la deuxième formant des zones d'attente. Le but de
>> ces places étant de réduire la vitesse et forcer les véhicules à rouler au
>> pas (pas évident quand on en trouve même dans des rues où circulent des bus
>> et camions: ce sont des places pour jouer à l'auto-tamponneuse, les
>> véhicules stationnés sont régulièrement heurtés ou leurs ailes froissées
>> par les véhicules longs comme les bus...) et aussi détourner le trafic vers
>> d'autres avenues et vers la périphérie. ils ont remplacé les côtés de
>> stationnement (le stationnement par côté alterné disparait un peu partout)
>> et réduit largement le nombre de places disponibles, pour forcer les
>> résidents ou visiteurs à utiliser les parkings extérieurs et les transports
>> en commun dans le centre. Ces places isolées en slalom sont souvent
>> gratuites (au risque et péril du propriétaire du véhicule) car la
>> municipalité ne veut pas prendre le risque d'une responsabilité en cas de
>> pépin. Les résidents qui n'ont pas de garage sont bien en peine de se garer
>> ou doivent payer cher des stationnements loin de chez eux ou louer des
>> garages privés, ils hésitent à y garer leur véhicule la nuit car ces
>> emplacements sont dangereux, les accidents nombreux surtout en hiver. Les
>> livraisons à domicile sont également difficiles, comme les déménagements.
>>
>> Si le but était de réduire la vitesse ou le traffic, il était suffisant
>> de mettre des coussins ou dos d'âne, mais ce sont les cyclistes et motards
>> qui se plaignent de leur dangerosité. Ces slaloms sont égalemetn dangereux
>> en toute saison et à toute heure pour les cyclistes qui ne bénéficient pas
>> d'une vraie piste cyclable. J'ai du mal à comprendre la justification de
>> ces stationnements isolés qui transforment une rue résidentielle en piste
>> de slalom géant (à bosses avec les dos d'âne) qui ne sert même plus ses
>> propres résidents et ne réduit pas les accidents (mais favorisent le
>> chiffre d'affaire des carrossiers, et l'augmentation des tarifs des
>> assurances...). Au final cela coûte cher à tout le monde et cela isole des
>> quartiers qui se voient vidés aussi d'activités, de commerces et services
>> pour les transformer en banlieues ou ghe
Re: [OSM-talk-fr] zones de parcmètres
Houlà sur le dernier paragraphe tu es parti dans un sacré hors-sujet je
trouve :)
Il faut effectivement ne pas avoir à découper le polygone sinon c’est pas
la peine.
djakk
Le mar. 18 sept. 2018 à 17:26, Philippe Verdy a écrit :
> note : les polygones s'appliquent essentiellement au stationnement le long
> des voies publiques, mais excluent les aires de staionnement avec
> entrées/sorties de parking dédiées qui ont leurs propres règles.
> Ils doivent aussi exclure les parkings privés, les voies privées. Je me
> demande l'intérêt de ces zones difficiles à délimiter sans couper des tas
> de bâtiments et propriétés et à exploiter quand il y a aura de nombreux
> trous disséminés.
> Je pense que cela devrait plutôt être tagué le long des voies, en même
> temps que les "parking lanes" et où sont disposés (à vue) aussi les
> horodateurs ou les panneaux de restriction d'usage ("sauf jours de marché à
> certaines heures", stationnement alterné par quinzaine, gratuit mais disque
> obligatoire, dépose-minute gratuite avec arrêt autorisé mais pas le
> stationnement sans conducteur visible à proximité immédiate ou encore au
> volant de plus de 5 minutes, 2 minutes dans les aéroports où on passe une
> barrière avec un ticket qui facturera en sortie les premières secondes de
> dépassement, car dans ce cas cela devient payant dès la première minute aux
> horodateurs).
> En gros les zones de stationnement sont peut-être affichées sommairement
> sur les sites des municipalités, à titre informatif, mais le terrain
> détaille les conditions réelles avec une précision bien supérieure et un
> équipement ou marquage détaillé.
>
> Taguer au niveau des voies publiques sera nettement supérieur (et on
> pourra aussi délimiter les véritables "parking lanes" ont il y a
> effectivement des places, ou des emplacements individuels qu'on peut taguer
> directement
>
> Les emplacements individuels sont dans des rues résidentielles de plus en
> plus nombreuses où les municipalités les installent avec sens de
> circulation prioritaire alterné en "slalom" , pour ne garder qu'une voie à
> côté des emplacements, la deuxième formant des zones d'attente. Le but de
> ces places étant de réduire la vitesse et forcer les véhicules à rouler au
> pas (pas évident quand on en trouve même dans des rues où circulent des bus
> et camions: ce sont des places pour jouer à l'auto-tamponneuse, les
> véhicules stationnés sont régulièrement heurtés ou leurs ailes froissées
> par les véhicules longs comme les bus...) et aussi détourner le trafic vers
> d'autres avenues et vers la périphérie. ils ont remplacé les côtés de
> stationnement (le stationnement par côté alterné disparait un peu partout)
> et réduit largement le nombre de places disponibles, pour forcer les
> résidents ou visiteurs à utiliser les parkings extérieurs et les transports
> en commun dans le centre. Ces places isolées en slalom sont souvent
> gratuites (au risque et péril du propriétaire du véhicule) car la
> municipalité ne veut pas prendre le risque d'une responsabilité en cas de
> pépin. Les résidents qui n'ont pas de garage sont bien en peine de se garer
> ou doivent payer cher des stationnements loin de chez eux ou louer des
> garages privés, ils hésitent à y garer leur véhicule la nuit car ces
> emplacements sont dangereux, les accidents nombreux surtout en hiver. Les
> livraisons à domicile sont également difficiles, comme les déménagements.
>
> Si le but était de réduire la vitesse ou le traffic, il était suffisant de
> mettre des coussins ou dos d'âne, mais ce sont les cyclistes et motards qui
> se plaignent de leur dangerosité. Ces slaloms sont égalemetn dangereux en
> toute saison et à toute heure pour les cyclistes qui ne bénéficient pas
> d'une vraie piste cyclable. J'ai du mal à comprendre la justification de
> ces stationnements isolés qui transforment une rue résidentielle en piste
> de slalom géant (à bosses avec les dos d'âne) qui ne sert même plus ses
> propres résidents et ne réduit pas les accidents (mais favorisent le
> chiffre d'affaire des carrossiers, et l'augmentation des tarifs des
> assurances...). Au final cela coûte cher à tout le monde et cela isole des
> quartiers qui se voient vidés aussi d'activités, de commerces et services
> pour les transformer en banlieues ou ghettos sociaux.
>
>
> Le mar. 18 sept. 2018 à 16:05, djakk djakk a
> écrit :
>
>> Yo !
>>
>> Est-ce que tu penses tagger la zone payante avec un polygone ?
>> Vu que les zones sont souvent concentriques, au lieu de « faire un trou »
>> dans des polygones, faire des polygones qui se superposent et donner un
>> indice pour choisir le
Re: [OSM-talk-fr] zones de parcmètres
Yo ! Est-ce que tu penses tagger la zone payante avec un polygone ? Vu que les zones sont souvent concentriques, au lieu de « faire un trou » dans des polygones, faire des polygones qui se superposent et donner un indice pour choisir le bon polygone à un point donné. djakk Le mar. 18 sept. 2018 à 15:41, Julien Lepiller a écrit : > Le 2018-09-18 15:30, Florian LAINEZ a écrit : > > Hello, > > En ville, le stationnement est souvent régulé avec des zones. > > Celles-ci portent souvent un nom de couleur, mais ce n'est pas > > toujours le cas. > > Sous quel tag signaleriez-vous ça ? > > > > Il n'y a pas beaucoup de détails pour les parcmètres sur le wiki > > https://wiki.openstreetmap.org/wiki/FR:Tag:vending%3Dparking_tickets > > Je m'intéresse pour l'instant aux parcmètres de la ville de > > Montrouge et j'ai documenté ça ici : > > https://wiki.openstreetmap.org/wiki/Montrouge#Parcm.C3.A8tres > > > > La première proposition était charge=FR:Montrouge:zone rouge mais à > > priori le tag "charge" indique plutôt des prix, pas des zones. > > > > overpasse m'informe qu'en France, les tags suivants sont utilisés, > > même s'ils sont assez peu répandus : > > parking:ticket:zone > > parking_tickets:zone:FR > > parking_tickets:zone:colour > > vending_machine:zone > > > > Le plus clair et universel me parait parking:ticket:zone=nom de la > > couleur > > Et vous ? > > > > -- > > > > FLORIAN LAINEZ > > @overflorian [1] > > > > Ça serait intéressant : À Rennes on a bien indiqué les zones, mais sous > la forme : > > note=green zone > > par exemple... > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Les bretelles
Oui, aussi. djakk Le mar. 18 sept. 2018 à 11:17, Rpnpif a écrit : > Le 18 septembre 2018, djakk djakk a écrit : > > > Ça n’est pas fait au hasard, je te l’ai pourtant expliqué avant que tu > > n'écrives ce mail : > > https://www.openstreetmap.org/changeset/62524278 > > :O > > > > Une explication ne signifie pas accord de celui qui la reçoit. > > -- > Alain Rpnpif > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Les bretelles
Ça n’est pas fait au hasard, je te l’ai pourtant expliqué avant que tu n'écrives ce mail : https://www.openstreetmap.org/changeset/62524278 :O Le mar. 18 sept. 2018 à 09:48, Philippe Verdy a écrit : > Note: djakk djakk s'est maintenant lancé dan la conversion de "village" en > "town", en piochant au hasard (là encore en Bretagne et à proximité autour > en Basse-Normandie, Maine, Anjou, Loire-Atlantique et Vendée). > Du coup on a des villages mieux classés que les réelles villes pourtant > pas loin. > Et ça se voit dans le rendu final par défaut sur osm.org ! > Il n'y a pas de critère bien défini. On dirait qu'il a décidé de piocher > non pas les bourgs-centre des bassins de vie comme il semble l'indiquer > mais n'importe quelle commune siège d'une communauté de communes (dont > certaines n'existent déjà plus depuis début 2017 ou sont devenues des > communes nouvelles). > > Note: les intercommunalités depuis 2017 ont toutes au moins 15 000 > habitants, mais ça s'est fait de façon forcée, et pas forcément selon les > bassins de vie (qui sont plutôt concertés au niveau des "pays" qui > regroupaient déjà des intercommunalités mais ont été aussi redessinés un > peu lorsque les intercommunalités ont été forcées de fusionner). > > Je ne pense pas que les intercommunalités soient pertinentes, d'autant > plus que leur siège n'est pas forcément non plus dans la commune centre. La > distribution des présences de services publics résulte d'accords locaux > entre communes, le siège de l'intercommunalité résulte aussi de choix > budgétaires et des ressources immobilières, ou de la présence de lignes de > transports. Et même regroupées de force, les intercommunalités ne sont pas > centrées sur leur ville siège dont le bassin de vie et l'attractivité > réelle peut sortir aussi de leur propre territoire et couvrir des communes > de l'intercommunaltié voisine. > > Je suggère de ne pas expérimenter ces changements dans la base OSM > elle-même mais plutôt de mettre au point une base à part sous forme de > liste à partir d'une feuille de calcul pour créer un CSV et générer une > carte uMap permettant de visualiser ces listes sous forme de nuage de > points selon plusieurs critères. Ca permet de ne pas aller trop vite dans > la sélection, vérifier la densité des points selon le niveau de zoom, > ajuster les critères pertinents à retenir sur chaque niveau de zoom, et > ensuite définir éventuellement des tags OSM adaptés, et d'en discuter et > les documenter sur une liste internationale. > > Et ensuite cela permettra aussi de faire les éventuels changements dans > les clés existantes sans en oublier et non au hasard, et même de les > vérifier automatiquement (par exemple, analyse Osmose vérifiant ces > critères). Le rendu suivra ensuite concernant les éventuelles clés > supplémentaires documentées sur lesquelles on aura importé correctement les > valeurs de façon cohérente et vérifiable. Le rendu ensuite pourra suivre et > s'adapter aux critères retenus pour chacun de ses niveaux de zoom. ou en > fonction de la densité relative des libellés > > En attendant, les changements apportés sont plus une pollution et sont une > gêne visuelle évidente pour les réutilisateurs des cartes rendues > standards, notamment pour les rendus voisins des niveaux de zoom 9-10-11 en > France. > > > > Le mar. 18 sept. 2018 à 09:26, Christian Quest > a écrit : > >> Le dim. 16 sept. 2018 à 13:01, Frédéric Rodrigo >> a écrit : >> >>> > Du coup je propose link_from et link_to : pour une bretelle dans le >>> > sens autoroute vers tertiary, on aura link_from=motorway et >>> > link_to=tertiary. >>> >>> Cette information peut être calculé depuis la topologie et là n'apporte >>> rien, même pas de la cohérence. >>> >> >> Je ne vois pas l'intérêt non plus. >> >> L'info est déjà dans la topologie des données et une requête postgis (ou >> autre) permet de savoir à quoi est connecté un tronçon de _link si on en a >> vraiment besoin. >> >> Les données OSM sont des données GEO et à ce titre, on a plein >> d'informations latentes que nous offrent la topologie et la géo, même si >> elle ne figurent pas sur chaque objet en tant que tel. >> Par contre pour tirer le maximum des données OSM il faut savoir exploiter >> topologie et géo, sinon on passe à côté de l'essentiel et on a tendance à >> rajouter des infos redondantes sans grand intérêt (et qui, en plus, ne >> seront pas évident à conserver à jour). >> >> -- >> Christian Quest - OpenStreetMap France >> ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Classement ville/village - city/town/village
Et l’aéroport Charles de Gaulle avec ses commerces, ses employés et ses hôtels, capitale de zone d’emploi selon l’INSEE, est-il une ville ? :) Je serai très apolitique et loin des frontières administratives et de la densité du bâti pour la clé place, d’où mon intérêt pour les zones d’emploi, les bassins de vie, et il y a aussi l’aire urbaine. djakk Le lun. 17 sept. 2018 à 11:32, Rpnpif a écrit : > Le 17 septembre 2018, ades a écrit : > > > La def donnée par l’Insee parrait plus appropriée : >2000 habitants + > dist. entre bât < 200 m . > > L’ajout de la présence de services (qui avait été ajoutée et que Jérôme > a supprimé) me semble pourtant bien correspondre à ce qu’est une ville > > Oui, calculer cette distance entre bâti n'est pas simple sauf à > utiliser des chiffres extérieurs. > > De même pour la présence de services, quels services, combien, sur > quels critères objectifs les choisir ? > Un bourg avec un très gros ensemble d'une certaine activité (par > exemple un très gros hôpital, ou bien trois grosses sociétés) et avec > 1500 habitants est-il une ville ? > > De même, une station balnéaire de 1800 habitants l'hiver et de 15000 > pendant 2 mois l'été et dont les 3/4 des commerces sont fermés > 10 mois dans l'année est-elle une ville ? > > -- > Alain Rpnpif > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Classement ville/village - city/town/village
Oui effectivement ! Je me suis rendu compte que la clé place manque de granuralité, du coup je suis revenu en arrière, en ajoutant tout de même l’info capital:INSEE=“zone d’emploi”. Ca serait bien de passer à une granularité plus forte, passer de village - town - city à village - small_town - large_town - small_city - medium_city - large_city - metropolis. Ancenis serait pas mal en large_town ou en small_city ? Angers serait une medium_city, Nantes une large_, Paris une metropolis. Seulement ces valeurs qui étaient parfois rendues par la feuille de style “officielle” ont été supprimées : en pratique on ne va pas utiliser une valeur qui efface la ville de la carte ... Du coup je compte demander à gravitystorm/openstreetmap-carto de reprendre en compte ces valeurs, avant de changer les valeurs de place ... on risque de me répondre qu’il faut d’abord utiliser la valeur avant de la prendre en compte :-] djakk Le dim. 16 sept. 2018 à 20:23, Stéphane Péneau a écrit : > Je disais ça en rigolant, mais lorsque je vois par exemple le "bourg" > d'Ancenis, commune de 7800 habitants, qui passe de place=village à > place=city, je rigole un peu moins. > Ensuite, lorsque je vois que tu as modifié la page wiki du tag "place" > pour que ça convienne à ta volonté, je commence à trouver ça pas drôle du > tout. > > Que tu sois bourré d'énergie pour faire bouger les choses, super, mais que > tu le fasses sans tenir compte de ce qui fait la force d'Osm, c'est à dire > sa communauté, alors là je suis moins d'accord. > > Franchement, Ancenis, au même niveau que Nantes, dans les 10 plus > importantes villes de france, faut pas déconner > > Stf > > > Le 16/09/2018 à 18:39, djakk djakk a écrit : > > Ahah :) > > > Le dim. 16 sept. 2018 à 18:32, Stéphane Péneau > a écrit : > >> Wow wow !! Dis-nous un peu ce que tu as modifié. >> Tu fais un peu peur là ! On dirait que tu tournes à la Red-Bull 24/24 >> depuis quelque temps ! >> >> Stf >> >> >> Le 16/09/2018 à 15:50, djakk djakk a écrit : >> >> Yo, >> >> bon après avoir modifié les villes du grand ouest, je me rend compte >> qu’il manquerait des valeurs pour la clé “place” : j’estime qu’on a besoin >> de : village (les “village”) - gros village (les “Town”) - petite ville >> (exemple : Carhaix - small_city ?) - ville moyenne (Brest - medium_city ?) >> - grosse ville (Rennes - big_city ?) - très grosse ville (Paris - huge_city >> ?) >> >> >> djakk >> >> Le mar. 11 sept. 2018 à 15:04, Philippe Verdy a >> écrit : >> >>> on a déjà les capital=yes (pour les capitales nationales) et >>> capital= pour les niveaux inférieurs >>> >>> Attributs un peu redondant avec les "admin_centre" des relations >>> précisant ces niveaux, mais il y a des utilisations de ces attributs pour >>> ne pas avoir à consulter la liste de toutes les relations qui pourraient >>> référencer un noeud place=*, et ensuite les télécharger toutes pour voir si >>> cette référence a un rôle admin_centre (qui plus est n'est pas toujours >>> unique par relation, par exemple dans des pays où peuvent coexister >>> plusieurs "capitales" selon l'usage: administratif, législatif, >>> présidentiel/royale, exécutif, judiciaire, diplomatique, de facto parfois >>> aussi...) >>> >>> Le mar. 11 sept. 2018 à 14:55, djakk djakk a >>> écrit : >>> >>>> C’est vrai, mais pour le coup on est obligé d’etre relatif, par exemple >>>> je verrai Figeac comme une “city” car le seul grand ensemble urbain >>>> alentours, d’ailleurs capitale de sa zone d’emploi, par contre Figeac >>>> serait collée à Rennes ça serait “Town” seulement et collée à Paris ça >>>> serait même “village”. >>>> >>>> Comme pour les “highway” une rue tertiary de Paris à dans doute autant >>>> de circulation qu’une “primary” de Figeac. >>>> >>>> La définition de “city” sur le wiki anglais parle de relativité : Use >>>> the place <https://wiki.openstreetmap.org/wiki/Key:place>=city tag >>>> <https://wiki.openstreetmap.org/wiki/Tag> to identify the largest >>>> settlement or settlements within a territory, >>>> >>>> >>>> djakk >>>> >>>> >>>> Le mar. 11 sept. 2018 à 12:33, Rpnpif a écrit : >>>> >>>>> Le 10 septembre 2018, djakk djakk a écrit : >>>>> >>>>> > Par exemple : être la capitale d’un bassin de vie ou d’une zone >&g
Re: [OSM-talk-fr] Classement ville/village - city/town/village
Ahah :) Le dim. 16 sept. 2018 à 18:32, Stéphane Péneau a écrit : > Wow wow !! Dis-nous un peu ce que tu as modifié. > Tu fais un peu peur là ! On dirait que tu tournes à la Red-Bull 24/24 > depuis quelque temps ! > > Stf > > > Le 16/09/2018 à 15:50, djakk djakk a écrit : > > Yo, > > bon après avoir modifié les villes du grand ouest, je me rend compte qu’il > manquerait des valeurs pour la clé “place” : j’estime qu’on a besoin de : > village (les “village”) - gros village (les “Town”) - petite ville (exemple > : Carhaix - small_city ?) - ville moyenne (Brest - medium_city ?) - grosse > ville (Rennes - big_city ?) - très grosse ville (Paris - huge_city ?) > > > djakk > > Le mar. 11 sept. 2018 à 15:04, Philippe Verdy a > écrit : > >> on a déjà les capital=yes (pour les capitales nationales) et >> capital= pour les niveaux inférieurs >> >> Attributs un peu redondant avec les "admin_centre" des relations >> précisant ces niveaux, mais il y a des utilisations de ces attributs pour >> ne pas avoir à consulter la liste de toutes les relations qui pourraient >> référencer un noeud place=*, et ensuite les télécharger toutes pour voir si >> cette référence a un rôle admin_centre (qui plus est n'est pas toujours >> unique par relation, par exemple dans des pays où peuvent coexister >> plusieurs "capitales" selon l'usage: administratif, législatif, >> présidentiel/royale, exécutif, judiciaire, diplomatique, de facto parfois >> aussi...) >> >> Le mar. 11 sept. 2018 à 14:55, djakk djakk a >> écrit : >> >>> C’est vrai, mais pour le coup on est obligé d’etre relatif, par exemple >>> je verrai Figeac comme une “city” car le seul grand ensemble urbain >>> alentours, d’ailleurs capitale de sa zone d’emploi, par contre Figeac >>> serait collée à Rennes ça serait “Town” seulement et collée à Paris ça >>> serait même “village”. >>> >>> Comme pour les “highway” une rue tertiary de Paris à dans doute autant >>> de circulation qu’une “primary” de Figeac. >>> >>> La définition de “city” sur le wiki anglais parle de relativité : Use >>> the place <https://wiki.openstreetmap.org/wiki/Key:place>=city tag >>> <https://wiki.openstreetmap.org/wiki/Tag> to identify the largest >>> settlement or settlements within a territory, >>> >>> >>> djakk >>> >>> >>> Le mar. 11 sept. 2018 à 12:33, Rpnpif a écrit : >>> >>>> Le 10 septembre 2018, djakk djakk a écrit : >>>> >>>> > Par exemple : être la capitale d’un bassin de vie ou d’une zone >>>> d’emploi >>>> > implique être place=Town au moins. >>>> >>>> Oui mais non, il ne faut pas oublier que la population des villes et >>>> villages en Grande-Bretagne est souvent plus importantes qu'en France, >>>> que celle des villages et villes de Lozère est différente (inférieure) >>>> de celle du Nord de la France ou de l'Ouest. >>>> >>>> Ne pas oublier aussi que certains maires se font mousser en appelant >>>> ville leur village, que les gens de l'Ouest appelle village, les >>>> hameaux et bourg le... bourg principal. >>>> >>>> Faute de mieux, je pense que le wiki français distinguant en fonction de >>>> la population fait un bon compromis. >>>> >>>> Ce n'est que mon avis. >>>> >>>> -- >>>> Alain Rpnpif >>>> >>>> ___ >>>> Talk-fr mailing list >>>> Talk-fr@openstreetmap.org >>>> https://lists.openstreetmap.org/listinfo/talk-fr >>>> >>> ___ >>> Talk-fr mailing list >>> Talk-fr@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-fr >>> >> ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > > > ___ > Talk-fr mailing > listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr > > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Classement ville/village - city/town/village
Oui bon j’ai mes marottes :P Tu trouves les tags mauvais proposes donc des améliorations au lieu de suggérer de ne rien faire :O Le dim. 16 sept. 2018 à 18:33, ades a écrit : > Et bien bon courage, place est renseigné 5 091 400 fois par 59 683 > contributeurs, ‘city’ est utilisé 19446 fois, town 109 939 fois , village 1 > 229 929 fois; ça te fait du pain sur la planche ;-) à moins qu’un grand > manitou US te licencie avant que tu finisse cette modeste tâche ;-) > > Plus sérieusement peu importe la pertinence ou pas de tes remarques ou > modifications, les tags sont tous mauvais, ils constituent juste une > partie d'une règle du jeu et si tu joues, tu accepte la règle… Tu peux > proposer de la modifier mais faut poser la question avant et en discuter. > > Maintenant quand tu auras fini les ‘place’ je te recommande de te pencher > sur ‘landuse’ et ‘nature’ par exemple tu aurais du grain à moudre ;-) > > > Le 16 sept. 2018 à 15:50, djakk djakk a écrit : > > > > Yo, > > > > bon après avoir modifié les villes du grand ouest, je me rend compte > qu’il manquerait des valeurs pour la clé “place” : j’estime qu’on a besoin > de : village (les “village”) - gros village (les “Town”) - petite ville > (exemple : Carhaix - small_city ?) - ville moyenne (Brest - medium_city ?) > - grosse ville (Rennes - big_city ?) - très grosse ville (Paris - huge_city > ?) > > > > > > djakk > > > > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Impasse
Pas de soucis Frédéric ;) En fait je parle de sujets sur lesquels j’ai une vue depuis un certain temps ;) J’ai réfléchi au préprocess mais ça ne marche pas dans certains cas (le réseau routier d’une île ou d’une péninsule). djakk Le dim. 16 sept. 2018 à 16:03, Frédéric Rodrigo a écrit : > Le 16/09/2018 à 15:37, djakk djakk a écrit : > > Salut ! > > Je souhaiterai tagger des impasses (panneau “voie sans issue”) afin > > d’avoir l’information sur toutes les way de l’impasse. But = > > transmettre l’info au moteur de rendu. > > Je croyais que noexit était fait pour mais apparement c’est plutôt > > pour ne pas affoler les éditeurs sur une éventuelle mauvaise connexion > > avec une autre way. > > Dois-je continuer à utiliser noexit=yes sur les ways, ou trouver une > > autre clé ? > > > > PS : difficile de calculer ça, pensez au réseau routier de Belle-Île ;) > > > > Désolé de te répondre comme ça. > > Mais vu tes dernières propositions et ta façon de partir bille en tête. > Je pense que pour l'instant l'important est de rien faire et surtout de > na pas modifier en masse OSM ou d'inventer des tags ou des usages. Le > plus important est peut-être déjà de réparer ce que tu as fait. > > Tu as visiblement des besoins particulier de rendu, regarde du coté du > préprossing ce qu tu peux faire, et c'est faisable. > > Frédéric. > > > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Classement ville/village - city/town/village
Yo, bon après avoir modifié les villes du grand ouest, je me rend compte qu’il manquerait des valeurs pour la clé “place” : j’estime qu’on a besoin de : village (les “village”) - gros village (les “Town”) - petite ville (exemple : Carhaix - small_city ?) - ville moyenne (Brest - medium_city ?) - grosse ville (Rennes - big_city ?) - très grosse ville (Paris - huge_city ?) djakk Le mar. 11 sept. 2018 à 15:04, Philippe Verdy a écrit : > on a déjà les capital=yes (pour les capitales nationales) et > capital= pour les niveaux inférieurs > > Attributs un peu redondant avec les "admin_centre" des relations précisant > ces niveaux, mais il y a des utilisations de ces attributs pour ne pas > avoir à consulter la liste de toutes les relations qui pourraient > référencer un noeud place=*, et ensuite les télécharger toutes pour voir si > cette référence a un rôle admin_centre (qui plus est n'est pas toujours > unique par relation, par exemple dans des pays où peuvent coexister > plusieurs "capitales" selon l'usage: administratif, législatif, > présidentiel/royale, exécutif, judiciaire, diplomatique, de facto parfois > aussi...) > > Le mar. 11 sept. 2018 à 14:55, djakk djakk a > écrit : > >> C’est vrai, mais pour le coup on est obligé d’etre relatif, par exemple >> je verrai Figeac comme une “city” car le seul grand ensemble urbain >> alentours, d’ailleurs capitale de sa zone d’emploi, par contre Figeac >> serait collée à Rennes ça serait “Town” seulement et collée à Paris ça >> serait même “village”. >> >> Comme pour les “highway” une rue tertiary de Paris à dans doute autant de >> circulation qu’une “primary” de Figeac. >> >> La définition de “city” sur le wiki anglais parle de relativité : Use >> the place <https://wiki.openstreetmap.org/wiki/Key:place>=city tag >> <https://wiki.openstreetmap.org/wiki/Tag> to identify the largest >> settlement or settlements within a territory, >> >> >> djakk >> >> >> Le mar. 11 sept. 2018 à 12:33, Rpnpif a écrit : >> >>> Le 10 septembre 2018, djakk djakk a écrit : >>> >>> > Par exemple : être la capitale d’un bassin de vie ou d’une zone >>> d’emploi >>> > implique être place=Town au moins. >>> >>> Oui mais non, il ne faut pas oublier que la population des villes et >>> villages en Grande-Bretagne est souvent plus importantes qu'en France, >>> que celle des villages et villes de Lozère est différente (inférieure) >>> de celle du Nord de la France ou de l'Ouest. >>> >>> Ne pas oublier aussi que certains maires se font mousser en appelant >>> ville leur village, que les gens de l'Ouest appelle village, les >>> hameaux et bourg le... bourg principal. >>> >>> Faute de mieux, je pense que le wiki français distinguant en fonction de >>> la population fait un bon compromis. >>> >>> Ce n'est que mon avis. >>> >>> -- >>> Alain Rpnpif >>> >>> ___ >>> Talk-fr mailing list >>> Talk-fr@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-fr >>> >> ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Changement unilatéral de la définition de tags
Je pense que je rajoute de l’information sans en supprimer ... ? Bon certes je chamboule l’existant ... djakk Le dim. 16 sept. 2018 à 13:51, Philippe Verdy a écrit : > Djakk aussi met des noexit=yes un peu partout (sur les voies, pas sur le > noeud final, et même quand elles ont pourtant bien une issue!) > > Le dim. 16 sept. 2018 à 13:48, Philippe Verdy a > écrit : > >> De même djakk a transformé unilatéralement des "highway=trunk_link" en >> "highway=tertiary"+"link=trunk" ! Ce ne sont même plus des bretelles, alors >> même qu'une partie de la voie est encore à 110 km/h, et qu'il n'y a >> strictement aucune adresse le long de ces voies de décélération en sens >> unique, et qu'elles ne font pas du tout partie du réseau "tertiaire" >> (normalement partie du réseau communal, pas intercommunal). >> >> Evoquer ici des solutions à son "problème" ne signifie pas qu'il n'y a a >> pas d'autres alternatives ni d'autres méthodes déjà existantes pour >> consolider les pratiques. Djakk clairement fait du tagging pour le rendu >> façon Michelin (interdit pour des raisons de droit d'auteur en plus) ! Nous >> on veut s'appuyer sur des données objectives et raisonnablement observables >> ou vérifiables dans des données libres, pas sur des cartes propriétaires. >> >> Le dim. 16 sept. 2018 à 13:40, Philippe Verdy a >> écrit : >> >>> De même le reclassement par djakk de la D29 autour de Rennes de >>> "primary" en "trunk" est totalement faux. >>> Voilà qui va compliquer notre tâche en plus pour requalifier les limites >>> de 90 à 80. >>> >>> Merci djakk de ne pas continuer sur cette voie et même annuler ton >>> "essai". Clairement la D29 n'est pas du tout comme la rocade de Rennes, >>> c'est un itinéraire bis recommandé poru les poids lourds pour éviter la >>> rocade, mais pas du tout de même type. >>> >>> Le dim. 16 sept. 2018 à 13:23, Philippe Verdy a >>> écrit : >>> >>>> Note: djakk s'est aussi lancé dans le changement de type de toutes les >>>> bretelles pour coller au rendu Michelin (dont le design est lui aussi >>>> protégé par son droit d'auteur, donc à ne pas reproduire tel quel, d'autant >>>> que les cartes Michelin sont remplies "d'oeufs de Pâques" comme on le voit >>>> dans le cas de la N175 qui devient une impasse sur un pont ! Donc merci de >>>> ne PAS utiliser Michelin comme source, elle n'est PAS libre). >>>> >>>> Là aussi je ne suis pas d'accord, cela a été fait sans concertation. On >>>> peut discuter et comparer, mais avant de changer les choses, il faut savoir >>>> l'impact que ça aura car ce n'est pas du tout ce qui est documenté pour >>>> l'instant (donc ce sera incohérent). >>>> >>>> Ce que fait djakk n'a donc strictement aucun intérêt pour l'instant, il >>>> vient compliquer les choses sans se demander l'impact que cela aura pour >>>> les autres: ce sont des clés déjà utilisées depuis longtemps et partout. >>>> Les outils d'analyse sont égalemetn basés sur les règles existantes et il >>>> va donc créer donc des tas de nouveaux signalements >>>> d'anomalies/incohérences. >>>> >>>> >>>> Le dim. 16 sept. 2018 à 12:34, Philippe Verdy a >>>> écrit : >>>> >>>>> Là) je trouve que ces changements de typologies de villes est >>>>> excessif. Pour Redon ce n'est clairement pas une "city": par sa population >>>>> non, par celle de son agglomération non plus. Ce n'est pas un chef-lieu >>>>> d'arrondissement non plus. >>>>> >>>>> Pour Laval on peut discuter. Pour Fougères et Vitré c'est deux >>>>> "demi-chef-lieux" d'un même arrondissement (créé il y a une poignée >>>>> d'années en le séparant de celui de Rennes), mais ce ne sont pas des >>>>> "city" >>>>> et restent des "towns". De même pour Dinan. >>>>> >>>>> Concerant les nouveaux tags que djakk ajoute, il s'ajoute aussi à >>>>> "traffic=*" qui existait aussi (valeurs="heavy", "trunk"... pas toujours >>>>> consistante) de même que "motorway=yes". >>>>> >>>>> >>>>> Le dim.
[OSM-talk-fr] Impasse
Salut ! Je souhaiterai tagger des impasses (panneau “voie sans issue”) afin d’avoir l’information sur toutes les way de l’impasse. But = transmettre l’info au moteur de rendu. Je croyais que noexit était fait pour mais apparement c’est plutôt pour ne pas affoler les éditeurs sur une éventuelle mauvaise connexion avec une autre way. Dois-je continuer à utiliser noexit=yes sur les ways, ou trouver une autre clé ? PS : difficile de calculer ça, pensez au réseau routier de Belle-Île ;) djakk ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Les bretelles
J’ai supprimé du coup, et je ferai la demande à un admin, merci Philippe ! djakk Le dim. 16 sept. 2018 à 12:04, Philippe Verdy a écrit : > Bref demande à un admin de supprimer ces images. Pour la discussion il > était suffisant de mettre un lien vers le site Michelin qui les héberge > (sous forme de carte interactive). > Effectivement Michelin fait un rendu des bretelles en fonction du type de > route mineure connectée et non du type de route majeure (nos tags OSM > "highway=*_link")... la plupart du temps mais pas partout ! C'est son choix > de rendu. > > Le dim. 16 sept. 2018 à 11:55, Philippe Verdy a > écrit : > >> Attention ces cartes Michelin ne sont pas libres de droit. Cela ne >> devrait pas être sur le wiki. >> >> Le dim. 16 sept. 2018 à 11:45, djakk djakk a >> écrit : >> >>> Nooon pas le tag mono-utilisateur ! (la punition :) ) >>> >>> J’ai mis 2 extraits de carte Michelin sur ma page wiki : >>> wiki.openstreetmap.org/wiki/User:Djakk >>> >>> >>> djakk >>> >>> Le sam. 15 sept. 2018 à 11:25, marc marc a >>> écrit : >>> >>>> le preprocesseur peux tres bien analyser la moindre diff >>>> c'est à mon avis bien plus durable que d'espérer que quelqu'un modifie >>>> toutes les bretelles d'une route pour mettre à jour un tag >>>> mono-utilisateur :) >>>> >>>> publie qlq part stp un extrait rendu osm <> rendu avec ta modif >>>> (ou extrait michelin), j'ai du mal a imaginer la chose. >>>> >>>> >>>> Le 15. 09. 18 à 11:01, djakk djakk a écrit : >>>> > Oui Marc j’ai pensé à faire un rendu perso avec pré-processeur pour >>>> > récupérer l’info, mais en pratique difficile de faire un >>>> pré-processeur >>>> > pour les données énormes et très mouvantes d’osm. De plus, je pense >>>> que >>>> > pour les collectrices c’est impossible d’y arriver. >>>> > >>>> > Le rendu correspondrait à la plupart des cartes, par exemple les >>>> cartes >>>> > Michelin papier. >>>> > >>>> > >>>> > djakk >>>> > >>>> > Le sam. 15 sept. 2018 à 10:09, marc marc >>> > <mailto:marc_marc_...@hotmail.com>> a écrit : >>>> > >>>> > Bonjour djakk, >>>> > >>>> > Le ven. 14 sept. 2018 à 18:46, djakk djakk a écrit : >>>> > >>>> > > si on relie une autoroute à une tertiary, on pourrait >>>> > > choisir au niveau du rendu de ne pas afficher la bretelle. >>>> > >>>> > je ne suis pas sur de comprendre. >>>> > De quel rendu tu parles ? un rendu perso ? >>>> > tu peux poster qlq part un extrait de carte qui n'afficherait pas >>>> > certains bretelles parce que autoroute-tertiary ? >>>> > >>>> > > Impossible en l’état actuel. >>>> > >>>> > Parmis les spécialistes des styles de rendu, quelqu'un confirme >>>> > qu'on ne peux pas récupérer le type de voie inférieur connectée à >>>> un >>>> > bretelle ? >>>> > si c'était confirmée, cela me semble bien + un problème de rendu >>>> > qu'un problème de donnée. >>>> > s'imagine qu'un preprocesseur doit pouvoir dupliquer l'info >>>> > pour le cas oä cela serait nécessaire (mais j'ai du mal a >>>> comprendre le >>>> > cas réel d'utilisation) >>>> > >>>> > Cordialement, >>>> > Marc >>>> > ___ >>>> > Talk-fr mailing list >>>> > Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org> >>>> > https://lists.openstreetmap.org/listinfo/talk-fr >>>> > >>>> > >>>> > >>>> > ___ >>>> > Talk-fr mailing list >>>> > Talk-fr@openstreetmap.org >>>> > https://lists.openstreetmap.org/listinfo/talk-fr >>>> > >>>> >>>> ___ >>>> Talk-fr mailing list >>>> Talk-fr@openstreetmap.org >>>> https://lists.openstreetmap.org/listinfo/talk-fr >>>> >>> ___ >>> Talk-fr mailing list >>> Talk-fr@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-fr >>> >> ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Les bretelles
On n’a pas le droit pour donner un exemple d’autre carte ? :-/ djakk Le dim. 16 sept. 2018 à 11:56, Philippe Verdy a écrit : > Attention ces cartes Michelin ne sont pas libres de droit. Cela ne devrait > pas être sur le wiki. > > Le dim. 16 sept. 2018 à 11:45, djakk djakk a > écrit : > >> Nooon pas le tag mono-utilisateur ! (la punition :) ) >> >> J’ai mis 2 extraits de carte Michelin sur ma page wiki : >> wiki.openstreetmap.org/wiki/User:Djakk >> >> >> djakk >> >> Le sam. 15 sept. 2018 à 11:25, marc marc a >> écrit : >> >>> le preprocesseur peux tres bien analyser la moindre diff >>> c'est à mon avis bien plus durable que d'espérer que quelqu'un modifie >>> toutes les bretelles d'une route pour mettre à jour un tag >>> mono-utilisateur :) >>> >>> publie qlq part stp un extrait rendu osm <> rendu avec ta modif >>> (ou extrait michelin), j'ai du mal a imaginer la chose. >>> >>> >>> Le 15. 09. 18 à 11:01, djakk djakk a écrit : >>> > Oui Marc j’ai pensé à faire un rendu perso avec pré-processeur pour >>> > récupérer l’info, mais en pratique difficile de faire un >>> pré-processeur >>> > pour les données énormes et très mouvantes d’osm. De plus, je pense >>> que >>> > pour les collectrices c’est impossible d’y arriver. >>> > >>> > Le rendu correspondrait à la plupart des cartes, par exemple les >>> cartes >>> > Michelin papier. >>> > >>> > >>> > djakk >>> > >>> > Le sam. 15 sept. 2018 à 10:09, marc marc >> > <mailto:marc_marc_...@hotmail.com>> a écrit : >>> > >>> > Bonjour djakk, >>> > >>> > Le ven. 14 sept. 2018 à 18:46, djakk djakk a écrit : >>> > >>> > > si on relie une autoroute à une tertiary, on pourrait >>> > > choisir au niveau du rendu de ne pas afficher la bretelle. >>> > >>> > je ne suis pas sur de comprendre. >>> > De quel rendu tu parles ? un rendu perso ? >>> > tu peux poster qlq part un extrait de carte qui n'afficherait pas >>> > certains bretelles parce que autoroute-tertiary ? >>> > >>> > > Impossible en l’état actuel. >>> > >>> > Parmis les spécialistes des styles de rendu, quelqu'un confirme >>> > qu'on ne peux pas récupérer le type de voie inférieur connectée à >>> un >>> > bretelle ? >>> > si c'était confirmée, cela me semble bien + un problème de rendu >>> > qu'un problème de donnée. >>> > s'imagine qu'un preprocesseur doit pouvoir dupliquer l'info >>> > pour le cas oä cela serait nécessaire (mais j'ai du mal a >>> comprendre le >>> > cas réel d'utilisation) >>> > >>> > Cordialement, >>> > Marc >>> > ___ >>> > Talk-fr mailing list >>> > Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org> >>> > https://lists.openstreetmap.org/listinfo/talk-fr >>> > >>> > >>> > >>> > ___ >>> > Talk-fr mailing list >>> > Talk-fr@openstreetmap.org >>> > https://lists.openstreetmap.org/listinfo/talk-fr >>> > >>> >>> ___ >>> Talk-fr mailing list >>> Talk-fr@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-fr >>> >> ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Les bretelles
Nooon pas le tag mono-utilisateur ! (la punition :) ) J’ai mis 2 extraits de carte Michelin sur ma page wiki : wiki.openstreetmap.org/wiki/User:Djakk djakk Le sam. 15 sept. 2018 à 11:25, marc marc a écrit : > le preprocesseur peux tres bien analyser la moindre diff > c'est à mon avis bien plus durable que d'espérer que quelqu'un modifie > toutes les bretelles d'une route pour mettre à jour un tag > mono-utilisateur :) > > publie qlq part stp un extrait rendu osm <> rendu avec ta modif > (ou extrait michelin), j'ai du mal a imaginer la chose. > > > Le 15. 09. 18 à 11:01, djakk djakk a écrit : > > Oui Marc j’ai pensé à faire un rendu perso avec pré-processeur pour > > récupérer l’info, mais en pratique difficile de faire un pré-processeur > > pour les données énormes et très mouvantes d’osm. De plus, je pense que > > pour les collectrices c’est impossible d’y arriver. > > > > Le rendu correspondrait à la plupart des cartes, par exemple les cartes > > Michelin papier. > > > > > > djakk > > > > Le sam. 15 sept. 2018 à 10:09, marc marc > <mailto:marc_marc_...@hotmail.com>> a écrit : > > > > Bonjour djakk, > > > > Le ven. 14 sept. 2018 à 18:46, djakk djakk a écrit : > > > > > si on relie une autoroute à une tertiary, on pourrait > > > choisir au niveau du rendu de ne pas afficher la bretelle. > > > > je ne suis pas sur de comprendre. > > De quel rendu tu parles ? un rendu perso ? > > tu peux poster qlq part un extrait de carte qui n'afficherait pas > > certains bretelles parce que autoroute-tertiary ? > > > > > Impossible en l’état actuel. > > > > Parmis les spécialistes des styles de rendu, quelqu'un confirme > > qu'on ne peux pas récupérer le type de voie inférieur connectée à un > > bretelle ? > > si c'était confirmée, cela me semble bien + un problème de rendu > > qu'un problème de donnée. > > s'imagine qu'un preprocesseur doit pouvoir dupliquer l'info > > pour le cas oä cela serait nécessaire (mais j'ai du mal a comprendre > le > > cas réel d'utilisation) > > > > Cordialement, > > Marc > > ___ > > Talk-fr mailing list > > Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org> > > https://lists.openstreetmap.org/listinfo/talk-fr > > > > > > > > ___ > > Talk-fr mailing list > > Talk-fr@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk-fr > > > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Les bretelles
Oui Marc j’ai pensé à faire un rendu perso avec pré-processeur pour récupérer l’info, mais en pratique difficile de faire un pré-processeur pour les données énormes et très mouvantes d’osm. De plus, je pense que pour les collectrices c’est impossible d’y arriver. Le rendu correspondrait à la plupart des cartes, par exemple les cartes Michelin papier. djakk Le sam. 15 sept. 2018 à 10:09, marc marc a écrit : > Bonjour djakk, > > Le ven. 14 sept. 2018 à 18:46, djakk djakk a écrit : > > > si on relie une autoroute à une tertiary, on pourrait > > choisir au niveau du rendu de ne pas afficher la bretelle. > > je ne suis pas sur de comprendre. > De quel rendu tu parles ? un rendu perso ? > tu peux poster qlq part un extrait de carte qui n'afficherait pas > certains bretelles parce que autoroute-tertiary ? > > > Impossible en l’état actuel. > > Parmis les spécialistes des styles de rendu, quelqu'un confirme > qu'on ne peux pas récupérer le type de voie inférieur connectée à un > bretelle ? > si c'était confirmée, cela me semble bien + un problème de rendu > qu'un problème de donnée. > s'imagine qu'un preprocesseur doit pouvoir dupliquer l'info > pour le cas oä cela serait nécessaire (mais j'ai du mal a comprendre le > cas réel d'utilisation) > > Cordialement, > Marc > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Les bretelles
Oui, en fait il s’agit du type de la voie qui est 2ème dans le classement des voiries que connecte la bretelle : motorway vers secondary, tertiary et primary -> on retiendra primary. djakk Le ven. 14 sept. 2018 à 23:23, Philippe Verdy a écrit : > on a déjà les clés destination=* et sinon ces bretelles aboutissent à une > extrémité sur plusieurs routes de type différent à leur jonction. Je vois > mal comment désigner le type de l'autre côté quand il peut y en avoir > plusieurs (souvent aussi la destination est vers un rond-point, mais il > hérite de la typologie le plus importante des voies connectées). > On ne peut pas tout mettre dans un tag et en pratique ces bretelles font > partie de la voie principale qu'elles connectent. Le seul fait de voir un > "*_link" signifie déjà qu'il y a une connexion entre deux types, on connait > l'un et l'autre est un type inférieur. > > Le ven. 14 sept. 2018 à 21:40, djakk djakk a > écrit : > >> Ou bien perdre l’info actuelle au profit de l’”autre côté” : remplacer la >> valeur de highway=*_link ? (En pratique c’est fait fréquemment en France) >> >> >> djakk >> >> Le ven. 14 sept. 2018 à 18:46, djakk djakk a >> écrit : >> >>> Salut ! >>> >>> Une autre chose me tarabusce au sujet des routes dans osm, c’est >>> l’absence d’info sur le type de route joint par une bretelle >>> (highway=*_link), c’est-à-dire qu’on sait qu’une bretelle joint une >>> autoroute mais on n’a pas d’info sur l’autre côté ! Primary, secondary ? On >>> ne sait pas directement. >>> >>> Et je trouve cette information plus importante. En effet, si on relie >>> une autoroute à une autoroute, ou si on relie une autoroute à une tertiary, >>> on pourrait choisir au niveau du rendu de ne pas afficher la bretelle. >>> Impossible en l’état actuel. >>> >>> Du coup je propose link_from et link_to : pour une bretelle dans le sens >>> autoroute vers tertiary, on aura link_from=motorway et link_to=tertiary. >>> >>> djakk >>> >>> ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Les bretelles
Ou bien perdre l’info actuelle au profit de l’”autre côté” : remplacer la valeur de highway=*_link ? (En pratique c’est fait fréquemment en France) djakk Le ven. 14 sept. 2018 à 18:46, djakk djakk a écrit : > Salut ! > > Une autre chose me tarabusce au sujet des routes dans osm, c’est l’absence > d’info sur le type de route joint par une bretelle (highway=*_link), > c’est-à-dire qu’on sait qu’une bretelle joint une autoroute mais on n’a pas > d’info sur l’autre côté ! Primary, secondary ? On ne sait pas directement. > > Et je trouve cette information plus importante. En effet, si on relie une > autoroute à une autoroute, ou si on relie une autoroute à une tertiary, on > pourrait choisir au niveau du rendu de ne pas afficher la bretelle. > Impossible en l’état actuel. > > Du coup je propose link_from et link_to : pour une bretelle dans le sens > autoroute vers tertiary, on aura link_from=motorway et link_to=tertiary. > > djakk > > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Classification des highway - trunk comme super-primary
Oui j’ai été complètement cavalier dans ma manière de faire ! Cela me travaille à chaque fois que je regarde une carte osm :) C’est pas comme si la situation précédente était satisfaisante: il y avait de nombreuses guerres d’édition car la définition FR était ambiguë. Je serai très attentif à mes messages privés sur osm et au “revert”, je ne partirai pas dans des guerres d’édition, je verrai qui est “chaud” sur le sujet. (Car si pas de réponse sur la mailing-list, c’est que personne n’est intéressé par le sujet ... sur la mailing-list mais tout le monde n’est pas sur la ML !) djakk Le ven. 14 sept. 2018 à 11:31, Jérôme Seigneuret < jerome.seigneu...@gmail.com> a écrit : > oui en effet @Axelos Dans ce cas j'avoue que ça > aurait une utilité. Sachant que c'est comme un raccourci une voie à 110 > permet l'accès au véhicule agricoles que le permet pas les voies avec > panneau C107. C'est là tous le problème. On se retrouve donc avec des > panneaux pour autoriser les engin agricole à rouler... > > Les routes pour automobile impose le même mode de fonctionnement q'une > autoroute. Les trunck en France ont été défini sur une logique de vitesse > en sur le fait d'avoir au moins de voies séparé par terre-plein central... > > Bref ça fait bien longtemps que l'on discute de définir un modèle > présentant des exemples de cas pour définir des logiques (interurbaines ou > extraurbaines) mais faire un tableau et le valider en ayant l'accord de la > plus part n'est pas simple. > > On doit bien pouvoir identifier des cas où cela est utile de choisir un > certains type de clé. Sans devoir uniquement se baser sur un référentiel où > la volonté d'une commune à monter qu'une voie est un axe majeur quand ce > n'est pas le cas. > > A défaut d'explications clair et d'une logique bien défini on se retrouve > à voir tout et son contraire... > > Si l'on veut améliorer ce système il faudrait encore en définir un modèle > plus clair (ne serait ce que pour notre territoire) car ce sujet revient > sans cesse sans y répondre ou avec des réponse complètement contraire. > > Ce travail a déjà été initié mais sans aboutir il me semble car la > priorité avait été donner pour compléter les voies manquante et adjoindre > les noms pour le projet BANO. Maintenant, c'est classification ont deux > objectifs: > - le routing > - l'accessibilité > > La base ne sert pas à définir une logique de règlementaire (sinon c'est > une autre clé) > > Si l'on veut aussi définir des règles pour choisir comment taguer les > voies non classifiées et les chemins et voie de service. > Pour les chemins je crois que réglementairement il n'y a pas lieux d'y > mettre des panneaux de sortie et entrée de ville. > Merci de me confirmer ce sujet si vous en avait l'occassion. > > Que voulons nous et quelles limites on y met? > Bonne journée. > > > Le jeu. 13 sept. 2018 à 19:44, Axelos a écrit : > >> Le 13/09/2018 à 16:03, Christian Rogel a écrit : >> >> Le 12 sept. 2018 à 20:10, JB a écrit : >> >> >> >> Pas de réponse = accord de tous ? Je pense plutôt l'inverse. Le sujet >> a été discuté, rediscuté plusieurs et encore plusieurs fois ces dernières >> années. Tu as tenté de relancer la discussion sans grande réussite il y a >> quelques mois, si je ne me trompe pas. Ça n'a pas l'air de prendre cette >> fois-ci non-plus. Laisser les choses telles qu'elles sont, ce qui semble le >> compromis le plus stable ou au mieux le moins bancal, t'empêchera-t-il >> de dormir tranquille ? >> >> Je pense que le panier de crabes est mieux ainsi, en équilibre, que si >> on le retourne une fois encore. Je pense que tu risques de te frotter à des >> résistances locales à plusieurs endroits, à des conflits d'éditions, qui >> montent parfois vite en tension lorsque la modification est faite par des >> contributeurs distants. Es-tu sûr que le jeu en vaille la chandelle ? >> >> JB. >> >> >> >> Le 12/09/2018 à 12:59, djakk djakk a écrit : >> >>> Apparement il existe un tag “expressway=yes” donc utilisons-le ! Je >> réfléchi à de nouvelles valeurs pour la clé (pour refléter les quatre-voies >> en normes autoroutières - Bande d'arrêt d’urgence bitumée et large - et >> d’autres cas) >> >>> >> >>> djakk >> >>> >> >>> >> >>> Le lun. 10 sept. 2018 à 19:49, djakk djakk > <mailto:djakk.dj...@gmail.com>> a écrit : >> >>> Coucou ! >> >>> >> >>> Je reviens sur cette histoire de highway=trunk qui
[OSM-talk-fr] Les bretelles
Salut ! Une autre chose me tarabusce au sujet des routes dans osm, c’est l’absence d’info sur le type de route joint par une bretelle (highway=*_link), c’est-à-dire qu’on sait qu’une bretelle joint une autoroute mais on n’a pas d’info sur l’autre côté ! Primary, secondary ? On ne sait pas directement. Et je trouve cette information plus importante. En effet, si on relie une autoroute à une autoroute, ou si on relie une autoroute à une tertiary, on pourrait choisir au niveau du rendu de ne pas afficher la bretelle. Impossible en l’état actuel. Du coup je propose link_from et link_to : pour une bretelle dans le sens autoroute vers tertiary, on aura link_from=motorway et link_to=tertiary. djakk ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Classification des highway - trunk comme super-primary
Alors selon moi l'interêt c’est d’avoir une cohérence avec le Royaume-Uni, terre de référence pour osm ; un nouveau niveau de classification des routes (je “vois” que j’en ai besoin dans certains cas, exemple dans mon premier mail) ; décoreler les 5 caractéristiques d’une voie : la hiérarchie dans le réseau routier (dévolu à la clé “highway” - sauf pour le cas des autoroutes), ses caractéristiques physiques (aussi performance) dévolu aux clés “expressway” et “lane”, son accessibilité (foot=no ou motorroad=yes), son intensité de trafic (clé traffic) et ses vitesses limites (clé maxspeed). (Je rejoins ce que tu dis en fait il me semble) J’ai mûri ça de longue date, du coup je me suis permis de mettre à jour le wiki ! djakk Le mer. 12 sept. 2018 à 20:51, Jérôme Seigneuret < jerome.seigneu...@gmail.com> a écrit : > Bonjour, > En soit c'est un débat de longue date dont je ne ressortirai pas les > archives. La hiérarchie des voie n'est pas classé seulement sur des > vitesses. Les règles établi reprennent en grande partie ce que l'on peut > exploiter sur le référentiel route 500... > > On a des petits malin qui pour des raisons de règlementation préfèrent > casser le schéma routier "hiérarchisé" parce une voie secondaire à une > portion de zone 30 ou de zone de rencontre... Sauf que c'est une réalité > terrain. Certaine commune sont traversé par une voie et comme c'est une > zone de passage de piéton on se retrouve avec des zone à 20 ou 30km/h pour > des routes départementales... > > Bref qu'apporte les expressway ou de reclasser des voies en trunk? > > Les modèles classifié sont fais pour fournir des propositions d'itinéraire > en fonction de deux critères qui donne un poids au tronçon parcouru. en > clair c'est comme des coefficients pondérateur. > > Une voieie en faite c'est quatre choses : > - type de route permettant de définir si elle est destiné à accompagner > les voyageurs vers une destination plus ou moins éloigné (on a aussi les > panneaux de circulation qui donne du sens au catégorie) > - vitesse des parcours (on a des nationales ou les vitesses sont plus > importantes que certaines autoroutes l'A709 est limité à 90km/h et sert de > périphérique. Ça n'en reste pas moins une autoroute) > - l'accès sert à absorber une quantité de véhicule par heure (oui mais > quel ratio définir et seul les DDT on réllement le moyens de faire parler > le traffic... avec les service de voirie équiper de capteur) > - le droit et les contraintes légale de circulation (ce dernier point est > utiliser pour générer de nouvelle clé et type de voie qui dans certains cas > casse le schéma précédent) > > D'où la problématique des trunk, living_street > > > > > > > Le mer. 12 sept. 2018 à 13:00, djakk djakk a > écrit : > >> Apparement il existe un tag “expressway=yes” donc utilisons-le ! Je >> réfléchi à de nouvelles valeurs pour la clé (pour refléter les quatre-voies >> en normes autoroutières - Bande d'arrêt d’urgence bitumée et large - et >> d’autres cas) >> >> djakk >> >> >> Le lun. 10 sept. 2018 à 19:49, djakk djakk a >> écrit : >> >>> Coucou ! >>> >>> Je reviens sur cette histoire de highway=trunk qui diffère selon les >>> pays. >>> >>> Je pense qu’il est important d’avoir pour chaque clé-valeur une >>> définition commune au monde entier (autant que possible ) et qu’un 5e >>> niveau dans la hiérarchie des “highways” >>> serait souhaitable : residential/unclassified - tertiary - secondary - >>> primary - trunk. >>> >>> Du coup, il s’agirait de reprendre pour la France le classement anglais >>> des highways, où le trunk désigne une super-route pas forcément de type >>> autoroutier. >>> >>> Par exemple pour différencier la N12 et la D31 à Ernée ( >>> https://www.openstreetmap.org/#map=12/48.3017/-0.9306 ) la N12 serait à >>> mettre en trunk - comme à priori toutes les nationales restant en France. >>> >>> Pour retrouver les informations actuellement fournies par le trunk >>> français : la classification administrative avec le panneau “route pour >>> automobiles”, on a la clé-valeur “motorroad=yes”. >>> Il faut inventer une nouvelle clé pour désigner une route dénivelée (pas >>> de carrefours à niveau) : at_grade=no ou junctionS=interchangeS (utile pour >>> les cas où la route ressemble à une route pour automobiles dénivelée, mais >>> ça n’en est pas une officiellement, exemple : la N12 au niveau de >>> Goussainville : >>> https://www.openstreetmap.org/#map=16/48.7718/1.5526 >>> ). >>> >>> >>> djakk >>> >> ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr > > >> > > -- > Cordialement, > Jérôme Seigneuret > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
