[OSM-talk-fr] Offre de stage
Bonjour, Vue ce matin, une (chouette) offre de stage où OSM est une partie du sujet : http://georezo.net/forum/viewtopic.php?pid=262994#p262994 vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mechanical Edit : le mal ( était : peut-il guérir le mal ?)
Le 19 janv. 2015 à 21:41, Art Penteur art.pent...@gmail.com a écrit : Personnellement, je suis pour [les éditions (semi) automatiques]. itou .Certaines erreurs signalées par Osmose m'énervent : Espace en double, ou au début où à la fin de name. +1 Je ne sais pas combien il en reste à intégrer, mais serait-il possible de nettoyer le fichier de données source qu’utilise Osmose ? J’ai intégré quelques bureaux de poste et quelques gares, mais je n’ai pas pensé à corriger la casse du nom. Pour en revenir aux bureaux de poste, je pense qu'il y en a un peu trop pour faire du cas pas cas. +1 et il y en a d'autres (nombre inconnu). C'est pour ça que je propose de passer à l'automatisation, soit du mail de sensibilisation, soit de la correction. Attention à la forme ;-) Allez, je peux essayer quelques messages spécifiques, pour voir si ça donne quelque chose. J’ai eu le passage du père « bot » , à moins que c’était Arpenteur en personne ? — Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mechanical Edit : le mal ( était : peut-il guérir le mal ?)
Oui, pour l'instant je n'ai fait que quelques signalements, sans l'aide d'un programme. Je n'ai eu que des retours courtois, et les bureaux concernés sont corrigés. C'est peut-être aussi bien de rester entre humains, après tout. Et il n'y a a que ceux qui ne font rien qui n'ont pas d'erreur à corriger ! (dixit Art Penteur à qui Osmose associe 6258 erreurs !) Art. Le 20 janvier 2015 09:53, Yves Pratter yves.prat...@gmail.com a écrit : Le 19 janv. 2015 à 21:41, Art Penteur art.pent...@gmail.com a écrit : Personnellement, je suis pour [les éditions (semi) automatiques]. itou .Certaines erreurs signalées par Osmose m'énervent : Espace en double, ou au début où à la fin de name. +1 Je ne sais pas combien il en reste à intégrer, mais serait-il possible de nettoyer le fichier de données source qu’utilise Osmose ? J’ai intégré quelques bureaux de poste et quelques gares, mais je n’ai pas pensé à corriger la casse du nom. Pour en revenir aux bureaux de poste, je pense qu'il y en a un peu trop pour faire du cas pas cas. +1 et il y en a d'autres (nombre inconnu). C'est pour ça que je propose de passer à l'automatisation, soit du mail de sensibilisation, soit de la correction. Attention à la forme ;-) Allez, je peux essayer quelques messages spécifiques, pour voir si ça donne quelque chose. J’ai eu le passage du père « bot » , à moins que c’était Arpenteur en personne ? — Yves ___ 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] Réunion contributeurs Toulouse ?
Merci les gars du Tetaneutral ! Perso cela me convient tout à fait. On se retrouve donc à la Paniolade à 19h. Comme je disais je peux covoiturer depuis l'Ouest de Toulouse, n'hésitez pas à m'appeler (mon num est dans ma signature). Dommage Seb, j'espère te croiser tout de même. À tout à l'heure Florian LAINEZ a écrit : Je suis content que certains d'entre vous puisse se libérer demain. Pour les autres ce n'est que partie remise :) Honte à moi, je n'avais pas détecté la collision de date entre cette proposition et une obligation professionnelle à laquelle je dois donner la priorité. La rencontre se fera donc sans moi, j'en suis sincèrement navré. :( Suivant l'heure et le lieu retenus, j'essaierai quand même de passer vous dire bonjour avant de me rendre à mon rendez-vous. Sébastien, penaud. -- Sébastien Dinot, sebastien.di...@free.fr http://sebastien.dinot.free.fr/ Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer ! ___ 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] Zonages statistiques Ilots et IRIS
Bonjour, L'APUR libère des données qui sont parfois évoquées ici, souvent pour regretter leur caractère non libre, car s'appuyant sur des géométries de l'IGN. Il s'agit des les limites statistiques infracommunales Îlots et IRIS : http://www.apur.org/article/donnees-disponibles-open-data Les données Îlot ne sont pas (au moins en diffusion INSEE) promises à grand avenir : http://www.insee.fr/fr/methodes/default.asp?page=definitions/ilot.htm donc les intégrer dans OSM se discute. Proposer en revanche un fond IRIS [1] national et libre aurait de l'allure, et des consommateurs. Les données de l'APUR sont un matériau pertinent, sur Paris et petite couronne, pour alimenter cette démarche. Il faudrait à cette occasion établir un schéma de tags, à base de boundary=census ou boundary=statistical, non documentés pour l'instant. vincent [1] : http://www.insee.fr/fr/methodes/default.asp?page=definitions/iris.htm ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
Ça va quand même être difficile de faire ça sans rien ajouter dans OSM. Certaines limites n'existent simplement pas dans la zone où je regarde (ma commune). J'ai précisément une limite qui semble être la voie ferrée et comme les rails sont multiples, je serais tenté de placer une limite boundary filaire pour clore ma surface constituée jusque là de boundary=admin et de highway. Mais la question vaut d'être posée ! Dans OSM, ou pas ? A+ Marc Sibert m...@sibert.fr Le 20 janvier 2015 17:36, JB jb...@mailoo.org a écrit : On parle bien de « couche » comme dans « pas dans la base principale d'OSM » ? (Si oui, j'approuve, si non, je me demande qui va entretenir ça et comment les nouveaux contributeurs vont encore se prendre ça dans la figure…) JB. Le 20/01/2015 17:24, Damouns a écrit : Quand je vois que les nouveaux cantons ne sont pas encore tous saisis je crains un peu que cette nouvelle idée ne soit jamais terminée... Mais c'est effectivement une couche qui serait utile. Le 20 janvier 2015 17:21, Marc SIBERT m...@sibert.fr a écrit : Bonjour, Il faudrait aussi se limiter à un modèle contour/surface pour simplifier la création et l'usage (si c'est possible en même temps) et sans ajouter trop de surcharge à la carte (les relations pour ça c'est bien, mais plus difficile à maintenir il est vrai). Il faut voir qu'une majorité des IRIS correspondent aux communes et qu'il est facile de copier les relations administratives existantes pour en faire des surfaces census. A+ Marc Sibert m...@sibert.fr Le 20 janvier 2015 14:51, Vincent de Château-Thierry osm.v...@free.fr a écrit : Bonjour, L'APUR libère des données qui sont parfois évoquées ici, souvent pour regretter leur caractère non libre, car s'appuyant sur des géométries de l'IGN. Il s'agit des les limites statistiques infracommunales Îlots et IRIS : http://www.apur.org/article/donnees-disponibles-open-data Les données Îlot ne sont pas (au moins en diffusion INSEE) promises à grand avenir : http://www.insee.fr/fr/methodes/default.asp?page=definitions/ilot.htm donc les intégrer dans OSM se discute. Proposer en revanche un fond IRIS [1] national et libre aurait de l'allure, et des consommateurs. Les données de l'APUR sont un matériau pertinent, sur Paris et petite couronne, pour alimenter cette démarche. Il faudrait à cette occasion établir un schéma de tags, à base de boundary=census ou boundary=statistical, non documentés pour l'instant. vincent [1] : http://www.insee.fr/fr/methodes/default.asp?page=definitions/iris.htm ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
Bonjour, Il faudrait aussi se limiter à un modèle contour/surface pour simplifier la création et l'usage (si c'est possible en même temps) et sans ajouter trop de surcharge à la carte (les relations pour ça c'est bien, mais plus difficile à maintenir il est vrai). Il faut voir qu'une majorité des IRIS correspondent aux communes et qu'il est facile de copier les relations administratives existantes pour en faire des surfaces census. A+ Marc Sibert m...@sibert.fr Le 20 janvier 2015 14:51, Vincent de Château-Thierry osm.v...@free.fr a écrit : Bonjour, L'APUR libère des données qui sont parfois évoquées ici, souvent pour regretter leur caractère non libre, car s'appuyant sur des géométries de l'IGN. Il s'agit des les limites statistiques infracommunales Îlots et IRIS : http://www.apur.org/article/donnees-disponibles-open-data Les données Îlot ne sont pas (au moins en diffusion INSEE) promises à grand avenir : http://www.insee.fr/fr/methodes/default.asp?page=definitions/ilot.htm donc les intégrer dans OSM se discute. Proposer en revanche un fond IRIS [1] national et libre aurait de l'allure, et des consommateurs. Les données de l'APUR sont un matériau pertinent, sur Paris et petite couronne, pour alimenter cette démarche. Il faudrait à cette occasion établir un schéma de tags, à base de boundary=census ou boundary=statistical, non documentés pour l'instant. vincent [1] : http://www.insee.fr/fr/methodes/default.asp?page=definitions/iris.htm ___ 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] Zonages statistiques Ilots et IRIS
On parle bien de « couche » comme dans « pas dans la base principale d'OSM » ? (Si oui, j'approuve, si non, je me demande qui va entretenir ça et comment les nouveaux contributeurs vont encore se prendre ça dans la figure…) JB. Le 20/01/2015 17:24, Damouns a écrit : Quand je vois que les nouveaux cantons ne sont pas encore tous saisis je crains un peu que cette nouvelle idée ne soit jamais terminée... Mais c'est effectivement une couche qui serait utile. Le 20 janvier 2015 17:21, Marc SIBERT m...@sibert.fr mailto:m...@sibert.fr a écrit : Bonjour, Il faudrait aussi se limiter à un modèle contour/surface pour simplifier la création et l'usage (si c'est possible en même temps) et sans ajouter trop de surcharge à la carte (les relations pour ça c'est bien, mais plus difficile à maintenir il est vrai). Il faut voir qu'une majorité des IRIS correspondent aux communes et qu'il est facile de copier les relations administratives existantes pour en faire des surfaces census. A+ Marc Sibert m...@sibert.fr mailto:m...@sibert.fr Le 20 janvier 2015 14:51, Vincent de Château-Thierry osm.v...@free.fr mailto:osm.v...@free.fr a écrit : Bonjour, L'APUR libère des données qui sont parfois évoquées ici, souvent pour regretter leur caractère non libre, car s'appuyant sur des géométries de l'IGN. Il s'agit des les limites statistiques infracommunales Îlots et IRIS : http://www.apur.org/article/donnees-disponibles-open-data Les données Îlot ne sont pas (au moins en diffusion INSEE) promises à grand avenir : http://www.insee.fr/fr/methodes/default.asp?page=definitions/ilot.htm donc les intégrer dans OSM se discute. Proposer en revanche un fond IRIS [1] national et libre aurait de l'allure, et des consommateurs. Les données de l'APUR sont un matériau pertinent, sur Paris et petite couronne, pour alimenter cette démarche. Il faudrait à cette occasion établir un schéma de tags, à base de boundary=census ou boundary=statistical, non documentés pour l'instant. vincent [1] : http://www.insee.fr/fr/methodes/default.asp?page=definitions/iris.htm ___ 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 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] Mechanical Edit : le mal ( était : peut-il guérir le mal ?)
Attention à ce que compte Osmose. Il ne détecte que l'auteur de la dernière version d'un objet qui 'a pu être modifié que sur certains des tags sans même toucher à la géométrie ou la contrôler; certains objets sont laissés tels quels et il faut remonter l'historique pour savoir ce qui a été fait avant, mais ça Osmose ne sait pas remonter à la source de qui a fait réellement l'erreur signalée. D'autre part il y a des erreurs comptées tout à fait normales quand la modification a consisté à ajouter un FIXME sur ce qui est incomplet. Il vaut mieux une donnée incomplète que mettre une donnée arbitraire corrigeant l'erreur Osmose (par exemple un segment destiné à fermer un objet dont on ne connait pas certains détail locaux. En fait tous ceux qui font beaucoup de travail sur OSM ont des paquets d'erreurs qui leur sont attribués par Osmose qui ne fait pas dans le détail et ne tient pas compte même de ce que cette modif a réellement corrigé (très souvent cela corrige un paquet d'erreurs laissées par d'autres mais certaines ne le sont pas). On ne peut pas s'attendre non plus à ce que ceux qui font des erreurs les corrige toutes eux-mêmes. D'ailleurs s on regarde un peu mieux on voit aussi que les bots du DWG laissent un énorme paquet d'erreurs derrière eux (notamment dans les données qu'ils suppriment en masse même à tord car leurs requêtes sont souvent insuffisantes pour savoir réellement ce qu'ils suppriment, ils oublient souvent de regarder les autres tags pour lesquels les données supprimées étaient nécessaires et tout à fait justes et même pas concernées par les raisons données par le DWG). Bref méfiance avec ces statistiques qu'il ne faut pas lire à la lettre (une meilleure statistique est de regarder le rapport entre le nombre de modifs NON marquées en erreur et celles qui le sont et voir comment évolue ce taux avec le temps : parfois il y a des hausses brutales mais c'est la plupart du temps dû soit à l'ajout de nouvelles règles ajoutées dans Osmose, pas toujours justes dans un premier jet car pas assez filtrées pour tenir compte de certaines exceptions normales oubliées, ou parce qu'il y a eu une nouvelle façon de faire, ou bien un apport massif, ou le passage d'un bot qui a pu rompre un objet sur ces règles; qui sera ensuite modifié sur tout autre chose que ce qui est signalé par ce que ce n'était pas l'objet du changeset) On fait de notre mieux pour tenter de tenir nos statistiques basses; mais il est impossible de les corriger sans infos supplémentaires quand au départ les données étaient justes et correctement marquées en FIXME quand elles étaient insuffisantes ou ambiguës à la source. Enfin certaines erreurs d'Osmose n'en sont pas, ce sont souvent juste des alertes sur des erreurs courantes fortement probables mais ayant des exceptions. On peut toujours tenter de les signaler en faux-positif mais en pratique on ne le fait pas s'il y a effectivement des FIXME ou des notes expliquant pourquoi ce n'est pas une erreur mais qu'il manque des données. Et puis on ne passe pas sa vie non plus à surveiller Osmose sans arrêt; même juste pour le niveau 1 de gravité tel que la prétendue erreur deux noms qui n'en est souvent pas une mais juste dûe à la présence de certains caractères (et pas seulement un point-virgule mais aussi un simple / quand il y a bien deux noms en deux langues ou qui est le nom officiel d'une enseigne commerciale, ou un + qui fait partie du nom tel que les P+R ... pour les noms de nombreux parkings en France, Allemagne, Suisse; Belgique...). Osmose applique juste une heuristique pour signaler ce qui est souvent une erreur mais pas toujours (et même si on signale comme faux positif, cela revient plus tard à la première modification sui suit de l'objet signalé car Osmose ne garde les faux positifs QUE pour la version qui a été signalée mais pas les suivantes). Voyez Osmose comme un assistant utile mais heureusement il ne donne pas des ordres sinon il ferait lui-même les modifs automatiques par un bot et n'aurait pas besoin de les lister pour un contrôle humain (même pour les prétendue fautes d'orthographes qui n'en sont pas toujours avec des fausses homonymies ou homophonies). Ce que fait Osmose c'est juste poser des questions, il n'y répond pas même s'il **suggère** des corrections possibles. Le 20 janvier 2015 14:08, Art Penteur art.pent...@gmail.com a écrit : Oui, pour l'instant je n'ai fait que quelques signalements, sans l'aide d'un programme. Je n'ai eu que des retours courtois, et les bureaux concernés sont corrigés. C'est peut-être aussi bien de rester entre humains, après tout. Et il n'y a a que ceux qui ne font rien qui n'ont pas d'erreur à corriger ! (dixit Art Penteur à qui Osmose associe 6258 erreurs !) Art. Le 20 janvier 2015 09:53, Yves Pratter yves.prat...@gmail.com a écrit : Le 19 janv. 2015 à 21:41, Art Penteur art.pent...@gmail.com a écrit : Personnellement, je suis pour [les éditions (semi) automatiques]. itou .Certaines erreurs
Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
Franchement; si des communes entières sont des IRIS, pas la peine d'ajouter une relation supplémentaire, il suffira juste de les marquer avec un tag supplémentaire tel que statistical=FR:IRIS. On ne créera alors des relations QUE pour les IRIS infracommunaux (dans les communes de plus de 5000 habitants à la date où l'INSEE les a définis initialement pour une année légale ou l'année suivante le temps pour l'INSEE de faire l'étude) de type boundary=statistical avec aussi le même tag précédent. Le 20 janvier 2015 17:21, Marc SIBERT m...@sibert.fr a écrit : Bonjour, Il faudrait aussi se limiter à un modèle contour/surface pour simplifier la création et l'usage (si c'est possible en même temps) et sans ajouter trop de surcharge à la carte (les relations pour ça c'est bien, mais plus difficile à maintenir il est vrai). Il faut voir qu'une majorité des IRIS correspondent aux communes et qu'il est facile de copier les relations administratives existantes pour en faire des surfaces census. A+ Marc Sibert m...@sibert.fr Le 20 janvier 2015 14:51, Vincent de Château-Thierry osm.v...@free.fr a écrit : Bonjour, L'APUR libère des données qui sont parfois évoquées ici, souvent pour regretter leur caractère non libre, car s'appuyant sur des géométries de l'IGN. Il s'agit des les limites statistiques infracommunales Îlots et IRIS : http://www.apur.org/article/donnees-disponibles-open-data Les données Îlot ne sont pas (au moins en diffusion INSEE) promises à grand avenir : http://www.insee.fr/fr/methodes/default.asp?page=definitions/ilot.htm donc les intégrer dans OSM se discute. Proposer en revanche un fond IRIS [1] national et libre aurait de l'allure, et des consommateurs. Les données de l'APUR sont un matériau pertinent, sur Paris et petite couronne, pour alimenter cette démarche. Il faudrait à cette occasion établir un schéma de tags, à base de boundary=census ou boundary=statistical, non documentés pour l'instant. vincent [1] : http://www.insee.fr/fr/methodes/default.asp?page=definitions/iris.htm ___ 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] Zonages statistiques Ilots et IRIS
C'est pas terminé uniquement parce qu'il manque de monde pour le faire (et les cas compliqués, ceux des communes découpées) sont en voie d'achèvement et certaines régions sont déjà complètes. Il y a toutes les données nécessaires sur la page wiki qui mentionne les arrêtés. De nombreux cantons peuvent être ajoutés uniquement à partir de la liste de communes entières. Il y a deux ans un bot l'avait fait déjà pour tous les cantons ancienne génération ne comprenant aucune commune découpée (et dont les communes étaient entièrement tracées, ce qui n'était pas encore le cas de communes en Basse-Normandie ou en Corse et quelques espaces ruraux négligés par les contributeurs). Note: les cantons actuels devraient être gardés quelques temps encore même après mars. Il y a encore trop de références à ceux-ci dans les textes légaux. Il faudra juste changer leurs tags actuels en: disused:boundary=political disused:political_division=canton et leur ajouter end_date=2015-02 (ceci peut être fait par bot; même maintenant) Avant d'enlever le préfixe planned: en mars pour les actuels planned;boundary=* planned;political_division=* Note: planned:ref=* restera encore jusqu'à ce que l'INSEE codifie réellement l'année prochaine. Le 20 janvier 2015 17:24, Damouns damo...@gmail.com a écrit : Quand je vois que les nouveaux cantons ne sont pas encore tous saisis je crains un peu que cette nouvelle idée ne soit jamais terminée... Mais c'est effectivement une couche qui serait utile. Le 20 janvier 2015 17:21, Marc SIBERT m...@sibert.fr a écrit : Bonjour, Il faudrait aussi se limiter à un modèle contour/surface pour simplifier la création et l'usage (si c'est possible en même temps) et sans ajouter trop de surcharge à la carte (les relations pour ça c'est bien, mais plus difficile à maintenir il est vrai). Il faut voir qu'une majorité des IRIS correspondent aux communes et qu'il est facile de copier les relations administratives existantes pour en faire des surfaces census. A+ Marc Sibert m...@sibert.fr Le 20 janvier 2015 14:51, Vincent de Château-Thierry osm.v...@free.fr a écrit : Bonjour, L'APUR libère des données qui sont parfois évoquées ici, souvent pour regretter leur caractère non libre, car s'appuyant sur des géométries de l'IGN. Il s'agit des les limites statistiques infracommunales Îlots et IRIS : http://www.apur.org/article/donnees-disponibles-open-data Les données Îlot ne sont pas (au moins en diffusion INSEE) promises à grand avenir : http://www.insee.fr/fr/methodes/default.asp?page=definitions/ilot.htm donc les intégrer dans OSM se discute. Proposer en revanche un fond IRIS [1] national et libre aurait de l'allure, et des consommateurs. Les données de l'APUR sont un matériau pertinent, sur Paris et petite couronne, pour alimenter cette démarche. Il faudrait à cette occasion établir un schéma de tags, à base de boundary=census ou boundary=statistical, non documentés pour l'instant. vincent [1] : http://www.insee.fr/fr/methodes/default.asp?page=definitions/iris.htm ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
Ça dépend de la complexité de ce découpage. Les ways superposés sur de nombreuses rues sont de toute façon cassés aussi par les modifs sur les rues, d'autant plus facilement et rendent souvent même la modif des rues compliquées. Note: la prévision de tracé des rues est importante, mais pas celles des cantons qui se contentent juste de séparer les zones habitées/ Il est rare qu'une rue même soit réaménagée de sorte que le canton soit légalement modifié. Prenons l'exemple d'un carrefour réaménagé en rond-point: la modif consiste souvent à tracer un cercle; découper les rues qui avant se croisaient, puis virer les segments. L'auteur va accepter le changement des relations cantonales ou des circonscriptions mais omet de retracer un segment de jonction gardant l'intégrité des cantons ou circonscription. Normalement il n'aurait pas du supprimer ces chemins et leurs noeuds mais ils ne font tout de même et ce n'est pas parce qu'il y avait deux ways superposés que ça les arrête ! Bref les ways superposés sont une plaie ils compliquent encore plus la tache pour ceux qui veulent modifier autour. Il est difficile de sélectionner le bon chemin surtout quand on doit faire des sélections multiples. Astuce : pour les sélections multiples dans JOSM, je m'en sors parfois en créant une relation **temporaire** pour accumuler des objets et permettre de travailler sur la liste. Cette relation n'est pas toujours enregistrée (le dialogue de création reste ouvert, mais à la fin quand je n'ai plus besoin de cette liste, j'annule sans enregistrer) ou bien il sera supprimé avant l'envoi; mais dans ce cas si l'objet est validé localement, ou en cas de besoin d'un envoi intermédiaire, je met dessus un tag explicite repérable comme type=!DELETEME qui, grâce au point d'exclamation en premier caractère, sera affichée en tête de la liste des relations, pour la trouver facilement en cas d'oubli; le dialogue d'envoi des données devrait afficher cette relation tout en haut, il peut arriver qu'on ait besoin aussi de tels objets le temps de résoudre une série de conflits d'édition pour y accumuler des objets dépendants restant à vérifier; ce genre de relation temporaire peut aussi être utile quand on manque de mémoire pour charger tous les objets dépendants et travailler de façon incrémentale, ils signaleront aux autres qu'il y a un travail en cours). Je préfère indiquer explicitement qu'une rue est aussi une frontière politique, pour que les modificateurs s'en aperçoivent avant de virer des chemins ou leurs nœuds. Ces tags mettent des alertes qui leur évite d'oublier de regarder les autres relations (l'omission est beaucoup trop facile par les auteurs utilisant iD, qui en plus ne sait pas conserver l'ordre de succession des éléments, il supprime mais n'ajoute qu'en fin de liste des membres, il ne gère pas du tout leur ordre relatif; même si cet ordre n'est à priori pas significatif pour les boundary, mais très utile pourtant pour réparer et trouver les trous) Le 20 janvier 2015 19:28, Jérôme Amagat jerome.ama...@gmail.com a écrit : Pas grand chose à voir avec ces nouvelles données en particulier mais avec les relations boundary : Quelles way mettre dans ces relations? Je sais pas si il y a une bonne façon de faire. Moi je préfère (j'ai ajouter des nouveaux cantons) utiliser les way qui sont déjà des boundary (limite des anciens cantons et des communes surtout) et créer des way boundary=political pour tout le reste. ces way utilise beaucoup les node des way highway mais je ne mets pas ces way highway dans la relation. Je pense que comme ça il y a moins de chance de casser la relation dans le futur (surtout en supprimant,coupant ou fusionnant des highway) et c'est plus facile à maintenir et à comprendre pour les autres contributeurs (beaucoup moins de way dans la relation) et on mélange moins des choses qui n'ont pas grand chose a voir (frontière et route). Pour ce qui est de ces données, pas vraiment d'avis (ça n'a plus l'air de servir a grand chose?). Mais si vous voulez tracer des frontières il reste un peu moins de 1000 cantons a ajouter dont environ 250 avec une frontière à tracer à l’intérieur d'une commune. ___ 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] Zonages statistiques Ilots et IRIS
Pas grand chose à voir avec ces nouvelles données en particulier mais avec les relations boundary : Quelles way mettre dans ces relations? Je sais pas si il y a une bonne façon de faire. Moi je préfère (j'ai ajouter des nouveaux cantons) utiliser les way qui sont déjà des boundary (limite des anciens cantons et des communes surtout) et créer des way boundary=political pour tout le reste. ces way utilise beaucoup les node des way highway mais je ne mets pas ces way highway dans la relation. Je pense que comme ça il y a moins de chance de casser la relation dans le futur (surtout en supprimant,coupant ou fusionnant des highway) et c'est plus facile à maintenir et à comprendre pour les autres contributeurs (beaucoup moins de way dans la relation) et on mélange moins des choses qui n'ont pas grand chose a voir (frontière et route). Pour ce qui est de ces données, pas vraiment d'avis (ça n'a plus l'air de servir a grand chose?). Mais si vous voulez tracer des frontières il reste un peu moins de 1000 cantons a ajouter dont environ 250 avec une frontière à tracer à l’intérieur d'une commune. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Voie centrale banalisée et voies pour cyclistes
Bonsoir, Saint-Lô va prochainement innover en transformant 3 de ses rues en voies banalisées (1 couloir central pour les voitures, pouvant circuler dans les 2 sens) et 1 voie cyclable de chaque coté (cf.cet article pour en savoir plus : http://www.ouest-france.fr/voies-centrales-banalisees-cest-un-test-3123192) Pourriez-vous me confirmer que pour tagguer ces rues, il suffira de faire comme suit : * highway=residential * name=XXX * lanes=1 (les voies cyclables doivent être exclues du compte) * cycleway=lane -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
Quand je vois que les nouveaux cantons ne sont pas encore tous saisis je crains un peu que cette nouvelle idée ne soit jamais terminée... Mais c'est effectivement une couche qui serait utile. Le 20 janvier 2015 17:21, Marc SIBERT m...@sibert.fr a écrit : Bonjour, Il faudrait aussi se limiter à un modèle contour/surface pour simplifier la création et l'usage (si c'est possible en même temps) et sans ajouter trop de surcharge à la carte (les relations pour ça c'est bien, mais plus difficile à maintenir il est vrai). Il faut voir qu'une majorité des IRIS correspondent aux communes et qu'il est facile de copier les relations administratives existantes pour en faire des surfaces census. A+ Marc Sibert m...@sibert.fr Le 20 janvier 2015 14:51, Vincent de Château-Thierry osm.v...@free.fr a écrit : Bonjour, L'APUR libère des données qui sont parfois évoquées ici, souvent pour regretter leur caractère non libre, car s'appuyant sur des géométries de l'IGN. Il s'agit des les limites statistiques infracommunales Îlots et IRIS : http://www.apur.org/article/donnees-disponibles-open-data Les données Îlot ne sont pas (au moins en diffusion INSEE) promises à grand avenir : http://www.insee.fr/fr/methodes/default.asp?page=definitions/ilot.htm donc les intégrer dans OSM se discute. Proposer en revanche un fond IRIS [1] national et libre aurait de l'allure, et des consommateurs. Les données de l'APUR sont un matériau pertinent, sur Paris et petite couronne, pour alimenter cette démarche. Il faudrait à cette occasion établir un schéma de tags, à base de boundary=census ou boundary=statistical, non documentés pour l'instant. vincent [1] : http://www.insee.fr/fr/methodes/default.asp?page=definitions/iris.htm ___ 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] Zonages statistiques Ilots et IRIS
On est d'accord... Les superpositions de ways c'est juste pour des petits objets de nature similaire, susceptibles d'être modifiés facilement et localement (par exemple deux bâtiments accolés avec une géométrie relativement simple; mais pas non plus tout un château; d'autant plus que les batiments compelxes nécessitent déjà des multipolygones pour les enclaves et les diverses surfaces incluses). Dès qu'on dépasse les 20 mètres de rayon, on a déjà des problèmes de sélection on a vite des objets à tracer dedans. Lavantage de multipolygones est de rendre les objets facilement éditables localement et il est plus facile de les enrichir en détails locaux. Certes pour les débutants c'est déroutant de travailler sur les multipolygnes mais les débutants sont tout autant déroutés sur le fait de travailler sur des objets de toute façon déjà complexes par eux-mêmes; et sont encore plus déroutés par les moyens de sélectionner des objets quand ils sont superposés (et c'est encore plus difficile d'ailleurs dans iD que dans JOSM !) Certes il y a le risque d'un multipolygne soit localement brisé mais justement cette brisure restera locale et plus facile à reconstiter. Mais quand les débutants tombent sur des objets superposés ils ne se rendent pas compte du tout de l'objet qu'il modifient. Les multipolygones il faut s'y faire, d'autant plus qu'OSM (contrairement aux systèmes GIS standards) mélange tout dans sa base sans la gérer en couches indépendantes. Ca s'apprend, mais les débutants commencent d'aord par des modifs sur des objets de petite taille et sans inclusions. Quand ils ont besoin de travailler sur des objets plus gros, ils passent à autre chose qu'iD et apprennent à se servir de JOSM. Le 20 janvier 2015 22:00, Romain MEHUT romain.me...@gmail.com a écrit : Bonsoir, Le 20 janvier 2015 20:02, Philippe Verdy verd...@wanadoo.fr a écrit : Bref les ways superposés sont une plaie ils compliquent encore plus la tache pour ceux qui veulent modifier autour. Il est difficile de sélectionner le bon chemin surtout quand on doit faire des sélections multiples. +1. D'ailleurs j'ai modifié pour cette raison les cantons de Nancy cf. http://www.openstreetmap.org/changeset/28291169 Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
Ah! si OSM permettait de travailler sur une base à couches séparées ou sur plusieurs bases séparées, on pourrait charger une zone avec toutes ses couches, et utiliser le sélecteur de calques ! Et bien des problèmes d'intégration (et même de versionnement) seraient évités. Autrement dit une base OpenGIS standard directement, comme sur les systèmes commerciaux et des administrations. Et pour chaque claque un jeu de tags bien mieux défini et plus cohérent. LEs jeux de données étant plus simples, meˆme les débutants seraient moins intimidés puisque la casse serait immédiatement visible et bien plus facilement repérable et réparable. On éviterait aussi pas mals de conflits d'édition que les débutants ne savent pas du tout gérer correctement (ils abandonnent vite en cours de route et laissent les autres réparer). Plus la base se densifie et moins elle est accessible aux débutants. OSM devient un système pour spécialistes et de plus en plus fermé, dont le nombre de contributeurs se réduit de plus en plus et où tout nouveau jeu de données est de plus en plus difficile à intégrer. LA bonne volonté des débuts ne suffit plus et assez vite on va être confronté à des abandons et au manque de nouveaux contributeurs qui ne comprendront plus rien sur la façon de commencer sur des choses simples. La base pourrait aussi être distribuée (avec des serveurs séparés pour des jeux de couches différentes ou des versions historisées, datées, vérifiées, validées et stabilisées sans aucune casse ultérieure). Les performances des serveurs seraient aussi bien meilleures. Tôt ou tard on y viendra: la base changera de format et on va devoir la migrer vers un système plus accessible et plus stable (et plus facile aussi à rescaler vers des jeux de données et usages plus nombreux). Il est tout à fait possible même d'avoir une interface de requêtes permettant d'interroger un nombre indéfini de bases de données, lesquelles retourneront des jeux de calques séparés répondant à la requête. D'ailleurs le W3C prépare un système d''interopéraiblité permettant d'interconnecter des bases multiples; gérées séparément et sans nécessiter de travail de préparation/fusion (une grosse perte de temps gaspillée dans OSM). Le 20 janvier 2015 22:13, Vincent de Château-Thierry v...@laposte.net a écrit : Le 20/01/2015 18:22, Marc SIBERT a écrit : Ça va quand même être difficile de faire ça sans rien ajouter dans OSM. Certaines limites n'existent simplement pas dans la zone où je regarde (ma commune). J'ai précisément une limite qui semble être la voie ferrée et comme les rails sont multiples, je serais tenté de placer une limite boundary filaire pour clore ma surface constituée jusque là de boundary=admin et de highway. Mais la question vaut d'être posée ! Dans OSM, ou pas ? En effet, quel peut être l'intérêt d'un zonage (un de plus !) directement dans OSM ? Petit préambule : il existe un produit, commercialisé par l'IGN, qui détaille les contours d'IRIS avec une précision géométrique semblable à celle qu'on manipule dans OSM. Je vous laisse voir les tarifs de 2012 p10 de ce doc : http://professionnels.ign.fr/sites/default/files/Bar%C3% A8me%20des%20licences%20d%27utilisation%20des%20produits%202012.pdf Un autre produit est proposé par ESRI France : http://esrifrance.fr/iso_album/DP_FranceIRIS_V1.1.pdf Ces mentions pour indiquer que le contenu IRIS est suffisamment utilisé pour disposer d'un marché. Je parlais volontairement de consommateurs au début de ce fil. À partir de là, proposer des contours IRIS issus d'OSM, c'est potentiellement répondre à un besoin. La problématique ici n'est pas différente des autres thématiques de la base, comme par exemple les limites communales : https://www.data.gouv.fr/fr/datasets/decoupage-administratif-communal- francais-issu-d-openstreetmap/ Par nature, les limites d'IRIS s'appuient sur des éléments physiques : cours d'eau, axes de voirie, voies ferrées. Proposer une couche intégrée dans OSM, c'est offrir un jeu de données cohérent, en terme de géométrie. Si les IRIS sont libérés prochainement, ça facilitera le travail d'intégration, mais ne changera pas la plus-value de cohérence géométrique liée à une intégration dans OSM. À l'inverse, oui bien sûr, ça constitue une couche de relations supplémentaire, qui plus est en milieu urbain, dense en informations. On n'échappera pas à de la casse de relations de temps en temps. C'est le lot (quotidien) pour les limites communales. Mais, comme pour ces dernières, s'il y a un besoin, et des consommateurs, il y aura toujours de la motivation pour assurer la maintenance, j'en suis convaincu. 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] Zonages statistiques Ilots et IRIS
Le 20 janvier 2015 22:00, Romain MEHUT romain.me...@gmail.com a écrit : Bonsoir, Le 20 janvier 2015 20:02, Philippe Verdy verd...@wanadoo.fr a écrit : Bref les ways superposés sont une plaie ils compliquent encore plus la tache pour ceux qui veulent modifier autour. Il est difficile de sélectionner le bon chemin surtout quand on doit faire des sélections multiples. +1. D'ailleurs j'ai modifié pour cette raison les cantons de Nancy cf. http://www.openstreetmap.org/changeset/28291169 Romain Je suis d'accord pour les selections multiples, les ways superposer les complique mais pour des sélections simple c'est pas très compliqué. Exemple pour le Canton Nancy-1: Avant,(c'est moi qui ai créé la relation), 3 ways : 1 way qui est une partie de la frontière de la commune et 2 ways créé pour les cantons de Nancy (1 sert aussi pour nancy 2 et l'autre pour nancy 3) Après, 72 ways : toutes les parties superposées avec des highways ont été remplacé par des highways. pour cela il a surement fallu coupé des highway et des rond point pour avoir que le morceau voulu. il reste quand même 9 ways de 2 ou 3 nœuds boundary=political pour faire la jonction entre des highway. ça fait 72 way pour 13.7 km (71 pour 9.3 km si on enlève le way frontière de commune.) Donc pour moi, ça veut dire qu'on à compliqué les highway avec de nouvelles découpes (il n'y a pas déjà assez de tag donnant de bonnes raisons de le faire), la relation est beaucoup plus compliquer (avant : beaucoup moins d’élément et que des boundary) donc plus de chance d’être détruite. En échange, c'est plus facile de faire des sélections multiples. Ici c'est pou un canton, ou la frontière est plus ou moins lié a la rue, mais pour des frontières de communes, ça veut dire que si on déplace la rue, le chemin ou la rivière la frontière est déplacer aussi. Moi, pour les landuse après m'y être déjà frotter, je ne touche plus au landuse qui on été modifié pour ne plus avoir de way superposé, trop compliqué. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
Le 20/01/2015 18:22, Marc SIBERT a écrit : Ça va quand même être difficile de faire ça sans rien ajouter dans OSM. Certaines limites n'existent simplement pas dans la zone où je regarde (ma commune). J'ai précisément une limite qui semble être la voie ferrée et comme les rails sont multiples, je serais tenté de placer une limite boundary filaire pour clore ma surface constituée jusque là de boundary=admin et de highway. Mais la question vaut d'être posée ! Dans OSM, ou pas ? En effet, quel peut être l'intérêt d'un zonage (un de plus !) directement dans OSM ? Petit préambule : il existe un produit, commercialisé par l'IGN, qui détaille les contours d'IRIS avec une précision géométrique semblable à celle qu'on manipule dans OSM. Je vous laisse voir les tarifs de 2012 p10 de ce doc : http://professionnels.ign.fr/sites/default/files/Bar%C3%A8me%20des%20licences%20d%27utilisation%20des%20produits%202012.pdf Un autre produit est proposé par ESRI France : http://esrifrance.fr/iso_album/DP_FranceIRIS_V1.1.pdf Ces mentions pour indiquer que le contenu IRIS est suffisamment utilisé pour disposer d'un marché. Je parlais volontairement de consommateurs au début de ce fil. À partir de là, proposer des contours IRIS issus d'OSM, c'est potentiellement répondre à un besoin. La problématique ici n'est pas différente des autres thématiques de la base, comme par exemple les limites communales : https://www.data.gouv.fr/fr/datasets/decoupage-administratif-communal-francais-issu-d-openstreetmap/ Par nature, les limites d'IRIS s'appuient sur des éléments physiques : cours d'eau, axes de voirie, voies ferrées. Proposer une couche intégrée dans OSM, c'est offrir un jeu de données cohérent, en terme de géométrie. Si les IRIS sont libérés prochainement, ça facilitera le travail d'intégration, mais ne changera pas la plus-value de cohérence géométrique liée à une intégration dans OSM. À l'inverse, oui bien sûr, ça constitue une couche de relations supplémentaire, qui plus est en milieu urbain, dense en informations. On n'échappera pas à de la casse de relations de temps en temps. C'est le lot (quotidien) pour les limites communales. Mais, comme pour ces dernières, s'il y a un besoin, et des consommateurs, il y aura toujours de la motivation pour assurer la maintenance, j'en suis convaincu. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
Bonsoir, Le 20 janvier 2015 20:02, Philippe Verdy verd...@wanadoo.fr a écrit : Bref les ways superposés sont une plaie ils compliquent encore plus la tache pour ceux qui veulent modifier autour. Il est difficile de sélectionner le bon chemin surtout quand on doit faire des sélections multiples. +1. D'ailleurs j'ai modifié pour cette raison les cantons de Nancy cf. http://www.openstreetmap.org/changeset/28291169 Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
Tu oublies de dire quelle valeur tu as utilisée pour boundary=* si ce n'est pas administrative (statistical?), ou s'il y a cohérence avec d'autres entités comparables et quel autre tag indique le type de subdivision statistique. Tu n'indiques pas non plus dans quelle ville tu l'as fait. J'espère au moins que tu ne les as pas juste taguées en admin_level=10 ou autre valeur puisque ce ne sont pas non plus des quartiers à proprement parler : Ces entités obéissent aussi en taille minimale à des règles légales de secret statistique, l'INSEE pouvant aussi regrouper plusieurs IRIS ensemble pour certaines données dont l'anonymat doit être préservé, comme il le fait depuis longtemps pour des données comparables carroyées: ces îlots géographiques peuvent dont changer à tout moment d'une année à l'autre voire plusieurs fois selon les jeux de données statistiques, et ne correspondent à aucune entité administrative légale (laquelle est stable et rendue publique par lois, décrets ou arrêtés publiés dans un des journaux officiels, ce qui n'est pas le cas des IRIS dont l'INSEE se sert uniquement comme outil pour ses études pas toutes publiques non plus) ! Le 20 janvier 2015 21:35, Christian Quest cqu...@openstreetmap.fr a écrit : J'ai modélisé les IRIS sur ma commune depuis pas mal de temps... c'est une frontière comme une autre (type=boundary) mais pas administrative. Mon petit doigt me dit qu'en principe les nouveaux IRIS devraient arriver en opendata dans un avenir proche... sans avoir vu à quoi ce jeu de données pourrait ressembler. -- 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] Zonages statistiques Ilots et IRIS
Le 21 janvier 2015 01:12, Jérôme Amagat jerome.ama...@gmail.com a écrit : Je suis d'accord pour les selections multiples, les ways superposer les complique mais pour des sélections simple c'est pas très compliqué. Exemple pour le Canton Nancy-1: Avant,(c'est moi qui ai créé la relation), 3 ways : 1 way qui est une partie de la frontière de la commune et 2 ways créé pour les cantons de Nancy (1 sert aussi pour nancy 2 et l'autre pour nancy 3) Après, 72 ways : toutes les parties superposées avec des highways ont été remplacé par des highways. pour cela il a surement fallu coupé des highway et des rond point pour avoir que le morceau voulu. il reste quand même 9 ways de 2 ou 3 noeuds boundary=political pour faire la jonction entre des highway. ça fait 72 way pour 13.7 km (71 pour 9.3 km si on enlève le way frontière de commune.) Donc pour moi, ça veut dire qu'on à compliqué les highway avec de nouvelles découpes (il n'y a pas déjà assez de tag donnant de bonnes raisons de le faire), la relation est beaucoup plus compliquer (avant : beaucoup moins d'élément et que des boundary) donc plus de chance d'être détruite. En échange, c'est plus facile de faire des sélections multiples. Ici c'est pou un canton, ou la frontière est plus ou moins lié a la rue, mais pour des frontières de communes, ça veut dire que si on déplace la rue, le chemin ou la rivière la frontière est déplacer aussi. Moi, pour les landuse après m'y être déjà frotter, je ne touche plus au landuse qui on été modifié pour ne plus avoir de way superposé, trop compliqué. Il y a des cas où les limites sont portées par le même élément (limite de quartier, limite des IRIS, canton électoral, etc) et des cas où les limites sont certes proches, mais réellement distinctes (cas typique des limites administratives). Dans le premier cas, il me semble préférable et souhaitable d'utiliser le filaire existant pour définir le multipolygone, et dans le second il faut avoir des filaires séparés pour qu'un changement de géométrie n'impacte pas la limite. Si l'on traçait des géométries distinctes pour chaque limite on aurait un plat de nouille ingérable (cas fréquent de nombreuses limites passant au même endroit) et il faut préférer autant que possible la réutilisation du filaire. Le risque c'est d'avoir des multipolygones cassés, mais on peut avoir des outils pour les détecter automatiquement et améliorer leur maintenance. J'ai d'ailleurs l'impression qu'on en a moins (ou alors les réparateurs sont super efficaces). -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Voie centrale banalisée et voies pour cyclistes
Le 20/01/2015 19:53, Francescu GAROBY a écrit : Bonsoir, Saint-Lô va prochainement innover en transformant 3 de ses rues en voies banalisées (1 couloir central pour les voitures, pouvant circuler dans les 2 sens) et 1 voie cyclable de chaque coté (cf.cet article pour en savoir plus : http://www.ouest-france.fr/voies-centrales-banalisees-cest-un-test-3123192) Pourriez-vous me confirmer que pour tagguer ces rues, il suffira de faire comme suit : * highway=residential * name=XXX * lanes=1 (les voies cyclables doivent être exclues du compte) * cycleway=lane C'est pas plutôt pensé comme une voie douce avec une tolérance de la circulation des motorisés ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
J'ai modélisé les IRIS sur ma commune depuis pas mal de temps... c'est une frontière comme une autre (type=boundary) mais pas administrative. Mon petit doigt me dit qu'en principe les nouveaux IRIS devraient arriver en opendata dans un avenir proche... sans avoir vu à quoi ce jeu de données pourrait ressembler. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Voie centrale banalisée et voies pour cyclistes
La voie centrale est donc en circulation alternée, avec sans doute des priorités de sens, et des îlots d'attente pour les croisements. De nombreuses rues en ville sont maintenant comme ça un peu partout en France dans les zones résidentielles, et la vitesse y est limitée à 30, avec souvent des ralentisseurs (dos d'âne, coussins) ou des slaloms imposés par des places de stationnement qui changent de côté tous les 50 mètres; même pas toujours protégés par des ilots surélevés (seulement le marquage au sol). On en a même dans des rues où circulent les bus du réseau public (et d'autres véhicules longs autorisés) qui sont prioritaires quel que soit le sens car ils ne peuvent pas utiliser ces petits ilôts de croisement en dégageant la voie pour l'autre sens. Mais les cyclistes sont prioritaires sur les autres; même sur les bus: ils se croisent sans problème sur le même voie et se dégagent des points de croisement vite et facilement. La limite à 30 est nécessaire aussi car on est parfois obligé de faire une marche arrière pour rejoindre l’îlot de croisement face à un bus ou à une trop longue file de voitures qui ne peuvent pas reculer. Le 20 janvier 2015 19:53, Francescu GAROBY f.gar...@gmail.com a écrit : Bonsoir, Saint-Lô va prochainement innover en transformant 3 de ses rues en voies banalisées (1 couloir central pour les voitures, pouvant circuler dans les 2 sens) et 1 voie cyclable de chaque coté (cf.cet article pour en savoir plus : http://www.ouest-france.fr/voies-centrales-banalisees-cest-un-test-3123192 ) Pourriez-vous me confirmer que pour tagguer ces rues, il suffira de faire comme suit : * highway=residential * name=XXX * lanes=1 (les voies cyclables doivent être exclues du compte) * cycleway=lane -- Cordialement, Francescu GAROBY ___ 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] Voie centrale banalisée et voies pour cyclistes
Bonjour, cette page devrait t'aider : http://wiki.openstreetmap.org/wiki/Bicycle À part un oneway=No explicite couplé à un lane=1, il n'y a pas de particularité il le semble. Le 20 janv. 2015 19:54, Francescu GAROBY f.gar...@gmail.com a écrit : Bonsoir, Saint-Lô va prochainement innover en transformant 3 de ses rues en voies banalisées (1 couloir central pour les voitures, pouvant circuler dans les 2 sens) et 1 voie cyclable de chaque coté (cf.cet article pour en savoir plus : http://www.ouest-france.fr/voies-centrales-banalisees-cest-un-test-3123192 ) Pourriez-vous me confirmer que pour tagguer ces rues, il suffira de faire comme suit : * highway=residential * name=XXX * lanes=1 (les voies cyclables doivent être exclues du compte) * cycleway=lane -- Cordialement, Francescu GAROBY ___ 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
