Re: [OSM-talk-fr] Voeux pour 2013...
Peut être qu'il serait envisageable d'effectuer une grossière traduction automatique d'un certains nombre de page en français en indiquant en haut de page que le contenu et la formulation des pages est à améliorer ? Cela permettrait aux lecteurs réguliers d'une ou plusieurs page de faire de petite retouches au lieu de tout recréer. Il est probable que les nouveaux serait moins dérouté et peut être plus enclin à mettre à jour une documentation où la structure serait déjà en place. Dans la même logique, un débutant sur JOSM trouvant l'édition trop complexe pourrait considérer que peaufiner le contenu francophone serait moins déroutant. C'est une idée à creuser mais ça me semble un grand pas en avant. Le 3 janvier 2013 01:25, Pierre Béland infosbelas-...@yahoo.fr a écrit : Jo, Je suis d'accord que la documentation est un vrai casse-tête. Et ce est encore plus vrai pour les non anglophones qui doivent doublement chercher pour retrouver l'info pertinente en français. Déjà à partir de la page principale, même si notre langue préférée est le français, les hyperliens nous amènent d'abord vers des pages en anglais. Espérons que l'on continuera à faire des progrès de ce côté-là. Pierre -- *De :* Jo. perche...@gmail.com *À :* Discussions sur OSM en français talk-fr@openstreetmap.org *Envoyé le :* Mercredi 2 janvier 2013 18h41 *Objet :* Re: [OSM-talk-fr] Voeux pour 2013... Je me souvient avoir découvert OSM il y a presque un an j'avais fuit devant le manque d'information rapidement compréhensible pour un curieux de passage. Depuis le site à eu de nouveau contenu plus clair, avec plus d'explication et surtout plus de média (image, vidéo). Avec l'arrivée d'outils pour Android qui arrive eux aussi à maturité j'ai franchi le pas et mis à part le wiki qui est majoritairement en anglais (un vrais casse tête) j'ai réussi à trouver les informations que je recherchait. Les réponses pertinente et rapide du forum m'ont également beaucoup aidé. Cela ne fait pas encore 2 mois que je contribue, voici donc mon avis de débutant : tant que la vitrine francophone évolue dans ce sens (le site), cela aidera les nouveaux venu à franchir le pas. Quelques compte rendu, quelques liens pour ce documenter et surtout quelques applications réelle. J'ai beaucoup aimé la génération de plan de ville, les plan de piste cyclabe ou l'outil Osmose ainsi que OsmStreetBug pour participer avec mon Android. Le 2 janvier 2013 22:47, Romain MEHUT romain.me...@gmail.com a écrit : Bonsoir, Tous mes vœux à tous! Je compte bien, dans la mesure du possible, poursuivre mon investissement dans le projet en 2013... Romain Le 2 janvier 2013 21:31, Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net a écrit : Le mardi 1 janvier 2013 19:24:11 Christian Quest a écrit : C'est la saison des voeux, des bonnes résolutions... Que peut-on souhaiter à OSM et OSM-FR ? Ce qui est sûr que notre projet gagne en maturité chaque année. Cette année 2012 a encore vu d'énormes améliorations dont des contributions toujours croissantes, des outils d'audit et de nouvelles applications. J'ai pu découvrir toujours plus de nouveaux contributeurs, des bons, des curieux, des moins bons, mais globalement une force de frappe qui se renforce, notament en zones rurales. OSM-FR a soufflé sa première bougie et bravo aux ambassadeurs et aux techos de l'association, le site web offre une vitrine attractive et riche pour notre projet ! Voilà, on n'a qu'à se souhaiter effectivement de joyeux « changesets » ! Et surtout une année joyeuse à vous tous ! -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] [forum-osm-fr] Quelqu'un sur Chaumont (52) pour valider corriger ce bintz!
Le message suivant de : ## Bonjour, Un mappeur connaissant bien Chaumont (52) pourrait-il valider ce bintz ! J'ai contacté son auteur, mais pas de réponse. http://www.openstreetmap.org/?lat=48.11011lon=5.13502zoom=17layers=M Il y a des noeuds et chemins dupliqués, des autres non-connectés etc, et pas de correspondance avec l'imagerie disponible. Merci. a été posté sur le forum http://forum.openstreetmap.fr/viewforum.php?f=2 Une réponse par mail sur l'adresse d'expédition n'arrivera nulle part Une réponse à la liste ne sera pas transmise au forum, ce qui n'empêche pas une concertation sur la liste avant de recopier la/les meilleurs réponses sur le forum. Notez qu'il n'est pas necessaire d'avoir un compte sur le forum pour répondre. -- Les questions sur ce robot de transfert forum-liste peuvent être posées à sylvainaletuffe.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modélisation du réseau électrique français
Bonjour Le 02/01/2013 23:38, François Lacombe a écrit : En revanche, rien n'empêche de balayer les compte rendus de réunion d'information publique sur les projets ou les communiqués de presse de RTE pour avoir les tracés des projets souterrains ou de s'appuyer sur l'imagerie aérienne pour connaitre le cheminement des circuits. J'ai eu l'occasion de le faire pour la nouvelle ligne HTA de l'EPR avec la dépose et la mise en souterrain, ainsi que du déplacement de ligne sur le département de la manche, puisque les documents mis en ligne sont ceux que le publique pouvait aller consulter auprès des commissaire des consultations publiques. et donc j'en ai profiter pour amender OSM : http://www.openstreetmap.org/?lat=49.17259lon=-1.33565zoom=15layers=M où l'on peut voir la déviation souterraine singulière d'une ligne aérienne. Mais également http://www.openstreetmap.org/?lat=49.08075lon=-1.26145zoom=15layers=M d'où l'absence de pylône C'est le plus commode pour l'intégrer dans le node/way/relation d'OSM mais ca n’empêche pas l'indétermination topologique. Si dans l'exemple il y avait eu plusieurs circuits du même type à y aboutir, comment savoir qui est connecté avec qui? Il y a des pylônes qui ont plusieurs niveaux d'ancrage sans que les circuits soient connectés entre-eux. https://maps.google.fr/maps?q=lausannehl=enll=46.562426,6.559904spn=0.002068,0.004128sll=45.86462,6.057506sspn=0.002962,0.008256t=hhnear=Lausanne,+Vaud,+Switzerlandz=19layer=ccbll=46.562426,6.559904panoid=bLcu9m2dZc60Zupe4aEnpQcbp=12,129.74,,0,-47.95 En fait ca me semblerai cohérent de faire deux (ou +) ways superposées en cas de double (ou +) circuits. Pour que ca soit manipulable, il faudra adapter la représentation en conséquence : +--+== +===+ (2 circuits superposés) De là à voir si la chaine OSM peut le supporter ou l'adopter facilement... Pour ma part, cela devient très compliqué avec la situation que tu décrits, surtout en édition pour que déjà tout le monde comprennent que les réseaux sont intégrés lors d'une modification. En HTA et en BTB ce peut-être différent, il existe de vieux câbles papier qui supportent les 3 phases (+ neutre en distribution locale). Mais là, un tag power=line + cables=3 ou cables=1 sera suffisant pour donner l'information. Non, il est extremement rare que les 3 phases soient physiquement éloignés l'un de l'autre. Donc je le réseau et non la constitution physique. On ne tague pas toutes les voies de circulation même si elle sont non séparés physiquement mais éloignées l'une de l'autre d'environ 1m50 sans discontinuité du support de roulement dans le sens de la largeur de la voie ? En France, je ne prendrais la peine de cartographier que la HTA et les transfos HTA/BTB vu la capillarité et la facilité d'évolution des réseaux de distribution locaux (ou alors il faut un suivi régulier et pointu). Oui, mais ce sont des éléments géographiques, donc en toute logique peuvent être intégrés dans la base et leur durée de vie (ie l'implantation physique) est pérenne sur moyen voire long terme. -- Cordialement David Crochet http://fr.wikiversity.org : Communauté pédagogique libre à laquelle chacun peut prendre part ! http://www.wikimedia.fr : Aidons la diffusion de la connaissance libre ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Petites bizarreries sur Notre-Dame-des-Landes et Vigneux-de-Bretagne
Vous avez dit bizarre ? Comme c'est ... Bon le principe, pour sortir des landuse de corine qui s'étalent sur des zones trop grandes et de sectoriser en prenant une unité gérable, par exemple la commune. On prend alors l'utilisation majoritaire (le bocage) landuse= meadow qu'on applique à toute la commune (copie de la relation commune mais avec un landuse meadow) Ensuite on découpe ce qui n'est pas du meadow dans la relation principal avec inner et on crée des relation pour le résidentiel, les fermes etc avec le type outer. Un seul chemin (way) pour indiquer la séparation des zones (pas de chevauchement de chemin). L'inconvénient, c'est que pour être cohérent, il faut traiter toutes les zones importantes avec la technique des relations. -- View this message in context: http://gis.19327.n5.nabble.com/Petites-bizarreries-sur-Notre-Dame-des-Landes-et-Vigneux-de-Bretagne-tp5742389p5742414.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Communes nouvelles
Bonjour, comme je l'avais annoncé, je m'occupe des 2 EPCI précédement évoqués (cf. ci-dessous). Juste pour éviter de faire une connerie : on est d'accord que quand une EPCI fusionne avec une autre, la première doit disparaitre de la base d'OSM ? En l'occurrence, c'est la CC Rives-de-l'Odon qui a fusionné avec la CA Caen-la-Mer (ainsi que 3 autres communes, mais qui n'étaient dans aucune EPCI donc pas de pb pour elles), donc je dois supprimer la CC Rives-de-l'Odon. C'est correct ? Francescu Le 17 décembre 2012 11:51, Francescu GAROBY windu...@gmail.com a écrit : Bonjour, Le même jour, plusieurs EPCI vont aussi évoluer : je peux au moins citer Caen-la-Mer (14 - Calvados) et la Communauté Urbaine d'Alençon (61 - Orne). Je compte m'en occuper, mais ce sera plutôt le 2 janvier... afin d'éviter toute erreur due à l'alcool ! ;-) Francescu Le 17 décembre 2012 11:44, Damouns damo...@gmail.com a écrit : Bonjour à tous, Sept arrêtés (et peut-être d'autres à venir, ou que je n'ai pas vus) ont été publiés depuis cet été sur Légifrance pour annoncer la fusion de communes françaises en communes nouvelles. La plupart d'entre eux prennent effet à compter du 1er janvier 2013. Il me semble qu'on peut intégrer ça le jour J dans la base OSM en créant pour chacune une nouvelle relation admin_level=8 suivant les nouveaux contours. Je me pose la question de la conservation des anciennes communes en relations de niveau admin_level=10. Faut-il les garder de cette façon ou non ? En effet celles-ci subsistent normalement sous forme de « communes déléguées » (je m'attends à une réaction argumentée et développée de Philippe Verdy !! Mais les autres peuvent aussi donner leur avis bien sûr ;-) Et j'appelle donc des volontaires pour traiter les communes concernées. Signalez-vous ! Pour faire les modifs le jour J. Les voici par département : == dans le Maine-et-Loire == 1) Fusion des 2 communes de Chemillé et Melay (Maine-et-Loire), en une commune nouvelle appelée Chemillé-Melay, chef-lieu Chemillé. (Référence : Arrêté du 14 septembre 2012) http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT26769873 2) Fusion des 2 communes de Clefs et Vaulandry (Maine-et-Loire), en une commune nouvelle appelée Clefs-Val-d'Anjou, chef-lieu Clefs. (Référence : Arrêté du 19 novembre 2012) http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT26769876 3) Fusion des 5 communes de Baugé, de Montpollin, de Pontigné, de Saint-Martin-d'Arcé et du Vieil-Baugé (Maine-et-Loire), en une commune nouvelle appelée Baugé-en-Anjou, chef-lieu Baugé. (Référence : Arrêté du 30 mars 2012) http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT25990218 == dans les Deux-Sèvres == Fusion des 2 communes de Saint-Clémentin et Voultegon (Deux-Sèvres), en une commune nouvelle appelée Voulmentin, chef-lieu Saint-Clémentin. (Référence : Arrêté du 12 novembre 2012) http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT2106 == dans le Rhône == Fusion des 5 communes de Bourg-de-Thizy, de La Chapelle-de-Mardore, de Mardore, de Marnand et de Thizy (Rhône), en une commune nouvelle appelée Thizy-les-Bourgs, chef-lieu Thizy. (Référence : Arrêté du 29 octobre 2012) http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT26635902 == dans les Hautes-Alpes == 1) Fusion des 3 communes de Bénévent-et-Charbillac, Les Infournas et Saint-Bonnet-en-Champsaur (Hautes-Alpes), en une commune nouvelle appelée Saint-Bonnet-en-Champsaur, chef-lieu Saint-Bonnet-en-Champsaur. (Référence : Arrêté du 9 novembre 2012) http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT26767005 2) Fusion des 4 communes d'Agnières-en-Dévoluy, de La Cluse, de Saint-Etienne-en-Dévoluy et de Saint-Disdier (Hautes-Alpes), en une commune nouvelle appelée Dévoluy, chef-lieu Saint-Etienne-en-Dévoluy. (Référence : Arrêté du 2 octobre 2012) http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT26537090 Damouns PS : on ne sait pas quel ref:INSEE sera attribué, en attendant on peut prendre celui de l'ancienne commune du chef-lieu ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modélisation du réseau électrique français
Bonjour, Le 3 janvier 2013 10:09, David Crochet david.croc...@online.fr a écrit : J'ai eu l'occasion de le faire pour la nouvelle ligne HTA de l'EPR avec la dépose et la mise en souterrain, ainsi que du déplacement de ligne sur le département de la manche, puisque les documents mis en ligne sont ceux que le publique pouvait aller consulter auprès des commissaire des consultations publiques. et donc j'en ai profiter pour amender OSM : http://www.openstreetmap.org/?**lat=49.17259lon=-1.33565** zoom=15layers=Mhttp://www.openstreetmap.org/?lat=49.17259lon=-1.33565zoom=15layers=M où l'on peut voir la déviation souterraine singulière d'une ligne aérienne. Mais également http://www.openstreetmap.org/?**lat=49.08075lon=-1.26145** zoom=15layers=Mhttp://www.openstreetmap.org/?lat=49.08075lon=-1.26145zoom=15layers=M d'où l'absence de pylône Excellent, c'est une affaire qui tourne! Par contre ne vaudrait-il mieux pas utiliser power=line + location=underground que power=line + tunnel=yes? Peut-être ont-ils creusé une galerie visitable pour supporter la section souterraine? Pour ma part, cela devient très compliqué avec la situation que tu décrits, surtout en édition pour que déjà tout le monde comprennent que les réseaux sont intégrés lors d'une modification. Oui je reconnais qu'avoir plusieurs way superposées c'est compliqué à maintenir. Je suis passé à côté de l'aspect relation qui relie n circuits aboutés à un même nœud. La topologie décrite par le wiki me semble maintenant beaucoup plus claire et correcte. Il faudra par contre prendre garde à bien sectionner les ways à chaque pylône présentant des dérivations sans quoi des tronçons qui ne supportent pas le circuit en réalité risquent de se trouver membre des relations malgré eux. Sur la partie représentation, on pourrait représenter ces circuits parallèles en représentant les relations au lieu des ways. Je ne sais pas si c'est quelque chose que mapnik saurait gérer... Non, il est extremement rare que les 3 phases soient physiquement éloignés l'un de l'autre. Donc je le réseau et non la constitution physique. On ne tague pas toutes les voies de circulation même si elle sont non séparés physiquement mais éloignées l'une de l'autre d'environ 1m50 sans discontinuité du support de roulement dans le sens de la largeur de la voie ? Oui je suis bien de cet avis aussi mais ce sont les tag eux-mêmes qui introduisent line et cable comme deux choses différentes. Du coup, si on ne cartographie pas les voies (câbles) mais uniquement les routes (lignes électriques), pourquoi avoir ce tag power=cable qui n'est jamais sensé servir? Oui, mais ce sont des éléments géographiques, donc en toute logique peuvent être intégrés dans la base et leur durée de vie (ie l'implantation physique) est pérenne sur moyen voire long terme. Ok pour l'utilité géographique des lignes BTB aériennes. En ville tout est parfois enterré de plus en plus facilement. Pour avoir une carte fiable et à jour pour ce niveau de tension, qui résiste rarement aux modifications de la voirie, il va falloir suivre tout ça régulièrement. Sur la question du taggage de la HTA vs BTB il y a aussi cette possibilité : HTA : power=minor_line + tension=2 + operator=ERDF... BTB : power=minor_line + tension=400 + operator=ERDF... A bientôt, -- *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modélisation du réseau électrique français
Bonjour Le 03/01/2013 11:00, François Lacombe a écrit : Par contre ne vaudrait-il mieux pas utiliser power=line + location=underground que power=line + tunnel=yes? Peut-être ont-ils creusé une galerie visitable pour supporter la section souterraine? Oui, c'est une erreur de ma part que je n'ai jamais recorrigé. J'avais pris l'habitude du « tunnel » des voies routières que j'ai appliqué sans réfléchir sur les lignes électrique. Il faudra par contre prendre garde à bien sectionner les ways à chaque pylône présentant des dérivations sans quoi des tronçons qui ne supportent pas le circuit en réalité risquent de se trouver membre des relations malgré eux. Est-ce que RTE applique des informations de réseau d'énergie indépendant du réseau physique comme le fait la SCNF qui applique un numéro de ligne (le Paris-Granville) indépendant des voies physique mais liés quand même ? Dans ce cas, pas la peine de simuler la présence de plusieurs réseaux au sein d'un même « chemin » puisque la relation va faire le tri correctement dans ce cas Oui je suis bien de cet avis aussi mais ce sont les tag eux-mêmes qui introduisent line et cable comme deux choses différentes. Du coup, si on ne cartographie pas les voies (câbles) mais uniquement les routes (lignes électriques), pourquoi avoir ce tag power=cable qui n'est jamais sensé servir? Car « power=cable » sous entend implicitement « layer = -1 » ce qui évite par exemple à un logiciel de dire qu'un câble croisent sans connexion une ligne. alors qu'il n'ont pas le layer indiqué En ville tout est parfois enterré de plus en plus facilement. Mais très peu visible sauf les balises au sol indiquant la présence d'un réseau souterrain -- Cordialement David Crochet http://fr.wikiversity.org : Communauté pédagogique libre à laquelle chacun peut prendre part ! http://www.wikimedia.fr : Aidons la diffusion de la connaissance libre ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Communes nouvelles
Bonjour, De : Francescu GAROBY comme je l'avais annoncé, je m'occupe des 2 EPCI précédement évoqués (cf. ci-dessous). Juste pour éviter de faire une connerie : on est d'accord que quand une EPCI fusionne avec une autre, la première doit disparaitre de la base d'OSM ? En l'occurrence, c'est la CC Rives-de-l'Odon qui a fusionné avec la CA Caen-la-Mer (ainsi que 3 autres communes, mais qui n'étaient dans aucune EPCI donc pas de pb pour elles), donc je dois supprimer la CC Rives-de-l'Odon. C'est correct ? Oui, dans le lot, il y a bien une relation à supprimer, et l'autre à modifier / augmenter. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Communes nouvelles
Merci pour la confirmation : c'est bien ce qu'il me semblait, mais je préférais en être sûr. Francescu Le 3 janvier 2013 11:24, Vincent de Chateau-Thierry v...@laposte.net a écrit : Bonjour, De : Francescu GAROBY comme je l'avais annoncé, je m'occupe des 2 EPCI précédement évoqués (cf. ci-dessous). Juste pour éviter de faire une connerie : on est d'accord que quand une EPCI fusionne avec une autre, la première doit disparaitre de la base d'OSM ? En l'occurrence, c'est la CC Rives-de-l'Odon qui a fusionné avec la CA Caen-la-Mer (ainsi que 3 autres communes, mais qui n'étaient dans aucune EPCI donc pas de pb pour elles), donc je dois supprimer la CC Rives-de-l'Odon. C'est correct ? Oui, dans le lot, il y a bien une relation à supprimer, et l'autre à modifier / augmenter. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Communes nouvelles
Et est-ce que l'on peut trouver quelque part les annonces officielles de ces changements au niveau national? Romain Le 3 janvier 2013 11:24, Vincent de Chateau-Thierry v...@laposte.net a écrit : Bonjour, De : Francescu GAROBY comme je l'avais annoncé, je m'occupe des 2 EPCI précédement évoqués (cf. ci-dessous). Juste pour éviter de faire une connerie : on est d'accord que quand une EPCI fusionne avec une autre, la première doit disparaitre de la base d'OSM ? En l'occurrence, c'est la CC Rives-de-l'Odon qui a fusionné avec la CA Caen-la-Mer (ainsi que 3 autres communes, mais qui n'étaient dans aucune EPCI donc pas de pb pour elles), donc je dois supprimer la CC Rives-de-l'Odon. C'est correct ? Oui, dans le lot, il y a bien une relation à supprimer, et l'autre à modifier / augmenter. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Petites bizarreries sur Notre-Dame-des-Landes et Vigneux-de-Bretagne
Ça m'intéresse d'en savoir plus sur le sujet. Dans ma zone j'ai de grande surface de vigne qui était formé par des suite de segments. L'outil de validation indiquait une erreur (surface non fermée). Après avoir effectué la correction, je me suis retrouvé avec une surface de près de 5000 nœud avec l'impossibilité d'envoyer mes modifications (limité à 2000 nœuds). Dans l'urgence j'ai découpé la surface en plusieurs bout en choisissant les cours d'eau et canaux comme délimitation. Pour l'instant il est existe donc un grand multipolygone regroupant les différentes aire externe et interne mais avec mes dernière retouche, je me retrouve de nouveau avec une aire qui est passé de 800 à 2006 nœuds et la zone et il reste de grande zone non définie. Sur des zones aussi grande, est il préférable de tout sectoriser par commune ou plutôt visuellement selon les images aérienne ? Pour information il existe très souvent parcelles de petites à moyenne de terrain en jachère depuis des années, en garrigue ou en bois (sans compter les zones résidentielle et industrielle). Voici le multi-polygone en question : http://www.openstreetmap.org/browse/relation/285855 Vue la taille et l'importance des vignes dans ma région, est il intéressant de le découper par terroir viticole comme indiqué sur Wikipédia ? http://fr.wikipedia.org/wiki/Vignoble_du_Languedoc-Roussillon Il est a remarqué que des portions de vignoble existe mais ne font parti d'aucun terroir. Le 3 janvier 2013 10:52, PhQ pierre.que...@sfr.fr a écrit : Vous avez dit bizarre ? Comme c'est ... Bon le principe, pour sortir des landuse de corine qui s'étalent sur des zones trop grandes et de sectoriser en prenant une unité gérable, par exemple la commune. On prend alors l'utilisation majoritaire (le bocage) landuse= meadow qu'on applique à toute la commune (copie de la relation commune mais avec un landuse meadow) Ensuite on découpe ce qui n'est pas du meadow dans la relation principal avec inner et on crée des relation pour le résidentiel, les fermes etc avec le type outer. Un seul chemin (way) pour indiquer la séparation des zones (pas de chevauchement de chemin). L'inconvénient, c'est que pour être cohérent, il faut traiter toutes les zones importantes avec la technique des relations. -- View this message in context: http://gis.19327.n5.nabble.com/Petites-bizarreries-sur-Notre-Dame-des-Landes-et-Vigneux-de-Bretagne-tp5742389p5742414.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Petites bizarreries sur Notre-Dame-des-Landes et Vigneux-de-Bretagne
C'est très clean en théorie, mais dans la pratique ça me semble un peu fragile. Je ne pense pas que ce soit une bonne idée d'utiliser les même way pour décrire un découpage administratif et une occupation du sol, le premier évoluant peu, le second évoluant bien plus souvent, on risque d'avoir des découpages administratifs modifiées par une édition de landuse... la réparation de nombreux découpages administratifs suite à ce genre de manip par un contributeur qui avait suivit une fausse bonne idée noyée dans un mail de Philippe Verdy me laisse de douloureux souvenir dans le poignet droit. Qui a eu cette idée ? Le 3 janvier 2013 10:52, PhQ pierre.que...@sfr.fr a écrit : Vous avez dit bizarre ? Comme c'est ... Bon le principe, pour sortir des landuse de corine qui s'étalent sur des zones trop grandes et de sectoriser en prenant une unité gérable, par exemple la commune. On prend alors l'utilisation majoritaire (le bocage) landuse= meadow qu'on applique à toute la commune (copie de la relation commune mais avec un landuse meadow) Ensuite on découpe ce qui n'est pas du meadow dans la relation principal avec inner et on crée des relation pour le résidentiel, les fermes etc avec le type outer. Un seul chemin (way) pour indiquer la séparation des zones (pas de chevauchement de chemin). L'inconvénient, c'est que pour être cohérent, il faut traiter toutes les zones importantes avec la technique des relations. -- View this message in context: http://gis.19327.n5.nabble.com/Petites-bizarreries-sur-Notre-Dame-des-Landes-et-Vigneux-de-Bretagne-tp5742389p5742414.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Communes nouvelles
De : Romain MEHUT Et est-ce que l'on peut trouver quelque part les annonces officielles de ces changements au niveau national? Au niveau national, peut-être du côté du JO ? Je dis ça mais je n'en sais rien. Sinon pour rappel, l'INSEE diffuse la liste et la composition des EPCIs dans un fichier téléchargeable ici : http://insee.fr/fr/methodes/default.asp?page=zonages/intercommunalite.htm mais avec un gros bémol : les données ont +/- 1 an de retard, donc impossible d'y trouver aujourd'hui les modifs opérées au 01/01/2013. Sinon Banatic ( http://www.banatic.interieur.gouv.fr/Banatic2/ ) a des mises à jour trimestrielles mais il y a des restrictions sur l'usage des données : http://www.banatic.interieur.gouv.fr/Banatic2/static/ba-Infos-legales.htm qui concrètement empêchent qu'on s'en serve comme source. De mon côté, j'utilise un mix entre les fichiers de l'INSEE (pour le ref:INSEE justement) et les infos trouvées, le plus souvent, sur les sites web des EPCIs (beaucoup en ont) pour valider la liste des communes membres. On trouve aussi des docs sur les sites des préfectures, lorsque des décisions de fusion/adhésion sont prises à ce niveau. Bref, c'est un peu la pêche à droite à gauche... vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Communes nouvelles
Pour Caen-la-mer, c'est un mix entre les annonces (journauxhttp://www.lamanchelibre.fr/actualite-33171-caen-la-mer-change-avec-ses-six-nouvelles-communes.html, ...) et l'arrêté préfectoralhttp://www.calvados.gouv.fr/sections/calvados/les_missions_de_la_p/intercommunalite/projet_de_schema_dep/downloadFile/attachedFile/SDCIAPfusionCaenlamer.pdf?nocache=1326467424.5 . J'avais voulu retrouver tout ça sur le site du Journal Officiel : je sais pas si c'est moi qui m'y prends mal ou quoi, mais j'ai l'impression que le site du JO fait un concours avec celui de legifrance pour être imbitable... Et je suis incapable de vous dire lequel des 2 a gagné ! -_- Francescu Le 3 janvier 2013 11:27, Romain MEHUT romain.me...@gmail.com a écrit : Et est-ce que l'on peut trouver quelque part les annonces officielles de ces changements au niveau national? Romain Le 3 janvier 2013 11:24, Vincent de Chateau-Thierry v...@laposte.net a écrit : Bonjour, De : Francescu GAROBY comme je l'avais annoncé, je m'occupe des 2 EPCI précédement évoqués (cf. ci-dessous). Juste pour éviter de faire une connerie : on est d'accord que quand une EPCI fusionne avec une autre, la première doit disparaitre de la base d'OSM ? En l'occurrence, c'est la CC Rives-de-l'Odon qui a fusionné avec la CA Caen-la-Mer (ainsi que 3 autres communes, mais qui n'étaient dans aucune EPCI donc pas de pb pour elles), donc je dois supprimer la CC Rives-de-l'Odon. C'est correct ? Oui, dans le lot, il y a bien une relation à supprimer, et l'autre à modifier / augmenter. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Données historique et historiques des données...
Je dévie le fil vers une notion d'historique... Il y a une réflexion actuelle sur l'intégration de données historiques dans OSM, une liste dédiée a même été créée (historic). Plutôt que de supprimer ce genre de relation, ne pourrait-on pas en garder au moins une trace ? J'ai une ébauche de commencement de réflexion sur des tags adaptés... où l'on pourrait intégrer un intervalle de temps à un tag à l'aide d'une notation du type [debut:fin], exemple: name[:1970]=Place de l'Etoile name=Place Charles de Gaulle Ce serait intéressant pour des objets toujours existants, mais ayant évolué dans un passé récent. Ces tags à suffixe temporel ne peuvent pas être confondus avec des tags actuels, et permettent de couvrir plusieurs intervalles (ce que ne permet pas old_name). A charge pour ceux qui veulent les exploiter de les traiter selon leur besoin, mais au moins l'info est là et utilisable plutôt que de disparaitre. Qu'en pensez-vous ? Le 3 janvier 2013 11:24, Vincent de Chateau-Thierry v...@laposte.net a écrit : Bonjour, De : Francescu GAROBY comme je l'avais annoncé, je m'occupe des 2 EPCI précédement évoqués (cf. ci-dessous). Juste pour éviter de faire une connerie : on est d'accord que quand une EPCI fusionne avec une autre, la première doit disparaitre de la base d'OSM ? En l'occurrence, c'est la CC Rives-de-l'Odon qui a fusionné avec la CA Caen-la-Mer (ainsi que 3 autres communes, mais qui n'étaient dans aucune EPCI donc pas de pb pour elles), donc je dois supprimer la CC Rives-de-l'Odon. C'est correct ? Oui, dans le lot, il y a bien une relation à supprimer, et l'autre à modifier / augmenter. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Communes nouvelles
Bon, je viens de faire le ménage vers chez moi : la commune de Voulmentin est maintenant dans la base (suppression de la relation boundary pour Voultegon, modification de la relation de Saint-Clémentin, suppression des anciennes limites, vérification des relations boundary de niveau supérieur). J'espère que je n'ai rien cassé. J'ai quand même laissé les nodes place=village des deux anciennes communes. Les panneaux d'indications ne sont en effet pas à jour, on se rend encore à l'une ou à l'autre des communes par des routes différentes... J'attends de voir comment ils vont faire la différence (quartier ?) Cordialement, Mika_Gueret Le lundi 17 décembre 2012 à 11:44 +0100, Damouns a écrit : Bonjour à tous, Sept arrêtés (et peut-être d'autres à venir, ou que je n'ai pas vus) ont été publiés depuis cet été sur Légifrance pour annoncer la fusion de communes françaises en communes nouvelles. La plupart d'entre eux prennent effet à compter du 1er janvier 2013. Il me semble qu'on peut intégrer ça le jour J dans la base OSM en créant pour chacune une nouvelle relation admin_level=8 suivant les nouveaux contours. Je me pose la question de la conservation des anciennes communes en relations de niveau admin_level=10. Faut-il les garder de cette façon ou non ? En effet celles-ci subsistent normalement sous forme de « communes déléguées » (je m'attends à une réaction argumentée et développée de Philippe Verdy !! Mais les autres peuvent aussi donner leur avis bien sûr ;-) Et j'appelle donc des volontaires pour traiter les communes concernées. Signalez-vous ! Pour faire les modifs le jour J. Les voici par département : == dans le Maine-et-Loire == 1) Fusion des 2 communes de Chemillé et Melay (Maine-et-Loire), en une commune nouvelle appelée Chemillé-Melay, chef-lieu Chemillé. (Référence : Arrêté du 14 septembre 2012) http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT26769873 2) Fusion des 2 communes de Clefs et Vaulandry (Maine-et-Loire), en une commune nouvelle appelée Clefs-Val-d'Anjou, chef-lieu Clefs. (Référence : Arrêté du 19 novembre 2012) http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT26769876 3) Fusion des 5 communes de Baugé, de Montpollin, de Pontigné, de Saint-Martin-d'Arcé et du Vieil-Baugé (Maine-et-Loire), en une commune nouvelle appelée Baugé-en-Anjou, chef-lieu Baugé. (Référence : Arrêté du 30 mars 2012) http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT25990218 == dans les Deux-Sèvres == Fusion des 2 communes de Saint-Clémentin et Voultegon (Deux-Sèvres), en une commune nouvelle appelée Voulmentin, chef-lieu Saint-Clémentin. (Référence : Arrêté du 12 novembre 2012) http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT2106 == dans le Rhône == Fusion des 5 communes de Bourg-de-Thizy, de La Chapelle-de-Mardore, de Mardore, de Marnand et de Thizy (Rhône), en une commune nouvelle appelée Thizy-les-Bourgs, chef-lieu Thizy. (Référence : Arrêté du 29 octobre 2012) http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT26635902 == dans les Hautes-Alpes == 1) Fusion des 3 communes de Bénévent-et-Charbillac, Les Infournas et Saint-Bonnet-en-Champsaur (Hautes-Alpes), en une commune nouvelle appelée Saint-Bonnet-en-Champsaur, chef-lieu Saint-Bonnet-en-Champsaur. (Référence : Arrêté du 9 novembre 2012) http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT26767005 2) Fusion des 4 communes d'Agnières-en-Dévoluy, de La Cluse, de Saint-Etienne-en-Dévoluy et de Saint-Disdier (Hautes-Alpes), en une commune nouvelle appelée Dévoluy, chef-lieu Saint-Etienne-en-Dévoluy. (Référence : Arrêté du 2 octobre 2012) http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT26537090 Damouns PS : on ne sait pas quel ref:INSEE sera attribué, en attendant on peut prendre celui de l'ancienne commune du chef-lieu ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Communes nouvelles
Au passage, le cadastre prend en compte cette fusion. Je vous invite à regarder le bordel que ça donne dans le bourg de Voultegon, juste pour ceux qui pensent que le cadastre est la source ultime de données géographiques... ;-) Mika_Gueret Le jeudi 03 janvier 2013 à 12:11 +0100, Mickaël Guéret a écrit : Bon, je viens de faire le ménage vers chez moi : la commune de Voulmentin est maintenant dans la base (suppression de la relation boundary pour Voultegon, modification de la relation de Saint-Clémentin, suppression des anciennes limites, vérification des relations boundary de niveau supérieur). J'espère que je n'ai rien cassé. J'ai quand même laissé les nodes place=village des deux anciennes communes. Les panneaux d'indications ne sont en effet pas à jour, on se rend encore à l'une ou à l'autre des communes par des routes différentes... J'attends de voir comment ils vont faire la différence (quartier ?) Cordialement, Mika_Gueret Le lundi 17 décembre 2012 à 11:44 +0100, Damouns a écrit : Bonjour à tous, Sept arrêtés (et peut-être d'autres à venir, ou que je n'ai pas vus) ont été publiés depuis cet été sur Légifrance pour annoncer la fusion de communes françaises en communes nouvelles. La plupart d'entre eux prennent effet à compter du 1er janvier 2013. Il me semble qu'on peut intégrer ça le jour J dans la base OSM en créant pour chacune une nouvelle relation admin_level=8 suivant les nouveaux contours. Je me pose la question de la conservation des anciennes communes en relations de niveau admin_level=10. Faut-il les garder de cette façon ou non ? En effet celles-ci subsistent normalement sous forme de « communes déléguées » (je m'attends à une réaction argumentée et développée de Philippe Verdy !! Mais les autres peuvent aussi donner leur avis bien sûr ;-) Et j'appelle donc des volontaires pour traiter les communes concernées. Signalez-vous ! Pour faire les modifs le jour J. Les voici par département : == dans le Maine-et-Loire == 1) Fusion des 2 communes de Chemillé et Melay (Maine-et-Loire), en une commune nouvelle appelée Chemillé-Melay, chef-lieu Chemillé. (Référence : Arrêté du 14 septembre 2012) http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT26769873 2) Fusion des 2 communes de Clefs et Vaulandry (Maine-et-Loire), en une commune nouvelle appelée Clefs-Val-d'Anjou, chef-lieu Clefs. (Référence : Arrêté du 19 novembre 2012) http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT26769876 3) Fusion des 5 communes de Baugé, de Montpollin, de Pontigné, de Saint-Martin-d'Arcé et du Vieil-Baugé (Maine-et-Loire), en une commune nouvelle appelée Baugé-en-Anjou, chef-lieu Baugé. (Référence : Arrêté du 30 mars 2012) http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT25990218 == dans les Deux-Sèvres == Fusion des 2 communes de Saint-Clémentin et Voultegon (Deux-Sèvres), en une commune nouvelle appelée Voulmentin, chef-lieu Saint-Clémentin. (Référence : Arrêté du 12 novembre 2012) http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT2106 == dans le Rhône == Fusion des 5 communes de Bourg-de-Thizy, de La Chapelle-de-Mardore, de Mardore, de Marnand et de Thizy (Rhône), en une commune nouvelle appelée Thizy-les-Bourgs, chef-lieu Thizy. (Référence : Arrêté du 29 octobre 2012) http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT26635902 == dans les Hautes-Alpes == 1) Fusion des 3 communes de Bénévent-et-Charbillac, Les Infournas et Saint-Bonnet-en-Champsaur (Hautes-Alpes), en une commune nouvelle appelée Saint-Bonnet-en-Champsaur, chef-lieu Saint-Bonnet-en-Champsaur. (Référence : Arrêté du 9 novembre 2012) http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT26767005 2) Fusion des 4 communes d'Agnières-en-Dévoluy, de La Cluse, de Saint-Etienne-en-Dévoluy et de Saint-Disdier (Hautes-Alpes), en une commune nouvelle appelée Dévoluy, chef-lieu Saint-Etienne-en-Dévoluy. (Référence : Arrêté du 2 octobre 2012) http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT26537090 Damouns PS : on ne sait pas quel ref:INSEE sera attribué, en attendant on peut prendre celui de l'ancienne commune du chef-lieu ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Données historique et historiques des données...
Le 3 janvier 2013 11:50, Christian Quest cqu...@openstreetmap.fr a écrit : Qu'en pensez-vous ? Je subodore que le problème sera la source, ou la référence, de la donnée. La référence actuelle que j'ai comprise de osm est le terrain : c'est ce que l'on voit. Il y a déjà quelques exceptions, qui me semble qui mériteraient d'être mieux comprises et décrites, mais enfin, grosso modo, le juge de paix est ce que l'on voit. Pour les données historiques, comment serait indiquée la référence ? Et quelle est la référence acceptable ? Je pense que, dans un premier temps, l'option on renvoie sur wikipedia est une bonne débrouille. Que déjà ça marche et ça soit fait, on coordination avec leur data.wikipedia, et je pense qu'osm aura fait un grand pas vers la cartographie de données historiques, et plein d'autres choses. Il y a d'ailleurs le projet chronologie sur wikipedia http://fr.wikipedia.org/wiki/Projet:Chronologie qui vaut ce qu'il vaut, qui pourrait peut être simplifier (complexifier est plus probable) la chose. De plus, vu l'explosion de taille qu'un enregistrement des données historiques engendrerait, il faudrait que la diffusion des copies des bases de données osm soit plus confortable et rapide. Sinon il est urgent d'attendre. Cordialement. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Données historique et historiques des données...
Techniquement, il doit être possible de reconstruire ce qui a été effacé (tant que ce n'est pas le bot redaction qui l'a mangé), non ? La relation que je viens d'effacer reste dans la base par exemple : http://api.openstreetmap.org/api/0.6/relation/154958/history Par contre il faut que les ways/nodes de la relation ne soient pas modifiés entre temps, sinon ça doit être dur de reconstruire l'objet de départ (en utilisant la date de modif ?). Pourquoi il n'y a pas l'info de version du way/node dans la relation ? ça simplifierait la gestion de l'historique, non ? Sinon, ce que tu propose me semble bien compliqué à maintenir... Sans parler de l'édition sous Potlach... Mika Le jeudi 03 janvier 2013 à 11:50 +0100, Christian Quest a écrit : Je dévie le fil vers une notion d'historique... Il y a une réflexion actuelle sur l'intégration de données historiques dans OSM, une liste dédiée a même été créée (historic). Plutôt que de supprimer ce genre de relation, ne pourrait-on pas en garder au moins une trace ? J'ai une ébauche de commencement de réflexion sur des tags adaptés... où l'on pourrait intégrer un intervalle de temps à un tag à l'aide d'une notation du type [debut:fin], exemple: name[:1970]=Place de l'Etoile name=Place Charles de Gaulle Ce serait intéressant pour des objets toujours existants, mais ayant évolué dans un passé récent. Ces tags à suffixe temporel ne peuvent pas être confondus avec des tags actuels, et permettent de couvrir plusieurs intervalles (ce que ne permet pas old_name). A charge pour ceux qui veulent les exploiter de les traiter selon leur besoin, mais au moins l'info est là et utilisable plutôt que de disparaitre. Qu'en pensez-vous ? Le 3 janvier 2013 11:24, Vincent de Chateau-Thierry v...@laposte.net a écrit : Bonjour, De : Francescu GAROBY comme je l'avais annoncé, je m'occupe des 2 EPCI précédement évoqués (cf. ci-dessous). Juste pour éviter de faire une connerie : on est d'accord que quand une EPCI fusionne avec une autre, la première doit disparaitre de la base d'OSM ? En l'occurrence, c'est la CC Rives-de-l'Odon qui a fusionné avec la CA Caen-la-Mer (ainsi que 3 autres communes, mais qui n'étaient dans aucune EPCI donc pas de pb pour elles), donc je dois supprimer la CC Rives-de-l'Odon. C'est correct ? Oui, dans le lot, il y a bien une relation à supprimer, et l'autre à modifier / augmenter. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modélisation du réseau électrique français
Un truc du genre: http://wiki.openstreetmap.org/wiki/Power_lines#example :) Le 2 janvier 2013 23:55, Christian Quest cqu...@openstreetmap.fr a écrit : Pour l'interconnexion, je pense qu'on est dans la même logique que les relations de type=route Pourquoi pas type=route + route=power ou un truc du genre ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Communes nouvelles
Le 3 janvier 2013 11:40, Vincent de Chateau-Thierry v...@laposte.net a écrit : Sinon Banatic ( http://www.banatic.interieur.gouv.fr/Banatic2/ ) a des mises à jour trimestrielles mais il y a des restrictions sur l'usage des données : http://www.banatic.interieur.gouv.fr/Banatic2/static/ba-Infos-legales.htm qui concrètement empêchent qu'on s'en serve comme source. C'est moche ça ! Gaël et Christian n'ont pas des contacts au ministère de l'intérieur des fois ? ça devrait être publié sur data.gouv.fr en LO/OL ce type de données. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Données historique et historiques des données...
De : Christian Quest Je dévie le fil vers une notion d'historique... Il y a une réflexion actuelle sur l'intégration de données historiques dans OSM, une liste dédiée a même été créée (historic). Plutôt que de supprimer ce genre de relation, ne pourrait-on pas en garder au moins une trace ? L'un n'empêche pas l'autre, dès lors que la trace gardée est stockée hors de la base OSM. J'ai une ébauche de commencement de réflexion sur des tags adaptés... où l'on pourrait intégrer un intervalle de temps à un tag à l'aide d'une notation du type [debut:fin], exemple: name[:1970]=Place de l'Etoile name=Place Charles de Gaulle Mais dans ce cas, ne faudrait-il pas : name[1970:]=Place Charles de Gaulle ? Et là ça devient coton à gérer... Ce serait intéressant pour des objets toujours existants, mais ayant évolué dans un passé récent. Ces tags à suffixe temporel ne peuvent pas être confondus avec des tags actuels, et permettent de couvrir plusieurs intervalles (ce que ne permet pas old_name). A charge pour ceux qui veulent les exploiter de les traiter selon leur besoin, mais au moins l'info est là et utilisable plutôt que de disparaitre. Qu'en pensez-vous ? Disposer de données datées rajouterait évidemment de l'intérêt, mais avec le paradigme de l'api v0.6 (tout dans une même base) la concrétisation me semble assez effrayante. On gère 2 dimensions correctement, la 3è a déjà un peu de mal à émerger (les souterrains, les étages de bâtiments, l'indoor en général) alors la 4è par dessus tout ça, côté gestion / édition, aïe. Et comme déjà dit dans ce fil, faute de référence actuelle, vérifiable, la fragilité de ces données me semble encore supérieure, face au besoin de maintenance (cf. les cas quotidiens de relations admin cassées, pour prendre un exemple dans le même contexte que l'EPCI qu'on efface aujourd'hui). Bref, je suis pour mais soit en dehors de la base OSM (au moins en api v0.6) soit au prix d'un changement assez radical d'organisation des données, avec l'émergence de meta-données telles ici des dates de validité qu'on appliquerait aux données elles- mêmes. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] suppression d'une zone de construction....
Bonjour, Est-il possible de faire un revert sur le changement suivant: http://www.openstreetmap.org/browse/way/176783361 Ce n'est pas parceque l'on a des opinions contraires a ce qui est prévu que l'on doit supprimer des données qui existent réelement... Je pense que Sylvain pourrait user de son role de DWG pour bloquer ce genre de personnes vandalisant volontairement des données sous prétexte qu'ils n'ont pas le même opinion politique que ce qui a été décidé par des textes de loi !! De toute manière ce compte a été ouvert exprès pour supprimer cette donnée... JE pense que c'est uniquement si les autorités font retour en arrière et interdisent la construction de cet aéroport que l'on peut supprimer de telles données... mais malheureusement ce n'est pas en vandalisant la base de donnée OSM que la réalité sera la meme sur le terrain... ;-) -- View this message in context: http://gis.19327.n5.nabble.com/suppression-d-une-zone-de-construction-tp5742455.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modélisation du réseau électrique français
Le 3 janvier 2013 11:12, David Crochet david.croc...@online.fr a écrit : Est-ce que RTE applique des informations de réseau d'énergie indépendant du réseau physique comme le fait la SCNF qui applique un numéro de ligne (le Paris-Granville) indépendant des voies physique mais liés quand même ? Dans ce cas, pas la peine de simuler la présence de plusieurs réseaux au sein d'un même « chemin » puisque la relation va faire le tri correctement dans ce cas Si les voies SNCF correspondent aux files de pylônes alors la réponse est oui. RTE ne connait même que le circuit qui est codifié selon le nom des postes aux extrémités et suivant un ordre numérique (plusieurs circuits peuvent correspondre aux mêmes extrémités). Les files de pylônes ne sont pas codifiées en tant qu'artère, par contre les pylônes possèdent des numéros (selon un des circuits supportés je crois) Je suis aussi d'accord pour dire que la relation réifie correctement le circuit, il faut que tout s'ordonne dans ma tête surtout :) Il peut exister des cas particuliers : les piquages. C'est le cas à Montchanin : http://goo.gl/maps/fjdKy Le circuit de gauche se voit ponctionner vers le poste électrique tout proche. Là, le modèle d'OSM à base de relation permet de traiter ce cas avec un tag via= par contre je ne sais pas comment RTE fait puisque le circuit n'a pas 2 mais 3 extrémités. D'ailleurs les apparences sont parfois trompeuses puisque ce circuit est construit en techno 400 kV mais n'accepte en réalité que du 225 kV (cf le piquage et les cartes de RTE). Le 400 kV arrive prochainement. http://www.rte-france.com/fr/nos-activites/nos-projets/bourgogne/les-projets-en-cours-en-bourgogne Car « power=cable » sous entend implicitement « layer = -1 » ce qui évite par exemple à un logiciel de dire qu'un câble croisent sans connexion une ligne. alors qu'il n'ont pas le layer indiqué Je ne comprends pas très bien cette histoire de layer. Deux ways peuvent se croiser, elles ne seront connectées que si elles ont un node en commun à l'endroit du croisement. Pourquoi vouloir hiérarchiser de cette façon? Mais très peu visible sauf les balises au sol indiquant la présence d'un réseau souterrain Ce que je voulais dire est qu'un contributeur OSM pourra faire la carto d'une artère BTB aérienne qui disparaitra 15 jours plus tard sous le coup d'une dissimulation de réseau. La capillarité fait que les zones à surveiller sont multiples sans avoir une visibilité correcte sur les projets des concessionnaires de ces réseaux. Sur la HTB (et ca démarre un peu sur la HTA) les projets sont connus et les travaux bien plus voyant. C'est juste une question de capacité de mise à jour, sinon on est bien d'accord que le max de données disponibles reste l'objectif. -- *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] suppression d'une zone de construction....
Je plussois... Il y a une différence entre les opinion personnelle et la réalité du terrain. Si le projet est modifier ou abandonné ce sera à prendre en compte mais pas avant autrement le pont de Millau et de nombreuse éolienne aurait déjà été supprimé de la carte. Le 3 janvier 2013 13:32, PierreV belett...@hotmail.fr a écrit : Bonjour, Est-il possible de faire un revert sur le changement suivant: http://www.openstreetmap.org/browse/way/176783361 Ce n'est pas parceque l'on a des opinions contraires a ce qui est prévu que l'on doit supprimer des données qui existent réelement... Je pense que Sylvain pourrait user de son role de DWG pour bloquer ce genre de personnes vandalisant volontairement des données sous prétexte qu'ils n'ont pas le même opinion politique que ce qui a été décidé par des textes de loi !! De toute manière ce compte a été ouvert exprès pour supprimer cette donnée... JE pense que c'est uniquement si les autorités font retour en arrière et interdisent la construction de cet aéroport que l'on peut supprimer de telles données... mais malheureusement ce n'est pas en vandalisant la base de donnée OSM que la réalité sera la meme sur le terrain... ;-) -- View this message in context: http://gis.19327.n5.nabble.com/suppression-d-une-zone-de-construction-tp5742455.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Petites bizarreries sur Notre-Dame-des-Landes et Vigneux-de-Bretagne
Le 3 janv. 2013 à 10:52, PhQ a écrit : Bon le principe, pour sortir des landuse de corine qui s'étalent sur des zones trop grandes et de sectoriser en prenant une unité gérable, par exemple la commune. On prend alors l'utilisation majoritaire (le bocage) landuse= meadow qu'on applique à toute la commune (copie de la relation commune mais avec un landuse meadow) OK, pour le principe, mais, le fait que ce n'ai été appliqué qu'à 2 communes qui sont le lieu d'une contestation politique sur la suppression d'une partie du bocage herbager ne peut être fortuit. Comme la deuxième partie de travail à faire ne l'a pas été, le soupçon se renforce. Que peut-on en faire ? Rien, puisqu'on sait que cela risque d'être sérieusement modifié à plus ou moins long terme. Chrsitian R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] suppression d'une zone de construction....
On jeudi 3 janvier 2013, PierreV wrote: Bonjour, Salut, Est-il possible de faire un revert sur le changement suivant: http://www.openstreetmap.org/browse/way/176783361 C'est toujours possible, la question étant : faut il le faire ? JE pense que c'est uniquement si les autorités font retour en arrière et interdisent la construction de cet aéroport que l'on peut supprimer de telles données... Au delà des opinions de chacun, openstreetmap enregistre des faits, et c'est le terrain qui prime : Est-ce qu'il y a un aéroport à cet endroit ? non - donc je propose de ne pas utiliser aeroway = aerodrome (voir les pages du wiki concernant construction=yes) Maintenant, le terrain est-il en construction pour un aéroport ? (En clair, y'a-t-il des engins de chantier, de la terre brassée et quelque chose qui se voit) Si oui, alors ok pour l'enregistrer dans openstreetmap avec, par exemple, : http://wiki.openstreetmap.org/wiki/Brownfield et construction:aeroway = aerodrome -- sly, DWG member since 11/2012 Coordinateur du groupe [ga] http://wiki.openstreetmap.org/wiki/User:Sletuffe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] suppression d'une zone de construction....
Le 3 janv. 2013 à 14:04, sly (sylvain letuffe) a écrit : Au delà des opinions de chacun, openstreetmap enregistre des faits, et c'est le terrain qui prime : Est-ce qu'il y a un aéroport à cet endroit ? non - donc je propose de ne pas utiliser aeroway = aerodrome (voir les pages du wiki concernant construction=yes) Il n'y a pas de travaux, et celui qui se cache derrière le pseudonyme de ZAD (pour lui, c'est une zone à défendre, alors que pour la loi, c'est une zone à aménagement différé) a voulu supprimer virtuellement le futur aéroport. Cette mention était là depuis des mois, probablement d'après les données libérées par le Conseil général de Loire-Atlantique Maintenant, le terrain est-il en construction pour un aéroport ? (En clair, y'a-t-il des engins de chantier, de la terre brassée et quelque chose qui se voit) Si oui, alors ok pour l'enregistrer dans openstreetmap avec, par exemple, : http://wiki.openstreetmap.org/wiki/Brownfield et construction:aeroway = aerodrome Pas de chantier, puisqu'un Fort Chabrol (baraques et 40 tracteurs enchaînés) s'est constitué dans une petite forêt. Les travaux de défrichage sont repoussés, au minimum, jusqu'en avril. Y-a-t'il des tags pour une Zone à aménagement différé : cela pourrait freiner les maires qui donnent des permis de construire à proximité des aéroports en projet. :-) Christian Rogel___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Petites bizarreries sur Notre-Dame-des-Landes et Vigneux-de-Bretagne
Le 3 janvier 2013 11:36, Christian Quest cqu...@openstreetmap.fr a écrit : C'est très clean en théorie, mais dans la pratique ça me semble un peu fragile. Je ne pense pas que ce soit une bonne idée d'utiliser les même way pour décrire un découpage administratif et une occupation du sol, le premier évoluant peu, le second évoluant bien plus souvent, on risque d'avoir des découpages administratifs modifiées par une édition de landuse... la réparation de nombreux découpages administratifs suite à ce genre de manip par un contributeur qui avait suivit une fausse bonne idée noyée dans un mail de Philippe Verdy me laisse de douloureux souvenir dans le poignet droit. Doucement je n'ai jamais eu ce genre de bonne idée et j'ai même défendu le contraire, le plus possible. Quand j'étais intervenu c'est pour réparer bon nombre de landuse cassés et de frontières cassées en Champagne-Ardenne. La réparation a été douloureuse et pénible à faire, mais l'idée suivie par moi a été d'éviter aussi de reconstruire des polygones géants, mais de me rapprocher de ce qui était visible depuis l'imagerie en collant au terrain, et en évitant de suivre les frontières administratives. Cependant je n'ai pas été au delà de la réparation de ces frontières et de refermer les polygones cassés, sans le refusionner s'ils étaient déjà scindés en plusieurs morceaux (sauf les micro-fragments contigus pour simplifier le découpage en réduisant le nombre de traits inutiles entre deux zones de même type). Ce qui est fragile ce sont les polygones très étendus et très complexes. Oui il vaut mieux les scinder en plusieurs parties, mais pas n'importe comment : on trouvera toujours au moins un chemin, une route pour faire ce découpage et ce sera toujours préférable à l'utilisation des frontières administratives. Malgré tout quand les frontières administratives suivent déjà l'axe d'une route ou d'une rivière, autant utiliser le même chemin que de les superposer. La frontière est alors matérialisée sur le terrain et peut convenir aussi au découpage des landuse. Mais un découpage de polygone géant fait sur une ligne de découpe arbitraire qui ne correspond à rien (cas des polygones Corine) n'est pas souhaitable : on peut parfaitement toujours déterminer des tracés plus adéquats pour avoir des tracés fiables, pas trop étendus, sans grandes enclaves (les seules enclaves à inclure étant alors réduites à un seul chemin) ni aucune exclave même petite (il vaut mieux pour les landuse en faire des surfaces séparées). De même je n'aime pas trop les landuse superposés; pas plus que les surfaces riverbanks ne devraient se superposer aux landuse adjascents (ce cela rend l'interprétation ambiguë). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Petites bizarreries sur Notre-Dame-des-Landes et Vigneux-de-Bretagne
Le 3 janvier 2013 15:00, Philippe Verdy verd...@wanadoo.fr a écrit : Ce qui est fragile ce sont les polygones très étendus et très complexes. Oui il vaut mieux les scinder en plusieurs parties, mais pas n'importe comment : on trouvera toujours au moins un chemin, une route pour faire ce découpage et ce sera toujours préférable à l'utilisation des frontières administratives. J'espère que tu ne veux pas dire que tu utilises un chemin ou un route comme un morceau du polygone de landuse? Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Paray-le-Monial : une commune qui risque d'utiliser OSM pour son plan de ville
Bonjour à tous, Je suis en contact avec plusieurs personnes sur Paray le Monial qui est un haut lieu spirituel en France avec plusieurs milliers de pélerins par an. Le service des pèlerinage n'a pas de plan dynamique et multilingue et la mairie s'oriente vers le prochain recensement de la population avec peine : il leur manque un plan de ville précis. Je dois avoir des échanges dans les semaines qui viennent pour concrétiser l'appropriation sur les deux niveaux : tourisme spirituel et municipal. Pour ceux qui se sentent de m'épauler : j'ai besoin d'un coup de main pour affiner la carte : - emprise des zones urbaines - nommage des voies - qualification des équipements majeurs - autres inspirations Voici la commune : http://www.openstreetmap.org/?lat=46.4503lon=4.1154zoom=14layers=M Merci d'avance - Cordialement, ZIMMY Jean-Louis ZIMMERMANN Développeur territorial (ville d'Orange,FR84) Mandataire OSM-France sur le Grand-Sud-est -- View this message in context: http://gis.19327.n5.nabble.com/Paray-le-Monial-une-commune-qui-risque-d-utiliser-OSM-pour-son-plan-de-ville-tp5742488.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Numéro de rue ?
Bonjour, Je me lance dans la numérotation des habitations de mon village. http://www.openstreetmap.org/?lat=49.38994lon=4.656808zoom=18layers=M Pour le moment je n'ai fait qu'ajouter le tag addr:housenumber Les numéro apparaissent bien sur OSM. Lorsque je fais une recherche par exemple : 7 rue de richecourt blaise, pas de problème. Mais si je fais la recherche 20 rue henri rouyer blaise, OSM trouve bien la rue mais pas le numéro. Corrigez moi si je me trompe, mais je suppose que le N° 20 est trop éloigné de la rue pour qu'il soit automatiquement associé à elle. Ma question est donc : Comment associer toutes les habitations d'une rue à un nom de rue ? Avec addr:street http://wiki.openstreetmap.org/wiki/Key:addr:street pour chaque maison ? Avec une relation ? Comment faire ? Merci d'avance pour vos lumières. Corneliux ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Numéro de rue ?
Bonjour, Tu as en effet 2 solutions : * le double-tag addr:housenumber + addr:street, pour chaque maison ; * créer une relation associatedStreet, avec le rôle 'street' sur chaque way représentant la rue, et le rôle 'house' sur chaque maison + le tag addr:housenumber sur chaque maison. Francescu Le 3 janvier 2013 15:11, Xavier x.larc...@laposte.net a écrit : Bonjour, Je me lance dans la numérotation des habitations de mon village. http://www.openstreetmap.org/?lat=49.38994lon=4.656808zoom=18layers=M Pour le moment je n'ai fait qu'ajouter le tag addr:housenumber Les numéro apparaissent bien sur OSM. Lorsque je fais une recherche par exemple : 7 rue de richecourt blaise, pas de problème. Mais si je fais la recherche 20 rue henri rouyer blaise, OSM trouve bien la rue mais pas le numéro. Corrigez moi si je me trompe, mais je suppose que le N° 20 est trop éloigné de la rue pour qu'il soit automatiquement associé à elle. Ma question est donc : Comment associer toutes les habitations d'une rue à un nom de rue ? Avec addr:street http://wiki.openstreetmap.org/wiki/Key:addr:streetpour chaque maison ? Avec une relation ? Comment faire ? Merci d'avance pour vos lumières. Corneliux ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Numéro de rue ?
Pour mon village j'ai utilisé le greffon FixAdress : http://wiki.openstreetmap.org/wiki/JOSM/Plugins/FixAddresses et l'outil nommé dans JOSM Outil d'aide pour l'adresse qui permet de créer automatiquement des relations entre les rue et les adresses. Par contre n'ayant aucun bâtiment, pour l'instant les adresses sont indiqué par des nœuds et je ne sais pas si l'outil d'aide pour l'adresse permet d'attribuer un numéro directement sur un bâtiment ou si il crée systématiquement un nœud. Le 3 janvier 2013 15:15, Francescu GAROBY windu...@gmail.com a écrit : Bonjour, Tu as en effet 2 solutions : * le double-tag addr:housenumber + addr:street, pour chaque maison ; * créer une relation associatedStreet, avec le rôle 'street' sur chaque way représentant la rue, et le rôle 'house' sur chaque maison + le tag addr:housenumber sur chaque maison. Francescu Le 3 janvier 2013 15:11, Xavier x.larc...@laposte.net a écrit : Bonjour, Je me lance dans la numérotation des habitations de mon village. http://www.openstreetmap.org/?lat=49.38994lon=4.656808zoom=18layers=M Pour le moment je n'ai fait qu'ajouter le tag addr:housenumber Les numéro apparaissent bien sur OSM. Lorsque je fais une recherche par exemple : 7 rue de richecourt blaise, pas de problème. Mais si je fais la recherche 20 rue henri rouyer blaise, OSM trouve bien la rue mais pas le numéro. Corrigez moi si je me trompe, mais je suppose que le N° 20 est trop éloigné de la rue pour qu'il soit automatiquement associé à elle. Ma question est donc : Comment associer toutes les habitations d'une rue à un nom de rue ? Avec addr:street http://wiki.openstreetmap.org/wiki/Key:addr:streetpour chaque maison ? Avec une relation ? Comment faire ? Merci d'avance pour vos lumières. Corneliux ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Numéro de rue ?
Le 3 janvier 2013 15:11, Xavier x.larc...@laposte.net a écrit : Bonjour, Je me lance dans la numérotation des habitations de mon village. http://www.openstreetmap.org/?lat=49.38994lon=4.656808zoom=18layers=M Pour le moment je n'ai fait qu'ajouter le tag addr:housenumber Les numéro apparaissent bien sur OSM. Lorsque je fais une recherche par exemple : 7 rue de richecourt blaise, pas de problème. Mais si je fais la recherche 20 rue henri rouyer blaise, OSM trouve bien la rue mais pas le numéro. Corrigez moi si je me trompe, mais je suppose que le N° 20 est trop éloigné de la rue pour qu'il soit automatiquement associé à elle. Ma question est donc : Comment associer toutes les habitations d'une rue à un nom de rue ? Avec addr:street http://wiki.openstreetmap.org/wiki/Key:addr:streetpour chaque maison ? Avec une relation ? Comment faire ? Merci d'avance pour vos lumières. Regarde ici http://osm.org/go/0DEYk_hE_-- pour prendre exemple. Il te suffit d'utiliser l'outil d'aide pour l'adresse du greffon cadastre pour créer très facilement les relations associatedStreet. Perso, j'ai pris pour habitude de mettre les numéros non pas sur l'ensemble du polygone mais sur un nœud soit solidaire sur un côté du polygone soit isolé de façon à matérialiser l'emplacement de la boite aux lettres. Romain Corneliux ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Petites bizarreries sur Notre-Dame-des-Landes et Vigneux-de-Bretagne
Le 3 janvier 2013 15:06, Romain MEHUT romain.me...@gmail.com a écrit : Le 3 janvier 2013 15:00, Philippe Verdy verd...@wanadoo.fr a écrit : Ce qui est fragile ce sont les polygones très étendus et très complexes. Oui il vaut mieux les scinder en plusieurs parties, mais pas n'importe comment : on trouvera toujours au moins un chemin, une route pour faire ce découpage et ce sera toujours préférable à l'utilisation des frontières administratives. J'espère que tu ne veux pas dire que tu utilises un chemin ou un route comme un morceau du polygone de landuse? Pourquoi pas ? C'est mieux qu'une frontière territoriale nue, et au moins ça colle au terrain. Sinon où places-tu la limite de landuse quand c'est la route elle-même qui sépare deux terrains de nature/utilisation différente? Tu inventes un trait arbitraire d'un côté ou de l'autre de la route ? Ou tu superpose les deux tracés ? La notion même de landuse est liée à une utilisation humaine du terrain, et une route est bel et bien une utilisation humaine. Au delà de ça la route sépare deux parcelles de chaque côté mais si on n'a pas détaillé l'emprise parcellaire de la route elle-même car on n'a tracé que son filaire, on n'a rien d'autre à détailler de chaque côté et c'est bien le filaire central de la route qui séparera les terrains. Même si la route a son tracé modifié plus tard (mais tant que ce ne sera pas fait, il n'y a rien de plus à ajouter). Le jour où tu ne voudras plus lier le landuse à la route c'est qu'on sera passé au niveau de détail du tracé exact des parcelles, et les routes devront être autre chose qu'un simple tracé filaire et devront avoir un tracé en plus de leur surface réelle (chaussée, bas-côtés ou trottoirs, voire aussi les fossés à taguer en waterway). A ce niveau on inclura aussi les barrières, barbelés, les haies, l'implantation de chaque arbre... Sans ces détails, il n'y a pas lieu d'utiliser des chemins différents pour les limites de landuse et les routes avec des tracés arbitraires (parallèles ou superposés). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Petites bizarreries sur Notre-Dame-des-Landes et Vigneux-de-Bretagne
Le 3 janvier 2013 15:31, Philippe Verdy verd...@wanadoo.fr a écrit : Pourquoi pas ? C'est mieux qu'une frontière territoriale nue, et au moins ça colle au terrain. Sinon où places-tu la limite de landuse quand c'est la route elle-même qui sépare deux terrains de nature/utilisation différente? Tu inventes un trait arbitraire d'un côté ou de l'autre de la route ? Ou tu superpose les deux tracés ? Il avait déjà été question de ce cas de figure où l'on s'était posé la question de coller ou pas coller et j'avais donné un cas de figure montrant la complexité de ce choix de coller du landuse à des highway: http://lists.openstreetmap.org/pipermail/talk-fr/2012-September/048373.html Et donc actuellement, je mets l'emprise de la route dans un landuse. Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Paray-le-Monial : une commune qui risque d'utiliser OSM pour son plan de ville
*Bonjour à toutes et à tous. @**Jean-Louis ZIMMERMANN : En visualisant le lien de la carte que tu a mis, je constate qu'il manque les bâtiments de la Gare SNCF et le nœud marquant le point d’arrêt SNCF. Je vais donc tracé ces élément avec l'imagerie Bing qui est plus tôt de bonne qualité même en zoom fort dans JOSM. Voilà, je m'y met après cette envoie de ce message. À bientôt... Amicales salutations. PS : Je présente mes meilleurs vœux pour 2013. Olivier Griffet http://griffet.net/ | Contributeur OpenStreetMap = http://www.openstreetmap.org/user/olivier_griffet_83660_carnoules | | Habitant de 83660http://www.openstreetmap.org/export/embed.html?bbox=6.17628,43.29493,6.19694,43.30505layer=mapnikmarker=43.29837,6.18737- Carnoules http://carnoules.fr/ - Var | Adhérent de GULLIVAR et ToulonuX | Utilisateur de GNU/LINUX de Linux Mint 11 [ Gnome ] + (X)Ubuntu 12.04 [ XFCE ] ; Lives USB ASRI.EDU.2.1a ; Etc... Site web de GULLIVAR : http://gullivar.org/ Site web de ToulonuX : http://toulonux.tuxfamily.org/ * - Le 3 janvier 2013 15:09, ZIMMY jeanlouis.zimmerm...@laposte.net a écrit : Bonjour à tous, Je suis en contact avec plusieurs personnes sur Paray le Monial qui est un haut lieu spirituel en France avec plusieurs milliers de pélerins par an. Le service des pèlerinage n'a pas de plan dynamique et multilingue et la mairie s'oriente vers le prochain recensement de la population avec peine : il leur manque un plan de ville précis. Je dois avoir des échanges dans les semaines qui viennent pour concrétiser l'appropriation sur les deux niveaux : tourisme spirituel et municipal. Pour ceux qui se sentent de m'épauler : j'ai besoin d'un coup de main pour affiner la carte : - emprise des zones urbaines - nommage des voies - qualification des équipements majeurs - autres inspirations Voici la commune : http://www.openstreetmap.org/?lat=46.4503lon=4.1154zoom=14layers=M Merci d'avance - Cordialement, ZIMMY Jean-Louis ZIMMERMANN Développeur territorial (ville d'Orange,FR84) Mandataire OSM-France sur le Grand-Sud-est -- View this message in context: http://gis.19327.n5.nabble.com/Paray-le-Monial-une-commune-qui-risque-d-utiliser-OSM-pour-son-plan-de-ville-tp5742488.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] INSEE, recensement 2010 et mise à jour de la population des communes
Bonjour, Suite à quelques articles de médias locaux ( Coté Caenhttp://www.cotecaen.fr/20944/caen-herouville-et-mondeville-continuent-de-perdre-des-habitants/, Tendance Ouesthttp://www.tendanceouest.com/region/actualite-46736-quelle-est-la-population-de-votre-commune-.html, ...) parlant de la parution des chiffres du recensement mené en 2010 par l'INSEE, je voulais mettre à jour ces infos sur les communes de ma région. Or, je remarque une grande hétérogénéité dans les tags : en plus du tag population=XYZ, on trouve des fois census=20XX (qui semble être un tag surtout utilisé aux États-Unis, avec TIGER), d'autres fois source:population=INSEE 20XX, d'autres fois encore rien... En cherchant dans le wiki, j'ai vu qu'il y avait eu une proposition de tag acceptée pour population, mais rien d'arrêté concernant la source. Savez-vous si une méthode est plus plébiscitée que d'autres ? -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] [forum-osm-fr] Peut on indiquer les terroir agricole ?
Le message suivant de : ## Bonjour à tous, Suite à l'agrandissement continu d'un gros multi-polygone landuse=vineyard (ouaips on aime le vin d'ici et pas l'eau de là) par chez moi j'ai du le scinder déjà 3 fois au fur à mesure de son agrandissement. Pour l'instant j'ai profiter de la présence de cours d'eau, de canaux et d'autre polygone existant pour le scinder de façon compréhensible mais lors d'une récente modification j'ai du le scinder de façon totalement arbitraire en plein champ faute de trouver un meilleur emplacement. Peut être est possible de récupérer les informations de Wikipédia pour scinder et nommer correctement les multi-polygones landuse=vineyard par terroir puis de les réunir dans une seule relation nommé Vignoble du Languedoc-Roussillon : http://fr.wikipedia.org/w/index.php?title=Vignoble_du_Languedoc-Roussillon Par contre il restera toujours des zones qui ne seront dans aucun terroir car c'est également le cas sur le terrain. Il ne semble y avoir aucun tag existant pour cette utilisation. Est ce que les tag suivant serait suffisant ? - type=multipolygone - landuse=vineyard - name=nom du terroir - wikipedia=lien si existant Les spécificité et éléments plus détaillé [b]ne seront pas pris en compte[/b] comme les zone climatique. Par exemple l'appellation La Clape qui est une zone climatique (et AOC) du terroir Coteau du Languedoc. Pour information, le fameux voici le multipolygone me posant des problème : http://www.openstreetmap.org/browse/relation/285855 a été posté sur le forum http://forum.openstreetmap.fr/viewforum.php?f=3 Une réponse par mail sur l'adresse d'expédition n'arrivera nulle part Une réponse à la liste ne sera pas transmise au forum, ce qui n'empêche pas une concertation sur la liste avant de recopier la/les meilleurs réponses sur le forum. Notez qu'il n'est pas necessaire d'avoir un compte sur le forum pour répondre. -- Les questions sur ce robot de transfert forum-liste peuvent être posées à sylvainaletuffe.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] INSEE, recensement 2010 et mise à jour de la population des communes
Salut, Savez-vous si une méthode est plus plébiscitée que d'autres ? J'aurais plutôt tendance à commencer par la question : est-ce une bonne idée de le faire ? Si ces données existent, et que tu vas faire le recoupement par le tag ref:INSEE, alors est-ce que ça apporte une info puisque finalement, n'importe qui peut le faire à partir du fichier fourni par l'INSEE ? Et plutôt que de faire chacun dans son coin, si on opte pour le faire, n'est-il pas plus intéressant de faire sur toute la france ? Si tu proposes un remplacement, on peut supposer que le tag précédent a été rentré par quelqu'un qui avait, lui aussi, certaines raisons de le mettre, peut-on automatiquement juger que sa source est plus mauvaise que l'insee ? -- sly, DWG member since 11/2012 Coordinateur du groupe [ga] http://wiki.openstreetmap.org/wiki/User:Sletuffe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] suppression d'une zone de construction....
2013/1/3 Christian Rogel christian.ro...@club-internet.fr: Je pense aussi que le balisage précédent la suppression n'était pas approprié tant que les travaux n'ont pas débuté sur le terrain. Maintenant, on devrait quand même restaurer le polygone mais avec des tags plus appropriés pour dire ce que Christian mentionne, genre landuse=greenfield ? d'après le wiki A greenfield is scheduled to turn into a construction site. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] INSEE, recensement 2010 et mise à jour de la population des communes
Questions pertinentes, en effet. Il est vrai que j'ai cherché à mettre à jour parce que j'avais déjà vu que cette donnée (la population) était présente sur les nodes 'admin_centre' de certaines communes. Quant à la source précédente qui avait servi à renseigner cette info, elle n'est pas forcément fausse : elle peut juste être obsolète (précédent recensement de l'INSEE, par ex). Francescu Le 3 janvier 2013 16:16, sly (sylvain letuffe) li...@letuffe.org a écrit : Salut, Savez-vous si une méthode est plus plébiscitée que d'autres ? J'aurais plutôt tendance à commencer par la question : est-ce une bonne idée de le faire ? Si ces données existent, et que tu vas faire le recoupement par le tag ref:INSEE, alors est-ce que ça apporte une info puisque finalement, n'importe qui peut le faire à partir du fichier fourni par l'INSEE ? Et plutôt que de faire chacun dans son coin, si on opte pour le faire, n'est-il pas plus intéressant de faire sur toute la france ? Si tu proposes un remplacement, on peut supposer que le tag précédent a été rentré par quelqu'un qui avait, lui aussi, certaines raisons de le mettre, peut-on automatiquement juger que sa source est plus mauvaise que l'insee ? -- sly, DWG member since 11/2012 Coordinateur du groupe [ga] http://wiki.openstreetmap.org/wiki/User:Sletuffe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Paray-le-Monial : une commune qui risque d'utiliser OSM pour son plan de ville
le 03/01/2013 15:09, ZIMMY a écrit: [...] Pour ceux qui se sentent de m'épauler : j'ai besoin d'un coup de main pour affiner la carte : - emprise des zones urbaines - nommage des voies - qualification des équipements majeurs - autres inspirations Bonjour, Je peux m'occuper de compléter les tracés de routes sur Bing. Samy ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Numéro de rue ?
2013/1/3 Xavier x.larc...@laposte.net: Corrigez moi si je me trompe, mais je suppose que le N° 20 est trop éloigné de la rue pour qu'il soit automatiquement associé à elle. C'est un peu plus compliqué que ça. Comme on le voit ici http://nominatim.openstreetmap.org/details.php?place_id=3670662157 il reconnait le 19, le 21 mais pas le 20. Parce que comme tu n'as pas mis de tag addr:street, ni de relation de type associatedStreet, nominatim n'est pas capable de dire si le 20 appartient à cette rue ou à la rue adjacente. C'est bien un problème de distance, mais de distance entre deux rues. Le mieux est de systématiquement tagguer ensemble numéro ET rue au minimum, avec l'une des deux méthodes sus-mentionnées. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] suppression d'une zone de construction....
On jeudi 3 janvier 2013, Pieren wrote: 2013/1/3 Christian Rogel christian.ro...@club-internet.fr: Je pense aussi que le balisage précédent la suppression n'était pas approprié tant que les travaux n'ont pas débuté sur le terrain. Je suis d'accord avec ça. Maintenant, on devrait quand même restaurer le polygone mais avec des tags plus appropriés pour dire ce que Christian mentionne, genre landuse=greenfield ? d'après le wiki A greenfield is scheduled to turn into a construction site. Je reste réservé sur une telle solution. Comme souvent, c'est pas parce qu'un tag existe qu'il faut l'utiliser. Il faut 1) se demander s'il est bien adapté, le wiki disant par exemple : where there have been no buildings before. Et 2) même si adapté, avons nous intérêt à mettre dans OSM des projections d'avenir ? et si oui, à quelle échéance max (je suppose que personne ne trouverait utile d'indiquer les glaciers de la prochaine aire glaciaire) Si oui toujours, quelle maintenabilité d'éléments qui n'auront jamais été réalisés et qui risque de rester à traîner ? Pour ma part, je pense que les projets d'historiques et de projection du futur ne devrait pas, en l'état des outils et de la base, appartenir à OSM, mais à un autre projet ou tout du moins, une autre base. Les ajouter à OSM, en l'état des choses, ne ferait que compliquer une activité de mapping déjà bien compliquée pour des débutants. -- sly, DWG member since 11/2012 Coordinateur du groupe [ga] http://wiki.openstreetmap.org/wiki/User:Sletuffe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] INSEE, recensement 2010 et mise à jour de la population des communes
De : Francescu GAROBY Questions pertinentes, en effet. Il est vrai que j'ai cherché à mettre à jour parce que j'avais déjà vu que cette donnée (la population) était présente sur les nodes 'admin_centre' de certaines communes. Quant à la source précédente qui avait servi à renseigner cette info, elle n'est pas forcément fausse : elle peut juste être obsolète (précédent recensement de l'INSEE, par ex). Le 3 janvier 2013 16:16, sly (sylvain letuffe) a écrit : Savez-vous si une méthode est plus plébiscitée que d'autres ? J'aurais plutôt tendance à commencer par la question : est-ce une bonne idée de le faire ? Si ces données existent, et que tu vas faire le recoupement par le tag ref:INSEE, alors est-ce que ça apporte une info puisque finalement, n'importe qui peut le faire à partir du fichier fourni par l'INSEE ? Et plutôt que de faire chacun dans son coin, si on opte pour le faire, n'est-il pas plus intéressant de faire sur toute la france ? Si tu proposes un remplacement, on peut supposer que le tag précédent a été rentré par quelqu'un qui avait, lui aussi, certaines raisons de le mettre, peut-on automatiquement juger que sa source est plus mauvaise que l'insee ? D'accord sur le fait que par principe, grâce au ref:INSEE des relations communales, on peut retrouver la population directement dans les fichiers INSEE (c'est bien le but du ref:INSEE comme clé externe). De mon côté je continue néanmoins de l'ajouter quand je définis une relation admin. Je vois 2 intérêts, chacun discutable : - avoir l'info en direct, du point de vue d'un consommateur de données OSM - avoir un élément pour aider à déterminer le type de place=* qu'on trouvera dans la commune. Ça n'est pas efficace partout, mais par exemple une population en dessous de 100 hab. justifie qu'aucun place=village ne soit présent. Une population autour des seuils (10.000 et 100.000 hab) permet de viser village, town ou city selon le cas. On a donc une info qui sert dans notre contexte. Maintenant, la cible, c'est, plutôt qu'à la main, le passage, au moins une fois l'an, d'un bot qui ajouterait ou mettrait à jour le tag population, sur la foi des résultats de recensement publiés par l'INSEE. Une fois cette mécanique en place, il n'y aura plus de valeur ajoutée à faire ça à la main. Et on s'économisera :-) vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Petites bizarreries sur Notre-Dame-des-Landes et Vigneux-de-Bretagne
Je suis en train de suivre vos développement et j'hésite sur la méthode à suivre car j'imagine pas encore les implication que cela pourrait entraîner. Quand je vois cette doc : http://wiki.openstreetmap.org/wiki/Multipolygon_Examples#Forest_with_2_lakes.2C_island.2C_boundary_and_highway_.28Multiple_ways_forming_nested_multipolygons.29 J'opterai pour ce choix car je le trouve simple à mettre en place mais d'un coté je connaît à moins d'un kilomètre de chez moi où la piste est également la séparation entre deux commune (Narbonne - Moussan). Ce même chemin est bordé d'un coté par une vigne et de l'autre par de la garrigue. Est ce que cela implique donc de superposer tous ces éléments ? Ceci était un exemple modifié de la réalité pour en savoir plus sur la question. Voici ce qui ce passe réellement : La piste est à moins d'un mètre de la séparation entre deux commune (Narbonne -Moussan). Ce même chemin est réellement bordé d'un coté par une vigne et de l'autre par de la garrigue (non représentée car trop petite). Ne pas joindre les landuse avec le chemin représenterai les uns à coté des autre à la fois le chemin, la frontière communale et les terrains soit trois traits. Pour information la zone est complexifié par le fait que 300 mètre plus loin j'ai la jonction à la fois de deux pistes d'état différent, d'une route de service, d'une piste cyclable et une nouvelle commune qui s'ajoute à l'ensemble. Voici le résulta de mes choix, n'hésitez pas à me corriger : http://www.openstreetmap.org/?lat=43.219182lon=2.921285zoom=18layers=M Le 3 janvier 2013 15:52, Romain MEHUT romain.me...@gmail.com a écrit : Le 3 janvier 2013 15:31, Philippe Verdy verd...@wanadoo.fr a écrit : Pourquoi pas ? C'est mieux qu'une frontière territoriale nue, et au moins ça colle au terrain. Sinon où places-tu la limite de landuse quand c'est la route elle-même qui sépare deux terrains de nature/utilisation différente? Tu inventes un trait arbitraire d'un côté ou de l'autre de la route ? Ou tu superpose les deux tracés ? Il avait déjà été question de ce cas de figure où l'on s'était posé la question de coller ou pas coller et j'avais donné un cas de figure montrant la complexité de ce choix de coller du landuse à des highway: http://lists.openstreetmap.org/pipermail/talk-fr/2012-September/048373.html Et donc actuellement, je mets l'emprise de la route dans un landuse. Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Petites bizarreries sur Notre-Dame-des-Landes et Vigneux-de-Bretagne
PhQ wrote Vous avez dit bizarre ? Comme c'est ... / Bon le principe, pour sortir des landuse de corine qui s'étalent sur des zones trop grandes et de sectoriser en prenant une unité gérable, par exemple la commune. On prend alors l'utilisation majoritaire (le bocage) landuse= meadow qu'on applique à toute la commune (copie de la relation commune mais avec un landuse meadow) Ensuite on découpe ce qui n'est pas du meadow dans la relation principal avec inner et on crée des relation pour le résidentiel, les fermes etc avec le type outer. Un seul chemin (way) pour indiquer la séparation des zones (pas de chevauchement de chemin). L'inconvénient, c'est que pour être cohérent, il faut traiter toutes les zones importantes avec la technique des relations. / Personnellement je suis partisan de la simplicité. J'ai commencé à affiné les emprises agricoles jusqu'aux parties non identifiables : les fameux corridors écologiques : trames bleus et trames vertes. http://www.developpement-durable.gouv.fr/-La-Trame-verte-et-bleue,1034-.html Donc pour montrer avec le même soucis de précision l'agriculture que nous le faisons pour le bâti ou les lotissement, ça commence à donner ceci : http://www.openstreetmap.org/?lat=44.14865lon=4.82444zoom=15layers=M A terme avec des applications de type PushPin qui affiche les objets surfaciques nous pourront mettre à jour sur le terrain les activités agricoles difficiles à identifier en vue aérienne. - Cordialement, ZIMMY Jean-Louis ZIMMERMANN Développeur territorial (ville d'Orange,FR84) Mandataire OSM-France sur le Grand-Sud-est -- View this message in context: http://gis.19327.n5.nabble.com/Petites-bizarreries-sur-Notre-Dame-des-Landes-et-Vigneux-de-Bretagne-tp5742389p5742559.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Petites bizarreries sur Notre-Dame-des-Landes et Vigneux-de-Bretagne
Mémoire en défense. Au contraire, une division administrative présente (en général) une garantie de stabilité au long terme que n'a pas une chemin rural ou une petite rivière. Donc pourquoi ne pas asseoir une division sur de l'existant stable ? Certes, il faut probablement n'utiliser que JOSM pour maitriser la bête relationnelle. (Affirmation non prouvable, je n'utilise que JOSM) Une idée à long terme (très très long terme) consisterait à avoir, par commune une répartition territoriale des landuse différents et de pouvoir faire des calculs de surface respectifs de ces occupations du sol. Ceci impliquera(it) une très forte cohérence du découpage, mais donnera(it) une valeur ajoutée intéressante à la base de donnée ... à condition qu'un outil surface maitrisant les relations existe :) De toute façon, je rectifie un peu partout des découpages administratifs qui ne sont pas aux normes (outer) et enchainement., ça ne changera donc pas grand chose à la situation actuelle. Pour l'idée, ben je dépose le brevet .. en Odbl bien sur ! -- View this message in context: http://gis.19327.n5.nabble.com/Petites-bizarreries-sur-Notre-Dame-des-Landes-et-Vigneux-de-Bretagne-tp5742389p5742565.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Paray-le-Monial : une commune qui risque d'utiliser OSM pour son plan de ville
*Bonjour à toutes et à tous. @**Jean-Louis ZIMMERMANN : Voilà je viens de terminer de ' construire ' les bâtiments et les quais de la Gare de **Paray-le-Monial. J'ai fait au mieux compte-tenu de l'imagerie Bing où il y a une certaine déviation des bâtiments par rapport à la verticale. Il manque à compléter les voies ferrée de service dans l'emprise de la Gare. À voir à ce lien : http://www.openstreetmap.org/?lat=46.447244lon=4.113892zoom=18layers=M Dans l'attente de vos commentaires...** Amicales salutations. * *Olivier Griffet http://griffet.net/ | Contributeur OpenStreetMap = http://www.openstreetmap.org/user/olivier_griffet_83660_carnoules | | Habitant de 83660http://www.openstreetmap.org/export/embed.html?bbox=6.17628,43.29493,6.19694,43.30505layer=mapnikmarker=43.29837,6.18737- Carnoules http://carnoules.fr/ - Var | Adhérent de GULLIVAR et ToulonuX | Utilisateur de GNU/LINUX de Linux Mint 11 [ Gnome ] + (X)Ubuntu 12.04 [ XFCE ] ; Lives USB ASRI.EDU.2.1a ; Etc... Site web de GULLIVAR : http://gullivar.org/ Site web de ToulonuX : http://toulonux.tuxfamily.org/ * Le 3 janvier 2013 16:07, Olivier Griffet oliviergriffetli...@gmail.com a écrit : *Bonjour à toutes et à tous. @**Jean-Louis ZIMMERMANN : En visualisant le lien de la carte que tu a mis, je constate qu'il manque les bâtiments de la Gare SNCF et le nœud marquant le point d’arrêt SNCF. Je vais donc tracé ces élément avec l'imagerie Bing qui est plus tôt de bonne qualité même en zoom fort dans JOSM. Voilà, je m'y met après cette envoie de ce message. À bientôt... Amicales salutations. PS : Je présente mes meilleurs vœux pour 2013. Olivier Griffet http://griffet.net/ | Contributeur OpenStreetMap = http://www.openstreetmap.org/user/olivier_griffet_83660_carnoules | | Habitant de 83660http://www.openstreetmap.org/export/embed.html?bbox=6.17628,43.29493,6.19694,43.30505layer=mapnikmarker=43.29837,6.18737- Carnoules http://carnoules.fr/ - Var | Adhérent de GULLIVAR et ToulonuX | Utilisateur de GNU/LINUX de Linux Mint 11 [ Gnome ] + (X)Ubuntu 12.04 [ XFCE ] ; Lives USB ASRI.EDU.2.1a ; Etc... Site web de GULLIVAR : http://gullivar.org/ Site web de ToulonuX : http://toulonux.tuxfamily.org/ * - Le 3 janvier 2013 15:09, ZIMMY jeanlouis.zimmerm...@laposte.net a écrit : Bonjour à tous, Je suis en contact avec plusieurs personnes sur Paray le Monial qui est un haut lieu spirituel en France avec plusieurs milliers de pélerins par an. Le service des pèlerinage n'a pas de plan dynamique et multilingue et la mairie s'oriente vers le prochain recensement de la population avec peine : il leur manque un plan de ville précis. Je dois avoir des échanges dans les semaines qui viennent pour concrétiser l'appropriation sur les deux niveaux : tourisme spirituel et municipal. Pour ceux qui se sentent de m'épauler : j'ai besoin d'un coup de main pour affiner la carte : - emprise des zones urbaines - nommage des voies - qualification des équipements majeurs - autres inspirations Voici la commune : http://www.openstreetmap.org/?lat=46.4503lon=4.1154zoom=14layers=M Merci d'avance - Cordialement, ZIMMY Jean-Louis ZIMMERMANN Développeur territorial (ville d'Orange,FR84) Mandataire OSM-France sur le Grand-Sud-est -- View this message in context: http://gis.19327.n5.nabble.com/Paray-le-Monial-une-commune-qui-risque-d-utiliser-OSM-pour-son-plan-de-ville-tp5742488.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Paray-le-Monial : une commune qui risque d'utiliser OSM pour son plan de ville
Je peux m'atteler ce soir à partir de 20h à l'ajout des noms de rues depuis le cadastre. Mais si quelqu'un d'autre veut le faire, je peux aussi contribuer ailleurs... ;-) Nicolas ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Paray-le-Monial : une commune qui risque d'utiliser OSM pour son plan de ville
De : Olivier Griffet oliviergriffetli...@gmail.com Voilà je viens de terminer de ' construire ' les bâtiments et les quais de la Gare de Paray-le-Monial. J'ai fait au mieux compte-tenu de l'imagerie Bing où il y a une certaine déviation des bâtiments par rapport à la verticale. Salut, Une petite question, pourquoi ne pas avoir utilise le cadastre pour tracer le batiment ? il semble vectorise pour cette commune et cela evite les problemes de deviation des batiments par rapport a la vertical du aux images aeriennes ( si le cadastre est bien cale en position bien sur) Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Paray-le-Monial : une commune qui risque d'utiliser OSM pour son plan de ville
*Bonjour à toutes et à tous. @** Julien THEVENON :* ** * En réponse à ton questionnement à propos du cadastre sur la commune de ** Paray-le-Monial, je viens de vérifier que le cadastre vectoriel de cette commune ignore toute la zone de l'emprise de la Gare SNCF de **Paray-le-Monial. Voilà pourquoi j'ai utilisé l'imagerie Bing qui est plus tôt bonne même à fort zoom dans JOSM. Reste à affiner l'ensemble de cette zone **de la Gare SNCF de Paray-le-Monial. Amicales salutations. Olivier Griffet http://griffet.net/ | Contributeur OpenStreetMap = http://www.openstreetmap.org/user/olivier_griffet_83660_carnoules | | Habitant de 83660http://www.openstreetmap.org/export/embed.html?bbox=6.17628,43.29493,6.19694,43.30505layer=mapnikmarker=43.29837,6.18737- Carnoules http://carnoules.fr/ - Var | Adhérent de GULLIVAR et ToulonuX | Utilisateur de GNU/LINUX de Linux Mint 11 [ Gnome ] + (X)Ubuntu 12.04 [ XFCE ] ; Lives USB ASRI.EDU.2.1a ; Etc... Site web de GULLIVAR : http://gullivar.org/ Site web de ToulonuX : http://toulonux.tuxfamily.org/ * -- Le 3 janvier 2013 18:20, THEVENON Julien julien_theve...@yahoo.fr a écrit : * De :* Olivier Griffet oliviergriffetli...@gmail.com * **Voilà je viens de terminer de ' construire ' les bâtiments et les quais de la Gare de **Paray-le-Monial.* ***J'ai fait au mieux compte-tenu de l'imagerie Bing où il y a une certaine déviation des bâtiments par rapport à la verticale.* Salut, Une petite question, pourquoi ne pas avoir utilise le cadastre pour tracer le batiment ? il semble vectorise pour cette commune et cela evite les problemes de deviation des batiments par rapport a la vertical du aux images aeriennes ( si le cadastre est bien cale en position bien sur) Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] problème overpass-api et area-query sur une relation
Salut, Je ne comprends pas ce qui peut bien se passer... Me voici donc arrivé ici ;-) Je cherche à récupérer tous les arrêts de bus dans l'agglo de Tours en interrogeant la base de données via l'overpass-api http://overpass-api.de qui supporte les requêtes avec une limite de recherche sur une zone (area-query). Pour allez direct au problème, la même requête fonctionne avec une relation mais pas avec une autre. La relation ok est celle du Viêt Nam (http://osm.org/browse/relation/49915) et celle qui ne fonctionne pas, disons qui ne retourne aucun résultat, est celle de l'agglomération tourangelle (http://osm.org/browse/relation/1663056). Donc la requête osm-script query type=node area-query ref=3600049915/ has-kv k=highway v=bus_stop/ /query print mode=meta/ /osm-script retourne bien des données, alors que celle-ci n'en retourne aucune : osm-script query type=node area-query ref=3601663056/ has-kv k=highway v=bus_stop/ /query print mode=meta/ /osm-script J'ai essayé avec has-kv k=place / et c'est pareil. J'ai regardé la relation 1663056 avec http://analyser.openstreetmap.fr/ mais rien de signalé. Je l'ai chargée dans Josm et rien de remarquable. Auriez vous une piste de recherche ? Merci beaucoup. -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] INSEE, recensement 2010 et mise à jour de la population des communes
On trouve aussi population:date=2009 en plus de population=n Ce qui laisse la source stable (INSEE en France : est-ce utile de mentionner aussi source:population=INSEE puisque c'est la seule référence fiable en France ?) Il me semble que le census n'est plus d'actualité en France où on se base sur les population légales, ajustées chaque année par estimation (même si les règles ont changé concernant les double comptes ou comptes à part pour certaines populations résidant temporairement dans d'autres communes sans que ce soit leur domicile officiel), le recensement ayant lieu à une période donnée mais réajusté ensuite pour la définition de la population légale l'année suivante. Il n'y a plus de recensement général de la population en France et je me demande s'il a effectivement jamais existé depuis des décennies (JAMAIS je n'ai été recensé de ma vie alors que c'était des années où on était sensé être recensé dans une commune donnée). L'INSEE visiblement ne fait que des sondages estimatifs et croise visiblement des fichiers pour estimer la population légale selon quelques critères de corrélation (par exemple les listes électorales, les inscriptions dans les écoles primaires publiques, les fichiers de la sécurité sociale ou ceux des impôts sur le revenu et les impôts locaux ou taxe d'habitation et redevance télé, ou l'annuaire universel pour la téléphonie fixe, ou les inscriptions aux Pôle Emploi et aux registres du commerce, ou ceux de la Poste). Même si ce n'est plus un recensement général depuis longtemps cela reste un sondage massif et statistiquement assez parlant pour compléter les trous avec une très bonne précision, mais on n'en est plsu à savoir s'il y a 1 ou 2 habitants de plus dans une commune. JE me demande juste quel est le taux de population interrogée réellement sur le terrain mais il est certainement très loin de tout ce qui est annoncé (et ne doit même pas effleurer les 50%. Le 3 janvier 2013 16:11, Francescu GAROBY windu...@gmail.com a écrit : Bonjour, Suite à quelques articles de médias locaux ( Coté Caen, Tendance Ouest, ...) parlant de la parution des chiffres du recensement mené en 2010 par l'INSEE, je voulais mettre à jour ces infos sur les communes de ma région. Or, je remarque une grande hétérogénéité dans les tags : en plus du tag population=XYZ, on trouve des fois census=20XX (qui semble être un tag surtout utilisé aux États-Unis, avec TIGER), d'autres fois source:population=INSEE 20XX, d'autres fois encore rien... En cherchant dans le wiki, j'ai vu qu'il y avait eu une proposition de tag acceptée pour population, mais rien d'arrêté concernant la source. Savez-vous si une méthode est plus plébiscitée que d'autres ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Paray-le-Monial : une commune qui risque d'utiliser OSM pour son plan de ville
Merci Nicolas de ton aide précieuse. Je reprendrai là où il y aura des trous. Pour ce qui est de la gare, merci à Olivier qui a vertueusement enrichi le secteur de la gare. Il y a enfin quelques lotissements qui n'ont pas été numérisés. A priori j'ai déjà un retour pour un échange la semaine prochaine. Belle soirée Jean-lOUIS Nicolas Moyroud wrote Je peux m'atteler ce soir à partir de 20h à l'ajout des noms de rues depuis le cadastre. Mais si quelqu'un d'autre veut le faire, je peux aussi contribuer ailleurs... ;-) Nicolas - Cordialement, ZIMMY Jean-Louis ZIMMERMANN Développeur territorial (ville d'Orange,FR84) Mandataire OSM-France sur le Grand-Sud-est -- View this message in context: http://gis.19327.n5.nabble.com/Paray-le-Monial-une-commune-qui-risque-d-utiliser-OSM-pour-son-plan-de-ville-tp5742488p5742587.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Petites bizarreries sur Notre-Dame-des-Landes et Vigneux-de-Bretagne
Le 3 janvier 2013 11:36, Christian Quest cqu...@openstreetmap.fr a écrit : C'est très clean en théorie, mais dans la pratique ça me semble un peu fragile. Je ne pense pas que ce soit une bonne idée d'utiliser les même way pour décrire un découpage administratif et une occupation du sol, le premier évoluant peu, le second évoluant bien plus souvent, on risque d'avoir des découpages administratifs modifiées par une édition de landuse... la réparation de nombreux découpages administratifs suite à ce genre de manip par un contributeur qui avait suivit une fausse bonne idée noyée dans un mail de Philippe Verdy me laisse de douloureux souvenir dans le poignet droit. Je rejoins Chrisitian sur le problème d'associer les limites administratives et les descriptions du terrain. Tout les mappeurs ne font pas (encore) attention qu'un way est utilisé pour plusieurs données et le déplace sans faire les séparations nécessaire. Séparations qui sont d'ailleurs bien souvent galère à opérer. Cyrille. Qui a eu cette idée ? Le 3 janvier 2013 10:52, PhQ pierre.que...@sfr.fr a écrit : Vous avez dit bizarre ? Comme c'est ... Bon le principe, pour sortir des landuse de corine qui s'étalent sur des zones trop grandes et de sectoriser en prenant une unité gérable, par exemple la commune. On prend alors l'utilisation majoritaire (le bocage) landuse= meadow qu'on applique à toute la commune (copie de la relation commune mais avec un landuse meadow) Ensuite on découpe ce qui n'est pas du meadow dans la relation principal avec inner et on crée des relation pour le résidentiel, les fermes etc avec le type outer. Un seul chemin (way) pour indiquer la séparation des zones (pas de chevauchement de chemin). L'inconvénient, c'est que pour être cohérent, il faut traiter toutes les zones importantes avec la technique des relations. -- View this message in context: http://gis.19327.n5.nabble.com/Petites-bizarreries-sur-Notre-Dame-des-Landes-et-Vigneux-de-Bretagne-tp5742389p5742414.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Données historique et historiques des données...
Le 3 janvier 2013 13:15, Vincent de Chateau-Thierry v...@laposte.net a écrit : De : Christian Quest Je dévie le fil vers une notion d'historique... Il y a une réflexion actuelle sur l'intégration de données historiques dans OSM, une liste dédiée a même été créée (historic). Plutôt que de supprimer ce genre de relation, ne pourrait-on pas en garder au moins une trace ? L'un n'empêche pas l'autre, dès lors que la trace gardée est stockée hors de la base OSM. J'ai une ébauche de commencement de réflexion sur des tags adaptés... où l'on pourrait intégrer un intervalle de temps à un tag à l'aide d'une notation du type [debut:fin], exemple: name[:1970]=Place de l'Etoile name=Place Charles de Gaulle Mais dans ce cas, ne faudrait-il pas : name[1970:]=Place Charles de Gaulle ? Et là ça devient coton à gérer... Ce serait intéressant pour des objets toujours existants, mais ayant évolué dans un passé récent. Ces tags à suffixe temporel ne peuvent pas être confondus avec des tags actuels, et permettent de couvrir plusieurs intervalles (ce que ne permet pas old_name). A charge pour ceux qui veulent les exploiter de les traiter selon leur besoin, mais au moins l'info est là et utilisable plutôt que de disparaitre. Qu'en pensez-vous ? Disposer de données datées rajouterait évidemment de l'intérêt, mais avec le paradigme de l'api v0.6 (tout dans une même base) la concrétisation me semble assez effrayante. On gère 2 dimensions correctement, la 3è a déjà un peu de mal à émerger (les souterrains, les étages de bâtiments, l'indoor en général) alors la 4è par dessus tout ça, côté gestion / édition, aïe. Et comme déjà dit dans ce fil, faute de référence actuelle, vérifiable, la fragilité de ces données me semble encore supérieure, face au besoin de maintenance (cf. les cas quotidiens de relations admin cassées, pour prendre un exemple dans le même contexte que l'EPCI qu'on efface aujourd'hui). Bref, je suis pour mais soit en dehors de la base OSM (au moins en api v0.6) soit au prix d'un changement assez radical d'organisation des données, avec l'émergence de meta-données telles ici des dates de validité qu'on appliquerait aux données elles- mêmes. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr Aïe aïe aïe ... Une bonne base bien à jour et cohérente c'est ça qu'il nous faut. Atteignons déjà cet objectif avant de réfléchir à cette 4 ème dimension. De plus, il y a tellement de tags et de façon de les interpréter, qu'il est déjà assez difficile de maitriser la bête, alors mollo sur la créativité s'il vous plait. ;-) Cyrille. -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] suppression d'une zone de construction....
Bonsoir à tous, Le jeudi 03 janvier 2013 16:41:21, sly (sylvain letuffe) a écrit : On jeudi 3 janvier 2013, Pieren wrote: 2013/1/3 Christian Rogel christian.ro...@club-internet.fr: Je pense aussi que le balisage précédent la suppression n'était pas approprié tant que les travaux n'ont pas débuté sur le terrain. Je suis d'accord avec ça. Étant le contributeur initial de ce way, je suis également d'accord que le choix des tags n'était pas très judicieux :) Maintenant, on devrait quand même restaurer le polygone mais avec des tags plus appropriés pour dire ce que Christian mentionne, genre landuse=greenfield ? d'après le wiki A greenfield is scheduled to turn into a construction site. [...] Pour ma part, je pense que les projets d'historiques et de projection du futur ne devrait pas, en l'état des outils et de la base, appartenir à OSM, mais à un autre projet ou tout du moins, une autre base. Les ajouter à OSM, en l'état des choses, ne ferait que compliquer une activité de mapping déjà bien compliquée pour des débutants. Difficile de répondre sur un aspect très général, c'est en effet très compliqué de définir ce qui va et ce qui ne va pas dans la base de données (et ce débat apparait régulièrement sous une forme ou une autre sur cette liste). Mais pour en revenir à cet exemple, 1/ j'ai connaissance de plusieurs utilisations faites de ces données (par des journalistes notamment) 2/ la suppression arbitraire de ces données par ZAD est pour moi un vandalisme avéré 3/ je m'intéresse au projet NDDL et je vais donc maintenir ce/ces objets sur la durée Je propose de réinjecter ce tracé en utilisant le tag proposed qui me semble en effet plus approprié : http://wiki.openstreetmap.org/wiki/Key:proposed This key can be used for any feature that is still in planning phase but constructions haven't yet started. Qu'en pensez-vous ? Librement, -- Damien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Numéro de rue ?
Sachant que la version latest de JOSM embarque un certain nombre de contrôles de validation (directement pompés de Osmose) sur les adresses qui suivent la méthode associatedStreet (doublons, distance à la rue, etc.) ça permet d'éviter des erreurs vu que ces checks sont effectués par défaut avant l'upload :) Le 3 janvier 2013 16:33, Pieren pier...@gmail.com a écrit : 2013/1/3 Xavier x.larc...@laposte.net: Corrigez moi si je me trompe, mais je suppose que le N° 20 est trop éloigné de la rue pour qu'il soit automatiquement associé à elle. C'est un peu plus compliqué que ça. Comme on le voit ici http://nominatim.openstreetmap.org/details.php?place_id=3670662157 il reconnait le 19, le 21 mais pas le 20. Parce que comme tu n'as pas mis de tag addr:street, ni de relation de type associatedStreet, nominatim n'est pas capable de dire si le 20 appartient à cette rue ou à la rue adjacente. C'est bien un problème de distance, mais de distance entre deux rues. Le mieux est de systématiquement tagguer ensemble numéro ET rue au minimum, avec l'une des deux méthodes sus-mentionnées. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Communes nouvelles
Le 03/01/2013 11:40, Vincent de Chateau-Thierry a écrit : Au niveau national, peut-être du côté du JO ? Je dis ça mais je n'en sais rien. Sinon pour rappel, l'INSEE diffuse la liste et la composition des EPCIs dans un fichier téléchargeable ici : http://insee.fr/fr/methodes/default.asp?page=zonages/intercommunalite.htm mais avec un gros bémol : les données ont +/- 1 an de retard, donc impossible d'y trouver aujourd'hui les modifs opérées au 01/01/2013. Sinon Banatic ( http://www.banatic.interieur.gouv.fr/Banatic2/ ) a des mises à jour trimestrielles mais il y a des restrictions sur l'usage des données : http://www.banatic.interieur.gouv.fr/Banatic2/static/ba-Infos-legales.htm qui concrètement empêchent qu'on s'en serve comme source. De mon côté, j'utilise un mix entre les fichiers de l'INSEE (pour le ref:INSEE justement) et les infos trouvées, le plus souvent, sur les sites web des EPCIs (beaucoup en ont) pour valider la liste des communes membres. On trouve aussi des docs sur les sites des préfectures, lorsque des décisions de fusion/adhésion sont prises à ce niveau. Bref, c'est un peu la pêche à droite à gauche... vincent Il ne faudra rien attendre du niveau national puisque ces décisions sont de l'ordre de l'arrêté préfectoral (mise en oeuvre des schémas départementaux de coopération intercommunale). Donc la source officielle est le RAA (Recueil des Actes Administratifs), document réutilisable, sans restrictions légales (hormis la mention de source, comme le veut la Loi). D'ailleurs le schéma départemental de coopération intercommunale est un document en lui-même indiquant l'état futur (souhaité) des EPCI. Il faut juste attendre que les arrêtés soient pris pour officialiser la fusion de CC ou le rattachement de communes isolées, etc. J'ai maintenu pendant de nombreuses années une base de données sur l'intercommunalité à fiscalité propre en Alsace ; je parle d'expérience. Si on est pas pressé, il reste banatic qui fera le boulot en double. Denis exemples de schéma départemental de coopération intercommunale : http://www.bas-rhin.gouv.fr/site/Commission-departementale-de-cooperation-intercommunale-567.html de RAA : http://www.bas-rhin.pref.gouv.fr/site/RAA-du-Bas-Rhin-37.html ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] [forum-osm-fr] Je souhaite ajouter plusieures commune manquante
Le message suivant de : ## Bonsoir, En vu de créer correctement la 2° circonscription de l'Aude, il manque plusieurs communes et canton. Je souhaite donc les ajouter en utilisant http://cadastre.openstreetmap.fr/ Afin d'avoir l'aval sur la méthode que je vais utiliser voici ce que ça va donner pour chaque commune : 1 - Recherche de commune manque sur http://osm7.openstreetmap.fr/~vincentpottier/comcom/ 2 - Recherche de la commune sur Wikipédia pour récupérer la ref:INSEE et le code postal 3 - Importation du fichier *-city-limit.osm Avant envoi : 1 - Vérification d'erreur avec l'outil de validation de donnée 2 - Chargement de toute les limites de commune voisine à la zone de travail pour vérifier les éventuels décalage ou erreur 3 - Si tout est correct, envoi en ligne sur OSM Je pense avoir le bon raisonnement de travail mais sachant que cela va créer au minimum 5 communes (probablement plus) je préfère avoir une confirmation a été posté sur le forum http://forum.openstreetmap.fr/viewforum.php?f=2 Une réponse par mail sur l'adresse d'expédition n'arrivera nulle part Une réponse à la liste ne sera pas transmise au forum, ce qui n'empêche pas une concertation sur la liste avant de recopier la/les meilleurs réponses sur le forum. Notez qu'il n'est pas necessaire d'avoir un compte sur le forum pour répondre. -- Les questions sur ce robot de transfert forum-liste peuvent être posées à sylvainaletuffe.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Numéro de rue ?
Le 3 janvier 2013 15:24, Romain MEHUT romain.me...@gmail.com a écrit : Le 3 janvier 2013 15:11, Xavier x.larc...@laposte.net a écrit : Bonjour, Je me lance dans la numérotation des habitations de mon village. http://www.openstreetmap.org/?lat=49.38994lon=4.656808zoom=18layers=M Pour le moment je n'ai fait qu'ajouter le tag addr:housenumber Les numéro apparaissent bien sur OSM. Lorsque je fais une recherche par exemple : 7 rue de richecourt blaise, pas de problème. Mais si je fais la recherche 20 rue henri rouyer blaise, OSM trouve bien la rue mais pas le numéro. Corrigez moi si je me trompe, mais je suppose que le N° 20 est trop éloigné de la rue pour qu'il soit automatiquement associé à elle. Ma question est donc : Comment associer toutes les habitations d'une rue à un nom de rue ? Avec addr:street pour chaque maison ? Avec une relation ? Comment faire ? Merci d'avance pour vos lumières. Regarde ici http://osm.org/go/0DEYk_hE_-- pour prendre exemple. Il te suffit d'utiliser l'outil d'aide pour l'adresse du greffon cadastre pour créer très facilement les relations associatedStreet. Perso, j'ai pris pour habitude de mettre les numéros non pas sur l'ensemble du polygone mais sur un nœud soit solidaire sur un côté du polygone soit isolé de façon à matérialiser l'emplacement de la boite aux lettres. Je viens appuyer l'explication de Romain. Mettre le numéro de la rue au plus près de l'entrée du lieu et non pas sur le bâti. C'est plus facile à trouver et plus simple à mapper, surtout quand il y a plusieurs bâtiments pour la même adresse, ou que le bâti se trouve loin de l'entrée, ou ... Cyrille. Romain Corneliux ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] [forum-osm-fr] Erreur indiqué par JOSM concernant un point géodésique
Le message suivant de : ## Lors d'un envoi j'ai reçu un message concernant le nom d'un point géodésique et sa localisation. Sachant qu'il ne faut pas y toucher, je refile le bébé à qui de droit. Cela concerne http://www.openstreetmap.org/browse/relation/465476 Le note comporte une erreur qui existe sur beaucoup de carte en ligne que différent site on du ce recopier (Google, Waze, Michelin entre autre). Le nom n'est pas le[b]v[/b]rette mais le[b]b[/b]rette. Ensuite le tag name = Marcorignan B est étrange car la limite de la commune est à plusieurs kilomètre. Il est probable que cela soit normal mais je préfère remonter cette information. a été posté sur le forum http://forum.openstreetmap.fr/viewforum.php?f=5 Une réponse par mail sur l'adresse d'expédition n'arrivera nulle part Une réponse à la liste ne sera pas transmise au forum, ce qui n'empêche pas une concertation sur la liste avant de recopier la/les meilleurs réponses sur le forum. Notez qu'il n'est pas necessaire d'avoir un compte sur le forum pour répondre. -- Les questions sur ce robot de transfert forum-liste peuvent être posées à sylvainaletuffe.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modélisation du réseau électrique français
Le 3 janvier 2013 13:49, François Lacombe francois.laco...@telecom-bretagne.eu a écrit : Le 3 janvier 2013 11:12, David Crochet david.croc...@online.fr a écrit : Est-ce que RTE applique des informations de réseau d'énergie indépendant du réseau physique comme le fait la SCNF qui applique un numéro de ligne (le Paris-Granville) indépendant des voies physique mais liés quand même ? Dans ce cas, pas la peine de simuler la présence de plusieurs réseaux au sein d'un même « chemin » puisque la relation va faire le tri correctement dans ce cas Si les voies SNCF correspondent aux files de pylônes alors la réponse est oui. Pour la SNCF, il y a des relations route=train pour décrire les trains qui circulent sur les route=railway qui sont les infrastructures des lignes elles même. Les premiers sont liés à la SNCF, les seconds en réalité à RFF. François, ton TOC* est déjà identifié: les pylônes électrique car dans ces relations, il n'y a pas de pylônes... certaines lignes ferroviaires n'étant toujours pas électrifiées ;) RTE ne connait même que le circuit qui est codifié selon le nom des postes aux extrémités et suivant un ordre numérique (plusieurs circuits peuvent correspondre aux mêmes extrémités). Les files de pylônes ne sont pas codifiées en tant qu'artère, par contre les pylônes possèdent des numéros (selon un des circuits supportés je crois) Je suis aussi d'accord pour dire que la relation réifie correctement le circuit, il faut que tout s'ordonne dans ma tête surtout :) Il peut exister des cas particuliers : les piquages. C'est le cas à Montchanin : http://goo.gl/maps/fjdKy Le circuit de gauche se voit ponctionner vers le poste électrique tout proche. Là, le modèle d'OSM à base de relation permet de traiter ce cas avec un tag via= par contre je ne sais pas comment RTE fait puisque le circuit n'a pas 2 mais 3 extrémités. D'ailleurs les apparences sont parfois trompeuses puisque ce circuit est construit en techno 400 kV mais n'accepte en réalité que du 225 kV (cf le piquage et les cartes de RTE). Le 400 kV arrive prochainement. http://www.rte-france.com/fr/nos-activites/nos-projets/bourgogne/les-projets-en-cours-en-bourgogne Car « power=cable » sous entend implicitement « layer = -1 » ce qui évite par exemple à un logiciel de dire qu'un câble croisent sans connexion une ligne. alors qu'il n'ont pas le layer indiqué Je ne comprends pas très bien cette histoire de layer. Deux ways peuvent se croiser, elles ne seront connectées que si elles ont un node en commun à l'endroit du croisement. Pourquoi vouloir hiérarchiser de cette façon? Une habitude qui vient des routes, l'une passe forcément sur l'autre et layer permet d'indiquer qui est dessus, qui est dessous ce qui n'est pas forcément sans intérêt, car dans la réalité c'est quand même bien comme ça. Mais très peu visible sauf les balises au sol indiquant la présence d'un réseau souterrain Ce que je voulais dire est qu'un contributeur OSM pourra faire la carto d'une artère BTB aérienne qui disparaitra 15 jours plus tard sous le coup d'une dissimulation de réseau. La capillarité fait que les zones à surveiller sont multiples sans avoir une visibilité correcte sur les projets des concessionnaires de ces réseaux. Sur la HTB (et ca démarre un peu sur la HTA) les projets sont connus et les travaux bien plus voyant. C'est juste une question de capacité de mise à jour, sinon on est bien d'accord que le max de données disponibles reste l'objectif. C'est une question qui revient pour quasiment tout type de données: a-t-on les moyens de les maintenir à jour ? Cette question se pose logiquement le plus pour des données qui vont dans le détail. *TOC = Trouble Obsessionnel Cartographique -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] INSEE, recensement 2010 et mise à jour de la population des communes
Le 3 janvier 2013 16:43, Vincent de Chateau-Thierry v...@laposte.net a écrit : Maintenant, la cible, c'est, plutôt qu'à la main, le passage, au moins une fois l'an, d'un bot qui ajouterait ou mettrait à jour le tag population, sur la foi des résultats de recensement publiés par l'INSEE. Une fois cette mécanique en place, il n'y aura plus de valeur ajoutée à faire ça à la main. Et on s'économisera :-) Cela fait partie des choses que l'INSEE envisage de faire EUX MEME :) Maintenir à jour dans OSM les informations qu'il produisent. Cela fait partie des discussions que j'ai eu le mois dernier lors d'une première réunion informelle. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Petites bizarreries sur Notre-Dame-des-Landes et Vigneux-de-Bretagne
Le 3 janvier 2013 17:54, PhQ pierre.que...@sfr.fr a écrit : Mémoire en défense. Au contraire, une division administrative présente (en général) une garantie de stabilité au long terme que n'a pas une chemin rural ou une petite rivière. Donc pourquoi ne pas asseoir une division sur de l'existant stable ? Certes, il faut probablement n'utiliser que JOSM pour maitriser la bête relationnelle. (Affirmation non prouvable, je n'utilise que JOSM) C'est quasiment ingérable avec des outils tels que Potlatch. Le risque est donc grand qu'en utilisant le même way, on déplace sans le vouloir bien plus de choses que ce que l'on croit. Ca m'est arrivé avec JOSM à mes débuts et ça doit encore m'arriver quand j'ai plus les yeux complètement en face des trous. Une idée à long terme (très très long terme) consisterait à avoir, par commune une répartition territoriale des landuse différents et de pouvoir faire des calculs de surface respectifs de ces occupations du sol. Un calcul totalisant les différentes surface de landuse pour une commune, voire même en donnant leur pourcentage respectif ? Tu ne connais pas etat-commune ? Exemple: http://openstreetmap.fr/outils/etat-commune?insee=89400 Ceci impliquera(it) une très forte cohérence du découpage, mais donnera(it) une valeur ajoutée intéressante à la base de donnée ... à condition qu'un outil surface maitrisant les relations existe :) De toute façon, je rectifie un peu partout des découpages administratifs qui ne sont pas aux normes (outer) et enchainement., ça ne changera donc pas grand chose à la situation actuelle. Ce n'est pas trop gênant que l'outer manque où qu'ils ne soient pas ordonnés, les algos s'y retrouvent, mais c'est vrai que c'est plus propre à maintenir pour les humains et je le fais aussi quasiment systématiquement sur les relations que je modifie, au moins afin de vérifier qu'elles ferment toujours bien après mes modifs. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] problème overpass-api et area-query sur une relation
Le 3 janvier 2013 19:02, Cyrille Giquello cyrill...@gmail.com a écrit : Salut, Je ne comprends pas ce qui peut bien se passer... Me voici donc arrivé ici ;-) Je cherche à récupérer tous les arrêts de bus dans l'agglo de Tours en interrogeant la base de données via l'overpass-api http://overpass-api.de qui supporte les requêtes avec une limite de recherche sur une zone (area-query). Pour allez direct au problème, la même requête fonctionne avec une relation mais pas avec une autre. La relation ok est celle du Viêt Nam (http://osm.org/browse/relation/49915) et celle qui ne fonctionne pas, disons qui ne retourne aucun résultat, est celle de l'agglomération tourangelle (http://osm.org/browse/relation/1663056). Donc la requête osm-script query type=node area-query ref=3600049915/ has-kv k=highway v=bus_stop/ /query print mode=meta/ /osm-script retourne bien des données, alors que celle-ci n'en retourne aucune : osm-script query type=node area-query ref=3601663056/ has-kv k=highway v=bus_stop/ /query print mode=meta/ /osm-script J'ai essayé avec has-kv k=place / et c'est pareil. J'ai regardé la relation 1663056 avec http://analyser.openstreetmap.fr/ mais rien de signalé. Je l'ai chargée dans Josm et rien de remarquable. Auriez vous une piste de recherche ? Merci beaucoup. Il me semble que la raison est très simple et expliquée ici : http://wiki.openstreetmap.org/wiki/Overpass_API/Areas Les areas sont définis avec des critères en dur auxquels la relation en question ne correspond pas ... dommage. -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Données historique et historiques des données...
Au moins l'avantage avec des données anciennes, c'est qu'elles sont stables ;) -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] suppression d'une zone de construction....
proposed, me semble le tag adapté. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Numéro de rue ?
Le 3 janvier 2013 22:14, Cyrille Giquello cyrill...@gmail.com a écrit : Je viens appuyer l'explication de Romain. Mettre le numéro de la rue au plus près de l'entrée du lieu et non pas sur le bâti. C'est plus facile à trouver et plus simple à mapper, surtout quand il y a plusieurs bâtiments pour la même adresse, ou que le bâti se trouve loin de l'entrée, ou ... Et ça évite des questions existentielles lorsqu'il y a plusieurs bâtiments à la même adresse... Je ne met des adresses sur les polygones que pour les bâtiments éloignés de la rue, par exemple dans une résidence avec plusieurs immeubles où le cadastre met justement un numéro au milieu du bâtiment et pas sur l'entrée. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] suppression d'une zone de construction....
Le jeudi 03 janvier 2013 20:53:40, Damien Raude-Morvan a écrit : Difficile de répondre sur un aspect très général, c'est en effet très compliqué de définir ce qui va et ce qui ne va pas dans la base de données (et ce débat apparait régulièrement sous une forme ou une autre sur cette liste). C'est vrai... et c'est pas près de finir puisque chacun a sa propre limite ;-) Je propose de réinjecter ce tracé en utilisant le tag proposed qui me semble en effet plus approprié : http://wiki.openstreetmap.org/wiki/Key:proposed This key can be used for any feature that is still in planning phase but constructions haven't yet started. Qu'en pensez-vous ? ça me paraît pas trop mal comme le bon compromis. Si j'ai bien compris la proposition ça donne : aeroway=proposed + proposed=aerodrome Toutefois, bien qu'acceptable à mon goût, j'eu préféré volontiers la méthode du style http://wiki.openstreetmap.org/wiki/Key:abandoned Qui évite l'éventuelle mauvaise interprétation du tag principal. Ce qui aurait pu donner : proposed:aeroway=aerodrome En un seul tag au lieu de deux. -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] problème overpass-api et area-query sur une relation
Cyrille Tu dis Les areas sont définis avec des critères en dur auxquels la relation en question ne correspond pas ... dommage. puisque tu sembles comprendre ce charabia, tu nous traduit en termes plus clairs,pour nous éviter de faire trop de boucles inutiles? Pierre De : Cyrille Giquello cyrill...@gmail.com À : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Jeudi 3 janvier 2013 17h27 Objet : Re: [OSM-talk-fr] problème overpass-api et area-query sur une relation Le 3 janvier 2013 19:02, Cyrille Giquello cyrill...@gmail.com a écrit : Salut, Je ne comprends pas ce qui peut bien se passer... Me voici donc arrivé ici ;-) Je cherche à récupérer tous les arrêts de bus dans l'agglo de Tours en interrogeant la base de données via l'overpass-api http://overpass-api.de qui supporte les requêtes avec une limite de recherche sur une zone (area-query). Pour allez direct au problème, la même requête fonctionne avec une relation mais pas avec une autre. La relation ok est celle du Viêt Nam (http://osm.org/browse/relation/49915) et celle qui ne fonctionne pas, disons qui ne retourne aucun résultat, est celle de l'agglomération tourangelle (http://osm.org/browse/relation/1663056). Donc la requête osm-script query type=node area-query ref=3600049915/ has-kv k=highway v=bus_stop/ /query print mode=meta/ /osm-script retourne bien des données, alors que celle-ci n'en retourne aucune : osm-script query type=node area-query ref=3601663056/ has-kv k=highway v=bus_stop/ /query print mode=meta/ /osm-script J'ai essayé avec has-kv k=place / et c'est pareil. J'ai regardé la relation 1663056 avec http://analyser.openstreetmap.fr/ mais rien de signalé. Je l'ai chargée dans Josm et rien de remarquable. Auriez vous une piste de recherche ? Merci beaucoup. Il me semble que la raison est très simple et expliquée ici : http://wiki.openstreetmap.org/wiki/Overpass_API/Areas Les areas sont définis avec des critères en dur auxquels la relation en question ne correspond pas ... dommage. -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Paray-le-Monial : une commune qui risque d'utiliser OSM pour son plan de ville
Le 03/01/2013 20:11, ZIMMY a écrit : Merci Nicolas de ton aide précieuse. Je reprendrai là où il y aura des trous. Avec plaisir. Je me suis bien amusé ce soir malgré quelques inévitables petits conflits quand on bosse à plusieurs sur la même zone. Je crois qu'il ne va pas rester beaucoup de trous à combler dans les noms de rues. ;-) Maintenant, au lit... :-) a+ Nicolas ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] problème overpass-api et area-query sur une relation
Le 4 janvier 2013 00:46, Pierre Béland infosbelas-...@yahoo.fr a écrit : Cyrille Tu dis Les areas sont définis avec des critères en dur auxquels la relation en question ne correspond pas ... dommage. puisque tu sembles comprendre ce charabia, tu nous traduit en termes plus clairs,pour nous éviter de faire trop de boucles inutiles? [image: *B-) Relax, Max] Ce areas est un raccourci en rapport direct avec le précédent message dans le fil. Le 1er message expliquait le problème rencontré avec une requête overpass-api et la clause area-query / et le second message (très court) indiquait un lien vers la page où l'on trouve l'explication. Cette page ayant pour titre Areas je l'ais reprit tout simplement (et succinctement). Après, si on ne comprend pas plus, ce n'est pas grave du tout, c'est tout simplement que l'on ne connait pas l'overpass-api ;-) Cyrille. Pierre -- *De :* Cyrille Giquello cyrill...@gmail.com *À :* Discussions sur OSM en français talk-fr@openstreetmap.org *Envoyé le :* Jeudi 3 janvier 2013 17h27 *Objet :* Re: [OSM-talk-fr] problème overpass-api et area-query sur une relation Le 3 janvier 2013 19:02, Cyrille Giquello cyrill...@gmail.com a écrit : Salut, Je ne comprends pas ce qui peut bien se passer... Me voici donc arrivé ici ;-) Je cherche à récupérer tous les arrêts de bus dans l'agglo de Tours en interrogeant la base de données via l'overpass-api http://overpass-api.de qui supporte les requêtes avec une limite de recherche sur une zone (area-query). Pour allez direct au problème, la même requête fonctionne avec une relation mais pas avec une autre. La relation ok est celle du Viêt Nam (http://osm.org/browse/relation/49915) et celle qui ne fonctionne pas, disons qui ne retourne aucun résultat, est celle de l'agglomération tourangelle (http://osm.org/browse/relation/1663056). Donc la requête osm-script query type=node area-query ref=3600049915/ has-kv k=highway v=bus_stop/ /query print mode=meta/ /osm-script retourne bien des données, alors que celle-ci n'en retourne aucune : osm-script query type=node area-query ref=3601663056/ has-kv k=highway v=bus_stop/ /query print mode=meta/ /osm-script J'ai essayé avec has-kv k=place / et c'est pareil. J'ai regardé la relation 1663056 avec http://analyser.openstreetmap.fr/ mais rien de signalé. Je l'ai chargée dans Josm et rien de remarquable. Auriez vous une piste de recherche ? Merci beaucoup. Il me semble que la raison est très simple et expliquée ici : http://wiki.openstreetmap.org/wiki/Overpass_API/Areas Les areas sont définis avec des critères en dur auxquels la relation en question ne correspond pas ... dommage. -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bonne et heureuse année 2013
Le 3 janvier 2013 21:10, seyeize ize seyeizeinformati...@gmail.com a écrit : Happy new year to everyone. Bon allez c'est dit pour tout le monde. Le nombre de ces messages qui pulullent en janvier envoyés à n'importe qui (y compris pour la pub) doit être réduit. Envoyez vos vœux à votre famille, achetez une belle carte, au moins vous saurez à qui vous les envoyez. Je n'ai que trop de ces messages depuis n'importe quel site ou projet, cela ne rime à rien. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
