Re: [OSM-talk-fr] Frontière franco-italienne du Mont-Blanc
Quelqu'un a l'expérience de geogig http://geogig.org/ geogig http://sourceforge.net/projects/geogig/ (anciennement geogit) ? Il y a comme une petite restriction : /The default underlying object database (berkeley db) is single user./ Quand à la comparaison avec Wikimafia, leur problème c'est qu'ils ont des administrateurs (*) non neutres (contrairement à leur règlement mais comme ce sont les administrateurs qui administrent...). Du coup ils sont possibilité de mettre des pages en modification bloquée/protégée/semi-protégée. Un tag data_protection=blocked / protected... et une date de fin pourrait être une solution (à condition que les éditeurs les prennent en compte). Allez faisons riches: data_protection:level data_protection:until data_protection:ref (ref : référence à une page de discussion). Je préfère pouvoir compter sur le bons sens que sur l'administration qui peut être corrompue. Et si le comportement d'un utilisatieur pose problème on peut le bloquer. Jean-Yvon (*) au sens informatique, pas au sens associatif. Le 18/07/2015 02:14, Philippe Verdy - verd...@wanadoo.fr a écrit : Bref ce qui est décide le mois n est vite obsolète des le mois n+1, comme est en fait la totalité de la base qui n'a strictement aucun degré de protection. La dessus osm fait beaucoup moins bien que wikilrdua qui permet a tout moment de tracer des décisions prises tout en ne bloqyantvpas tout définitivement sur des bases obsolètes car il est ensuite permis de présenter de nouveaux arguments et d'évoluer mêle su c'est moins facile que lors des premières éditions ou chacun faisait ses modifs avec moins de besoin pour une concertation. Il faudra bien qu'osm passe a un système de versionnelent multuniveau maus aussi ouvert sue peut l'être gît. Ca voudra dire permettre d'avoir différents forks de la base de données et des échanges et validations et fusions d'une base a l'autre. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Relation Itinéraires vélo
Petits rappels: Sur un highway, ref est utilisé pour la nomenclature de la route elle même, pas pour les multiples itinéraires (vélo, mais aussi bus, rando, etc) qui pourraient passer par là. Même logique pour name=* Les itinéraires sont décrits à l'aide de relations et c'est sur la relation qu'on indiquera son numéro / ref / name. Pour la nomenclature européenne des routes (exemple E54), on utilise un deuxième tag pour ça: int_ref Le 15/07/2015 21:46, George Kaplan a écrit : Un way automobile qui est emprunté par une route cycliste prend-il comme référence, en plus de la référence de type D 951, la référence cycliste, E 32 : Ref= D 951;E 32 ? C'est même l'essentiel des itinéraires cyclables, ils empruntent beaucoup de routes à circulation générale de faible fréquentation. Pour répondre à ta question, c'est non : j'ai lu quelque part à mes début d'OSM, qu'en France, la convention veut que l'on n'indique qu'une seule référence. Je ne retrouve plus l'origine de cette information. Merci de vos réponses Bernard -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Osmose] Ajout d'un test sur la nature en tant que nom d'objet
Le 17 juil. 2015 à 16:25, Yves Pratter yves.prat...@gmail.com mailto:yves.prat...@gmail.com a écrit : J’ai rajouté de mémoire ce qu’on trouve sur le cadastre (Croix, Fontaine) et ce que je trouve dans taginfo (Fontaine d’eau potable). Pour les croix, overpass en trouve : 326 pour “name=Croix” dont 267 pour “name=Croix and historic=wayside_cross” : http://overpass-turbo.eu/s/atM http://overpass-turbo.eu/s/atM 23 pour “name=Croix and amenity=place_of_worship” : http://overpass-turbo.eu/s/atT http://overpass-turbo.eu/s/atT 4 pour “name=Croix and aerialway=station” : http://overpass-turbo.eu/s/atU http://overpass-turbo.eu/s/atU A Megève, le nom a été mis sur les pylônes de départ et d’arrivé au lieu d’être mis sur le téléski 3 pour “name=Croix and historic=memorial” : http://overpass-turbo.eu/s/atO http://overpass-turbo.eu/s/atO 1 pour “name=Croix and natural=peak” : http://overpass-turbo.eu/s/atS http://overpass-turbo.eu/s/atS Pour les fontaines : « name=fontaine and amenity=drinking_water » « name=fontaine and amenity=fountain » « name=fontaine and natural=spring » « name=fontaine and man_made=water_well » « name=fontaine and landuse=basin » « name=fontaine and amenity=public_building » « name=fontaine and natural=water » il y a aussi le tag name sans aucun autre tag. — Yves___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Osmose] Ajout d'un test sur la nature en tant que nom d'objet
Le 18/07/2015 10:02, Yves Pratter a écrit : Le 17 juil. 2015 à 16:25, Yves Pratter yves.prat...@gmail.com mailto:yves.prat...@gmail.com a écrit : J’ai rajouté de mémoire ce qu’on trouve sur le cadastre (Croix, Fontaine) et ce que je trouve dans taginfo (Fontaine d’eau potable). Pour les croix, *overpass* en trouve : * 326 pour “name=Croix” dont * 267 pour “name=Croix and *historic=wayside_cross*” : http://overpass-turbo.eu/s/atM * 23 pour “name=Croix and *amenity=place_of_worship*” : http://overpass-turbo.eu/s/atT * 4 pour “name=Croix and *aerialway=station*” : http://overpass-turbo.eu/s/atU A Megève, le nom a été mis sur les pylônes de départ et d’arrivé au lieu d’être mis sur le téléski * 3 pour “name=Croix and *historic=memorial*” : http://overpass-turbo.eu/s/atO * 1 pour “name=Croix and *natural=peak*” : http://overpass-turbo.eu/s/atS Pour les fontaines : « name=fontaine and amenity=drinking_water » « name=fontaine and amenity=fountain » « name=fontaine and natural=spring » « name=fontaine and man_made=water_well » « name=fontaine and landuse=basin » « name=fontaine and amenity=public_building » « name=fontaine and natural=water » il y a aussi le tag name sans aucun autre tag. Il faudrait tester la proposition de tag automatiquement en fonction du name, pour les name sans autres tags pertinent en fonction des statistiques de ce même name quand il y a d'autres tags. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Frontière franco-italienne du Mont-Blanc
tous les projets collaboratifs ont des niveaux de privilèges qui s'acquirent avec l'expérience passée sur un projet et des postes pouvant être remis en cause par un processus collectif ou par désistement. Ce n'est pas toujours simple pour gérer les conflits aux niveaux les plus privilégiés, mais un bon moyen de les éviter est d'offrir un système ne restreignant jamais la création de forks ni le nombre de serveurs pour les héberger. Git est un tel système qui évite la concentration des pouvoirs et permet à chaque branche de se développer sans perturber les autres qui préfèrent une autre branche (la notion de trunk est en fait purement locale à un seul des serveurs, les autres serveurs de branche ont chacun leur préférence sur la branche principale à utiliser, il n'y a as plus de mérite pour une branche ou pour une autre quelque soit le nombre des utilisateurs qui les référence, et cela fait aussi disparaitre les notions d'urgence à déployer et la tentation de vouloir effacer ou refuser le travail d'un voisin. Le 18 juillet 2015 10:13, osm.sanspourr...@spamgourmet.com a écrit : Quelqu'un a l'expérience de geogig http://geogig.org/ geogig http://sourceforge.net/projects/geogig/ (anciennement geogit) ? Il y a comme une petite restriction : *The default underlying object database (berkeley db) is single user.* Quand à la comparaison avec Wikimafia, leur problème c'est qu'ils ont des administrateurs (*) non neutres (contrairement à leur règlement mais comme ce sont les administrateurs qui administrent...). Du coup ils sont possibilité de mettre des pages en modification bloquée/protégée/semi-protégée. Un tag data_protection=blocked / protected... et une date de fin pourrait être une solution (à condition que les éditeurs les prennent en compte). Allez faisons riches: data_protection:level data_protection:until data_protection:ref (ref : référence à une page de discussion). Je préfère pouvoir compter sur le bons sens que sur l'administration qui peut être corrompue. Et si le comportement d'un utilisatieur pose problème on peut le bloquer. Jean-Yvon (*) au sens informatique, pas au sens associatif. Le 18/07/2015 02:14, Philippe Verdy - verd...@wanadoo.fr a écrit : Bref ce qui est décide le mois n est vite obsolète des le mois n+1, comme est en fait la totalité de la base qui n'a strictement aucun degré de protection. La dessus osm fait beaucoup moins bien que wikilrdua qui permet a tout moment de tracer des décisions prises tout en ne bloqyantvpas tout définitivement sur des bases obsolètes car il est ensuite permis de présenter de nouveaux arguments et d'évoluer mêle su c'est moins facile que lors des premières éditions ou chacun faisait ses modifs avec moins de besoin pour une concertation. Il faudra bien qu'osm passe a un système de versionnelent multuniveau maus aussi ouvert sue peut l'être gît. Ca voudra dire permettre d'avoir différents forks de la base de données et des échanges et validations et fusions d'une base a l'autre. ___ 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] Frontière franco-italienne du Mont-Blanc
*Franchement je suis d'accord aussi, mais quoi qu'on du se ici ou dans divers forums, il y aura toujours un utilisateur plus malin qui voudra corriger en étant persuadé qu'il a raison et qui n'aura rien lu de ce qui se passe ici. * Salut, Un moyen sur serait de transférer la discussion sur le wiki d'openstreetmap et d'adjoindre sur les éléments du tracé concernant cette zone de chevauchement un commentaire renvoyant sur cette discussion et une page spécifique à la gestion des frontières. Demander à ne pas manipuler sauf personne compétente de la même manière que les points géodésiques. C'est le wiki qui guide la manière de taguer et de dessiner donc autant que ce soit décrit au bon endroit. La liste de discussion c'est pour affirmer, corriger, ou confirmer des points de vue sur les bonnes pratiques ou des sujets permettant de compléter des informations manquantes de mon point de vue. *Le 18 juillet 2015 11:34, Philippe Verdy verd...@wanadoo.fr verd...@wanadoo.fr a écrit :* *tous les projets collaboratifs ont des niveaux de privilèges qui s'acquirent avec l'expérience passée sur un projet et des postes pouvant être remis en cause par un processus collectif ou par désistement. Ce n'est pas toujours simple pour gérer les conflits aux niveaux les plus privilégiés, mais un bon moyen de les éviter est d'offrir un système ne restreignant jamais la création de forks ni le nombre de serveurs pour les héberger. Git est un tel système qui évite la concentration des pouvoirs et permet à chaque branche de se développer sans perturber les autres qui préfèrent une autre branche (la notion de trunk est en fait purement locale à un seul des serveurs, les autres serveurs de branche ont chacun leur préférence sur la branche principale à utiliser, il n'y a as plus de mérite pour une branche ou pour une autre quelque soit le nombre des utilisateurs qui les référence, et cela fait aussi disparaitre les notions d'urgence à déployer et la tentation de vouloir effacer ou refuser le travail d'un voisin.* Tu sous-entends qu'OSM à choisi une gestion à la mode de l'armée mexicaine ;-) * (ref : référence à une page de discussion). Je préfère pouvoir compter sur le bons sens que sur l'administration qui peut être corrompue. Et si le comportement d'un utilisatieur pose problème on peut le bloquer. Jean-Yvon (*) au sens informatique, pas au sens associatif.* Tiens ça me rappel le principe de google mapmaker... Tu as beau avoir pris les info sur le terrain et être cartographe, on te votre modification a été refusé car nous n'avons pas le moyen de vérifier ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Intégration des données de PSS dans OSM
Il est clair que la licence actuelle de PSS n'est pas compatible avec une intégration de toute ou partie de ces données dans OSM. A chaque fois qu'on parle d'import ou autre, il faut TOUJOURS s'occuper de la partie légale avant de s'attaquer à la technique. ça évite de perdre du temps pour se retrouver coincer au final. Il me semble que ce point a été soulevé relativement tôt à propos de PSS. Autre chose non évaluée... d'où viennent les données de localisation de PSS ? C'est sur un fond Google ou par géocodage que les lat/lon ont été déterminés ? Dans ce cas, PSS ne peut pas les utiliser ailleurs que sur Google Maps et OSM ne peut pas non plus les réutiliser... Il y a une différence de philosophie importante entre PSS et OSM. Le choix d'une licence CC-by-NC-ND très peu libre et ouverte par rapport à l'ODbL qui limite très peu les usages mais pousse à contribuer. Malheureusement ce n'est pas la première fois qu'on ne peut faire converger un projet de ce type avec OSM sauf à faire comprendre aux contributeurs de ce projet qu'ils font un petit peu fausse route... par exemple en utilisant GMaps d'un côté et donc en autorisant Google à faire ce qu'ils veulent des données PSS (y compris un usage commercial) et de l'autre à ne pas trouver un moyen de collaborer avec OSM... Faire naitre une vraie réflexion côté PSS est à mon avis la meilleure suite. Le 16/07/2015 23:03, Jérôme Seigneuret a écrit : Désolé pou l’émoticône. Mais c'était juste une pointe sarcastique. Je te rejoins en tous points. J'ai aussi une double casquette comme Jean Yvon. Il présente ce sûr quoi j'ai pas voulu m’étaler. Je ne sais pas si la 3D commence à percer mais la hauteur peut en effet être intéressante. Ça alimentera http://osmbuildings.org/ Le 16 juillet 2015 22:32, osm.sanspourr...@spamgourmet.com mailto:osm.sanspourr...@spamgourmet.com a écrit : Par rapport à la réponse de Jérôme j'allais vous répondre en MP : Je dirais +1, sauf que vu l'émoticône, je dis : Donc en clair ça sert à rien *;-( *Je suis aussi d'accord avec le nouveau message de Jérôme.* * Par contre ça vaut peut-être le coup de revenir vers eux : à quoi ça leur sert de restreindre cette information à but non commercial. Le nom des bâtiments et la hauteur ne sont pas des secrets. Donc c'est de l'information publique. Demander d'ajouter : source:name=/PSS-archi.eu /source:height=/PSS-archi.eu/ Me semblerait plus efficace (pour nous car sinon on ne peut l'utiliser) et pour eux (plus grande visibilité si on extrait ou regarde des données de près). Et proposer de mettre un ref:pss-archi pour leur référence. Tu dis en plus que c'est fait par des bénévoles, il me semble donc évident que ça ne devrait pas poser de soucis s'ils peuvent faire un sondage auprès de leurs bénévoles, passer à la licence ODbL, n'est-on pas des centaines de milliers de bénévoles à l'avoir fait ? N. B. : je suis contributeur à tire privé, mais je monte une pile OSM à titre professionnel. Ça ne nous permet que de proposer un service de meilleure qualité qu'une carte Nasa Blue Marble ou Natural Earth, on ne vendra pas notre solution un centime de plus. Et la hauteur d'un bâtiment ou son nom c'est un plus pour les secours. Personnellement il me semble bien plus valorisant pour PSS-archi.eu d'offrir les données à OSM. Tiens, je suis allé sur leur site : http://www.pss-archi.eu/pss_maps.php?latlng=43.6619110572607, 7.19417005777359z=18 http://www.pss-archi.eu/pss_maps.php?latlng=43.6621633061906850,7.1947547793388370z=16 Aïe, Evil Map ? Et ça ne leur fait pas mal de payer Evil Map pour qu'Evil Map puisse disposer de ces informations ? Ça ne leur fait pas mal d'informer Google des bâtiments les plus intéressants (par pistage des requêtes sur le site) ? Ici lors de ma petite visite sur leur site 68 requêtes Google vers 7 sites Google. Tu ne veux pas leur proposer une switch2osm install party en échange d'une licence ODbl ? ;-). Si tu regardes le site, les bâtiments sont en zone francophone. L'annonce de la publication sur un bulletin hebdomadaire d'OSM Europe (si leur site n'était pas qu'en français) leur ferait une belle promo gratuite. N. B. : avec ma casquette professionnelle je viens de mettre à jour de la doc pour avoir un serveur de tuiles créé en conteneur OpenVZ sur un environnement ProxMox. Je vais passer les mises à jour à faire sur la doc à Thomas G., ce temps je l'ai passé sur mon temps de travail et le message de correctif sera sur mon temps de bénévole. Tout le monde y gagne. Et si PSS veut essayer de monter une pile en s’inspirant de ma doc' (en échange de retours), pas de soucis. Avant qu'on ne me pose la question : je vais sans doute voir auprès de ma hiérarchie si la partie ProxMox/OpenVZ peur
Re: [OSM-talk-fr] Intégration des données de PSS dans OSM
Merci Jean-Yvon et Jérôme pour vos retour, avec vos arguments et avec l'aide de Christian, notre vénérable président, je vais essayer de les convaincre d'abandonner cette satanée clause NC ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Efficacité d'une requête Overpass (around)
overpass doit faire un choix entre une recherche géographique et une
recherche par tags.
Si on a des tags qui permettent de filtrer suffisamment il est
préférable dans bien des cas de ne pas ajouter de bbox ou area.
line:SNCF étant suffisamment filtrant, on peut à mon avis éviter bbox
et area.
On touche quand même aux limites de l'utilisation de l'overpass pour un
usage live, overpass n'étant pas vraiment prévu pour ce genre d'usages.
Solutions:
- monter une instance overpass locale, avec uniquement les données d'ile
de France... qui sera bien plus rapide qu'une instance monde
- mettre en place un cache ou regénérer à intervalle régulier un fichier
geojson à partir de l'overpass publique...
Le 17/07/2015 10:43, Vincent Génin a écrit :
Merci beaucoup à tous pour vos réponses.
Je pensais vraiment qu'une area bien definie faciliterait la tâche à
Overpass et je n'ai même pas testé sans...
Je vais tenter avec un BBox grossière et sans et voir ce que ça donne.
Pour le tilde, je ne vais pas pouvoir m'en passer si je veux faire un
truc propre, puisque qu'une gare peut desservir plusieurs lignes.
Je vais ajouter et nettoyer un peu les appels pour les services et
équipements (supprimer les acces=private/no ou voir comment avoir qq
chose de plus propre pour les terrains de tennis par exemple).
Merci en tout cas pour vos retours, et je vous tiens au courant de
l'avancée du projet.
Le 17 juil. 2015 02:25, Thierry Bézecourt thie...@thbz.org
mailto:thie...@thbz.org a écrit :
Oui, et on pourrait même supprimer carrément la bounding box car
la condition sur la relation limite les résultats de manière
équivalente (d'ailleurs la ligne C est, sauf erreur, entièrement
en Île-de-France).
De plus, il me semble que le tilde (présente dans le lien sur
Overpass) ralentit la requête.
La requête suivante (http://overpass-turbo.eu/s/atj) dure moins de
10 secondes et devrait être facile à adapter pour d'autres lignes
de RER. Evidemment, il faut faire attention à ne pas mettre une
condition trop large sur la relation...
[out:json];
rel[line:SNCF=C];
node(around:800)[sport=swimming];
out body qt;
rel[line:SNCF=C];
way(around:800)[sport=swimming];
out body center qt;
Thierry
Le 17/07/2015 08:19, Philippe Verdy a écrit :
La délimitation a l'Île-de-France au sens strict construit un
polygone
très complexe. Ce serait peut-être plus rapide avec juste une
bounding
box. Quitte a chercher des picines autour des gares et qu'il
n'y a pas
tant que ca de gares, il suffit juste d'avoir une bounding bix
englobant
les gares. Et après on n'est guère mieux qu'a 1 km près pour
trouver les
piscines mais on n'a pas besoin de la précision fine des
frontieres de
l'Île-de-France... Est-genant si tu as des résultats en
Normandie ou
Picardie ?
Le 16 juil. 2015 16:11, Pierre-Yves Berrard
pierre.yves.berr...@gmail.com
mailto:pierre.yves.berr...@gmail.com
mailto:pierre.yves.berr...@gmail.com
mailto:pierre.yves.berr...@gmail.com a
écrit :
Le 16 juillet 2015 15:09, Vincent Génin
vincent.ge...@gmail.com mailto:vincent.ge...@gmail.com
mailto:vincent.ge...@gmail.com
mailto:vincent.ge...@gmail.com a écrit :
Bonjour à tous,
Désolé si la question est un peu spécifique, mais je
n'ai pas
trouvé de liste pour Overpass.
Pour une utilisation personnelle, je recherchais des
piscines
autour des gares de la ligne C du RER.
J'ai fait quelques tests et utilise cette requête :
http://overpass-turbo.eu/s/asI
{{geocodeArea:Île-de-France}}-.searchArea;
rel[line:SNCF=C](area.searchArea);
node(around:800)[sport=swimming](area.searchArea);
out body qt;
rel[line:SNCF=C](area.searchArea);
way(around:800)[sport=swimming](area.searchArea);
out center qt;
Cependant, elle prend pas mal de temps à s'exécuter
(~60s).
Bonjour,
Il y aurait peut-être à creuser sur la première ligne, en lui
passant directement le numéro de la relation Ile-de-France.
Je n'ai plus en tête la syntaxe exacte : quelque chose du
style
3600 + le numéro de la relation.
Ça éviterait de passer par nominatim (?), mais je ne sais
pas si ça
gagne beaucoup de temps.
PY
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
Re: [OSM-talk-fr] Intégration des données de PSS dans OSM
Le 18 juillet 2015 15:29, Christian Quest cqu...@openstreetmap.fr a écrit : Il est clair que la licence actuelle de PSS n'est pas compatible avec une intégration de toute ou partie de ces données dans OSM. A chaque fois qu'on parle d'import ou autre, il faut TOUJOURS s'occuper de la partie légale avant de s'attaquer à la technique. ça évite de perdre du temps pour se retrouver coincer au final. Il me semble que ce point a été soulevé relativement tôt à propos de PSS. Oui c'est vrai mais le temps n'a pas été complètement perdu parce que mon programme m'a ensuite permis de faire l'import des immeubles parisiens (avec pas mal de modifications tout de même) à partir des données libres disponibles data.paris.fr. Je suis d'ailleurs en train de le faire fortement évoluer pour pouvoir faire des suppression/ajouts d'immeubles et sous-immeubles (toujours pour l'open data de Paris), je vous en reparlerai dans un autre thread. Autre chose non évaluée... d'où viennent les données de localisation de PSS ? C'est sur un fond Google ou par géocodage que les lat/lon ont été déterminés ? Dans ce cas, PSS ne peut pas les utiliser ailleurs que sur Google Maps et OSM ne peut pas non plus les réutiliser... Hmm c'est un autre point qui pourrait être bloquant effectivement, je vais leur rappeler.. ceci dit c'est pas du tout sûr car pour un nombre important d'immeuble les coordonnées correspondent très mal avec les immeubles visibles sous la vue satellite de GMaps (et d'où le fait que mon import ne pouvait importer que 31k immeubles sur les 43k€ présents dans leur export). Il y a une différence de philosophie importante entre PSS et OSM. Le choix d'une licence CC-by-NC-ND très peu libre et ouverte par rapport à l'ODbL qui limite très peu les usages mais pousse à contribuer. Malheureusement ce n'est pas la première fois qu'on ne peut faire converger un projet de ce type avec OSM sauf à faire comprendre aux contributeurs de ce projet qu'ils font un petit peu fausse route... par exemple en utilisant GMaps d'un côté et donc en autorisant Google à faire ce qu'ils veulent des données PSS (y compris un usage commercial) et de l'autre à ne pas trouver un moyen de collaborer avec OSM... Faire naitre une vraie réflexion côté PSS est à mon avis la meilleure suite. J'espère qu'on l'a fait, maintenant il n'y a plus qu'a attendre... ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Frontière franco-italienne du Mont-Blanc
Tout à fait d'accord avec la suggestion de porter la discussion sur le wiki. Les listes de diffusion ont peu de mémoire et sont difficiles d'accès. Les pages de discussion du wiki sont l'une des grandes forces de Wikipédia, car on peut y voir de manière organisée les discussions qui ont eu lieu il y a cinq ou dix ans. Thierry Le 18/07/2015 20:13, Jérôme Seigneuret a écrit : / / /Franchement je suis d'accord aussi, mais quoi qu'on du se ici ou dans divers forums, il y aura toujours un utilisateur plus malin qui voudra corriger en étant persuadé qu'il a raison et qui n'aura rien lu de ce qui se passe ici. / Salut, Un moyen sur serait de transférer la discussion sur le wiki d'openstreetmap et d'adjoindre sur les éléments du tracé concernant cette zone de chevauchement un commentaire renvoyant sur cette discussion et une page spécifique à la gestion des frontières. Demander à ne pas manipuler sauf personne compétente de la même manière que les points géodésiques. C'est le wiki qui guide la manière de taguer et de dessiner donc autant que ce soit décrit au bon endroit. La liste de discussion c'est pour affirmer, corriger, ou confirmer des points de vue sur les bonnes pratiques ou des sujets permettant de compléter des informations manquantes de mon point de vue. /Le 18 juillet 2015 11:34, Philippe Verdy verd...@wanadoo.fr mailto:verd...@wanadoo.fr a écrit : / /tous les projets collaboratifs ont des niveaux de privilèges qui s'acquirent avec l'expérience passée sur un projet et des postes pouvant être remis en cause par un processus collectif ou par désistement. Ce n'est pas toujours simple pour gérer les conflits aux niveaux les plus privilégiés, mais un bon moyen de les éviter est d'offrir un système ne restreignant jamais la création de forks ni le nombre de serveurs pour les héberger. Git est un tel système qui évite la concentration des pouvoirs et permet à chaque branche de se développer sans perturber les autres qui préfèrent une autre branche (la notion de trunk est en fait purement locale à un seul des serveurs, les autres serveurs de branche ont chacun leur préférence sur la branche principale à utiliser, il n'y a as plus de mérite pour une branche ou pour une autre quelque soit le nombre des utilisateurs qui les référence, et cela fait aussi disparaitre les notions d'urgence à déployer et la tentation de vouloir effacer ou refuser le travail d'un voisin./ Tu sous-entends qu'OSM à choisi une gestion à la mode de l'armée mexicaine ;-) / (ref : référence à une page de discussion). Je préfère pouvoir compter sur le bons sens que sur l'administration qui peut être corrompue. Et si le comportement d'un utilisatieur pose problème on peut le bloquer. Jean-Yvon (*) au sens informatique, pas au sens associatif./ Tiens ça me rappel le principe de google mapmaker... Tu as beau avoir pris les info sur le terrain et être cartographe, on te votre modification a été refusé car nous n'avons pas le moyen de 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] Frontière franco-italienne du Mont-Blanc
Pour résumé, il y a de nombreuses zones contestées dans le monde. Dans le cas particulier, les deux gouvernements reconnaissent qu'il y a un litige. Ils n'ont pas l'intention de le résoudre. Il n'y a pas un pays qui occupe plus la zone que l'autre. Le cas USA-Canada semble similaire. Je pense qu'il faut trouver un moyen de matérialiser ça dans la base. Par exemple, séparer la frontière en deux et aussi définir une zone spéciale entre les deux avec des tags indiquant que c'est une zone contestée. Je veux bien lancer une discussion sur [tagging] sur comment tagger une zone contestée qui est amenée à le rester ad vitam æternam. Un moyen sur serait de transférer la discussion sur le wiki d'openstreetmap On peut aussi mettre du wiki mais tout le monde ne va pas consulter non plus, loin s'en faut. Et il n'y a pas besoin d’administrateurs sachant qu'il n'y a pas de guerre d'édition et qu'il n'y a pas de raison d'en avoir puisque les gouvernements reconnaissent le désaccord. Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Frontière franco-italienne du Mont-Blanc
Très bien. Le résultat de la discussion méritera tout de même d'être mis quelque part sur le wiki, car c'est l'endroit le plus visible pour la plupart des contributeurs. Et ce serait bien de signaler le lancement de cette discussion sur talk-it (ce que peut sans doute faire celui qui l'a lancée, puisqu'il vient de là-bas). Thierry Le 19/07/2015 04:39, Eric SIBERT a écrit : Pour résumé, il y a de nombreuses zones contestées dans le monde. Dans le cas particulier, les deux gouvernements reconnaissent qu'il y a un litige. Ils n'ont pas l'intention de le résoudre. Il n'y a pas un pays qui occupe plus la zone que l'autre. Le cas USA-Canada semble similaire. Je pense qu'il faut trouver un moyen de matérialiser ça dans la base. Par exemple, séparer la frontière en deux et aussi définir une zone spéciale entre les deux avec des tags indiquant que c'est une zone contestée. Je veux bien lancer une discussion sur [tagging] sur comment tagger une zone contestée qui est amenée à le rester ad vitam æternam. Un moyen sur serait de transférer la discussion sur le wiki d'openstreetmap On peut aussi mettre du wiki mais tout le monde ne va pas consulter non plus, loin s'en faut. Et il n'y a pas besoin d’administrateurs sachant qu'il n'y a pas de guerre d'édition et qu'il n'y a pas de raison d'en avoir puisque les gouvernements reconnaissent le désaccord. Eric ___ 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] Frontière franco-italienne du Mont-Blanc
Le 18 juil. 2015 13:13, Jérôme Seigneuret jseigneuret-...@yahoo.fr a écrit : Tu sous-entends qu'OSM à choisi une gestion à la mode de l'armée mexicaine ;-) Je ne peux pas sous-entendre ca car tout ce que je sais de l'armée mexicaine je l'ai vu avec leurs faucons sur les champs élysées a parus il y a quelques jour ou a l'époque de zorro et des films américains traitant de la guerre entre les deux pays ou des révolutions successives. Comment elle fonctionne et quels rapport elle peut avoir avec les forces de police et les mafias locales du trafic de drogues et d'armes ou les gangs et trafics humains, ou encore avec les migrants clandestin ne me parle pas du tout de ce que faut cette armée aujourd'hui et ce qu'elle représente réellement alors que l'Amérique latine a profondément changé dans ses régimes et les relations internationales qu'ils entretiennent. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Frontière franco-italienne du Mont-Blanc
Dès qu'on fait des cartes (avec des villes que l'on nomme (dans quelle langue?), des zonages (de pouvoir...) que l'on trace ), on fait de la politique. Une frontière ça sert à quoi ? C'est avant tout pour savoir si en allant d'un point A à un point B on va changer ou pas de souveraineté administrative (juste histoire d'avoir son visa en règle, ce qui est quand même préférable au cas où la maréchaussée se pointe...). J'ai regardé la carte du Sahara Occidental et c'est bien la position qui semble être retenue par OSM : l'administration de fait (via le Mur des Sables) d'un territoire dessine la frontière. C'est je pense la position la plus apolitique possible (si tant est que ce puisse être possible tant qu'on parle de frontière...) me semble-t-il. D'ailleurs c'est une déclinaison du c'est le terrain qui prime que j'ai entendu à plusieurs reprises dans ces fils de discussion. On reste factuel en actant une situation de fait (car une carte c'est fait pour servir, le lecteur basique d'OSM n'est ni diplomate, ni géographe, ni historien, il veut savoir dans quel pays(i.e. souveraineté administrative) c'est ce qu'il cherche sur la carte). OSM a vocation, je le pense, à répondre à répondre à minima à ce besoin basique et dire dans les fait c'est ici ou là. Pour en revenir au Mont-Blanc. La partie contestée est semble-t-il inhabitée. Sauf mon ignorance, il me semble qu'il n'y a jamais eu d'échauffourés entre l'Italie et la France à ce sujet, avec échanges de coups de feu, mouvement de troupes sur le terrain etc..Donc à priori il semble impossible de trouver une administration de fait (par une administration civile ou une occupation militaire) de la partie concernée. Les revendications de part et d'autres étant non concordantes cela veut dire donc tout simplement que la frontière n'est pas tracée.Les deux points extrémaux de la frontière posant problème devraient être reliés par une ligne en pointillés (comme dans les vieux atlas papiers) indiquant qu'il n'y a pas de tracé de frontière bilatéralement reconnue. Et ça semble le plus logique. Lorsqu'on ne sait pas, OSM doit répondre on ne sait pas Une autre solution qui me semble moins satisfaisante et moins logique, serait de faire passer la frontière d'un pays par la frontière revendiquée par l'autre, et laisser ce qui est reconnu par l'un et pas par l'autre en dehors des deux territoires(zone disputée). Le Vendredi 17 juillet 2015 19h32, Sylvain Maillard sylvain.maill...@gmail.com a écrit : Salut, pour le tracé de la frontière franco-italienne, le CNIG a une page qui liste quelques compte-rendus de réunions, et il y a notamment un document avec les positions des bornes frontières officielles : http://cnig.gouv.fr/?page_id=8653 Les derniers ajustements ont été effectués pour harmoniser les 2 tracés dans le cadre d'INSPIRE. En ce qui concerne le point précis du mont-blanc, on est face à 2 entités politiques légitimes avec chacune un point de vue, et qui sont tous les deux reconnus au niveau international : il est prévu que les 2 tracés figurent dans le bases européennes ! (voir diapo 13 sur http://cnig.gouv.fr/wp-content/uploads/2015/05/2015-10fronti%C3%A8res_GTEI_VF.pdf) Je pense que dans ce cas précis, OSM a plutôt vocation à afficher les 2 tracés ... Du côté l'organisation des secours, il y a des accords internationaux entre la France et l'Italie pour une coopération complète des services de secours qui interviennent sur le secteur ... Sylvain Le 17 juillet 2015 18:19, Florian LAINEZ winner...@free.fr a écrit : Le 17 juillet 2015 17:39, Eric Sibert courr...@eric.sibert.fr a écrit : Ce qui ne semble pas très en accord avec les recommandations de la fondation de n'avoir qu'une frontière. Ça serait plutôt d'avoir une frontière qui coupe la poire en deux (en surface? avec ou sans passage par le sommet?) et tracer à part avec des tags spécifiques les revendications de chaque pays. On ouvrirait ainsi la boite de Pandore, cf. le débat sur le Sahara Occidental. En effet si on commence à prendre en compte les revendications des pays, on fait de la politique. Je ne suis pas contre de manière théorique (donner le point de vue de chacun peut être une bonne chose) mais cela amène de nombreuses complications du type 1. Prends-t-on en compte les revendications uniquement des états ou également des organisations ? 2. Qu'est ce qui définit un état ? le fait qu'il soit reconnu par d'autres ? Mais si tous les autres ne le reconnaissent pas, on met une limite ? Quels critères prendre en compte ? (exemple de l'Ukraine) etc ... Si je ne me trompe pas, le débat sur le Sahara Occidental avait abouti sur la solution de ne pas intégrer la vision Marocaine dans la base OSM mais de leur fournir un serveur pour créer un rendu local intégrant cette donnée. On met le Mont blanc dans nos frontières sur le rendu fr ou ça ressemble à une galère à gérer ? -- FlorianLainez @overflorian
Re: [OSM-talk-fr] Relation Itinéraires vélo
C'est ce qui se passe si 'le format de référence' est insensé, voir ridicule. Il n'y a aucune raison d'ajouter des espaces superflues. De toute façon je suppose que des expressions régulières peuvent aider pour retrouver les 2 formes/formats. Polyglot 2015-07-18 21:15 GMT+02:00 Jérôme Seigneuret jseigneuret-...@yahoo.fr: Il me semble dans le wiki que la question a déjà été posé sur le wiki concernant l'espace sur les int_ref http://wiki.openstreetmap.org/wiki/Key:int_ref *The reference format is E followed by a space followed by up to 3 digits* Il y a pas mal de page à revoir car cet espace n'est pas ajouter dans les descriptions. C'est pénible pour les recherches. Un coup on le met un coup non et dès fois les parties de relations ne suivent pas la même règle. Il y a un MS_BOT pour la correction automatique des références N, A, E, D et C il me semble car la question s'était posé pour les RNx ou R.N x ou R.N.x N x Je pense que les itinéraires de vélo ne doivent pas déroger à la règle. Il faut une normalisation des ref similaires pour garder une cohérence sur la recherche et la lecture. La page ref du wiki présente bien l'espace entre la lettre de départ et la valeur numérique. D'ailleurs, comment les outils de vérification ou d'intégration test cette valeur? ___ 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] Relation Itinéraires vélo
Il me semble dans le wiki que la question a déjà été posé sur le wiki concernant l'espace sur les int_ref http://wiki.openstreetmap.org/wiki/Key:int_ref *The reference format is E followed by a space followed by up to 3 digits* Il y a pas mal de page à revoir car cet espace n'est pas ajouter dans les descriptions. C'est pénible pour les recherches. Un coup on le met un coup non et dès fois les parties de relations ne suivent pas la même règle. Il y a un MS_BOT pour la correction automatique des références N, A, E, D et C il me semble car la question s'était posé pour les RNx ou R.N x ou R.N.x N x Je pense que les itinéraires de vélo ne doivent pas déroger à la règle. Il faut une normalisation des ref similaires pour garder une cohérence sur la recherche et la lecture. La page ref du wiki présente bien l'espace entre la lettre de départ et la valeur numérique. D'ailleurs, comment les outils de vérification ou d'intégration test cette valeur? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Intégration des données de PSS dans OSM
Le 18/07/2015 16:24, Vincent Frison a écrit : Le 18 juillet 2015 15:29, Christian Quest cqu...@openstreetmap.fr mailto:cqu...@openstreetmap.fr a écrit : Il est clair que la licence actuelle de PSS n'est pas compatible avec une intégration de toute ou partie de ces données dans OSM. A chaque fois qu'on parle d'import ou autre, il faut TOUJOURS s'occuper de la partie légale avant de s'attaquer à la technique. ça évite de perdre du temps pour se retrouver coincer au final. Il me semble que ce point a été soulevé relativement tôt à propos de PSS. Oui c'est vrai mais le temps n'a pas été complètement perdu parce que mon programme m'a ensuite permis de faire l'import des immeubles parisiens (avec pas mal de modifications tout de même) à partir des données libres disponibles data.paris.fr http://data.paris.fr. Je suis d'ailleurs en train de le faire fortement évoluer pour pouvoir faire des suppression/ajouts d'immeubles et sous-immeubles (toujours pour l'open data de Paris), je vous en reparlerai dans un autre thread. Tu as bien fait de ne pas te baser que sur PSS justement, du coup ce que tu as fait sert heureusement pour d'autres sources de données. Autre chose non évaluée... d'où viennent les données de localisation de PSS ? C'est sur un fond Google ou par géocodage que les lat/lon ont été déterminés ? Dans ce cas, PSS ne peut pas les utiliser ailleurs que sur Google Maps et OSM ne peut pas non plus les réutiliser... Hmm c'est un autre point qui pourrait être bloquant effectivement, je vais leur rappeler.. ceci dit c'est pas du tout sûr car pour un nombre important d'immeuble les coordonnées correspondent très mal avec les immeubles visibles sous la vue satellite de GMaps (et d'où le fait que mon import ne pouvait importer que 31k immeubles sur les 43k€ présents dans leur export). Il faut clarifier cette source de localisation (ou ces sources). -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Efficacité d'une requête Overpass (around)
Il faut surtout filtrer et garder les arrêts et non pas faire le traitement
sur l'intégralité du linéaire
Voici la requête sans Nominatim:
[out:json];
area[type=boundary][admin_level=4][name=Île-de-France]- .s;
/* Relation pour le RER C remplacer la lettre du ref par celle de la ligne
*/
rel[network=RER][ref=C](area.s);
/* Récupération des arrêts */
node(r:stop) - .r;
/* Récupération des piscines à 800m des gares */
(node(around.r:800)[sport=swimming];
way(around.r:800)[sport=swimming];);
out center qt;
Pour filter sur le type d'accès, il faut soit le faire après [sport=
swimming]
[network=RER][ref=C] ça marche pour le RER A à D mais pour le
transilien c'est différent
Bon courage
Le 18 juillet 2015 15:19, Christian Quest cqu...@openstreetmap.fr a écrit
:
overpass doit faire un choix entre une recherche géographique et une
recherche par tags.
Si on a des tags qui permettent de filtrer suffisamment il est préférable
dans bien des cas de ne pas ajouter de bbox ou area.
line:SNCF étant suffisamment filtrant, on peut à mon avis éviter bbox et
area.
On touche quand même aux limites de l'utilisation de l'overpass pour un
usage live, overpass n'étant pas vraiment prévu pour ce genre d'usages.
Solutions:
- monter une instance overpass locale, avec uniquement les données d'ile
de France... qui sera bien plus rapide qu'une instance monde
- mettre en place un cache ou regénérer à intervalle régulier un fichier
geojson à partir de l'overpass publique...
Le 17/07/2015 10:43, Vincent Génin a écrit :
Merci beaucoup à tous pour vos réponses.
Je pensais vraiment qu'une area bien definie faciliterait la tâche à
Overpass et je n'ai même pas testé sans...
Je vais tenter avec un BBox grossière et sans et voir ce que ça donne.
Pour le tilde, je ne vais pas pouvoir m'en passer si je veux faire un truc
propre, puisque qu'une gare peut desservir plusieurs lignes.
Je vais ajouter et nettoyer un peu les appels pour les services et
équipements (supprimer les acces=private/no ou voir comment avoir qq chose
de plus propre pour les terrains de tennis par exemple).
Merci en tout cas pour vos retours, et je vous tiens au courant de
l'avancée du projet.
Le 17 juil. 2015 02:25, Thierry Bézecourt thie...@thbz.org a écrit :
Oui, et on pourrait même supprimer carrément la bounding box car la
condition sur la relation limite les résultats de manière équivalente
(d'ailleurs la ligne C est, sauf erreur, entièrement en Île-de-France).
De plus, il me semble que le tilde (présente dans le lien sur Overpass)
ralentit la requête.
La requête suivante (http://overpass-turbo.eu/s/atj) dure moins de 10
secondes et devrait être facile à adapter pour d'autres lignes de RER.
Evidemment, il faut faire attention à ne pas mettre une condition trop
large sur la relation...
[out:json];
rel[line:SNCF=C];
node(around:800)[sport=swimming];
out body qt;
rel[line:SNCF=C];
way(around:800)[sport=swimming];
out body center qt;
Thierry
Le 17/07/2015 08:19, Philippe Verdy a écrit :
La délimitation a l'Île-de-France au sens strict construit un polygone
très complexe. Ce serait peut-être plus rapide avec juste une bounding
box. Quitte a chercher des picines autour des gares et qu'il n'y a pas
tant que ca de gares, il suffit juste d'avoir une bounding bix englobant
les gares. Et après on n'est guère mieux qu'a 1 km près pour trouver les
piscines mais on n'a pas besoin de la précision fine des frontieres de
l'Île-de-France... Est-genant si tu as des résultats en Normandie ou
Picardie ?
Le 16 juil. 2015 16:11, Pierre-Yves Berrard
pierre.yves.berr...@gmail.com mailto:pierre.yves.berr...@gmail.com a
écrit :
Le 16 juillet 2015 15:09, Vincent Génin vincent.ge...@gmail.com
vincent.ge...@gmail.com
mailto:vincent.ge...@gmail.com a écrit :
Bonjour à tous,
Désolé si la question est un peu spécifique, mais je n'ai pas
trouvé de liste pour Overpass.
Pour une utilisation personnelle, je recherchais des piscines
autour des gares de la ligne C du RER.
J'ai fait quelques tests et utilise cette requête :
http://overpass-turbo.eu/s/asI
{{geocodeArea:Île-de-France}}-.searchArea;
rel[line:SNCF=C](area.searchArea);
node(around:800)[sport=swimming](area.searchArea);
out body qt;
rel[line:SNCF=C](area.searchArea);
way(around:800)[sport=swimming](area.searchArea);
out center qt;
Cependant, elle prend pas mal de temps à s'exécuter (~60s).
Bonjour,
Il y aurait peut-être à creuser sur la première ligne, en lui
passant directement le numéro de la relation Ile-de-France.
Je n'ai plus en tête la syntaxe exacte : quelque chose du style
3600 + le numéro de la relation.
Ça éviterait de passer par nominatim (?), mais je ne sais pas si ça
gagne beaucoup de temps.
PY
Re: [OSM-talk-fr] Frontière franco-italienne du Mont-Blanc
Le sujet de la discussion italienne : https://www.mail-archive.com/talk-it@openstreetmap.org/msg46931.htmlAvec l'autre problématique :Le tag:name devrait contenir les deux noms du Mont-Blanc (Monte Bianco) classés par ordre alphabétique. Florian Le Dimanche 19 juillet 2015 0h00, Thierry Bézecourt thie...@thbz.org a écrit : Très bien. Le résultat de la discussion méritera tout de même d'être mis quelque part sur le wiki, car c'est l'endroit le plus visible pour la plupart des contributeurs. Et ce serait bien de signaler le lancement de cette discussion sur talk-it (ce que peut sans doute faire celui qui l'a lancée, puisqu'il vient de là-bas). Thierry Le 19/07/2015 04:39, Eric SIBERT a écrit : Pour résumé, il y a de nombreuses zones contestées dans le monde. Dans le cas particulier, les deux gouvernements reconnaissent qu'il y a un litige. Ils n'ont pas l'intention de le résoudre. Il n'y a pas un pays qui occupe plus la zone que l'autre. Le cas USA-Canada semble similaire. Je pense qu'il faut trouver un moyen de matérialiser ça dans la base. Par exemple, séparer la frontière en deux et aussi définir une zone spéciale entre les deux avec des tags indiquant que c'est une zone contestée. Je veux bien lancer une discussion sur [tagging] sur comment tagger une zone contestée qui est amenée à le rester ad vitam æternam. Un moyen sur serait de transférer la discussion sur le wiki d'openstreetmap On peut aussi mettre du wiki mais tout le monde ne va pas consulter non plus, loin s'en faut. Et il n'y a pas besoin d’administrateurs sachant qu'il n'y a pas de guerre d'édition et qu'il n'y a pas de raison d'en avoir puisque les gouvernements reconnaissent le désaccord. Eric ___ 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] highway=trunk en France
Bonjour, Jérôme Seigneuret wrote J'aurais tendance à dire qu'il ne faut pas simplifier à la voie express. La voie rapide c'est ce qui y a de plus probant même si elle n'est pas à 110 (valeur par défaut). La présence d'un C107 ou pas, on s'en fou. C'est juste un panneaux de rappel précisant les conditions d'accès. Bon j'ai l'impression de tourner en rond en fait là, donc je laisse tomber ça sert à rien de persévérer. Je laisse tel quel, si un jour quelqu'un repasse les chemins en primaire, alors je me contenterais d'ajouter bicycle=no. Merci quand même pour vos réponses, et si un jour ça évolue faites-moi signe. Cordialement. -- View this message in context: http://gis.19327.n5.nabble.com/highway-trunk-en-France-tp5821793p5850477.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
