Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
2m ça me parait bien peu pour une conflation efficace. Les espèces et autre ont plein de tags prévus pour: genus / species/ taxon, voir http://wiki.openstreetmap.org/wiki/Key:species +1 aussi pour compléter les objets existants plutôt que de les supprimer pour les remplacer. Le 21/07/2015 14:41, Jérôme Seigneuret a écrit : Perso je m'occupe d'intégrer les arbres de Montpellier + éclairage (campagne terrain plus Bing pour le placement) Les palmiers c'est du feuillu persistant. Il n'y a plus de distinction. Je laisse type=palm uniquement pour les palmiers... Sinon leaf_type=* et leaf_cycle sur chaque arbre et c'est ok Pour le nom complet latin j'utilise taxon=* et pas plus quand j'aurais mis tous les arbres j'ajouterai le reste par requête (Overpass) Penses à tester tout de même les zones contenant déjà un couvert végétal dans OSM pour éviter les doublons et de supprimer le tout. Après je mettrais plutôt 5 à 7m pour le rayons. Faire plusieurs tests en variant d'un mètre pour vérifier le rayons le plus probant. Le 21 juillet 2015 14:37, JB jb...@mailoo.org mailto:jb...@mailoo.org a écrit : Salut, Quelques remarques : - Overpass trouve 1188 arbres dans Nice : soit il en manque dans le fichier de l'agglo, soit 2m, c'est pas assez. Soit le fichier de l'agglo n'est pas assez bon, soit ce qui est dans OSM n'est pas assez bon. Problèmatique de tenter d'importer avant d'en savoir plus. - Pas vraiment d'accord pour supprimer l'existant pour y mettre la donnée de « référence » à la place. Le but est d'éviter d'arriver à la situation US vue d'ici (difficile de savoir ce qu'il en est réellement sans être sur place) ou l'essentiel de la donnée est issue d'import avec peu de vie communautaire locale. Et d'éviter la frustration des mappeurs locaux. - Es-tu inscrit à la liste de discussion import ? JB. Le 21/07/2015 14:05, Vincent Frison a écrit : Hello Je compte importer dans OSM l'ensemble des arbres municipaux de Nice, merci au portail OpenData de l'agglomération de Côte d'Azur. Ici c'est du vrai open data, je ne devrais donc pas avoir la même frustration qu'avec l'import des immeubles de PSS ;) Ils viennent de mettre à jour leur fichier qui contient maintenant plus de 30 000 arbres : http://opendata.nicecotedazur.org/data/dataset?q=arbres En plus de créer les nouveaux arbres mon programme vérifie également la présence d'arbres existants afin de les effacer. Actuellement j'ai mis un rayon de 2 mètres donc pour chaque arbre importé, je regarde les arbres existants qui sont à moins de 2 mètres. Pour l'instant je n'efface que l'arbre plus proche de l'arbre importé (je pourrais également supprimer tous les arbres qui sont à moins de x mètres mais en fait ça ne change pas grand chose car s'il y a plusieurs arbres existants qui sont très proches à priori il y aura également plusieurs arbres importés qui seront très proches donc au final même en ne supprimant que l'arbre existant le plus proche tous les arbres existants seront bien effacés, ce que j'ai pu vérifier par mes tests). Concrètement sur les ~30 000 arbres importés il y a ~540 arbres existants à supprimer. Ce qui est dommage c'est que le fichier n'indique pas le type des arbres et c'est d'autant plus dommage que les arbres existants ont parfois un tag type=*. Par ex. les arbres existants le long de la Promenade des Anglais sont marqué comme palmier (type=palm). Malheureusement je serai obligé de remettre le type à la main une fois l'import exécuté. Mon programme pourrait éventuellement récupérer le type des arbres existants mais bon ça ne marcherait que sur une toute petite partie des arbres importés... D'ailleurs j'ai un peu de mal à comprendre la bonne manière d'indiquer le type car sur la page Wiki du tag natural=tree (http://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree) il est marqué que le tag type=* est obsolète et qu'il faut plutôt utilisé le tag leaf_type=*. Sauf que ce dernier n'est censé prendre que les valeurs suivantes : broadleaved / needleleaved / mixed / leafless. De plus sous JSOM si on met type=palm ça affiche bien l'arbre avec une image de palmier mais ça ne le fait pas si j'essaye avec genus|species=palm|palmtree. Bref c'est pas très clair... Voila si vous avez des conseils ou suggestions n'hésitez surtout pas.. ++ Vincent. ___ 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 mailto:Talk-fr@openstreetmap.org
Re: [OSM-talk-fr] durée des trajets à vélo dans Paris
Bonjour La durée d'un parcours à vélo dépend avant tout du cycliste lorsqu'il n'y a pas d'obstacles à une progression continue. En ville, on s'arrête tous les 100m (feux, croisements, passages piétons, etc.), ce qui lisse énormément les temps de parcours (c'est aussi ce qui explique qu'on aille souvent aussi vite à vélo qu'en voiture). Généralement tout le monde se retrouve au feu. Julien Le 21/07/2015 17:49, Jean-Claude Repetto a écrit : Le 21/07/2015 17:33, Julien Demade a écrit : Pour Christian: je ne dis rien des itinéraires, qui sont pas mals (il y a de toute façon généralement beaucoup de possibilités correctes, et l'avantage d'ailleurs d'avoir deux solutions de routage est de rendre sensible au fait qu'il n'y a pas une et une seule bonne solution); quant aux durées, si elles ne sont vraiment pas fiables (on est quand même dans du 40% de marge d'erreur...), il ne paraît pas pertinent de les indiquer (de même qu'il ne paraîtrait pas pertinent d'indiquer des itinéraires non fiables). Encore une fois: 40% d'erreur, on n'est pas dans l'ordre du détail. Et je suppose que cela vaut pour toutes les zones urbaines? Bonjour, Je ne suis pas cycliste, et encore moins Parisien, mais je suis très étonné par ta question. Il me semble que la durée d'un parcours en vélo dépend en premier lieu du cycliste lui-même. Entre un sportif de 20 ans et un retraité de 70 ans, la durée doit bien varier du simple au double, sinon plus ? Donc le logiciel de calcul doit forcément pouvoir être paramétré en fonction des possibilités physiques du cycliste. 40% de différence, c'est négligeable ... Jean-Claude ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] durée des trajets à vélo dans Paris
Merci de vos premières réponses Pour Simon: le problème n'est pas l'algo de routage de géovélo, mais celui d'OSM (ou plus ceux de GraphHopper et Mapquest), c'est au contraire celui de géovélo qui marche bien (sans réglage) Pour Christian: je ne dis rien des itinéraires, qui sont pas mals (il y a de toute façon généralement beaucoup de possibilités correctes, et l'avantage d'ailleurs d'avoir deux solutions de routage est de rendre sensible au fait qu'il n'y a pas une et une seule bonne solution); quant aux durées, si elles ne sont vraiment pas fiables (on est quand même dans du 40% de marge d'erreur...), il ne paraît pas pertinent de les indiquer (de même qu'il ne paraîtrait pas pertinent d'indiquer des itinéraires non fiables). Encore une fois: 40% d'erreur, on n'est pas dans l'ordre du détail. Et je suppose que cela vaut pour toutes les zones urbaines? Le 21/07/2015 17:09, Christian Quest a écrit : C'est fort probable que les algo génériques dispo sur osm.org ne tiennent pas compte d'assez de détails. La durée totale n'est peut être pas fiable au final mais les itinéraires calculés sont-ils cohérents ? C'est un point important, voire essentiel, non ? Le 21/07/2015 15:16, Julien Demade a écrit : Bonjour Je voulais signaler un problème quant à la durée indiquée sur OSM des trajets à vélo dans Paris (problème possiblement plus général, je ne sais pas): elle est beaucoup trop brève, ne tient pas du tout compte du fait qu'on ne roule pas aussi vite en milieu urbain que sur une route de campagne (feux, circulation, croisements, etc.). Pour donner un ordre de grandeur, un trajet indiqué sur OSM comme prenant à peu près 30-40mn (suivant que l'on utilise GraphHopper ou MapQuest), est indiqué sur un autre calculateur d'itinéraires (qui donne lui des durées fiables) comme prenant environ 50mn (il s'agit dehttp://www.geovelo.fr/). Bref, tel quel le planificateur d'itinéraire vélo est inutilisable, ce qui est dommage! Comme je n'ai malheureusement aucune idée de la nature du problème, et donc encore moins de la façon de le résoudre, je me contente de le signaler, en espérant qu'il y a plus compétent que moi - ce dont je ne doute pas! Julien ___ 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] durée des trajets à vélo dans Paris
C'est fort probable que les algo génériques dispo sur osm.org ne tiennent pas compte d'assez de détails. La durée totale n'est peut être pas fiable au final mais les itinéraires calculés sont-ils cohérents ? C'est un point important, voire essentiel, non ? Le 21/07/2015 15:16, Julien Demade a écrit : Bonjour Je voulais signaler un problème quant à la durée indiquée sur OSM des trajets à vélo dans Paris (problème possiblement plus général, je ne sais pas): elle est beaucoup trop brève, ne tient pas du tout compte du fait qu'on ne roule pas aussi vite en milieu urbain que sur une route de campagne (feux, circulation, croisements, etc.). Pour donner un ordre de grandeur, un trajet indiqué sur OSM comme prenant à peu près 30-40mn (suivant que l'on utilise GraphHopper ou MapQuest), est indiqué sur un autre calculateur d'itinéraires (qui donne lui des durées fiables) comme prenant environ 50mn (il s'agit de http://www.geovelo.fr/). Bref, tel quel le planificateur d'itinéraire vélo est inutilisable, ce qui est dommage! Comme je n'ai malheureusement aucune idée de la nature du problème, et donc encore moins de la façon de le résoudre, je me contente de le signaler, en espérant qu'il y a plus compétent que moi - ce dont je ne doute pas! Julien ___ 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
Re: [OSM-talk-fr] Recyclage du rendu QA dans osmose: les carreaux INSEE sans route...
Le 21/07/2015 15:00, didier2020 a écrit : 31 000 me semble faible : http://tile.openstreetmap.fr/?zoom=15lat=49.4462575043827lon=4.56345641933607layers=B000TFF http://osmose.openstreetmap.fr/fr/map/#zoom=15lat=49.4462575043827lon=4.56345641933607item=7170 J'ai pas mal agrandit la zone de recherche autour d'un carreau, en gros si il y a une route qui passe dans le carreau à côté, ça considère que c'est ok. On affinera au fur et à mesure de l'avancée ;) -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Recyclage du rendu QA dans osmose: les carreaux INSEE sans route...
Le 21/07/2015 17:03, Christian Quest a écrit : Le 21/07/2015 15:00, didier2020 a écrit : 31 000 me semble faible : http://tile.openstreetmap.fr/?zoom=15lat=49.4462575043827lon=4.56345641933607layers=B000TFF http://osmose.openstreetmap.fr/fr/map/#zoom=15lat=49.4462575043827lon=4.56345641933607item=7170 J'ai pas mal agrandit la zone de recherche autour d'un carreau, en gros si il y a une route qui passe dans le carreau à côté, ça considère que c'est ok. On affinera au fur et à mesure de l'avancée ;) C'est intéressant, on peut voir la densité de voies manquantes avec cette analyse : http://osmose.openstreetmap.fr/fr/map/#zoom=6lat=46.49lon=2.51layer=Mapnikoverlays=FFTFitem=7170level=1%2C2%2C3tags=fixable= Encore du rouge à dégommer. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Edition et ajout de note à OpenStreeMap directement depuis Github
Salut à tous, Github a publié aujourd'hui une annonce concernant l'édition d’éléments et l'ajout de notes dans OpenStreetMap https://github.com/blog/2041-improving-map-data-on-github Bonne lecture Thomas Gratier ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] durée des trajets à vélo dans Paris
Je profite du fil pour mentionner http://cycle.travel qui reste ma référence en matière d'itinéraires cyclistes... Je serais curieux de connaître leur paramétrage OSRM qui tient même compte du relief. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Effectivement je vais plutôt modifier les éléments existants plutôt que de les supprimer, c'est une meilleure manière de procéder, en tout cas moins agressive. Je ferai aussi quelques tests en variant le rayon, je vous tiendrai au courant des résultats... ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Bonjour Je ne connais rien aux arbres dans osm ni à la qualité des données de Nice mais je sais que la localisation des toilettes publiques et des grands dessins type BD à Bruxelles fournis par la ville sur son portail opendata officiel est tellement mauvaise que nous avons renoncé à osm-be à l'importation automatique. En résumé : à mon avis souvent les données Gis officielles doivent etre vérifiées sur le terrain une à une. C'est dommage mais c'est la réalité Nicolas À mar. juil. 21 08:37:18 2015 GMT-0400, JB a écrit : Salut, Quelques remarques : - Overpass trouve 1188 arbres dans Nice : soit il en manque dans le fichier de l'agglo, soit 2m, c'est pas assez. Soit le fichier de l'agglo n'est pas assez bon, soit ce qui est dans OSM n'est pas assez bon. Problèmatique de tenter d'importer avant d'en savoir plus. - Pas vraiment d'accord pour supprimer l'existant pour y mettre la donnée de « référence » à la place. Le but est d'éviter d'arriver à la situation US vue d'ici (difficile de savoir ce qu'il en est réellement sans être sur place) ou l'essentiel de la donnée est issue d'import avec peu de vie communautaire locale. Et d'éviter la frustration des mappeurs locaux. - Es-tu inscrit à la liste de discussion import ? JB. Le 21/07/2015 14:05, Vincent Frison a écrit : Hello Je compte importer dans OSM l'ensemble des arbres municipaux de Nice, merci au portail OpenData de l'agglomération de Côte d'Azur. Ici c'est du vrai open data, je ne devrais donc pas avoir la même frustration qu'avec l'import des immeubles de PSS ;) Ils viennent de mettre à jour leur fichier qui contient maintenant plus de 30 000 arbres : http://opendata.nicecotedazur.org/data/dataset?q=arbres En plus de créer les nouveaux arbres mon programme vérifie également la présence d'arbres existants afin de les effacer. Actuellement j'ai mis un rayon de 2 mètres donc pour chaque arbre importé, je regarde les arbres existants qui sont à moins de 2 mètres. Pour l'instant je n'efface que l'arbre plus proche de l'arbre importé (je pourrais également supprimer tous les arbres qui sont à moins de x mètres mais en fait ça ne change pas grand chose car s'il y a plusieurs arbres existants qui sont très proches à priori il y aura également plusieurs arbres importés qui seront très proches donc au final même en ne supprimant que l'arbre existant le plus proche tous les arbres existants seront bien effacés, ce que j'ai pu vérifier par mes tests). Concrètement sur les ~30 000 arbres importés il y a ~540 arbres existants à supprimer. Ce qui est dommage c'est que le fichier n'indique pas le type des arbres et c'est d'autant plus dommage que les arbres existants ont parfois un tag type=*. Par ex. les arbres existants le long de la Promenade des Anglais sont marqué comme palmier (type=palm). Malheureusement je serai obligé de remettre le type à la main une fois l'import exécuté. Mon programme pourrait éventuellement récupérer le type des arbres existants mais bon ça ne marcherait que sur une toute petite partie des arbres importés... D'ailleurs j'ai un peu de mal à comprendre la bonne manière d'indiquer le type car sur la page Wiki du tag natural=tree (http://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree) il est marqué que le tag type=* est obsolète et qu'il faut plutôt utilisé le tag leaf_type=*. Sauf que ce dernier n'est censé prendre que les valeurs suivantes : broadleaved / needleleaved / mixed / leafless. De plus sous JSOM si on met type=palm ça affiche bien l'arbre avec une image de palmier mais ça ne le fait pas si j'essaye avec genus|species=palm|palmtree. Bref c'est pas très clair... Voila si vous avez des conseils ou suggestions n'hésitez surtout pas.. ++ Vincent. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Envoyé depuis mon Jolla ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Edition et ajout de note à OpenStreeMap directement depuis Github
Salut, Il semble que ce ne soit pas les notes d'osm.org, mais le système « privé » de Mapbox (que les correcteurs rémunérés renvoient vers osm.org quand ils ne peuvent rien faire…). Par contre, bonne chance pour encourager les ouvreurs de note à être précis dans leur demande en utilisant comme commentaire « This is wrong ». C'est pas avec ça que la qualité des notes va s'améliorer… JB. Le 21/07/2015 20:33, Thomas Gratier a écrit : Salut à tous, Github a publié aujourd'hui une annonce concernant l'édition d’éléments et l'ajout de notes dans OpenStreetMap https://github.com/blog/2041-improving-map-data-on-github Bonne lecture Thomas Gratier ___ 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] Importation des arbres municipaux sur Nice
Le 21 juillet 2015 22:00, Vincent Frison vincent.fri...@gmail.com a écrit : Je ferai aussi quelques tests en variant le rayon, je vous tiendrai au courant des résultats... Avec un rayon de 2 mètres : Total of created trees: 29947 Total of updated trees: 574 Total of multi matching trees: 28 Avec un rayon de 5 mètres : Total of created trees: 29767 Total of updated trees: 754 Total of multi matching trees: 281 Maintenant je met à jour les éléments existants au lieu de les effacer. La mise à jour consiste à mettre la même position (la même que l'arbre importé) et de rajouter un tag ref:FR:Nice:trees=* avec l'identifiant de leur jeu de données. Par contre la gestion des multi matching trees (ie. les arbres existant qui matchent plus qu'un seul arbre importé) est très basique puisque je met à jour l'élément avec les valeurs du 1er arbre importé tout simplement (pour les autres éléments importés je créé donc un nouvel élément). Mais bon, avec un rayon de 2 mètres ça ne concerne moins d'1/1000e des arbres.. et surtout je rappelle qu'en plus on parle de décalages inférieurs à 2 mètres donc bon je pense que c'est tolérable. Et du coup je pense qu'il faut garder un rayon faible comme 2 mètres. Au niveau des 1188 arbres visibles sur Overpass il faut voir que: - certains arbres municipaux ne sont pas référencés - certains arbres existants ne sont pas des arbres municipaux - certains arbres existants peuvent être municipaux (et référencés) mais éventuellement trop mal positionnés (et dans ce cas là je pourrai pas faire grand chose) Mais effectivement je vais devoir creuser un peu pour mieux comprendre ;) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Importation des arbres municipaux sur Nice
Hello Je compte importer dans OSM l'ensemble des arbres municipaux de Nice, merci au portail OpenData de l'agglomération de Côte d'Azur. Ici c'est du vrai open data, je ne devrais donc pas avoir la même frustration qu'avec l'import des immeubles de PSS ;) Ils viennent de mettre à jour leur fichier qui contient maintenant plus de 30 000 arbres : http://opendata.nicecotedazur.org/data/dataset?q=arbres En plus de créer les nouveaux arbres mon programme vérifie également la présence d'arbres existants afin de les effacer. Actuellement j'ai mis un rayon de 2 mètres donc pour chaque arbre importé, je regarde les arbres existants qui sont à moins de 2 mètres. Pour l'instant je n'efface que l'arbre plus proche de l'arbre importé (je pourrais également supprimer tous les arbres qui sont à moins de x mètres mais en fait ça ne change pas grand chose car s'il y a plusieurs arbres existants qui sont très proches à priori il y aura également plusieurs arbres importés qui seront très proches donc au final même en ne supprimant que l'arbre existant le plus proche tous les arbres existants seront bien effacés, ce que j'ai pu vérifier par mes tests). Concrètement sur les ~30 000 arbres importés il y a ~540 arbres existants à supprimer. Ce qui est dommage c'est que le fichier n'indique pas le type des arbres et c'est d'autant plus dommage que les arbres existants ont parfois un tag type=*. Par ex. les arbres existants le long de la Promenade des Anglais sont marqué comme palmier (type=palm). Malheureusement je serai obligé de remettre le type à la main une fois l'import exécuté. Mon programme pourrait éventuellement récupérer le type des arbres existants mais bon ça ne marcherait que sur une toute petite partie des arbres importés... D'ailleurs j'ai un peu de mal à comprendre la bonne manière d'indiquer le type car sur la page Wiki du tag natural=tree ( http://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree) il est marqué que le tag type=* est obsolète et qu'il faut plutôt utilisé le tag leaf_type=*. Sauf que ce dernier n'est censé prendre que les valeurs suivantes : broadleaved / needleleaved / mixed / leafless. De plus sous JSOM si on met type=palm ça affiche bien l'arbre avec une image de palmier mais ça ne le fait pas si j'essaye avec genus|species=palm|palmtree. Bref c'est pas très clair... Voila si vous avez des conseils ou suggestions n'hésitez surtout pas.. ++ Vincent. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
D'expérience par rapport à Lyon, les implantations d'arbres issus des données ouvertes ne sont pas toujours plus fiables que ce qui a déjà été mis sur OpenStreetMap. Florian Le Mardi 21 juillet 2015 14h16, Vincent Frison vincent.fri...@gmail.com a écrit : Hello Je compte importer dans OSM l'ensemble des arbres municipaux de Nice, merci au portail OpenData de l'agglomération de Côte d'Azur. Ici c'est du vrai open data, je ne devrais donc pas avoir la même frustration qu'avec l'import des immeubles de PSS ;) Ils viennent de mettre à jour leur fichier qui contient maintenant plus de 30 000 arbres : http://opendata.nicecotedazur.org/data/dataset?q=arbres En plus de créer les nouveaux arbres mon programme vérifie également la présence d'arbres existants afin de les effacer. Actuellement j'ai mis un rayon de 2 mètres donc pour chaque arbre importé, je regarde les arbres existants qui sont à moins de 2 mètres. Pour l'instant je n'efface que l'arbre plus proche de l'arbre importé (je pourrais également supprimer tous les arbres qui sont à moins de x mètres mais en fait ça ne change pas grand chose car s'il y a plusieurs arbres existants qui sont très proches à priori il y aura également plusieurs arbres importés qui seront très proches donc au final même en ne supprimant que l'arbre existant le plus proche tous les arbres existants seront bien effacés, ce que j'ai pu vérifier par mes tests). Concrètement sur les ~30 000 arbres importés il y a ~540 arbres existants à supprimer. Ce qui est dommage c'est que le fichier n'indique pas le type des arbres et c'est d'autant plus dommage que les arbres existants ont parfois un tag type=*. Par ex. les arbres existants le long de la Promenade des Anglais sont marqué comme palmier (type=palm). Malheureusement je serai obligé de remettre le type à la main une fois l'import exécuté. Mon programme pourrait éventuellement récupérer le type des arbres existants mais bon ça ne marcherait que sur une toute petite partie des arbres importés... D'ailleurs j'ai un peu de mal à comprendre la bonne manière d'indiquer le type car sur la page Wiki du tag natural=tree (http://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree) il est marqué que le tag type=* est obsolète et qu'il faut plutôt utilisé le tag leaf_type=*. Sauf que ce dernier n'est censé prendre que les valeurs suivantes : broadleaved / needleleaved / mixed / leafless. De plus sous JSOM si on met type=palm ça affiche bien l'arbre avec une image de palmier mais ça ne le fait pas si j'essaye avec genus|species=palm|palmtree. Bref c'est pas très clair... Voila si vous avez des conseils ou suggestions n'hésitez surtout pas.. ++ Vincent. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Présentation : Snutin
Bonjour, Moi c'est Snutin, nouveau contributeur Breton j'espère pouvoir aider notamment sur la région de Loudéac qui manque cruellement de contributeurs ! (même les rivières ne sont pas indiquées). Je pense aussi contribuer sur la région de Quimperlé puisque j'y habite... Je suis également débutant dans l'utilisation des listes de diffusion... mais ça ne devrait pas être un problème :D A bientôt pour de futures question :) Snutin. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Présentation : Snutin
Bonjour et bienvenu! A noter qu'il existe également une liste de discussion dédiée aux contributeurs bretons https://lists.openstreetmap.org/listinfo/talk-fr-bzh Romain Le 21 juillet 2015 10:37, Pierre Jarnet pjar...@gmail.com a écrit : Bonjour, Moi c'est Snutin, nouveau contributeur Breton j'espère pouvoir aider notamment sur la région de Loudéac qui manque cruellement de contributeurs ! (même les rivières ne sont pas indiquées). Je pense aussi contribuer sur la région de Quimperlé puisque j'y habite... Je suis également débutant dans l'utilisation des listes de diffusion... mais ça ne devrait pas être un problème :D A bientôt pour de futures question :) Snutin. ___ 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] Présentation : Snutin
Soit le bienvenu ! Pour les cours d'eau, tu peux t'aider de la couche BDCarthage: http://tile.openstreetmap.fr/?zoom=13lat=48.16921lon=-2.73772layers=B000FTF La géométrie n'est pas très précise, mais les noms et références de cours d'eau sont en principe fiables. Le 21/07/2015 10:37, Pierre Jarnet a écrit : Bonjour, Moi c'est Snutin, nouveau contributeur Breton j'espère pouvoir aider notamment sur la région de Loudéac qui manque cruellement de contributeurs ! (même les rivières ne sont pas indiquées). Je pense aussi contribuer sur la région de Quimperlé puisque j'y habite... Je suis également débutant dans l'utilisation des listes de diffusion... mais ça ne devrait pas être un problème :D A bientôt pour de futures question :) Snutin. ___ 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
Re: [OSM-talk-fr] durée des trajets à vélo dans Paris
Cela vient de l'algo de routage de geovelo, et non des donnée osm. Par contre il me semble que sur geovelo on peut choisir son profil et donc sa vitesse moyenne (du moin sur l'apli Android geovelo touraine) Le 21 juillet 2015 15:16:21 CEST, Julien Demade dem...@no-log.org a écrit : Bonjour Je voulais signaler un problème quant à la durée indiquée sur OSM des trajets à vélo dans Paris (problème possiblement plus général, je ne sais pas): elle est beaucoup trop brève, ne tient pas du tout compte du fait qu'on ne roule pas aussi vite en milieu urbain que sur une route de campagne (feux, circulation, croisements, etc.). Pour donner un ordre de grandeur, un trajet indiqué sur OSM comme prenant à peu près 30-40mn (suivant que l'on utilise GraphHopper ou MapQuest), est indiqué sur un autre calculateur d'itinéraires (qui donne lui des durées fiables) comme prenant environ 50mn (il s'agit de http://www.geovelo.fr/). Bref, tel quel le planificateur d'itinéraire vélo est inutilisable, ce qui est dommage! Comme je n'ai malheureusement aucune idée de la nature du problème, et donc encore moins de la façon de le résoudre, je me contente de le signaler, en espérant qu'il y a plus compétent que moi - ce dont je ne doute pas! Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Salut, Quelques remarques : - Overpass trouve 1188 arbres dans Nice : soit il en manque dans le fichier de l'agglo, soit 2m, c'est pas assez. Soit le fichier de l'agglo n'est pas assez bon, soit ce qui est dans OSM n'est pas assez bon. Problèmatique de tenter d'importer avant d'en savoir plus. - Pas vraiment d'accord pour supprimer l'existant pour y mettre la donnée de « référence » à la place. Le but est d'éviter d'arriver à la situation US vue d'ici (difficile de savoir ce qu'il en est réellement sans être sur place) ou l'essentiel de la donnée est issue d'import avec peu de vie communautaire locale. Et d'éviter la frustration des mappeurs locaux. - Es-tu inscrit à la liste de discussion import ? JB. Le 21/07/2015 14:05, Vincent Frison a écrit : Hello Je compte importer dans OSM l'ensemble des arbres municipaux de Nice, merci au portail OpenData de l'agglomération de Côte d'Azur. Ici c'est du vrai open data, je ne devrais donc pas avoir la même frustration qu'avec l'import des immeubles de PSS ;) Ils viennent de mettre à jour leur fichier qui contient maintenant plus de 30 000 arbres : http://opendata.nicecotedazur.org/data/dataset?q=arbres En plus de créer les nouveaux arbres mon programme vérifie également la présence d'arbres existants afin de les effacer. Actuellement j'ai mis un rayon de 2 mètres donc pour chaque arbre importé, je regarde les arbres existants qui sont à moins de 2 mètres. Pour l'instant je n'efface que l'arbre plus proche de l'arbre importé (je pourrais également supprimer tous les arbres qui sont à moins de x mètres mais en fait ça ne change pas grand chose car s'il y a plusieurs arbres existants qui sont très proches à priori il y aura également plusieurs arbres importés qui seront très proches donc au final même en ne supprimant que l'arbre existant le plus proche tous les arbres existants seront bien effacés, ce que j'ai pu vérifier par mes tests). Concrètement sur les ~30 000 arbres importés il y a ~540 arbres existants à supprimer. Ce qui est dommage c'est que le fichier n'indique pas le type des arbres et c'est d'autant plus dommage que les arbres existants ont parfois un tag type=*. Par ex. les arbres existants le long de la Promenade des Anglais sont marqué comme palmier (type=palm). Malheureusement je serai obligé de remettre le type à la main une fois l'import exécuté. Mon programme pourrait éventuellement récupérer le type des arbres existants mais bon ça ne marcherait que sur une toute petite partie des arbres importés... D'ailleurs j'ai un peu de mal à comprendre la bonne manière d'indiquer le type car sur la page Wiki du tag natural=tree (http://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree) il est marqué que le tag type=* est obsolète et qu'il faut plutôt utilisé le tag leaf_type=*. Sauf que ce dernier n'est censé prendre que les valeurs suivantes : broadleaved / needleleaved / mixed / leafless. De plus sous JSOM si on met type=palm ça affiche bien l'arbre avec une image de palmier mais ça ne le fait pas si j'essaye avec genus|species=palm|palmtree. Bref c'est pas très clair... Voila si vous avez des conseils ou suggestions n'hésitez surtout pas.. ++ Vincent. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Perso je m'occupe d'intégrer les arbres de Montpellier + éclairage (campagne terrain plus Bing pour le placement) Les palmiers c'est du feuillu persistant. Il n'y a plus de distinction. Je laisse type=palm uniquement pour les palmiers... Sinon leaf_type=* et leaf_cycle sur chaque arbre et c'est ok Pour le nom complet latin j'utilise taxon=* et pas plus quand j'aurais mis tous les arbres j'ajouterai le reste par requête (Overpass) Penses à tester tout de même les zones contenant déjà un couvert végétal dans OSM pour éviter les doublons et de supprimer le tout. Après je mettrais plutôt 5 à 7m pour le rayons. Faire plusieurs tests en variant d'un mètre pour vérifier le rayons le plus probant. Le 21 juillet 2015 14:37, JB jb...@mailoo.org a écrit : Salut, Quelques remarques : - Overpass trouve 1188 arbres dans Nice : soit il en manque dans le fichier de l'agglo, soit 2m, c'est pas assez. Soit le fichier de l'agglo n'est pas assez bon, soit ce qui est dans OSM n'est pas assez bon. Problèmatique de tenter d'importer avant d'en savoir plus. - Pas vraiment d'accord pour supprimer l'existant pour y mettre la donnée de « référence » à la place. Le but est d'éviter d'arriver à la situation US vue d'ici (difficile de savoir ce qu'il en est réellement sans être sur place) ou l'essentiel de la donnée est issue d'import avec peu de vie communautaire locale. Et d'éviter la frustration des mappeurs locaux. - Es-tu inscrit à la liste de discussion import ? JB. Le 21/07/2015 14:05, Vincent Frison a écrit : Hello Je compte importer dans OSM l'ensemble des arbres municipaux de Nice, merci au portail OpenData de l'agglomération de Côte d'Azur. Ici c'est du vrai open data, je ne devrais donc pas avoir la même frustration qu'avec l'import des immeubles de PSS ;) Ils viennent de mettre à jour leur fichier qui contient maintenant plus de 30 000 arbres : http://opendata.nicecotedazur.org/data/dataset?q=arbres En plus de créer les nouveaux arbres mon programme vérifie également la présence d'arbres existants afin de les effacer. Actuellement j'ai mis un rayon de 2 mètres donc pour chaque arbre importé, je regarde les arbres existants qui sont à moins de 2 mètres. Pour l'instant je n'efface que l'arbre plus proche de l'arbre importé (je pourrais également supprimer tous les arbres qui sont à moins de x mètres mais en fait ça ne change pas grand chose car s'il y a plusieurs arbres existants qui sont très proches à priori il y aura également plusieurs arbres importés qui seront très proches donc au final même en ne supprimant que l'arbre existant le plus proche tous les arbres existants seront bien effacés, ce que j'ai pu vérifier par mes tests). Concrètement sur les ~30 000 arbres importés il y a ~540 arbres existants à supprimer. Ce qui est dommage c'est que le fichier n'indique pas le type des arbres et c'est d'autant plus dommage que les arbres existants ont parfois un tag type=*. Par ex. les arbres existants le long de la Promenade des Anglais sont marqué comme palmier (type=palm). Malheureusement je serai obligé de remettre le type à la main une fois l'import exécuté. Mon programme pourrait éventuellement récupérer le type des arbres existants mais bon ça ne marcherait que sur une toute petite partie des arbres importés... D'ailleurs j'ai un peu de mal à comprendre la bonne manière d'indiquer le type car sur la page Wiki du tag natural=tree ( http://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree) il est marqué que le tag type=* est obsolète et qu'il faut plutôt utilisé le tag leaf_type=*. Sauf que ce dernier n'est censé prendre que les valeurs suivantes : broadleaved / needleleaved / mixed / leafless. De plus sous JSOM si on met type=palm ça affiche bien l'arbre avec une image de palmier mais ça ne le fait pas si j'essaye avec genus|species=palm|palmtree. Bref c'est pas très clair... Voila si vous avez des conseils ou suggestions n'hésitez surtout pas.. ++ Vincent. ___ 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] durée des trajets à vélo dans Paris
Bonjour Je voulais signaler un problème quant à la durée indiquée sur OSM des trajets à vélo dans Paris (problème possiblement plus général, je ne sais pas): elle est beaucoup trop brève, ne tient pas du tout compte du fait qu'on ne roule pas aussi vite en milieu urbain que sur une route de campagne (feux, circulation, croisements, etc.). Pour donner un ordre de grandeur, un trajet indiqué sur OSM comme prenant à peu près 30-40mn (suivant que l'on utilise GraphHopper ou MapQuest), est indiqué sur un autre calculateur d'itinéraires (qui donne lui des durées fiables) comme prenant environ 50mn (il s'agit de http://www.geovelo.fr/). Bref, tel quel le planificateur d'itinéraire vélo est inutilisable, ce qui est dommage! Comme je n'ai malheureusement aucune idée de la nature du problème, et donc encore moins de la façon de le résoudre, je me contente de le signaler, en espérant qu'il y a plus compétent que moi - ce dont je ne doute pas! Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Pourquoi supprimes-tu ? Si tu détectes qu'un arbre existe déjà, dans un rayon de 2m, pourquoi ne pas plutôt déplacer l'arbre existant et lui ajouter les éventuelles infos que tu apportes (source, date, ...) ? Ça permettrait de ne pas supprimer un travail déjà fait, et de conserver les éventuels tags déjà apposés (tel que le type que tu évoques). Francescu Le 21 juillet 2015 14:05, Vincent Frison vincent.fri...@gmail.com a écrit : Hello Je compte importer dans OSM l'ensemble des arbres municipaux de Nice, merci au portail OpenData de l'agglomération de Côte d'Azur. Ici c'est du vrai open data, je ne devrais donc pas avoir la même frustration qu'avec l'import des immeubles de PSS ;) Ils viennent de mettre à jour leur fichier qui contient maintenant plus de 30 000 arbres : http://opendata.nicecotedazur.org/data/dataset?q=arbres En plus de créer les nouveaux arbres mon programme vérifie également la présence d'arbres existants afin de les effacer. Actuellement j'ai mis un rayon de 2 mètres donc pour chaque arbre importé, je regarde les arbres existants qui sont à moins de 2 mètres. Pour l'instant je n'efface que l'arbre plus proche de l'arbre importé (je pourrais également supprimer tous les arbres qui sont à moins de x mètres mais en fait ça ne change pas grand chose car s'il y a plusieurs arbres existants qui sont très proches à priori il y aura également plusieurs arbres importés qui seront très proches donc au final même en ne supprimant que l'arbre existant le plus proche tous les arbres existants seront bien effacés, ce que j'ai pu vérifier par mes tests). Concrètement sur les ~30 000 arbres importés il y a ~540 arbres existants à supprimer. Ce qui est dommage c'est que le fichier n'indique pas le type des arbres et c'est d'autant plus dommage que les arbres existants ont parfois un tag type=*. Par ex. les arbres existants le long de la Promenade des Anglais sont marqué comme palmier (type=palm). Malheureusement je serai obligé de remettre le type à la main une fois l'import exécuté. Mon programme pourrait éventuellement récupérer le type des arbres existants mais bon ça ne marcherait que sur une toute petite partie des arbres importés... D'ailleurs j'ai un peu de mal à comprendre la bonne manière d'indiquer le type car sur la page Wiki du tag natural=tree ( http://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree) il est marqué que le tag type=* est obsolète et qu'il faut plutôt utilisé le tag leaf_type=*. Sauf que ce dernier n'est censé prendre que les valeurs suivantes : broadleaved / needleleaved / mixed / leafless. De plus sous JSOM si on met type=palm ça affiche bien l'arbre avec une image de palmier mais ça ne le fait pas si j'essaye avec genus|species=palm|palmtree. Bref c'est pas très clair... Voila si vous avez des conseils ou suggestions n'hésitez surtout pas.. ++ Vincent. ___ 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
Re: [OSM-talk-fr] Recyclage du rendu QA dans osmose: les carreaux INSEE sans route...
Le lundi 20 juillet 2015 à 22:59 +0200, Christian Quest a écrit : Ah les devoirs de vacances ;) +1 c bien les vacances Voilà un petit ajout pour osmose, la répartition de la population faite par l'INSEE sur des careaux de 200m de côté servait déjà au rendu QA pour indiquer là où des routes manquent potentiellement (ou des bâtiments). Pour faciliter la recherche de ces carreaux sans route à proximité, ils sont désormais transmis chaque nuit à osmose... http://osmose.openstreetmap.fr/fr/map/#item=7170 Ceci permet de charger rapidement la zone en question dans JOSM (ou iD) et de rajouter la ou les routes manquantes. En général il y a pas mal d'autres choses à ajouter car il est rare qu'une zone soit détaillée et que des routes n'y soient pas présentes ! Attention: Il peut y avoir des faux positifs... les données de l'INSEE ne sont pas parfaites. Parfois il s'agit de décalage d'un carreau, parfois il n'y a vraiment rien sur la zone en question (j'ai eu des cas en plein champs). Dans ce cas, vous pouvez indiquer le faux-positif à osmose. Sur les zones de forêt, penser à utiliser le cadastre en complément des images aériennes pour retrouver les routes et chemins masqués par les arbres. Il y a un peu plus de 31000 carreaux sans route à proximité... à vous de jouer ! 31 000 me semble faible : http://tile.openstreetmap.fr/?zoom=15lat=49.4462575043827lon=4.56345641933607layers=B000TFF http://osmose.openstreetmap.fr/fr/map/#zoom=15lat=49.4462575043827lon=4.56345641933607item=7170 D'autres analyses de ce type pourront s'ajouter avec le croisement d'autres données (le Route500 par exemple). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Présentation : Snutin
Sauf si le nom change le long du cours d'eau ce qui est le cas dans les PO. Mais c'est une bonne base pour commencer à tracer. Après il vaut mieux charger le shapefile car il est plus complet que la tuiles. Il permet d'avoir les largeurs, l'intermittence et d'autres infos utiles. Le 21 juillet 2015 10:45, Christian Quest cqu...@openstreetmap.fr a écrit : Soit le bienvenu ! Pour les cours d'eau, tu peux t'aider de la couche BDCarthage: http://tile.openstreetmap.fr/?zoom=13lat=48.16921lon=-2.73772layers=B000FTF La géométrie n'est pas très précise, mais les noms et références de cours d'eau sont en principe fiables. Le 21/07/2015 10:37, Pierre Jarnet a écrit : Bonjour, Moi c'est Snutin, nouveau contributeur Breton j'espère pouvoir aider notamment sur la région de Loudéac qui manque cruellement de contributeurs ! (même les rivières ne sont pas indiquées). Je pense aussi contribuer sur la région de Quimperlé puisque j'y habite... Je suis également débutant dans l'utilisation des listes de diffusion... mais ça ne devrait pas être un problème :D A bientôt pour de futures question :) Snutin. ___ Talk-fr mailing listTalk-fr@openstreetmap.orghttps://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] Présentation : Snutin
Pour les cours d'eau je pensais me servir des cadastres en bonne partie, n'est-ce pas une bonne solution ? Le 21 juillet 2015 15:18, Jérôme Seigneuret jseigneuret-...@yahoo.fr a écrit : Sauf si le nom change le long du cours d'eau ce qui est le cas dans les PO. Mais c'est une bonne base pour commencer à tracer. Après il vaut mieux charger le shapefile car il est plus complet que la tuiles. Il permet d'avoir les largeurs, l'intermittence et d'autres infos utiles. Le 21 juillet 2015 10:45, Christian Quest cqu...@openstreetmap.fr a écrit : Soit le bienvenu ! Pour les cours d'eau, tu peux t'aider de la couche BDCarthage: http://tile.openstreetmap.fr/?zoom=13lat=48.16921lon=-2.73772layers=B000FTF La géométrie n'est pas très précise, mais les noms et références de cours d'eau sont en principe fiables. Le 21/07/2015 10:37, Pierre Jarnet a écrit : Bonjour, Moi c'est Snutin, nouveau contributeur Breton j'espère pouvoir aider notamment sur la région de Loudéac qui manque cruellement de contributeurs ! (même les rivières ne sont pas indiquées). Je pense aussi contribuer sur la région de Quimperlé puisque j'y habite... Je suis également débutant dans l'utilisation des listes de diffusion... mais ça ne devrait pas être un problème :D A bientôt pour de futures question :) Snutin. ___ Talk-fr mailing listTalk-fr@openstreetmap.orghttps://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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Présentation : Snutin
Bienvenue Pierre et amuses toi bien ! Le 21 juillet 2015 15:18, Jérôme Seigneuret jseigneuret-...@yahoo.fr a écrit : Sauf si le nom change le long du cours d'eau ce qui est le cas dans les PO. Mais c'est une bonne base pour commencer à tracer. Après il vaut mieux charger le shapefile car il est plus complet que la tuiles. Il permet d'avoir les largeurs, l'intermittence et d'autres infos utiles. Le 21 juillet 2015 10:45, Christian Quest cqu...@openstreetmap.fr a écrit : Soit le bienvenu ! Pour les cours d'eau, tu peux t'aider de la couche BDCarthage: http://tile.openstreetmap.fr/?zoom=13lat=48.16921lon=-2.73772layers=B000FTF La géométrie n'est pas très précise, mais les noms et références de cours d'eau sont en principe fiables. Le 21/07/2015 10:37, Pierre Jarnet a écrit : Bonjour, Moi c'est Snutin, nouveau contributeur Breton j'espère pouvoir aider notamment sur la région de Loudéac qui manque cruellement de contributeurs ! (même les rivières ne sont pas indiquées). Je pense aussi contribuer sur la région de Quimperlé puisque j'y habite... Je suis également débutant dans l'utilisation des listes de diffusion... mais ça ne devrait pas être un problème :D A bientôt pour de futures question :) Snutin. ___ Talk-fr mailing listTalk-fr@openstreetmap.orghttps://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 -- *Florian Lainez* @overflorian http://twitter.com/overflorian ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Présentation : Snutin
Bienvenue, Je ne travaille pas sur ta zone (pour le moment) mais question cadastre, ça dépend de la qualité des saisies et le détail du cartographe qui a saisie. Mais normalement le cadastre n'a pas vocation à renseigner les cours d'eau (C'est mis à titre d'information) Pour être plus clair ce sont des zones où il n'y a pas d'info cadastrale (pas de parcelle) Comme les impôts se base sur l'usage du sol, la précision du cours d'eau peut être mauvaise surtout en zone agricole ou forestière. Donc c'est bien à titre indicatif mais pas plus. Il y a eu pas mal de discussion sur la taille des cours d'eau pour définir si c'est tagué d'une manière ou d'une autre, si c'est du naturel ou des fossé. Attention aussi car il y a encore beaucoup de cours d'eau en riverbank (tag déprécié) Pioches dans le wiki mais pour steam ou river c'est pas facile à déterminer quand tu es sur une largeur faible car il n'y a pas de précision. Après pour définir un zonage en dessous du tracé du cours d'eau c'est une question sans réponse. Ça a un intérêt pour des largeurs significatives mais personnes n'est d'accord sur une largeur. Par exemple ditch, steam n'ont pas de zonage en dessous du tracé hors l'import du cadastre en a mis de partout... Donc il y a du nettoyage à faire. Je te conseille d'utiliser toutes les sources possibles (Dans la mesures où elles le permettent : question de droits), mais reste que le terrain est la meilleur solution pour choisir le type de tag. Mapillary en barque ;-) Sinon c'est les waders. Bon courage Le 21 juillet 2015 16:10, Florian LAINEZ winner...@free.fr a écrit : Bienvenue Pierre et amuses toi bien ! Le 21 juillet 2015 15:18, Jérôme Seigneuret jseigneuret-...@yahoo.fr a écrit : Sauf si le nom change le long du cours d'eau ce qui est le cas dans les PO. Mais c'est une bonne base pour commencer à tracer. Après il vaut mieux charger le shapefile car il est plus complet que la tuiles. Il permet d'avoir les largeurs, l'intermittence et d'autres infos utiles. Le 21 juillet 2015 10:45, Christian Quest cqu...@openstreetmap.fr a écrit : Soit le bienvenu ! Pour les cours d'eau, tu peux t'aider de la couche BDCarthage: http://tile.openstreetmap.fr/?zoom=13lat=48.16921lon=-2.73772layers=B000FTF La géométrie n'est pas très précise, mais les noms et références de cours d'eau sont en principe fiables. Le 21/07/2015 10:37, Pierre Jarnet a écrit : Bonjour, Moi c'est Snutin, nouveau contributeur Breton j'espère pouvoir aider notamment sur la région de Loudéac qui manque cruellement de contributeurs ! (même les rivières ne sont pas indiquées). Je pense aussi contribuer sur la région de Quimperlé puisque j'y habite... Je suis également débutant dans l'utilisation des listes de diffusion... mais ça ne devrait pas être un problème :D A bientôt pour de futures question :) Snutin. ___ Talk-fr mailing listTalk-fr@openstreetmap.orghttps://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 -- *Florian Lainez* @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
